Techrepublics gratis nyhedsbrev, der leveres hver tirsdag, indeholder praktiske tip, der hjælper dig med at blive mere dygtig med dette kraftfulde relationsdatabasestyringssystem. Tilmeld dig automatisk i dag!

den almindeligt accepterede visdom om lagrede procedurer (eller tandhjul) er,at fordi de kan optimere og kompilere dem, kører de hurtigere end de tilsvarende kvm-udsagn, der udføres fra (eller måske videregivet fra en eller anden front-end-app, såsom en hjemmeside eller VBprogram). Dette er sandt til en vis grad.

først skal du vide, hvad der sker med et nyt sprog. På oprettelsestidspunktet kontrollerer den syntaksen. Hvis det ikke finder nogen fejl, tilføjer det sproc til systemtabellerne: sysobjects, sysdepends og syscomments (sidstnævnte gemmer sproc ‘ s krop). Som standard kompilerer den ikke sproc på oprettelsestidspunktet.

Ved første udførelse af sproc optimerer og kompilerer den. Dette er, når udarbejder en forespørgeplan og gemmer det i sin procedure cache. Ved efterfølgende påkaldelser ser vi udi cachen først, finder sproc der og kompilerer det ikke. Hvis sproc ‘ en ikke er i cachen,samler vi den og placerer den i cachen.

min erfaring med indstillingen med genkompilering

et stykke tid tilbage støttede jeg en søgeside, der tillod detdets brugere at søge efter en af flere kolonner. Derefter kaldte siden en sproc, der passerer en parameter for at angive hvilken kolonne tilsøgning. Jeg undersøgte parameteren ved hjælp af en SAGSBLOK og udførte derefter en af flere forespørgsler afhængigt af kolonnen for at søge.

Jeg vidste, at der var noget galt, da jeg begyndte at teste min påståede lagrede procedure. I teorien skal udførelsen af hver søgning mindst være omtrent den samme, men det er ikke, hvad der skete. Da jeg udførteflere søgninger, uanset rækkefølgen, ville den første være hurtig, ogefterfølgende søgninger var meget langsommere.

endelig indså jeg, at første gang proceduren blev kaldt, blev en forespørgselsplan udtænkt og gemt i cachen. Så længe jeg søgte på den pågældende kolonne, ville alt fungere som forventet. I det øjeblik jeg skiftede kolonner, imidlertid, ydeevne faldt. Hvorforskete dette?

den første søgning, jeg udførte, oprettede en forespørgselsplan og lagerdit i cachen. For eksempel, siger jeg søgte på kolonnen OrderDate. Hvis jeg skiftede søgningen til kolonnen firmanavn, ville vi blindt bruge den cachelagrede forespørgeplan og søge efter målfirmaets navn ved hjælp af Ordredateindekset. Ikke underligt, at ydeevnen ville falde så dramatisk.

rettelsen er ret simpel. Jeg udførte sprocsupplying med RECOMPILE option:

EXEC MySproc_Select '12/31/2004' WITH RECOMPILE

dette fortæller os, at vi skal smide den eksisterende forespørgselsplanog bygge en anden-men kun denne gang.

Du kan også tilføje med kompilere direkte til storedprocedure lige før som søgeord. Dette fortæller os, at vi skal smide forespørgselsplanen ud på hver udførelse af sproc.

der er også en tredje mulighed. Jeg kunne have oprettet aseparate sproc for hver søgemetode, og derefterbeslutte hvilken der skal udføres inden for SAGSBLOKKEN. På den måde forbliver forespørgselsplanen, der er knyttet til underhjulene,i cachen, hvor CVR kan drage fordel af dem. Siden hver af tandhjulenesøgt nøjagtigt en kolonne, er der ikke behov for at kompilere igen.serverens evne til at optimere og kompilere en storedprocedure er stor, men hvis du ikke er forsigtig, kan den bide dig, når du mindst forventer det. Nu hvor du ved, hvordan du skal håndtere problemet, er der måske enfå situationer i din egen database, som du måske vil besøge igen.