2.5.

Oporavak baze podataka

(RECOVERY)
Oporavak baze podataka je vraanje baze podataka u stanje za koje se zna da je korektno, posle nekog softverskog ili hardverskog otkaza sistema. Postoje mnogi razliiti uzroci otkaza sistema, od greke u programiranju, preko greki u operativnom sistemu i samom SUBP-u, padanja glava diska, nestanka napajanja, do sabotae.

Osnovni princip oporavka baze podataka je redundansa (ponavljanje) podataka. Postoje mnogi naini redundantnog pamenja podataka za potrebe oporavka baze podataka. Tehnike redundantnog pamenja podataka i oporavka baze su veoma kompleksne. Jednostavne procedure koje bi se bazirale samo na, na primer, periodinom kopiranju baze podataka u neku arhivsku memoriju i svih transakcija koje su se u meuvremenu desile ili jednostavno dupliciranje baze podataka, imaju mnogo nedostataka.

Da bi se objasnili osnovni koncepti, proces oporavka baze podataka uproeno emo opisati na sledei nain: 1. Periodino se (jednom dnevno, na primer) cela baza podataka kopira na neku arhivsku memoriju (drugi disk, traku, CD, DVD). 2. Za svaku promenu u bazi, u tzv. log (ili urnal) zapisuje se stara i nova vrednost rekorda baze podataka. 3. Posle otkaza sistema: (a) Ako je sama baza podataka oteena, ona se rekonstruie (oporavlja) na osnovu svoje poslednje arhivske kopije koristei log za ponovno izvrenje svih promena koje su izvrene od trenutka uzimanja arhivske kopije, do trenutka otkaza. (b) Sama baza podataka nije oteena, ve je samo dovedena u neko nekonzistentno stanje. Tada se, pomou loga, ponite sve nekorektne promene (undo), a same transakcije koje su ih proizvele, ponove.

Transakcije. Osnovni cilj baze podataka je da omogui efikasnu obradu transakcija. Transakcija je jedno izvrenje neke "logike jedinice rada" korisnika baze podataka, jedno izvrenje neke logike celine jednog programa, ili jedno izvrenje celog programa. Vie izvrenja jednog istog programa mogu se u sistemu odvijati konkurentno, svako od njih predstavlja transakciju.

Skup aktivnosti nad bazom podataka koje se izvravaju po principu "sve ili nita" - ili su sve uspeno obavljene ili je baza podataka ostala nepromenjena, je atomski skup aktivnosti. Oigledno je da "logika jedinica rada" mora predstavljati atomski skup aktivnosti, "atomsku transakciju"

Imajui u vidu ovakvu definiciju transakcije, moe se takoe rei da ona predstavlja izvrenje jednog skupa operacija nekog programa, koji (skup) poinje sa specijalnom operacijom BEGIN TRANSACTION, a zavrava se bilo sa operacijom COMMIT (ako je ceo skup operacija uspeno izvren)

ili sa ROLLBACK tako ceo skup operacija nije uspeno zavren).

Jedan program moe predstavljati sekvencu transakcija, mada u praksi, esto, jedan program predstavlja jednu transakciju.

Transakcije ne mogu biti "ugnjedene", odnosno u jednom programu operacija BEGIN TRANSACTION moe se izvriti (zadati) samo ako taj program nema ni jednu drugu transakciju u izvrenju, odnosno naredbe COMMIT i ROLLBACK se mogu izvriti samo ako je neka transakcija u izvrenju.

U izvrenju transakcije nije samo problem ouvanje integriteta baze podataka nego i neke poruke korisniku baze, odnosno tzv. "stvarni izlazi" mogu postati nekorektni. Na primer, vlasnik rauna u banci komunicira sa svojim zapisom u bazi podataka preko terminala za izdavanje novca. U tom sluaju transakcija mora da bude atomska i u sledeem smislu: ili je plaanje izvreno i auriranje odgovarajueg zapisa uinjeno ili ni jedno ni drugo.

