DBCC CHECKDB: Teljes körű útmutató az MS-hez SQL Server Adatbázis állapota (2026)

A DBCC CHECKDB a következő: SQL Serverfő adatbázis-integritási eszköze. Tanulja meg példákkal, hogyan kell használni, hogyan javíthatja ki a sérüléseket és hogyan optimalizálhatja a teljesítményt.

3. A DBCC CHECKDB futtatása: lépésről lépésre

3.1 Előfeltételek

Az alábbiakban a DBCC CHECKDB műveletek végrehajtása előtt teendő ellenőrzőlista látható:

• Teljes adatbázis-mentés – Az integritási ellenőrzések futtatása előtt készítsen teljes biztonsági mentést biztonsági hálóként arra az esetre, ha sérülést fedeznének fel, vagy javítási műveletek válnának szükségessé.
• Megfelelő jogosultságok – A DBCC CHECKDB parancsok végrehajtásához sysadmin vagy db_owner jogosultságokra van szükség.
• Elegendő rendszererőforrás:
  • Memória: az adatbázis méretének 25%-a
  • Tempdb tárhely: az adatbázis méretének 10-15%-a
  • CPU: 50-70%-os rendelkezésre állás karbantartás alatt
  • I/O: Nagy mennyiségű olvasási műveletre számíthat
• Adatbázis-hozzáférés – Ellenőrizze, hogy az adatbázis elérhető-e, és nincs-e korlátozott állapotban, mivel a CHECKDB olvasási hozzáférést igényel az összes adatbázisoldalhoz.

3.2 Alapvető parancs

A most Az alapvető DBCC CHECKDB parancs három gyakori változatát tartalmazza:

(1) Ellenőrizze az aktuális adatbázist (paraméterek nélkül):

DBCC CHECKDB

(2) Adatbázis keresése név alapján:

DBCC CHECKDB ('YourDatabaseName')

(3) Adatbázis keresése azonosító alapján:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

Ez az alapvető parancs a megadott adatbázis teljes integritási ellenőrzését végzi, megvizsgálva az összes táblát, indexet és rendszerstruktúrát. A szóközöket nem tartalmazó szabványos nevű adatbázisok esetén elhagyhatja az idézőjeleket. A parancs a befejezésig fut, megjelenítve a folyamatjelző üzeneteket és a végeredményeket. Ez az alapvető szintaxis tökéletesen működik kisebb adatbázisok esetén, vagy ha elegendő karbantartási idő áll rendelkezésre.

Az alábbi képernyőkép a DBCC CHECKDB futtatását mutatja be a következőben: SQL Server Menedzsment Stúdió (SSMS):

3.3 Teljes opciók

Az alábbiakban a DBCC CHECKDB összes opcióját láthatjuk:

Kategória	opció	Leírás	DBCC CHECKDB példa
Javítási lehetőségek	REPAIR_REBUILD	Adatvesztés nélküli javítások (pl. index-újraépítés)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Nincs javítás. Csak visszafelé kompatibilis.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Kijavítja az összes hibát (ami adatvesztést okozhat)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Hatáskör ellenőrzése	NOINDEX	Kihagyja a nem klaszterezett indexellenőrzéseket	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Csak a fizikai tároló integritását ellenőrzi (oldalak/rekordok)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Logikai oszlopérték-hibák ellenőrzése (pl. érvénytelen dátumok)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Mély logikai ellenőrzések (indexelt nézetek, XML/térbeli indexek)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Kimenet vezérlés	ALL_ERRORMSGS	Az összes hibát megjeleníti (alapértelmezett: 200 objektumonként)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Elrejti az információs üzeneteket	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Teljesítmény	TABLOCK	Táblazárakat használ (csökkenti a TempDB használatát, de blokkolja az írásokat)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Felülírja a párhuzamossági beállításokat	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Hasznosság	ESTIMATEONLY	Becsüli a TempDB szükséges helyét. (nincs tényleges ellenőrzés)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Az eredmények megértése

