Rozdział 8.
Odtwarzanie baz danych

Poprzedni rozdział omawiał tworzenie kopii bezpieczeństwa baz SQL Servera. Został omówiony sposób zastosowania odporności na błędy (w formie sprzętowej i programowej — oprogramowanie Windows 2000), pozwalającej uniknąć korzystania z kopii bezpieczeństwa. Omówione zostały również typy kopii bezpieczeństwa dostępne w SQL Serverze 2000, włączając w to pełne kopie bazy danych, kopie różnicowe i kopie dziennika transakcji. W poprzednim rozdziale przedstawiono również implementację kopii bezpieczeństwa przy pomocy języka Transact-SQL i SQL Server Enterprise Managera.

Niniejszy rozdział omawia jeden z najistotniejszych aspektów obsługi relacyjnych baz danych: odzyskiwanie. Nie ma znaczenia jak dużo pracy włoży się w zabezpieczenie bazy danych i ułatwienie dostępu do danych, ochrona danych przed ich utratą jest najważniejszym celem pracy administratora. Jeżeli serwer ulegnie awarii i wszystkie dane zostaną utracone — jest wielce prawdopodobne, że administrator może utracić coś jeszcze — własną pracę. Niniejszy rozdział omawia proces odtwarzania oraz typy scenariuszy odtwarzania obsługiwane przez SQL Server. Na początku zostaną przedstawione mechanizmy odzyskiwania używane przez SQL Server 2000, uwzględniając odzyskiwanie automatyczne i ręczne. Większa część tego rozdziału będzie dotyczyła odzyskiwania ręcznego bazy danych do spójnego punktu w czasie.

Odtwarzanie bazy danych

Kopie bezpieczeństwa nie mają wartości same w sobie. Jednak, są bardzo pożyteczne w przypadku problemów z serwerem. Jeżeli dysk przestaje działać prawidłowo lub plik bazy danych zostanie uszkodzony, zachodzi potrzeba odtworzenia baz danych, których pliki uległy uszkodzeniu.

Inną przyczyną odtwarzania bazy danych z kopii bezpieczeństwa jest odtworzenie jej do logicznie spójnego punktu w czasie. Przypuśćmy, że szef usuwa całą sprzedaż z danego dnia o piątej po południu. Można odzyskać dane z wcześniejszej pełnej kopii bezpieczeństwa bazy danych a następnie zastosować wszystkie kopie dziennika transakcji (lub kopię różnicową i kopie dziennika transakcji) aż do momentu zaraz przed tym, jak szef uruchomił polecenie usunięcia danych. Tym sposobem, można odzyskać dane minimalnym nakładem pracy.

SQL Server 2000 może odtwarzać kopie bezpieczeństwa stworzone przy pomocy SQL Servera 7.0, ale nie może korzystać z kopii utworzonych przez wcześniejsze wersje. Warto również wiedzieć, że kopie bezpieczeństwa SQL Servera 2000 nie mogą być przeczytane przez żadną wcześniejszą wersję SQL Servera, włączając w to SQL Server 7.0.

Zanim zostanie omówiony sam proces odzyskiwania, należy zapoznać się z dwoma różnymi typami odzyskiwania SQL Servera: automatycznym i ręcznym.

Odzyskiwanie automatyczne

Odzyskiwanie automatyczne jest procesem, przez który SQL Server przechodzi za każdym razem, gdy uruchamiana jest usługa SQL Server. Nie można wyłączyć tego procesu i nie potrzeba wykonywać żadnych specjalnych czynności, aby proces nastąpił — dlatego zwany jest procesem automatycznym.

Przy każdym ponownym uruchomieniu SQL Servera, stosowany jest zbiór kroków, które wykonują ponownie (roll forward) wszelkie zatwierdzone transakcje z dziennika transakcji, wykonane od czasu ostatniego punktu kontrolnego (checkpoint). Rolling forward transakcji oznacza, że wszelkie zatwierdzone transakcje bazy danych są ponownie wykonywane w tej bazie danych. SQL Server wycofuje z dziennika transakcji wszystkie transakcje, które nie zostały wcześniej zatwierdzone. Wycofanie (roll back) oznacza, że wszelkie częściowo wykonane — ale nie zatwierdzone transakcje — są usuwane z bazy danych. Po zakończeniu procesu automatycznego odzyskiwania, każda baza danych jest pozostawiana w formie logicznie spójnej i ustawiany jest punkt kontrolny. Transakcje zostaną omówione później, w rozdziale 12.

Proces odzyskiwania automatycznego gwarantuje, że bez względu na to, jak i dlaczego SQL Server został zatrzymany, zostanie on uruchomiony w stanie logicznie spójnym. Nawet jeśli serwer uległ nagłej awarii, można bez problemów odtworzyć dane. Strony dziennika dla wszystkich zatwierdzonych transakcji są zapisywane na dysk natychmiast (zapis synchroniczny). Dlatego, wszelkie trwałe zmiany w bazie danych są z powodzeniem kopiowane na dysk i używane podczas procesu odtwarzania.

Odzyskiwanie automatyczne każdej z baz danych jest wykonywane w określonej kolejności. Pierwszą czynnością jest zlokalizowanie plików bazy danych master (master.mdf i mastlog.ldf), szukając informacji o położeniu tych plików bazy danych w Rejestrze Windows. Informację tę można znaleźć w kluczu rejestru HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer\Parameters dla instancji domyślnej lub w kluczu HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\INSTANCENAME\MSSQLServer\Parameters w przypadku instancji nazwanej (nazwę instancji należy wpisać w miejsce INSTANCENAME). Jest to miejsce, w którym SQL Server szuka plików bazy danych master. Na rysunku 8.1 pokazano przykładowy klucz rejestru (Windows 2000). Położenie tej informacji w rejestrze jest takie samo na wszystkich platformach Windows.

Rysunek 8.1. Klucze rejestru do uruchomienia usługi SQL Servera.

Po zlokalizowaniu plików bazy danych master, SQL Server ładuje i odtwarza tę bazę danych. Baza danych master musi zostać załadowana i odzyskana jako pierwsza, ponieważ zawiera odniesienia do podstawowego pliku danych (pliku .mdf) dla pozostałych baz danych w tabeli systemowej sysdatabases, w kolumnie filename. Po odzyskaniu bazy danych master, SQL Server może rozpocząć proces lokalizacji, otwierania i odtwarzania pozostałych baz danych. Każda baza danych śledzi, jakie pliki są z nią skojarzone, przechowując tę informację w tabelach systemowych sysfiles i sysfilegroups.

Zanim SQL Server będzie mógł odtworzyć pozostałe bazy danych musi najpierw odtworzyć bazę model. Dla przypomnienia — baza danych model jest bazą-szablonem. Baza ta musi zostać odtworzona zanim nastąpi kontynuacja ponieważ kolejnym krokiem jest utworzenie bazy danych tempdb. Baza danych tempdb jest potrzebna do wykonywania różnorodnych zapytań lub procedur składowych w SQL Serverze. Baza danych tempdb jest tworzona od nowa przy każdym uruchomieniu SQL Servera. SQL Server tworzy bazę danych poprzez utworzenie kopii bazy model a następnie rozszerzenie jej do pożądanego rozmiaru, jaki został wcześniej określony.

Następnie odtwarzana jest baza danych MSDB jako kolejna baza dystrybucyjna (jeśli istnieje), następnie baza danych pubs i Northwind a na końcu bazy danych użytkownika (te, o które troszczy się użytkownik najbardziej).

Można prześledzić cały proces odtwarzania przeglądając dziennik błędów (Error Log) SQL Servera:

1. Należy uruchomić SQL Server Enterprise Manager, jeżeli nie jest otwarty, połączyć się do odpowiedniego serwera, rozwinąć folder Management i rozwinąć opcję SQL Server Logs. Ukaże się lista zawierająca bieżący dziennik błędów i na ogół także ostatnie sześć dzienników błędów.

2. Należy podświetlić dziennik błędów, który ma być przeglądany. Dziennik pojawi się w prawym panelu SQL Server Enterprise Managera (zobacz rysunek 8.2).

Można również przeglądać te pliki bezpośrednio przy pomocy edytora takiego jak Notatnik. Pliki te można znaleźć w katalogu \mssql\log, posiadają nazwy errorlog.*, gdzie * jest numerem kopii bezpieczeństwa. Nazwą bieżącego dziennika błędów jest errorlog. (z kropką, ale bez rozszerzenia). Poprzednie dzienniki błędów noszą nazwy odpowiednio errorlog.1, errorlog.2 itd.

3. Należy rozpocząć od znalezienia wpisu Starting Up Database Master.

Dziennik błędów pokazany na rysunku 8.2 informuje, że baza danych master została otworzona (pliki są otwarte przez SQL Server) a następnie odzyskana do odpowiedniego logicznego punktu spójności.

Następnie otwierana i odtwarzana jest baza danych model; potem kolejno odtwarzane są — baza danych MSDB i bazy stworzone przez użytkownika (włączając w to bazę pubs i Northwind). Następnie czyszczona i uruchamiana jest baza tempdb (kopiowana z bazy model). Wiadomo, że odzyskiwanie zakończyło się pomyślnie jeżeli w dzienniku błędów pojawi się wpis Recovery Complete (podświetlony na rysunku 8.2).

