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

← На главную

Каждый администратор или разработчик 1С рано или поздно сталкивается с критическими сбоями файловых баз данных (файлы с расширением 1Cv8.1CD). Типичный сценарий выглядит следующим образом: в результате внезапного отключения питания, сетевого сбоя или прерванного динамического обновления база перестает открываться. Пользователи или штатные сотрудники в панике пытаются восстановить работоспособность системы собственными силами. Не сделав резервную копию, они запускают стандартную утилиту проверки chdbfl.exe и пытаются «лечить» базу из Конфигуратора. В результате этих действий база окончательно ломается и перестает пускать даже в Конфигуратор, выдавая критическую ошибку формата потока.

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

Выясняем причину: почему chdbfl.exe ухудшает состояние базы?

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

Если во время сбоя (например, при записи конфигурации) бинарные данные в системных таблицах записались некорректно или частично, chdbfl.exe видит поврежденную физическую страницу файла. Не имея возможности восстановить ее содержимое, утилита просто «вырезает» дефектный блок или страницу целиком, чтобы привести файл к физически корректному виду. Для СУБД файл становится «здоровым», но для логики платформы 1С это катастрофа. Из базы могут бесследно исчезнуть критически важные файлы метаданных (например, карта сопоставления объектов dbnames), из-за чего запуск Конфигуратора становится невозможным.

Анализ логов технологического журнала: расшифровка ошибки формата потока

При попытке запустить поврежденную базу в логах технологического журнала (ТЖ) часто фиксируется следующая запись:

Exception=e88a796d-7758-48a7-9ba7-781e269e9aa4, Descr='src\ExceptionWriterUIImpl.cpp(205), shown to the user: Ошибка формата потока'

Давайте разберем природу этой ошибки:

Системный GUID исключения: Идентификатор e88a796d-7758-48a7-9ba7-781e269e9aa4 не привязан к конкретной базе данных. В исходном коде платформы 1С:Предприятие (написанном на языке C++) этот GUID является глобальной константой класса исключения Stream format error (Ошибка формата потока).
Суть сбоя: Ошибка возникает в модуле интерфейса вывода исключений ExceptionWriterUIImpl.cpp. Это означает, что платформа попыталась прочитать сжатый бинарный поток данных из таблицы (например, описание метаданных или конфигурации), но структура этого потока (заголовки, контрольные суммы, zlib-сжатие) оказалась нарушена. Платформа не смогла разобрать полученный массив байтов и аварийно завершила сеанс.
Конкретный адрес сбоя: Часто детальный анализ указывает на сбой чтения конкретного объекта, например: CONFIG/8261cfe8-f981-4375-bba5-ae1484facbc2.0. Примечательно, что данный объект может присутствовать и в рабочей копии, и в чистом типовом релизе конфигурации. Ошибка формата потока в данном случае вызвана тем, что нарушена связь между физическим размещением этого файла в таблице CONFIG и его описанием в таблице схемы данных DBSCHEMA или параметрах базы PARAMS.

Подготовка инструментов для восстановления

Для восстановления поврежденной базы нам потребуются:

Рабочая копия базы данных: Подойдет архив любой давности (даже 3–4 месяца назад), но строго того же релиза конфигурации, который был установлен на момент сбоя. Она послужит нам донором корректных системных таблиц.
Программа Tool_1CD: Специализированный инструмент для низкоуровневого просмотра и редактирования таблиц файловых баз данных 1С.
Утилита cnvdbfl.exe: Входит в стандартную поставку платформы 1С и предназначена для конвертации форматов файловых баз.

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

Метод 1: Пошаговая замена поврежденных системных таблиц конфигурации

Если база не открывается даже в Конфигураторе, это указывает на повреждение таблиц метаданных: CONFIG (хранит основную конфигурацию), CONFIGSAVE (содержит редактируемую конфигурацию) или PARAMS (хранит настройки и служебные файлы платформы). Наша задача — заменить их структурами из рабочей копии-донора.

Рассмотрим по шагам процесс замены таблиц:

Шаг 1. Конвертация формата базы данных

Современные версии платформ 1С (начиная с 8.3.8) используют обновленный формат файловых баз с размером страницы отличным от 4096 байт. Старые версии утилиты Tool_1CD, поддерживающие запись и редактирование таблиц, не умеют работать с новым форматом напрямую. Нам необходимо временно понизить формат базы до совместимого (версии 8.2.14).

Для этого откройте командную строку и выполните конвертацию битой базы и базы-донора с помощью штатной утилиты cnvdbfl.exe:


"C:\Program Files\1cv8\8.3.XX.XXXX\bin\cnvdbfl.exe" -c -f 8.2.14 "C:\Recovery\BrokeBase\1Cv8.1CD"
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\cnvdbfl.exe" -c -f 8.2.14 "C:\Recovery\DonorBase\1Cv8.1CD"

Примечание: вместо 8.3.XX.XXXX укажите путь к каталогу вашей актуальной установленной платформы.

Шаг 2. Экспорт исправных таблиц из базы-донора

Запустите программу Tool_1CD с поддержкой записи. Откройте в ней базу-донор (из старого архива) и выполните экспорт следующих таблиц в файлы на диске:

CONFIG
CONFIGSAVE
PARAMS

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

Шаг 3. Импорт таблиц в поврежденную базу

Закройте базу-донор в Tool_1CD и откройте поврежденный файл базы данных. Выполните операцию импорта (замены) экспортированных ранее таблиц CONFIG, CONFIGSAVE и PARAMS аналогичным образом (через контекстное меню таблиц).

Шаг 4. Очистка маркеров зависших обновлений

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

commit
dbStruFinal
dynamicCommit

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

Шаг 5. Обратная конвертация формата базы

После завершения импорта и удаления маркеров закройте Tool_1CD. Теперь необходимо вернуть файл базы данных к исходному современному формату 8.3.8 (или выше) для корректной работы актуальной платформы:


"C:\Program Files\1cv8\8.3.XX.XXXX\bin\cnvdbfl.exe" -c -f 8.3.8 "C:\Recovery\BrokeBase\1Cv8.1CD"

Попробуйте запустить Конфигуратор восстановленной базы. Если запуск прошел успешно, обязательно выполните операцию Тестирование и исправление (меню Администрирование — Тестирование и исправление) с включенными опциями проверки логической и ссылочной целостности.

Метод 2: Альтернативный перенос данных («Метод наоборот»)

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

Гораздо более надежным и безопасным является альтернативный метод — перенос накопленных данных из битой базы в заведомо исправную структуру.

Проанализируем этот алгоритм по шагам:

Возьмите вашу старую рабочую архивную копию базы данных (донор). Ее структура и метаданные гарантированно исправны. Она без проблем открывается в Конфигураторе.
Очистите в этой архивной копии все таблицы, содержащие фактические данные (документы, справочники, регистры сведений и накопления). Сделать это можно обработками очистки данных или напрямую через СУБД/специализированные скрипты, сохранив структуру метаданных нетронутой.
С помощью утилиты Tool_1CD выгрузите таблицы с данными из поврежденной базы. Так как структура конфигураций идентична (релизы совпадают), физический состав полей и таблиц документов в битой базе и чистой базе-доноре абсолютно одинаков.
Загрузите выгруженные таблицы данных в чистую базу-донор.

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