Ситуация, когда при обновлении конфигурации 1С происходит критический сбой, и база перестает открываться даже в режиме Конфигуратора, является одной из самых сложных для администратора или программиста. Ошибка "Обнаружена незавершенная операция сохранения конфигурации" блокирует любые стандартные попытки исправления через графический интерфейс. В такой ситуации нам на помощь приходят инструменты SQL Management Studio. Разберем подробно, как восстановить работоспособность системы, манипулируя данными в таблицах базы данных.
Проанализируем, что происходит "под капотом" 1С в момент обновления. Когда вы нажимаете "Обновить конфигурацию базы данных", платформа выполняет несколько этапов: копирование метаданных в промежуточные таблицы, реструктуризацию таблиц данных и, наконец, фиксацию изменений. Если на последнем этапе происходит сбой (выключение света, обрыв связи с сервером, нехватка места на диске), в служебных таблицах Config и ConfigSave остаются записи-маркеры, указывающие на незавершенный процесс. При следующем запуске платформа видит эти маркеры и пытается продолжить обновление, но из-за повреждения структуры или кэша это приводит к "вылету" программы.
Прежде чем приступать к "хирургическим" операциям в SQL, выполним обязательные подготовительные шаги:
Этот метод является наиболее предпочтительным, так как он не требует полной замены конфигурации, а лишь убирает признаки "зависшей" транзакции. Рассмотрим последовательность действий в SQL Management Studio.
Выясним причину блокировки, проверив наличие записей о фиксации изменений. Выполним следующий запрос к испорченной базе:
SELECT * FROM [Имя_Вашей_Базы].[dbo].[Config]
WHERE [FileName] IN ('commit', 'dbStruFinal', 'DynamicCommit')
Если запрос вернул строки, значит, именно они не дают системе запуститься. Для восстановления нам необходимо очистить таблицу ConfigSave (где хранятся временные данные обновления) и удалить маркеры из Config. Реализуем это следующими командами:
-- Очищаем таблицу временных данных конфигурации
DELETE FROM [Имя_Вашей_Базы].[dbo].[ConfigSave]
-- Удаляем маркеры незавершенного обновления
DELETE FROM [Имя_Вашей_Базы].[dbo].[Config]
WHERE [FileName] = 'commit'
DELETE FROM [Имя_Вашей_Базы].[dbo].[Config]
WHERE [FileName] = 'dbStruFinal'
DELETE FROM [Имя_Вашей_Базы].[dbo].[Config]
WHERE [FileName] = 'DynamicCommit'
После выполнения этих команд попробуйте запустить Конфигуратор. В большинстве случаев система "откатится" к состоянию до начала обновления.
Если очистка маркеров не помогла и Конфигуратор все равно не открывается, можно попробовать радикальный метод — полную замену содержимого таблицы Config данными из аналогичной исправной базы (например, из вчерашнего бэкапа, развернутого рядом). Рассмотрим, как сделать это правильно, избегая ошибок дублирования ключей.
Важно: Данный метод сработает корректно только в том случае, если структура таблиц данных (справочники, документы) в SQL еще не была изменена обновлением, либо изменения полностью соответствуют конфигурации-донору.
Разберем алгоритм замены:
Config в испорченной базе, используя команду TRUNCATE. Она работает быстрее, чем DELETE, и полностью освобождает ресурсы.
-- 1. Очистка целевой таблицы
TRUNCATE TABLE [MistakeBase].[dbo].[Config];
-- 2. Перенос данных из эталонной базы
INSERT INTO [MistakeBase].[dbo].[Config]
SELECT * FROM [WriteBase].[dbo].[Config];
После этого крайне важно очистить таблицу ConfigSave в целевой базе, чтобы старые временные данные не конфликтовали с новой конфигурацией:
TRUNCATE TABLE [MistakeBase].[dbo].[ConfigSave];
Иногда записи о необходимости обновления "застревают" в таблице Params. Проанализируем ситуацию, когда удаление из Config не приносит результата. В таблице Params могут содержаться параметры с именами DBConfigUpdate или v8list. Попробуем очистить их.
Также стоит обратить внимание на записи, отвечающие за динамическое обновление. Если база обновлялась "динамически", это часто становится причиной краха. Удалим признак динамического обновления:
DELETE FROM [Имя_Вашей_Базы].[dbo].[Config]
WHERE [FileName] = 'dynamicallyUpdated'
Очистка серверного кэша: Это критически важный шаг. Даже после исправления таблиц в SQL, сервер 1С может хранить "битые" скомпилированные модули в своей оперативной памяти и локальных файлах. Выясним, где они находятся. Обычно это путь:
C:\Program Files\1cv8\srvinfo\reg_1541\UUID_вашей_базы\snccg
Удалите содержимое папки snccg при остановленной службе сервера 1С. Это заставит систему пересобрать кэш метаданных при первом запуске.
Разберем еще один тонкий момент. В таблице Config существует запись с FileName = 'dbSchema'. В ней хранится описание того, как объекты 1С (справочники, регистры) отображаются на таблицы SQL. Если вы подменяете таблицу Config, но структура реальных таблиц в SQL уже успела измениться (например, добавились новые колонки), возникнет несоответствие.
В некоторых случаях помогает удаление записи dbSchema из Config. При запуске Конфигуратора система увидит отсутствие схемы и попытается воссоздать её, анализируя фактическую структуру таблиц базы данных. Однако это рискованная операция, которую следует выполнять только в крайнем случае.
Мы рассмотрели основные методы восстановления базы 1С при сбоях обновления средствами SQL. Подведем итог нашим действиям:
commit и dbStruFinal.Config через TRUNCATE и INSERT.ConfigSave и удаление серверного кэша в папке snccg.Помните, что работа напрямую с таблицами SQL — это крайняя мера. Чтобы минимизировать риски, всегда выполняйте обновление конфигурации базы данных в монопольном режиме и на стабильном оборудовании.