COME RIPARARE UN DATABASE SUSPECT

Mi è capitato ultimamente di dover ripristinare un database con flag impostato su SUSPECT. La problematica possiede una piccola probabilità di risoluzione, vediamo come riparare una base dati compromessa.

Le cause del problema

Cerchiamo di capire prima di tutto quali sono le cause del problema. Un database sospetto è un database ritenuto compromesso da SQL Server che, per ragioni di sicurezza, imposta il flag "sospetto" ed impedisce l'accesso ai dati. 

Le possibili cause sono:

• I file fisici sul file system risultano corrotti, i motivi potrebbero essere di natura software (virus) o hardware (hard disk danneggiato).
• Spazio libero su disco insufficiente.
• Memoria RAM insufficiente.
• I file fisici sul file system risultano aperti da un altro software quindi con accesso negato.
• Uno spegnimento inaspettato del computer o l'arresto inaspettato dei servizi di SQL Server.

Nel mio caso però, nessuno di questi casi era applicabile.

Risolvere il problema

Per risolvere il problema è necessario affidarci a SQL Server Management Studio, che ci fornisce l'unica via d'accesso per i database suspect. Una volta effettuato il login iniziamo a scrivere le prime query di diagnostica (al posto di DBNAME utilizzeremo il nome del nostro database suspect):

Il primo tentativo (quasi sempre inutile) è quello di togliere il flag di sospetto al database.

exec sp_resetstatus DBNAME

Il passo successivo è impostare il database in emergenza. In questa modalità i dati del database torneranno ad essere accessibili (se non corrotti).

alter database DBNAME set emergency

Tramite il comando DBCC è possibile effettuare un check degli oggetti del database:

dbcc checkdb('DBNAME')
alter database DBNAME set SINGLE_USER with ROLLBACK IMMEDIATE
dbcc checkdb('DBNAME',REPAIR_ALLOW_DATA_LOSS)
alter database DBNAME set MULTI_USER

Quasi sempre i risultati di DBCC sono totalmente incomprensibili, per questo motivo consiglio di cercare brevemente qualche riferimento a tabelle specifiche o altro per iniziare a restringere le possibili cause del problema.

A questo punto se sono state scoperte le cause possiamo procedere con l'operazione di ripristino:

1. Creiamo un database d'appoggio
2. Nel menu contestuale del database selezioniamo la voce Task quindi Export Data.
3. Copiamo tutti i dati nel database d'appoggio
4. Durante questa procedura alcune tabelle saranno impossibili da copiare
5. Ripetere il passaggio di Export Data escludendo le tabelle inaccessibili quindi procedere finchè l'export non viene fatto con successo.
6. Rinominare il database originale con un nuovo nome (ad esempio DBNAME_OLD)
7. Rinominare il database d'appoggio con il nome originale
8. Copiare eventuali utenti o elementi che non sono stati importati dall'operazione di Export Data.

Adesso siamo nella condizione di avere un database funzionante che però non possiede le tabelle danneggiate. Possiamo quindi procedere con due possibili soluzioni:

1. PERDITA DEI DATI
• Nel caso in cui i dati contenuti nelle tabelle non siano vitali è sufficiente ricreare la tabella ed eventualmente popolarla a mano (ad esempio: tabelle di configurazione).
2. RIPRISTINO DEI DATI
• Nel caso in cui i dati contenuti nelle tabelle siano vitali è necessario creare un altro database d'appoggio quindi effettuare il restore dell'ultimo backup effettuato quindi copiare il contenuto delle tabelle ripristinate nelle tabelle del nostro nuovo database. In questo caso avremo uno storico dei dati ripristinato senza i dati persi dal problema.

Eliminare il problema alla fonte...

So che a molti questa non sembra una soluzione valida, ma vi ricordo che se avete necessità di non perdere assolutamente nemmeno un bit di un dato, dovevate scegliere una soluzione con database ridondanti o adottare soluzioni più robuste. 

fonti support.managed.com