Как восстановить базу 1С после сбоя динамического обновления и ошибки формата потока?

← На главную

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

Разберем детально, почему это происходит на уровне СУБД и какими способами можно вернуть базу к жизни без длительного восстановления всей базы данных из резервной копии.

Почему откат только таблиц Config и ConfigSave не решает проблему?

Проанализируем архитектуру хранения метаданных платформы. При динамическом обновлении платформа 1С не просто заменяет записи в таблицах Config и ConfigSave, а формирует версионные цепочки и служебные маркеры. В процессе сохранения изменений создаются промежуточные бинарные потоки (BLOB-данные), а также обновляются записи в таблице Params (включая флаги незавершенного применения изменений DynamicallyUpdated и маркеры commit).

Если в этот момент происходит обрыв соединения или падение процесса, возникают следующие проблемы:

Рассинхронизация таблиц: метаданные в Config уже частично ссылаются на новые структуры, тогда как в Params и DBSchema сохраняются старые или поврежденные указатели.
Повреждение бинарных потоков: при разборе структуры XML-потока платформа наталкивается на оборванный блок данных и выбрасывает критическую ошибку формата потока.
Кеширование кластера и клиентов: рабочие процессы сервера (rphost) и локальные клиенты продолжают хранить в кеше устаревшие дескрипторы метаданных.
Конфликт с хранилищем конфигурации: если база подключена к хранилищу, записи о захваченных объектах и соответствиях версий (depot.cnf, devdepot.cnf) входят в противоречие с разорванным состоянием конфигурации.

Способ 1. Восстановление полного набора служебных таблиц конфигурации из бэкапа

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

Рассмотрим SQL-скрипт для СУБД Microsoft SQL Server, который полностью синхронизирует служебные таблицы рабочей базы со стабильной резервной копией:


-- Очистка служебных таблиц в целевой поврежденной базе
TRUNCATE TABLE [ЦелеваяБаза].[dbo].[_YearOffset];
TRUNCATE TABLE [ЦелеваяБаза].[dbo].[config];
TRUNCATE TABLE [ЦелеваяБаза].[dbo].[configSave];
TRUNCATE TABLE [ЦелеваяБаза].[dbo].[Params];
TRUNCATE TABLE [ЦелеваяБаза].[dbo].[DBSchema];
TRUNCATE TABLE [ЦелеваяБаза].[dbo].[files];
TRUNCATE TABLE [ЦелеваяБаза].[dbo].[IBVersion];
TRUNCATE TABLE [ЦелеваяБаза].[dbo].[v8users];

-- Перенос стабильных данных из резервной копии
INSERT INTO [ЦелеваяБаза].[dbo].[_YearOffset] SELECT * FROM [БазаРезервная].[dbo].[_YearOffset];
INSERT INTO [ЦелеваяБаза].[dbo].[config] SELECT * FROM [БазаРезервная].[dbo].[config];
INSERT INTO [ЦелеваяБаза].[dbo].[configSave] SELECT * FROM [БазаРезервная].[dbo].[configSave];
INSERT INTO [ЦелеваяБаза].[dbo].[Params] SELECT * FROM [БазаРезервная].[dbo].[Params];
INSERT INTO [ЦелеваяБаза].[dbo].[DBSchema] SELECT * FROM [БазаРезервная].[dbo].[DBSchema];
INSERT INTO [ЦелеваяБаза].[dbo].[files] SELECT * FROM [БазаРезервная].[dbo].[files];
INSERT INTO [ЦелеваяБаза].[dbo].[IBVersion] SELECT * FROM [БазаРезервная].[dbo].[IBVersion];
INSERT INTO [ЦелеваяБаза].[dbo].[v8users] SELECT * FROM [БазаРезервная].[dbo].[v8users];

Важно: перед выполнением SQL-скриптов обязательно остановите службу сервера 1С:Предприятия (ragent) или завершите все процессы rphost, чтобы освободить блокировки таблиц.

Способ 2. Точечная очистка маркеров сбоя в SQL

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

Выполним следующие SQL-запросы:


-- 1. Удаление незавершенных коммитов динамического обновления
DELETE FROM dbo.Config WHERE FileName LIKE '%commit%';

-- 2. Удаление флагов динамического обновления
DELETE FROM dbo.Config WHERE FileName LIKE '%DynamicallyUpdated%';
DELETE FROM dbo.Params WHERE FileName LIKE '%DynamicallyUpdated%';

-- 3. Очистка временной конфигурации сохранения
DELETE FROM dbo.ConfigSave;

После выполнения запросов очистите серверный кеш кластера и попробуйте открыть Конфигуратор.

Способ 3. Отключение привязки к хранилищу конфигурации через SQL

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


-- Удаление записей привязки к хранилищу из таблиц конфигурации и параметров
DELETE FROM dbo.Config WHERE FileName IN ('depot.cnf', 'devdepot.cnf');
DELETE FROM dbo.Params WHERE FileName IN ('depot.cnf', 'devdepot.cnf', 'DepotAutentification');

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

Способ 4. Восстановление и откат через командную строку

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

Откат к конфигурации базы данных:


"C:\Program Files\1cv8\8.3.X.X\bin\1cv8.exe" DESIGNER /S "server\ib_name" /RollbackCfg

Принудительное нединамическое обновление конфигурации базы данных:
```
"C:\Program Files\1cv8\8.3.X.X\bin\1cv8.exe" DESIGNER /S "server\ib_name" /UpdateDBCfg -Dynamic-
```

Загрузка стабильного файла конфигурации (.cf):


"C:\Program Files\1cv8\8.3.X.X\bin\1cv8.exe" DESIGNER /S "server\ib_name" /LoadCfg "C:\backup.cf" /UpdateDBCfg -Dynamic-

Обязательные сопутствующие действия: очистка кеша

После выполнения любых манипуляций с системными таблицами необходимо исключить влияние старого кеша:

Очистка серверного кеша: остановите службу 1C:Enterprise Server Agent. Перейдите в каталог данных кластера (по умолчанию C:\Program Files\1cv8\srvinfo\...) и удалите содержимое папок временных файлов (каталоги с GUID процессов и сеансов, кроме конфигурационных файлов кластера 1CV8Reg.lst).
Очистка клиентского кеша: удалите каталоги локального кеша пользователя в папках %LocalAppData%\1C\1cv8\ и %AppData%\1C\1cv8\ либо удалите базу из списка запуска и добавьте ее повторно под новым именем.