A DBCC CHECKDB függvény eltérő eredményeket fog produkálni attól függően, hogy a végrehajtása sikeresen befejeződött-e vagy sem. Nézzük meg részletesen ezeket.

4.1 A CHECKDB végrehajtása sikeresen befejeződött

Ha a DBCC CHECKDB végrehajtása sikeresen befejeződik, az adatbázis állapotától függően különböző típusú eredményeket fog jelenteni.

4.1.1 Nem található probléma

Ha a DBCC CHECKDB nem talál problémákat, akkor a következőhöz hasonló kimenetet fog látni:

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Ez az eredmény azt jelzi, hogy az adatbázis tökéletes integritást tart fenn az összes ellenőrzött struktúrában.

4.1.2 Talált sérülési hibák

Amikor a DBCC CHECKDB sérülési hibát észlel, a következő felépítésű hibaüzenetet küld:
Súlyossági szint útmutató:

• 16-19 szint: Felhasználó által javítható hibák, gyakran kisebb sérülések
• 20-24 szint: Rendszerhibák, azonnali beavatkozást igénylő súlyos korrupció
• 25. szint: Végzetes hibák, az adatbázis elérhetetlen lehet

A gyakori hibák a következők:

• Oldal ellenőrzőösszeg hibák (824-es üzenet)
• Kiosztási hibák (8928-as üzenet)
• Indexkonzisztencia-problémák (8964-es üzenet)

Az üzenetstruktúra megértése segít a válaszlépések rangsorolásában és a megfelelő helyreállítási stratégiák meghatározásában.

4.1.3 Gyakori információs és figyelmeztető üzenetek

Nem minden DBCC CHECKDB kimenet jelez komoly problémákat. Előfordulhat, hogy tájékoztató és figyelmeztető üzeneteket is kiad, beleértve a következőket:

• Javítási nyilatkozatok – Üzenetek, amelyek kisebb problémák megoldására javasolnak javítási parancsokat
• Elosztási figyelmeztetések – Figyelmeztetések a tárhelyelosztással kapcsolatban, amelyek nem befolyásolják az adathozzáférést
• Teljesítményjavaslatok – Javaslatok az index karbantartására és optimalizálására
• Tájékoztató közlemények – Általános állapotüzenetek, amelyek nem igényelnek azonnali beavatkozást

Ezek az üzenetek értékes karbantartási útmutatást nyújtanak, miközben különbséget tesznek az azonnali beavatkozást igénylő kritikus sérülések és a kisebb problémák között, amelyeket a szokásos karbantartási időszakokban lehet kezelni.

Példa figyelmeztető üzenetre:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 CHECKDB végrehajtás megszakítása

Ha a CHECKDB végrehajtása különféle okok miatt megszakad, hibaüzenetet küld, és egy hibanaplót készít az alábbi állapotkóddal:

Állami	Leírás
0	8930-as számú hiba történt. Ez a metaadatok sérülését jelzi, amely leállította a DBCC parancsot.
1	8967-es hiba történt. Belső DBCC hiba történt.
2	Hiba történt a vészhelyzeti módú adatbázis-javítás során.
3	Ez a metaadatok sérülését jelzi, amely leállította a DBCC parancsot.
4	Assert vagy hozzáférés-megsértést észleltünk.
5	Ismeretlen hiba történt, amely leállította a DBCC parancsot.

Példa hibaüzenet:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

or

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

Példa hibanaplóra:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

Ilyen esetben kipróbálhat alternatív, speciális opciókat, például DataNumen SQL Recovery hogy kijavítsa az adatbázisban lévő sérülést.

5. Korrupciós hibák javítása

5.1 Biztonsági mentés és visszaállítás: A legbiztonságosabb megoldás

Amikor a DBCC CHECKDB sérülési hibákat azonosít, a tiszta biztonsági mentésből való visszaállítás jelenti a legbiztonságosabb és leghatékonyabb módszert.ost megbízható megoldás. Ez a megközelítés garantálja az adatok integritását, miközben kiküszöböli a mögöttes sérülési okokat. Visszaállítás előtt ellenőrizze a biztonsági mentés integritását a következővel: CSAK ELLENŐRZÉSSEL VISSZAÁLLÍTÁS parancsokat, és vegye figyelembe az adott időpontban elérhető helyreállítási lehetőségeket az adatvesztés minimalizálása érdekében. Dokumentálja a sérülés részleteit a kiváltó ok elemzése érdekében, mivel a hardverproblémák vagy szoftverhibák további figyelmet igényelhetnek az ismétlődés megelőzése érdekében.

5.2 Oldalszintű sérülési megoldások

Kis adatrészeket érintő elszigetelt oldalsérülések esetén SQL Server Az Enterprise Edition olyan oldal-helyreállítási funkciókat kínál, amelyekkel a teljes adatbázis-visszaállítás nélkül javíthatók bizonyos sérült oldalak. Ez a fejlett technika teljes helyreállítási modellt és aktuális naplómentéseket igényel.

Lépésről lépésre az oldal visszaállításának folyamata:

1. A sérült oldal azonosítása a CHECKDB hibaüzenetből (pl. 1:256. oldal)
2. Készítsen biztonsági másolatot az aktuális naplóról a legutóbbi tranzakciók rögzítéséhez:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. A sérült oldal visszaállítása az m-tőlost legutóbbi teljes biztonsági mentés:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. Differenciális biztonsági mentés alkalmazása (ha van):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. Az összes naplómentés alkalmazása sorban, beleértve az imént létrehozottat is:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. Készítsen egy utolsó naplómentést és állítsa vissza az oldal aktuálissá tételéhez:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Alternatív megoldás nem kritikus adatokhoz: Ha a sérülés nem kritikus adatokat érint, akkor érdemes lehet az érintetlen sorokat új táblákba exportálni a sérült struktúrák újjáépítése előtt:

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 Indextörés gyors megoldásai

Az indexsérülés gyakran jól reagál azokra az újraépítési műveletekre, amelyek az indexstruktúrákat újraalkotják anélkül, hogy befolyásolnák az alapul szolgáló táblaadatokat:

ALTER INDEX ALL ON YourTable REBUILD

Ez a megközelítés különösen jól működik nem klaszterezett indexsérülés esetén, mivel az újjáépítés során az indexlapok a forrástábla adataiból regenerálódnak, hatékonyan kiküszöbölve a sérülést, miközben megőrzi az összes eredeti információt.

6. Használja a REPAIR_REBUILD és a REPAIR_ALLOW_DATA_LOSS függvényeket.

Ha az előző módszerek mindegyike kudarcot vallott vagy nem megvalósítható, akkor a REPAIR_REBUILD és a REPAIR_ALLOW_DATA_LOSS beállításokkal javíthatja az adatbázist.

6.1 JAVÍTÁS_ÚJRAÉPÍTÉS (Biztonságosabb opció):

• Használ: Indexhiba és kisebb elosztási hibák
• Adatbiztonság: Adattörlés nélküli korrupciójavítási kísérleteket tesz
• Kockázati szint: Alacsony – nem várható adatvesztés
• Tipikus forgatókönyvek: Nem fürtözött index sérülése, kisebb metaadat-problémák
• Parancs példa: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Utolsó megoldás):

• Használ: Súlyos adatvesztés, ha a biztonsági mentések nem érhetők el
• Adatbiztonság: A sérült adatokat törölheti az adatbázis funkcionalitásának visszaállítása érdekében
• Kockázati szint: Magas – maradandó adatvesztés lehetséges
• Tipikus forgatókönyvek: Oldal sérülése, rendszertábla sérülése, allokációs lánc hibák
• Parancs példa: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Bevált gyakorlatok ezekhez a lehetőségekhez:

• Mindig teszteljen adatbázis-másolatok javítási műveletei, amikor lehetséges
• Mindig készítsen biztonsági másolatot mielőtt futtatná ezeket a beállításokat
• Dokumentálja az összes változtatást megfelelőségi és hibaelhárítási célokból
• Adatbázis beállítása egyfelhasználós módba javítási műveletek megkezdése előtt

