Перенос базы данных 1С между серверами — стандартная задача администрирования. Однако при этом часто возникает классическая проблема: базу данных обновили до более новой версии СУБД (например, перенесли на SQL Server 2012), а затем потребовалось развернуть ее резервную копию на старом сервере (например, на SQL Server 2008). Попытка стандартного восстановления из файла .bak или прикрепления файлов .mdf/.ldf на старой версии сервера неизменно заканчивается ошибкой совместимости.
В этой статье мы подробно разберем, почему Microsoft SQL Server не поддерживает обратную совместимость бэкапов, проанализируем технические нюансы структуры БД и рассмотрим рабочие методы решения этой проблемы, в том числе для баз данных большого объема (около 350 ГБ).
Разберем первопричину проблемы. Многие администраторы предполагают, что если в настройках базы данных на новом SQL Server изменить уровень совместимости (Compatibility Level) на старую версию (например, установить уровень 100 для SQL Server 2008 внутри SQL Server 2012), то бэкап легко восстановится на старом движке. К сожалению, это заблуждение.
Необходимо четко разграничивать понятия Compatibility Level и Database Version (внутренний физический формат версии базы данных):
Как только база данных подключается к более новой версии СУБД, ее физическая структура автоматически и безвозвратно обновляется (выполняется внутренний апгрейд метаданных). Движок старого SQL Server физически не обучен чтению новой разметки заголовков и системных таблиц, созданных более новыми версиями СУБД. Механизма автоматического "физического даунгрейда" в Microsoft SQL Server не существует.
Поэтому восстановить бэкап .bak или прикрепить файлы .mdf/.ldf с версии 2012 на версию 2008 напрямую нельзя.
Ниже мы подробно рассмотрим проверенные и эффективные методы решения этой задачи.
---
Самый простой путь для администратора 1С — это использование платформенного механизма выгрузки информационной базы в файл .dt. Платформа 1С хранит конфигурацию и данные в универсальном формате, не зависящем от версии конкретной СУБД. База, выгруженная в .dt на SQL Server 2012, без проблем загрузится на SQL Server 2008.
Однако для баз большого объема (например, 350 ГБ) прямая выгрузка на рабочей базе несет огромные риски:
Для решения этой проблемы применим эффективный обходной путь. Разберем его по шагам:
Staging_Copy) из свежего бэкапа. С этой базой никто из пользователей работать не будет.Staging_Copy..dt (через меню Администрирование -> Выгрузить информационную базу...)..dt переносим на целевой сервер с SQL Server 2008, создаем там пустую базу данных в СУБД, регистрируем ее в кластере 1С, заходим в конфигуратор и загружаем данные (Администрирование -> Загрузить информационную базу...).---
Если по каким-то причинам выгрузка через .dt не подходит или завершается с ошибками формата потока, мы можем воспользоваться генерацией T-SQL скриптов непосредственно в среде SQL Server Management Studio (SSMS).
Обратим внимание на важный нюанс: если просто сгенерировать скрипт создания таблиц и вставки строк для базы в 350 ГБ, мы получим текстовый файл размером в сотни гигабайт. Попытка открыть его в среде SSMS приведет к моментальному падению программы из-за нехватки оперативной памяти (out of memory). Поэтому действовать нужно аккуратно.
Проанализируем пошаговый алгоритм генерации совместимого скрипта:
db_backup.sql).Поскольку файл будет огромным, выполнять его на целевом сервере (SQL Server 2008) через графический интерфейс SSMS нельзя. Для этого мы применим консольную утилиту sqlcmd, которая оптимизирована под чтение тяжелых файлов пакетами.
Для запуска скрипта выполним следующую команду в командной строке (cmd) на целевом сервере:
sqlcmd -S Имя_Целевого_Сервера -d Имя_Пустой_Базы -i C:\Scripts\db_backup.sql -a 32767
Параметр -a 32767 задает увеличенный размер сетевого пакета команд, что существенно ускоряет выполнение транзакций по вставке данных.
---
Для больших баз данных вставка сотен миллионов строк через текстовые файлы T-SQL скриптов — крайне неэффективный и медленный процесс. Гораздо надежнее использовать встроенную технологию SQL Server Integration Services (SSIS).
Рассмотрим этот мощный инструмент, который позволяет перенести данные напрямую из одной СУБД в другую без промежуточных текстовых файлов. Нам понадобятся оба запущенных сервера в одной локальной сети.
Разберем процесс по шагам:
Этот метод является одним из самых производительных и безопасных для переноса структуры и данных баз данных 1С объемом 350 ГБ и более.
---
Еще один профессиональный способ переноса данных "на лету" без использования графических мастеров — это настройка связи между серверами СУБД через механизм Linked Server.
Проанализируем этот сценарий. Мы можем связать старый сервер SQL Server 2008 с новым сервером SQL Server 2012 напрямую, а затем запустить SQL-запрос, который перекачает данные из таблиц источника в таблицы приемника.
Для настройки связанного сервера на целевом сервере SQL Server 2008 выполним следующий T-SQL скрипт:
EXEC sp_addlinkedserver
@server = N'SourceSQL2012',
@srvproduct=N'SQL Server';
GO
EXEC sp_addlinkedsrvlogin
@rmtsrvname = N'SourceSQL2012',
@useself = N'FALSE',
@locallogin = NULL,
@rmtuser = N'sa',
@rmtpassword = N'Ваш_Пароль_sa_На_Источнике';
GO
После успешного создания связи мы можем переносить данные из таблиц с помощью прямого запроса. Сначала мы создаем пустую структуру таблиц на сервере-приемнике (например, скопировав схему через SSMS), а затем запускаем транзакционное наполнение таблиц:
-- Пример ручного переноса данных конкретной таблицы
-- Включаем возможность вставки явных значений в автоинкрементное поле (Identity)
SET IDENTITY_INSERT Имя_Локальной_Таблицы ON;
INSERT INTO Имя_Локальной_Таблицы (Поле1, Поле2, Поле3)
SELECT Поле1, Поле2, Поле3
FROM [SourceSQL2012].[Имя_Удаленной_БД].[dbo].[Имя_Удаленной_Таблицы];
SET IDENTITY_INSERT Имя_Локальной_Таблицы OFF;
При использовании данного метода для баз 1С необходимо автоматизировать обход всех таблиц метаданных с помощью динамического SQL. Системные администраторы могут написать скрипт-курсор, который будет поочередно отключать внешние ключи (foreign keys), переносить данные по каждой таблице и включать ограничения обратно.
---
Мы подробно разобрали физические ограничения совместимости файлов баз данных Microsoft SQL Server и изучили альтернативные варианты даунгрейда версии СУБД.
Подведем итог и выберем оптимальную стратегию работы:
.dt и процесс падает по таймауту, оптимально использовать Метод 3 (Перенос схемы структуры с последующим заполнением через SQL Server Import and Export Wizard). Пакетная вставка (Bulk Insert) обеспечит максимальную производительность без перегрузки транзакционного лога СУБД.