Nell'articolo precedente abbiamo visto come controllare se un database è corrotto oppure no (fai click qui: La megaditta è ferma! ..DBCC CHECK fallito)
Il comando che avevamo utilizzato in precedenza è il comando DBCC CHECKDB. Oggi vi faccio vedere un modo diverso "ma molto furbo" per vedere quali tabelle si sono corrotte.
Lo si può usare mentre il DBCC sta verificando i databases dacchè l'operazione richiede tempo in caso di database di dimensioni notevoli.Seguitemi, si parte!
La tabella suspect_pages
Diciamo subito che SQL Server quando trova degli errori se li memorizza un una tabella apposita.
Questa tabella si chiama suspected_pages ed è contenuta nel database di sistema msdb.Aprite quindi la console del SQL Server Manager Studio scrivete:
SELECT * FROM [msdb].[dbo].[suspect_pages]
Eseguitela ed ecco qui il risultato:
Anche questo comando ci dice che è presente la pagina 26094 che ha un problema.
Ora che abbiamo il numero della pagina andiamola ad osservare utilizzando il comando, di cui abbiamo già parlato, DBCC PAGE:
DBCC TRACEON (3604);
DBCC PAGE (27, 1, 26094, 0);
DBCC TRACEOFF (3604);
Quando lo eseguiamo otteniamo una serie di informazioni.
Senza entrare nel dettaglio per il momento cerchiamo la scritta Metadata: ObjectId =
Bene! Ora sappiamo che la pagina 26094 appartiene all'oggetto che ha ID=3
Infine andiamo a vedere qual'è la tabella interessata eseguendo:
SELECT OBJECT_NAME(3)
Eccoci qua! questa è il nome della tabella
Per adesso è veramente tutto!
Ma vi preannuncio che il prossimo articolo sarà molto più "denso".
Vi farò vedere come tentare il recupero di un database corrotto andando fisicamente a modificare i puntamenti delle varie pagine.
A proposito, ve lo ricordate il passaggio nell'articolo precedente dove dicevamo..
"...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."
Ciao, alla prossima e ... STAY TUNED!
Luca Biondi @ SQLServerPerformance blog!