poniedziałek, 2 lipca 2012

RMAN - Kopie zapasowe w Oracle. Backup i odtwarzanie



Podstawowe informacje i wstępna konfiguracja


Backupy możemy wykonywać na dwa sposoby:
- wyłączając bazę i kopiując fizyczne pliki (tzw. zimny backup)
- wykorzystując RMANa i zrobić backup bez wyłączania bazy (hot backup)


Aby wykonać hot backup należy ustawić bazę w tryb ARCHIVELOG. Po tym zabiegu pliki
dzienników powtórzeń przed nadpisaniem zostaną zarchiwizowane. Dzięki temu mamy pewność że
nie zostaną wyczyszczone w trakcie backupu. Wykonujemy to w następujący sposób:

- Logujemy się SQL*Plusem jako SYS do bazy.
- Robimy SHUTDOWN IMMEDIATE; (tylko ten jeden raz jest to konieczne).
- Uruchamiamy bazę w trybie MOUNT (poleceniem STARTUP MOUNT).
- Wywołujemy polecenie ALTER DATABASE ARCHIVELOG;
- otwieramy bazę dla użytkowników poleceniem ALTER DATABASE OPEN;

Ten krok można pominąć ale ta konfiguracja pozwoli nam na wybór innego niż domyślne miejsce
składowania plików backupu. Oracle zawiera w sobie Flash Recovery Area. To przestrzeń
zawierająca backupy, służąca do ich przywracania. Jest ona zarządzana przez silnik bazy danych, a
nie system operacyjny. W niej właśnie będą składowane nasze backupy. Sprawdzamy aktualne
położenie FRA:

SELECT * FROM v$recovery_file_dest;






Jeśli chcemy zmienić dostępną dla FRA przestrzeń dyskową stosujemy komendę:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 100G;

Parametr ten ustawia ile miejsca na dysku mogą maksymalnie zajmować backupy oraz archivelogi.

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='c:\FRA';

Parametr ten ustawia gdzie na dysku mają znajdować się backupy.

Po ustaleniu w/w parametrów, warto sprawdzić, czy wszystko zostało przez nas poprawnie
ustawione. Wybieramy więc komendy:


SELECT * FROM v$parameter WHERE NAME='db_recovery_file_dest';



SELECT * FROM v$parameter WHERE NAME='db_recovery_file_dest_size';








Włączamy konsolę command line a następnie wpisujemy RMAN.


Podłączenie do bazy

Przede wszystkim po włączeniu RMANa, musimy podłączyć się do bazy danych. Robi się to
wpisując komendę:

CONNECT TARGET
lub
CONNECT TARGET /
lub
CONNECT TARGET nazwabazy



Pełny backup


W celu wykonania pełnego backupu bazy danych wywołujemy komendę:


BACKUP DATABASE;


Jako że to jest pełny backup, trwa on dosyć długo. Należy cierpliwie poczekać na pojawienie się
komunikatu RMANa. Nasz backup pojawi się w zdefiniowanym przez nas Flash Recovery Area.

Jeśli chcemy by nasz backup znalazł się w innym niż domyślne miejscu wpisujemy komendę:


BACKUP DATABASE FORMAT 'c:\rman\calabaza%u.bck';


Tag %u to unikalny numer generowany m.in. na podstawie daty i godziny utworzenia, dzięki
czemu każdy plik kopii zapasowej będzie miał unikalny numer.

Formatów tych jest kilka i można je wplatać w nazwę pliku. Przedstawiam te podstawowe:


%s – numer backupu
%d – nazwa bazy danych
%D – dzień
%M – miesiąc
%Y – rok
%u – wartość unikalna wyliczona na podstawie wszystkich w.w opcji


Taki backup obejmuje dane oraz plik kontrolny. Jeśli chcemy wykonać backup razem z plikami
zarchiwizowanymi dziennika powtórzeń, to wywołujemy komendę:


BACKUP DATABASE PLUS ARCHIVELOG;

Backup skompresowany


Pliki backupów zajmują sporo miejsca. Warto więc by były kompresowane. Jest możliwość
kompresowania przy użyciu RMANa. RMAN stosuje algorytm podobny do tego używanego przez
program archiwizujący ZIP.


