Sunteți pe pagina 1din 3

ATELIER

ORACLE

Strategii de recuperare a bazelor de date Oracle

CCllaauuddiiuu AArriittoonn

P rincipala responsabilitate a administratorului bazei de date este

sã fie pregãtit din timp în cazul apariþiei unei „cãderi” hardware,

software, de reþea, de proces sau de sistem. Dacã un astfel de eºec

afecteazã activitatea unui sistem de gestiune a bazelor de date, este de dorit recuperarea datelor ºi reluarea operaþiilor normale cât mai repede posibil. Procesul de recuperare variazã în funcþie de tipul de eºec care apare, structurile care sunt afectate ºi de tipul de recuperare cerut. Dacã nici un fiºier 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ã paºi adiþionali.

Tipuri de eºec

Eºecul instanþei (DataBase Instance Failure) – apare când un eveniment împiedicã rularea normalã a proceselor de backgound (PMON, SMON, DBWR sau LGWR). Acest tip de eºec poate fi cauzat de o problemã hardware (întreruperea alimentãrii cu energie electricã) sau software (eºecul sistemului de operare sau al altor programe ce lu- creazã cu baza de date). Recuperarea instanþei se realizeazã automat, procedura implicând douã faze: derularea înainte a tranzacþiilor „comise” aplicând fiºierele jurnal online ºi derularea înapoi a tranzac- þiilor „necomise” utilizãnd segmentele de revenire (figura 1). Aceastã procedurã se executã ºi atunci când baza de date este repornitã dupã închiderea ei cu opþiunea ABORT SHUTDOWN ABORT. În cazul utilizãrii OPS (Oracle Parallel Server) o instanþa activã recupereazã automat instanþa cãzutã.

Figura 1 – Recuperarea automatã a instanþei
Figura 1 – Recuperarea automatã a instanþei

Eºecul 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 eºec media includ defectarea discului, blocuri defecte pe disc, fiºiere de date sau de sistem ºterse sau defecte. Recu- perarea media se realizeazã prin restaurarea fiºierelor pierdute sau dete- riorate dintr-un backup recent ºi apoi aplicarea fiºierelor log online sau arhivã pentru readucerea bazei de date într-o stare anterioarã produce- rii eºecului (figura 2).

21

NET REPORT

aprilie 2001

Cum afecteazã eºecul media baza de date? Eºecul media poate afecta un tip sau toate tipurile de fiºiere necesare funcþionãrii normale

a bazei de date Oracle (fiºiere de date, fiºiere jurnal, fiºierul de control). Dacã a fost distrus un disc ce conþine fiºiere jurnal sau fiºierul de control, dar se utilizeazã multiplexarea acestora pe alte discuri, baza de date va funcþiona normal fãrã nici o întrerupere. Dacã însã aceste fiºiere nu au fost multiplexate, funcþionarea bazei de date este întreruptã ºi pot apare pierderi de date. Eºecul media care afecteazã fiºierele de date se divide în douã cate- gorii: eºec de scriere sau eºec de citire. Dacã Oracle descoperã cã nu poa- te citi un fiºier de date, o eroare de sistem este returnatã aplicaþiei in- dicând faptul cã fiºierul respectiv nu poate fi gãsit, nu poate fi deschis sau nu poate fi citit. Baza de date va funcþiona normal, dar aceastã eroare va aparea ori de câte ori se va încerca o nouã citire din fiºierul deterio- rat. Dacã Oracle descoperã cã nu poate scrie într-un fiºier de date, atunci se arhiveazã automat fiºierul jurnal online activ, o eroare este returnatã procesului DBWR ºi se va produce scoatere offline a fiºierului deteriorat. Dacã fiºierul de date în care nu se poate scrie se gãseºte în tabela de spaþiu SYSTEM, fiºierul nu poate fi scos offline. O eroare este returnatã ºi Oracle va opri automat baza de date. Cauza acestei excepþii este cã toate fiºierele de date din tabela de spaþiu SYSTEM trebuie sã fie online pentru ca baza de date sã funcþioneze normal. Tot din acest motiv toate fiºierele de date ce conþin segmente de revenire active trebuie sã fie online.

Tipuri de recuperare media

recuperarea completã când se utilizeazã cel mai recent backup ºi toate fiºierele jurnal

