Как очистить все старые планы запросов из Microsoft SQL Server?

12

У нас есть готовое приложение, которое использует базу данных Microsoft SQL. В этом приложении мы выбираем различные критерии выбора для каждого отчета. Это приложение затем запускает эти отчеты.

Я считаю, что у нас есть проблема с планом запроса. Первый отчет, который мы запускаем каждый день, работает очень быстро 7 минут. Любой отчет, который мы запускаем после первого, занимает более часа.

Каждую ночь мы запускаем запланированное задание, которое останавливает и запускает агент SQL Server и SQL Server. В этом одном экземпляре SQL Server есть примерно 25 других баз данных. Никакие другие базы данных не имеют проблем с производительностью, только та, которую я упоминал ранее.

Есть ли способ очистить все планы запросов, которые SQL Server в настоящее время имеет в памяти?

Как я могу сделать это, не влияя на 30 или около того пользователей, которые полагаются на другие базы данных на том же сервере?

Майкл Райли - AKA Gunny
источник
это может помочь dba.stackexchange.com/questions/623/full-plan-cache-behavior/…
CoderHawk

Ответы:

7

Мои извинения за мой предыдущий ответ.

1) Добавьте параметр WITH RECOMPILE в оператор CREATE PROCEDURE, если вы знаете, что ваш запрос будет меняться при каждом запуске из хранимой процедуры. Параметр WITH RECOMPILE предотвращает повторное использование плана выполнения хранимой процедуры, поэтому SQL Server не кэширует план для этой процедуры, и процедура перекомпилируется во время выполнения. Использование параметра WITH RECOMPILE может повысить производительность, если ваш запрос будет изменяться при каждом запуске из хранимой процедуры, поскольку в этом случае неверный план выполнения не будет использоваться.

2) Необходимо создать руководство плана, которое использует подсказку запроса USE PLAN для каждого типа запроса (каждого типа запроса хранимой процедуры) для принудительного выполнения плана выполнения.

Вот статья о плане выполнения, который может помочь.

Гарик
источник
Я согласен использовать WITH RECOMPILE, я сделал это с системами, которые я построил. Тем не менее, у меня нет доступа к источнику SQL ... он запускается из приложения.
Майкл Райли - AKA Gunny
@Cape Cod Gunny в этом случае попробуйте DBCC FLUSHPROCINDB: Используется для очистки кэша хранимых процедур для конкретной базы данных на SQL Server, а не для всего SQL Server. Возможно, вы захотите использовать эту команду перед тестированием, чтобы убедиться, что предыдущие планы хранимых процедур не окажут негативного влияния на результаты тестирования. Пример: DECLARE @intDBID Integer Установлено @intDBID = (SELECT DBID ОТ master.dbo.sysdatabases где имя = 'имя_базы_данных') DBCC FLUSHPROCINDB (@intDBID)
Гарик
проблема была решена. Оказалось, что временная таблица, используемая для хранения критериев поиска, постоянно накапливала данные. Предполагается, что процесс усекает данные из этой таблицы перед сбором данных. Спасибо за хороший фрагмент SQL.
Майкл Райли - AKA Gunny
13

Вы задали два вопроса здесь. Во-первых, вы хотите знать, можете ли вы удалить все планы, хранящиеся в памяти, для экземпляра SQL. Это делается с помощью DBCC FREEPROCCACHE, как предложил Мэтт М.

Второй вопрос, который вы задали: «Как я могу сделать это, не затрагивая около 30 пользователей, которые полагаются на другие базы данных на том же сервере?». Краткий ответ: «Вы не можете». Если вы удалите все планы, то другие пользователи, использующие планы, находящиеся в памяти, скорее всего, пострадают от снижения производительности.

Обходной путь для этого требует некоторого ручного вмешательства. Вы можете использовать DBCC FREEPROCCACHE, чтобы удалить конкретные планы, если у вас есть plan_handle.

Из того, что вы описываете выше, это звучит как вопрос о плане, но я не уверен, что удаление планов - это ответ. Я бы указал вам в направлении сниффинга параметров, прежде чем думать об удалении планов:

http://blogs.msdn.com/b/conor_cunningham_msft/archive/2010/08/11/conor-vs-misbehaving-parameterized-queries-optimize-for-hints.aspx

Вы должны быть в состоянии оптимизировать запросы, а не дурачиться с DBCC FREEPROCCACHE по расписанию. Я бы также посоветовал вам потратить время на анализ событий ожидания для вашего экземпляра.

SQLRockstar
источник
DBCC FREEPROCCACHE не решил проблему. Я контролирую деятельность и события. Есть 0 физических входов / выходов. Кажется, висит на этом приложении: .Net Sql Client Data Provider. Тип ожидания - CXPACKET.
Майкл Райли - AKA Gunny
CXPACKET подразумевает, что ваш запрос идет параллельно. Можете ли вы определить, сколько потоков запущено для запроса, и изучить их ожидания? Вы можете использовать бесплатный инструмент Адама Мачаника WhoIsActive sqlblog.com/files/folders/release/entry29675.aspx .
SQLRockstar
7

DBCC FREEPROCCACHE

С помощью этой команды вы можете очистить весь кеш процедур до одной команды. Обязательно прочтите документацию перед использованием этой команды. Прочтите раздел «Замечания» несколько раз.

Очистка кэша процедур приведет к перекомпиляции кэшей хранимых процедур при следующем использовании. Это может повлиять на производительность. Используйте осторожно!

Matt

Мэтт М
источник
Я попытался использовать DBCC FREEPROCCACHE, и это не решило проблему. Я закончил, убивая процесс через 1 час.
Майкл Райли - AKA Gunny