DBCC ELLENŐRZŐASZTAL (Transact-SQL)

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

Ellenőrzi a táblázatot vagy indexelt nézetet alkotó összes oldal és struktúra integritását.

Transact-SQL szintaxis konvenciói

Szintaxis

DBCC CHECKTABLE
(
    table_name | view_name
    [ , { NOINDEX | index_id }
     | , { 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

| table_nameview_name

Az a tábla vagy indexelt nézet, amelyhez integritás-ellenőrzéseket kell futtatni. A tábla- vagy nézetneveknek 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 ne történjen meg. Ez csökkenti a teljes végrehajtási időt. NOINDEX nincs hatással a rendszertáblákra, mert az integritás-ellenőrzéseket mindig minden rendszertábla-indexen elvégzik.

index_id

Az indexazonosítási (ID) szám, amelyhez integritás-ellenőrzéseket kell futtatni. Ha index_id van megadva, DBCC CHECKTABLE csak az adott indexen futtatja az integritás-ellenőrzéseket, valamint a halom vagy a fürtözött indexet.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Megadja, hogy DBCC CHECKTABLE javítsa ki a talált hibákat. A javítási lehetőség használatához az adatbázisnak egyfelhasználós módban kell lennie.

• REPAIR_ALLOW_DATA_LOSS

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

• Gyors_javítás

  A szintaxis csak a visszamenőleges kompatibilitás érdekében van fenntartva. A rendszer nem végez javítási műveleteket.

• JAVÍTÁS_ÚJJÁÉPÍTÉS

  Olyan javításokat végez, amelyek nem rendelkeznek adatvesztéssel. Ilyenek lehetnek például a gyors javítások, például a hiányzó sorok kijavítása nemclustered indexekben, valamint több időigényes javítás, például egy index újraépítése.

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

Fontos

Csak végső megoldásként használja a JAVÍTÁS lehetőségeket. 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 azok 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 javítást kell használnia, futtassa a DBCC CHECKTABLE 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 CHECKTABLE.

ALL_ERRORMSGS

Korlátlan számú hibát jelenít meg. Alapértelmezés szerint minden hibaüzenet megjelenik. Ennek a beállításnak a megadása vagy kihagyása nincs hatással.

EXTENDED_LOGICAL_CHECKS

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

További információ: A cikk későbbi, Megjegyzések szakaszában indexek logikai konzisztencia-ellenőrzése.

NO_INFOMSGS

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

TABLOCK

A DBCC CHECKTABLE belső adatbázis-pillanatkép használata helyett egy megosztott tábla zárolásának lekérését okozza. TABLOCK DBCC CHECKTABLE gyorsabban fut egy táblán nagy terhelés mellett, de csökkenti a táblán elérhető egyidejűséget, miközben DBCC CHECKTABLE fut.

BECSLÉS

Megjeleníti a tempdb futtatásához szükséges DBCC CHECKTABLE terület becsült mennyiségét az összes többi megadott beállítással.

PHYSICAL_ONLY

Korlátozza az oldal fizikai szerkezetének integritását, a rekordfejléceket és a B-fák fizikai szerkezetét. Úgy tervezték, hogy a táblázat fizikai konzisztenciájának kis mértékű terhelésellenőrzését biztosítsa, ez az ellenőrzés képes észlelni az elszakított oldalakat és az adatokat veszélyeztető gyakori hardverhibákat is. A DBCC CHECKTABLE teljes futtatása jelentősen tovább tarthat, mint a korábbi verziókban. Ez a viselkedés a következő okok miatt 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.

Jegyzet

A dokumentáció általában a B-fa kifejezést használja az indexekre hivatkozva. A sorkataszterekben az adatbázismotor egy B+ fát implementál. Ez nem vonatkozik az oszlopcentrikus indexekre vagy a memóriaoptimalizált táblák indexére. További információ: SQL Server és Azure SQL index architektúrája és tervezési útmutatója.

Ezért a PHYSICAL_ONLY beállítás használata sokkal rövidebb futási időt okozhat a DBCC CHECKTABLE nagy táblákon, ezért az éles rendszereken való gyakori használathoz ajánlott. Továbbra is azt javasoljuk, hogy rendszeresen végezze el a DBCC CHECKTABLE teljes körű futtatását. A futtatások gyakorisága az egyes vállalkozásokra és éles környezetekre jellemző tényezőktől függ. PHYSICAL_ONLY mindig NO_INFOMSGS jelent, és egyik javítási lehetőség sem engedélyezett.

Jegyzet

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

DATA_PURITY

Érvénytelen vagy tartományon kívüli oszlopértékeket DBCC CHECKTABLE ellenőrizni a táblában. DBCC CHECKTABLE 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 a DBCC CHECKTABLE WITH DATA_PURITY segítségével megkeresheti és kijavíthatja az adott táblában lévő hibákat; A tábla oszlopérték-ellenőrzései azonban 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 és DBCC CHECKTABLE ellenőrizni az oszlopértékek integritását.

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 DBCC CHECKDB által jelentett adatbáziskonzisztencia-hibák elhárítása című témakörben talál.

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

MAXDOP

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

Felülbírálja a maximális párhuzamossági fokotsp_configure konfigurálási beállítását az utasításhoz. A MAXDOP túllépheti a sp_configurekonfigurált értéket. Ha a MAXDOP meghaladja az Erőforrás-kormányzóval konfigurált értéket, az adatbázismotor az ALTER SZÁMÍTÁSI FELADATCSOPORTban (Transact-SQL) leírt Resource Governor MAXDOP értéket használja. A max. párhuzamossági konfigurációs beállítással használt szemantikai szabályok a MAXDOP lekérdezési tipp használatakor alkalmazhatók. További információ: A kiszolgáló konfigurációs beállításainak maximális fokának konfigurálása.

Jegyzet

Ha a MAXDOP értéke nulla, akkor a kiszolgáló a párhuzamosság maximális fokát választja ki.

Megjegyzések

Jegyzet

Ha DBCC CHECKTABLE szeretne végrehajtani az adatbázis minden tábláján, használja DBCC CHECKDB.

A megadott táblában DBCC CHECKTABLE a következőket ellenőrzi:

• Az index, a sorközi, a LOB és a sor-túlcsordulási adatoldalak megfelelően vannak csatolva.
• Az indexek a megfelelő rendezési sorrendben vannak.
• A mutatók konzisztensek.
• Az egyes oldalakon lévő adatok ésszerűek, beleértve a számított oszlopokat is.
• Az oldaleltolások ésszerűek.
• Az alaptábla minden sorában egyező sor található minden nemclustered indexben, és fordítva.
• A particionált táblák vagy indexek minden sora a megfelelő partíción található.
• Kapcsolatszintű konzisztencia a fájlrendszer és a tábla között varbinary(max) adatok filestream használatával történő tárolásakor.

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 100 (SQL Server 2008 (10.0.x)) vagy magasabb:

  • Ha nincs megadva NOINDEX, DBCC CHECKTABLE 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ának és a hivatkozó felhasználói táblának. 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 nagyon nagy 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 CHECKTABLE konzisztencia-ellenőrzéseket végez annak ellenőrzéséhez, hogy az indexbejegyzések megfelelnek-e a szűrő predikátumának.

• Az SQL Server 2016-tól (13.x) kezdődően a megőrzött számított oszlopok, az UDT-oszlopok és a szűrt indexek további ellenőrzései alapértelmezés szerint nem futnak a költséges 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 CHECKTABLE időtartamát. Az objektumok fizikai konzisztenciájának 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, amellett, hogy a EXTENDED_LOGICAL_CHECKS lehetőség részeként már vannak logikai ellenőrzések (indexelt nézet, XML-indexek és térbeli indexek).

• Ha a kompatibilitási szint 90 (SQL Server 2005 (9.x)) vagy annál kisebb, kivéve, ha NOINDEX van megadva, DBCC CHECKTABLE 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 adatbázis kompatibilitási szintjének megismerése

• Adatbázis- kompatibilitási szintjének megtekintése vagy módosítása

Belső adatbázis-pillanatkép

DBCC CHECKTABLE egy belső adatbázis-pillanatkép használatával biztosítja a tranzakciós konzisztenciát, amelyet ezeknek az ellenőrzéseknek el kell végeznie. További információ: Adatbázis-pillanatkép ritka fájljának (Transact-SQL) méretének és DBCC belső adatbázis-pillanatkép-használati szakaszának megtekintése DBCC (Transact-SQL).

Ha nem hozható létre pillanatkép, vagy TABLOCK van megadva, DBCC CHECKTABLE egy megosztott tábla zárolását szerzi be a szükséges konzisztencia eléréséhez.

Jegyzet

Ha DBCC CHECKTABLEtempdbfut, akkor egy megosztott táblazárolást 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.

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 CHECKTABLE használ egy olyan táblán, 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 CHECKTABLE ellenőrzi, hogy van-e egy-az-egyhez megfeleltetés a fájlrendszerkönyvtárak és fájlok, valamint a táblasorok, oszlopok és oszlopértékek között. DBCC CHECKTABLE 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 azokat a táblázatsorokat, amelyekből hiányoznak a fájlrendszer adatai, és törli azokat a könyvtárakat és fájlokat, amelyek nem képeznek le táblázatsorra, oszlopra vagy oszlopértékre.

Objektumok ellenőrzése párhuzamosan

Alapértelmezés szerint DBCC CHECKTABLE 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 esetén. 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ó: A kiszolgáló konfigurációs beállításainak maximális fokának konfigurálása.

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

Egy DBCC CHECKTABLE művelet során a byte-ordered user-defined type oszlopban tárolt bájtok száma megegyezik a felhasználó által megadott típusérték számított szerializálásával. Ha ez nem igaz, a DBCC CHECKTABLE rutin konzisztenciahibát fog jelenteni.

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 CHECKTABLE 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 sikeres befejezést és a parancs futtatásának időtartamát jelzi. Ha a DBCC-parancs hiba miatt leáll az ellenőrzés befejezése 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 egy metaadat-sérülést jelez, amely miatt a DBCC parancs leállt.
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 egy metaadat-sérülést jelez, amely miatt a DBCC parancs leállt.
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.

Hibajelentés

Az SQL Server SQLDUMP<nnnn>.txt könyvtárában egy miniképfájl (LOG) jön létre, amikor DBCC CHECKTABLE 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 CHECKTABLE parancs eredményeit és a további diagnosztikai kimenetet. A fájl korlátozott diszkrecionális hozzáférés-vezérlési listákat (DACL-eket) biztosít. Az hozzáférés az SQL Server szolgáltatásfiókjára és a sysadmin szerepkör tagjaira korlátozódik. A sysadmin szerepkör alapértelmezés szerint a Windows BUILTIN\Rendszergazdák 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 DBCC CHECKTABLE bármilyen hibát jelez, javasoljuk, hogy az adatbázis biztonsági mentéséből állítsa vissza az adatbázist aHELYETT, hogy a JAVÍTÁS parancsot futtatja a JAVÍTÁS lehetőséggel. Ha nincs biztonsági másolat, a javítás futtatása ki tudja javítani a jelentett hibákat. A használni kívánt JAVÍTÁS beállítás 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 előfordulhat, hogy egyes oldalakat, így az adatokat is törölni kell.

A javítás elvégezhető egy felhasználói tranzakció alatt, hogy a felhasználó visszaállíthassa a végrehajtott módosításokat. Ha a javításokat visszaállítják, az adatbázis továbbra is hibákat fog tartalmazni, és biztonsági másolatból kell visszaállítani. Miután elvégezte az összes javítást, biztonsági másolatot készít az adatbázisról.

Eredményhalmazok

DBCC CHECKTABLE a következő eredményhalmazt adja vissza. Ugyanez az eredményhalmaz akkor lesz visszaadva, ha csak a tábla nevét vagy a beállítások bármelyikét adja meg.

DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKTABLE a következő eredményhalmazt adja vissza, ha a ESTIMATEONLY beállítás meg van adva:

Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
21
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Engedélyek

A felhasználónak rendelkeznie kell a táblával, vagy tagja kell lennie a sysadmin rögzített kiszolgálói szerepkörnek, a db_owner rögzített adatbázis-szerepkörnek vagy a db_ddladmin rögzített adatbázis-szerepkörnek.

Példák

Egy. Adott tábla ellenőrzése

A következő példa ellenőrzi az AdventureWorks2025 adatbázis táblázatának adatbázis adatlapjának integritását HumanResources.Employee .

DBCC CHECKTABLE ('HumanResources.Employee');
GO

B. A táblázat alacsony terhelésű ellenőrzése

Az alábbi példa alacsony overköltség-ellenőrzést végez az Employee AdventureWorks2025 adatbázis táblázatán.

DBCC CHECKTABLE ('HumanResources.Employee') WITH PHYSICAL_ONLY;
GO

C. Adott index ellenőrzése

Az alábbi példa egy adott indexet ellenőriz, amelyet a sys.indexeseléréséhez kapunk.

DECLARE @indid int;
SET @indid = (SELECT index_id
              FROM sys.indexes
              WHERE object_id = OBJECT_ID('Production.Product')
                    AND name = 'AK_Product_Name');
DBCC CHECKTABLE ('Production.Product',@indid);

Lásd még:

• DBCC (Transact-SQL)
• DBCC CHECKDB (Transact-SQL)