är RECOMPILE verkligen så illa?

Heh … på DBCC FREEPROCCACHE-saken och med förståelsen att min server förmodligen inte är någonstans nära en plats där det skulle orsaka en verklig oro, har vi en tung blandning mellan OLTP och stora bearbetningskörningar, särskilt under dagtid. Det tar alldeles för lång tid att isolera varje lagrad procedur som behöver en kompilering och så använder jag DBCC FREEPROCCACHE på min produktionslåda då och då utan allvarliga skadliga effekter och det rensar upp en mängd synder omedelbart. YMMV men, för mig, använder DBCC FREEPROCCACHE är inte nej-nej att alla gör det ut att vara.

När det gäller kompileringar håller jag med. De är inte nödvändigtvis synden som många människor skulle få dig att tro. De är särskilt användbara i några av de stora bearbetningskörningarna där du behöver en omkompilering för att faktiskt få minimal loggning att fungera.

det har varit ett tag sedan jag har tittat på vår kompileringssituation på jobbet men vi hade en proc som ”bara” tog 100ms att utföra, vilket jag också trodde tog för lång tid men kunde inte få ledningen att springa på trots att jag förklarade tiotusentals gånger det slogs varje timme. Sedan gjorde jag en kompileringsanalys och den fördömda saken kompilerade inte bara varje gång den kallades, det tog mellan 2 och 22 sekunder att kompilera om varje gång med genomsnittet som kom in på 20 sekunder. När jag gjorde mina tweaks till den ganska korta koden i proc, gick inte bara kompilerna bort utan utförandet mäts nu i ensiffrig ms.jag visste inte det, men det löste också en stor smärtpunkt i returtider på golvet för en viss skärm i applikationen som använde proc.

När det gäller de ”framsteg” som de kom med på detta område för 2017 och 2019, är jag rädd för att dö för att flytta från 2016. Jag lider fortfarande av några av de ”framsteg” som de kom fram till 2014 och 2016. De ger oss inte mycket val när det gäller uppgradering, fastän. En sådan ” förskott ”är”snabba insatser”. De flesta vet inte om det eftersom deras indexunderhållsrutiner döljer felet Det har med att allokera en full utsträckning utan att leta efter delvis tomma redan befintliga utsträckning även om du sätter in en ordspråkig ”1 byte” rad. Tack och lov för TF 692.

de ändringar som de gjorde för TempDB är ganska bra men tillåter inte ens en tillfällig utflykt till obalans filstorlekar har dödat en hel del saker som vi gjorde på grund av ett annat fel inbäddat i SET IDENTITY INSERT där hela dataöverföringen sorteras i TempDB trots att det inte behövs på grund av närvaron av ett grupperat Index och Minimal loggning.

Jag önskar att MS skulle sluta göra ” förbättringar ”och börja fixa de” förbättringar ” som de redan har gjort.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *