Opfølgning på Summer Performance Palooza 2013

Den 27. juni afholdt PASS Performance Virtual Chapter sin 2013 Summer Performance Palooza - en slags nedskaleret 24 Hours of PASS, men fokuserede udelukkende på præstationsrelaterede emner. Jeg holdt en session med titlen "10 dårlige vaner, der kan dræbe ydeevne", hvor jeg behandlede følgende 10 begreber:

1. VÆLG *
2. Blindindekser
3. Intet skemapræfiks
4. Standardmarkørindstillinger
5. sp_ præfiks
6. Tillader cache-bloat
7. Vide datatyper
8. SQL-serverstandarder
9. Overbrug af funktioner
10. "Virker på min maskine"

Du husker måske nogle af disse emner fra sådanne præsentationer som min "Dårlige vaner og bedste praksis"-foredrag eller vores ugentlige Query Tuning-webinarer, som jeg har været vært for med Kevin Kline fra begyndelsen af ​​juni til denne uge. (De 6 videoer vil i øvrigt være tilgængelige i begyndelsen af ​​august på YouTube.)

Min session havde 351 deltagere, og jeg fik god feedback. Jeg ville tage fat på noget af det.

Først et konfigurationsproblem:Jeg brugte en helt ny mikrofon og anede ikke, at hvert tastetryk ville lyde som torden. Jeg har løst det problem med en bedre placering af mine perifere enheder, men jeg vil gerne undskylde til alle, der er berørt af det.

Dernæst downloads; dækket og prøverne sendes til begivenhedsstedet. De er nederst på siden, men du kan også downloade dem lige her.

Til sidst er det følgende en liste over spørgsmål, der blev stillet under sessionen, og jeg ville være sikker på, at jeg tog fat på dem, der ikke blev besvaret under live Q &A. Jeg undskylder, at jeg har presset dette ind på knap en måned , men der var en masse spørgsmål, og jeg ønskede ikke at offentliggøre dem i dele.

A: Du bliver nødt til at gribe dette an fra sag til sag, da det virkelig vil afhænge af en række forskellige faktorer (herunder planens kompleksitet). Bemærk også, at du kan lave omkompilering på sætningsniveau, således at kun de berørte sætninger skal tage hit, i modsætning til hele modulet. Paul White mindede mig om, at folk ofte 'retter' parametersniffing med RECOMPILE , men alt for ofte betyder det 2000-stil WITH RECOMPILE snarere end den meget bedre OPTION (RECOMPILE) , som ikke kun begrænser sig til sætningen, men også muliggør parameterindlejring, som WITH RECOMPILE gør ikke. Så hvis du vil bruge RECOMPILE for at forhindre parametersniffing, føj det til sætningen, ikke modulet.

A: Som ovenfor vil dette afhænge af omkostningerne og kompleksiteten af ​​planerne, og der er ingen måde at sige, "Ja, der vil altid være et stort præstationshit." Du skal også være sikker på at sammenligne det med alternativet.

A: Jeg er ikke sikker på, hvad "læsbar i den virkelige verden" betyder. Hvis du mener, at du vil have output i et bestemt format, er du normalt bedre stillet til at konvertere til en streng på klientsiden. C# og de fleste af de andre sprog, du sandsynligvis bruger på præsentationsniveauet, er mere end i stand til at formatere dato/klokkeslæt output fra databasen i det regionale format, du ønsker.

A: De fleste DMV'er er kun gyldige siden sidste servicestart, og selv andre kan skylles hyppigere (selv efter behov – både utilsigtet og med vilje). Plancachen er selvfølgelig i konstant forandring, og AFAIK-planer, der falder ud af cachen, bevarer ikke deres tidligere optælling, hvis de dukker ind igen. Så selv når du ser en plan i cachen, er jeg ikke 100% sikker på, at du kan tro på det antal brug, du finder.

Når det er sagt, er det, du sandsynligvis leder efter, sys.dm_exec_cached_plans.usecounts og du kan også finde sys.dm_exec_procedure_stats.execution_count for at hjælpe med at supplere information til procedurer, hvor individuelle udsagn inden for procedurerne ikke findes i cachen.

A: De største bekymringer omkring dette er evnen til at bruge bestemt syntaks, såsom OUTER APPLY eller variabler med en funktion med tabelværdi. Jeg er ikke bekendt med nogen tilfælde, hvor brug af en lavere kompatibilitet har nogen direkte indvirkning på ydeevnen, men et par ting, der typisk anbefales, er at genopbygge indekser og opdatere statistik (og at få din leverandør til at understøtte det nyere kompatibilitetsniveau ASAP). Jeg har set det løse uventet ydeevneforringelse i et betydeligt antal tilfælde, men jeg har også hørt nogle meninger om, at det ikke er nødvendigt og måske endda uklogt.

