Восстановление поврежденной базы данных 1С — это всегда сложный, а порой и непредсказуемый процесс. Типичная ситуация: после аварийного завершения работы, сбоя СУБД или повреждения диска база перестает открываться. Администраторы и разработчики пытаются восстановить ее работоспособность всеми доступными средствами, включая утилиту chdbfl.exe и прямое редактирование таблиц через специализированный софт (например, Tool_1CD). Однако подобные «хирургические» вмешательства часто приводят к возникновению опасных логических несоответствий.
В этой статье мы подробно разберем природу возникновения критических ошибок SDBL при проведении процедуры Тестирования и исправления (ТиИ), выясним, почему замена служебных таблиц разрушает структуру базы, и рассмотрим детальные практические методы восстановления работоспособности информационной базы.
Давайте проанализируем внутреннее устройство реляционной структуры 1С. Платформа не обращается к таблицам СУБД (будь то файловый 1CD или клиент-серверный MS SQL/PostgreSQL) напрямую по их метаименам (таким как Справочник.ДоговорыКонтрагентов). Вместо этого используется внутренний слой абстракции — SDBL (Simple Data Base Layer).
Для трансляции понятных разработчику имен в физические имена таблиц СУБД платформа использует две ключевые системные сущности:
DBSchema.Справочник.ДоговорыКонтрагентов = _Reference34).Физические имена таблицам (_ReferenceXX) и колонкам (_FldXXXX) присваиваются строго последовательно в момент их физического создания в базе данных. Если конфигурация развивалась и обновлялась на протяжении месяцев или лет, порядок создания реквизитов в рабочей базе будет абсолютно уникальным.
Если в процессе восстановления поврежденной базы данных вы берете таблицу CONFIG из старого бэкапа или из чистой типовой конфигурации того же релиза, возникает глобальная рассинхронизация:
CONFIG этих объектов или конкретных реквизитов еще не существовало, либо они имели другие физические индексы._Fld12581) или несоответствие типов данных и завершает работу аварийно.Простая замена или переименование файлов таблиц (например, попытка подменить Reference34 на Reference36) не решает проблему, так как внутреннее описание полей внутри этих таблиц все равно расходится с ожиданиями платформы.
---
Если для восстановления таблицы CONFIG использовался файл конфигурации годовой давности, то несоответствие структуры неизбежно. Прежде чем приступать к низкоуровневым манипуляциям с СУБД, необходимо попытаться вернуть конфигурацию БД к актуальному состоянию.
Рассмотрим по шагам, как правильно восстановить структуру:
Бухгалтерия предприятия 2.0.64.21).1cv8.cf.Tool_1CD (или аналогичные инструменты для работы с файловыми базами данных), загрузите корректный, чистый файл конфигурации непосредственно в таблицу CONFIG поврежденной базы. Это гарантирует, что метаданные платформы будут соответствовать релизу конфигурации на момент аварии.---
Если база данных переведена на клиент-серверный вариант (MS SQL Server или PostgreSQL), мы получаем мощный инструментарий для прямого управления структурой таблиц. Мы можем обмануть механизм реструктуризации ТиИ, вручную создав те поля, которые он не может найти.
Разберем алгоритм устранения ошибки на примере Microsoft SQL Server:
SDBL и EXCP, либо запустите утилиту трассировки SQL Server Profiler._Reference34) шло обращение и какое поле (например, _Fld12581) вызвало ошибку SDBL: Fld12581 не является именем поля. Также зафиксируйте ожидаемый тип данных этого поля из контекста запроса.Пример SQL-скрипта для добавления недостающей колонки неопределенного типа (или числового типа):
ALTER TABLE dbo._Reference34
ADD _Fld12581 NUMERIC(10, 0) NOT NULL DEFAULT 0;
Если в процессе анализа выяснилось, что поле должно хранить ссылку, строку или булево значение, создайте его с соответствующим типом данных:
-- Пример добавления строкового поля
ALTER TABLE dbo._Reference34
ADD _Fld12581 NVARCHAR(150) NOT NULL DEFAULT '';
После добавления поля повторно запустите ТиИ с включенной опцией реструктуризации таблиц. Если платформа обнаружит нехватку других полей, повторите процедуру добавления колонок. Как только ТиИ завершится успешно, платформа автоматически перестроит внутреннюю структуру DBSchema и приведет базу к корректному логическому виду.
---
Иногда успешному прохождению реструктуризации мешают зависшие транзакции или недозаписанные пакеты обновлений конфигурации, хранящиеся в служебных таблицах. Перед запуском ТиИ рекомендуется очистить эти данные.
Выполните следующие действия через консоль СУБД:
CONFIGSAVE, в которой хранится промежуточная (несохраненная) конфигурация базы данных. В ней не должно быть записей.
DELETE FROM dbo._ConfigChngR;
DELETE FROM dbo._ConfigChngR_ExtProps;
Для файлового варианта базы данных эти действия можно выполнить с помощью специализированных обработок очистки конфигурации базы данных, запускаемых в монопольном режиме.
---
Когда структура справочников (особенно таких сложных, как ДоговорыКонтрагентов) разрушена окончательно, а простая замена физических файлов таблиц приводит к потере связей, наиболее надежным решением является перенос данных «снизу вверх» на уровне СУБД.
Рассмотрим алгоритм контролируемого переноса данных:
.cf) нужного релиза._FldXXXX) различаются.Пример SQL-запроса для потабличного переноса данных с явным сопоставлением полей:
INSERT INTO НоваяБаза.dbo._Reference36 (_IDRRef, _Version, _Description, _Fld15000)
SELECT
_IDRRef,
_Version,
_Description,
_Fld12581 -- Сопоставляем старое поле с новым физическим именем
FROM СтараяБаза.dbo._Reference34;
Этот метод гарантирует, что новая база данных будет иметь идеально чистую и правильную структуру DBSchema, а все перенесенные данные гарантированно пройдут проверку платформы без вызова ошибок SDBL.
---
Для того чтобы в будущем не сталкиваться с необходимостью ручной сборки таблиц базы данных, придерживайтесь простых правил:
1cv8.1cd (для файлового варианта). Храните архивные копии на физически изолированном сервере или в облаке.chdbfl.exe) всегда завершайте полным циклом Тестирования и исправления с включенными логическими проверками.