Odbudowanie dziennika transakcji

Mamy bardzo dużą bazę danych (~ 6 TB), której plik dziennika transakcji został usunięty (podczas gdy SQL Server był zamknięty. Próbowaliśmy:

1. Odłączanie i ponowne podłączanie bazy danych; i
2. Odzyskiwanie pliku dziennika transakcji

... ale jak dotąd nic nie działało.

Aktualnie prowadzimy:

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

... ale biorąc pod uwagę rozmiar bazy danych, prawdopodobnie zajmie to kilka dni.

pytania

• Czy istnieje różnica między powyższym poleceniem a następnym?

  DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

• Czy REPAIR_ALLOW_DATA_LOSSzamiast tego powinniśmy wykonywać ?

Warto zauważyć, że dane pochodzą z innych źródeł, więc baza danych może zostać odbudowana, jednak podejrzewamy, że naprawienie bazy danych będzie znacznie szybsze niż ponowne włożenie wszystkich danych.

Aktualizacja

Dla osób utrzymujących wynik: ALTER DATABASE/REBUILD LOGpolecenie zostało zakończone po około 36 godzinach i zgłoszono:

Ostrzeżenie: dziennik bazy danych „dbname” został odbudowany. Zagubiona została spójność transakcyjna. Łańcuch PRZYWRACANIA został zerwany, a serwer nie ma już kontekstu w poprzednich plikach dziennika, więc musisz wiedzieć, jakie były.
Powinieneś uruchomić DBCC CHECKDB, aby sprawdzić fizyczną spójność. Baza danych została ustawiona w tryb tylko dbo. Gdy będziesz gotowy udostępnić bazę danych do użytku, musisz zresetować opcje bazy danych i usunąć wszelkie dodatkowe pliki dziennika.

Następnie przeprowadziliśmy DBCC CHECKDB(zajęło około 13 godzin), co było udane. Powiedzmy, że wszyscy nauczyliśmy się, jak ważne jest tworzenie kopii zapasowych baz danych (i udzielanie kierownikom projektów dostępu do serwera ...).

Nigdy nie odłączaj podejrzanej bazy danych. W każdym razie, jak załączyłeś bazę danych po jej odłączeniu? Użyłeś CREATE DATABASEz FOR ATTACH_REBUILD_LOGopcją?

Te polecenia powinny załatwić sprawę:

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;

Napisałem post dotyczący tej sytuacji:

SQL 2005/2008 Procedura odzyskiwania bazy danych - plik dziennika usunięty (część 3)

Pytałeś o różnicę między:

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

Chodzi o to, że możesz uruchomić oba, aby odbudować plik dziennika, ale wraz z CHECKDBtobą odbuduj dziennik i sprawdź bazę danych pod kątem błędów integralności.

Drugi (zmiana bazy danych) nie będzie działał, jeśli po utracie pliku dziennika wystąpiły aktywne transakcje (niepisane na dysk). Podczas uruchamiania lub dołączania SQL Server będzie chciał wykonać odzyskiwanie (wycofanie i przywrócenie) z pliku dziennika, którego nie ma. Zdarza się to, gdy dysk ulega awarii lub następuje nieoczekiwane zamknięcie serwera, a baza danych nie zostaje całkowicie zamknięta. Wydaje mi się, że to nie była twoja sprawa i wszystko dobrze dla ciebie rozwiązało.

1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)uruchom na bazie danych w stanie awaryjnym sprawdza bazę danych pod kątem błędów niespójności, próbuje najpierw użyć pliku dziennika, aby odzyskać wszelkie niespójności. Jeśli go brakuje, dziennik transakcji jest odbudowywany.

2. ALTER DATABASE REBUILD LOG ON...jest procedurą nieudokumentowaną i wymaga późniejszego DBCC CHECKDBnaprawienia błędów.

Tak, są to dwie różne wypowiedzi, z których każda robi bardzo różne rzeczy.

W zależności od stanu bazy danych, gdy plik został usunięty, to może być w stanie wstać i działa poprzez podłączenie do bazy danych i przebudowa dziennika za pomocą:

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

Zobacz sp_attach_single_file_db (Transact-SQL) w dokumentacji produktu.

Zobacz także ten post na blogu autorstwa Paula S. Randala :

Naprawa w trybie AWARYJNYM: w ostateczności