Odtwarzanie bazy danych

Ćwiczenie 4
Odtwarzanie bazy danych.
Wprowadzenie teoretyczne. ................................................................................................................. 2
Odtwarzanie bazy danych ................................................................................................................ 2
Odzyskiwanie automatyczne............................................................................................................ 2
Konfiguracja odzyskiwania automatycznego .............................................................................. 3
Odzyskiwanie ręczne ....................................................................................................................... 3
Odtwarzanie z plików (ponowne łączenie bazy danych w całość) .............................................. 4
Znalezienie poprawnego zestawu kopii bezpieczeństwa ................................................................. 4
Sprawdzenie użyteczności zestawu kopii bezpieczeństwa .............................................................. 6
Wykonywanie pełnego odtwarzania bazy danych ........................................................................... 6
Odtwarzanie z kopii różnicowej ...................................................................................................... 8
Odtwarzanie z dziennika transakcji ................................................................................................. 8
Odtwarzanie plików lub grup plików............................................................................................... 9
Przebieg ćwiczenia:............................................................................................................................ 10
Treść sprawozdania: ........................................................................................................................... 15
Przykładowe pytania kontrolne .......................................................................................................... 15
Wprowadzenie teoretyczne.
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.
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.
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.
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
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 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 ).
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.
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).
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.
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 TransactSQL 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

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ą
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.
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.
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
jest opcją domyślną, więc nie ma potrzeby stosować jej w odtwarzaniu dziennika
transakcji, ale została umieszczona tutaj dla zachowania przejrzystości.
RECOVERY
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.
Przebieg ćwiczenia:
Uwaga: wszystkie kody wykonywane w programie Query Analizer zapisywać do
plików, gdyż ułatwi to sporządzanie sprawozdania.
1. Przeniesienie testowej bazy danych „Samochody” do SQL serwera.
W celu realizacji ćwiczenia Należy pobrać testową bazę „samochod.BAK” ze strony
internetowej. W tym punkcie w SQL serwerze będzie odtwarzana ta baza. Plik
„samochod.BAK” jest kopią bezpieczeństwa (Backup Device) która została wcześniej
stworzona na innym komputerze.
- Stwórz na dysku c:\ katalog C:\BACKUP. Zapisz ze strony internetowej do tego
katalogu plik „samochod.BAK”, zawierający kopie bazy danych.
- Uruchom program QUERY ANALYZER. Sprawdź poprawność pliku „samochod.BAK”
przez instrukcje RESTORE VERIFYONLY. Komunikat „The backup set is valid”
świadczy o poprawności pliku.
- Sprawdź treść Backup Device przez instrukcje RESTORE HEADERONLY. Kopia
bezpieczeństwa musi zawierać jedną kopie o nazwie „samochody backup”.
- Uruchom program Enterprise Manager. Kliknji katalog „Data Base”. Wybrać
„DataBase->Wszystkie zadania-> Restore Data Base. Uruchom okno „Restore Data
Base”. W zakładce „General” ustal następujące wartości pól:
Pole
Restore as database
Restore
Wartość
Samochody
From device
Device
C:\BACKUP\
samochod.BAK
Restore Backup set
Database complete
True
True
Opis pola
Nazwa BD serwerze SQL po odtwarzaniu
Odtwarzanie odbędzie się przez plik Backup
Device
Ścieżkę dostępu do Backup Device. Ścieżkę
dostępu trzeba ustalić się przez przycisk
„Select Device”.
W zakładce „Option” musi być ustalona wartość „Leave database operational. No
additional transaction logs can be restored” co oznacza, że odtwarzanie odbędzie się bez
wykorzystania dziennika transakcji. Kliknij OK. Po otrzymaniu komunikatu „Restore of
database „samochody” completed successfully”, kliknij OK.
- W programie Enterprise Manager sprawdź obecność bazy danych, obecność tabel
użytkownika: „Klienci”, „Miejsca”, „Samochody”, „Pracownicy”, „Wypozyczenia”.
- Stwórz w QUERY ANALYZER polecenia SQL w celu sprawdzenia obecności
danych w każdej z tych tabel.
2. Tworzenie diagramu związków w programie Enterprise Manager.
W programie Enterprise Manager stwórz diagram związków pomiędzy tabelami bazy
danych samochody: „Klienci”, „Miejsca”, „Samochody”, „Pracownicy”, „Wypozyczenia”.
Diagram ten jest schematem fizycznego modelu danych i będzie potrzebny przy
konstruowaniu poleceń SQL w następnych punktach ćwiczenia.
Odtwórz ikonę bazy danych „Samochody”. Kliknji prawym przyciskiem myszy ikonę
„Diagrams”, wybierz opcję „New Database diagram”, uruchom wizard „Create database
diagram”, gdzie trzeba wybrać potrzebne do diagramu tabele bazy danych: „Klienci”,
„Miejsca”, „Samochody”, „Pracownicy”, „Wypozyczenia”.
3. Modyfikacja bazy danych.
W tym punkcie baza danych zostanie zmodyfikowana przez dodawanie
nowych rekordów do tabel.
Wpisz w QUERY ANALYZER po jednym nowym rekordzie do każdej z tabel: „Klienci”,
„Miejsca”, „Samochody”.
Sprawdź przez polecenie SQL czy te rekordy zostały wpisane.
W celu wpisania nowych rekordów może być wykorzystana instrukcja SQL :
INSERT INTO ... VALUES (...);
4. Tworzenie urządzenia archiwizacyjnego “Backup Device”.
Wykorzystując wiedzę z poprzedniego ćwiczenia stwórz nowy „Backup Device” w
katalogu C:\BACKUP o nazwie „samochody_backup_1” dla bazy danych „Samochody”.
W tym celu można wykorzystać systemową procedurę sp_addumpdevice lub program
Enterprice Manager.
5. Tworzenie kopii bazy danych.
Wykorzystując wiedzę z poprzedniego ćwiczenia stwórz nową kopię bazy danych
„Samochody” na „Backup Device” o nazwie „samochody_backup_1”.
Nowa kopia musi stworzona z następującymi opcjami:
Wartość
Opcja
NAME
DESCRIPTION
Backup
Overwrite
‘Samochody-Full’
‘Druga kopia Full-backup po dodawaniu
nowych danych’
DataBase-complete
Overwrite existing media
Zanotuj datę oraz czas stworzenia kopii. Sprawdź w Enterprise Manager obecność kopii
na nośniku archiwizacyjnym „samochody_backup_1”.
6. Modelowanie nieprawidłowych czynności użytkownika.
W tym punkcie do bazy danych będą wprowadzone „uszkodzone” dane. Taka sytuacja
może zaistnieć w realnych warunkach przy nieprawidłowych czynnościach użytkownika.
Administrator bazy danych musi później naprawić uszkodzoną bazę danych.
- Zmodyfikuj tabele do których zostały wpisane nowe dane w p.3., instrukcją Update z
grupową modyfikacją danych. Np.:
UPDATE klienci SET nazwisko = 'Kowalski'
- Sprawdź zawartość „zmodyfikowanych” tabel. Dane zostały „uszkodzone”, ponieważ
pola jednej kolumny w różnych rekordach tabeli mają tą samą wartość (dla tabeli
„Klienci” to jest nazwisko 'Kowalski').
7. Odtwarzanie bazy danych.
W tym punkcie baza danych „Samochody” będzie odtwarzana z kopii 'Samochody-Full',
która została utworzona w p.5.
- Uruchom Enterprise Manager. Rozwiń „SQL Server Group”->Database”, klinj prawym
przyciskiem myszy „Samochody”, klinji „Properties”. Wybierz zakładkę „Option”.
Ogranicz dostęp do bazy innym użytkownikom, wybierając „Restrict Access” , „Members
of db_owner, dbcreator, or sysadmin” . Kliknji OK. Sprawdź w lewym panelu Enterprise
Manager obecność ograniczonego trybu dostępu do bazy”Samochody” „DBO Use Only”.
- Kliknji prawą myszą na lewej konsoli ikonę bazy „Samochody”. Wybierz tryb
„Wszystkie zadania”, wybierz opcję ”Restore DataBase”. W oknie „General” ustal
następujące parametry:
Pole
Restore Database
First backup to restore
Restore (list)
Wartość
Samochody
<Date Time> 'Samochody-Full'
Wybierz potrzebny Backup Device z listy
nośników archiwalnych
- Wybierz zakładkę „Option”. Ustaw tryb „Leave database operational. No additional
transaction logs can be restored”. Ten tryb ustawi odtwarzanie bazy danych bez
wykorzystania dzienników transakcji. Kliknji OK.
- Uruchom QUERY ANALYZER. Sprawdzić tabele, które byli „uszkodzone” w p. 6.
W kolejnych punktach ćwiczenia będą realizowane różne modyfikacje bazy danych, będą
tworzone kopie różnicowe oraz kopie „logów” tych modyfikacji. Będzie modelowana
sytuacja awaryjna oraz będzie pokazane w jaki sposób należy wykorzystać kopie
bezpieczeństwa do odtwarzania bazy danych.
8. Stworzenie nowego nośnika archiwizacyjnego (Backup Device) , który
będzie przeznaczony do jednoczesnego przechowywania pełnej kopii (Full)
oraz kopii różnicowych (Differential copies).
W tym punkcie będzie stworzony nowy nośnik archiwalny (Backup Device) oraz kopia
Full bazy danych „samochody”.
- Uruchom QUERY ANALYZER. Stwórz przez procedurę systemową
„sp_addumpdevice” nowy nośnik archiwalny z nazwą logiczną „Samochody_backup_2”
oraz plikiem C:\Backup\Samochody_backup_2.bak
- Wykorzystując wiedzę z poprzedniego ćwiczenia stwórz nową kopię bazy danych
„Samochody” na Backup Device „samochody_backup_2” z następnymi opcjami:
Opcja
NAME
DESCRIPTION
Backup
Overwrite
Wartość
'Samochody-Full'
„Kopia Full-backup DB Samochody”
DataBase-complete
Overwrite existing media
9. Pierwsza modyfikacja bazy danych. Stworzenie kopii dziennika transakcji.
W tym punkcie będą zmodyfikowane tabele bazy danych w sposób analogiczny do p.3.
Do przechowywania zmian w porównaniu z „Kopią Full-backup...” będzie utworzony
nowy nośnik archiwizacyjny „Samochody Changes” i do tego nośnika zostanie zapisany
dziennik transakcji(log). Na nowym nośniku archiwizacyjnym będą kopie różnicowe
(differential backup) oraz kopi logów(dzienników transakcji).
- Wpisz wykorzystując QUERY ANALYZER nowe rekordy do tabel: „Klienci”,
„Miejsca”, „Samochody”. Sprawdź wykorzystując polecenia SQL czy te rekordy zostały
wpisane.
Do wpisania nowych rekordów może być wykorzystana instrukcja SQL :
INSERT INTO ... VALUES (...);
- Wykorzystując wiedzę z poprzedniego ćwiczenia utwórz nowy „Backup Device” o
nazwie „samochody_change” do przechowywania zmian w bazie danych „Samochody”.
Plik „samochody_change.bak” musi być w katalogu C:\BACKUP.
- Wykorzystując wiedzę z poprzedniego ćwiczenia utwórz nową kopię dziennika
transakcji bazy danych „Samochody” na urządzeniu „Backup Device”
„samochody_change” z następującymi opcjami:
Opcja
NAME
DESCRIPTION
Backup
Overwrite
Wartość
‘Samochody Changes '
' 1-a modyfikacja - Log and Differential backups
BD samochody'
Transaction Log
Append to media
Sprawdź obecność kopii. Zwracaj uwagę na typ i czas stworzenia kopii.
10.Druga modyfikacja bazy danych. Stworzenie kopii różnicowej (differential
backup).
W tym punkcie będą zmodyfikowane tabele bazy danych w sposób analogiczny pp.3,9.
Do przechowywania zmian w porównaniu z „Trzecią kopią Full-backup...” w nośniku
archiwizującym będzie stworzona kopia różnicowa (differential backup).
- Wpisz w QUERY ANALYZER nowe rekordy do tabel: „Klienci”, „Miejsca”,
„Samochody”. Sprawdź przez polecenie SQL czy te rekordy zostali wpisane.
Dla wpisania nowych rekordów może być wykorzystana instrukcja SQL :
INSERT INTO ... VALUES (...);
- Wykorzystując wiedzę z poprzedniego ćwiczenia stwórz w QUERY ANALYZER za
pomocą instrukcji BACKUP DATABASE kopię różnicową bazy danych „Samochody” na
„Backup Device” „samochody_change” z opcjami „with DIFFERENTIAL, NOINIT”.
Sprawdź obecność kopii. Zwracaj uwagę na typ i czas stworzenia kopii.
11.Trzecia modyfikacja danych. Stworzenie kopii dziennika transakcji (logu).
W tym punkcie będą znowu zmodyfikowane tabele bazy danych. Do przechowywania
zmian w porównaniu z „Kopią Full-backup...” będzie stworzona druga kopia dziennika
transakcji(logu).
- Wpisz w QUERY ANALYZER nowe rekordy do tabel: „Klienci”, „Miejsca”,
„Samochody”. Sprawdź przez polecenie SQL czy te rekordy zostały wpisane.
Do wpisania nowych rekordów może być wykorzystana instrukcja SQL :
INSERT INTO ... VALUES (...);
- Wykorzystując wiedzę z poprzedniego ćwiczenia w QUERY ANALYZER przy pomocy
instrukcji BACKUP LOG stwórz kopię dziennika transakcji (logu) bazy danych
„Samochody” na „Backup Device” „samochody_change” z opcją „with NOINIT”.
Sprawdź obecność kopii. Zwracaj uwagę na typ, czas stworzenia kopii oraz rozmiary
wszystkich kopii na urządzniu archiwizacyjnym (Backup Device).
12.Modelowanie sytuacji awaryjnej.
W tym punkcie będzie modelowana sytuacja gdy serwer SQL nie może uruchomić bazę
danych.
- Zamknij programy „Enterprise Manager” oraz „Query Analyzer”. Uruchom program „SQL
Server service” oraz zatrzymaj SQL Server.
- Odszukaj w „Windows Explorer” plik bazy danych „Samochody” w katalogu C:\Program
Files\Microsoft SQL Server\MSSQL\Data. Zmień nazwę pliku Samochody.mdf na
Samochody.bad.
- Zrestartuj SQL Server w programie “SQL Server service”.
- Uruchom „Enterprise Manager”. Rozwiń katalog „Databases”. Zwróć uwagę na komunikat
obok ikony „samochody”.
- Rozwiń katalog „Management -> SQL Server Logs”. Odczytaj ostatni „log” SQL serwera.
Odszukaj w tym „logu” rekord „Starting up database 'samochody'”. Przeanalizuj komunikaty
o błędach, które są w tym logu.
Przed realizacją następnych punktów przeanalizuj zawartość nośników archiwizacyjnych
(Backup Device) „Samochody_backup_2” oraz „Samochody_change”. Zwróć uwagę jakie
modyfikacje danych są zawarte w tych kopiach.
13.Odtwarzanie bazy danych z wykorzystaniem kopii różnicowych.
W tym punkcie będzie odtwarzana baza danych z istniejących kopii: kopii Full-Beckup oraz
kopii różnicowej.
- Uruchom „Enterprise Manager”. Rozwiń katalog Databases. Kliknij prawym przyciskiem
myszy na bazę „Samochody”. Wybierz „Wszystkie zadania ->Restore Database”. W polu
„Restore as database” wybierz „Samochody”. W polu „First backup to restore” wybierz
ostatnią kopię Full bazy danych „Samochody”. Na liście „Restore” wybierz tylko dwie kopie:
„Full” oraz kopię różnicową. Na zakładce „Option” ustaw tryb „Leave database read-only and
able to restore additional transaction logs.” Kliknji OK.
Przeanalizuj komunikat obok ikony „samochody”.
- Uruchom Query Analyzer. Utwórz polecenie SQL do odczytania zawartości tabel. Sprawdź
czy zostały odtworzone dane w tych tabelach.
14.Odtwarzanie bazy danych z wykorzystaniem kopii logów.
W tym punkcie będzie odtwarzana baza danych z istniejących kopii: kopii Full-Beckup oraz
kopii dziennika transakcji (logu).
- Uruchom „Enterprise Manager”. Rozwiń katalog Databases. Kliknij prawym przyciskiem
myszy na bazę „Samochody”. Wybierz „Wszystkie zadania ->Restore Database”. W polu
„Restore as database” wybierz „Samochody”. W polu „First backup to restore” wybierz
ostatnią kopię Full bazy danych „Samochody”. Na liście „Restore” wybierz tylko jedną
kopię: ostatnią kopie dziennika transakcji (logu). W zakładce „Option” ustaw tryb „Leave
database operational. No additional transaction logs can be restored.” Kliknji OK.
- Uruchom Query Analyzer. Utwórz polecenie SQL do odczytania zawartości tabel. Sprawdź
czy zostały odtworzone dane w tych tabelach.
Treść sprawozdania:
1. Odnośnie do każdego punktu ćwiczenia umieścić kod Transact-SQl oraz
wyniki .
2. Do kilku wybranych punktów zademonstrować własne przykłady
Przykładowe pytania kontrolne
1. Jaka jest różnica pomiędzy kopiami dziennika transakcji bazy danych oraz kopiami
różnicowymi?
2. Została przypadkowo usunięta tabela bazy danych. W jaki sposób można ją
odtwarzać?
3. Dlaczego przy odtwarzaniu bazy danych musi być ustalona opcja Restrict Access?
4. Omów zawartość różnych plików przechowywanych w urządzeniach archiwalnych
w tym ćwiczeniu.