web-dev-qa-db-fra.com

Comment puis-je effacer le cache de requête 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 dans < 1 sec.

Comment 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 la requête (toujours < 1 sec).

sql-servercaching
187
PaulB

Voici une bonne explication. regarde ça.

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

CHECKPOINT; 
GO 
DBCC DROPCLEANBUFFERS; 
GO

De l'article lié:

Si tous les tests de performances sont effectués dans SQL Server, la meilleure approche consiste peut-être à émettre un CHECKPOINT, puis à émettre la commande DBCC DROPCLEANBUFFERS. Bien que le processus CHECKPOINT soit un processus système interne automatique dans SQL Server et qu'il se produise régulièrement, il est important de lancer cette commande pour écrire toutes les pages modifiées de la base de données actuelle 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.

245
Saar

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

1. Supprimez tous les éléments du cache de plan pour toute l'instance.

DBCC FREEPROCCACHE;

Utilisez cette option pour vider le cache de plan avec précaution. La libération du cache de plan entraîne, par exemple, la recompilation d’une procédure stockée au lieu de son utilisation ultérieure à partir du cache. Cela peut entraîner une baisse soudaine et temporaire des performances de la requête.

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

"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. Videz le cache de plan ad hoc et préparé pour l'instance entière

DBCC FREESYSTEMCACHE ('SQL Plans');

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

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

5. Vider le cache de plan complet 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. Effacer le cache de 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. Supprimer 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 12

9
Somnath Muluk

Bien que la question soit un peu ancienne, cela pourrait quand même 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)
9
Tony Basallo
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'est pas importante, 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ête, mais le cache de données.

6
erikkallen

Notez que ni DBCC DROPCLEANBUFFERS; ni DBCC FREEPROCCACHE; ne sont pris en charge dans SQL Azure/SQL Data Warehouse.

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

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

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

3
MSC