К статье
Практический материал

Администрирование · 10 мин

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

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

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

Основной риск при обновлении клиент-серверной базы — реструктуризация. Когда 1С меняет структуру таблиц (добавляет реквизиты, изменяет типы), SQL-сервер перестраивает объекты, и на больших базах этот процесс занимает от десятков минут до нескольких часов. Всё это время пользователи не должны работать с базой.

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

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

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

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

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

Резервное копирование средствами SQL Server

Для клиент-серверной базы выгрузка в .dt из конфигуратора — не лучший и не единственный способ бэкапа. На больших базах выгрузка занимает часы и не гарантирует целостность при активной работе пользователей. Основной метод — полная резервная копия (FULL backup) средствами SQL Server через SQL Server Management Studio или скриптом.

Откройте SSMS, найдите нужную базу, щёлкните правой кнопкой — «Задачи» → «Создать резервную копию», выберите тип «Полная» и укажите путь к файлу на диске с достаточным объёмом. Дождитесь завершения и убедитесь, что файл создан и имеет ненулевой размер.

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

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

Отключение пользователей и регламентных заданий

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

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

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

Загрузка обновления конфигурации

Запустите конфигуратор в монопольном режиме. Для типовой конфигурации без доработок используйте путь «Конфигурация» → «Поддержка» → «Обновить конфигурацию» и укажите файл обновления (.cfu) или папку с дистрибутивом. Система покажет список доступных обновлений — выберите нужное и запустите процесс.

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

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

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

Обработчики обновления и первый запуск

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

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

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

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

Номер версии конфигурации в разделе «О программе»
Норма

Совпадает с версией установленного релиза

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

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

Журнал регистрации за период обновления
Норма

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

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

Ошибки в процедурах обновления, отложенные обработчики не выполняются

Ключевые отчёты и документы
Норма

Открываются, данные согласованы с периодом до обновления

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

Пустые отчёты, ошибки при проведении документов

Фоновые и регламентные задания
Норма

Выполняются по расписанию без ошибок

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

Задания блокируются или завершаются аварийно

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

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

Типичные ошибки
01
Обновление без бэкапа SQL — при сбое реструктуризации базу не восстановить быстро
02
Незавершённые сеансы пользователей — конфигуратор не может получить монопольный доступ, обновление откатывается
03
Нехватка места в журнале транзакций — реструктуризация падает на середине с ошибкой SQL
04
Запуск рабочей базы сразу после обновления без проверки — ошибки обработчиков обнаруживают пользователи
05
Пропуск промежуточных релизов — обновление невозможно, приходится ставить версии последовательно

Если обновление завершилось ошибкой на этапе реструктуризации, не пытайтесь повторно запускать его наугад. Проанализируйте сообщение об ошибке и журнал SQL Server; в большинстве серьёзных случаев правильный путь — восстановить базу из резервной копии, устранить причину (место на диске, блокировки, версия платформы) и повторить процедуру.

Маршрут решения

Как выбрать действие

Конфигурация типовая, без доработокОбновляйте штатно через «Обновить конфигурацию», тестовый прогон желателен, но короткий
В конфигурацию внесены доработкиСначала прогоните объединение на тестовой копии, зафиксируйте все конфликты и решения по ним
База большая, реструктуризация занимает часыПланируйте обновление на нерабочее время и предупредите пользователей о простое заранее
Обновление завершилось с ошибкой реструктуризацииВосстановите базу из SQL-бэкапа, устраните причину и повторите на тестовой копии

FAQ по обновлению баз 1С на SQL-сервере

Можно ли обновлять базу, пока пользователи работают?

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

Достаточно ли выгрузки в .dt вместо бэкапа SQL?

Для небольших баз — допустимо, но для рабочих клиент-серверных баз основным средством должна быть полная резервная копия SQL Server. Она создаётся быстрее, восстанавливается быстрее и корректно фиксирует согласованное состояние данных.

Сколько времени занимает обновление?

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

Что делать, если обновление «зависло» на реструктуризации?

Сначала проверьте в SQL Server, идёт ли реальная работа (активные запросы, рост файлов). Долгая реструктуризация больших таблиц — нормальное явление. Прерывать процесс стоит только при явной ошибке или полном отсутствии активности; после прерывания восстанавливайте базу из бэкапа.

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

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

Как откатиться к предыдущей версии, если после обновления нашлись проблемы?

Штатного «отката» в 1С нет: возврат выполняется восстановлением базы из резервной копии SQL, созданной до обновления. Данные, введённые после обновления, при этом будут потеряны, поэтому критично проверять результат сразу после обновления, до массового возврата пользователей.

Итог

Что важно запомнить

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