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

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

1. Wprowadzenie
W serii artykułów publikowanych w czasopiśmie PLOUG’tki (numery 7/98, 8/98, 9/99) zostały omówione podstawowe sposoby archiwizowania
danych i odtwarzania bazy danych Oracle7 w przypadku uszkodzenia nośników danych.
Niniejszy artykuł jest kontynuacją poprzednich, dlatego od Czytelnika jest wymagana
znajomość podstawowych zagadnień dotyczących archiwizowania i odtwarzania bazy danych,
omówionych we wspomnianych wcześniej numerach PLOUG’tek.
SZBD Oracle8 dostarcza nowego narzędzia, zwanego Recovery Manager (RMAN),
wspomagającego archiwizowanie i odtwarzanie bazy danych. RMAN jest dostępny jako
narzędzie pracujące w trybie: znakowym, graficznym – jako część programu Backup
Manager
(wchodzącego w kład pakietu Enterprise Manager), lub jako biblioteka
programowa.
Komunikacja z Recovery Managerem odbywa się za pomocą specjalnego języka
poleceń, niezależnego od systemu operacyjnego. Możliwa jest współpraca z popularnymi
systemami składowania danych, np. EMC/Epoch, Legato, Storage Tek, IBM, HP.
Recovery Manager umożliwia m.in.:

  • sporządzanie kopii bezpieczeństwa: całej bazy danych, wybranych przestrzeni tabel,
    wybranych plików danych;
  • sporządzanie nowych rodzajów kopii bezpieczeństwa bazy danych, tj. pełnych,
    inkrementalnych i kumulacyjnych, wykonywanych na poziomie fizycznym;
  • zautomatyzowanie procesów archiwizowania bazy danych i odtwarzania, dzięki
    zastosowaniu katalogu odtwarzania;
  • rejestrowanie operacji archiwizowania i odtwarzania w pliku dziennika;
  • zrównoleglenie operacji archiwizowania i odtwarzania;
  • uzyskanie informacji na temat sporządzonych kopii bezpieczeństwa.

W kolejnych punktach części pierwszej artykułu zostaną omówione
następujące zagadnienia: w punkcie drugim zostanie zaprezentowana ogólna architektura
systemu wykorzystującego RMANa. W punkcie trzecim zostanie przedstawiony sposób
pracy w środowisku programu RMAN. Punkt czwarty będzie poświęcony rodzajom
kopii bezpieczeństwa bazy danych, jakie oferuje Recovery Manager, a punkt piąty –
kanałom komunikacyjnym i skryptom składowanym. W części drugiej artykułu, w punkcie
szóstym i siódmym zostaną omówione techniki sporządzania kopii archiwalnych bazy
danych, punkt ósmy będzie prezentował katalog odtwarzania, a dziewiąty – sposoby
wyszukiwania informacji z tego katalogu. Część trzecia artykułu będzie zawierała
informacje dotyczące różnych sposobów odtwarzania bazy danych z wykorzystaniem
poleceń Recovery Managera (punkty dziesiąty i jedenasty) oraz opis obiektów bazy
danych przechowujących informacje dla RMANa (punkty dwunasty i trzynasty).
Omawiając składnie poleceń RMANa zastosowano następujące reguły: nawiasy
prostokątne oznaczają opcjonalność fragmentu polecenia ograniczonego tymi nawiasami,
znak | oznacza alternatywę elementów składni oddzielonych tym znakiem, natomiast
podkreślenie oznacza wartość lub słowo kluczowe domyślne. Klauzule, słowa kluczowe,
parametry i polecenia są pisane czcionką pogrubioną.

