Перенос крупной информационной базы, которая годами развивалась на старых версиях программного обеспечения, — это всегда серьезный вызов для системного администратора и программиста 1С. Типичная ситуация: база успешно работала на платформе 1С:Предприятие 8.2 под управлением MS SQL Server 2008, но пришло время модернизировать серверное оборудование и обновить ПО до современных версий, например, до платформы 8.3.14+ (или более свежей) и СУБД MS SQL Server 2017.
Часто при таком переходе специалисты сталкиваются с неприятным симптомом: выгрузка и загрузка файлов данных (.dt) проходят без видимых замечаний, в Конфигуратор зайти удается, но при попытке запустить систему в режиме «1С:Предприятие» программа аварийно завершает работу с неинформативной ошибкой. В этой статье мы подробно разберем причины этой проблемы, выясним, почему изменяется структура индексов, и рассмотрим пошаговый алгоритм безопасной и корректной миграции базы данных.
Для того чтобы понять природу сбоя, проанализируем изменения в архитектуре хранения данных СУБД, которые произошли при переходе со старых версий платформы 1С на новые:
[Разделители] + Период + [Измерения]. Начиная с платформы 8.3, логика была оптимизирована разработчиками для повышения быстродействия, и теперь кластерный индекс строится по принципу [Разделители] + [Измерения] + Период. При первом запуске базы на новой платформе СУБД пытается выполнить глобальную реструктуризацию этих таблиц.Violation of PRIMARY KEY / UNIQUE KEY constraint).Выгрузка базы через файл .dt скрывает эти проблемы при создании архива, но при развертывании и первом обращении к данным новая платформа пытается «на лету» преобразовать структуру таблиц, что приводит к критическому сбою.
Многие специалисты по привычке используют механизм выгрузки и загрузки информационной базы через файлы .dt. Рассмотрим, почему в данном случае это является ошибочной методикой:
.dt — это внутренний логический формат архива 1С, предназначенный в первую очередь для файловых баз небольшого объема. При его загрузке платформа пытается заново пересоздать все таблицы СУБД и наполнить их данными..dt крайне непроизводителен и чувствителен к нехватке оперативной памяти..dt на новой платформе эти индексы попытаются построиться по новым правилам 1С 8.3, что моментально вызовет транзакционный сбой.Правильный подход — использовать механизмы резервного копирования и восстановления самой СУБД (MS SQL Server Backup / Restore). Это гарантирует физическую целостность данных на момент миграции, после чего мы сможем точечно исправить проблемы совместимости непосредственно в SQL-базе.
Разберем детально безопасную методику переноса базы, которая позволит избежать ошибок индексации и обеспечит стабильный запуск системы.
Перед тем как переносить базу, необходимо максимально очистить ее от логического «мусора» средствами старой платформы:
Создадим бэкап базы данных средствами SQL Server Management Studio (SSMS) на старом сервере:
.bak и выполните операцию.На новом сервере выполним восстановление базы данных:
.bak в качестве источника и восстановите базу под нужным именем.После восстановления базы со старого SQL Server 2008 на SQL Server 2017, она наследует старые настройки совместимости, что может приводить к ошибкам и блокировкам. Нам необходимо принудительно перенастроить параметры базы данных. Для этого выполним специальный SQL-скрипт.
Выясним причину необходимости этих настроек:
READ_COMMITTED_SNAPSHOT база при реструктуризации может уйти во взаимоблокировку (deadlock).Выполним следующий T-SQL запрос в среде SSMS на новом сервере:
-- Изменяем уровень совместимости базы данных до SQL Server 2017 (140)
ALTER DATABASE [Имя_Вашей_Базы] SET COMPATIBILITY_LEVEL = 140;
GO
-- Включаем режим READ_COMMITTED_SNAPSHOT (требует монопольного доступа, сбрасываем активные соединения)
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
GO
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
GO
-- Ограничиваем параллелизм выполнения запросов для базы данных (MAXDOP = 1)
ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 1;
GO
Теперь база готова к подключению к серверу 1С:Предприятия 8.3:
Во время реструктуризации новая платформа 1С 8.3 последовательно перестроит физическую структуру таблиц СУБД, приведя индексы в соответствие с новыми стандартами. Если на каком-то этапе процесс прервется с ошибкой, обратитесь к журналу регистрации 1С или логам SQL Server. Там будет четко указано имя проблемной таблицы (например, _InfoRgXXXX — регистр сведений или _AccumRgXXXX — регистр накопления), в которой СУБД нашла дублирующиеся записи. Вы сможете точечно очистить эти записи через SQL-запрос и повторить реструктуризацию.
Рассматривая проблему совместимости старых конфигураций с новыми платформами, обратите внимание на стабильность релизов:
Следуя этой методике, мы планомерно перенесем базу данных, оптимизируем настройки СУБД под стандарты 1С 8.3 и успешно запустим систему в эксплуатацию на современном и быстром оборудовании.