Side 1 for Databaser DBS22 Databasegjenopprettingsteknikker onsdag 1. juni 2016 21.49 Pensum: 22.1-22.5, side 813-831 22.1 Gjenopprettingskonsepter 22.1.1 Recovery outline and categorization of recovery algorithms Gjenoppretting betyr typisk at databasen er gjenopprettet til en tidligere konsistent tilstand før en feil. Informasjon for å kunne utføre gjenoppretting er typisk bevart i systemloggen. Typisk strategi: 1) Hvis det er stor skade på databasen, gjenopprettes en kopi fra en back up (for eksempel magnetisk tape), og operasjoner fra en back-up av systemloggen blir gjort på nytt av. 2) Hvis disken ikke er fysisk skadet, er gjenopprettingsstrategien å identifisere endringer som forårsaker inkonsistens. Punkt (2) kan deles to fremgangsmåter: Utsatt oppdatering (deferred update) Oppdateringer blir ikke lagret på disk før etter commit, men blir lagret persistent i systemlogg. No-undo/redo. Trenger ikke undo siden ingenting er endret i databasen ved abort. umiddelbar oppdatering (immediate update). Operasjoner kan bli skrevet til disk før commit, men da må de også logges i systemloggen med force-writing først. Undo/redo. Undo/no-redo. Alle operasjoner må skrives til disk før commit. Undo/redo må være idempotent, at utføring av en operasjon flere ganger er det samme som å utføre den bare én gang. 22.1.2 Caching (buffering) av disk-blokker DBMS-cachen holder styr på buffer og diskblokker. Hver buffer har en dirty bit som sier om blokken i bufferet er endret eller ikke (1 = endring), og en pinunpin bit som sier om man får lov å skrive blokken tilbake til disk. Kun buffer der dirty bit er 1 skal skrives tilbake til disk, og det er to metoder: In-place oppdatering. Blokken blir skrevet tilbake til samme plass den var før. Shadowing. Blokken blir skrevet tilbake til en ny plass, så man har flere versjoner av dataelementene. 22.1.3 Write-ahead logging, steal/no-steal, force/no-force BFIM - before image, verdien et dataelement hadde før oppdatering. AFIM - after image, verdien et dataelement har etter oppdatering. Write ahead-logging. Sørg for at BFIM blir logget, og loggen blir skrevet til disk før BFIM blir overskrevet av AFIM på disk. I logger som skal brukes til REDO, trenger man AFIM og i logger som skal brukes til UNDO trenger man BFIM. Man har typisk også buffer til loggfilblokker og indeksfilblokker. Det er typisk satt av buffer til n loggfilblokker, og en loggfilblokk må skrives til disk før en endret blokk kan skrives til disk med write-ahead.
Side 2 for Databaser No-steal. Hvis en oppdatert blokk ikke kan skrive tilbake til disk før transaksjonen committer. Pin-unpin settes til 1 (så blokken ikke blir byttet ut). Undo trengs ikke Steal. Hvis en oppdatert blokk kan skrives tilbake til disk før en transaksjon committer. Da trengs også undo. Man unngår behovet for masse bufferplass. Undo trengs. Force approach. Hvis alle oppdaterte blokker blir skrevet til disk umiddelbart, før transaksjonen committer. Redo trengs ikke No-force. Ikke force approach. En blokk kan fortsette å være i minnet, så andre transaksjoner kan bruke den. Reduserer I/O. Redo trengs. Mange databaser følger en Steal/No-force-fremgangsmåte. 22.1.4 Sjekkpunkter i systemloggen og "fuzzy checkpointing" Et sjekkpunkt er også med i systemloggen. Når man tar sjekkpunkt, lagres en post [checkpoint, liste med aktive transaksjoner] i loggen. Et sjekkpunkt består av følgende handlinger: 1) Pause transaksjoner midlertidig 2) Force-write alle buffer som er endret til disk 3) Skriv en [checkpoint]-post til loggen, og force-write loggen til disk. 4) Start transaksjoner igjen. Resultatet er at alle transaksjoner som har [commit, T] i loggen før et sjekkpunkt ikke trenger å skrives på nytt av. Det er en liste med aktive transaksjoner i posten, slik at det under gjenoppretting er enkelt å identifisere disse. Sjekkpunkt kan for eksempel tas hver m-te minutt eller etter at t transaksjoner har committed. Fuzzy checkpointing går ut på at transaksjoner kan starte igjen etter [begin_checkpoint], i stedet for å vente på steg (2). Når steg (2) er ferdig, skrives en [end_checkpoint, ]-post til loggen, med relevant informasjon. Mens dette foregår, må forrige sjekkpunkt være gyldig. 22.1.5 Transaksjonstilbakerulling og gallopperende tilbakerulling Cascading rollback er når en transaksjon må tilbakerulles, fordi den leste en verdi til en annen transaksjon som ble tilbakerullet, fordi den leste en verdi til en tredje transaksjon som ble tilbakerullet Det er vanskelig å implementere databaser som støtter dette, så det er mer vanlig å implementere databaser der dette ikke skjer, ved at det garanteres historier som er cascadeless eller strict. 22.1.6 Transaksjonshandlinger som ikke påvirker databasen Transaksjoner kan også utføre handlinger som ikke påvirker databasen, men som for eksempel er ment som rapporter til brukeren. Disse bør bare kjøres hvis man vet at transaksjonen var vellykket, for eksempel etter at den har
Side 3 for Databaser committet. 22.2 NO-UNDO/REDO gjenoppretting basert på utsatt oppdatering Med utsatt oppdatering blir ikke data skrevet på disk før etter commit. I loggen trengs bare REDO-informasjon, som inkluderer AFIM (den nye verdien). Det er vanskelig å få til i praksis, siden man kan gå tom for bufferplass hvis for mange blokker i bufferet blir pinned. Typisk eksempel på utsatt oppdateringsprotokoll: 1) No-steal policy 2) Write ahead-logging Hvis dette blir brukt sammen med strikt 2PL, der opplåsing av skrevne verdier skjer etter commit, og man har med sjekkpunkt, kan dette være en mulig løsning: Gjenoppretting: Har to lister med transaksjoner, commit list og active transactions. REDO alle transaksjoner i commit-lista i samme rekkefølge som de er skrevet til loggen. De aktive transaksjonene blir avbrutt. REDO: Finn AFIM (new_value) i loggen for transaksjon T: [write_item, T, X, new_value] Ulemper: Kan bruke masse bufferplass Hindrer samtidighet pga. strikt 2PL Fordeler: Trenger ikke å rulle tilbake transaksjoner siden de ikke blir lagret på disk før etter commit. En transaksjon vil ikke lese en skitten verdi, siden alle dataelementer er låst til etter commit, så det vil ikke være noen cascading rollbacks. 22.3 Gjenopprettingsteknikker basert på umiddelbar oppdatering Når en transaksjon blir oppdatert, kan denne skrives tilbake med én gang, i stedet for å vente på commit. Det må være mulig å angre effektene av en transaksjon som feiler, så man må ha med BFIM (old_value) i loggen. To hovedkategorier for oppdateringsalgoritmer 1) Hvis det sørges for at alle oppdateringer til en transaksjon blir skrevet til disk før commit, så trengs ikke REDO. Dette er en UNDO/NO-REDO gjenopprettingsalgoritme. Må bruke steal/force-strategien. 2) Hvis transaksjonen kan committe før alle oppdateringer er skrevet til disk, er det en UNDO/REDO gjenopprettingsalgoritme. Da brukes en steal/no-force-strategi. Denne er mest vanlig og mest kompleks. Et eksempel på UNDO/REDO, med sjekkpunkt og strikte historier (for eksempel strikt 2PL). Gjenoppretting: 1) To lister: Committede transaksjoner siden siste sjekkpunkt og aktive transaksjoner 2) UNDO alle operasjoner gjort av de aktive transaksjonene, i motsatt
Side 4 for Databaser 3) rekkefølge av hvordan de ble lagt inn i loggen. REDO alle skriveoperasjoner av de committede transaksjonene, i samme rekkefølge som de ble lagt inn i loggen (REDO fra 22.2). UNDO: Sjekk logg-verdien, [write_item, T, X, old_value, new_value], og sett X til old_value, BFIM. 22.4 Shadow paging Side 826-827. 22.5 ARIES gjenoppretting Steal/no-force Write ahead Loggendringer during UNDO Gjentagende historikk during REDO Spore opp alle handlinger ARIES består av tre steg: Analyse, UNDO og REDO, og trenger systemloggen, transaksjonstabellen og Dirty Page-tabellen, i tillegg til sjekkpunkt. Analyse. Identifiserer skitne blokker i bufferet og transaksjonene som var aktive ved krasjet. Den finner også det punktet der REDO bør startes. REDO. De oppdateringene som trengs å gjøres fra loggen blir gjort på nytt av i databasen, og den vil gjøre alle oppdateringer til slutten av loggen. UNDO. Loggen blir scannet bakover, og transaksjoner som var aktive ved krasjet blir UNDO-et i reversert rekkefølge. Hver loggpost har et loggsekvensnummer, LSN, som er monotont økende og indikerer adressen til loggposten på disken. Hver LSN korresponderer til en spesifikk endring av en transaksjon, og hver diskblokk vil lagre LSN til den siste loggposten til en endring av datablokken. Mulige handlinger som blir lagret i loggen: Write, commit, abort, undo (for å slippe å gjøre det igjen) og end, for om en transaksjon avsluttes ved abort eller commit. Vanlig felt i loggposter inkluderer previouslsn, transaksjonsid og typen loggpost. For write-loggposter er det en blokkid (pageid), lengden på elementet, offset fra begynnelsen av blokken, BFIM og AFIM. Transaksjonstabellen har en post for alle aktive transaksjoner, med transaksjonsid, transaksjonsstatus og LSN til den siste loggposten til transaksjonen. Dirty page-tabellen har en post for alle skitne blokker i bufferet, med pageid og LSN til den tidligste oppdateringen. Når systemet krasjer, vil disse tabellene oppdateres i analyse-delen, ved å se på systemloggen. Fuzzy checkpoint. Har begin_checkpoint og end_checkpoint. Ved end_checkpoint blir transaksjonstabellen og dirty page-tabellen lagt til på slutten av loggen. Innholdet i bufferet trenger ikke flushes til disk, siden nødvendig inforasjon for recovery ligger i transaksjonstabellen og dirty pagetabellen. I analysefasen begynner gjenopprettingsmanageren på begin_checkpoint og går i gjennom loggpostene til slutten. Da kan den gjøre endringer på
Side 5 for Databaser transaksjonstabellen og dirty page-tabellen. I REDO-fasen gjør den alle operasjoner som er nødvendig å gjøre på nytt av. Den vil starte på den transaksjonen med samme LSN som den laveste LSN-verdien i dirty pagetabellen. En skriveoperasjon trenger ikke gjøres hvis Page ikke er i dirty page-tabellen Page er i dirty page-tabellen, men LSN(Page) er større enn LSN(loggpost). I UNDO-fasen vil den gå bakover i loggen og UNDO alle operasjoner som ikke ble committet.