Rozdział 7.
Tworzenie kopii bezpieczeństwa baz danych

W poprzednim rozdziale zostały omówione uprawnienia oraz przyznawanie uprawnień w celu ochrony baz danych. SQL Server 2000 jest dobrze zabezpieczony: użytkownicy nie mogą wykonać żadnej operacji dopóki nie zostanie im bezpośrednio przyznane uprawnienie do wykonywania poszczególnych operacji. Można łatwo przyznać użytkownikowi uprawnienia (grant) oraz cofnąć (revoke) przyznane uprawnienia.

Uprawnienia sumują się, więc należy dodawać uprawnienia, które użytkownik posiada, oraz uprawnienia jakie wynikają z przynależności użytkownika do grup Windows lub ról SQL Servera. Polecenie deny (wykonywanie zabronione) nadpisuje wszystkie inne uprawnienia.

Bieżący oraz kolejny rozdział pokazują być może najistotniejszy ale mniej interesujący aspekt obsługi relacyjnej bazy danych: tworzenie kopii bezpieczeństwa i odzyskiwanie baz po awarii. Nie ważne ile pracy zostanie włożone w zabezpieczenie baz danych i dostępnych informacji, ochrona danych przez zniszczeniem jest najważniejszą częścią pracy administratora. Jeżeli serwer uległ uszkodzeniu i wszystkie dane zostały utracone — administrator może utracić coś więcej — własną pracę. Niniejszy rozdział omawia proces tworzenia kopii bezpieczeństwa i typy kopii bezpieczeństwa obsługiwane przez SQL Server. Aby rozpocząć omawianie kopii bezpieczeństwa, należy przyglądnąć się jakie zabezpieczenia zostały zastosowane aby nie utracić informacji z dysków i aby SQL Server mógł pracować stabilnie.

Ochrona danych przy pomocy lustrzanego odbicia, dupleksowania i paskowania

Na początku zostanie omówiona odporność na błędy dysków serwera, tworzenie odbicia lustrzanego SQL Servera a następnie tworzenie kopii bezpieczeństwa i odzyskiwanie. Implementacja kopii bezpieczeństwa i odzyskiwania jest ochroną przed utratą danych; implementacja odporności na błędy dysków i urządzeń również ma na celu ochronę danych przed ich utratą. Implementacja odporności na błędy nie oznacza jednak, że nie ma potrzeby tworzenia kopii bezpieczeństwa baz danych.

Najlepiej jest zacząć od omówienia niektórych kluczowych pojęć. Dwa dyski tworzą lustrzane odbicie jeżeli zawierają dokładnie te same dane. Jeżeli jeden z dysków jest modyfikowany, drugi również jest modyfikowany (zobacz rysunek 7.1). Dupleksowanie dysku oznacza, że dyski tworzą odbicie lustrzane, ale każdy z dysków jest kontrolowany przez osobny kontroler dysku (taki jak karty SCSI — small computer system interface) — zobacz rysunek 7.2. Konfiguracja ta różni się od odbicia lustrzanego (mirroring) ponieważ dyski lustrzane używają tego samego kontrolera dysku, jako pokazano na rysunku 7.1.Striped rozmieszczają dane równomiernie na wielu dyskach, z częścią każdego logicznego elementu danych na każdym dysku w zestawie paskowym dysków (zobacz rysunek 7.3).

Rysunek 7.1. Odbicie lustrzane dysku.
Rysunek 7.2. Dupleksowanie dysku.
Rysunek 7.3. Paskowanie dysku.

Powyższe omówienie zakłada, że wykorzystywane są dyski SCSI. Ponieważ nie są one wymagane — serwery używane przez autorów do napisania tej książki korzystają ze standardowych dysków sztywnych Integrated Developement Environment (IDE) — na ogół dyski SCSI dostarczają lepszej wydajności i niezawodności w porównaniu z innymi dyskami (nie SCSI).

RAID

Tworzenie odbicia lustrzanego, dupleksowania i paskowania pasuje do schematu zwanego Redundant Array of Inexpensive Disks (RAID). Dyski są konfigurowane jako macierze RAID aby ochronić dane na dyskach i dostarczyć wyższej niezawodności. Jeżeli dane są chronione przed utratą dostępu, to można przez to odizolować użytkowników od większości błędów sprzętowych (użytkownicy nie będą wiedzieli o awarii sprzętowej). Poniżej przedstawiono siedem najpopularniejszych poziomów RAID:

RAID 0 Zestawy paskowane bez informacji o parzystości

RAID 1 Lustrzane odbicie dysku lub dupleksowanie

RAID 2, 3, 4 Poziomy prowadzące do RAID 5 (rzadko implementowane)

RAID 5 Zestawy paskowane z informacją o parzystości równomiernie rozmieszczonej pomiędzy paski.

RAID 10 Zestawy paskowane z parzystością tworzące odbicie lustrzane pomiędzy dwoma kontrolerami.

RAID 10 (zwany także RAID 1+0) staje się coraz częściej stosowany, ale nie jest na ogół ujmowany w listach opcji RAID w większości opracowań. Został tutaj umieszczony ponieważ użytkownik zetknie się prawdopodobnie z tym pojęciem w kontaktach ze sprzedawcami sprzętu. RAID 10 nie jest obecnie często używany, gdyż wymaga prawie dwa razy więcej przestrzeni dyskowej niż system RAID 5. Należy pamiętać, że RAID 10 nie tylko paskuje informacje, ale także tworzy odbicie lustrzane tych paskowych zbiorów pomiędzy kontrolerami. Jednak, w przypadku RAID 10, przeciwnie do RAID 5, nie jest przechowywana informacja o parzystości.

RAID 0 nie dostarcza odporności na błędy, co oznacza że nie jest użyteczny jeśli chodzi o zastosowanie go jako mechanizmu odporności na błędy. Jednak, jego zaletą jest wydajność. RAID 10 jest lepszą opcją jeśli chodzi o odporność na błędy, zapewniając stale dobrą wydajność.

RAID 1 jest to odbicie lustrzane lub dupleksowanie danych. Przy zastosowaniu odbicia lustrzanego, jeżeli karta SCSI kontrolująca zestaw lustrzany ulegnie uszkodzeniu, dane z dysku staną się niedostępne. Jednak, zawsze może się zdarzyć, że jeden z dysków ulegnie uszkodzeniu i dostęp do danych będzie nadal możliwy. Jeżeli zastosuje się dupleksowanie dysku, gdy ulegnie uszkodzeniu jeden z dysków lub jeden z kontrolerów dysków nadal jest możliwy dostęp do danych. Dlatego, dupleksowanie jest najlepszym mechanizmem zapewniania odporności na błędy (ale jest droższy, ponieważ wymaga dodatkowej karty kontrolera dysku).

RAID poziomu 2,3 i 4 były kolejnymi iteracjami paskowania z parzystością, zastąpionymi pod względem funkcjonalności przez RAID 5.

RAID 5 jest zbiorem trzech lub więcej dysków zgrupowanych logicznie. Każdy dysk zawiera „pasek”, sekcję danych lub informację o parzystości. W macierzy RAID 5 informacja o parzystości dla każdego z pasków jest rozmieszczana równomiernie poprzez cały zbiór dysków. Przykładowo, jeżeli zestaw paskowy RAID zawiera trzy dyski, może wyglądać tak, jak pokazano na rysunku 7.4.

Rysunek 7.4. Zestaw paskowy RAID 5 z kontrolą parzystości.

Informacja o parzystości jest obliczeniowym zbiorem wartości, które mogą być używane do ponownej kalkulacji zgubionych danych. Obecne wartości parzystości są dokładne do 1 na 2 biliony. Jeżeli zostanie utracony pojedynczy dysk danych, natomiast funkcjonują nadal inne dyski danych, jak również dysk parzystości, można odtworzyć utracone dane przy pomocy informacji o parzystości. Jeżeli zostanie uszkodzony dysk zawierający informacje o parzystości, nadal będą istniały wszystkie dane. Inaczej mówiąc, korzystając z macierzy RAID z parzystością nie dojdzie do utraty żadnych danych.

Na rysunku 7.4 w wierszu 1, połowa danych jest na dysku 1, druga połowa na dysku 2, a informacja o parzystości, (która, w połączeniu z dowolnym z dysków jest wystarczająca do odtworzenia utraconych danych) znajduje się na dysku 3. Wiersz 2 zawiera połowę danych na dysku 1, połowę na dysku 3 a informacje o parzystości na dysku 2. Wiesz trzeci zawiera podobne rozmieszczenie. Jeżeli do tego zbioru dodane zostanie więcej dysków, stanie się on korzystniejszy jeśli chodzi o narzuty kosztów, z większym ryzykiem zdarzenia, że więcej niż jeden dysk będzie niedostępny w tym samym czasie (ponieważ częstotliwość wystąpienia błędu dysku jest teoretycznie stała dla każdego z dysków). Pomimo, że rysunek 7.4 pokazuje tylko trzy dyski, można mieć tyle dysków, na ile pozwala sprzęt i oprogramowanie.

RAID 5 jest generalnie najbardziej akceptowym rozwiązaniem jako niedroga opcja, ponieważ ma najmniejsze narzuty kosztów — szczególnie jeżeli zwiększy się liczba dysków. RAID 10 jest na ogół rozważany jako najlepsze rozwiązanie dla instalacji SQL Servera typu high-end. Tworzenie odbicia lustrzanego lub dupleksowanie jest rozważane jako znacznie droższe ponieważ wymaga, aby używać dwukrotnie większej przestrzeni dyskowej do przechowywania danej ilości informacji.

Przykładowo, na serwer bazy danych potrzeba 27 GB dostępnej przestrzeni dyskowej. Zostaje wybrana implementacja RAID 5 korzystająca z dysków SCSI o rozmiarze 9GB (standard przemysłowy, w momencie pisania tej książki). Będą potrzebne przynajmniej 4 dyski: jeden dysk zostanie przeznaczony w całości na kontrolę parzystości, pozostawiając trzy dyski dostępne do przechowywania danych, trzy dyski x 9GB = 27 GB. Aby zaimplementować tą samą ilość danych przy pomocy odbicia lustrzanego potrzeba sześciu dysków o rozmiarze 9GB każdy.

RAID na poziomie sprzętowym

Wiele firm komputerowych implementuje rozwiązania sprzętowe RAID. Rozwiązania te zmierzają do dostarczenia najlepszej wydajności, w porównaniu z innymi rozwiązaniami, oprogramowaniem Windows NT RAID. Na ogół, sprzętowe rozwiązanie RAID jest implementowane ze specjalnymi kartami i może korzystać z zewnętrznych szafek dyskowych (samodzielnych lub w postaci szafek serwera — „racks”). Wadą korzystania z RAID sprzętowego jest to, że specjalne karty kontrolerów — w szczególności te dobre — są bardzo drogie. Można kupić wiele dysków za tę samą cenę co koszt jednej z tych kart. Wiele ludzi kupuje te karty, jednak muszą mieć do tego zapewne bardzo ważny powód.

Rozwiązanie programowe RAID z Windows 2000 Server

W przypadku rozwiązań opartych na SQL Serverze 2000 w systemie Windows 2000 Server (lub Windows NT Server), można korzystać z wbudowanych własności do implementacji technologii RAID na wielu zwykłych dyskach. RAID poziomu 0,1 i 5 jest zaimplementowany w produktach serwera Windows 2000.

Inne obsługiwane platformy Windows a technologia RAID

Systemy Windows 98/ME, Windows NT Workstation i Windows 2000 Professional nie obsługują tych własności programowych ale generalnie działają poprawnie na sprzętowych implementacjach RAID (ponieważ system operacyjny „nie jest świadomy”, że została zaimplementowana technologia RAID).

Wybór systemu plików

Inną sprawą do rozważenia przy korzystaniu z RAID i dysków jest wybór systemu plików dla SQL Servera. Obecnie, trzy systemy plików są obsługiwane przez Windows 9x, Windows NT i Windows 2000:

FAT zwany także FAT 16, jest systemem plików, który występuje od wczesnych wersji systemu MS-DOS. Ten system plików nie ma zabezpieczeń dla plików i nie obsługuje zaawansowanych opcji takich jak szyfrowanie. Generalnie ten system plików nie jest polecany dla SQL Servera.

FAT32 jest nowszą implementacją systemu plików FAT16. Implementuje znacznie efektywniejszy sposób przechowywania danych na dysku ale posiada te same ograniczenia co FAT w zakresie zabezpieczeń i szyfrowania. FAT32 został zaimplementowany w późniejszych wersjach Windows 95 (OSR2) i w pełni obsługiwany w wersji Windows 98 i Windows 2000. Warto zauważyć, że FAT32 nie jest obsługiwany w systemie Windows NT 4.0.