recuperarea incompletã când se utilizeazã cel mai recent backup ºi numai o parte din fiºierele jurnal. Recuperarea incompletã apare în unul din urmãtoarele cazuri:

• eºecul media a distrus o parte din fiºierele jurnal online sau arhivã

Figura 2 – Recuperarea dupã eºec media
Figura 2 – Recuperarea dupã eºec media

• o eroare umanã a cauzat pierderea datelor (ºtergeri de tabele)

• s-a pierdut fiºierul de control online ºi se va utiliza un fiºier de con- trol 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 fãrã a aplica datele din jurnal. Structuri utilizate în recuperarea bazei de date:

• backup-ul bazei de date – utilizat pentru a restaura baza de date

• fiºiere jurnal online – lucreazã împreunã cu procesul de background LGWR ºi înregistreazã toate modificãrile asociate unei instanþe (sunt scrise circular). Aceste tipuri de fiºiere fac parte din procesul de recu- perare numai dacã se restaureazã baza de date dintr-o arhivã „la rece” (cold backup). De fapt, ele nu trebuiesc niciodatã arhivate în cazul arhivãrii „la cald” (hot backup).

• fiºiere jurnal arhivã – copii ale tuturor fiºierelor jurnal online (numai dacã baza de date ruleazã în modul ARCHIVELOG)

• segmentele de revenire – conþin imaginea înainte a unui rând dintr-o tabelã sau a rândurilor modificate din blocul de date (vezi tabelul)

• fiºierul de control – conþine informaþii 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 spaþiu sau a fiºierului de date) se va opta pentru cel mai potrivit nivel, astfel încât, sã se recupereze numai ceea ce este deteriorat sau pierdut. Recuperarea pe cele trei nivele presupune diferite opþiuni la pornirea bazei de date.

Cum lucreazã segmentele de revenire

Tranzacþia Ce conþine segmen- tul de revenire

Comanda ROLLBACK

INSERT

ROWID-ul rândului inserat Citeºte ROWID-ul din segmentul de revenire, gãseºte rândul inserat în tabelã ºi apoi ºterge rândul inserat din tabelã

UPDATE

Toate coloanele modificate ºi ROWID-ul rândului modificat

Citeºte ROWID-ul din segmentul de revenire, gãseºte rândul modificat în tabelã ºi anuleazã modificãrile folosind imaginea coloanele modifi- cate din segmentul de revenire Re-insereazã rândul în tabelã folosind ROWID-ul ºi imaginea tuturor coloanele din segmentul de revenire

DELETE

Toate coloanele ºi ROWID-ul rândului ºters

Pornirea bazei de date se realizeazã în trei paºi:

1. Pornirea instanþei Oracle (STARTUP NOMOUNT) – se citeºte fiºierul

init<SID>.ora care conþine parametrii de iniþializare, se alocã memo- ria pentru zona de SGA ºi se pornesc procesele de background. Toto- datã se deschid ºi fiºierele de urmãrire ºi de alertã care monitorizeazã starea bazei de date – TRACE, ALERT.

2. Montarea bazei de date – se deschide fiºierul de control asociat

bazei de date ºi se citesc starea ºi locaþia fiºierelor de date ºi a fiºierelor jurnal. În aceastã etapã sunt disponibile urmãtoarele operaþii: redenu- mirea fiºierelor de date, activare/dezactivare ARCHIVELOG, recuperarea

bazei de date. Comanda utilizatã pentru montarea bazei de date este

ALTER DATABASE MOUNT dacã instanþa este pornitã sau STARTUP MOUNT

dacã instanþa nu este pornitã.

3. Deschiderea bazei de date - se deschid fiºierele de date ºi

fiºierele jurnal ale bazei de date ºi se verificã consistenþa bazei de date. Comanda utilizatã pentru deschiderea bazei de date este ALTER DATA- BASE 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 fiºierelor externe, faza de derulare înainte (roll-forward) ºi faza de deru- lare înapoi (rollback). Faza de derulare înainte ºi faza de derulare înapoi se desfãºoarã prin aplicarea fiºierelor jurnal arhivã ºi se utilizeazã în

ATELIER

ORACLE

cazul recuperãrii complete. Dacã baza de date nu ruleazã în modul ARCHIVELOG, singurul mod de a recupera baza de date este restaurarea fiºierelor de date, a fiºierului de control ºi a fiºierelor jurnal online din cel mai recent backup. În acest caz avem de a face cu o recuperare in- completã deoarece se produc pierderi de date. Dupã o recuperare in- completã baza de date va fi deschisã cu opþiunea RESETLOGS, care va re- seta numãrul secvenþei jurnal ºi va curãþa fiºierul jurnal online curent. În unele cazuri opþiunea RESETLOGS poate sã modifice conþinutul fiºierului de control ºi header-ul fiºierelor de date pentru a reflecta noua organizare fizicã a bazei de date. Din acest motiv, dupã utilizarea opþi- unii 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

Recuperarea la nivelul bazei de date – se utilizeazã când se recupereazã tabelã de spaþiu SYSTEM, un fiºier de date ce face parte din tabela de spa- þiu SYSTEM sau conþine segmente de revenire active sau când se executã orice tip de recuperare incompletã. Opþiunea UNTIL CANCEL – realizeazã o recuperare incompletã ºi se utilizeazã când un fiºier jurnal arhivã este deteriorat.

1. Restaurarea fiºierelor de date ºi a fiºierelor jurnal arhivã din cel

mai recent backup

2. Montarea bazei de date cu comanda STARTUP MOUNT din SERVER

MANAGER

3. Comanda RECOVER DATABASE UNTIL CANCEL – produce recupera-

rea bazei de date aplicând primul fiºier jurnal din secvenþã ºi oferã posi-

bilitatea anulãrii recuperãrii înainte de a aplica urmãtorul fiºier jurnal.

4. Comanda RECOVER DATABASE CANCEL – produce orpirea proce-

sului de recuperare

5. Deschiderea bazei de date cu comanda ALTER DATABASE OPEN

RESETLOGS

Opþiunea UNTIL TIME – realizeazã o recuperare incompletã, pânã la un moment specificat în timp. De exemplu, un utilizator a ºters, din

greºealã, 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 fiºierelor de date ºi a a fiºierelor jurnal arhivã din cel

mai recent backup

2. Montarea bazei de date cu comanda STARTUP MOUNT din SERVER

MANAGER

3. Comanda RECOVER [AUTOMATIC] DATABASE UNTIL TIME '2001-

03-24 15:59:59' Opþiunea AUTOMATIC

realizeazã recuperarea bazei de date ºi apli-

carea fiºierelor arhivã fãrã intervenþia administratorului bazei de date

DATABASE OPEN

RESETLOGS

Opþiunea UNTIL CHANGE - realizeazã o recuperare incompletã, pânã la un anumit SCN (System Change Number). Oracle asigneazã fiecãrei tranzacþii „comise” un unic SCN. Pentru a vedea SCN-ul tranzacþiilor „comise” se pot utiliza view-urile system v$log_history (pentru fiºierele jurnal arhivã) ºi v$log (pentru fiºierele jurnal online).

4. Deschiderea bazei de date cu comanda ALTER

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 fiºierelor de date ºi a a fiºierelor jurnal arhivã din cel

mai recent backup

2. Montarea bazei de date cu comanda STARTUP MOUNT din SERVER

MANAGER

3. Comanda RECOVER [AUTOMATIC] DATABASE UNTIL CHANGE 10488

(10488 reprezintã SCN-ul tranzacþiei pânã la care se va face recuperarea bazei de date)

4. Deschiderea bazei de date cu comanda ALTER DATABASE OPEN

RESETLOGS

Opþiunea USING BACKUP CONTROLFILE – este necesarã în douã situaþii • fiºierul de control este deteriorat ºi nu a fost multiplexat • fiºierul de control nu mai reflectã structura fizicã curentã a bazei de date Recuperarea la nivelul tabelei de spaþiu – este o recuperare consis- tentã, deoarece se aplicã toate fiºierele arhivã. În acest caz baza de date poate fi deschisã, iar tabela de spaþiu trebuie sã fie offline. Dacã tabela de spaþiu alteratã este tabela SYSTEM sau dacã un fiºier arhivã este dete- riorat atunci singura recuperare posibilã este la nivelul bazei de date.

1. Deschiderea bazei de date cu comanda STARTUP din SERVER

MANAGER

2. Comanda ALTER TABLESPACE nume_tab OFFLINE IMMEDIATE

select * from v$datafile – se observã ca status-ul fiºierelor

