При работе с архивными базами «1С:Бухгалтерия предприятия 2.0» или другими конфигурациями на обычных формах системные администраторы и программисты часто сталкиваются с неприятным явлением: база, в которой давно не ведутся операции, продолжает стремительно увеличиваться в объеме. Основная причина кроется в механизме работы регистров накопления и автоматическом пересчете итогов. В этой статье мы подробно разберем, почему это происходит и как эффективно остановить «распухание» таблиц итогов, сохранив при этом целостность данных для налоговых проверок и выполнив поиск ликвидированных юридических лиц.
Проанализируем механику платформы 1С. Для каждого регистра накопления в базе данных SQL создаются таблицы движений и таблицы итогов (с суффиксами _T и _B). Платформа 1С спроектирована так, чтобы обеспечивать максимальную скорость получения остатков на текущий момент. Для этого система ежемесячно рассчитывает итоги на начало следующего месяца.
Даже если в вашей базе БП 2.0 учет завершен в 2022 году, регламентные задания или встроенные механизмы платформы продолжают пытаться рассчитать итоги на «сегодня». Если у вас в регистрах МПЗ (Материально-производственные запасы) или в регистрах маркировки (ИС МП) остались ненулевые остатки (а они там есть почти всегда из-за специфики учета), система каждый месяц создает новые записи в таблицах итогов для каждой комбинации измерений (особенно если есть номенклатура с одинаковыми кодами). За 2 года простоя базы количество таких «пустых» итоговых записей может исчисляться миллионами, что добавляет десятки гигабайт к объему SQL-базы.
Рассмотрим самый простой и штатный способ, который часто упускают из виду в конфигурациях на обычных формах. Нам необходимо жестко ограничить период, далее которого система не будет даже пытаться заглядывать.
Важный нюанс: в БП 2.0 интерфейс может быть не таким наглядным, как в современных версиях. Главная задача здесь — убедиться, что «Максимальный период» не улетает в бесконечность или в текущий месяц 2024-2025 года.
Если регистров много, ручная настройка может быть утомительной. Разберем, как автоматизировать этот процесс с помощью небольшого фрагмента кода. Мы можем использовать удаление объектов для обычных форм или создать внешнюю обработку и выполнить следующий алгоритм для принудительной установки границ:
Для Каждого Регистр Из РегистрыНакопления Цикл
Если Регистр.ПолучитьИспользованиеИтогов() Тогда
Попытка
// Устанавливаем границу на конец 2022 года
ГраницаИтогов = Дата(2023, 01, 01);
Регистр.УстановитьПериодРассчитанныхИтогов(ГраницаИтогов);
Сообщить("Для регистра " + Регистр + " установлен период: " + ГраницаИтогов);
Исключение
Сообщить("Не удалось установить итоги для: " + Регистр);
КонецПопытки;
КонецЕсли;
КонецЦикла;
Этот код пройдется по всем регистрам накопления и «прижмет» их итоги к дате архивации. После выполнения этого скрипта рост таблиц в будущем прекратится.
Проанализируем ситуацию: даже если мы установили итоги, в базе могут продолжать запускаться фоновые задания ОбновлениеИтогов или СлияниеИндексов (по аналогии с удалением помеченных объектов в БП 2.0). В архивной базе они абсолютно бессмысленны. Посмотрим на шаги по их отключению:
Это действие гарантирует, что никакие внутренние процессы 1С не инициируют пересчет итогов и не вызовут расширение файлов базы данных.
Как отмечали участники обсуждения, штатные средства БП 2.0 не всегда дают полную картину. Рекомендуем воспользоваться портативным набором «Инструменты разработчика». С его помощью можно увидеть скрытые регистры и системные таблицы, которые также могут «пухнуть». В консоли управления итогами этого набора инструментов можно визуально отследить «хвосты» — записи, которые выходят за рамки актуальных периодов, и очистить их одной кнопкой.
Если ваша база работает на MS SQL Server, и даже после фиксации итогов она занимает слишком много места, применим методы сжатия. Поскольку данные в архиве больше не меняются (ReadOnly-режим), они идеально подходят для SQL-компрессии.
Разберем последовательность действий в SQL Management Studio (SSMS):
_AccumRegT....SHRINKDATABASE или SHRINKFILE, чтобы вернуть освободившееся место операционной системе.Пример SQL-запроса для оценки размера таблиц:
SELECT t.NAME AS TableName, s.Name AS SchemaName, p.rows AS RowCounts,
(SUM(a.total_pages) * 8) / 1024 AS TotalSpaceMB
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
LEFT OUTER JOIN sys.schemas s ON t.schema_id = s.schema_id
GROUP BY t.Name, s.Name, p.Rows
ORDER BY TotalSpaceMB DESC
Особое внимание уделим регистрам маркировки. В конфигурациях, где используется работа с «Честным Знаком», записи в регистрах сведений и накопления часто не закрываются «в ноль» даже после продажи товара. Если база нужна только как юридический архив, мы можем рассмотреть вариант полного отключения итогов по регистрам маркировки через Конфигуратор. Это физически удалит таблицы _T из SQL-базы, оставив только сами движения (документы), чего достаточно для подтверждения операций, но сэкономит колоссальное количество места.
Подведем итог: Борьба с ростом архивной базы — это комплекс мер. Сначала мы ограничиваем «аппетиты» платформы через Управление итогами и УстановитьПериодРассчитанныхИтогов, затем блокируем фоновую активность через консоль сервера, и в конце оптимизируем хранение на уровне СУБД. Такой подход позволяет сократить размер базы в несколько раз и гарантировать, что она не вырастет снова.