DBCC CHECKDB (Transact-SQL) – SQL Server | Microsoft Docs DBCC CHECKDB (Transact-SQL)

• 2017.12.14.
• 22 perc olvasás
• • p
  • M
  • m
  • M
  • P
  • +3

Az alábbiakra vonatkozik: SQL Server (minden támogatott verzió) Azure SQL Database

A megadott adatbázisban lévő összes objektum logikai és fizikai integritásának ellenőrzése a következő műveletek elvégzésével:

• Futtatja a DBCC CHECKALLOC-ot az adatbázisban.
• Futtatja a DBCC CHECKTABLE-t az adatbázis minden tábláján és nézetén.
• Futtatja a DBCC CHECKCATALOG-ot az adatbázisban.
• Hitelesíti az adatbázis minden indexelt nézetének tartalmát.
• Hitelesíti a táblák metaadatai és a fájlrendszer könyvtárai és fájljai közötti kapcsolatszintű konzisztenciát, ha varbinary(max) adatokat tárol a fájlrendszerben FILESTREAM használatával.
• Hitelesíti a Service Broker adatait az adatbázisban.

Ez azt jelenti, hogy a DBCC CHECKALLOC, DBCC CHECKTABLE vagy DBCC CHECKCATALOG parancsokat nem kell a DBCC CHECKDB-től külön futtatni. Az ezen parancsok által végrehajtott ellenőrzésekről részletesebb információt a parancsok leírásában talál.

Transact-SQL szintaxis konvenciók

Szintaxis

DBCC CHECKDB ) ] } ] ] 

Argumentumok

database_name | database_id | 0
Az adatbázis neve vagy azonosítója, amelyre integritásellenőrzéseket kell futtatni. Ha nincs megadva, vagy ha 0 van megadva, akkor az aktuális adatbázist használja a rendszer. Az adatbázisneveknek meg kell felelniük az azonosítókra vonatkozó szabályoknak.

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 teljes végrehajtási időt. A NOINDEX nem érinti a rendszertáblákat, mivel az integritásellenőrzés mindig a rendszertáblák indexein történik.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Meghatározza, hogy a DBCC CHECKDB javítsa a talált hibákat. A REPAIR opciókat csak végső esetben használja. A megadott adatbázisnak egyfelhasználós üzemmódban kell lennie ahhoz, hogy az alábbi javítási opciók valamelyikét használhassa.

REPAIR_ALLOW_DATA_LOSS
Megpróbálja az összes bejelentett hibát javítani. Ezek a javítások némi adatvesztéssel járhatnak.

REPAIR_FAST
Kizárólag a visszafelé kompatibilitás érdekében tartja fenn a szintaxist. Nem hajt végre javítási műveleteket.

REPAIR_REBUILD
Az adatvesztés lehetőségét kizáró javításokat hajt végre. Ide tartozhatnak a gyors javítások, például a hiányzó sorok javítása a nem klaszterezett indexekben, és az időigényesebb javítások, például egy index újjáépítése.
Ez az argumentum nem javítja a FILESTREAM-adatokat érintő hibákat.

ALL_ERRORMSGS
Megjeleníti az összes bejelentett hibát objektumonként. Alapértelmezés szerint minden hibaüzenet megjelenik. Az opció megadása vagy elhagyása nincs hatással. A hibaüzenetek objektumazonosító szerint vannak rendezve, kivéve a tempdb adatbázisból generált üzeneteket.

EXTENDED_LOGICAL_CHECKS
Ha a kompatibilitási szint 100 ( SQL Server 2008) vagy magasabb, logikai konzisztencia-ellenőrzést végez az indexelt nézeten, az XML-indexeken és a térbeli indexeken, ahol vannak.
Bővebb információért lásd az Indexek logikai konzisztencia-ellenőrzésének elvégzése című részt a témakör későbbi Megjegyzések részében.

NO_INFOMSGS
Minden információs üzenet elnyomása.

TABLOCK
A DBCC CHECKDB-t belső adatbázis-pillanatfelvétel használata helyett zárak megszerzésére készteti. 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 álló adatbázisban, de csökkenti az adatbázisban elérhető párhuzamosságot a DBCC CHECKDB futása alatt.

ESTIMATEONLY
Kijelzi a tempdb hely becsült mennyiségét, amely a DBCC CHECKDB futtatásához szükséges az összes többi megadott opcióval. A tényleges adatbázis-ellenőrzés nem történik meg.

