Kopie zapasowe transakcji programu SQL Server a dzienniki

Odziedziczyłem bazę danych SQL Server 2008 o krytycznym znaczeniu dla biznesu i staram się skupić na planowaniu tworzenia kopii zapasowych. (Jestem programistą, a nie DBA.)

Sposób, w jaki nasz system jest teraz skonfigurowany, obejmuje dwa systemy tworzenia kopii zapasowych:

1. Cotygodniowe pełne kopie zapasowe ( .bak) i cogodzinne .trnkopie zapasowe dziennika transakcji ( ). Przechowujemy kilka zestawów tych kopii zapasowych i są one regularnie wysyłane poza miejsce.
2. SQL Server logs ( .ldf), z modelem odzyskiwania ustawionym na Full. Ten plik znajduje się na innym dysku niż .mdfplik główny , ale w przeciwnym razie nie jest tworzona kopia zapasowa.

W przypadku awaryjnego przywracania (lub podczas przywracania kopii zapasowych na maszynę programistyczną) moją procedurą jest użycie .bakplików, a następnie zastosowanie plików .trn. Mamy skrypt, który czyni tę procedurę stosunkowo prostą.

Moje pytania:

1. Czy można przywrócić bazę danych z .ldfpliku? Po co to jest?
2. Czy niepotrzebne jest posiadanie obu tych dzienników transakcji?
3. Czy ważne jest utworzenie kopii zapasowej .ldfpliku?

Nie, nie można przywrócić bazy danych z pliku ldf. Plik ldf zostanie przywrócony wraz z plikami mdf.

Nie, nie jest to zbędne, ponieważ mają dwa różne cele.

Ważne jest, aby wykonywać pełne kopie zapasowe i kopie zapasowe dziennika transakcji. Samo posiadanie kopii pliku ldf nie pomaga przywrócić bazy danych.

Co do tego, do czego służy plik ldf, ldf to dziennik transakcji. Pomyśl o tym jak o okrągłym buforze, który rejestruje zmiany w bazie danych. Po zaktualizowaniu wiersza zmiana jest natychmiast zapisywana w pliku ldf. W pewnym momencie w przyszłości (zwykle mniej niż pięć minut) zmodyfikowane dane są zapisywane w pliku mdf.

Jeśli serwer ulegnie awarii lub nastąpiła awaria zasilania, podczas uruchamiania SQL odczytuje plik ldf i ponownie stosuje (REDO) te zmiany.

Ponadto, jeśli masz transakcję, która nie została zatwierdzona, a serwer ulega awarii, wszystkie zmiany dokonane przez tę transakcję muszą zostać cofnięte, aby baza danych była spójna. Plik ldf ma również to zadanie. (COFNIJ)

Wspomniałem powyżej, że plik ldf jest okrągły. Wykonanie kopii zapasowej dziennika transakcji (.trn) powoduje skopiowanie części pliku ldf. Po bezpiecznym utworzeniu pliku trn, sql może ponownie użyć tej części pliku ldf. Seria kopii zapasowych trn tworzy łańcuch, który razem rejestruje każdą modyfikację dokonaną w bazie danych. Oczywiście, jeśli nigdy nie zrobiłeś kopii zapasowej dziennika transakcji, plik ldf będzie się powiększał i powiększał.

W przypadku awarii przywrócenie pełnej kopii zapasowej powoduje otrzymanie kopii bazy danych w momencie ukończenia pełnej kopii zapasowej. Następnie możesz przywrócić pliki trn w kolejności i doprowadzić bazę danych do dowolnego punktu w czasie, w tym do ostatniej kopii zapasowej trn.

Przeglądam kilka ważnych szczegółów, ale najważniejsze jest to, że ldf jest działającym plikiem, który rejestruje ostatnie zmiany w bazie danych. Pliki trn to kopie części ldf wykonane przy założeniu, że będziesz je wtedy chronić, aby sql mógł ponownie wykorzystać przestrzeń w ldf, a jeśli dojdzie do katastrofy, będziesz mieć je w innej lokalizacji.