Da jeg tidligere har været nødt til at undersøge problemer med plancache/overdreven forespørgselsrekompilering, har jeg fulgt vejledningen i Microsofts hvidbog 'Planlæg cachelagring i SQL Server 2008' og jeg vil kraftigt anbefale at læse det, da det dækker caching af plan, genbrug af forespørgselsplaner, årsager til genkompileringer, identifikation af genkompileringer og andre relaterede emner.
Når det er sagt, afslører SQL Server Profiler (Skal være placeret under Microsoft SQL Server 2008 -> Ydelsesværktøjer, hvis du installerede det som en del af din klientværktøjsinstallation) tre hændelser, der er direkte relateret til forespørgselskompilering, som kan være til hjælp for dig:
- Markør
- CursorRecompile
- Ydeevne
- Showplan XML for Query Compile
- Lagret procedure
- SP:Rekompilere
Du bruger Stored Procedures, så det er sandsynligt, at du kun behøver at bekymre dig om SP:Rekompilere begivenhed. Denne hændelse udløses hver gang en lagret procedure, trigger eller brugerdefineret funktion er blevet genkompileret. TextData-kolonnen viser teksten af tsql-sætningen, der forårsagede sætningsrekompileringen, og EventSubClass-kolonnen vil vise en kode, der angiver årsagen til rekompileringen.
EventSubClass Codes for SP:Recompile in SQL 2008
- 1 =Skema ændret
- 2 =Statistik ændret
- 3 =Genkompiler DNR
- 4 =Indstil indstilling ændret
- 5 =Temp-tabel ændret
- 6 =Eksternt rækkesæt ændret
- 7 =For ændret tilladelse til at gennemse
- 8 =Forespørgselsmeddelelsesmiljø ændret
- 9 =MPI-visning ændret
- 10 =Markørindstillinger ændret
- 11 =Med genkompileringsmulighed
Hvis du overvåger følgende 5 hændelser, vil du være i stand til at se, hvilke lagrede procedurer og sætninger, der kaldes på SQL Serveren, og hvilke der udløser rekompilering:
- Butiksprocedurer
- SP:Starter
- SP:StmtStarting
- SP:Rekompilere
- SP:Udført
- Ydeevne
- Automatisk statistik
Jeg sætter også normalt Profiler-sporingen op til at fange alle kolonner for disse begivenheder. Jeg vil sige opsæt et spor med disse 5 hændelser, kør et spor i 30 til 60 sekunder og sæt det derefter på pause, og så skulle du have et godt øjebliksbillede af, hvad der forårsager rekompileringerne.
Hvis der er for meget støj, kan du begynde at tilføje kolonnefiltre til sporingsegenskaberne for at filtrere ind/ud hændelser. Hvis du f.eks. finder, at de fleste af dine omkompileringer sker på en enkelt database, skal du opsætte et kolonnefilter på kolonnen databaseID eller databaseName, så kun forespørgsler, der køres mod den database, er inkluderet i dit spor.
Begynd derefter at lede efter mønstre, hvor forespørgsler bliver omkompileret, og brug whitepaperet fra Microsoft som en guide til, hvorfor de muligvis udløser omkompileringen.