Проблема роста физического размера таблиц в SQL-базе 1С — это классическая ситуация, с которой сталкиваются администраторы и разработчики высоконагруженных систем. Особенно остро это проявляется в конфигурации «Управление производственным предприятием» (УПП) 1.3, где механизмы итогов могут вести себя непредсказуемо при неправильной настройке бизнес-логики. Давайте детально разберем, почему таблица _AccumRgT (таблица текущих итогов) может «раздуваться», даже если вы регулярно делаете рендексацию, и как это исправить.
Первым делом проанализируем ситуацию, описанную в теме. Мы имеем дело с регистром накопления Заказы покупателей. В системе 1С регистры накопления бывают двух видов: Остатки и Обороты. Для регистров остатков платформа создает две физические таблицы в SQL:
_AccumRg... — таблица движений (все записи документов)._AccumRgT... — таблица текущих итогов (актуальные остатки на «сейчас»).Важно понимать фундаментальный принцип: запись в таблице _AccumRgT существует до тех пор, пока остаток по данной комбинации измерений (Номенклатура, Склад, Заказ и т.д.) не станет равным нулю. Как только сумма и количество по всем ресурсам обнуляются, 1С (теоретически) должна удалить эту строку из таблицы итогов.
В рассматриваемом случае автор сообщает, что документ Заказ покупателя не делает движений («прихода»), а документ Реализация товаров и услуг (РТиУ) делает только «расход». Это критическая ошибка. Если в регистр пишутся только расходы без соответствующих приходов, остатки по каждому заказу уходят в «минус». Поскольку остаток никогда не становится нулевым, строка в таблице итогов остается там навсегда. С каждым новым заказом количество строк в _AccumRgT будет расти линейно, и никакая реорганизация индексов здесь не поможет.
Разберем еще одну неочевидную причину роста — механизм разделения итогов. Для того чтобы несколько пользователей могли одновременно проводить документы, не блокируя друг друга при записи в одну и ту же строку итогов (например, по одному популярному товару), 1С применяет «разделитель».
Как это работает: Платформа создает не одну строку Товар А | Склад Б | Остаток 10, а несколько строк с разными значениями скрытого поля-разделителя. В итоге физическое количество строк в таблице SQL может быть в десятки раз больше, чем логическое количество уникальных остатков. Если в конфигураторе для регистра включено свойство Разделение итогов, это повышает параллельность, но увеличивает объем таблицы.
Чтобы минимизировать этот эффект, необходимо регулярно выполнять регламентную операцию «Свертка итогов». Это не просто пересчет, а процесс объединения «разделившихся» строк в одну. В УПП это можно сделать через «Тестирование и исправление» или через консоль управления итогами.
Проанализируем ситуацию с некорректными датами. Иногда пользователи ошибаются и вводят документ датой 31.12.3999. Платформа 1С хранит актуальные итоги на самую позднюю дату движений. Если такая запись появилась, система будет пытаться поддерживать таблицу актуальных итогов именно на 3999 год.
Выясним причину через прямой SQL-запрос. Откройте SQL Server Management Studio (SSMS) и выполните запрос к проблемной таблице (имя таблицы итогов можно узнать через ПолучитьСтруктуруХраненияБазыДанных()):
SELECT MAX(Period) FROM _AccumRgT27774; -- Замените на имя вашей таблицы
Если результат запроса показывает дату, отличную от текущего месяца или конца времен (стандартно это 5999 год для итогов, но нас интересуют аномалии в движениях), значит, в базе есть «мусорные» документы. Их нужно найти и исправить.
Посмотрим на проблему со стороны СУБД. Даже если 1С логически пометила записи как удаленные, SQL Server не освобождает место мгновенно. Рассмотрим два фактора:
Ghost Cleanup должен их вычищать, но при высокой нагрузке он может не успевать.Fill Factor 100%, то любая вставка новой строки (а при разделении итогов их много) вызывает Page Split (расщепление страницы). Это ведет к резкому росту физического файла базы данных и фрагментации.Рекомендация: Для таблиц итогов с интенсивной записью попробуйте установить Fill Factor на уровне 80–90% при перестроении индексов.
Рассмотрим по шагам, что нужно сделать администратору 1С:
Заказ не делает прихода, необходимо использовать специализированные документы для «закрытия» остатков. В УПП это документ Закрытие заказов покупателей. Он сформирует необходимые движения, которые выведут остаток в ноль, и 1С сможет удалить строку из итогов.Операции -> Управление итогами. Убедитесь, что период рассчитанных итогов установлен на текущий месяц. Если итоги рассчитаны на глубокое прошлое, система тратит огромные ресурсы на вычисления «на лету»._AccumRgT:
РегистрыНакопления.ЗаказыПокупателей.УстановитьИспользованиеИтогов(Ложь);
// После завершения транзакции
РегистрыНакопления.ЗаказыПокупателей.УстановитьИспользованиеИтогов(Истина);
Продажи. Оборотные регистры не хранят остатки «навсегда», их таблицы итогов (_AccumRgStatic) хранят данные в разрезе периодов (обычно месяц), и их гораздо проще администрировать.Если визуально всё в порядке, а таблица растет, настройте Технологический журнал (ТЖ). Нам интересны события DBMSSQL, связанные с данной таблицей. Проанализируем запросы INSERT и UPDATE. Если вы видите, что один и тот же документ порождает сотни записей в таблицу итогов, ищите ошибку в коде подписок на события или в логике проведения.
Резюме: Основная причина «распухания» — это незакрытые остатки. В 1С:УПП 1.3 регистр Заказы покупателей обязательно должен «закрываться» в ноль. Либо приходом от Заказа и расходом от Реализации, либо корректировками. Пока в таблице висят «хвосты» (даже копеечные или минусовые), SQL-таблица итогов будет расти бесконечно.