Hej, jeg hedder Curt. Jeg er seniorchefingeniør og arbejder med GSE-teamet.
I denne video diskuteres SQL Server-fejlloggen. Hvor den er placeret, hvilke oplysninger den indeholder, og hvorfor den kan hjælpe os med fejlfinding af problemer med Microsoft SQL Server.
Så den hurtigste måde, vi normalt kan få adgang til loggen på, går gennem Microsoft SQL Server Management Studio.
Hvis vi går ned til objektbeholderen "Management" og derefter ned til "SQL Server-logfiler", kan vi se de tilgængelige fejllogfiler, som SQL Server har indsamlet til denne installation af SQL.
SQL indeholder seks arkivlogfiler over tidligere hændelser, der er indtruffet på serveren. Den aktuelle log er den, der indsamler alle oplysninger siden sidste genstart af SQL Server, og fejlloggen regenereres, hver gang SQL Server genstartes.
Så ved at se på den aktuelle log for at give dig en idé om nogle af de ting, som vi kan forvente at se her. Det første element, vi ser, er installationstypen for SQL Server, i dette tilfælde er det SQL Server 2019.
Det giver os også produktversionsoplysninger. I dette tilfælde arbejder vi med en grundlæggende RTM-installation af SQL Server. Vi får også OS-oplysninger.
I dette tilfælde har vi at gøre med en Workstation-installation af Windows 10. Når du bevæger dig gennem loggen, og hvad du ser i Studio Management, registreres de tidligste begivenheder nederst i loggen, som den vises, og de seneste begivenheder er nær toppen af loggen.
Når vi arbejder igennem eller kigger gennem loggen, ser vi ting som godkendelsestilstanden, der er blandet, vi ser den faktiske placering af fejlloggen - dette er standardplaceringen for fejllogprogramfilerne / Microsoft SQL-serveren og installationsmappen for selve SQL-forekomsten.
Vi kan også se oplysningerne om den tjenestekonto, der blev brugt til at starte SQL Server. En anden post, der kan være vigtig, er startparametrene, standardplaceringen, som SQL i øjeblikket har til databasefilerne, også placeringen af fejlloggen igen og også de logfiler, vi ser for SQL Server.
Vi får også oplysninger om kernerne på systemet, hvor mange tilgængelige processorer SQL kan bruge, og også mængden af tilgængelig hukommelse, som SQL ser på det fysiske niveau, når systemet startes op.
Andre oplysninger, der følger, er, at systemdatabasen kommer online, hvis vi har brugerproduktionsdatabaser, ser vi også disse oplysninger, men det mest bemærkelsesværdige ved SQL-serverfejlloggen og dens største fordel er faktisk at returnere oplysninger om fejl, der ses af SQL-serveren.
Og dette kan ikke kun være en opstartstid, men i hele levetiden for tjenesten, der kører. Så vi har en fejl her, der er ret ubetydelig, men den henviser til Polybase, Polybase-konfigurationen på systemet.
Faktisk blev Polybase ikke installeret med dette, der er ingen Polybase-konfigurationsoplysninger, så dette er igen et ikke-problem for denne installation, men dette er et eksempel på en meddelelse, som vi ser som en fejl.
For nu at komme lidt mere i detaljer om, hvor fejlloggen kan være yderst gavnlig, er for eksempel når SQL Server ikke starter.
Så denne særlige logfil er den forrige logfil, jeg havde til vores aktuelle logfil, og SQL Server i dette startforsøg startede faktisk ikke.
Og dette er en fabrikeret fejl, og den måde, jeg fremstillede denne fejl på, var, at jeg flyttede placeringen af modeldatabasen, som er en systemdatabase.
Det er en skabelondatabase til alle databaser, der oprettes af SQL Server. Når SQL Server starter, skal den starte op og bruge en tempdb-database, og modeldatabasen er skabelonen for tempdb.
Så uden en modeldatabase kunne tempdb ikke starte, eller kunne ikke komme online, og SQL Server-tjenesten kunne ikke starte.
Dette er et eksempel på, hvad vi ville se i fejlloggen. Vi ville se fejlen, vi ville se flere oplysninger om, hvorfor fejlen blev genereret - i dette tilfælde kunne den ikke finde en databasefil, modeldatabasefilen - og senere vil den fortælle os, at den ikke kunne finde modeldatabasens logfil, hvilket betyder, at tempdb-databasen ikke kunne oprettes.
Så dette er den dårlige nyhed, at fejlloggen kan vende tilbage til dig for at give dig oplysninger om, hvordan du foretager fejlfinding af dit problem.
Nu skal vi huske på, at når vi ser en post for en fejl som denne, vil den også blive inkluderet i applikationslogfilerne.
Vi ser, at den samme hændelse registreres i systemprogramloggen, og den første fejlmeddelelse, vi ser, fortæller os, at databasefilen ikke blev fundet, og den anden fortæller os, at logfilen ikke blev fundet.
Så endnu en gang et fremstillet eksempel på en fejl, selvfølgelig kan dette være meget kritisk for dig, hvis du fejlfinder et problem i det virkelige liv.
Hvis en større databasefil f.eks. er beskadiget, f.eks. modeldatabasen, starter tjenesten til SQL ikke, og det er det område, du får oplysninger om for at få mere at vide om det og foretage fejlfinding af det.
Så nok om indholdet af fejlloggen. Vi kan også få adgang til fejllogfilerne live i filstifinder. Og endnu en gang skal vi kende filplaceringen af fejlloggen, det så vi i selve fejlloggen.
Vi ved, at dette er, at den er placeret på standardplaceringen for fejlloggen, og den er i logmappen for den pågældende installation af SQL Server.
Se altid de samme oplysninger - vi får valget af den teksteditor, du vil bringe den op med. Endnu en gang er udsigten anderledes.
Her er de tidligste hændelser øverst i loggen, når man ser på selve den rå log, og de seneste er nederst.
Der er en anden måde at finde fejllogplaceringen på, og det er at gå til programinstallationen fra Start-menuen for den forekomst af SQL Server.
Når vi går ind her, går vi til 'SQL Server Configuration Manager'. Configuration Manager viser alle tjenesterne til denne installation af SQL.
Hvis vi går til 'SQL Server Service', højreklik på det, gå til 'Egenskaber', 'Startparametre', er parameteren '-e', hvor fejlloggen er placeret.
Og nogle gange er det virkelig vigtigt at forstå dette, fordi du måske ikke har en installation af Studio Management at se på.
Hvis du ikke gør det, skal du begynde at tænke på alle de mulige drevplaceringer, der er tilgængelige for den pågældende installation af SQL.
Mange gange kan du blot skære til jagten, gå ind i Configuration Manager, finde disse opstartsparametre, og når du gør det, kan du finde ud af præcis, hvor fejlloggen er placeret.
Okay, det afslutter vores kig på SQL Server-fejlloggen. Jeg håber, at denne video hjalp dig med at forstå, hvor du kan finde loggen, og hvordan den kan hjælpe dig med fejlfinding af Microsoft SQL Server.
Tak, fordi du så med, og farvel.
