Как убрать скрытые «лишние» поля в таблицах MS SQL и PostgreSQL, которых нет в конфигураторе 1С?

← На главную

При работе с расширениями в платформе «1С:Предприятие 8.3» (начиная с версии 8.3.11 и особенно часто на релизах 8.3.14–8.3.18) разработчики сталкиваются с крайне коварным поведением СУБД. После удаления расширения, в котором были добавлены собственные реквизиты к документам или справочникам, в физических таблицах базы данных (MS SQL или PostgreSQL) остаются «фантомные» или «лишние» поля. При этом в самом Конфигураторе этих полей нет — ни в основной конфигурации, ни в списке расширений.

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

Выясняем причину: техническая суть бага платформы 1С

Когда мы добавляем новые реквизиты через механизм расширений, платформа 1С вынуждена перестраивать структуру физических таблиц СУБД. Для обеспечения связи между логическими метаданными и реальной структурой таблиц СУБД платформа использует внутренний транслятор запросов — SDBL (System Database Layer). Сведения обо всех изменениях, накладываемых расширениями, записываются в служебные системные таблицы базы данных.

Ключевую роль в хранении этих схем играют следующие таблицы:

_ExtensionsInfo — хранит общую информацию о зарегистрированных в системе расширениях.
_ExtensionsRestruct (и ее аналог _ExtensionsRestructNGS) — содержит бинарные данные (двоичные макеты схем) о произведенных изменениях в структурах таблиц.
SchemaStorage — хранит сериализованные схемы баз данных. Запись со значением SchemaID = 0 отвечает за основную конфигурацию, а другие идентификаторы описывают схемы, наложенные поверх нее расширениями.
Params — хранит файлы соответствия имен метаданных физическим полям СУБД (например, файл DBNames для основной конфигурации и файлы вида DBNames-Ext-* для расширений).

Почему происходит сбой? При удалении расширения или в случае аварийного прерывания процесса реструктуризации платформа корректно очищает таблицу _ExtensionsInfo и убирает расширение из интерфейса Конфигуратора. Однако из-за ошибки в логике платформы системные таблицы _ExtensionsRestruct, SchemaStorage и служебные файлы в Params могут остаться неочищенными.

В итоге возникает опасная рассинхронизация:

Конфигуратор считает, что база чиста, и не отображает удаленные реквизиты.
Механизм SDBL при обращении к таблице документа обращается к «зависшим» записям в _ExtensionsRestruct или SchemaStorage, считывает старую схему и по-прежнему ожидает увидеть эти поля в физической таблице.

Если мы оставляем колонки в SQL, SDBL не передает в них значения при записи объектов (так как в метаданных конфигурации их нет). СУБД пытается записать туда NULL, но у колонок стоит ограничение NOT NULL (созданное платформой при установке расширения) — в результате запись документа блокируется ошибкой СУБД.

Если же мы удаляем эти колонки из SQL вручную, SDBL при записи пытается к ним обратиться согласно своей «фантомной» схеме и выдает ошибку о том, что поле вида _Fld... отсутствует в схеме или разделе FROM. Для анализа и устранения сопутствующих низкоуровневых сбоев СУБД подойдёт инструмент для исследования структуры хранения базы данных.

---

Способ 1. Полная очистка системных таблиц реструктуризации (рекомендуемый способ)

Если в вашей базе данных на текущий момент действительно удалены все расширения, содержащие собственные реквизиты, системные таблицы реструктуризации расширений должны быть абсолютно пустыми. Мы можем принудительно очистить их на уровне СУБД, чтобы заставить SDBL забыть о несуществующих полях.

Важно: Перед выполнением любых операций на уровне СУБД обязательно создайте резервную копию базы данных средствами MS SQL Server или PostgreSQL!

Рассмотрим пошагово этот процесс:

Полностью завершите все активные сеансы пользователей и остановите службу агента сервера «1С:Предприятие» (1C:Enterprise 8.3 Server Agent).
Откройте консоль управления СУБД (SQL Server Management Studio для MS SQL или pgAdmin для PostgreSQL) и выполните запрос к вашей базе данных.
Проверьте наличие записей в таблице реструктуризации расширений. Для MS SQL выполните команду:

SELECT COUNT(*) FROM dbo._ExtensionsRestruct;

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

TRUNCATE TABLE dbo._ExtensionsRestruct;

Если в вашей базе присутствует таблица с суффиксом NGS, очистите и ее:

TRUNCATE TABLE dbo._ExtensionsRestructNGS;

Для PostgreSQL названия таблиц пишутся строчными буквами без префикса владельца схемы:


truncate table _extensionsrestruct;
truncate table _extensionsrestructngs;

После этого запустите службу агента сервера 1С, зайдите в базу в режиме Конфигуратора и запустите Тестирование и исправление с единственным выбранным пунктом — «Реструктуризация таблиц информационной базы». Платформа перестроит физические таблицы СУБД в строгом соответствии с чистыми метаданными.

---

Способ 2. Очистка SchemaStorage и файлов соответствия имен в Params

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

Проанализируем структуру таблицы SchemaStorage. Записи, относящиеся к основной конфигурации, всегда имеют идентификатор SchemaID = 0. Схемы расширений имеют другие идентификаторы.

Разберем алгоритм очистки:

Остановите сервер «1С:Предприятие».
В консоли СУБД выполните запрос на удаление всех схем, кроме основной схемы конфигурации:

DELETE FROM dbo.SchemaStorage WHERE SchemaID <> 0;

Далее перейдем к таблице Params. Нам нужно удалить старые кэшированные файлы соответствия имен, которые платформа создавала для расширений. Все такие записи имеют имена, начинающиеся с префикса DBNames-Ext-. Выполните команду удаления:

DELETE FROM dbo.Params WHERE FileName LIKE 'DBNames-Ext-%';

После удаления этих записей на уровне СУБД необходимо обязательно выполнить очистку локального кэша сервера 1С. Для этого перейдите в каталог хранения данных сервера (по умолчанию для Windows это C:\Program Files\1cv8\srvinfo\reg_1541\) и удалите папки с временными файлами и кэшем метаданных (папки формата UUID внутри каталога вашей информационной базы).

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

---

Способ 3. Пересоздание физической таблицы объекта (обходной путь)

Если прямое редактирование системных таблиц SchemaStorage и Params кажется вам слишком рискованным шагом, можно пойти по другому пути. Мы можем заставить платформу 1С самостоятельно пересоздать «с нуля» чистую физическую таблицу для проблемного документа, а затем вернуть туда все данные без лишних колонок.

Рассмотрим этот процесс на примере документа с физическим именем таблицы в СУБД _Document234 и его табличной частью _Document234_VT321. Для этой задачи можно использовать внешнюю обработку для анализа структуры хранения базы данных.

Определите точные имена таблиц СУБД для вашего документа. Сделать это можно с помощью функции ПолучитьСтруктуруХраненияБазыДанных() в 1С или через получении информации о структуре в Конфигураторе.
Через инструменты вашей СУБД переименуйте исходные таблицы во временные резервные копии. Например, для MS SQL выполните команды:


EXEC sp_rename '_Document234', '_Document234_BAK';
EXEC sp_rename '_Document234_VT321', '_Document234_VT321_BAK';

Для PostgreSQL переименование выполняется стандартным запросом ALTER TABLE:


ALTER TABLE _document234 RENAME TO _document234_bak;
ALTER TABLE _document234_vt321 RENAME TO _document234_vt321_bak;

Запустите Конфигуратор 1С и откройте окно «Тестирование и исправление». Отметьте флажком пункт «Реструктуризация таблиц информационной базы» и запустите выполнение.

Платформа в процессе реструктуризации обнаружит отсутствие физических таблиц для нашего документа и автоматически создаст их заново. Поскольку метаданные расширения у нас уже удалены, новые таблицы будут созданы в идеально «чистом» виде — без лишних фантомных колонок и с корректными индексами.

Теперь нам остается перелить данные из резервных таблиц _BAK в новые чистые таблицы. Напишем SQL-запрос для переноса данных, исключив при этом из списка полей те самые 5 лишних колонок, которые вызывали ошибку:


INSERT INTO dbo._Document234 (
    _IDRRef, _Version, _Marked, _Date_Time, _Number, _Posted, 
    -- Перечисляем только реально существующие реквизиты основной конфигурации
    _Fld567, _Fld568
)
SELECT 
    _IDRRef, _Version, _Marked, _Date_Time, _Number, _Posted, 
    _Fld567, _Fld568
FROM dbo._Document234_BAK;

Аналогичным образом перенесите данные для всех подчиненных табличных частей документа.

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


DROP TABLE dbo._Document234_BAK;
DROP TABLE dbo._Document234_VT321_BAK;

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