środa, 25 kwietnia 2012

RMAN - opcja CATALOG




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:


1 komentarz:

  1. 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ń