RMAN: Deset zlatih pravil
Boris Oblak,
11. 9. 2007
(Objavljeno: Moj Mikro, september 2007)
Kaj povzroča največ stresa pri odgovornih za informatiko v podjetjih? Odgovorov je verjetno več, zagotovo pa je nekje na vrhu strah pred izgubo podatkov.
Varnostno kopiranje in obnavljanje podatkov sta med najpomembnejšimi opravili, ki jih izvaja administrator zbirke podatkov. Če se zbirka podatkov zruši in ni poti, da bi jo vrnili, pomeni to katastrofalne posledice za poslovanje. Vsem podjetjem, naj bodo to mala z majhnimi zbirkami podatkov ali pa velika z veliko in velikimi zbirkami, je skupna ena lastnost: potreba po varnostnem kopiranju pomembnih podatkov in načrt reševanja podatkov v primeru katastrofe.
»Vsa podjetja potrebujejo varnostno kopiranje pomembnih podatkov in načrt reševanja v primeru katastrofe. V pomoč je lahko Oraclovo orodje Recovery Manager (RMAN).«
Oraclovo orodje za izdelavo varnostnih kopij in obnavljanje zbirk podatkov se imenuje Recovery Manager (RMAN). Kaj vse je treba narediti pri varnostnem kopiranju podatkov, da bi administrator zbirke podatkov mirneje spal in kako mu lahko pri tem RMAN pomaga?
Temeljni pogoji za tehnike, ki so omenjene v tem dokumentu, so:
- zbirka podatkov teče v arhivskem načinu (archivelog mode)
- uporabljamo več kontrolnih datotek (controlfile)
- redno izvajamo postopke varnostnega kopiranja zbirke podatkov
- redno izvajamo obnavljanje zbirke podatkov, da preverimo postopke za varnostno kopiranje in obnavljanje zbirke
Vklopimo preverjanje blokov
Okvare na podatkih lahko izvirajo iz različnih virov. Nastanejo lahko zaradi napake na disku, napake v operacijskem sistemu ali v podatkovni zbirki, napake na omrežju pomnilniških naprav (SAN), ... Če okvare ne preprečimo ali popravimo, lahko ustavijo zbirko podatkov ali celo privedejo do izgube pomembnih podatkov.
Zbirka podatkov Oracle zagotavlja učinkovite tehnike za odkrivanje okvarjenih podatkov in za njihovo obnavljanje. Tehnike zagotavljajo obnavljanje podatkov na nivoju posameznega bloka, varnostno kopiranje in obnavljanje podatkov (v celoti ali inkrementalno), obnavljanje do določenega časa (point in time recovery), podatkovne zbirke v pripravljenosti (standby databases) in obnavljanje na nivoju transakcij. Te tehnike zagotavljajo obnavljanje podatkov, vendar lahko celoten proces traja dolgo, posebno še v primeru obnavljanja s trakov. S preventivnim nadzorom nad podatki lahko prihranimo veliko časa, truda in stresa, ki jih povzročijo okvara ali izguba podatkov oziroma začasno neuporabna zbirka podatkov.
Vseh napak v podatkovnih blokih ne moremo preprečiti, vendar obstajajo tehnike, s katerimi lahko preprečimo večino. Ena od tehnik je tudi pravilna uporaba parametrov zbirke podatkov.
Kljub preventivnim tehnikam lahko še vedno pride do tega, da se okvarjen blok zapiše na disk. V tem primeru moramo tak blok najti. Zbirka podatkov ima dva pomembna parametra, s katerima nastavimo, kako naj se izvaja preverjanje blokov pri branju in zapisovanju. To sta DB_BLOCK_CHECKSUM in DB_BLOCK_CHECKING. Poleg tega zbirka podatkov ponuja več orodij za odkrivanje okvarjenih blokov na zahtevo: Recovery Manager (RMAN), DBVERIFY, ANALYZE in DBMS_REPAIR.
Parametra zbirke podatkov nastavimo z namenom, da čim prej odkrijemo poškodovane bloke in da preprečimo širitev poškodbe še na druge medije (disk, nadomestna zbirka, varnostna kopija).
Parameter DB_BLOCK_CHECKSUM ima lahko vrednosti:
- TYPICAL
- OFF
- FULL
Privzeta vrednost je TYPICAL in pomeni, da zbirka podatkov izračuna kontrolno vsoto in jo shrani v glavo bloka pri vsakem zapisovanju na disk. Pri naslednjem branju se kontrolna vsota preveri. Na ta način zbirka podatkov ugotovi, ali je blok okvarjen. Izračunavanje kontrolne vsote najde napake, ki se nastanejo pri zapisovanju na diske, omrežja pomnilniških naprav oziroma na vhodno/izhodni sistem.
Če ima parameter vrednost OFF, potem zbirka podatkov izračunava in zapisuje kontrolne vsote samo v podatkovno področje (tablespace) SYSTEM.
V primeru vrednosti parametra FULL, zbirka podatkov preveri kontrolno vsoto pred spremembo podatkov pri stavku UPDATE/DELETE in jo ponovno preračuna, ko je sprememba podatkov v bloku narejena. Izračuna kontrolno vsoto vsakega bloka, ki ga zapiše v dnevnik (current redo log). Postavljanje parametra na FULL pomeni približno 4-5 % performančni pribitek.
Ko delujoča zbirka podatkov ugotovi okvaro v bloku, javi napake (ORA‑600, ORA‑01578) v dnevnik opozoril (alert log). Podatke o okvarjenih blokih zapiše tudi v pogled V$DATABASE_BLOCK_CORRUPTION. Zavedati se moramo, da kontrolna vsota ne zagotavlja logične pravilnosti podatkov v bloku, pač pa zagotavlja samo hitro zagotovilo, da je blok pravilno zapisan na disk.
Parameter DB_BLOCK_CHECKING ima lahko vrednosti:
- OFF
- LOW
- MEDIUM
- FULL
Ko ima parameter vrednost FULL, zbirka podatkov preverja vse bloke, torej preveri glavo in podatkovni del bloka. Kadar je vrednost OFF, kar je tudi privzeta vrednost, zbirka podatkov ne preverja uporabniških podatkov. Vedno preverja podatkovno področje SYSTEM in meta podatke o zasedenosti prostora (bitmap in segment header block).
Parameter ima lahko še dve vmesni vrednosti, LOW in MEDIUM. Pri vrednosti LOW zbirka podatkov preveri glavo bloka, ko se vsebina bloka spremeni v pomnilniku (na primer po UPDATE ali INSERT stavkih, ko se blok prebere z diska ali ko se blok prenese med instancami v gruči). Pri nastavitvi MEDIUM zbirka podatkov preveri vse kot pri nastavitvi LOW, dodatno pa izvede še semantične kontrole vsebine bloka pri vseh neindeksnih strukturah blokov.
Pri vrednosti FULL zbirka podatkov preveri vse podatkov v bloku, tako da je zagotovljena konsistenca. To pomeni, da je glava bloka skladna s podatki ter da so vrstice in kolone pravilno zapisane (dolžine kolon niso pokvarjene, vrstice se ne prekrivajo, ...). Taka kontrola bloka običajno ujame pomnilniške in napake na podatkih, ki jih izračun kontrolne vsote spregleda.
Tako preverjanje blokov povzroči približno 1-10 % performančnega pribitka na sistemu, odvisno od delovne obremenitve. Če je performančno sprejemljivo, priporočam nastavitev parametra na vrednost FULL.
Vklopimo sledenje sprememb podatkovnih blokov in inkrementalno varnostno kopiranje podatkov
V različici zbirke podatkov Oracle 9i in 8i je RMAN pri inkrementalnem varnostnem kopiranju prebral vse bloke in shranil samo bloke, ki so bili spremenjeni od zadnje celotne varnostne kopije. Zato so se administratorji podatkovnih zbirk redkeje odločali za to možnost. Od različice 10g dalje pa zbirka podatkov zapisuje v posebno datoteko seznam blokov, ki se spreminjajo. Vklop te možnosti pove programu RMAN, da bo na varnostno kopijo zapisal samo bloke, ki so se spremenili od zadnje celotne varnostne kopije (full backup). S tem se skrajša čas varnostnega kopiranja.
Možnost vklopimo z ukazom:
SQL> alter database enable block change tracking [using file '<filename>'];
in preverimo, če deluje:
SQL> select filename, status from v$block_change_tracking;
FILENAME STATUS
---------------------------------------- ----------
+ABA/abakus/changetracking/ctf.327.1 ENABLED
Podvojimo dnevniške skupine in člane (log groups and members) in določimo več kot eno destinacijo za arhivski dnevnik (archive log)
Če se poškodujeta arhivski ali trenutni dnevnik, bo obstajala vsaj še ena kopija, ki se bo lahko uporabila, če bo treba obnoviti podatke.
SQL> alter system set log_archive_dest_2='location=/oradmin/abakus/arch2' scope=both;
SQL> alter database add logfile member '/oradata/abakus/onlinelog/redo21.log' to group 1;
Pri izdelavi varnostnih kopij uporabimo parameter 'check logical'
Če nastavimo ta parameter, potem RMAN preveri tudi logično skladnost podatkov v bloku in ne samo kontrolno vsoto. To je najboljši način, da se zagotovi dobra varnostna kopija.
RMAN> backup check logical database plus archivelog delete input;
Testiranje varnostnih kopij
RMAN> restore validate database;
Ukaz bo izvedel vse akcije razen dejanske obnove zbirke podatkov. To je najboljša metoda za ugotavljanje, ali je varnostna kopija nepokvarjena in uporabna.
Vsaka datoteka naj bo v svojem delu varnostne kopije (backup piece)
RMAN> backup database filesperset 1 plus archivelog delete input;
Kadar obnavljamo samo del podatkov, mora RMAN prebrati celotni del varnostne kopije, da najde potrebno podatkovno datoteko ali datoteko dnevnika. Manjši je del varnostne kopije, hitreje bo RMAN našel datoteko, ki jo je treba obnoviti. To je zlasti potratno pri varnostnih kopijah, ki so shranjene na trakovih.
Vzdrževanje RMAN-ovega kataloga in/ali kontrolne datoteke
Politiko varnostnega kopiranja podatkov je potrebno skrbno načrtovati. Če ne uporabljamo kataloga, moramo zagotoviti dovolj prostora v kontrolni datoteki, da bo skladna s politiko varnostnega kopiranja podatkov.
SQL> alter system set control_file_record_keep_time=21 scope=both;
Ukaz bo v kontrolni datoteki rezerviral prostor za 21 dni zapisov o varnostnih kopijah.
Redno moramo vzdrževati katalog. Z ukazom "delete obsolete" zbrišemo zapise o varnostnih kopijah, ki ne ustrezajo politiki varnostnega kopiranja podatkov. Če teh zapisov ne izbrišemo, potem bo velikost kataloga naraščala, kar lahko privede do performančnih problemov.
Z navzkrižno kontrolo kataloga ali kontrolne datoteke preverimo skladnost zapisov v katalogu z dejanskim stanjem varnostnih kopij. Če varnostna kopija oziroma del varnostne kopije manjka, potem RMAN označi ta del s statusom 'EXPIRED'. Pri obnavljanju podatkov RMAN tak del preskoči in vzame starejšega. Za brisanje delov varnostne kopije s statusom 'EXPIRED' uporabimo ukaz 'delete expired'.
RMAN> crosscheck backup;
RMAN> delete expired backup;
Varnostno kopiranje kontrolnih datotek
Z ukazom 'set autobackup on' poskrbimo, da bo RMAN na koncu izdelave varnostne kopije shranil še kontrolno datoteko.
RMAN> configure controlfile autobackup on;
Pametno je tudi obdržati dnevnik varnostnega kopiranja podatkov, ker vsebujejo pomembne podatke o lokaciji varnostnih kopij kot tudi o lokaciji shranjene kontrolne datoteke.
Testiranje obnovitve podatkov
Pri testiranju obnovitve podatkov se pokaže, kaj se bo dejansko obnovilo (trial recovery).
SQL> recover database test;
Periodično preverjanje blokov v datotekah podatkovne zbirke in v dnevniku
RMAN> backup validate check logical database archivelog all;
S tem ukazom bo zbirka podatkov preverila vse bloke v zbirki podatkov in v dnevniku. Izvedla bo test kontrolne vsote kot tudi logično kontrolo blokov. Če bo našla okvarjen blok, bo napake javlila v dnevnik opozoril (alert log). Podatke o okvarjenih blokih bo zapisala tudi v pogled V$DATABASE_BLOCK_CORRUPTION.