Der er et par måder at sikre genkompilering af en lagret procedure på:
- ved hjælp af
WITH RECOMPILE, - gør den lagrede procedure dynamisk (tænk
exec()) - markering af proc til rekompilering med
sp_recompile. - ændring af det skema, som en cachelagret forespørgselsplan er afhængig af
- kalder
DBCC FREEPROCCACHE - På forespørgselsniveauet kan en individuel sætning i en proc genkompileres med RECOMPILE-forespørgselstip (SQL 2008).
Faktorer i rekompilering
Udover de hårde faktorer, der er anført ovenfor, hvad forårsager rekompilering af lagrede procedurer? Tja, mange ting. Nogle af disse er vævet sammen med listen ovenfor, men jeg vil gerne præsentere dem igen, da det måske ikke er indlysende.
- Indsættelse eller sletning af masser af data (datatæthed i indekser og tabeller styrer ofte forespørgselsplaner)
- Genopbygning af indekser (en ændring af underliggende objekter)
- Oprettelse/sletning af midlertidige tabeller (igen, underliggende DML-ændringer).
- forespørgselsplan forældes (tror ikke brugt for nylig, og sql ønsker at rydde op i hukommelsesbrug)
Dette er på ingen måde en udtømmende liste. Forespørgselsoptimeringsværktøjet udvikler sig og overrasker, uanset hvor længe du har brugt SQL Server. Men her er nogle ressourcer, der kan være nyttige:
- Fejlfinding af genkompilering af lagrede procedurer (en oldie, men en goodie)
- Recompling Stored Procedures
- Optimering af SQL Server Stored Procedures for at undgå genkompilering
- Caching og genbrug af eksekveringsplan (skal læses)
MEN vent - DER ER MERE !
Når det er sagt, er formodningen i dit spørgsmål, at genkompilering altid er dårligt for ydeevnen. Faktisk er recompliment ofte godt.
Så hvornår vil du have det til at genkompilere? Lad os se på et eksempel på en proc, der søger på efternavn. Lagrede procedurer udfører 'parametersniffing
' hvilket er en velsignelse (hvis det virker for dig) og en forbandelse (hvis det virker imod dig). Først forbi nogen søger på Zebr% for zerbrowski. Efternavnsindekset indser, at dette er meget specifikt og vil returnere, lad os sige, 3 rækker fra en million -- så en udførelsesplan er bygget. Med processen kompileret til et resultat med lav række, er den næste søgning efter S% . Nå, S er dit mest almindelige navn og matcher 93.543 rækker ud af 1 million.