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

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

Главное правило безопасного обновления на SQL — никогда не выполнять его «на живую» в рабочее время и всегда иметь проверенную резервную копию, сделанную именно средствами SQL Server. Копия каталога базы или выгрузка в .dt — это дополнительная страховка, а не замена полноценного бэкапа базы данных.

Ниже разобран полный цикл: подготовка, вывод пользователей, создание копии, установка шаблона обновления, запуск конфигуратора в монопольном режиме, обновление базы данных и проверка результата. Инструкция подходит для типовых конфигураций (Бухгалтерия, Зарплата и управление персоналом, Управление торговлей, ERP) на платформе 8.3.

Что нужно подготовить перед обновлением

До начала работ убедитесь, что у вас есть доступ ко всем трём компонентам: серверу 1С:Предприятия (консоль кластера), серверу СУБД (SQL Server Management Studio) и учётной записи с правами администратора в самой информационной базе. Частая ситуация — администратор имеет доступ к кластеру, но не знает пароль администратора базы, и обновление останавливается на полпути.

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

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

Резервная копия: как сделать правильно на SQL

В клиент-серверном режиме корректная резервная копия создаётся средствами СУБД. Для MS SQL Server это команда BACKUP DATABASE или задача в плане обслуживания. Полная копия (FULL) гарантирует, что базу можно восстановить на момент её создания, независимо от модели восстановления базы.

BACKUP DATABASE [MyBase1C] TO DISK = N'D:\Backup\MyBase1C_before_update.bak' WITH COMPRESSION, CHECKSUM;

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

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

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

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

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

Отдельно отключите регламентные и фоновые задания. В свойствах базы в консоли кластера есть параметр «Блокировка регламентных заданий». Если задание запустится во время обновления, возможны конфликты блокировок и ошибки реструктуризации. Также проверьте, что не запущены обмены данными с другими системами.

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

Установка шаблона обновления и запуск конфигуратора

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

Запустите конфигуратор от имени пользователя с полными правами в базе. Откройте меню «Конфигурация → Поддержка → Обновить конфигурацию». Выберите вариант «Поиск доступных обновлений» — конфигуратор просканирует каталог шаблонов и покажет подходящие релизы. Если нужного релиза нет в списке, проверьте путь к шаблонам и корректность установки дистрибутива.

После выбора релиза конфигуратор покажет окно с описанием изменений и порядком обновления. Подтвердите запуск и дождитесь сообщения «Конфигурация обновлена». Это обновление конфигурации поставщика и основной конфигурации — но не базы данных. До завершения следующего шага база остаётся в старой структуре.

Обновление конфигурации базы данных и его особенности на SQL

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

Во время реструктуризации платформа создаёт новые версии таблиц, копирует в них данные и удаляет старые. Из-за этого база на диске временно растёт — иногда заметно. Убедитесь, что на дисках SQL-сервера достаточно свободного места под файлы данных и журнал транзакций. Переполнение диска посреди реструктуризации — одна из самых тяжёлых аварий.

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

Проверка результата и возврат базы в работу

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

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

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

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

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

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

Частые вопросы об обновлении 1С на SQL-сервере