NTFS, New Technology File System, obsługuje wiele zaawansowanych własności, włączając w to kompresję i szyfrowanie (w Windows 2000), z których żadne nie powinno być używane w większości środowisk OLAP (Online Transaction Processing). Co ważniejsze, NTFS obsługuje przyznawanie uprawnień do pojedynczych katalogów i plików. Dlatego można ograniczyć dostęp do plików danych SQL Servera jedynie dla kont usługi SQL Server (i administratorów Windows).

Sposób działania kopii bezpieczeństwa

SQL Server 2000 tworzy kopie danych dynamicznie. Oznacza to, że nie ma potrzeby wyłączania bazy danych z użytkowania w celu stworzenia kopii bezpieczeństwa. Jak zawsze, dobrym sposobem jest uruchamianie procesu tworzenia kopii w czasie, gdy pracuje mniejsza cześć użytkowników, ponieważ tworzenie kopii zabiera część zasobów. Jednak, testy (benchmarks) pokazują, ze proces tworzenia kopii bezpieczeństwa ma niewielki wpływ na całkowitą wydajność pracy SQL Servera, zapytania użytkownika i modyfikacje.

Kopie bezpieczeństwa baz danych SQL Servera są spójne w momencie ukończenia kopiowania bazy danych. Dlatego, jeżeli tworzenie kopii zapasowej skończy się o 6 p.m., wiadomo, że obraz zawiera wszystkie dane do tego czasu.

We wszystkich wersjach SQL Servera przed wersją 7.0, kopia bezpieczeństwa była spójna w punkcie rozpoczęcia tworzenia kopii. Zmiana ta może być mało znacząca lub może mieć wpływ na wcześniej ustalone strategie wykonywania kopii bezpieczeństwa. Bez względu na wszystko zmiana ta jest warta uwagi.

Kopie bezpieczeństwa bazy danych i dziennika transakcji można przechowywać w plikach dynamicznie, lub można przewidzieć miejsce na nośnikach archiwizacyjnych. Nośnik archiwizacyjny może być fizycznym plikiem dyskowym, taśmą, zdalnym fizycznym plikiem dyskowym lub Named Pipe. Named Pipes jest na ogół używana w połączeniu z rozwiązaniami do tworzenia kopii bezpieczeństwa proponowanymi przez inne firmy. Najczęściej kopie bezpieczeństwa są tworzone na dysku lub na taśmie.

Kopie bezpieczeństwa bazy danych lub dziennika transakcji mogą tworzyć członkowie ustalonej roli systemowej sysadmin lub roli bazy danych db_owner lub db_backupoperator. Jak zostało powiedziane w rozdziale 6, można przyznać również innym uprawnienia do tworzenia kopii bezpieczeństwa bazy danych i dziennika transakcji.

Kopie bezpieczeństwa SQL Servera 2000 nie są zgodne z wcześniejszymi wersjami SQL Servera. SQL Server 2000 może czytać kopie bezpieczeństwa utworzone przy pomocy SQL Servera 7.0 ale nie może czytać kopii żadnych wcześniejszych wersji. Sprawa ta dotyczy głównie rozważań na temat uaktualnienia ale należy mieć tego świadomość podczas administracji SQL Serverem. Jedynym sposobem odczytania kopii bezpieczeństwa SQL Servera z wersji wcześniejszych niż 7.0 jest zainstalowanie wcześniejszej wersji i skorzystanie z kreatora SQL Server Version Upgrade Wizard dla bazy danych z SQL Servera 6.5 lub eksport/import danych z wcześniejszych wersji.

Typy kopii bezpieczeństwa

Można stworzyć kilka rodzajów kopii bezpieczeństwa w SQL Serverze 2000. Zostaną omówione: kopia bezpieczeństwa całej bazy danych (full), różnicowa kopia bazy danych (differential), kopie bezpieczeństwa pliku i grupy plików oraz kopie bezpieczeństwa dziennika transakcji. W tym rozdziale wszystkie kopie bezpieczeństwa z wyjątkiem kopii dziennika transakcji będą nazywane kopiami bazy danych.

Z powodów historycznych, kopie bezpieczeństwa nazywane są czasem dumps (zrzutami) lub database dumps.

Poniżej przedstawiono omówienie różnych typów kopii bezpieczeństwa:

Kopia bezpieczeństwa bazy danych — tworzy kopię całej bazy danych, włączając w to tabele, indeksy, tabele systemowe i obiekty bazy danych, (które są zawarte w tych tabelach systemowych). Kopia bezpieczeństwa bazy danych tworzy również kopię wpisów do dziennika transakcji ale nie przechowuje pustych stron ani nie usuwa z bazy danych żadnych wpisów w dzienniku transakcji.

Różnicowa kopia bezpieczeństwa bazy danych — tworzy kopię wszystkich stron danych, które były modyfikowane od czasu tworzenia ostatniej kopii całej bazy danych. Odtwarzanie z kopii tego typu jest szybsze niż odtwarzanie z kopii bezpieczeństwa dziennika transakcji. Proces odzyskiwania zostanie omówiony w kolejnym rozdziale.

Kopia bezpieczeństwa pliku i/lub grupy plików zakłada tworzenie kopii bezpieczeństwa jedynie wybranych plików lub grup plików, a nie całej bazy danych. Jeżeli jedna tabela lub więcej tabel lub indeksów ma zostać umieszczonych w odrębnych grupach plików zamiast pozostawienia wszystkich danych i indeksów w domyślnej grupie plików, można niezależnie utworzyć kopię danych. Zaletą tego rozwiązania jest to, że jeśli pojedynczy dysk ulegnie uszkodzeniu a została zrobiona kopia plików z tego dysku, można odtworzyć uszkodzone pliki bez potrzeby odtwarzania całej bazy danych. Ten typ kopii bezpieczeństwa jest szybszy niż odtwarzanie kopii całej bazy danych. Jednak, procedura ta jest poza zakresem prac jakie wykonuje na ogół administrator SQL Servera. Zaawansowane mechanizmy tworzenia kopii bezpieczeństwa są szczegółowo omówione w książce Microsoft SQL Server 2000 Unleashed wydanej przez Sams Publishing.

Kopia bezpieczeństwa dziennika transakcji zawiera kopię wpisów wszystkich zmian jakie zostały wykonane w bazie danych w zadanym czasie. Zawiera wyrażenia uruchamiane przez użytkowników, jak również działania drugoplanowe systemu, takie jak alokacja przestrzeni w bazie danych. Dzięki transakcjom zapisywanym w dzienniku można odtworzyć wszystkie działania (transakcje. Inną korzystną własnością dziennika transakcji jest to, że można powtórzyć (uruchomić ponownie) transakcje do określonego punktu w czasie. Więcej informacji na temat kopii tego typu zostanie przedstawionych w rozdziale 8.

Transakcje i punkty kontrolne

Transakcje (omówione szczegółowo w rozdziale 12) są logicznym zbiorem wszystkich operacji, które zakończyły się sukcesem lub tych, które zakończyły się niepowodzeniem. Każde polecenie modyfikacji danych uruchomione w bazie jest domyślnie transakcją i jest rejestrowane w dzienniku transakcji (zbiór wpisów w osobnym pliku bazy danych) dla każdej z baz danych. Można zażądać transakcji otwarcie, czyli wiele uruchomionych poleceń zakończy się sukcesem lub będzie nieudanych jak gdyby były pojedynczą operacją.

Można używać informacji zarejestrowanych w dzienniku transakcji do odtwarzania zmian w bazie danych do punktu w czasie innego niż ten, w którym była wykonywana kopia bezpieczeństwa. Inne zadania, takie jak alokacja przestrzeni, są również wpisywane do dziennika transakcji. Co jakiś czas dziennik transakcji wypełnia się, jeżeli nie jest tworzona jego kopia lub nie jest czyszczony (lub kiedy zapełni się dysk, na którym jest plik dziennika — jeżeli nie została wyłączona opcja automatycznego wzrostu pliku). Opcje autogrowth zostały omówione w rozdziale 4. Wykonane transakcje można usunąć z pliku dziennika przy pomocy polecenia BACKUP LOG, omówionego później. Jeżeli transakcja jest zakończona (wszystkie modyfikacje danych zostały wykonane pomyślnie), wpisy w dzienniku transakcji są od razu zapisywane na dysk. Jest to część, która gwarantuje, że baza danych będzie mogła być odtworzona w przypadku awarii. Jednak, co powoduje zapisanie stron danych na dysk? Odpowiedzią są punkty kontrolne.

Punkty kontrolne (checkpoints)

Rozdział 12 dostarczy pełnego wytłumaczenia procesu korzystania z punktów kontrolnych, tutaj wymagane jest pobieżne wyjaśnienie. Punkt kontrolny jest okresową operacją, kopiującą na dysk strony danych, które były modyfikowane w pamięci. Wiele zdarzeń można powodować zapisywanie na dysk stron danych i wpisów dziennika. Jednak, punkty kontrolne są podstawowym mechanizmem synchronizacji bazy danych pomiędzy zdarzeniami w pamięci, a tym co zostało fizycznie zapisane na dyskach. Punkt kontrolny jest również zarejestrowaną transakcją, co oznacza, że punkt kontrolny jest również zapisywany w dzienniku transakcji i zachowywany na dysku.

Inne strategie tworzenia kopii bezpieczeństwa

Niektórzy administratorzy wierzą, że alternatywnym sposobem tworzenia kopii bezpieczeństwa SQL Servera jest zatrzymanie usługi SQL Server a następnie utworzenie kopii wszystkich plików związanych z SQL Serverem (w szczególności plików z foldera \mssql\data). Jednak, podejście to nie jest w pełni funkcjonalne ponieważ może nie pozwolić na odtworzenie baz danych indywidualnie i nie zapewnia możliwości przeprowadzenia odtwarzania bazy do punktu w czasie. Dlatego zalecane jest stosowanie kopii bezpieczeństwa SQL Servera a nie bezpośrednie tworzenie kopii plików. Warto również zauważyć, ze tworzenie „normalnych” kopii przez system Windows nie tworzy kopii plików urządzeń SQL Servera podczas pracy SQL Servera ponieważ w tym czasie pliki są otwarte i nie jest możliwe ich kopiowanie.

Terminologia związana z kopiami bezpieczeństwa

SQL Server 2000 korzysta z kilku pojęć zawartych w dokumentacji i interfejsie użytkownika dotyczących kopii bezpieczeństwa. Po uruchomieniu pojedynczego polecenia tworzenia kopii zapasowej otrzymuje się zbiór backup set. Jest to kopia zapasowa bazy danych ulokowana na nośniku archiwizacyjnym (nośniki archiwizacyjne zostaną omówione później). Podczas tworzenia kopii bezpieczeństwa tworzony jest również media set. Media set jest to zbiór jednego lub wielu nośników archiwizacyjnych używanych podczas tworzenia kopii lub zestawu kopii. Jest on szczególnie przydatny, przy sprawdzaniu możliwości SQL Servera do utworzenia kopii na wielu nośnikach. Własność ta, zwana parallel striped backup zostanie omówiona w dalszej części rozdziału.

Innym potrzebnym pojęciem jest media family, które odnosi się do wszystkich typów taśm używanych w jednej sesji archiwizacji. Czyli, jeżeli kopia bezpieczeństwa zajmuje pięć taśm, te pięć taśm razem zwane są media family tej kopii. W tym przypadku, jest to zasadniczo to samo co zestaw kopii (backup set). Jeżeli tworzona jest kopia równolegle paskowana (parallel striped backup), każdy zestaw taśm z każdego napędu taśmowego jest zwany media family.

Brzmi dziwnie? Być może, ale te pojęcia występują w dokumentacji Microsoft na temat kopii bezpieczeństwa i odzyskiwania baz danych. Dobrą wiadomością jest to, że można stworzyć wiele kopii bezpieczeństwa i nigdy nie używać tych pojęć. Złą wiadomością jest natomiast to, że można spotkać się czasem z tymi pojęciami, i dobrze jest wiedzieć, o czym mówi dokumentacja.

Rozważania dotyczące tworzenia kopii bezpieczeństwa

Należy odpowiedzieć sobie na wiele pytań przystępując do tworzenia kopii bezpieczeństwa:

jak często należy tworzyć kopie baz danych?

które bazy danych należy archiwizować?

gdzie będą przetrzymywane kopie bezpieczeństwa?

jak długo powinny być przetrzymywane?

kto odpowiada za archiwizację danych i jak będzie sprawdzana poprawność wykonanych kopii?

Teraz należy przestudiować wszystkie pytania, rozpoczynając od osób odpowiedzialnych.

Kto odpowiada za archiwizację danych?

„ Jeżeli zadanie nie jest przypisane do kogoś, to nie zostanie wykonane”. Jeżeli chodzi o tworzenie kopii bezpieczeństwa, to zdanie jest szczególnie prawdziwe. Tworzenie kopii bezpieczeństwa jest nudne. Dużo pracy zajmuje poprawne skonfigurowanie tworzenia kopii i jego regularne testowanie. Odpowiedzialność za tworzenie kopii bezpieczeństwa spada na ogół na administratora bazy danych lub administratora systemu. Może się zdarzyć, że administrator sieci będzie chciał pomóc w tworzeniu kopii bezpieczeństwa. Istotne jest, aby były to konkretne osoby odpowiedzialne za dane zadanie.

Jak będzie sprawdzana poprawność utworzonych kopii bezpieczeństwa?

Jeżeli baza danych zostaje uszkodzona, nadal pozostaje możliwość utworzenia jej kopii. Może się jednak zdarzyć, że taka możliwość nie będzie istniała. Może się zdarzyć, że nie pojawi się nawet komunikat ostrzegający o uszkodzeniu. Powinno się uruchomić pewne testy sprawdzające (krótko omówione) zanim rozpocznie się tworzenie kopii. SQL Server uruchamia wewnętrznie wiele testów kontrolnych w celu wykrycia uszkodzenia (czasem może nawet naprawić uszkodzenie). Jeżeli sprawdzenie spójności nie zostanie uruchomione lub wyniki nie zostaną sprawdzone przed rozpoczęciem archiwizacji, nie będzie można powiedzieć, czy kopie są poprawne, aż do momentu ich odtworzenia.

Dobrze jest okresowo sprawdzać kopie poprzez odtworzenie danych z jednej z nich, aby przetestować serwer i upewnić się, że wszystko działa zgodnie z oczekiwaniami. Tą drogą wiadomo, czy kopie bezpieczeństwa są poprawne i można okresowo testować proces odtwarzania. SQL Server 2000 zawiera możliwość weryfikacji integralności kopii bezpieczeństwa po jej utworzeniu. Oprócz tego, nie zdarza się, żeby administratorzy byli zwalniani z pracy, ponieważ paranoicznie tworzą plany archiwizacji i odtwarzania.

Które bazy danych należy archiwizować?

Rada może wydać się oczywista — należy tworzyć kopie bezpieczeństwa wszystkich baz danych zdefiniowanych przez użytkownika. Jeżeli tworzenie bazy danych i umieszczanie jej na serwerze jest ważne, tworzenie kopii bezpieczeństwa tej bazy powinno być równie istotne. Jak wygląda sprawa z bazami systemowymi? Należy tworzy kopie bazy master i MSDB. Posiadanie kopii bazy model może być przydatne, ale nie ma potrzeby archiwizować bazy temdb. Jeżeli używana jest replikacja, powinno się również regularnie tworzyć kopie bezpieczeństwa bazy dystrybucyjnej. Zalecane jest traktowanie tej bazy jak innych baz często modyfikowanych przez użytkownika.

Gdzie będą przechowywane kopie bezpieczeństwa?

Jak zostało powiedziane wcześniej, może tworzyć kopie na dysku, taśmie, dysku sieciowym lub Named Pipe. Taśma jest nośnikiem preferowanym przez większość ludzi ale ma kilka znaczących ograniczeń. Jednym z nich jest szybkość. Tworzenie kopii na dysku jest zwykle najszybsze. Jako alternatywa można tworzyć kopię bazy danych na innym dysku serwera w sieci. Powinno się archiwizować dyskowe kopie bezpieczeństwa na taśmie, nawet jeśli są to kopie na dysku lokalnym lub na innym dysku serwera. Typowy scenariusz zakłada utworzenie kopii na serwerze sieciowym poprzez szybkie połączenie sieciowe (100MB Ethernet, ATM itp.) a następnie skorzystanie z wbudowanego programu archiwizacji Windows 2000 aby utworzyć kopię urządzeń archiwizujących lub plików. Alternatywą jest zakup narzędzia archiwizacyjnego innej firmy, (które będzie lub nie wykorzystywać opcję Named Pipe). Większość głównych grup narzędzi archiwizujących zawiera dodatek do tworzenia kopii bezpieczeństwa baz danych SQL Servera.

Jeżeli szybkość taśm wzrośnie, będzie to preferowany typ nośnika dla kopii bezpieczeństwa. Ograniczeniem dla kopii bezpieczeństwa SQL Servera (w pojęciu szybkości) jest na ogół prędkość napędów taśmowych, a nie prędkość SQL Servera.

Jak często należy tworzyć kopie bezpieczeństwa baz danych?

Odpowiedź na pytanie jak często należy tworzyć kopie bezpieczeństwa zależy od rozmiaru bazy danych oraz tego, jak szybko powinien się wykonywać proces odtwarzania. Dla baz danych o rozmiarach mniejszych niż kilka gigabajtów, zwykle kopia całej bazy danych wykonywana jest codziennie, z kopiami dziennika transakcji, o określonych porach w ciągu dnia. Jako minimum powinno się tworzyć kopie baz danych raz na tydzień, z co najmniej raz dziennie wykonywaną kopią dziennika transakcji. Na temat systemowych baz danych zostaną przedstawione osobne rozważania.

Jeżeli baza danych rozrasta się znacząco, można nie mieć wystarczającej ilości czasu aby codziennie wykonywać pełną kopię bazy. Jednak, jeżeli napędy taśmowe staną się szybsze (lub skorzysta się z zalet kopii równoległych) to ograniczenie może przestać istnieć. Ponownie, oprogramowanie SQL Servera 2000 nie jest ograniczeniem szybkości tworzenia kopii bezpieczeństwa.

Jak długo należy przechowywać kopie bezpieczeństwa?

Możliwe, że niektóre kopie nie będą potrzebne aż do czasu gdy stworzy się nowe. Jest to zwykle dobry pomysł, jednak dobrze jest przechowywać kilka kopii, na wypadek gdy jakaś z wcześniejszych kopii okaże się uszkodzona. Wiele firm wybrało okres dwóch tygodni jako arbitralny okres przechowywania kopii bezpieczeństwa. Można również przechowywać dane z powodów prawnych, np.: dane podatkowe wymagające kilku lat przechowywania ich kopii. Należy poznać te wymagania zanim określi się zasady przechowywania kopii bezpieczeństwa. Najgorszą rzeczą jest obciążenie winą za to, że dane nie były przechowywane wystarczająco długo.

Jak długo zajmuje odtwarzanie danych z kopii bezpieczeństwa?

Nie ma nic gorszego niż awaria serwera, za wyjątkiem tego, gdy szef zapyta, jak długo zajmie odzyskanie danych serwera, a administrator nie będzie miał pojęcia ile czasu to potrwa. Dlatego, regularne testowanie odtwarzania z kopii bezpieczeństwa może pomóc uniknąć zakłopotania w trudnych sytuacjach i pomóc w lepszym zrozumieniu procesu odtwarzania. Proces odtwarzania zostanie omówiony w kolejnym rozdziale.

Czy posiadam plan odzyskiwania danych po awarii?

Jedna z najlepszych rzeczy jakich dokonano w erze dużych systemów komputerowych dotyczy planu odtwarzania w przypadku awarii i uruchamiania od czasu do czasu testowych ćwiczeń „awaryjnych”. Autor opisuje swoje uczestnictwa w takim ćwiczeniu: „Zabraliśmy taśmy, wsiedliśmy do samolotu, przylecieliśmy do oddziału archiwizacji, uruchomiliśmy nasz system komputerowy (mainframe) i bazy danych”. Należy skorzystać z takiego ćwiczenia aby przetestować plan tworzenia kopii bezpieczeństwa i sprawdzić, czy wszystko co potrzeba jest zarchiwizowane. Zdumiewające jest, o jak wielu rzeczach można zapomnieć. Mogą się pojawić interesujące pytania — czy dany oddział firmy ma dostępny ten sam model/markę napędu taśmowego? Czy pamiętało się, aby wziąć oprogramowanie, które może być potrzebne w procesach archiwizacji?

Należy rozważyć włączenie do planu następujących typowych elementów:

system Windows NT/2000 na płycie CD

ostatni pakiet serwisowy dla Windows NT/2000

płytę SQL Server 2000, wraz z najnowszymi pakietami serwisowymi

oprogramowanie specyficzne dla aplikacji lub zewnętrzne biblioteki DDL (rozszerzone procedury składowe) które są związane z SQL Serverem, włączając w to oprogramowanie firm trzecich do tworzenia kopii bezpieczeństwa i odzyskiwania (jeżeli jest używane).

własne kopie bezpieczeństwa

Nie trzeba koniecznie wsiadać do samolotu jeżeli posiada się pewność, że nikt nie oszukuje i nie zabiera ostatniego pliku jaki był potrzebny z sieci lub nie podkrada go z biurka.

Należy również odpowiedzieć sobie na pytania:

Czy wiem na jakim napędzie jest zainstalowany SQL Server?

Czy wiem jaka strona kodowa i kolejność sortowania zostały użyte?

Jakie biblioteki sieciowe są zainstalowane?

Z jakich kont użytkowników w sieci korzysta SQL Server?

Jakie dyski i nazwy plików zostały użyte w każdej bazie danych?

Jaki profil mailowy został użyty do automatycznej wymiany poczty z SQL Serverem?

W przypadku większej ilości SQL Serverów, poradzenie sobie z awarią może szybko stać się niemożliwe bez posiadania planu. Być może plan ten wymaga poważnego przemyślenia zanim zdarzy się awaria systemu. Należy pamiętać, że awaria może się zdarzyć w każdym momencie. Powodzie, pożar, grad, tornada, huragany, trzęsienia ziemi, wulkany, sabotaż i kłopoty wywoływane przez samego użytkownika (np.: słabo napisane transakcje) są poważnymi problemami, często różnymi w różnych częściach świata.

Gdzie są przechowywane taśmy z kopiami bezpieczeństwa?

Czy taśmy z kopiami bezpieczeństwa są przechowywane w szufladach biurka administratora? Na serwerze? W napędzie taśmowym serwera? Gdyby trzęsienie ziemi zrównało z ziemią dany budynek (i wszystkie budynki wokoło także) czy nadal można byłoby dostać się do budynku, nie mówiąc już o dostępie do taśm z archiwum? Należy zainwestować w osobną lokalizację dla taśm poza daną siedzibą firmy. Niektóre firmy dają taśmy pracownikom aby przechowywali je w domu. Lepszym rozwiązaniem dla relatywnie małych baz danych jest złożenie ich kopii w bezpiecznej skrytce depozytowej w banku. Dla większych kopii, istnieją specjalne firmy specjalizujące się w bezpiecznym przechowywaniu kopii poza siedzibą firmy. Renomowane firmy zajmujące się przechowywaniem archiwum dostarczają i odbierają taśmy i mogą nawet zabrać je lub dostarczyć w sytuacji awaryjnej (za normalną opłatą). Należy sprawdzić zabezpieczenie miejsca przechowywania taśm i zweryfikować czy firma przedsięwzięła odpowiednie kroki (i zabezpieczenia) aby ochronić najważniejszą rzecz w danej organizacji — posiadane informacje.

Wybór z różnorodnych taśm

Jeżeli zapadnie decyzja, że kopie bezpieczeństwa będą tworzone na taśmach, należy mieć na uwadze następujące czynniki:

SQL Server zapisuje na taśmę przy użyciu nagłówków taśmy American National Standards Institute (ANSI). Oznacza to, że SQL Server może współdzielić taśmy z kopiami systemu Windows NT lub Windows 2000.

SQL Server korzysta z programu konsoli aby poinformować operatora o potrzebie zmiany taśmy (jeżeli program jest uruchomiony).

Można przechowywać więcej niż jedną kopię bezpieczeństwa na taśmie.

W przypadku planowania skorzystania ze specjalnych własności pojedynczego napędu taśmowego, takich jak kompresja sprzętowa, należy się upewnić czy ten sam model będzie dostępny gdy zajdzie potrzeba odtworzenia bazy przy pomocy taśmy. Jest to prawdziwe szczególnie jeżeli planuje się przechowywać taśmy przez długi czas. Należy się upewnić, czy dany rodzaj napędu taśmowego będzie nadal dostępny w ciągu najbliższych 5 lat.

Tworzenie kopii bezpieczeństwa baz użytkownika

Bazy danych utworzone przez użytkownika powinny być archiwizowane regularnie. Jako minimum przyjmuje się tworzenie co tydzień kopii całej bazy danych i codzienne tworzenie kopii dziennika transakcji. Preferowane jest tworzenie kopii bazy danych codziennie, z okresowym tworzeniem kopii dziennika transakcji. Należy pamiętać, że kopiowanie całej bazy danych nie usuwa transakcji z dziennika transakcji bazy danych. Kopia różnicowa również nie usuwa wpisów z dziennika transakcji.

Poniżej przedstawiono kilka przypadków nie wymagających regularnego tworzenia kopii bezpieczeństwa bazy danych:

jeżeli baza danych jest w trybie tylko-do-odczytu, pojedyncza kopia (sprawdzona) jest na ogół wystarczająca.

jeżeli jest to testowa baza danych i dane nie są istotne lub są łatwe do odtworzenia.

dane mogą być szybko zrekonstruowane z alternatywnego źródła.

Jednak, należy się skupić na przypadkach, kiedy potrzeba utworzyć kopie baz danych. Jeżeli baza danych jest duża (większa niż kilka gigabajtów), można chcieć utworzyć jej kopię zaraz po utworzeniu bazy. Jest całkiem możliwe, że szybsze będzie ponowne utworzenie bazy danych przy pomocy opcji FOR LOAD wymienionej w rozdziale 4 a następnie odtworzenie bazy z kopii bezpieczeństwa.

Modele odtwarzania baz danych i kopie bezpieczeństwa

SQL Server 2000 wprowadził modele odtwarzania, które pozwalają określić jak wiele transakcji w bazie danych ma być rejestrowanych. Określenie modelu odtwarzania dla bazy danych drastycznie zmienia dozwolone typy kopii bezpieczeństwa oraz sposób przeprowadzania odtwarzania. Jednak, należy rozumieć wszystkie modele aby wiedzieć, który rodzaj wybrać.

Przyczyną posiadania różnych modeli odtwarzania jest to, że mogą być potrzebne różne poziomy dostępu do przywracania bazy danych. Jedną z przyczyn, dla których pojawiają się różne potrzeby rejestrowania są operacje masowe (we wcześniejszych wersjach często nazywane nonlogged operations). Operacje takie jak ładowanie dużej ilości danych może oznaczać, że stworzenie kopii bezpieczeństwa jest potrzebne jedynie przed i po operacji ładowania danych, ale nie podczas tej operacji. Modele odtwarzania w pełni obsługują ten typ konfiguracji poprzez model odtwarzania bulk-logged.

Inną popularną konfiguracją jest odtworzenie całości bazy danych (model full). Przykładowo, jeżeli baza danych zmienia się jedynie raz dziennie a poza tym jest przeznaczona tylko do odczytu, najlepiej zastosować model simple.

Model Full recovery

Model Full recovery jest najczęściej uruchamianym modelem. Model ten obsługuje wszystkie kopie baz danych (pełną, różnicową, kopię dziennika transakcji, kopię pliku/grupy). Można odtworzyć dane do punktu w czasie lub do „zaznaczonej” transakcji (co zostanie omówione później). Zasadniczo, jeżeli ma się uzyskać ochronę danych w 100% (i ochronę zadań), należy ustawić model Full recovery i nie zmieniać go. Jest to domyślne ustawienie dla nowej bazy tworzonej przy pomocy wersji Standard i Enterprise Editon SQL Servera.

Model Bulk-logged recovery

Po wykonaniu wybranych poleceń, takich jak SELECT INTO, BULK INSERT, CREATE INDEX, WRITETEXT i UPDATETEXT, zostają zapisane bardzo duże ilości danych. Przy zastosowaniu modelu Full recovery, każdy wiersz dodawany do SQL Servera jest w pełni odtwarzany w dzienniku transakcji. Można sobie wyobrazić, że oznacza to, że dane są zapisywane dwukrotnie. Zapewnia to maksimum możliwości odtworzenia danych ale może być nadmierne w stosunku do potrzeb.

W trybie Bulk-logged, dane modyfikowane przez te polecenia nie są w pełni rejestrowane; obrazy modyfikowanych stron są rejestrowane po załadowaniu strony. Z powodu metody używanej do rejestracji danych w bazie nie jest możliwe odtwarzanie do punktu w czasie. Można odtworzyć jedynie do punktu końcowego kopii bazy danych lub do końca kopii bezpieczeństwa dziennika transakcji.

Innym zagadnieniem związanym z trybem bulk-logged jest pytanie, co nastąpi w przypadku utraty pliku danych. Kiedy ustawiony jest tryb full recovery, wystarczy zrobić kopię dziennika transakcji a następnie przeprowadzić odtworzenie bazy danych (w kolejnym rozdziale zostanie powiedziane jak to zrobić). Jednak, kopie dziennika transakcji tworzone w trybie bulk-logged wymagają dostępu do bazy danych. Jeżeli pliki bazy danych są uszkodzone, nie można zrobić kopii dziennika transakcji i można utracić pracę. Sytuacja ta może nie stanowić problemu (być może kopia została prawidłowo wykonana przed rozpoczęciem ładowania danych do bazy), ale na pewno należy być świadomym tych zagrożeń.

Model Simple recovery

Model simple recovery jest najbardziej restrykcyjny. Zasadniczo, model ten jest używany gdy jedyne co jest istotne to powrót do ostatniej pełnej kopii bezpieczeństwa lub kopii różnicowej. Kopie bezpieczeństwa dziennika transakcji są dostępne i dziennik transakcji jest okresowy czyszczony.

W SQL Server 7.0 i wcześniejszych wersjach, aby uzyskać ekwiwalent modelu simple recovery były ustawiane opcje na poziomie bazy danych Truncate Log on Checkpoint oraz Select Into/bulkCopy.

Jeżeli baza danych jest taka, że jedyne co potrzeba zrobić w razie awarii, to odtworzyć dane do pojedynczego punktu w czasie (do czasu tworzenia ostatniej kopii całkowitej lub różnicowej), to dobrze jest zastosować prostą rejestrację (simple logging). Najmniejsza możliwa ilość informacji jest rejestrowana w dzienniku transakcji i dziennik utrzymuje najmniejszy rozmiar. Występuje nadal rejestracja niektórych transakcji więc SQL Server może zachować wewnętrzną spójność i obsługiwać obiekty takie jak wyzwalacze, używające dziennika transakcji.

Zasadniczo, nie należy nigdy ustawiać modelu simple recovery w bazie danych, w której ma być możliwość uruchamiania zapytań modyfikujących dane. Wtedy nie należy się też spodziewać, że będzie możliwość odtworzenia bazy danych. Jest to dobre dla prostych baz danych, statycznych baz, które się nie zmieniają, lub baz, w których można łatwo odtworzyć wykonaną pracę, ale nie należy używać tego trybu w bazach danych produkcyjnych gdzie użytkownicy interaktywnie dodają, zmieniają lub usuwają dane.

Aby zobaczyć jaki model odtwarzania danej bazy jest uruchomiony należy wpisać kod:

Select BATABASEPROPERTYEX ('mydb', 'recovery')

W odpowiedzi system określi nazwę używanego modelu: FULL, BULK_LOGGED lub SIMPLE.

Bazy danych pubs i Nortwind korzystają z modelu SIMPLE. Jednak, baza danych model ma ustawiony typ odtwarzania FULL. Należy pamiętać, że tworzenie bazy danych zawiera po pierwsze kopiowanie bazy model, więc własności bazy model są dziedziczone przy tworzeniu nowej bazy.

Aby zmienić model odtwarzania, należy skorzystać z polecenia ALTER DATABASE. Można uruchomić następujące polecenie aby zmienić model bazy danych pubs na wartość FULL:

Alter database pubs SET RECOVERY FULL

Tworzenie kopii bezpieczeństwa systemowych baz danych

Następnie zostaną omówione bazy systemowe oraz to, jak często należy tworzyć ich kopie. Systemowe bazy danych to master, model, MSDB i tempdb. Strategia wykonywania kopii tych baz jest inna niż stosowana dla baz danych tworzonych przez użytkownika.

Baza danych master

Baza danych master jest specjalną bazą systemową. Jeżeli baza master zostanie z jakiegoś powodu uszkodzona, SQL Server 2000 nie może funkcjonować. Dlatego, bardzo ważne jest żeby wiedzieć jak i kiedy trzeba wykonywać jej kopie zapasowe.

Inaczej niż w przypadku wersji 6.x i wcześniejszych SQL Servera, baza danych master jest trzymana we własnym zbiorze plików, z dziennikiem transakcji w osobnym pliku. W przypadku uaktualniania z SQL Server 6.5 lub wcześniejszej, należy pamiętać o zmianach jakie nastąpiły.

Firma Microsoft zaleca aby tworzyć kopię bezpieczeństwa bazy master za każdym razem, kiedy została ona zmodyfikowana. Z praktycznego punktu widzenia, tworzenie kopii za każdym razem jest naprawdę możliwe w większości środowisk. Należy rozważyć elementy znajdujące się w bazie master: bazy danych, konta logowania, komunikaty systemowe i użytkownika informujące o błędzie i wiele innych. Przykładowo, konta logowania zawierają hasła. Nie jest praktykowane tworzenie kopii bazy danych master za każdym razem, gdy ktoś zmieni hasło. Zaleca się tworzenie kopii bazy danych master codziennie. Oznacza to, że wszelkie zmiany haseł dokonane po ostatnim tworzeniu kopii bezpieczeństwa po otworzeniu nie są ustawione prawidłowo. Jednak, stosuje się to jedynie do kont stworzonych przy pomocy zabezpieczeń SQL Server Authentication Mode.

Jest również bardzo istotne aby tworzyć kopię bezpieczeństwa bazy danych master gdy zostaje dokonana znacząca zmiana dotycząca serwera, taka jak zmiany konfiguracyjne: tworzenie, zmiany lub usuwanie baz danych; dodawanie zdalnych lub przyłączonych serwerów lub włączenie replikacji.

Domyślnie, baza danych master ma ustawiony tryb simple recovery. Należy pozostawić ten tryb odtwarzania, ponieważ można wykonywać jedynie całkowite kopie bazy danych master. Kopie różnicowe, kopie plików/grup i kopie dziennika transakcji nie są dostępne dla bazy danych master.

Baza danych MSDB

Baza danych MSDB zawiera informacje o obsłudze usługi SQL Server Agent oraz o obsłudze operacji replikacji. Jeżeli jest stosowana usługa SQL Server Agent (a powinna być stosowana), należy wykonywać regularne kopie tej bazy danych.

Jako reguła, baza danych MSDB powinna być archiwizowana co najmniej raz w tygodniu, z codziennym tworzeniem kopii dziennika transakcji. Podobnie jak w przypadku baz danych użytkownika, można rozważyć częstsze wykonywanie kopii. Można zsynchronizować wykonywanie kopii bezpieczeństwa z bazą danych master. Jeżeli zachodzi potrzeba odbudowania bazy master (na ogół w przypadku poważnego uszkodzenia nośnika), baza danych MSDB jest reinicjalizowana i dlatego musi być odtworzona z kopii bezpieczeństwa.

Z pewnych powodów firma Microsoft ustawiła tryb odtwarzania simple dla bazy MSDB. Nie jest to zrozumiały wybór i autor niniejszej książki radzi zmienić tryb odtwarzania na FULL dla bazy MSDB lub zmienić zalecenia i codziennie tworzyć pełne kopie bazy MSDB.

Baza danych model

Baza danych model nie będzie się zapewne często zmieniać. Po dodaniu tablic, widoków, zabezpieczeń i procedur składowych stworzonych przez użytkownika do tej bazy, pozostaje tylko kilka modyfikacji raz na jakiś czas. Jednak, ponieważ ostrożność administratora to bardzo przydatna cecha, dobrze jest mieć kopię tej bazy. Jeżeli zachodzi potrzeba odbudowania bazy danych master, zerowana (resetowana) jest również baza model.

Baza danych tempdb

Baza danych tempdb jest resetowana przy każdym ponownym uruchomieniu usługi MSSQLServer service. Dlatego, nie ma potrzeby tworzenia kopii bazy danych temdb. Należy pozostawić bazę tempdb w trybie SIMPLE aby dziennik transakcji nie rozrastał się niepotrzebnie.

Dystrybucyjna baza danych

W przypadku używania replikacji, dystrybucyjna baza danych przechowuje replikowane transakcje. Replikacja zostanie omówiona szczegółowo w rozdziale 17. Należy traktować dystrybucyjną bazę danych jako ważną bazę danych użytkownika; zalecane jest codzienne tworzenie kopii tej bazy i okazjonalne archiwizowanie dziennika transakcji. Wykonywanie częstszych kopii jest możliwe jeśli pozwala na to czas i koszty konserwacji (utrzymania).

Przygotowanie do implementacji archiwizacji

Znając już teorię na temat kopii bezpieczeństwa baz danych można skupić się na fizycznej implementacji kopii. Zostały omówione kopie całkowite, różnicowe oraz kopie plików i grup. Omówiono również kopie dziennika transakcji. Na zakończenie tej sekcji użytkownik może przetestować konfigurację rzeczywistego serwera i utworzyć plan archiwizacji dla danego serwera.

W tym rozdziale poruszono kilka tematów, które potrzeba znać. Należy przechowywać gdzieś kopie bezpieczeństwa i należy zweryfikować integralność kopii bezpieczeństwa i baz danych.

Tworzenie narzędzia archiwizacyjnego

Pierwszym krokiem w przygotowaniu do wykonywania kopii baz danych jest utworzenie narzędzia archiwizacyjnego. Pomimo tego, że nie ma technicznie potrzeby posiadania predeklarowanych narzędzi archiwizujących, upraszcza to składnię poleceń archiwizujących, jak również pomaga administratorowi, który musi pracować w systemie po zakończeniu pracy przez użytkowników.

Narzędzie archiwizujące jest to wskaźnik, w katalogu systemowym SQL Servera (tabela systemowa sysdevices w bazie danych master), zawierający logiczną nazwę i fizyczną ścieżkę dostępu do pliku lokalnego dysku sztywnego, lokalnego napędu taśmowego lub zdalnego pliku na innym komputerze. Kopie bezpieczeństwa nie mogą być wykonywane przy pomocy zdalnych napędów taśmowych. Po określeniu polecenia BACKUP, należy odwołać się raczej do logicznej nazwy niż określać pełną ścieżkę i nazwę pliku za każdym razem. Podejście to pomaga zredukować nakład czasu na powtarzające się wpisywanie wszystkich informacji i jest mniej narażone na błędy.

Po pierwszym zainstalowaniu SQL Servera 2000, w systemie nie są zdefiniowane żadne urządzenia do tworzenia kopii bezpieczeństwa. Jednym z pierwszych kroków jest utworzenie tych narzędzi. Jeżeli kopie mają być tworzone na napędach taśmowych, na ogół tworzy się pojedynczy wskaźnik do urządzenia taśmowego. Oczywiście, jeżeli serwer ma wiele napędów taśmowych, należy utworzyć osobne urządzenie dla każdego z napędów.

W przypadku urządzeń dyskowych (lub sieciowych) na ogół można tworzyć jedno urządzenie archiwizujące dla jednej bazy danych. Dobrze jest na początek zdefiniować urządzenia archiwizujące dla baz systemowych, które istnieją na serwerze.

Kontrolowanie urządzeń archiwizacyjnych przy pomocy Transact-SQL

Można utworzyć urządzenie archiwizujące przy pomocy systemowej procedury składowej sp_addumpdevice:

sp_addumpdevice [@devtype =] 'device_type',

[@logicalname =] 'logical_name', [@physicalname =] 'physical_name'

[, {[@cntrltype =] cntrltype |

[@devstatus =] 'device_status'}]

Znaczenie składni:

device_type jest typem urządzenia, na które ma wskazywać urządzenie archiwizujące. Jest to jeden z możliwych wariantów:

Disk wskaźnik do fizycznego pliku na lokalnym dysku twardym

Tape wskaźnik do lokalnego napędu taśmowego

Pipe wskaźnik do Named Pipe

logical_name jest nazwą, jaka ma być używana dla kopii bezpieczeństwa przez polecenia odtwarzania, przy odwoływaniu się do fizycznego położenia kopii.

physical_name jest fizyczną lokalizacją urządzenia archiwizacyjnego. Dla dysków, będzie to ścieżka i nazwa pliku. Dla taśmy, będzie to wskaźnik do napędu taśmowego. Dla Named Pipe jest to adres sieciowy biblioteki Named Pipe.

cntrltype jest przestarzałym parametrem obsługiwanym dla zachowania zgodności z wcześniejszymi wersjami.

device_status określa czy nagłówki ANSI taśmy są ignorowane podczas zapisu do tego urządzenia archiwizacyjnego. Jeżeli wartość parametru device_type zostanie określona jako Tape, SQL Server będzie miał informację, że oznacza to NoSkip. Czyli jeśli taśma posiada informacje nagłówkowe o wcześniejszych kopiach na taśmie, SQL Server nie ignoruje ich automatycznie i nie reinicjalizuje taśmy. Jeżeli takie działanie SQL Servera (automatyczna reinicjalizacja taśmy nawet gdy zawiera dane) jest pożądane należy określić wartość: Skip.

Potrzebne jest tutaj krótkie omówienie szczegółów składni parametru physical_name. Jeżeli lokalna ścieżka zostanie określona, musi być ona w pełni poprawna. Przykładowo:

d:\program files\Microsoft SQL Server\mssql\backup\master_backup.bak

Plik sieciowy musi być w formie ścieżki Universal Naming Convention (UNC), tak jak:

\\remoteserver\backups\sql\master_backup.bak

Na końcu określa się jednostki taśmy przy pomocy konwencji:

\\.\tape#

rozpoczynając od 0 dla pierwszego napędu taśmowego w systemie. W przypadku posiadania jedynie pojedynczego napędu taśmowego, można się do niego odwoływać jako:

\\.\tape0

Następujący przykład tworzy urządzenie archiwizujące (dump device), które może być używane do utworzenia kopii bazy danych master. Polecenie to dodaje nowe urządzenie archiwizujące —dysk zwany master_backup w odpowiedniej fizycznej lokalizacji:

EXEC sp_addumpdevice 'disk', 'master_backup', 'd:\program files\Microsoft SQL Server\mssql\backup\master_backup.bak'

Pojęcie dump device jest przejawem powrotu do wcześniejszych wersji SQL Servera. Jest nadal używane dla zachowania zgodności z wersją SQL Server 6.5. Takie same rozważania dotyczące zgodności wstecz dotyczą procedur składowych, które będą wspomniane w dalszej części rozdziału, m.in. sp_dropdevice.

Aby usunąć urządzenie archiwizujące, należy uruchomić systemową procedurę składową:

sp_dropdevice [@logicalname =] 'logical_name', [@delfile =] 'delfile'

Składnia:

logical_name jest nazwą, jaka ma być używana w poleceniach tworzenia kopii i odtwarzania danych, przy odwoływaniu się do fizycznej lokalizacji kopii bezpieczeństwa.

delfile — jeżeli parametr został użyty — określa fizyczny plik kopii, który powinien być skasowany (jeśli jest na dysku).

Dlatego, jeżeli ma zostać skasowane urządzenie archiwizujące pubs_backup należy uruchomić:

EXEC sp_dropdevice 'pubs_backup'

Aby pozbyć się pliku kopii bezpieczeństwa w tym samym czasie (przyjmując, że kopia bazy pubs została umieszczona na dysku), należy uruchomić następujący kod:

EXEC sp_dropdevice 'pubs_backup', 'delfile'

Odpowiedź systemu powinna być następująca:

Succesfully deleted the physical file 'd:\program files\Microsoft SQL Server\mssql\backup\pubs_backup.dat'

Device dropped.

Aby zobaczyć listę wszystkich urządzeń w systemie, należy uruchomić procedurę systemową sp_helpdevice:

sp_helpdevice [[@devname =] 'logical_name']

W tej składni logical_name jest nazwa, jaka ma być używana przez polecenia archiwizujące i odtwarzające, przy odwoływaniu się do fizycznego położenia kopii bezpieczeństwa. Przykładowo, uruchamiając:

EXEC sp_helpdevice

odpowiedzią systemu będzie wydruk (przesunięty, aby dopasować do strony):

device_name physical_name

description status ctrltype size

master D:\Program Files\Microsoft SQL Server\mssql\data\master.mdf master_backup D:\Program Files\Microsoft SQL Server\mssql\backup\master. mastlog D:\Program Files\Microsoft SQL Server\mssql\data\mastlog... modeldev D:\Program Files\Microsoft SQL Server\mssql\data\model.mdf modellog D:\Program Files\Microsoft SQL Server\mssql\data\modellog.. tempdev D:\Program Files\Microsoft SQL Server\mssql\data\tempdb.mdf templog D:\Program Files\Microsoft SQL Server\mssql\data\templog...

disk, backup device 16 2 0

special, physical disk, 1 MB 2 0 128 special, physical disk, 0.6 MB 2 0 80 special, physical disk, 0.8 MB 2 0 96 special, physical disk, 2 MB 2 0 256 special, physical disk, 0.5 MB 2 0 64 special, physical disk, 4 MB 2 0 512

(7 row(s) affected)

Warto zauważyć, że kilka wierszy zawiera informacje special, physical disk, a jeden z wierszy zawiera informację: disk, backup device. Jest to dane urządzenie archiwizujące. Należy prześledzić wyniki działania procedury sp_helpdevice aby znaleźć na liście urządzenia archiwizujące.

Kontrolowanie urządzeń archiwizujących przy pomocy SQL Server Enterprise Managera

Można również używać SQL Server Enterprise Managera do tworzenia i usuwania urządzeń archiwizujących. Aby to wykonać, należy wybrać dany serwer, folder Management i podświetlić ikonę Backup. Kliknąć prawym klawiszem myszy ikonę (lub dowolne miejsce w prawym panelu okna Enterprise Managera) i wybrać z menu New Backup Device. Powinno się pojawić okno podobne do przedstawionego na rysunku 7.5. Warto ponownie zauważyć, że nie są dostępne żadne urządzenia archiwizujące, zdefiniowane po pierwszym zainstalowaniu SQL Servera 2000 (urządzenie master_backup, dodane uprzednio przy pomocy Transact-SQL jest widoczne).

Rysunek 7.5. Okno właściwości kopii zapasowej.

Tak jak to było wykonywane wcześniej, można stworzyć urządzenie archiwizujące do przechowywania kopii bezpieczeństwa baz danych. Przykładowo zostało utworzone urządzenie o nazwie msdb_backup jako kontener do przetrzymywania bazy MSDB. Warto zauważyć, że SQL Server Enterprise Manager wypełnia pole z nazwą pliku, podczas wpisywania nazwy urządzenia i domyślną ścieżkę aby zachować tą samą nazwę jak logiczna nazwa urządzenia. W większości przypadków zachowanie tej samej nazwy fizycznej i logicznej jest dobrym rozwiązaniem.

Po wypełnieniu pól w tym oknie, należy kliknąć OK. aby zakończyć tworzenie urządzenia. Jeżeli chce się przekonfigurować urządzenie tak, aby wskazywało na położenie sieciowe, należy wpisać ścieżkę UNC do zdalnego serwera w polu tekstowym Name. Nie należy używać jako nazw mapowanych liter napędu ponieważ w praktyce to bardzo komplikuje sprawę. Należy pamiętać, że tworząc urządzenie archiwizujące tworzy się wskaźnik w tabeli systemowej; żadne rzeczywiste dane nie są zapisywane w urządzeniu.

Aby usunąć urządzenie archiwizujące przy pomocy SQL Server Enterprise Managera, wystarczy kliknąć prawym klawiszem myszy urządzenie w folderze Backup Devices i wybrać z menu Delete. Należy potwierdzić usunięcie i urządzenie jest usuwane z tabel systemowych SQL Servera. Jeżeli został utworzony fizyczny plik, usunięcie urządzenia przy pomocy SQL Server Enterprise Managera nie usunie tego pliku.

Sprawdzanie spójności bazy danych

Jeżeli jest dostępne urządzenie archiwizujące, wszystko jest prawie przygotowane do utworzenia kopii bezpieczeństwa baz danych. Może się zdarzyć, że zajdzie potrzeba przedsięwzięcia dodatkowych kroków przed rozpoczęciem tworzenia kopii. Jak zostało wcześniej wspomniane, uszkodzona kopia bazy danych jest bezwartościowa. Dlatego, należy sprawdzić, czy kopia jest poprawna. Microsoft dostarcza dwóch opcji do weryfikacji integralności bazy danych i kopii bezpieczeństwa. Polecenie tworzenia kopii bezpieczeństwa posiada opcję do kontroli poprawności kopii bezpieczeństwa po jej wykonaniu. Zbiór poleceń również dostarcza możliwości zweryfikowania integralności bazy danych.

Teraz należy się skupić na możliwościach sprawdzania spójności jaka występuje w bazach danych SQL Servera. Jeżeli baza danych jest w porządku przed wykonywaniem jej kopii, na ogół kopii bezpieczeństwa również jest poprawna. Aby sprawdzić spójność bazy danych, należy skorzystać z rozszerzeń narzędzia Database Consistency Checker (DBCC). Kilka różnych narzędzi DBCC sprawdza różne aspekty integralności bazy danych. Warto uruchomić polecenie DBCC CHECKDB:

DBCC CHECKDB ('database_name' [, Noindex |

{ Repair_Allow_Data_Loss | Repair_Fast | Repair_Rebuild }])

[ With {[ALL_ERRORMSGS] | [NO_INFOMSGS],

[TABLOCK],[ESTIMATEONLY], [PHYSICAL_ONLY], [TABLERESULTS]] } ]