2. Architektura systemu
Ogólna architektura systemu wykorzystującego Recovery Managera została
przedstawiona na rysunku 1.
Recovery Manager wykorzystuje procesy usługowe systemu Oracle (ang. server
processes) do archiwizowania i odtwarzania danych. Procesy takie są odpowiedzialne za
sporządzanie kopii archiwalnych plików zabezpieczanej bazy danych oraz za odzyskiwanie i
odtwarzanie tych plików.
Informacje dotyczące parametrów pracy bazy danych oraz informacje na temat
archiwizowania i odtwarzania bazy danych są przechowywane w pliku kontrolnym.
Plik kontrolny (ang. control file) jest plikiem binarnym, który zawiera m.in.:
nazwę bazy danych, datę utworzenia bazy danych, informacje o wszystkich grupach
dziennika powtórzeń wraz ze wskazaniem bieżącej grupy, nazwę, lokalizację i rozmiar
każdego pliku dziennika powtórzeń, numer sekwencyjny bieżącego pliku dziennika
powtórzeń, nazwę, lokalizację, rozmiar i status (tylko do odczytu, do odczytu i
zapisu, włączony, wyłączony, wymagający odtworzenia) każdego pliku danych,
informacje dotyczące punktu kontrolnego. Plik kontrolny bazy Oracle8 zawiera
dodatkowo informacje na temat sporządzonych kopii archiwalnych RMANa oraz
zakończonych procesów odtwarzania danych. Dodatkowe informacje przechowywane w pliku
kontrolnym przyczyniają się do wzrostu jego rozmiaru. Rozmiar pliku kontrolnego bazy Oracle8
jest większy niż bazy Oracle7 i wzrasta wraz ze wzrostem liczby sporządzonych
kopii archiwalnych.
Rozmiar pliku kontrolnego można ograniczyć za pomocą parametru inicjującego CONTROL_FILE_RECORD_KEEP_TIME
(w pliku init.ora). Wartością tego parametru jest minimalna liczba dni, przez
które informacje dotyczące archiwizowania i odtwarzania są przechowywane w pliku
kontrolnym. Po przekroczeniu wyspecyfikowanej liczby dni, poprzednie informacje są
zastępowane nowymi.
Nowym komponentem systemu jest tzw. katalog odtwarzania (ang. recovery katalog)
przechowujący m.in.: informacje dotyczące przełączania i archiwizowania plików
dziennika powtórzeń, dane na temat fizycznej struktury zabezpieczanej bazy danych, kopii
bezpieczeństwa sporządzonych dla tej bazy, odtwarzania bazy oraz kody źródłowe
skryptów składowanych Recovery Managera. Katalog odtwarzania stanowi w istocie
niewielkie repozytorium znajdujące się w bazie danych innej niż zabezpieczana.
Zawartość katalogu odtwarzania może być prezentowana w formie raportów i zestawień.
Służą do tego celu polecenia report i list. Katalog odtwarzania powinien
zawsze przechowywać najnowsze informacje o zabezpieczanej bazie danych. Oznacza to, że
wszelkie zmiany struktury fizycznej (dodanie lub usunięcie pliku danych, pliku dziennika
powtórzeń) i logicznej (dodanie lub usunięcie przestrzeni tabel, dodanie lub usunięcie
segmentu wycofania) zabezpieczanej bazy danych powinny zostać zarejestrowane w katalogu
odtwarzania. Proces rejestrowania zmian w tym katalogu nosi nazwę synchronizacji
(ang. resynchronization) i jest on inicjowany przez administratora bazy danych za pomocą
polecenia resync catalog. Jeżeli sesja jest dołączona do katalogu
odtwarzania, wówczas katalog ten jest synchronizowany automatycznie w dwóch przypadkach:
przed rozpoczęciem procesu archiwizowania i po zakończeniu procesu odtwarzania.
Podczas uaktualniania katalogu odtwarzania, odpowiednie informacje są przepisywane z
pliku kontrolnego bazy zabezpieczanej. RMAN tworzy tymczasową kopię pliku
kontrolnego (ang. snapshot control file) przed każdorazowym uaktualnieniem katalogu
odtwarzania.
RMAN może pracować również bez katalogu odtwarzania. Jednak w tym przypadku
niemożliwe jest:

  • stosowanie skryptów składowanych (ang. stored scripts);
  • odtwarzanie zniszczonego pliku kontrolnego (jedyną metodą jest utworzenie nowego pliku
    kontrolnego za pomocą polecenia create controlfile);
  • dtwarzanie wybranej przestrzeni tabel do punktu w czasie.

Jeżeli w systemie nie zainstalowano katalogu odtwarzania, wówczas RMAN
korzysta z plików kontrolnych zabezpieczanej bazy danych w celu uzyskania informacji
dotyczących archiwizowania i odtwarzania.
Kopie archiwalne mogą być składowane na dyskach lub taśmach magnetycznych. W przypadku
drugim jest jednak niezbędne zainstalowanie oprogramowania Media Manager
umożliwiającego zarządzanie takimi nośnikami z poziomu RMANa.

rys. 1

Rys. 1. Architektura systemu wykorzystującego Recovery Manager

3. Praca z Recovery Managerem

3.1. Instalowanie katalogu odtwarzania
Oracle zaleca, aby właścicielem katalogu odtwarzania był dedykowany do tego celu
użytkownik, posiadający swoje obiekty  w odrębnej przestrzeni tabel lub
przestrzeni SYSTEM. W celu zainstalowania katalogu odtwarzania w wydzielonej przestrzeni
tabel należy:

  1. Utworzyć przestrzeń tabel dla katalogu odtwarzania:
    create tablespace rec_ratalog
    datafile ‚c:/lab80/data/rec_catalog.dbf’ size 10M
    autoextend on next 10M maxsize 50M;
  2. Utworzyć użytkownika – właściciela katalogu odtwarzania:
    create user rman identified by recman
    default tablespace rec_catalog
    temporary tablespace temp
    quota unlimited on rec_catalog;
  3. Przyznać rolę recovery_catalog_owner użytkownikowi rman.
    grant recovery_catalog_owner to rman;
  4. W schemacie użytkownika rman zainstalować katalog odtwarzania uruchamiając
    skrypt catrman.sql:
    connect rman/recman
    @$ORACLE_HOME/rdbms/admin/catrman.sql

Uwaga: w systemie Windows NT skrypt catrman.sql znajduje się w
katalogu: %ORACLE_HOME%rdbms80admin

3.2. Wywołanie Recovery Managera

Komunikacja z RMANem odbywa się za pomocą specjalnego języka poleceń. Polecenia
mogą być wydawane na trzy sposoby:

  • sposób interaktywny (podobnie, jak w środowisku SQL, czy Server Manager);
  • zapisywane w plikach tekstowych, tzw. skryptach, a następnie uruchamiane w środowisku RMANa
    w trybie wsadowym;
  • składowane w katalogu odtwarzania w postaci tzw. skryptów składowanych (ang. stored
    scripts), a następnie wywoływane za pomocą polecenia execute script.

Wywołanie programu Recovery Manager jest różne w różnych
systemach operacyjnych, np. w Sun Solaris program ten wywołuje się poleceniem rman,
a w Windows NT – za pomocą rman80.

3.2.1. Praca z katalogiem odtwarzania

Jak wspomniano wcześniej, Recovery Manager może pracować z wykorzystaniem
katalogu odtwarzania lub bez niego. W celu wykorzystania tego katalogu należy w poleceniu
rman wskazać katalog odtwarzania w następujący sposób:

rman target internal/hasło@BD1 rcvcat rman/recman@BD2

gdzie:
target jest parametrem wskazującym docelową (zabezpieczaną) bazę danych;
BD1 jest nazwą zabezpieczanej bazy danych, określoną w pliku konfiguracyjnym tnsnames.ora
(oprogramowania SQL*Net);
rcvcat jest parametrem wskazującym bazę danych, w której zainstalowano
katalog odtwarzania;
BD2 jest nazwą bazy danych zawierającą katalog odtwarzania (nazwa ta jest
określona w pliku tnsnames.ora).
Dodatkowo, w poleceniu rman można umieścić dwa parametry: cmdfile i msglog.
Pierwszy z nich umożliwia wskazanie pliku zawierającego polecenia RMANa, a drugi
umożliwia wskazanie pliku śladu rejestrującego wszystkie informacje pojawiające się
na ekranie.
Przykładowo, poniższe polecenie wywołuje program Recovery Manager (w systemie
Windows NT) realizując dołączenie do zabezpieczanej bazy danych LAB, jako internal
z hasłem zebra, a do katalogu odtwarzania w bazie CAT – jako użytkownik rman
z hasłem recman. Dodatkowo, w trybie wsadowym jest uruchamiany plik poleceń dbincr0.rmn,
a wyniki jego działania są zapisywane w pliku śladu rmanlog.log.

rman80 target internal/zebra@LAB rcvcat rman/recman@CAT
cmdfile dbincr0.rmn msglog rmanlog.log

W powyższym przykładzie, do zabezpieczanej bazy danych dołączono się jako internal.
Możliwe jest również dołączenie się do tej bazy danych jako inny użytkownik
posiadający przywilej SYSDBA. W takim przypadku parametr konfiguracyjny REMOTE_LOGIN_PASSWORDFILE
zabezpieczanej bazy danych musi przyjąć wartość EXCLUSIVE i musi również
istnieć plik haseł zabezpieczanej bazy danych przechowujący hasła użytkowników z
przywilejami SYSDBA i SYSOPER.

3.2.2. Praca bez katalogu odtwarzania

Jeżeli dostęp do katalogu odtwarzania nie jest wymagany, to RMANa należy
wywołać w sposób następujący:

rman80 target internal/zebra@LAB80 nocatalog
Recovery Manager: Release 8.0.5.0.0 – Production
RMAN-06009: using target database controlfile instead of recovery catalog
RMAN-06005: connected to target database: LAB

3.3. Polecenie run

Polecenie to umożliwia wykonywanie poleceń RMANa, składowanych skryptów RMANa,
poleceń systemu operacyjnego, poleceń SQL, procedur i funkcji składowanych.
Polecenie systemu operacyjnego wywołuje się w następujący sposób: run { host
"polecenie"; }
Polecenie SQL wywołuje się w następujący sposób: run { sql "polecenie";
}
Uwaga: można stosować znaki cudzysłowu lub apostrofu.
Składowany skrypt wywołuje się w następujący sposób: run { execute script
nazwa_skryptu; }
Polecenie @ umożliwia uruchomienie skryptu zapisanego w pliku tekstowym.
Przykładowo, poniższe polecenie uruchamia skrypt poleceń RMANa zapisany w pliku s_arch_log.rmn.

