Как выявить и устранить причины аномального роста размера базы 1С:Управление торговлей 10.3

← На главную

Ситуация, когда база данных «1С:Управление торговлей 10.3» (УТ 10.3) разрастается до внушительных размеров (например, 1 Тб), требует системного подхода. Такой объем часто не является следствием реального роста количества хозяйственных операций, а указывает на технические проблемы или неоптимальные настройки хранения данных. Рассмотрим подробно, как проанализировать структуру базы, выявить «пожирателей» места и привести систему в порядок.

Шаг 1. Анализ распределения места на уровне СУБД

Прежде чем приступать к действиям внутри конфигуратора 1С, нам необходимо выяснить, какие именно физические таблицы занимают больше всего места на диске. Поскольку база работает под управлением MS SQL Server, воспользуемся стандартными инструментами этой СУБД. Проанализируем ситуацию с помощью отчета Disk Usage by Top Tables.

Откроем SQL Server Management Studio (SSMS), нажмем правой кнопкой мыши на нашу базу данных и выберем пункт Reports -> Standard Reports -> Disk Usage by Top Tables. Этот отчет покажет нам список таблиц, отсортированных по занимаемому объему. Особое внимание стоит уделить колонкам Data (данные) и Index (индексы).

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


SELECT 
    t.NAME AS TableName,
    p.rows AS RowCounts,
    SUM(a.total_pages) * 8 AS TotalSpaceKB, 
    SUM(a.used_pages) * 8 AS UsedSpaceKB, 
    (SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB
FROM 
    sys.tables t
INNER JOIN      
    sys.indexes i ON t.object_id = i.object_id
INNER JOIN 
    sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
INNER JOIN 
    sys.allocation_units a ON p.partition_id = a.container_id
WHERE 
    t.is_ms_shipped = 0 AND i.object_id > 255 
GROUP BY 
    t.Name, p.Rows
ORDER BY 
    TotalSpaceKB DESC;

Этот запрос позволит нам увидеть реальную картину. Выясним причину: если в топе находятся таблицы с префиксами _AccumRg, проблема в регистрах накопления; если _InfoRg — в регистрах сведений; если _Document или _Reference — в самих документах или справочниках.

Шаг 2. Сопоставление имен таблиц SQL с объектами 1С

SQL-имена таблиц (например, _InfoRg12345) мало что говорят прикладному программисту. Нам нужно сопоставить их с метаданными. Для этого в платформе предусмотрена функция ПолучитьСтруктуруХраненияБазыДанных(). Также можно воспользоваться готовыми внешними обработками, такими как «Структура хранения БД» из состава инструментов разработчика.

Рассмотрим, как программно получить имя таблицы 1С по ее имени в SQL:


Структура = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Таблица Из Структура Цикл
    Если Таблица.ИмяТаблицыХранения = "_InfoRg12345" Тогда
        Сообщить("Это таблица объекта: " + Таблица.Метаданные);
    КонецЕсли;
КонецЦикла;

Шаг 3. Анализ версионирования объектов

Одной из самых частых причин разрастания УТ 10.3 является включенная подсистема «Версионирование объектов». Если в настройках указано «Хранить историю всегда» для всех документов, то регистр сведений ВерсииОбъектов (в SQL это будет одна из крупнейших таблиц _InfoRg...) может занимать сотни гигабайт. В нем хранятся XML-снимки объектов при каждом их изменении.

Решение: Проанализируем настройки версионирования. Если история за 5 лет не нужна, следует очистить старые записи. Для очистки можно использовать типовые средства подсистемы или написать простую обработку, удаляющую записи из регистра ВерсииОбъектов по определенную дату.

Шаг 4. Проверка хранения файлов в базе

Выясним, не хранятся ли в базе тяжелые вложения. В УТ 10.3 часто используют справочник ХранилищеДополнительной информации. Если пользователи загружают туда сканы договоров в высоком разрешении или даже видеофайлы, база будет расти катастрофически быстро. Данные хранятся в полях типа Image или VarBinary(max).

Решение: Рассмотрим вариант выноса файлов на диск. В современных конфигурациях 1С это штатный функционал, но в старой УТ 10.3 может потребоваться доработка. Мы можем программно выгрузить содержимое хранилища в сетевую папку, а в самой базе оставить только путь к файлу.

Шаг 5. Проблема незакрытых регистров и итогов

Регистры накопления (например, Закупки, Продажи, ОстаткиТоваров) имеют таблицы итогов (префикс _AccumRgT). 1С хранит итоги на конец каждого месяца. Если в регистрах есть «зависшие» остатки (когда по одной аналитике пришло 10 единиц, а ушло 10 единиц по другой, из-за чего общий остаток ноль, но в разрезе измерений записи остаются), таблица итогов начинает раздуваться.

Разберем по шагам, что делать:

Проверим актуальность итогов через Операции -> Управление итогами.
Выполним пересчет итогов. Это удалит лишние записи из таблиц _AccumRgT, которые больше не актуальны.
Проанализируем регистры на предмет «незакрытых» измерений. Если мы видим остатки по сериям или складам, которые по факту нулевые, необходимо провести корректировку записей регистров.

Шаг 6. Таблицы регистрации изменений (Планы обмена)

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

Проанализируем ситуацию: зайдем в Операции -> Планы обмена. Посмотрим на количество зарегистрированных изменений для каждого узла. Если там миллионы записей для узла, который не используется — смело удаляем регистрацию или сам узел.

Шаг 7. Техническое обслуживание SQL (Shrink и Логи)

Иногда «размер базы» — это просто размер файла .mdf, в котором 80% свободного места после удаления старых данных. SQL Server не отдает место операционной системе автоматически.

Рассмотрим технические действия:

Shrink (Сжатие): После массового удаления данных (например, очистки версий) выполните SHRINKDATABASE или SHRINKFILE. Но помните: это вызывает сильную фрагментацию индексов.
Reindex (Переиндексация): После сжатия обязательно выполните перестроение индексов (Rebuild).
Лог транзакций (.ldf): Проверьте размер лога. Если база находится в модели Full Recovery, но бэкап лога не делается, файл .ldf может быть больше файла данных. Установите модель Simple (если это допустимо политикой безопасности) или настройте регулярный бэкап лога.

Шаг 8. Свертка информационной базы

Если после всех манипуляций размер базы остается критическим, единственным радикальным решением для УТ 10.3 остается свертка базы. Это процесс обрезания документов до определенной даты (например, до начала текущего года) с переносом входящих остатков. Это физически удаляет миллионы строк из основных таблиц документов и регистров.

Резюме: Мы проанализировали основные причины роста базы. Начните с отчета по таблицам в SQL, определите «виновника» по метаданным 1С и последовательно применяйте методы очистки: от удаления версий и пересчета итогов до оптимизации хранения файлов. Совместная работа системного администратора и программиста 1С позволит сократить базу в несколько раз без потери производительности.