DBCC CHECKDB: Guida completa a MS SQL Server Salute del database (2025)

La corruzione del database è ogni SQL Server l'incubo dell'amministratore. Quando i dati aziendali critici diventano inaccessibili o inaffidabili, il cost può essere devastante. Questa guida completa copre tutto ciò che devi sapere sull'utilizzo di DBCC CHECKDB per mantenere il database in salute e prevenirne la corruzione, oltre a soluzioni di ripristino avanzate per quando gli strumenti standard non sono sufficienti.

1. Importanza di SQL Server Salute del database

1.1 Cos'è la corruzione del database Costs Aziende

Oggi, most Le aziende archiviano i loro dati critici nei database. Quando si verifica un danneggiamento del database, le conseguenze sono catastrofiche:

• Perdite finanziarie una media di 2.3 milioni di dollari all'anno a causa della perdita di dati, con guasti hardware e danneggiamenti come cause principali (EMC Corporation)
• Tassi di chiusura delle attività commerciali dimostrano che il 50% delle piccole imprese che subiscono perdite di dati a causa di guasti hardware falliscono entro due anni, mentre il 94% delle imprese con perdite di dati catastrofiche non sopravvive affatto
• Frequenza di corruzione dei dati colpisce annualmente il 20% delle applicazioni mission-critical, causando interruzioni della continuità aziendale (ricerca Gartner)
• Corruzione correlata all'hardware rappresenta il 67% di tutti gli incidenti di perdita di dati dovuti a crash del disco rigido e guasti del sistema, con il 40% della perdita di dati attribuita direttamente a malfunzionamenti hardware
• Corruzione del software costs variano da migliaia a milioni di dollari a seconda della gravità e della portata, con l'82% delle aziende che hanno subito interruzioni non pianificate in cui la corruzione è stata una delle cause principali

1.2 Perché i controlli sanitari regolari sono fondamentali

Le persone hanno bisogno di controlli sanitari regolari per individuare precocemente potenziali malattie. Allo stesso modo, anche i database necessitano di controlli sanitari regolari:

1. Individuare tempestivamente potenziali casi di corruzione e gestirli tempestivamente, impedendo che i problemi diventino gravi e diffusi, il che potrebbe avere conseguenze catastrofiche per l'azienda.
2. Garantire che il database funzioni a prestazioni ottimali.
3. Ilost dei controlli proattivi sullo stato del database è molto inferiore a quello del ripristino reattivo dei dati dopo il verificarsi di un disastro del database.

1.3 Introduzione ai comandi di integrità del database

SQL Server fornisce diversi comandi integrati per mantenere la salute del database, con DBCC CHECKDB fungendo da most Strumento completo di controllo dell'integrità disponibile. Questi comandi lavorano insieme per verificare diversi aspetti della struttura del database, dalle singole tabelle alla coerenza dell'intero database, formando una strategia di manutenzione completa che mantiene i dati sicuri e accessibili.

2. Che cosa è DBCC CHECKDB

DBCC CHECKDB is SQL ServerStrumento principale per verificare l'integrità del database e identificare problemi di corruzione.

• Si tratta di un'istruzione T-SQL, non di uno strumento GUI.
• Puoi eseguirlo tramite metodi comuni, come SQL Server Studio di gestione (SSMS), SQL Server Agente, SQLCMD, ecc.

2.1 Cosa controlla effettivamente CHECKDB nel tuo database

Quando si esegue DBCC CHECKDB, il comando esegue più livelli di convalida nella struttura del database:

• Verifica dei checksum delle pagine per rilevare danneggiamenti fisici e problemi relativi all'hardware
• Validazione della coerenza dell'indice per garantire il corretto recupero dei dati e le prestazioni delle query
• Controlli della struttura di allocazione per confermare l'utilizzo accurato dello spazio e l'allocazione delle pagine
• Esame di integrità referenziale tra tabelle correlate e relazioni di chiave esterna
• Convalida della coerenza della tabella di sistema per garantire SQL ServerI metadati interni di rimangono affidabili
• Verifica del collegamento della pagina dati per confermare la corretta integrità della catena di pagine
• Coerenza dello schema del database per convalidare le definizioni e le dipendenze degli oggetti

Questi controlli completi riguardano sia i dati utente sia le strutture di sistema, offrendo una visibilità completa sullo stato di integrità del database.

3. Esecuzione di DBCC CHECKDB: procedura dettagliata

3.1 Prerequisiti

Di seguito è riportata la checklist da eseguire prima di eseguire qualsiasi operazione DBCC CHECKDB:

• Backup completo del database – Creare un backup completo prima di eseguire controlli di integrità come rete di sicurezza nel caso in cui venga scoperto un danneggiamento o siano necessarie operazioni di riparazione.
• Permessi adeguati – Sono necessarie le autorizzazioni sysadmin o db_owner per eseguire i comandi DBCC CHECKDB
• Risorse di sistema sufficienti:
  • Memoria: 25% della dimensione del database
  • Spazio Tempdb: 10-15% della dimensione del database
  • CPU: disponibilità del 50-70% durante la manutenzione
  • I/O: prevedere operazioni di lettura pesanti
• Accessibilità al database – Verificare che il database sia accessibile e non in uno stato limitato, poiché CHECKDB richiede l’accesso in lettura a tutte le pagine del database

3.2 Comando di base

Il most il comando base DBCC CHECKDB include tre varianti comuni:

(1) Controlla il database corrente (nessun parametro):

DBCC CHECKDB

(2) Controllare un database per nome:

DBCC CHECKDB ('YourDatabaseName')

(3) Controlla un database tramite ID:

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

Questo comando fondamentale esegue un controllo completo dell'integrità del database specificato, esaminando tutte le tabelle, gli indici e le strutture di sistema. Per i database con nomi standard senza spazi, è possibile omettere le virgolette. Il comando verrà eseguito fino al completamento, visualizzando messaggi di avanzamento e risultati finali. Questa sintassi di base è perfetta per database di piccole dimensioni o quando si ha a disposizione ampio tempo per la manutenzione.

Di seguito è riportato uno screenshot dell'esecuzione di DBCC CHECKDB in SQL Server Studio di gestione (SSMS):

3.3 Opzioni complete

Di seguito sono riportate le opzioni complete per DBCC CHECKDB:

Categoria	Opzione	Descrizione	Esempio DBCC CHECKDB
Opzioni di riparazione	REPAIR_REBUILD	Riparazioni senza perdita di dati (ad esempio, ricostruzioni di indici)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Nessuna riparazione. Solo retrocompatibilità.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Ripara tutti gli errori (potrebbe causare la perdita di dati)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Controllo dell'ambito	NOINDEX	Salta i controlli degli indici non cluster	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Controlla solo l'integrità fisica dell'archiviazione (pagine/record)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Controlla gli errori logici nei valori delle colonne (ad esempio, date non valide)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Controlli logici approfonditi (viste indicizzate, indici XML/spaziali)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Controllo delle uscite	ALL_ERRORMSGS	Mostra tutti gli errori (predefinito: 200 per oggetto)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Nasconde i messaggi informativi	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Cookie di prestazione	TABLOCK	Utilizza blocchi di tabella (riduce l'utilizzo di TempDB ma blocca le scritture)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Sostituisce le impostazioni di parallelismo	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Utilità	ESTIMATEONLY	Stima dello spazio necessario su TempDB. (nessun controllo effettivo)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Comprendere i risultati

DBCC CHECKDB produrrà risultati diversi a seconda che la sua esecuzione venga completata correttamente o meno. Li spieghiamo in dettaglio.

4.1 L'esecuzione di CHECKDB si completa con successo

Se l'esecuzione di DBCC CHECKDB viene completata correttamente, verranno segnalati diversi tipi di risultati a seconda dello stato di integrità del database.

4.1.1 Nessun problema riscontrato

Se DBCC CHECKDB non rileva alcun problema, verrà visualizzato un output simile al seguente:

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

Questo risultato indica che il database mantiene la perfetta integrità in tutte le strutture controllate.

4.1.2 Errori di corruzione rilevati

Ogni volta che DBCC CHECKDB rileva un errore di danneggiamento, segnalerà un messaggio di errore con la seguente struttura:
Guida al livello di gravità:

• Livello 16-19: Errori correggibili dall'utente, spesso corruzione minore
• Livello 20-24: Errori di sistema, corruzione grave che richiede attenzione immediata
• Livello 25: Errori fatali, il database potrebbe essere inaccessibile

Gli errori comuni includono:

• Errori di checksum della pagina (messaggio 824)
• Errori di allocazione (messaggio 8928)
• Problemi di coerenza dell'indice (messaggio 8964)

Comprendere la struttura del messaggio aiuta a stabilire le priorità delle azioni di risposta e a determinare le strategie di ripristino appropriate.

4.1.3 Messaggi informativi e di avvertimento comuni

Non tutti gli output di DBCC CHECKDB indicano problemi gravi. Potrebbe anche generare alcuni messaggi informativi e di avviso, tra cui:

• Dichiarazioni di riparazione – Messaggi che suggeriscono comandi di riparazione per risolvere problemi minori
• Avvisi di allocazione – Avvisi sull’allocazione dello spazio che non influiscono sull’accesso ai dati
• Raccomandazioni sulle prestazioni – Suggerimenti per la manutenzione e l’ottimizzazione dell’indice
• Avvisi informativi – Messaggi di stato generali che non richiedono un'azione immediata

Questi messaggi forniscono preziose indicazioni sulla manutenzione, distinguendo tra danneggiamenti critici che richiedono un intervento immediato e problemi minori che possono essere risolti durante le normali finestre di manutenzione.

Esempio di messaggio di avviso:

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 Interruzioni dell'esecuzione di CHECKDB

Se CHECKDB si interrompe durante l'esecuzione per vari motivi, segnalerà un messaggio di errore e aggiungerà un registro degli errori con il codice di stato seguente:

Regione / Stato	Descrizione
0	È stato generato l'errore numero 8930. Questo indica un danneggiamento dei metadati che ha interrotto il comando DBCC.
1	È stato generato l'errore numero 8967. Si è verificato un errore DBCC interno.
2	Si è verificato un errore durante la riparazione del database in modalità di emergenza.
3	Ciò indica un danneggiamento dei metadati che ha interrotto il comando DBCC.
4	È stata rilevata una violazione di asserzione o di accesso.
5	Si è verificato un errore sconosciuto che ha interrotto il comando DBCC.

Esempio di messaggio di errore:

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.

oppure

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

Esempio di registro degli errori:

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.

In tal caso, puoi provare opzioni avanzate alternative come DataNumen SQL Recovery per correggere il danneggiamento del database.

5. Correzione degli errori di corruzione

5.1 Backup e ripristino: la soluzione più sicura

Quando DBCC CHECKDB identifica errori di corruzione, il ripristino da un backup pulito rappresenta il metodo più sicuro e most soluzione affidabile. Questo approccio garantisce l'integrità dei dati eliminando al contempo le cause di corruzione sottostanti. Prima di ripristinare, verificare l'integrità del backup utilizzando RIPRISTINO SOLO VERIFICA Comandi e considerare opzioni di ripristino point-in-time per ridurre al minimo la perdita di dati. Documentare i dettagli del danneggiamento per l'analisi della causa principale, poiché problemi hardware o bug software potrebbero richiedere maggiore attenzione per evitarne il ripetersi.

5.2 Soluzioni per la corruzione a livello di pagina

Per la corruzione di pagine isolate che interessano piccole porzioni di dati, SQL Server L'Enterprise Edition offre funzionalità di ripristino delle pagine che riparano specifiche pagine danneggiate senza dover ripristinare l'intero database. Questa tecnica avanzata richiede un modello di ripristino completo e backup dei log aggiornati.

Procedura passo passo per il ripristino della pagina:

1. Identificare la pagina danneggiata dal messaggio di errore CHECKDB (ad esempio, pagina 1:256)
2. Eseguire un backup del registro corrente per acquisire le transazioni recenti:

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

3. Ripristina la pagina danneggiata dal most backup completo recente:

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

4. Applica backup differenziale (se disponibile):

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

5. Applica tutti i backup del registro in sequenza, compreso quello appena creato:

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. Eseguire un backup del registro finale e ripristinare per portare la pagina corrente:

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

Alternativa per dati non critici: Se il danneggiamento interessa dati non critici, è possibile esportare le righe non interessate in nuove tabelle prima di ricostruire le strutture danneggiate:

-- 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 Soluzioni rapide per la corruzione dell'indice

Il danneggiamento dell'indice spesso risponde bene alle operazioni di ricostruzione che ricreano le strutture dell'indice senza influire sui dati della tabella sottostante:

ALTER INDEX ALL ON YourTable REBUILD

Questo approccio funziona particolarmente bene in caso di danneggiamento di indici non cluster, poiché la ricostruzione rigenera le pagine di indice dai dati della tabella di origine, eliminando di fatto il danneggiamento e preservando tutte le informazioni originali.

6. Utilizzare REPAIR_REBUILD e REPAIR_ALLOW_DATA_LOSS

Se tutti i metodi precedenti falliscono o non sono fattibili, è possibile utilizzare le opzioni REPAIR_REBUILD e REPAIR_ALLOW_DATA_LOSS per riparare il database.

6.1 REPAIR_REBUILD (opzione più sicura):

• Utilizzare per: Corruzione dell'indice ed errori di allocazione minori
• Sicurezza dei dati: Tenta di correggere la corruzione senza eliminare i dati
• Livello di rischio: Basso – nessuna perdita di dati prevista
• Scenari tipici: Corruzione dell'indice non cluster, problemi minori di metadati
• Esempio di comando: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Ultima risorsa):

• Utilizzare per: Grave danneggiamento quando i backup non sono disponibili
• Sicurezza dei dati: Può eliminare i dati danneggiati per ripristinare la funzionalità del database
• Livello di rischio: Alto – possibile perdita permanente dei dati
• Scenari tipici: Corruzione della pagina, danni alla tabella di sistema, errori della catena di allocazione
• Esempio di comando: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Buone pratiche per queste opzioni:

• Test sempre operazioni di riparazione sulle copie del database quando possibile
• Eseguire sempre il backup prima di eseguire queste opzioni
• Documentare tutte le modifiche per scopi di conformità e risoluzione dei problemi
• Imposta il database in modalità utente singolo prima di eseguire operazioni di riparazione

Normalmente dovremmo provare RIPARAZIONE_RICOSTRUISCI prima l'opzione. Se fallisce, allora prova REPAIR_ALLOW_DATA_LOSS opzione.

6.4 Risultati REPAIR_ALLOW_DATA_LOSS

6.4.1 La riparazione riesce con la perdita di dati

A volte il REPAIR_ALLOW_DATA_LOSS l'opzione avrà successo, ma alcuni dati sono lost dopo la riparazione.

Di seguito alcuni messaggi di esempio:

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.

Ciò accade perché DBCC CHECKDB corregge il database abbandonando alcuni record danneggiati, ma in realtà, most di essi possono ancora essere recuperati tramite DataNumen SQL Recovery.

File di esempio:

SQL Server versione	File MDF corrotto	File MDF riparato da DataNumen SQL Recovery
SQL Server 2014	Errore10_1.mdf (Msg 8909 seguito da Msg 8939) (600 record lost con REPAIR_ALLOW_DATA_LOSS)	Errore10_1_fixed.mdf (Nessuna registrazione lost)
SQL Server 2014	Errore10_2.mdf (Msg 8909 seguito da Msg 8939) (6000 record (50%) lost con REPAIR_ALLOW_DATA_LOSS)	Errore10_2_fixed.mdf (Solo 100 record lost)
SQL Server 2014	Error7mdf (100 record lost con REPAIR_ALLOW_DATA_LOSS)	Errore7_risolto.mdf (Solo un record lost)

6.4.2 Riparazione fallita: considerare una soluzione professionale

If REPAIR_ALLOW_DATA_LOSS fallisce, verranno visualizzati uno o più messaggi di errore.

Di seguito sono riportati alcuni esempi:

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.

In questi scenari, è necessario utilizzare una soluzione professionale come DataNumen SQL Recovery per riparare il tuo database.

File di esempio