RMAN> @d:dysk4skryptys_arch_log.rmn

3.4. Rejestrowanie zabezpieczanej bazy danych

Po dołączeniu się do katalogu odtwarzania i zabezpieczanej bazy danych należy bazę
tę zarejestrować w katalogu odtwarzania. Służy do tego celu polecenie:

rman> register database;
RMAN-03022: compiling command: register
RMAN-03023: executing command: register
RMAN-08006: database registered in recovery catalog
RMAN-03023: executing command: full resync
RMAN-08029: snapshot controlfile name set to default value:
%ORACLE_HOME%DATABASESNCF%ORACLE_SID%.ORA
RMAN-08002: starting full resync of recovery catalog
RMAN-08004: full resync complete

Informacje o wszystkich bazach danych zarejestrowanych w katalogu odtwarzania są
dostępne za pomocą perspektywy katalogu odtwarzania RC_DATABASE, np.:

SQL> select * from rc_database; DB_KEY DBINC_KEY DBID NAME RESETLOGS_CHANGE# RESETLOGS
—- —- —- —- ——– —
1 2 822167203 LAB 1 24-AUG-99

4. Rodzaje kopii bezpieczeństwa
Recovery Manager umożliwia sporządzanie kopii bezpieczeństwa dwojakiego rodzaju:
tzw. zbiorów archiwalnych i tzw. kopii plików. Oba rodzaje kopii są sporządzane przez
proces usługowy Oracle.

4.1. Zbiory archiwalne
Zbiory archiwalne (ang. backup sets) mogą zawierać:

  • jeden lub więcej plików danych i plik kontrolny – są to tzw. zbiory archiwalne
    plików danych
    (ang. datafile backup sets);
  • jeden lub więcej zarchiwizowanych plików dziennika powtórzeń – są to tzw. zbiory
    archiwalne zarchiwizowanych plików dziennika powtórzeń
    (ang. archivelog backup
    sets).

Zbiory archiwalne posiadają następujące własności:

  • są zapisywane w specjalnym formacie, a odtworzone mogą zostać wyłącznie z poziomu RMANa;
    odtworzenie musi być         poprzedzone
    operacją odzyskania (ang. restore) pliku ze zbioru archiwalnego;
  • mogą być składowane na dysku lub innych nośnikach;
  • mogą zawierać pełne (ang. full) lub inkrementalne (ang. incremental) kopie
    archiwalne;
  • zawierają tylko te bloki danych które kiedykolwiek zostały zapisane;
  • mogą być zapisane w jednym lub wielu plikach, z których każdy stanowi tzw. część
    zbioru archiwalnego
    (ang. backup piece).

Administrator bazy danych może określić maksymalny rozmiar części
zbioru archiwalnego (por. punkt 5.1). Domyślnie cały zbiór archiwalny jest zapisywany w
jednym pliku, tj. jednej części archiwalnej.
Zależności między plikami bazy danych, zbiorami archiwalnymi i częściami zbiorów
archiwalnych przedstawia rysunek 2. Pliki danych umieszczone na różnych dyskach mają
rozmiary 1MB, 2MB, 10MB i 5MB. Maksymalny rozmiar części archiwalnej został ustalony na
10MB, stąd zbiór archiwalny fizycznie został składowany w dwóch plikach o rozmiarach
odpowiednio 10MB i 8MB.

rys. 2

Rys. 2. Zależności między plikami bazy danych, zbiorami archiwalnymi i częściami
zbioru archiwalnego

Plik kontrolny w zbiorze archiwalnym można umieścić na dwa sposoby:

  • specyfikując klauzulę include control file w poleceniu tworzącym zbiór
    archiwalny (por. punkt 7.3, części drugiej artykułu);
  • archiwizując plik danych o numerze 1, tj. plik przestrzeni tabel SYSTEM
    wówczas plik kontrolny zostanie automatycznie włączony do zestawu.

Proces usługowy Oracle w czasie kopiowania i archiwizowania
bloków danych wykrywa uszkodzone bloki danych, a informacje o nich zapisuje w pliku
kontrolnym, pliku alertu i katalogu odtwarzania. Po wykryciu, uszkodzone bloki danych
trafiają do kopii bezpieczeństwa. Administrator bazy danych może uzyskać informacje na
temat uszkodzonych bloków za pomocą dynamicznych tabel systemowych: V$BACKUP_CORRUPTION
(dla zbiorów archiwalnych) i V$COPY_CORRUPTION (dla kopii plików), np.:

select * from V$BACKUP_CORRUPTION where file# in (1, 2, 3);

4.1.1. Pełny zbiór archiwalny
Pełny zbiór archiwalny (ang. full backup set) zawiera pełną kopię
bezpieczeństwa plików danych, tj. wszystkie bloki wyspecyfikowanych plików danych, z
wyjątkiem bloków, które nie zostały nigdy zapisane. Pełny zbiór archiwalny może
być sporządzony dla: wybranych plików danych, wybranych przestrzeni tabel, lub całej
bazy danych.

4.1.2. Inkrementalny zbiór archiwalny
Inkrementalny zbiór archiwalny (ang. incremental backup set) może być
sporządzony na różnych poziomach (ang. levels) zarówno dla wybranych plików danych,
wybranych przestrzeni tabel, jak i całej bazy danych. Każdy z poziomów jest oznaczany
liczbą całkowitą.
Inkrementalny zbiór archiwalny wybranego poziomu (większego od 0) zawiera tylko te
bloki, które zostały zmodyfikowane od czasu sporządzenia ostatniego inkrementalnego
zbioru na tym samym poziomie lub niższym. Natomiast zbiór archiwalny poziomu 0
zawiera wszystkie bloki, w których kiedykolwiek zostały zapisane dane. Inkrementalne
zbiory archiwalne posiadają mniejsze rozmiary i czas ich sporządzania jest krótszy niż
w przypadku zbiorów pełnych.
Inkrementalne zbiory archiwalne poziomu 0 należy sporządzać po każdorazowym dodaniu do
bazy danych pliku danych lub przestrzeni tabel.
Przykładowy scenariusz sporządzania zbioru archiwalnego z wykorzystaniem metody
inkrementalnej przedstawiono na rysunku 3. W dniu pierwszym (d1) sporządzono
inkrementalny zbiór archiwalny poziomu zerowego, do którego zapisano wszystkie te bloki
danych, które były kiedykolwiek wykorzystywane (bloki oznaczono cyframi 1 do 10).

rys. 3

Rys. 3. Przykładowy scenariusz sporządzania inkrementalnych zbiorów archiwalnych na
różnych poziomach

W dniu drugim (d2) zmianie uległa zawartość bloków o
numerach 1 i 2. Sporządzony pod koniec dnia zbiór archiwalny poziomu trzeciego zawiera
bloki zmienione od czasu sporządzenia ostatniego zbioru tego samego poziomu (tj.
trzeciego) lub niższego. Ostatnim zbiorem spełniającym ten warunek jest więc zbiór
poziomu 0. Oznacza to, że bieżący zbiór poziomu 3 zawiera bloki 1 i 2.
W dniu trzecim (d3) zmianie uległa zawartość bloku 3 i 4. Pod koniec tego
dnia sporządzono zbiór poziomu trzeciego, który zawiera bloki zmienione od czasu
sporządzenia ostatniego zbioru tego samego poziomu (tj. trzeciego) lub niższego.
Ostatnim zbiorem spełniającym ten warunek jest więc zbiór poziomu 3, utworzony w dniu
d2. Oznacza to, że bieżący zbiór poziomu 3 zawiera bloki 3 i 4.
W dniu czwartym (d4) zmianie uległa zawartość bloku 5. Utworzony pod koniec
dnia zbiór archiwalny poziomu drugiego zawiera bloki zmienione od czasu sporządzenia
ostatniego zbioru tego samego poziomu (tj. drugiego) lub niższego. Ostatnim zbiorem
spełniającym ten warunek jest zbiór poziomu 0. Oznacza to, że bieżący zbiór poziomu
2 zawiera bloki 1, 2, 3, 4 i 5.
W dniu piątym (d5) zmianie uległa zawartość bloków 6 i 7. Sporządzony pod
koniec dnia zbiór poziomu pierwszego zawiera bloki zmienione od czasu sporządzenia
ostatniego zbioru tego samego poziomu (tj. pierwszego) lub niższego. Ostatnim zbiorem
spełniającym ten warunek jest zbiór poziomu 0. Oznacza to, że bieżący zbiór poziomu
1 zawiera bloki 1, 2, 3, 4, 5, 6 i 7.
W dniu szóstym (d6) zmianie uległa zawartość bloku 8. Sporządzony pod
koniec dnia zbiór poziomu drugiego zawiera bloki zmienione od czasu utworzenia ostatniego
zbioru tego samego poziomu (tj. drugiego) lub niższego. Ostatnim zbiorem archiwalnym
spełniającym ten warunek jest zbiór poziomu 1, sporządzony w dniu d5.
Oznacza to, że bieżący zbiór poziomu 2 zawiera blok 8.
W dniu siódmym (d7) zmianie uległa zawartość bloku 9. Sporządzony pod
koniec dnia zbiór poziomu drugiego zawiera bloki zmienione od czasu sporządzenia
ostatniego zbioru tego samego poziomu (tj. drugiego) lub niższego. Ostatnim zbiorem
spełniającym ten warunek jest zbiór poziomu 2, utworzony w dniu d6. Oznacza
to, że bieżący zbiór poziomu 2 zawiera blok 9.
Jeżeli w dniu d8 baza danych ulegnie uszkodzeniu, wówczas do odtworzenia do
momentu bezpośrednio poprzedzającego awarię będą niezbędne następujące zbiory
archiwalne: poziomu 0 z dnia d1, poziomu 1 z dnia d5, poziomu 2 z
dnia d6 i poziomu 2 z dnia d7.

4.1.3. Inkrementalny-kumulacyjny zbiór archiwalny
Zbiory inkrementalne mogą być sporządzane również jako tzw. kumulacyjne (ang.
cumulative) na poziomie pierwszym i wyższych, są to tzw. inkrementalne-kumulacyjne
zbiory archiwalne
. Inkrementalny-kumulacyjny zbiór danego poziomu zawiera te bloki
danych, które zostały zmienione od czasu sporządzenia ostatniego zbioru inkrementalnego
na poziomie niższym. Domyślnie, zbiory inkrementalne nie są sporządzane jako
kumulacyjne.
Przykładowy scenariusz sporządzania kopii archiwalnej z wykorzystaniem metody
inkrementalnej-kumulacyjnej przedstawiono na rysunku 4. W dniu pierwszym (d1)
sporządzono inkrementalny zbiór archiwalny poziomu zerowego, do którego zapisano
wszystkie te bloki danych, które były kiedykolwiek wykorzystywane.

rys. 4

Rys. 4. Przykładowy scenariusz sporządzania inkrementalnych-kumulacyjnych zbiorów
archiwalnych na różnych poziomach

W dniu drugim (d2) zmianie uległa zawartość bloków o
numerach 1 i 2. Sporządzony pod koniec tego dnia zbiór kumulacyjny poziomu trzeciego
zawiera bloki zmienione od czasu sporządzenia ostatniego zbioru tego samego poziomu minus
1 (tj. drugiego) lub niższego. Ostatnim zbiorem spełniającym ten warunek jest więc
zbiór poziomu 0. Oznacza to, że bieżący zbiór inkrementalny-kumulacyjny poziomu 3
zawiera bloki 1 i 2.
W dniu trzecim (d3) zmianie uległa zawartość bloku 3 i 4. Pod koniec tego
dnia sporządzono zbiór kumulacyjny poziomu 3, który zawiera bloki zmienione od czasu
sporządzenia ostatniego zbioru tego samego poziomu minus 1 (tj. drugiego) lub niższego.
Ostatnim zbiorem spełniającym ten warunek jest więc zbiór poziomu 0. Oznacza to, że
bieżący zbiór inkrementalny-kumulacyjny poziomu 3 zawiera bloki 1, 2, 3 i 4.
W dniu czwartym (d4) zmianie uległa zawartość bloku 5. Sporządzony pod
koniec dnia zbiór kumulacyjny poziomu drugiego zawiera bloki zmienione od czasu
sporządzenia ostatniego zbioru tego samego poziomu minus 1 (tj. pierwszego) lub
niższego. Ostatnim zbiorem spełniającym ten warunek jest zbiór poziomu 0. Oznacza to,
że bieżący zbiór inkrementalny-kumulacyjny poziomu 2 zawiera bloki 1, 2, 3, 4 i 5.
W dniu piątym (d5) zmianie uległa zawartość bloków 6 i 7. Sporządzony pod
koniec dnia zbiór kumulacyjny poziomu pierwszego zawiera bloki zmienione od czasu
sporządzenia ostatniego zbioru tego samego poziomu minus 1 (tj. zerowego) lub niższego.
Ostatnim zbiorem spełniającym ten warunek jest zbiór poziomu 0. Oznacza to, że
bieżący zbiór inkrementalny-kumulacyjny poziomu 1 zawiera bloki 1, 2, 3, 4, 5, 6 i 7.
W dniu szóstym (d6) zmianie uległa zawartość bloku 8. Utworzony pod koniec
dnia zbiór kumulacyjny poziomu drugiego zawiera bloki zmienione od czasu sporządzenia
ostatniego zbioru tego samego poziomu minus 1 (tj. pierwszego) lub niższego. Ostatnim
zbiorem spełniającym ten warunek jest zbiór kumulacyjny poziomu 1, utworzony w dniu d5.
Oznacza to, że bieżący zbiór inkrementalny-kumulacyjny poziomu 2 zawiera blok 8.
W dniu siódmym (d7) zmianie uległa zawartość bloku 9. Sporządzony pod
koniec dnia zbiór kumulacyjny poziomu drugiego zawiera bloki zmienione od czasu
sporządzenia ostatniego zbioru tego samego poziomu minus 1 (tj. pierwszego) lub
niższego. Ostatnim zbiorem spełniającym ten warunek jest zbiór poziomu 1, utworzony w
dniu d5. Oznacza to, że bieżący zbiór inkrementalny-kumulacyjny poziomu 2
zawiera bloki 8 i 9.
Jeżeli w dniu d8 baza danych ulegnie uszkodzeniu, wówczas do odtworzenia do
momentu bezpośrednio poprzedzającego awarię będą niezbędne następujące zbiory
archiwalne: poziomu 0
z dnia d1, poziomu 1 z dnia d5 i poziomu 2 z dnia d7.