tabelei de spaþiu nume_tab este RECOVER – urmeazã sa fie recuperate

3. Restaurarea fiºierelor de date corespunzãtoare tabelei de spaþiu

din cel mai recent back-up

4. Comanda RECOVER [AUTOMATIC] TABLESPACE nume_tab

select * from v$datafile – se observã ca status-ul fiºierelor

tabelei de spaþiu nume_tab este acum OFFLINE – au fost recuperate

5. Comanda ALTER TABLESPACE nume_tab ONLINE

select * from v$datafile – se observã ca status-ul fiºierelor tabelei de spaþiu nume_tab este acum ONLINE – tabela de spaþiu este disponibilã utilizatorilor Tabelele de spaþiu ce conþin segmente temporare, de index sau seg- mente de revenire (numai dacã avem comenzile iniþiale de creare ale acestora) pot fi refãcute prin ºtergerea tabelei de spaþiu cu comanda

DROP TABLESPACE nume_tab, ºtergerea fizicã de pe disc a fiºierelor de date corespunzãtoare acesteia, refacerea tablei de spaþiu ºi a seg- mentelor folosind comenzile iniþiale de creare (CREATE TABLESPACE,

CREATE INDEX, CREATE ROLLBACK).

Recuperarea la nivelul fiºierului de date - este o recuperare con- sistentã, asemãnãtoare recuperãrii la nivelul tabelei de spaþiu. Singura deosebire este cã, doar fiºierul de date deteriorat este „scos” offline ºi nu întreaga tabelã de spaþiu din care face parte. Dacã fiºierul de date apar- þine tabelei de spaþiu 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 fiºierului 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 fiºierelor jurnal online dintr-un grup care nu este activ. Când procesul LGWR va încerca sã scrie în membrii unui grup redo log deteriorat, automat toþi utilizatorii bazei de date vor fi deconec- taþi, primind mesajul de eroare „ORA-01092: ORACLE instance ter- minated. Disconnection forced” Dacã se încearcã o nouã conexiune la baza de date se primeºte mesajul de eroare „ORA-03114: not con- nected 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.

23

NET REPORT

aprilie 2001

2. Interogarea select bytes/1024 from v$log where group# =

3; pentru a vedea mãrimea în K a fiºierelor jurnal pierdute (de ex. 500 K)

3. ªtergerea grupului redo log 3 alter database drop log-

file group 3;

1. Recrearea grupului redo log 3

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

2. Deschiderea bazei de date cu comanda ALTER DATABASE OPEN

Deteriorarea tuturor fiºierelor jurnal online dintr-un grup care este activ În acest caz apare mesajul de eroare „ORA-00257: archiver error. Con- nect internal only, until freed”. Dacã se încearcã recuperarea efectuând paºii descriºi 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; se va scade o se-

cundã din coloana first_time corespunzãtoare 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 determinãm ce eºec a apãrut? Multe din problemele apãrute pot fi rezolvate prin monitorizarea fiºierului de alertã (ALERT LOG), ce conþine informaþii generale despre pornirea, oprirea bazei de date ºi erorile întâlnite pe parcursul funcþionãrii acesteia ºi prin consultarea fiºierelor de urmãrire (TRACE FILES), ce conþin informaþii despre fiecare proces de background în

parte (DBWR, LGWR, ARCH, PMON, etc).

Fiºierul de alertã ºi fisierele de urmãrire se gãsesc în subdirectorul

TRACE din directorul %ORACLE_HOME%.

(2) Cum determinãm ce trebuie sã recuperãm? Putem detecta fiºierele ce vor fi recuperate prin interogarea view-urilor de perfomanþã sistem V$:

V$DATAFILE – conþine informaþii despre fiºierele de date. V$LOGFILE, V$LOG – conþin informaþii despre fiºierele jurnal online. V$LOG_HISTORY – conþine informaþii despre fiºierele jurnal arhivã. V$RECOVER_FILE – conþine informaþii despre fiºierele ce necesitã recuperare. (3) Performanþa ºi succesul planului de arhivare ºi recuperare depinde de doi factori: timpul necesar realizãrii procesului de recuperare (trebuie sã fie cât mai mic) ºi pierderile de date apãrute (trebuie sã fie minime sau chiar inexistente).

Claudiu Ariton este junior Oracle DBA la Advantage Software Factory din Bucureºti. 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