Как очистить кэш запросов SQL Server?
у меня есть простой запрос, работающий против SQL Server 2005
SELECT *
FROM Table
WHERE Col = 'someval'
первый раз, когда я выполняю запрос может занять > 15 secs. Последующие выполнения возвращаются в < 1 sec.
как я могу заставить SQL Server 2005 не использовать кэшированные результаты? Я пробовал запустить
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
но это, кажется, не влияет на скорость запроса (все еще < 1 sec).
5 ответов:
вот некоторые хорошие объяснения. проверьте это.
http://www.mssqltips.com/tip.asp?tip=1360
CHECKPOINT; GO DBCC DROPCLEANBUFFERS; GOиз связанной статьи:
Если все тестирование производительности проводится в SQL Server, лучшим подходом может быть выдача контрольной точки, а затем выдача команды DBCC DROPCLEANBUFFERS. Хотя процесс контрольной точки является автоматическим внутренним системным процессом в SQL Server и происходит на регулярной основе, это важно выполнить эту команду, чтобы записать все грязные страницы для текущей базы данных на диск и очистить буферы. Затем команда DBCC DROPCLEANBUFFERS может быть выполнена для удаления всех буферов из буферного пула.
хотя вопрос немного устарел, это все еще может помочь. Я сталкиваюсь с подобными проблемами и использование опции ниже помогло мне. Не уверен, что это постоянное решение, но сейчас оно исправляет его.
OPTION (OPTIMIZE FOR UNKNOWN)тогда ваш запрос будет выглядеть так
select * from Table where Col = 'someval' OPTION (OPTIMIZE FOR UNKNOWN)
EXEC sys.sp_configure N'max server memory (MB)', N'2147483646' GO RECONFIGURE WITH OVERRIDE GOкакое значение вы укажете для памяти сервера не важно, пока оно отличается от текущего.
кстати, то, что вызывает ускорение, - это не кэш запросов, а кэш данных.
восемь различных способов очистить кэш плана
1. Удаляет все элементы из кэша планов для всего экземпляра
DBCC FREEPROCCACHE;используйте это, чтобы очистить кэш плана тщательно. Освобождение кэша планов приводит, например, к повторной компиляции хранимой процедуры вместо повторного использования из кэша. Это может привести к внезапному временному снижению производительности запросов.
2. Очистите кэш планов для всего экземпляра и подавите регулярное завершение сообщение
"выполнение DBCC завершено. Если инструкция DBCC выдает сообщения об ошибках, обратитесь к системному администратору."
DBCC FREEPROCCACHE WITH NO_INFOMSGS;3. Очистите специальный и подготовленный кэш планов для всего экземпляра
DBCC FREESYSTEMCACHE ('SQL Plans');4. Очистите специальный и подготовленный кэш планов для одного пула ресурсов
DBCC FREESYSTEMCACHE ('SQL Plans', 'LimitedIOPool');5. Очистите весь кэш планов для одного пула ресурсов
DBCC FREEPROCCACHE ('LimitedIOPool');6. Удаляет все элементы из кэша планов для одной базы данных (не работает в SQL Лазурный)
-- Get DBID from one database name first DECLARE @intDBID INT; SET @intDBID = (SELECT [dbid] FROM master.dbo.sysdatabases WHERE name = N'AdventureWorks2014'); DBCC FLUSHPROCINDB (@intDBID);7. Очистить кэш плана для текущей базы данных
USE AdventureWorks2014; GO -- New in SQL Server 2016 and SQL Azure ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;8. Удалите один план запроса из кэша
USE AdventureWorks2014; GO -- Run a stored procedure or query EXEC dbo.uspGetEmployeeManagers 9; -- Find the plan handle for that query -- OPTION (RECOMPILE) keeps this query from going into the plan cache SELECT cp.plan_handle, cp.objtype, cp.usecounts, DB_NAME(st.dbid) AS [DatabaseName] FROM sys.dm_exec_cached_plans AS cp CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st WHERE OBJECT_NAME (st.objectid) LIKE N'%uspGetEmployeeManagers%' OPTION (RECOMPILE); -- Remove the specific query plan from the cache using the plan handle from the above query DBCC FREEPROCCACHE (0x050011007A2CC30E204991F30200000001000000000000000000000000000000000000000000000000000000);
обратите внимание, что ни
DBCC DROPCLEANBUFFERS;, ниDBCC FREEPROCCACHE;поддерживается в хранилище данных SQL Azure / SQL.однако, если вам нужно сбросить кэш планов в SQL Azure, вы можете изменить одну из таблиц в запросе (например, просто добавить потом удалить столбец), это будет иметь побочный эффект удаления плана из кэша.
Я лично делаю это как способ тестирования производительности запросов без необходимости иметь дело с кэшированных планов.
Comments