it-swarm.it

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 eseguire REPAIR_ALLOW_DATA_LOSS anziché?

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.


pdate

Per coloro che mantengono il punteggio: il ALTER DATABASE/REBUILD LOG comando 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 (ha 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 ...).

20

Non scollegare mai un database sospetto. Comunque, come hai collegato il database dopo averlo staccato? Hai usato CREATE DATABASE Con l'opzione FOR ATTACH_REBUILD_LOG?

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 CHECKDB si ricostruisce il registro e si verificano anche errori di integrità nel database.

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, prova innanzitutto a utilizzare il file di registro per ripristinare eventuali incoerenze. Se questo manca, il registro delle transazioni viene ricostruito.

  2. ALTER DATABASE REBUILD LOG ON... È una procedura non documentata e richiede un successivo DBCC CHECKDB Per correggere eventuali errori.

20
yrushka

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

A seconda dello stato del database al momento dell'eliminazione del file, l'utente potrebbe essere in grado di mettersi in funzione 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

12
SQLRockstar