att vara DAG 12 i DBCC-kommandomånaden vid SteveStedman.com, dagens presenterade DBCC-kommando är DBCC FREEPROCCACHE.
beskrivning:
DBCC FREEPROCCACHE används för att rensa alla tolkade frågeplaner ur minnet. Detta används ofta i utvecklingsmiljöer, men inte lika vanligt i en produktionsmiljö.
användning i en utvecklingsmiljö är vanligt, till exempel när du arbetar med prestandajustering eller parametrisering av frågor. Du kan rensa procedurcachen med DBCC FreeProcCache, köra programmet eller webbsidan som kan använda databasen och se vad som finns i procedurcachen. Detta kan vara användbart för att hitta frågor som kan behöva parametriseras. Ett annat sätt att använda skulle vara att ta reda på vilka frågor som körs av något program. För att göra detta skulle du börja med att arbeta med en databas som inte används av andra, rensa procedurcachen med DBCC FreeProcCache, kör sedan programmet du försöker lista ut, titta sedan på vad som finns i cachen, igen är det något som kan göras i en utvecklings-eller testmiljö, men jag skulle inte rekommendera att göra det i produktion.
användning i en produktionsmiljö bör vara sällsynt, det här är en av de vanliga sakerna att försöka när SQL Server har svårt. Om du är är poängen att SQL Server är extremt långsam att svara och du inte har kunnat hitta orsaken, är en sak att försöka frigöra procedurcachen med DBCC FreeProcCache och se om det löser problemet.
DBCC FreeProcCache Syntax:
dbcc freeproccache
exempel:
följande exempel kommer från en utvecklingsmiljö med hjälp av databasen AdventureWorks2012.
först ansluter vi till AdventureWorks2012 och ser vad som finns i cachen.
USE AdventureWorks2012;GOSELECT size_in_bytes, text FROM sys.dm_exec_cached_plans CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st;
här ser vi att det finns gott om i cachen. Därefter rensar vi cachen med DBCC FreeProcCache och tittar på vad som finns i cachen.
DBCC FREEPROCCACHE;SELECT size_in_bytes, text FROM sys.dm_exec_cached_plans CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st;
efter att ha kört DBCC FreeProcCache kan du se att det inte finns något kvar i cachen.
när nästa fråga körs måste den repareras snarare än att använda en redan analyserad fråga i cachen. Detta kommer att ta lite längre tid än om det redan fanns en analyserad plan att köra. Låt oss köra 3 frågor, ta en titt på cachen.
GOSELECT FirstName, MiddleName, LastName FROM person.Person p WHERE FirstName like 'John';GOSELECT FirstName, MiddleName, LastName FROM person.Person p WHERE FirstName like 'Mary';GOSELECT FirstName, MiddleName, LastName FROM person.Person p WHERE FirstName like 'Bill';
Lägg märke till Go-satsen mellan varje fråga. Detta berättar SSMS att köra varje fråga som en separat sats. Utan GO-uttalandet skulle de 3 frågorna ha analyserats som en enda sats.
här ser vi resultaten från de tre frågorna. De två första returnerade resultaten, och den tredje hade inga rader i resultatuppsättningen. Låt oss nu titta på cachen
SELECT size_in_bytes, text FROM sys.dm_exec_cached_plans CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st;
nedan ser vi totalt 20 objekt i cachen nu. det översta objektet markerat i blått är frågan vi använde för att se vad som fanns i cachen, det andra blocket markerat i rött innehåller de 3 frågorna ovanifrån och den tredje resten av dem är frågor som körs av SQL eller andra stödjande frågor. Till exempel är rad 13 dm_exec_sql_text som anropas från frågan ovan som kontrollerar Planen.
om vi ville filtrera ner detta till bara de frågor vi hade skrivit kan du göra det genom att lägga till en where text LIKE … – klausul till frågan som visas här.
SELECT size_in_bytes, text FROM sys.dm_exec_cached_plans CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS stWHERE text LIKE N'SELECT FirstName%';
här ser vi att endast de tre frågorna dyker upp, och att var och en av dessa tre tar upp cirka 40k minne på SQL Server. 
så varför finns det tre kopior av samma SELECT-uttalande, Det verkar lite slösigt. Det gör det faktiskt, för mer information se ett tidigare inlägg som heter Hur mycket Procedurcacheminne tar ett SQL-uttalande upp? Det finns sätt att korrigera detta.
använda DBCC FreeProcCache för ett specifikt Planhandtag
om du ville rensa bara ett enda planhandtag, och inte alla planhandtag, kan du använda den valfria parametern @handle.
för att få planhandtaget börjar vi med att ändra vår tidigare Fråga för att visa oss vad som finns i plancachen. Du kan utelämna where-klausulen på ditt eget system, men jag har den här för att visa oss bara de tre frågorna i fråga ovanifrån.
SELECT size_in_bytes, text, plan_handle FROM sys.dm_exec_cached_plans CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS stWHERE text LIKE N'SELECT FirstName%';
här ser vi samma tre frågeplaner från tidigare, med en tilläggskolumn som heter plan_handle. För att frigöra ett enda planhandtag skulle vi bara kopiera det numeriska planhandtaget och lägga till det i DBCC FreeProcCache-frågan.
DBCC FREEPROCCACHE(0x060007000100FF3310B8DA7D0600000001000000000000000000000000000000000000000000000000000000);SELECT size_in_bytes, text, plan_handle FROM sys.dm_exec_cached_plans CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS stWHERE text LIKE N'SELECT FirstName%';
där vi bara ser 2 av de tre ursprungliga frågorna i plancachen.
hur stor är min Procedurcache?
du kan köra följande Fråga för att kontrollera storleken på din procedurcache.
SELECT count(*) AS NumPlans, objtype as Type,SUM(size_in_bytes)/(1024.0*1024.0) AS size_in_mbFROM sys.dm_exec_cached_plansGROUP BY objtype;
som ger följande resultat på min testserver.
Databashälsorapporter och Plancachen
du kan också visa plancachen med hjälp av programmet Databashälsorapporter som visas här.
anmärkningar:
för mer information se TSQL Wiki DBCC freeproccache.
DBCC Kommandomånad vid SteveStedman.com det är nästan lika roligt som att äta jello.
Steve och teamet på Stedman Solutions är här för alla dina SQL Server-behov.
Contct oss idag för din gratis 30 minuters konsultation..
vi är redo att hjälpa!
