SQL Server DBCC CHECKDB áttekintés

By: Frissítve: Brady Upton | Frissítve: DBCCs

Probléma

Az SQL Server adatbázisának sérülése problémát jelenthet, és komoly károkat okozhat az adatbázisban. Ha Ön tapasztalt DBA, akkor valószínűleg rendelkezik biztosítékokkal ennek észlelésére, de az évek során több száz SQL szervert láttam, ahol egyáltalán nem volt észlelési módszer, és ez probléma. Van néhány módszer az adatbázis sérülésének észlelésére, de ez a tipp inkább a DBCC CHECKDB-re összpontosít.

Megoldás

Az adatbázis konzolparancsok (DBCC) utasításokról talán hallott, talán nem. Ezek az utasítások különböző műveletek elvégzésére szolgálnak az adatbázisban, és négy kategóriába sorolhatók:Karbantartás, Egyéb, Információs és Érvényesítés. A DBCC-kijelentések közül néhányat napi szinten használok, de egyiket sem jobban, mint a DBCC CHECKDB-t.

Mi az SQL Server DBCC CHECKDB

A Microsoft MSDN Libraryből származó DBCC CHECKDB a következő műveletek elvégzésével ellenőrzi a megadott adatbázisban lévő összes objektum logikai és fizikai integritását:

• Futtatja a DBCC CHECKALLOC-ot az adatbázisban – Ellenőrzi a megadott adatbázis lemezterület-elosztási struktúráinak konzisztenciáját.
• Futtatja a DBCC CHECKTABLE-t az adatbázis minden tábláján és nézetén – Ellenőrzi a táblázatot vagy indexelt nézetet alkotó összes oldal és struktúra egységességét.
• Futtatja a DBCC CHECKCATALOG-ot az adatbázisban – Ellenőrzi a katalógus konzisztenciáját az adatbázisban.
• Hitelesíti az adatbázis minden indexelt nézetének tartalmát.
• Hitelesíti a kapcsolat szintű konzisztenciát a tábla metaadatai és a fájlrendszer könyvtárai és fájljai között, ha varbinary(max) adatokat tárol a fájlrendszerben aFILESTREAM használatával.
• Hitelesíti a Service Broker adatait az adatbázisban

Ha valaha is futtatta már a DBCC CHECKDB-t, tudja, hogy nagy adatbázisok esetén ez némi időt vesz igénybe.Most, hogy ismeri az összes futtatott lépést, láthatja, miért vesz igénybe időt a befejezés.

Hogyan segíthet nekem az SQL Server DBCC CHECKDB?

Az adatok sérülése rossz. Mindenféle problémát okozhat az adatbázisban, amely magában foglalhatja a helytelen adateredményeket, a sikertelen SQL-kijelentéseket, és bizonyos esetekben az egész SQL-példányt leállíthatja. A DBCC CHECKDB figyelmeztet a korrupcióra, így még azelőtt kijavíthatja, mielőtt (remélhetőleg) túl rosszra fordulna.

Hogyan használhatom az SQL Server DBCC CHECKDB-t?

A DBCC CHECKDB használata meglehetősen egyszerű. Van néhány lehetőség, amit használhatsz az utasítással, és ezek közül néhányat a következő részben átnézünk, de az alapszintaktika így néz ki:

DBCC CHECKDB ('DatabaseName') 

Meglehetősen egyszerű.

Automate SQL Server DBCC CHECKDB

Láthatóan nem akar minden reggel bejelentkezni és futtatni ezt az utasítást minden adatbázisra, ezért ezt a folyamatot néhány különböző módszerrel automatizálhatja:

• SQL Server karbantartási tervek -A karbantartási tervek az SQL Server részei a dobozból (kivéve, ha ExpressEditiont futtat). A karbantartási terveket többnyire nem szeretem használni, de nem bánom, ha ilyen típusú feladatra használom őket. A Karbantartási terv eszköztárban az Adatbázis integritásának ellenőrzése feladatot kell használnia. Az egyetlen konfigurálható opció az indexek bevonása, így nem igazán felhasználóbarát, de bizonyos esetekben csak erre van szükség. A többi lehetőségről a következő szakaszban lesz szó.

