Вопрос обслуживания больших баз данных 1С на платформе MS SQL Server — один из ключевых для обеспечения стабильной и быстрой работы системы. Одной из важнейших процедур является обновление статистики. Давайте разберемся, нужно ли настраивать ежедневное обновление, как работают встроенные механизмы SQL и какую стратегию обслуживания выбрать для высоконагруженной системы, используя инструкции по настройке регламентных операций.
Прежде чем перейти к стратегиям, давайте кратко вспомним, что такое статистика в MS SQL. Статистика — это набор данных, который описывает распределение значений в одном или нескольких столбцах таблицы. Оптимизатор запросов SQL Server использует эту информацию, чтобы строить наиболее эффективные планы выполнения запросов. Если статистика устарела или неточна, оптимизатор может выбрать неоптимальный план, что приведет к значительному замедлению выполнения запросов. Для детального мониторинга таких проблем полезно проводить анализ SQL сервера глазами 1С-ника, чтобы вовремя заметить деградацию производительности.
В свойствах любой базы данных MS SQL по умолчанию включена опция "Автоматическое обновление статистики" (Auto Update Statistics). Это основной механизм, который следит за актуальностью данных для оптимизатора. Разберем его работу подробнее.
Принцип работы:
INSERT, UPDATE, DELETE).Важно понимать, что этот порог менялся с версиями SQL Server:
Синхронный и асинхронный режимы:
По умолчанию автообновление работает в синхронном режиме. Это значит, что если запрос пользователя "наткнулся" на устаревшую статистику, его выполнение будет приостановлено до тех пор, пока статистика не обновится. На большой таблице это может вызвать заметные "зависания" у пользователя. Чтобы избежать этого, можно включить асинхронный режим (Auto Update Statistics Asynchronously). В этом случае запрос выполнится со старым планом, а обновление статистики запустится в фоновом режиме. Следующие запросы уже смогут использовать новые данные. Это позволяет избежать простоев, но создает риск, что некоторые запросы кратковременно будут работать по неоптимальному плану.
Несмотря на улучшения, полагаться только на автоматическое обновление в больших и активно используемых базах 1С — не лучшая идея. Вот основные причины, почему необходимо настраивать собственное регламентное обслуживание:
Ежедневно обновлять статистику для всех таблиц подряд в базе размером в несколько терабайт — это избыточно и долго. Чтобы правильно расставить приоритеты, предварительно рекомендуется провести анализ размера таблиц базы данных, так как эта операция сама по себе может занимать почти сутки. Поэтому нужен более гибкий и продуманный подход.
Основное преимущество ручного запуска — возможность использовать опция WITH FULLSCAN. В этом режиме SQL Server сканирует все строки таблицы для сбора статистики, что обеспечивает максимальную точность. Это "золотой стандарт" для ключевых таблиц.
Простой скрипт для обновления статистики по всей базе с полным сканированием выглядит так:
EXEC sp_updatestats @resample = 'RESAMPLE';
Однако, как мы уже выяснили, для больших баз это может быть слишком долго. Поэтому перейдем к более умным стратегиям.
Это наиболее эффективная стратегия для крупных систем. Суть в том, чтобы разделить таблицы по частоте изменений и критичности, и настроить для них разное расписание обслуживания.
Шаги для реализации:
WITH FULLSCAN в ночное время.Совет: Вместо стандартного мастера планов обслуживания (Maintenance Plans) лучше использовать T-SQL скрипты. Скрипты предоставляют гораздо больше гибкости: можно использовать доработанное решение MaintenanceSolution от Ola Hallengren или внедрить скрипт адаптивного обновления индексов, который будет выбирать только те объекты, которые действительно нуждаются в обслуживании.
Чтобы стратегия обслуживания была полной, нужно учитывать еще несколько моментов.
Связь с реиндексацией:
ALTER INDEX ... REBUILD) автоматически обновляет связанную с ними статистику, причем с эквивалентом FULLSCAN. Если у вас настроена регулярная полная реиндексация, то запускать сразу после нее обновление статистики для тех же таблиц не нужно — это лишняя работа. Для ускорения процесса на гигантских таблицах можно использовать переиндексацию в несколько потоков.ALTER INDEX ... REORGANIZE) статистику не обновляет. После нее обновление статистики будет полезно.Очистка кэша планов запросов:
После массового обновления статистики крайне рекомендуется очистить кэш планов запросов. Иначе SQL Server может продолжать использовать старые, неэффективные планы, построенные на основе устаревшей статистики. Для этого используется команда:
DBCC FREEPROCCACHE;
Внимание! Эта команда удаляет все планы из кэша, и следующим запросам потребуется время на компиляцию. Выполняйте ее в период минимальной нагрузки, сразу после завершения обслуживания.
Проанализировав ситуацию, можно сформулировать оптимальную стратегию обслуживания статистики для больших баз 1С:
Auto Update Statistics оставляем включенной. Для высоконагруженных систем можно рассмотреть асинхронный режим.WITH FULLSCAN для самых критичных и динамичных таблиц (большие регистры).DBCC FREEPROCCACHE.Такой гибридный подход позволяет, с одной стороны, поддерживать статистику в актуальном состоянии для быстро меняющихся данных, а с другой — не тратить лишние ресурсы сервера на обслуживание статичных таблиц и укладываться в технологическое "окно".