Upravljanje porukama emo ilustrovati na sledeem primeru (program za prebacivanje novca sa rauna na raun).

Program je napisan u jednoj vrsti pseudokoda, koji se lako prilagoava bilo kom SUBP i bilo kom jeziku domainu.

PRENOS: PROC; GET(RA1, RA2, IZNOS); /*ulazna poruka*"/ FIND UNIQUE (BROJRA WHERE BROJRA = RA1); STANJE= (STANJE - IZNOS); IF STANJE < 0 THEN PUT ('NEMA DOSTA LOVE'); /*izlazna poruka*/ ROLLBACK; ELSE

FIND UNIQUE (BROJRA WHERE BROJRA = RA2); ASSIGN (STANJE + IZNOS) TO STANJE; PUT ('LOVA PRENEENA'); /*izlazna poruka*/ COMMIT; END IF END: /*PRENOS*/

Oigledno je da se izlazne poruke ne smeju prenositi direktno, ve tek nakon planiranog zavretka transakcije (sa COMMIT ili ROLLBACK). Postupak upravljanja porukama u oporavku baze podataka je sledei: Poruke se ne prihvataju direktno ve se ulazne poruke stavljaju u tzv. ulazni red, a izlazne poruke u izlazni red. Operacija GET uzima ulaznu poruku iz ulaznog reda, a operacija PUT stavlja izlaznu poruku u izlazni red. Pri neplaniranom ROLLBACK (koji se izvrava automatski ako doe do neke greke u programu tipa "overflow", deljenje sa nulom i slino), prouzrokuje izbacivanje izlaznih poruka iz izlaznog reda.

2.5.1. Vrste otkaza (1) Naruavanje integriteta u nekoj transakciji koje program sam otkriva, odnosno planirani ROLLBACK (na primer 'NEMA DOSTA LOVE'). (2) Lokalna greka u nekoj transakciji koja nije eksplicitno planirana u programu (na primer aritmetiki overflow). (3) Sistemski otkaz koji utie na sve transakcije u obradi, ali ne oteuje bazu podataka (na primer nestanak napajanja). (4) Fiziko oteenje baze podataka.

