La megaditta è ferma! ..DBCC CHECK fallito

Rieccoci!

Prima di tutto, grazie delle tante visite, noi nonostante il caldo siamo ancora qui anche per farvi compagnia in questo assolato agosto.
Avviso di servizio: tra una settimana ci prenderemo una breve pausa, se volete potrebbe essere l'occasione ideale per rileggere ciò che vi è scappato!

L'articolo di oggi rappresenta il proseguo di quello di ieri ( Di database corrotti ed aziende bloccate), una sorta di parte 2.
L'argomento è vasto e così questa volta vedremo come controllare se un database è corrotto o meno.
Vedremo che a volte sarà possibile individuare quali sono la tabelle rovinate e che non sono più leggibili.

Stavolta non faremo nulla di pericoloso, percui provate e cercando di acquisire dimestichezza.

Buona lettura!

Riassunto della puntata precedente.
Il vostro cliente più grosso nonchè titolare della megaditta vi ha telefonato perchè improvvisamente a due giorni dalla chiusura estiva improvvisamente nessuno riusciva più a lavorare con il vostro gestionale!
Tutta la megadittà è ferma!
Vi siete collegati immediamente ed avete concluso che il problema è il database che si è rovinato!

Era presente un piano di manutenzione perfetto che segnalava errore ed inviava una mail al responsabile EDP.
Qui però il misterio si infittisce! Il responsabile EDP "giurava"  di non aver ricevuto mai alcuna mail.

Il nostro esperto SQL scopre subito l'arcano: l'invio della mail non era configurato correttamente e nessuna mail è mai partita!

Quindi, un insegnamento prezioso: se fate un piano di manutenzione controllate se funziona!

Fine del riassunto della puntata precedente: Il resto sarebbe accaduto molto velocemente.

Dopo aver rispristinano tutti i database disponibili emerse chiara la situazione: tutti i databases erano corrotti!
Torniamo nei panni del nostro esperto di SQL Server.
Come si fa a controllare se un database di SQL Server è corrotto o meno?

In questo ci viene in aiuto un comando T-SQL, il DBCC CHECKDB la cui funzione è quella di controllare appunto l'integrità del database.

Eseguite questo comando ed aspettate qualche minuto: 

DBCC CHECKDB ('NOMEDATABASE')

Quando avrà terminato andate alla fine del report.
Se il messaggio che restituisce è questo sotto allora il database non ha errori. 

CHECKDB ha trovato 0 errori di allocazione e 0 errori di coerenza nel database 'XXXX'.
Esecuzione DBCC completata. Se sono stati visualizzati messaggi di errore DBCC, rivolgersi all'amministratore di sistema.

In caso contrario scorretelo e cercate le righe in rosso e troverete le tabelle che hanno un problema.

Nel nostro caso invece la situazione si rileva essere anche peggiore.

Nel nostro caso il comando DBCC non arrivava neppure a controllare le tabelle presenti all'interno del database ma si bloccava prima.

Cosa ci dice questo errore?

Dice che ad essersi è rovinata non una tabella utente bensì una tabella di sistema.

Restituisce anche un errore (il numero 9787) ma se lo cercate sul sito della Microsoft si legge che l'unica opzione è quella di effettuare un restore da un database integro (...oppure di rivolgersi direttamente alla MicroSoft)

Messaggio 7987, livello 16, stato 1, riga 33
Controlli preliminari su tabella di sistema: per l'ID di oggetto 3 è definito un collegamento a catena non corrispondente. (1:772003)->next = (1:26094), ma (1:26094)->prev = (1:2494249). Istruzione di controllo interrotta a causa di un errore irreversibile.
Messaggio 8930, livello 16, stato 43, riga 33
Errore di database: metadati incoerenti per il database 27. Questo errore non può essere corretto e impedisce l'ulteriore elaborazione DBCC. Eseguire un ripristino da un backup.
Risultati DBCC per 'DATABASE_DA_VERIFICARE'.
CHECKDB ha trovato 0 errori di allocazione e 0 errori di coerenza nel database 'DATABASE_DA_VERIFICARE'.

Per inciso il messaggio spiega bene anche qual'è il tipo di errore che si è verificato.
In breve il database è composto da una serie di pagine che sono legate tra di loro come in una lista doppiamente collegata.

In ogni pagina è presente un campo NEXT che punta alla pagina successiva.
E anche presente un campo PREV che invece punta alla pagine precedente.

L'errore (che rivela anche il tipo di controllo che il DBCC esegue) dice che esiste una pagina che ha un problema di collegamento:

La pagina 1:772003 punta tramite il campo NEXT alla pagina 1:26094 ma
la pagina 1:26094 punta attraverso il campo PREV non alla pagina 1:772003 ma alla pagina 1:2494249.

Ma torniamo a noi.

Già certo un database integro ...solo che noi non ne abbiamo nessuno!

In questi casi, in cui ad essere rovinato non sono le tabelle utente,  la soluzione migliore diventa quella di travasare tutti i dati su di un database che abbia la stessa struttura da integra.

Per fortuna noi l'avevamo, era un backup datato di un azienda di prova ma tanto bastava.

Abbiamo quindi scriptato tutta la struttura del database "datato" tramite la funzione standard del Management studio:

Poi abbiamo travasato i dati dal database corrotti a quello sano tabella per tabella.

La megaditta era salva!

A proposito: non vi ho raccontato di come ho fatto a capire che tutte le tabelle erano leggibili e neppure vi ho fatto vedere come recuperari i dati nel caos non avessimo avuto un database con la struttura sana da cui partire (vi avverto già da ora: occorre andare molto più in profondità..)

 

Non sarà per invogliarvi a leggere il mio prossimo "pezzo" ?

 

 

Ciao ed al prossimo post!

Luca

 

 

Next post: Database Corrotti e la tabella suspect_pages

Previous post: Di database corrotti ed aziende bloccate