Archiwizowanie i odtwarzanie bazy danych z wykorzystaniem programu Recovery Manager(część III – dalsza część)

Niniejszy artykuł stanowi kontynuację artykułów zamieszczonych w
poprzednich numerach PLOUG’tek. Część pierwsza dotyczyła ogólnej
architektury systemu wykorzystującego RMANa, sposobów pracy w środowisku
programu RMAN, rodzajów kopii bezpieczeństwa bazy danych, jakie oferuje Recovery
Manager
oraz kanałom komunikacyjnym i skryptom składowanym. W części drugiej
zostały omówione techniki sporządzania kopii archiwalnych bazy danych, katalog
odtwarzania i sposoby wyszukiwania informacji z tego katalogu. Natomiast część trzecia
artykułu jest poświęcona sposobom odtwarzania bazy danych z wykorzystaniem poleceń Recovery
Managera
(punkty dziesiąty i jedenasty) oraz obiektom bazy danych przechowującym
informacje dla RMANa (punkty dwunasty i trzynasty). W poprzednim numerze
PLOUG’tek przedstawiono już polecenia Recovery Managera służące do
odtwarzania danych (punkt dziesiąty).

11. Techniki odtwarzania bazy danych z wykorzystaniem Recovery Managera

Ilość danych, jaką można odzyskać po awarii bazy danych (np.
uszkodzenie dysku) jest zależna od zastosowanego sposobu archiwizacji (por. [Wre98]).
Baza danych pracująca w trybie bez archiwizacji plików dziennika powtórzeń umożliwia
tylko odzyskanie plików bazy danych z kopii archiwalnej. Natomiast baza danych pracująca
w trybie z archiwizacją plików dziennika powtórzeń, w najlepszym przypadku umożliwia
odzyskanie danych do momentu bezpośrednio poprzedzającego awarię.

W tym punkcie zostaną omówione podstawowe techniki odtwarzania danych
z wykorzystaniem programu Recovery Manager, tj.: odtwarzanie bazy danych z kopii
bezpieczeństwa wykonanych dla bazy danych pracującej w trybie NOARCHIVELOG oraz
sposoby odtwarzania bazy danych pracującej w trybie ARCHIVELOG, m.in. odtwarzanie
pełne i odtwarzanie niepełne.

11.1. Odtwarzanie bazy danych pracującej w trybie NOARCHIVELOG

Kopia bezpieczeństwa całej bazy danych sporządzona dla bazy
pracującej w trybie NOARCHIVELOG umożliwia odzyskanie bazy danych z kopii
archiwalnej (ang. restore) do stanu jaki był w momencie sporządzania tej kopii. Oznacza
to, że wszystkie zmiany wprowadzone do bazy po sporządzeniu kopii archiwalnej są
tracone.

W przypadku gdy baza danych pracuje w trybie NOARCHIVELOG
zniszczenie jakiegokolwiek pliku danych wiąże się ze stratą części danych. Procedura
odtwarzania polega na zastąpieniu aktualnych plików bazy danych pełną kopią
archiwalną.

Przed odzyskaniem ze zbioru archiwalnego kopii plików bazy danych
(polecenie restore database) należy odzyskać plik kontrolny (polecenie
restore controlfile
). Po zakończeniu procesu odzyskiwania pliku kontrolnego i
plików bazy danych należy wyzerować numery sekwencyjne dziennika powtórzeń (ponieważ
odzyskano plik kontrolny) i wykonać kopię bezpieczeństwa całej bazy danych.

Poniżej przedstawiono zbiór poleceń odzyskujący pliki bazy danych.

run {
allocate channel k1 type disk;
restore controlfile to ;
restore database;

sql
alter database open resetlogs„;
}

Zwykle baza danych posiada wiele plików kontrolnych umieszczonych na
różnych dyskach. W celu powielenia odzyskanego pliku kontrolnego w katalogach wskazanych
parametrem konfiguracyjnym CONTROL_FILES (pliku init.ora) należy
użyć polecenia replicate o następującej składni:

replicate controlfile from ;

Przykładowo, drugie z poniższych poleceń odzyskuje ze zbioru
archiwalnego plik kontrolny, który jest następnie powielany przez polecenie trzecie.

run { allocate channel k1 type disk;
restore controlfile to ;

replicate controlfile from ; }

11.2. Odtwarzanie pełne bazy danych pracującej w trybie ARCHIVELOG

Kopia bezpieczeństwa całej bazy danych sporządzona dla bazy
pracującej w trybie ARCHIVELOG umożliwia odzyskanie bazy danych z kopii, a
następnie odtworzenie danych na podstawie informacji zapisanych w zarchiwizowanych
plikach dziennika powtórzeń. Jeżeli wszystkie zarchiwizowane pliki dziennika
powtórzeń i wszystkie włączone (online) pliki dziennika są dostępne, wówczas
zawartość bazy danych można odzyskać do momentu bezpośrednio poprzedzającego
awarię.

Baza danych pracująca w trybie ARCHIVELOG może zostać
odtworzona:

  • w pełni, tj. do momentu bezpośrednio poprzedzającego awarię – odtwarzanie
    pełne
    (ang. full recovery),

  • do określonego momentu w czasie – jest to tzw. odtwarzanie
    niepełne
    (ang. partial recovery).

Odtwarzanie pełne, tj. do momentu bezpośrednio poprzedzającego
awarię można zrealizować na trzy następujące sposoby:

  • Odtwarzanie całej bazy danych – realizuje się w trybie MOUNT.
    Oznacza to, że baza jest niedostępna dla użytkowników. Jest to jedyny sposób
    odtworzenia bazy danych w przypadku zniszczenia plików należących do przestrzeni tabel SYSTEM.

  • Odtwarzanie pojedynczej przestrzeni tabel – realizuje się w
    trybie OPEN, przy wyłączonej (offline) tej przestrzeni tabel, której zawartość
    jest odtwarzana. W czasie odtwarzania użytkownicy mogą korzystać z bazy danych, ale
    wyłączona przestrzeń tabel jest dla nich niedostępna. Tego trybu nie można jednak
    stosować odtwarzając przestrzeń tabel SYSTEM, ponieważ przestrzeń ta jest
    niezbędna do pracy bazy danych.

  • Odtwarzanie pojedynczych plików danych – realizuje się przy
    otwartej lub zamkniętej bazie danych. Odtwarzane pliki danych muszą być wyłączone
    (offline), natomiast do danych znajdujących się w pozostałych plikach użytkownicy
    mają dostęp pod warunkiem, że baza jest otwarta. Tego trybu nie można jednak stosować
    w przypadku, gdy są odtwarzane pliki należące do przestrzeni tabel SYSTEM.

11.2.1. Odtwarzanie całej bazy danych

Odtwarzanie całej bazy danych pracującej w trybie z archiwizacją
plików dziennika powtórzeń jest realizowane za pomocą polecenia recover database
i przebiega w następujący sposób:

  1. Przydzielenie kanału komunikacyjnego dla RMANa (polecenie allocate
    channel
    ).

  2. Odzyskanie ze zbioru archiwalnego wszystkich plików danych
    (polecenie restore database).
    W przypadku, gdy istnieje wiele zbiorów archiwalnych sporządzonych dla odtwarzanej bazy
    danych, RMAN wybiera zbiór sporządzony jako ostatni.

  3. Odtworzenie bazy danych (polecenie recover database).

Sekwencja poleceń Recovery Managera prowadząca do odtworzenia
całej bazy danych została przedstawiona poniżej. Sesja RMANa nie korzysta z
katalogu odtwarzania. Zakładamy, że po awarii baza danych została zamontowana
poleceniem startup mount. Po odtworzeniu baza danych zostaje automatycznie
otwarta.

D: >rman80 target internal/zebra nocatalog
RMAN> run {
2> allocate channel k1 type disk;
3> restore database;
4> recover database;
5> sqlalter database open„;
6> }

11.2.2. Odtwarzanie bazy danych z pominięciem wybranych przestrzeni tabel

Poniżej przedstawiono sekwencję poleceń prowadzących do:

  • odzyskania plików bazy danych z wyjątkiem plików przestrzeni LAB_TEMP;

  • odtworzenia bazy danych z wyjątkiem przestrzeni LAB_TEMP,

  • usunięcia przestrzeni LAB_TEMP.

RMAN> run {
2> allocate channel k1 type disk;
3> restore database skip tablespace lab_temp;
4> recover database skip tablespace lab_temp;
5> sqlalter database open„;
6> sqldrop tablespace lab_temp”;
7> release channel k1;
6> }

11.2.3. Odtwarzanie bazy danych z wykorzystaniem zbiorów archiwalnych inkrementalnych

Ten sposób odtwarzania zostanie zilustrowany następującym
przykładem. Przyjmijmy, że w niedzielę sporządzono zbiór archiwalny bazy danych
poziomu 0. W poniedziałek sporządzono zbiór archiwalny poziomu 1, we wtorek – poziomu
2, a w środę – również zbiór poziomu 2. W czwartek rano uszkodzeniu uległa
większość plików danych. Odtworzenie bazy danych w tym przypadku wymaga odzyskania
zbioru poziomu 0 (z niedzieli), 1 (z poniedziałku) i obu zbiorów poziomu 2 (z wtorku i
środy) i zaaplikowaniu zmian znajdujących się w tych zbiorach. Przykładową sekwencję
poleceń prowadzącą do odtworzenia bazy danych przedstawiono poniżej.

Należy zwrócić uwagę na to, że zbiory archiwalne poziomów
większych niż 0 nie są jawnie ani odzyskiwane poleceniem restore ani
odtwarzane poleceniem recover. Zawartość tych zbiorów jest niejawnie
aplikowana do bazy danych (po odzyskaniu zbioru poziomu 0) w czasie odtwarzania bazy
danych poleceniem recover database.

RMAN> run {
2> allocate channel k1 type disk;
3> restore database;
4> recover database;
5> sqlalter database open„;
6> }

RMAN-03022: compiling command: allocate

RMAN-08016: channel k1: starting datafile backupset restore
RMAN-08502: set_count=40 set_stamp=375531641
RMAN-08019: channel k1: restoring datafile 1
RMAN-08509: destination for restore of datafile 1: D:DYSK1LABLABSYSTEM.DBF

RMAN-08024: channel k1: restore complete
RMAN-03022: compiling command: recover

RMAN-08039: channel k1: starting incremental datafile backupset restore
RMAN-08502: set_count=41 set_stamp=375531802
RMAN-08019: channel k1: restoring datafile 1
RMAN-08509: destination for restore of datafile 1: D:DYSK1LABLABSYSTEM.DBF

RMAN-08511: piece handle=D:DYSK4ARCHIWUMDB1_41_1_375531802.BAK params=NULL
RMAN-08024: channel k1: restore complete
RMAN-08039: channel k1: starting incremental datafile backupset restore
RMAN-08502: set_count=42 set_stamp=375531899
RMAN-08019: channel k1: restoring datafile 1
RMAN-08509: destination for restore of datafile 1: D:DYSK1LABLABSYSTEM.DBF

RMAN-08511: piece handle=D:DYSK4ARCHIWUMDB2_42_1_375531899.BAK params=NULL
RMAN-08024: channel k1: restore complete
RMAN-08039: channel k1: starting incremental datafile backupset restore
RMAN-08502: set_count=43 set_stamp=375531993
RMAN-08019: channel k1: restoring datafile 1
RMAN-08509: destination for restore of datafile 1: D:DYSK1LABLABSYSTEM.DBF

RMAN-08511: piece handle=D:DYSK4ARCHIWUMDB2_43_1_375531993.BAK params=NULL
RMAN-08024: channel k1: restore complete

RMAN-08054: starting media recovery
RMAN-08055: media recovery complete

11.2.4. Odtwarzanie pojedynczego pliku danych z wykorzystaniem zbioru archiwalnego

Odtwarzanie pliku danych do jego oryginalnego katalogu przebiega w
sposób następujący:

  1. Przydzielenie kanału komunikacyjnego dla RMANa (polecenie allocate
    channel
    ).

  2. Wyłączenie uszkodzonego pliku danych (polecenie alter
    database datafile
    offline
    ).

  3. Odzyskanie pliku ze zbioru archiwalnego (polecenie restore
    datafile
    ).

  4. Odtworzenie zawartości odzyskanego pliku danych (polecenie recover
    datafile
    ).

  5. Włączenie odtworzonego pliku danych (polecenie alter database
    datafile
    online
    ).

Przykładowy scenariusz odtwarzania pojedynczego pliku przedstawiono
poniżej.

W czasie otwierania bazy danych administrator otrzymał następujący
komunikat:

SVRMGR> startup mount
SVRMGR> alter database open;
alter database open
*
ORA-01157: cannot identify data file 2 – file not found
ORA-01110: data file 2:

Sekwencja poleceń Recovery Managera prowadząca do odtworzenia
pliku danych o numerze 2 została przedstawiona poniżej.

D:>rman80 target internal/zebra nocatalog

RMAN> run {

2> allocate channel k1 type disk;

3> sqlalter database datafile 2 offline„;

3> restore datafile 2;
4> recover datafile 2;
5> sqlalter database datafile 2 online„;
6> }

Uszkodzony plik może być również wyłączony z poziomu programu Server
Manager
. W czasie odtwarzania pliku baza danych może być otwarta lub zamontowana.
Bazę danych można otworzyć (również z poziomu Server Managera) dopiero
po wyłączeniu uszkodzonego pliku danych.

Uwaga: w powyższym przykładzie plik wskazywany był za pomocą
jego numeru, można jednak posłużyć się jego pełną nazwą ujętą w apostrofy.
Numery i nazwy plików i ich nazwy są przechowywane m.in. w dynamicznej tabeli systemowej
V$DATAFILE.

W przypadku, gdy odzyskiwanego pliku danych nie można wgrać na jego
oryginalne miejsce (np. z powodu awarii dysku) należy plik ten wgrać do katalogu na
sprawnym dysku. W celu wskazania nowego katalogu należy posłużyć się poleceniem set
newname
. Następnie należy włączyć ten plik do bazy danych poleceniem switch.
W poniższym przykładzie plik o numerze 2 (tj. lab_dane.dbf) został wgrany
do nowego katalogu c:lab, a następnie włączony do bazy danych.

RMAN> run {
2> allocate channel k1 type disk;
3> set newname for datafile 2 to
;
4> sqlalter database datafile 2 offline„;
5> restore datafile 2;
6> switch datafile 2;
7> recover datafile 2;
8> sqlalter database datafile 2 online„;
9> }

11.2.5. Odtwarzanie pojedynczego pliku danych z wykorzystaniem kopii pliku

Odtwarzanie pliku danych do jego oryginalnego katalogu przebiega w
następujący sposób:

  1. Przydzielenie kanału komunikacyjnego dla RMANa (polecenie allocate
    channel
    ).

  2. Wyłączenie uszkodzonego pliku danych (polecenie alter
    database datafile
    offline
    ).

  3. Włączenie kopii archiwalnej pliku danych do bazy danych (polecenie swith
    datafile
    ).

  4. Odtworzenie zawartości odzyskanego pliku danych (polecenie recover
    datafile
    ).

  5. Włączenie odtworzonego pliku danych (polecenie alter database
    datafile
    online
    ).

Kopia pliku danych o numerze 2, tj. lab_dane.dbf została
sporządzona za pomocą następującej sekwencji poleceń:

run {
allocate channel k1 type disk;
copy tag „cpy df2 06.09.99 17:18”
(datafile 2 to );
release channel k1;
}

W czasie otwierania bazy danych administrator otrzymał następujący
komunikat:

SVRMGR> startup mount
SVRMGR> alter database open;
alter database open
*
ORA-01157: cannot identify data file 2 – file not found
ORA-01110: data file 2:

Sekwencja poleceń Recovery Managera prowadząca do odtworzenia
pliku danych z wykorzystaniem sporządzonej wcześniej jego kopii została przedstawiona
poniżej.

RMAN> run {
2> sqlalter database datafile 2 offline„;
3> switch datafile
4> to datafilecopy ;

2> recover datafile ;

3> sqlalter database datafile 2 online„;
6> }
RMAN-03022: compiling command: switch
RMAN-03023: executing command: switch
RMAN-08015: datafile 2 switched to datafile copy
RMAN-08507: input datafilecopy recid=16 stamp=375470366
filename=D:DYSK4ARCHIWUMCPY_DF2.BAK
RMAN-03022: compiling command: recover

RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-08515: archivelog filename=D:DYSK3LOGARCHARCH1.ARC thread=1 sequence=1
RMAN-08515: archivelog filename=D:DYSK3LOGARCHARCH2.ARC thread=1 sequence=2
RMAN-08055: media recovery complete

Informacja o włączonych poleceniem switch datafile plikach
danych jest dostępna za pomocą perspektywy słownika danych DBA_DATA_FILES i
dynamicznej tabeli systemowej V$DATAFILE, np.:

SVRMGR> select file_id, file_name from dba_data_files;

FILE_ID FILE_NAME
— ———————————————
1 D:DYSK1LABLABSYSTEM.DBF
2 D:DYSK4ARCHIWUMCPY_DF2.BAK
3 D:DYSK1LABLAB_TEMP.DBF
4 D:DYSK1LABLAB_RBS.DBF
5 D:DYSK1LABLAB_RECCAT.DBF
6 D:DYSK1LABLABSYSTEM1.DBF

11.2.6. Odtwarzanie przestrzeni tabel