4.2. Kopie plików
Kopia pliku (ang. image copy) posiada następujące własności:

  • składa się z pojedynczego pliku danych lub kontrolnego lub zarchiwizowanego pliku
    dziennika powtórzeń;
  • może być składowana wyłącznie na dysku;
  • jest wykonywana przez proces usługowy Oracle, który  w czasie
    sporządzania kopii pliku sprawdza, czy bloki danych nie są uszkodzone, a po zakończeniu
    kopiowania informacja o utworzonej kopii jest zapisywana w pliku kontrolnym i katalogu
    odtwarzania (jeśli jest sesja RMANa korzysta z niego);
  • kopia pliku sporządzona za pomocą RMANa jest spójna (tj. zawiera dane z
    jednego momentu czasowego), nawet, jeżeli inni użytkownicy w czasie kopiowania
    modyfikują dane znajdujące się w kopiowanym pliku;
  • do kopii plików trafiają wszystkie bloki, również te, które nie zostały jeszcze
    nigdy zapisane;
  • w przypadku awarii pliku bazy danych, jego kopia może być natychmiast wykorzystana do
    odtwarzania; wykorzystuje się wówczas polecenie switch (por. punkt 11.2.5,
    części trzeciej artykułu) będące odpowiednikiem polecenia alter database rename
    datafile
    .

5. Mechanizmy Recovery Managera

5.1. Kanał
Wszystkie operacje wymagające dostępu do plików wymagają uprzedniego przydzielenia
tzw. kanału (ang. channel). Oznacza to, że przed rozpoczęciem zarówno
archiwizowania danych, odzyskiwania jak i odtwarzania należy przydzielić kanał.
Operacja przydziału kanału powoduje zainicjowanie połączenia między RMANem, a
zabezpieczaną bazą danych i utworzenie procesu usługowego Oracle dla
zabezpieczanej bazy danych. Dla jednej operacji archiwizowania, odzyskiwania lub
odtwarzania można przydzielić n kanałów. Wówczas możliwe jest zrównoleglenie
tej operacji w stopniu n.

5.1.1. Przydzielenie kanału

Przydzielenie kanału jest realizowane poleceniem allocate channel o
następującej składni:

allocate channel id_kanału type disk|’nazwa_urządzena_IO’
[parms <ciąg parametrów>]
[connect <użytkownik/hasło@baza_danych>]
[format <format_nazw_plików’];

type określa rodzaj nośnika wykorzystywanego do składowania zbioru
archiwalnego; słowo kluczowe disk umożliwia zapisanie zbioru na dysku,
natomiast ujęta w apostrofy nazwa urządzenia umożliwia zapisanie zbioru na nośniku o
dostępie sekwencyjnym, np. taśmie magnetycznej;
dostęp do nośnika magnetycznego z poziomu RMANa jest możliwy dopiero po
zainstalowaniu oprogramowania zarządzającego tym nośnikiem. Standardowo, Oracle
dostarcza oprogramowanie Legato Storage Manager (LSM) zarządzające nośnikiem
oraz jedno predefiniowane wyjście o dostępie sekwencyjnym
o nazwie "SBT_TAPE";
parms umożliwia określenie parametrów dla urządzenia innego niż dysk;
connect umożliwia wskazanie bazy danych, dla operacji archiwizowania lub
odtwarzania, np.: connect "internal/zebra@LAB"
parametr stosowany tylko dla Oracle Parallel Server;
format określa format nazw plików części archiwalnych w przypadku, gdy
nie wyspecyfikowano takiego formatu w poleceniu backup (por. punkt 7.1,
części drugiej artykułu).
Jeżeli zbiory archiwalne lub ich części będą usuwane z dysku, wówczas należy
przydzielić kanał za pomocą poniższego polecenia:
allocate channel for delete type disk|’nazwa_urządzena_IO’;