Rysunek 8.2. Widok Dziennika błędów w oknie Enterprise Managera.

Konfiguracja odzyskiwania automatycznego

Istotną rzeczą jaką należy wykonać, aby skonfigurować automatyczne odzyskiwanie jest konfiguracja opcji Recovery Internal. Opcja ta określa maksymalną ilość czasu, jaką SQL Server poświęci na automatyczne odzyskiwanie każdej z baz danych. Wartością domyślną jest 0, oznacza to, że SQL Server będzie automatycznie decydował jak często wstawiać punkt kontrolny.

Parametr konfiguracyjny Recovery Internal wpływa na to, jak często pojawiają się punkty kontrolne. Punkt kontrolny (checkpoint) jest procesem, który wykonuje kopiowanie na dyski stron danych i wpisów dziennika, które były modyfikowane w pamięci. Jeżeli punkt kontrolny jest ukończony, transakcje zatwierdzone przed punktem kontrolnym nie będą już później automatycznie odtwarzane.

Parametr Recovery Interval można skonfigurować przy pomocy procedury systemowej sp_configure. Przykładowo, aby zmienić czas odtwarzania do trzech minut należy uruchomić następujący kod Transact-SQL:

Exec sp_configure 'Recovery Interval',3

Go

Reconfigure with Override

Go

Nie należy zmieniać domyślnego ustawienia Recovery Interval konfiguracji automatycznej. Zmiana tego parametru może grozić spadkiem wydajności z powodu zbyt wielu punktów kontrolnych.

Recovery Interval nie pomaga w przypadku długo trwających transakcji. Załóżmy, że istnieje proces systemowy, który rozpoczyna transakcję a następnie rozpoczyna uruchamianie serii uaktualnień, trwających godzinami, a w pewnym momencie serwer ulega awarii. Jeżeli nie ma wystarczającej ilości pamięci aby przechować w niej wszystkie zmiany i niektóre ze zmian zostają zapisane na dysk, zachodzi potrzeba wycofania tych zmian z bazy danych. Jeżeli wcześniej Recovery Interval został ustawiony na trzy minuty (jak w powyższym kodzie źródłowym), odzyskiwanie bazy danych będzie zapewne trwało dłużej niż trzy minuty. Aby uniknąć tego problemu, należy tworzyć niewielkie transakcje, tak aby było możliwe szybkie odzyskanie poprawnego stanu w przypadku wystąpienia problemów.

Odzyskiwanie ręczne

Odzyskiwanie ręczne — temat kolejnej części tego rozdziału — jest procesem odzyskiwania bazy danych. Proces ten może zawierać odzyskiwanie z pełnej kopii bazy danych, możliwe jest również odzyskiwanie z kopii różnicowej oraz odtwarzanie kopii jednego lub więcej dzienników transakcji z nośników archiwizujących. Szczegóły procesu odtwarzania różnią się w zależności od przyczyn odzyskiwania.

Można odtworzyć bazę danych a następnie zastosować dzienniki transakcji dla pełnego odtworzenia utraconej bazy danych lub odtwarzać do punktu w czasie aby cofnąć zmiany wprowadzone w bazie danych. Można odtworzyć bazę nawet do określonej (zwanej marked transaction) transakcji. Można również użyć różnicowych kopii bazy danych (jeżeli zostały wykonane) co pozwoli na odtworzenie mniejszej ilości dzienników transakcji. SQL Server 2000 posiada nawet opcje do odtwarzania zbioru grup plików (aby przeprowadzić częściowe odtwarzania).

Odtwarzanie bazy danych z kopii bezpieczeństwa ma następujące ograniczenia:

• Baza danych nie może być używana. Baza danych jest używana jeżeli ktokolwiek zastosował polecenie USE i wskazał tę bazę danych lub jest uruchomione dowolne zapytanie dotyczące tej bazy.

• Należy posiadać odpowiednie uprawnienia. Bazę danych mogą odtwarzać jedynie użytkownicy należący do roli serwera sysadmin lub dbcreator lub użytkownik dbo. Prawo do wykonywania tego procesu nie może być przekazywane dalej (grant). Prawo do odtwarzania bazy danych jest bardzo istotnym i odpowiedzialnym uprawnieniem.

• Dzienniki transakcji muszą być odtwarzane w kolejności, w jakiej były tworzone. Każdy dziennik transakcji ma skojarzony ze sobą kolejny numer. Należy odtwarzać kopie dziennika transakcji w prawidłowej kolejności. Nie przestrzeganie tego może zakończyć się nieudanym odtworzeniem bazy. Przed przystąpieniem do odtwarzania kopii dziennika transakcji zostanie przedstawionych wiele rozważań dotyczących warunków odtwarzania.

Jeżeli odtwarzanie następuje z powodu uszkodzenia dysku sztywnego, należy najpierw zamienić uszkodzony dysk (włączając w to ponowne utworzenie odbicia lustrzanego lub innych konfiguracji RAID) a następnie usunąć wszelkie uszkodzone bazy danych. Następnie można odzyskać bazy danych lub ustawić ponowne utworzenie baz danych jako część procesu odtwarzania.

Jeżeli proces odtwarzania zostanie przeprowadzony na istniejącej bazie danych, domyślnie w wyniku nastąpi nadpisanie istniejącej zawartości bazy danymi z kopii bezpieczeństwa (kilka ważnych zagadnień z tym związanych zostanie omówionych później).

Odtwarzanie z plików (ponowne łączenie bazy danych w całość)

Przed omówieniem procesów odtwarzania należy rozważyć jedną z możliwych opcji odtwarzania. Można ponownie połączyć bazę danych w całość jeżeli posiada się kopie wszystkich skojarzonych z nią plików danych. SQL Server 2000 może rozdzielić a następnie połączyć ponownie bazy danych przy pomocy procedur składowych Transact-SQL oraz opcji CREATE DATABASE z opcją FOR_ATTACH.

Na początek zostanie omówiona opcja CREATE DATABASE. Poniższy przykładowy kod źródłowy pokazuje tworzenie bazy danych, posiadającej dwa pliki, test_data.mdf oraz test_log.ldf:

create database test

on (filename = 'd:\program files\Microsoft SQL Server\mssql\data\test_data.mdf')

log on (filename = 'd:\program files\Microsoft SQL Server\mssql\data\test_log.ldf')

Kod ten powinien zwrócić komunikat:

Succesfully attached database 'test'.

Warto zauważyć, że jedyne, co należy podać, to nazwa pliku. Kiedy SQL Server znajdzie pliki, może zbudować wszystkie inne informacje jakich potrzebuje, przy pomocy tabel systemowych SQL Servera przechowywanych w bazie danych.

Można również skorzystać z procedury systemowej sp_attach_db. Można wypróbować procedurę poprzez stworzenie na początek bazy danych test (jak w przykładzie) a następnie uruchomienie procedury systemowej sp_detach_db:

Exec sp_detach_db 'test'

Go

Kod ten powinien zwrócić komunikat:

Succesfully detached database 'test'.

DBCC execution completed. If DBCC printed error messages,

contact your system administrator.

Procedura ta „oddziela” bazę danych test od serwera. Można następnie wysłać pliki dowolnej osobie, a odbiorca może uruchomić następujący kod źródłowy (lub można to zrobić własnoręcznie):

EXEC sp_attach_db @dbname = 'test',

@filename1 = 'd:\program files\Microsoft SQL Server\mssql\data\test.mdf',

@filename2 = 'd:\program files\Microsoft SQL Server\mssql\data\test_log.ldf'

Warto zauważyć, że systemowa procedura składowa sp_attach_db zasadniczo wykonuje polecenie CREATE DATABASE FOR ATTACH. Nie ma żadnej różnicy w funkcjonalności tych dwóch opcji (create database i sp_attach_db). Również, warto zauważyć, że w przypadku polecenia

create database test

baza danych jest tworzona z nazwami plików pokazanymi w przykładzie. Jeżeli używane są inne nazwy plików, należy wykonać odpowiednie zmiany w ścieżce do plików w wywołaniu procedury sp_attach_db.

Rozłączanie baz danych nie jest najlepszą zasadą tworzenia kopii i odtwarzania. Jest to łatwy sposób na zmienianie położenia bazy danych. W strategii wykonywania kopii należy tworzyć pełne kopie bazy danych, kopie różnicowe i kopie dziennika transakcji jak opisano w rozdziale 7. Jak zostanie pokazane później, można silnie ograniczyć opcje odtwarzania nie używając wbudowanych mechanizmów SQL Servera do tworzenia i odzyskiwania z kopii bezpieczeństwa.

Znalezienie poprawnego zestawu kopii bezpieczeństwa

Pierwszym krokiem jest znalezienie poprawnego zestawu kopii bezpieczeństwa. Można postępować w tym przypadku na dwa sposoby: trudny i łatwy. Powinno się zacząć (jak zwykle) od sposobu trudnego, ponieważ można nauczyć się w ten sposób jakie operacje są wykonywane. Można skorzystać z poniższych trzech poleceń Transact - SQL aby zorientować się (w różnym stopniu szczegółowości) co znajduje się na poszczególnych urządzeniach archiwizacyjnych:

• RESTORE LABELONLY dostarcza informacji w postaci pojedynczego wiersza na temat całego zbioru kopii bezpieczeństwa.

• RESTORE HEADONLY dostarcza podsumowania informacji na temat każdego elementu w zestawie kopii bezpieczeństwa.

• RESTORE FILELISTONLY dostarcza listę baz danych i dzienników zarchiwizowanych na określonym urządzeniu archiwizacyjnym.

RESTORE LABELONLY Jeżeli zostanie uruchomione polecenie RESTORE LABELONLY, nagłówek napędu urządzenia archiwizacyjnego (na ogół polecenie to używane jest w odniesieniu do taśm) jest czytany i podsumowywany w postaci pojedynczego wiersza. Wiersz zawiera nazwę nośnika, określonego podczas tworzenia kopii bezpieczeństwa, opis podany podczas tworzenie kopii bazy danych i datę ostatniej kopii bezpieczeństwa na tym urządzeniu archiwizacyjnym. Zwracane są również inne informacje, ale dopóki nie tworzy się zaawansowanej strategii archiwizacji, nie ma potrzeby zgłębiania szczegółów tych informacji.

RESTORE LABELONLY FROM backup_device

[WITH {NOUNLOAD | UNLOAD } ] [[,] MEDIAPASSWORD = {mediapwd | @mediapwd_var}]

Składnia:

• backup_device jest nazwą nośnika archiwizującego lub nazwą zmiennej dla tego nośnika archiwizującego. Można określić tutaj w razie potrzeby nazwę pliku, taśmy lub Named Pipe, które mają być używane do odtwarzania bazy (można określić ten parametr jako zmienną). W poprzednim rozdziale w opisie składni polecenia BACKUP można znaleźć szczegółowy opis, co może występować w miejscu backup_device.

• NOUNLOAD | UNLOAD określa czy taśma zostanie wyjęta gdy zakończy się proces RESTORE LABELONLY.

• MEDIAPASSWORD jest używany, gdy tworzy się kopię bezpieczeństwa (jeżeli jest w ogóle używany). Jeżeli hasło nie jest znane, a nośnik z kopią bezpieczeństwa jest zabezpieczony hasłem, nie można uruchomić tego polecenia. Posiadanie hasła na indywidualne kopie bezpieczeństwa nie chroni przed wykonaniem polecenia RESTORE LABELONLY; jedynie hasła na cały nośnik chronią przed udanym wykonaniem polecenia dopóki nie zostanie podane prawidłowe hasło.

RESTORE HEADERONLY Polecenie RESTORE HEADERONLY pobiera informację o każdej z kopii bezpieczeństwa znajdują się na nośniku archiwizacyjnym. Polecenie zwraca jeden wiersz dla każdej kopii jaka istnieje dla danej bazy ponieważ, inaczej niż polecenie RESTORE LABELONLY, polecenie RESTORE HEADERONLY czyta pojedynczo informacje z każdej zarchiwizowanej. Proces ten może zabierać dużo czasu jeżeli na taśmie znajduje się kilka kopii bezpieczeństwa. Dla plików kopii bezpieczeństwa na dysku proces ten działa na ogół bardzo szybko.

RESTORE HEADERONLY FROM backup_device

[WITH {NOUNLOAD | UNLOAD } ] [[,] FILE = file_num]

[[,] PASSWORD = { pwd | @pwd_var}]

[[,] MEDIAPASSWORD = {mediapwd | @mediapwd_var}]

Składnia ta używa tych samych opcji co RESTORE LABELONLY, z wyjątkiem przedstawionych poniżej:

• FILE określa, który zestaw kopii bezpieczeństwa z taśmy ma być testowany. Przykładowo, jeżeli taśma zawiera dwa zestawy kopii bezpieczeństwa, można określić ten parametr jako 1 (pierwszy zbiór) lub jako 2 (drugi zbiór).

• PASSWORD jest hasłem, podawanym podczas tworzenia kopii bezpieczeństwa.

Wyniki tego polecenia zawierają nazwy kopii bezpieczeństwa (oraz opis) oraz datę ważności danego zestawu. Zawierają również informacje o tym, kto tworzył kopię bezpieczeństwa, z jakiego serwera ona pochodzi, jakie dane zostały zarchiwizowane, jak duża jest kopia bezpieczeństwa oraz kiedy rozpoczęło się i zakończyło tworzenie tej kopii. Wyniki uwzględniają również stronę kodową i kolejność sortowania (używaną w SQL Server 7.0), sposób kodowania (collation —odpowiednik w SQL Server 2000 kolejności sortowania/strony kodowej/Unicode LocalID), tryb zgodności bazy danych i wersję SQL Servera użytą do wykonania kopii bezpieczeństwa. Można uzyskać również wewnętrzną informację o sekwencyjnych numerach dzienników (zakres tej książki nie obejmuje tego tematu).

RESTORE FILELISTONLY Polecenie RESTORE FILELISTONLY zwraca listę plików bazy danych i dziennika, które zostały zarchiwizowane na określonym nośniku archiwizacyjnym. Jednocześnie można uzyskać informację tylko na temat jednej kopii, dlatego w przypadku, gdy nośnik archiwizacyjny zawiera wiele kopii bezpieczeństwa, należy określić, o którą kopię chodzi.

Informacja ta jest szczególnie przydatna w sytuacji odzyskiwania po awarii. Jeżeli baza danych ma być odtworzona a nie jest znane poprzednie położenie plików, można je odnaleźć przy pomocy polecenia RESTORE FILEONLY:

RESTORE FILEONLY FROM backup_device

[WITH {NOUNLOAD | UNLOAD } ] [[,] FILE = file_num]

[[,] PASSWORD = { pwd | @pwd_var}]

[[,] MEDIAPASSWORD = {mediapwd | @mediapwd_var}]

Składnia jest taka sama jak składnia polecenia RESTORE HEADERONLY.

Jeżeli nie jest znany numer pliku, jaki ma być odnaleziony, należy uruchomić polecenie RESTORE HEADERONLY aby uzyskać listę numerów plików oraz informację, do której kopii bezpieczeństwa należy każdy z plików. Jeżeli nie zostanie określony parametr FILE, polecenie dotyczy pierwszej kopii bezpieczeństwa.

Sprawdzenie użyteczności zestawu kopii bezpieczeństwa

Można przyjąć, że zostały uruchomione odpowiednie procedury sprawdzające DBCC, zanim została stworzona kopia bazy danych. Można również przyjąć, że przy tworzeniu kopii skorzystano z zalet dostępnej opcji Verify. Czy to jednak oznacza, że kopia bezpieczeństwa jest gotowa do odtwarzania?

Odpowiedź "tak", nie do końca odzwierciedla prawdę. Firma Microsoft również ma tą świadomość o czym świadczy polecenie RESTORE VERIFYONLY. Polecenie to sprawdza czy wszystkie taśmy lub pliki dyskowe są dostępne do odtwarzania, i że wszystkie niezbędne informacje mogą być odczytane. Nie jest uruchamiane sprawdzanie DBCC kopii bezpieczeństwa; jest jedynie sprawdzane, czy taśma lub plik dyskowy mogą być odczytane.

RESTORE VERIFYONLY FROM backup_device [,...n]

