Как перенести базу 1С 7.7 большого объема с MS SQL Server 2005 на MS SQL Server 2000?

← На главную

Перенос базы данных «вниз» по версии СУБД (даунгрейд с Microsoft SQL Server 2005 на SQL Server 2000) — задача нетипичная и сложная, особенно когда речь идет о платформе 1С:Предприятие 7.7 и базах данных размером под 90 ГБ. Стандартные средства SQL Server, такие как создание резервной копии с последующим восстановлением (RESTORE DATABASE) или прямое подключение файлов (ATTACH DATABASE), здесь принципиально не работают. Движок MS SQL Server не поддерживает обратную совместимость файлов данных между мажорными версиями.

Разберем подробнее, с какими сложностями приходится сталкиваться при таком переносе, выясним причины типичных ошибок платформы 1С 7.7 и рассмотрим проверенные практические способы решения этой задачи.

Анализ возникающих ошибок и ограничений

При попытке нестандартного переноса данных специалисты сталкиваются со следующими проблемами:

Ошибка несовместимости версий СУБД: При попытке запустить исходную информационную базу на MS SQL Server 2005 штатный конфигуратор 1С 7.7 выдает ошибку: Требуется MS SQL 6.5 + Service 5a или более старшая версия!. Это происходит из-за того, что библиотека BkEnd.dll не рассчитана на парсинг строк версий выше SQL 2000 (версия 8.x). Для работы с SQL 2005 и новее традиционно используется пропатченная библиотека или специальная заглушка.
Ошибка «Нарушена структура таблицы [1SCONST]»: Данная ошибка возникает, если структуру таблиц создают на целевом SQL Server 2000 вручную или через генераторы скриптов DDL (Generate Scripts, SSIS/DTS). Платформа 1С:Предприятие 7.7 крайне чувствительна не только к типам данных и именам колонок, но и к физическому порядку их следования (column ordinal ID), заданному в словаре базы данных 1Cv7.DDS. Если последовательность полей, первичные ключи или свойства NULL/NOT NULL хоть немного отклоняются от стандарта 1С, запуск базы аварийно блокируется.
Ограничение штатного архиватора на размер файла: Попытка сделать стандартную выгрузку базы объемом 90 ГБ через меню «Администрирование — Выгрузить данные» наталкивается на лимит встроенного в платформу 32-битного компрессора (архивы свыше 2–4 ГБ приводят к аварийному завершению работы Конфигуратора).

Способ 1. Использование механизма выгрузки/загрузки с патчем Romix (Рекомендуемый)

Проанализируем самый надежный и простой с точки зрения целостности метаданных способ, которым автор темы успешно решил проблему. Он заключается в штатной логической выгрузке и последующей загрузке данных средствами самой 1С 7.7, но с обходом лимита размера файла выгрузки.

Разберем процесс по шагам:

Подготовим среду на исходном сервере. Убедимся, что платформа 1С 7.7 может корректно подключиться к базе на SQL Server 2005 (в библиотеке BkEnd.dll должна быть отключена проверка версии СУБД).
Применим специализированный патч от разработчика Romix (заменяющий стандартные механизмы сжатия платформы на современные алгоритмы с поддержкой архивов Zip64). Это устраняет ограничение на размер выгружаемого zip-пакета и позволяет формировать дамп таблиц базы любого размера (включая 90–150 ГБ).
Запустим Конфигуратор в монопольном режиме и выполним команду «Администрирование — Выгрузить данные». Процесс формирования архива для базы в 90 ГБ может занять длительное время (вплоть до нескольких суток в зависимости от дисковой подсистемы).
На целевом сервере с MS SQL Server 2000 развернем новую пустую базу данных. Проверим, что на сервере установлен пакет обновлений не ниже Service Pack 3a (SP3a) или Service Pack 4 (SP4), а системный Collation базы совпадает с требованиями русскоязычной платформы (Cyrillic_General_CI_AS).
Создадим новый каталог на диске, поместим туда файл конфигурации 1Cv7.MD, укажем параметры подключения к новой базе на SQL Server 2000 и откроем Конфигуратор.
Выполним пункт меню «Администрирование — Загрузить данные», указав ранее полученный дамп. Платформа 1С сама корректно создаст все таблицы с идеальной последовательностью колонок, загрузит данные и сформирует системные индексы.

Способ 2. Воссоздание правильной структуры Конфигуратором и перелив данных

Если время простоя строго ограничено и ждать долгую выгрузку через архив нет возможности, применим вариант переноса данных напрямую на уровне SQL, но с обязательным формированием схемы самой платформой 1С. Это позволит избежать ошибки с нарушением структуры 1SCONST.

Разберем по шагам правильную последовательность действий:

Создание эталонной схемы таблиц: Создадим чистую базу данных на MS SQL Server 2000. Скопируем файл метаданных 1Cv7.MD в отдельную папку. Запустим Конфигуратор, укажем путь к новой базе на SQL 2000 и выполним сохранение. В этот момент платформа сама сформирует словарь 1Cv7.DDS и создаст в СУБД все таблицы с правильным физическим порядком полей, системными свойствами и типами.
Проверка пустого каркаса: Запустим режим «1С:Предприятие» на пустой базе, чтобы убедиться, что вход выполняется штатно и никаких ошибок структуры нет.
Перенос данных между серверами: Теперь необходимо перенести исключительно строки таблиц, не трогая саму структуру DDL. Для этого свяжем два сервера через механизм Linked Server на MS SQL Server 2000 или настроим задачу импорта/экспорта.
Заполнение таблиц: При переносе через конструкции запросов критически важно указывать точный список полей из словаря 1Cv7.DDS, избегая конструкций с маской звездочки. Посмотрим на пример концептуального переноса данных для таблицы констант:
```
-- Пример запроса переноса данных через связанный сервер
INSERT INTO dbo._1SCONST (ID, OBJID, VALUE, DATE, TIME)
SELECT ID, OBJID, VALUE, DATE, TIME 
FROM [SQL2005_LINKED_SERVER].[DatabaseName].dbo._1SCONST;
```
Восстановление целостности и индексов: После завершения переноса данных по всем таблицам запустим Конфигуратор в монопольном режиме и выполним тестирование и исправление информационной базы с обязательным перестроением индексов (реиндексацией).

Способ 3. Использование нативной утилиты BCP (Bulk Copy Program)

Для ускорения процесса копирования 90 ГБ данных отлично подходит стандартная консольная утилита СУБД — bcp. Она позволяет выгружать и загружать строки на максимальной скорости дисковой подсистемы.

Как и во втором способе, развернем пустую базу на MS SQL 2000 средствами Конфигуратора 1С для получения корректной структуры.
Выполним экспорт данных из каждой таблицы на исходном сервере SQL 2005 в нативном бинарном формате: bcp DatabaseName.dbo._1SCONST out "C:\Dump\_1SCONST.bcp" -n -T -S SQL2005_SERVER
Выполним импорт на целевой сервер MS SQL 2000 с подавлением внешних ограничений и включением блокировки таблицы для максимального быстродействия:
```
bcp DatabaseName.dbo._1SCONST in "C:\Dump\_1SCONST.bcp" -n -T -S SQL2000_SERVER -h "TABLOCK, CHECK_CONSTRAINTS"
```

Перед началом любой из процедур миграции настоятельно рекомендуется выполнить аудит базы: очистить системный журнал регистрации (таблица 1SSYSLOG), усечь журнал транзакций (LDF) в режиме Simple и выполнить сжатие (SHRINKDATABASE). Это позволит существенно снизить объем перемещаемых данных и сократить время простоя системы.