Podle: Brady Upton | Aktualizováno: 2016-07-26 | Komentáře (2) | Související: Více > Příkazy konzoly databáze DBCC

Problém

Poškození databáze SQL Serveru může být problém a může způsobit vážné poškození databáze. Pokud jste zkušený DBA, pak máte pravděpodobně zavedena ochranná opatření, která toto odhalí, ale v průběhu let jsem viděl stovky serverů SQL Server bez jakýchkoli detekčních metod a to je problém. Existuje několik způsobů, jak odhalit poškození databáze, ale tento tip se zaměří spíše na příkaz DBCC CHECKDB.

Řešení

O příkazech DBCC (database console commands) jste možná slyšeli, ale možná také ne. Tyto příkazy se používají k prováděnírůzných operací v databázi a lze je rozdělit do čtyř kategorií:Údržba, Různé, Informační a Validační. Některé z příkazů DBCC používám denně, ale žádný více než DBCC CHECKDB.

Co je SQL Server DBCC CHECKDB

DBCC CHECKDB z knihovny MSDN společnosti Microsoft kontroluje logickou a fyzickou integritu všech objektův zadané databázi provedením následujících operací:

  • Provede DBCC CHECKALLOC na databázi – kontroluje konzistenci struktur přidělování místa na disku pro zadanou databázi.
  • Provede DBCC CHECKTABLE na každé tabulce a pohledu v databázi – Zkontroluje konzistenci všech stránek a struktur, které tvoří tabulku nebo indexovaný pohled.
  • Provede DBCC CHECKCATALOG na databázi – Kontroluje konzistenci kataloguv rámci databáze.
  • Ověřuje obsah každého indexovaného zobrazení v databázi.
  • Ověřuje konzistenci na úrovni odkazů mezi metadaty tabulky a adresáři a soubory souborového systému při ukládání varbinárních(max) dat v souborovém systému pomocíFILESTREAM.
  • Ověřuje data Service Broker v databázi

Pokud jste někdy spouštěli DBCC CHECKDB, víte, že u velkých databází to chvíli trvá.

Jak mi může SQL Server DBCC CHECKDB pomoci?

Poškození dat je špatné. Může způsobit nejrůznější problémy v databázi, které mohou zahrnovat nesprávné výsledky dat, neúspěšné příkazy SQL a v některých případech může vyřadit celou instanci SQL. DBCC CHECKDB vás na poškození upozorní, abyste ho mohli opravit dříve, než se (snad) příliš zhorší.

Jak používat SQL Server DBCC CHECKDB?

DBCC CHECKDB je poměrně jednoduchý. Existuje několik možností, které můžete s příkazem použít, a některé z nich probereme v další části, ale základní syntaxe vypadá takto:

DBCC CHECKDB ('DatabaseName') 

Pěkně jednoduše.

Automatizovat SQL Server DBCC CHECKDB

Je zřejmé, že se nechcete každé ráno přihlašovat a spouštět tento příkaz na každédatabázi, takže tento proces můžete automatizovat pomocí několika různých metod:

  • Plány údržby SQL Serveru -Plány údržby jsou součástí SQL Serveru po vybalení z krabice (pokud nepoužíváte ExpressEdition). Plány údržby většinou nepoužívám rád, ale pro tento typ úlohy mi jejich použití nevadí. V sadě nástrojů plánu údržby budete muset použít úlohu Kontrola integrity databáze. Jedinou konfigurovatelnou možností je zahrnout indexy, takže to není úplně uživatelsky přívětivé, ale v některých případech to stačí. O dalších možnostech si opět povíme v další části.
  • Vlastní skripty – Vlastní skripty jsou obvykle to, co používám, a nabízejí nejlepší flexibilitu, pokud jde o přidání požadovaných možností. Moje go-toskripty jsou již vytvořené a zdarma k použití odOla Hallengren. Odvedl skvělou práci při jejich vytváření a sdílení se světem. DíkyOla!
    • Podívejte se na skripty na MSSQLTips.com:
    • Provádění údržby s databázemi SQL Serveru v režimu plné obnovy
    • Plány údržby databází SQL Serveru a správa záložních souborů
    • Provádění údržby SQL Serveru bez okna údržby