PHYSICAL_ONLY
Az ellenőrzést a lap- és rekordfejlécek fizikai szerkezetének sértetlenségére é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 kis felületen történő ellenőrzését biztosítsa, 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.
A DBCC CHECKDB teljes futtatása lényegesen tovább tarthat, mint a korábbi verzióké. Ez a viselkedés azért következik be, mert:

• A logikai ellenőrzések átfogóbbak.
• Az ellenőrizendő mögöttes struktúrák némelyike összetettebb.
• Az új funkciók miatt számos új ellenőrzés került bevezetésre.
  Ezért a PHYSICAL_ONLY opció használata a DBCC CHECKDB sokkal rövidebb futási idejét okozhatja nagy adatbázisok esetén, és gyakori használatra ajánlott a termelő rendszereken. Továbbra is javasoljuk a DBCC CHECKDB teljes futtatásának rendszeres időközönkénti elvégzését. Ezeknek a futtatásoknak a gyakorisága az egyes vállalatokra és termelési környezetekre jellemző tényezőktől függ.
  Ez az érv mindig NO_INFOMSGS-t feltételez, és a javítási opciók egyikével sem megengedett.

DATA_PURITY
A DBCC CHECKDB ellenőrzi az adatbázist a nem érvényes vagy tartományon kívüli oszlopértékek tekintetében. A DBCC CHECKDB például é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ámtani adattípusú oszlopokat, amelyek skála- vagy pontossági értékei nem érvényesek.
Az oszlopértékek integritásának ellenőrzése alapértelmezés szerint engedélyezett, és nem igényli a DATA_PURITY opciót. 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 a DBCC CHECKDB WITH DATA_PURITY nem futott hibátlanul az adatbázisban. Ezt követően a DBCC CHECKDB alapértelmezés szerint ellenőrzi az oszlopértékek sértetlenségét. További információt arról, hogy a CHECKDB-t hogyan befolyásolhatja az adatbázis SQL Server korábbi verzióiról történő frissítése, a témakör későbbi részében található Megjegyzések szakaszban talál.

Az ezzel az opcióval jelentett érvényességi hibák nem javíthatók a DBCC javítási opciókkal. Az ilyen hibák kézi javításával kapcsolatos információkért lásd a 923247 számú tudásbázis cikket: Troubleshooting DBCC error 2570 in SQL Server 2005 and later versions.

MAXDOP
Applies to: SQL Server ( SQL Server 2014 (12.x) SP2 és újabb).

Többszörözi az utasításhoz tartozó sp_configure maximális párhuzamossági fok konfigurációs beállítását. A MAXDOP meghaladhatja az sp_configure segítségével konfigurált értéket. Ha a MAXDOP meghaladja az erőforrás-kormányzóval konfigurált értéket, az SQL Server adatbázis-motor az ALTER WORKLOAD GROUP című fejezetben leírt erőforrás-kormányzói MAXDOP-értéket használja. A MAXDOP lekérdezési súgó használatakor a max degree of parallelism konfigurációs opcióval használt összes szemantikai szabály alkalmazható. További információért lásd: A párhuzamosság maximális fokozata kiszolgálói konfigurációs opció konfigurálása.

Megjegyzések

A DBCC CHECKDB nem vizsgálja a letiltott indexeket. A letiltott indexekről további információt a Letiltott indexek és korlátozások című fejezetben talál.

Ha egy felhasználó által definiált típus bájtrendezettként van megjelölve, akkor a felhasználó által definiált típusnak csak egy szerializációja lehet. A byte-rendezésű felhasználó által definiált típusok nem konzisztens szerializációja a DBCC CHECKDB futtatásakor a 2537-es hibát okozza. További információért lásd: Felhasználó által definiált típusok követelményei.

Mivel az erőforrás-adatbázis csak egyfelhasználós módban módosítható, a DBCC CHECKDB parancs nem futtatható rajta közvetlenül. Amikor azonban a DBCC CHECKDB parancsot a főadatbázis ellenében hajtjuk végre, egy második CHECKDB parancsot is futtatunk belsőleg az erőforrás-adatbázison. Ez azt jelenti, hogy a DBCC CHECKDB extra eredményeket adhat vissza. A parancs extra eredményhalmazokat ad vissza, ha nincsenek beállítások, vagy ha a PHYSICAL_ONLY vagy a ESTIMATEONLY opció van beállítva.

