В работе системного администратора и разработчика 1С часто возникает ситуация, когда производительность системы внезапно падает без видимых причин. Документы, которые обычно проводятся за секунды, начинают «висеть» минутами, а нагрузка на сервер растет. Одним из инструментов оперативного реагирования в таких случаях является очистка процедурного кэша SQL Server. В этой статье мы подробно разберем, как работают команды FREEPROCCACHE и FLUSHPROCINDB, когда их стоит применять и почему это решение часто называют «атомной бомбой» для сервера.
Проанализируем сначала, что именно мы очищаем. SQL Server сохраняет планы выполнения запросов в специальной области памяти — процедурном кэше. Это делается для того, чтобы при повторном выполнении того же запроса сервер не тратил ресурсы на построение оптимального пути доступа к данным. Однако в среде 1С часто возникает проблема Parameter Sniffing. Это ситуация, когда SQL Server строит план выполнения на основе первого переданного параметра (например, выборка по пустой ссылке или по очень редкому значению), и этот план оказывается крайне неэффективным для всех последующих вызовов с другими параметрами.
Рассмотрим основные команды, которые используются для решения этой проблемы:
Выясним причину, почему системные администраторы часто прибегают к этой недокументированной команде. Как было отмечено в обсуждении, FLUSHPROCINDB требует идентификатор базы данных. Посмотрим на пример кода, который можно использовать в SQL Management Studio или в задании SQL Agent:
DECLARE @DBID INT;
SET @DBID = DB_ID('Имя_Вашей_Базы');
DBCC FLUSHPROCINDB(@DBID);
Важно помнить, что напрямую передать функцию DB_ID() в команду DBCC нельзя — синтаксис SQL Server этого не позволяет. Сначала необходимо получить идентификатор в переменную, как показано в примере выше.
Проанализируем ситуацию, когда очистка кэша становится частью регламента. В официальных рекомендациях 1С (на портале ИТС) указывается, что после обновления статистики (UPDATE STATISTICS) крайне желательно сбрасывать кэш планов. Почему это важно?
Если мы обновили статистику, SQL Server теперь знает актуальное распределение данных в таблицах. Однако в кэше могут оставаться старые планы, построенные на основе «кривой» статистики. Очистка кэша заставляет сервер перестроить планы, используя уже новые, точные данные.
Рассмотрим взаимосвязь с индексами:
Следовательно, если ваш ночной регламент включает только реорганизацию, вам обязательно нужно отдельно запускать обновление статистики и последующую очистку кэша.
Необходимо понимать, почему опытные администраторы баз данных предостерегают от частого использования этих команд. Представим ситуацию: в системе работают сотни пользователей, генерирующих тысячи запросов в секунду. В момент выполнения FREEPROCCACHE все эти запросы мгновенно лишаются готовых планов.
Проанализируем последствия:
RESOURCE_SEMAPHORE_QUERY_COMPILE), когда запросы выстраиваются в очередь просто для того, чтобы их «скомпилировали».Это и называется «компиляционным штормом». Вместо ускорения работы вы можете получить полную остановку системы на несколько минут.
Если вы используете современные версии SQL Server, у нас есть гораздо более элегантные способы управления кэшем. Рассмотрим их подробнее.
1. Очистка кэша на уровне базы (документированная)
Вместо использования недокументированной команды FLUSHPROCINDB, в SQL Server 2016 появилась официальная инструкция:
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;
Она безопасна, поддерживается Microsoft и делает именно то, что нам нужно — очищает кэш только текущей базы данных.
2. Использование Query Store
Это, пожалуй, самый мощный инструмент. Вместо того чтобы «бомбить» весь кэш, мы можем проанализировать Query Store, найти конкретный запрос, который деградировал из-за плохого плана, и «принудительно» (Force Plan) закрепить за ним хороший план. Это решает проблему точечно, не затрагивая остальные процессы.
3. Удаление конкретного плана
Если мы знаем plan_handle проблемного запроса, мы можем удалить из кэша только его:
DBCC FREEPROCCACHE (0x060006001ECA29044021AD05000000000000000000000000);
Это требует определенных навыков мониторинга, но является «тру-способом» администрирования.
Подводя итог, ответим на вопрос: стоит ли использовать очистку кэша регулярно?
Рассмотрим правильную стратегию:
FREEPROCCACHE в ежедневных заданиях оправдано только в ночное время, сразу после выполнения операций UPDATE STATISTICS.ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE (для новых версий SQL) или FLUSHPROCINDB (для старых), но только как экстренную меру.Parameter Sniffing.Таким образом, очистка кэша — это мощный, но опасный инструмент. Используйте его осознанно, понимая структуру своего регламентного обслуживания и версию используемого SQL-сервера.