Řešení s vysokou závažností chyb v SQL Server

V mém předchozím článku o SQL Server Agent Alerts jsem poskytl podrobné pokyny, jak nastavit a nakonfigurovat upozornění SQL Agent pro velmi závažné chyby 19-25 a také chybu 825. V tomto článku se budu zabývat prodiskutujte tyto chyby podrobně a podělte se o to, co byste měli dělat, pokud k nim dojde ve vašem prostředí.

Chyby s úrovní závažnosti 19 nebo vyšší zastaví dokončení aktuální dávky. Chyby se závažností 20 a vyšší jsou závažné chyby a ukončují aktuální připojení klienta. Tyto chyby mohou také ovlivnit všechny procesy v databázi. Závažné chyby jsou přesně to, co název napovídá:běžící proces je ukončen a klientské připojení je uzavřeno.

Chyby závažnosti 19

Chyba závažnosti 19 je chyba způsobená nedostatkem zdroje. To znamená, že byl překročen vnitřní limit (který nemůžete konfigurovat), což způsobilo ukončení aktuální dávky. K těmto chybám dochází jen zřídka a pro nápravu problému můžete udělat jen málo. Pokud dojde k chybě závažnosti 19, měli byste kontaktovat svého primárního poskytovatele podpory; typicky by to byl Microsoft.

Za všechny roky práce se serverem SQL si nemohu vzpomenout na žádný incident, kdy by byla vygenerována chyba závažnosti 19. I když jsem prohledal Bing, měl jsem problém najít výskyty chyby; těch několik odkazů, které jsem našel, se týkalo rané verze SQL Serveru a odkazovalo na chybu v samotném SQL Serveru.

Chyby závažnosti 20

Chyba závažnosti 20 je závažnou chybou v aktuálním procesu. To znamená, že příkaz narazil na problém a byl ukončen. Protože to ovlivňuje pouze aktuální proces, je velmi nepravděpodobné, že by byla poškozena samotná databáze. Tyto chyby jsou spojeny s jednotlivými prohlášeními, takže budete muset shromáždit celou chybovou zprávu a kontaktovat osobu nebo tým odpovědný za daný bit kódu. Může to být interní nebo možná dodavatel aplikace. Příklad chyby je:

V případě této chyby bych se obrátil na vývojáře aplikace nebo dodavatele, protože chyba souvisí se sdruženým připojením, u kterého při pokusu o reset došlo k chybě. Také bych zkontroloval protokoly SQL Server, které mohou obsahovat podrobnější chybovou zprávu týkající se toho, co se ve skutečnosti děje, aby chybu způsobilo.

Chyby závažnosti 21

Chyba závažnosti 21 je závažná chyba v databázi, která ovlivňuje všechny procesy používající tuto databázi.

Viděl jsem, že k této chybě došlo při pokusu o obnovení databáze pomocí podnikových funkcí do instance Standard Edition a také když je databáze poškozená a uživatel se pokusí otevřít poškozenou stránku. Příklad chybové zprávy tohoto typu je:

Při pokusu o obnovení databáze, která používá funkce Enterprise, do instance Standard Edition, budete muset nejprve odebrat funkce Enterprise. Pokud například používáte kompresi dat nebo sběr dat změn, budete muset nejprve přestat používat a odebrat tyto funkce z databáze, zálohovat databázi a poté ji obnovit do instance Standard Edition. Můžete použít DMV sys.dm_db_persisted_sku_features zkontrolovat, zda používáte nějaké funkce pouze pro podniky.

Pro chyby poškození budete muset spustit DBCC CHECKDB určit rozsah korupce a jít odtud. Pokud budete mít štěstí, chyba bude v neklastrovaném indexu, který můžete znovu sestavit a problém vyřešit. Pokud je poškození závažnější, můžete se podívat na operaci obnovení. Chcete-li lépe porozumět korupci a tomu, jak řešit různé aspekty korupce, doporučuji vám přečíst si různé blogové příspěvky Paula Randala. Paul má celou kategorii o korupci, kterou si můžete prohlédnout zde:

• http://www.sqlskills.com/blogs/paul/category/corruption/

Spuštění DBCC CHECKDB jako součást pravidelně naplánované úlohy proti vašim databázím se důrazně doporučuje odhalit korupci co nejdříve. Pokud pravidelně nekontrolujete poškození, pak jste vystaveni obrovskému riziku, že nebudete moci obnovit poškozená data.

Chyby závažnosti 22

Chyba závažnosti 22 je závažná chyba způsobená podezřením na integritu tabulky, což v podstatě znamená, že tabulka nebo index zadaný ve zprávě je poškozen. Korupce se stává a stává se často. Naše zkušenost je taková, že k většině poškození dochází kvůli problému souvisejícím s I/O subsystémem. Pokud narazíte na chybu závažnosti 22, budete muset spustit DBCC CHECKDB k určení rozsahu škody. Příklad chyby je:

Pokud je chyba v neklastrovaném indexu, můžete pouze znovu vytvořit index a opravit poškození. Pokud je poškození v hromadě nebo klastrovaném indexu, budete muset obnovit databázi do konzistentního stavu.

Viděl jsem zprávy, kde bylo poškození v paměti, ale ne na disku. V takovém případě by restartování instance nebo nastavení databáze offline a poté online mělo odstranit chybu.

Chyby závažnosti 23

Chyba závažnosti 23 je další závažnou chybou oznamující, že samotná databáze má problém s integritou. Rozlišení je podobné jako u chyby závažnosti 22, kde musíte okamžitě spustit DBCC CHECKDB zjistit celý rozsah poškození databáze.

Tato úroveň poškození je detekována jako ovlivňující celou databázi. Může se jednat o poškození v rámci samotného datového souboru nebo poškození v souboru protokolu. Podrobnosti o chybě vás nasměrují ke kořenovému problému. Například následující chyba poukazuje na to, že bychom museli obnovit naši databázi nebo se pokusit znovu sestavit protokol. Kvůli konzistenci bych obnovil z mé nejnovější zálohy a všech dostupných záloh protokolu transakcí.

Chyby závažnosti 24

Chyba závažnosti 24 je závažná chyba související s hardwarem. Tato zpráva by se objevila kvůli nějakému typu selhání média. Nejběžnější z těchto typů chyb, které jsem viděl, souvisí s problémy s pamětí a chybami I/O. Například: