Som DBA er håndtering af præstationsproblemer ofte en reaktiv begivenhed; problemet opstår, skal du svare. Nogle gange ser du på en SQL Server-instans, som du kender godt, andre gange kan det være dit første møde med et miljø. Dette sker også i konsulentverdenen. Når jeg hjælper en langsigtet kunde, har jeg allerede oplysningerne om miljøet arkiveret. Men når vi får en mail fra en, som vi ikke har arbejdet sammen med før, og det er en nødsituation, hvor de vil have øjeblikkelig hjælp, har vi ingen baggrund om miljøet og har ingen idé om, hvad vi går ind i. Vi yder assistance uden at gå igennem den omfattende dataindsamlings- og analyseproces, der starter hver ny kundeengagement.
Af denne grund har jeg et sæt på fem elementer, som jeg tjekker med det samme, når jeg konfronterer et nyt miljø. De oplysninger, jeg indsamler, sætter scenen for, hvordan jeg griber fejlfinding an fremadrettet, og mens den sjældent identificerer DEN specifikt problem, hjælper det mig med at udelukke, hvad der er IKKE problemet, som nogle gange er lige så vigtigt.
Dataindsamlingsmetoder
Jeg erkender, at alle har en anden tilgang, når de tackler et nyt miljø. Der er adskillige gratis, bredt tilgængelige scripts, som du kan downloade og køre for at give dig "landskabet" for en SQL Server-instans (Glenn Berrys DMV-scripts kommer til at tænke på). Fokus her er ikke hvordan du indsamler dataene, er det hvad data, du indsamler, og hvad du analyserer først .
Serveregenskaber
Det allerførste, jeg vil vide, når jeg ser på en instans, er SQL Server-versionen og -udgaven. Den hurtigste måde at få disse oplysninger på er at udføre:
SELECT @@VERSION;
Med dette output kan jeg kontrollere bygningen for at bestemme de anvendte servicepakker, kumulative opdateringer og hotfixes, og jeg ved, hvilken udgave der bruges. Jeg kan også godt lide at vide, om instansen er klynget, så jeg udfører også:
SELECT SERVERPROPERTY('IsClustered'); Jeg har nogle gange disse oplysninger fra kunden, men det skader aldrig at verificere, da version og udgave kan påvirke efterfølgende fejlfindingstrin og anbefalinger. For eksempel kontaktede en klient os for nylig om et intermitterende ydelsesproblem, de så med SQL Server 2008. Et hurtigt tjek af versionen afslørede, at de kørte SQL Server 2008 SP3, og der var flere kumulative opdateringer udgivet efter SP3, der adresserede en række af præstationsproblemer. Selvom jeg indsamlede flere oplysninger, før jeg anbefalede, at de skulle anvende den seneste CU, var dette et øjeblikkeligt rødt flag for, hvad der kan forårsage problemet.
sys.configurations
Denne katalogvisning hjælper med at bygge videre på det grundlag, der startede med serveregenskaber, og hjælper os med at forstå, hvordan instansen er konfigureret. Med denne visning leder jeg efter indstillinger, der er blevet ændret fra standardindstillingerne, men som ikke burde have været det, og dem, der er ikke blevet ændret, men burde.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Overvej indstillingen for maksimal serverhukommelse (MB), som begrænser mængden af tilgængelig hukommelse til bufferpuljen. Standardværdien er 2147483647, men den bør ændres til en værdi, der er mindre end den samlede hukommelse på serveren for at sikre, at der er masser af hukommelse til OS, andre applikationer og andre SQL Server-opgaver, der kræver hukommelse, der ikke er taget fra bufferpuljen . Til vejledning om indstilling af den passende værdi for max serverhukommelse (MB), anbefaler jeg Jonathans indlæg, Hvor meget hukommelse har min SQL Server egentlig brug for?
Omvendt har prioritetsboost-indstillingen en standard på nul og bør altid stå som sådan. Faktisk anbefaler Microsoft ikke at ændre det, og muligheden vil blive fjernet i en fremtidig udgivelse af SQL Server.
sys.databases
Når jeg har forstået, hvordan forekomsten er konfigureret, ser jeg næste gang for at se, hvad der findes på databaseniveau.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Når jeg tjekker outputtet af denne katalogvisning, leder jeg efter anti-mønstre - alt, der springer ud som uventet eller atypisk - i dataene. Outputtet er befordrende for hurtig analyse - mange af indstillingerne angiver en 0 eller 1 for værdien (fra eller til), og jeg noterer mig, hvad der er anderledes. Jeg forventer, at automatisk oprettelse af statistik og automatisk opdatering af statistik er aktiveret (indstillet til 1). Jeg forventer, at automatisk lukning og automatisk krympning er deaktiveret (indstillet til 0). Jeg ser for at se, hvad sorteringen er for brugerdatabaserne, specifikt om de alle har den samme sortering, og om denne sortering er den samme som tempdb. Jeg bemærker også sikkerhedsindstillinger såsom krydsdatabase-kæde og is_trustworthy-indstillingen, begge deaktiveret (0) som standard. Hvis jeg opdager, at nogen af disse indstillinger afviger fra, hvad jeg forventer, noterer jeg det og går videre. Jeg stopper på intet tidspunkt min indsamling eller analyse for at lave en ændring, da jeg simpelthen indsamler information så hurtigt som muligt for at få en god forståelse af miljøet.
Udover at tjekke indstillingerne for databaserne, noterer jeg mig også antallet af brugerdatabaser. Der er ikke noget "rigtigt antal" af brugerdatabaser for en instans – en instans kan klare sig dårligt med én database, og den kan klare sig fantastisk med 100. Der er et utal af faktorer, der spiller ind, og antallet af databaser er simpelthen et datapunkt værd at bemærke.
Fejllogs
Jeg indrømmer, jeg plejede at forsømme SQL Server ERRORLOG; det var som en eftertanke, da jeg undersøgte et SQL Server-problem. Så indså jeg fejlen i mine måder, og jeg har ikke taget det for givet siden. Jeg har en tendens til at navigere gennem Management Studio for at få adgang til loggen (indenfor Management | SQL Server Logs), selvom du kan bruge den lagrede sp_readerrorlog-procedure eller browse ud til filen og åbne den dit foretrukne tekstredigeringsprogram.
I ERRORLOG søger jeg efter nylige fejl – for eksempel alt relateret til hukommelse – og jeg ser også efter, hvilke sporingsflag, hvis nogen, der er i brug. Jeg tjekker også for at se, om Lås sider i hukommelsen er aktiveret, om cachen tømmes (enten med vilje eller ej), og om nogen anden usædvanlig aktivitet forekommer med regelmæssighed. Afhængigt af hvor påtrængende problemet er, ser jeg også på Windows-logfilerne (hændelse, applikation og sikkerhed), igen og leder ikke kun efter fejl, men også uventede meddelelsesmønstre.
Ventstatistik
Det sidste område af SQL Server, som jeg gennemgår, når jeg ser på et ydeevneproblem på en ukendt forekomst, er ventestatistikker. Hver SQL Server-instans vil have ventetider – uanset hvor godt tunet koden er, uanset hvor meget hardware der ligger bag den. Som DBA vil du gerne vide, hvad dine typiske ventetider er for en instans, og når jeg kigger på et nyt miljø, ved jeg ikke umiddelbart, om de ventetider, jeg ser, er typiske, eller på grund af præstationsproblemet. Jeg spørger kunden, om de baseline ventestatistikker, og hvis ikke, spørger jeg, om jeg kan rydde dem og lade dem begynde at akkumulere, mens ydeevneproblemet opstår. For at tjekke ventestatistikker kan du bruge scriptet i Paul Randals ofte refererede indlæg eller versionen i Glenns DMV-forespørgsler.
Når du har gennemgået de akkumulerede ventestatistikker, vil du have den sidste brik, der giver det "store billede" af SQL Server-forekomsten og de oplysninger, du har brug for for at starte fejlfinding. Det er ikke ualmindeligt at tjekke ventestatistikker først ved fejlfinding, men ventetider alene er ikke nok information til at bestemme, hvad du skal undersøge næste gang, medmindre du også forstår den grundlæggende SQL Server-konfiguration.
Næste trin
Som jeg hentydede til tidligere, er der typisk ikke ét stykke data, der fortæller dig, hvor ydeevneproblemet ligger, det er flere datapunkter, der er opnået, der peger dig i den rigtige retning. Hvordan du fanger den information er op til dig, men når du har gennemgået outputtet, bør du have en god forståelse af, hvordan SQL Server-miljøet er konfigureret, og den viden, kombineret med ventestatistikken, kan hjælpe dig med at beslutte, hvad du skal undersøge næste gang. Fejlfinding fungerer bedst med en metodisk tilgang, så start med det grundlæggende, og arbejd dig op, og når du tror, du har fastslået årsagen, skal du grave lidt mere og finde et eller to yderligere beviser, der understøtter dit fund. Når du har disse data, kan du komme med en anbefaling for at hjælpe med at forbedre eller løse problemet.