Az SQL Server 2005 (9.x) SP2-től kezdve a DBCC CHECKDB végrehajtása már nem törli az SQL Server példány tervtárát. Az SQL Server 2005 (9.x) SP2 előtt a DBCC CHECKDB végrehajtása törli a terv gyorsítótárat. A terv gyorsítótár törlése az összes későbbi végrehajtási terv újbóli összeállítását okozza, és a lekérdezések teljesítményének hirtelen, átmeneti csökkenését okozhatja.

Logikai konzisztenciaellenőrzés végrehajtása indexeken

Az indexek logikai konzisztenciaellenő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) vagy magasabb:
• Ha nincs megadva NOINDEX, a DBCC CHECKDB fizikai és logikai konzisztenciaellenőrzést is végez egyetlen táblán és annak összes nem csoportosított indexén. Az XML-indexeken, térbeli indexeken és indexelt nézeteken azonban alapértelmezés szerint csak fizikai konzisztencia-ellenőrzéseket végez.
• Ha WITH EXTENDED_LOGICAL_CHECKS van megadva, a logikai ellenőrzéseket az indexelt nézeten, az XML-indexeken és a térbeli indexeken végzi el, ahol vannak. Alapértelmezés szerint a fizikai konzisztencia-ellenőrzések a logikai konzisztencia-ellenőrzések előtt kerülnek végrehajtásra. Ha a NOINDEX is meg van adva, csak a logikai ellenőrzések kerülnek végrehajtásra.

Ezek a logikai konzisztencia-ellenőrzések keresztellenőrzik az indexobjektum belső index-tábláját azzal a felhasználói táblával, amelyre hivatkozik. A kilógó sorok megtalálásához egy belső lekérdezés készül, amely a belső és a felhasználói táblák teljes keresztezését végzi el. Ennek a lekérdezésnek a futtatása nagyon nagy hatással lehet a teljesítményre, és az előrehaladása nem követhető nyomon. Ezért javasoljuk, hogy csak akkor adja meg a WITH EXTENDED_LOGICAL_CHECKS értéket, ha olyan indexproblémákra gyanakszik, amelyeknek nincs köze a fizikai sérüléshez, vagy ha az oldalszintű ellenőrző összegek ki lettek kapcsolva, és oszlopszintű hardveres sérülésre gyanakszik.

• Ha az index egy szűrt index, a DBCC CHECKDB konzisztenciaellenőrzést végez annak ellenőrzésére, hogy az indexbejegyzések megfelelnek-e a szűrő predikátumnak.
• Ha a kompatibilitási szint 90 vagy annál kisebb, kivéve, ha NOINDEX van megadva, a DBCC CHECKDB mind fizikai, mind logikai konzisztenciaellenőrzést végez egyetlen táblán vagy indexelt nézeten és annak összes nem fürtözött és XML indexén. A térbeli indexek nem támogatottak.
• Az SQL Server 2016-tól kezdődően a perzisztens számított oszlopok, az UDT-oszlopok és a szűrt indexek további ellenőrzései alapértelmezés szerint nem futnak le a drága kifejezéskiértékelések elkerülése érdekében. Ez a változás jelentősen csökkenti a CHECKDB időtartamát az ilyen objektumokat tartalmazó adatbázisok ellen. Ezen objektumok fizikai konzisztencia-ellenőrzései azonban mindig befejeződnek. Csak a EXTENDED_LOGICAL_CHECKS opció megadásakor a már meglévő logikai ellenőrzések (indexelt nézet, XML-indexek és térbeli indexek) mellett a EXTENDED_LOGICAL_CHECKS opció részeként a kifejezéskiértékelések is végrehajtásra kerülnek.

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

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

Belső adatbázis-pillanatfelvétel

A DBCC CHECKDB egy belső adatbázis-pillanatfelvételt használ az ezen ellenőrzések elvégzéséhez szükséges tranzakciós konzisztenciához. Ez megakadályozza a blokkolási és párhuzamossági problémákat e parancsok végrehajtásakor. További információért lásd: Az adatbázis-pillanatfelvétel ritkított fájljának méretének megtekintése (Transact-SQL) és a DBCC belső adatbázis-pillanatfelvétel használata című szakasz a DBCC (Transact-SQL) című fejezetben. Ha a pillanatfelvétel nem hozható létre, vagy TABLOCK van megadva, a DBCC CHECKDB zárakat szerez a szükséges konzisztencia elérése érdekében. Ebben az esetben az allokációs ellenőrzések elvégzéséhez kizárólagos adatbázis-zárra, a táblaellenőrzések elvégzéséhez pedig megosztott táblaszárakra van szükség.A DBCC CHECKDB a master ellen futtatva sikertelen, ha belső adatbázis-pillanatfelvétel nem hozható létre.A DBCC CHECKDB futtatása a tempdb ellen nem végez allokációs vagy katalógusellenőrzést, és a táblaellenőrzések elvégzéséhez megosztott táblaszárakat kell szereznie. Ennek az az oka, hogy a tempdb-n a teljesítmény miatt az adatbázis pillanatfelvételek nem állnak rendelkezésre. Ez azt jelenti, hogy a szükséges tranzakciós konzisztencia nem érhető el.A Microsoft SQL Server 2012 vagy az SQL Server egy korábbi verziójában hibaüzenetekkel találkozhat, amikor a DBCC CHECKDB parancsot olyan adatbázisra futtatja, amelynek fájljai ReFS-formátumú köteten találhatók. További információért lásd a 2974455 Tudásbázis cikket: DBCC CHECKDB viselkedése, ha az SQL Server adatbázis ReFS köteten található.

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

