Comment puis-je effacer le cache de requêtes SQL Server?

J'ai une requête simple en cours d'exécution contre SQL Server 2005

SELECT * 
FROM Table 
WHERE Col = 'someval'

La première fois que j'exécute la requête peut prendre > 15 secs . Les exécutions suivantes sont de retour < 1 sec.

Comment puis-je faire en sorte que SQL Server 2005 n'utilise aucun résultat mis en cache? J'ai essayé de courir

DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE

Mais cela semble n'avoir aucun effet sur la vitesse de requête (encore < 1 sec).

Voici une bonne explication. Découvrez-le.

http://www.mssqltips.com/tip.asp?tip=1360

CHECKPOINT; 
GO 
DBCC DROPCLEANBUFFERS; 
GO

De l'article lié:

Si tous les tests de performances sont effectués dans SQL Server, la meilleure approche peut être d'émettre un CHECKPOINT, puis d'émettre la commande DBCC DROPCLEANBUFFERS. Bien que le processus CHECKPOINT soit un processus système interne automatique dans SQL Server et se produise régulièrement, il est important d'émettre cette commande pour écrire toutes les pages sales de la base de données en cours sur le disque et nettoyer les tampons. Ensuite, la commande DBCC DROPCLEANBUFFERS peut être exécutée pour supprimer tous les tampons du pool de tampons.

Huit façons différentes de vider le cache du plan

1. Supprimez tous les éléments du cache de plan pour l'instance entière

DBCC FREEPROCCACHE;

Utilisez-le pour vider soigneusement le cache du plan. La libération du cache de plan entraîne par exemple la recompilation d'une procédure stockée au lieu de sa réutilisation à partir du cache. Cela peut entraîner une baisse soudaine et temporaire des performances des requêtes.

2. Videz le cache du plan pour l'instance entière et supprimez le message d'achèvement normal

"L'exécution de DBCC est terminée. Si DBCC a imprimé des messages d'erreur, contactez votre administrateur système."

DBCC FREEPROCCACHE WITH NO_INFOMSGS;

3. Vider le cache de plan ad hoc et préparé pour l'instance entière

DBCC FREESYSTEMCACHE ('SQL Plans');

4. Vider le cache de plan ad hoc et préparé pour un pool de ressources

DBCC FREESYSTEMCACHE ('SQL Plans', 'LimitedIOPool');

5. Vider l'intégralité du cache du plan pour un pool de ressources

DBCC FREEPROCCACHE ('LimitedIOPool');

6. Supprimez tous les éléments du cache de plan pour une base de données (ne fonctionne pas dans SQL Azure)

-- 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. Vider le cache du plan pour la base de données actuelle

USE AdventureWorks2014;
GO
-- New in SQL Server 2016 and SQL Azure
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

8. Supprimez un plan de requête du cache

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);
 

Source 1 2 3

Bien que la question soit un peu ancienne, cela pourrait encore aider. Je rencontre des problèmes similaires et l'utilisation de l'option ci-dessous m'a aidé. Je ne sais pas si c'est une solution permanente, mais c'est en train de la réparer pour le moment.

OPTION (OPTIMIZE FOR UNKNOWN)

Ensuite, votre requête sera comme ça

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

La valeur que vous spécifiez pour la mémoire du serveur n'a pas d'importance, tant qu'elle diffère de la valeur actuelle.

Btw, la chose qui provoque l'accélération n'est pas le cache de requêtes, mais le cache de données.

Notez que ni DBCC DROPCLEANBUFFERS;ni DBCC FREEPROCCACHE;n'est pris en charge dans SQL Azure / SQL Data Warehouse.

Cependant, si vous devez réinitialiser le cache du plan dans SQL Azure, vous pouvez modifier l'une des tables de la requête (par exemple, ajoutez simplement puis supprimez une colonne), cela aura pour effet secondaire de supprimer le plan du cache .

Personnellement, je fais cela pour tester les performances des requêtes sans avoir à gérer les plans mis en cache.

Plus de détails sur le cache de procédures SQL Azure ici