SQL Server (2005/2008): Czy pełna kopia zapasowa obcina dziennik w trybie pełnego odzyskiwania

Właśnie przeczytałem wiele dokumentacji MSDN i myślę, że rozumiem różne modele odzyskiwania i koncepcję łańcucha kopii zapasowych. Nadal mam jedno pytanie:

Czy pełna kopia zapasowa bazy danych obcina dziennik transakcji (używając trybu pełnego odzyskiwania)?

• Jeśli tak: gdzie to jest wymienione w MSDN? Wszystko, co mogłem znaleźć, to to, że tylko KOPIA ZAPASOWA skraca dziennik.

• Jeśli nie: dlaczego? Skoro pełna kopia zapasowa bazy danych rozpoczyna nowy łańcuch kopii zapasowej, po co utrzymywać transakcje, które zostały sfinalizowane, zanim pełna kopia zapasowa była aktywna w dzienniku?

Nie - zdecydowanie nie. Tylko rzeczą, która pozwala dziennika do jasnego / obciąć modeli odzyskiwania Pełny lub BULK_LOGGED jest kopia zapasowa dziennika - nie ma wyjątków. Jakiś czas temu miałem ten argument i opublikowałem długi i szczegółowy post na blogu z wyjaśnieniem i skryptem, którego możesz użyć, aby udowodnić to sobie na błędnych wyobrażeniach wokół kopii dzienników i dzienników: jak się przekonać .

Zachęcamy do dalszych pytań. Btw - zobacz także długi artykuł, który napisałem dla TechNet Magazine na temat zrozumienia rejestrowania i odzyskiwania w SQL Server .

Dzięki

Pełna kopia zapasowa NIE obcina dziennika, należy wykonać operację tworzenia kopii zapasowej dziennika. Pełna kopia zapasowa NIE resetuje łańcucha dziennika - to całkowicie zepsułoby replikację / wysyłkę dziennika itp.

Trzeba dokładnie przyjrzeć się, w jaki sposób SQL Server tworzy kopie zapasowe, ale wiedzieć, że transakcje w locie / długo działające nie są uwzględniane w kopii zapasowej (w przeciwnym razie kopia zapasowa może nigdy nie zostać ukończona), więc nie można powiedzieć, że pełna kopia zapasowa online-baza danych gwarantuje, że następna kopia zapasowa dziennika stanie się nieaktualna.

http://msdn.microsoft.com/en-us/library/ms175477.aspx

Z mojego zrozumienia jedyną rzeczą, która skraca dziennik transakcji, jest kopia zapasowa dziennika .

Pełna kopia zapasowa kopiuje tylko wystarczającą ilość dziennika, aby był spójny transakcyjnie, ponieważ operacja tworzenia kopii zapasowej zajmuje trochę czasu iw tym czasie skopiowane strony mogły ulec zmianie.

Nadal potrzebujesz kopii zapasowych dziennika w celu odzyskania punktu w czasie.

Nie mam MSDN do połączenia, ale mogę połączyć cię z blogiem Paula Randala , który był programistą w zespole SQL Server, napisał DBCC CHECKDB i części Books Online.

Odpowiada również na pytania na tym forum, więc byłby to jeszcze lepszy autorytet niż informacje z drugiej / trzeciej ręki ode mnie :)

Ludzie często mają błędne przekonanie na temat pełnej kopii zapasowej i kopii zapasowych dziennika. Aby kopia zapasowa działała w FULLmodelu odzyskiwania kopii zapasowej, należy użyć dzienników T, ponieważ podczas tworzenia kopii zapasowych mogą nadal zachodzić transakcje w bazie danych (chyba że wykonasz tak zwaną COLDkopię zapasową po zamknięciu bazy danych). Oracle stosuje tę samą koncepcję, gdy baza danych jest w ARCHIVELOGtrybie. Sekwencja tworzenia kopii zapasowej sprowadza się do tego:

1. Rozpocznij tworzenie kopii zapasowej - wstrzymaj wszystkie działania w prawdziwych plikach i zapisz w dziennikach t-log.
2. Wykonaj kopię zapasową - wszystkie transakcje są kontynuowane, ale nie są zapisywane w prawdziwych plikach, są zapisywane w dziennikach t
3. End backup - wznów zapisywanie transakcji z bazy danych do prawdziwych plików.
4. Jeśli to konieczne, spuść zawartość dzienników T do prawdziwych plików.

To jest powód, dla którego t-logi nie są domyślnie obcinane / zmniejszane, ponieważ są istotną częścią kontynuacji transakcji podczas fazy tworzenia kopii zapasowej.

Nie należy mylić przycinania kłody ze zmniejszaniem kłody.

• TRUNCATE polega na usunięciu transakcji z dziennika, które znajdują się przed ostatnim punktem kontrolnym (punktem kontrolnym jest to, kiedy transakcje są opróżniane do samej bazy danych). Odbywa się to za pomocą polecenia BACKUP.

• Aby SHRINK dziennik miał zmniejszyć rzeczywisty rozmiar pliku dziennika. Odbywa się to za pomocą poleceń DBCC.

Zasadniczo nie trzeba automatycznie zmniejszać dziennika transakcji za każdym razem, ponieważ dzienniki transakcji potrzebują miejsca do pracy, a jeśli zostaną obcięte automatycznie, pozostaną one prawie tego samego rozmiaru.