ProgramiranjeI_sylabus.

doc

Fakultet informacijskih tehnologija emina@fit.ba

Datum:25.04.2011.

Rekonstrukcija baze podataka nakon greke

Raunarski sistemi su podloni grekama. Najea posljedica greke je gubitak informacija. Sastavni dio sistema za upravljanje bazama podataka je manager recovery, koji je odgovoran za oporavak baze podataka nakon greke i povratak u konzistentno stanje (stanje u kojem se baza podataka nalazila prije greke). Svaki administrator mora imati plan za odravanje backup-a baze podataka i za oporavak baze podataka nakon greke.

Klasifikacija greaka
Razliite greke prouzrokuju razliite posljedice i tretiraju se na razliite naine. Najlaki oblik greke je onaj pri kojem ne dolazi do gubitka informacija, dok kod teeg oblika greaka dolazi do gubitka informacija iz bilo kojeg oblika memorije. Da bi smo znali primijeniti odgovarajui algoritma oporavka baze podataka nakon greke moramo poznavati: - tip ureaja na kojem su podaci pohranjeni, - tip greke i odrediti na koji nain ova greka utjee na sadraj baze podataka te - dizajnirati algoritme koji omoguavaju oporavak (recovery) baze podatka. Openito, algoritmi za oporavak baze podataka nakon greke odvijaju se u slijedea dva koraka: 1. U toku normalnog izvrenja transakcije pohranjuju se informacije o operacijama. Ove informacije treba da budu dovoljne za rekonstrukciju baze podataka nakon greke i obino se pohranjuju u log file-ovima (urnalima). 2. U sluaju greke, na osnovu informacija iz log filr-a, radi se oporavak (recovery) baze podataka operacijama REDO (ponovo izvriti transakciju) ili UNDO (ponititi transakciju). Greke klasificiramo na sljedei nain, ovisno o uzroku i posljedicama: 1. Logike greke su interne logike greke transakcije pri kojima dolazi do prekida transakcije ili pogrenog rada same transakcije. Mogui uzroci su: nevaljani ulazni podaci, nedovoljni resursi itd. 2. Sistemske greke se deavaju kada sistem ue u nepoeljno stanje (greka u DBMS-u ili operativnom sistemu). 3. Pad sistema je greka pri kojoj dolazi do gubitka informacija iz primarne memorije. 4. Hardverska greka pri kojoj gubimo informacije pohranjene u sekundarnoj memorije (na primjer kvar diska ili ak fiziko unitenje cijelog raunara). Jedino mogue rjeenje je odravati sigurnosne kopije baze podataka. Od savremenog DBMS-a oekuje se da u svim ovim sluajevima omogui oporavak baze podataka, dakle njen povratak u to aurnije i konzistentno stanje. Opravak baze podataka nakon greke bi se trebao, po mogunosti, automatski izvravati, ili bar na relativno jednostavan nain. Da bi oporavak bio mogu, DBMS osim same baze podataka mora odravati jo i neka pomona sredstva; tipino to su: rezervna kopija baze (backup copy) i urnal datoteka (journal file, log file). Rezervna kopija i urnal datoteka omoguuju razliite tipove oporavka. Dva najvanija oblika su: neutralizacija
Upravljanje bazama podataka::Predavanja http://dl.fit.ba/

ProgramiranjeI_sylabus.doc

Fakultet informacijskih tehnologija emina@fit.ba

prekinute ili pogrene transakcije, te ponovno uspostavljanje baze nakon njenog znatnijeg oteenja.

Rezervna kopija baze

Rezervna kopija baze podataka pohranjuje cijelu bazu podataka na drugi medij (drugi disk), i to u trenutku kad smatramo da se baza podataka nalazi u konzistentnom stanju. Za vrijeme kopiranja baze podataka nijedna transakcija koja mijenja podatke ne smije biti u aktivnom stanju. Stvaranje rezervne kopije je dugotrajna operacija koja ometa uobiajeni rad korisnika. Zbog toga se kopiranje ne obavlja suvie esto, ve povremeno u unaprijed predvienim terminima (na primjer jednom sedmino).

