I min tidligere artikel om SQL Server Agent Alerts gav jeg trin-for-trin instruktioner om, hvordan man opsætter og konfigurerer SQL Agent-alarmer for fejl 19-25 med høj alvorlighed samt fejl 825. I denne artikel vil jeg diskutere disse fejl i detaljer, og del, hvad du skal gøre, hvis de sker i dit miljø.
Fejl med et alvorlighedsniveau på 19 eller højere forhindrer den aktuelle batch i at blive færdig. Fejl med en sværhedsgrad på 20 og højere er fatale fejl og afslutter den aktuelle klientforbindelse. Disse fejl kan også påvirke alle processer i databasen. Fatale fejl er præcis, hvad navnet antyder:processen, der kører, afsluttes, og klientforbindelsen lukkes.
Sværhedsgrad 19 fejl
En alvorlighedsgrad 19 fejl er en fejl på grund af mangel på en ressource. Dette betyder, at en intern grænse (som du ikke kan konfigurere) er blevet overskredet og fik den aktuelle batch til at afslutte. Disse fejl opstår sjældent, og der er ikke meget, du kan gøre for at løse problemet. Hvis der opstår en alvorlighedsfejl 19, skal du kontakte din primære supportudbyder; typisk ville det være Microsoft.
I alle mine år med at arbejde med SQL Server kan jeg ikke huske nogen hændelse, hvor der blev genereret en alvorlighedsgrad 19 fejl. Selv efter at søge Bing, har jeg haft problemer med at finde forekomster af fejlen; de få referencer, jeg fandt, var relateret til en tidlig version af SQL Server, og refererede til en fejl i selve SQL Server.
Sværhedsgrad 20-fejl
En sværhedsgrad 20 fejl er en fatal fejl i den aktuelle proces. Dette indikerer, at en erklæring stødte på et problem og blev afsluttet. Da dette kun påvirker den aktuelle proces, er det meget usandsynligt, at selve databasen er blevet beskadiget. Disse fejl er knyttet til en individuel erklæring, så du bliver nødt til at samle hele fejlmeddelelsen og kontakte den person eller team, der er ansvarlig for den bit kode. Dette kan være internt eller muligvis leverandøren af applikationen. Et eksempel på fejl er:
Fejl:18056, sværhedsgrad 20, tilstand:29Klienten kunne ikke genbruge en session med SPID 123, som var blevet nulstillet til pooling af forbindelse.
For denne fejl vil jeg kontakte applikationsudvikleren eller -leverandøren, da fejlen er relateret til en samlet forbindelse, der støder på en fejl, når den forsøger at nulstille. Jeg ville også gennemgå SQL Server-logfilerne, som kan have en mere detaljeret fejlmeddelelse om, hvad der faktisk sker for at forårsage fejlen.
Sværhedsgrad 21-fejl
En alvorlighedsgrad 21-fejl er en fatal fejl i databasen, der påvirker alle processer, der bruger den pågældende database.
Jeg har set denne fejl opstå, når jeg forsøger at gendanne en database ved hjælp af Enterprise-funktioner til en Standard Edition-instans, såvel som når en database er korrupt, og brugeren forsøger at få adgang til en korrupt side. Et eksempel på fejlmeddelelse af denne type er:
Fejl:605, Alvor:21, Tilstand 1Forsøg på at hente logisk side (1:8574233) i databasen 'DB_NAME' tilhører objektet '0', ikke objektet 'Table01'.
Når du forsøger at gendanne en database, der bruger Enterprise-funktioner til en Standard Edition-instans, skal du først fjerne Enterprise-funktionerne. For eksempel, hvis du bruger datakomprimering eller ændrer datafangst, skal du først stoppe med at bruge og fjerne disse funktioner fra databasen, sikkerhedskopiere databasen og derefter gendanne den til Standard Edition-forekomsten. Du kan bruge DMV sys.dm_db_persisted_sku_features for at kontrollere, om du har nogle Enterprise-only-funktioner i brug.
For korruptionsfejlene skal du køre DBCC CHECKDB at fastslå omfanget af korruptionen og gå derfra. Hvis du er heldig, vil fejlen være i et ikke-klynget indeks, som du kan genopbygge og løse problemet. Hvis korruptionen er mere alvorlig, kan du se på en gendannelsesoperation. For bedre at forstå korruption og hvordan man løser forskellige aspekter af korruption, opfordrer jeg dig til at gennemgå de forskellige blogindlæg af Paul Randal. Paul har en hel kategori om korruption, som du kan se her:
- http://www.sqlskills.com/blogs/paul/category/corruption/
Kører DBCC CHECKDB som en del af et regelmæssigt planlagt job mod dine databaser anbefales det stærkt at opdage korruption så tidligt som muligt. Hvis du ikke jævnligt tjekker for korruption, er du i en enorm risiko for ikke at kunne gendanne de korrupte data.
Sværhedsgrad 22-fejl
En alvorlighedsgrad 22-fejl er en fatal fejl, der skyldes, at tabellens integritet er mistænkelig, hvilket grundlæggende indikerer, at tabellen eller indekset, der er angivet i meddelelsen, er beskadiget. Korruption sker og sker ofte. Vores erfaring er, at størstedelen af korruptionen opstår på grund af et I/O-undersystemrelateret problem. Hvis du støder på en sværhedsgrad 22 fejl, skal du køre DBCC CHECKDB at fastslå skadens omfang. Et eksempel på fejl er:
Kunne ikke åbne XYZ for ugyldig fil-id ## i databasen. Tabel eller database kan være beskadiget.
Hvis fejlen er i et ikke-klynget indeks, kan du bare genopbygge indekset og rette korruptionen. Hvis korruptionen er i en heap eller et klynget indeks, bliver du nødt til at gendanne databasen til en konsistent tilstand.
Jeg har set rapporter, hvor korruptionen var i hukommelsen, men ikke på disken. I så fald burde en genstart af forekomsten eller indstilling af databasen offline og derefter online rydde fejlen.
Sværhedsgrad 23-fejl
En sværhedsgrad 23-fejl er en anden fatal fejl, der rapporterer, at selve databasen har et integritetsproblem. Opløsningen minder meget om en sværhedsgrad 22-fejl, hvor du straks skal køre DBCC CHECKDB at finde det fulde omfang af skaden på databasen.
Dette niveau af korruption detekteres som at påvirke hele databasen. Dette kan være korruption i selve datafilen eller korruption i logfilen. Oplysningerne om fejlen vil lede dig mod rodproblemet. For eksempel påpeger følgende fejl, at vi bliver nødt til at gendanne vores database eller forsøge at genopbygge loggen. For konsistens vil jeg gendanne fra min seneste sikkerhedskopi og alle tilgængelige sikkerhedskopier af transaktionslogfiler.
Fejl:9004, Alvor:23 Tilstand:6Der opstod en fejl under behandling af loggen for databasen 'db_name'. Hvis det er muligt, gendan fra backup. Hvis en sikkerhedskopi ikke er tilgængelig, kan det være nødvendigt at genopbygge loggen.
Sværhedsgrad 24-fejl
En sværhedsgrad 24 fejl er en fatal fejl relateret til en hardware. Denne meddelelse vil opstå på grund af en eller anden form for mediefejl. De mest almindelige af disse typer fejl, jeg har set, er relateret til problemer med hukommelse og I/O-fejl. For eksempel:
Fejl:832, Alvor:24, Tilstand:1En side, der skulle have været konstant, er ændret (forventet kontrolsum:
Når fejl som denne opstår, bør du kontakte dit systemsupportteam for at køre hukommelsestest på din server og give serveren et godt helbredstjek. Denne fejl kan være dårlig hukommelse eller en hukommelsesskriver (en kerneproces eller noget, der ændrer SQL Servers hukommelse).
Et andet eksempel:
Fejl:824, Alvor:24, Tilstand:2SQL-server har registreret en logisk konsistensbaseret I/O-fejl:forkert side-id (forventet 1:123; faktisk 0:0). Det skete under en læsning af side (1:123) i database-id
Denne fejl angiver en konsistensfejl i databasens primære datafil. Du skal straks køre DBCC CHECKDB for at bestemme omfanget af korruptionen og tage de nødvendige skridt til at reparere eller gendanne databasen.
Sværhedsgrad 25-fejl
En alvorlighedsgrad 25 fejl er en fatal systemfejl. Jeg har hørt, at sværhedsgrad 25 er mere eller mindre en catch-all for diverse fatale fejl. Jeg har kun set denne fejl, når den er relateret til mislykkede opgraderinger:noget forhindrer et af opgraderingsscripts i at køre, og en alvorlighedsgrad 25 fejl bliver kastet. Du vil få en fejl, der ligner:
Script-niveauopgradering for database 'master' mislykkedes, fordi opgraderingstrin 'sqlagent90_sysdbupg.sql' stødte på fejl 598, tilstand 1, sværhedsgrad 25. Dette er en alvorlig fejltilstand, som kan forstyrre regelmæssig drift, og databasen vil blive taget offline. Hvis fejlen opstod under opgradering af 'master'-databasen, vil det forhindre hele SQL Server-instansen i at starte. Undersøg de tidligere fejllogposter for fejl, tag de passende korrigerende handlinger og genstart databasen, så scriptopgraderingstrinene kører til fuldførelse.I dette tilfælde indikerede fejl før denne meddelelse en forkert sti til standarddataplaceringen for SQL Server. Da det var rettet, kørte opgraderingen med succes.
Fejl 825
Fejl 825 omtales ofte som advarslen om at læse-forsøg igen, men betingelsen er for både læse- og skriveoperationer. Denne fejl fortæller dig, at et genforsøg af handlingen var påkrævet, og hvor mange gange SQL Server skulle prøve forsøget igen, før det lykkedes. SQL Server vil gentage operationerne op til fire gange, efter fire genforsøg vil den give en 823 eller 824 fejl. Fejl 825-meddelelser vil ligne følgende:
En læsning af filen 'sti til filnavn\db_navn.mdf' ved offset 0x00000002000 lykkedes efter fejl 2 gange med fejl:forkert kontrolsum (forventet:XYZ; faktisk ABC). Yderligere meddelelser i SQL Server-fejlloggen og systemets hændelseslog kan give flere detaljer. Denne fejltilstand truer databasens integritet og skal rettes. Gennemfør et komplet databasekonsistenstjek (DBCC CHECKDB). Denne fejl kan skyldes mange faktorer; for mere information, se SQL Server Books Online.
Disse meddelelser er vigtige, da de indikerer, at du har et større problem med dit diskundersystem. Fejlfindingsmetoder ville være at køre DBCC CHECKDB for at sikre, at databasen er konsistent, som fejlen anbefaler, samt gennemgå Windows-hændelseslogfilerne for fejl fra operativsystemet eller lagerenhederne. Du bør også få dit lager- og hardwaresupportteam til at gennemgå det underliggende I/O-undersystem for fejl.
Oversigt
Det er gratis og nemt at have konfigureret SQL Agent-advarsler. At være proaktiv og lydhør over for disse advarsler er vigtig for at hjælpe med at minimere nedetid for dig og dine kunder. Som du nu har lært, kan mange ting påvirke SQL Server og konsistensen af dine databaser, og det bedste forsvar for at kunne gendanne disse fejl er at have gode sikkerhedskopier og kende de forskellige reparationsmuligheder for DBCC CHECKDB . Det anbefales altid at køre DBCC CHECKDB regelmæssigt mod dine databaser for at opdage korruption så tidligt som muligt, da jo hurtigere du finder korruption, jo større er sandsynligheden for, at du får dataene sikkerhedskopieret, så du kan gendanne uden datatab.