it-swarm.dev

Przebudowa 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 powinniśmy wykonywać REPAIR_ALLOW_DATA_LOSS zamiast?

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 tych, którzy zachowują wynik: ALTER DATABASE/REBUILD LOG polecenie 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.
Należy 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życia, musisz zresetować opcje bazy danych i usunąć wszystkie dodatkowe pliki dziennika.

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

20

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 DATABASE Z opcją FOR ATTACH_REBUILD_LOG?

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 - Usunięto plik dziennika (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 pliki, aby odbudować plik dziennika, ale używając CHECKDB odbudujesz dziennik i sprawdzisz bazę danych pod kątem błędów integralności.

Druga (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 do odzyskania od wszelkich niespójności. Jeśli go brakuje, dziennik transakcji jest odbudowywany.

  2. ALTER DATABASE REBUILD LOG ON... To procedura nieudokumentowana i wymaga kolejnego DBCC CHECKDB, Aby naprawić wszelkie błędy.

20
yrushka

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, kiedy plik został usunięty, możesz być w stanie uruchomić się i uruchomić, dołączając bazę danych i odbudowując dziennik 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 Paul S. Randal :

Naprawa w trybie AWARYJNYM: w ostateczności

12
SQLRockstar