Перенос базы данных «вниз» по версии (с более новой версии MS SQL Server на более старую) — задача, с которой часто сталкиваются системные администраторы при оптимизации лицензионной политики или смене серверного оборудования. Стандартный механизм Backup/Restore в данном случае не работает, так как структура файлов базы данных (MDF/LDF) в более новых версиях SQL содержит изменения, которые старый движок просто «не понимает». При попытке восстановить бэкап 2016 года на сервере 2014 года вы неизбежно получите ошибку о несовместимости версий (например, версия 852 не может быть открыта версией 782).
В этой статье мы подробно разберем все доступные способы миграции, проанализируем их плюсы и минусы, а также выясним, какой метод будет наиболее эффективным для базы объемом около 40 Гб.
Для администратора 1С этот способ является наиболее естественным и надежным. Несмотря на опасения, что база объемом 40 Гб «не пролезет» или будет выгружаться слишком долго, практика показывает обратное. Рассмотрим этот процесс пошагово.
Во-первых, важно понимать, что 40 Гб в формате SQL (MDF) — это не то же самое, что 40 Гб в формате .dt. Файл выгрузки 1С использует сильное сжатие и содержит только логические данные. База в 40 Гб в формате SQL часто превращается в .dt файл размером всего 2–5 Гб. Разберем алгоритм действий:
Проанализируем временные затраты: для базы в 40 Гб процесс выгрузки обычно занимает от 30 до 60 минут, а загрузка — от 1 до 2 часов, в зависимости от дисковой подсистемы. Если запустить процесс вечером, то к утру база будет гарантированно готова к работе. Это самый безопасный метод, так как 1С сама пересоздаст все индексы и структуру таблиц, совместимую с текущей версией SQL.
Если по каким-то причинам использование .dt невозможно, мы можем прибегнуть к штатным средствам SQL Server Management Studio (SSMS). Этот метод позволяет создать T-SQL скрипт, который сначала воссоздаст структуру базы, а затем заполнит ее данными.
Рассмотрим нюансы настройки этого мастера, так как по умолчанию он переносит только структуру (Schema only):
SQL Server 2014.Schema and data.Проанализируем ситуацию: для базы 40 Гб итоговый текстовый файл может получиться огромным (сотни гигабайт). Мы не рекомендуем пытаться открыть его в текстовом редакторе или в самой SSMS — программа зависнет. Выполнять такой скрипт на целевом сервере лучше всего через консольную утилиту sqlcmd.
Это современный и очень удобный способ «логического» переноса базы. Файл .bacpac содержит в себе и схему, и данные в сжатом виде. В отличие от обычного бэкапа, он не привязан к конкретной физической версии движка SQL.
Разберем процесс:
.dt, но на уровне SQL.Важный момент: Перед экспортом необходимо убедиться, что в базе 2016 года не используются функции, которых физически нет в 2014 версии. Например, Temporal Tables или специфическое сжатие данных, доступное только в Enterprise-версиях старых редакций.
Если нам нужно перенести данные максимально быстро («за 15 минут утречком», как упоминалось в обсуждении), и оба сервера находятся в одной локальной сети, мы можем использовать механизм Linked Server. Рассмотрим, как это работает.
Сначала на сервере SQL 2014 создадим пустую базу с идентичной структурой. Проще всего это сделать, выполнив скрипт «только схема» (Schema only) из Метода 2. Затем настроим связь между серверами:
EXEC sp_addlinkedserver
@server = 'SQL2016_Source',
@srvproduct = '',
@provider = 'SQLNCLI',
@datasrc = 'IP_адрес_или_имя_сервера';
После создания линка мы можем переливать данные из таблиц одной базы в другую прямыми запросами INSERT INTO ... SELECT * FROM. Однако, для 1С это трудоемкий процесс из-за огромного количества таблиц. Для автоматизации можно использовать динамический SQL, который в цикле пройдет по всем таблицам системы. Выясним причину, почему это может быть быстрее: данные передаются по сети напрямую из памяти в память, минуя промежуточные файлы выгрузки.
Часто возникает заблуждение, что если в свойствах базы на SQL 2016 изменить Compatibility Level на SQL Server 2014 (120), то бэкап станет совместимым. Разберем, почему это не так. Параметр совместимости влияет только на поведение оптимизатора запросов, доступность определенных функций T-SQL и синтаксис. Он не меняет внутренний формат хранения данных в файлах MDF и формат заголовка бэкапа. Движок SQL Server 2014 просто откажется открывать файл, помеченный версией 2016, независимо от настроек совместимости внутри него.
При миграции с 2016 на 2014 версию мы можем столкнуться с рядом проблем, которые нужно предусмотреть заранее:
.dt или .bacpac является более предпочтительным, так как он корректно обрабатывает зависимости объектов..dt) необходимо обязательно выполнить обновление статистик и переиндексацию. В противном случае производительность базы на новом сервере может неприятно удивить пользователей.Проанализировав ситуацию, мы приходим к следующим выводам. Если время позволяет (есть окно в 2–4 часа), используйте выгрузку через .dt. Это гарантирует отсутствие ошибок на уровне SQL и чистоту структуры данных. Для базы в 40 Гб это абсолютно штатная операция. Если же требуется максимально автоматизированный перенос на уровне SQL, посмотрите в сторону .bacpac или генерации скриптов с опцией Schema and data.
Помните, что после перехода на SQL 2014 стоит проверить настройки флагов трассировки (например, флаг 4199 для оптимизатора) и убедиться, что производительность ключевых операций в 1С не снизилась из-за использования более старого движка СУБД.