SQL Server versione	File MDF corrotto	File MDF riparato da DataNumen SQL Recovery
SQL Server 2014	Errore1_3.mdf (Messaggio singolo 824)	Errore1_3_fixed.mdf
SQL Server 2014	Errore1_1.mdf (Errori continui del messaggio 824)	Errore1_1_fixed.mdf
SQL Server 2014	Errore1_2.mdf ((Msg 824 seguito da Msg 7909)	Errore1_2_fixed.mdf
SQL Server 2014	Errore4_1.mdf (Msg 8992 seguito da Msg 3852)	Errore4_1_fixed.mdf
SQL Server 2014	Errore4_2.mdf (Msg 8992 seguito da Msg 3852)	Errore4_2_fixed.mdf
SQL Server 2014	Errore5.mdf (Messaggio 8945)	Errore5_risolto.mdf
SQL Server 2014	Errore6.mdf (Messaggio 2510)	Errore6_risolto.mdf
SQL Server 2014	Errore2.mdf (Messaggio 2575)	Errore2_risolto.mdf
SQL Server 2014	Errore11.mdf (Messaggio 8905)	Errore11_risolto.mdf
SQL Server 2014	Errore3.mdf (Messaggio 5028)	Errore3_risolto.mdf
SQL Server 2014	Error8mdf (Messaggio 5125)	Error8_fixed.mdf
SQL Server 2014	Errore9.mdf (Messaggio 3313)	Errore9_risolto.mdf

7. Migliori Pratiche

7.1 Pianificazione di operazioni CHECKDB regolari

Implementare l'esecuzione settimanale di DBCC CHECKDB per i database di produzione critici, con controlli giornalieri per i sistemi ad alto numero di transazioni. Pianificare le operazioni durante i periodi di basso utilizzo per ridurre al minimo l'impatto sulle prestazioni e valutare la rotazione tra controlli completi e opzioni PHYSICAL_ONLY in base alle dimensioni del database e alle finestre di manutenzione. Pianificazione automatizzata tramite SQL Server L'agente garantisce un'esecuzione coerente, offrendo al contempo funzionalità centralizzate di monitoraggio e avviso.

7.2 Gestione dell'impatto sulle prestazioni

Le operazioni DBCC CHECKDB consumano notevoli risorse di sistema, con un potenziale impatto sull'attività simultanea degli utenti. Monitorare l'utilizzo della CPU, il consumo di memoria e l'I/O del disco durante i controlli per comprendere i modelli di impatto sulle prestazioni. Valutare l'utilizzo delle opzioni NOINDEX per i controlli di routine, riservando la convalida completa alle finestre di manutenzione mensili. Implementare estensioni del timeout delle query e strategie di comunicazione con gli utenti per gestire le aspettative durante i periodi di controllo dell'integrità.

7.3 Pianificazione della finestra di manutenzione

Coordinare la pianificazione di DBCC CHECKDB con altre attività di manutenzione come operazioni di backup, ricostruzione degli indici e aggiornamenti delle statistiche. Evitare la sovrapposizione di operazioni ad alto consumo di risorse che potrebbero causare un degrado delle prestazioni o problemi di timeout. Pianificare le finestre di manutenzione in base alle proiezioni di crescita delle dimensioni del database, garantendo tempo adeguato per la verifica completa dell'integrità con l'aumentare dei volumi di dati.

7.4 Monitoraggio e avvisi automatizzati

Configurazione SQL Server Avvisi degli agenti per informare immediatamente gli amministratori quando DBCC CHECKDB identifica un danneggiamento. Implementare soluzioni di analisi dei log che estraggano e categorizzino i risultati dei controlli di integrità, consentendo l'analisi delle tendenze e l'identificazione proattiva dei problemi. Creare procedure di escalation che definiscano i tempi di risposta e il personale responsabile per i diversi livelli di gravità del danneggiamento.

8. DBCC CHECKTABLE: l'alternativa leggera

8.1 Quando utilizzare CHECKTABLE invece di CHECKDB

DBCC CHECKTABLE fornisce un controllo di integrità mirato per singole tabelle, rendendolo ideale per tarRisoluzione dei problemi e manutenzione ottimizzate di specifici oggetti di database. Utilizzate CHECKTABLE per analizzare problemi di prestazioni con tabelle specifiche, convalidare tabelle aziendali critiche tra controlli completi del database o quando vincoli di tempo impediscono la convalida completa del database. Questo approccio si rivela particolarmente utile nei database di grandi dimensioni in cui le operazioni CHECKDB complete superano le finestre di manutenzione disponibili.

8.2 Sintassi ed esempi di DBCC CHECKTABLE

Il comando base CHECKTABLE tarottiene tabelle specifiche:

DBCC CHECKTABLE('YourTable')

Come CHECKDB, CHECKTABLE supporta diverse opzioni, tra cui NOINDEX per l'ottimizzazione delle prestazioni e parametri di riparazione per la risoluzione dei problemi. È anche possibile specificare i nomi degli schemi per un'identificazione precisa della tabella:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Questo tarL'approccio geted consente la verifica granulare dell'integrità mantenendo inalterate le prestazioni del sistema durante l'orario lavorativo.

8.3 Vantaggi in termini di prestazioni per database di grandi dimensioni

Le operazioni CHECKTABLE vengono completate in modo significativamente più rapido rispetto ai controlli completi del database, consentendo verifiche di integrità più frequenti delle tabelle critiche. Questo approccio consente la convalida giornaliera delle tabelle aziendali essenziali, riservando le operazioni CHECKDB complete a pianificazioni settimanali o mensili. Il ridotto consumo di risorse rende CHECKTABLE adatto all'esecuzione in ambiente di produzione con un impatto minimo sull'utente.

9. Quando CHECKDB fallisce

DBCC CHECKDB fallirà in vari scenari, tra cui:

• Esecuzione di DBCC CHECKDB termina in modo anomalo
• L'esecuzione di DBCC CHECKDB viene completata correttamente, ma opzioni di riparazione non riesce a riparare il database.

In questi scenari abbiamo bisogno di uno strumento più professionale che ci aiuti a correggere i danneggiamenti nel database.

9.1 Introduzione a DataNumen SQL Recovery

DataNumen SQL Recovery fornisce funzionalità più avanzate:

• Miglior tasso di recupero nell'industria.
• Recupera file di database gravemente danneggiati.
• Recupera tutti gli oggetti del database, tra cui tabelle, indici, viste, trigger, regole e impostazioni predefinite.
• Ripristina stored procedure, funzioni scalari, funzioni con valori di tabella inline e funzioni con valori di tabella con più istruzioni.
• Recupera i record eliminati definitivamente.
• Decifrare gli oggetti crittografati in SQL Server banche dati.
• Ripara i file MDF in batch.
• Opzioni di riparazione complete.
• Registrazione e reporting avanzati.
• Supporto per tutti SQL Server versioni.
• Disponibilità del supporto tecnico
• Aggiornamenti e miglioramenti regolari

9.2 Confronto del tasso di successo

I tassi di successo del recupero differiscono in modo significativo:

• DBCC CHECKDB e CHECKTABLE: 1.27% tasso medio di recupero
• DataNumen: 92.6% tasso di recupero

Di seguito un confronto competitivo completo:

9.3 Recupero da gravi casi di corruzione

Funzionalità avanzate per i casi più gravi:

• Recupero da storage fisicamente danneggiato
• Recupero da unità formattate o sistemi bloccati
• Recupera da immagini disco, file di backup, file disco macchina virtuale, temporarfile y, ecc.

9.4 Quando considerare soluzioni professionali

• Nessun backup disponibile di recente
• DBCC CHECKDB fallisce
• Scenari di corruzione grave
• Gestione dei dati aziendali critici
• Quando il tempo è critico
• Quando è essenziale il massimo recupero

10. FAQs

11. CONCLUSIONE

11.1 Riepilogo dei punti chiave

11.1.1 Riepilogo dei comandi essenziali di DBCC CHECKDB

Padroneggia la sintassi di base di DBCC CHECKDB per un controllo completo del database, utilizza le opzioni NOINDEX e PHYSICAL_ONLY per l'ottimizzazione delle prestazioni e comprendi CHECKTABLE per tarVerifica della tabella ottenuta. Questi comandi fondamentali costituiscono il fondamento della manutenzione proattiva del database, consentendo il rilevamento precoce di eventuali danneggiamenti e il monitoraggio sistematico dell'integrità.

11.1.2 Promemoria sulle migliori pratiche critiche

Mantenere sempre backup aggiornati prima di eseguire controlli di integrità, pianificare operazioni CHECKDB regolari in base alla criticità del database e implementare un monitoraggio automatico per avvisi immediati di danneggiamento. Ricordate che la prevenzione attraverso un monitoraggio regolare supera gli approcci reattivi e che le soluzioni di ripristino professionali offrono preziose opzioni di backup quando gli strumenti standard si rivelano insufficienti.

11.2 Quando utilizzare DBCC CHECKDB rispetto alle soluzioni avanzate

Utilizzare DBCC CHECKDB per il monitoraggio di routine dell'integrità e la risoluzione di piccole corruzioni, riservando strumenti di ripristino professionali per scenari di corruzione gravi che vanno oltre le capacità di riparazione integrate. Il framework decisionale dovrebbe considerare la disponibilità del backup, la criticità dei dati, i vincoli temporali e la gravità della corruzione. Gli amministratori di database di successo combinano il monitoraggio regolare di CHECKDB con strategie di backup complete e la conoscenza delle opzioni di ripristino avanzate quando gli approcci standard si rivelano inadeguati.

12. Riferimenti

1. Microsoft Learn. "DBCC CHECKDB (Transact-SQL)." SQL Server DocumentazioneMicrosoft Corporation.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. "Risolvere gli errori di coerenza del database segnalati da DBCC CHECKDB." SQL Server DocumentazioneMicrosoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors