Oporavak baze podataka

Oporavak
• Odnosi se na restaurisanje podataka baze podataka u slučaju
da dođe do greške u transakciji, u sistemu ili u mediju (disku).

• Razmatraju se aktivnosti koje komponenta SUBP – upravljač

oporavkom preduzima da bi oporavljeni (restaurirani) sadržaj
baze podataka zadovoljio (privremeno narušene) uslove
integriteta baze.

2
 Oporavak
• Podrazumeva aktivnost koju sistem preduzima u slučaju da se,
u toku izvršenja jedne ili više transakcija, otkrije neki razlog
koji onemogućava njihovo uspešno kompletiranje. Taj razlog
može biti:
– u samoj transakciji, kao što je prekoračenje neke od dozvoljenih
vrednosti (pad transakcije),
– u sistemu, npr. prestanak električnog napajanja (pad sistema), ili
– u disku na kome je baza podataka, npr. oštećenje glava diska (pad
medija).

3
 Oporavak
• Transakcija: sve radnje se uspešno izvrše ili nijedna
• Transakcija je i logička jedinica oporavka
• Kod nemogućnosti uspešnog kompletiranja
– poništavanje efekata parcijalno izvršenih transakcija
• Kad je uspešno kompletirana transakcija
– u trenutku pada sistema neki efekti još nisu upisani u bazu
– potrebno je ponovno izvršiti neke njene radnje
• Pad transakcije ili sistema
– poništavanje / ponovno izvršavanje: sistemska aktivnost oporavka
• Pad medija
– prepisivanje arhivirane kopije baze na ispravan medij
– eventualno, ponovno izvršenje transakcija kompletiranih posle
poslednjeg arhiviranja a pre pada medija
4
 Oporavak: log datoteka
• Ovako koncipiran oporavak
– postojanje ponovljenih (dupliranih) podataka i informacija
na različitim mestima ili medijima
– mogućnost rekonstrukcije informacije na osnovu druge
informacije, ponovljeno smeštene na drugom mestu u
sistemu
– tzv. log datoteka (sistemski log, dnevnik ažuriranja).

5
 Oporavak: zadaci upravljača
• Komponenta SUBP odgovorna za oporavak baze podataka od
pada transakcije, sistema ili medija je upravljač oporavka
– periodično prepisuje (engl. dump) celu bazu podataka na
medij za arhiviranje;
– pri svakoj promeni baze podataka, upisuje slog promene u
log datoteku, sa
• tipom promene i sa novom i starom vrednošću pri ažuriranju,
• sa novom vrednošću pri unošenju u bazu
• sa starom vrednošću pri brisanju iz baze

6
 Oporavak
– u slučaju pada transakcije ili sistema, stanje baze podataka
može biti nekonzistentno;
• upravljač oporavka koristi informacije iz log datoteke
• poništi dejstva parcijalno izvršenih transakcija
• ponovo izvrši neke kompletirane transakcije;
• arhivirana kopija baze podataka se ne koristi;
– u slučaju pada medija
• “najsvežija” arhivirana kopija baze podataka se prepisuje na
ispravni medij (disk)
• koriste se informacije iz log datoteke za ponovno izvršenje
transakcija kompletiranih posle poslednjeg arhiviranja a pre pada
medija.

7
 Oporavak: UNDO / REDO
• Neophpdne procedure kojima se poništavaju odnosno
ponovo izvršavaju pojedinačne radnje transakcija kojima se
menja baza podataka

• Baza podataka menja se operacijama ažuriranja (u užem

smislu), unošenja ili brisanja podataka (DO-logika (“uradi”))
– SUBP: UNDO –logika (“poništi”)
– REDO-logika (“ponovo uradi”) logiku.
– na osnovu starih odnosno novih vrednosti zapamćenih u sistemskom
logu.

8
 Oporavak: idempotentnost
• Pad sistema ili medija može se dogoditi i u fazi oporavka od
prethodnog pada.
• Može doći do ponovnog poništavanja već poništenih radnji /
ponovnog izvršavanja već izvršenih radnji.
• UNDO i REDO logika: svojstvo idempotentnosti
• UNDO(UNDO(x)) ≡ UNDO(x)
• REDO(REDO(x)) ≡ REDO(x) za svaku radnju x.

9
 Oporavak
• U log datoteci pokazivačima su povezani slogovi koji se odnose
na jednu transakciju
• Čuvanje log datoteke na mediju sa direktnim pristupom, npr.
na disku.
• Aktivni deo / arhivirani deo (npr. na traci)
• Log datoteka nikada, ili veoma retko, “pada”
• Dupliranje, tripliranje, itd, na raznim medijima;
• Uvek dostupna

