Proaktive SQL Server-sundhedstjek, del 4:FEJLLOG

Der er så meget, du kan sige om historie og betydning. Historien om et land, om civilisation, om hver enkelt af os. Jeg elsker citater og kan godt lide denne fra Teddy Roosevelt (sej fyr):

Hvorfor bliver jeg poetisk (eller forsøger) om historien i en blog om SQL Server? Fordi historik i SQL Server også er vigtig. Når der eksisterer et ydelsesproblem i SQL Server, er det ideelt at fejlfinde problemet live, men i nogle tilfælde kan historiske oplysninger give en rygende pistol eller i det mindste et udgangspunkt. En stor kilde til historisk information i SQL Server er ERRORLOG. Jeg nævnte i mit oprindelige indlæg, Performance Issues:The First Encounter, at ERRORLOG plejede at være en eftertanke for mig. Ikke mere. Under klientrevision fanger vi altid ERRORLOGS, og selvom vi bliver underrettet om alle advarsler med høj alvorlighed (som er skrevet til loggen), er det ikke uhørt at finde andre interessante oplysninger i loggen. Vi forbereder os på fremtiden ved at bruge de historiske oplysninger i loggene; oplysningerne kan hjælpe os med at løse et problem, eller potentielt problem, før det bliver katastrofalt.

Visning af ERRORLOG

Først og fremmest vil vi gennemgå nogle muligheder for at se ERROLOG. Hvis jeg er forbundet til en instans, vil jeg normalt navigere til den via SSMS (Management | SQL Server Logs, højreklik på en log, og vælg View SQL Server Log). Fra dette vindue kan jeg bare rulle gennem loggen eller bruge indstillingerne Filter eller Søg til at indsnævre resultatsættet. Jeg kan også se flere filer ved at vælge dem i venstre rude.

Hvis jeg ser på data, der er fanget i en af ​​vores sundhedsrevisioner, åbner jeg bare logfilerne i en teksteditor og gennemgår dem (jeg har også mulighed for at gå ind i fremviseren og indlæse dem). Logfilerne findes i logmappen (standardplacering:C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\Log), hvis jeg nogensinde ville se på dem på serveren. Mange af jer foretrækker måske at se og/eller søge i loggen ved hjælp af den udokumenterede procedure sp_readerrorlog eller den udvidede lagrede procedure xp_readerrorlog.

Og endelig, hvis du alle er til PowerShell, er det også en mulighed for at læse loggen på den måde (se dette indlæg:Brug PowerShell til at parse SQL Server 2012 fejllogfiler). Metoden er op til dig – brug det du kender og hvad der virker for dig – det er indholdet, der virkelig betyder noget. Og husk, at der er tidspunkter, hvor du bliver nødt til blot at læse loggen igennem for at forstå rækkefølgen af ​​hændelser, og der er andre tidspunkter, hvor du kan søge for at finde en specifik fejl eller stykke information.

Hvad er der i FEJLLOGGEN?

Så hvilke oplysninger kan vi finde i ERRORLOG, udover fejl? Jeg har listet mange af de ting, jeg har fundet mest nyttige nedenfor. Bemærk, at dette ikke er en udtømmende liste (og jeg er sikker på, at mange af jer vil have forslag til, hvad der kan tilføjes – du er velkommen til at skrive en kommentar, så kan jeg opdatere dette!), men igen, det er det, jeg er leder efter først når jeg proaktivt kigger på en instans.

• Om serveren er fysisk eller virtuel (se efter System Manufacturer-posten)
• Sporingsflag aktiveret ved opstart
  • Hvis du ruller helt til højre i indgangen til registreringsdatabasens startparametre, vil du se, om nogen sporingsflag er aktiveret:
    
    Sporingsflag aktiveret ved opstart
• Sporingsflag aktiveret eller deaktiveret, efter at forekomsten er startet
  • Hvis brugere (eller et program) aktiverer eller deaktiverer et sporingsflag ved hjælp af DBCC TRACEON eller DBCC TRACEOFF, vises en post i loggen
• Antal kerner og sockets fundet af SQL Server
  • Jeg kan altid godt lide at bekræfte, at SQL Server ser al den tilgængelige hardware - og hvis ikke, er det et rødt flag at undersøge nærmere. For et godt eksempel, se Jonathans indlæg, Ydelsesproblemer med SQL Server 0212 Enterprise Edition under CAL-licens, og Glenns indlæg, Balancing Your Available SQL Server Core Licenses Evenly Across NUMA Nodes, som også indeholder nogle praktiske TSQL til at forespørge i loggen.
  • Bemærk, at teksten til denne post varierer mellem SQL Server-versioner.
• Mængden af ​​hukommelse detekteret af SQL Server
  • Igen vil jeg bekræfte, at SQL Server kan se al den hukommelse, der er tilgængelig for den.
• Bekræftelse af, at låste sider i hukommelsen (LPIM) er aktiveret
  • Mens denne mulighed er aktiveret via Windows-sikkerhedspolitikken, kan du bekræfte, at den er aktiveret ved at se efter meddelelsen "Bruger låste sider i hukommelseshåndteringen" i loggen.
  • Bemærk, at hvis du har Trace Flag 834 i brug, vil meddelelsen ikke sige låste sider, men at der bruges store sider til bufferpuljen.
• Version af CLR i brug
• Succes eller mislykket registrering af Service Principal Name (SPN)
• Hvor lang tid tager det for en database at komme online
  • Loggen registrerer, hvornår databasen starter op, og når den er online – jeg tjekker, om en database tager for lang tid at komme op.
• Status for Service Broker og Database Mirroring-slutpunkter – vigtigt, hvis du bruger begge funktioner
• Bekræftelse af, at Instant File Initialization (IFI) er aktiveret*
  • Som standard logges disse oplysninger ikke, men hvis du aktiverer Trace Flag 3004 (og 3605 for at tvinge output til loggen), når du opretter eller dyrker en datafil, vil du se meddelelser i loggen for at angive, om IFI er i brug eller ej.
• Status for SQL-spor
  • Når du starter eller stopper en SQL-sporing, bliver den logget, og jeg ser efter, om der findes spor ud over standardsporingen (enten midlertidigt eller langsigtet). Hvis du kører et tredjepartsovervågningsværktøj, såsom SQL Sentry's Performance Advisor, kan du muligvis se en aktiv sporing, der altid kører, men kun fanger specifikke hændelser, eller du kan muligvis se en sporingsstart, køre i en kort varighed, og derefter hold op. Jeg er ikke bekymret for et eller to ekstra spor, medmindre de fanger en masse begivenheder, men jeg er bestemt opmærksom, når der kører flere spor.
