Er zijn een paar manieren om ervoor te zorgen dat een opgeslagen procedure opnieuw wordt gecompileerd:
- met behulp van
WITH RECOMPILE
, - de opgeslagen procedure dynamisch maken (denk aan
exec()
) - het proces markeren voor hercompileren met
sp_recompile
. - het schema wijzigen waarop een queryplan in de cache is gebaseerd
- aanroepend
DBCC FREEPROCCACHE
- Op het queryniveau kan een individuele instructie binnen een proc opnieuw worden gecompileerd met de RECOMPILE-queryhint (SQL 2008).
Factoren bij hercompilatie
Wat veroorzaakt behalve de hierboven genoemde harde factoren de hercompilatie van opgeslagen procedures? Nou, heel veel dingen. Sommige hiervan zijn verweven met de bovenstaande lijst, maar ik wil ze opnieuw presenteren, omdat het misschien niet voor de hand ligt.
- Veel gegevens invoegen of verwijderen (gegevensdichtheid in indexen en tabellen bepaalt vaak queryplannen)
- Indexen opnieuw opbouwen (een wijziging in onderliggende objecten)
- Tijdelijke tabellen maken/verwijderen (opnieuw, onderliggende DML-wijzigingen).
- queryplan veroudert (denk niet recentelijk gebruikt en sql wil geheugengebruik opschonen)
Dit is geenszins een uitputtende lijst. De query-optimizer evolueert en verrast, ongeacht hoe lang u SQL Server al gebruikt. Maar hier zijn enkele bronnen die van pas kunnen komen:
- Problemen oplossen met het opnieuw compileren van opgeslagen procedures (een oudje, maar een goedje)
- Opgeslagen procedures opnieuw aanvullen
- Opgeslagen SQL Server-procedures optimaliseren om hercompilaties te voorkomen
- Uitvoeringsplan caching en hergebruik (een must om te lezen)
MAAR WACHT - ER IS MEER!
Dat gezegd hebbende, het vermoeden in uw vraag is dat hercompilaties altijd slecht zijn voor de prestaties. In feite is hercompliment vaak goed.
Dus wanneer zou je willen dat het opnieuw wordt gecompileerd? Laten we eens kijken naar een voorbeeld van een proc die zoekt op achternaam. Opgeslagen procedures doen 'parameter snuiven
' wat een zegen is (als het voor je werkt) en een vloek (als het tegen je werkt). Geef eerst iemand een zoekopdracht op Zebr%
voor zerbrowski. De achternaamindex realiseert zich dat dit heel specifiek is en zal, laten we zeggen, 3 rijen van een miljoen retourneren - dus er wordt één uitvoeringsplan gebouwd. Met de procedure gecompileerd voor een laag rijresultaat, is de volgende zoekopdracht voor S%
. Nou, S is je meest voorkomende naam en komt overeen met 93.543 rijen van 1 miljoen.