ATELIER

ORACLE

Strategii de recuperare a bazelor de date Oracle

Claudiu Ariton
rincipala responsabilitate a administratorului bazei de date este s fie pregtit din timp n cazul apariiei unei cderi hardware, software, de reea, de proces sau de sistem. Dac un astfel de eec afecteaz activitatea unui sistem de gestiune a bazelor de date, este de dorit recuperarea datelor i reluarea operaiilor normale ct mai repede posibil. Procesul de recuperare variaz n funcie de tipul de eec care apare, structurile care sunt afectate i de tipul de recuperare cerut. Dac nici un fiier nu este pierdut sau deteriorat, recuperarea se realizeaz doar prin simpla repornire a bazei de date. Dac exist pierderi de date, procesul de recuperare solicit pai adiionali.

Tipuri de eec
Eecul instanei (DataBase Instance Failure) apare cnd un eveniment mpiedic rularea normal a proceselor de backgound (PMON, SMON, DBWR sau LGWR). Acest tip de eec poate fi cauzat de o problem hardware (ntreruperea alimentrii cu energie electric) sau software (eecul sistemului de operare sau al altor programe ce lucreaz cu baza de date). Recuperarea instanei se realizeaz automat, procedura implicnd dou faze: derularea nainte a tranzaciilor comise aplicnd fiierele jurnal online i derularea napoi a tranzaciilor necomise utiliznd segmentele de revenire (figura 1). Aceast procedur se execut i atunci cnd baza de date este repornit dup nchiderea ei cu opiunea ABORT SHUTDOWN ABORT. n cazul utilizrii OPS (Oracle Parallel Server) o instana activ recupereaz automat instana czut.

Cum afecteaz eecul media baza de date? Eecul media poate afecta un tip sau toate tipurile de fiiere necesare funcionrii normale a bazei de date Oracle (fiiere de date, fiiere jurnal, fiierul de control). Dac a fost distrus un disc ce conine fiiere jurnal sau fiierul de control, dar se utilizeaz multiplexarea acestora pe alte discuri, baza de date va funciona normal fr nici o ntrerupere. Dac ns aceste fiiere nu au fost multiplexate, funcionarea bazei de date este ntrerupt i pot apare pierderi de date. Eecul media care afecteaz fiierele de date se divide n dou categorii: eec de scriere sau eec de citire. Dac Oracle descoper c nu poate citi un fiier de date, o eroare de sistem este returnat aplicaiei indicnd faptul c fiierul respectiv nu poate fi gsit, nu poate fi deschis sau nu poate fi citit. Baza de date va funciona normal, dar aceast eroare va aparea ori de cte ori se va ncerca o nou citire din fiierul deteriorat. Dac Oracle descoper c nu poate scrie ntr-un fiier de date, atunci se arhiveaz automat fiierul jurnal online activ, o eroare este returnat procesului DBWR i se va produce scoatere offline a fiierului deteriorat. Dac fiierul de date n care nu se poate scrie se gsete n tabela de spaiu SYSTEM, fiierul nu poate fi scos offline. O eroare este returnat i Oracle va opri automat baza de date. Cauza acestei excepii este c toate fiierele de date din tabela de spaiu SYSTEM trebuie s fie online pentru ca baza de date s funcioneze normal. Tot din acest motiv toate fiierele de date ce conin segmente de revenire active trebuie s fie online.

Tipuri de recuperare media

recuperarea complet cnd se utilizeaz cel mai recent backup i toate fiierele jurnal recuperarea incomplet cnd se utilizeaz cel mai recent backup i numai o parte din fiierele jurnal. Recuperarea incomplet apare n unul din urmtoarele cazuri: eecul media a distrus o parte din fiierele jurnal online sau arhiv

Figura 1 Recuperarea automat a instanei

Figura 2 Recuperarea dup eec media

Eecul media (de disc) (Media (Disk) Failure) se manifest prin incapacitatea bazei de date de a citi sau de a scrie date de/pe disc. Cauzele care duc la un eec media includ defectarea discului, blocuri defecte pe disc, fiiere de date sau de sistem terse sau defecte. Recuperarea media se realizeaz prin restaurarea fiierelor pierdute sau deteriorate dintr-un backup recent i apoi aplicarea fiierelor log online sau arhiv pentru readucerea bazei de date ntr-o stare anterioar producerii eecului (figura 2). 21 NET REPORT aprilie 2001