Možnosti SQL Serveru DBCC CHECKDB

Existuje několik možností, které lze použít s DBCC CHECKDB, a já zde proberu několik nejpopulárnějších:

  • NOINDEX – Určuje, že se nemají provádět intenzivní kontroly neclusterových indexů pro uživatelské tabulky. Tím se snižuje doba nadměrného provádění. NOINDEX nemá vliv na systémové tabulky, protože kontroly integrityse vždy provádějí na indexech systémových tabulek.
  • NO_INFOMSGS – Potlačuje všechna informační hlášení.
  • PHYSICAL_ONLY – Omezuje kontrolu na integritu fyzické struktury záhlaví stránek a záznamů a konzistenci alokace databáze. Tato kontrola je navržena tak, aby poskytovala malou režii kontroly fyzické konzistence databáze, ale může také odhalit roztržené stránky, selhání kontrolního součtu a běžné hardwarové poruchy, které mohou ohrozit uživatelská data.
  • TABLOCK – Způsobí, že DBCC CHECKDB získá zámky místo použití interního snímku databáze. To zahrnuje krátkodobý exkluzivní (X)zámek databáze. TABLOCK způsobí, že DBCC CHECKDB poběží rychleji na databázi při velkém zatížení, ale sníží souběžnost dostupnou v databázi během běhu DBCC CHECKDB.
  • DATA_PURITY – Způsobí, že DBCC CHECKDB zkontroluje databázi na hodnoty sloupců, které nejsou platné nebo jsou mimo rozsah. Například DBCC CHECKDBzjistí sloupce s hodnotami data a času, které jsou větší nebo menší než přípustný rozsah pro datový typ datetime; nebo sloupce s desetinným nebo přibližným číselným datovým typem s hodnotami stupnice nebo přesnosti, které nejsou platné.

Některé možnosti OPRAVY probereme v jiné části níže.

Jak často mám kontrolovat, zda není SQL Server poškozen?

Každou minutu každý den. Dělám si legraci.

Pokud máte denní okno údržby, bylo by dobré kontrolovat poškození datkaždý den. Čím rychleji ji zachytíte, tím méně škody může napáchat. Všiml jsem si, že hodně lidí to spouští o víkendu, zejména u větších databází. Není na tom nic správného ani špatného, jen se ujistěte, že to máte pravidelně naplánované.

Musím v produkčním prostředí spouštět DBCC CHECKDB?

Ne, no ano. Tak trochu.

Pro kontrolu poškození dat nemá smysl spouštět DBCC CHECKDB v testovacím prostředí… Ledaže byste obnovili kopii produkčního prostředí pro testování a pak ji spustili. BRILIANTNÍ!

Možná se ptáte, zda jsou vhodné některé možnosti HA, například AlwaysOn, LogShipping atd.? Ne, je třeba zkontrolovat vaše produkční *živé* prostředí.

Teď, když je DBCC CHECKDB nakonfigurován a spuštěn, co mám hledat?

Gratuluji! Máte DBCC CHECKDB zautomatizovaný a spuštěný, ale co teď? Pokud máte nastavenou úlohuSQL ServerAgent, pak se ujistěte, že jste v úloze nastaviliDatabase Mail,operátora a oznámení. Pokud úloha uspěje, pokračujte ve svém krásném dni. Pokud úloha selže, pak nás čeká nějaká práce.

Můžete vidět chybu, jako je tato:

Počet stránek In-row data USED pro objekt „tablename“, index ID 2, partitionID 608313809829888, alloc unit ID 608313809829888 (typ In-row data) je nesprávný.Spusťte DBCC UPDATEUSAGE. (Chyba 2508) The In-row data RSVD pagecount for object „tablename“, index ID 2, part… Krok se nezdařil.

