Ricostruzione del registro delle transazioni

Abbiamo un database molto grande (~ 6 TB), il cui file di registro delle transazioni è stato eliminato (mentre SQL Server è stato chiuso. Abbiamo provato:

1. Staccare e ricollegare il database; e
2. Annullamento della cancellazione del file di registro delle transazioni

... ma nulla ha funzionato finora.

Attualmente stiamo eseguendo:

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

... ma date le dimensioni del database, questo richiederà probabilmente alcuni giorni per essere completato.

Domande

• C'è una differenza tra il comando sopra e quello seguente?

  DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

• Dovremmo REPAIR_ALLOW_DATA_LOSSinvece eseguire ?

Vale la pena notare che i dati sono derivati ​​da altre fonti in modo che il database possa essere ricostruito, tuttavia sospettiamo che sarà molto più veloce riparare il database che reinserire nuovamente tutti i dati.

Aggiornare

Per coloro che mantengono il punteggio: il ALTER DATABASE/REBUILD LOGcomando è stato completato dopo circa 36 ore e riportato:

Avviso: il registro per il database 'dbname' è stato ricostruito. La coerenza transazionale è andata persa. La catena RESTORE è stata interrotta e il server non ha più contesto sui file di registro precedenti, quindi sarà necessario sapere quali fossero.
È necessario eseguire DBCC CHECKDB per convalidare la coerenza fisica. Il database è stato messo in modalità solo dbo. Quando si è pronti per rendere il database disponibile per l'uso, sarà necessario ripristinare le opzioni del database ed eliminare eventuali file di registro aggiuntivi.

Abbiamo quindi eseguito un DBCC CHECKDB(impiegato circa 13 ore) che ha avuto successo. Diciamo solo che tutti abbiamo imparato l'importanza dei backup del database (e garantendo ai project manager l'accesso al server ...).

Non scollegare mai un database sospetto. Comunque, come hai collegato il database dopo averlo staccato? Hai usato CREATE DATABASEcon l' FOR ATTACH_REBUILD_LOGopzione?

Questi comandi avrebbero dovuto fare il trucco:

ALTER DATABASE recovery_test_2 SET EMERGENCY;   
ALTER DATABASE recovery_test_2 SET SINGLE_USER;  

DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) 
WITH NO_INFOMSGS, ALL_ERRORMSGS;

Ho scritto un post per questa situazione:

Procedura di recupero del database SQL 2005/2008 - File di registro eliminato (parte 3)

Hai chiesto informazioni sulla differenza tra:

• DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) e
• ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

Il fatto è che è possibile eseguire entrambi per ricostruire il file di registro, ma con CHECKDBte ricostruire il registro e controllare anche il database per errori di integrità.

Inoltre, il secondo (alter database) non funzionerà se ci fossero transazioni attive (non scritte su disco) quando il file di registro andava perso. All'avvio o all'allegato, SQL Server vorrà eseguire il ripristino (rollback e rollforward) dal file di registro che non è presente. Succede quando un disco si arresta in modo anomalo o si verifica un arresto imprevisto del server e il database non viene arrestato in modo pulito. Immagino che non fosse il tuo caso e tutto risolto per te.

1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)eseguito su un database in stato di emergenza controlla che il database non presenti errori di incoerenza, tenta innanzitutto di utilizzare il file di registro per ripristinare eventuali incoerenze. Se manca, il registro delle transazioni viene ricostruito.

2. ALTER DATABASE REBUILD LOG ON...è una procedura non documentata e richiede un successivo DBCC CHECKDBper correggere eventuali errori.

Sì, quelle sono due affermazioni diverse, ognuna che fa cose molto diverse.

A seconda dello stato del database al momento dell'eliminazione del file, potrebbe essere possibile attivarsi collegando il database e ricostruendo il registro utilizzando:

EXEC sp_attach_single_file_db 'dbname here', 'file path and name here'

Vedere sp_attach_single_file_db (Transact-SQL) nella documentazione del prodotto.

Vedi anche questo post sul blog di Paul S. Randal :

Riparazione in modalità EMERGENCY: l'ultima, ultima risorsa