Szybciutkie odtwarzanie

Jadwiga Gnybek Jadwiga_Gnybek@nofer.lodz.pl

 

Nasze systemy informatyczne ciągle się dokądś spieszą. Spora ich część nominalnie działa już w trybie 24/7. Coraz krótsze stają się również okna serwisowe, czyli czas w jakim system może być niedostępny dla użytkowników. W takim właśnie oknie serwisowym najczęściej wykonujemy kopie zapasowe naszej bazy.

Mimo, że mechanizmy backupowania „w locie” są coraz doskonalsze, raz na jakiś czas musimy przecież wykonać na przykład zimną kopię systemu. Z jednej zatem strony poprawiają się parametry narzędzi i urządzeń wykorzystywanych do wykonywania kopii zapasowych; z drugiej strony w systemach wciąż przybywa danych, a parametry dostępności wciąż szybują w górę. Aby za tym nadążyć, administratorzy muszą wciąż wymyślać nowe sposoby, jak szybko stworzyć kopię zapasową i – co nie mniej ważne – jak ją szybko odtworzyć.

Na kłopoty – RMAN

Trzeba zatem szukać coraz to nowych sposobów przyspieszania procesu backupowania danych. A jeśli już nie wymyślać nowe, to dokopywać się do mniej znanych opcji narzędzi, których używamy od wielu lat. Tak jak np. „starego dobrego” RMANa. Nie od dziś wiadomo, że kopiowanie danych z dysku na dysk zwykle jest szybsze niż przenoszenie danych z dysku na taśmę. Wykorzystując to genialne odkrycie zajrzyjmy w opcje RMANa, aby odkryć Oracle flash recovery area.

Nie od dziś RMAN umożliwia nam wykonywanie kopii zapasowych na wskazanej lokalizacji dyskowej lub na taśmie. Oczywiście wskazanie docelowego miejsca zapisania kopii na dysku wiąże się z koniecznością zadbania, aby kopia ta nie przerosła rozmiaru wskazanego wolumenu dyskowego. Niejako dla równowagi – przy pomocy tego samego narzędzia możemy usuwać niepotrzebne nam już kopie zapasowe. Możemy również sprawdzić, jakie zrobione wcześniej kopie dostępne są we wskazanych lokalizacjach.

Bardzo przydatnym rozszerzeniem tych funkcjonalności jest dostępna od wersji Oracle Database 10g Release 1 możliwość definiowania specjalnego obszaru dyskowego zwanego flash recovery area (FRA). Obszar ten tym wyróżnia się od pozostałej powierzchni dyskowej, że zarządzany jest nie przez system operacyjny maszyny, a przez motor bazy danych. To on decyduje, czy konieczne jest skasowanie starego backupu – tak, aby umożliwić wykonanie nowej kopii. Wykonując kompletną kopię bazy wraz z plikami kontrolnymi, plikami logów itd., bez niepokojenia administratora zarządza on powierzonym obszarem dyskowym tak, aby wykonać nałożone na niego zadania.

Jak to skonfigurować?

Generalnie, jest to dość proste. Po pierwsze (dość intuicyjnie) musimy zdecydować o lokalizacji oraz rozmiarze obszaru dyskowego przeznaczonego na FRA. Na przykład jeśli chcemy zadeklarować obszar o rozmiarze 100GB w katalogu /home/oracle/FRA, składnia niezbędnego do wykonania polecenia alter system będzie miała postać:
alter system set
db_recovery_file_dest_size = 100G;
alter system set
db_recovery_file_dest = '/home/oracle/FRA';

Następnie do parametrów bazy wprowadzamy następujące informacje:
db_recovery_file_dest_size = 100G
db_recovery_file_dest = '/home/oracle/FRA'

Oczywiście musimy jeszcze sprawić, aby parametry zostały zaczytane przez motor bazy, ale to już zadanie trywialne. Oczywiście pamiętać warto, że jeśli nasza instalacja zawiera Oracle Real Application Clusters (Oracle RAC), wówczas wskazana lokalizacja musi być znana wszystkim maszynom, czyli musi być umieszczona we współdzielonym systemie plików, przymontowanym obszarze dyskowym NFS lub grupie dysków Automatic Storage Management ASM. W tym ostatnim przypadku, drugi z prezentowanych wcześniej parametrów musimy ustawić na wartość:
db_recovery_file_dest = '+DISKGROUP1'

Wszystkie te informacje powinny być widoczne w bazie po zadaniu pytania:
select *
from v$recovery_file_dest;

