Ситуация, когда привычные операции в 1С начинают выполняться в десятки раз медленнее без видимых причин, часто ставит в тупик даже опытных разработчиков. Рассмотрим конкретный сценарий: внешняя обработка, которая активирует движения документа Операция (бухгалтерский учет), внезапно стала работать вместо 5 секунд целых 3 минуты. При этом конфигурация не обновлялась, а объем данных в базе вырос незначительно. Проанализируем причины этого явления и разберем пошагово методы диагностики и решения проблемы.
Первым делом проанализируем ситуацию на уровне СУБД. Использование технологического журнала (ТЖ) позволяет увидеть, на какой именно запрос тратится основное время. В нашем случае выяснилось, что задержка происходит на запросе типа UPDATE, который работает с таблицами регистра бухгалтерии Хозрасчетный.
Ключевая аномалия: Параметр RowsAffected (количество затронутых строк) вырос с 10 000 до 1 000 000 при активации одного и того же набора из 6 000 проводок. Это прямо указывает на то, что система обновляет не только сами записи регистра, но и огромный массив данных в таблицах итогов. Выясним причину, почему при 6 000 проводок перелопачивается треть всего регистра (1,3 миллиона записей).
Одной из наиболее частых причин «скачкообразного» падения производительности является человеческий фактор — ввод документа с некорректной датой. Рассмотрим, как это влияет на работу системы. Регистры бухгалтерии хранят итоги в разрезе месяцев. Если в базе появляется хотя бы один документ с датой, например, 01.01.0202 вместо 2022 года, система вынуждена поддерживать таблицы итогов за весь этот гигантский интервал (более 1800 лет).
Проанализируем ситуацию: при активации движений Набор.УстановитьАктивность(Истина) платформа 1С инициирует пересчет итогов. Если в базе есть «мусорные» даты, SQL-запрос начинает обновлять итоги за каждый месяц, начиная с самой ранней даты в системе до актуального периода. Именно это дает эффект RowsAffected = 1 000 000.
Для поиска таких документов выполним следующий запрос в консоли запросов:
ВЫБРАТЬ
Хозрасчетный.Регистратор,
Хозрасчетный.Период
ИЗ
РегистрБухгалтерии.Хозрасчетный КАК Хозрасчетный
ГДЕ
Хозрасчетный.Период < ДАТАВРЕМЯ(2000, 1, 1)
ИЛИ Хозрасчетный.Период > ДАТАВРЕМЯ(2030, 1, 1)
Если запрос возвращает данные, необходимо исправить даты у найденных документов-регистраторов и заново пересчитать итоги.
Даже если даты документов корректны, таблицы итогов могут деградировать. Рассмотрим по шагам процесс обслуживания регистра бухгалтерии для восстановления скорости:
Все функции -> Стандартные -> Управление итогами. Проверим, на какую дату рассчитаны итоги по регистру Хозрасчетный. Если период итогов сильно отстает от текущей даты, любая запись в регистр будет вызывать тяжелый пересчет «на лету»._AccRgT..., а затем включить их заново и установить актуальный период расчета.УточнениеПериода. Оно помогает платформе различать записи внутри одной секунды. Если длина уточнения периода установлена некорректно или индексы по этому полю повреждены, SQL-сервер может выбирать неоптимальный план запроса (Table Scan вместо Index Seek).Разберем ситуацию с точки зрения архитектуры 1С. Для обеспечения параллельной работы пользователей платформа использует механизм разделителей итогов. Это означает, что в базе SQL для одного счета и одного набора аналитики может существовать несколько строк в таблице итогов с разными значениями специального разделителя.
Когда мы вызываем код:
НаборЗаписей = РегистрыБухгалтерии.Хозрасчетный.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Установить(Объект.Ссылка);
НаборЗаписей.Прочитать();
НаборЗаписей.УстановитьАктивность(Истина);
НаборЗаписей.Записать();
Платформа может принять решение о «схлопывании» (агрегации) этих разделителей именно в момент записи набора. Если база давно не подвергалась процедуре реиндексации и сжатия, количество записей с разделителями может стать избыточным, что и приводит к радикальному замедлению.
Если работа в файловом варианте и в MS SQL показывает одинаковое замедление, это подтверждает проблему в структуре данных (как в случае с датами). Однако, если на SQL-сервере проблема выражена сильнее, проанализируем план запроса. Посмотрим на статистику: иногда SQL-сервер «запоминает» плохой план выполнения для запроса UPDATE.
Для сброса кэша планов (выполнять с осторожностью на рабочей базе) можно использовать команду:
DBCC FREEPROCCACHE
Также крайне полезно обновить статистику конкретно для таблиц регистра бухгалтерии. Рассмотрим пример команды для SQL Management Studio:
UPDATE STATISTICS _AccRg3456; -- где _AccRg3456 - имя таблицы вашего регистра
Подводя итог, если вы столкнулись с резким падением скорости активации движений, выполните следующие действия:
ПередЗаписью или ПриЗаписи регистра бухгалтерии).В большинстве случаев проблема кроется именно в раздутых таблицах итогов из-за некорректных данных, что заставляет SQL-сервер выполнять миллионы лишних операций обновления строк при каждой попытке изменить активность проводок документа.