Аварийное завершение работы сервера или внезапное отключение электропитания в момент сохранения метаданных — один из самых опасных сценариев для любой базы данных. В случае с платформой 1С:Предприятие такая ситуация практически гарантированно приводит к разрушению структуры таблиц. Чаще всего пользователи сталкиваются с критической ошибкой «Ошибка формата потока», при которой база данных отказывается запускаться в режиме Предприятия, а стандартное тестирование утилитой chdbfl.exe либо не находит ошибок, либо исправляет заголовки таблиц, но не решает проблему запуска.
В этой статье мы подробно разберем, почему возникает эта ошибка при повреждении расширений, почему простая замена таблиц конфигурации не помогает и какими способами можно полностью и безопасно удалить поврежденные расширения, чтобы вернуть базу в рабочее состояние.
Рассмотрим внутреннюю структуру хранения расширений в платформе 1С. Попытка восстановить базу данных путем частичной замены поврежденных таблиц (например, таблицы CONFIGCAS, в которой хранятся двоичные данные расширений) из недавней резервной копии часто приводит к тому, что Конфигуратор начинает открываться, но при запуске в режиме Предприятия происходит аварийное завершение работы процесса (падение платформы с предложением запустить отладку в Windows).
Выясним причину этого поведения. Платформа 1С хранит информацию о расширениях не в одном месте, а в нескольких взаимосвязанных таблицах:
ConfigCAS — таблица, содержащая двоичные данные (сжатые потоки) самих расширений конфигурации.ConfigCASSave — временная таблица, куда записываются редактируемые, но еще не примененные (не сохраненные окончательно) версии расширений._ExtensionsInfo (в клиент-серверном варианте) или аналогичная внутренняя таблица файловой базы данных — реестр зарегистрированных в системе расширений. Здесь хранятся их уникальные идентификаторы (UUID), имена, версии, контрольные суммы и текущие состояния (активно, подключено и т.д.).Когда мы вручную очищаем таблицу ConfigCASSave или копируем ConfigCAS из старого бэкапа, мы нарушаем логическую ссылочную целостность системных метаданных. В реестре расширений (в таблице информации о расширениях) остаются записи о зарегистрированных объектах с конкретными UUID. При запуске системы платформа считывает этот список, пытается сопоставить его с двоичными данными в ConfigCAS, обнаруживает несоответствие контрольных сумм или отсутствие необходимых внутренних объектов и аварийно завершает работу без вывода понятного сообщения об ошибке.
Единственный надежный способ вернуть базу к жизни в такой ситуации — полностью вырезать поврежденные расширения из структуры метаданных. Рассмотрим, как это сделать.
Если графический интерфейс Конфигуратора не позволяет удалить расширения (вылетает с ошибкой формата потока при открытии окна расширений), мы можем воспользоваться недокументированными или штатными ключами пакетного запуска платформы. Этот метод хорош тем, что платформа выполняет очистку таблиц на уровне ядра, соблюдая все внутренние взаимосвязи.
Для выполнения этой операции закроем все сеансы работы с базой данных и запустим командную строку Windows (cmd) от имени администратора. Нам понадобятся специальные параметры запуска конфигуратора.
Проанализируем команду для удаления всех расширений из базы данных:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "D:\Put_K_Baze" /N "Admin" /P "Password" /DeleteCfg -AllExtensions
Разберем параметры этой команды подробнее:
DESIGNER — запуск платформы в режиме Конфигуратора./F "D:\Put_K_Baze" — путь к поврежденной файловой базе данных (для клиент-серверного варианта используйте ключ /S "ИмяСервера\ИмяБазы")./N "Admin" /P "Password" — имя пользователя и пароль учетной записи с правами Администратора./DeleteCfg -AllExtensions — ключевой параметр, который дает указание платформе полностью удалить все расширения и связанные с ними записи из системных таблиц, минуя загрузку графической оболочки.Если нам известно, какое конкретно расширение вызывает сбой (например, мы устанавливали его непосредственно перед выключением сервера), мы можем удалить его точечно, указав его имя:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "D:\Put_K_Baze" /N "Admin" /P "Password" /DeleteCfg -Extension "ИмяПроблемногоРасширения"
После запуска команды окно Конфигуратора откроется в фоновом режиме, выполнит очистку таблиц и автоматически закроется. После этого можно пробовать запускать базу данных в обычном режиме.
Если поврежденная база данных развернута на SQL-сервере (MS SQL Server, PostgreSQL, IBM DB2), мы можем выполнить низкоуровневую очистку таблиц напрямую через консоль СУБД. Это позволяет быстро восстановить работоспособность без использования конфигуратора.
Важно: Перед выполнением любых прямых запросов к СУБД обязательно создайте резервную копию базы данных средствами самой СУБД!
Для полного удаления информации о расширениях нам необходимо очистить три таблицы одновременно, чтобы не нарушить ссылочную целостность метаданных. Запустим среду управления СУБД (например, SQL Server Management Studio или pgAdmin) и выполним следующий запрос:
DELETE FROM _ExtensionsInfo;
DELETE FROM ConfigCAS;
DELETE FROM ConfigCASSave;
Примечание: В зависимости от версии платформы 1С и особенностей ее установки, имена таблиц в СУБД могут иметь префиксы или незначительно отличаться регистрами букв. Перед выполнением запроса найдите эти таблицы в списке таблиц вашей базы данных, чтобы уточнить их точные названия.
После выполнения данного запроса и перезапуска службы сервера «1С:Предприятие» база данных запустится без расширений, как чистая типовая конфигурация.
Что делать, если в базе данных установлено множество расширений, данные которых критически важно сохранить, и мы не хотим удалять все подряд? Нам нужно выяснить, какое именно расширение повреждено.
Разберем по шагам метод диагностики через процедуру Тестирования и исправления:
Даже после того как база данных успешно запустилась без расширений, радоваться рано. В самой конфигурации остаются «фантомные» или сиротские (orphan) записи, которые платформа создала при установке этих расширений. Эти записи хранятся в стандартных объектах базы данных.
Если проигнорировать этот шаг, то при попытке повторно установить те же самые расширения (или их новые версии) система начнет выдавать непредсказуемые ошибки совместимости или снова упадет в «Ошибку формата потока». Это происходит из-за конфликта уникальных идентификаторов (UUID) новых расширений со старыми записями в служебных таблицах.
Нам необходимо очистить два ключевых объекта:
ИдентификаторыОбъектовРасширенийИдентификаторыОбъектовВерсийРасширенийДля этого запустим базу данных в режиме Предприятия, откроем внешнюю обработку или воспользуемся групповой обработкой данных и выполним следующий программный код для удаления устаревших записей:
// Очистка справочника идентификаторов объектов расширений
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Идентификаторы.Ссылка КАК Ссылка
|ИЗ
| Справочник.ИдентификаторыОбъектовРасширений КАК Идентификаторы";
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
Попытка
Объект = Выборка.Ссылка.ПолучитьОбъект();
Если Объект <> Неопределено Тогда
Объект.ОбменДанными.Загрузка = Истина;
Объект.Удалить();
КонецЕсли;
Исключение
ЗаписьЖурналаРегистрации("ОчисткаРасширений", УровеньЖурналаРегистрации.Предупреждение, , ,
"Не удалось удалить элемент: " + СокрЛП(Выборка.Ссылка));
КонецПопытки;
КонецЦикла;
// Полная очистка регистра сведений версий расширений
НаборЗаписей = РегистрыСведений.ИдентификаторыОбъектовВерсийРасширений.СоздатьНаборЗаписей();
НаборЗаписей.Записать(Истина);
Выполнение этого кода полностью сотрет следы присутствия поврежденных расширений в конфигурации. После выполнения очистки настоятельно рекомендуется запустить процедуру «Тестирование и исправление» с включенными опциями «Реиндексация таблиц» и «Проверка логической целостности», чтобы окончательно перестроить индексы базы данных.
Теперь база данных полностью очищена, стабильна и готова к повторному внедрению исправленных версий расширений конфигурации.