[WITH [FILE = filen_um] [[,] {NOUNLOAD | UNLOAD } ]

[[,]LOADHISTORY ] [[,] { NOREWIND | REWIND } ]

[[,] PASSWORD = { pwd | @pwd_var}]

[[,] MEDIAPASSWORD = {mediapwd | @mediapwd_var}]

Składnia tego polecenie jest podobna do omówionych wcześniej, z wyjątkiem poniższych parametrów:

• LOADHISTORY określa czy informacja na temat sprawdzanej kopii bezpieczeństwa zostanie dodana do tabel z historią kopii w bazie danych MSDB. Tabele te zostaną krótko omówione później.

• NOREWIND | REWIND określa czy taśma powinna być przewinięta po wykonaniu polecenia RESTORE VERIFYONLY.

Tabele historii kopii bezpieczeństwa w bazie MSDB

Zanim nastąpi omówienie kolejnych poleceń odtwarzania przedstawione zostaną tabele systemowe związane z kopiami bezpieczeństwa. Za każdym razem, przy wykonywaniu kopii bezpieczeństwa baz SQL Servera, szczegóły kopii są umieszczane w bazie danych MSDB w następujących tabelach systemowych:

• Backupfile zawiera informacje na temat plików kopii.

• BackupMediaFamily zawiera informacje na temat grupy nośników. Krótkie wprowadzenie do tematu zestawu nośników zostało przedstawione w poprzednim rozdziale. Należy pamiętać, że są one na ogół używane dla równolegle paskowanych kopii bezpieczeństwa.

• BackupMediaSet zawiera informacje na temat zestawów nośników. Zestawy nośników są na ogół omawiane przy korzystaniu z równolegle paskowanej kopii, ale każda z kopii jest częścią zestawu nośników.

• Backupset zawiera informacje na temat każdej wykonanej kopii.

• Restorefile zawiera informacje na temat każdego odtwarzania pliku.

• Restorefilegroup zawiera informacje na temat każdego odtwarzania grupy plików.

• Restorehistory zawiera informacje o każdym uruchamianym odtwarzaniu.

Za każdym razem gdy jest tworzony nowy rodzaj kopii bezpieczeństwa lub wykonywana jest operacja odtwarzania, czynność ta jest rejestrowana w razie potrzeby w tych tabelach systemowych. Nie ma znaczenia, czy kopia bezpieczeństwa lub odtwarzanie zostało wykonane przy pomocy wyrażeń Transact-SQL lub SQL Server Enterprise Managera. Wynika z tego potrzeba częstego tworzenia kopii bazy danych MSDB, aby zachować te informacje w przypadku utraty bazy MSDB lub master.

Wykonywanie pełnego odtwarzania bazy danych

Pełne odtwarzanie bazy danych korzysta z pełnej kopii bezpieczeństwa (można traktować ją jako „normalną” kopię bezpieczeństwa) i umieszcza tę kopię na serwerze. Używa dziennika transakcji, który został zarchiwizowany wraz z kopią bazy danych, aby odtworzyć bazę, wykonać wszystkie zatwierdzone transakcje i wycofać wszelkie nie zatwierdzone transakcje do czasu zakończenia kopii bazy danych. Podobnie jak w przypadku poleceń kopii bezpieczeństwa, polecenie Transact-SQL RESTORE ma więcej funkcji niż polecenie SQL Server Enterprise Managera, a okna SQL Server Enterprise Managera są znacznie łatwiejsze do zrozumienia, gdy widoczne są polecenia uruchamiane na SQL Serverze.

Gdy baza danych jest odzyskiwana dostępnych jest kilka opcji. Można

• przesunąć pliki z miejsca, w którym znajdowały się podczas tworzenia kopii bezpieczeństwa

• ustawić opcję bazy danych RESTRICTED_USER podczas odtwarzania, w przypadku gdy nie zostało jeszcze ukończone odtwarzanie lub dostęp do bazy danych ma zostać ograniczony.

• wybrać opcję aby odtwarzać lub nie — do określonego, spójnego punktu w czasie (w zależności czy będą stosowane kopie dziennika transakcji) lub do określonej, zaznaczonej transakcji.

• tworzyć plik wstrzymany( standby). Można tworzyć tego rodzaju plik w przypadku, gdy ma być kontynuowane stosowanie kopii dziennika transakcji ale ma być przetestowany stan bazy danych w trybie „tylko-do-odczytu” pomiędzy odtwarzaniami z tych kopii. Sytuacja ta zostanie krótko omówiona.

• ponownie uruchomić odtwarzanie, które zostało przerwane w danym punkcie (przykładowo — w przypadku awarii zasilania, która nastąpiła podczas operacji odtwarzania).

Wykonywanie pełnego odtwarzania bazy danych przy pomocy polecenia języka Transact-SQL RESTORE

Można korzystać z polecenia RESTORE aby odtworzyć bazę danych z pełnej kopii bezpieczeństwa. Składnia tego polecenia jest następująca:

RESTORE DATABASE databasename FROM backup_device [,...n]

[WITH [RESTRICTED_USER] [[,] FILE = file_num]

[[,] PASSWORD = { pwd | @pwd_var } ]

[[,] MEDIANAME = { media_name | @media_name_var } ]

[[,] MEDIAPASSWORD = { mediapwd | @mediapwd_var } ]

[[,] MOVE 'logical_file_name' TO 'new_file_name'] [,...n]

[[,] KEEP_REPLICATION]

[[,] {NORECOVERY | RECOVERY | STANDBY = undo_file_name}]

[[,] {NOUNLOAD | UNLOAD}] [[,] REPLACE] [[,] RESTART]

[[,] {NOREWIND | REWIND} ]

[[,] STATS [= percentage]]]

Znaczenie składni:

• databasename jest nazwą bazy danych, która ma być odtwarzana.

• backup_device jest nazwą nośnika archiwizacyjnego lub nazwą zmiennej dla nośnika archiwizacyjnego. Można również określić nazwę pliku, taśmy lub Named Pipe jaka ma zostać użyta do odtwarzania — także w postaci zmiennej.

• RESTRICTED_USER określa, że jedynie członkowie roli serwera sysadmin lub dbcreator lub roli bazy danych db_owner mogą mieć dostęp do bazy danych po wykonaniu odtwarzania.

• FILE określa, która kopia ma być odtworzona.

• PASSWORD jest hasłem, które zostało określone podczas tworzenia zestawu archiwizacyjnego.

• MEDIANAME określa, czy zachowana nazwa nośnika kopii bezpieczeństwa ma być porównywana z daną nazwą nośnika. Jeżeli nazwy do siebie nie pasują, odtwarzanie nie powiedzie się.

• MEDIAPASSWORD jest hasłem, jakie zostało podane podczas tworzenia kopii bezpieczeństwa (jeżeli zostało określone jakiekolwiek hasło). Jeżeli hasło nie jest znane, a nośnik kopii bezpieczeństwa jest zabezpieczony hasłem, nie można uruchomić tego polecenia.

• MOVE określa, że dla każdej logicznej nazwy pliku, do której wystąpi odniesienie, operacja odtwarzania powinna znaleźć logiczny plik w zestawie archiwizacyjnym i odtworzyć go do alternatywnej ścieżki i nazwy pliku, jaka została wskazana.

• KEEP_REPLICATION informuje, że konfiguracja replikacji bazy danych ma być zachowana podczas odtwarzania. Opcja ta jest dostępna do obsługi mechanizmu log shipping, zaawansowanej techniki, nie opisywanej w tej książce.

• RECOVERY oznacza, że odtwarzanie powinno wycofać wszystkie nie zakończone transakcje i przywrócić bazę danych do spójnego stanu. Po wykonaniu polecenia RECOVERY nie można odtworzyć żadnej kopii dziennika transakcji lub kopii różnicowych bazy danych. Opcja ta występuje domyślnie jeśli nie została określona żadna inna opcja odzyskiwania (NORECOVERY lub STANDBY).

• NORECOVERY informuje, że odtwarzanie nie powinno wycofywać żadnych nie zachowanych transakcji oraz, że odtwarzanie nie doprowadzi bazy do spójnego punktu. Opcji tej należy używać podczas odtwarzania bazy danych, gdy mają być zastosowane kopie dziennika transakcji lub kopie różnicowe do bazy danych po zastosowaniu pełnego odtwarzania bazy.

• STANDBY określa ścieżkę i nazwę pliku wycofania (undo file), który przetrzymuje wystarczającą ilość informacji do ponownego uruchomienia transakcji wycofanych podczas procesu odtwarzania. Należy skorzystać z polecenia STANDBY gdy zamierza się testować bazę danych (w trybie do-odczytu) pomiędzy odtwarzaniami różnicowymi lub odtwarzaniami dzienników transakcji. Jeżeli plik, który został określony nie istnieje, SQL Server stworzy wymagany plik.

• NOUNLOAD | UNLOAD określa czy taśma ma być wyjęta po zakończeniu polecenia RESTORE DATABASE.

• REPLACE oznacza, że odtwarzanie powinno zastąpić każdą bazę danych o tej samej nazwie istniejącą na danym serwerze. Normalne odtwarzanie bez tej opcji oznacza, że w przypadku gdy nazwa bazy danych różni się od nazwy zarchiwizowanej bazy danych lub gdy zbiór plików z kopii bezpieczeństwa nie pasuje do istniejącej bazy danych, odtwarzanie nie powiedzie się. Jest to opcja związana z bezpieczeństwem.

• RESTART ponownie uruchamia odtwarzanie kopii bezpieczeństwa od miejsca, w którym zostało ostatnio przerwane. Jak wspomniano wcześniej, opcja ta jest stosowana gdy następuje odtwarzanie z kopii na wielu taśmach, podczas wykorzystywania drugiej lub późniejszej taśmy.

• NOREWIND | REWIND określa, czy taśma powinna zostać przewinięta po ukończeniu polecenia RESTORE.

• STATS oznacza, że użytkownik chce otrzymać raport o postępie wykonywania operacji odtwarzania (określony procentowo). Domyślnie, podobnie jak w przypadku tworzenia kopii, informowanie użytkownika o postępie występuje co 10% wykonanej operacji.

Aby odtworzyć bazę danych pubs, która została zarchiwizowana na urządzeniu pubs_backup, akceptując wszelkie domyślne opcje, należy uruchomić następujące polecenie:

RESTORE DATABASE PUBS FROM PUBS_BACKUP

Jeżeli na urządzeniu archiwizacyjnym pubs_backup są przechowywane trzy kopie bezpieczeństwa i planuje się odtworzyć trzecią z nich, należy uruchomić dwa zestawy poleceń. Pierwszym krokiem jest sprawdzenie, czy na pewno plik numer trzy jest pożądanym plikiem:

RESTORE HEADERONLY FROM PUBS_BACKUP

Drugim krokiem jest wykonanie odtwarzania:

RESTORE DATABASE PUBS FROM PUBS_BACKUP WITH FILE = 3

Aby odtworzyć bazę danych pubs, ale zachować plik pubs.mdf na komputerze, na dysku D po odtworzeniu, należy pozostawić bazę danych w stanie standby, odtworzyć dane z pliku numer trzy i określić powiadamianie o postępie odtwarzania co 25% stanu wykonania. Należy uruchomić następujące polecenie:

RESTORE DATABASE PUBS FROM PUBS_BACKUP

WITH MOVE 'pubs' TO 'D:\pubs.mdf',

FILE = 3,

STANDBY = 'd:\standby.dat'

STATS = 25

Powinno się otrzymać następujący komunikat:

26 percent restored.

53 percent restored.

76 percent restored.

100 percent restored.

Processed 208 pages for database 'PUBS', file 'pubs' on file 3.

Processed 1 pages for database 'PUBS', file 'pubs_log' on file 3.

RESTORE DATABASE successfully processed 209 pages in 0.807 seconds (2.112 MB/sec).

W tym miejscu można zastosować dziennik transakcji lub kopię różnicową bazy danych aby dokończyć odzyskiwanie bazy. Można uruchomić kod:

restore log pubs from pubs_backup with file = 4, RECOVERY

gdzie plik z numerem cztery jest plikiem kopii dziennika transakcji, który powstał później po wykonaniu pełnej kopii bazy danych. W tym przypadku, pojawi się następujący komunikat:

Deleting database file 'd:\standby.dat'.

Processed 5 pages for database 'pubs';, file 'pubs_log' on file 4.

RESTORE LOG successfully processed 5 pages in 0.048 seconds

(0.853 MB/sec).

Warto zauważyć, że SQL Server usuwa plik wstrzymany (standby) i kończy odtwarzanie dziennika transakcji. Teraz, gdy plik ten nie jest już potrzebny, należy go usunąć.

Opcja MOVE Opcja MOVE pozwala na wykonanie łatwych migracji danych z jednego serwera na inny. Jeżeli przykładowo serwer produkcyjny ma przypisaną literę H oraz I i zawiera dane SQL Servera lub pliki dziennika, można odtworzyć te kopie na serwerze projektowym. Jest to prawdą, nawet jeśli serwer ma jedynie oznaczenia dysków C, D i E. Wystarczy określić logiczne nazwy plików ze starej kopii i określić nową lokalizację na nowym serwerze dla każdego logicznego pliku.

Należy pamiętać, że można znaleźć listę plików w zestawie kopii przy pomocy polecenia RESTORE FILELISTONLY.

Opcja ta pomaga również w sytuacji odzyskiwania po awarii. Jest możliwe, ale mało prawdopodobne, że serwer po awarii nie będzie miał tej samej litery napędu, więc dobrze jest znać działanie opcji MOVE.

Jeżeli ktoś uważa, że autor kładzie zbyt wielki nacisk na wszelkie uszkodzenia systemu, należy rozważyć zdarzenie w sieci Internet, jakie miało miejsce podczas pisania wersji 7.0 tej książki. Autor odwiedził witrynę Web, na której była umieszczona informacja z przeprosinami za brak zawartości, ponieważ serwery zostały ukradzione podczas włamania. Czy to samo nie może przydarzyć się innym?

Opcja REPLACE Opcja REPLACE jest pożyteczna ponieważ informuje o niektórych procedurach sprawdzających, które są normalnie uruchamiane podczas odtwarzania. Jeżeli nazwa bazy danych, jaka została zarchiwizowana (przykładowo Accounting) nie jest taka sama jak ta, którą próbowano odtworzyć (przykładowo Sales), nie jest dozwolona normalna operacja odtwarzania.

Opcja ta pomaga również jeżeli zestawy plików nie pasują do siebie. Jeżeli zarówno kopia bazy danych jak i baza danych, do której ma być odtworzona są nazywane Accounting, ale produkcyjna baza danych (w danym momencie działająca) składa się z dwudziestu 1GB plików a kopia bezpieczeństwa jest niewłaściwa (np.: kopia bazy testowej o rozmiarze 20 MB), SQL Server zauważy to i ochroni przed odtworzeniem.

Można ominąć to zachowanie w obydwu przypadkach poprzez określenie opcji REPLACE, która zasadniczo informuje SQL Server aby nie ingerował, zakładając, że użytkownik jest świadomy konsekwencji działania tej opcji.

Należy być pewnym stosowania opcji REPLACE. Jeżeli wystąpi błąd z powodu jednego z wymienionych tutaj warunków, nadszedł czas aby zatrzymać się, wziąć głęboki oddech i przemyśleć, jakie działania są wykonywane. Lepiej jest zastanowić się przez minutę, niż próbować wytłumaczyć dlaczego została odtworzona niewłaściwa baza danych na bazie produkcyjnej.

Odtwarzanie z kopii różnicowej

Odtwarzania z kopii różnicowej działa podobnie jak odtwarzanie z pełnej kopii bezpieczeństwa. Nie ma różnic w składni polecenia. Należy określić prawidłowy numer pliku z urządzenia archiwizacyjnego.

Można odtworzyć kopię różnicową tylko po odtworzeniu z pełnej kopii bezpieczeństwa. Należy również określić opcję STANDBY lub NORECOVERY podczas odtwarzania z pełnej kopii aby mieć możliwość zastosowania kopii różnicowej.

Kopie różnicowe mogą się kumulować, więc jeśli zostały wykonane trzy kopie różnicowe od czasu wykonania ostatniej pełnej kopii, trzeba odtworzyć jedynie ostatnią z tych trzech kopii różnicowych.

Odtwarzanie z dziennika transakcji

Odtwarzanie z dziennika transakcji nie jest skomplikowane, dopóki ma się na uwadze pewne reguły. Można odtwarzać dzienniki transakcji jedynie w kolejności, w której zostały zarchiwizowane. Inaczej, niż w przypadku kopii różnicowych, kopie dziennika transakcji nie kumulują się, więc potrzeba żeby wszystkie były nienaruszone, aby było możliwe całkowite odtworzenie bazy danych.

W przypadku odtwarzań dziennika transakcji, inaczej niż w przypadku odtwarzania kopii bazy danych lub kopii różnicowych, które pozwalają na odtwarzania jedynie do punktu w czasie gdy kopia była tworzona; można odtwarzać do wybranego punktu w czasie, jak również odtwarzać do nazwanego znacznika w dzienniku transakcji.

Używanie Transact-SQL do odtwarzania dzienników transakcji Można wykonać polecenie RESTORE LOG aby odtworzyć kopię dziennika transakcji:

RESTORE LOG databasename FROM backup_device [,...n]

[WITH [RESTRICTED_USER] [[,] FILE = file_num]

[[,] PASSWORD = { pwd | @pwd_var } ]

[[,] MEDIANAME = { media_name | @media_name_var } ]

[[,] MEDIAPASSWORD = { mediapwd | @mediapwd_var } ]

[[,] MOVE 'logical_file_name' TO 'new_file_name'] [,...n]

[[,] KEEP_REPLICATION]

[[,] {NORECOVERY | RECOVERY | STANDBY = undo_file_name}]

[[,] {NOUNLOAD | UNLOAD}] [[,] {NOREWIND | REWIND} ]

[[,] RESTART] [[,] STATS [= percentage]]

[[,] STOPAT = datetime]

| [,] STOPATMARK = 'markname' [AFTER datetime]

| [,] STOPBEFOREMARK = 'markname' [AFTER datetime]]]

