Auto Update Statistics Asynchronously для базы 1С на MS SQL

Асинхронное обновление статистики — это параметр базы MS SQL Server AUTO_UPDATE_STATISTICS_ASYNC. Для базы 1С его обычно включают: запрос пользователя больше не ждёт, пока сервер пересчитает устаревшую статистику, а выполняется сразу по старой, пересчёт идёт в фоне. Включается одной командой ALTER DATABASE … SET AUTO_UPDATE_STATISTICS_ASYNC ON или галочкой в свойствах базы в SSMS.

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

Как SQL Server решает, когда обновить статистику

Статистика — это гистограмма распределения значений в колонках таблицы. По ней оптимизатор SQL Server оценивает, сколько строк вернёт условие, и выбирает план: поиск по индексу, просмотр таблицы, тип соединения. База 1С на SQL — это тысячи таблиц _Document…, _AccumRg…, _InfoRg…, и у каждого индекса своя статистика.

Статистика стареет по мере изменения данных. Сервер считает изменённые строки и, когда счётчик перевалит порог, помечает статистику как устаревшую:

• 📊 при уровне совместимости базы ниже 130 — после изменения 20% строк плюс 500;
• 📈 при уровне совместимости 130 и выше (SQL Server 2016 и новее) — по динамическому порогу: для больших таблиц он заметно меньше 20%, примерно квадратный корень из 1000 × число строк.

Пример: регистр накопления на 10 млн строк. По старому правилу пересчёт случится после 2 000 500 изменений. По новому — примерно после 100 000. Разница в 20 раз.

Синхронный и асинхронный режим

Сам пересчёт запускается не по таймеру, а в момент, когда очередной запрос обращается к устаревшей статистике. Дальше всё зависит от режима:

Асинхронный режим работает, только если включено и само автообновление (AUTO_UPDATE_STATISTICS ON). Без него параметр ничего не делает.

Что меняется в производительности базы 1С

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

С асинхронным режимом такой паузы нет. Что вы получаете:

• ⚡ ровное время ответа на типовых операциях — без редких «провалов» на 10–30 секунд;
• 🔒 меньше риска таймаутов блокировок: транзакция проведения не висит, пока идёт пересчёт статистики;
• 🧵 пересчёт идёт фоновым потоком, его видно в sys.dm_exec_background_job_queue.

И чем за это платите:

• 🐢 запрос, запустивший пересчёт, и несколько следующих идут по старому плану; если данные сильно изменились, этот план может быть плохим;
• 🔁 после фонового обновления планы, зависящие от статистики, перекомпилируются — короткий всплеск нагрузки на процессор.

Для типичной учётной базы, где данные меняются постепенно в течение дня, баланс почти всегда в пользу асинхронного режима. Старая статистика на 5–10% отличается от свежей, план от этого обычно не меняется.

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

Перед изменением посмотрите текущее состояние. Запрос выполняется в SSMS под учётной записью с правом на чтение sys.databases:

SELECT name,
       compatibility_level,
       is_auto_create_stats_on,
       is_auto_update_stats_on,
       is_auto_update_stats_async_on
FROM sys.databases
WHERE name = N'buh_base';

Вместо buh_base подставьте имя базы SQL, которое указано в свойствах информационной базы в консоли кластера 1С.

Через свойства базы в SSMS

1. В обозревателе объектов откройте Базы данных, щёлкните правой кнопкой по базе 1С → Свойства.
2. Перейдите на страницу Параметры (в английской версии — Options).
3. В группе «Автоматически» найдите «Автоматическое обновление статистики» — должно быть True.
4. Строкой ниже — «Асинхронное автоматическое обновление статистики» (Auto Update Statistics Asynchronously). Поставьте True.
5. Нажмите ОК.

Через T-SQL

ALTER DATABASE [buh_base] SET AUTO_CREATE_STATISTICS ON;
ALTER DATABASE [buh_base] SET AUTO_UPDATE_STATISTICS ON;
ALTER DATABASE [buh_base] SET AUTO_UPDATE_STATISTICS_ASYNC ON;

Параметр применяется сразу, перезапускать службу SQL Server или сервер 1С не нужно. Пользователей выгонять тоже не надо.

Временные таблицы 1С

