DBCC CHECKDB: Ghid complet pentru MS SQL Server Sănătatea bazei de date (2025)

Corupția bazei de date este omniprezentă SQL Server coșmarul administratorului. Când datele critice ale afacerii devin inaccesibile sau nesigure, cost poate fi devastator. Acest ghid cuprinzător acoperă tot ce trebuie să știți despre utilizarea DBCC CHECKDB pentru a menține sănătatea bazei de date și a preveni coruperea, plus soluții avansate de recuperare pentru situațiile în care instrumentele standard nu sunt suficiente.

1. Importanța SQL Server Sănătatea bazei de date

1.1 Ce înseamnă coruperea bazei de date CostAfaceri

Astăzi, m.ost Companiile își stochează datele critice în baze de date. Atunci când are loc coruperea bazelor de date, consecințele sunt catastrofale:

• Pierderi financiare o medie de 2.3 milioane de dolari anual din cauza pierderilor de date, principalele cauze fiind defecțiunile hardware și coruperea (EMC Corporation)
• Ratele de închidere a afacerilor arată că 50% dintre întreprinderile mici care se confruntă cu pierderi de date din cauza defecțiunilor hardware își pierd activitatea în termen de doi ani, în timp ce 94% dintre întreprinderile cu pierderi catastrofale de date nu supraviețuiesc deloc
• Frecvența coruperii datelor afectează anual 20% din aplicațiile critice pentru misiune, provocând întreruperi ale continuității afacerii (cercetări Gartner)
• Corupție legată de hardware reprezintă 67% din toate incidentele de pierdere a datelor cauzate de blocarea hard disk-ului și defecțiunile sistemului, 40% din pierderile de date fiind atribuite direct defecțiunilor hardware.
• Corupția software-ului costs variază de la mii la milioane de dolari, în funcție de gravitate și amploare, 82% dintre companii înregistrând întreruperi neplanificate în care corupția a fost o cauză principală

1.2 De ce sunt esențiale controalele medicale regulate

Oamenii au nevoie de controale medicale regulate pentru a detecta din timp potențialele boli. În mod similar, bazele de date au nevoie și ele de controale medicale regulate:

1. Detectează din timp potențialele cazuri de corupție și gestionează-le prompt, prevenind ca problemele să devină grave și răspândite, ceea ce ar putea duce la consecințe catastrofale pentru afacere.
2. Asigurați-vă că baza de date funcționează la performanțe optime.
3. Cost Rata verificărilor proactive ale stării bazei de date este mult mai mică decât cea a recuperării reactive a datelor după producerea unui dezastru al bazei de date.

1.3 Introducere în comenzile de integritate a bazei de date

SQL Server oferă mai multe comenzi încorporate pentru menținerea sănătății bazei de date, cu DBCC CHECKDB servind ca most Instrument complet de verificare a integrității disponibil. Aceste comenzi funcționează împreună pentru a verifica diferite aspecte ale structurii bazei de date, de la tabele individuale până la consistența întregii baze de date, formând o strategie completă de întreținere care menține datele în siguranță și accesibile.

2. Ce este DBCC CHECKDB

DBCC CHECKDB is SQL ServerInstrumentul principal pentru verificarea integrității bazei de date și identificarea problemelor de corupție.

• Este o instrucțiune T-SQL, nu un instrument GUI.
• Îl poți executa prin metode comune, cum ar fi SQL Server Studio de Management (SSMS), SQL Server Agent, SQLCMD etc.

2.1 Ce verifică de fapt CHECKDB în baza dvs. de date

Când executați DBCC CHECKDB, comanda efectuează mai multe straturi de validare în structura bazei de date:

