Как обновлять SQL-базу 1С: полное руководство

Обновление SQL-базы 1С отличается от обновления файловой базы тем, что данные хранятся на сервере СУБД (MS SQL Server, PostgreSQL), а сама информационная база подключается через сервер 1С:Предприятия. Это добавляет этапов: нужно учитывать права на уровне СУБД, блокировки пользователей и корректность резервного копирования именно средствами SQL-сервера.

Типичная ошибка администраторов — обновлять конфигурацию «на живую», пока пользователи работают в базе. Для SQL-базы это особенно опасно: реструктуризация таблиц при активных соединениях может завершиться обрывом, а восстановление потребует отката на резервную копию. Поэтому обновление всегда начинается с подготовки: копии, выгон пользователей и проверки свободного места.

Ниже описан полный цикл обновления SQL-базы 1С: от проверки текущего состояния до контроля результата. Инструкция подходит для типовых конфигураций (Бухгалтерия, Управление торговлей, ЗУП) и для доработанных решений с учётом указанных оговорок.

Подготовка: что проверить до начала обновления

Первое действие — убедиться, что версия платформы 1С совместима с новым релизом конфигурации. Требуемая версия платформы указана в описании поставки обновления (файл описания в каталоге шаблонов или на портале 1С). Если платформа устарела, сначала обновляется она на сервере и на клиентских машинах, и только потом конфигурация.

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

Третий шаг — определить последовательность обновления. Если текущий релиз сильно отстаёт от актуального, обновление выполняется через промежуточные релизы, а не напрямую. Список допустимых переходов указан в файле поставки. Пропуск обязательных промежуточных версий — частая причина ошибок при обновлении.

Резервное копирование SQL-базы

Для SQL-базы резервную копию делают средствами самой СУБД, а не выгрузкой в dt. Для MS SQL Server это команда BACKUP DATABASE или задание в SQL Server Management Studio, для PostgreSQL — pg_dump или pg_basebackup. Копия, сделанная на уровне СУБД, гарантирует целостность данных и позволяет быстро откатить базу в исходное состояние.

Выгрузка в dt через конфигуратор — допустимое дополнение, но не замена SQL-бэкапа. Выгрузка большой базы занимает много времени, а восстановление из dt — ещё дольше. Кроме того, при выгрузке база должна быть в монопольном режиме. Оптимальная схема: полный бэкап средствами СУБД плюс, при желании, dt для переносимости.

Перед началом обновления проверьте, что копия действительно создана и доступна для восстановления. Полезно хотя бы раз выполнить тестовое восстановление в отдельную базу — это единственный способ убедиться, что бэкап рабочий. Хранить копию следует вне дисков, где лежит сама база.

Завершение работы пользователей и блокировка сеансов

Обновление конфигурации базы данных требует монопольного доступа. Все сеансы пользователей, фоновые задания и соединения через веб-сервисы должны быть завершены. Управление сеансами выполняется через консоль кластера серверов 1С:Предприятия (оснастка «Администрирование серверов 1С») или через административную консоль.

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

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

1. 1
   Проверьте совместимость версии платформы с новым релизом конфигурации
2. 2
   Сделайте полную резервную копию средствами СУБД и проверьте её
3. 3
   Убедитесь, что на дисках SQL-сервера достаточно свободного места
4. 4
   Установите блокировку начала сеансов для информационной базы
5. 5
   Завершите активные сеансы и заблокируйте регламентные задания
6. 6
   Проверьте в консоли кластера, что соединений с базой не осталось

Обновление конфигурации через конфигуратор

Откройте конфигуратор под учётной записью с полными правами и выполните пункт меню «Конфигурация — Поддержка — Обновить конфигурацию». Укажите источник обновления: файл поставки (.cfu), каталог шаблонов или файл конфигурации (.cf). Для типовых конфигураций чаще используется обновление из каталога шаблонов, куда предварительно устанавливается дистрибутив обновления.