• Egyéni parancsfájlok – Általában az egyéni parancsfájlokat használom, és ezek nyújtják a legnagyobb rugalmasságot a kívánt opciók hozzáadása tekintetében. Az én go-toszkriptjeim már elkészültek és ingyenesen használhatókOla Hallengrentől. Csodálatos munkát végzett ezek létrehozásában és a világgal való megosztásában. KöszönömOla!
• Nézze meg a szkripteket az MSSQLTips oldalon.com:
• Karbantartás végrehajtása SQL Server adatbázisokkal teljes helyreállítási módban
• SQL Server adatbázis-karbantartási tervek és biztonsági mentési fájlok kezelése
• SQL Server karbantartás végrehajtása karbantartási ablak nélkül

SQL Server DBCC CHECKDB lehetőségek

A DBCC CHECKDB-vel kapcsolatban több lehetőség is van, amelyek közül néhányat itt áttekintek a népszerűbbek közül:

• NOINDEX – Meghatározza, hogy a felhasználói táblák nem fürtözött indexeinek intenzív ellenőrzését nem kell elvégezni. Ez csökkenti a többletalkalmazási időt. A NOINDEX nem érinti a rendszer táblákat, mivel az integritásellenőrzéseket mindig a rendszer táblák indexein végzik el.
• NO_INFOMSGS – Elnyom minden információs üzenetet.
• PHYSICAL_ONLY – Az ellenőrzést a lap- és rekordfejlécek fizikai szerkezetének integritására és az adatbázis kiosztási konzisztenciájára korlátozza. Ezt az ellenőrzést úgy tervezték, hogy az adatbázis fizikai konzisztenciájának ellenőrzését kis ráfordítással végezze, de képes észlelni a szakadt oldalakat, az ellenőrzőösszeg-hibákat és a gyakori hardverhibákat is, amelyek veszélyeztethetik a felhasználó adatait.
• TABLOCK – A DBCC CHECKDB-t zárak beszerzésére készteti ahelyett, hogy belső adatbázis-pillanatképet használna. Ez magában foglalja az adatbázis rövid távú kizárólagos (X)zárolását. A TABLOCK hatására a DBCC CHECKDB gyorsabban fut a nagy terhelés alatt lévő adatbázison, de csökkenti az adatbázisban elérhető párhuzamosságot aDBCC CHECKDB futása alatt.
• DATA_PURITY – A DBCC CHECKDB-t arra készteti, hogy ellenőrizze az adatbázist az érvénytelen vagy tartományon kívüli oszlopértékek tekintetében. Például a DBCC CHECKDB észleli a dátum- és időértékeket tartalmazó oszlopokat, amelyek nagyobbak vagy kisebbek, mint a datetime adattípus elfogadható tartománya; vagy a tizedes vagy közelítő számszerű adattípusú oszlopokat, amelyek skála- vagy pontossági értékei nem érvényesek.

Az alábbiakban egy másik szakaszban áttekintünk néhány REPAIR opciót.

Milyen gyakran kell ellenőrizni az SQL Server sérülését?

Minden nap minden percében. Csak vicceltem.

Ha van napi karbantartási ablak, akkor jó lenne naponta ellenőrizni az adatok sérülését. Minél gyorsabban észleled, annál kevesebb kárt okozhat. Úgy vettem észre, hogy sokan futtatják ezt hétvégén, különösen nagyobb adatbázisoknál. Nincs ezzel semmi helyes vagy helytelen, csak győződjön meg róla, hogy rendszeresen be van ütemezve.

A DBCC CHECKDB-t kell futtatnom a termelési környezetemben?

Nem, vagyis igen.

Az adatrongálódás ellenőrzéséhez nem jó a DBCC CHECKDB futtatása a tesztkörnyezeten…HAcsak nem állít vissza egy másolatot a termelési környezetéből a teszteléshez, majd futtatja azt. BRILLIANT!