Więcej informacji uzyskamy odpytując perspektywę V$FLASH_RECOVERY_AREA_USAGE, która poda nam procent wykorzystanego obszaru FRA w podziale na poszczególne typy plików. Aby zobaczyć to w postaci wartości przeliczonych na pojemność dysku, możemy wystosować zapytanie do obu tych perspektyw jednocześnie:
select file_type, space_used*percent_space_used/100/1024/1024 used,
space_reclaimable*percent_space_reclaimable/100/1024/1024 reclaimable, frau.number_of_files
from v$recovery_file_dest rfd, v$flash_recovery_area_usage frau;
FILE_TYPE USED RECLAIMABLE NUMBER_OF_FILES
----------------- ----------- --------------------- -------------------------
CONTROLFILE .00 .00 0
ONLINELOG .00 .00 0
ARCHIVELOG 1490.80 101.20 15
BACKUPPIECE 372.46 3928.92 7
IMAGECOPY .00 .00 0
FLASHBACKLOG 16.07 .00 2

Pliki kopii zapasowych, które zdaniem RMANa można już usunąć, zaznaczone są jako RECLAIMABLE. Oczywiście mamy wciąż możliwość ingerencji „ręcznej” i podejmowania suwerennych decyzji o usunięciu niektórych z backupów. W tym celu pomocne będzie wcześniejsze wylistowanie zawartości FRA:
RMAN> list copy of database;
List of Datafile Copies
Key File S Completion Time Ckp SCN Ckp Time Name
------ ------ ------ -------------------- ------------ ------------ ------------
4404 1 A 06-JAN-07 1607862 06-JAN-07 /home/oracle/FRA/B2/datafile/o1_mf_system_gd.dbf
4407 2 A 06-JAN-07 607935 06-JAN-07 /home/oracle/FRA/B2/datafile/o1_mf_undotbs1_ab.dbf
4405 3 A 06-JAN-07 1607907 06-JAN-07 /home/oracle/FRA/B2/datafile/o1_mf_sysaux_nz.dbf
4408 4 A 06-JAN-07 1607939 06-JAN-07 /home/oracle/FRA/B2/datafile/o1_mf_users_st.dbf
4406 5 A 06-JAN-07 1607926 06-JAN-07 /home/oracle/FRA/B2/datafile/o1_mf_example_to.dbf

Teraz, aby dobrze wykorzystać wiedzę o RMANie, musimy jeszcze przypomnieć sobie w jaki sposób wykonywane są w tym narzędziu kopie zapasowe. Jeśli nie zmienimy ustawień domyślnych, kopie zapasowe zawierają jedynie bloki dyskowe zapisane danymi. Możemy jednak sprawić, że nasza kopia będzie lustrzanym odbiciem oryginalnych plików. Jest to tzw. Oracle RMAN image copy. Oczywiście, nie trudno jest przewidzieć, że kopia taka zajmuje doskonale więcej miejsca, ale jak się za chwilę przekonamy, może się to okazać bardzo opłacalnym. Już tylko dla porządku dodam, że image copy wykonywana jest bez konieczności zatrzymania pracy bazy. Wystarczy tylko wydać polecenie:
run {
backup as copy
database;
}

Jak tego użyć?

Właśnie. Jak sprytnie użyć tak stworzoną kopię bazy? Wystarczy uzmysłowić sobie, że tak utworzona kopia pliku nie tylko znajduje się w obszarze dyskowym FRA. Informacja o tej lustrzanej kopii pliku zapisana jest również w pliku kontrolnym bazy. Co z tego wynika? Ano dokładnie tyle, że w przypadku awarii zbackupowanego w ten sposób pliku, niekoniecznie musimy go wykopiowywać do „normalnego” systemu plików bazodanowych. Możemy wykorzystać ją bezpośrednio.

Ale po kolei. Zakładając uszkodzenie jednego z plików bazodanowych, w klasycznym podejściu do odtwarzania systemu powinniśmy wprowadzić przestrzeń tabel, w której plik uległ uszkodzeniu w tryb off-line. Następnie odtworzyć feralny plik z backupu i uzupełnić go o transakcje przeprowadzane do chwili poprzedzającej awarię. W tym momencie przestrzeń tabel powinna dać się wprawić w tryb on-line. Procedura nie wygląda na skomplikowaną, w praktyce trwać może od kilku minut do kilku godzin. Nie zawsze jest to jednak czas akceptowalny dla użytkowników aplikacji z bazy tej korzystającej.

Jak więc możemy skorzystać z kopii zapisanych w obszarze FRA? Możemy zrezygnować z odtwarzania pliku przestrzeni tabel z kopii zapasowej do katalogu przechowującego pliki bazy danych i wskazać motorowi bazy, aby do bieżącej pracy wykorzystywał bezpośrednio kopię pliku zapisaną w obszarze FRA. Aby informację taką przekazać bazie danych, musimy wykonać następującą sekwencję działań. Po pierwsze, musimy ustalić numer i nazwę uszkodzonego pliku:
select file_id, file_name
from dba_data_files
where tablespace_name = 'nazwa_przestrzeni _tabel';
file_id file_name
-------- --------------------------------------------
2 /home/oracle/oradata/B1/plik01.dbf

