När jag har varit tvungen att undersöka problem med plancaching/överdriven omkompilering av frågor har jag följt riktlinjerna i Microsofts whitepaper "Planera cachelagring i SQL Server 2008" och jag rekommenderar starkt att du läser det eftersom det täcker plancache, återanvändning av frågeplaner, orsaker till omkompilering, identifiering av omkompilering och andra relaterade ämnen.
Med det sagt avslöjar SQL Server Profiler (Bör finnas under Microsoft SQL Server 2008 -> Prestandaverktyg om du installerade det som en del av installationen av klientverktygen) tre händelser som är direkt relaterade till frågekompilering som kan vara till hjälp för dig:
- Markör
- CursorRecompile
- Prestanda
- Showplan XML för frågekompilering
- Lagrad procedur
- SP:Omkompilera
Du använder lagrade procedurer så sannolikt behöver du bara oroa dig för SP:Omkompilera händelse. Denna händelse kommer att aktiveras varje gång en lagrad procedur, trigger eller användardefinierad funktion har kompilerats om. TextData-kolumnen kommer att visa texten i tsql-satsen som orsakade satsomkompileringen och EventSubClass-kolumnen kommer att visa en kod som anger orsaken till omkompileringen.
EventSubClass Codes for SP:Recompile in SQL 2008
- 1 =Schema ändrat
- 2 =Statistiken ändrad
- 3 =Omkompilera DNR
- 4 =Ange alternativ ändrat
- 5 =Temp tabell ändrad
- 6 =Fjärrraduppsättning ändrad
- 7 =För sökningstillstånd ändrade
- 8 =Frågemeddelandemiljö ändrad
- 9 =MPI-vy ändrad
- 10 =Marköralternativ ändrade
- 11 =Med omkompileringsalternativ
Om du övervakar följande 5 händelser kommer du att kunna se vilka lagrade procedurer och satser som anropas på SQL Server och vilka som utlöser omkompilering:
- Butiksrutiner
- SP:Startar
- SP:StmtStarting
- SP:Omkompilera
- SP:Slutförd
- Prestanda
- Automatisk statistik
Jag brukar också ställa in Profiler-spåret för att fånga alla kolumner för dessa händelser. Jag skulle säga att ställa in ett spår med dessa 5 händelser, köra ett spår i 30 till 60 sekunder och sedan pausa det och sedan bör du ha en bra ögonblicksbild av vad som orsakar omkompileringarna.
Om det är för mycket brus kan du börja lägga till kolumnfilter i spårningsegenskaperna för att filtrera in/ut händelser. Om du till exempel upptäcker att de flesta av dina omkompileringar sker på databasen en gång, ställ in ett kolumnfilter på kolumnen databaseID eller databaseName så att bara frågor som körs mot den databasen inkluderas i ditt spår.
Börja sedan leta efter mönster där frågor kompileras om och använd whitepaper från Microsoft som en guide till varför de kan utlösa omkompileringen.