Neutralizacija jedne transakcije

Neutralizacija transakcije je rutinska operaciji i vrlo esto se izvrava, odnosno obino DBMS obavlja ovu operaciju automatski. Primjenjuje se za neutralizaciju transakcije koja je poela pisati u bazu podataka i nije izvrena do kraja, nije potvrena. Isti postupak mogao bi se primijeniti za neutralizaciju ve zavrene transakcije za koju se ustanovilo da je pogrena. Svodi se na to da se podacima koje je transakcija mijenjala vrate prethodne vrijednosti, vrijednosti koje su imali prije ulaska transakcije koja se neutralizira u aktivno stanje. Uobiajeni postupak naziva se odmotavanje unatrag (roll-back): ita se log file i pronalaze se stare vrijednosti (pre-images) podataka koje je transakcija mijenjala; te stare vrijednosti se ponovo upisuju na odgovarajua mjesta u bazu podataka. Osim toga, ako je neka druga transakcija proitala vrijednost koju je unijela upravo neutralizirana transakcija, tada treba i tu drugu transakciju neutralizirati (i ponovo izvriti). Detalji cijelog postupka mogu biti dosta komplicirani i oni ovise o tome kako se obavlja koordinacija paralelnog rada vie transakcija. Stvari se bitno pojednostavnjuju ukoliko zamislimo da DBMS odjednom obavlja samo jednu transakciju. U tom sluaju se neutralizacija prekinute transakcije elegantno rjeava tzv. tehnikom odgoenog pisanja (deferred write). Ta tehnika zahtijeva da se promjene podataka (nastale kao rezultat rada transakcije) ne upisuju u bazu podataka odmah, nego tek nakon to transakcija unese u log file registar potvrde (commit). Znai, rad transakcije se odvija u dvije faze: transakcija upisuje u log file sve promjene koje bi trebala napraviti u bazi podataka i nakon toga upisuje registar commit; im je upisan registar commit, DBMS prenosi odjednom sve promjene iz log file-a u bazu podataka. Uz primjenu ove tehnike, problem neutralizacije prekinute transakcije postaje trivijalan. Naime prekinuta transakcija ne uspijeva u log file upisati registar commit, pa stoga DBMS ne prenosi njene promjene u bazu.

promjene

TRANSAKCIJA

LOG FILE

commit

BAZA

2
Upravljanje bazama podataka::Predavanja http://dl.fit.ba/

ProgramiranjeI_sylabus.doc

Fakultet informacijskih tehnologija emina@fit.ba

Operacije pohranjivanja podataka

Baza podataka obino je pohranjena u sekundarnoj (permanentnoj) memoriji. Baza podatak je podijeljena na blokove podataka. Blokovi podataka su osnovne jedinice alokacije memorije i prenosa podataka. Blokove pohranjene u sekundarnoj memoriji nazivamo fiziki blokovi, dok blokove pohranjene u primarnoj memoriji nazivamo buffer blokovima. Prenos podataka izmeu diska i primarne memorije vri DBMS. Operacija Input(x) prenosi blok podataka u kojem je pohranjena informacija x sa diska u primarnu memoriju. Operacija Output(x) prenosi buffer blok u kojem se nalazi informacija x iz primarne memorije na disk. U odreenim uvjetima ove operacije moe realizirati operativni sistem koji se nalazi ispod DBMS-a. Operacije koje koristi transakcija za itanje ili pisanje su read(x,xi) i write(x,xi). - operacija read(x,xi) se sastoji iz dva dijela: o ako x nije u primarnoj memoriji, DBMS vri input(x) o dodjeljuje se vrijednost x varijabli xi - operacija write(x,xi) takoer se sastoji iz dva dijela: o ako x nije u primarnoj memoriji DBMS vri input(x) o dodjeljuje se vrijednost xi varijabli x

