Разберем ситуацию, типичную для администраторов и разработчиков высоконагруженных систем на базе «1С:Предприятие 8.3». В процессе эксплуатации базы данных на MS SQL Server часто обнаруживается, что таблица итогов одного из регистров (например, РегистрНакопления.ВзаиморасчетыСКонтрагентами, которая в SQL носит имя _AccumRgT с соответствующим индексом) разрастается до аномальных размеров — 10, 20 или даже 100 Гб. Чтобы быстро локализовать проблему, можно выполнить расчет размера таблиц базы данных и сопоставить имена SQL-таблиц с объектами метаданных. При этом объем самих движений в основной таблице может быть значительно меньше. Проанализируем причины этого явления и изучим пошаговый алгоритм решения проблемы. Для сопоставления таблицы итогов с регистром используйте обработку обследования базы. Размер итогов она покажет после отдельного SQL-запроса и загрузки результата; обычный размер по платформе их не учитывает.
Первое, на что стоит обратить внимание при просмотре таблицы через консоль MS SQL Server или используя инструмент, позволяющий анализировать SQL сервер глазами 1С-ника — это странные значения в поле _Period. Там могут встречаться даты с годами 4014, 4024 или даже 5999. Рассмотрим, что это означает с технической точки зрения, изучив ошибки в датах и периодах 1С в MS SQL Server:
DATETIME в SQL Server, который не поддерживает значения ранее 1753 года. Таким образом, реальный 2024 год в базе данных отображается как 4024-й.Миллионы строк в таблице _AccumRgT при наличии всего нескольких тысяч активных клиентов свидетельствуют о «раздувании» итогов. Основные факторы роста:
Незакрытые аналитические разрезы: В регистрах (особенно в конфигурациях УТ 10.3 или УПП) активно используются измерения Сделка, Договор и ДокументРасчетов. Если в системе возникает копеечный остаток или «пересортица» по документам (например, по одному документу +10 коп., а по другому -10 коп.), общий баланс по контрагенту обнулится, но платформа будет хранить обе строки вечно. Каждый месяц 1С копирует эти незакрытые остатки в новую порцию записей, что вызывает геометрический рост таблицы.
Механизм разделителя итогов (Splitter): Для повышения параллельности записи в современных версиях платформы применяется поле _Splitter. Вместо блокировки одной строки итога система создает несколько записей с разными разделителями. Если регламентные задания по обслуживанию итогов не выполняются, эти строки не «схлопываются», увеличивая размер таблицы в несколько раз. Детально этот процесс описан в материале про работу с итогами регистров накопления и влияние разделителей на объем базы данных.
Последовательность действий для устранения «финансового пузыря» в базе данных:
Прежде всего, нужно проверить движения регистра на предмет ошибочных дат в прошлом. Используйте консоль запросов 1С для поиска записей с периодом ранее 2000 года (при использовании смещения):
ВЫБРАТЬ
Взаиморасчеты.Регистратор,
Взаиморасчеты.Период
ИЗ
РегистрНакопления.ВзаиморасчетыСКонтрагентами КАК Взаиморасчеты
ГДЕ
Взаиморасчеты.Период < ДАТАВРЕМЯ(2000, 1, 1)
Все найденные документы необходимо исправить: перепровести с верной датой или скорректировать программно, чтобы удалить некорректные записи из «начала времен».
Изучите структуру итогов. Если проблема заключается в незакрытых сделках, найдите комбинации измерений, по которым итоговый остаток равен нулю, но есть движения в разрезе детальной аналитики. На основе этого анализа следует применить методику борьбы с «пухлыми» регистрами через закрытие аналитики и использовать специализированный инструмент для удаления и обработки записей регистров накопления, чтобы обнулить все неактуальные старые сделки и документы расчетов.
Платформа 1С хранит итоги за каждый месяц до определенной «Границы рассчитанных итогов». Если эта граница установлена слишком далеко в будущем, таблица будет перегружена. Выполните следующие действия:
_AccumRgT.В ряде случаев обычного пересчета недостаточно. Тогда применяется радикальный, но эффективный метод — полное отключение и последующее включение итогов. Осуществляя управление итогами в 1С 8.3, вы очищаете таблицу _AccumRgT и пересоздаете её заново на основе таблицы движений.
Внимание! Данная операция требует монопольного доступа и может занять длительное время.
Пример программного выполнения операции:
Регистр = РегистрыНакопления.ВзаиморасчетыСКонтрагентами;
// Отключаем использование итогов — таблица в SQL полностью очищается
Регистр.УстановитьИспользованиеИтогов(Ложь);
// Включаем обратно — система заново рассчитывает итоги по движениям
Регистр.УстановитьИспользованиеИтогов(Истина);
// Выполняем пересчет итогов по текущую дату
Регистр.ПересчитатьИтоги();
После оптимизации данных в 1С физический размер файла базы данных (MDF) на диске не уменьшится сам по себе. Для освобождения места в операционной системе необходимо выполнить операцию Shrink Database или Shrink File через SQL Server Management Studio. Однако перед этим обязательно проведите инструкцию по настройке регламентных операций MS SQL SERVER под 1С, выполнив дефрагментацию и перестроение индексов. Для качественного обслуживания индексов в современных версиях платформы рекомендуется использовать MaintenanceSolution от Ola Hallengren с доработанной IndexOptimize, так как после массового удаления записей индексы будут сильно фрагментированы.
Подведем итог: размер таблицы итогов в 13 Гб при сравнительно небольшом количестве движений — явный признак избыточности аналитики. Сочетание исправления дат, закрытия старых сделок и технического пересоздания итогов позволяет сократить объем таблицы в 5–10 раз, что значительно ускорит формирование отчетов и проведение документов.