Vervolg op Zomervoorstelling Palooza 2013

Op 27 juni hield het PASS Performance Virtual Chapter zijn Summer Performance Palooza 2013 - een soort verkleinde 24 Hours of PASS, maar uitsluitend gericht op prestatiegerelateerde onderwerpen. Ik gaf een sessie met de titel "10 slechte gewoonten die prestaties kunnen doden", waarbij ik de volgende 10 concepten behandelde:

1. SELECTEER *
2. Blinde indexen
3. Geen schemavoorvoegsel
4. Standaard cursoropties
5. sp_ voorvoegsel
6. Cache bloat toestaan
7. Brede gegevenstypen
8. SQL Server-standaardinstellingen
9. Overmatig gebruik van functies
10. "Werkt op mijn computer"

Misschien herinnert u zich enkele van deze onderwerpen uit presentaties zoals mijn "Bad Habits and Best Practices"-lezing of onze wekelijkse Query Tuning-webinars die ik van begin juni tot en met deze week met Kevin Kline heb gehost. (Die 6 video's zullen trouwens begin augustus beschikbaar zijn op YouTube.)

Mijn sessie had 351 deelnemers en ik kreeg geweldige feedback. Daar wilde ik iets over kwijt.

Ten eerste een configuratieprobleem:ik gebruikte een gloednieuwe microfoon en had geen idee dat elke toetsaanslag als onweer zou klinken. Ik heb dat probleem aangepakt met een betere plaatsing van mijn randapparatuur, maar ik wil mijn excuses aanbieden aan iedereen die hierdoor wordt getroffen.

Vervolgens de downloads; het dek en de monsters worden op de evenementensite geplaatst. Ze staan ​​onderaan de pagina, maar je kunt ze ook hier downloaden.

Tot slot, wat volgt is een lijst met vragen die tijdens de sessie zijn gepost, en ik wilde er zeker van zijn dat ik alle vragen beantwoord die niet werden beantwoord tijdens de live Q &A. Het spijt me dat ik dit in iets minder dan een maand heb geperst , maar er waren veel vragen, en ik wilde ze niet in delen publiceren.

A: Je zult dit van geval tot geval moeten bekijken, aangezien het echt van verschillende factoren afhangt (waaronder de complexiteit van het plan). Merk ook op dat u hercompilatie op statement-niveau kunt doen, zodat alleen de betrokken statements de treffer moeten opvangen, in tegenstelling tot de hele module. Paul White herinnerde me eraan dat mensen vaak parameters 'repareren' met RECOMPILE , maar al te vaak betekent dat 2000-stijl WITH RECOMPILE in plaats van de veel betere OPTION (RECOMPILE) , die zich niet alleen beperkt tot de instructie, maar ook parameterinbedding mogelijk maakt, die WITH RECOMPILE doet niet. Dus, als u RECOMPILE . gaat gebruiken om het snuiven van parameters te dwarsbomen, voeg je het toe aan het statement, niet aan de module.

A: Zoals hierboven, zal dit afhangen van de kosten en complexiteit van de plannen en er is geen manier om te zeggen:"Ja, er zal altijd een grote prestatiehit zijn." Je moet dat ook met het alternatief vergelijken.

A: Ik weet niet zeker wat "leesbaar in de echte wereld" betekent. Als u bedoelt dat u de uitvoer in een specifiek formaat wilt, kunt u meestal beter converteren naar een string aan de clientzijde. C# en de meeste andere talen die u waarschijnlijk op de presentatielaag gebruikt, zijn meer dan in staat om datum/tijd-uitvoer van de database op te maken in elk regionaal formaat dat u maar wilt.

A: De meeste DMV's zijn pas geldig sinds de laatste servicestart, en zelfs andere kunnen vaker worden gespoeld (zelfs op aanvraag - zowel per ongeluk als met opzet). De plancache is natuurlijk constant in beweging, en AFAIK-plannen die uit de cache vallen, behouden hun vorige telling niet als ze weer binnenkomen. Dus zelfs als je een plan in de cache ziet, ben ik niet 100% ervan overtuigd dat u het gebruik kunt geloven dat u vindt.

Dat gezegd hebbende, wat u waarschijnlijk zoekt, is sys.dm_exec_cached_plans.usecounts en u kunt ook sys.dm_exec_procedure_stats.execution_count vinden om informatie aan te vullen voor procedures waarbij individuele verklaringen binnen de procedures niet in de cache worden gevonden.

A: De belangrijkste zorgen hieromtrent zijn de mogelijkheid om bepaalde syntaxis te gebruiken, zoals OUTER APPLY of variabelen met een functie met tabelwaarde. Ik ken geen gevallen waarin het gebruik van een lagere compatibiliteit een directe invloed heeft op de prestaties, maar een aantal dingen die doorgaans worden aanbevolen, zijn het opnieuw opbouwen van indexen en het bijwerken van statistieken (en om uw leverancier zo snel mogelijk het nieuwere compatibiliteitsniveau te laten ondersteunen). Ik heb in een aanzienlijk aantal gevallen onverwachte prestatievermindering zien oplossen, maar ik heb ook enkele meningen gehoord dat dit niet nodig en misschien zelfs onverstandig is.

A: Nee, in ieder geval qua prestaties, één uitzondering waarbij SELECT * maakt niet uit wanneer gebruikt in een EXISTS clausule. Maar waarom zou je * . gebruiken? hier? Ik gebruik liever EXISTS (SELECT 1 ... – de optimizer zal die hetzelfde behandelen, maar op een bepaalde manier documenteert het de code zelf en zorgt het ervoor dat lezers begrijpen dat de subquery geen gegevens retourneert (zelfs als ze de grote EXISTS missen buiten). Sommige mensen gebruiken NULL , en ik heb geen idee waarom ik 1 ben gaan gebruiken, maar ik vind NULL ook een beetje onintuïtief.

*Opmerking* je moet voorzichtig zijn als je EXISTS (SELECT *) probeert te gebruiken binnen een module die schemagebonden is:

CREATE VIEW dbo.ThisWillNotWork
WITH SCHEMABINDING
AS
  SELECT BusinessEntityID
    FROM Person.Person AS p
	WHERE EXISTS (SELECT * FROM Sales.SalesOrderHeader AS h
	  WHERE h.SalesPersonID = p.BusinessEntityID);

U krijgt deze foutmelding:

Verander het echter in SELECT 1 werkt gewoon goed. Dus misschien is dat een ander argument om SELECT * te vermijden zelfs in dat scenario.

A: Er zijn er waarschijnlijk honderden in verschillende talen. Net als naamgevingsconventies zijn coderingsnormen een zeer subjectief iets. Het maakt niet echt uit welke conventie u besluit het beste voor u te werken; als je van tbl houdt voorvoegsels, gek! Geef de voorkeur aan Pascal boven bigEndian, doe het maar. Wilt u uw kolomnamen vooraf laten gaan door het gegevenstype, zoals intCustomerID , ik ga je niet tegenhouden. Het belangrijkste is dat u een conventie definieert en deze *consistent gebruikt.*

Dat gezegd hebbende, als je mijn mening wilt, ik heb er geen gebrek aan.

A: Ik ken geen plannen om XACT_ABORT te beëindigen dus het zou gewoon goed moeten blijven werken. Eerlijk gezegd zie ik dit niet vaak meer worden gebruikt nu we TRY / CATCH hebben (en THROW vanaf SQL Server 2012).

A: Ik heb dit niet getest, maar in veel gevallen kan het vervangen van een scalaire functie door een inline tabelwaardefunctie een grote impact hebben op de prestaties. Het probleem dat ik vind is dat het maken van deze overstap een aanzienlijke hoeveelheid werk kan zijn op een systeem dat is geschreven vóór APPLY bestond, of wordt nog steeds beheerd door mensen die deze betere aanpak niet hebben omarmd.

A: Twee dingen springen in het oog:(1) de vertraging heeft te maken met de compilatietijd of (2) de vertraging heeft te maken met de hoeveelheid gegevens die wordt geladen om aan de vraag te voldoen, en de eerste keer dat deze van schijf moet komen en niet het geheugen. Voor (1) kunt u de query uitvoeren in SQL Sentry Plan Explorer en de statusbalk toont u de compileertijd voor de eerste en volgende aanroepen (hoewel een minuut hiervoor nogal overdreven en onwaarschijnlijk lijkt). Als je geen verschil vindt, dan ligt het misschien aan de aard van het systeem:onvoldoende geheugen om de hoeveelheid gegevens te ondersteunen die je probeert te laden met deze query in combinatie met andere gegevens die al in de bufferpool zaten. Als je niet gelooft dat een van beide het probleem is, kijk dan of de twee verschillende uitvoeringen daadwerkelijk verschillende plannen opleveren - als er verschillen zijn, post de plannen dan op answer.sqlperformance.com en we zullen graag een kijkje nemen . In feite kan het vastleggen van daadwerkelijke plannen voor beide uitvoeringen met Plan Explorer u in ieder geval ook informeren over eventuele verschillen in I/O en kan ertoe leiden dat SQL Server zijn tijd besteedt aan de eerste, langzamere uitvoering.

A: Nee, ik denk niet dat de instelling Optimaliseren voor ad-hocworkloads dit scenario zal helpen, aangezien het snuiven van parameters impliceert dat opeenvolgende uitvoeringen van hetzelfde plan worden gebruikt voor verschillende parameters en met aanzienlijk verschillend prestatiegedrag. Optimaliseren voor ad-hocworkloads wordt gebruikt om de drastische impact op de plancache te minimaliseren die kan optreden wanneer u een groot aantal verschillende SQL-instructies hebt. Dus tenzij je het hebt over de impact op de plancache van veel verschillende instructies die je naar sp_executesql stuurt – wat niet zou worden gekarakteriseerd als het snuiven van parameters – ik denk dat ik aan het experimenteren ben met OPTION (RECOMPILE) kan een beter resultaat hebben of, als u de parameterwaarden kent die *do* goede resultaten opleveren voor verschillende parametercombinaties, gebruikt u OPTIMIZE FOR . Dit antwoord van Paul White geeft misschien een veel beter inzicht.

A: Natuurlijk, voeg gewoon OPTION (RECOMPILE) toe in de dynamische SQL-tekst:

DBCC FREEPROCCACHE;
 
USE AdventureWorks2012;
GO
SET NOCOUNT ON;
GO
 
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderHeader;';
GO
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderDetail OPTION (RECOMPILE);'
GO
 
SELECT t.[text], p.usecounts
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.[plan_handle]) AS t
WHERE t.[text] LIKE N'%Sales.' + 'SalesOrder%';

Resultaten:1 rij met de Sales.SalesOrderHeader vraag.

Nu, als een instructie in de batch GEEN OPTION (RECOMPILE) bevat , het plan kan nog steeds in de cache worden bewaard, het kan alleen niet opnieuw worden gebruikt.

DBCC FREEPROCCACHE(0x06.....);