Procesiranje transakcija
Transakcija je skup operacija koje ine jednu logiku cjelinu rada ili jedinica izvrnog programa koji pristupa i aktualizira podatke baze podataka. Zahtijevamo da transakcije ne ugroze konzistentnost baze podataka. Ponekad je potrebno dozvoliti privremene nekonzistentnosti, to moe prouzrokovati probleme u sluaju greke. Primjer privremene nekonzistentnosti: Transakcija prenosi 500 KM sa rauna A na raun B. Aktualno stanje rauna A je 10000 KM i rauna B je 20000 KM.

Memorija

Disk

A=10 000
T1: read(A,a1) a1:= a1-500 write(A, a1) read(B, b1) b1:= b1+500 write(B, b1) Suma A+B mora biti konstantna.

A= 9 500 B=20 000 B=20 500

output(A) input(B) output(B)

A=10 000 A=9 500 Privremena B=20 000 nekonzistentnost B=20500

Slika 1: Privremena nekonzistentnost

3
Upravljanje bazama podataka::Predavanja http://dl.fit.ba/

ProgramiranjeI_sylabus.doc

Fakultet informacijskih tehnologija emina@fit.ba

Ispravno izvrena transakcija odrava konzistentnost baze podataka. Ispravnost transakcije je odgovornost programera. Atominost je osobina transakcije, sve operacije koje ine jednu transakciju se adekvatno izvre ili se ne izvri nijedna. Odravanje atominosti je odgovornost DBMS-a (manager transakcija). Ukoliko se desi graka u sistemu u toku izvrenja transakcije, transakcija se mora prekinuti. Prekinuta transakcija ne smije prihvatiti stanje u koje je dovela bazu podataka, ve se vraa u stanje u kojem se nalazila prije poetka izvrenja transakcije. Oporavak baze podataka predstavlja ponitenje efekata prekinute transakcije transakcije. Uspjeno zavrena transakcija (commit) se moe ponititi samo inverznom transakcijom. Za kreiranje inverzne transakcije zadueni su korisnici. Parcijalno potvrena

Potvrena

Aktivna

Neuspjela

Prekinuta

Slika 1: Dijagram stanja transakcija Iz prekinutog stanja transakcija se ponovo izvrava ukoliko se radi o hardverskoj ili softverskoj greci, a ponitava se ukoliko se radi o greci uzrokovanoj internom logikom transakcije.

Ponovno uspostavljanje baze podataka

Ponovno uspostavljanje baze podataka (recovery) je opsena operacija koja se pokree na zahtjev administratora. Primjenjuje se nakon znatnijeg oteenja baze podataka ili u sluaju njenog potpunog unitenja. Podrazumijeva ponovni upis svih podataka. Cilj ponovnog uspostavljanja baze podataka je zatititi podatke od logikih i fizikih greaka koje uzrokuju gubitak podataka na primarnoj ili sekundarnoj memoriji. Da bi se osiguralo konzistentno stanje baze podataka definirane su transakcije kao izvrne jedinice nad bazom podataka. Transakcije se uspjeno zavre ili ne uspiju, to zahtjeva povratak baze podatak u stanje prije poetka izvrenja transakcije. Uobiajeni postupak naziva se odmotavanje prema naprijed (roll-forward). U log-file-u moraju biti upisane posebne kontrolne take koje oznaavaju trenutke kad je baza podataka bila konzistentna (obino su to trenutci kad nije bilo aktivnih transakcija). Postupak je tada sljedei: uspostavlja se stanje baze pohranjeno zadnjom sigurnosnom kopijom; odredi se zadnja (posebna) kontrolna toka u log-file-u; proita se dio log-file-a od poetka do zadnje kontrolne toke; ponovo se unose u bazu promjene podataka (post-images), i to redom za svaku potvrenu transakciju iz posmatranog dijela urnala. Nakon ovoga, uspostavit e se stanje baze koje odgovara zadnjoj (posebnoj) kontrolnoj taki. To je najbolje to moemo uiniti. Manager transakcija je zaduen za odravanje nedjeljivosti transakcija i operacije COMMIT i ROLLBACK su osnova njegove funkcije.
Upravljanje bazama podataka::Predavanja http://dl.fit.ba/

ProgramiranjeI_sylabus.doc

Fakultet informacijskih tehnologija emina@fit.ba

Operacija COMMIT predstavlja uspjean zavretak transakcije i sve izmjene koje je napravila se mogu uiniti stalnim. Takoer garantiramo da se baza podataka ponovo nalazi u konzistentnom stanju. Operacija ROLLBACK predstavlja neuspjean zavretak transakcije sve izmjene koje je napravila neuspjela transakcija se moraju ponititi. Ukoliko se transakcija nalazi u parcijalno potvrenom stanju (sadraj primarne i sekundarne memorije su nesuglasni) i dogodi se greka, pri ponovnom pokretanju sistema, baza podataka e biti u nekonzistentnom stanju. Ukoliko ponovo izvrimo transakciju, ulazni podaci su neispravni i nemamo dovoljno informacija za rekonstrukciju baze podataka u konzistentno stanje, te e konano stanje baze podataka ponovo biti nekonzistentno.

urnal datoteka (log file)

Kao to postoje file-ovi koji pohranjuju podatke baze podataka, takoer postoje file-ovi koji pohranjuju informacije o transakcijama. Za rekonstrukciju baze podataka potrebno je pohraniti u sekundarnoj memoriji opis izmjena koje e biti izvrene. Za pohranjivanje opisa izmjena koriste se log file-ovi (urnali) i strukture koje pohranjuju opise izmjena. urnal file je datoteka koja biljei istoriju svake transakcije koja je mijenjala bazu podataka nakon stvaranja zadnje rezervne kopije. Za jednu transakciju urnal evidentira: 1. identifikator transakcije (LSN-log sequence number), 2. adresu svakog podatka kojeg je transakcija promijenila, 3. prethodnu vrijednost tog podatka (pre-image ili BEFORE IMAGE) 4. novom vrijednost podatka (post-image ili AFTER IMAGE) 5. kontrolne take (checkpoints) u napredovanju transakcije: taka poetka, taka potvrivanja (commit) ili odustajanja (rollback). Svaki put kad se izvri operacija write, upie se jedan registar tipa <T, PODATAK, PRE, POST> u log file. Za svaku transakciju se pohranjuju i slijedea dva registra (kontrolne take): - <NAZIV TRANSAKCIJE, START> kada transakcija ue u aktivno stanje i - <NAZIV TRANSAKCIJE, COMMIT> ili <NAZIV TRANSAKCIJE, ROLLBACK> kada transakcija pree u parcijalno potvreno stanje ili se prekine njeno izvravanje. Primjer: <T1, start> <T1, A, 10 000, 9 500> <T1, B, 20 000, 20 500> <T1, commit> Za rekonstrukciju baze podataka moemo koristiti slijedee algoritme: - REDO(naziv transakcije) ponavlja izvrenje transakcija (roll forward) i - UNDO(naziv transakcije) ponitava promjene koje je izvrila transakcija (roll back). Algoritam REDO se izvrava kada za transakciju postoji registar start i registar commit, dok se UNDO izvrava kada za jednu transakciju postoji registar start u log file-u, a ne postoji registar commit. Primjer:

<T1, <T1, <T1, <T1,

start> <T2, start> A, 10 000, 9 500> <T2, C, 500, 600> B, 20 000, 20 500> <T2, D, 300, 200> REDO Upravljanje bazama podataka::Predavanja commit> http://dl.fit.ba/