Платформа активно пользуется временными таблицами (#tt…) — в запросах с ПОМЕСТИТЬ, при проведении, в отчётах СКД. Они живут в tempdb, и автоматическая статистика по ним подчиняется параметрам tempdb, а не вашей базы. Если хотите единого поведения, проверьте те же три флага у tempdb.

Обновление статистики по расписанию

Автообновление по порогу — страховка. Основная работа делается заданием обслуживания в SQL Server Agent. В регламентных заданиях 1С (обмены, загрузка курсов, обновление агрегатов) такой операции нет, и встроенными средствами платформы статистику SQL не обновить.

Что включить в задание

• 🗓 Ежедневно, ночью — обновление статистики. Простой вариант — системная процедура sp_updatestats: она пересчитывает только ту статистику, где были изменения.
• 📅 Раз в неделю — перестроение или реорганизация фрагментированных индексов. После перестроения индекса его статистика пересчитывается полной выборкой, повторно обновлять её не нужно.
• 🧹 После обновления — по желанию очистка кэша планов DBCC FREEPROCCACHE. Многие администраторы 1С ставят её последним шагом, чтобы все запросы гарантированно перекомпилировались.

Минимальный шаг задания:

USE [buh_base];
EXEC sp_updatestats;

Для самых больших таблиц (регистры остатков, проводки, движения товаров) можно точечно сделать полный пересчёт:

UPDATE STATISTICS dbo._AccumRg1234 WITH FULLSCAN;

Имя таблицы подставьте своё. Соответствие имён метаданным 1С показывает метод ПолучитьСтруктуруХраненияБазыДанных() — его можно вызвать из внешней обработки.

В мастере планов обслуживания SSMS то же самое собирается из готовых задач «Обновить статистику» и «Перестроить индекс». Нужен только выбор базы и расписание.

Файловая база, MS SQL и PostgreSQL

Настройка существует не везде. Вот как обстоит дело по типам баз:

Для PostgreSQL порог автоматического ANALYZE задают параметры autovacuum_analyze_scale_factor (по умолчанию 0.1, то есть 10% строк) и autovacuum_analyze_threshold (по умолчанию 50 строк). Для больших таблиц 1С 10% — много, поэтому scale factor часто уменьшают.

Тестирование файловой базы требует монопольного доступа: пользователи должны выйти. Делайте его в нерабочее время и после свежей копии.

Как понять, что тормоза из-за статистики

Журнал регистрации 1С здесь мало помогает. Он показывает, кто и что сделал в базе, но не время SQL-запросов и не их планы. Нужны другие инструменты.

Признаки проблемы со статистикой

• ⏳ одна и та же операция то выполняется за секунду, то за минуту без видимой причины;
• 🌅 утром после ночной загрузки или обмена отчёты медленнее обычного, к обеду проходит;
• 🔄 после массовой операции (перепроведение, закрытие месяца , свёртка) отчёт по регистру резко замедлился.

Чем смотреть

1. Технологический журнал 1С. Настройте logcfg.xml на события DBMSSQL с отбором по длительности — увидите текст медленного запроса и время. Если тот же запрос в другое время идёт быстро, это повод проверить статистику.
2. Возраст статистики в SQL Server. Запрос ниже показывает, когда статистика по таблице обновлялась и сколько строк изменено с тех пор:

SELECT OBJECT_NAME(s.object_id) AS table_name,
       s.name AS stats_name,
       sp.last_updated,
       sp.rows,
       sp.modification_counter
FROM sys.stats s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE OBJECT_NAME(s.object_id) LIKE N'_AccumRg%'
ORDER BY sp.modification_counter DESC;

3. Расширенные события (Extended Events). Событие auto_stats фиксирует каждый автоматический пересчёт: какая статистика, сколько длился, синхронно или асинхронно. Полезно, чтобы найти «тяжёлые» пересчёты в рабочее время.
4. Фоновая очередь. SELECT * FROM sys.dm_exec_background_job_queue; показывает асинхронные задания пересчёта, которые ждут или выполняются прямо сейчас.

Когда асинхронный режим лучше выключить

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

Массовая загрузка с немедленным чтением. Если обработка заливает в пустую или почти пустую таблицу сотни тысяч строк и сразу её читает, первый запрос пойдёт по статистике «таблица пустая». Получится план под 10 строк на 500 000 — например, вложенные циклы вместо хеш-соединения. Решение без отключения режима: после загрузки явно вызвать UPDATE STATISTICS по этой таблице.

Перевод базы в однопользовательский режим. При включённом асинхронном режиме фоновый поток пересчёта занимает собственное соединение с базой. Из-за этого перевод в SINGLE_USER перед восстановлением или обслуживанием может не пройти. Перед такими работами выключите параметр, а потом верните:

ALTER DATABASE [buh_base] SET AUTO_UPDATE_STATISTICS_ASYNC OFF;
-- работы в однопользовательском режиме
ALTER DATABASE [buh_base] SET AUTO_UPDATE_STATISTICS_ASYNC ON;

Исключить отдельную таблицу

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

EXEC sp_autostats 'dbo._AccumRg1234', 'OFF';

Посмотреть текущее состояние по таблице — та же процедура без второго параметра. Вернуть — 'ON'. Аналогичный эффект даёт UPDATE STATISTICS … WITH NORECOMPUTE, но про такие таблицы легко забыть. Ведите их список: таблица с выключенным автообновлением и без ручного задания со временем станет главным источником тормозов.

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