Попробуем разобраться...
Что такое итоги по регистрам?
Это агрегированные значения из таблицы движений регистров, которые используются для быстрого вычисления остатка или оборота по каким-либо измерениям. Хранятся они в отдельных таблицах.
Какие итоги бывают?
По умолчанию для регистров существуют итоги по месяцам и актуальные итоги (только для регистров остатков).
Почему "по умолчанию"? Потому что администратор базы может управлять наличием итогов с помощью методов "УстановитьИспользованиеИтогов" и "УстановитьИспользованиеТекущихИтогов".
Что происходит, когда документ записывает движения по регистру?
Представим, что проводим документ "Реализация товаров и услуг" в типовой УТ 10.3 с 1 строкой в табличной части задним числом за 01.01.2013, а дата расчета итогов - 28.02.2013. Во время проведения происходит запись регистра накопления "Товары на складах".
При этом в СУБД:
1) добавляется новая запись в таблицу движений регистра накопления
2) в таблице итогов происходит обновление актуальных итогов - из остатка на 01.11.3999 отнимается списанное количество.
3) если дата документа меньше крайней даты расчета итогов, то происходит обновление итогов по месяцам (причем столько раз, насколько месяцев дата документа меньше даты расчета итогов) - т.е. будут обновлены итоги на 01.02.2013 и 01.03.2013.
Итого в результате записи документа произошла модификация 4-х строк только по этому регистру.
И где проблема?
А проблема в том, что с течением времени в таблице итогов накапливаются записи с нулевыми значениями. Представим, что в предыдущем примере реализация полностью списала весь остаток товара на тот момент. Получается, что 2 итога по месяцам и актуальные итоги будут обнулены - сначала поступление добавило положительное значение в итоги, а реализация его обнулила. В виртуальных таблицах значение пропадет, но нулевые записи в физических таблицах остаются.
Посмотрим на таблицу итогов этого регистра в СУБД - получим по периодам общее число записей и число записей, для которых все ресурсы равны 0:
Получается, что мы имеем некое количество "мусорных" записей в итогах по месяцам и почти 30% "мусорных" записей в актуальных итогах.
А ведь актуальные итоги - это наиболее часто используемые данные для оперативно проводимых документов. И лишние строки в этом массиве данных приводят к замедлению выполнения запросов, т.е. документы проводятся дольше, больше риск возникновения блокировок.
Как исправить ситуацию?
Следует отметить, что делать это нужно регулярно. Частота проведения определяется в индивидуальном порядке в зависимости от интенсивности работы с базой.
Есть несколько вариантов.
Самый простой и очевидный - в конфигураторе запустить полный пересчет итогов. Минусы - если база большая, то этот процесс займет длительное время.
Другой вариант - запуск пересчет итогов средствами встроенного языка.
Например, для пересчета актуальных итогов (как наиболее важных с точки зрения оперативной работы пользователей) можно использовать следующий код:
Для каждого Рег из Метаданные.РегистрыНакопления Цикл
Если Рег.ВидРегистра = Метаданные.СвойстваОбъектов.ВидРегистраНакопления.Остатки Тогда
РегистрыНакопления[Рег.Имя].ПересчитатьТекущиеИтоги();
КонецЕсли;
КонецЦикла;
Для каждого Рег из Метаданные.РегистрыБухгалтерии Цикл
РегистрыБухгалтерии[Рег.Имя].ПересчитатьТекущиеИтоги();
КонецЦикла;
Если ваша база работает уже не один год и ее объем достаточно большой, то этот код выполниться на порядок быстрее полного пересчета итогов. Поэтому можно даже сделать этот код регламентным заданием и выполнять каждую ночь или на выходных.
Выполним эту процедуру и посмотрим в СУБД на ту же таблицу:
Видно, что в актуальных итогах (первая строка) нулевых записей больше нет.
Похожим образом выполняется пересчет итогов по месяцам.
Необходимо использовать метод "УстановитьПериодРассчитанныхИтогов()" - пересчитать можно, например, только несколько последних месяцев и не нагружать систему лишним пересчетом прошлых лет.
В совсем запущенных случаях пересчет итогов только средствами 1С занимает очень много времени.
Фактически платформе 1С сначала надо очистить огромный объем записей в таблицах итогов, а потом заново их наполнить обновленными данными меньшего размера.
При этом платформа удаляет итоги помесячно с помощью DELETE. Соответственно, это требует много ресурсов и времени.
Сильно ускорить процесс можно путем предварительной очистки итогов в СУБД с помощью TRUNCATE TABLE.
Как один из вариантов:
1) отключаем всех пользователей и делаем бэкап базы средствами MSSQL;
2) генерируем запросы на очистку всех таблиц итогов по регистрам накопления:
В контексте базы данных выполняем запрос:
SELECT 'TRUNCATE TABLE ' + name FROM sys.tables
WHERE name like '_AccumRgT%'
Результат вывода копируем, вставляем в окно запроса и выполняем в контексте базы данных.
3) Запускаем пересчет итогов через Тестирование и исправление в Конфигураторе.
При таком подходе процесс займет существенно меньше времени, т.к. СУБД не будет тратить время на тяжелую операцию удаления старых записей.
Что еще следует помнить?
Пересчет итогов влияет на статистику - она становится не актуальной. Соответственно, после пересчета итогов вы можете получить не улучшение, а, наоборот, ухудшение производительности. Поэтому нужно не забывать запускать полное обновление статистики в СУБД и очистку процедурного кэша после проведения пересчета.
Пересчет итогов также приводит к практически 100% фрагментации индексов по таблицам итогов.
Для больших баз данных это может существенно сказываться на производительности.
Варианта решения этой проблемы два:
1) (долгий, но простой) - После пересчета итогов запускать реиндексацию таблиц из конфигуратора через "Тестирование и исправление".
Не запускайте одновременно пересчет итогов и реиндексацию, т.к. конфигуратор сначала перестроит индексы, а затем пересчитает итоги, т.е. таблицы итогов все равно будут фрагментированы. Необходимо выполнять эти операции раздельно.
2) (более быстрый, только для клиент-серверного варианта) - Воспользоваться одним из множества скриптов в интернете для перестроения только наиболее фрагментированных индексов.
UPD. Посмотрите также очень содержательный комментарий Алексея Лустина в этой теме (сообщение №58).
