Как получить структуру таблиц 1С в MS SQL и безопасно удалить большой объем документов?

← На главную

При работе с крупными базами данных на платформе 1С перед разработчиками нередко встает задача быстрой очистки старых данных. Когда речь идет об удалении миллионов документов, стандартные механизмы 1С через объектную модель ДокументОбъект.Удалить() могут работать часами или даже днями. Это связано с колоссальными накладными расходами на чтение объектов в память, проверку бизнес-логики, подписочные события и блокировки.

В этот момент возникает логичное желание выполнить удаление напрямую средствами СУБД (например, MS SQL Server). Однако напрямую обратиться к таблицам документов непросто: имена таблиц в SQL выглядят как _Document152, а полей — как _Fld1523. В этой статье мы подробно разберем, как устроена структура метаданных 1С внутри SQL, как правильно сопоставить физические таблицы с объектами конфигурации и как организовать безопасное удаление гигантских объемов данных без разрушения базы.

Где 1С хранит структуру метаданных в MS SQL?

Рассмотрим внутреннее устройство хранения метаданных. Многие разработчики знают, что если перенести файл базы данных SQL (.mdf) на другой сервер и развернуть его там, то платформа 1С успешно распознает всю структуру объектов, их русские и английские имена, типы данных и связи. Это означает, что конфигурация полностью хранится внутри самой СУБД.

Проанализируем основные системные таблицы, в которых платформа сохраняет эти сведения:

Таблица Config. Здесь в бинарном виде хранится вся конфигурация информационной базы. По сути, это виртуальная файловая система, где файлы (модули, формы, схемы компоновки данных) упакованы по алгоритму Deflate (стандартный формат сжатия zlib без заголовков). Поле FileName содержит уникальные текстовые имена файлов конфигурации. Попытка распаковать их напрямую через T-SQL — крайне нетривиальная задача, требующая написания внешних CLR-процедур.
Таблица Params. Содержит служебные параметры базы данных. Именно здесь, в строке с FileName = 'DBNames', хранится двоичная карта соответствия (маппинг) между именами объектов в конфигураторе (например, Документ.РеализацияТоваровУслуг) и их физическими именами в SQL (например, _Document123).
Таблица DBSchema. Хранит сериализованное описание структуры базы данных в бинарном поле SerializedData. Платформа использует эту таблицу для контроля соответствия физической схемы SQL и ожидаемой логической схемы 1С при запуске системы.

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

Штатный и безопасный способ получения структуры таблиц

Выясним, как решить задачу сопоставления элегантно. Вместо того чтобы «воевать» с бинарными данными в таблицах Config и Params средствами SQL, мы можем использовать встроенный метод платформы 1С: ПолучитьСтруктуруХраненияБазыДанных(). Этот метод мгновенно возвращает точную информацию обо всех физических таблицах и полях базы данных на SQL-сервере.

Рассмотрим пример кода на стороне 1С, который решает задачу автора темы: находит все документы, содержащие реквизиты ОтражатьВУправленческомУчете и ОтражатьВБухгалтерскомУчете, а затем выгружает их физические имена таблиц и полей:


// Создаем массив для отбора нужных документов
МассивИменДокументов = Новый Массив;

Для Каждого Док Из Метаданные.Документы Цикл
    // Проверяем наличие необходимых реквизитов у документа
    Если Док.Реквизиты.Найти("ОтражатьВУправленческомУчете") <> Неопределено 
       И Док.Реквизиты.Найти("ОтражатьВБухгалтерскомУчете") <> Неопределено Тогда
        
        МассивИменДокументов.Добавить(Док.ПолноеИмя());
        
    КонецЕсли;
КонецЦикла;

// Получаем физическую структуру хранения для отобранных документов
ТаблицаСтруктуры = ПолучитьСтруктуруХраненияБазыДанных(МассивИменДокументов, Истина);

// Выведем сопоставление имен для анализа
Для Каждого СтрокаТаблицы Из ТаблицаСтруктуры Цикл
    Если СтрокаТаблицы.Назначение = "Основная" Тогда
        Сообщить("Объект: " + СтрокаТаблицы.ИмяМетаданных 
               + " -> Таблица SQL: " + СтрокаТаблицы.ИмяТаблицыХранения);
        
        // Найдем физические имена полей
        Для Каждого Поле Из СтрокаТаблицы.Поля Цикл
            Если Поле.ИмяМетаданных = "ОтражатьВУправленческомУчете" Тогда
                Сообщить("   Поле УУ: " + Поле.ИмяПоляХранения);
            ИначеЕсли Поле.ИмяМетаданных = "ОтражатьВБухгалтерскомУчете" Тогда
                Сообщить("   Поле БУ: " + Поле.ИмяПоляХранения);
            КонецЕсли;
        КонецЦикла;
    КонецЕсли;
КонецЦикла;

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

Анатомия документа 1С в СУБД: скрытые опасности прямого удаления

Попытка выполнить банальный запрос DELETE FROM _Document123 WHERE ... на уровне базы данных приведет к фатальному разрушению логической целостности 1С. Документ в системе — это не просто строка в одной таблице. Это сложная иерархическая структура данных. Разберем по шагам, какие связанные сущности необходимо очищать при прямом удалении через SQL:

