it-swarm.it

Modalità SQL Server 2008 R2 (Suspect) - come riparare?

Ho un database SQL Server 2008 R2 in modalità Sospetto. Ho provato a risolverlo eseguendo questa query:

EXEC sp_resetstatus ‘yourDBname’;
ALTER DATABASE yourDBname SET EMERGENCY
DBCC checkdb(’yourDBname’)
ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB (’yourDBname’, REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE yourDBname SET MULTI_USER

Ma l'output di riparazione era questo messaggio:

Warning: You must recover this database prior to access.
Msg 8921, Level 16, State 1, Line 5
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Warning: The log for database 'ServeDB' has been rebuilt. Transactional consistency has been lost. The RESTORE chain was broken, and the server no longer 
has context on the previous log files, so you will need to know what they were. You should run DBCC CHECKDB to validate physical consistency. The database has 
been put in dbo-only mode. When you are ready to make the database available for use, you will need to reset database options and delete any extra log files.
Msg 8921, Level 16, State 1, Line 9
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.

Come riparare completamente il database? Questa riparazione che ho fatto, funziona solo per alcuni giorni, quindi il database passa nuovamente alla modalità Sospetto ...

5
Vytas999

Ho riscontrato un problema simile. Tuttavia, non sono stato in grado di estrarre il database dal sospetto poiché anche i backup erano sospetti. Ho usato la funzionalità di esportazione in SSMS per spostare tabelle e dati in un nuovo database vuoto.

Questo, tuttavia, non sposta tutte le stored procedure, le viste, le funzioni, ecc. Ho una copia di SQL Compare di RedGate (che consiglio vivamente a chiunque lavori regolarmente con gli schemi SQL) che ha gestito tutta la migrazione della struttura. Quindi ha reso il processo abbastanza indolore. RedGate ha una versione di prova di 14 giorni sul suo software se è necessario utilizzarlo.

Se si dispone solo di tabelle o di una piccola quantità di procedure, viste, ecc., È possibile utilizzare la funzione "Genera script" di SSMS per creare script di creazione per questi elementi, quindi eseguirli sul nuovo DB.

Confronto SQL di RedGate: http://www.red-gate.com/products/sql-development/sql-compare/

5
AJ Piscitelli

Non è possibile riparare questo database e la riparazione potenzialmente eseguita non è stata completata. Dovresti assicurarti di capire perché il tuo database sta diventando corrotto - controlla il tuo sistema disco poiché è il colpevole più probabile.

Quindi ripristina il database da un backup, ma assicurati di eseguire DBCC CHECKDB su quel backup per assicurarti che non si corrompa da solo.

DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS è l'ultima risorsa a cui dovresti mai andare. Prima di ciò, è necessario ripristinare un backup valido. Dopo aver utilizzato REPAIR_ALLOW_DATA_LOSS, non aspettarti che il tuo database ritorni magicamente di nuovo in vita - molto probabilmente, si è verificato un danno irreparabile - soprattutto in questo caso poiché si lamenta della corruzione della tabella di sistema.

7

Hai provato ciò che Paul Randal raccomanda? Creazione, rimozione, ricollegamento e correzione di un database sospetto

  1. Creare un nuovo database fittizio con lo stesso identico layout di file e il più vicino possibile alle dimensioni del file del database rimosso
  2. Arresto di SQL Server
  3. Scambia i file di database corrotti
  4. Riavvia SQL Server
  5. Utilizzare la riparazione in modalità di emergenza
6