ATELIER
ORACLE
o eroare uman a cauzat pierderea datelor (tergeri de tabele) s-a pierdut fiierul de control online i se va utiliza un fiier de control multiplexat pentru a porni baza de date n modul ARCHIVELOG se poate opta ntre recuperarea complet sau incomplet. n modul NOARCHIVELOG baza de date se poate numai restaura folosind cel mai recent backup fr a aplica datele din jurnal. Structuri utilizate n recuperarea bazei de date: backup-ul bazei de date utilizat pentru a restaura baza de date fiiere jurnal online lucreaz mpreun cu procesul de background LGWR i nregistreaz toate modificrile asociate unei instane (sunt scrise circular). Aceste tipuri de fiiere fac parte din procesul de recuperare numai dac se restaureaz baza de date dintr-o arhiv la rece (cold backup). De fapt, ele nu trebuiesc niciodat arhivate n cazul arhivrii la cald (hot backup). fiiere jurnal arhiv copii ale tuturor fiierelor jurnal online (numai dac baza de date ruleaz n modul ARCHIVELOG) segmentele de revenire conin imaginea nainte a unui rnd dintr-o tabel sau a rndurilor modificate din blocul de date (vezi tabelul) fiierul de control conine informaii despre structura fizic a bazei de date Deoarece n Oracle, recuperarea se realizeaz pe trei nivele (la nivelul bazei de date, la nivelul tabelei de spaiu sau a fiierului de date) se va opta pentru cel mai potrivit nivel, astfel nct, s se recupereze numai ceea ce este deteriorat sau pierdut. Recuperarea pe cele trei nivele presupune diferite opiuni la pornirea bazei de date. cazul recuperrii complete. Dac baza de date nu ruleaz n modul ARCHIVELOG, singurul mod de a recupera baza de date este restaurarea fiierelor de date, a fiierului de control i a fiierelor jurnal online din cel mai recent backup. n acest caz avem de a face cu o recuperare incomplet deoarece se produc pierderi de date. Dup o recuperare incomplet baza de date va fi deschis cu opiunea RESETLOGS, care va reseta numrul secvenei jurnal i va cura fiierul jurnal online curent. n unele cazuri opiunea RESETLOGS poate s modifice coninutul fiierului de control i header-ul fiierelor de date pentru a reflecta noua organizare fizic a bazei de date. Din acest motiv, dup utilizarea opiunii RESETLOGS se va face un nou backup al bazei de date deoarece vechiul backup nu mai reflect corect structura fizic a bazei de date. Comanda general de recuperare este:
RECOVER [AUTOMATIC] [FROM 'archive_file_location'] | [STANDBY] DATABASE [UNTIL CANCEL] | [UNTIL TIME time] | [UNTIL CHANGE integer] [USING BACKUP CONTROLFILE] TABLESPACE 'table_space name' DATAFILE 'datafile_name' CONTINUE CANCEL

Cum lucreaz segmentele de revenire

Tranzacia Ce conine segmentul de revenire INSERT ROWID-ul rndului inserat Comanda ROLLBACK Citete ROWID-ul din segmentul de revenire, gsete rndul inserat n tabel i apoi terge rndul inserat din tabel Toate coloanele modificate Citete ROWID-ul din segmentul de i ROWID-ul rndului revenire, gsete rndul modificat n modificat tabel i anuleaz modificrile folosind imaginea coloanele modificate din segmentul de revenire Toate coloanele i Re-insereaz rndul n tabel ROWID-ul rndului ters folosind ROWID-ul i imaginea tuturor coloanele din segmentul de revenire

Recuperarea la nivelul bazei de date se utilizeaz cnd se recupereaz tabel de spaiu SYSTEM, un fiier de date ce face parte din tabela de spaiu SYSTEM sau conine segmente de revenire active sau cnd se execut orice tip de recuperare incomplet. Opiunea UNTIL CANCEL realizeaz o recuperare incomplet i se utilizeaz cnd un fiier jurnal arhiv este deteriorat. 1. Restaurarea fiierelor de date i a fiierelor jurnal arhiv din cel mai recent backup 2. Montarea bazei de date cu comanda STARTUP MOUNT din SERVER
MANAGER

UPDATE

DELETE

3. Comanda RECOVER DATABASE UNTIL CANCEL produce recuperarea bazei de date aplicnd primul fiier jurnal din secven i ofer posibilitatea anulrii recuperrii nainte de a aplica urmtorul fiier jurnal. 4. Comanda RECOVER DATABASE CANCEL produce orpirea procesului de recuperare 5. Deschiderea bazei de date cu comanda ALTER DATABASE OPEN
RESETLOGS