Znaczenie składni:

database_name jest nazwą bazy danych, dla której ma być sprawdzona integralność.

Noindex określa, że integralność nie klastrowanych indeksów nie ma być sprawdzana. (Indeksy zostaną omówione w rozdziale 13).

Repair_Allow_Data_Loss określa wszystkie rodzaje napraw, jakie mają być przeprowadzone prze opcję Repair_Rebuild. Opcja ta pozwala również „wyczyścić” uszkodzone strony i strony tekst/obraz bez względu na to czy powoduje to utratę danych czy nie. Baza danych musi być w trybie pojedynczego użytkownika (single-user) aby określić tę opcję.

Repair_Fast modyfikuje uszkodzone indeksy, jeżeli jest to bezpieczne (żadne dane nie zostaną utracone używając tej opcji). Opcja ta wykonuje również szybkie i łatwe naprawy (takie jak uszkodzone klucze indeksu). Baza danych musi być w trybie pojedynczego użytkownika, aby było możliwe określenie tej opcji.

Repair_Rebuild naprawia uszkodzone indeksy, podobnie jak opcja Repair_Fast ale są to bardziej czasochłonne naprawy, takie jak ponowne utworzenie uszkodzonych indeksów. Baza danych musi być w trybie pojedynczego użytkownika, aby było możliwe określenie tej opcji.

ALL_ERRORMSGS zwraca wszystkie komunikaty z polecenia. Domyślnie, SQL Server wstrzymuje zwracanie komunikatów o błędach po otrzymaniu 200 komunikatów. Być może opcja ta nie będzie nigdy potrzebna.

NO_INFOMSGS określa, że będą zgłaszane jedynie znaczące komunikaty o błędach; nie będą natomiast przedstawiane komunikaty informacyjne. Opcja ta jest na ogół używana przez większość czasu.

TABLOCK określa, że współdzielone blokady tabel powinny być używane w zamian za domyślne blokady stron. Używanie tego parametru przyspiesza działanie poleceń DBCC jeśli system jest zajęty ale utrudnia pracę konkurencyjnych użytkowników, którzy mogą być w tym przypadku blokowani przez dane polecenia DBCC.

ESTIMATEONLY oznacza, że użytkownik chce wiedzieć ile wolnej przestrzeni w bazie danych tempdb jest potrzebne do uruchamiania polecenie bez uruchamiania CHECKDB.

PHYSICAL_ONLY oznacza, ze użytkownik chce sprawdzić jedynie fizyczną integralność bazy danych (a nie logiczną integralność). Opcja ta działa szybciej i wyłapuje większość typowych uszkodzeń w SQL Serverze (takich jak problemy z dyskiem, kontrolerem dysku i uszkodzonymi stronami).

TABLERESULTS określa, że rezultaty poleceń DBCC będą zwracane w formacie polecenia SELECT (jako zbiór „wynikowy”). Opcja ta, nowa w SQL Serverze 2000, pozwala zachować wyniki tego polecenia (i innych poleceń DBCC) w postaci tabeli, co powala uniknąć zagłębiania się w raporty w poszukiwaniu interesującego wyniku.

SQL Server 2000 może naprawiać problemy ze spójnością. Opcje naprawy zostaną omówione w rozdziale 8. Teraz należy uruchomić następujący kod, aby sprawdzić spójność i integralność bazy danych:

DBCC CHECKDB ('pubs') With NO_INFOMSGS, TABLERESULTS

The command(s) completed successfully.

Jeżeli zostanie ominięta część polecenia With NO_INFOMSGS, ukaże się wiele wierszy (dwa dla każdej tabeli w bazie danych), podobnie do pokazanych na rysunku 7.6.

Rysunek 7.6. Polecenie DBCC CHECKDB z wieloma wierszami.

Interpretacja wyników polecenia jest znacznie łatwiejsza, jeżeli została zastosowana opcja NO_INFOMSGS. Nie ma powodu do omijania opcji NO_INFOMSGS, chyba, że potrzebny jest raport na temat ilości wierszy i stron.

Jeżeli w raporcie pojawiły się też inne komunikaty, najprawdopodobniej w bazie danych występują pewne formy uszkodzeń. Naprawianie błędów z poleceń DBCC CHECKDB jest poza zakresem tej książki, ale można znaleźć dodatkowe informacje w bazie wiedzy Microsoft (http:support.microsoft.com/support). Jeżeli nie jest możliwa naprawa żadnego z uszkodzeń bazy danych, należy ją raczej odtworzyć z ostatniej kopii bezpieczeństwa. Przeprowadzanie operacji odtwarzania zostanie omówione w rozdziale 8.

Sprawdzenie spójności DBCC CHECKDB jest więcej niż adekwatne przez 90% czasu. Faktycznie, w SQL Server 2000, prawdopodobnie nie będą uruchamiane polecenia DBCC. Jednak, ponieważ należy być bardzo ostrożnym, jeżeli chodzi o dane firmy, być może dobrym pomysłem jest codzienne sprawdzenie DBCC. Nie powinno być problemów z czasem, potrzebnym do sprawdzenia integralności baz, chyba, że baza danych jest bardzo duża (tysiące gigabajtów). Polecenie DBCC CHECKDB może wydawać jedynie użytkownik należący do roli serwera sysadmin lub roli bazy danych db_owner.

Inne sposoby sprawdzenia integralności

Następne trzy polecenia DBCC CHECKCATALOG, DBCC CHECKALLOC i DBCC CHECKTABLE są podzbiorem DBCC CHECKDB.

Polecenia te wymagają, aby użytkownik należał do roli serwera sysadmin lub roli baz danych db_owner. Te same warunki stosują się do używania DBCC CHECKDB.

DBCC CHECKCATALOG Polecenie DBCC CHECKCATALOG sprawdza integralność referencyjną tabel systemowych. Więcej informacji na ten temat zostało przedstawionych w rozdziale 14.

DBCC CHECKCATALOG ( 'database_name') [WITH NO_INOFMSGS]

W tej składni database_name oznacza nazwę bazy danych, której integralność na być sprawdzona.

Poniżej przedstawiono przykład użycia tego polecenia:

DBCC CHECKCATALOG ('Pubs')

Wynik:

DBCC results for 'pubs'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Warto zauważyć, że pojawiają się tylko dwie linie wynikowe. Dla tego polecenia, opcja NO_INFOMSGS eliminuje jedynie pierwszą linię:

DBCC Results for 'databasename'.

DBCC CHECKALLOC DBCC CHECKALLOC sprawdza, czy informacje na temat alokacji (oznaczającej — jakie rozszerzenia są własnością jakich tabel) w bazie danych są poprawne.

DBCC CHECKALLOC ('database_name' [, NOINDEX |

{ REPAIR_ALLOW_DATA_LOSS |REPAIR_FAST | REPAIR_REBUILD }] )

[WITH {[ALL_ERRORMSGS | NO_INFOMSGS], [TABLOCK] [,ESTIMATEONLY]

[, TABLERESULTS]}]

Wszystkie parametry w tej składni mają takie samo znaczenie jak w przypadku DBCC CHECKDB.

DBCC CHECKTABLE Polecenie DBCC CHECKTABLE wykonuje te same operacje co DBCC CHECKDB ale jest ograniczone do pojedynczej tabeli. Jest to bardzo przydatne jeżeli ma zostać sprawdzona jedna duża tabela ale nie ma potrzeby sprawdzania całej bazy danych.

DBCC CHECKTABLE ('table_name' [, NOINDEX | index_id

|{ REPAIR_ALLOW_DATA_LOSS |REPAIR_FAST | REPAIR_REBUILD }] )

[WITH {[ALL_ERRORMSGS | NO_INFOMSGS],

[TABLOCK] [,ESTIMATEONLY], [PHYSICAL_ONLY].[TABLERESULTS]}]

W przypadku tej składni wszystkie opcje są takie same jak dla DBCC CHECKDB z wyjątkiem dwóch:

table_name jest nazwą tabeli, której integralność ma zostać sprawdzona

index_id oznacza, że ma zostać sprawdzona integralność pojedynczego indeksu (Identyfikatory indeksów — ID zostaną omówione w rozdziale 13).

Tworzenie kopii bezpieczeństwa bazy danych

Jest wiele do zrobienia zanim stworzy się kopię bezpieczeństwa bazy danych. Nie jest to nigdy sprawa trywialna, nawet w przypadku niewielkiego systemu. Po utworzeniu nośników archiwizacyjnych i sprawdzeniu poprawności baz danych, nadszedł czas na stworzenie kopii bezpieczeństwa każdej bazy danych. Pierwszym krokiem jest sprawdzenie jakie nośniki archiwizujące będą używane i jak należy używać te nośniki.

Opcje nośnika archiwizacyjnego

Można stworzyć kopię bezpieczeństwa na pojedynczym nośniku archiwizacyjnym lub na wielu nośnikach; można także umieścić wiele kopii bezpieczeństwa na pojedynczym nośniku archiwizacyjnym. Za każdym razem, odwołując się do nośnika archiwizacyjnego, należy określić nazwę pliku zamiast polecenia BACKUP.

Kopie bezpieczeństwa na pojedynczym nośniku archiwizującym (single-device)

Kopia na pojedynczym nośniku jest domyślnym i najczęstszym sposobem archiwizacji. Jeżeli każda baza danych jest archiwizowana na odrębnym nośniku, można przeprowadzić strategię kopiowania jeden-do-jednego. Jeżeli kopia bezpieczeństwa ma być na dyskach, podejście to jest zalecane. Jeżeli z pewnych przyczyn został utracony plik, została w związku z tym utracona pojedyncza kopia bezpieczeństwa pojedynczej bazy danych a nie wiele kopii bezpieczeństwa zawartych w pojedynczym pliku. Jeżeli kopia bezpieczeństwa jest na taśmie, tworzenie kopii wielu baz danych na pojedynczej taśmie jest bardziej akceptowalne (i mniej kosztowne).

Kopie bezpieczeństwa równolegle rozproszone (parallel striped)

Kopie bezpieczeństwa równolegle rozproszone pozwalają na tworzenie kopii pojedynczej bazy danych na wielu nośnikach archiwizacyjnych. Wystarczy podać więcej niż jeden nośnik archiwizacyjny w poleceniu BACKUP. SQL Server 2000 inicjuje wątek dla każdego wybranego nośnika w kopii równolegle rozproszonej. Istnieje możliwość używania w tym przypadku do 24 nośników (oraz wynikających z tego wątków).

Silnym argumentem za używaniem kopii bezpieczeństwa równolegle rozproszonych są kopie na taśmach. Można podłączyć wiele taśm w tym samym czasie. Jeżeli tworzenie kopii bazy danych zajmuje trzy godziny, a zakupi się dwa dodatkowe napędy taśmowe (czyli w sumie trzy), można z dużym prawdopodobieństwem przyjąć, że tworzenie kopii bezpieczeństwa zakończy się w godzinę. Istotną sprawą jest to, że nie potrzeba tej samej ilości napędów taśmowych do odtworzenia bazy danych z kopii bezpieczeństwa. Jest to szczególnie istotne w przypadku odtwarzania po awarii. Nie ma gwarancji, że posiada się taką samą ilość napędów taśmowych na serwerze odtwarzającym. Jednak, nadal potrzeba posiadać wszystkie taśmy aby odtworzyć bazę danych.

Jeżeli w przypadku kopii równolegle rozproszonej wykorzystywana jest taśma, nie może być ona wykorzystana do innych celów jak tylko do kolejnej kopii równolegle rozproszonej z tą samą ilością napędów taśmowych aż do czasu ponownego sformatowania taśmy.

Wiele kopii bezpieczeństwa na pojedynczym nośniku

Można również umieścić wiele kopii bezpieczeństwa na pojedynczym nośniku archiwizacyjnym. Jest to domyślna konfiguracja w przypadku korzystania z taśm. Należy się spodziewać, ze użytkownik będzie chciał umieścić tak wiele kopii bezpieczeństwa na pojedynczej taśmie jak to jest możliwe. Można również zastosować tę metodę w przypadku dysków; jednak to podejście nie jest polecane dla dysków — jeżeli pojedynczy plik zostanie utracony lub ulegnie uszkodzeniu, wszystkie kopie bezpieczeństwa na tym nośniku są stracone.

Polecenie BACKUP DATABASE dla całej bazy danych

Tworzenie bazy danych jest następnym logicznym krokiem (końcowym). Można utworzyć kopię bezpieczeństwa przy pomocy polecenia BACKUP:

BACKUP DATABASE {database_name | @database_var}

TO backup_device [, ...n]

[WITH [BLOCKSIZE = {blocksize | @blocksize_variable}]

[[,] DESCRIPTION = {text | @text_variable}]

[[,] DIFFERENTIAL]

[[,] EXPIREDATE = {date | @date_var}

| RETAINDAYS = {days | @days_var}]

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

[[,] FORMAT | NOFORMAT]

[[,] {INIT | NOINIT}]

[[,] MEDIADESCRIPTION = {text | @text_variable}]

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

[[,] MEDIAPASSWORD = {media_pwd | @media_pwd_variable}]

[[,] [NAME = {backup_set_name | @backup_set_name_var}]

[[,] {NOSKIP | SKIP}]

[[,] {NOUNLOAD | UNLOAD}]

[[,] {NOREWIND | REWIND}]

[[,] [RESTART]

[[,] STATS [= percentage]]

gdzie

backup_device :: =

{

{ backup_device_name | @backup_device_name_var}

|

{ DISK | TAPE | PIPE} =

{'temp_backpup_device' | @temp_backup_device_var}

}

Poniżej przedstawiono znaczenie poszczególnych opcji. Opisy nie są powtarzane, chyba że są specyficzne dla jednego z poleceń, przedstawionych później. Może zachodzić potrzeba odwołania się do opisu opcji BACKUP LOG i BACKUP FILE/FILEGROUP.

database_name jest nazwą bazy danych, której kopia ma zostać wykonana

@database_var jest nazwą bazy danych, której kopia ma być wykonana, z tym wyjątkiem, że jest przedstawiona w postaci zmiennej.

backup_device jest albo nazwą nośnika archiwizacyjnego albo określeniem zmiennej dla urządzenia archiwizacyjnego. Można również określić nazwę pliku, taśmy lub Named Pipe, które mają zostać wykorzystane do tworzenia kopii bezpieczeństwa. Ponownie, można określić ten parametr jako zmienną.

blocksize określa rozmiar bloku, jaki ma być używany w przypadku taśmy lub Named Pipe. Należy sprawdzić w dokumentacji Windows 2000 lub instrukcji obsługi napędu taśmowego, jakie rozmiary bloku są zalecane.

DESCRIPTION jest to opis kopii bezpieczeństwa, zawierający do 255 znaków. Ponownie, można określić zmienną dla tego parametru.

DIFFERENTIAL zasługuje na własną sekcję dla pełnego opisu. Zobacz kolejną sekcję.

EXPIREDATE jest datą ważności taśmy (terminem, po którym zapis na taśmie powinna być usunięty). Nie można dokonać zapisu na taśmę przed upływem terminu EXPIREDATE bez określenia parametrów nadpisywania.

RETAINDAYS przynosi ten sam efekt co EXPIREDATE, z wyjątkiem tego, że należy określić liczbę dni a nie konkretną datę.

PASSWORD jest hasłem, jakie ma być wprowadzone aby było możliwe odtworzenie z tej kopii bezpieczeństwa.

Kopia bezpieczeństwa jest zabezpieczona jedynie hasłem. Nie jest w żaden sposób szyfrowana.

FORMAT | NOFORMAT pozwala żądać, aby taśma była ponownie sformatowana. Wszelkie zabezpieczenia hasłem lub istniejące dane są ignorowane. Używanie tego parametru jest odpowiednikiem obydwu opcji INIT i SKIP.

INIT | NOINIT określa, czy inicjalizować nośnik archiwizujący przed zapisem kopii bezpieczeństwa. NOINIT jest opcją domyślną, oznaczającą, że jeżeli na danym nośniku archiwizującym jest inna kopia bezpieczeństwa, bieżąca kopia zostanie dołączona (dopisana) na taśmę lub do pliku dyskowego. Jeżeli urządzenie nie zawiera żadnej kopii, jest inicjalizowane a następnie kopia jest zapisywana. INIT powoduje nadpisanie istniejącej zawartości taśmy lub pliku dyskowego. Dla taśm, jeżeli minęła ich data ważności lub parametr MEDIANAME nie jest zgodny, taśma nie jest inicjalizowana. Należy określić opcję SKIP jeżeli to było zamierzeniem (jeżeli było to zamierzeniem, można również skorzystać z opcji FORMAT).

MEDIADESCRIPTION jest innym polem opisu dla kopii bezpieczeństwa, o długości 255 znaków.

MEDIANAME jest opisem zbioru kopii bezpieczeństwa, o długości 128 znaków. Nazwa ta jest używana do porównań w przypadku nadpisywania. Jeżeli planuje się używanie pojedynczej taśmy do przetrzymywania kopii bezpieczeństwa systemu Windows 2000 i SQL Servera należy określić MEDIANAME.

MEDIAPASSWORD jest hasłem, jakie ma być używane przy tworzeniu kopii bezpieczeństwa jako część zestawu nośników, jak również hasłem, jakie będzie wymagane przy odtwarzaniu z tego zestawu nośników.

NAME jest kolejną nazwą dla zestawu kopii bezpieczeństwa. Ponownie, parametr ten może być określony jako zmienna.

NOSKIP | SKIP określa czy opuścić czytanie nagłówka taśmy podczas zapisywania na taśmę. Jeżeli została wybrana opcja NOSKIP (domyślna), nagłówek taśmy jest czytany i sprawdzane są parametry EXPIREDATE i MEDIANAME aby nie spowodować przypadkowego nadpisania taśmy.

NOUNLOAD | UNLOAD określa, czy taśma ma zostać wyjęta po zakończeniu tworzenia kopii bezpieczeństwa.

NOREWIND |REWIND określa czy taśma na zostać przewinięta po zakończeniu tworzenia kopii bezpieczeństwa.

RESTART pozwana na ponowne uruchomienie tworzenia kopii bezpieczeństwa jeżeli zostało przerwane i ma być kontynuowane od punku przerwania. RESTART jest poprawny jedynie gdy tworzy się kopie bezpieczeństwa na wielu taśmach.

STATS = percentage określa jak często użytkownik będzie powiadamiany o postępie w tworzeniu kopii bezpieczeństwa. Domyślną wartością jest 10, oznaczające, że po ukończeniu każdego kolejnego 10 % tworzenia kopii SQL Server zwróci komunikat określający postęp archiwizacji.

Polecenie BACKUP ma wiele opcji dlatego przyda się przykład. Czasem próbka kodu bardzo pomaga w wyjaśnieniu znaczenia polecenia. Następujący skrypt tworzy nowy nośnik archiwizacyjny dla bazy danych pubs, sprawdza integralność bazy a następnie tworzy kopię bezpieczeństwa tej bazy.

exec sp_addumpdevice 'disk', 'pubs_backup',

'd:\program files\Microsoft SQL Server\mssql\backup\pubs_backup.bak'

go

use pubs

dbcc checkdb ('pubs') With NO_INFOMSGS

BACKUP DTABASE pubs to pubs_backup WITH INIT

(1 row(s) affected)

'Disk' device added.

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

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

BACKUP DATABASE successfully processed 209 pages in 0.639 seconds (2.668 MB/sec).

Nie jest to takie przerażające, jak by wyglądało. Następny segment kodu tworzy kopie bezpieczeństwa bazy danych pubs, ale tym razem na określonym lokalnym napędzie taśmowym. Nie można uruchomić tego kodu, nie posiadając zainstalowanego napędu taśmowego na komputerze z SQL Serverem 2000. Tym razem, okres ważności taśmy mija po 30 dniach i taśma powinna zostać sformatowana przed zapisaniem oraz rozmiar bloku taśmy wynosi 8,192 bajty. Nazwą kopii bezpieczeństwa jest Pubs Backup Tape.

exec sp_addumpdevice 'tape', 'pubs_tape_backup', '\\.\tape0'

use pubs

dbcc checkdb ('pubs') With NO_INFOMSGS

BACKUP DATABASE pubs to pubs_backup WITH FORMAT,

RETAIN_days = 30, MediaName = 'Pubs Backup Tape',

Blocksize = 8192

Polecenie DIFFERENTIAL BACKUP DATABASE

Jak zostało powiedziane wcześniej, kopia różnicowa kopiuje wszystkie zmodyfikowane strony z bazy danych — co oznacza — wszystkie strony, które zmieniły się od czasu wykonania ostatniej pełnej kopii bazy danych. Jeżeli wykonywana jest kopia różnicowa, a następnie kolejna kopia różnicowa, ta druga kopia różnicowa zawiera wszystkie zmiany te same co pierwsza plus wszelkie zmienione strony, które zmieniły się od czasu wykonania pierwszej kopii. Warto zauważyć, że kopia różnicowa ma sens jedynie jako kolejna po wykonaniu pełnej kopii bezpieczeństwa bazy danych.

Teraz należy wykonać kopię różnicową bazy danych pubs. Po pierwsze, należy stworzyć tabelę i dodać do niej jeden wiersz (czyli jest to coś nowego do archiwizowania). Nie będzie tworzone nowe urządzenie archiwizacyjnego, kopia różnicowa zostanie dodana do urządzenia zawierającego kopię bezpieczeństwa bazy danych. Można określić parametr NOINIT (jak w przykładzie) dla przejrzystości, nawet jeśli jest on domyślny.

use pubs

Create table backuptest (col1 int not null)

Insert backuptest values (1)

Go

BACKUP DATABASE pubs to pubs_backup WITH differential, NOINIT

Odpowiedź systemu:

(1 row(s) affected)

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

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

BACKUP DATABASE WITH DIFFERENTIAL successfully processed 49 pages in 0.486 seconds (0.811 MB/sec).

Potrzeba wiele informacji aby korzystać prawidłowo z kopii różnicowych. Szersze omówienie tego zagadnienia zawiera rozdział 8.

Opcja RESTART jest interesująca jeżeli ma się do czynienia z kopiami bezpieczeństwa dużych baz danych. Jeżeli utworzenie kopii nie powiedzie się z jakiegoś powodu, nie ma potrzeby rozpoczynania od samego początku; można rozpocząć w punkcie, w którym kopiowanie zostało przerwane i kontynuować tworzenie kopii bezpieczeństwa. Jednak, w przypadku kopii na pojedynczą taśmę lub w przypadku pierwszej taśmy z zestawu należy zacząć od samego początku, bez względu na ustawienie parametru RESTART.

Ustawienie wstrzymania ważności w przypadku kopii taśmowych

Jeżeli nie zostały ustawione opcje EXPIREDATE i RETAINDAYS dla kopii taśmowej, data ważności taśmy jest ustawiona domyślnie na opcję konfiguracyjną serwera media retention. W razie potrzeby można ustawić tę opcję, podobnie jak inne opcje konfiguracyjne serwera przy pomocy systemowej procedury składowej sp_configure (jest to opcja zaawansowana). Przykładowo, aby ustawić domyślną ważność na 30 dni, należy uruchomić następujący kod:

exec sp_configure 'media retention', 30

RECONFIGURE WITH OVERRIDE

Należy uruchomić ponownie SQL Server aby zmiany odniosły skutek. Domyślną konfiguracją ważności nośnika jest 0 dni (brak ustalonego okresu ważności).

Polecenie BACKUP DATABASE dla plików i grup plików

Składnia dla tworzenia kopii bezpieczeństwa plików i grup plików została tutaj przedstawiona dla zachowania kompletności opisu. Jednak, należy tworzyć kopie plików i grup plików jedynie jeśli nie można wykonać kopii bezpieczeństwa całej bazy danych (lub kombinacji kopii pełnej i różnicowej) w rozsądnym przedziale czasu. Można również tworzyć kopie grup plików z różnych innych prawidłowych przyczyn, ale ten zaawansowany temat wykracza poza zakres tej książki.

Zasadniczo, polecenie BACKUP DATABASE pozwala na tworzenie kopii bezpieczeństwa pojedynczego pliku lub zbioru plików zwanego grupą plików (opisanego w rozdziale 4). Nadal potrzebna jest kopia dziennika transakcji, jeżeli chce się korzystać z kopii plików lub grup plików w celu odtworzenia bazy danych.

BACKUP DATABASE {database_name | @database_name_var}

file_or_filegroup [, ...n]

TO backup_device [, ...n]

[WITH

[BLOCKSIZE = {blocksize | @blocksize_variable}]

[[,] DESCRIPTION = {text | @text_variable}]

[[,] EXPIREDATE = {date | @date_var}

| RETAINDAYS = {days | @days_var}]

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

[[,] FORMAT | NOFORMAT]

[[,] {INIT | NOINIT}]

[[,] MEDIADESCRIPTION = {text | @text_variable}]

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

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

[[,] [NAME = {backup_set_name | @backup_set_name_var}]

[[,] {NOSKIP | SKIP}]

[[,] {NOUNLOAD | UNLOAD}]

[[,] {NOREWIND | REWIND}]

[[,] [RESTART]

[[,] STATS [= percentage]]

]

gdzie

file_or_filegroup :: =

{

FILE = { logical_file_name | @logical_file_name_var}

|

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var}

}

W tej składni większość opcji zostało omówionych, z wyjątkiem następujących:

FILE oznacza nazwę pojedynczego pliku (lub zmiennej przypisanej do ścieżki i nazwy pojedynczego pliku), którego kopia ma być utworzona

FILEGROUP oznacza logiczną nazwę grupy plików, której kopia ma zostać tworzona. Wszystkie pliki z danej grupy zostaną zarchiwizowane.

Polecenie BACKUP LOG

Można utworzyć kopię jedynie dziennika transakcji bazy danych przy pomocy polecenia BACKUP LOG:

BACKUP LOG {database_name | @database_name_var}

{[WITH { NO_LOG | TRUNCATE_ONLY}]}

|

{TO backup_device [, ...n]

[WITH

[BLOCKSIZE = {blocksize | @blocksize_variable}]

[[,] DESCRIPTION = {text | @text_variable}]

[[,] EXPIREDATE = {date | @date_var}

| RETAINDAYS = {days | @days_var}]

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

[[,] FORMAT | NOFORMAT]

[[,] {INIT | NOINIT}]

[[,] MEDIADESCRIPTION = {text | @text_variable}]

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

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

[[,] [NAME = {backup_set_name | @backup_set_name_var}]

[[,] NO_TRUNCATE]

[[,] {NOSKIP | SKIP}]

[[,] {NOUNLOAD | UNLOAD}]

[[,] {NOREWIND | REWIND}]

[[,] [RESTART]

[[,] STATS [= percentage]]

W tej składni większość opcje zostało omówionych, z wyjątkiem następujących:

Parametry TRUNCATE_ONLY i NO_LOG są identyczne. Usuwają one wykonane (zakończone) transakcje z dziennika ale nie robią kopii wpisów. Przykładowo, po wykonaniu kopii bezpieczeństwa bazy, w której były wykonywane nie rejestrowane operacje, dziennik transakcji jest przydatny. Można uruchomić polecenie BACKUP LOG WITH TRUNCATE_ONLY, a następnie utworzyć pełną kopię bezpieczeństwa bazy danych. Okrojenie dziennika transakcji jest rejestrowaną operacją samą w sobie. Warto również zauważyć, że opcja ta wykonuje faktycznie archiwizację, ale nazwa nośnika archiwizacyjnego jest nie potrzebna. Oczywiście, jeżeli chce się wykonywać tę operację należy przełączyć bazę danych w tryb odzyskiwania SIMPLE.

NO_TRUNCATE wykonuje kopię bezpieczeństwa dziennika transakcji (tak jak polecenie BACKUP LOG bez żadnych specjalnych opcji). Jednak, opcja ta wykonuje działanie, którego nie wykonuje zwykłe tworzenie kopii: może utworzyć kopię dziennika transakcji nawet jeśli baza danych jest włączona (dostępna). Można przyjąć, że w bazie danych jest plik danych na jednym fizycznym dysku i dziennik transakcji na osobnym dysku. Jeżeli plik danych został z jakiegoś powodu uszkodzony, można uruchomić polecenie BACKUP LOG z opcją NO_TRUNCATE aby zachować wszystkie transakcje, które wystąpiły od czasu tworzenia ostatniej kopii dziennika transakcji. Tym sposobem, można odtworzyć bazę danych do punktu w czasie, w którym nastąpiło uszkodzenie dysku.

Można utworzyć kopię dziennika transakcji bazy danych jedynie w przypadku, gdy wcześniej została wykonana pełna kopia bazy danych. Nie można wykonać kopii dziennika transakcji jeżeli ustawione są opcje Truncate Log On Checkpoint lub Select Into/Bulkcopy Database.

Kopie dziennika transakcji są sekwencjami kopii bezpieczeństwa. W przypadku tych kopii, podobnie jak w przypadku kopii różnicowych, nie pojawia się żadne duplikowanie danych pomiędzy poszczególnymi kolejnymi kopiami dziennika transakcji. Kiedy zachodzi konieczność odtwarzania dzienników transakcji, potrzeba do tego wszystkich kopii utworzonych od czasu wykonania ostatniej pełnej kopii bazy danych. Kolejny rozdział prezentuje szczegóły odtwarzania bazy danych przy pomocy dzienników transakcji.

Jak często należy wykonywać kopie dziennika transakcji? Typowy scenariusz może wyglądać tak (dla bazy danych używanej głównie w godzinach pracy):

6:00 a.m. Wykonanie codziennej pełnej kopii bazy danych z opcją FORMAT

6:05 a.m. Utworzenie kopii dziennika transakcji z opcją FORMAT

10:00 a.m. Ponownie utworzenie kopii dziennika transakcji (NOINIT)

12:00 p.m. Wykonanie różnicowej kopii bazy danych (NOINIT)

2:00 p.m. Kolejne utworzenie kopii dziennika transakcji (NOINIT)

6:00 p.m. Kolejne utworzenie kopii dziennika transakcji (NOINIT)

8:00 p.m. Wykonanie różnicowej kopii bazy danych (NOINIT)

10:00 p.m. Kolejne utworzenie kopii dziennika transakcji (ostatni raz)

Ten skrypt będzie wyglądał podobnie jak przedstawiony w wydruku 7.1 dla bazy danych pubs. Oczywiście, założeniem jest, że baza jest w trybie Full recovery.

Domyślnie baza danych pubs jest w trybie odtwarzania SIMPLE. Jeżeli jest ustawiony ten tryb, nie można wykonać kopii bezpieczeństwa dziennika transakcji. Aby wykonać kod przedstawiony w wydruku 7.1 należy przestawić bazę danych w tryb FULL przy pomocy polecenia: Alter Database pubs SET RECOVERY FULL

Wydruk 7.1 Ustawianie planu archiwizacji

--SCRIPT BEGINS AT 6:00 AM

use pubs

go

dbcc checkdb ('pubs') With NO_INFOMSGS, TABLERESULTS

go

BACKUP DATABASE pubs to pubs_backup WITH FORMAT,

Retaindays = 30, MediaNAme= 'Pubs Backup Tape',

Blocksize = 8192

Go

--6:05 AM

BACKUP LOG pubs to pubs_log_backup WITH INIT

Go

--10:00 AM

BACKUP LOG pubs to pubs_log_backup

Go

-- 12:00 PM

BACKUP DATABASE pubs to pubs_backup WITH DIFFERENTIAL,

NOINIT, NOSKIP, Retaindays = 30, MediaName = 'Pubs Backup Tape',

Blocksize = 8912

Go

-- 2:00 PM

BACKUP LOG pubs to pubs_log_backup

Go

-- 6:00 PM

BACKUP LOG pubs to pubs_log_backup

Go

-- 8:00 PM

BACKUP DATABASE pubs to pubs_backup WITH DIFFERENTIAL,

NOINIT, NOSKIP, Retaindays = 30, MediaName = ' Pubs Backup Tape',

Blocksize= 8192

Go

-- 10:00 PM

BACKUP LOG pubs to pubs_log_backup

Go

Skrypt ten pozwala na odtworzenie bazy danych bez utraty transakcji (dopóki nie zostanie utracone urządzenie archiwizacyjne). Przykład ten zakłada wykorzystanie dwóch napędów taśmowych: jednego dla pełnych/różnicowych kopii bezpieczeństwa bazy danych a drugiego dla kopii dziennika transakcji.

Tworzenie kopii bezpieczeństwa korzystając z SQL Server Enterprise Managera

SQL Server Enterprise Manager jest w pełni funkcjonalnym narzędziem w zakresie tworzenia kopii bezpieczeństwa. Na początku, należy utworzyć dwa kolejne nośniki archiwizujące: jedno dla bazy danych pubs (zwane pubs_backup) i drugie dla bazy danych Northwind (zwane northwind_backup). Należy ustawić obydwie bazy danych w tryb FULL recovery.

Następnie należy rozwinąć folder Databases, kliknąć prawym klawiszem myszy bazę danych, dla której ma być wykonana kopia bezpieczeństwa i wybrać z menu Wszystkie zadania, Backup Database. Pojawi się okno SQL Server Backup pokazane na rysunku 7.7.

Rysunek 7.7. Okno kopii zapasowej w SQL Serverze dla bazy pubs.

Po wcześniejszym zapoznaniu się ze składnią poleceń archiwizujących Transact-SQL, nie powinno być problemów z uzupełnieniem pól w tym oknie. Należy uzupełnić niezbędne szczegóły oraz opis kopii bezpieczeństwa (gdy jest taka potrzeba) i wybrać typ kopii bezpieczeństwa. Należy pamiętać, że w przypadku tworzenia dziennika transakcji, należy najpierw wykonać pełną kopię bazy danych. Opcje bazy danych Select Into/Bulkcopy i Truncate Log On Checkpoint muszą być wyłączone i baza danych nie może być w trybie SIMPLE.

W bloku Destination (rysunek 7.7) należy kliknąć Add aby otworzyć okno Select Backup Destination (zobacz rysunek 7.8). Z tego okna należy wybrać położenie pliku, napęd taśmowy, położenie sieciowe, Named Pipe lub (najłatwiejsze rozwiązanie) wybrać urządzenie archiwizacyjne. W przypadku opcji Backup device należy wybrać z listy pubs_backup.

Rysunek 7.8 Okno wyboru urządzenia archiwizacyjnego.

Należy kliknąć OK. aby zakończyć wybieranie urządzenia archiwizacyjnego i przejść do sekcji okna SQL Server Backup. Domyślny wybór (jak wspomniano wcześniej) oznacza dołączenie tworzonej kopii do poprzednich kopii, które mogą istnieć na danym urządzeniu archiwizacyjnym lub pliku kopii bezpieczeństwa. Należy wybrać opcję Overwrite Existing Media, jeżeli aktualna zawartość urządzenia archiwizacyjnego ma być usunięta przed zapisaniem bieżącej kopii.

Pole wyboru Schedule zapewnia interfejs pozwalający skorzystać z aparatu planowania SQL Servera, które jest dostarczany przez usługę SQL Server Agent. Należy zaznaczyć to pole jeżeli SQL Server ma wykonywać regularne kopie bezpieczeństwa jako zaplanowane zadania o określonej częstotliwości. Należy zapoznać się z tym interfejsem, ustawić sposób tworzenia kopii, zaznaczyć opcję Schedule a następnie skonfigurować plan. Ponieważ planowanie tworzenia kopii jest tylko jedną z wielu możliwych funkcji (bardzo ważną funkcją) SQL Servera, własności te zostały omówione szerzej w rozdziale 18.

Należy kliknąć zakładkę Options aby wyświetliło się okno, pokazane na rysunku 7.9. Warto zauważyć, że zaznaczona jest opcja Verify backup upon completion. Opcja ta powoduje sprawdzenie czy kopia bezpieczeństwa jest nienaruszona i nie uszkodzona.

Rysunek 7.9. Zakładka Opcje kopii bezpieczeństwa w SQL Serverze.

Opcja Verity Backup Upon Completion nie jest tym samym co DBCC CHECKDB. Nie sprawdza ona integralności w bazie danych; sprawdza jedynie czy nośnik z kopią bezpieczeństwa nie jest uszkodzony.

Każda z niedostępnych opcji (rysunek 7.9) jest dostępna jedynie dla wybranego typu kopii bezpieczeństwa — w tym przypadku, wybrana jest pełna (full) kopia, tworzona na dysku. Jeżeli byłaby to kopia dziennika transakcji, byłaby dostępna opcja Remove Inactive Entries from Transaction Log, która określa domyślne zachowanie kopii dziennika. Jeżeli wyłączy się tę opcję, uzyska się odpowiednik opcji NO_TRUNCATE kopii dziennika.

Reszta opcji na tej zakładce jest specyficzna dla napędów taśmowych i ich znaczenie wynika z ich opisu. Aby rozpocząć tworzenie kopii należy nacisnąć OK. Ukaże się okno podobne do pokazanego na rysunku 7.10, ukazujące postęp tworzenia kopii bezpieczeństwa. Jeżeli została wybrana opcja Verify, ukaże się również komunikat, pokazany na rysunku 7.11 informujący o pomyślnym zakończeniu weryfikacji.

Rysunek 7.10. Postęp procesu tworzenia kopii bezpieczeństwa.
Rysunek 7.11. Informacja o pozytywnym zweryfikowaniu kopii bezpieczeństwa.

Teraz, można pokazać najlepszy element dotyczący używania nośników archiwizacyjnych zamiast używania bezpośrednio plików. Należy rozwinąć folder Management w Enterprise Manager, kliknąć ikonę Backup i kliknąć dwukrotnie nośnik archiwizacyjne pubs_backup. Następnie należy kliknąć aktywny przycisk View Contents. Zostanie wyświetlona lista wszystkich kopii przechowywanych na nośnikach archiwizacyjnych, wraz z informacją o typie kopii i terminie jej wykonania. Na rysunku 7.12 można zauważyć, że obydwie pełne kopie bazy danych i dziennika transakcji są na nośnikach archiwizacyjnych.

Rysunek 7.12. Widok zawartości kopii bezpieczeństwa.

Tworzenie kopii bezpieczeństwa baz danych i dzienników transakcji przy pomocy SQL Server Enterprise Managera jest bardzo proste. Oczywiście, zrozumienie zachodzących procesów i znaczenia poszczególnych opcji wiąże się z pewnym wysiłkiem, ale warto wiedzieć jakie działania są wykonywane.

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

1 H:\Książki\!Marcin\SQL Server 2000 dla każdego\5 po odbiorze technicznym\r07-1.doc

---