Vraag en antwoord uit onze webinarserie Parameter Sniffing

De afgelopen twee woensdagen hebben we een tweedelige webinarserie georganiseerd waarin problemen met parametergevoeligheid worden behandeld:

• Opgeslagen procedures, parameters, problemen...
  Kimberly L. Tripp en Aaron Bertrand
  24 januari
  Heb je het gemist? Registreer om het nu te bekijken!

• Snuiven van parameters aanpakken met SentryOne
  Aaron Bertrand, Kimberly L. Tripp en Andy Mallon
  31 januari
  Heb je het gemist? Bekijk het nu!

Tijdens beide webinars kwamen enkele vragen naar voren en ik dacht dat ik ze zou verzamelen en hier zou beantwoorden (sommige antwoorden kwamen van Andy tijdens het webinar).

In een probleem dat we onlangs hebben gezien, zien we dat plannen heel snel uit de cache worden gehaald. We voeren niets uit dat u beschrijft (DBCC FREEPROCCACHE enzovoort.); kan geheugendruk dit ook veroorzaken?

Ja, geheugendruk kan een factor zijn (zie dit bericht), en ik weet dat er in dit opzicht ook enkele onderzoeken zijn naar mogelijke problemen met het geheugenbeheer van SQL Server.

Van een deelnemer:"Geen vraag, maar een opmerking aan de gebruiker die vraagt ​​naar de vele keren dat zijn plancache wordt geleegd. Dat hadden we ook en inderdaad, het was geheugendruk. We hadden het maximale servergeheugen verkeerd geconfigureerd, dat was opgelost met behulp van de hier genoemde formule, en toen lieten we de procedure uit dit artikel elke 10 minuten draaien (we hebben tonnen dynamische SQL, slechts één keer gebruikt)."

Wat als u OR . gebruikt in de waar-clausule in plaats van AND , zou het probleem aanhouden?

Meestal als u OR . gebruikt in dit type patroon krijgt u elke keer alle rijen, tenzij elke afzonderlijke parameter is gevuld met waarden die rijen filteren. Dit verandert de semantiek van de vraag van 'al deze dingen moeten waar zijn' in 'elk van deze dingen kan waar zijn'. Het plan dat voor de eerste set parameters is samengesteld, wordt echter nog steeds in de cache opgeslagen en bewaard voor toekomstige uitvoeringen, ongeacht of uw clausules AND gebruiken of OR .

Is dat 1=1 een goede aanpak markeren? Het is niet beter om alleen de opgegeven parameters toe te voegen en daarom de lelijke 1=1 . te vermijden ?

De 1 = 1 wordt vrijwel genegeerd door SQL Server, maar staat toe dat alle voorwaardelijke clausules worden toegevoegd met AND zodat u de *eerste* niet anders hoeft te behandelen. Hier is het alternatief:

SET @IncludedWhereClauseYet bit = 0;
SET @sql = N'SELECT cols FROM dbo.Table';
 
IF @param1 IS NOT NULL
BEGIN
  IF @IncludedWhereClauseYet = 0
  BEGIN
    SET @sql += N' WHERE ';
    SET @IncludedWhereClauseYet = 1;
  END
  ELSE
  BEGIN
    SET @sql += N' AND ';
  END
  SET @sql += N' @param1 = @param1';
END
 
IF @param2 IS NOT NULL
BEGIN
  IF @IncludedWhereClauseYet = 0
  ...
END
...

De 1=1 stelt u in staat om te vereenvoudigen, door u altijd een clausule te laten voorafgaan met AND . De bovenstaande code wordt:

SET @sql = N'SELECT cols FROM dbo.Table WHERE 1 = 1';
 
IF @param1 IS NOT NULL
BEGIN
  SET @sql += N' AND @param1 = @param1';
END
 
IF @param2 IS NOT NULL
BEGIN
  SET @sql += N' AND @param2 = @param2';
END

Je zou misschien een andere initiële clausule kunnen gebruiken om alle conditionals te vermijden, zoals WHERE PrimaryKey > 0 of WHERE PrimaryKey IS NOT NULL , en dan zou elke volgende clausule kunnen beginnen met AND . Maar 1 = 1 , hoewel lelijk, is onschadelijk, en IMHO is niet minder lelijk dan het toevoegen van een *echte* maar betekenisloze clausule, behalve dat een *echte* clausule het plan kan beïnvloeden.

Onthoud dat wanneer u T-SQL-code maakt met T-SQL, u aan twee aspecten van "lelijk" moet denken:soms lost u de bovenstaande code op en soms lost u de vraag op die eruit komt het. Wees voorzichtig met het opofferen van het een omwille van het ander.

WAT?! Ik heb dat helemaal gemist ... WITH RECOMPILE . Ik dacht dat het plan daarmee leeg was, maar het laat het alleen voor deze uitvoering... dat is heel belangrijk om te weten!