nebo toto:

Ident ID objektu 2088535921, ID indexu 0, ID oddílu 72345201021503994, alokační jednotkaID 72345201051571606 (typ In-row data): Podrobnosti viz další chyby. Msg 8939, Level 16, State 98, Line 1 Chyba tabulky:Object ID 2088535921, index ID 0, partition ID 72345201021503994, alloc unitID 72345201051571606 (type In-row data), page (1:94299). Test (IS_OFF (BUF_IOERR,pBUF->bstat)) selhal. CHECKDB našel 0 chyb alokace a 2 chyby konzistence v tabulce ‚tablename‘ (ID objektu 2088535921). CHECKDB nalezl 0 alokačních chyb a 2 chyby konzistence v databázi ‚tablename‘. repair_allow_data_lossis minimální úroveň opravy pro chyby nalezené pomocí DBCC CHECKDB (Database).

Nejprve nepanikařte. Za druhé zkontrolujte zálohy. Chyby DBCC CHECKDB vám obvykle řeknou, co je třeba udělat.

Při první chybě opraví DBCC UPDATEUSAGE nepřesnosti v počtu stránek a řádků v katalogových zobrazeních. Celkem neškodné.

Druhá chyba hlásí poškození dat. Chyba zmiňuje použití opravy_povolení_ztráty_datjako minimální úrovně opravy. To znamená, že příkaz můžete spustit s tímto argumentem,ale můžete přijít o data. Proto vždy doporučuji obnovu do zálohy, pokud můžete. Musíte se ujistit, že záloha neobsahuje poškozená data, a chcete mít jistotu, že nedojde ke ztrátě dat.

Jak opravit databázi SQL Server

Pokud nemáte zálohu, možná budeme muset použít DBCC CHECKDB s možností opravy. zde jsou možnosti opravy, které je možné použít. Mohou, ale nemusí fungovata je třeba je použít jako poslední možnost:

  • REPAIR_ALLOW_DATA_LOSS – Pokusí se opravit všechny nahlášené chyby. tyto opravy mohou způsobit určitou ztrátu dat.
  • REPAIR_REBUILD – Provede opravy, které nemají možnostztráty dat. Může se jednat o rychlé opravy, jako je oprava chybějících řádků v neclusterových indexech, a časově náročnější opravy, jako je přestavba indexu.

Jak jsem uvedl výše, je velmi důležité mít k dispozici aktuální zálohy dat pro obnovu po poškození. Poškození nezáleží na tom, kolik dat máte, jakou verzi SQL používáte nebo jak luxusní je vaše datové centrum.

Mám z toho docela dobrý pocit, ale co dalšího mohu použít k ochraně svých instancí SQL?

DBCC CHECKDB by měl být spuštěn na každé instanci SQL, kterou máte, ale existuje několik dalších způsobů, které mohou pomoci odhalit/ zabránit poškození dat.

  • Výstrahy agenta SQL Serveru – Brian Kelley napsal pěkný tip na toto témazde.
  • Ověření stránky – Ujistěte se, že vaše databáze používají ověření stránkyCHECKSUM. Pokud stále používáte SQL 2005 nebo nižší, není toto nastavení k dispozici, ale po upgradu se ujistěte, že jste toto nastavení změnili. Chcete-li zobrazit nastavení ověřování stránek, použijte následující příkaz:
select name, page_verify_option_desc from sys.databases 
Další kroky
  • Ujistěte se, že jste se podívali do knihovnyMSDN, kde najdete podrobnější informace týkající se DBCC CHECKDB
  • MSSQLTips.com má pěknou sbírku tipů o kontrole konzistence databází, která může být také užitečná.

Poslední aktualizace: O autorovi

O autorovi
Brady Upton je správce databází a superstar SharePointu v Nashvillu, TN.
Zobrazit všechny mé tipy
Související zdroje

  • Další tipy pro SQL Server DBA…

.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.