5
UNDO

ProgramiranjeI_sylabus.doc

Fakultet informacijskih tehnologija emina@fit.ba

U SQL serveru imamo tri naina oporavka baze podataka: full (mogunost rekonstrukcije baze podataka do momenta greke ili do traenog momenta), simple (moemo rekonstruirati bazu podatka samo do momenta posljednjeg backupa) i bulk-logged (sve operacije mogu biti ponovljene) slika 3. U kompletnom modu (full) svaka transakcija nad bazom podataka (insert, update, delete) je registrirana u log file-u i mogu se rekonstruirati sve promjene nad bazom podataka u toku njenog postojanja. Koritenje ovog moda podrazumijeva da log file neogranieno raste i moe postati vei od same baze podataka.

Slika 3: Recovery modeli

6
Upravljanje bazama podataka::Predavanja http://dl.fit.ba/

ProgramiranjeI_sylabus.doc

Fakultet informacijskih tehnologija emina@fit.ba

Slika 4: Modeli recovery-a iz SQL Query Analyzer-a

Rjeenje problema nekontrolirane veliine log file-a je praviti sigurnosne kopije. Kada napravimo sigurnosnu kopiju, registri pohranjeni u log file-u se briu sa diska i ostavlja se slobodan prostor za registriranje novih transakcija. Pri kreiranju sigurnosne kopije ostavljamo slobodan prostor u log file-u, ali se ne smanjuje veliina log file-a (log file i dalje zauzima isti prostor na disku).

Checkpoints (kontrolne take) log file-a

Proces pretrage (start i commit registara) log file-a oduzima vrijeme. Takoer veina transakcija koje se moraju ponovo izvriti, ve su aktualizirale svoje registre. Da bi se uklonili ovi nedostaci uvede se checkpoins u 3 etape: 1. pohraniti u sekundarnoj memoriji log registre koji se nalaze u buffer-u, 2. pohraniti u sekundarnu memoriju sve podatke koji se nalaze u buffer-u, 3. upisati u log file u sekundarnoj memoriji <checkpoint>. Svaki checkpoint vri flushing drty blokova iz buffera na disk. Za rekonstrukciju baze podataka potrebno je itati log file od kraja dok ne naemo prvi checkpoint i od tog momenta ponitimo ili ponovo izvrimo odgovarajue transakcije. Znai, checkpoint minimizira dio log file-a koji mora biti procesuiran pri recovering-u. Uvoenje koncepta checkpointa rekonstrukcija baze podataka postaje efikasnija.

7
Upravljanje bazama podataka::Predavanja http://dl.fit.ba/

ProgramiranjeI_sylabus.doc

Fakultet informacijskih tehnologija emina@fit.ba

Primjer: <T1, start> <T1, A, 100, 50> <T1, B, 500, 600> <T1, commit> <T2, start> <T2, C, 300, 200> <T2, commit> <checkpoint> <T3, start> <T3, D, 300, 100> greka <checkpoint> Greka

UNDO T3

nije potrebno izvriti nijednu transakciju

Slika 2: Rekonstrukcija do checkpointa u log file-u

Na transakciju t1 ne utjee greka sistema i sam proces rekonstrukcije, jer je zavrena prije posljednjeg checkpointa. Iako su transakcije t2 i t4 zavrene, nalaze se poslije posljednjeg checkpointa i ulaze u proces rekonstrukcije. Transakcije t3 i t5 e se morati ponovo izvriti, jer nisu zavrene prije greke sistema. Smanjiti veliinu log file-a moemo na sljedei nain:

8
Upravljanje bazama podataka::Predavanja http://dl.fit.ba/

ProgramiranjeI_sylabus.doc

Fakultet informacijskih tehnologija emina@fit.ba

