Uppföljning av Summer Performance Palooza 2013

Den 27 juni höll PASS Performance Virtual Chapter sin 2013 Summer Performance Palooza – en sorts nedskalad 24 Hours of PASS, men fokuserade enbart på prestationsrelaterade ämnen. Jag höll en session med titeln "10 dåliga vanor som kan döda prestation", och behandlade följande 10 koncept:

1. VÄLJ *
2. Blinda index
3. Inget schemaprefix
4. Standardmarköralternativ
5. sp_ prefix
6. Tillåter uppblåst cache
7. Brett datatyper
8. SQL-serverns standardinställningar
9. Överanvändning av funktioner
10. "Fungerar på min maskin"

Du kanske kommer ihåg några av dessa ämnen från sådana presentationer som mitt "Dåliga vanor och bästa praxis"-föreläsning eller våra veckovisa webbseminarier för Query Tuning som jag har varit värd för med Kevin Kline från början av juni till denna vecka. (Dessa 6 videor kommer förresten att finnas tillgängliga i början av augusti på YouTube.)

Min session hade 351 deltagare och jag fick bra feedback. Jag ville ta upp en del av det.

Först ett konfigurationsproblem:jag använde en helt ny mikrofon och hade ingen aning om att varje knapptryckning skulle låta som åska. Jag har åtgärdat det problemet med bättre placering av min kringutrustning, men jag vill be alla som påverkas av det om ursäkt.

Nästa, nedladdningarna; däcket och proverna läggs upp på evenemangsplatsen. De finns längst ner på sidan, men du kan också ladda ner dem här.

Till sist, vad som följer är en lista över frågor som postades under sessionen, och jag ville försäkra mig om att jag tog upp alla som inte besvarades under live Q &A. Jag ber om ursäkt för att jag har klämt in detta på knappt en månad , men det fanns många frågor, och jag ville inte publicera dem i delar.

Svar: Du måste närma dig detta från fall till fall, eftersom det verkligen kommer att bero på en mängd olika faktorer (inklusive planens komplexitet). Observera också att du kan göra omkompilering på satsnivå så att endast de berörda satserna måste ta träffen, i motsats till hela modulen. Paul White påminde mig om att folk ofta "fixar" parametersniffning med RECOMPILE , men alltför ofta betyder det 2000-stil WITH RECOMPILE snarare än det mycket bättre OPTION (RECOMPILE) , som inte bara begränsar sig till satsen, utan även möjliggör parameterinbäddning, som WITH RECOMPILE gör inte. Så om du ska använda RECOMPILE för att förhindra parametersniffning, lägg till det i satsen, inte modulen.

Svar: Som ovan kommer detta att bero på kostnaden och komplexiteten i planerna och det finns inget sätt att säga, "Ja, det kommer alltid att finnas en stor prestationsträff." Du måste också se till att jämföra det med alternativet.

Svar: Jag är inte säker på vad "läsbar i verkligheten" betyder. Om du menar att du vill ha utdata i ett specifikt format är det vanligtvis bättre att konvertera till en sträng på klientsidan. C# och de flesta andra språk som du förmodligen använder i presentationsnivån är mer än kapabla att formatera datum/tid från databasen i vilket regionalt format du vill.

Svar: De flesta DMV:er är endast giltiga sedan den senaste servicestarten, och även andra kan spolas oftare (även på begäran – både av misstag och med avsikt). Plancachen är naturligtvis i konstant förändring, och AFAIK-planer som faller ur cachen behåller inte sin tidigare räkning om de dyker in igen. Så även när du ser en plan i cachen är jag inte 100% säker på att du kan tro på användningstalet du hittar.

Som sagt, det du förmodligen letar efter är sys.dm_exec_cached_plans.usecounts och du kan också hitta sys.dm_exec_procedure_stats.execution_count för att komplettera informationen för procedurer där enskilda uttalanden inom procedurerna inte finns i cachen.

Svar: De största problemen kring detta är möjligheten att använda viss syntax, såsom OUTER APPLY eller variabler med en tabellvärderad funktion. Jag är inte medveten om några fall där användning av en lägre kompatibilitet har någon direkt inverkan på prestanda, men ett par saker som vanligtvis rekommenderas är att bygga om index och uppdatera statistik (och att få din leverantör att stödja den nyare kompatibilitetsnivån ASAP). Jag har sett det lösa oväntad prestandaförsämring i ett stort antal fall, men jag har också hört några åsikter om att det inte är nödvändigt och kanske till och med oklokt.

Svar: Nej, åtminstone när det gäller prestanda, ett undantag där SELECT * spelar ingen roll när den används i en EXISTS klausul. Men varför skulle du använda * här? Jag föredrar att använda EXISTS (SELECT 1 ...). – optimeraren kommer att behandla dem på samma sätt, men på ett sätt dokumenterar den själv koden och säkerställer att läsarna förstår att underfrågan inte returnerar någon data (även om de missar den stora EXISTS utanför). Vissa människor använder NULL , och jag har ingen aning om varför jag började använda 1, men jag hittar NULL lite ointuitivt också.

*Obs* du måste vara försiktig om du försöker använda EXISTS (SELECT * inuti en modul som är schemabunden:

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 det här felet:

Ändrar dock den till SELECT 1 fungerar bra. Så det kanske är ytterligare ett argument för att undvika SELECT * även i det scenariot.

Svar: Det finns förmodligen hundratals över en mängd olika språk. Liksom namnkonventioner är kodningsstandarder en mycket subjektiv sak. Det spelar egentligen ingen roll vilken konvention du bestämmer dig för fungerar bäst för dig; om du gillar tbl prefix, bli galen! Föredrar Pascal framför bigEndian, ha det. Vill du prefixa dina kolumnnamn med datatypen, som intCustomerID , jag tänker inte stoppa dig. Det viktigaste är att du definierar en konvention och använder den *konsekvent.*

Som sagt, om du vill ha mina åsikter har jag ingen brist på dem.

Svar: Jag känner inte till några planer på att fasa ut XACT_ABORT så det borde fortsätta fungera bra. Ärligt talat ser jag inte att detta används så ofta nu när vi har TRY / CATCH (och THROW från och med SQL Server 2012).

Svar: Jag testade inte detta, men i många fall kan det ha stor inverkan på prestandan att ersätta en skalär funktion med en inline-tabellvärderad funktion. Problemet jag upptäcker är att att göra den här växlingen kan vara en stor mängd arbete på systemet som skrevs innan APPLY existerade, eller fortfarande hanteras av folk som inte har anammat detta bättre tillvägagångssätt.

Svar: Två saker hoppar på:(1) fördröjningen har att göra med kompileringstiden eller (2) fördröjningen har att göra med mängden data som laddas för att tillfredsställa frågan, och första gången den måste komma från disken och inte minne. För (1) kan du köra frågan i SQL Sentry Plan Explorer och statusfältet visar dig kompileringstid för de första och efterföljande anropen (även om en minut verkar ganska överdriven för detta, och osannolikt). Om du inte hittar någon skillnad kan det bara vara systemets natur:otillräckligt minne för att stödja mängden data du försöker ladda med den här frågan i kombination med annan data som redan fanns i buffertpoolen. Om du inte tror att något av dessa är problemet, se om de två olika avrättningarna faktiskt ger olika planer – om det finns några skillnader, lägg upp planerna på answers.sqlperformance.com så tar vi gärna en titt . Faktum är att fånga faktiska planer för båda körningarna med Plan Explorer i alla fall kan också informera dig om eventuella skillnader i I/O och kan leda till var SQL Server spenderar sin tid på den första, långsammare körningen.

Svar: Nej, jag tror inte att inställningen Optimera för ad hoc-arbetsbelastningar kommer att hjälpa detta scenario, eftersom parametersniffning innebär att efterföljande körningar av samma plan används för olika parametrar och med signifikant olika prestandabeteenden. Optimera för ad hoc-arbetsbelastningar används för att minimera den drastiska inverkan på planens cache som kan inträffa när du har ett stort antal olika SQL-satser. Så om du inte talar om påverkan på plancachen för många olika uttalanden som du skickar till sp_executesql – som inte skulle karakteriseras som parametersniffning – jag tror att experimentera med OPTION (RECOMPILE) kan ha ett bättre resultat eller, om du känner till de parametervärden som *gör* ger bra resultat över en mängd olika parameterkombinationer, använd OPTIMIZE FOR . Detta svar från Paul White kan ge mycket bättre insikt.

Svar: Visst, inkludera bara OPTION (RECOMPILE) i den dynamiska SQL-texten:

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%';

Resultat:1 rad som visar Sales.SalesOrderHeader fråga.

Nu, om någon sats i partiet INTE inkluderar OPTION (RECOMPILE) , planen kan fortfarande vara cachad, den kan bara inte återanvändas.

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