I min tidigare artikel om SQL Server Agent Alerts gav jag steg-för-steg-instruktioner om hur man ställer in och konfigurerar SQL Agent-varningar för fel 19-25 med hög allvarlighetsgrad samt fel 825. I den här artikeln ska jag diskutera dessa fel i detalj och berätta vad du bör göra om de inträffar i din miljö.
Fel med en allvarlighetsgrad på 19 eller högre hindrar den aktuella batchen från att slutföras. Fel med en allvarlighetsgrad på 20 och högre är allvarliga fel och avslutar den aktuella klientanslutningen. Dessa fel kan också påverka alla processer i databasen. Fatala fel är precis vad namnet antyder:processen som körs avslutas och klientanslutningen stängs.
Allvarlighetsgrad 19-fel
Ett allvarlighetsfel 19 är ett fel på grund av brist på en resurs. Detta betyder att en intern gräns (som du inte kan konfigurera) har överskridits och orsakat att den aktuella batchen slutar. Dessa fel uppstår sällan och det finns lite du kan göra för att åtgärda problemet. Om ett allvarlighetsfel 19 inträffar bör du kontakta din primära supportleverantör; vanligtvis skulle det vara Microsoft.
Under alla mina år av att arbeta med SQL Server kan jag inte minnas någon incident där ett allvarlighetsfel 19 genererades. Även när jag sökte på Bing har jag haft problem med att hitta förekomster av felet; de få referenserna jag hittade var relaterade till en tidig version av SQL Server och refererade till en bugg i själva SQL Server.
Allvarlighetsgrad 20-fel
Ett allvarlighetsfel 20 är ett allvarligt fel i den aktuella processen. Detta indikerar att ett uttalande stötte på ett problem och avslutades. Eftersom detta bara påverkar den aktuella processen är det mycket osannolikt att själva databasen har skadats. Dessa fel är knutna till ett individuellt uttalande så du måste samla in hela felmeddelandet och kontakta personen eller teamet som ansvarar för den biten av kod. Detta kan vara internt eller möjligen leverantören av applikationen. Ett exempel på fel är:
Fel:18056, allvarlighetsgrad 20, tillstånd:29Klienten kunde inte återanvända en session med SPID 123, som hade återställts för anslutningspoolning.
För detta fel skulle jag kontakta applikationsutvecklaren eller leverantören, eftersom felet är relaterat till en poolad anslutning som stöter på ett fel vid försök att återställa. Jag skulle också granska SQL Server-loggarna som kan ha ett mer detaljerat felmeddelande om vad som faktiskt händer som orsakar felet.
Allvarlighetsgrad 21-fel
Ett allvarlighetsfel 21 är ett allvarligt fel i databasen som påverkar alla processer som använder den databasen.
Jag har sett det här felet uppstå när man försöker återställa en databas med Enterprise-funktioner till en Standard Edition-instans, såväl som när en databas är korrupt och användaren försöker komma åt en korrupt sida. Ett exempel på felmeddelande av denna typ är:
Fel:605, Allvarlighet:21, Tillstånd 1Försök att hämta logisk sida (1:8574233) i databasen 'DB_NAME' tillhör objektet '0', inte objektet 'Table01'.
När du försöker återställa en databas som använder Enterprise-funktioner till en Standard Edition-instans måste du först ta bort Enterprise-funktionerna. Om du till exempel använder datakomprimering eller ändrar datainsamling måste du först sluta använda och ta bort dessa funktioner från databasen, säkerhetskopiera databasen och sedan återställa den till Standard Edition-instansen. Du kan använda DMV sys.dm_db_persisted_sku_features för att kontrollera om du använder några Enterprise-only-funktioner.
För korruptionsfelen måste du köra DBCC CHECKDB att fastställa omfattningen av korruptionen och gå därifrån. Om du har tur kommer felet att finnas i ett icke-klustrat index som du kan bygga om och lösa problemet. Om korruptionen är mer allvarlig kan du titta på en återställningsåtgärd. För att bättre förstå korruption och hur man löser olika aspekter av korruption, uppmuntrar jag dig att granska de olika blogginläggen av Paul Randal. Paul har en hel kategori om korruption som du kan se här:
- http://www.sqlskills.com/blogs/paul/category/corruption/
Kör DBCC CHECKDB som en del av ett regelbundet schemalagt jobb mot dina databaser rekommenderas starkt för att upptäcka korruption så tidigt som möjligt. Om du inte regelbundet letar efter korruption, löper du en stor risk att inte kunna återställa korrupta data.
Allvarlighetsgrad 22-fel
Ett allvarlighetsfel 22 är ett allvarligt fel på grund av att tabellens integritet är misstänkt, vilket i princip indikerar att tabellen eller indexet som anges i meddelandet är skadat. Korruption händer och händer ofta. Vår erfarenhet är att majoriteten av korruptionen uppstår på grund av ett I/O-undersystemrelaterat problem. Om du stöter på ett allvarlighetsfel 22 måste du köra DBCC CHECKDB för att fastställa skadans omfattning. Ett exempel på fel är:
Kunde inte öppna XYZ för ogiltigt fil-ID ## i databasen. Tabell eller databas kan vara skadad.
Om felet finns i ett icke-klustrat index kan du bara bygga om indexet och åtgärda korruptionen. Om korruptionen finns i en heap eller ett klustrat index måste du återställa databasen till ett konsekvent tillstånd.
Jag har sett rapporter där korruptionen fanns i minnet men inte på disken. I så fall bör en omstart av instansen eller inställning av databasen offline och sedan online åtgärda felet.
Allvarlighetsgrad 23-fel
Ett allvarlighetsfel 23 är ett annat allvarligt fel som rapporterar att själva databasen har ett integritetsproblem. Upplösningen är ungefär som ett allvarlighetsfel 22, där du omedelbart måste köra DBCC CHECKDB för att hitta hela skadan på databasen.
Denna nivå av korruption upptäcks som påverkar hela databasen. Detta kan vara korruption i själva datafilen eller korruption i loggfilen. Informationen om felet kommer att leda dig mot rotproblemet. Till exempel pekar följande fel på att vi skulle behöva återställa vår databas eller försöka bygga om loggen. För konsekvens skulle jag återställa från min senaste säkerhetskopia och alla tillgängliga säkerhetskopior av transaktionsloggar.
Fel:9004, Allvarlighet:23 Tillstånd:6Ett fel uppstod vid bearbetning av loggen för databasen 'db_name'. Om möjligt, återställ från säkerhetskopia. Om en säkerhetskopia inte är tillgänglig kan det bli nödvändigt att bygga om loggen.
Allvarlighetsgrad 24-fel
Ett allvarlighetsfel 24 är ett allvarligt fel relaterat till en hårdvara. Detta meddelande skulle uppstå på grund av någon typ av mediafel. De vanligaste av dessa typer av fel jag har sett är relaterade till problem med minne och I/O-fel. Till exempel:
Fel:832, Allvarlighet:24, Tillstånd:1En sida som borde ha varit konstant har ändrats (förväntad kontrollsumma:
När fel som detta uppstår bör du kontakta ditt systemsupportteam för att köra minnestest på din server och ge servern en bra hälsokontroll. Det här felet kan vara dåligt minne eller en minnesskrivare (en kärnprocess eller något som förändrar SQL Servers minne).
Ett annat exempel:
Fel:824, Allvarlighet:24, Tillstånd:2SQL-server upptäckte ett logiskt konsistensbaserat I/O-fel:felaktig pageid (förväntat 1:123; faktisk 0:0). Det inträffade under en läsning av sidan (1:123) i databas-ID
Det här felet indikerar ett konsistensfel i databasens primära datafil. Du skulle omedelbart behöva köra DBCC CHECKDB för att fastställa omfattningen av korruptionen och vidta lämpliga åtgärder för att reparera eller återställa databasen.
Allvarlighetsgrad 25-fel
Ett allvarlighetsfel 25 är ett allvarligt systemfel. Jag har hört att svårighetsgrad 25 är mer eller mindre en catch-all för diverse fatala fel. Jag har bara sett det här felet när det är relaterat till misslyckade uppgraderingar:något hindrar ett av uppgraderingsskripten från att köras, och ett allvarlighetsfel 25 visas. Du skulle få ett fel som liknar:
Skriptnivåuppgradering för databasen 'master' misslyckades eftersom uppgraderingssteget 'sqlagent90_sysdbupg.sql' stötte på fel 598, tillstånd 1, allvarlighetsgrad 25. Detta är ett allvarligt feltillstånd som kan störa normal drift och databasen kommer att kopplas bort. Om felet inträffade under uppgraderingen av 'master'-databasen kommer det att förhindra att hela SQL Server-instansen startar. Undersök de tidigare felloggposterna för fel, vidta lämpliga korrigerande åtgärder och starta om databasen så att skriptuppgraderingsstegen slutförs.I det här fallet indikerade fel före detta meddelande en felaktig sökväg för standarddataplatsen för SQL Server. När det väl var rättat gick uppgraderingen framgångsrikt.
Fel 825
Fel 825 hänvisas ofta till som läs-försök-varningen, men villkoret gäller både läs- och skrivoperationer. Det här felet låter dig veta att ett nytt försök av operationen behövdes och hur många gånger SQL Server behövde försöka igen innan det lyckades. SQL Server kommer att göra om operationerna upp till fyra gånger, efter fyra försök igen kommer det att visa ett 823- eller 824-fel. Felmeddelanden 825 kommer att likna följande:
En läsning av filen 'sökväg till filnamn\db_namn.mdf' vid offset 0x00000002000 lyckades efter att ha misslyckats 2 gånger med fel:felaktig kontrollsumma (förväntat:XYZ; faktisk ABC). Ytterligare meddelanden i SQL Server-felloggen och systemets händelselogg kan ge mer detaljer. Detta feltillstånd hotar databasens integritet och måste korrigeras. Slutför en fullständig databaskonsistenskontroll (DBCC CHECKDB). Detta fel kan orsakas av många faktorer; för mer information, se SQL Server Books Online.
Dessa meddelanden är viktiga eftersom de indikerar att du har ett större problem med ditt diskundersystem. Felsökningsmetoder skulle vara att köra DBCC CHECKDB för att säkerställa att databasen är konsekvent, som felet rekommenderar, samt granska Windows-händelseloggarna för fel från operativsystemet eller lagringsenheter. Du bör få ditt lagrings- och hårdvarusupportteam att granska det underliggande I/O-undersystemet för fel också.
Sammanfattning
Att ha SQL Agent-varningar konfigurerade är gratis och enkelt. Att vara proaktiv och lyhörd för dessa varningar är viktigt för att minimera stilleståndstiden för dig och dina kunder. Som du nu har lärt dig kan många saker påverka SQL Server och konsistensen i dina databaser, och det bästa försvaret för att kunna återställa från dessa fel är att ha bra säkerhetskopior och känna till de olika reparationsalternativen för DBCC CHECKDB . Det rekommenderas alltid att köra DBCC CHECKDB regelbundet mot dina databaser för att upptäcka korruption så tidigt som möjligt, eftersom ju snabbare du hittar korruption, desto mer sannolikt är det att du säkerhetskopierar data så att du kan återställa utan dataförlust.