• Verificarea sumelor de control ale paginilor pentru a detecta corupția fizică și problemele legate de hardware
• Validarea consistenței indexului pentru a asigura recuperarea corectă a datelor și performanța interogărilor
• Verificări ale structurii de alocare pentru a confirma utilizarea corectă a spațiului și alocarea paginilor
• Examinarea integrității referențiale între tabele corelate și relații cu chei externe
• Validarea consistenței tabelului de sistem pentru a asigura SQL ServerMetadatele interne rămân fiabile
• Verificarea legăturii paginii de date pentru a confirma integritatea corectă a lanțului de pagini
• Consistența schemei bazei de date pentru a valida definițiile și dependențele obiectelor

Aceste verificări complete acoperă atât datele utilizatorilor, cât și structurile sistemului, oferind vizibilitate completă asupra stării de sănătate a bazei de date.

3. Rularea DBCC CHECKDB: Pas cu pas

3.1 Condiții prealabile

Mai jos este lista de verificare înainte de a executa orice operațiune DBCC CHECKDB:

• Copie de rezervă completă a bazei de date – Creați o copie de rezervă completă înainte de a executa verificări de integritate, ca plasă de siguranță în cazul în care se descoperă coruperea datelor sau dacă devin necesare operațiuni de reparare.
• Permisiuni corespunzătoare – Aveți nevoie de permisiuni sysadmin sau db_owner pentru a executa comenzi DBCC CHECKDB
• Resurse de sistem suficiente:
  • Memorie: 25% din dimensiunea bazei de date
  • Spațiu Tempdb: 10-15% din dimensiunea bazei de date
  • CPU: disponibilitate 50-70% în timpul mentenanței
  • I/O: Așteptați operațiuni de citire intense
• Accesibilitatea bazelor de date – Verificați dacă baza de date este accesibilă și nu se află într-o stare restricționată, deoarece CHECKDB necesită acces de citire la toate paginile bazei de date

3.2 Comanda de bază

Lorost Comanda DBCC CHECKDB de bază include trei variante comune:

(1) Verificați baza de date curentă (fără parametri):

DBCC CHECKDB

(2) Verificați o bază de date după nume:

DBCC CHECKDB ('YourDatabaseName')

(3) Verificați o bază de date după ID:

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

Această comandă fundamentală efectuează o verificare completă a integrității bazei de date specificate, examinând toate tabelele, indexurile și structurile sistemului. Pentru bazele de date cu nume standard care nu conțin spații, puteți omite ghilimelele. Comanda va rula până la finalizare, afișând mesaje de progres și rezultatele finale. Această sintaxă de bază funcționează perfect pentru bazele de date mai mici sau atunci când aveți suficient timp disponibil pentru mentenanță.

Mai jos este o captură de ecran a rulării DBCC CHECKDB în SQL Server Management Studio (SSMS):

3.3 Opțiuni complete

Mai jos sunt opțiunile complete pentru DBCC CHECKDB:

Categorii	Opțiune	Descriere	Exemplu DBCC CHECKDB
Opțiuni de reparare	REPAIR_REBUILD	Reparații fără pierderi de date (de exemplu, reconstrucții de index)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Fără reparații. Doar compatibilitate retroactivă.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Repară toate erorile (poate cauza pierderea datelor)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Controlul domeniului	NOINDEX	Omite verificările indexului neclusterizat	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Verifică doar integritatea spațiului de stocare fizic (pagini/înregistrări)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Verifică erorile logice ale valorilor coloanelor (de exemplu, date nevalide)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Verificări logice aprofundate (vizualizări indexate, indexuri XML/spațiale)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Control ieșire	ALL_ERRORMSGS	Afișează toate erorile (implicit: 200 per obiect)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Ascunde mesajele informative	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Performanţă	TABLOCK	Folosește blocări de tabel (reduce utilizarea TempDB, dar blochează scrierile)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Suprascrie setările de paralelism	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Utilitate	ESTIMATEONLY	Estimează spațiul TempDB necesar. (fără verificare propriu-zisă)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Înțelegerea rezultatelor

DBCC CHECKDB va produce rezultate diferite în funcție de finalizarea cu succes a execuției sale. Să le explicăm în detaliu.

4.1 Execuția CHECKDB s-a finalizat cu succes

Dacă execuția DBCC CHECKDB se finalizează cu succes, va raporta diferite tipuri de rezultate în funcție de starea bazei de date.

4.1.1 Nu s-au găsit probleme

Dacă DBCC CHECKDB nu găsește nicio problemă, veți vedea o ieșire similară cu:

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

Acest rezultat indică faptul că baza de date menține o integritate perfectă în toate structurile verificate.

4.1.2 Erori de corupție găsite

Ori de câte ori DBCC CHECKDB detectează o eroare de corupție, va raporta un mesaj de eroare cu următoarea structură:
Ghid pentru nivelul de severitate:

• Nivelul 16-19: Erori corectabile de utilizator, adesea corupții minore
• Nivelul 20-24: Erori de sistem, corupție gravă care necesită atenție imediată
• Nivel 25: Erori fatale, baza de date poate fi inaccesibilă

Erorile comune includ:

• Erori ale sumei de control a paginii (mesajul 824)
• Erori de alocare (mesajul 8928)
• Probleme de consistență a indexului (mesajul 8964)

Înțelegerea structurii mesajului ajută la prioritizarea acțiunilor de răspuns și la determinarea strategiilor de recuperare adecvate.

4.1.3 Mesaje informative și de avertizare comune

Nu toate ieșirile DBCC CHECKDB indică probleme grave. De asemenea, poate afișa mesaje informative și de avertizare, inclusiv:

• Declarații de reparații – Mesaje care sugerează comenzi de reparare pentru remedierea problemelor minore
• Avertismente privind alocările – Avertismente privind alocarea spațiului care nu afectează accesul la date
• Recomandări de performanță – Sugestii pentru întreținerea și optimizarea indexului
• Anunțuri informative – Mesaje generale de stare care nu necesită acțiune imediată

Aceste mesaje oferă îndrumări valoroase pentru întreținere, distingând în același timp între corupțiile critice care necesită acțiuni imediate și problemele minore care pot fi rezolvate în timpul intervalelor de întreținere regulate.

Exemplu de mesaj de avertizare:

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 Execuția CHECKDB se întrerupe

Dacă CHECKDB se întrerupe în timpul execuției din diverse motive, va raporta un mesaj de eroare și va adăuga un jurnal de erori cu codul de stare de mai jos:

Stat	Descriere
0	A fost generată eroarea numărul 8930. Aceasta indică o corupere a metadatelor care a terminat comanda DBCC.
1	A fost generată eroarea numărul 8967. A apărut o eroare DBCC internă.
2	A apărut o eroare în timpul reparării bazei de date în modul de urgență.
3	Aceasta indică o corupere a metadatelor care a terminat comanda DBCC.
4	A fost detectată o încălcare a aserțiunii sau a accesului.
5	A apărut o eroare necunoscută care a terminat comanda DBCC.

Exemplu de mesaj de eroare:

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'.

Exemplu de jurnal de erori:

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.

Într-un astfel de caz, puteți încerca opțiuni avansate alternative, cum ar fi DataNumen SQL Recovery pentru a remedia corupția din baza de date.

5. Corectarea erorilor de corupție

5.1 Copiere de rezervă și restaurare: Cea mai sigură soluție

Când DBCC CHECKDB identifică erori de corupție, restaurarea dintr-o copie de rezervă curată reprezintă cea mai sigură și eficientă metodă.ost soluție fiabilă. Această abordare garantează integritatea datelor, eliminând în același timp cauzele subiacente ale corupției. Înainte de restaurare, verificați integritatea copiei de rezervă folosind RESTAURAȚI NUMAI PRIN VERIFICARE comenzi și luați în considerare opțiunile de recuperare la un moment dat pentru a minimiza pierderile de date. Documentați detaliile coruperii pentru analiza cauzelor principale, deoarece problemele hardware sau erorile software pot necesita atenție suplimentară pentru a preveni recurența.

5.2 Soluții pentru coruperea la nivel de pagină

Pentru coruperea izolată a paginilor care afectează porțiuni mici de date, SQL Server Ediția Enterprise oferă capabilități de restaurare a paginilor care repară pagini specifice deteriorate fără restaurarea completă a bazei de date. Această tehnică avansată necesită un model de recuperare completă și copii de rezervă ale jurnalelor actuale.

Procesul de restaurare a paginii pas cu pas:

1. Identificați pagina coruptă din mesajul de eroare CHECKDB (de exemplu, pagina 1:256)
2. Faceți o copie de rezervă a jurnalului curent pentru a captura tranzacțiile recente:

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

3. Restaurați pagina coruptă de la most copie de rezervă completă recentă:

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

4. Aplicați backup diferențial (daca este disponibil):

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

5. Aplicați toate copiile de rezervă ale jurnalelor în secvență, inclusiv cea tocmai creată:

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. Faceți o copie de rezervă finală a jurnalului și restaurați-l pentru a aduce pagina la zi:

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

Alternativă pentru datele necritice: Dacă datele necritice sunt afectate de corupție, puteți exporta rândurile neafectate în tabele noi înainte de a reconstrui structurile corupte:

-- 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 Remedieri rapide pentru coruperea indexului

Coruperea indexului răspunde adesea bine la operațiunile de reconstrucție care recreează structurile indexului fără a afecta datele tabelului subiacent:

ALTER INDEX ALL ON YourTable REBUILD

Această abordare funcționează deosebit de bine pentru coruperea indexurilor care nu sunt grupate în clustere, deoarece reconstrucția regenerează paginile de index din datele tabelului sursă, eliminând efectiv coruperea, păstrând în același timp toate informațiile originale.

6. Folosește REPAIR_REBUILD și REPAIR_ALLOW_DATA_LOSS

Dacă toate metodele anterioare eșuează sau nu sunt fezabile, puteți utiliza opțiunile REPAIR_REBUILD și REPAIR_ALLOW_DATA_LOSS pentru a repara baza de date.

6.1 REPAIR_REBUILD (Opțiune mai sigură):

• Utilizați pentru: Corupția indexului și erori minore de alocare
• Siguranța datelor: Încercă remedierea corupției fără ștergerea datelor
• Nivel de risc: Scăzut – nu se așteaptă nicio pierdere de date
• Scenarii tipice: Corupție a indexului fără grup, probleme minore de metadate
• Exemplu de comandă: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Ultima soluție):

• Utilizați pentru: Corupție severă atunci când copiile de rezervă nu sunt disponibile
• Siguranța datelor: Poate șterge datele corupte pentru a restaura funcționalitatea bazei de date
• Nivel de risc: Ridicat – posibilă pierdere permanentă de date
• Scenarii tipice: Coruperea paginii, deteriorarea tabelului de sistem, erorile lanțului de alocare
• Exemplu de comandă: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Cele mai bune practici pentru aceste opțiuni:

• Încearcă întotdeauna operațiuni de reparare a copiilor bazei de date atunci când este posibil
• Faceți întotdeauna o copie de rezervă înainte de a rula aceste opțiuni
• Documentați toate modificările în scopuri de conformitate și depanare
• Setează baza de date la modul utilizator unic înainte de a efectua operațiuni de reparații

În mod normal, ar trebui să încercăm REPARARE_RECONSTRUCȚIE prima opțiune. Dacă eșuează, încercați REPAIR_ALLOW_DATA_LOSS opțiune.

6.4 Rezultate REPAIR_ALLOW_DATA_LOSS

6.4.1 Repararea are succes în cazul pierderii de date

Uneori REPAIR_ALLOW_DATA_LOSS Opțiunea va avea succes, dar unele date sunt pierdute.ost după reparație.

Mai jos sunt câteva exemple de mesaje:

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.

Acest lucru se datorează faptului că DBCC CHECKDB corectează baza de date prin abandonarea unor înregistrări deteriorate, dar, de fapt, most dintre ele pot fi încă recuperate prin DataNumen SQL Recovery.

Fișiere exemplu:

SQL Server versiune	Fișier MDF corupt	Fișier MDF reparat de DataNumen SQL Recovery
SQL Server 2014	Error10_1.mdf (Mesajul 8909 urmat de Mesajul 8939) (600 de înregistrări)ost cu REPAIR_ALLOW_DATA_LOSS)	Error10_1_fixed.mdf (Fără înregistrare lost)
SQL Server 2014	Error10_2.mdf (Mesajul 8909 urmat de Mesajul 8939) (6000 de înregistrări (50%))ost cu REPAIR_ALLOW_DATA_LOSS)	Error10_2_fixed.mdf (Doar 100 de înregistrări)ost)
SQL Server 2014	Error7MDF (100 de înregistrări lost cu REPAIR_ALLOW_DATA_LOSS)	Error7_fixed.mdf (Doar o înregistrare lost)

6.4.2 Reparațiile eșuează – Luați în considerare o soluție profesională

If REPAIR_ALLOW_DATA_LOSS eșuează, va afișa unul sau mai multe mesaje de eroare.

Mai jos sunt câteva exemple:

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.

În aceste situații, trebuie să utilizați o soluție profesională, cum ar fi DataNumen SQL Recovery pentru a vă repara baza de date.

Fișiere exemplu