Ha a FILESTREAM engedélyezve van egy adatbázis és tábla számára, akkor opcionálisan varbinary(max) bináris nagy objektumokat (BLOB) tárolhat a fájlrendszerben. Amikor a DBCC CHECKDB-t olyan adatbázison használja, amely BLOB-okat tárol a fájlrendszerben, a DBCC ellenőrzi a kapcsolat szintű konzisztenciát a fájlrendszer és az adatbázis között. például, ha egy tábla tartalmaz egy varbinary(max) oszlopot, amely a FILESTREAM attribútumot használja, a DBCC CHECKDB ellenőrzi, hogy van-e egy az egyben megfeleltetés a fájlrendszer könyvtárai és fájljai, valamint a táblázat sorai, oszlopai és oszlopértékei között. A DBCC CHECKDB javíthatja a korrupciót, ha megadjuk a REPAIR_ALLOW_DATA_LOSS opciót. A FILESTREAM korrupció javításához a DBCC törli azokat a táblázatsorokat, amelyekből hiányoznak a fájlrendszer adatai.

Best Practices

A termelésben használt rendszereken gyakori használat esetén a PHYSICAL_ONLY opció használatát javasoljuk. A PHYSICAL_ONLY használata nagy adatbázisok esetén jelentősen lerövidítheti a DBCC CHECKDB futási idejét. Javasoljuk továbbá, hogy rendszeresen futtassa a DBCC CHECKDB-t opciók nélkül. Az, hogy milyen gyakran érdemes ezeket a futtatásokat elvégezni, az egyes vállalkozásoktól és azok termelési környezetétől függ.

Objektek párhuzamos ellenőrzése

A DBCC CHECKDB alapértelmezés szerint párhuzamosan végzi az objektumok ellenőrzését. A párhuzamosság mértékét a lekérdezésfeldolgozó automatikusan meghatározza. A párhuzamosság maximális foka a párhuzamos lekérdezésekhez hasonlóan konfigurálható. A DBCC-ellenőrzéshez rendelkezésre álló processzorok maximális számának korlátozásához használja az sp_configure parancsot. További információért lásd: A párhuzamosság maximális fokának konfigurálása Kiszolgáló konfigurációs opció. A párhuzamos ellenőrzés kikapcsolható a 2528-as trace flag használatával. További információért lásd: Nyomkövetési zászlók (Transact-SQL).

A DBCC hibaüzenetek megértése

A DBCC CHECKDB parancs befejezése után a rendszer üzenetet ír az SQL Server hibanaplójába. Ha a DBCC parancs sikeresen végrehajtódik, az üzenet a sikert és a parancs futásának időtartamát jelzi. Ha a DBCC parancs az ellenőrzés befejezése előtt hiba miatt leáll, az üzenet jelzi a parancs megszakítását, egy állapotértéket és a parancs futásának időtartamát. A következő táblázat felsorolja és leírja az üzenetben feltüntethető állapotértékeket.

State	Description
0	A 8930-as számú hiba keletkezett. Ez a metaadatok sérülését jelzi, amely megszakította a DBCC parancsot.
1	A 8967-es számú hiba jelentkezett. Belső DBCC-hiba történt.
2	Egy hiba történt a vészhelyzeti üzemmódú adatbázis-javítás során.
3	Ez azt jelzi, hogy a metaadatokban olyan sérülés történt, amely megszakította a DBCC parancsot.
4	Egy assert vagy hozzáférés megsértése történt.
5	Egy ismeretlen hiba történt, amely megszakította a DBCC parancsot.

Hibajelentés