10
 Oporavak od pada transakcije
• Jedan aplikativni program može se sastojati od većeg broja
transakcija.
• Izvršenje jedne transakcije može da se završi planirano ili
neplanirano.
• Do planiranog završetka dolazi izvršenjem COMMIT operacije
(uspešno kompletiranje) ili eksplicitne ROLLBACK operacije,
(greška za koju postoji programska provera; program nastavlja
sa radom izvršenjem sledeće transakcije)
• Neplanirani završetak izvršenja transakcije
– kada dođe do greške za koju ne postoji programska provera
– implicitna (sistemska) ROLLBACK operacija
– radnje transakcije se poništavaju a program prekida sa radom

11
 Oporavak od pada transakcije
• COMMIT - efekti svih ažuriranja transakcije postaju trajni
• Ne mogu se poništiti procedurom oporavka
• U log datoteku se upisuje COMMIT slog
• Svi katanci koje je transakcija držala se slobađaju
• COMMIT ne podrazumeva fizički upis svih ažuriranih podataka
u bazu
• Neki podaci mogu biti u baferu podataka
• Sa fizičkim upisom u bazu čeka se dok se baferi ne napune
• Garantuje se upis u bazu u nekom narednom trenutku
• U slučaju pada sistema posle COMMIT operacije upis se
garantuje REDO-logikom.

12
 Oporavak od pada transakcije
• Pad transakcije nastaje kada transakcija ne završi svoje
izvršenje planirano.
• Implicitna – prinudna ROLLBACK operacija
• Sprovodi se aktivnost oporavka od pada transakcije
• Svaka radnja ažuriranja omogućuje oporavak baze u slučaju
pada transakcije
• Oporavak podataka obezbeđen upisom svih potrebnih
informacija u sistemski log

13
 Oporavak od pada transakcije
• Izvršavanjem operacije BEGIN TRANSACTION (bilo da je
eksplicitna ili implicitna) u log datoteku se upisuje slog
početka transakcije
• Operacija ROLLBACK, bilo eksplicitna ili implicitna, sastoji se
od poništavanja učinjenih promena nad bazom
• Izvršava se čitanjem unazad svih slogova iz log datoteke koji
pripadaju toj transakciji, do BEGIN TRANSACTION sloga
• Za svaki slog, promena se poništava primenom odgovarajuće
UNDO-operacije
• Aktivnost oporavka od pada transakcije ne uključuje REDO
logiku.

14
 Oporavak od pada sistema
• U slučaju pada sistema, sadržaj unutrašnje memorije je
izgubljen.
• Po ponovnom startovanju sistema, za oporavak se koriste
podaci iz log datoteke
• Poništavaju se efekti transakcija koje su bile u toku u trenutku
pada sistema
• Ove transakcije se mogu identifikovati čitanjem sistemskog
loga unazad, kao transakcije za koje postoji BEGIN
TRANSACTION slog ali ne postoji COMMIT slog

15
 Oporavak od pada sistema – tačke
pamćenja
• Da bi se smanjila količina posla vezana za poništavanje
transakcija,
– u pravilnim intervalima tačke pamćenja.
– fizički se upisuju podaci i informacije iz log bafera i bafera podataka u
log datoteku i u bazu podataka
– upisuje se slog tačke pamćenja u log datoteku
– slog sadrži informaciju o svim aktivnim transakcijama u momentu
tačke pamćenja, adrese poslednjih slogova tih transakcija u log
datoteci i druge informacije o bazi
• Adresa sloga tačke pamćenja upisuje se u datoteku ponovnog
startovanja (engl. restart file).

16
 Oporavak od pada sistema – tačke
pamćenja
• Fizički upis u tački pamćenja - bez obzira da li su baferi pun.
• Fizički upis ažuriranih podataka uspešno kompletirane
transakcije garantuje se tek u tački pamćenja
• upis COMMIT sloga u log datoteku i upis svih ažuriranja te
transakcije u bazu – dve odvojene radnje
• protokol unaprednog upisivanja u log (engl. WAL – Write
Ahead Log) obezbeđuje da se obe izvrše
– prvo se odgovarajući slog fizički upisuje u log datoteku,
– pa se zatim podaci upisuju iz bafera podataka u bazu.
• Ako dođe do pada sistema posle upisa COMMIT sloga u log
datoteku a pre nego što je sadržaj bafera podataka prepisan u
bazu, restauriranje iz sistemskog loga REDO logikom
17
 Oporavak od pada sistema
