Megosztás a következőn keresztül:

DBCC CHECKDB (Transact-SQL)

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseFelügyelt Azure SQL-példány

A megadott adatbázis összes objektumának logikai és fizikai integritását az alábbi műveletek végrehajtásával ellenőrzi:

  • Futtatja DBCC CHECKALLOC az adatbázisban.

  • Futtatja DBCC CHECKTABLE az adatbázis minden tábláján és nézetén.

  • Futtatja DBCC CHECKCATALOG az adatbázisban.

  • Ellenőrzi az adatbázis összes indexelt nézetének tartalmát.

  • Ellenőrzi a tábla metaadatai, a fájlrendszer könyvtárai és a fájlok közötti kapcsolatszintű konzisztenciát, amikor varbinary(max) adatokat tárol a fájlrendszerben a FILESTREAM használatával.

  • Ellenőrzi a Service Broker adatait az adatbázisban.

Ez azt jelenti, hogy a DBCC CHECKALLOC, DBCC CHECKTABLEvagy DBCC CHECKCATALOG parancsokat nem kell külön futtatni DBCC CHECKDB. A parancsok által végrehajtott ellenőrzésekkel kapcsolatos részletesebb információkért tekintse meg ezeknek a parancsoknak a leírását.

DBCC CHECKDB memóriaoptimalizált táblákat tartalmazó adatbázisokban támogatott, de az ellenőrzés csak lemezalapú táblákon történik. Az adatbázis biztonsági mentésének és helyreállításának részeként azonban CHECKSUM ellenőrzés történik a memóriaoptimalizált fájlcsoportokban lévő fájlok esetében.

Mivel a DBCC javítási lehetőségei nem érhetők el a memóriaoptimalizált táblákhoz, rendszeresen biztonsági másolatot kell készítenie az adatbázisokról, és tesztelnie kell a biztonsági másolatokat. Ha adatintegritási problémák lépnek fel egy memóriaoptimalizált táblában, a legutóbbi jól ismert biztonsági mentésből kell visszaállítania.

Transact-SQL szintaxis konvenciói

Szintaxis