SQL Server versiune	Fișier MDF corupt	Fișier MDF reparat de DataNumen SQL Recovery
SQL Server 2014	Error1_3.mdf (Mesaj unic 824)	Error1_3_fixed.mdf
SQL Server 2014	Error1_1.mdf (Erori continue Msg 824)	Eroare1_1_fixed.mdf
SQL Server 2014	Error1_2.mdf ((Mesajul 824 urmat de Mesajul 7909)	Error1_2_fixed.mdf
SQL Server 2014	Error4_1.mdf (Mesajul 8992 urmat de mesajul 3852)	Error4_1_fixed.mdf
SQL Server 2014	Error4_2.mdf (Mesajul 8992 urmat de mesajul 3852)	Error4_2_fixed.mdf
SQL Server 2014	Error5.mdf (Mesaj 8945)	Error5_fixed.mdf
SQL Server 2014	Error6.mdf (Mesaj 2510)	Error6_fixed.mdf
SQL Server 2014	Error2.mdf (Mesaj 2575)	Error2_fixed.mdf
SQL Server 2014	Error11.mdf (Mesaj 8905)	Error11_fixed.mdf
SQL Server 2014	Error3.mdf (Mesaj 5028)	Error3_fixed.mdf
SQL Server 2014	Error8MDF (Mesaj 5125)	Error8_fixed.mdf
SQL Server 2014	Error9.mdf (Mesaj 3313)	Error9_fixed.mdf

7. Cele mai bune practici

7.1 Planificarea operațiunilor CHECKDB regulate

Implementați execuția săptămânală DBCC CHECKDB pentru bazele de date critice de producție, cu verificări zilnice pentru sistemele cu tranzacții numeroase. Programați operațiunile în perioadele de utilizare redusă pentru a minimiza impactul asupra performanței și luați în considerare rotirea între verificări complete și opțiunile PHYSICAL_ONLY în funcție de dimensiunea bazei de date și de ferestrele de întreținere. Programare automată prin SQL Server Agentul asigură o execuție consistentă, oferind în același timp capacități centralizate de monitorizare și alertare.

7.2 Managementul impactului asupra performanței

Operațiunile DBCC CHECKDB consumă resurse semnificative de sistem, afectând potențial activitatea concurentă a utilizatorilor. Monitorizați utilizarea CPU, consumul de memorie și I/O-urile pe disc în timpul verificărilor pentru a înțelege modelele de impact asupra performanței. Luați în considerare utilizarea opțiunilor NOINDEX pentru verificările de rutină, rezervând validarea completă pentru ferestrele de întreținere lunară. Implementați extensii de timeout pentru interogări și strategii de comunicare cu utilizatorii pentru a gestiona așteptările în perioadele de verificare a integrității.

7.3 Planificarea ferestrei de întreținere

Coordonați programarea DBCC CHECKDB cu alte activități de mentenanță, cum ar fi operațiunile de backup, reconstrucția indexului și actualizările statisticilor. Evitați suprapunerea operațiunilor care consumă multe resurse și care ar putea cauza degradarea performanței sau probleme de timeout. Planificați ferestrele de mentenanță pe baza proiecțiilor de creștere a dimensiunii bazei de date, asigurând timp adecvat pentru verificarea completă a integrității pe măsură ce volumele de date cresc.

7.4 Monitorizare și alertare automată

Configurați SQL Server Agentul emite alerte pentru a notifica imediat administratorii atunci când DBCC CHECKDB identifică corupții. Implementați soluții de analiză a jurnalelor care extrag și clasifică rezultatele verificărilor de integritate, permițând analiza tendințelor și identificarea proactivă a problemelor. Creați proceduri de escaladare care definesc intervalele de timp de răspuns și personalul responsabil pentru diferite niveluri de severitate a corupției.

8. TABEL DE VERIFICARE DBCC: Alternativa ușoară

8.1 Când se utilizează CHECKTABLE în loc de CHECKDB

DBCC CHECKTABLE oferă verificarea integrității concentrată pentru tabele individuale, fiind ideal pentru tarDepanarea și întreținerea anumitor obiecte ale bazei de date a fost optimizată. Utilizați CHECKTABLE atunci când investigați probleme de performanță cu anumite tabele, validați tabele critice între verificări complete ale bazei de date sau când constrângerile de timp împiedică validarea completă a bazei de date. Această abordare se dovedește a fi deosebit de valoroasă în bazele de date mari, unde operațiunile complete CHECKDB depășesc ferestrele de întreținere disponibile.

8.2 Sintaxa și exemplele DBCC CHECKTABLE

Comanda de bază CHECKTABLE tarobține tabele specifice:

DBCC CHECKTABLE('YourTable')

La fel ca CHECKDB, CHECKTABLE acceptă diverse opțiuni, inclusiv NOINDEX pentru optimizarea performanței și parametri de reparare pentru rezolvarea corupției. De asemenea, puteți specifica nume de scheme pentru identificarea precisă a tabelelor:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Acest tarAbordarea geted permite verificarea granulară a integrității, menținând în același timp performanța sistemului în timpul orelor de program.

8.3 Beneficii de performanță pentru bazele de date mari

Operațiunile CHECKTABLE se finalizează semnificativ mai rapid decât verificările complete ale bazei de date, permițând o verificare mai frecventă a integrității tabelelor critice. Această abordare permite validarea zilnică a tabelelor de business esențiale, rezervând în același timp operațiuni CHECKDB complete pentru programări săptămânale sau lunare. Consumul redus de resurse face ca CHECKTABLE să fie potrivit pentru execuția în mediul de producție, cu un impact minim asupra utilizatorului.

9. Când CHECKDB eșuează

DBCC CHECKDB va eșua în diverse scenarii, inclusiv:

• Execuția DBCC CHECKDB se termină anormal
• Execuția DBCC CHECKDB se finalizează cu succes, dar opțiuni de reparație eșuează în repararea bazei de date.

În aceste scenarii, avem nevoie de un instrument mai profesional care să ne ajute să remediem erorile din baza de date.

9.1 Introducere în DataNumen SQL Recovery

DataNumen SQL Recovery oferă capabilități mai avansate:

• Cea mai bună rată de recuperare în industrie.
• Recuperează fișierele bazei de date grav corupte.
• Recuperează toate obiectele bazei de date, inclusiv tabele, indexuri, vizualizări, declanșatoare, reguli și valori implicite.
• Recuperați procedurile stocate, funcțiile scalare, funcțiile inline cu valori de tabel și funcțiile cu valori multiple de tabel.
• Recuperează înregistrările șterse definitiv.
• Decriptați obiectele criptate în SQL Server baze de date.
• Reparați fișierele MDF în lot.
• Opțiuni de reparații complete.
• Înregistrare avansată și raportare.
• Sprijin pentru toți SQL Server versiuni.
• Disponibilitatea suportului tehnic
• Actualizări și îmbunătățiri regulate

9.2 Comparație a ratei de succes

Ratele de succes ale recuperării diferă semnificativ:

• DBCC CHECKDB și CHECKTABLE: 1.27% rata medie de recuperare
• DataNumen: 92.6% Rata de recuperare

Mai jos este o comparație competitivă completă:

9.3 Recuperarea după corupție severă

Capabilitati avansate pentru cazuri severe:

• Recuperare din depozitare deteriorată fizic
• Recuperare de pe unități formatate sau sisteme prăbușite
• Recuperați de pe imagini de pe disc, fișiere de rezervă, fișiere de pe disc ale mașinii virtuale, temporary fișiere etc.

9.4 Când să luați în considerare soluții profesionale

• Nu există disponibilitate recentă de backup
• DBCC CHECKDB eșuează
• Scenarii de corupție severă
• Gestionarea datelor critice ale afacerii
• Când timpul este critic
• Când recuperarea maximă este esențială

10. Întrebări frecvente

11. Concluzie

11.1 Rezumatul punctelor cheie

11.1.1 Recapitulare a comenzilor esențiale DBCC CHECKDB

Stăpânește sintaxa de bază DBCC CHECKDB pentru verificarea completă a bazelor de date, utilizează opțiunile NOINDEX și PHYSICAL_ONLY pentru optimizarea performanței și înțelege CHECKTABLE pentru tarVerificarea tabelului obținut. Aceste comenzi fundamentale formează baza întreținerii proactive a bazelor de date, permițând detectarea timpurie a corupției și monitorizarea sistematică a integrității.

11.1.2 Memento privind cele mai bune practici critice

Mențineți întotdeauna copii de rezervă actualizate înainte de a executa verificări de integritate, programați operațiuni regulate CHECKDB în funcție de importanța bazei de date și implementați monitorizare automată pentru alerte imediate de corupție. Rețineți că prevenirea prin monitorizare regulată depășește abordările reactive, iar soluțiile profesionale de recuperare oferă opțiuni valoroase de backup atunci când instrumentele standard se dovedesc insuficiente.

11.2 Când se utilizează DBCC CHECKDB vs. soluții avansate

Utilizați DBCC CHECKDB pentru monitorizarea de rutină a integrității și rezolvarea corupțiilor minore, rezervând în același timp instrumente profesionale de recuperare pentru scenarii de corupție severă care depășesc capacitățile de reparare încorporate. Cadrul decizional ar trebui să ia în considerare disponibilitatea copiilor de rezervă, caracterul critic al datelor, constrângerile de timp și severitatea corupției. Administratorii de baze de date de succes combină monitorizarea regulată CHECKDB cu strategii complete de backup și conștientizarea opțiunilor avansate de recuperare atunci când abordările standard se dovedesc inadecvate.

12. referinte

1. Microsoft Learn. „DBCC CHECKDB (Transact-SQL)”. SQL Server DocumentațieCorporația Microsoft.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. „Depanarea erorilor de consistență a bazei de date raportate de DBCC CHECKDB.” SQL Server DocumentațieCorporația Microsoft.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors