MS SQL Server 6.5 - Administracja serwerem SQL









Administrowanie serwera można podzielić na cztery zagadnienia:
Zrozumienie i stosowanie punktów kontrolnych "checkpoints".
Punkty kontrolne są używane przez SQL do utrzymania integralności bazy danych.

Używanie DBCC "Database Consistency Checker". DBCC dostarcza
wartościowych informacji o stanie bazy danych i tablic.
Tworzenie kopii zapasowej Serwera SQL. Aby serwer SQL był
niezawodny należy tworzyć kopie zapasowe systemu. Serwer SQL dostarcza różne
narzędzia, które to umożliwiają.
Transfer danych do i z Serwera SQL. Jeżeli tworzy się bazę
danych na podstawie innego poprzednio istniejącego systemu lub dokonuje się
zmian do innego typu danych, należy wiedzieć jak dokonać transferu z i do
SQL Serwera.

 

"Checkpoints" są funkcjami Serwera SQL, którym powierzono zmienianie
konfiguracji w odpowiednich momentach czasowych. Jeżeli dokona się zmiany
konfiguracji ręcznie powinno się restartować serwer.
Jeżeli "checkpoint" przestanie działać z powodów interwencji procesów
ręcznych lub naturalnych procesów serwera, wszystkie "brudne strony"
zostaną zapisane na dysk. "Brudne strony" zawierają zmiany, które nie
zostały jeszcze zastosowane w bazie danych. "Checkpoints" normalnie
zdarzają się co 60 sekund, oczywiście jeżeli nie nastąpi żadna interwencja z
naszej strony. Na ten czas składa się wczytanie opcji, które zmieniliśmy
i ogólne dostrojenie systemu.
Jeżeli Serwer SQL niespodziewanie się zawiesi, można przywrócić go do
poprzedniego stanu. Stanie się tak ponieważ SQL Serwer cofnie się do ostatniej
działającej konfiguracji, pod warunkiem, że ostatni "checkpoint" został
prawidłowo wywołany i wykonany.
Możesz również ręcznie zamknąć serwer używając komendy SHUTDOWN.
Dzięki temu możesz być pewny, że wszystkie informacje zostaną odpowiednio
zapisane.
Jeżeli wiemy, że będziemy zamykać serwer, możemy uniknąć długiego ręcznego
ustawiania "Checkpoints". Serwer może to robić automatycznie. Wszystkie
niezbędne informacje zostaną zapamiętane i serwer w prosty sposób
wystartuje i uruchomi bazy danych naszych klientów. Jest to korzystne przy
szybkim wyłączaniu serwera np. w przypadku przerwy w dopływie energii.
"Checkpoints" są wykonywane na poziomie bazy danych i na
aktualnej bazie. Jeżeli jest więcej baz danych muszą być wywołane dla każdej z
nich. Żeby to zrobić należy być właścicielem danej bazy.
Inna całkiem użyteczna opcja to: "Truncate Log on Checkpoint".
Dokonuje ona automatycznego obcięcia transakcji log kiedykolwiek zostanie
osiągnięty "Checkpoint".
Jeżeli jest włączona ta opcja, nie można zachować transakcji log podczas
standartowego tworzenia kopii zapasowej. Dlatego należy rozważyć w swoim planie
tworzenia kopii użycie tej opcji.

 

DBCC jest narzędziem dzięki, któremu można uzyskać szczegółowych informacji o
bazach danych zarządzanych przez SQL Serwer. Ponieważ SQL Serwer jest bardzo
złożoną konstrukcją zawierającą wiele integralnych części, DBCC jest bardzo
użyteczne w przypadku gdy chcemy sprawdzić czy wszystko działa
prawidłowo.Ustawienie zapewniające najlepszy rezultat: Tryb
jednego użytkownika.
Zanim zaczniemy używać DBCC, ważne jest zrozumienie dwóch zasad. Po pierwsze
jeżeli ludzie łączą się z serwerem uaktualniają lub zmieniają coś, możesz
otrzymać błędy używając DBCC. Po drugie często będziemy musieli mieć wyłączny
dostęp do bazy. W tym przypadku należy użyć komendy sp_dboption, która
umożliwia osiągnięcie trybu jednego użytkownika. Składnia tej komendy jest
następująca:




sp_dboption <database name> , 'single user' ,
True
Użycie tego trybu zapobiegnie ingerencji innych użytkowników w systemie
podczas dokonywania kontroli bazy. Oczywiście zanim użyjemy tej komendy musimy
być pewni, że jesteśmy w bazie danych "the Master".
Jeżeli dokonujemy już kontroli systemu przy pomocy DBCC, możemy przywrócić
tryb pracy dla wielu użytkowników. Dokonuje się tego za pomocą komendy
sp_dboption.
Na przykład:




sp_dboption 'pubs', 'single user',
False
gdzie pubs - nazwa bazy danych.Używanie opcji DBCC
DBCC wspomaga wiele różnych opcji. Teraz będą opisane te, które są
najczęściej używane.
Używanie NEWALLOC
NEWALLOC zastępuje poprzednio używaną komendę CHECKALLOC. Przy
używaniu CHECKALLOC system zatrzymywał się na pierwszym znalezionym
błędzie czasami nie znajdował niektórych problemów. NEWALLOC nie
zatrzymuje się gdy znajdzie błąd, ale kontynuuje pracę dopóki nie znajdzie
wszystkich błędów w strukturze bazy danych. Ma ona następującą składnie:




DBCC NEWALLOC <database name>
Jeżeli opuścimy parametr <database name> , SQL Serwer sprawdzi
bieżącą bazę danych.
Kiedy uruchomimy NEWALLOC zwróci on szczegółowe informacje o naszym
systemie i bazach danych. Poniżej zamieszczone są fragmenty zwracanych
informacji:




Checking
pubs***************************************************************




TABLE: sysobjects
OBJID = 1




INDID=1
FIRST=1
ROOT=8
DPAGES=4
SORT=0




   Data level: 1. 4 Data Pages in 1
extents.   Indid : 1. 1 Index Pages in 1
extents.




INDID=2
FIRST=40
ROOT=41
DPAGES=1
SORT=1




   Indid : 2. 3 Index Pages in 1 extents.TOTAL # of
extents =
3***************************************************************




TABLE: sysindexes
OBJID = 2




INDID=1
FIRST=24
ROOT=32
DPAGES=4
SORT=0




   Data level: 1. 4 Data Pages in 1
extents.   Indid : 1. 1 Index Pages in 1
extents.TOTAL # of extents =
2......***************************************************************




TABLE: pub_info
OBJID = 864006109




INDID=1
FIRST=568
ROOT=584
DPAGES=1
SORT=0




   Data level: 1. 1 Data Pages in 1
extents.   Indid : 1. 1 Index Pages in 1
extents.




INDID=255
FIRST=560
ROOT=608
DPAGES=0
SORT=0




TOTAL # of extents =
2......***************************************************************Processed
49 entries in the Sysindexes for dbid 4.Alloc page 0 (# of extent=32
used pages=57 ref pages=57)Alloc page 256 (# of extent=25 used
pages=34 ref pages=34)Alloc page 512 (# of extent=15 used pages=39 ref
pages=39)Alloc page 768 (# of extent=1 used pages=1 ref
pages=1)Alloc page 1024 (# of extent=1 used pages=1 ref
pages=1)Alloc page 1280 (# of extent=1 used pages=1 ref
pages=1)......Alloc page 31744 (# of extent=1 used pages=1 ref
pages=1)Alloc page 32000 (# of extent=1 used pages=1 ref
pages=1)Total (# of extent=196 used pages=261 ref pages=254) in this
databaseDBCC execution completed. If DBCC printed error messages, see
your      System Administrator.

Można zobaczyć jak wielka ilość informacji zostaje zwrócona. Dobrą stroną
tego jest fakt, że należy szukać w raporcie tylko wyjątków. Drugą zaletą jest
to, że jeżeli zostanie zwrócony komunikat błędu, powinna zostać również zwrócona
instrukcja zawierająca informacje w jaki sposób usunąć błąd.
Używanie CHECKDB
Jeżeli uruchomimy CHECKDB każda tablica i związane z nią dane,
indeksy i wskaźniki stają się ważne. Wszystkie zostają sprawdzone aby
zapewnić, że odpowiednie relacje informacji są poprawne. Składnia tej komendy
jest następująca:




DBCC CHECKDB <database name>
Jeżeli opuścisz parametr <database name> , SQL Serwer sprawdzi
bieżącą bazę danych.
Oto próbka zwracanych przez komendę informacji:




Checking pubsChecking 1The total number of data pages in this
table is 4.Table has 70 data rows.Checking 2The total number
of data pages in this table is 4.Table has 49 data rows.Checking
3The total number of data pages in this table is 10.Table has 283
data rows.Checking 4The total number of data pages in this table
is 1.Table has 29 data rows.Checking 5The total number of data
pages in this table is 23.Table has 165 data
rows.......Checking 592005140The total number of data
pages in this table is 1.Table has 14 data rows.Checking
688005482The total number of data pages in this table is 2.Table
has 43 data rows.Checking 864006109The total number of data pages
in this table is 1.The total number of TEXT/IMAGE pages in this table
is 73.Table has 8 data rows.DBCC execution completed. If DBCC
printed error messages, see your      System
Administrator.
Komenda również sprawdza tablice systemowe. Używając CHECKDB
sprawdzisz wszystkie tablice we wszystkich aspektach danej bazy danych.
Używanie DBCC SHRINKDB
Jeżeli tworzymy bazę danych, musimy często przewidzieć ile przeznaczyć
miejsca na jej tablice. Jeżeli baza danych jest już w trakcie tworzenia możesz
określić jej wielkość. Jeżeli zajdzie potrzeba zmniejszenia jej rozmiarów możesz
użyć komendy SHRINKDB. Należy zapamiętać, że SHRINKDB pracuje na
stronach. To znaczy, że musisz określić nowy rozmiar bazy i podzielić przez
2048 (rozmiar strony bazy danych) aby uzyskać wartość oczekiwaną przez komendę .
Składnia tej komendy jest następująca:




DBCC SHRINKDB <database name> ,<new
size>
Dobrym pomysłem jest nie zmniejszać "the Master" bazy danych, ta baza
zawiera wszystkie informacje o twoim systemie. Jak okaże się, że zmniejszenie
tej bazy danych jest niezbędne, z jakiegoś powodu, upewnij się przedtem, że
zrobiłeś jej kopie zapasową.
Jeżeli użyjesz komendy SHRINKDB bez parametru <new size> SQL
Serwer zwróci najmniejszą możliwą wielkość bazy danych. Możesz użyć tej wartości
do określenia nowego rozmiaru bazy.
Rzadko powinno się stosować najmniejszą wartość bazy danych przy zmniejszaniu
jej rozmiarów ponieważ będzie to sprzeczne z założeniami projektowania baz
klient/serwer SQL.
Używanie "uaktualniania statystyk" i "rekompilacji"
SQL Serwer wiele zyskuje przez inteligentny proces umieszczania danych w
tablicach. Ta analiza ma różne formy, ale najbardziej znaczący jest egzamin
polegający na uzyskaniu optymalnej drogi odzyskania informacji.
Jako przykład tego, rozważmy marszrutę do twojego domu. Zapewne masz
obliczoną najszybszą drogę do twojego domu z miejsca pracy. Jasne jest, że
jeżeli znajdziesz optymalną drogę to pójdziesz nią nawet wtedy gdy ktoś ci
zaproponuje inną ponieważ miałeś czas aby rozważyć wszystkie możliwości
i wybrać tą jedyną poprawną.
Rozważanie nowej drogi byłoby sensowne gdyby została zaoferowana lepsza droga
lub gdyby konstruowanie nowej drogi na podstawie dotychczasowej było
nieskuteczne.
W Serwerze SQL ta analogia obowiązuje. "Drogi" serwera zawierają się w
indeksach do danych w systemie. To są ścieżki, które rozważamy przy wyborze
optymalnego dostępu do danych.
Jeżeli dodasz do tablicy liczbę wierszy większą niż na przykład 20 procent
tablicy powinieneś rozważyć możliwość uaktualnienia statystyk związanych z
tablicą. Można to zrobić następująco:




update statistics <table name>[.index
name]
na przykład:




update statistics authors
Nie używamy cudzysłowu przy podawaniu nazwy tablicy.
Możesz wyszczególnić jeden indeks do uaktualnienia lub informacje zawarte w
całej bazie. Jeżeli wskazujesz indeks musisz w sposób jawny wskazać tablicę, w
której można go znaleźć.
Ostatnim krokiem przy uaktualnianiu indeksów jest powtórne przeliczenie
optymalnych "ścieżek" w bazie. Uzyskuje się to poprzez rekompilacje składowanych
procedur używających statystyk.
Generalnie procedury są kompilowane zaraz po uruchomieniu Serwera SQL. Nie
jest to jedyny moment kiedy kompilacja następuje automatycznie, ale niestety nie
następuje ona po uaktualnieniu statystyk.
Rekompilacja procedur następuje poprzez ustawienie flag w tablicy, które
unieważniają kopie przechowywanych procedur. To powoduje, że SQL Serwer wgrywa
i rekompiluje nowe procedury. Aby ustawić flagi należy użyć komendy:




sp_recompile <table name>
Jeżeli nie dojdzie do rekompilacji po uaktualnieniu statystyk, nastąpi to
dopiero po powtórnym uruchomieniu serwera.
Nie można nic zniszczyć uaktualniając statystyki ani rekompilując procedury,
ale powinno się to robić przy jak najmniejszej ilości aktywnych użytkowników w
systemie. Dobrym pomysłem jest regularne uaktualnianie statystyk
i dokonywanie rekompilacji np. raz w miesiącu. Należy to zrobić również
zaraz po postawieniu serwera, a w dni kiedy wpisywanych jest wiele danych nawet
częściej niż raz dziennie.

 

Z SQL Server, problem archiwizacji jest wiele ważniejszy niż na samodzielnej
stacji roboczej. Baza danych na SQL Serwer jest przecież eksploatowana przez
wielu pracowników i archiwizacja danych co jakiś czas jest bardzo ważna.
Strata danych może narazić firmę na ogromne wydatki związane z ponownym ich
wprowadzaniem. SQL Server przewiduje kilka sposobów ochrony danych.
Jak często archiwizować dane?
Pierwszą rzeczą o jaką zapyta nasz odbiorca będzie "Jak często mam
archiwizować dane?". Odpowiedź jest prosta, a zależy od tego jaką ilość danych
możemy stracić w razie awarii. Konkretna odpowiedź zależy oczywiście od ilości
tworzonych nowych informacji w bazie danych. Najlepiej byłoby oczywiście,
gdybyśmy w razie awarii nie tracili żadnych danych. Jest to w pewnym stopniu
możliwe poprzez tworzenie kopii bazy danych, czyli tzw. mirroring.
Ponieważ mirroring jest kosztowniejszy, dlatego częściej stosuje się
archiwizację danych. Pomocny jest przy tym Transaction Log.
Transaction Log zawiera dane o tym co zmieniło się w bazie od jej
ostatniej archiwizacji.
Archiwizacje bazy danych powinno przeprowadzać się nie rzadziej niż raz w
tygodniu z codziennym backup-em Transaction Log.
Najlepszym systemem archiwizacji jest system z tzw. rotating backups.
Tabela 18.1 przedstawia proponowany cykl archiwizacji danych. Jeżeli
archiwizacja odbywa się na taśmę, roczne zapotrzebowanie na ten właśnie nośnik
wynosi 29 sztuk. 14 taśm jest używanych do cotygodniowej archiwizacji, a 13 do
comiesięcznych. Pozostałe dwie taśmy są używane do 1) archiwizacji
Transaction Log 2) do początkowej archiwizacji całej bazy danych.
Pamiętać należy, że dotyczy to jedynie archiwizacji bieżącej bazy danych, a
nie do odtwarzania historycznych zbiorów.

Tabela 18.1


Numer kasety
Kaseta używana do archiwizacji danych z odpowiedniego dnia tygodnia
Komentarz

 
Poniedziałek 
Archiwizacja dla pierwszego poniedziałku z dwutygodniowego cyklu

 
Wtorek
 

 
Środa
 

 
Czwartek
 

 
Piątek
 

 
Sobota
 

 
Niedziela*
 

 
Poniedziałek
Archiwizacja drugiego poniedziałku z cyklu

 
Wtorek
 

 
Środa
 

 
Czwartek
 

 
Piątek
 

 
Sobota
 

 
Niedziela*
 
* Te taśmy
powinny być przeniesione do osobnego, bezpiecznego miejsca
Taki przepis archiwizacji danych pozwala na odtworzenie bazy w przypadku
zauważenia błędu w przeciągu dwóch tygodni. Polecany jest dwutygodniowy cykl
archiwizacji, ponieważ można zauważyć błąd, ale nie musi to nastąpić w chwili
jego pojawienia się.Archiwizacja i odtwarzanie danych
Archiwizacja odbywa się poprzez kopiowanie danych z systemu do odpowiedniego
urządzenia, które jest rozpoznane przez SQL Server jako magazyn informacji
i może być zarówno plikiem na dysku, jak i taśmą. W razie potrzeby SQL
kopiuje potrzebne informacje do jednego pliku na dysku, który to plik może
później zostać przeniesiony na taśmę, na inny dysk twardy lub na dysk twardy na
innym serwerze, którego akurat używamy do archiwizacji.
Najlepszą droga do archiwizacji danych jest używanie SQL Enterprise Manager.
Aby rozpocząć procedurę archiwizacji z Tool menu wybierz Database
Backup/Restore. Ustawianie urządzenia do archiwizacji
Pierwszą rzeczą jaką będziemy musieli zrobić jest ustawienie urządzenia, na
którym system będzie tworzył backup. Lista dostępnych urządzeń jest
widoczna w oknie dialogowym okna Backup Devices. Możemy wybrać jedno z
nich, lub stworzyć własne.
Aby stworzyć własne urządzenie należy nacisnąć przycisk New pod oknem
Backup Devices. Zostanie otworzone nowe okno - New Backup Devices,
a użytkownik zostanie zapytany o nazwę nowego urządzenia.
Można podać ścieżkę, która wskazuje na inny system. W ten sposób unikniemy
kopiowania backup-u z naszego systemu na drugi używając do tego innych
nośników.
Rozważmy tworzenie nowego urządzenia dla każdego z 14-tu dni dwutygodniowego
cyklu archiwizacji opisanego powyżej. Wtedy będziemy mogli tworzyć zaplanowany
backup na innym systemie bez użycia taśmy w celu kopiowania
archiwizowanych danych. Jeżeli ustawimy system na tworzenie backup-u na
nowym urządzeniu bez opcji append flag, każdy z urządzeń, które
stworzyłeś będzie tylko tak duże, jak to potrzebne do wykonania pojedynczej
kopii bazy danych, którą archiwizujemy.
Ważne punkty, które warto zapamiętać dotyczące archiwizacji danych:
Należy pamiętać, że jeżeli tworzymy urządzenie archiwizacji na innym
serwerze, to serwer ten powinien być zawsze dostępny dla naszego.
Ilość wolnego miejsca na dysku tego serwera powinna być wystarczająca dla
tworzenia kopii bezpieczeństwa.
Jeżeli serwer z kopią bezpieczeństwa znajduje się w tym samym budynku co
SQL serwer, to w razie np. pożaru budynku nasza zapasowa kopia również może
ulec zniszczeniu. Dlatego preferowaną metodą archiwizacji danych jest ich
kopiowanie np. na taśmę i przetrzymywanie taśm w zupełnie innym budynku.
Najlepszą metodą jest przetrzymywanie zarchiwizowanych danych w dwóch
zupełnie innych miejscach, np. jedna kopia na serwerze, a druga na taśmie.


Po wskazaniu nazwy urządzenia archiwizacji naciskamy przycisk Create. SQL
Serwer stworzy nowe urządzenie, które będzie dostępne w oknie Backup
Devices.Uruchamianie procedury archiwizacji danych
Kilka ważnych punktów, o których należy pamiętać przy wyborze metody
archiwizacji:
należy pamiętać o archiwizacji Transaction Log pomiędzy backup-em
kolejnych baz danych;
należy upewnić się, że archiwizujemy każdą z baz, które chcemy
zarchiwizować;
należy pamiętać o archiwizacji głównej bazy danych;
Teraz należy wybrać pomiędzy archiwizacją ręczną (manualną)
i automatyczną.Manualna metoda archiwizacji
Daje ona większą kontrolę nad samym procesem archiwizacji. Można obserwować
co jest archiwizowane i w jaki sposób w przeciwieństwie do archiwizacji
automatycznej, w której kopia bezpieczeństwa tworzona jest po prostu
automatycznie.
Podczas, gdy backup jest uruchamiany po raz pierwszy musi być
zainicjalizowane urządzenie archiwizacji. Odbywa się to poprzez włączenie opcji
Initialize Device w oknie Options section. Aby rozpocząć
archiwizację wybieramy urządzenie i naciskamy ikonę Backup
Now.Automatyczna metoda archiwizacji
Najlepszą metodą archiwizacji jest automatyczne tworzenie kopii zapasowej co
pewien ustalony czas. Włączenie automatycznego backup-u polega na
włączeniu Schedule button (oczywiście wcześniej należy wybrać bazę, którą
chcemy archiwizować oraz urządzenie archiwizacji).
Jeżeli tworzymy backup typu Append, system poprosi o wskazanie
nazwy do której chcemy dodawać backup. Kiedy wskażemy nazwę zobaczymy na
ekranie okno Task.
Należy zwrócić uwagę na okno SQL Command text box. Pokazuje ono jakie
komendy można uruchomić z ISQL, które uzupełnią manualny backup. To jest
dobre rozwiązanie do ręcznego wpisania komend, ale można je zaimplementować
później w każdej twojej aplikacji.
Pierwsze dwie opcje w oknie dialogowym umożliwiają stworzenie pojedynczego
backup-u naszej bazy. Zalecane jest, aby pierwszy backup był całkowity
i sprawdzany.
Należy wybrać wszystkie opcje, które chcemy włączyć. Można to zrobić klikając
na przycisk Options w oknie Schedule Backup. Najbardziej
prawdopodobne jest logowanie do Windows NT Event Log. Zalecane jest
włączenie opcji poprawnego logowania. Daje to mechanizm sprawdzania poprawnego
lub błędnego logowania. Opcja ta jest używana dla powiadamiania za pomocą
e-mail, jeżeli oczywiście używa się mail services w SQL Server. Jeżeli
istnieje możliwość zatkania się sieci można ustawić ilość powtórzeń.
Klikamy OK, aby potwierdzić zmiany i zamknąć okno dialogowe.
Backup będzie robiony automatycznie w tle, ale należy przeglądać logi
jakie tworzy backup podczas każdej archiwizacji. Są one dostępne z menu
Serwera z Scheduled Tasks.
Jeżeli nie jesteśmy pewni jakie zadania stworzyliśmy, które mogą zaszkodzić
pracy backup-u, należy pamiętać, że to my wybieramy, opcje
backup-u, którą potrzebujemy przed początkiem pracy z zadaniami. Ponieważ
każde z zadań pracujących w tle jest kontrolowane przez Tasks listing,
można zniszczyć proces, który kontroluje replikacje oraz wiele innych prac
systemu, jeśli skasujemy lub zmodyfikujemy nieprawidłowe.
Można również użyć Task listing do sprawdzenia statusu
backup-u, jako inną drogę sprawdzenia problemów. Możesz użyć kombinacji
Task listing i NT Event log do wykrycia każdych problemów,
które można spotkać podczas archiwizacji danych.
Należy pamiętać, że musimy być absolutnie pewni, że zarchiwizowaliśmy
wszystkie dane zgodnie z następującymi punktami:
backup głównej bazy danych;
backup wszystkich baz danych, które chcemy archiwizować;
backup wszystkich transaction logs dla każdej z baz;
Używanie i założenia procesu odtwarzania danych z kopii
bezpieczeństwa
Jeżeli systematycznie tworzymy kopie bezpieczeństwa danych nie będzie
problemu, aby odtworzyć zniszczoną bazę.
Aby odtworzyć zniszczoną bazę należy:
Zainstalować SQL Server, jeżeli jest to konieczne.
Odtworzyć główną bazę danych, jeżeli jest to konieczne.
Zainstalować ponownie urządzenia archiwizacji, jeżeli jest to konieczne.
Odtworzyć ostatnią pełną zarchiwizowaną bazę danych.
Odtworzyć transaction logs, które zostały zarchiwizowane od
ostatniej odtworzonej bazy danych.
W ten sposób zostanie odtworzona baza danych od ostatniego backup-u
transaction log.
Jeżeli tworzymy nową bazę danych, należy ją utworzyć z opcją Create for
Load. Opcja to pozwala na utworzenie bazy bez początkowych ustawień
pointerów w bazie danych. Informacje te odtworzymy później z backup-u bazy
danych, nie ma więc potrzeby robić tego dwa razy, tym bardziej, że czas
instalowania bazy danych skróci nam się o połowę.
Kiedy wybierzemy z Tools menu Database Backup/Restore
i zaznaczymy opcję Restore ukaże się okno dialogowe zawierające
wszystkie możliwe do odtworzenia kopie bezpieczeństwa. Lista ta będzie również
zawierać czas, datę stworzenia backup-u oraz jego typ (baza danych lub
transaction log).
SQL Server automatycznie wypisze te bazy danych, które zostały całkowicie
i bez błędów odtworzone. Umożliwi to wybór różnych backup-ów, które
chcemy dołączyć do bazy danych. Jeżeli wiemy na pewno, że niektóre informacje
przed utratą bazy danych są poprawne można to zaznaczyć w oknie Until Time
text.
Jeżeli chcemy odtworzyć dane z kopii bezpieczeństwa należy nacisnąć
Restore Now.
Jeżeli stworzymy bazę danych z opcją Create for Load, będziemy musieli
odtworzyć opcje bazy przed rozpoczęciem pracy kogokolwiek z tą bazą. Należy
pamiętać, że dopóki tego nie zrobimy, baza będzie niedostępna i zaznaczona
dla innych jako "(loading)". Nikt, oprócz DBO nie będzie miał dostępu do
bazy. Aby odtworzyć opcje i umożliwić innym użytkownikom dostęp do bazy
należy wybrać z menu Manage, Databases. Wybieramy to co chcemy odtworzyć.
Wybieramy Select Options wtedy odznaczamy opcję DBO Use Only.
Kiedy zakończymy te działania należy przetestować bazę, czy na pewno
odtwarzanie jej przebiegło pomyślnie.
W przypadku odtwarzania z uszkodzonego systemu praktycznym będzie dokładne
sprawdzenie key role. Jako proces testowania rozpatrzmy bazę danych
PUBS jako Guinea pig.
Postępujemy zgodnie z następującym przepisem:
Wykonujemy backup bazy danych PUBS.
Zmieniamy jednego z autorów w tabeli Authors. Można dodać kolumnę,
zmienić imię albo cokolwiek, co będziemy mogli w łatwy sposób poprawić
później.
Wykonujemy backup transaction log. Została zachowana baza
podstawowa oraz zmiany, które zostały dokonane później.
Tworzymy nową bazę danych (np. RestoreTest). Nazwa nie ma
znaczenia, rozmiar bazy musi być wystarczający dla bazy PUBS. Tworzymy
tą bazę o rozmiarze 33M oraz transaction log o rozmiarze 30M.
Odtwarzamy bazę danych tylko na naszym systemie. Należy odznaczyć opcję
transaction log restoration.
Wchodzimy w ISQL/W i wybieramy kolumnę z tabeli Authors.
Wszystkie one powinny być prawidłowe. Dokonane nasze zmiany nie są jeszcze
widoczne, ponieważ zmian dokonaliśmy po archiwizacji bazy.
Otwieramy teraz tylko transaction log. Sprawdzamy raz jeszcze
tabelę Authors. Teraz zmiany dokonane przez nas są widoczne. Widzimy,
że transaction log został odtworzony prawidłowo.
Należy także eksperymentalnie sprawdzić różne możliwości zmian
i odtwarzania bazy danych. Tym sposobem można bez problemu odtworzyć
wszystkie zmiany bazy danych jakie były zrobione po ostatnim backup-ie
całej bazy, ale jednocześnie przed backup-em ostatniego transaction
log.Założenia i używanie Mirroring
W uzupełnieniu do archiwizacji i technologii odtwarzania danych
opisanych w poprzednim punkcie SQL Server ma również możliwość tworzenia tzw.
Mirroring. Ponieważ dyski twarde są najbardziej podatne na występowanie
błędów i utraty danych powinieneś zabezpieczać swoją bazę danych.
Mirroring polega na tworzeniu dokładnej kopii całej bazy danych w
innym miejscu wskazanym przez użytkownika przez urządzenia archiwizacji. Należy
pamiętaj, aby Mirroring tworzyć fizycznie na innym dysku niż nasza baza
danych, ponieważ w przypadku awarii dysku tracimy również
Mirroring.Działanie Mirroring
Mirroring jest tworzony kiedy SQL Server zapisuje zmiany na dwóch
różnych urządzeniach (np. na dwóch dyskach twardych). Podstawowe urządzenie jest
standardową bazą danych, natomiast dodatkowe urządzenie to nic innego jak jego
kopia, czyli nasz Mirroring. W przypadku awarii podstawowego dysku
twardego mamy dokładną kopię bazy w danym momencie na drugim dysku twardym.
Od tego momentu baza będzie zapisywała dane na drugim, zapasowym dysku, a po
wymianie uszkodzonego dysku należy uruchomić raz jeszcze bazę, aby przenieść ją
z dysku zapasowego na już sprawny dysk podstawowy.Ustawianie opcji
Mirroring
Jeżeli stworzyliśmy urządzenie archiwizacji klikamy na to urządzenie
i zaznaczamy Edit, aby modyfikować opcje Mirroring.
Klikamy na Mirroring aby wskazać gdzie ma być stworzony plik
Mirroring. Jeżeli wybierzemy położenie pliku Mirroring, SQL Server
będzie wykonywał Mirroring danej bazy danych.
Po wykonaniu całego procesu Mirroring urządzenie będzie kopiowane
przez SQL Server automatycznie. Od tego momentu SQL Server będzie dokonywał
zmian również na drugim, zapasowym urządzeniu.
Jeżeli zaimplementowaliśmy Mirroring do urządzenia, należy się upewnić
czy kopiowana jest również główna baza danych. Musimy pamiętać, że tylko z
głównej bazy danych istnieje możliwość odtworzenia danych gdy pierwsze
urządzenie ulegnie uszkodzeniu.
Jeżeli nie wykonujemy Mirroring głównej bazy, może się okazać, że nie
jest możliwe odtworzenie bazy danych w przypadku awarii urządzenia
podstawowego.
Końcową czynnością jest wskazanie SQL Server, że istnieje Mirroring
głównej bazy danych, z którego może skorzystać w przypadku awarii podstawowego
urządzenia. Główna baza jest niezbędna podczas startu SQL Server-a. Pozostałe
bazy danych są poddawane procesowi Mirroring automatycznie, więc te kroki
są potrzebne jedynie dla głównej bazy danych.
Są dwa parametry potrzebne dla SQL Server, które kontrolują główną bazę
danych: -r i -d. Wybieramy Server, SQL Server,
Configure aby otworzyć okno. Wciskamy przycisk Parameters na
stronie Server Options i teraz dodajemy parametry startowe.
Dodajemy nowy parametr -r <mirror location>, który wskazuje na
urządzenie Mirroring dla podstawowego urządzenia bazy danych. Należy
pamiętać, że nawet jeśli zaznaczyliśmy parametr -r, i jeśli uruchomimy
ponownie bazę system będzie jako pierwsze szukał bazy na podstawowy, urządzeniu.
Oznacza to, że musimy zostawić opcje -d, która pokazuje położenie podstawowego
urządzenia. Jeśli dodamy opcję -r wskazujemy na urządzenie dodatkowe, które
będzie przeglądane przez system jeżeli urządzenie podstawowe będzie
niedostępne.
Klikamy na przycisk Add aby stworzyć nowy parametr. Należy upewnić
się, że podaliśmy prawidłową ścieżkę dla urządzenia dodatkowego (parametr
-r).
Kiedy urządzenie podstawowe ulegnie uszkodzeniu, SQL Server automatycznie
będzie korzystał z urządzenia dodatkowego. Kiedy Mirroring jest aktywny
użytkownicy korzystający aktualnie z bazy danych nie zauważą nawet awarii
systemu. Będą nadal mogli kontynuować prace i zapisywać wszystkie
zmiany.
Gdy urządzenie podstawowe zostanie naprawione można w prosty sposób przenieść
bazę z powrotem. Odtwarzanie bazy polega na tym samym co wprowadzanie urządzenia
Mirroring. Po prostu podajemy nazwę, gdzie znajduje się Mirroring
bazy, a SQL Serwer zatroszczy się o resztę.
Jeżeli chcemy przełączyć z aktualnego urządzenia na urządzenie
Mirroring, wystarczy zamienić urządzenia i postępować zgodnie z
przepisem:
Wykonujemy Mirroring oryginalnego urządzenia.
Jeżeli urządzenie podstawowe uległo uszkodzeniu: SQL Server przełączy na
drugie urządzenie .
Wymieniamy, lub naprawiamy urządzenie podstawowe.
Przenosimy z powrotem bazę danych na urządzenie podstawowe.
Przełączamy bazę danych na urządzenie podstawowe poprzez wybór opcji
Switch to Mirror Device-Replace.
Wykonujemy Mirroring urządzenia.
Wykonując powyższe kroki dotarliśmy do punktu startowego. Baza danych pracuje
na urządzeniu podstawowym jednocześnie jest tworzony Mirroring bazy, w
przypadku awarii urządzenia podstawowego baza przełącza się na urządzenie
dodatkowe. Jak widać Mirroring jest bardzo pomocną opcją i w
przypadku awarii zaoszczędza nam wiele godzin spędzonych podczas odtwarzania
bazy danych z kopii bezpieczeństwa. Nie należy traktować tego jako doskonałe
zabezpieczenie swojej bazy, najlepiej równolegle z Mirroring stosować
archiwizację danych co jakiś czas najlepiej na nośnik, który możemy fizycznie
przenieść w inne miejsce.

 

SQL Transfer Object dostarcza możliwość przenoszenia informacji
pomiędzy bazami danych w systemie. Aby rozpocząć transfer należy wybrać źródłową
bazę danych, a następnie opcje transferu z Object menu. Standardowo
kopiowanie całej bazy danych jest tak łatwe jak wybranie bazy źródłowej,
docelowej i wciśnięcie przycisku "Start Transfer".
Możliwe jest również zainicjowanie procesu kopiowania według rozkładu
czasowego, takiego aby obciążenie serwera było najmniejsze.
Jeżeli potrzebujemy można użyć Transfer Object do tworzenia
elementarnej kopii zapasowej systemu, można to zrobić poprzez skopiowanie baz
danych na inny serwer. Należy jednak tego unikać.
Jeżeli wyłączy się opcję Transfer All Objects w Object menu
możliwe jest dokładne wybranie elementów do kopiowania po naciśnięciu przycisku
Choose Objects. Możliwe jest wybranie różnych opcji pozwalających
skopiowanie części bazy np. tylko tabel.
Wyłączając opcję Use Default Scripting i wciskając przycisk
Scripting Options, możemy jeszcze zmienić kilka dodatkowych opcji.
Transfer Object jest dobrym uzupełnieniem do tworzenia kopii
zapasowych i "mirroring" . Należy go używać do kopiowania krytycznych
komponentów systemu, a kopie zapasowe i "mirroring" stosować jako
zabezpieczenie przeciw katastroficznym błędom systemu.


Data ostatniej modyfikacji 25.XI.1999.Wszelkie uwagi mile widziane