Pornirea bazei de date se realizeaz n trei pai: 1. Pornirea instanei Oracle (STARTUP NOMOUNT) se citete fiierul init<SID>.ora care conine parametrii de iniializare, se aloc memoria pentru zona de SGA i se pornesc procesele de background. Totodat se deschid i fiierele de urmrire i de alert care monitorizeaz starea bazei de date TRACE, ALERT. 2. Montarea bazei de date se deschide fiierul de control asociat bazei de date i se citesc starea i locaia fiierelor de date i a fiierelor jurnal. n aceast etap sunt disponibile urmtoarele operaii: redenumirea fiierelor de date, activare/dezactivare ARCHIVELOG, recuperarea bazei de date. Comanda utilizat pentru montarea bazei de date este ALTER DATABASE MOUNT dac instana este pornit sau STARTUP MOUNT dac instana nu este pornit. 3. Deschiderea bazei de date - se deschid fiierele de date i fiierele jurnal ale bazei de date i se verific consistena bazei de date. Comanda utilizat pentru deschiderea bazei de date este ALTER DATABASE OPEN dac baza de date este montat sau STARTUP [OPEN] dac baza de date nu este montat. Procesul de recuperare se realizeaz n trei faze: restaurarea fiierelor externe, faza de derulare nainte (roll-forward) i faza de derulare napoi (rollback). Faza de derulare nainte i faza de derulare napoi se desfoar prin aplicarea fiierelor jurnal arhiv i se utilizeaz n

Opiunea UNTIL TIME realizeaz o recuperare incomplet, pn la un moment specificat n timp. De exemplu, un utilizator a ters, din greeal, o tabel la ora 16.00 n cursul zilei de 24 Martie 2001. Baza de date poate fi recuperat la momentul 15:59:59. 1. Restaurarea fiierelor de date i a a fiierelor jurnal arhiv din cel mai recent backup 2. Montarea bazei de date cu comanda STARTUP MOUNT din SERVER
MANAGER

3. Comanda RECOVER
03-24 15:59:59'

[AUTOMATIC] DATABASE UNTIL TIME '2001-

Opiunea AUTOMATIC realizeaz recuperarea bazei de date i aplicarea fiierelor arhiv fr intervenia administratorului bazei de date 4. Deschiderea bazei de date cu comanda ALTER DATABASE OPEN
RESETLOGS

Opiunea UNTIL CHANGE - realizeaz o recuperare incomplet, pn la un anumit SCN (System Change Number). Oracle asigneaz fiecrei tranzacii comise un unic SCN. Pentru a vedea SCN-ul tranzaciilor comise se pot utiliza view-urile system v$log_history (pentru fiierele jurnal arhiv) i v$log (pentru fiierele jurnal online).
select archive_name, low_change#, high_change# from v$log_history; select group#, members, first_change# from v$log;

aprilie 2001 NET REPORT 22

ATELIER
ORACLE
1. Restaurarea fiierelor de date i a a fiierelor jurnal arhiv din cel mai recent backup 2. Montarea bazei de date cu comanda STARTUP MOUNT din SERVER
MANAGER

2. Interogarea select bytes/1024 from v$log where group# = pentru a vedea mrimea n K a fiierelor jurnal pierdute (de ex. 500 K) 3. tergerea grupului redo log 3 alter database drop log3; file group 3;

3. Comanda RECOVER [AUTOMATIC] DATABASE UNTIL CHANGE 10488 (10488 reprezint SCN-ul tranzaciei pn la care se va face recuperarea bazei de date) 4. Deschiderea bazei de date cu comanda ALTER DATABASE OPEN
RESETLOGS

1. Recrearea grupului redo

log 3

alter database add logfile group 3 (/cale/log31.log, /cale/log32.log) size 500k;

Opiunea USING BACKUP CONTROLFILE este necesar n dou situaii fiierul de control este deteriorat i nu a fost multiplexat fiierul de control nu mai reflect structura fizic curent a bazei de date Recuperarea la nivelul tabelei de spaiu este o recuperare consistent, deoarece se aplic toate fiierele arhiv. n acest caz baza de date poate fi deschis, iar tabela de spaiu trebuie s fie offline. Dac tabela de spaiu alterat este tabela SYSTEM sau dac un fiier arhiv este deteriorat atunci singura recuperare posibil este la nivelul bazei de date. 1. Deschiderea bazei de date cu comanda STARTUP din SERVER
MANAGER

2. Deschiderea bazei de date cu comanda ALTER DATABASE OPEN Deteriorarea tuturor fiierelor jurnal online dintr-un grup care este activ n acest caz apare mesajul de eroare ORA-00257: archiver error. Connect internal only, until freed. Dac se ncearc recuperarea efectund paii descrii mai sus, la ncercarea de tergere a grupului redo log (pasul 3), Oracle returneaz mesajul de eroare ORA-00350: log 3 of thread 1 needs to be archived. 1. Montarea bazei de date cu comanda STARTUP MOUNT din SERVER
MANAGER

2. Interogarea

select

group#,

sequence#,

bytes,

first_change#, first_time, status from v$log; TABLESPACE nume_tab OFFLINE IMMEDIATE

2. Comanda ALTER

