Som DBA är det ofta en reaktiv händelse att ta itu med prestationsproblem; problem uppstår, du måste svara. Ibland tittar du på en SQL Server-instans som du känner väl, andra gånger kan det vara ditt första möte med en miljö. Detta förekommer även i konsultvärlden. När jag hjälper en långsiktig kund har jag redan uppgifterna om miljön arkiverade. Men när vi får ett mejl från någon som vi inte har arbetat med tidigare, och det är en nödsituation där de vill ha omedelbar hjälp, har vi ingen bakgrund om miljön och har ingen aning om vad vi går in i. Vi tillhandahåller hjälp utan att gå igenom den omfattande datainsamlings- och analysprocessen som inleder varje ny kundengagemang.
Av denna anledning har jag en uppsättning med fem föremål som jag kontrollerar direkt när jag möter en ny miljö. Informationen jag samlar in sätter scenen för hur jag närmar mig felsökning framöver, och även om den sällan pekar ut DEN specifikt problem, det hjälper mig att utesluta vad som är INTE problemet, som ibland är lika viktigt.
Datainsamlingsmetoder
Jag inser att alla har olika inställning när de tar itu med en ny miljö. Det finns flera gratis, allmänt tillgängliga skript som du kan ladda ner och köra för att ge dig "landskapet" för en SQL Server-instans (Glenn Berrys DMV-skript kommer att tänka på). Fokus här är inte hur du samlar in data, det är vad data du samlar in och vad du analyserar först .
Serveregenskaper
Det allra första jag vill veta när jag tittar på en instans är SQL Server-versionen och -utgåvan. Det snabbaste sättet att få denna information är att köra:
SELECT @@VERSION;
Med den här utgången kan jag kontrollera byggnaden för att bestämma servicepaketen, kumulativa uppdateringar och snabbkorrigeringar som tillämpas, och jag vet vilken utgåva som används. Jag vill också veta om instansen är klustrad, så jag kör också:
SELECT SERVERPROPERTY('IsClustered'); Jag har ibland denna information från kunden, men det skadar aldrig att verifiera, eftersom version och utgåva kan påverka efterföljande felsökningssteg och rekommendationer. Till exempel kontaktade en klient oss nyligen angående ett intermittent prestandaproblem som de såg med SQL Server 2008. En snabb kontroll av versionen visade att de körde SQL Server 2008 SP3, och det fanns flera kumulativa uppdateringar som släpptes efter SP3 som hanterade en rad olika prestationsproblem. Även om jag samlade in mer information innan jag rekommenderade att de skulle tillämpa den senaste CU, var detta en omedelbar röd flagga om vad som kan orsaka problemet.
sys.configurations
Denna katalogvy hjälper till att bygga vidare på grunden som startade med serveregenskaper och hjälper oss att förstå hur instansen är konfigurerad. Med den här vyn letar jag efter inställningar som har ändrats från standardinställningarna, men som inte borde ha gjort det, och de som inte har gjort det. har ändrats, men bör.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Tänk på inställningen för max serverminne (MB), som begränsar mängden tillgängligt minne för buffertpoolen. Standardvärdet är 2147483647, men det bör ändras till ett värde som är mindre än det totala minnet på servern för att säkerställa att det finns gott om minne för operativsystemet, andra applikationer och andra SQL Server-uppgifter som kräver minne som inte tas från buffertpoolen . För vägledning om att ställa in lämpligt värde för max serverminne (MB), rekommenderar jag Jonathans inlägg, Hur mycket minne behöver min SQL Server egentligen?
Omvänt har prioritetsförstärkningsinställningen en standard på noll och bör alltid lämnas som sådan. Faktum är att Microsoft rekommenderar att du inte ändrar det, och alternativet kommer att tas bort i en framtida version av SQL Server.
sys.databases
När jag har förstått hur instansen är konfigurerad tittar jag nästa gång för att se vad som finns på databasnivå.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
När jag kontrollerar utdata från den här katalogvyn, letar jag efter antimönster – allt som hoppar ut som oväntat eller atypiskt – i datan. Utdata är gynnsamt för snabb analys - många av inställningarna visar en 0 eller 1 för värdet (av eller på) och jag gör en mental anteckning om vad som är annorlunda. Jag förväntar mig att automatisk skapa statistik och automatisk uppdateringsstatistik ska vara aktiverade (inställd på 1). Jag förväntar mig att automatisk stängning och automatisk krympning är inaktiverad (inställd på 0). Jag tittar för att se vad sorteringen är för användardatabaserna, särskilt om de alla har samma sortering och om den sammanställningen är densamma som tempdb. Jag noterar också säkerhetsalternativ som korsdatabaskedja och alternativet is_trustworthy, båda inaktiverade (0) som standard. Om jag upptäcker att någon av dessa inställningar avviker från vad jag förväntar mig, noterar jag det och går vidare. Jag stoppar inte vid något tillfälle min insamling eller analys för att göra en förändring, eftersom jag helt enkelt samlar in information så snabbt jag kan för att få en bra förståelse för miljön.
Förutom att kontrollera inställningarna för databaserna, så tar jag även del av antalet användardatabaser. Det finns inget "rätt antal" användardatabaser för en instans – en instans kan prestera dåligt med en databas, och den kan prestera fantastiskt med 100. Det finns en myriad av faktorer som spelar in, och antalet databaser är helt enkelt en datapunkt värt att notera.
Felloggar
Jag erkänner, jag brukade försumma SQL Server ERRORLOG; det var som en eftertanke när jag undersökte ett SQL Server-problem. Sedan insåg jag felet i mina vägar, och jag har inte tagit det för givet sedan dess. Jag brukar navigera genom Management Studio för att komma åt loggen (inom Management | SQL Server Logs), även om du kan använda sp_readerrorlog lagrad procedur eller bläddra till filen och öppna den som din favorittextredigerare.
Inom ERRORLOG letar jag efter senaste fel – till exempel allt som har med minne att göra – och jag tittar också för att se vilka spårningsflaggor, om några, som används. Jag kontrollerar också om Lås sidor i minnet är aktiverat, om cachen töms (antingen avsiktligt eller inte) och om någon annan ovanlig aktivitet inträffar med regelbundenhet. Beroende på hur brådskande problemet är, tittar jag också på Windows-loggarna (händelse, applikation och säkerhet), igen och letar inte bara efter fel utan också oväntade meddelandemönster.
Väntestatistik
Det sista området av SQL Server som jag granskar när jag tittar på ett prestandaproblem på en okänd instans är väntestatistik. Varje SQL Server-instans kommer att ha väntan – oavsett hur välinställd koden är, oavsett hur mycket hårdvara som ligger bakom den. Som DBA vill du veta vad dina typiska väntetider är för en instans, och när jag tittar på en ny miljö vet jag inte omedelbart om de väntetider jag ser är typiska, eller på grund av prestandaproblemet. Jag frågar kunden om de väntar med baslinjestatistik, och om inte, frågar jag om jag kan rensa dem och låta dem börja samlas medan prestandaproblemet uppstår. För att kontrollera väntestatistik kan du använda skriptet i Paul Randals ofta refererade inlägg, eller versionen i Glenns DMV-frågor.
När du har granskat den ackumulerade väntestatistiken har du den sista biten som ger den "stora bilden" av SQL Server-instansen och den information du behöver för att börja felsöka. Det är inte ovanligt att först kontrollera väntestatistiken vid felsökning, men bara väntar är inte tillräckligt med information för att avgöra vad du behöver undersöka härnäst om du inte också förstår den grundläggande SQL Server-konfigurationen.
Nästa steg
Som jag antydde tidigare finns det vanligtvis ingen databit som talar om för dig var prestandaproblemet ligger, det är flera datapunkter som erhållits som pekar dig i rätt riktning. Hur du fångar den informationen är upp till dig, men när du väl har granskat resultatet bör du ha en god förståelse för hur SQL Server-miljön är konfigurerad, och den kunskapen, i kombination med väntestatistiken, kan hjälpa dig att bestämma vad du ska undersöka härnäst. Felsökning fungerar bäst med ett metodiskt tillvägagångssätt, så börja med grunderna och arbeta dig fram, och när du tror att du har bestämt grundorsaken, gräv bara lite mer och hitta ytterligare ett eller två bevis som stöder ditt fynd. När du har den informationen kan du ge en rekommendation för att förbättra eller lösa problemet.