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žemsmislu), 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 sistemskomlogu.

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 serijskombroju 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