Auto Update Statistics Asynchronously в 1С: для чего нужно и как настроить

При работе 1С на платформе клиент-сервер с СУБД Microsoft SQL Server производительность запросов напрямую зависит от актуальности статистики — служебных данных, по которым оптимизатор строит планы выполнения запросов. Параметр Auto Update Statistics Asynchronously (AUTO_UPDATE_STATISTICS_ASYNC) определяет, как именно сервер обновляет эту статистику: блокируя текущий запрос или делая это в фоновом режиме. Для крупных баз 1С с интенсивной записью правильная настройка этого параметра способна заметно снизить количество «подвисаний» у пользователей.

По умолчанию в SQL Server статистика обновляется синхронно: когда оптимизатор обнаруживает, что статистика устарела, текущий запрос останавливается и ждёт, пока обновление завершится. На больших таблицах документов и регистров это ожидание может занимать секунды и даже десятки секунд, а пользователь в этот момент видит зависшую форму. Асинхронный режим меняет логику: запрос выполняется со старой статистикой, а обновление запускается параллельно в фоне.

Настройка относится к уровню базы данных в SQL Server и применяется администратором СУБД, а не внутри конфигуратора 1С. В статье разберём, как работает механизм, кому подходит асинхронный режим, как его включить и проверить результат, а также какие ограничения и риски нужно учитывать.

Что такое статистика и зачем она нужна в 1С

Статистика в SQL Server — это объект, содержащий сведения о распределении значений в колонках таблиц и индексов: сколько строк, как часто встречаются те или иные значения, какова плотность данных. На основе этих сведений оптимизатор запросов решает, какой план выполнения выбрать: сканирование таблицы, поиск по индексу, порядок соединений таблиц.

В базах 1С таблицы документов, регистров накопления и сведений постоянно меняются: проводятся документы, пишутся движения, удаляются помеченные объекты. Из-за этого статистика быстро устаревает, и оптимизатор может начать строить неоптимальные планы — отсюда резкие замедления отчётов и проведения документов, которые «ещё вчера работали быстро».

SQL Server отслеживает объём изменений и при превышении порога помечает статистику как устаревшую. Дальше срабатывает механизм автообновления — и именно режим его работы (синхронный или асинхронный) определяет, почувствуют ли это пользователи.

Как работает синхронное и асинхронное обновление

При синхронном режиме (настройка по умолчанию) последовательность такая: запрос приходит на сервер, оптимизатор видит устаревшую статистику, приостанавливает компиляцию, обновляет статистику, строит новый план и только потом выполняет запрос. Обновление статистики по большой таблице регистра — это чтение значительной части данных, и на это уходит заметное время.

При асинхронном режиме запрос не ждёт: он компилируется и выполняется с имеющейся (устаревшей) статистикой, а отдельный фоновый поток запускает обновление. Следующие запросы уже получат свежую статистику. Пользователь не наблюдает паузы, связанной с обслуживанием статистики.

Цена вопроса — один запрос может выполниться по неидеальному плану, построенному на старых данных. На практике для типовых операций 1С это почти всегда приемлемый компромисс по сравнению с гарантированной блокировкой при синхронном обновлении.

Когда асинхронный режим даёт эффект в 1С

Асинхронное обновление статистики оправдано не всегда. Его включение имеет смысл при совпадении нескольких условий: база большая (сотни гигабайт и более), таблицы регистров и документов содержат миллионы строк, в течение дня идёт интенсивная запись, и пользователи жалуются на периодические «фризы» без явной причины.

Характерный симптом — запросы, которые обычно выполняются быстро, время от времени «зависают» на несколько секунд или минут без блокировок со стороны других сеансов. Если в мониторе активности SQL Server в такие моменты видно операции обновления статистики (например, ожидания, связанные с компиляцией), это прямое указание на проблему синхронного режима.

Для небольших баз с десятками пользователей и умеренным объёмом данных синхронное обновление обычно происходит настолько быстро, что переключение режима не даст видимого эффекта. В этом случае важнее следить за регламентным обслуживанием: перестроением индексов и полным обновлением статистики по расписанию.

Как включить асинхронное обновление статистики

Настройка выполняется на уровне конкретной базы данных в SQL Server. Сделать это можно двумя способами: через графический интерфейс SQL Server Management Studio (SSMS) или запросом T-SQL. Оба варианта равнозначны.

