Как правильно выполнить непосредственное удаление документов в 1С 7.7 на SQL и подготовить базу для УРБД

← На главную

При работе с крупными базами данных на платформе 1С:Предприятие 7.7 под управлением MS SQL Server часто возникает задача уменьшения объема данных. Это особенно актуально при подготовке периферийных информационных баз в системе УРБД (универсальное распределение баз данных), когда из центральной базы (ЦБ) необходимо исключить документы, не относящиеся к конкретному складу или подразделению. В этой статье мы подробно разберем, как работает метод непосредственного удаления, какие последствия он несет для SQL-сервера и как правильно подготовить "облегченную" копию базы.

Механизм работы метода Удалить(1) и его влияние на таблицы

Рассмотрим стандартный программный метод Удалить(1). В отличие от пометки на удаление, этот метод выполняет физическое удаление записи из таблиц базы данных. Проанализируем, что происходит внутри системы при вызове этой команды:

Система обращается к общему журналу документов — таблице _1SJOURN — и удаляет соответствующую строку.
Удаляются записи из основных таблиц документа: DH* (шапка) и DT* (табличная часть).
Очищаются записи в таблице движений RA* и таблице итогов RG*, если документ был проведен.
Удаляются ссылки в таблице подчиненных документов _1SCRDOC.

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

Особенности работы с MS SQL Server: сжатие и логи транзакций

Проанализируем ситуацию с точки зрения системного администрирования. Если мы массово удаляем тысячи документов, это порождает колоссальную нагрузку на дисковую подсистему и систему логирования.

Лог транзакций (файл .ldf): При массовом удалении через метод Удалить(1) SQL Server записывает каждую операцию в лог транзакций. Если база находится в модели восстановления Full, файл лога может вырасти в несколько раз, превысив размер самой базы. Разберем по шагам, как этого избежать:

Перед началом массового удаления переключите модель восстановления базы в Simple.
Выполните процедуру удаления документов.
После завершения выполните операцию Shrink Database (сжатие базы) через SQL Server Management Studio.

Посмотрим на пример кода, который часто используется для пакетного удаления документов в 1С 7.7:


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

Целостность данных и регистры при массовом удалении

Выясним, почему простое удаление может быть опасным. Хотя движок 1С 7.7 старается корректно вычищать движения, при программных сбоях в таблицах итогов (RG*) могут остаться "фантомные" записи. Это приведет к тому, что отчеты будут показывать неверные остатки.

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

Сначала необходимо снять документ с проведения методом СделатьНепроведенным(). Это гарантирует корректный пересчет итогов в таблицах RG*.
Только после успешного снятия с проведения вызывайте Удалить(1).
После массовой очистки обязательно выполните "Пересчет итогов" и "Восстановление последовательностей" через режим Конфигуратора или программно.

Подготовка базы для УРБД через создание копии

Часто в обсуждениях на форумах предлагают стратегию: "сделать копию ЦБ — удалить лишнее — создать дочернюю базу". Это эффективный способ, если нужно передать в филиал только НСИ (нормативно-справочную информацию) и остатки. Однако здесь есть критические нюансы, касающиеся механизмов миграции.

Проанализируем таблицу _1STRANS. Это системная таблица, где 1С хранит регистрацию изменений для обмена. Если вы просто удалите документы в копии базы, эти удаления могут зарегистрироваться как изменения и при первой же синхронизации "улетят" обратно в центральную базу, удалив данные там!

Как правильно подготовить копию для УРБД:

Выполните удаление лишних документов в копии.
Полностью очистите таблицу _1STRANS (средствами SQL: TRUNCATE TABLE _1STRANS).
Очистите таблицы миграции, чтобы база "забыла" о своей связи с другими узлами до момента инициализации.
Только после этого выполняйте процедуру превращения копии в периферийную базу (инициализацию из ЦБ).

Архивирование периода (Свертка базы)

Рассмотрим понятие "Архивирование периода", упомянутое в сообщениях. В контексте 1С 7.7 под этим понимается свертка базы. Это более надежный метод, чем простое удаление. Выясним, из каких этапов он состоит:

Фиксация остатков на определенную дату (например, на начало года) и ввод этих остатков специальными документами.
Удаление всех документов за предыдущие периоды.
Сжатие таблиц базы данных.

Этот подход гарантирует, что в дочерней базе будут актуальные начальные данные, но объем таблиц _1SJOURN и DT* существенно сократится, что ускорит работу системы.

Реиндексация и производительность

После удаления миллионов строк индексы в MS SQL становятся сильно фрагментированными. Разберем, к чему это приводит: даже если данных стало меньше, SQL Server может тратить больше времени на поиск из-за "дыр" в индексах.

Рекомендация: Сразу после удаления документов и выполнения процедуры Shrink, обязательно запустите Rebuild Indexes. В 1С 7.7 это также можно инициировать через процедуру "Тестирование и исправление" с флагом "Реиндексация", но на SQL-версии эффективнее использовать средства самого SQL Server Maintenance Plans.

Подведем итог: непосредственное удаление Удалить(1) является мощным инструментом, но требует понимания работы СУБД. Совместное использование программных методов 1С и административных инструментов SQL Server позволит вам эффективно управлять размером базы и корректно настраивать распределенные системы.