Felmerülhet a kérdés, hogy egyes HA opciók, mint például az AlwaysOn, LogShipping, stb. alkalmasak-e? Nem, a termelési *éles* környezetét kell ellenőriznie.

Most, hogy a DBCC CHECKDB be van állítva és fut, mit keressek?

Gratulálok! Automatizálta és futtatja a DBCC CHECKDB-t, de most mi következik? Ha van egySQL ServerAgent feladat beállítása, akkor győződjön meg róla, hogy beállította azAdatbázis Mailt,egy operátort és egy értesítést a feladathoz. Ha a feladat sikeres, akkor folytassa a szép napját. Ha a feladat sikertelen, akkor van némi tennivalónk.

Egy ilyen hibát láthat:

vagy ez:

First, don’t panic. Másodszor, ellenőrizze a biztonsági mentéseket. A DBCC CHECKDB hibái általában elárulják, hogy mit kell tenni.

Az első hiba esetén a DBCC UPDATEUSAGE kijavítja a katalógusnézetek oldal- és sorszámozási pontatlanságait. Elég ártalmatlan.

A második hiba adatsérülést jelent. A hiba a repair_allow_data_loss használatát említi a minimális javítási szintként. Ez azt jelenti, hogy ezzel az argumentummal futtathatja az utasítást,de előfordulhat, hogy adatokat veszít. Ezért javaslom mindig a biztonsági másolatra való visszaállítást, ha lehet. Meg kell győződnünk arról, hogy a biztonsági mentés nem tartalmaz sérült adatokat, és meg akarjuk győződni arról, hogy nincs adatvesztés.

Hogyan javítsunk egy SQL Server adatbázist

Ha nincs biztonsági mentésünk, előfordulhat, hogy a DBCC CHECKDB-t kell használnunk javítási opcióval.Itt vannak a javítási lehetőségek, amelyeket használhatunk. Ezek vagy működnek, vagy nem, és csak végső megoldásként kell használni:

• REPAIR_ALLOW_DATA_LOSS – Megpróbálja kijavítani az összes bejelentett hibát.Ezek a javítások némi adatvesztéssel járhatnak.
• REPAIR_REBUILD – Olyan javításokat végez, amelyeknél nincs adatvesztés lehetősége. Ez magában foglalhat gyors javításokat, mint például a hiányzó sorok javítása a nem klaszterezett indexekben, és időigényesebb javításokat, mint például egy index újjáépítése.

Mint már említettem, nagyon fontos, hogy naprakész biztonsági mentésekkel rendelkezzünk a sérülések utáni helyreállításhoz. A korrupciót nem érdekli, hogy mennyi adatod van, milyen SQL-verziót futtatsz, vagy milyen puccos az adatközpontod.

Ezzel elég jól érzem magam, de mivel védhetem még az SQL-példányaimat?

A DBCC CHECKDB-t minden SQL-példányon futtatni kell, de van még néhány egyéb módszer, amely segíthet az adatrongálódás észlelésében/megelőzésében.

• SQL Server Agent Alerts – Brian Kelley írt egy szép tippet erről a témáról itt.
• Page verification – Győződjön meg róla, hogy az adatbázisai aCHECKSUM oldalellenőrzést használják. Ha még SQL 2005-öt vagy az alattiakat futtat, ez nem elérhető, de a frissítés után mindenképpen változtassa meg ezt a beállítást. Az oldalellenőrzési beállítások megtekintéséhez használja a következő utasítást:

select name, page_verify_option_desc from sys.databases 

Következő lépések

• Nézze meg azMSDN könyvtárat a DBCC CHECKDB-vel kapcsolatos részletesebb részletekért
• AzMSSQLTips.com egy szép tippgyűjteményt tartalmaz az adatbázis konzisztencia-ellenőrzéséről, amely szintén hasznos lehet.

Most Updated:

A szerzőről

Brady Upton adatbázis-adminisztrátor és SharePoint szupersztár Nashville-ben, TN-ben.
Minden tippem megtekintése

Kapcsolódó források

• Még több SQL Server DBA tipp…