Za pomocą polecenia BACKUP LOG w MS SQL Server można
A. przeczytać komunikaty wygenerowane podczas tworzenia kopii.
B. wykonać kopię bezpieczeństwa dziennika transakcyjnego.
C. wykonać pełną kopię bezpieczeństwa.
D. zalogować się do kopii bezpieczeństwa.
Pytanie z egzaminu CKE, styczeń 2016 (arkusz E.14-X-16.01).
Polecenie BACKUP LOG w MS SQL Server służy do wykonania kopii bezpieczeństwa dziennika transakcyjnego, czyli transaction log backup. To jest ważny element strategii backupu dla baz pracujących zwykle w modelu odzyskiwania FULL albo BULK_LOGGED. Dziennik transakcyjny zapisuje informacje o operacjach wykonanych w bazie, np. INSERT, UPDATE, DELETE, zmiany struktury tabel czy zatwierdzanie transakcji. Dzięki kopiom dziennika można odtworzyć bazę nie tylko do ostatniej pełnej kopii, ale często do konkretnego punktu w czasie, np. tuż przed przypadkowym usunięciem danych. W praktyce wygląda to tak, że administrator robi okresowo BACKUP DATABASE, a pomiędzy pełnymi kopiami wykonuje BACKUP LOG, czasem co kilka lub kilkanaście minut, zależnie od wymagań firmy. Moim zdaniem to jedna z tych komend, które dobrze pokazują różnicę między zwykłym backupem a sensowną polityką odtwarzania danych. Dobra praktyka branżowa mówi, żeby regularnie testować także RESTORE, bo sama kopia zapasowa bez sprawdzenia może dawać tylko złudne poczucie bezpieczeństwa. BACKUP LOG pomaga też kontrolować rozmiar pliku dziennika, bo po poprawnym backupie logu SQL Server może oznaczyć część wpisów jako możliwą do ponownego użycia, oczywiście zależnie od stanu bazy i transakcji.
W tym pytaniu łatwo pomylić znaczenie słowa LOG, bo w języku potocznym kojarzy się ono z logowaniem użytkownika albo z komunikatami systemowymi. W MS SQL Server polecenie BACKUP LOG nie służy jednak do zalogowania się do kopii bezpieczeństwa. Uwierzytelnianie i dostęp do serwera realizuje się przez mechanizmy logowania SQL Server Authentication albo Windows Authentication, a nie przez instrukcję backupu. Backup to operacja administracyjna wykonywana przez użytkownika z odpowiednimi uprawnieniami, np. członka roli sysadmin, db_owner albo db_backupoperator, zależnie od konfiguracji. Również czytanie komunikatów powstałych podczas tworzenia kopii nie jest zadaniem BACKUP LOG. Komunikaty o przebiegu operacji można zobaczyć w wynikach zapytania, w SQL Server Management Studio, w historii zadań SQL Server Agent czy w logach serwera, ale sama komenda wykonuje operację archiwizacji dziennika transakcyjnego. Częsty błąd polega na traktowaniu słowa log jako pliku z tekstowymi komunikatami, a w bazach danych log transakcyjny to specjalna struktura potrzebna do zapewnienia spójności i odtwarzania danych. Pełną kopię bezpieczeństwa wykonuje się poleceniem BACKUP DATABASE, a nie BACKUP LOG. Pełny backup zapisuje stan całej bazy w danym momencie, natomiast backup dziennika transakcyjnego zapisuje zmiany od poprzedniej kopii logu. W dobrze zaprojektowanej strategii kopii zapasowych te mechanizmy się uzupełniają: pełna kopia daje bazę startową do przywracania, a kolejne kopie logu pozwalają dojść do nowszego stanu. Z mojego doświadczenia warto zapamiętać prostą zasadę: DATABASE oznacza kopię bazy, LOG oznacza kopię dziennika transakcyjnego. Niby proste, ale na egzaminach i w pracy administracyjnej takie rozróżnienie jest naprawdę istotne.