Co to jest CATALOG i jakie korzyści
przynosi?
Opcja catalog w
skrócie, polega na tym że repozytorium backupów poza plikiem
kontrolnym znajduje się również w specjalnym schemacie innej bazy
danych. Co nam to daje?
- Dane o backupach są przechowywane również poza plikiem kontrolnym , więc w przypadku jego utraty jesteśmy w stanie odtwarzać kopie zapasowe.
- Jesteśmy w stanie odtwarzać kopie zapasowe już w trybie NOMOUNT, co normalnie nie byłoby możliwe.
- Możemy posiadać gotowe użytkowe skrypty i współdzielić je między bazami danych.
W teorii jak stworzyć CATALOG?
- Musimy w innej bazie danych stworzyć użytkownika i nadać mu poza zwykle przyznawanymi rolami CONNECT, RESOURCE również rolę RECOVERY_CATALOG_OWNER.
- Stworzyć w schemacie tego użytkownika specjalną strukturę tabel do przechowywania danych o backupach i skryptach
- Zarejestrować bazę, tj dodać odpowiednie wpisy w stworzonym wyżej schemacie.
- Zsynchronizować repozytorium pliku kontrolnego i CATALOG (co dzieje się automatycznie przy rejestracji bazy).
W jednym raz stworzonym CATALOGu możemy
zarejestrować wiele baz.
A w praktyce?
Tworzenie użytkownika i nadawanie
mu odpowiednich uprawnień
W pierwszej kolejności , w bazie w
której ma się znaleźć CATALOG tworzymy użytkownika. Nadajemy mu
trzy role :
- connect
- resource
- recovery_catalog_owner
Tutaj sworzyłem użytkownika o nazwie
rman z hasłem rman. Oczywiście Twój użytkownik może nazywać się
inaczej.
Będziemy potrzebowali podłączyć się
do bazy w której znajduje się nasz CATALOG z poziomu RMANa więc
wszelkie dane połączeniowe musimy dodać do pliku tnsnames.ora by
nazwa bazy była rozpoznawana. Moja baza katalogowa będzie
rozpoznawana pod nazwą KATALOG.
Następnie musimy uruchomić RMANa i
podłączyć się do naszej bazy, oraz do schematu bazy w której
znajdować się będzie nasze dodatkowe repozytorium tj. do schematu
który przed chwilą stworzyliśmy. Zauważ że podczas połączenia
wskazujemy do której bazy łączymy się w jakim celu. Łącząc się
z użyciem słówka TARGET wskazujemy RMANowi że ta baza będzie
backupowana, odtwarzana, rejestrowana w CATALOGu lub duplifikowana. W
każdym razie jest to nasza podstawowa baza na której chcemy
wykonywać działania. Do bazy w której znajduje się nasze nowe
repozytorium łączymy się z użyciem klauzuli CATALOG. Dzięki temu
kiedy napiszemy „register database” RMAN będzie wiedział która
baza jest bazą dla której tworzymy katalog, a która spełnia rolę
repozytorium.
Po właściwym podłączeniu się do
obu baz, tworzymy wszystkie niezbędne tabele w których będą
przechowywane informacje o backupach. Robimy to klauzulą „CREATE
CATALOG”. RMAN wie w którym schemacie ma te tabele utworzyć na
podstawie informacji przekazanych mu podczas połączenia. Tabele
stworzy w schemacie do którego podłączamy się z użyciem klauzuli
CONNECT CATALOG. Takie tworzenie tabel w schemacie wykonujemy tylko
raz, niezależnie od tego jak wiele baz ma korzystać z tego
repozytorium. W raz utworzonym katalogu możemy zarejestrować wiele
baz.
Kolejną czynnością jest rejestracja
bazy w katalogu. Robimy to klauzulą REGISTER DATABASE. Rman doda do
tabel w schemacie katalogowym wpisy o bazie do której jesteśmy
podłączeni jako do bazy targetowej. Gdybyś zechciał zarejestrować
więcej baz, rozłącz się i podłącz do kolejnej bazy z użyciem
CONNECT TARGET oraz do bazy katalogowej. Nie będzie już konieczne
ponowne tworzenie struktur poleceniem „CREATE CATALOG” , jedynie
rejestrujemy kolejną bazę poleceniem „REGISTER DATABASE”.
Wujek Dobra Rada: Catalog z
technicznego punktu widzenia możesz utworzyć również w bazie dla
której tworzysz katalog. Z praktycznego punktu widzenia, jest to bez
sensu :) Pomyśl – gdyby nastąpiła jakaś awaria tej bazy i i tak
nie moglibyśmy jej podnieść, to do takiego katalogu byśmy się
nie podłączyli :) Żeby sworzyć sobie taki katalog nie
potrzebujesz żadnej komercyjnej licencji Oracle. Wystarczy Ci bazka
Express Edition postawiona na komputerze choćby z Pentium III :).
Przecież to tylko kilka tabel z wpisami znajdujących się w
schemacie do którego mamy się podłączać przez sieć. That's all!
Zauważ że podczas
rejestracji bazy w katalogu, następuje automatyczna synchronizacja
repozytorium. Oznacza to że informacje o wszystkich backupach są
kopiowane z Twojego pliku kontrolnego do schematu katalogowego.
Zawsze możesz je ponownie zsynchronizować gdy będzie to konieczne
(o tym dalej) poleceniem „resync catalog”.
Wykorzystajmy teraz
możliwości takiego katalogu.
Odtwarzanie bazy
w trybie nomount
W sytuacji gdybyśmy spotkali się z awarią bazy taką, że baza nie
podnosi się wyżej niż do trybu NOMOUNT, nie mamy dostępu do
informacji o backupach zawartych w pliku kontrolnym. Oczywiście
zawsze pozostaje nam autobackup pliku kontrolnego lub zduplifikowany
plik kontrolny (jeśli o to zadbaliśmy).
W tym przypadku
wykonuję otwarzanie bazy w trybie nomount. Oczywiście aby to się
udało, muszę być podłączony do bazy targetowej oraz katalogu.
Sam recover bazy
wykonać musimy już w trybie mount. Po zakończeniu odtwarzania
plików (restore) przechodzimy więc do trybu mount i wykonujemy
recover.
Synchronizacja
katalogu
Gdyby z różnych przyczyn (problemy z siecią, problemy sprzętowe
serwera z katalogiem etc) nie było możliwe podłączenie się do
bazy katalogowej przez jakiś czas, wszystkie czynności wykonujemy
podłączeni tylko do bazy targetowej. Informacje o backupach znajdą
się wtedy tylko w pliku kontrolnym.
Kiedy połączenie do katalogu znowu będzie możliwe, łączymy się
do bazy targetowej i do katalogu i synchronizujemy repozytoria
poleceniem „resync catalog”.
Po tej operacji nastąpi skopiowanie do katalogu informacji o
backupach które zostały wykonane bez połączenia z nim.
Wyrejestrowanie
bazy z katalogu
W każdej chwili możemy zrezygnować z opcji catalog i wyrejestrować
bazę. Aby to zrobić, łączymy się do bazy targetowej i do
katalogu, a następnie wykonujemy polecenie „unregister database”.
Kasowanie
katalogu
Katalog możemy również skasować wraz z repozytoriami wszystkich
baz w nim zarejestrowanych.
Skrypty
Posiadając katalog, możemy również stworzyć skrypty narzędziowe.
Bez katalogu możliwość przechowywania skryptów ograniczała się
do zapisywania ich w plikach. Mając katalog, możemy tworzyć
skrypty i przechowywać je w nim. Dzięki temu wszystkie skrypty
znajdują się w jednym miejscu i są dostępne z każdego miejsca z
którego jesteśmy w stanie podłączyć się do katalogu.
Skrypty mogą być globalne albo lokalne. Globalne są dostępne dla
wszystkich baz zarejestrowanych w katalogu, lokalne tylko dla jednej
bazy.
Generalnie skrypty tworzymy poleceniem create [ global ] script. Na
powyższej ilustracji stworzyłem skrypt do odtwarzania tablespace
uzyszkodnicy. Sekwencję komend które wpisywałbym pojedynczo lub w
bloku run , zamknąłem w skrypcie. Jest to skrypt lokalny.
Tylko w jednej bazie posiadam tablespace o takiej nazwie , dlatego
stworzyłem skrypt dostępny tylko dla tej bazy.
Poniżej tworzę skrypt uniwersalny do odtwarzania całej bazy. Nie
posiada on elementów różnych dla różnych baz, więc mogę go
wykorzystywać do odwarzania dowolnej bazy. Zauważ że doszła nam
klauzula GLOBAL. To sprawia, że skrypt będzie dostępny dla
wszystkich baz zarejestrowanych w katalogu.
Mogę też stworzyć skrypt w oparciu o plik:
Zawartość pliku zostanie przeczytana i zaposana pon nazwą
„przyrostowy”.
Aby uruchomić skrypt korzystam z komendy „execute”. Wywoływanie
skryptów zawsze musi być objęte blokiem „run”.
Przy uruchomieniu w ten sposób RMAN będzie szukał skryptu
lokalnego, choćby istniały dwa skrypty o takiej nazwie – lokalny
i globalny. Gdybyśmy chcieli wywołać skrypt globalny :
Zawartość skryptów możemy również wypisać na ekran przy użyciu
polecenia print. Jeśli mielibyśmy dwa skrypty o tej samej nazwie
(jeden globalny a drugi lokalny), a chcielibyśmy uruchomić ten
globalny posługujemy się dodatkowo klauzulą GLOBAL:
Możemy też skrypty wydrukować do pliku tekstowego:
Jeśli chcemy sprawdzić jakie mamy skrypty dostępne możemy
posłużyć się dwoma klauzulami:
list script names
lub
list global script names
W pierwszym wypadku wyświetlone zostaną nazwy wszystkich skryptów,
w drugim tylko globalnych.
Kasować skrypty możemy przy użyciu komendy delete script. Tak jak
do tej pory, gdybyśmy mieli dwa skrypty (lokalny i globalny ) o tej
samej nazwie, RMAN domyślnie skasuje lokalny. Możemy więc stosować
też klauzulę GLOBAL:
Skrypty możemy ulepszać i podmieniać w katalogu poleceniem
replace:
Super wpis ale mam pytanie czy tą metodą jest możliwość odtworzenia bazy na innym serwerze (serwer zapasowy)? chodzi mi dokładnie o to że z serwera zapasowego podłączam się do bazy katalogowej i chciałbym na nim odzyskać kopie. Jak uzyskać informacje o kopiach na nowym serwerze ponieważ baza z zapasowego serwera nie jest zarejestrowana w bazie katalogowej. Pozdrawiam
OdpowiedzUsuń