W MS SQL Server polecenie RESTORE DATABASE służy do
A. usunięcia bazy danych z serwera centralnego subskrybenta.
B. odtworzenia bazy danych z kopii bezpieczeństwa.
C. przebudowania bazy danych w oparciu o buforowane dane.
D. odświeżenia bazy danych z kontrolą więzów integralności.
Pytanie z egzaminu CKE, wrzesień 2015 (arkusz E.14-X-15.08).
Polecenie RESTORE DATABASE w MS SQL Server służy do przywracania, czyli odtworzenia bazy danych z kopii bezpieczeństwa. To jest typowa czynność administracyjna wykonywana po awarii dysku, uszkodzeniu plików MDF/LDF, błędnym usunięciu danych albo podczas przenoszenia bazy na inny serwer, np. ze środowiska produkcyjnego na testowe. W praktyce używa się go razem z plikami backupu tworzonymi poleceniem BACKUP DATABASE, najczęściej z rozszerzeniem .bak. Przykładowy scenariusz: administrator robi pełną kopię bazy sklepu internetowego, a po awarii wykonuje RESTORE DATABASE Sklep FROM DISK = 'D:\backup\sklep.bak'. Moim zdaniem to jedna z tych komend, które trzeba kojarzyć nie tylko z teorii, ale też z normalnej pracy admina. Dobra praktyka mówi, żeby regularnie testować odtwarzanie kopii, bo backup, którego nigdy nie sprawdzono, może być niemiłą niespodzianką. W SQL Server można też używać opcji takich jak WITH RECOVERY, WITH NORECOVERY, MOVE czy REPLACE, zależnie od tego, czy przywracamy pełną kopię, kopie różnicowe albo logi transakcyjne. Ważne jest też planowanie RPO i RTO, czyli ile danych możemy maksymalnie stracić i jak szybko baza ma wrócić do działania.
W tym pytaniu łatwo pomylić kilka pojęć administracyjnych, bo wszystkie brzmią trochę jak prace porządkowe przy bazie danych. RESTORE DATABASE nie oznacza jednak przebudowania bazy na podstawie buforowanych danych. Bufor w SQL Server, czyli pamięć podręczna stron danych i planów zapytań, służy do przyspieszania działania serwera, a nie do trwałego odtwarzania całej bazy po awarii. Dane w buforze mogą zniknąć po restarcie usługi, więc nie są traktowane jako bezpieczne źródło odzyskiwania. Do naprawy struktur, indeksów czy kontroli spójności służą inne mechanizmy, na przykład DBCC CHECKDB, ALTER INDEX REBUILD albo procedury konserwacyjne. Usunięcie bazy z serwera to także zupełnie inna operacja, bliższa poleceniu DROP DATABASE, ewentualnie zagadnieniom replikacji, jeśli mówimy o subskrybentach i publikatorach. RESTORE nie kasuje bazy po prostu z centralnego serwera, choć przy opcji REPLACE może nadpisać istniejącą bazę przy przywracaniu backupu, i tu trzeba uważać. Odświeżanie bazy z kontrolą więzów integralności też nie jest właściwym opisem tej komendy. Więzy integralności, klucze obce, ograniczenia CHECK czy spójność logiczna danych są sprawdzane i egzekwowane przez silnik bazy podczas operacji na danych albo przez narzędzia diagnostyczne. Typowy błąd myślowy polega na tym, że słowo restore kojarzy się ogólnie z naprawą albo odświeżeniem. W SQL Server ma ono bardziej konkretne znaczenie: przywrócenie bazy, plików lub logów transakcyjnych z wcześniej wykonanej kopii zapasowej. W praktyce bez poprawnej strategii backupu samo polecenie RESTORE DATABASE nie pomoże, bo musi mieć z czego odtwarzać dane.