Hei, jeg heter Curt. Jeg er senior avdelingsingeniør og jobber med GSE-teamet.
Denne videoen er dedikert til å diskutere feilloggen for SQL Server. Hvor den er plassert, hvilken informasjon den inneholder og hvorfor den kan hjelpe oss med å feilsøke Microsoft SQL Server-problemer.
Den raskeste måten vi normalt kan få tilgang til loggen på, er å gå gjennom Microsoft SQL Server Management Studio.
Hvis vi går til 'Management'-beholderen og deretter ned til SQL Server-logger, ser vi de tilgjengelige feilloggene som SQL Server har samlet inn for denne installasjonen av SQL.
Det er seks arkivlogger som holdes av SQL av tidligere hendelser som har skjedd til dette til serveren. Den gjeldende loggen er den som samler inn all informasjon siden forrige omstart av SQL Server, og feilloggen genereres på nytt hver gang SQL Server startes på nytt.
Så når du ser på gjeldende logg for å gi deg en idé om noen av de tingene som vi kan forvente å se her. Det første elementet vi ser er installasjonstypen for SQL Server, i dette tilfellet er det SQL Server 2019.
Det gir oss også informasjon om produktversjon. I dette tilfellet jobber vi med en grunnleggende RTM-installasjon av SQL Server. Vi får også informasjon om operativsystem.
I dette tilfellet har vi å gjøre med en arbeidsstasjonsinstallasjon av Windows 10. Når du går gjennom loggen og det du ser i Studioadministrasjon, er de tidligste hendelsene registreres nederst i loggen slik den vises, og de siste hendelsene er nær toppen av loggen.
Når vi jobber gjennom, eller ser gjennom loggen, ser vi ting som autentiseringsmodusen som er blandet, vi ser den faktiske plasseringen av feilloggen - dette er standardplasseringen for feilloggprogramfilene/Microsoft SQL-serveren og installasjonsmappen for selve SQL-forekomsten.
Vi ser også informasjonen for tjenestekontoen som ble brukt til å starte SQL Server. En annen oppføring som kan være viktig er oppstartsparametrene, standardplasseringen som SQL for øyeblikket har for databasefilene, også plasseringen av feilloggen igjen, og også loggfilene vi ser for SQL Server.
Vi får også informasjon om kjernene på systemet, hvor mange tilgjengelige prosessorer SQL kan bruke, og også hvor mye tilgjengelig minne SQL ser på det fysiske nivået når systemet startes opp.
Annen informasjon som følger er at systemdatabasen kommer online, hvis vi har brukerproduksjonsdatabaser, ser vi også den informasjonen, men det mest bemerkelsesverdige med SQL-serverfeilloggen og dens største fordel er faktisk å returnere informasjon om feil som ses av SQL-server.
Og dette kan ikke bare være en oppstartstid, men gjennom hele levetiden til tjenesten som kjører. Vi har en feil her som er ganske ubetydelig, men den refererer til Polybase, Polybase-konfigurasjonen på systemet.
Faktisk ble ikke Polybase installert med dette, det er ingen informasjon om Polybase-konfigurasjon, så dette er nok en gang et ikke-problem for denne installasjonen, men dette er et eksempel på en melding som vi ser som en feil.
Nå for å komme inn i litt mer detalj om hvor feilloggen kan være ekstremt gunstig, er for eksempel når SQL Server ikke starter.
Denne loggen er den forrige loggen jeg hadde i den gjeldende loggen, og SQL Server i dette oppstartsforsøket startet faktisk ikke.
Og dette er en produsert feil, og måten jeg produserte denne feilen på var at jeg flyttet plasseringen til modelldatabasen, som er en systemdatabase.
Det er en maldatabase for alle databaser som er opprettet av SQL Server. Når SQL Server starter må den starte opp og bruke en tempdb-database, og modelldatabasen er malen for tempdb.
Så uten en modelldatabase tempdb kunne ikke starte, eller kunne ikke komme online og SQL Server-tjenesten kunne ikke starte.
Dette er et eksempel på hva vi ser i feilloggen. Vi ville se feilen, vi ville se mer informasjon om hvorfor feilen ble generert - i dette tilfellet kunne den ikke finne en databasefil, modelldatabasefilen - og senere vil den fortelle oss at den ikke kunne finne loggfilen for modelldatabasen, noe som betyr at tempdb-databasen ikke kunne opprettes.
Så dette er den dårlige nyheten at feilloggen kan komme tilbake til deg for å gi deg informasjon om hvordan du feilsøker problemet.
Nå må vi huske på at når vi ser en oppføring for en feil som denne, vil dette også bli inkludert i applikasjonsloggene.
Så vi ser at den samme hendelsen blir registrert i systemapplikasjonsloggen, og den første feilmeldingen vi ser, forteller oss at databasefilen ikke ble funnet, og den andre forteller oss at loggfilen ikke ble funnet.
Så nok en gang et produsert eksempel på en feil, selvfølgelig kan dette være svært kritisk for deg hvis du feilsøker et problem i det virkelige liv.
For eksempel, hvis en stor databasefil er ødelagt, som modelldatabasen, vil tjenesten for SQL ikke starte, og dette er området du skal få informasjon om å lære om det og feilsøke det.
Så nok om innholdet i feilloggen. Vi kan også få tilgang til feilloggene live i filutforskeren. Og nok en gang trenger vi å vite filplasseringen til feilloggen, det så vi i selve feilloggen.
Vi vet at dette er plasseringen for feilloggen, og at den er plassert i loggkatalogen for denne installasjonen av SQL Server.
Se den samme informasjonen alltid - vi får valget av tekstredigereren du vil ta den opp med. Nok en gang er utsikten en annen.
Her er de tidligste hendelsene øverst i loggen når du ser på selve råloggen, og de siste er nederst.
Det er en annen måte å finne feilloggplasseringen på, og det går til programinstallasjonen utenfor Start-menyen for den forekomsten av SQL Server.
Her går vi til 'SQL Server Configuration Manager'. Konfigurasjonsbehandling viser alle tjenestene for denne installasjonen av SQL.
Hvis vi går til 'SQL Server Service' høyreklikk på det, gå til 'Egenskaper', 'Oppstartsparametere', parameteren '-e' er der feilloggen ligger.
Og noen ganger er det veldig viktig å forstå dette fordi du kanskje ikke har en installasjon av Studio Management å se på.
Hvis du ikke gjør det, må du begynne å tenke på alle mulige stasjonsplasseringer som er tilgjengelige for den aktuelle installasjonen av SQL.
Mange ganger kan du ganske enkelt kutte til jakten, gå inn i Configuration Manager, finne disse oppstartsparametrene, og når du gjør det, kan du finne ut nøyaktig hvor feilloggen ligger.
Greit som avslutter vår titt på SQL Server Error Log. Jeg håper denne videoen hjalp deg med å forstå hvor du finner loggen, og hvordan den kan hjelpe deg med feilsøking av Microsoft SQL Server.
Takk for at du så på, og farvel.
