Embed Size (px)
Citation preview
OPORAVAK BAZE PODATAKA
Gordana Pavlović-Lažetić
Matematički fakultet, Beograd
šk. 2017/18.
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
(restaurisani) sadržaj baze podataka zadovoljio
(privremeno narušene) uslove integriteta baze.
2/30
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/30
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 posleposlednjeg arhiviranja a pre pada medija
4/30
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/30
Oporavak: zadaci upravljača
• Komponenta SUBP odgovorna za oporavak baze
podataka od pada transakcije, sistema ili medija je
upravljač oporavkom
• 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/30
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/30
Oporavak: UNDO / REDO
• Neophodne 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”)
• na osnovu starih odnosno novih vrednosti zapamćenih u sistemskom logu.
8/30
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/30
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/30
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/30
COMMIT
• 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 oslobađ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/30
Oporavak od pada transakcije -
ROLLBACK
• 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/30
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, sastojise od poništavanja učinjenih promena nad bazom
• Izvršava se čitanjem unazad svih slogova iz log datotekekoji 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čujeREDO logiku.
14/30
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/30
Oporavak od pada sistema – tačke
pamćenja
• Da bi se smanjila količina posla vezana za oporavak od
pada sistema,
• u pravilnim intervalima tačke pamćenja.
• fizički se upisuju podaci i informacije iz log bafera i bafera podatakau 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 momentutač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/30
Oporavak od pada sistema – tačke
pamćenja• Fizički upis u tački pamćenja - bez obzira da li su baferi puni
• 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, restaurisanje iz sistemskog loga REDO logikom
17/30
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/30
Oporavak od pada sistema
19/30
Oporavak od pada sistema - primer
• Interpretacija
20/30
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:
• Interpretacija
21/30
Oporavak od pada sistema
22/30
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/30
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/30
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/30
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/30
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/30
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/30
Poboljšanje procedure oporavka od pada
sistema - algoritam
29/30
Poboljšanje procedure oporavka od pada
sistema - primer
• Procedura oporavka od pada sistema sada ima sledeći
izgled:
30/30