Odtwarzanie przestrzeni tabel przebiega w sposób następujący:

  1. Przydzielenie kanału komunikacyjnego dla RMANa (polecenie allocate
    channel
    ).

  2. Wyłączenie uszkodzonego pliku danych oraz wszystkich pozostałych
    plików odtwarzanej przestrzeni tabel (polecenie alter database datafile offline).
    Jeżeli nie wszystkie pliki odtwarzanej przestrzeni tabel zostaną wyłączone, wówczas
    polecenie restore zakończy się błędem.

  3. Otwarcie bazy danych (polecenie alter database open).

  4. Wyłączenie odtwarzanej przestrzeni tabel (polecenie alter
    tablespace
    offline immediate
    ).

  5. Odzyskanie wszystkich plików przestrzeni tabel ze zbioru
    archiwalnego (polecenie restore tablespace).

  6. Odtworzenie zawartości przestrzeni tabel (polecenie recover
    tablespace
    ).

  7. Włączenie odtworzonej przestrzeni tabel (polecenie alter
    tablespace
    online
    ).

Przyjmijmy, że plik danych o numerze 2 uległ uszkodzeniu. Sekwencja
poleceń Recovery Managera prowadząca do odtworzenia przestrzeni tabel, w skład
której wchodzi plik o numerze 2 została przedstawiona poniżej.

D:>rman80 target internal/zebra nocatalog

RMAN> run {
2> allocate channel k1 type disk;
3> sqlalter database datafile 2 offline„;
4> sqlalter database open„;
5> sqlalter tablespace lab_dane offline immediate„;
6> restore tablespace lab_dane;
7> recover tablespace lab_dane;
8> sqlalter tablespace lab_dane online„;
6> }

11.2.7. Odzyskiwanie zarchiwizowanych plików dziennika powtórzeń

Do odzyskiwania zarchiwizowanych plików dziennika powtórzeń służy
polecenie, którego podstawowa składnia została przedstawiona poniżej:

restore archivelog parametry;

gdzie:

parametry umożliwiają wskazanie tych zarchiwizowanych plików
dziennika powtórzeń, które mają zostać odzyskane ze zbioru archiwalnego; pliki te
wskazuje się za pomocą takich samych parametrów, jakie specyfikuje się w poleceniu backup
archivelog
(por. punkt 7.6, części drugiej artykułu).

Domyślnie, zarchiwizowane pliki dziennika powtórzeń są odzyskiwane
do katalogu wskazywanego parametrem konfiguracyjnym LOG_ARCHIVE_DEST (pliku init.ora).
Położenie odzyskiwanych plików można jednak zmienić za pomocą polecenia:

set archivelog destination to ;

Wydane następnie polecenie recover będzie korzystało
ze zarchiwizowanych plików dziennika znajdujących się w katalogu wskazanym poleceniem set
archivelog destination
.

W poniższym przykładzie wskazane pliki dziennika zostaną odzyskane
do katalogu c:lab. Ze zbioru archiwalnego zostaną odzyskane tylko pliki o
numerach sekwencyjnych od 178 do 189. Kolejne polecenia prowadzą do odtworzenia pliku
danych o numerze 2.

run {

allocate channel k1 type disk;

set archivelog destination to ;

restore archivelog from logseq=178 until logseq=189 thread=1;

sqlalter database datafile 2 offline„;

restore datafile 2;

recover datafile 2;

sqlalter database datafile 2 online„;

release channel k1;
}

11.3. Odtwarzanie niepełne bazy danych pracującej w trybie ARCHIVELOG

Baza danych pracująca w trybie ARCHIVELOG może zostać
odtworzona do określonego momentu w przeszłości – jest to tzw. odtwarzanie niepełne
(ang. incomplete recovery). Odtwarzanie niepełne stosuje się najczęściej w
przypadku, gdy użytkownik usunął przypadkowo dane (np. tabelę) lub uszkodzeniu uległ
plik danych i niektóre zarchiwizowane pliki dziennika powtórzeń.

11.3.1. Wskazanie momentu w przeszłości

Przed rozpoczęciem odtwarzania należy odzyskać pliki bazy danych ze
zbioru archiwalnego lub kopii plików. W celu zminimalizowania czasu odtwarzania należy
wskazać zbiór archiwalny lub kopie plików sporządzone w momencie najbliższym
momentowi wystąpienia awarii. Do wskazywania odpowiedniego zboru archiwalnego lub kopii
plików służy klauzula from tag nazwa_opisowa polecenia restore.

Zbiór archiwalny lub kopię pliku sporządzone w określonym momencie
w przeszłości można również wskazać za pomocą polecenia set until o
następującej składni:

set until
time data_i_czas |
SCN nrSCN |
logseq nr thread wątek;

gdzie:

time data_i_czas oznacza datę i czas w formacie określonym
zmienną systemową NLS_DATE_FORMAT;

SCN nr oznacza numer SCN;

logseq nr thread wątek oznacza numer sekwencyjny tego
zarchiwizowanego pliku dziennika powtórzeń, który nie powinien już być aplikowany w
czasie odtwarzania; dla serwera w konfiguracji jednowątkowej wątek przyjmuje
wartość 1;

Przykładowo, jeżeli do bazy danych mają być zaaplikowane
zarchiwizowane pliki dziennika do numeru 191 włącznie, wówczas po słowie kluczowym logseq
należy podać numer 192.

W przypadku, gdy zostanie wykorzystane polecenie set until,
następujące po nim polecenie restore automatycznie wybierze taki zbiór
archiwalny lub kopię pliku, który umożliwi odtworzenie bazy danych do wyspecyfikowanego
momentu w najkrótszym czasie.

Za pomocą programu Recovery Manager można odtwarzać w sposób
niepełny całą bazę danych lub wybraną przestrzeń tabel. W tym celu należy
wykorzystać odpowiednio pierwsze lub drugie z poniższych poleceń recover.

recover database until punkt_w_przeszłości;
recover tablespace przestrzeń until punkt_w_przeszłości;