DBCC CHECKDB
    [ [ ( database_name | database_id | 0
        [ , NOINDEX
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
    ) ]
    [ WITH
        {
            [ ALL_ERRORMSGS ]
            [ , EXTENDED_LOGICAL_CHECKS ]
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
            [ , MAXDOP = number_of_processors ]
        }
    ]
]

Érvek

| database_namedatabase_id | 0

Annak az adatbázisnak a neve vagy azonosítója, amelyhez az integritás-ellenőrzéseket futtatni szeretné. Ha nincs megadva, vagy ha 0 van megadva, a rendszer az aktuális adatbázist használja. Az adatbázisneveknek meg kell felelniük azonosítókszabályainak.

NOINDEX

Azt határozza meg, hogy a felhasználói táblák nem konklúziós indexeinek intenzív ellenőrzése nem történik meg. Ez a választás csökkenti a teljes végrehajtási időt. NOINDEX nincs hatással a rendszertáblákra, mert az integritás ellenőrzése mindig a rendszertábla-indexeken történik.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Megadja, hogy DBCC CHECKDB javítsa ki a talált hibákat. Csak végső megoldásként használja a REPAIR_* lehetőségeket. A megadott adatbázisnak egyfelhasználós módban kell lennie az alábbi javítási lehetőségek egyikének használatához.

  • REPAIR_ALLOW_DATA_LOSS

    Megpróbálja kijavítani az összes jelentett hibát. Ezek a javítások adatvesztést okozhatnak.

    Figyelmeztetés

    A REPAIR_ALLOW_DATA_LOSS beállítás több adatvesztést eredményezhet, mint ha egy utolsó ismert, jó biztonsági mentésből állít vissza. Lásd adatvesztésre vonatkozó figyelmeztetést REPAIR_ALLOW_DATA_LOSS

    A Microsoft mindig azt javasolja, hogy a felhasználók az utolsó ismert biztonsági mentésből állítsanak vissza elsődleges módszerként a DBCC CHECKDBáltal jelentett hibákból való helyreállításhoz. A REPAIR_ALLOW_DATA_LOSS lehetőség nem alternatíva egy ismert, jó biztonsági mentésből való visszaállításra. Ez egy vészhelyzeti végső megoldás, beállítás csak akkor ajánlott, ha a biztonsági másolatból való visszaállítás nem lehetséges.

    Bizonyos hibák, amelyeket csak a REPAIR_ALLOW_DATA_LOSS lehetőséggel lehet kijavítani, előfordulhat, hogy sor, oldal vagy oldalsorozat felszabadításával törlik a hibákat. A felszabadított adatok már nem érhetők el vagy állíthatók helyre a felhasználó számára, és a felszabadított adatok pontos tartalma nem határozható meg. Ezért előfordulhat, hogy a hivatkozási integritás nem lesz pontos a sorok vagy lapok felszabadítása után, mert a javítási művelet részeként nem ellenőrzi vagy tartja karban az idegenkulcs-korlátozásokat. A felhasználónak a DBCC CHECKCONSTRAINTS lehetőség használata után meg kell vizsgálnia az adatbázis hivatkozási integritását (REPAIR_ALLOW_DATA_LOSShasználatával).

    A javítás végrehajtása előtt létre kell hoznia az adatbázishoz tartozó fájlok fizikai másolatát. Ez magában foglalja az elsődleges adatfájlt (.mdf), a másodlagos adatfájlokat (.ndf), az összes tranzakciós naplófájlt (.ldf), valamint az adatbázist alkotó egyéb tárolókat, beleértve a teljes szöveges katalógusokat, a fájlstream-mappákat, a memóriaoptimalizált adatokat stb.

    A javítás végrehajtása előtt fontolja meg az adatbázis állapotának EMERGENCY módra való módosítását, és próbálja meg a lehető legtöbb információt kinyerni a kritikus táblákból, és menteni az adatokat.

  • REPAIR_FAST

    Csak a visszamenőleges kompatibilitás szintaxisát tartja karban. A rendszer nem végez javítási műveleteket.

  • REPAIR_REBUILD

    Olyan javításokat végez, amelyek nem rendelkeznek adatvesztéssel. Ez a beállítás gyors javításokat is tartalmazhat, például a hiányzó sorok kijavítását a nem rendezett indexekben, és több időt igénylő javítást, például egy index újraépítését.

    Ez az argumentum nem javítja ki a FILESTREAM-adatokat érintő hibákat.

Fontos

Mivel DBCC CHECKDB a REPAIR_* lehetőségek bármelyikével teljesen naplózható és helyreállítható, a Microsoft mindig azt javasolja a felhasználónak, hogy használja a DBCC CHECKDB a tranzakción belüli REPAIR_* beállításokkal (a parancs futtatása előtt hajtsa végre a BEGIN TRANSACTION), hogy a felhasználó meggyőződjön arról, hogy el szeretné fogadni a művelet eredményeit. Ezután a felhasználó végrehajthat COMMIT TRANSACTION a javítási művelet által végzett összes munka véglegesítéséhez. Ha a felhasználó nem szeretné elfogadni a művelet eredményeit, végrehajthat egy ROLLBACK TRANSACTION a javítási műveletek hatásainak visszavonásához.

A hibák kijavításához javasoljuk, hogy készítsen biztonsági másolatot a visszaállításról. A javítási műveletek nem veszik figyelembe a táblákon vagy a táblák között esetlegesen fennálló korlátozásokat. Ha a megadott tábla egy vagy több korlátozásba ütközik, javasoljuk, hogy a javítási művelet után futtassa DBCC CHECKCONSTRAINTS. Ha REPAIR_*kell használnia, futtassa a DBCC CHECKDB javítás nélkül, hogy megtalálja a használni kívánt javítási szintet. Ha a REPAIR_ALLOW_DATA_LOSS szintet használja, javasoljuk, hogy biztonsági másolatot készít az adatbázisról, mielőtt ezzel a beállítással futtatja DBCC CHECKDB.

ALL_ERRORMSGS

Megjeleníti az objektumonkénti összes jelentett hibát. Alapértelmezés szerint minden hibaüzenet megjelenik. Ennek a beállításnak a megadása vagy kihagyása nincs hatással. A hibaüzenetek objektumazonosító szerint vannak rendezve, kivéve azokat az üzeneteket, amelyeket tempdb adatbázisból.

EXTENDED_LOGICAL_CHECKS

Ha a kompatibilitási szint 100, és az SQL Server 2008 -ban (10.0.x) van bevezetve, ez a beállítás logikai konzisztencia-ellenőrzéseket végez egy indexelt nézeten, XML-indexeken és térbeli indexeken, ahol jelen van.

További információ: Logikai konzisztencia-ellenőrzések végrehajtása az indexeken a cikk későbbi részében.

NO_INFOMSGS

Letiltja az összes tájékoztató üzenetet.

TABLOCK

A DBCC CHECKDB belső adatbázis-pillanatkép használata helyett zárolások lekérését okozza. Ez magában foglalja az adatbázis rövid távú kizárólagos (X) zárolását. TABLOCK DBCC CHECKDB gyorsabban fut egy nagy terhelésű adatbázison, de csökkenti az adatbázison elérhető egyidejűséget, miközben DBCC CHECKDB fut.

Fontos

TABLOCK korlátozza az elvégzett ellenőrzéseket; DBCC CHECKCATALOG nem fut az adatbázisban, és a Service Broker adatai nincsenek érvényesítve.

BECSLÉS

Megjeleníti a tempdb futtatásához szükséges DBCC CHECKDB terület becsült mennyiségét az összes többi megadott beállítással. A tényleges adatbázis-ellenőrzés nem történik meg.

PHYSICAL_ONLY

Az oldal és a rekordfejlécek fizikai szerkezetének integritására és az adatbázis foglalási konzisztenciájára korlátozza az ellenőrzést. Ez az ellenőrzés az adatbázis fizikai konzisztenciájának kis mértékű terhelésellenőrzésére szolgál, de képes észlelni az elszakított oldalakat, ellenőrzőösszegeket és a felhasználók adatait veszélyeztető gyakori hardverhibákat is.

A DBCC CHECKDB teljes futtatása jelentősen tovább tarthat, mint a korábbi verziók. Ez a viselkedés a következő esetekben fordul elő:

  • A logikai ellenőrzések átfogóbbak.
  • Az ellenőrizendő mögöttes struktúrák némelyike összetettebb.
  • Számos új ellenőrzés lett bevezetve, hogy az új funkciókat is tartalmazza.

Ezért a PHYSICAL_ONLY beállítás használata sokkal rövidebb futási időt okozhat a DBCC CHECKDB nagy adatbázisokon, és az éles rendszereken való gyakori használathoz ajánlott. Továbbra is azt javasoljuk, hogy rendszeres időközönként DBCC CHECKDB teljes körűen fusson. A futtatások gyakorisága az egyes vállalkozásokra és éles környezetekre jellemző tényezőktől függ.

Ez az argumentum mindig NO_INFOMSGS, és a javítási lehetőségek egyikével sem engedélyezett.

Figyelmeztetés

A PHYSICAL_ONLY megadása miatt DBCC CHECKDB kihagyja a FILESTREAM-adatok összes ellenőrzését.

DATA_PURITY

Érvénytelen vagy tartományon kívüli oszlopértékeket DBCC CHECKDB ellenőrizni az adatbázisban. DBCC CHECKDB például olyan dátum- és időértékekkel rendelkező oszlopokat észlel, amelyek nagyobbak vagy kisebbek a dátum/idő adattípus elfogadható tartományánál; vagy nem érvényes skálázási vagy pontossági értékekkel rendelkező decimális vagy közelítő numerikus adattípusú oszlopokat.

Az oszlopérték-integritás ellenőrzése alapértelmezés szerint engedélyezve van, és nincs szükség a DATA_PURITY beállításra. Az SQL Server korábbi verzióiról frissített adatbázisok esetében az oszlopérték-ellenőrzések alapértelmezés szerint nem engedélyezettek, amíg DBCC CHECKDB WITH DATA_PURITY hibamentesen nem fut az adatbázisban. Ezt követően alapértelmezés szerint DBCC CHECKDB ellenőrzi az oszlop-érték integritást. Ha többet szeretne megtudni arról, hogy a CHECKDB hogyan befolyásolhatja az adatbázis frissítése az SQL Server korábbi verzióiról, tekintse meg a cikk későbbi, Megjegyzések szakaszát.

Figyelmeztetés

Ha PHYSICAL_ONLY van megadva, az oszlopintegritási ellenőrzések nem lesznek végrehajtva.

A beállítás által jelentett érvényesítési hibák nem javíthatók a DBCC javítási beállításaival. A hibák manuális kijavításáról további információt a MSSQLSERVER_2570című témakörben talál.

MAXDOP

: SQL Server 2014 (12.x) Service Pack 2 és újabb verziók

Felülbírálja a max degree of parallelismsp_configure konfigurációs beállítását az utasításhoz. A MAXDOP túllépheti a sp_configureáltal konfigurált értéket. Ha MAXDOP túllépi az Erőforrás-vezérlővel konfigurált értéket, az SQL Server adatbázismotorja a Resource Governor MAXDOP értéket használja, amelyet az ALTER SZÁMÍTÁSI FELADATCSOPORTcímű cikkben ismertetett. A max degree of parallelism konfigurációs beállításhoz használt összes szemantikai szabály alkalmazható a MAXDOP lekérdezési tipp használatakor. További információ: kiszolgálókonfiguráció: a párhuzamosság maximális foka.

Figyelmeztetés

Ha MAXDOP értéke nulla, akkor az SQL Server kiválasztja a használni kívánt max degree of parallelism.

Megjegyzések

DBCC CHECKDB nem vizsgálja meg a letiltott indexeket. A letiltott indexekről további információt az Indexek és korlátozások letiltásacímű témakörben talál.

Ha egy felhasználó által definiált típus bájtsorrendezésként van megjelölve, a felhasználó által megadott típusnak csak egy szerializálása lehet. Ha nincs konzisztens szerializálása a byte-ordered felhasználó által definiált típusoknak, a DBCC CHECKDB futtatásakor 2537-et eredményez. További információ: User-Defined típusok létrehozása – Követelmények.

Mivel a erőforrás-adatbázis csak egyfelhasználós módban módosítható, a DBCC CHECKDB parancs közvetlenül nem futtatható rajta. Ha azonban a DBCC CHECKDB a főadatbázisonhajtja végre, egy második CHECKDB is fut az erőforrás-adatbázisban. Ez azt jelenti, hogy DBCC CHECKDB további eredményeket adhat vissza. A parancs további eredményhalmazokat ad vissza, ha nincsenek megadva beállítások, vagy ha a PHYSICAL_ONLY vagy ESTIMATEONLY beállítás be van állítva.

Az SQL Server 2005 (9.x) Service Pack 2 és újabb verzióiban a DBCC CHECKDB végrehajtása már nem törli az SQL Server-példány csomaggyorsítótárát. Az SQL Server 2005 (9.x) Service Pack 2 előtt a DBCC CHECKDB végrehajtása törli a csomag gyorsítótárát. A tervgyorsítótár törlése az összes későbbi végrehajtási terv újrafordítását okozza, és a lekérdezési teljesítmény hirtelen, átmeneti csökkenését okozhatja.

Logikai konzisztencia-ellenőrzések végrehajtása indexeken

Az indexek logikai konzisztencia-ellenőrzése az adatbázis kompatibilitási szintjétől függően változik, az alábbiak szerint:

  • Ha a kompatibilitási szint legalább 100 (az SQL Server 2008-ban (10.0.x)):

  • Ha nincs megadva NOINDEX, DBCC CHECKDB fizikai és logikai konzisztencia-ellenőrzéseket is hajt végre egyetlen táblán és az összes nemclustered indexen. Az XML-indexeken, térbeli indexeken és indexelt nézeteken azonban alapértelmezés szerint csak a fizikai konzisztencia-ellenőrzések lesznek végrehajtva.

  • Ha WITH EXTENDED_LOGICAL_CHECKS van megadva, a logikai ellenőrzéseket indexelt nézetben, XML-indexeken és térbeli indexeken hajtja végre, ahol jelen van. Alapértelmezés szerint a fizikai konzisztencia-ellenőrzéseket a logikai konzisztencia ellenőrzése előtt hajtja végre a rendszer. Ha NOINDEX is meg van adva, csak a logikai ellenőrzések lesznek végrehajtva.

Ezek a logikai konzisztencia keresztellenőrzést végez az indexobjektum belső indextábláján a hivatkozó felhasználói táblával. A sorok részletes megkereséséhez egy belső lekérdezés jön létre a belső és a felhasználói táblák teljes metszetének végrehajtásához. A lekérdezés futtatása jelentős hatással lehet a teljesítményre, és az előrehaladása nem követhető nyomon. Ezért azt javasoljuk, hogy csak akkor adjon meg WITH EXTENDED_LOGICAL_CHECKS, ha olyan indexproblémákra gyanakszik, amelyek nem kapcsolódnak a fizikai sérüléshez, vagy ha az oldalszintű ellenőrzőösszegek ki lettek kapcsolva, és oszlopszintű hardversérülésre gyanakszik.

  • Ha az index szűrt index, DBCC CHECKDB konzisztencia-ellenőrzéseket végez annak ellenőrzéséhez, hogy az indexbejegyzések megfelelnek-e a szűrő predikátumának.

  • Ha a kompatibilitási szint legalább 90, kivéve, ha NOINDEX van megadva, DBCC CHECKDB fizikai és logikai konzisztencia-ellenőrzést is végez egyetlen táblán vagy indexelt nézetben, valamint az összes nem rendezett és XML-indexen. A térbeli indexek nem támogatottak.

  • Az SQL Server 2016 (13.x) és újabb verzióiban a fenntartott számított oszlopok, az UDT-oszlopok és a szűrt indexek további ellenőrzései alapértelmezés szerint nem futnak a drága kifejezésértékelések elkerülése érdekében. Ez a változás jelentősen csökkenti az ilyen objektumokat tartalmazó adatbázisok CHECKDB időtartamát. Az objektumok fizikai konzisztencia-ellenőrzése azonban mindig befejeződik. Csak EXTENDED_LOGICAL_CHECKS beállítás megadásakor végzik el a kifejezésértékeléseket a EXTENDED_LOGICAL_CHECKS beállítás részeként már meglévő logikai ellenőrzések (indexelt nézet, XML-indexek és térbeli indexek) mellett.

Az adatbázis kompatibilitási szintjének megismerése

Belső adatbázis-pillanatkép

DBCC CHECKDB az ellenőrzések végrehajtásához szükséges tranzakciós konzisztencia belső adatbázis-pillanatképet használ. Ez megakadályozza a blokkolási és egyidejűségi problémákat a parancsok végrehajtásakor. További információ: Adatbázis-pillanatkép ritka fájl méretének megtekintése, valamint a DBCC belső adatbázis-pillanatkép-használati szakasza DBCC. Ha nem hozható létre pillanatkép, vagy TABLOCK van megadva, DBCC CHECKDB a szükséges konzisztencia eléréséhez zárolásokat szerez be. Ebben az esetben kizárólagos adatbázis-zárolásra van szükség a foglalási ellenőrzések végrehajtásához, és megosztott táblazárolásokra van szükség a táblaellenőrzések végrehajtásához.

DBCC CHECKDB sikertelen a master adatbázison való futtatáskor, ha nem hozható létre belső adatbázis-pillanatkép.

A DBCC CHECKDBtempdb futtatása nem végez foglalási vagy katalógusellenőrzéseket, és a táblaellenőrzések végrehajtásához megosztott táblazárakat kell beszereznie. Ennek az az oka, hogy teljesítménybeli okokból az adatbázis-pillanatképek nem érhetők el tempdb. Ez azt jelenti, hogy a szükséges tranzakciós konzisztencia nem kérhető le.

Hogyan hoz létre a DBCC CHECKDB egy belső pillanatkép-adatbázist az SQL Server 2014-től kezdve

  1. DBCC CHECKDB létrehoz egy belső pillanatkép-adatbázist.

  2. A belső pillanatkép-adatbázis fizikai fájlok használatával jön létre. Például egy olyan database_id = 10 adatbázis esetében, amely három E:\Data\my_DB.mdf, E:\Data\my_DB.ndfés E:\Data\my_DB.ldffájllal rendelkezik, a belső pillanatkép-adatbázis E:\Data\my_DB.mdf_MSSQL_DBCC11 és E:\Data\my_DB.ndf_MSSQL_DBCC11 fájlok használatával jön létre. A pillanatkép database_iddatabase_id + 1. Azt is vegye figyelembe, hogy az új fájlok ugyanabban a mappában jönnek létre az elnevezési konvencióval <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>. A tranzakciónaplóhoz nem jön létre ritka fájl.

  3. Az új fájlok a fájlrendszer szintjén ritka fájlokként vannak megjelölve. Az új fájlok által használt lemez mérete attól függően növekszik, hogy mennyi adat frissül a forrásadatbázisban a DBCC CHECKDB parancs során. Az új fájlok méretének ugyanaz a fájl, mint a .mdf vagy .ndf fájl.

  4. Az új fájlok DBCC CHECKDB feldolgozás végén törlődnek. A DBCC CHECKDB által létrehozott ritka fájlokhoz a "Törlés bezáráskor" attribútum van beállítva.

Figyelmeztetés

Ha az operációs rendszer váratlan leállítást tapasztal, miközben a DBCC CHECKDB parancs folyamatban van, a rendszer nem távolítja el ezeket a fájlokat. Helyet foglalnak, és hibákat okozhatnak a jövőbeli DBCC CHECKDB végrehajtások során. Ebben az esetben törölheti ezeket az új fájlokat, miután meggyőződett arról, hogy jelenleg nincs DBCC CHECKDB parancs végrehajtása.

Az új fájlok a szokásos fájl-segédprogramok, például a Windows Explorer használatával láthatók.

Jegyzet

Az SQL Server 2014 (12.x) előtt fájlstreamek lettek használva a belső pillanatképfájlok létrehozásához. A névvel ellátott fájlstreamek <filename.extension>:MSSQL_DBCC<database_id_of_snapshot>formátumot használták. Az elnevezett fájlstreamek nem láthatók szokásos fájl-segédprogramokkal, például a Windows Intézővel. Ezért az SQL Server 2012 (11.x) és korábbi verzióiban 7926-os és 5030-os hibaüzenetek jelenhetnek meg, amikor egy DBCC CHECKDBformázott köteten található adatbázisfájlok parancsát futtatja. Ennek az az oka, hogy a fájlstreamek nem hozhatók létre Rugalmas fájlrendszer (RefS).

FILESTREAM-adatok ellenőrzése és javítása

Ha a FILESTREAM engedélyezve van egy adatbázishoz és táblához, akkor opcionálisan tárolhat varbinary(max) bináris nagy objektumokat (BLOB-okat) a fájlrendszerben. Ha DBCC CHECKDB használ olyan adatbázison, amely blobokat tárol a fájlrendszerben, a DBCC ellenőrzi a fájlrendszer és az adatbázis közötti kapcsolatszintű konzisztenciát.

Ha például egy tábla egy varbinary(max) oszlopot tartalmaz, amely a FILESTREAM attribútumot használja, DBCC CHECKDB ellenőrzi, hogy van-e egy-az-egyhez megfeleltetés a fájlrendszer könyvtárai és fájljai, valamint a táblasorok, oszlopok és oszlopértékek között. DBCC CHECKDB kijavíthatja a sérülést, ha megadja a REPAIR_ALLOW_DATA_LOSS beállítást. A FILESTREAM sérülésének javítása érdekében a DBCC törli az összes olyan táblasort, amelyből hiányoznak a fájlrendszer adatai.

Ajánlott eljárások

Javasoljuk, hogy használja a PHYSICAL_ONLY lehetőséget az éles rendszerek gyakori használatához. A PHYSICAL_ONLY használata jelentősen lerövidítheti a nagy adatbázisokon DBCC CHECKDB futásideje. Azt is javasoljuk, hogy rendszeresen futtassa a DBCC CHECKDB beállítás nélkül. A futtatások végrehajtásának gyakorisága az egyes vállalkozásoktól és azok éles környezetétől függ.

Felügyelt Azure SQL-példányon a rendelkezésre álló tárterületnek tartalmaznia kell a DBCC CHECKDBáltal létrehozott teljes belső adatbázis-pillanatképfájlt, függetlenül attól, hogy az adatok ténylegesen mekkora részét használják fel. Ez olyan helyzethez vezethet, amikor a DBCC CHECKDB végrehajtása egy nagyon nagy, de ritka adatbázison (az adatok mérete sokkal kisebb, mint az adatbázisfájl mérete) meghiúsulhat, mivel nincs hely a felügyelt SQL-példányon. Ha DBCC CHECKDB a végrehajtás során az összes rendelkezésre álló tárterületet felhasználja, a következő hibaüzenet jelenik meg:

Msg 1133, Level 16, State 3, Line 1
The managed instance has reached its storage limit. To storage usage for the managed instance cannot exceed (...) MBs.
You might need to temporarily scale up your SQL managed instance storage capacity before running `DBCC CHECKDB` again.

Objektumok ellenőrzése párhuzamosan

Alapértelmezés szerint DBCC CHECKDB az objektumok párhuzamos ellenőrzését hajtja végre. A párhuzamosság mértékét a lekérdezésfeldolgozó automatikusan meghatározza. A párhuzamosság maximális foka ugyanúgy van konfigurálva, mint a párhuzamos lekérdezések. A DBCC-ellenőrzéshez elérhető processzorok maximális számának korlátozásához használja a sp_configure. További információ: kiszolgálókonfiguráció: a párhuzamosság maximális foka. A párhuzamos ellenőrzés letiltható a 2528-at jelző nyomkövetési jelzővel. További információ: Nyomkövetési jelzők beállítása a DBCC TRACEON használatával.

Jegyzet

Ez a funkció nem érhető el az SQL Server minden kiadásában. További információkért tekintse meg a párhuzamos konzisztencia-ellenőrzést az RDBMS kezelhetőségikiadások és az SQL Server 2022támogatott funkcióinak szakaszában.

A DBCC-hibaüzenetek ismertetése

A DBCC CHECKDB parancs befejeződése után a rendszer egy üzenetet ír az SQL Server hibanaplójába. Ha a DBCC parancs sikeresen végrehajtja a parancsot, az üzenet a sikerességet és a parancs futtatásának időtartamát jelzi. Ha a DBCC-parancs hiba miatt leáll az ellenőrzés végrehajtása előtt, az üzenet azt jelzi, hogy a parancs leállt, egy állapotérték és a parancs futási ideje. Az alábbi táblázat felsorolja és ismerteti az üzenetben szereplő állapotértékeket.

Állam Leírás
0 A 8930-es hibaszám lett előállítva. Ez azt jelzi, hogy a metaadatok sérülése megszakította a DBCC parancsot.
1 A 8967-es hibaszám ki lett emelve. Belső DBCC-hiba történt.
2 Hiba történt a vészmódú adatbázis javítása során.
3 Ez azt jelzi, hogy a metaadatok sérülése megszakította a DBCC parancsot.
4 A rendszer érvényességi vagy hozzáférési szabálysértést észlelt.
5 Ismeretlen hiba történt, amely megszakította a DBCC parancsot.

Az SQL Server rögzíti azt a dátumot és időpontot, amikor egy adatbázis konzisztencia-ellenőrzését hiba nélkül futtatták (vagy "tiszta" konzisztencia-ellenőrzést). Ez az úgynevezett last known clean check. Az adatbázis első indításakor a rendszer ezt a dátumot az Eseménynaplóba (EventID-17573) írja, a hibanapló pedig a következő formátumban:

CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

Hibajelentés

Az SQL Server SQLDump<nnnn>.txt könyvtárában akkor jön létre egy veremkép (SQLDump<nnnn>.log, SQLDump<nnnn>.mdmp, LOG), amikor DBCC CHECKDB sérülési hibát észlel. Ha a szolgáltatáshasználati adatgyűjtés és hibajelentési funkciók engedélyezve vannak az SQL Server-példányon, a fájl automatikusan továbbítja a Microsoftnak. Az összegyűjtött adatok az SQL Server funkcióinak javítására szolgálnak. A memóriaképfájl tartalmazza a DBCC CHECKDB parancs eredményeit és a további diagnosztikai kimenetet. Az hozzáférés az SQL Server szolgáltatásfiókjára és a sysadmin szerepkör tagjaira korlátozódik. Alapértelmezés szerint a sysadmin szerepkör a Windows BUILTIN\Administrators csoport és a helyi rendszergazda csoport összes tagját tartalmazza. A DBCC parancs nem hiúsul meg, ha az adatgyűjtési folyamat meghiúsul.

Hibák elhárítása

Ha a DBCC CHECKDBbármilyen hibát jelez, javasoljuk, hogy az adatbázis biztonsági mentéséből visszaállítsa az adatbázist ahelyett, hogy a DBCC CHECKDB az egyik REPAIR_* beállítással futtatja. Ha nincs biztonsági másolat, a futó javítás kijavítja a jelentett hibákat. A használni kívánt javítási lehetőség a jelentett hibák listájának végén van megadva. A hibák REPAIR_ALLOW_DATA_LOSS beállítással történő kijavításához azonban szükség lehet néhány oldal, és így néhány adat törlésére.

Bizonyos körülmények között előfordulhat, hogy olyan értékeket ad meg az adatbázisba, amelyek az oszlop adattípusa alapján érvénytelenek vagy tartományon kívüliek. DBCC CHECKDB olyan oszlopértékeket képes észlelni, amelyek nem minden oszlop adattípusra érvényesek. Ezért a DBCC CHECKDB az SQL Server korábbi verzióiról frissített adatbázisok DATA_PURITY beállításával való futtatása előre létező oszlopérték-hibákat jelezhet. Mivel az SQL Server nem tudja automatikusan kijavítani ezeket a hibákat, az oszlop értékét manuálisan kell frissíteni. Ha CHECKDB észlel ilyen hibát, CHECKDB egy figyelmeztetést, a 2570-es hibaszámot, valamint az érintett sor azonosítására és a hiba manuális kijavítására szolgáló információkat ad vissza.

A javítás elvégezhető egy felhasználói tranzakcióval, hogy a felhasználó visszaállítsa a végrehajtott módosításokat. Ha a javítások vissza lettek állítva, az adatbázis továbbra is hibákat tartalmaz, és biztonsági másolatból kell visszaállítani. A javítás befejezése után biztonsági másolatot készít az adatbázisról.

Adatbázis vészhelyzeti módban jelentkező hibák elhárítása

Ha egy adatbázis vész üzemmódra van állítva az ALTER DATABASE utasítással, DBCC CHECKDB speciális javításokat végezhet az adatbázison, ha a REPAIR_ALLOW_DATA_LOSS beállítás meg van adva. Ezek a javítások lehetővé teszik, hogy a helyreállíthatatlan adatbázisok fizikailag konzisztens állapotban legyenek újra online állapotban. Ezeket a javításokat végső megoldásként kell használni, és csak akkor, ha nem tudja visszaállítani az adatbázist biztonsági másolatból. Ha az adatbázis vészhelyzeti üzemmódra van állítva, az adatbázis READ_ONLY van megjelölve, a naplózás le van tiltva, és a hozzáférés a sysadmin rögzített kiszolgálói szerepkör tagjaira korlátozódik.

Jegyzet

A DBCC CHECKDB parancsot nem futtathatja vészhelyzeti módban egy felhasználói tranzakción belül, és nem állíthatja vissza a tranzakciót a végrehajtás után.

Ha az adatbázis vészhelyzeti módban van, és DBCC CHECKDB a REPAIR_ALLOW_DATA_LOSS záradékkal fut, a következő műveleteket hajtja végre:

  • DBCC CHECKDB olyan oldalakat használ, amelyek I/O- vagy ellenőrzőösszeg-hibák miatt nem érhetők el, mintha a hibák nem történtek volna meg. Ezzel növeli az adatbázisból való adat-helyreállítás esélyét.

  • DBCC CHECKDB rendszeresen naplóalapú helyreállítási technikákkal próbálja helyreállítani az adatbázist.

  • Ha az adatbázis helyreállítása sikertelen a tranzakciónapló sérülése miatt, a tranzakciónapló újraépül. A tranzakciónapló újraépítése a tranzakciós konzisztencia elvesztését eredményezheti.

Figyelmeztetés

A REPAIR_ALLOW_DATA_LOSS beállítás több adatvesztést eredményezhet, mint ha egy utolsó ismert, jó biztonsági mentésből állít vissza. Lásd adatvesztésre vonatkozó figyelmeztetést REPAIR_ALLOW_DATA_LOSS

Ha a DBCC CHECKDB parancs sikeres, az adatbázis fizikailag konzisztens állapotban van, és az adatbázis állapota ONLINE értékre van állítva. Az adatbázis azonban tartalmazhat egy vagy több tranzakciós inkonzisztenciát. Javasoljuk, hogy futtassa DBCC CHECKCONSTRAINTS az üzleti logika hibáinak azonosításához és az adatbázis azonnali biztonsági mentéséhez.

Ha a DBCC CHECKDB parancs sikertelen, az adatbázis nem javítható.

Adatvesztési figyelmeztetés REPAIR_ALLOW_DATA_LOSS

A REPAIR_ALLOW_DATA_LOSS lehetőség az SQL Server támogatott funkciója. Előfordulhat azonban, hogy nem mindig ez a legjobb megoldás az adatbázisok fizikailag konzisztens állapotba helyezéséhez. Ha sikeres, a REPAIR_ALLOW_DATA_LOSS lehetőség adatvesztést okozhat.

Valójában több adat veszhet el, mint ha egy felhasználó visszaállítja az adatbázist az utolsó ismert jó biztonsági mentésből. A Microsoft mindig azt javasolja, hogy a felhasználók az utolsó ismert biztonsági mentésből állítsanak vissza elsődleges módszerként a DBCC CHECKDBáltal jelentett hibákból való helyreállításhoz.

A REPAIR_ALLOW_DATA_LOSS lehetőség az, nem egy ismert, jó biztonsági mentésből való visszaállítás alternatívát. Ez egy vészhelyzeti végső megoldás, lehetőség csak akkor ajánlott, ha a biztonsági másolatból való visszaállítás nem lehetséges.

A napló újraépítése után nincs teljes ACID-garancia.

Miután újraépíti a naplót, a DBCC CHECKDB automatikusan végrehajtja, és mindkét jelentés és a fizikai konzisztencia problémáinak javítása történik.

A logikai adatkonzisztencia és az üzleti logika által kikényszerített kényszereket manuálisan kell érvényesíteni.

A tranzakciónapló mérete az alapértelmezett méretre marad, és manuálisan vissza kell állítani a legutóbbi méretre.

A DBCC CHECKDB futtatása REPAIR_ALLOW_DATA_LOSS replikált adatbázisokban

A DBCC CHECKDB parancs REPAIR_ALLOW_DATA_LOSS beállítással való futtatása hatással lehet a felhasználói adatbázisokra (közzétételi és előfizetési adatbázisokra) és a replikáció által használt terjesztési adatbázisra. A közzétételi és előfizetési adatbázisok közé tartoznak a közzétett táblák és a replikáció metaadatainak táblái. Vegye figyelembe az alábbi lehetséges problémákat ezekben az adatbázisokban:

  • Közzétett táblák. Előfordulhat, hogy a CHECKDB folyamat által a sérült felhasználói adatok javítása érdekében végrehajtott műveletek nem replikálhatók:

  • Az egyesítési replikáció eseményindítókkal követi nyomon a közzétett táblák módosításait. Ha a CHECKDB folyamat sorokat szúr be, frissít vagy töröl, az eseményindítók nem aktiválódnak; ezért a módosítás nem replikálódik.

  • A tranzakciós replikáció a tranzakciónapló használatával követi nyomon a közzétett táblák módosításait. A Naplóolvasó ügynök ezután áthelyezi ezeket a módosításokat a terjesztési adatbázisba. Egyes DBCC-javítások, bár naplózva vannak, a Naplóolvasó ügynök nem tudja replikálni. Ha például egy adatoldalt felszabadít a CHECKDB folyamat, a Naplóolvasó ügynök nem fordítja le ezt a felszabadítást DELETE utasításra; ezért a módosítás nem replikálódik.

  • Replikációs metaadattáblák. Az CHECKDB folyamat által a sérült replikáció metaadattábláinak javításához végrehajtott műveletekhez el kell távolítani és újra kell konfigurálni a replikációt.

Ha a DBCC CHECKDB parancsot a REPAIR_ALLOW_DATA_LOSS beállítással kell futtatnia egy felhasználói adatbázisban vagy terjesztési adatbázisban:

  1. Kapcsolja ki a rendszert: Állítsa le a tevékenységet az adatbázison és a replikációs topológiában lévő összes többi adatbázison, majd próbálja meg szinkronizálni az összes csomópontot. További információ: Replikációs topológia (replikáció Transact-SQL programozás).

  2. Hajtsa végre DBCC CHECKDB.

  3. Ha a DBCC CHECKDB jelentés tartalmazza a terjesztési adatbázis bármely táblájának vagy egy felhasználói adatbázis replikációs metaadattábláinak javítását, távolítsa el és konfigurálja újra a replikációt. További információ: Közzététel és terjesztés letiltása.

  4. Ha a DBCC CHECKDB jelentés tartalmazza a replikált táblák javítását, végezzen adatérvényesítést annak megállapításához, hogy vannak-e különbségek a kiadványban és az előfizetési adatbázisokban lévő adatok között.

Eredményhalmaz

DBCC CHECKDB a következő eredményhalmazt adja vissza. Az értékek eltérőek lehetnek, kivéve, ha a ESTIMATEONLY, PHYSICAL_ONLYvagy NO_INFOMSGS beállítások meg vannak adva:

DBCC results for 'model'.
Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.
Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.
Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.
Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.

DBCC results for 'sys.sysrowsetcolumns'.
There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.

DBCC results for 'sys.sysrowsets'.
There are 97 rows in 1 pages for object 'sys.sysrowsets'.

DBCC results for 'sysallocunits'.
There are 195 rows in 3 pages for object 'sysallocunits'.
There are 0 rows in 0 pages for object "sys.sysasymkeys".

DBCC results for 'sys.syssqlguides'.
There are 0 rows in 0 pages for object "sys.syssqlguides".

DBCC results for 'sys.queue_messages_1977058079'.
There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".

DBCC results for 'sys.queue_messages_2009058193'.
There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".

DBCC results for 'sys.queue_messages_2041058307'.
There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".

CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB NO_INFOMSGS megadásakor a következő eredményhalmazt (üzenetet) adja vissza:

The command(s) completed successfully.

DBCC CHECKDB PHYSICAL_ONLY megadásakor a következő eredményhalmazt adja vissza:

DBCC results for 'model'.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB a következő eredményhalmazt adja vissza ESTIMATEONLY megadásakor.

Estimated TEMPDB space needed for CHECKALLOC (KB)
-------------------------------------------------
13

(1 row(s) affected)

Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
57

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Engedélyek

A sysadmin rögzített kiszolgálói szerepkörben vagy a db_owner rögzített adatbázis-szerepkörben való tagság szükséges.

Példák

Egy. Ellenőrizze az aktuális és egy másik adatbázist is

Az alábbi példa DBCC CHECKDB hajt végre az aktuális adatbázishoz és a AdventureWorks2025 adatbázishoz.

-- Check the current database.
DBCC CHECKDB;
GO

-- Check the AdventureWorks2022 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2022, NOINDEX);
GO

B. Ellenőrizze az aktuális adatbázist, és tiltsa le az információs üzeneteket

Az alábbi példa ellenőrzi az aktuális adatbázist, és letiltja az összes tájékoztató üzenetet.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Kapcsolódó tartalom

  • Last updated on