Zamiast BACKUP DATABASE; wpisujemy:


BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT
'c:\FRA\full_compressed%u';


lub przykładowo z plikami (zarchiwizowanymi) dziennika powtórzeń:


BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG FORMAT
'c:\FRA\full_compressed%u';


Taką kompresję można stosować też przy backupach tablespace'ów oraz backupach przyrostowych
i kumulatywnych. Co prawda kopia zapasowa jeśli jest kompresowana wykonywana jest dużo
dłużej, ale zajmuje w efekcie mniej miejsca.

Backup przyrostowy i kumulatywny


Nie zawsze musimy chcieć wykonywać pełną kopię zapasową. Z resztą po co nam za każdym
razem całość jeśli można pełny backup zrobić raz, a później wykorzystywać zajmujące znacznie
mniej miejsca kopie przyrostowe.


Definicje:

Kopia pełna - czyli kopia wszystkich plików danych oraz pliku kontrolnego
Kopia przyrostowa - czyli kopia tylko tych bloków danych które uległy zmianie od ostatniego
pełnego lub przyrostowego backupu.
Kopia kumulatywna - kopia wszystkich bloków danych które uległy zmianie od ostatniego
pełnego (!!! już nie ostatniego przyrostowego) backupu.


Backup przyrostowy


Od wersji 10g Oracle obsługuje dwa poziomy kopii przyrostowej 0 i 1. Kopia przyrostowa poziomu
0 fizycznie nie różni się niczym od pełnego backupu, z tą różnicą że na jej podstawie możemy
wykonywać normalne kopie przyrostowe (poziom 1). Tak więc przynajmniej raz musimy wykonać
komendę:


BACKUP INCREMENTAL LEVEL 0 DATABASE FORMAT 'c:\FRA\przyrostowa_0_%u';


aby następnie móc wykonywać :


BACKUP INCREMENTAL LEVEL 1 DATABASE FORMAT 'c:\FRA\przyrostowa_1_%u';


Komenda z level 1, jest to już normalna kopia przyrostowa.


Backup kumulatywny


Aby wykonać backup kumulatywny wywołujemy komendę:


BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;


Warto dość często wykonywać kopie przyrostowe, a raz na jakiś czas (np. tydzień) kopię
kumulatywną. Dzięki temu będziemy mogli później pozbyć się kopii przyrostowych, a co za tym
idzie, mieć mniejszą ilość plików do przechowywania.


Ten tag możemy łączyć z innymi poznanymi wcześniej, np.:


BACKUP INCREMENTAL LEVEL 1 FORMAT 'c:\FRA\inc_comp%u' AS COMPRESSED
BACKUPSET DATABASE PLUS ARCHIVELOG;



Szybki backup przyrostowy


Normalnie backup przyrostowy realizowany jest tak, że ostatni backup z danymi porównywany jest
blok po bloku. Zamiast tego, można zrobić tak by Oracle tworzyło sobie listę zmienionych bloków.
W takim wypadku backup przebiegał będzie znacznie szybciej. Niestety ta opcja jest dostępna tylko
w wersjach Standard i Enterprise.

Najpierw sprawdźmy czy już ta opcja nie jest włączona:

SELECT * FROM v$parameter WHERE NAME='db_create_file_dest';

Jeśli pole value będziemy mieli puste, to znaczy że nie było to wcześniej ustawiane.
Tworzymy katalog w którym taka lista będzie przechowywana, a następnie wpisujemy:

ALTER SYSTEM SET db_create_file_dest='c:\FRA\fib';

oraz włączamy tą opcję:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;



Backup tablespace'ów


RMANem możemy wykonywać również backupy tablespace'ów, plików danych, pliku parametrów, pliku kontrolnego.

Najpierw sprawdźmy jakie mamy tablespace'y:

SELECT * FROM DBA_TABLESPACES;

Komenda do backupu wybranego tablespace'a:

BACKUP TABLESPACE USERS FORMAT 'c:\FRA\users%u';

Klauzula format jest oczywiście nieobowiązkowa. Możemy też chcieć zapisać kilka tablespace'ów,
wtedy rozdzielamy ich nazwy przecinkami:

BACKUP TABLESPACE USERS, SYSTEM FORMAT 'c:\FRA\users_system%u';