punkt_w_przeszłości wskazuje moment w przeszłości, do którego
należy odtworzyć stan bazy danych. Moment ten można wskazać za pomocą jednego z
trzech następujących słów kluczowych: time, SCN, logseq,
których znaczenie zostało omówione wcześniej.

Jeżeli wcześniej wykorzystano polecenie set until, to w
poleceniu recover nie specyfikuje się już parametru punkt_w_przeszłości.

Odtwarzanie bazy danych do wyspecyfikowanego momentu w przeszłości
przebiega w sposób następujący:

  1. Przydzielenie kanału komunikacyjnego dla RMANa (polecenie allocate
    channel
    ).

  2. Odzyskanie plików danych z odpowiedniego zbioru archiwalnego
    sporządzonego w przeszłości, wskazanego nazwą opisową (polecenie restore
    database from tag
    ).

  3. Odtworzenie bazy danych do wskazanego momentu (polecenie recover
    database until
    ).

  4. Otwarcie bazy danych z zerowaniem numerów sekwencyjnych (polecenie alter
    database open resetlogs
    ).

  5. Zarejestrowanie w katalogu odtwarzania nowej wersji (inkarnacji) bazy
    danych (polecenie reset database). Polecenie to może być wykonane tylko,
    gdy sesja RMANa korzysta z katalogu odtwarzania.

Przykładowy scenariusz archiwizowania i dotwarzania do momentu w
czasie przedstawiono poniżej. Rysunek 6 prezentuje kolejność wykonywania operacji w
bazie danych: w dniach 01.09 i 02.09 wykonywano operacje wstawiania, uaktualniania i
usuwania danych. Dnia 02.09, o godzinie 13:21 sporządzono pierwszy zbiór archiwalny bazy
danych. Zbiór ten otrzymał nazwę opisową full_02_09_13_21. Drugi zbiór
archiwalny utworzono dnia 04.09, o godzinie 20:27 i nadano mu nazwę opisową full_04_09_20_27.


Rys. 6. Scenariusz archiwizowania bazy danych

W celu odtworzenia bazy danych do stanu z dnia 02.09, godziny 14:25
należy:

  1. Odzyskać pliki bazy danych z ostatniego zbioru archiwalnego
    sporządzonego przed momentem, do którego baza będzie odtwarzana – warunek ten spełnia
    zbiór sporządzony 02.09, o godzinie 13:21. W tym celu, w poleceniu restore
    wyspecyfikowano klauzulę from tag, wskazującą zbiór archiwalny za
    pomocą jego nazwy opisowej.

  2. Odtworzyć bazę danych do momentu wskazanego klauzulą until
    time
    , polecenia recover.

RMAN> run {
2> allocate channel k1 type disk;
3> restore (database from tag )
4> from backupset;
5> recover database
6> until time ’02-09-1999:14:25:00′;

7> sqlalter database open resetlogs„;

8> release channel k1;
9> }
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: k1
RMAN-08500: channel k1: sid=11 devtype=DISK
RMAN-03022: compiling command: restore
RMAN-03022: compiling command: IRESTORE
RMAN-03023: executing command: IRESTORE
RMAN-08016: channel k1: starting datafile backupset restore
RMAN-08502: set_count=43 set_stamp=375110560
RMAN-08019: channel k1: restoring datafile 1
RMAN-08509: destination for restore of datafile 1: D:DYSK1LABLABSYSTEM.DBF
RMAN-08019: channel k1: restoring datafile 2
RMAN-08509: destination for restore of datafile 2: D:DYSK1LABLAB_DANE.DBF

RMAN-08509: destination for restore of datafile 6: D:DYSK1LABLABSYSTEM1.DBF
RMAN-08023: channel k1: restored backup piece 1
RMAN-08511: piece handle=D:DYSK4ARCHIWUMFULL_43_1_375110560.BAK params=NULL
RMAN-08023: channel k1: restored backup piece 2
RMAN-08511: piece handle=D:DYSK4ARCHIWUMFULL_43_2_375110560.BAK params=NULL
RMAN-08024: channel k1: restore complete
RMAN-03022: compiling command: recover

RMAN-08054: starting media recovery
RMAN-08515: archivelog filename=D:DYSK3LOGARCHARCH180.ARC thread=1 sequence=180

RMAN-08515: archivelog filename=D:DYSK3LOGARCHARCH182.ARC thread=1 sequence=213
RMAN-08055: media recovery complete
RMAN-03022: compiling command: recover(4)
RMAN-03022: compiling command: sql
RMAN-06162: sql statement: alter database open resetlogs
RMAN-03023: executing command: sql
RMAN-08031: released channel: k1

RMAN> reset database;

Uwaga: w powyższym przykładzie odtwarzanie wykonano przy
następujących założeniach:

  • zarchiwizowane pliki dziennika powtórzeń znajdowały się na dysku
    w katalogu wskazywanym parametrem konfiguracyjnym ARCHIVE_LOG_DEST (pliku init.ora);

  • zmiennej systemowej NLS_DATE_FORMAT nadano wartość .

Jak wspomniano, punkt w przeszłości można wyspecyfikować również
za pomocą polecenia set until. Poniżej przedstawiono zbiór poleceń
odzyskujący pliki danych i odtwarzający bazę danych do momentu określonego datą: ’02-09-1999:14:25:00′
(jak w poprzednim przykładzie).

run {
allocate channel k1 type disk;
set until time ’02-09-1999:14:25:00′;
restore database;
recover database;
sql alter database open resetlogs„;
release channel k1;
}

11.3.2. Wybór wersji (inkarnacji) bazy danych

Po pomyślnym zakończeniu odtwarzania do określonego momentu w
przeszłości jest tworzona nowa wersja bazy danych, zwana również inkarnacją (ang.
incarnation). Nowa wersja staje się wersją bieżącą. Istnieje jednak możliwość
wskazania jednej z poprzednich wersji, jako bieżącą. Służy do tego celu polecenie:

reset database to incarnation identyfikator_inkarnacji;

gdzie:

identyfikator_inkarnacji przyjmuje wartość atrybutu dbinc_key
(perspektywy RC_DATABASE_INCARNATION) rekordu opisującego wybraną wersję.

12. Perspektywy katalogu odtwarzania

Katalog odtwarzania udostępnia swoje informacje za pomocą tzw.
perspektyw katalogu odtwarzania. Oprócz poleceń report i list zawartość
katalogu odtwarzania można przeanalizować wydając odpowiednie zapytania do tych
perspektyw. Poniżej przedstawiono listę najczęściej wykorzystywanych perspektyw
katalogu odtwarzania.

RC_ARCHIVED_LOG

Perspektywa ta udostępnia informacje na temat wszystkich
zarchiwizowanych (przez proces ARCH) plików dziennika powtórzeń i kopii
tych plików wykonanych za pomocą polecenia copy archivelog. Nowe
zarchiwizowane pliki będą widoczne przez tę perspektywę dopiero po zsynchronizowaniu
katalogu odtwarzania (polecenie resync catalog). Natomiast jeżeli sesja RMANa
korzysta z katalogu odtwarzania, to po utworzeniu kopii wybranych plików dziennika
katalog jest synchronizowany automatycznie i kopie te pojawiają się w perspektywie RC_ARCHIVED_LOG,
np.:

RMAN> run {
2> allocate channel k1 type disk;
3> copy archivelog
4> to ;


5> release
channel k1;}
SQL> select al_key, stamp, name, archived, status

2 from rc_archived_log order by 3;

AL_KEY STAMP NAME ARC S
………….. …………………………. ……………………………………………………………………. ………………..
469 374834661 D:DYSK3LOGARCHARCH174.ARC YES A
470 374834664 D:DYSK3LOGARCHARCH175.ARC YES A
475 374837461 D:DYSK3LOGARCHARCH176.ARC YES A
480 374837593 D:DYSK3LOGARCHARCH177.ARC YES A
483 374838114 D:DYSK4ARCHIWUMLOGIARCH174.BAK YES A

Podobne informacje można uzyskać wydając również polecenie list
copy of archivelog
. Wartość atrybutu al_key perspektywy RC_ARCHIVED_LOG
odpowiada wartości kolumny Key, w liście uzyskanej za pomocą
polecenia list copy of archivelog.

Fizyczne usunięcie kopii pliku dziennika nie powoduje usunięcia
zapisu o nim z katalogu odtwarzania. Atrybut status przyjmuje wartość A – dla
plików dostępnych lub D – dla usuniętych za pomocą polecenia change
archivelog
delete
.

RC_DATABASE

Perspektywa ta udostępnia informacje na temat baz danych
zarejestrowanych w katalogu odtwarzania i informacje na temat bieżącej inkarnacji
każdej z tych baz, np.:

SQL> select * from rc_database;

DB_KEY DBINC_KEY DBID NAME RESETLOGS_CHANGE# RESETLOGS_TIME
……………. …………………… ……………….. ………….. ……………………………………. ………………………………
1 2 822167203 LAB 1 24-08-1999:21:39:47

db_key jest atrybutem kluczowym,

dbinc_key est unikalnym numerem bieżącej wersji (inkarnacji),

dbid jest unikalnym identyfikatorem bazy danych odczytanym z pliku
kontrolnego,

name jest nazwą bazy danych,

resetlogs_change# wskazuje numer SCN w momencie zerowania
numerów sekwencyjnych dziennika powtórzeń,

resetlogs_time podaje czas zerowania dziennika powtórzeń.

Po odtwarzaniu do momentu w przeszłości i wydaniu polecenia reset
database
wartość atrybutu dbinc_key, resetlogs_change# i resetlogs_time
ulegają zmianie, np.:

SQL> select * from rc_database;

DB_KEY DBINC_KEY DBID NAME RESETLOGS_CHANGE# RESETLOGS_TIME
……………. …………………… ……………….. ………….. ……………………………………. ………………………………
1 499 822167203 LAB 75010 02-09-1999:13:44:33

RC_DATABASE_INCARNATION

Perspektywa ta udostępnia historię tworzenia wersji (inkarnacji)
każdej zarejestrowanej bazy danych, np.:

SQL> select * from rc_database_incarnation;

DB_KEY DBID DBINC_KEY NAME RESETLOGS_CHANGE# RESETLOGS_TIME CUR PARENT_DBINC_KEY
……………… ………………… ……………………. …………… ……………………………………. …………………………….. ……………………………………………
1 822167203 2 LAB 1 24-08-1999:21:39:47 YES

db_key jest identyfikatorem bazy danych, do której należy wersja,

dbid jest unikalnym identyfikatorem bazy danych odczytanym z pliku
kontrolnego,

dbinc_key jest atrybutem kluczowym – identyfikatorem wersji,

name jest nazwą bazy danych,

resetlogs_change# wskazuje numer SCN w momencie zerowania
numerów sekwencyjnych dziennika powtórzeń,

resetlogs_time podaje czas zerowania dziennika,

cur określa, czy dana inkarnacja jest bieżącą (wartość YES),

parent_dbinc_key wskazuje na identyfikator wersji, z której
wywiedziono wersję bieżącą.

Po odtworzeniu do momentu w przeszłości i wydaniu polecenia reset
database
przez perspektywę są udostępniane wszystkie wersje bazy danych, np.:

SQL> select * from rc_database_incarnation;

DB_KEY DBID DBINC_KEY NAME RESETLOGS_CHANGE# RESETLOGS_TIME CUR PARENT_DBINC_KEY
……………. ………………. …………………… ………….. ……………………………………. …………………………….. …………………………………………….
1 822167203 2 LAB 1 24-08-1999:21:39:47 NO
1 822167203 499 LAB 75010 02-09-1999:13:44:33 YES

W powyższym przykładzie bieżąca wersja bazy danych, identyfikowana
kluczem 499 została wywiedziona z wersji identyfikowanej kluczem o numerze 2.

RC_BACKUP_SET