• Sidste gang CHECKDB blev fuldført
  • Denne meddelelse bliver ofte misforstået af folk – når instansen starter op, læser den opstartssiden for hver database og noterer, hvornår CHECKDB sidst kørte. De fleste mennesker læser ikke hele beskeden:
    
    Dato, hvor DBCC CHECKDB sidst blev gennemført korrekt

    Datoen for gennemførelse af CHECKDB er den 11. november 2012, men ERRORLOG-datoen er den 7. juli 2015. Det er vigtigt at forstå, at SQL Server ikke køre CHECKDB mod databaser ved opstart, tjekker den dbcclastknowngood-værdien på opstartssiden (for at se, hvornår den bliver opdateret, tjek mit indlæg, What Checks Update dbcclastknowngood. Desuden, hvis DBCC CHECKDB aldrig er blevet kørt mod en database, er der ingen indgang vil dukke op for databasen her.

• CHECKDB-afslutning
  • Når CHECKDB køres mod en database, bliver outputtet registreret i loggen.
• Ændringer af instansindstillinger
  • Hvis du ændrer indstillinger på instansniveau (f.eks. maks. serverhukommelse, omkostningstærskel for parallelitet) ved hjælp af sp_configure eller gennem brugergrænsefladen (bemærk, at den ikke logger hvem ændret det).

• Ændringer af databaseindstillinger
  • Er der nogen, der har aktiveret AUTO_SHRINK? Ændre GENDANNELSE til SIMPLE og derefter tilbage til FULD? Du finder den her.
• Ændringer af databasestatus
  • Hvis nogen tager en database OFFLINE (eller bringer den ONLINE), bliver denne logget.
• Deadlock-oplysninger*
  • Hvis du har brug for at fange oplysninger om dødvande, skal du ikke køre et spor, og du kører SQL Server 2005 til 2008R2, skal du bruge sporingsflag 1222 til at skrive deadlock-oplysninger til loggen i XML-format. For dem af jer, der bruger SQL Server 2000 og derunder, kan du spore flag 1204 (dette sporingsflag er også tilgængelig i SQL Server 2005+, men det udsender minimal information). Hvis du kører SQL Server 2012 eller højere, er dette ikke nødvendigt, da system_health-hændelsessessionen fanger disse oplysninger (og det er der også i 2008 og 20082, men du skal trække det fra ring_buffer versus event_file-målet).
• FlushCache-meddelelser
  • Hvis cachen bliver tømt af SQL Server, fordi checkpoint-processen overskrider gendannelsesintervallet for databasen, vil du se et sæt FlushCache-meddelelser i loggen (se dette indlæg af Bob Dorr for mere information). Forveksle ikke disse meddelelser med dem, der dukker op, når du kører DBCC FREEPROCCACHE eller DBCC FREESYSTEMCACHE:
    
    Besked efter at have kørt DBCC FREEPROCCACHE eller DBCC FREESYSTEMCACHE

• AppDomain unload beskeder
  • Loggen noterer også, hvornår AppDomains er oprettet, og du vil kun se enten, hvis du bruger CLR. Hvis jeg ser AppDomain unload beskeder på grund af hukommelsestryk, er det noget at undersøge nærmere.

Der er andre oplysninger i loggen, der er nyttige, såsom godkendelsestilstand i brug, om den dedikerede administratorforbindelse (DAC) er aktiveret, osv., men jeg kan også få det fra sys.configurations, og jeg tjekker dem med instansens basislinjer Jeg diskuterede tidligere (Proaktive SQL Server-sundhedstjek, del 3:Forekomst- og databaseindstillinger).

Hvad er der ikke i ERROLOG, som du måske forventer?

Dette er en kort liste, for nu, da jeg gætter på, at nogle af jer måske har fundet andre ting, som du troede ville være i loggen, men ikke var...

• Tilføjelse eller fjernelse af databasefiler eller filgrupper
• Start eller stop af udvidede begivenhedssessioner
  • Men hvis du implementerer en DDL-udløser eller hændelsesmeddelelse på serverniveau, kan du logge disse oplysninger. Se Jonathans indlæg, Logning af udvidede hændelser, ændringer til ERRORLOG, for flere detaljer.
• Kørsel af DBCC DROPCLEANBUFFERS vises i ERRORLOG

Administration af loggen

Husk, at SQL Server som standard kun beholder de seneste seks (6) logfiler (ud over den aktuelle fil), og logfilen ruller over, hver gang SQL Server genstarter. Som et resultat kan du nogle gange have ekstremt store logfiler, som tager et stykke tid at åbne og som er en smerte at grave igennem. På bagsiden, hvis du støder på en sag, hvor instansen genstartes et par gange, kan du miste vigtig information. Det anbefales at øge antallet af bevarede filer til en højere værdi (f.eks. 30) og oprette et agentjob til at rulle over filen en gang om ugen ved hjælp af sp_cycle_errorlog.

Udover at administrere filerne kan du påvirke, hvilke oplysninger der skrives til loggen. En af de mest almindelige poster, der skaber rod i ERRORLOG, er den vellykkede sikkerhedskopi:

Sikkerhedskopieringen er gennemført

Hvis du har en instans med adskillige databaser og sikkerhedskopier af transaktionslogfiler tages med en hvilken som helst regelmæssighed (f.eks. hvert 15. minut), vil du se loggen hurtigt blive fyldt op med meddelelser, hvilket gør det sværere at finde et sandt problem. Heldigvis kan du bruge sporingsflag 3226 til at deaktivere vellykkede sikkerhedskopieringsmeddelelser (fejl vil stadig dukke op i loggen, og alle poster vil stadig eksistere i msdb).

Et andet sæt meddelelser, der roder i loggen, er vellykkede login-beskeder. Dette er en mulighed, du konfigurerer for forekomsten på fanen Sikkerhed:

Sikkerhedsmulighed for at logge succesfulde og/eller mislykkede logins

Hvis du logger succesfulde logins, eller mislykkede og succesfulde logins, kan du have meget store logfiler, selvom du ruller filerne dagligt (det vil afhænge af, hvor mange brugere der forbinder). Jeg anbefaler kun at fange mislykkede logins. For virksomheder, der har et krav om at logge succesfulde logins, kan du overveje at bruge revisionsfunktionen, tilføjet i SQL Server 2008. Sidebemærkning:Hvis du ændrer indstillingen for login-revision, træder den ikke i kraft, før du genstarter forekomsten.

Undervurder ikke FEJLLOGGEN

Som du kan se, er der nogle gode oplysninger i ERRORLOG, som du kan bruge, ikke kun når du fejlfinder ydeevne eller undersøger fejl, men også når du proaktivt overvåger en instans. Du kan finde oplysninger i loggen, som ikke findes andre steder; sørg for, at du tjekker det regelmæssigt og ikke efterlader det som en eftertanke.

Se de andre dele i denne serie:

• Del 1:Diskplads
• Del 2:Vedligeholdelse
• Del 3:Indstillinger for forekomst og database