Zorg ervoor dat je ook op de hoogte bent van de nadelen.
Zie dit geweldige bericht van Paul White.

Is OPTION OPTIMIZE FOR @parametername UNKNOWN niet langer de voorkeur in recentere SQL-versies?

Ik denk niet dat het beter of slechter is in moderne versies dan toen het voor het eerst werd geïntroduceerd in SQL Server 2008. Voor zover ik weet, werkt dat stukje nog steeds op dezelfde manier, zelfs met alle wijzigingen in de optimalisatie- en kardinaliteitsschatter.

Is de server belast als ik het vastleggen van procedurestatistieken en querystatistieken in SentryOne inschakel?

De verzameling procedure- en querystatistieken moet standaard zijn ingeschakeld. Aan alle gegevensverzameling zijn kosten verbonden, maar SQL Sentry is heel voorzichtig met de kosten die de verzameling met zich meebrengt.

Het zoeken op RS gebruikte het niet als een resterend predikaat, het zocht op iets anders dat ik niet kon zien.

Bedankt, ik zal dat voorbeeld opnieuw bekijken en apart bloggen over de demo's, waarbij ik ervoor zorg dat alle relevante details worden opgenomen die niet duidelijk waren uit het plandiagram alleen.

Is het niet waar dat het toevoegen van enkele van de kolommen die nodig zijn als INCLUDE s de index niet effectiever maken omdat het opzoeken van de sleutel niet wordt geëlimineerd? Ik denk dat het percentage niet zou moeten veranderen, tenzij je de sleutelzoekopdracht daadwerkelijk elimineert.

Strikt genomen, ja, dat is waar. De oorspronkelijke zoekopdracht was een uiterst slecht voorbeeld, met behulp van SELECT * en een index die een hopeloos aantal kolommen mist. Het punt dat ik probeerde te maken, is dat het tabblad Indexanalyse u aanmoedigt om zowel (a) de zoekopdracht te verbeteren als (b) de indexdekking te maken. De score is er om u te verleiden om een ​​van beide of beide te doen - als u de zoekopdracht wijzigt zodat u minder kolommen nodig heeft, komt de index ook dichter bij de zoekopdracht. Als je een nieuwe, aparte, dekkende index gaat maken, heb je ook de informatie over welke kolommen nodig zijn om deze specifieke zoekopdracht te dekken. Technisch gezien heb je gelijk, het toevoegen van één include-kolom maar het zoeken naar 4 anderen zal deze specifieke zoekopdracht niet beter laten presteren, en zal de index niet beter maken, maar het geeft wel aan dat je ' komt steeds dichterbij. De hoop is dat u niet stopt bij het toevoegen van slechts één kolom inclusief opnemen en de rest negeert. We weten niet wanneer je gaat stoppen, dus ik weet niet of er een perfecte oplossing is – we willen je zeker niet ontmoedigen gebruikers ervan te weerhouden hun indexen beter geschikt te maken voor hun zoekopdrachten.

Waarom zien we query's die de parameter voornaam en achternaam gebruiken, samengevat onder een instructie die alleen een parameter voor achternaam gebruikt?

UPDATE: Dit is opzettelijk. De groepering onder Toon Totalen groepeert dezelfde procedure die wordt aangeroepen met alle verschillende parametercombinaties. U kunt het dus eerst gebruiken om te bepalen welke parameters de neiging hebben om de slechtste prestaties te veroorzaken, en vervolgens inzoomen op de vraag of er al dan niet sprake is van scheeftrekking van gegevens. Een parameter die bijvoorbeeld leidt tot een zoekopdracht tegen een niet-geïndexeerde kolom, zal waarschijnlijk vrij betrouwbaar naar de top bubbelen, en dat kun je zien in combinatie met andere parameters die worden doorgegeven en ook vergeleken met alle aanroepen waar die parameter was' t geslaagd.

Dat gezegd hebbende, zullen we proberen dit groeperingsgedrag te verfijnen als we de wijzigingen die momenteel tijdens de vlucht worden doorgevoerd voor het Top SQL-scherm afronden.

Is er documentatie over het gebruik van een plangids? Ik zou momenteel geen idee hebben hoe ik dat moet doen.

Dit is iets anders waar ik over wilde bloggen, maar Microsoft heeft hier in de tussentijd een aantal onderwerpen (en bekijk alle gerelateerde links in de zijbalk).

Moet ik iets inschakelen om de Query History Chart te krijgen?

Nee, dit moet worden ingeschakeld op alle moderne versies van de SentryOne-clienttoepassing. Als je het niet ziet, probeer dan Tools > Reset Layout; als dat niet werkt, neem dan contact op met [email protected].

Zijn er gevallen waarin het laatst bekende goede plan wordt afgedwongen met Query Store wanneer een planregressie een slecht idee wordt gevonden? Zal dat ertoe leiden dat problemen worden verborgen die beter kunnen worden opgelost door de verklaring te wijzigen zoals u hebt laten zien?

