it-swarm-eu.dev

Opětovné sestavení protokolu transakcí

Máme velmi rozsáhlou databázi (~ 6TB), jejíž soubor protokolu transakcí byl smazán (zatímco byl vypnut SQL Server. Vyzkoušeli jsme:

  1. Odpojení a opětovné připojení databáze; a
  2. Odvolání souboru protokolu transakcí

... ale zatím nic nefungovalo.

Momentálně běží:

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

... ale vzhledem k velikosti databáze to bude pravděpodobně trvat několik dní.

Otázky

  • Existuje rozdíl mezi výše uvedeným a následujícím příkazem?

    DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)
    
  • Měli bychom vykonávat REPAIR_ALLOW_DATA_LOSS namísto?

Stojí za povšimnutí, že data pocházejí z jiných zdrojů, takže databázi lze znovu sestavit, domníváme se však, že oprava databáze bude mnohem rychlejší než opětovné vložení všech dat.


Aktualizace

Pro ty, kteří udržují skóre: ALTER DATABASE/REBUILD LOG příkaz dokončen po 36 hodinách a nahlášen

Upozornění: Protokol databáze 'dbname' byl znovu vytvořen. Transakční konzistence byla ztracena. Řetězec OBNOVENÍ byl přerušen a server již nemá kontext v předchozích souborech protokolu, takže budete muset vědět, jaké to byly.
Měli byste spustit DBCC CHECKDB k ověření fyzické konzistence. Databáze byla uvedena do režimu pouze pro dbo. Až budete připraveni zpřístupnit databázi k použití, budete muset resetovat možnosti databáze a odstranit všechny další soubory protokolu.

Potom jsme spustili DBCC CHECKDB (trvalo asi 13 hodin), což bylo úspěšné. Řekněme jen, že jsme se všichni naučili důležitost zálohování databáze (a udělení projektovým manažerům přístup k serveru ...).

20

Nikdy neoddělujte databázi podezřelých. Jak jste vlastně přiložili databázi po jejím odpojení? Použili jste CREATE DATABASE S možností FOR ATTACH_REBUILD_LOG?

Tyto příkazy měly udělat trik:

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;

Napsal jsem příspěvek pro tuto situaci:

Postup obnovy databáze SQL 2005/2008 - soubor protokolu byl smazán (část 3)

Ptali jste se na rozdíl mezi:

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

Jde o to, že můžete spustit obojí, abyste znovu vytvořili soubor protokolu, ale pomocí CHECKDB znovu vytvoříte protokol a zkontrolujete databázi také chyby integrity.

Také druhá (změnit databázi) nebude fungovat, pokud při ztrátě souboru protokolu došlo k aktivním transakcím (ne zapsaným na disk). Při spuštění nebo připojení, SQL Server bude chtít provést zotavení (rollback a rollforward) ze souboru protokolu, který tam není. Stává se to, když dojde ke zhroucení disku nebo dojde k neočekávanému vypnutí serveru a databáze není čistě vypnuta. Myslím, že to nebyl váš případ a všechno bylo pro vás dobré.

  1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS) spustit v databázi v nouzovém stavu zkontroluje databázi, zda neobsahuje chyby nekonzistence, nejprve se pokusí použít soubor protokolu k zotavení z nekonzistencí. Pokud toto chybí, je znovu vytvořen protokol transakcí.

  2. ALTER DATABASE REBUILD LOG ON... Je nezdokumentovaná procedura a vyžaduje další DBCC CHECKDB, Aby se odstranily všechny chyby.

20
yrushka

Ano, jsou to dvě různá tvrzení, z nichž každá dělá velmi odlišné věci.

V závislosti na stavu databáze, kdy byl soubor smazán, můžete být schopni získat a spustit připojením databáze a opětovným vytvořením protokolu pomocí :

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

Viz sp_attach_single_file_db (Transact-SQL) v dokumentaci k produktu.

Podívejte se také na tento blogový příspěvek od Paul S. Randal :

Oprava v nouzovém režimu: velmi, velmi poslední možnost

12
SQLRockstar