Teraz czas na wejście do konsoli Oracle RMAN i wykonanie pozostałych czynności:
RMAN> sql 'alter tablespace users offline';
sql statement: alter tablespace users offline
RMAN> switch datafile 2 to copy;
datafile 2 switched to datafile copy "/home/oracle/FRA/B1/datafile/o1_mf_nazwa_ac.dbf"
RMAN> recover datafile 2;
Starting recover at 06-JAN-07
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:05
Finished recover at 06-JAN-07
RMAN> sql 'alter tablespace users online';
sql statement: alter tablespace users online

Warto teraz sprawdzić jak wygląda informacja o tym pliku z perspektywy słownika bazy danych:
select name from v$datafile
where file# = 2;
NAME
-------
/home/oracle/FRA/B1/datafile/o1_mf_nazwa_ac.dbf

Jak widać, na poziomie słownika bazy zapisana jest już informacja, że aktywnym plikiem bazodanowym o ID=2 jest plik backupowy zapisany w obszarze FRA. Zaoszczędziliśmy w ten sposób sporo czasu potrzebnego do odtworzenia z taśmy pliku z kopii zapasowej.

 


Baza danych zbackupowana do obszaru FRA


Baza danych pracująca z plikiem z obszaru FRA

 

Sukces tak szybko odniesiony ma jednak swoje wady. Wprawdzie przywróciliśmy sprawność bazy danych, ale plik danych z którego korzysta baza, znajduje się w obszarze backupowym. Niekoniecznie jest to sytuacja wygodna. Dyski przeznaczone do składowania kopii zapasowych mogą na przykład być sprzętowo wolniejsze. Nie jest to również rozwiązanie eleganckie z punktu widzenia administratora bazy. Wcześniej czy później, musimy sprawę tę jakoś uregulować. A więc znów będziemy musieli użyć konsoli Oracle RMAN. Musimy bowiem wykonać następującą sekwencję operacji: skopiować (używany „tymczasowo” jako roboczy) plik obszaru FRA do lokalizacji przeznaczonej dla plików bazodanowych; wprawić feralną przestrzeń tabel w tryb off-line, a następnie przełączyć pracę bazy na nową (a w zasadzie starą) lokalizację pliku; wyrównać zawartość pliku przestrzeni tabel do aktualnego stanu transakcji w bazie i wykonać przywrócenie przestrzeni do stanu on-line.
RMAN> backup as copy datafile 2 format '/home/oracle/oradata/PRODB2/users01.dbf';
Starting backup at 06-JAN-07
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile fno=00002 name=/home/oracle/FRA/B1/datafile/o1_mf_nazwa_ac.dbf
output filename=/home/oracle/oradata/B1/plik01.dbf tag=TAG20070106T103710 recid=35 stamp=6022837460
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 06-JAN-07
Starting Control File Autobackup at 06-JAN-07
piece handle=/home/oracle/FRA/B1/autobackup/2007_01_06/
o1_mf_n_.bkp comment=NONE
Finished Control File Autobackup at 06-JAN-07
RMAN> sql 'alter tablespace nazwa offline';
...
RMAN> switch datafile 2 to copy;
datafile 2 switched to datafile copy "/home/oracle/oradata/B1/plik01.dbf"
RMAN> recover datafile 2;
...
RMAN> sql 'alter tablespace users online';
...

Oczywiście opisana tu procedura może zostać zastosowana do więcej niż jednego, a w skrajnym przypadku do wszystkich plików bazy. Finalne odtworzenie plików bazodanowych może się również odbyć do zupełnie nowej lokalizacji. Twórcy tego mechanizmu przewidzieli takie kompleksowe przełączenia. Dowodem na to jest istnienie jednej „zbiorczej” komendy, która przekierowuje uwagę motoru bazy danych na wskazaną lokalizację:
RMAN> switch database to copy;

Oczywiście przełączenia takiego dokonać można również w inny sposób, ale w tym przypadku konsola RMANa bardzo przyjemnie odciąża administratora od żmudnej pracy, zwłaszcza że rzecz cała dzieje się w obliczu stanu awarii bazy.

Nie same zalety

Na koniec jeszcze mała łyżka dziegciu. Wykonywanie kopii zapasowych bazy na wydzielonym obszarze dyskowym ma wiele zalet. Ma również sporo wad. Dyski obszaru FRA ulegają uszkodzeniu z dokładnie takim samym prawdopodobieństwem, jak pozostałe dyski serwera bazy danych. Nie można ich również w prosty i naturalny sposób usunąć z maszyny i zeskładować w innej lokalizacji niż dane produkcyjne. Nie pozostaje nam więc nic innego, jak wykonać kopię zapasową obszaru FRA na taśmie. Znów uśmiechamy się więc do rozlicznych możliwości konsoli RMANa. Aby obszar FRA zrzucić na taśmę wystarczy wydać polecenie:
run {
allocate channel c1 type sbt_tape;
backup recovery area;
}

Ot i cała filozofia szybciutkiego odtwarzania bazy. Życzę przyjemnej zabawy i jak najmniej negatywnych doświadczeń w realizacji tych procedur.