Lokalni otkazi (otkazi u transakciji) Za neplanirani zavretak transakcije (zavretak koji nije na naredbi COMMIT ili eksplicitnom ROLLBACK) neophodno je da se automatski izvri rollback. Rollback proceduru obavlja Recovery Manager, ponitavajui sve promene unazad kroz log, dok se ne dostigne u logu rekord koji oznaava poetak transakcije. Za vreme ovog procesa ponitavanja, takoe je mogue da doe do otkaza. U tom sluaju se rollback procedura mora startovati ponovo i ona zbog toga treba da ima osobinu idempotencije (UNDO(UNDO ... (UNDO(X) = UNDO(X)). Oigledno je, da zbog rollback procedura transakcije treba da budu to krae.

Sistemski otkazi bez oteenja baze podataka Sistemski otkaz prouzrokuje prestanak rada celog sistema i njegovo ponovno pokretanje. Oigledno je da bi se oporavak baze podataka u tom sluaju mogao da izvri pretraivanjem celog loga i identifikovanjem tansakcija koje su otpoele, a nisu zavrene i njihovim ponovnim izvrenjem. Da se ne bi pretraivao ceo log uvode se tzv. checkpoints (take ispitivanja).

"Check point record" sadri listu svih transakcija koje su aktivne u trenutku uzimanja "checkpoint" i za svaku transakciju adresu rekorda u logu kojem je poslednjem pristupljeno.

tc

tf

vrijeme

T1 T2 T3 T4

T5 checkpoint otkaz

Oigledno je da transakcije T3 i T5 moraju biti ponitene (undone), a transakcije T2 i T4 ponovljene (redone), jer nije garantovano da nisu njihovi efekti registrovani u bazi podataka (moda su jo uvek u baferu). Transakcija T1 je obavljena u potpunosti pre uzimanja "checkpoint" i ne ulazi u "checkpoint record".

Formiraju se dve liste - "undo-lista" u kojoj su sve transakcije koje su zapisane u "checkpoint record-u" i "redo-lista" koja je u poetku prazna. Pretraivanje po logu poinje od "checkpoint record-a" i: svaka transakcija za koju se pronae BEGIN TRANSACTION, stavlja se u "undo-listu" i svaka transakcija za koju se pronae COMMIT stavlja se u"redo-listu". Zatim, Recovery Manager, unazad, izvrava "undo" transakcija, a onda unapred "redo" odgovarajuih transakcija.

Dvofazni COMMIT (TWO-PHASE COMMIT) protokol Nain izvravanja COMMIT operacije, da se prvo promene upiu na log, a tek potom u samu bazu podataka (log write-ahead) se komplikuje u sluajevima kada ceo sistem koristi ne samo DBMS nego i neke druge resurse (na primer dva DMBS-a ili u distribuiranim sistemima). Ako svaki resurs ima svoj nezavisni mehanizam oporavka, postavlja se pitanje kako se izvrava COMMIT operacija, jer obavljanje ove operacije na jednom resursu ne znai da e se ona uspeno obaviti i na drugom, to moe da narui integritet baze podataka. U ovakvim sluajevima se uvodi nova sistemska komponenta koja se naziva koordinator.

2.6. Konkurentna (uporedna) obrada transakcija Transakcija se u sistemima zasnovanim na bazi podataka ne obavlja u izolaciji, ve konkurentno (uporedno) sa drugim transakcijama u sistemu (vie transakcija mogu istovremeno zahtevati iste resurse, isti rekord baze podataka). Nekontrolisana meusobna interferencija transakcija moe da dovede bazu u nekonzistentno stanje.

Posmatrajmo izvrenje sledee dve transakcije

Serijsko izvrenje transakcija je izrenje u kome se transakcije ne prepliu, ve se prvo potpuno izvri jedna, pa onda druga transakcija (A pa B, ili P pa A). Rezultat serijskog izvrenja transakcija T1, T2, ..., Tn u bilo kom redosledu emo smatrati korektnim. Ako je vrednost R.F bila 1 tada: (a) Serijsko A,B proizvodi novu vrednost R.F = 4. (b) Serijsko B,A proizvodi novu vrednost R.F = 3. (c) Uporedno izvrenje, prikazano na gornjoj slici proizvodi novu netanu vrednost R.F = 2, netanu zbog toga to nije jednaka vrednosti koju proizvodi neko serijsko izvrenje transakcija.

Da bi se spreilo ovakvo dinamiko naruavanje integriteta baze podataka moe se postupiti na jedan od sledea tri naina: (a) Zabranjuje se izvrenje naredbe NAI R u transakciji B zato to je transakcija A ve adresirala taj rekord (eksluzivno zakljuavanje - eksluzivni lokot E-lokot). (b) Zabranjuje se izvrenje naredbe AUR R u transakciji A zato to je transakcija B ve adresirala ("videla") rekord R (deljivi lokot - shared locks). (c) Zabranjuje se transakciji B u trenutku t4 da aurira rekord R zato to ga je "mlaa" transakcija A ve aurirala (Vremensko oznaavanje transakcija timestamping. Transakcija A je "mlaa" je otpoela prva i dobila je manju vremensku oznaku)

Ekskluzivni lokoti (E-lokot) Neka transakcija T moe da zakljua (da dobije lokot) rekord R prenosei takav zahtev na komponentu sistema koja se naziva Lock Manager. Lokot sadri, izmeu ostalog, identifikaciju rekorda R i identifikaciju transakcije A. Ako transakcija A postavi eksluzivni lokot na neki objekt BP, tada ni jedna druga transakcija ne moe postaviti lokot na isti objekt, dok ga transakcija A ne oslobodi.

PX protokol. Bilo koja transakcija koja eli da aurira neki rekord BP mora prvo izvriti ENAI operaciju kojom se adresira i zakljuava dati rekord. Ako se zakljuavanje ne moe da izvri, transakcija prelazi u stanje ekanja, dok se odgovarajui zapis ne oslobodi, kada se procesiranje nastavlja.

Da bi se izbegla situacija da neka transakcija eka zauvek, zbog toga to druge preuzimaju lokot na odgovarajuem objektu ("ivi lokot") uvodi se neki redosled zakljuavanja objekta (na primer FIFO).

Serijabilnost ili linearnost izvoenja skupa transakcija Uporedno izvravanje skupa transakcija je serijabilno (linearno) ako proizvodi isti rezultat kao i neko serijsko izvrenje istog skupa transakcija. Usvaja se da je skup uporednih transakcija izvren korektno, ako i samo ako je taj skup serijabilan. Mrtvi lokoti ("samrtniki zagrljaj"). Mrtvi lokot je ilustrovan sledeim nainom izvrenja dve transakcije:

Problemi "mrtvih lokota" se reavaju bilo nametanjem protokola obrade transakcija koji treba da spree da do njih doe, ili se dozvoljava da do njih doe, pa se tada neka od transakcija koja ga je izazvala "ubije", njeni efekti na bazu podataka ponite, a ona sama ponovo startuje, nadajui se da tada nee ponovo izazvati mrtvi lokot.

Ispitivanje mrtvih lokota se moe vriti bilo svaki put kada neka transakcija prelazi u stanje "ekaj", bilo periodino, ili se moe smatrati da je mrtvi lokot nastao ako transakcija nita nije uradila u nekom periodu vremena. Kriterijumi za izbor "rtve" mogu biti razliiti, na primer, transakcija koja je poslednja startovala ili transakcija koja zahteva najmanje lokota. "Ubijanje" transakcije i ponitavanje njenih efekata (ROLLBACK) oslobaa i sve lokote koje je ona postavila.

Mogunost da se transakcija poniti (ROLLBACK) pre njenog uspenog zavretka, moe da dovede do sledeeg problema:

Oigledno je da transakcija B radi na ponitenoj promeni rekorda R, na "prljavim" podacima. Jo je gori sluaj ako bi transakcija B zahtevala ekskluzivni lokot na R (ENAI R), pa ga zatim aurirala (AUR R), jer bi se time "prljavi" podatak trajno uneo u bazu podataka.

Dvofazno zakljuavanje (2PL) Protokoli PSC i PUC koji dozvoljavaju oslobaanje deljivih lokota i lokota auriranja pre zavretka transakcije ne garantuju serijabilnost transakcija. Zbog toga se definie Dvofazni protokol zakljuavanja (2PL) koji garantuje serijabilnost. Dvofazni protokol zakljuavanja. Pre bilo koje operacije nad nekim objektom transakcija zahteva lokot nad tim objektom. Posle oslobaanja nekog lokota transakcija vie ne zahteva nijedan lokot.

Posmatrajmo dve transakcije: (A) H := F + 1; (B) F := H + 1; Neka je u poetku H = 0 i F = 0. Serijsko izvrenje "A pa B" e rezultovati u H = 1, F = 2, a serijsko izvrenje "B pa A" u H = 2, F = 1. Uporedno izvravanje ovih transakcija, na nain koji je prikazan na sledeoj slici, koji ne potuje dvofazni protokol e dati nekorektan rezultat F = 1 i H = 1, ime se pokazuje da takvo izvrenje nije serijabilno.

IZBEGAVANJE MRTVIH LOKOTA Kao to je reeno DBMS mogu bilo dozvoljavati mrtve lokote, pa ih zatim razreavati, ili ih pomou razliitih tehnika obrade transakcija mogu izbegavati. U centralizovanim sistemima tehnike izbegavanja mrtvih lokota su skuplje nego tehnike njihovog razreavanja, za razliku od distribuiranih sistema.

Planiranje transakcija (Transaction Scheduling). Transakcije se planiraju tako da one transakcije koje zahtevaju iste podatke se ne izvravaju paralelno. To zahteva da se podaci kojima transakcije pristupaju znaju unapred, to se moe ostvariti bilo eksplicitnim navoenjem, bilo analizom programa za vreme prevoenja. Meutim, oigledno je nemogue precizno definisati zahteve transakcija za podacima pre izvrenja programa, pa se zbog toga "rezerviu" vei skupovi podataka nego to je neophodno i time smanjuje paralelizam obrade.

INTEGRITET BAZE PODATAKA Termin integritet baze podataka koristi se da oznai tanost, korektnost ili konzistentnost, odnosno da oznai problem zatite baze podataka od pogrenog auriranja (pogrenih ulaznih podataka, greki operatera i programera, sistemskih otkaza). Zatita baze podataka obino se tretira sa dva aspekta: (1)integritet - zatita od sluajnog pogrenog auriranja i (2) sigurnost - zatita od neovlaenog auriranja i korienja podataka.

2.9. Kriterijumi za ocenu relacionih SUBP-a Kriterijume koji neki sistem treba da zadovolji da bi se mogao zvati relacionim: 1. Struktura baze podataka se na logikom nivou predstavlja samo tabelama. 2. Svaki podatak u relacionoj bazi podataka dostupan je preko kombinacije imena tabele (relacije), vrednosti primarnog kljua i imena kolone (atributa). (Bez unapred zadatih pristupnih puteva i bez rekurzije ili iteracije).

3. Specifian indikator (razliit od "blanka", "praznog" niza karaktera, nule ili bilo kog broja) koristi se za predstavljanje nula vrednosti, bez obzira na tip podatka. Sistem takoe podrava i sve operacije sa nula vrednostima bez obzira na tip podataka.

4. Sistem poseduje katalog (renik) podataka koji se logiki predstavlja na isti nain kao i sama baza podataka, tako da korisnik moe da koristi isti jezik da bi pristupio ovim meta podacima.

5. Bez obzira koliko jezika i naina korienja terminala sistem podrava, mora posedovati barem jedan jezik ije se naredbe mogu izraziti kao niz karaktera sa dobro definisanom sintaksom i koji podrava: (1) definiciju podataka, (2) definiciju pogleda, (3) manipulaciju podatka, interaktivno i kroz programe, (4) definiciju pravila integriteta, (5) autorizaciju (sigurnost), (6) granice transakcija (BEGIN, COMMIT, ROLLBACK).

6. Sistem poseduje efikasan algoritam pomou koga moe da odredi, za svaki definisani pogled, u trenutku njegovog definisanja, da li se i koje operacije odravanja mogu da primene na taj pogled. Rezultat ovoga algoritma se smeta u katalog baze podataka. 7. I nad baznim relacijama i nad pogledima mogu se izvravati ne samo operacije pretraivanja, ve i operacije odravanja BP. 8. Aplikacioni program i interaktivna komunikacija ostaju neizmenjeni kada se promeni fizika organizacija baze ili fiziki metod pristupa.

9. Aplikacioni program i interaktivna komunikacija ostaju nepromenjene kada se bilo koje promene, koje ne menjaju odgovarajui sadraj tabele, unesu u baznu tabelu. 10. Pravila integriteta se definiu u okviru definicije baze podataka i uvaju se u katalogu. (Ne implementiraju se kroz aplikacione programe).

11. Sve navedene karakteristike su nezavisne od distribucije baze podataka. 12. Ako relacioni sistem poseduje ili moe da radi sa nekim jezikom tree generacije u kome se obrauje jedna n-torka u jednom trenutku vremena, kroz taj jezik se ne mogu zaobii pravila integriteta zadana preko samog relacionog jezika.