В практике администрирования 1С часто возникает задача: необходимо выполнить сложное и долгое обновление базы данных (например, пропущено много релизов), но делать это на рабочем сервере нельзя, так как он занят пользователями или недостаточно мощен. Решение кажется простым: перенести базу на мощный тестовый сервер, обновить её там, а затем вернуть обратно. Однако, здесь мы сталкиваемся с техническими ограничениями СУБД (в частности MS SQL Server) и особенностями платформы 1С. В этой статье мы подробно разберем, какие способы переноса корректны, как версии SQL влияют на выбор метода и почему формат DT — это не всегда зло, а иногда единственный выход.
Рассмотрим ситуацию, с которой столкнулись участники обсуждения: 1. Есть Рабочий сервер (Сервер 1) с базой данных, которая не обновлялась с начала года. На нем установлена более старая версия MS SQL Server. 2. Есть Мощный сервер (Сервер 2) для выполнения технических работ. На нем установлена более новая версия MS SQL Server. 3. Необходимо перенести базу с Сервера 1 на Сервер 2, выполнить последовательное обновление (около 27 релизов), и корректно вернуть базу на Сервер 1. Главный вопрос: можно ли использовать выгрузку в DT или обязательно использовать средства SQL? И как быть, если версии SQL не совпадают?
Первое, что предлагают опытные администраторы — использовать средства самой СУБД, а именно Backup / Restore или Detach / Attach. Это действительно самый быстрый и надежный способ создания копии.
Однако существует жесткое ограничение MS SQL Server:
Вы не можете восстановить резервную копию (или прикрепить файл базы), созданную в более новой версии SQL, на сервере с более старой версией.
Давайте проанализируем это на примере:
* Перенос "Туда" (Сервер 1 -> Сервер 2): Если на источнике SQL 2012, а на приемнике SQL 2019, то операция Restore пройдет успешно. База автоматически повысит свою внутреннюю версию.
* Перенос "Обратно" (Сервер 2 -> Сервер 1): После обновления базы на SQL 2019, вы делаете бэкап. При попытке развернуть его на SQL 2012 вы получите ошибку. Понижение версии (Downgrade) через бэкап невозможно.
Следовательно, если версии SQL на серверах разные (и рабочий сервер старее), использование классических SQL-бэкапов для возврата данных невозможно.
В описанной ситуации использование штатного механизма выгрузки/загрузки через Конфигуратор (файл с расширением .dt) становится легитимным и рабочим решением.
Разберем, почему это работает:
Файл .dt — это не образ диска и не SQL-дамп. Это специализированный формат 1С, который содержит структуру конфигурации и данные в логическом виде. При загрузке .dt платформа 1С фактически создает структуру таблиц заново и наполняет их данными, независимо от того, какая СУБД находится "под капотом".
Алгоритм действий для переноса базы с разными версиями SQL:
1. Выгрузка с рабочего сервера: Заходим в Конфигуратор -> Администрирование -> Выгрузить информационную базу. Получаем файл DT.
2. Загрузка на мощный сервер: Создаем пустую базу на новом SQL сервере. Заходим в Конфигуратор -> Администрирование -> Загрузить информационную базу.
3. Обновление: Проводим все необходимые операции по обновлению конфигурации.
4. Выгрузка обновленной базы: Снова делаем Выгрузить информационную базу в DT.
5. Возврат на рабочий сервер: Загружаем полученный DT в рабочую базу (предварительно сделав архивную копию!).
Несмотря на то, что DT решает проблему версий SQL, важно помнить, что фирма 1С не рекомендует использовать этот формат как основное средство резервного копирования. Рассмотрим нюансы, которые необходимо учитывать: * Риск незагрузки: Если в базе данных есть скрытые логические ошибки или "битые" ссылки, выгрузка в DT может пройти успешно, но при загрузке процесс прервется ошибкой. В этом случае вы рискуете остаться с нерабочей базой. * Время простоя: Процесс загрузки DT блокирует базу данных. На больших объемах (сотни гигабайт) это может занять часы. * Очистка кэша: При загрузке DT происходит полная перестройка таблиц. Это имеет побочный эффект "сжатия" базы и дефрагментации, но также требует обязательной очистки серверного кэша 1С после операции, чтобы избежать ошибок компиляции. Важное правило: Перед тем как загружать DT обратно на рабочий сервер, обязательно сделайте полный SQL-бэкап текущего состояния рабочей базы. Если DT не загрузится, вы сможете мгновенно откатиться назад.
В обсуждении возник справедливый вопрос: зачем гонять всю базу данных туда-обратно, если меняется только конфигурация? Можно ли обновить копию, сохранить файл конфигурации (CF) и накатить его на рабочую базу? Разберем два подхода к обновлению через конфигурацию.
В меню Конфигуратора есть пункт Конфигурация - Загрузить конфигурацию из файла.
Мы настоятельно не рекомендуем использовать этот метод для обновления рабочей базы, если вы не уверены на 100% в идентичности идентификаторов объектов.
Если в процессе подготовки на копии вы случайно удалили какой-то справочник и создали его заново с тем же именем, для системы это будут два разных объекта (разные UUID). При полной загрузке такой конфигурации на рабочую базу, данные старого справочника будут безвозвратно удалены (SQL выполнит TRUNCATE TABLE), так как в новой конфигурации старого объекта нет.
Более корректный способ — подготовить файл обновления .cfu или полный файл конфигурации .cf и использовать меню Конфигурация - Поддержка - Обновить конфигурацию или Сравнение и объединение.
Однако здесь кроется главная проблема при пропуске большого количества релизов.
Почему нельзя просто накатить последний CF на старую базу?
Процесс обновления 1С состоит из двух этапов:
1. Изменение метаданных: Происходит в Конфигураторе (добавляются новые регистры, справочники, реквизиты).
2. Обработка данных: Происходит в режиме "1С:Предприятие". Специальные процедуры переносят данные из старых реквизитов в новые, заполняют константы по умолчанию и т.д.
Если вы пропустили 20 релизов и сразу накатили последнюю конфигурацию, процедуры обработчиков обновления могут не сработать корректно. Данные для них могут уже находиться не там, где ожидается, или промежуточные процедуры, которые должны были подготовить почву, не были выполнены.
Исходя из анализа обсуждения и технических требований, если пропущено много релизов (например, год обновлений), наиболее безопасным и корректным алгоритмом будет следующий:
1. Подготовка: Сделайте бэкап рабочей базы.
2. Перенос: Используйте .dt файл для переноса базы на мощный тестовый сервер (так мы обходим разницу версий SQL).
3. Обновление: На тестовом сервере выполняйте обновление последовательно. Не обязательно ставить каждый мелкий патч, но все "ключевые" релизы (на которые ссылается документация) должны быть установлены.
4. Запуск Предприятия: После каждого ключевого обновления обязательно запускайте базу в режиме "1С:Предприятие", чтобы отработали процедуры обновления данных. Дожидайтесь окончания всех фоновых заданий по реструктуризации и обработке данных.
5. Возврат:
* Сделайте финальную выгрузку в .dt обновленной базы.
* Остановите работу пользователей на рабочем сервере.
* Сделайте страховой SQL-бэкап рабочей базы.
* Загрузите .dt на рабочий сервер.
Такой подход гарантирует, что данные будут корректно преобразованы (благодаря запускам в режиме Предприятия), а проблемы с версиями SQL будут решены за счет использования формата DT как средства миграции.
При переносе базы учитывайте следующие моменты (включая очистку кэша 1С на терминалах):
* Программные лицензии: При разворачивании базы на новом "железе" лицензия 1С слетит, если она привязана к параметрам сервера. Потребуется активация резервного пин-кода или использование аппаратного ключа.
* Журнал транзакций: При массовом обновлении на тестовом сервере журнал транзакций SQL (LDF) может вырасти до огромных размеров. Переведите модель восстановления базы в Simple на время обновлений, чтобы сэкономить место.
* Блокировка регламентных заданий: При запуске копии базы на тестовом сервере добавьте параметр запуска /AllowExecuteScheduledJobs -Off (или заблокируйте их через консоль администрирования), чтобы копия базы не начала рассылать письма клиентам или обмениваться данными с банками.