Табличные части (ТЧ) документа. Данные каждой табличной части хранятся в отдельных физических таблицах СУБД. Они имеют имя вида _Document123_VT_456. Если удалить запись из основной таблицы _Document123, но оставить строки в таблицах ТЧ, база данных заполнится «мусором», что приведет к ошибкам при последующем тестировании и исправлении или реструктуризации.
Движения по регистрам. Это самая критическая проблема. Документы при проведении записывают данные в регистры накопления (_AccumReg...), регистры сведений (_InfoReg...), регистры бухгалтерии (_AccReg...) и регистры расчета. При удалении самого документа из таблицы _Document123 его движения в регистрах **остаются нетронутыми**. В результате отчеты (например, оборотно-сальдовая ведомость или ведомость по складам) будут продолжать показывать старые цифры, но при попытке расшифровать строку (открыть регистратор) система выдаст ошибку <Объект не найден>.
Таблицы итогов регистров. Регистры накопления и бухгалтерии имеют служебные таблицы итогов (например, _AccumRegTotals...), которые хранят рассчитанные остатки на контрольные точки времени. Прямое удаление записей движений не пересчитает итоги автоматически, что полностью сломает логику получения остатков в запросах 1С.
Журналы документов. Если удаляемый документ входит в один или несколько журналов документов (таблицы вида _DocumentJournal...), строки из этих таблиц также необходимо вычищать, иначе битые ссылки будут отображаться в списках журналов.
Планы обмена (Регистрация изменений). Если база данных участвует в распределенном обмене (РИБ) или обменивается данными с другими системами, факт изменения или удаления объектов фиксируется в служебных таблицах регистрации изменений (например, _Document123_ChngR...). Без корректной очистки этих таблиц механизмы обмена начнут сбоить.
История данных. В современных версиях платформы 1С при включенном версионировании данные записываются в системные таблицы истории (_DataHistoryVersions и другие). Их также нужно обрабатывать, чтобы не оставлять сиротские записи.

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

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

Переполнение лога транзакций (LDF-файла). Операция DELETE является полностью журналируемой в MS SQL. При удалении огромных массивов информации файл лога транзакций может вырасти до сотен гигабайт, занять все дисковое пространство и аварийно остановить работу всего SQL-сервера.
Эскалация блокировок (Lock Escalation). Когда SQL Server понимает, что в рамках одной транзакции удаляется более 5000 строк, он автоматически заменяет точечные блокировки строк на полную блокировку всей таблицы. В этот момент все пользователи системы, пытающиеся записать или прочитать данные из этой таблицы, встанут в очередь и начнут получать ошибки по таймауту блокировок.

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


-- Объявляем переменную для контроля количества удаленных строк
DECLARE @RowsDeleted INT;
SET @RowsDeleted = 1;

-- Устанавливаем режим блокировок
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- Цикл выполняется до тех пор, пока удаляются строки
WHILE @RowsDeleted > 0
BEGIN
    BEGIN TRANSACTION;

    -- Удаляем порциями по 5000 строк
    DELETE TOP (5000) 
    FROM _Document152 
    WHERE _Fld1523 = 1; -- Условие отбора (например, пометка удаления или флаг учета)

    -- Записываем количество обработанных строк во временную переменную
    SET @RowsDeleted = @@ROWCOUNT;

    COMMIT TRANSACTION;

    -- Делаем технологическую паузу на 1 секунду для разгрузки дисковой подсистемы
    -- и возможности выполнения запросов других пользователей
    WAITFOR DELAY '00:00:01';
END

Перед запуском такого скрипта на работающей базе данных настоятельно рекомендуется перевести модель восстановления базы (Recovery Model) в режим Simple (Простая). Это позволит SQL Server автоматически очищать лог транзакций в процессе работы, предотвращая его неконтролируемый рост. После завершения операции не забудьте вернуть модель восстановления обратно в Full (Полная) и сделать полную резервную копию. Для автоматизации регулярного резервного копирования и сервисных операций во многих базах одновременно можно использовать софт для автоматического тестирования и архивирования 1С.

Обязательные действия после удаления данных через SQL

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

Запуск тестирования и исправления (ТИИ). Запустите конфигуратор, перейдите в меню Администрирование -> Тестирование и исправление. В списке проверок обязательно отметьте следующие пункты:
- Реорганизация таблиц (упорядочит физическое расположение данных на диске).
- Проверка ссылочной целостности. В правилах обработки выберите: при наличии битых ссылок — Очищать ссылки. Это позволит платформе автоматически вычистить «хвосты» в регистрах и табличных частях, которые ссылались на удаленные нами документы.
- Пересчет итогов (критически важно для восстановления корректности остатков в регистрах накопления и бухгалтерии).
Сжатие базы данных (Shrink). После удаления миллионов строк физические файлы базы данных на диске не уменьшатся автоматически — освободившееся место останется зарезервированным внутри файлов .mdf и .ldf. Чтобы вернуть свободное место операционной системе, выполните операцию SHRINKDATABASE или SHRINKFILE через SQL Server Management Studio.
Дефрагментация и реорганизация индексов. Массовое удаление строк приводит к сильнейшей фрагментации индексов таблиц. Выполните перестроение индексов (Index Rebuild) для всех измененных таблиц, чтобы восстановить прежнюю скорость работы запросов.

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