Een plan forceren is vaak een laatste redmiddel, en ik heb de neiging om het te reserveren voor gevallen waarin je de verklaring echt, echt, echt niet kunt repareren (of de index kunt wijzigen). Het forceren van een plan kan altijd leiden tot verkeerd gedrag, omdat het nog steeds een mens is die die keuze maakt, en je zou het kunnen maken op basis van slechte informatie. De regressie kan het gevolg zijn van een wijziging van het plan, maar als je het als een regressie beschouwt omdat de looptijd langer was, heb je dan andere mogelijke redenen onderzocht? Laten we bijvoorbeeld zeggen dat het systeem opnieuw is opgestart of dat er een failover is geweest en een nieuw plan heeft gekregen omdat het oude was uitgezet, en misschien zijn de statistieken in de tussentijd ook veranderd, maar nu loopt de query langer, niet omdat het plan slechter is, maar eerder omdat de buffers leeg waren. Dus ja, ik zou zeker niet aanraden om bij elke regressie een plan te forceren.

SentryOne legt niet altijd gegevens of parameters vast, dus ik heb niet genoeg informatie. Hoe zorg ik ervoor dat SentryOne altijd parameters en uitvoeringsplannen vastlegt?

Dat kan echt niet, omdat dit allemaal te maken heeft met hoe uw zoekopdrachten worden uitgevoerd, hoe we ze vastleggen en hoe snel ze worden uitgevoerd. Vaak duren uw query's niet lang genoeg om volledig te worden vastgelegd, en moeten we vertrouwen op de geaggregeerde query-/procedurestatistieken van SQL Server, die geen parameterinformatie verzamelen. U kunt de verzamelingsinstellingen voor Top SQL Source wijzigen om meer en met een frequenter interval vast te leggen, maar u moet de hoeveelheid gegevens die u verzamelt in evenwicht houden met de hoeveelheid aanvullende informatie die het u oplevert.

Kan ik informatie opvragen, zodat ik rapporten kan automatiseren en genereren?

We hebben niets uit de doos om dit voor je te doen, maar laat me het terugbrengen naar het team en kijken wat voor opties we kunnen bedenken. Een van de dingen waar ik mee speelde voor dit webinar was het bouwen van een adviesconditie om de soorten regressies op te vangen waarnaar we op zoek zijn, maar tijd werd een factor.

Hoe beslissen we wanneer we OPTION (RECOMPILE) moeten gebruiken? , omdat we elke dag verschillende plannen krijgen voor verschillende parameters?

Ik zou zeggen, begin met de vragen die het meest fluctueren met parametergevoeligheid. Als ik een vraag heb die soms 2 seconden duurt, maar soms 30, en een andere die varieert van 4 seconden tot 6 seconden,
ga ik me concentreren op de eerste.

Welke is beter om te gebruiken, OPTION (RECOMPILE) of QUERYTRACEON , in het geval van het snuiven van parameters.

Ik geef de voorkeur aan OPTION (RECOMPILE) om twee redenen. Ten eerste documenteert het zichzelf; niemand die de code leest, zal zich afvragen wat het doet, maar niet iedereen die de code leest, heeft TF-nummers zoals 4136 onthouden. Twee, het vereist geen verhoogde machtigingen - probeer QUERYTRACEON te gebruiken als een pioen.

Is het mogelijk om te signaleren of te rapporteren over procedures die langer duren dan normaal? Meest geïnteresseerd in procedures met een hoog aantal.

Absoluut, je zou een adviesvoorwaarde kunnen gebruiken, maar het kan een beetje ingewikkeld worden omdat - voor procedures die soms zelfs onder de verzameldrempel lopen - je snapshots van de procedurestatistieken DMV zou moeten vergelijken. Ik heb een herinnering toegevoegd om hier ook over te bloggen, omdat het iets is dat ik klanten in het verleden heb helpen implementeren.

Microsoft maakt automatisch afstemmen de standaard voor Azure SQL Database, inclusief automatische plancorrectie. Lijkt je dat een goed idee?

Ik bewaar mijn oordeel totdat ik (of sommige klanten) ermee hebben gespeeld. Beslissen hoe te stemmen is uitdagend genoeg voor stervelingen; stervelingen die software schrijven die op jou is afgestemd, lijkt minstens zo uitdagend, zo niet meer. Toen Andy deze vraag zag, zei hij tegen me dat het hem deed denken aan SQL Server 2000 - het marketingpraatje was toen dat het zo zelfafstemming was dat we geen DBA's meer nodig hadden. Die claim is niet goed verouderd.

Het zou fijn zijn om de twee stippen op de grafiek van de zoekopdrachtgeschiedenis te kunnen selecteren en te vergelijken.

Ik ga akkoord.
Blijf op de hoogte.