Az SQL Server LOG könyvtárában mindig akkor jön létre egy dump fájl (SQLDUMP*nnnn*.txt), amikor a DBCC CHECKDB korrupciós hibát észlel. Ha a Feature Usage adatgyűjtési és hibajelentési funkciók engedélyezve vannak az SQL Server példányban, a fájl automatikusan továbbításra kerül a Microsoftnak. Az összegyűjtött adatokat az SQL Server működésének javítására használják fel. a dump fájl a DBCC CHECKDB parancs eredményeit és további diagnosztikai kimeneteket tartalmaz. A hozzáférés az SQL Server szolgáltatási fió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 minden tagját tartalmazza. A DBCC parancs nem hibásodik meg, ha az adatgyűjtési folyamat sikertelen.

Hibák megoldása

Ha a DBCC CHECKDB hibát jelez, javasoljuk, hogy a REPAIR valamelyik REPAIR opcióval történő futtatása helyett állítsa vissza az adatbázist az adatbázis biztonsági mentéséből. Ha nincs biztonsági mentés, a javítás futtatása kijavítja a jelentett hibákat. A használandó javítási opciót a bejelentett hibák listájának végén kell megadni. A REPAIR_ALLOW_DATA_LOSS opció használatával történő hibajavítás azonban szükségessé teheti néhány oldal, és így néhány adat törlését.

Valamilyen körülmények között előfordulhat, hogy az adatbázisba olyan értékek kerülnek be, amelyek az oszlop adattípusa alapján érvénytelenek vagy tartományon kívüliek. A DBCC CHECKDB képes észlelni az összes oszlop adattípusa esetén érvénytelen oszlopértékeket. Ezért a DBCC CHECKDB DATA_PURITY opcióval történő futtatása az SQL Server korábbi verzióiról frissített adatbázisokon feltárhatja a már meglévő oszlopérték-hibákat. Mivel az SQL Server nem tudja automatikusan javítani ezeket a hibákat, az oszlopértéket kézzel kell frissíteni. Ha a CHECKDB ilyen hibát észlel, a CHECKDB figyelmeztetést, a 2570-es hibaszámot és az érintett sor azonosításához és a hiba kézi javításához szükséges információkat adja vissza.

A javítás egy felhasználói tranzakció keretében is elvégezhető, hogy a felhasználó visszavehesse az elvégzett módosításokat. Ha a javítás visszahívásra kerül, az adatbázis továbbra is tartalmazni fogja a hibákat, és azt biztonsági mentésből kell visszaállítani. A javítás befejezése után készítsen biztonsági másolatot az adatbázisról.

Hibák megoldása adatbázis vészhelyzeti üzemmódban

Ha egy adatbázis az ALTER DATABASE utasítással vészhelyzeti üzemmódba került, a DBCC CHECKDB elvégezhet néhány speciális javítást az adatbázison, ha a REPAIR_ALLOW_DATA_LOSS opciót megadta. Ezek a javítások lehetővé tehetik, hogy a rendszerint helyreállíthatatlan adatbázisok fizikailag konzisztens állapotban kerüljenek újra online állapotba. Ezeket a javításokat csak végső esetben és csak akkor szabad használni, ha az adatbázist nem lehet biztonsági mentésből visszaállítani. Ha az adatbázis vészhelyzeti üzemmódba van állítva, az adatbázis READ_ONLY jelölést kap, a naplózás le van tiltva, és a hozzáférés a sysadmin fix kiszolgálói szerepkör tagjaira korlátozódik.

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

• A DBCC CHECKDB az I/O- vagy ellenőrzőösszeg-hibák miatt elérhetetlennek jelölt oldalakat úgy használja, mintha a hibák nem történtek volna meg. Ezáltal megnő az adatbázisból történő adatvisszaállítás esélye.
• A DBCC CHECKDB megkísérli az adatbázis helyreállítását a szokásos naplóalapú helyreállítási technikákkal.
• Ha a tranzakciós napló sérülése miatt az adatbázis helyreállítása sikertelen, a tranzakciós naplót újraépíti. A tranzakciós napló újraépítése a tranzakciós konzisztencia elvesztéséhez vezethet.

Ha a DBCC CHECKDB parancs sikeres, az adatbázis fizikailag konzisztens állapotban van, és az adatbázis állapota ONLINE-ra áll. Az adatbázis azonban tartalmazhat egy vagy több tranzakciós ellentmondást. Javasoljuk, hogy futtassa a DBCC CHECKCONSTRAINTS parancsot az üzleti logikai hibák azonosítása érdekében, és azonnal készítsen biztonsági másolatot az adatbázisról.