Normális esetben meg kellene próbálnunk JAVÍTÁS_ÚJJÁÉPÍTÉS opciót. Ha nem sikerül, akkor próbálja meg REPAIR_ALLOW_DATA_LOSS opciót.

6.4 REPAIR_ALLOW_DATA_LOSS eredmények

6.4.1 A javítás sikeres adatvesztéssel

Néha a REPAIR_ALLOW_DATA_LOSS opció sikeres lesz, de néhány adat hiányzikost a javítás után.

Az alábbiakban néhány mintaüzenetet láthat:

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

Ez azért van, mert a DBCC CHECKDB néhány sérült rekord elhagyásával kijavítja az adatbázist, de valójában most közülük még mindig visszaszerezhetők a DataNumen SQL Recovery.

Minta fájlok:

SQL Server változat	Sérült MDF fájl	MDF fájl javítva DataNumen SQL Recovery
SQL Server 2014	Error10_1.mdf (8909. üzenet, majd 8939. üzenet) (600 rekord lost (REPAIR_ALLOW_DATA_LOSS hiba esetén)	Error10_1_fixed.mdf (Nincs rekord lost)
SQL Server 2014	Error10_2.mdf (8909-es üzenet, majd 8939-es üzenet) (6000 rekord (50%) lost (REPAIR_ALLOW_DATA_LOSS hiba esetén)	Error10_2_fixed.mdf (Csak 100 rekord lost)
SQL Server 2014	Error7.mdf (100 rekord lost (REPAIR_ALLOW_DATA_LOSS hiba esetén)	Error7_fixed.mdf (Csak egy rekord lost)

6.4.2 Javítási hibák – Fontolja meg a professzionális megoldást

If REPAIR_ALLOW_DATA_LOSS sikertelen, egy vagy több hibaüzenetet fog kiadni.

Az alábbiakban néhány példa látható:

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

Ilyen esetekben professzionális megoldást kell igénybe venni, például DataNumen SQL Recovery hogy kijavítsd az adatbázisodat.

Mintafájlok

SQL Server változat	Sérült MDF fájl	MDF fájl javítva DataNumen SQL Recovery
SQL Server 2014	Error1_3.mdf (824. számú üzenet)	Error1_3_fixed.mdf
SQL Server 2014	Error1_1.mdf (Folyamatos üzenet 824 hibák)	Hiba 1_1_fixed.mdf
SQL Server 2014	Error1_2.mdf ((824. üzenet, majd 7909. üzenet)	Error1_2_fixed.mdf
SQL Server 2014	Error4_1.mdf (8992. üzenet, majd 3852. üzenet)	Error4_1_fixed.mdf
SQL Server 2014	Error4_2.mdf (8992. üzenet, majd 3852. üzenet)	Error4_2_fixed.mdf
SQL Server 2014	Error5.mdf (8945. üzenet)	Error5_fixed.mdf
SQL Server 2014	Error6.mdf (2510. üzenet)	Error6_fixed.mdf
SQL Server 2014	Error2.mdf (2575. üzenet)	Error2_fixed.mdf
SQL Server 2014	Error11.mdf (8905. üzenet)	Error11_fixed.mdf
SQL Server 2014	Error3.mdf (5028. üzenet)	Error3_fixed.mdf
SQL Server 2014	Error8.mdf (5125. üzenet)	Error8_fixed.mdf
SQL Server 2014	Error9.mdf (3313. üzenet)	Error9_fixed.mdf

7. A legjobb gyakorlatok

7.1 Rendszeres CHECKDB műveletek ütemezése

Kritikus éles adatbázisok heti DBCC CHECKDB végrehajtásának bevezetése, valamint napi ellenőrzések a nagy tranzakciószámú rendszerek esetében. A műveletek ütemezése alacsony kihasználtságú időszakokra a teljesítményre gyakorolt ​​hatás minimalizálása érdekében, és a teljes ellenőrzések és a PHYSICAL_ONLY opciók közötti váltakozás az adatbázis mérete és a karbantartási időszakok alapján. Automatizált ütemezés a következőkön keresztül: SQL Server Az ügynök biztosítja a konzisztens végrehajtást, miközben központosított felügyeleti és riasztási képességeket biztosít.

7.2 Teljesítményhatás-menedzsment

A DBCC CHECKDB műveletek jelentős rendszererőforrásokat fogyasztanak, ami potenciálisan befolyásolhatja az egyidejű felhasználói tevékenységeket. Az ellenőrzések során figyelje a CPU-kihasználtságot, a memória-fogyasztást és a lemez I/O-t a teljesítményre gyakorolt ​​hatások mintázatainak megértése érdekében. Fontolja meg a NOINDEX beállítások használatát a rutinellenőrzésekhez, a teljes érvényesítést a havi karbantartási időszakokra fenntartva. Implementáljon lekérdezési időtúllépési kiterjesztéseket és felhasználói kommunikációs stratégiákat az integritásellenőrzési időszakok alatti elvárások kezelésére.

7.3 Karbantartási időszak tervezése

Koordinálja a DBCC CHECKDB ütemezését más karbantartási tevékenységekkel, például a biztonsági mentési műveletekkel, az indexek újraépítésével és a statisztikák frissítésével. Kerülje az átfedésben lévő erőforrás-igényes műveleteket, amelyek teljesítményromlást vagy időtúllépési problémákat okozhatnak. Tervezzen karbantartási időszakokat az adatbázis méretének növekedési előrejelzései alapján, biztosítva a megfelelő időt a teljes integritás-ellenőrzéshez az adatmennyiség növekedésével.

7.4 Automatizált monitorozás és riasztás

konfigurálása SQL Server Ügynökriasztásokat küld az adminisztrátoroknak, ha a DBCC CHECKDB sérülést észlel. Naplóelemző megoldások bevezetése, amelyek kinyerik és kategorizálják az integritás-ellenőrzési eredményeket, lehetővé téve a trendelemzést és a proaktív problémaazonosítást. Eszkalációs eljárások létrehozása, amelyek meghatározzák a válaszidőket és a felelősöket a különböző súlyossági szintek esetén.

8. DBCC CHECKTABLE: A könnyűsúlyú alternatíva

8.1 Mikor használjuk a CHECKTABLE-t a CHECKDB helyett?

A DBCC CHECKTABLE célzott integritásellenőrzést biztosít az egyes táblákhoz, így ideális a következőkhöz: tarAdott adatbázis-objektumok hibaelhárításának és karbantartásának gettesítése. Használja a CHECKTABLE-t adott táblák teljesítményproblémáinak vizsgálatakor, kritikus üzleti táblák validálásakor a teljes adatbázis-ellenőrzések között, vagy ha az időbeli korlátok megakadályozzák a teljes adatbázis-validálást. Ez a megközelítés különösen értékesnek bizonyul nagyméretű adatbázisokban, ahol a teljes CHECKDB műveletek meghaladják a rendelkezésre álló karbantartási ablakokat.

8.2 DBCC CHECKTABLE szintaxis és példák

Az alapvető CHECKTABLE parancs tarkonkrét táblázatokat kap:

DBCC CHECKTABLE('YourTable')

A CHECKDB-hez hasonlóan a CHECKTABLE is számos opciót támogat, beleértve a NOINDEX-et a teljesítményoptimalizáláshoz és a javítási paramétereket a sérülések felderítéséhez. A pontos táblaazonosítás érdekében sémaneveket is megadhat:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Ez a tarA geted megközelítés lehetővé teszi a részletes integritás-ellenőrzést, miközben fenntartja a rendszer teljesítményét munkaidőben.

8.3 Teljesítménybeli előnyök nagy adatbázisok esetén

A CHECKTABLE műveletek lényegesen gyorsabban végrehajtódnak, mint a teljes adatbázis-ellenőrzések, lehetővé téve a kritikus táblák gyakoribb integritás-ellenőrzését. Ez a megközelítés lehetővé teszi a létfontosságú üzleti táblák napi érvényesítését, miközben az átfogó CHECKDB műveleteket heti vagy havi ütemezésre tartja fenn. A csökkentett erőforrás-fogyasztás alkalmassá teszi a CHECKTABLE-t éles környezetben történő végrehajtásra, minimális felhasználói hatással.

9. Amikor a CHECKDB meghibásodik

A DBCC CHECKDB különböző esetekben hibát jelezhet, beleértve a következőket:

• DBCC CHECKDB végrehajtás rendellenesen megszakad
• A DBCC CHECKDB végrehajtása sikeresen befejeződött, de a javítási lehetőségek nem sikerül javítani az adatbázist.

Ilyen esetekben professzionálisabb eszközre van szükségünk, amely segít kijavítani az adatbázisban található hibákat.

9.1 Bevezetés a DataNumen SQL Recovery

DataNumen SQL Recovery fejlettebb képességeket kínál:

• Legjobb helyreállítási arány az iparban.
• Súlyosan sérült adatbázisfájlok helyreállítása.
• Az összes adatbázis-objektum helyreállítása, beleértve a táblákat, indexeket, nézeteket, triggereket, szabályokat és alapértelmezett értékeket.
• Helyreállíthatja a tárolt eljárásokat, skaláris függvényeket, soron belüli táblázatértékű függvényeket és többutasításos táblaértékű függvényeket.
• Véglegesen törölt rekordok helyreállítása.
• Titkosított objektumok visszafejtése SQL Server adatbázisok.
• MDF fájlok javítása kötegelt formában.
• Átfogó javítási lehetőségek.
• Speciális naplózás és jelentéskészítés.
• Támogatás mindenkinek SQL Server változatok.
• Műszaki támogatás elérhetősége
• Rendszeres frissítések és fejlesztések

9.2 Sikerráta összehasonlítása

A helyreállítás sikerességi aránya jelentősen eltér:

• DBCC CHECKDB és CHECKTABLE: 1.27% átlagos helyreállítási arány
• DataNumen: 92.6% felépülési arány

Az alábbiakban egy teljes versenyösszehasonlítás látható:

9.3 Súlyos korrupcióból való kilábalás

Speciális lehetőségek súlyos esetekre:

• Helyreállítás fizikailag sérült tárolóból
• Helyreállítás formázott meghajtókról vagy összeomlott rendszerekről
• Helyreállítás lemezképekből, biztonsági mentési fájlokból, virtuális gép lemezfájljaiból, tempóbólrary fájlok stb.

9.4 Mikor érdemes professzionális megoldásokat fontolóra venni

• Nincs elérhető friss biztonsági mentés
• A DBCC CHECKDB hibát jelez
• Súlyos korrupciós forgatókönyvek
• Kritikus üzleti adatok kezelése
• Amikor az idő kritikus
• Amikor a maximális gyógyulás elengedhetetlen

10. GYIK

11. Következtetés

11.1 A kulcsfontosságú pontok összefoglalása

11.1.1 A DBCC CHECKDB alapvető parancsainak összefoglalása

Sajátítsa el a DBCC CHECKDB alapvető szintaxisát az átfogó adatbázis-ellenőrzéshez, használja a NOINDEX és a PHYSICAL_ONLY opciókat a teljesítményoptimalizáláshoz, és értse meg a CHECKTABLE működését. targeted tábla ellenőrzés. Ezek az alapvető parancsok alkotják a proaktív adatbázis-karbantartás alapját, lehetővé téve a korai sérülésészlelést és a szisztematikus integritás-ellenőrzést.

11.1.2 Emlékeztető a kritikus fontosságú bevált gyakorlatokra

Mindig készítsen aktuális biztonsági mentéseket az integritási ellenőrzések futtatása előtt, ütemezzen rendszeres CHECKDB műveleteket az adatbázis kritikussága alapján, és valósítson meg automatikus monitorozást az azonnali sérülésriasztások érdekében. Ne feledje, hogy a rendszeres monitorozáson keresztüli megelőzés felülmúlja a reaktív megközelítéseket, és a professzionális helyreállítási megoldások értékes biztonsági mentési lehetőségeket kínálnak, ha a standard eszközök elégtelennek bizonyulnak.

11.2 Mikor használjunk DBCC CHECKDB-t, illetve mikor haladó megoldásokat?

Használja a DBCC CHECKDB-t a rutin integritás-monitorozáshoz és a kisebb sérülések elhárításához, miközben a professzionális helyreállítási eszközöket a beépített javítási képességeken túlmutató súlyos sérülési forgatókönyvekre tartja fenn. A döntési keretrendszernek figyelembe kell vennie a biztonsági mentések elérhetőségét, az adatok kritikusságát, az időkorlátokat és a sérülés súlyosságát. A sikeres adatbázis-adminisztrátorok a rendszeres CHECKDB-monitorozást átfogó biztonsági mentési stratégiákkal és a fejlett helyreállítási lehetőségek ismeretével ötvözik, ha a standard megközelítések nem bizonyulnak megfelelőnek.

11.3 Gyors napi állapotellenőrző lista adatbázis-adminisztrátoroknak

A DBCC CHECKDB futtatásán túl az adatbázis optimális állapotát a következő alapvető napi gyakorlatokkal tarthatja fenn:

1. Ellenőrizze a biztonsági mentés integritását

• Az ütemezett biztonsági mentések sikeres végrehajtásának megerősítése
• A biztonsági mentés olvashatóságának ellenőrzéséhez használja a RESTORE VERIFYONLY parancsot.
• Gondoskodjon arról, hogy a külső helyszínen lévő másolatok szinkronizálva legyenek és elérhetőek legyenek

További információkat is kaphat átfogó útmutatónk a SQL Server mentés.

2. A konzisztencia állapotának áttekintése

• Automatizált DBCC CHECKDB eredmények ellenőrzése éjszakai futtatásokból
• monitor SQL Server hibanaplók a sérülési figyelmeztetésekhez
• Azonnal vizsgálja ki az esetleges integritási hibákat

3. Figyelje a kiszolgáló állapotát

• CPU, memória és lemez I/O metrikák ellenőrzése
• Tempdb tárhely elérhetőségének ellenőrzése
• Blokkolt folyamatok és hosszan futó lekérdezések azonosítása

4. Holtpont-tevékenység nyomon követése

• A rendszerállapot-események holtpont-grafikonjainak áttekintése
• Problémás lekérdezések azonosítása és optimalizálása a fejlesztőcsapatokkal
• A holtpontok áldozatainak számának és üzleti hatásának figyelése

Fontos emlékeztetők

• Kerülje az adatbázis gyakori zsugorítását – növeli a fragmentációt és rontja a teljesítményt. Csak jelentős adattörlések után zsugorítson, ha az valóban szükséges.
• Automatizálja a monitorozási feladatokat segítségével SQL Server Ügynöki feladatok vagy karbantartási tervek riasztásokkal a kritikus problémákról.
• Katasztrófa utáni helyreállítási eljárások tesztelése hetente, hogy biztosítsa a biztonsági mentések helyreállíthatóságát és a helyreállítási célok elérhetőségét.

A napi ellenőrzőlista és a rendszeres DBCC CHECKDB műveletek kombinálásával átfogó védelmet hozhat létre adatbázis-környezete számára a proaktív monitorozás és a gyors problémamegoldás révén.

12. Referenciák

1. Microsoft Learn. „DBCC CHECKDB (Transact-SQL).” SQL Server DokumentációMicrosoft Corporation.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. „A DBCC CHECKDB által jelentett adatbázis-konzisztenciahibák elhárítása.” SQL Server DokumentációMicrosoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors