← На главную

Динамическое обновление информационных баз 1С — удобный инструмент, однако при его сбое или аварийном завершении работы сервера администраторы и разработчики часто сталкиваются с разрушением структуры метаданных. В результате база перестает открываться, возникает ошибка механизма SDBL, а в процессе тестирования и исправления появляются сообщения о недопустимых именах столбцов (например, _Fld61374).

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

Причины возникновения ошибки SDBL и рассогласования метаданных

Рассмотрим, что происходит внутри системы во время сбоя при динамическом обновлении:

1. Зависание изменений в служебной таблице ConfigSave: При запуске динамического обновления платформы 1С записывает новые метаданные во временную таблицу ConfigSave. Если процесс прерывается до момента успешного завершения, возникнет рассинхронизация между основной конфигурацией (таблица Config), структурой хранения данных (таблица DBSchema) и параметрами информационной базы (таблица Params).
2. Рассогласование уникальных идентификаторов (GUID): Попытки ручного переноса или замены таблиц Config, DBSchema и DBNames из бэкапа приводят к тому, что платформенные GUID объектов метаданных перестают соответствовать физическим именам полей (_Fld) и таблиц (_Reference, _Document) в СУБД SQL.
3. Кэширование структуры метаданных сервером 1С: Сервер приложений 1С кэширует описание метаданных в каталоге кластера (srvinfo). Даже если исправить таблицы в СУБД, сервер 1С продолжит читать устаревшие схемы из кэша, генерируя ошибки SDBL при выполнении запросов к данным.

Шаг 1. Очистка кэша и зачистка не примененных изменений

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

Выполним очистку таблицы ConfigSave на стороне СУБД. Для этого выполним SQL-запрос:

DELETE FROM ConfigSave

После удаления записей из ConfigSave выполним последовательную очистку кэша:

1. Остановим службу агента сервера 1С:Предприятие.
2. Очистим папки клиентского кэша на рабочих станциях (локальный кэш пользователя в AppData\Local\1C\1cv8 и AppData\Roaming\1C\1cv8).
3. Удалим содержимое сеансовых данных и кэша сервера приложений 1С в каталоге srvinfo (исключая файлы конфигурации самого кластера).
4. Перезапустим службу СУБД (SQL Server / PostgreSQL) и службу агента 1С.

Шаг 2. Принудительная реструктуризация проблемных объектов

Если после очистки кэша в конфигураторе объект открывается, но при получении структуры информационной базы или при выполнении проверок возникают ошибки по отсутствующим полям (например, Недопустимое имя столбца "_FldXXXXX"), заставим платформу принудительно пересчитать физическую структуру таблиц СУБД.

Разберем по шагам порядок действий:

1. Откроем Конфигуратор и найдем проблемный объект метаданных (например, ПланВидовХарактеристик или Документ).
2. Добавим к объекту временный (фиктивный) реквизит с произвольным типом (или изменим длину любого строкового реквизита на 1 символ).
3. Выполним обновление конфигурации базы данных (клавиша F7). На этом этапе платформа запустит полноценную реструктуризацию таблицы в СУБД и приведет физические столбцы в соответствие с конфигурацией.
4. Удалим ранее добавленный временный реквизит и повторно обновим конфигурацию базы данных.

Шаг 3. Восстановление структуры через выгрузку и загрузку информационной базы (.dt)

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

Рассмотрим данный процесс:

1. В Конфигураторе выполним команду меню Администрирование — Выгрузить информационную базу и сохраним файл .dt.
2. В СУБД создадим новую пустую базу данных.
3. Зарегистрируем новую базу в кластере серверов 1С и откроем ее Конфигуратор.
4. Выполним команду Администрирование — Загрузить информационную базу и укажем ранее сохраненный файл .dt.

При загрузке файла .dt платформа 1С создает таблицы СУБД «с нуля», наново генерируя соответствия между метаданными и физическими полями DBNames, что полностью исключает фантомные столбцы и конфликты GUID.

Шаг 4. Работа с таблицей соответствия DBNames

В случаях, когда базы восстанавливались путем подмены служебных таблиц из бэкапа (Config, DBSchema), физические имена таблиц в СУБД (например, Document31334) могут не совпадать с теми, которые ожидает система.

Соответствие между объектами метаданных 1С и наименованиями таблиц/полей в СУБД хранится в служебной таблице DBNames. Если имена столбцов рассогласовались, мы можем:

1. Загрузить заведомо исправный файл конфигурации .cf через меню Конфигурация — Загрузить конфигурацию из файла (это заставит платформу перезаписать структуру DBSchema и DBNames).
2. Воспользоваться специализированными обработками для чтения таблицы DBNames и сопоставления внутренних GUID объектов с реальными физическими полями SQL.
3. При наличии одиночных расхождений в именах полей вручную переименовать столбцы в СУБД через SQL-скрипты ALTER TABLE ... RENAME COLUMN ..., чтобы привести их в полное соответствие с ожидаемой структурой DBNames.

Правила безопасности при обновлении конфигурации

Чтобы избежать ошибок SDBL и разрушения структуры базы в будущем, следует придерживаться строгих регламентов работы:

1. Не использовать динамическое обновление для структурных изменений: Механизм динамического обновления предназначен исключительно для изменения модулей, форм, макетов и прав доступа. Любое добавление, удаление или изменение реквизитов, типов данных и объектов метаданных должно выполняться строго в монопольном режиме с полной реструктуризацией.
2. Использовать расширения конфигурации: Для быстрого внедрения новой доработки или реквизитов без остановки работы пользователей применяйте механизмы расширений.
3. Регулярно делать резервные копии: Перед выполнением любых операций со структурой базы данных обязательным шагом является создание полного дампа СУБД или выгрузка .dt.