В SSMS: откройте свойства базы данных, перейдите на вкладку «Параметры» (Options), найдите в группе «Автоматически» (Automatic) пункт «Асинхронное автоматическое обновление статистики» (Auto Update Statistics Asynchronously) и установите значение True. Убедитесь, что параметр «Автоматически обновлять статистику» (Auto Update Statistics) также включён — асинхронный режим работает только вместе с ним.

Через T-SQL настройка выполняется одной командой, которую удобно включить в скрипт регламентного обслуживания или чек-лист развёртывания новой базы:

ALTER DATABASE [ИмяБазы1С] SET AUTO_UPDATE_STATISTICS_ASYNC ON;
ALTER DATABASE [ИмяБазы1С] SET AUTO_UPDATE_STATISTICS ON;

1. 1
   Сделайте резервную копию базы или убедитесь, что актуальная копия существует
2. 2
   Проверьте текущее состояние параметров: SELECT name, is_auto_update_stats_on, is_auto_update_stats_async_on FROM sys.databases
3. 3
   Включите AUTO_UPDATE_STATISTICS и AUTO_UPDATE_STATISTICS_ASYNC для базы 1С
4. 4
   Убедитесь, что настроено регламентное полное обновление статистики в нерабочее время
5. 5
   Наблюдайте за производительностью несколько дней: фиксируйте жалобы на паузы и длительность типовых операций

Изменение параметра вступает в силу сразу, перезапуск сервера или базы не требуется. Тем не менее выполнять настройку лучше в период минимальной нагрузки — это общее правило для любых изменений на продуктивном сервере.

Как проверить результат и состояние статистики

Проверить, что параметр включён, можно запросом к системному представлению sys.databases: колонки is_auto_update_stats_on и is_auto_update_stats_async_on должны содержать значение 1 для нужной базы. Это быстрый способ убедиться, что настройка применилась.

Актуальность статистики по конкретным таблицам оценивается через функцию sys.dm_db_stats_properties или команду DBCC SHOW_STATISTICS: смотрите дату последнего обновления и число изменённых строк с момента обновления. Если по ключевым таблицам регистров статистика не обновлялась неделями при активной работе — автообновление не справляется, и нужно усилить регламентное обслуживание.

Косвенный признак эффекта от асинхронного режима — исчезновение характерных «ступенек» производительности: ситуаций, когда первый запрос после массовой записи выполнялся аномально долго, а последующие — нормально. Фиксируйте время выполнения типовых операций (проведение документа, формирование ключевого отчёта) до и после изменения настройки, чтобы оценка была предметной.

Ограничения, риски и типичные ошибки

Асинхронное обновление статистики — не универсальное средство от всех проблем производительности. Оно устраняет конкретную причину пауз: ожидание обновления статистики при компиляции запроса. Если медленная работа вызвана блокировками, нехваткой памяти, медленными дисками или неоптимальными запросами в конфигурации, настройка не поможет.

Важно понимать ограничение: фоновое обновление всё равно потребляет ресурсы сервера — процессор и дисковую подсистему. На перегруженном сервере фоновые операции могут конкурировать за ресурсы с пользовательскими запросами. Поэтому асинхронный режим не отменяет необходимости регламентного обновления статистики в нерабочее время с полным сканированием (FULLSCAN) для ключевых таблиц.

Отдельная ошибка — отключать автообновление статистики полностью, рассчитывая только на ручное регламентное обслуживание. При интенсивной дневной записи статистика устаревает за часы, и до ночного обслуживания оптимизатор работает с неадекватными данными. Автообновление и регламентное обслуживание должны дополнять друг друга.

Альтернативы и дополнительные меры

Помимо асинхронного режима, администратору баз 1С стоит держать в арсенале связанные практики. Первая — регулярное обновление статистики по расписанию через задание SQL Server Agent с командой UPDATE STATISTICS или sp_updatestats, для критичных таблиц — с параметром FULLSCAN. Вторая — обслуживание индексов: перестроение или реорганизация по мере фрагментации, что также влияет на качество планов.

Третья мера — мониторинг: технологический журнал 1С с настройкой событий длительных запросов, счётчики производительности SQL Server, динамические административные представления (sys.dm_exec_query_stats, sys.dm_os_wait_stats). Только по данным мониторинга можно отличить проблему статистики от проблемы блокировок или ресурсов.

В некоторых случаях для конкретных «проблемных» запросов эффективнее точечные меры: пересмотр индексов по регистрам, изменение запросов в конфигурации, использование подсказок оптимизатору. Это работа уже на стыке администрирования и разработки, и её стоит выполнять после того, как базовые настройки обслуживания приведены в порядок.

Частые вопросы