Можно ли обновить нетиповые SQL-базы через файловый вариант и как сделать это правильно

При переходе с администрирования файловых баз 1С на клиент-серверный вариант у многих специалистов возникает соблазн использовать привычные инструменты, такие как выгрузка в формат .dt. Рассмотрим ситуацию, когда необходимо обновить сильно устаревшие и доработанные конфигурации (например, БП 3.0.67 и ЗУП 3.1.8), работающие на PostgreSQL. Разберем, насколько оправдан переход в файловый режим для выполнения обновления и какие риски это несет для целостности данных.

Анализ рисков использования формата .dt для обновления

Предложенная схема «SQL-база -> выгрузка в .dt -> обновление в файловом варианте -> загрузка обратно в SQL» на первый взгляд кажется логичной, так как файловый движок прощает многие ошибки СУБД. Однако проанализируем скрытые угрозы этого метода:

1. Ограничение размера таблиц: Файловая база (формат 1CD) имеет жесткий лимит — размер любой внутренней таблицы не может превышать 4 Гб. При обновлении таких объемных конфигураций, как ЗУП 3.1, временные таблицы и индексы могут мгновенно разрастись, что приведет к фатальному сбою процесса.
2. Логическая целостность: Формат .dt предназначен для переноса данных, а не для резервного копирования. Если в SQL-базе есть нарушения ссылочной целостности, механизм выгрузки может их проигнорировать, и после обратной загрузки вы получите базу с «битыми» ссылками или отсутствующими записями.
3. Потеря специфических настроек: При загрузке .dt в новую или существующую SQL-базу могут сброситься настройки регламентных и фоновых заданий, что критично для автоматизации учета.

Вывод: Использовать этот метод стоит только в том случае, если штатное обновление на сервере выдает неинформативную ошибку, которую не удается устранить стандартным тестированием и исправлением (ТИИ).

Совместимость платформы и СУБД PostgreSQL

Выясним причину возможных проблем при обновлении. В рассматриваемом случае используется платформа 8.3.15.1830 и PostgreSQL 9.0.3-3.1C. Это критическое сочетание. Современные версии платформы (начиная с 8.3.14) требуют более актуальных сборок PostgreSQL (не ниже 9.2, а лучше 11 или 12 версии от 1С).

Старая СУБД может некорректно обрабатывать запросы на реструктуризацию таблиц, которые генерирует новая платформа при обновлении метаданных БП 3.0 и ЗУП 3.1. Если вы столкнулись с падением процесса обновления в клиент-серверном режиме, в первую очередь следует рассмотреть вопрос обновления версии PostgreSQL до рекомендованной вендором.

Блокировка пользователей и подготовка к обновлению

Рассмотрим по шагам, как правильно подготовить серверную базу к обновлению, не прибегая к выгрузке в файловый вариант. Основная задача — исключить активность пользователей и фоновых процессов.

Для этого воспользуемся Консолью администрирования серверов 1С:

1. Зайдем в свойства информационной базы.
2. Установим флаг «Блокировка начала сеансов включена».
3. В поле «Ключ разрешения» введем произвольную строку, например: AdminService.
4. Установим флаг «Блокировка регламентных заданий включена».

Теперь пользователи не смогут войти в систему. Чтобы зайти в Конфигуратор самому, запустим его с параметром /UC. Рассмотрим пример командной строки:

"C:\Program Files\1cv8\8.3.15.1830\bin\1cv8.exe" DESIGNER /S"ИмяСервера\ИмяБазы" /UC"AdminService"

Этот метод позволяет работать с базой администратору, игнорируя общую блокировку. Перед началом процесса обязательно отключите все текущие сеансы в консоли сервера.

Работа с нетиповыми конфигурациями (доработками)

Проанализируем ситуацию с нетиповыми базами. Если конфигурации были доработаны (изменены модули, добавлены реквизиты), категорически нельзя использовать метод «Загрузить конфигурацию из файла» (.cf). Это полностью сотрет все изменения предыдущего администратора.

Правильный алгоритм действий:

1. Выполним сравнение и объединение с новым файлом обновления (.cfu или .cf нужного релиза).
2. В окне сравнения-объединения снимем галочки с объектов, которые были кастомизированы (они помечены специальными значками).
3. Для измененных объектов воспользуемся механизмом трехстороннего объединения, чтобы перенести новый функционал типового релиза, сохранив при этом ваши доработки.
4. Обратим внимание на внешние обработки и отчеты. Если они подключены через механизм «Дополнительные отчеты и обработки», они хранятся в самой базе. При обновлении через .dt они переносятся, но могут перестать работать из-за смены программного интерфейса (API) конфигурации. Потребуется их ручная адаптация.

Рекомендации по резервному копированию на SQL

Поскольку выгрузка в .dt не является полноценным бэкапом для клиент-серверного варианта, разберем, как обезопасить себя. Перед любым действием в SQL-варианте необходимо создавать снапшот базы средствами СУБД. Для PostgreSQL используйте утилиту pg_dump:

pg_dump -h localhost -U postgres -F c -b -v -f "C:\Backup\base_before_update.backup" base_name

Такой бэкап позволит восстановить базу за считанные минуты в случае неудачной реструктуризации, в то время как загрузка из .dt может занять часы.

Особенности обновления ЗУП 3.1

Проанализируем специфику ЗУП 3.1.8. При переходе на актуальные релизы (например, до 3.1.10 и выше) происходит глобальное изменение структуры регистров расчета. Это самая тяжелая стадия обновления. В клиент-серверном варианте этот процесс проходит значительно быстрее за счет использования ресурсов сервера СУБД. Файловый вариант на локальном компьютере администратора может просто «зависнуть» на стадии Обновление информационной базы... из-за нехватки оперативной памяти или производительности дисковой подсистемы.

Рекомендация: Всегда выполняйте пробное обновление на копии базы, развернутой в той же серверной среде, что и основная база. Только так вы сможете предсказать время простоя и выявить ошибки несовместимости версий 1С и PostgreSQL.