Представим ситуацию: в наши руки попала файловая база данных «1С:Бухгалтерия предприятия, редакция 3.0». Известно, что база «погибла» при попытке обновления. Резервной копии, как это часто бывает, нет. При запуске в режиме «1С:Предприятие» система выдает критическое окно:
Невосстановимая ошибка. Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call по причине: Ошибка SDBL: В схеме базы данных нет таблицы с именем Const30015
При этом стандартная утилита проверки физической целостности chdbfl.exe не находит ошибок, а режим «Тестирование и исправление» (ТИИ) при попытке выполнить реиндексацию таблиц информационной базы просто «вылетает». Режим Конфигуратора при этом может успешно открываться. Давайте подробно разберем, почему возникает эта ошибка и как восстановить работоспособность базы данных шаг за шагом.
Для начала проанализируем физическую структуру хранения данных в 1С. Ошибка SDBL (System Database Layer) указывает на рассогласование между логическим описанием объектов метаданных конфигурации и их физическим представлением в таблицах базы данных СУБД (в файловом варианте — внутри файла 1Cv8.1CD).
В процессе обновления базы данных платформа выполняет реструктуризацию в несколько этапов:
CONFIGSAVE.DBNames (хранится в таблице системных параметров Params).DBSCHEMA, описывающая актуальную структуру базы данных.CONFIGSAVE переносятся в основную таблицу конфигурации CONFIG, а CONFIGSAVE очищается.Если в процессе этого сложного механизма происходит сбой (выключили свет, завис компьютер, завершился процесс платформы), транзакция прерывается на полпути. В результате в метаданных (или в таблице соответствия имен DBNames) новая константа или справочник уже прописаны, а физическое описание таблицы в DBSCHEMA еще не создано или таблица не успела физически появиться в файле базы. Платформа пытается обратиться к таблице _Const30015, не находит её описания в DBSCHEMA и аварийно завершает работу.
Утилита chdbfl.exe проверяет только физическую целостность страниц файла 1Cv8.1CD (смещения, заголовки блоков, структуру файловых таблиц). С точки зрения файловой системы СУБД 1С файл абсолютно здоров. Но на логическом уровне метаданных и схемы базы присутствует глубокий конфликт.
Чтобы успешно восстановить базу, нам понадобятся специализированные инструменты. Основным из них является утилита Tool_1CD (желательно использовать версии Alpha, например, 0.3.0 или 0.4.0, которые позволяют не только просматривать, но и редактировать данные таблиц напрямую).
Давайте выясним, за какие области структуры базы данных отвечают ключевые таблицы файла 1Cv8.1CD:
dbnames хранится карта соответствия внутренних идентификаторов объектов метаданных (например, GUID константы или справочника) их физическим именам таблиц (например, _Const30015 или _Reference45).Посмотрим на типичный фрагмент описания структуры в DBSCHEMA, экспортированный в текстовый вид:
{"Const21517","N",21517,"",
{3,
{"Fld21518",0,
{1,
{"L",0,0,"",0}
},"",0},
{"Fld1174",0,
{1,
{"N",7,0,"",0}
},"",0},
{"RecordKey",0,
{1,
{"B",1,0,"",0}
},"",0}
},
{0},
{1,
{"ByKey",1,
{1,"RecordKey"},1,0,0}
},1,"S"}
Если в вашей схеме отсутствует аналогичный блок для проблемной таблицы Const30015, платформа выдаст ошибку SDBL.
Это самый простой и быстрый способ реанимации базы, если сбой произошел в самом начале процесса реструктуризации. Наша задача — заставить платформу забыть о том, что она пыталась обновиться, и вернуть её к стабильной конфигурации, которая по-прежнему хранится в таблице CONFIG.
Выполним процедуру по шагам:
1Cv8.1CD перед любыми манипуляциями!CONFIGSAVE.CONFIGSAVE (в Tool_1CD для этого используется режим редактирования или импорта/экспорта таблиц). Полное удаление записей из этой таблицы отменит применение новой конфигурации.Если этот способ помог, база откроется на прежнем релизе (до обновления). После этого рекомендуется выполнить ТИИ с флагами реиндексации и проверки логической целостности, а затем повторить обновление, предварительно создав резервную копию.
Если очистка CONFIGSAVE не помогла или таблица изначально была пуста, значит, метаданные в CONFIG уже обновились, запись в DBNames добавилась, а физическая схема в DBSCHEMA осталась старой. Нам необходимо привести структуру СУБД в соответствие с новой конфигурацией.
Поскольку ручная правка бинарной схемы DBSCHEMA в HEX-редакторе — задача крайне трудоемкая и требующая глубоких познаний формата, мы воспользуемся методом «трансплантации» схемы из чистой базы-донора той же версии конфигурации.
Рассмотрим этот алгоритм детально:
.cf) с помощью Tool_1CD.DBSCHEMA и экспортируем её содержимое в файл (например, dbschema_donor.bin).Params, находим запись с идентификатором dbnames и экспортируем её значение во внешний файл (например, dbnames_donor.bin).dbschema_donor.bin в таблицу DBSCHEMA битой базы с заменой существующих данных.Params поврежденной базы, находим запись dbnames и заменяем её содержимое файлом dbnames_donor.bin.chdbfl.exe и проверяем модифицированную базу. Утилита исправит мелкие логические несоответствия в заголовках таблиц данных (поскольку мы заменили схему, некоторые таблицы данных могут потребовать переиндексации).Важное предупреждение: При замене файлов DBSCHEMA и DBNames на донорские напрямую, внутренние идентификаторы (GUID) метаданных в конфигурации-доноре должны строго совпадать с метаданными вашей поврежденной конфигурации. Этот метод идеально работает для полностью типовых конфигураций, обновлявшихся по стандартным релизам фирмы «1С». Если в базе присутствуют доработки (измененные объекты, добавленные реквизиты), этот способ разрушит связи метаданных, и данные доработанных объектов будут утеряны!
Если база была нетиповой или повреждения затронули всего одну-две таблицы (например, конкретную константу Const30015), можно попытаться «откатить» объявление этих таблиц в структуре базы. Выясним, как это сделать:
dbnames из таблицы Params. Это текстовый XML-подобный или JSON-подобный массив соответствий.
{05c30f10-c7aa-4806-9f63-5ba24872f7be,"Const",30015},
Params на место оригинальной записи dbnames.Const30015.DBSCHEMA, удалив или пересоздав некорректные таблицы.Если у вас есть доступ к клиент-серверному варианту работы (MS SQL или PostgreSQL), исправить ошибку SDBL часто оказывается намного проще благодаря развитым инструментам СУБД.
Давайте рассмотрим этот продвинутый метод:
.dt. Если Конфигуратор открывается и дает выполнить выгрузку — нам повезло..dt в созданную SQL-базу._Const30015.
CREATE TABLE _Const30015 (
_RecordKey binary(1) NOT NULL,
_Val_TypeOffset numeric(4,0) NOT NULL,
_Val_IDRRef binary(16) NOT NULL,
CONSTRAINT PK__Const30015 PRIMARY KEY CLUSTERED (_RecordKey)
);
_Const30015, успешно пройдет этап инициализации SDBL и запустит систему..dt и загружаем её в файловый вариант .1CD.Если структура повреждена настолько сильно, что Конфигуратор не позволяет выполнить обновление или ТИИ падает без объяснения причин, единственным выходом остается спасение пользовательских данных (документов, справочников, регистров) путем их переноса в новую, чистую базу данных.
Давайте разберем, как обойти ошибку SDBL при выгрузке:
Попытка
// Код выгрузки конкретного объекта метаданных
ВыгрузитьОбъект(ТекущийОбъект);
Исключение
ЗаписьЖурналаРегистрации("ВыгрузкаДанных", УровеньЖурналаРегистрации.Предупреждение, , ,
"Пропущен битый объект: " + ТекущийОбъект);
КонецПопытки;
Мы подробно рассмотрели сложнейшую техническую проблему — нарушение целостности метаданных СУБД 1С. Ошибка SDBL, связанная с отсутствием таблиц в схеме базы данных, больше не должна вызывать у нас панику. Мы научились восстанавливать базу несколькими альтернативными методами: от простого отката изменений в CONFIGSAVE до тонкой хирургической правки соответствий в таблицах DBSCHEMA и DBNames.
Для предотвращения подобных ситуаций в будущем крайне важно соблюдать базовые правила администрирования систем на базе «1С:Предприятие»:
1Cv8.1CD в отдельную директорию..dt не является полноценным бэкапом файловой базы, так как при сильных повреждениях логической структуры выгрузить или загрузить этот файл будет невозможно. Всегда копируйте непосредственно физический файл базы.