• Pri ponovnom startovanju sistema, posle pada sistema,
moguće je prema sadržaju log datoteke identifikovati
– neuspele transakcije – kandidate za poništavanje, i
– uspele transakcije – kandidate za ponovno izvršavanje.
• Oporavak baze podataka tada se vrši prema protokolu koji se
može opisati sledećim pseudoprogramom

18
Oporavak od pada sistema

19
Oporavak od pada sistema - primer

• Interpretacija

20
 Oporavak od pada sistema
• Upravljač oporavka podrazumeva da transakcija oslobađa sve
X-katance pri izvršenju COMMIT operacije
• Najčešće je isti slučaj i sa S-katancima
• Ovo je saglasno sa svojstvom izolacije transakcije i rešava
problem zavisnosti od poništenog ažuriranja, bilo da se ono
dogodilo pre ili posle tačke pamćenja
• Dakle, nisu moguća sledeća izvršenja:

21
Oporavak od pada sistema

22
Poboljšanje procedure oporavka od
pada sistema
• Postoji niz poboljšanja postupka oporavka od pada sistema.
• Moguće sva upisivanja jedne transakcije u bazu ostaviti za
trenutak izvršenja COMMIT operacije te transakcije
• Eliminiše se potreba za UNDO logikom
• Moguće je oslabiti zahtev za izolacijom transakcije, tj. zahtev
za dvofaznošću, što nosi opasnost nelinearizovanog izvršenja.

23
Poboljšanje procedure oporavka od
pada sistema
• Jedno poboljšanje protokola oporavka od pada sistema odnosi
se na aktivnosti vezane za tačku pamćenja.
• Prethodno opisani protokol
– poništava efekte neuspelih transakcija koji možda nisu ni bili ubeleženi
u bazu
– ponovo izvršava radnje uspelih transakcija od tačke pamćenja, čak i
ako su efekti tih radnji upisani u bazu pre pada sistema.

24
Poboljšanje procedure oporavka od
pada sistema
• Moguće je eliminisati fizičko upisivanje bafera podataka u
bazu podataka u tački pamćenja
• U fazi oporavka od pada sistema poništavaju se samo one
radnje neuspelih transakcija čiji su efekti upisani u bazu
• Ponovo izvršavaju samo one radnje uspelih transakcija čiji
efekti nisu upisani u bazu
• Uvodi se, u vreme upisa sloga u log, jedinstvena oznaka sloga
– serijski broj u logu (engl. LSN – Log Sequence Number)
• Serijski brojevi su u rastućem poretku

25
Poboljšanje procedure oporavka od
pada sistema
• Kadgod se ažurirana stranica fizički upisuje u bazu podataka, u
stranicu se upisuje i LSN sloga sistemskog loga koji odgovara
tom ažuriranju
• U sistemskom logu može biti više slogova koji odgovaraju
ažuriranju iste stranice baze podataka
• Ako je serijski broj upisan u stranicu P veći ili jednak serijskom
broju sloga loga, efekat ažuriranja kome odgovara taj slog
fizički je upisan u bazu; ako je manji, efekat nije upisan.

26
Poboljšanje procedure oporavka od
pada sistema
• Da bi se slog iz baze podataka ažurirao, potrebno je pročitati
(iz baze) stranicu na kojoj se slog nalazi.
• Posle ažuriranja sloga, stranica je (u baferu podataka)
spremna za upis u bazu; i dalje nosi serijski broj svog
prethodnog upisa u bazu.
• Pri registrovanju tačke pamćenja,
– eliminiše se fizički upis bafera podataka u bazu,
– dodaje se upis, u slog tačke pamćenja, vrednosti LSN m najstarije
stranice bafera podataka (najmanjeg LSN stranica iz bafera podataka,
koje su ažurirane ali još nisu upisane u bazu)

27
Poboljšanje procedure oporavka od
pada sistema
• Slog sistemskog loga sa serijskim brojem m odgovara tački u
sistemskom logu od koje treba pri oporavku od pada sistema,
ponovo izvršavati uspele transakcije
• Tačka m prethodi tački pamćenja
• Može se desiti da neka transakcija koja je uspešno
kompletirana pre tačke pamćenja “upadne” u skup aktivnih
(uspelih) transakcija (transakcija T1)
• Na takvu transakciju primeniće se procedura oporavka
– to se ne bi dogodilo u prethodnoj varijanti oporavka;
– to je “cena” smanjenog broja poništavanja, ponovnog izvršavanja i
fizičkog upisa koje obezbeđuje ovaj postupak.

28
Poboljšanje procedure oporavka od
pada sistema - algoritam

29
Poboljšanje procedure oporavka od
pada sistema - primer
• Procedura oporavka od pada sistema sada ima sledeći izgled:

30