Składnia ta używa tych samych opcji co składnia dotycząca pełnego odtwarzania bazy danych, z wyjątkiem następujących:

• STOPAT określa datę i czas, które zostały wybrane jako punkt spójności podczas odtwarzania dziennika transakcji. Dowolne transakcje, które były aktywne (nie zatwierdzone) w tym czasie, zostają wycofane.

• STOPATMARK wyznacza znacznik (określający zaznaczoną nazwę wpisu) przy którym następuje zatrzymanie.

• STOPBEFOREMARK pozwala na zatrzymanie zaraz przed określonym znacznikiem.

Po odtworzeniu z pełnej kopii bazy danych (i określeniu opcji STANDBY lub NORECOVERY) można zastosować dziennik transakcji (przyjmując, że istnieje nośnik archiwizacyjny pubs_log_backup i zawiera jedną lub więcej kopii dziennika transakcji):

RESTORE LOG pubs from pubs_log_backup

To wszystko co trzeba wykonać. Dziennik został odtworzony. Całkowite odtworzenie pełnej kopii i kopii dziennika transakcji wygląda w następujący sposób:

RESTORE DATABASE pubs FROM pubs_backup WITH NORECOVERY

RESTORE LOG from pubs_log_backup WITH RECOVERY

RECOVERY jest opcją domyślną, więc nie ma potrzeby stosować jej w odtwarzaniu dziennika transakcji, ale została umieszczona tutaj dla zachowania przejrzystości.

Teraz, dla poparcia powyższych informacji należy rozważyć przykład. Trzeba przyjąć, że zostały wykonane kopie bazy danych a następnie kopie trzech różnych dzienników transakcji (pliki o numerach 1,2, 3 zapisane na nośniku archiwizacyjnym pubs_log_backup). Należy uruchomić następujący ciąg poleceń aby odzyskać bazę danych i odtworzyć wszystkie kopie dziennika transakcji:

RESTORE DATABASE pubs FROM pubs_backup WITH NORECOVERY

RESTORE LOG pubs from pubs_log_backup WITH FILE = 1, NORECOVERY

RESTORE LOG pubs from pubs_log_backup WITH FILE = 2, NORECOVERY

RESTORE LOG pubs from pubs_log_backup WITH FILE = 3, RECOVERY

Wyniki wykonania powyższych poleceń:

Processed 208 pages for database 'pubs', file 'pubs' on file 1.

Processed 1 pages for database 'pubs', file 'pubs_log' on file 1.

RESTORE DATABASE successfully processed 209 pages in 0.744 seconds (2.291 MB/sec).

Processed 2 pages for database 'pubs', file 'pubs_log' on file 1.

RESTORE LOG successfully processed 2 pages in 0.066 seconds (0.186 MB/sec).

Processed 1 pages for database 'pubs', file 'pubs_log' on file 2.

RESTORE LOG successfully processed 1 pages in 0.110 seconds (0.032 MB/sec).

Processed 1 pages for database 'pubs', file 'pubs_log' on file 3.

RESTORE LOG successfully processed 1 pages in 0.053 seconds (0.019 MB/sec).

Odtwarzanie do punktu w czasie Aby odtworzyć do punktu w czasie, należy odtwarzać podobnie jak omówiono wcześniej, z wyjątkiem tego, że należy określić zatrzymanie odtwarzania dziennika transakcji w podanym momencie w czasie. Można skorzystać z polecenia RESTORE HEADERONLY aby przejrzeć zakresy czasu objęte przez poszczególne kopie dziennika transakcji. Czyli, aby zatrzymać odtwarzanie w określonym punkcie, należy uruchomić dokładnie takie same polecenia jak poprzednio, ale zatrzymać odtwarzanie trzeciego dziennika w określonym czasie:

RESTORE DATABASE pubs FROM pubs_backup WITH NORECOVERY

RESTORE LOG pubs from pubs_log_backup WITH FILE = 1, NORECOVERY

RESTORE LOG pubs from pubs_log_backup WITH FILE = 2, NORECOVERY

RESTORE LOG pubs from pubs_log_backup WITH FILE = 3, RECOVERY,

STOPAT = 'Jun 3, 2000 4:53 PM'

Proces odtwarzania doprowadzi bazę danych do spójnego stanu z określonego dnia i godziny (4:53 po południu, 3 czerwca 2000 roku).

Odtwarzanie do zaznaczonego wpisu w dzienniku transakcji Jak zostało powiedziane wcześniej, można również odtworzyć bazę do określonego zaznaczonego wpisu w dzienniku transakcji. Istotną sprawą jest tutaj to, że odtwarzanie trwa do napotkania nazwy transakcji, a nie nazwy znacznika (który jest jedynie komentarzem, czyli wiadomo jaka transakcja następuje po nim). Należy rozważyć przykład:

exec sp_dropdevice 'pubs_backup','DELFILE'

exec sp_dropdevice 'pubs_log_backup','DELFILE'

go

exec sp_addumpdevice 'disk','pubs_backup','d:\program files\microsoft sql server\mssql\backup\pubs_backup.bak'

exec sp_addumpdevice 'disk','pubs_log_backup','d:\program files\microsoft sql server\mssql\backup\pubs_log_backup.bak'

--create backup file #1 (full database backup)

backup database pubs to pubs_backup with init

go

use pubs

create table table3 (c1 int not null)

BEGIN TRANSACTION tran1 WITH MARK 'My first Mark'

insert table3 values (1)

COMMIT TRANSACTION tran1

-- create backup file #1 (tran log backup)

backup log pubs to pubs_log_backup with noinit

create table table4 (c1 int not null)

insert table4 values (1)

-- create backup file #2 (tran log backup)

backup log pubs to pubs_log_backup with noinit

insert table3 values (2)

BEGIN TRANSACTION tran2 WITH MARK 'My second Mark'

insert table3 values (3)

insert table4 values (3)

COMMIT TRANSACTION tran2

-- create backup file #3 (tran log backup)

backup log pubs to pubs_log_backup with noinit

Skrypt tworzy plik kopii bezpieczeństwa dla dziennika transakcji i kopię bazy danych, archiwizuje bazę danych, tworzy obiekty oraz tworzy dwie „oznaczone” transakcje: tran1 i tran2. Można odtworzyć dane do jednego z tych oznaczonych punktów, jak w poniższym przykładzie:

RESTORE DATABASE pubs FROM pubs_backup WITH NORECOVERY

RESTORE LOG pubs from pubs_log_backup WITH FILE = 1, NORECOVERY

RESTORE LOG pubs from pubs_log_backup WITH FILE = 2, NORECOVERY

RESTORE LOG pubs from pubs_log_backup WITH FILE = 3, RECOVERY,

STOPATMARK = 'tran2'

System wyświetli komunikat:

Processed 144 pages for database 'pubs', file 'pubs' on file 1.

Processed 1 pages for database 'pubs', file 'pubs_log' on file 1.

RESTORE DATABASE successfully processed 145 pages in 0.629 seconds (1.877 MB/sec).

Processed 2 pages for database 'pubs', file 'pubs_log' on file 1.

RESTORE LOG successfully processed 2 pages in 0.064 seconds (0.224 MB/sec).

Processed 1 pages for database 'pubs', file 'pubs_log' on file 2.

RESTORE LOG successfully processed 1 pages in 0.052 seconds (0.068 MB/sec).

Processed 1 pages for database 'pubs', file 'pubs_log' on file 3.

RESTORE LOG successfully processed 1 pages in 0.049 seconds (0.020 MB/sec).

Odtwarzanie dziennika transakcji i kopii różnicowych bazy danych Jeżeli zachodzi potrzeba połączenia odtwarzania z kopii różnicowych i z kopii dzienników transakcji, należy pamiętać, że potrzebne są wszystkie dzienniki transakcji, które były aktywne od czasu utworzenia kopii różnicowej. Przykładowo, jeżeli we wcześniejszym przykładzie, została utworzona kopia różnicowa po wykonaniu drugiej kopii dziennika transakcji, należy uruchomić następujący kod źródłowy:

RESTORE DATABASE pubs FROM pubs_backup WITH FILE = 1, NORECOVERY

RESTORE DATABASE pubs FROM pubs_backup WITH FILE = 2, NORECOVERY

RESTORE LOG pubs from pubs_log_backup WITH FILE = 1, RECOVERY

Odpowiedź systemu będzie następująca:

Processed 144 pages for database 'pubs', file 'pubs' on file 1.

Processed 1 pages for database 'pubs', file 'pubs_log' on file 1.

RESTORE DATABASE successfully processed 145 pages in 0.599 seconds (1.971 MB/sec).

Processed 48 pages for database 'pubs', file 'pubs' on file 2.

Processed 1 pages for database 'pubs', file 'pubs_log' on file 2.

RESTORE DATABASE successfully processed 49 pages in 0.312 seconds (1.263 MB/sec).

Processed 3 pages for database 'pubs', file 'pubs_log' on file 1.

RESTORE LOG successfully processed 3 pages in 0.070 seconds (0.307 MB/sec).

Baza danych została odtworzona przy pomocy pełnej kopii bezpieczeństwa, następnie została zastosowana kopia różnicowa, a w końcowym etapie jedynie kopia dziennika transakcji utworzona po wykonaniu kopii różnicowej: kopia dziennika transakcji numer 3.

Odtwarzanie plików lub grup plików

W razie potrzeby można odtworzyć również indywidualne pliki lub grupy plików. Dla zachowania spójności tematu niniejszy rozdział zawiera składnię odpowiedniego polecenia dotyczącego odtwarzania plików oraz przykład. Pomimo tego, że tworzenie kopii plików i grup plików to bardzo użyteczne cechy SQL Servera, wymagają one złożonego planowania, aby zapewnić udane korzystanie z tych mechanizmów i są poza zakresem tej książki.

RESTORE DATABASE databasename file_or_filegroup [,...n]

[FROM backup_device [,...n]]

[WITH [RESTRICTED_USER] [[,] FILE = file_num]

[[,] PASSWORD = { pwd | @pwd_var } ]

[[,] MEDIANAME = { media_name | @media_name_var } ]

[[,] MEDIAPASSWORD = { mediapwd | @mediapwd_var } ]

[[,] NORECOVERY ] [[,] {NOUNLOAD | UNLOAD}] [[,] {NOREWIND | REWIND} ]

[[,] REPLACE] [[,] RESTART] [[,] STATS [= percentage]]]

Składnia:

file_or_filegroup : : =

{FILE = {logical_file_name | @logical_file_name_var} |

FILEGROUP = {logical_filegroup_name | @logical_filegroup_name_var}}

Jedyną różnicą pomiędzy tą składnią a składnią polecenia dotyczącego odtwarzania pełnej kopii bazy danych jest to, że w tym poleceniu można określić nazwę pliku lub nazwę grupy plików.

Jeżeli na nośniku archiwizacyjnym został zarchiwizowany plik test_data bazy danych o nazwie o nazwie test_file_backup, można odtworzyć ten plik przy pomocy następujących poleceń:

RESTORE DATABASE test FILE = 'test_data'

FROM test_file_backup WITH NORECOVERY

RESTORE LOG test

FROM test_log_backup WITH RECOVERY

Nie można odtworzyć pliku lub grupy plików bez zastosowania, następnie odtworzenia dziennika transakcji aby doprowadzić bazę danych do spójnego stanu. Przykład ten jest jedynie podpowiedzią w całej złożonej strategii tworzenia kopii bezpieczeństwa plików lub grup plików.

Odtwarzanie przy pomocy SQL Server Enterprise Managera

Teraz gdy jest już zrozumiałe co dzieje się wewnątrz wykonywanych działań, nadszedł czas na przetestowanie jak łatwo można odtworzyć bazę danych przy pomocy SQL Server Enterprise Managera.

Należy rozwinąć folder Databases, wybrać poprzez kliknięcie prawym klawiszem myszy bazę danych jaka ma zostać odtworzona, następnie wybrać Wszystkie zadania i Restore Database. Teraz powinno się zrodzić pytanie: Co stanie się w przypadku, gdy baza danych jaka ma zostać odtworzona nie istnieje?

Po połączeniu z serwerem, należy wybrać z menu Narzędzia opcję Restore Database. W obydwu przypadkach pojawi się to samo okno dialogowe Restore Database (zobacz Rysunek 8.3 z przykładowo wybraną bazą pubs).

Jak widać z rysunku 8.3, SQL Server Enterprise Manager bardzo upraszcza odtwarzanie. SQL Server, jak zostało wcześniej powiedziane, pamięta, kiedy kopie są tworzone przechowując informacje w tabelach systemowych w bazie systemowej MSDB. Informacja ta jest pokazywana w oknach dotyczących odtwarzania. SQL Server odtwarza kopię każdego zaznaczonego (w polu wyboru) elementu. Na rysunku 8.3 można również zobaczyć, że baza będzie odtwarzana z pełnej kopii bezpieczeństwa (pierwsze zaznaczone pole), następnie bezpośrednio po tym wystąpi odtwarzanie z dziennika transakcji (następne dwa zaznaczone pola). Odtwarzanie z pełnej kopii bezpieczeństwa wystąpi z opcją NORECOVERY ponieważ zaraz po nim zastosowane jest odtwarzania dziennika transakcji. Odtwarzania dziennika transakcji następuje z opcją RECOVERY. Po wykonaniu tych operacji baza danych jest już dostępna.

Rysunek 8.3. Odtwarzanie bazy danych.

Aby wykonać odtwarzanie plików lub grup plików wystarczy kliknąć tę opcję. Aby przeprowadzić odtwarzanie do punktu w czasie (przyjmując, że jest odtwarzany jeden lub więcej dzienników transakcji), należy kliknąć pole Point in time restore.

Jeżeli zostanie wybrana opcja Restore from device, część okna ulegnie zmianie, jak pokazano na rysunku 8.4.

Rysunek 8.4. Odtwarzanie bazy danych (przy pomocy urządzenia).

Aby wybrać nośnik archiwizacyjny, należy kliknąć przycisk Select Devices. Następnie kliknąć przycisk Add aby przejść do okna pokazanego na rysunku 8.5. Należy wybrać plik zawierający kopię bazy danych lub dziennika transakcji lub wybrać urządzenie archiwizacyjne.

Rysunek 8.5. Wybór miejsca docelowego dla odtwarzanej bazy danych.

Po powrocie do okno Restore Database, należy określić rodzaj kopii, jaka będzie odtwarzana. Następnie wybrać numer kopii bezpieczeństwa (parametr FILE z polecenia RESTORE). Kolejną użyteczną własnością jest to, że można kliknąć przycisk View Contents aby zobaczyć odpowiednik polecenia LOAD HEADERONLY. Jednakże, w tym przypadku można wybrać odczytanie zawartości nośnika archiwizacyjnego, jeśli nośnik zawiera wiele kopii (przykładowo, wiele kopii dziennika transakcji). Zobacz rysunek 8.6.

Rysunek 8.6. Okno Wybór kopii bezbieczeństwa.

W końcowym etapie działań, w oknie Restore Database, warto przyglądnąć się opcjom w dolnej części okna, które pozwalają na uaktualnienie informacji o historii w bazie danych SQL Servera MSDB.

Aby zmienić inne opcje odtwarzania w oknie Restore Database, należy kliknąć zakładkę Options (zobacz rysunek 8.7). Z tej zakładki dostępne są następujące opcje:

• Eject Tapes (If Any) after restoring each backup — jeżeli pole wyboru jest zaznaczone powoduje wyjęcie taśmy po zakończeniu odtwarzania.

• Prompt before restorinf each backup pozwala na powiadamianie pomiędzy odtwarzaniami, wybranymi z zakładki General.

• Force restore over existing database odpowiada opcji REPLACE w poleceniu RESTORE DATABASE.

• W sekcji Restore database files as można zmienić nazwę każdego z plików zestawu archiwizacyjnego. Jest to odpowiednik opcji MOVE z polecenia RESTORE DATABASE.

• Blok Recovery Completion State posiada trzy opcje. Pierwsza, domyślna oznacza pozostawienie działającej bazy danych (jest to odpowiednik określenia opcji RECOVERY w końcowym odtwarzaniu).

Należy użyć środkowej opcji jeśli ma być kontynuowane odtwarzanie z kopii różnicowej lub dzienników transakcji. Opcja ta jest odpowiednikiem opcji NORECOVERY w końcowym odtwarzaniu z dziennika transakcji (lub odpowiednikiem odtwarzania z kopii pełnej lub różnicowej jeżeli zostało wybrane, że nie będą stosowane dzienniki transakcji).

Ostatnia opcja jest taka sama jak opcja STANDBY w poleceniu odtwarzania. Jak w przypadku polecenia Transact-SQL, należy określić położenie i nazwę pliku wycofania.

Rysunek 8.7. Przywracanie ustawień bazy danych.

Jeżeli wszystko jest przygotowane do operacji odtwarzania należy wcisnąć przycisk OK. SQL Server Enterprise Manager wykona odpowiednie polecenia RESTORE, które zostały określone graficznie w odpowiednim oknie.

Scenariusze odtwarzania

Być może najważniejszą rzeczą, jaką należy wykonać jest zapoznanie się z tym, jak stosować kopie bezpieczeństwa oraz techniki odtwarzania, omówione w tym i w poprzednim rozdziale.

Odtwarzanie po utracie dysku

Jedynym z typowych scenariuszy odtwarzania jest odzyskiwanie baz danych po utracie (uszkodzeniu) dysku serwera. Aby odtworzyć bazę danych należy podjąć następujące kroki:

1. Sprawdzić, czy posiada się wszystkie informacje potrzebne do odtwarzania zawartości napędów i baz danych.

2. Zachować dziennik transakcji jeżeli jest nadal dostępny.

3. Usunąć uszkodzone bazy danych.

4. Zastąpić uszkodzony dysk.

5. Odtworzyć odpowiednie bazy danych i dzienniki transakcji.

Poniżej każdy z tych kroków został omówiony szczegółowo.

Sprawdzenie czy wszystkie informacje potrzebne do odtwarzania bazy danych są dostępne

Należy skorzystać z poleceń CREATE DATABASE aby powtórnie utworzyć bazy danych uszkodzone w wyniku utraty dysku. Dużą zaletą jest to, że w przypadku SQL Servera 2000 jeżeli tylko można znaleźć kopię bezpieczeństwa (lub taśmę z archiwum) to można określić co zawiera archiwum przy pomocy poleceń poznanych w tym rozdziale (RESTORE HEADERONLY, RESTORE FILELISTONLY). W przypadku SQL Servera 2000 wszystkie informacje potrzebne do odtwarzania z kopii bezpieczeństwa są zawarte w kopiach bezpieczeństwa.

Zachowanie dziennika transakcji jeżeli jest nadal dostępny

Jeżeli pliki bazy danych są w jakiś sposób uszkodzone, a pliki dziennika transakcji są dostępne (na innym dysku), można uruchomić polecenie BACKUP LOG z opcją NO_TRUNCATE. Założeniem jest, że zostały zarchiwizowane wpisy dziennika transakcji, które pojawiły się od czasu tworzenia ostatniej kopii, czyli będzie możliwe skorzystanie z tych wpisów dziennika gdy dojdzie do odtwarzania bazy danych.

Usuwanie bazy danych

Ponieważ baza danych jest podejrzana o częściowe uszkodzenie, można usunąć bazę danych a następnie przygotować odtwarzanie. Można uruchomić polecenie DROP DATABASE aby usunąć bazę danych i wszystkie jej pliki z serwera. Polecenie DROP DATABASE działa nawet jeśli baza danych została częściowo uszkodzona.

Zastępowanie uszkodzonego dysku

Ten krok powinien być oczywisty. Zanim nastąpi ponowne uruchomienie systemu Windows 2000, należy zresetować wszelkie konfiguracje RAID. W przypadku korzystania z Windows 2000 RAID, należy skonfigurować program instalacyjny RAID w programie Disk Administrator przed wykonaniem kolejnego kroku. Należy zapoznać się z dokumentacją Windows 2000 jeżeli używana jest konfiguracja Windows 2000 RAID lub z dokumentacją używanego sprzętu w innym przypadku.

Ponowne utworzenie utraconych baz danych (opcjonalne)

Jeżeli zachodzi potrzeba, można ponownie utworzyć bazę danych. Krok ten jest opcjonalny. Proces odtwarzania może wykonać ponowne utworzenie bazy danych.

Odtwarzanie z pełnej kopii bazy danych, wszelkich kopii różnicowych i kopii dziennika transakcji

Po omówieniu niniejszego rozdziału, krok ten powinien również być jasny. Należy odzyskać bazę z pełnej kopii bezpieczeństwa oraz ostatniej kopii różnicowej (jeśli istnieje), a następnie zastosować dziennik transakcji (włączając w to ostatnią kopię dziennika utworzoną po uszkodzeniu dysku).

Uruchomienie DBCC CHECKDB w celu sprawdzenia poprawności odtwarzania (opcjonalne)

Ten krok jest opcjonalny, ale zalecany. Zaleca się uruchomienie DBCC CHECKDB aby sprawdzić każdą z baz danych, która została odtworzona, w celu weryfikacji, czy kopia bezpieczeństwa oraz operacja odtwarzania przywróciły prawidłowy stan bazy. Jeżeli z jakiegoś powodu to nie nastąpiło, należy spróbować ponownie odtworzyć bazę danych, tym razem z wcześniejszej kopii.

Jak można zauważyć, odtwarzanie bazy danych nie jest procesem wymagającym specjalistycznej wiedzy ścisłej, ale jest na tyle skomplikowane, że powinno się ćwiczyć odtwarzanie okazyjnie, żeby mieć pewność co do postępowania w każdym z kroków, jeżeli w sytuacji awaryjnej serwer testowy zostanie zastąpiony przez serwer produkcyjny, na którym wystąpiły realne problemy.

Odtwarzanie po utracie bazy danych master

Procedura RESTORE działa poprawnie, do czasu wystąpienia uszkodzenia bazy master. Co zrobić gdy to nastąpi? Istnieją dwa sposoby w jakie uszkodzenie bazy master wpływa na pozostałe bazy i serwer. Opierają się one na tym, co zamierza się zrobić aby naprawić uszkodzenie.

W przypadku gdy została uszkodzona baza danych lub plik dziennika lub występują problemy logiczne (ktoś usunął wszystkie konta logowania lub zaszło coś podobnego), ale SQL Server nadal działa, wystarczy odtworzyć bazę danych master. Szczerze mówiąc, bardziej prawdopodobny scenariusz jest taki, że gdy baza danych master ulegnie uszkodzeniu, zostanie uszkodzony również serwer. Dlatego dobrym sposobem jest utworzenie odbicia lustrzanego dysków przechowujących bazę danych master i pliki dziennika transakcji (co zostanie omówione w rozdziale 20).

Odtwarzanie bazy danych master

Na początek, łatwy scenariusz: aby odtworzyć bazę danych master z pełnej kopii bezpieczeństwa, należy uruchomić SQL Server w trybie pojedynczego użytkownika. Najłatwiejszy sposób to skorzystanie z wiersza poleceń na działającym SQL Serverze 2000. Należy otworzyć wiersz poleceń i uruchomić następującą sekwencję poleceń:

NET STOP MSSQLSERVER

Polecenie to zatrzymuje serwis MSSQLServer (dla domyślnej instancji). Aby zatrzymać instancję nazwaną, należy wpisać MSSQL$nazwa_instancji (np.:MSSQL$TRADE dla kopii nazwanej „trade”).

Następnie należy uruchomić SQL Server w trybie pojedynczego użytkownika, z parametrem (-m):

SQLSERVR.EXE -m

Polecenie to uruchamia SQL Server jako aplikację działającą w oknie poleceń. Nie należy nic wpisywać ani zamykać tego okna poleceń, ponieważ jest to SQL Server. Kiedy SQL Server skończy wypisywanie testu w oknie (tekst wygląda podobnie jak dzienniki błędów omawiane wcześniej) jest on gotowy do użytku.

Aby uruchomić instancję nazwaną należy skorzystać z opcji -s jak opisano w rozdziale 2. „Instalacja Microsoft SQL Server 2000”. Przykładowo, aby uruchomić instancję nazwaną TRADE należy wpisać polecenie:

SQLSERVR.EXE -m -sTRADE

Następnie, należy uruchomić ulubione narzędzie ułatwiające zadawanie zapytań (lub SQL Server Enterprise Managera) i odtworzyć bazę danych master oraz wszelkie inne pełne kopie baz danych. Kiedy operacja odtwarzania jest zakończona, SQL Server zatrzymuje swoje działanie. Wystarczy uruchomić usługę aby powrócić do normalnego działania. Można skorzystać z następującego polecenia aby uruchomić usługę ponownie:

NET START MSSQLServer

lub

NET START MSSQL$TRADE

Bazę danych master można odtworzyć jedynie gdy serwer jest w trybie pojedynczego użytkownika. Jeżeli nie jest w tym trybie, narzędzia typu SQL Server Enterprise Manager i inne narzędzia do zadawania zapytań poinformują o tym następującym komunikatem:

Server: MSG 3108, Level 16, State 1, Line 2 RESTORE DATABAS must be used in single user mode when trying to restore the master database. Server: Msg 3013, Level 16, State 1, Line 2 RESTORE DATABASE terminating abnormally.

--> Należy[Author:AK] dokończyć odtwarzanie bazy danych master i uruchomić ponownie, SQL Server zanim przejdzie się do odtwarzania jakiejkolwiek innej bazy danych.

Należy ręcznie wprowadzić wszelkie zmiany, jakie zostały wykonane w bazie master od czasu tworzenia ostatniej kopii bezpieczeństwa bazy danych — kolejna przyczyna, dla której należy wykonywać częste kopie bezpieczeństwa bazy danych master.

Ponowne budowanie bazy danych master

Inny scenariusz zakłada, że baza danych master nie jest dostępna i nie działa i serwer jest uszkodzony. Najlepiej powiedzieć sobie: „Nie panikuj!”. Zawsze istnieje wyjście z sytuacji, można nawet zostać największym bohaterem w całym biurze.

Jeżeli SQL Server nie uruchamia się, ponieważ baza danych master nie funkcjonuje, oznacza to na ogół problemy z dyskiem (lub dyskami), na których znajduje się baza danych master. Pierwszym krokiem jest uruchomienie narzędzia Rebuild Master (rebuildm.exe), umieszczonego w katalogu: \Program Files|Microsoft SQL Server\80\tools\binn.

Narzędzie to zakłada, że SQL Server nie jest uruchomiony. Kiedy zostanie uruchomiony, wyświetli się okno Rebuid Master (zobacz rysunek 8.8.).

Rysunek 8.8. Okno odbudowywania bazy danych.

Należy kliknąć przycisk Browse aby znaleźć katalog \data z płytą instalacyjną CD. Należy kliknąć przycisk Settings aby zmienić ustawienie Collation settings (zobacz rysunek 8.9), w przypadku, gdy nie zostały zaakceptowane ustalenia domyślne podczas instalacji SQL Servera.

Po ustawieniu tych opcji, należy kliknąć OK. W oknie Rebuild Master należy kliknąć opcję Rebuild aby SQL Server skopiował oryginale pliki bazy danych z płyty CD. Zawiera ona wszystkie pliki dla bazy danych master, MSDB, model, pubs i Northwind. Rebuild Master uruchamia następnie SQL Server, który tworzy ponownie bazę danych tempdb i przeprowadza wszystkie potrzebne konwersje, w zależności od wybranego sposobu kodowania (collation). Po zakończeniu użytkownik otrzymuje stosowny komunikat o zakończeniu odbudowywania.

Rysunek 8.9. Wybór odpowiednich opcji odbudowywania.

Odtwarzania bazy master a następnie wszystkich innych baz systemowych Po odbudowaniu serwera, należy odtworzyć kopię bazy danych master, jak zostało opisane wcześniej. Następnie potrzeba odtworzyć bazę danych model (jeżeli była zmieniana), bazę MSDB i bazę dystrybucyjną jeżeli jest to serwer dystrybucyjny stosowany do replikacji.

Dołączanie lub odtwarzanie baz danych, w razie potrzeby W końcowym etapie należy odtworzyć wszelkie inne uszkodzone bazy. Jeżeli nadal zachowały się poprawne pliki bazy danych, może użyć polecenia CREATE DATABASE FOR ATTACH lub systemowej procedury składowej sp_attach_db aby ponownie połączyć pliki bazy danych z SQL Serverem.

Wykonywanie DBCC na całym serwerze Na końcu, z powodu zachowywania dużej ostrożności, po wystąpieniu takiego uszkodzenia, należy uruchomić DBCC CHECKDB na każdej z baz danych aby zweryfikować czy serwer posiada kopie bezpieczeństwa i pracuje bezbłędnie.

2 Część I ♦ Podstawy obsługi systemu WhizBang (Nagłówek strony)

1 E:\Praca\Ksiaki\SQL\r08-1.doc

Jest to ciągle ta sama wskazówka - łącznie z powyższym kodem.

---