niedziela, 20 stycznia 2013

Gotuj z Oracle'm : Odtworzenie bazy w innym miejscu z backupu

Tutaj macie instrukcję jak w (prawie) bezbolesny sposób skopiować sobie bazę danych Oracle na inny serwer.  Warto zadbać o to, by zarówno serwer źródłowy  jak i docelowy miały tą samą wersję. Dzięki temu nie powinny się pojawić żadne zgrzyty.  Oczywiście baza źródłowa powinna mieć włączony tryb ARCHIVELOG.

Part I  - wykonanie kopii zapasowej i skopiowanie danych

W pierwszej kolejności najlepiej będzie wykonać sobie pełen skompresowany backup. Zanim jednak go wykonasz , zaloguj się do RMANa i wydaj tą komendę:

CONFIGURE CONTROLFILE AUTOBACKUP ON;

Sprawi ona, że po wykonaniu backupu (nie tylko wtedy) zostanie wykonany automatycznie backup pliku kontrolnego.

Po niej wykonaj skompresowany backup całej bazy danych (też z RMANa):

BACKUP AS COMPRESSED BACKUPSET DATABASE;

Wejdź teraz do swojego FRA. Jeśli nie wiesz gdzie się znajduje , to z poziomu sqlplusa wydaj polecenie:

SHOW PARAMETER DB_RECOVERY_FILE_DEST;

W katalogu który pokaże Ci się w wyniku działania powyższego polecenia znajdziesz podkatalog o nazwie takiej jak SID bazy danych którą kopiujesz. Wejdź w ten katalog. Powinieneś mieć w nim podkatalogi:
Backupset, Archivelog, Autobackup i Onlinelog. Skopiuj sobie cały katalog "autobackup" do FRA bazy docelowej. Tam również powinna być zachowana struktura katalogów: "SID_bazy/Autobackup" . Backup który przed momentem wykonałeś znajdziesz w katalogu backupset (w podkatalogu z dzisiejszą datą).   Skopiuj plik właśnie wykonanego backupu do dowolnego podkatalogu na dysku serwera docelowego.

Part II - Ustawianie ścieżek

Ponieważ położenie plików kontrolnych może być różne w bazie źródłowej i docelowej, a nawet system operacyjny może być inny, trzeba będzie poprzestawiać ścieżki.  W pierwszej kolejności z bazy docelowej wypluj sobie na dysk plik PFILE (z poziomu sqlplusa):

CREATE PFILE = ' C:\PFILE.TXT' FROM SPFILE;


Wyedytuj do i odnajdź parametr "control_files". Określa on gdzie system będzie szukał plików kontrolnych. W pierwszym etapie uruchomienia  (tj. przejściu do trybu NOMOUNT) system podpina sobie spfile lub pfile (plik z parametrami startowymi) , alokuje pamięć i czyta parametry. Parametr control_files będzie mu potrzebny do przejścia do trybu MOUNT , gdzie pliki kontrolne będą mu juz potrzebne.  Jeśli w bazie docelowej pliki kontrolne mają się znaleźć gdzie indziej , lub nie ma takiej struktury katalogów jak określona w parametrze - popraw go.
Odnajdź teraz w tym samym pliku parametr db_recovery_file_dest i popraw ścieżkę na tą obowiązującą w bazie docelowej. Tam właśnie system będzie szukał podkatalogu z sidem bazy, a w nim katalogu AUTOBACKUP, więc ważne jest byś jednak to zrobił....
Jeśli zależy Ci na zachowaniu parametrów startowych z bazy źródłowej, takich jak ustawienia SGA, możesz skopiować sobie plik pfile z bazy źródłowej i to na nim nanieść poprawki.

Part III - stawianie bazy

Na ten moment powinieneś mieć skopiowany katalog AUTOBACKUP i plik backupu z bazy źródłowej do docelowej, oraz poprawione parametry w pliku PFILE. Jeśli którejś z tych rzeczy nie masz, to znaczy że troszkę za bardzo się śpieszysz i powinieneś jeszcze raz przejrzeć wcześniejszą treść artykułu.
Zaloguj się do bazy docelowej i z poziomu sqplusa ją połóż:

SHUTDOWN IMMEDIATE;

Następnie podnieś ją do trybu nomount z użyciem pliku pfile zamiast spfile:

STARTUP PFILE='C:\PFILE.TXT' NOMOUNT;

Jesteś teraz w trybie nomount , ale pliki kontrolne oraz pliki danych w bazie docelowej pozostają stare. To jest właściwy tryb do podmiany pliku kontrolnego na ten pochodzący z bazy źródłowej, dlatego przechodzisz do RMANa i wydajesz polecenie takie:

RESTORE CONTROLFILE FROM AUTOBACKUP;

 Plik kontrolny jest już podmieniony na nowy, ale pliki danych są nadal stare. Trzeba teraz podmienić na te, z bazy źródłowej. Niezbędne będzie więc odtworzenie backupu (który już powinien znajdować się w FRA) bazy źródłowej. Do tego procesu potrzebna będzie informacja na temat tego gdzie pliki backupu się znajdują, a ta znajduje się w repozytorium które z kolei znajduje się w pliku kontrolnym który przecież nie jest podpięty do systemu (właśnie go podmieniliśmy). Dlatego właśnie powinieneś wydać komendę (możesz wykonać ją z RMANa):

ALTER DATABASE MOUNT;

Wszystkie kolejne polecenia wykonujemy już z RMANa. Ponieważ plik kontrolny pochodzi ze starej bazy, to i ścieżki do plików backupu będą stare. Trzeba więc zaprowadzić jakiś porządek aby system szukał backupów tam gdzie powinien. Wydaj więc komendy:

CROSSCHECK BACKUP;
DELETE EXPIRED BACKUP;

Dzięki tym komendom system sprawdzi czy położenie plików backupów wg. repozytorium pokrywa się z fizycznym położeniem plików. Jeśli tam ich nie znajdzie, to informacje o nich wywali z repozytorium. Właśnie o to nam chodzi. System ma szukać w nowym miejscu, czyli tam gdzie zrzuciliśmy plik backupu pochodzący z bazy źródłowej. Aby wiedział że ten backup się tam znajduje powinieneś wydać polecenie:

CATALOG START WITH 'C:\ŚCIEŻKA_DO_KATALOGU_GDZIE_WRZUCIŁEŚ_BACKUP';

 Na ten moment system już wie, gdzie znajduje się backup do odtworzenia , plik kontrolny już został podmieniony na pochodzący z bazy źródłowej. Pozostaje nam więc odtworzenie  bazy:

RESTORE DATABASE;

I otwarcie jej:

ALTER DATABASE OPEN RESETLOGS;

Koniec. Stan bazy docelowej będzie stanem bazy źródłowej z momentu wykonania backupu. Enjoy!

4 komentarze:

  1. Wszystko OK, ale zapomniałeś napisać, że aby Twoja procedura się powiodła, to na serwerze docelowym musi istnieć taka sama ścieżka do plików bazy danych jak na serwerze źródłowym. Innymi słowy nie da się odtworzyć bazy z np. takiej lokalizacji:
    /serwer1/oracle/data
    do lokalizacji
    /serwer2/oracle/data

    OdpowiedzUsuń
  2. Ten komentarz został usunięty przez autora.

    OdpowiedzUsuń
  3. Jeśli chcesz by pliki danych wylądowały w innym miejscu np. w innym katalogu niż było domyślnie, to musisz fragment z restorem przerobić na taki:

    run{
    set newname for database to 'sciezka_gdzie_maja_byc_pliki_danych\%U';
    restore database;
    }

    EDIT: sry, pomyliłem się w poprzednim komentarzu i musiałem skasowac.

    OdpowiedzUsuń
  4. moja źródłowa baza ma nazwę 'orcl' a nowa 'orcl2'. Niestety ten poradnik nie nadaje się do takiej mimo wszystko normalnej sytuacji..

    OdpowiedzUsuń