1. use Northwind U Queri Analyzer otvorimo kontekst eljene baze podataka. 2. CHECKPOINT pohranjuje sve blokove podataka iz buffera na disk. 3. EXEC sp_addumpdevice 'disk', 'CopiaMyBase', 'd:\LogMyBase.bak' kreira fiziki prostor za pohranjivanje sigurnosne kopije, file LogMyBase.bak na disku D. 4. BACKUP DATABASE Northwind TO CopiaMyBase kreira sigurnosnu kopiju baze podataka. 5. BACKUP LOG Northwind TO CopiaMyBase kreira sigurnosnu kopiju log file-a. Ovim smo oslobodili prostor u log file-u, meutim log file i dalje zauzima istu koliinu prostora na disku. 6. DBCC SHRINKFILE (Northwind_Log, 300) oslobaa prostor na disku. Prvi argument je logiki naziv file-a i drugi argument je eljena veliina file-a u MB. 1. 2. 3. 4. 5. 6. Ukoliko ne elimo sigurnosnu kopiju log file-a moemo koristiti bru metodu: use Northwind CHECKPOINT EXEC sp_addumpdevice 'disk', 'CopiaMyBase', 'd:\LogMyBase.bak' BACKUP DATABASE Northwind TO CopiaMyBase BACKUP LOG MyBase WITH TRUNCATE_ONLY DBCC SHRINKFILE (MiBase_Log, 100) Ova opcija umanjuje log file za njegov neaktivni dio. Gubitak log file-a je teka greka. Jedino rjeenje jeste imati sigurnosnu kopiju log file-a. Da se ne bi ponovio ovaj problem moramo imati plan odravanja koji realizira sigurnosne kopije baze podataka i log file-a u odreenim periodima. Koliko dug period mora proi izmeu dvije kopije ovisi o namjeni baze podataka i njenoj veliini, ali se kree od nekoliko puta dnevno do jednom sedmino. Checkpoint se izvrava kada: radimo modifikaciju strukture baze podataka (ALTER DATABASE), zaustavimo server (osim ako koristimo opciju shutdown with nowait) i aktivni log file prelazi 70% maksimalne dozvoljene veliine.

Ne znam koliko je potrebno istai da svaki put kad realiziramo zadae koje mogu imate opasne posljedice po bazu podataka je obavezno napraviti sigurnosnu kopiju.

Dvofazni protokol zavretka transakcija se izvrava sistemima koji imaju vie DBMS-ova u okviru distribuiranih sistema.

distribuiranim

Ukoliko imamo transakciju koja mijenja podatke u bazi podataka, ove promjene moraju biti zabiljeene od strane svih sistema za upravljanje bazama podataka. Ukoliko se transakcija uspjeno potvrdi ili prekine, to moraju registrirati svi DBMS-ovi i ponititi ono to su uradile prekinute transakcije. COMMIT (ili ROLLBACK) utjee na kompletan sistem. Ovim instrukcijama upravlja koordinator, koji koristi dvofazni protokol zavretka transakcija. Koordinator pripremi sve DBMS-ove na obe mogunosti.

9
Upravljanje bazama podataka::Predavanja http://dl.fit.ba/

ProgramiranjeI_sylabus.doc

Fakultet informacijskih tehnologija emina@fit.ba

Svaki od administratora pohranjuje odgovarajue registre u log-file. Ukoliko transakcija zavri pohranjivanjem izmjena na disk manager resursa alje potvrdan odgovor koordinatoru, u suprotnom negativan. Kada koordinator dobije pozitivne odgovore od oba managera resursa to pohranjuje u svoj log file. Ukoliko su svi odgovori bili pozitivni, transakcija se potvrdi (COMMIT). U koliko je jedan od odgovora bio negativan, vri se ROLLBACK. U svakom sluaju koordinator obavjetava sve administratore resursa i svaki od njih mora potvrditi ili ponititi transakciju.

10
Upravljanje bazama podataka::Predavanja http://dl.fit.ba/