← На главную

Перенос информационной базы 1С между разными версиями СУБД Microsoft SQL Server часто становится серьезной технической задачей, особенно когда требуется выполнить «даунгрейд» — переход с более новой версии (например, SQL 2017) на более старую (SQL 2012). В этой ситуации стандартные механизмы, такие как создание резервной копии .bak и её восстановление (Restore) или отсоединение и присоединение файлов .mdf/.ldf (Attach/Detach), не работают. Это связано с тем, что Microsoft SQL Server не обладает обратной совместимостью на уровне физических файлов: внутренняя структура страниц данных в версии 2017 отличается от 2012, и старый сервер просто не поймет формат нового файла.

В данной статье мы разберем, как решить эту задачу исключительно средствами SQL Server, минуя стандартную выгрузку 1С в формат .dt, которая на больших базах (от 75 ГБ и выше) может выполняться крайне медленно или приводить к ошибкам нехватки памяти.

Почему нельзя просто восстановить бэкап?

Прежде всего, проанализируем техническое ограничение. Каждый выпуск SQL Server имеет свой внутренний номер версии базы данных (Database Internal Version). Когда мы пытаемся выполнить команду RESTORE DATABASE на версии 2012, используя файл, созданный в 2017, система выдает ошибку, сообщая, что версия файла выше версии сервера. Даже если вы установите Compatibility Level (режим совместимости) в значение 110 (соответствует SQL 2012) на исходном сервере 2017, это изменит лишь логику работы оптимизатора запросов и доступность функций T-SQL, но не изменит физический формат хранения данных в .mdf.

Рассмотрим рабочие сценарии, которые позволят нам обойти это ограничение.

Метод 1. Использование мастера генерации скриптов (Generate Scripts)

Этот способ считается одним из самых надежных для баз среднего объема. Он заключается в создании SQL-запросов, которые сначала воссоздают структуру всех таблиц (схему), а затем наполняют их данными. Разберем этот процесс по шагам:

1. Откроем SQL Server Management Studio (SSMS) и подключимся к исходному серверу (SQL 2017).
2. Нажмем правой кнопкой мыши на нужную базу данных и выберем Tasks (Задачи) -> Generate Scripts (Сгенерировать скрипты).
3. В мастере выбора объектов отметим всю базу целиком со всеми таблицами, индексами и типами данных.
4. На этапе выбора параметров публикации нажмем кнопку Advanced (Дополнительно). Это самый важный момент.
5. В появившемся окне найдем параметр Script for Server Version и выберем SQL Server 2012.
6. Найдем параметр Types of data to script и обязательно выберем значение Schema and data (Схема и данные). По умолчанию там стоит только «Schema», что перенесет пустые таблицы без информации.
7. Сохраним полученный скрипт в файл. Если база большая (как в нашем примере 75 ГБ), файл может получиться огромным. В таком случае лучше сохранять скрипт частями или использовать специализированные утилиты для выполнения тяжелых SQL-файлов (например, sqlcmd).

После генерации скрипта выполним его на целевом сервере SQL 2012 в предварительно созданной пустой базе. Обратим внимание, что в 1С структура таблиц очень обширна, поэтому выполнение скрипта может занять значительное время.

Метод 2. Использование формата BACPAC (Data-tier Application)

Технология BACPAC была разработана для миграции баз в облако Azure, но она отлично подходит и для локального даунгрейда. В отличие от обычного бэкапа, .bacpac содержит описание схемы и данные в формате JSON/XML, что делает его независимым от физической версии SQL Server.

Рассмотрим алгоритм действий:

1. В SSMS на исходном сервере выберем базу, далее Tasks -> Export Data-tier Application.
2. Укажем путь для сохранения файла с расширением .bacpac.
3. На целевом сервере SQL 2012 выберем пункт Import Data-tier Application в контекстном меню папки Databases.

Важный нюанс: Если в базе 1С используются специфические объекты, которые появились только в версии 2017 (например, полнотекстовые индексы определенного типа), экспорт может прерваться с ошибкой. В этом случае придется временно удалить конфликтующие объекты в исходной базе и создать их заново уже на SQL 2012.

Метод 3. Мастер импорта и экспорта данных (Import and Export Wizard)

Если база весит десятки и сотни гигабайт, текстовые скрипты могут не подойти. Посмотрим на метод прямой перекачки данных между двумя запущенными серверами. Для этого нам понадобится сетевой доступ между SQL 2017 и SQL 2012.

1. На целевом сервере (SQL 2012) создадим пустую базу данных с теми же настройками Collation (сортировки), что и в оригинале. Это критично для 1С, обычно используется Cyrillic_General_CI_AS.
2. Нажмем правой кнопкой на созданную базу: Tasks -> Import Data.
3. В качестве источника (Source) укажем SQL 2017 и нашу рабочую базу.
4. В качестве назначения (Destination) укажем локальный SQL 2012 и новую пустую базу.
5. Выберем режим «Copy data from one or more tables or views».
6. В списке таблиц выберем все. Важно: перед запуском необходимо убедиться, что на целевой базе уже создана структура таблиц. Лучше всего сначала перенести «Схему» через Generate Scripts (без данных), а затем наполнить её через Import Wizard.

Метод 4. Настройка репликации данных

Этот способ подходит для опытных администраторов и ситуаций, когда простой базы должен быть минимальным (режим 24/7). Проанализируем схему:

Мы можем настроить транзакционную репликацию, где SQL 2017 будет выступать в роли Издателя (Publisher), а SQL 2012 — в роли Подписчика (Subscriber). Данные будут постепенно синхронизироваться. Когда репликация завершится и данные на обоих серверах станут идентичными, мы просто отключаем репликацию, и на SQL 2012 остается полноценная рабочая копия базы. Это позволяет избежать долгого простоя, связанного с копированием 75 ГБ данных «одним куском».

Особенности работы с 1С при переносе через SQL

Выясним причины, по которым после переноса база может не сразу заработать в 1С. При использовании SQL-инструментов переноса мы копируем только таблицы и данные, но можем упустить специфические настройки. После успешного разворота базы на SQL 2012 выполним следующие действия:

• Очистка таблицы Config: Если при переносе возникли проблемы с кэшем конфигурации, иногда требуется очистить временные данные, хотя при полном переносе через скрипты это обычно не требуется.
• Обновление статистики: После массового импорта данных в SQL 2012 статистика будет неактуальной. Обязательно выполним команду: EXEC sp_updatestats; Это позволит избежать жутких тормозов 1С в первые часы работы.
• Пересоздание индексов: Если перенос шел через Import/Export Wizard, индексы могли не перенестись. Лучшим решением будет запустить «Тестирование и исправление» в конфигураторе 1С на новой базе с галочкой «Реиндексация таблиц информационной базы».

Резюме по выбору метода

Проанализировав ситуацию, выберем оптимальный путь в зависимости от условий:

1. База до 20-30 ГБ: Оптимально использовать Generate Scripts (Schema and Data). 2. База 70-100 ГБ (наш случай): Лучше использовать BACPAC или комбинацию Generate Scripts (только схема) + Import Wizard (только данные). 3. База более 500 ГБ: Только репликация или все же использование 1С-ного .dt на очень мощном сервере с быстрыми NVMe дисками.

Таким образом, мы выяснили, что перенос базы 1С «вниз» по версии SQL Server возможен и без использования .dt, если грамотно использовать встроенные инструменты трансформации данных СУБД.