se observ ca status-ul fiierelor tabelei de spaiu nume_tab este RECOVER urmeaz sa fie recuperate 3. Restaurarea fiierelor de date corespunztoare tabelei de spaiu din cel mai recent back-up 4. Comanda RECOVER [AUTOMATIC] TABLESPACE nume_tab select * from v$datafile se observ ca status-ul fiierelor tabelei de spaiu nume_tab este acum OFFLINE au fost recuperate 5. Comanda ALTER TABLESPACE nume_tab ONLINE select * from v$datafile se observ ca status-ul fiierelor tabelei de spaiu nume_tab este acum ONLINE tabela de spaiu este disponibil utilizatorilor Tabelele de spaiu ce conin segmente temporare, de index sau segmente de revenire (numai dac avem comenzile iniiale de creare ale acestora) pot fi refcute prin tergerea tabelei de spaiu cu comanda DROP TABLESPACE nume_tab, tergerea fizic de pe disc a fiierelor de date corespunztoare acesteia, refacerea tablei de spaiu i a segmentelor folosind comenzile iniiale de creare (CREATE TABLESPACE, CREATE INDEX, CREATE ROLLBACK). Recuperarea la nivelul fiierului de date - este o recuperare consistent, asemntoare recuperrii la nivelul tabelei de spaiu. Singura deosebire este c, doar fiierul de date deteriorat este scos offline i nu ntreaga tabel de spaiu din care face parte. Dac fiierul de date aparine tabelei de spaiu SYSTEM atunci singura recuperare posibil este la nivelul bazei de date. 1. Deschiderea bazei de date cu comanda STARTUP din SERVER MANAGER 2. Comanda ALTER DATABASE DATAFILE nume_fis OFFLINE 3. Restaurarea fiierului de date din cel mai recent back-up 4. Comanda RECOVER [AUTOMATIC] DATAFILE nume_fis 5. Comanda ALTER DATABASE DATAFILE nume_fis OFFLINE Deteriorarea tuturor fiierelor jurnal online dintr-un grup care nu este activ. Cnd procesul LGWR va ncerca s scrie n membrii unui grup redo log deteriorat, automat toi utilizatorii bazei de date vor fi deconectai, primind mesajul de eroare ORA-01092: ORACLE instance terminated. Disconnection forced Dac se ncearc o nou conexiune la baza de date se primete mesajul de eroare ORA-03114: not connected to ORACLE sau ORA-00472: PMON process terminated with error. 1. Redeschiderea bazei de date cu comanda STARTUP FORCE (echivalent cu comanda SHUTDOWN ABORT urmat de STARTUP). Baza de date va fi doar montat datorit mesajului de eroare ORA-00313: open failed for members of log group 3 of thread 1, eroare ce arat c grupul redo log 3 este inaccesibil.
select * from v$datafile

se va scade o secund din coloana first_time corespunztoare grupului deteriorat (ex. first_time = 24/03/01 18:00:00) 1. RECOVER [AUTOMATIC] UNTIL TIME '2001-03-24 17:59:59' 2. ALTER DATABASE OPEN RESETLOGS

Concluzii
(1) Cum determinm ce eec a aprut? Multe din problemele aprute pot fi rezolvate prin monitorizarea fiierului de alert (ALERT LOG), ce conine informaii generale despre pornirea, oprirea bazei de date i erorile ntlnite pe parcursul funcionrii acesteia i prin consultarea fiierelor de urmrire (TRACE FILES), ce conin informaii despre fiecare proces de background n parte (DBWR, LGWR, ARCH, PMON, etc). Fiierul de alert i fisierele de urmrire se gsesc n subdirectorul TRACE din directorul %ORACLE_HOME%. (2) Cum determinm ce trebuie s recuperm? Putem detecta fiierele ce vor fi recuperate prin interogarea view-urilor de perfoman sistem V$: V$DATAFILE conine informaii despre fiierele de date. V$LOGFILE, V$LOG conin informaii despre fiierele jurnal online. V$LOG_HISTORY conine informaii despre fiierele jurnal arhiv. V$RECOVER_FILE conine informaii despre fiierele ce necesit recuperare. (3) Performana i succesul planului de arhivare i recuperare depinde de doi factori: timpul necesar realizrii procesului de recuperare (trebuie s fie ct mai mic) i pierderile de date aprute (trebuie s fie minime sau chiar inexistente). Claudiu Ariton este junior Oracle DBA la Advantage Software Factory din Bucureti. Poate fi contactat pe email la: aritonc@hotmail.com. n 84

Bibliografie
Willard Baird, Intermedia communications How to create a complete Backup and Recovery plan Stephen Rea, Oracle Certified Professional in Database Administration Bulletproofing, Backups, and Disaster Recovery Scenarios Oracle8i Backup and Recovery Guide http://technet.oracle.com Advanced Topics of Oracle Backup and Recovery Oracle Corporation Rama Velpuri Oracle Backup & Recovery Handbook, Oracle Press, 1997

23 NET REPORT aprilie 2001