После анализа конфигуратор покажет список изменённых объектов. Для типовой конфигурации без доработок достаточно подтвердить обновление. Если конфигурация доработана, на этапе сопоставления потребуется ручное разрешение конфликтов: объекты, изменённые и вами, и поставщиком, нужно объединять аккуратно, с анализом каждого отличия. При сомнениях такое обновление лучше выполнять на копии базы.

Завершающий этап — обновление конфигурации базы данных (клавиша F7 или команда в меню «Конфигурация»). Именно на этом шаге выполняется реструктуризация таблиц SQL-базы. Процесс может занимать от нескольких минут до нескольких часов на больших базах. Прерывать его нельзя: обрыв реструктуризации оставляет базу в несогласованном состоянии.

Запуск обработчиков обновления и проверка результата

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

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

Финальная проверка включает: открытие ключевых отчётов и сличение контрольных цифр с показателями до обновления (оборотно-сальдовая ведомость, остатки склада, касса), проверку журнала регистрации на ошибки, тестовое проведение документа. Если контрольные суммы совпали и ошибок нет — снимайте блокировку сеансов и возобновляйте регламентные задания.

Контрольные точки

Как проверить результат обновления

Версия конфигурации в сведениях о программе

Норма

Соответствует целевому релизу

Тревожный признак

Версия не изменилась или отличается от плановой

Обработчики обновления данных

Норма

Все выполнены без ошибок

Тревожный признак

Есть невыполненные или завершившиеся с ошибкой

Контрольные отчёты (ОСВ, остатки)

Норма

Показатели совпадают с данными до обновления

Тревожный признак

Расхождения в суммах или отсутствующие данные

Журнал регистрации

Норма

Нет ошибок за период обновления

Тревожный признак

Ошибки реструктуризации или обработчиков

Работа пользователей после разблокировки

Норма

Документы проводятся, отчёты строятся

Тревожный признак

Ошибки при проведении или открытии форм

Типичные ошибки и как их избежать

Самая частая ошибка — попытка обновления при активных сеансах. Конфигуратор либо не сможет установить монопольный режим, либо администратор принудительно обрывает соединения в середине транзакций пользователей, что приводит к непроведённым документам и жалобам. Всегда планируйте окно обновления и уведомляйте сотрудников заранее.

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

Третья типичная проблема — обновление доработанной конфигурации «вслепую», без анализа изменённых объектов. После такого обновления собственные доработки могут быть затёрты, а типовой функционал — сломан. Для доработанных баз ведите список изменений и выполняйте обновление сначала на тестовой копии, восстановленной из SQL-бэкапа.

FAQ: частые вопросы об обновлении SQL-базы 1С

Можно ли обновить SQL-базу 1С без остановки работы пользователей?

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

Чем отличается бэкап средствами СУБД от выгрузки в dt?

Бэкап средствами СУБД создаётся быстро, не требует монопольного режима (для полной модели восстановления) и восстанавливается за минуты. Выгрузка в dt универсальна и переносима между СУБД, но на больших базах занимает часы и требует монопольного доступа. Для отката после неудачного обновления используйте именно SQL-бэкап.

Что делать, если реструктуризация прервалась с ошибкой?

Не пытайтесь запустить базу в работу. Посмотрите текст ошибки: чаще всего это нехватка места в журнале транзакций или на диске. Устраните причину и попробуйте повторить обновление конфигурации базы данных. Если повторный запуск не помогает — восстановите базу из резервной копии и проведите обновление заново после устранения причины.

Как обновить сильно устаревшую конфигурацию?

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

Нужно ли обновлять платформу при каждом обновлении конфигурации?

Не обязательно, но версия платформы должна быть не ниже требуемой для нового релиза конфигурации. Требование указано в описании поставки. Если текущая платформа подходит — обновляйте только конфигурацию. При обновлении платформы помните, что её нужно установить и на сервер, и на все клиентские машины.

Как безопасно обновить доработанную конфигурацию?

Восстановите копию базы из SQL-бэкапа в тестовую среду и выполните обновление там. На этапе сопоставления внимательно разберите все объекты, изменённые и вами, и поставщиком. После успешного обновления тестовой копии проверьте работу доработок и ключевых отчётов, зафиксируйте порядок действий и повторите его на рабочей базе.