A DBCC CHECKDB parancs futtatása REPAIR_ALLOW_DATA_LOSS opcióval replikált adatbázisokban

A DBCC CHECKDB parancs futtatása a REPAIR_ALLOW_DATA_LOSS opcióval hatással lehet a felhasználói adatbázisokra (publikációs és előfizetési adatbázisok) és a replikáció által használt elosztási adatbázisra. A publikációs és előfizetési adatbázisok tartalmazzák a publikált táblákat és a replikációs metaadat táblákat. Figyeljen az alábbi lehetséges problémákra ezekben az adatbázisokban:

• Publikált táblák. Előfordulhat, hogy a CHECKDB folyamat által a sérült felhasználói adatok javítása érdekében végzett műveletek nem replikálódnak:
• Az összevont replikáció triggereket használ a közzétett táblák változásainak nyomon követésére. Ha a CHECKDB folyamat sorokat illeszt be, frissít vagy töröl, a triggerek nem lépnek működésbe, ezért a változás nem replikálódik.
• A tranzakciós replikáció a tranzakciós naplót használja a közzétett táblák változásainak követésére. A naplóolvasó ügynök ezután ezeket a változásokat áthelyezi az elosztó adatbázisba. Egyes DBCC javításokat, bár naplózva vannak, a Naplóolvasó ügynök nem replikálhatja. Ha például egy adatlapot a CHECKDB folyamat felszabadít, a Naplóolvasó ügynök ezt nem fordítja le DELETE utasítássá, ezért a változás nem replikálódik.
• Replikációs metaadattáblák. A CHECKDB folyamat által a sérült replikációs metaadattáblák javítására végzett műveletek a replikáció eltávolítását és újrakonfigurálását igénylik.

Ha a DBCC CHECKDB parancsot a REPAIR_ALLOW_DATA_LOSS opcióval kell futtatnia egy felhasználói adatbázisban vagy elosztási adatbázisban:

1. Kikapcsolja a rendszert: Állítsa le a tevékenységet az adatbázisban és a replikációs topológia összes többi adatbázisában, majd próbálja meg szinkronizálni az összes csomópontot. További információért lásd: Replikációs topológia csendesítése (Replikációs Transact-SQL programozás).
2. Futtassa a DBCC CHECKDB-t.
3. Ha a DBCC CHECKDB jelentés javításokat tartalmaz az elosztó adatbázis bármely táblájára vagy egy felhasználói adatbázis replikációs metaadat tábláira vonatkozóan, távolítsa el és konfigurálja újra a replikációt. További információért lásd: Kiadás és terjesztés letiltása.
4. Ha a DBCC CHECKDB jelentés javításokat tartalmaz bármely replikált táblára vonatkozóan, végezzen adatellenőrzést annak megállapítására, hogy vannak-e különbségek a kiadási és az előfizetési adatbázisok adatai között.

Eredményhalmazok

A DBCC CHECKDB a következő eredményhalmazt adja vissza. Az értékek változhatnak, kivéve, ha az ESTIMATEONLY, PHYSICAL_ONLY vagy NO_INFOMSGS beállítások vannak megadva:

 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. 

A DBCC CHECKDB a NO_INFOMSGS beállítása esetén a következő eredményhalmazt (üzenetet) adja vissza:

 The command(s) completed successfully.

DBCC CHECKDB a következő eredményhalmazt küldi vissza, ha PHYSICAL_ONLY van megadva:

 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 küldi vissza, ha ESTIMATEONLY van megadva.

 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.

Jogosultságok

Elvárja a sysadmin fix kiszolgálói szerepkörhöz vagy a db_owner fix adatbázis szerepkörhöz való tartozást.

Példák

A. Az aktuális és egy másik adatbázis ellenőrzése

A következő példa a DBCC CHECKDB végrehajtását hajtja végre az aktuális adatbázisra és az AdventureWorks2012 adatbázisra.

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

B. Az aktuális adatbázis ellenőrzése, az információs üzenetek elnyomása

A következő példa az aktuális adatbázis ellenőrzése és az összes információs üzenet elnyomása.

DBCC CHECKDB WITH NO_INFOMSGS; GO 

See also

DBCC (Transact-SQL)
Az adatbázis-pillanatkép ritkított fájljának méretének megtekintése (Transact-SQL)
sp_helpdb (Transact-SQL)
Rendszertáblák (Transact-SQL)

.