I database implicano molta attività di I/O. Quando si ha molto carico di lavoro I/O, si corre intrinsecamente il rischio di corruzione. La principale difesa contro la corruzione del database consiste nell'eseguire backup regolari del database e nel verificare periodicamente che tali backup possano essere ripristinati. Tuttavia, è necessario prestare attenzione alla corruzione del database e SQL Server fornisce strumenti che è possibile utilizzare per verificare la coerenza del database, nonché per risolvere problemi di coerenza se i backup non sono disponibili.
Errori di coerenza
Possono verificarsi errori di coerenza nei database utente o nei database di sistema, lasciando tabelle, database o persino intere istanze in uno stato inaccessibile. Gli errori di coerenza possono verificarsi per molti motivi, inclusi errori hardware e problemi con il Motore di database. Le sezioni seguenti evidenziano i tipi di errore che possono verificarsi, come rilevarli e cosa fare se i database di sistema vengono danneggiati.
Comprendere gli errori di coerenza
Possono verificarsi diversi errori di coerenza del database; questi causano il fallimento di una query o la disconnessione di una sessione e la scrittura di un messaggio nel log degli errori di SQL Server. Gli errori più comuni sono descritti in dettaglio nelle sezioni seguenti.
Errore 605
Un errore 605 può indicare uno dei due problemi, a seconda della gravità dell'errore. Se la severity è di livello 12, indica una lettura sporca(dirty). Una lettura sporca è un'anomalia transazionale che si verifica quando si utilizza il livello di isolamento Read Uncommitted isolation level o l'hint di query NOLOCK. Si verifica quando una transazione legge una riga che non è mai esistita nel database, dovuta al rollback di un'altra transazione.
Per risolvere questo problema, eseguire nuovamente la query finché non riesce oppure riscrivere la query per evitare l'utilizzo del livello di isolamento Read Uncommitted isolation level o l'hint di query NOLOCK.
L'errore 605 potrebbe tuttavia indicare un problema più serio e spesso indica un guasto hardware.
Se il livello di severity è 21, la pagina potrebbe essere danneggiata oppure il sistema operativo potrebbe fornire la pagina errata. In questo caso, è necessario eseguire il ripristino da un backup o utilizzare DBCC CHECKDB per risolvere il problema.
Inoltre, è necessario fare riferimento agli amministratori di sistema ed al team che si occupa dello storage di verificare eventuali problemi hardware o a livello di disco.
Errore 823
Si verifica un errore 823 quando SQL Server tenta di eseguire un'operazione di I/O e l'API di Windows utilizzata per eseguire questa azione restituisce un errore al Motore di database.
Un errore 823 è quasi sempre associato a un problema hardware o di driver.
Se si verifica un errore 823, è necessario utilizzare DBCC CHECKDB per verificare la coerenza del resto del database e di eventuali altri database che risiedono sullo stesso volume.
Si dovrebbe fare riferimento anche al team dedicato allo storage per risolvere il problema con lo storage stesso. Si dovrebbe anche verificare la presenza di messaggi di errore correlati nel registro eventi di Windows.
Errore 824
Se la chiamata all'API Windows ha esito positivo ma sono presenti problemi di coerenza logica con i dati restituiti, viene generato un errore 824. Proprio come un errore 823, un errore 824 di solito significa che c'è un problema con il sottosistema storage
Se viene generato un errore 824, dovresti seguire la stessa linea di condotta definita quando viene generato un errore 823.
Errore 5180
Si verifica un errore 5180 quando viene rilevato un ID file non valido. Gli ID file vengono archiviati nei puntatori di pagina, nonché nelle pagine di sistema all'inizio di ciascun file.
Questo errore è in genere causato da un puntatore danneggiato all'interno di una pagina, ma può potenzialmente anche indicare un problema con il Motore di database.
Se si verifica questo errore, è necessario ripristinare da un backup o eseguire DBCC CHECKDB per correggere l'errore.
Errore 7105
Si verifica un errore 7105 quando una riga all'interno di una tabella fa riferimento a una struttura LOB (Large Object Block) che non esiste. Ciò può verificarsi a causa di una lettura errata allo stesso modo di un errore 605 di severity 12 oppure può verificarsi come risultato di una pagina danneggiata. Il danneggiamento può trovarsi nella pagina dati che punta alla struttura LOB o in una pagina della struttura LOB stessa.
Se riscontri un errore 7105, dovresti eseguire DBCC CHECKDB per verificare la presenza di errori. Se non ne trovi, l'errore è probabilmente il risultato di una lettura sporca. Se trovi errori, tuttavia, ripristina il database da un backup o utilizza DBCC CHECKDB per risolvere il problema.
Rilevare gli errori di coerenza
SQL Server fornisce meccanismi per verificare l'integrità delle pagine mentre vengono lette e scritte su disco.
Fornisce inoltre un registro delle pagine danneggiate che ti aiuta a identificare il tipo di errore che si è verificato, quante volte si è verificato e lo stato attuale della pagina che è diventata danneggiata.
Page Verify Option
Un'opzione a livello di database denominata Page Verify determina il modo in cui SQL Server verifica il danneggiamento delle pagine causato dal sottosistema I/O durante la lettura e la scrittura di pagine su disco.
Può essere configurata come CHECKSUM, che è l'opzione predefinita, TORN_PAGE_DETECTION o NONE.
L'impostazione consigliata è CHECKSUM.
Quando questa opzione è selezionata, ogni volta che viene scritta una pagina, viene creato un valore CHECKSUM sull'intera pagina e salvato nell'intestazione della pagina.
Un valore CHECKSUM è una somma hash, deterministica e univoca in base al valore su cui viene eseguita la funzione di hashing. Questo valore viene quindi ricalcolato quando una pagina viene letta nella cache del buffer e confrontata con il valore originale.
Quando viene specificato TORN_PAGE_DETECTION, ogni volta che una pagina viene scritta su disco, i primi 2 byte di ogni settore da 512 byte della pagina vengono scritti nell'intestazione della pagina. Quando la pagina viene successivamente letta in memoria, questi valori vengono controllati per garantire che siano gli stessi. Il difetto qui è ovvio; è perfettamente possibile che una pagina sia corrotta e che questa corruzione non venga notata, perché non è all'interno dei byte che vengono controllati.
TORN_PAGE_DETECTION è una funzionalità deprecata di SQL Server.
Se la verifica della pagina è impostata su NONE, SQL Server non esegue alcuna verifica della pagina. Questa non è una best practice.
Se tutti i database sono stati creati in un'istanza di SQL Server 2022, sono tutti configurati per utilizzare CHECKSUM per impostazione predefinita. Se hai eseguito la migrazione dei database da una versione precedente di SQL Server, tuttavia, potrebbero essere configurati per utilizzare TORN_PAGE_DETECTION.
Se scopri che un database utilizza TORN_PAGE_DETECTION o, peggio, è stato impostato su NONE, puoi risolvere il problema modificando l'impostazione nella pagina Opzioni della finestra di dialogo Proprietà database.
Nota: la modifica dell'opzione Page Verify non comporta la creazione immediata del CHECKSUM rispetto alle pagine di dati. Il CHECKSUM viene generato solo quando le pagine vengono riscritte su disco dopo essere state modificate.
In alternativa, è possibile ottenere gli stessi risultati utilizzando T-SQL con un'istruzione
ALTER DATABASE <DatabaseName> SET PAGE_VERIFY CHECKSUM WITH NO_WAIT
Pagine Suspect
Se SQL Server rileva una pagina con un checksum errato o una pagina danneggiata, registra le pagine nel database MSDB in una tabella denominata dbo.suspect_pages. Registra inoltre tutte le pagine che riscontrano un errore 823 o 824 in questa tabella.
La struttura della tabella è questa:
| Column | Description |
|---|---|
| Database_id | ID del database che contiene la pagina sospetta. |
| File_id | ID del file che contiene la pagina sospetta. |
| Page_id | ID della pagina sospetta |
| Event_Type | La natura dell'evento che ha causato l'aggiornamento delle pagine sospette. |
| Error_count | Un contatore incrementale che registra il numero di volte in cui si è verificato l'evento. |
| Last_updated_date | L'ultima volta che la riga è stata aggiornata. |
I possibili valori per la colonna event_type sono:
| Event_type | Description |
|---|---|
| 1 | 823 or 824 error |
| 2 | Bad checksum |
| 3 | Torn page |
| 4 | Restored |
| 5 | Repaired |
| 7 | Deallocated by DBCC CHECKDB |
Dopo aver registrato la pagina sospetta nella tabella suspect_pages SQL Server aggiorna la riga dopo aver risolto il problema ripristinando la pagina da un backup o utilizzando DBCC CHECKDB.
Inoltre incrementa il conteggio degli errori ogni volta che viene rilevato un errore con lo stesso event_type.
Si dovrebbe monitorare questa tabella per righe nuove ed aggiornate e dovresti anche eliminare periodicamente le righe da questa tabella, che hanno un event_type di 4 o 5, per evitare che la tabella si riempia.
Consistency Issues for Memory-Optimized Tables
La corruzione in genere si verifica durante un'operazione di I/O fisica, ma è un errore pensare che le teballe ottimizzate per la memoria siano immuni alla corruzione.
Sebbene le tabelle ottimizzate per la memoria risiedano nella memoria, una copia delle tabelle e, a seconda delle impostazioni di durabilità, una copia dei dati, viene conservata nei file fisici. Questo per garantire che le tabelle e i dati siano ancora disponibili dopo il riavvio dell'istanza. Questi file possono essere soggetti a corruzione. È anche possibile che i dati in memoria vengano danneggiati, a causa di problemi come un chip RAM difettoso.
Sfortunatamente, le opzioni di riparazione di DBCC CHECKDB non sono supportate per le tabelle di memoria. Tuttavia, quando si esegue il backup di un database che contiene un filegroup ottimizzato per la memoria, viene eseguita una convalida del checksum sui file all'interno di questo filegroup.
È quindi fondamentale non solo eseguire backup regolari, ma anche verificare regolarmente che possano essere ripristinati con successo.
Questo perché l'unica opzione, nel caso di una tabella ottimizzata per la memoria danneggiata, è ripristinare dall'ultimo backup noto valido.
Per visualizzare il dettaglio degli errori che si possono riscontrare nell’ambito del motore di database Sql Server si può navigare al seguente indirizzo: https://learn.microsoft.com/it-it/sql/relational-databases/errors-events/database-engine-events-and-errors?view=sql-server-ver16
di Alice Sella, pubblicato il 20/02/2025