Za pomocą tej perspektywy można uzyskać informacje na temat zbiorów
archiwalnych, m.in.: identyfikator zbioru (atrybut bs_key), rodzaj kopii
archiwalnej (atrybut backup_type), poziom kopii inkrementalnych (atrybut incremental_level),
liczbę części składających się na zbiór (atrybut pieces) i status zbioru
(atrybut status).

Atrybut backup_type może przyjąć jedną z czterech wartości:
D, I, C, L. Wartość D oznacza pełną kopię
archiwalną bazy danych, I – oznacza kopię inkrementalną, C
kumulacyjną, a L – oznacza, że zbiór zawiera zarchiwizowane pliki dziennika
powtórzeń. Atrybut status może przyjąć wartość A (zbiór dostępny)
lub D (zbiór usunięty).

RC_BACKUP_PIECE

Perspektywa ta udostępnia informacje na temat części zbiorów
archiwalnych. Przykładowo, poniższe zapytanie umożliwia wyświetlenie identyfikatora
zbioru archiwalnego (atrybut bs.bs_key), statusu zbioru (bs.status),
identyfikatora części zbioru archiwalnego (bp.bp_key), numeru części zbioru (bp.piece#),
nazwy opisowej (bp.tag), nazwy pliku, w którym została zapisana część zbioru (bp.handle)
i statusu części zbioru archiwalnego (bp.status).

select bs.bs_key, bs.status,
bp.bp_key, bp.piece#, bp.tag, bp.handle, bp.status
from rc_backup_set bs, rc_backup_piece bp
where bs.bs_key=bp.bs_key
order by 1;

Status części zbioru archiwalnego może przyjąć wartość A (część
dostępna), U (część niedostępna) lub D (część usunięta).

RC_BACKUP_CONTROLFILE

Za pomocą tej perspektywy można odczytać informacje na temat kopii
archiwalnych plików kontrolnych wchodzących w skład zbioru archiwalnego.

RC_BACKUP_DATAFILE

Za pomocą tej perspektywy można odczytać informacje na temat kopii
archiwalnych plików danych wchodzących w skład zbioru archiwalnego, m.in.:
identyfikator pliku (atrybut bdf_key), rodzaj kopii archiwalnej (atrybut backup_type),
poziom kopii inkrementalnych (atrybut incremental_level), numer pliku (atrybut file#)
i status pliku (atrybut status).

Atrybut backup_type może przyjąć jedną z czterech wartości:
D, I, C, L. Wartość D oznacza pełną kopię
archiwalną, I oznacza kopię inkrementalną, C – kumulacyjną, a L oznacza
plik dziennika powtórzeń.

Atrybut status może przyjąć wartość A (plik
dostępny) lub D (plik usunięty).

Poniższe zapytanie dla każdego zbioru archiwalnego wyświetla numery,
nazwy i statusy plików wchodzących w skład danego zbioru archiwalnego.

select bs.bs_key, bdf.file#, df.name, bdf.status
from rc_backup_set bs, rc_backup_datafile bdf, rc_datafile df
where bs.bs_key=bdf.bs_key
and bdf.file#=df.file#
order by 1;

RC_BACKUP_REDOLOG

Perspektywa ta udostępnia informacje na temat tych plików dziennika
powtórzeń, które zostały umieszczone w zbiorze archiwalnym. Przykładowo, trzy pliki
dziennika o numerach od 187 do 189 zostały zapisane w zbiorze archiwalnym, poleceniem:

backup format
(archivelog from logseq=187 until logseq=189 thread=1);

Informacja o zarchiwizowaniu powyższych plików pojawia się w
perspektywie RC_BACKUP_REDOLOG.

SQL> select db_name, bs_key, sequence# from
rc_backup_redolog;

DB_NAME BS_KEY SEQUENCE#
……………….. ……………. ……………………
LAB 255 153
LAB 579 187
LAB 579 188
LAB 579 189

RC_CONTROLFILE_COPY

Perspektywa ta udostępnia informacje na temat kopii plików
kontrolnych sporządzonych przy pomocy polecenia copy lub sporządzonych z
poziomu Server Managera poleceniem alter database backup controlfile to plik,
a następnie skatalogowanych za pomocą polecenia catalog controlfilecopy.

RC_DATAFILE_COPY

Perspektywa ta udostępnia informacje na temat kopii plików danych
sporządzonych przy pomocy polecenia copy lub sporządzonych za pomocą
poleceń systemu operacyjnego, a następnie skatalogowanych za pomocą polecenia catalog
datafilecopy
.

RC_BACKUP_CORRUPTION

Perspektywa ta udostępnia informacje na temat uszkodzonych bloków
wykrytych podczas sporządzania zbiorów archiwalnych.

RC_COPY_CORRUPTION

Udostępnia informacje na temat uszkodzonych bloków wykrytych podczas
sporządzania kopii plików.

RC_TABLESPACE

Perspektywa ta udostępnia: informacje na temat wszystkich przestrzeni
tabel tych baz danych, które zostały zarejestrowane w katalogu odtwarzania oraz
informacje na temat przestrzeni usuniętych i istniejących w poprzednich inkarnacjach
bazy danych. Dla usuniętych przestrzeni tabel atrybuty drop_change# i drop_time
wskazują na moment usunięcia.

Po dodaniu nowej przestrzeni tabel lub usunięciu przestrzeni należy
zsynchronizować katalog odtwarzania (polecenie resync catalog), aby
informacje zostały przepropagowane do katalogu odtwarzania.

RC_DATAFILE

Perspektywa ta udostępnia: informacje na temat wszystkich plików
danych tych baz danych, które zostały zarejestrowane w katalogu odtwarzania oraz
informacje na temat plików należących do usuniętych przestrzeni – w tym przypadku
atrybuty drop_change# i drop_time wskazują na moment usunięcia pliku.

Po dodaniu nowego pliku do przestrzeni tabel lub usunięciu
istniejącego należy zsynchronizować katalog odtwarzania, aby informacje zostały
przepropagowane do katalogu odtwarzania.

RC_REDO_LOG

Perspektywa ta udostępnia informacje na temat włączonych (online)
plików dziennika powtórzeń tych baz danych, które zostały zarejestrowane w katalogu
odtwarzania.

Informacje o dodanych lub usuniętych plikach dziennika powtórzeń
zostaną przepropagowane do katalogu odtwarzania dopiero po jego zsynchronizowaniu z
plikiem kontrolnym.

13. Dynamiczne tabele systemowe przechowujące informacje na temat zbiorów
archiwalnych i kopii plików

Informacje na temat sporządzonych zbiorów archiwalnych i kopii
plików danych można uzyskać wydając odpowiednie zapytania do dynamicznych tabel
systemowych: V$BACKUP_REDOLOG, V$BACKUP_DATAFILE, V$BACKUP_SET, V$BACKUP_PIECE,
V$DATAFILE_COPY.

V$BACKUP_REDOLOG

Tabela ta przechowuje informacje na temat włączonych (online) plików
dziennika powtórzeń wchodzących w skład zbioru archiwalnego, podobnie jak perspektywa
katalogu odtwarzania RC_BACKUP_REDOLOG.

Przykładowo, po wykonaniu sekwencji poniższych poleceń

RMAN> run {
2> allocate channel k1 type disk;
3> backup
4> filesperset 20
5> format
6> (archivelog from logseq=187 until logseq=190 thread=1);
7> release channel k1;
8> }
RMAN-03022: compiling command: allocate

RMAN-08009: channel k1: starting archivelog backupset
RMAN-08502: set_count=44 set_stamp=376826398
RMAN-08014: channel k1: including archivelog in backup set
RMAN-08504: input archivelog thread=1 sequence=187 recid=42 stamp=375535094
RMAN-08014: channel k1: including archivelog in backup set
RMAN-08504: input archivelog thread=1 sequence=188 recid=43 stamp=375535098
RMAN-08014: channel k1: including archivelog in backup set
RMAN-08504: input archivelog thread=1 sequence=189 recid=44 stamp=375535272
RMAN-08013: channel k1: piece 1 created

w tabeli V$BACKUP_REDOLOG pojawiają się zapisy informujące o
umieszczeniu w zbiorze archiwalnym (identyfikowanym przez set_count=44 i set_stamp=376826398)
plików dziennika powtórzeń o numerach sekwencyjnych 187, 188 i 189.

SVRMGR> select set_stamp, set_count, sequence# from
v$backup_redolog;

SET_STAMP SET_COUNT SEQUENCE#
…………………………….. ………………………….. ………………………………………………………………………..
374600156 21 153
……… ..
376826398 44 187
376826398 44 188
376826398 44 189

V$BACKUP_SET

Tabela ta przechowuje informacje na temat sporządzonych zbiorów
archiwalnych, podobnie jak perspektywa katalogu odtwarzania RC_BACKUP_SET. Poniżej
przedstawiono przykładowe zapytanie do tej perspektywy i fragment jego wyniku.

SVRMGR> select set_stamp, set_count, backup_type, controlfile_included,
2> incremental_level, pieces
3> from v$backup_set;

SET_STAMP SET_COUNT B CON INCREMENTA PIECES
…………………………….. ……………………….. ……………. …………………. …………………. …………………..
374496233 2 D NO 0 1
……… .. .. .. .. ..
374503431 18 D YES 0 3
374503472 19 D NO 1 1
374600156 21 L NO 1 1

V$BACKUP_PIECE

Tabela ta przechowuje informacje na temat części zbiorów
archiwalnych, podobnie jak perspektywa katalogu odtwarzania RC_BACKUP_PIECE

V$BACKUP_DATAFILE

Tabela ta zawiera informacje na temat kopii archiwalnych plików danych
wchodzących w skład zbioru archiwalnego, podobnie jak perspektywa katalogu odtwarzania RC_BACKUP_DATAFILE.

V$DATAFILE_COPY

Tabela ta zawiera informacje na temat kopii plików danych
sporządzonych przy pomocy polecenia copy lub sporządzonych za pomocą
poleceń systemu operacyjnego, a następnie skatalogowanych za pomocą polecenia catalog
datafilecopy
. Informacje zapisane w tej tabeli są podobne do informacji
udostępnianych przez perspektywę katalogu odtwarzania RC_DATAFILE_COPY.

Przykładowo, po wydaniu poniższego polecenia copy
informacje o skopiowanym pliku danych pojawiają się w tabeli V$DATAFILE_COPY.

RMAN> run {
2> allocate channel k1 type disk;
3> copy tag „cpy df3 22.09.99 13:59”
4> (datafile 3 to );
5> release channel k1;
6> }

SQL> select stamp, name, tag, file# from v$datafile_copy;

STAMP NAME TAG FILE#
……………………. ………………………………………………………….. …………………………………….. ………..
374686638 D:DYSK4ARCHIWUMLAB_DANE.BAK DANE 28.08.99 2
……… …………………………………………….. …………………. ..
376840836 D:DYSK4ARCHIWUMCPY_DF3.BAK CPY DF3 22.09.99 13:59 3

Bibliografia

[O8BaR] Oracle8 Backup and Recovery Guide, rel. 8.0
[Backup8] Velpuri R., Oracle8 Backup & Recovery Handbook, Osborne McGraw-Hill,
1998, ISBN 0-07-882389-7
[Wre98] Wrembel R., Archiwizowanie danych i odtwarzanie bazy danych po awarii,
PLOUG’tki, numery 7/98, 8/98, 9/99
[WJZ99] Wrembel R., Jezierski J., Zakrzewicz M.: System Zarządzania Bazą Danych
Oracle7 i Oracle8
, Wydawnictwo NAKOM, Poznań, 1999, ISBN 83-86969-34-3

Robert Wrembel
Instytut Informatyki Politechniki Poznańskiej
e-mail: Robert.Wrembel@cs.put.poznan.pl