albo zechcieć je dodatkowo skompresować:

BACKUP AS COMPRESSED BACKUPSTE TABLESPACE USERS FORMAT
'c:\FRA\users_compressed%u';

lub zrobić nie dość że skompresowaną to jeszcze przyrostową (oszczędzamy miejsce - dyski kiedyś
się kończą).:

BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 FORMAT
'c:\FRA\users_comp_przyr%u' TABLESPACE USERS;


Backup pliku parametrów

Komenda (format jest opcjonalny):

BACKUP SPFILE FORMAT 'c:\FRA\spfile%u';


Backup pliku kontrolnego


Warto abyśmy wykonywali osobną kopię pliku kontrolnego. Dlaczego? Ponieważ informacje o
backupach przechowywane są właśnie w nim. Co prawda w pełnych backupach jest też kopia pliku
kontrolnego, ale nie będziemy w stanie przywrócić backupu, jeśli plik kontrolny ulegnie
uszkodzeniu. W takim przypadku dużo łatwiej odzyskać najpierw plik kontrolny a później resztę.
Aby wykonać taki backup wpisujemy:


BACKUP CURRENT CONTROLFILE FORMAT 'c:\FRA\controlfile%u';


Taką kopię pliku kontrolnego (zwłaszcza że nie zajmuje wiele miejsca) warto mieć jak najświeższą.
Dbanie o to by tak było możemy zlecić silnikowi bazy:


CONFIGURE CONTROLFILE AUTOBACKUP ON;


Od tej pory jeśli nastąpi jakakolwiek zmiana wpływająca na plik kontrolny, ten zostanie
automatycznie zbackupowany po zmianach. Możemy teraz chcieć by RMAN backupował nam plik
kontrolny w inne miejsce niż domyślne. Wywołujemy komendę:


CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'd:\FRA\plikkontrolny%u';

Kopia zapasowa plików zarchiwizowanych dziennika powtórzeń

SELECT * FROM v$datafile;


BACKUP AS COPY DATAFILE 'c:\app\administrator\oradata\orcl\users01.dbf' FORMAT
'c:\FRA\users.dbf';


Komenda ta kopiuje wszystkie bloki, zajęte oraz puste. Jeśli więc będziemy mięli określony
tablespace o wyznaczonej z góry sporej wielkości, backup zajmie niepotrzebnie bardzo dużo
miejsca.

Odtwarzanie przy użyciu RMAN

Aby rozpocząć przywracanie interesujących nas rzeczy z backupu, włączamy konsolę command
line a następnie wpisujemy RMAN.

Przede wszystkim po włączeniu RMANa, musimy podłączyć się do bazy danych (tak jak w
przypadku tworzenia plików backupu). Wpisujemy zatem komendę:

CONNECT TARGET
lub
CONNECT TARGET /
lub
CONNECT TARGET nazwabazy


Możemy przywrócić teraz to, co wcześniej zbackupowaliśmy (bazę, tablespace'y, plik kontrolny,
czy pliki zarchiwizowanych dzienników powtórzeń).


Przywracanie bazy z pełnego backupu
Zaczniemy od przywrócenia pełnej bazy z naszego backupu. Aby to zrobić musimy najpierw
wyłączyć bazę, a następnie włączyć ją w tryb mount (możemy to zrobić wprowadzając listę
komend):



RUN{
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN;
}




RMAN sam sprawdzi który backup jest tym ostatnim, bez względu na to, czy robiliśmy pełny
backup, inkrementalny, czy też kumulatywny. Również sam załaduje odpowiedni controlfile i
archivelogi.



Przywracanie bazy do określonego punktu w czasie

Możemy przywrócić bazę do określonego punktu w czasie, w tym celu wyłączamy, a następnie
uruchamiamy bazę do trybu mount:

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

Podajemy do którego momentu chcemy przywrócić bazę:

run{
set until time ”to_timestamp('12:00:00 01-09-2011','hh24-mi-ss dd-mm-yyyy')”;
restore database;
recover database;
}



Następnie uruchamiamy bazę, resetując archivelogi:


ALTER DATABASE OPEN RESETLOGS;


Walidacja bazy i backupów

W celu sprawdzenia poprawności plików bazy danych wywołujemy komendę:

BACKUP VALIDATE DATABASE;

możemy również wykonać walidacje dla bazy, wraz z archivelogami:

BACKUP VALIDATE DATABASE PLUS ARCHIVELOG;

Co ważne, podając tę komendę nie wykonujemy backupu!

Aby sprawdzić poprawność ostatnio wykonanego backupu wprowadzamy:

RESTORE DATABASE VALIDATE;

aby sprawdzić poprawność pliku backupu wraz z archivelogami:

RESTORE ARCHIVELOG ALL VALIDATE;




Zarządzanie backupami



Chcąc sprawdzić nasze backupy możemy je wylistować wpisując komendę:


LIST BACKUP;





Warto czasem sprawdzić, czy pliki do których odnosi się backup wciąż są obecne na dysku. Aby to
zrobić wywołujemy:


CROSSCHECK BACKUP;






Jeśli powyższe zapytanie wykaże nam błąd (różne od found to be 'AVALIABLE'), możemy wtedy usunąć niepotrzebne pliki backupu używając komendy:


DELETE EXPIRED BACKUP;


Możemy również wykasować nieaktualne, niepotrzebne już backupy np. przestarzałe:


DELETE OBSOLETE;

Aby ustawić politykę backupów, tzn. kiedy pliki backupów będą uważane przez RMANa za przestarzałe musimy zmodyfikować parametr RETENTION POLICY. Mamy możliwość ustawienia ilości backupów, które mają być uważane za aktualne, bądź czas, podawany w dniach.

Ustawienie dla ilości dni przez jakie backupy będą uważane za „ważne” ustawiamy poleceniem:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

Powyższym poleceniem ustawimy, iż RMAN będzie uważał za przestarzałe pliki backupów stworzone później niż 3 dni wstecz.

Ustawienie dla ilości przetrzymywanych backupów ustawiamy wywołując polecenie:

CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

Tym poleceniem ustawiamy, iż RMAN będzie uważał za aktualne 3 ostatnie pliki backupów.

Po wylistowaniu backupów (LIST BACKUP) zobaczymy jaki numer odpowiada konkretnemu
plikowi backupu. Znając ten numer, możemy usunąć konkretny backup posługując się właśnie tym
numerem:

DELETE BACKUPSET 69;


Przywracanie tablespaceów



Aby odtworzyć tablespace musimy odłączyć go od bazy przy pomocy komendy OFFLINE. W tym
wypadku również możemy posłużyć listą komend:

RUN{
SQL 'ALTER TABLESPACE USERS OFFLINE';
RESTORE TABLESPACE USER;
RECOVER TABLESPACE USERS;
SQL 'ALTER TABLESPACE USERS ONLINE';
}







Przywracamy tablespace systemowy


Tutaj również możemy posłużyć się listą komend. Jako, że jest to tablespace systemowy, jesteśmy
zmuszeni zamknąć bazę danych i wprowadzić ją w tryb MOUNT:


RUN{
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
RESTORE TABLESPACE SYSTEM, SYSAUX;
RECOVER TABLESPACE SYSTEM, SYSAUX;
ALTER DATABASE OPEN;
}



Przywracanie pliku kontrolnego

Plik kontrolny przywracamy dodając na końcu komend dodatek RESETLOGS:

RUN{
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM AUTOBACKUP ;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
}



















2 komentarze:

  1. Witam,

    Uprzejmie proszę o informacje w jaki sposób można zaimportować archivelogi do bazy po jej przywróceniu z pełnej kopii wykonanej przez RMAN.
    Zakładam sytuację w której cała baza ulegnie uszkodzeniu (awaria nosnika) o godzinie 22 a będę dysponował na dysku zewnetrznym założmy kopią RMANA z godziny 16 oraz dodatkowo plikami archivelog wykonanymi od tej godziny do czasu awarii.
    Kopia RMANA zostanie przywrocona przez co osiagne stan na godzine 16, jak zaimportowac archivelogi tak aby uzyskac stan bazy na godzine 22 czyli tuz przed awaria?

    Z gory dziekuje za wyjasnienie.

    OdpowiedzUsuń
  2. Dodam że baza zajmuje 400GB i jest to Oracle 9.2.0.8

    OdpowiedzUsuń