5.1.2. Parametry kanału
Każdy kanał jest opisany zbiorem parametrów, które określa się poleceniem set
limit channel
. Przykładowo, dla wybranego kanału można jawnie określić:

  • maksymalną przepustowość kanału, wydając polecenie:
    set limit channel id_kanału read rate = liczba_buforów;
    gdzie liczba_buforów określa maksymalną liczbę buforów odczytywanych w
    czasie jednej sekundy; natomiast rozmiar bufora jest iloczynem wartości parametrów
    konfiguracyjnych DB_BLOCK_SIZE i DB_FILE_DIRECT_IO_COUNT (pliku init.ora);
  • maksymalną liczbę jednocześnie otwartych plików przez kanał, wydając polecenie:
    set limit channel id_kanału maxopenfiles = liczba_plików;
  • maksymalny rozmiar pliku części zbioru archiwalnego zapisywanego przez kanał,
    wydając polecenie:
    set limit channel id_kanału kbytes = rozmiar;

Przykładowo, pierwsze z poniższych poleceń przydziela kanał o
nazwie k1 umożliwiający składowanie plików archiwalnych na dysku, drugie
ogranicza maksymalną liczbę plików otwartych przez ten kanał do 10, a trzecie
ogranicza rozmiar pojedynczego pliku części zbioru archiwalnego do 10MB.

allocate channel k1 type disk;
set limit channel k1 maxopenfiles = 10;
set limit channel k1 kbytes 10000;

Jeżeli do zbioru archiwalnego jest zapisywany plik przestrzeni tabel rozmiarze 25MB,
wypełnionej całkowicie, wówczas, przy powyższych ustawieniach limitów kanału,
zostaną utworzone trzy części zbioru archiwalnego, odpowiednio o rozmiarach 10MB, 10MB
i 5MB.
Po zakończeniu zbioru poleceń RMANa wszystkie przydzielone kanały są zwalniane
automatycznie. Kanał można również zwolnić jawnie stosując polecenie: release
channel
id_kanału;

5.2. Skrypty składowane
Skrypty składowane mogą być wykorzystywane do okresowego, automatycznego wykonywania
pewnych prac administratorskich, np. archiwizowania bazy danych w czasie, kiedy jest ona
najmniej obciążona. Polecenia takie są wówczas zapisywane
w pojedynczym skrypcie, składowanym w katalogu odtwarzania.
Zarządzanie skryptami realizuje się za pomocą czterech następujących poleceń:

  • create script – tworzącego skrypt,
  • replace script – zastępującego istniejący skrypt nowym,
  • delete script nazwa – usuwającego wskazany nazwą skrypt,
  • print script nazwa – drukującego wskazany nazwą skrypt na ekranie i do
    pliku śladu RMANa, jeśli wskazano ten
    plik parametrem msglog (por.
    punkt 3.2.1).

Przykładowo, pierwsze polecenie zastępuje skrypt składowany o nazwie
alloc_channel_1. Skrypt ten alokuje kanał o nazwie k1, ograniczający
maksymalny rozmiar pliku do 10MB (por. punkt 5.1). Drugie polecenie tworzy skrypt o nazwie
backup_archlog_all, zapisujący w zbiorze archiwalnym wszystkie zarchiwizowane
pliki dziennika powtórzeń (por. punkt 7.6, części drugiej artykułu). W ciele tego
skryptu zastosowano wywołanie utworzonego wcześniej skryptu alloc_channel_k1
(polecenie execute script).

replace script alloc_channel_k1
{
   allocate channel k1 type disk;
   set limit channel k1 kbytes=10000;
}
create script backup_archlog_all
{
   execute script alloc_channel_k1;
   backup
   filesperset 20
   format <d:dysk4archiwumlogiarch_%s_%p_%t>
   (archivelog all
   delete input
);
  release channel k1;
}
Składowany skrypt uruchamia się wydając polecenie: run { execute script
nazwa_skryptu; }
Informacje o składowanych skryptach są dostępne za pomocą perspektyw katalogu
odtwarzania: RC_STORED_SCRIPT i RC_STORED_SCRIPT_LINE. Pierwsza z nich
udostępnia m.in.: nazwę bazy danych, dla której został utworzony skrypt, jej unikalny
identyfikator nadawany przez RMANa w momencie zarejestrowania bazy w katalogu
odtwarzania (por. punkt 3.4) i nazwę skryptu składowanego. Druga perspektywa udostępnia
natomiast ciała skryptów. Poniżej przedstawiono przykładowe polecenie wyświetlające
nazwy baz danych, nazwy skryptów i ich ciała.

SQL> column script_name format a20
SQL> column line format 999
SQL> column text format a50 word wrap
SQL> set pagesize 1000
SQL> set linesize 100
SQL> break on script_name
SQL> select db_name, ssl.script_name, line, text
2 from rc_stored_script ss, rc_stored_script_line ssl
3 where ss.db_key=ssl.db_key
4 and ss.script_name=ssl.script_name
5 order by db_name, script_name, line;

Część druga artykułu (dotycząca technik archiwizowania) i trzecia (dotycząca technik
odtwarzania bazy danych) zostaną zamieszczone w kolejnych numerach PLOUG’tek.

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