Database Corrotti e la tabella suspect_pages

Ciao a tutti!

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!



 
 
 
 
 
 
 
 
 



Comments

Post a Comment

I Post più popolari

SQL Server, execution plan and the lazy spool (clearly explained)

SQL Server, datetime vs. datetime2

La clausola NOLOCK. Approfondiamo e facciamo chiarezza!