A: Nej, i det mindste med hensyn til ydeevne, en undtagelse hvor SELECT * det er ligegyldigt, når det bruges i en EXISTS klausul. Men hvorfor ville du bruge * her? Jeg foretrækker at bruge EXISTS (SELECT 1 ...). – optimeringsværktøjet vil behandle dem på samme måde, men på en måde selvdokumenterer den koden og sikrer, at læserne forstår, at underforespørgslen ikke returnerer nogen data (selvom de går glip af den store EXISTS uden for). Nogle mennesker bruger NULL , og jeg aner ikke hvorfor jeg begyndte at bruge 1, men jeg finder NULL også lidt uintuitivt.

*Bemærk* du skal være forsigtig, hvis du prøver at bruge EXISTS (SELECT *) inde i et modul, der er skemabundet:

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);

Du får denne fejl:

Men ved at ændre det til SELECT 1 fungerer fint. Så måske er det endnu et argument for at undgå SELECT * selv i det scenarie.

A: Der er sandsynligvis hundredvis på tværs af en række forskellige sprog. Ligesom navnekonventioner er kodningsstandarder en meget subjektiv ting. Det er lige meget, hvilken konvention du beslutter, der fungerer bedst for dig; hvis du kan lide tbl præfikser, gå amok! Foretrækker Pascal frem for bigEndian, tag det. Ønsker at præfikse dine kolonnenavne med datatypen, såsom intCustomerID , jeg vil ikke stoppe dig. Det vigtigere er, at du definerer en konvention og anvender den *konsekvent.*

Når det er sagt, hvis du vil have mine meninger, så mangler jeg dem ikke.

A: Jeg kender ikke til nogen planer om at udfase XACT_ABORT så det burde fortsætte med at fungere fint. Helt ærligt ser jeg ikke dette brugt så ofte nu, hvor vi har TRY / CATCH (og THROW fra SQL Server 2012).

A: Jeg testede ikke dette, men i mange tilfælde kan det have stor indflydelse på ydeevnen at erstatte en skalarfunktion med en inline-tabel-vurderet funktion. Problemet, jeg finder, er, at det kan være en betydelig mængde arbejde på systemet, der blev skrevet før APPLY at lave denne switch. eksisteret eller stadig administreres af folk, der ikke har taget denne bedre tilgang til sig.

A: To ting kommer til at tænke på:(1) forsinkelsen har at gøre med kompileringstiden eller (2) forsinkelsen har at gøre med mængden af ​​data, der indlæses for at tilfredsstille forespørgslen, og første gang det skal komme fra disken og ikke hukommelse. For (1) kan du udføre forespørgslen i SQL Sentry Plan Explorer, og statuslinjen vil vise dig kompileringstid for de første og efterfølgende påkaldelser (selvom et minut virker ret overdrevent for dette og usandsynligt). Hvis du ikke finder nogen forskel, er det måske bare systemets natur:utilstrækkelig hukommelse til at understøtte mængden af ​​data, du forsøger at indlæse med denne forespørgsel i kombination med andre data, der allerede var i bufferpuljen. Hvis du ikke tror på, at nogen af ​​disse er problemet, så se, om de to forskellige henrettelser rent faktisk giver forskellige planer – hvis der er forskelle, så send planerne til answers.sqlperformance.com, og vi vil med glæde tage et kig . Faktisk kan indfangning af faktiske planer for begge eksekveringer ved hjælp af Plan Explorer under alle omstændigheder også fortælle dig om eventuelle forskelle i I/O og kan føre til, hvor SQL Server bruger sin tid på den første, langsommere kørsel.

A: Nej, jeg tror ikke, at indstillingen Optimer til ad hoc-arbejdsbelastninger vil hjælpe dette scenarie, da parametersniffing indebærer, at efterfølgende eksekveringer af den samme plan bruges til forskellige parametre og med væsentligt forskellig præstationsadfærd. Optimer til ad hoc-arbejdsbelastninger bruges til at minimere den drastiske indvirkning på planens cache, der kan ske, når du har et stort antal forskellige SQL-sætninger. Så medmindre du taler om indvirkning på plan-cachen af ​​mange forskellige udsagn, du sender til sp_executesql – som ikke ville blive karakteriseret som parametersniffing – jeg tror, ​​at eksperimentere med OPTION (RECOMPILE) kan have et bedre resultat, eller hvis du kender de parameterværdier, der *gør* giver gode resultater på tværs af en række parameterkombinationer, skal du bruge OPTIMIZE FOR . Dette svar fra Paul White kan give meget bedre indsigt.

A: Selvfølgelig, inkluder bare OPTION (RECOMPILE) i den dynamiske 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%';

Resultater:1 række, der viser Sales.SalesOrderHeader forespørgsel.

Nu, hvis en sætning i batchen IKKE inkluderer OPTION (RECOMPILE) , planen kan stadig være cachelagret, den kan bare ikke genbruges.

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