Citater fra C.J. Date: An Introduction to Database Systems, kapitel 13:

13 Recovery

Begrebet recovery (gendannelse) betyder i relation til databasesystemer først og fremmest gendannelse af selve databasen - eller mere præcist gendannelse af databasen til en tilstand, hvor den vides at være korrekt (eller antages at være korrekt). Denne gendannelse finder sted, efter at der er sket en fejl, som har bragt databasen i en formodet fejltilstand. De principper, som gendannelsen er baseret på, er ret simple, og de kan opsummeres med et enkelt ord: redundans. [p. 374]

13.2 Transaktioner

En transaktion defineres som en logisk enhed af arbejde. [375]

En transaktion består ikke nødvendigvis af blot en enkelt databaseoperation. Der er tværtimod som regel tale om en sekvens af flere operationer, som tilsammen har til opgave at transformere databasen fra én konsistent tilstand frem mod en ny konsistent tilstand, uden at konsistensen nødvendigvis er bevaret mellem alle de indgående operationer. [376]

Et system, der understøtter transaktions behandling garanterer, at hvis en transaktion fejler under udførelsen af en sekvens af databaseopdateringer, så transaktionen ikke når sin planlagte terminering, da vil disse opdateringer blive annulleret. Derfor kan man sige, at enten bliver transaktionen udført i sin helhed, eller også bliver transaktionen totalt annulleret. På denne måde kan man opnå, at en serie af operationer, som reelt ikke er atomar, vil blive behandlet og opføre sig som om den var atomar, når man ser på den udefra. [376]

Den systemkomponent, som bruges til at simulere denne atomaritet kaldes transaktions manageren, og operationerne commit og rollback er nøglen til forståelse af, hvordan det virker:

For at kunne annullere de udførte opdateringer, må systemet vedligeholde en log eller journal på tape eller disk, hvor detaljerne om de enkelte opdateringer registreres. Hvis det bliver nødvendigt at annullere en bestemt operation, kan systemet bruge den tilsvarende indførsel i loggen til at føre de berørte databaseobjekter tilbage til deres oprindelige værdi. [377]

13.2 Transaction recovery

En transaktion begynder med udførelsen af operationen begin transaction, og den slutter med udførelse af enten commit eller rollback. Udførelse af commit etablerer et såkaldt commit punkt (synkroniseringspunkt), hvor databasen er (eller burde være) i en konsistent tilstand. [377]

Når et commit punkt er etableret, bliver

Bemærk at commit og rollback terminerer transaktionen, ikke programmet. [378]

Programmet vil udføre en implicit rollback for ethvert program, som af en eller anden grund ikke når sit planlagte terminerigspunkt. [379]

Transaktioner er ikke kun den enhed arbejdet opdeles i; men også den enhed, der anvendes ved retableringen (recovery). [379]

Data skal være fysisk overført til loggen, før behandlingen af commit kan siges at være fuldført. Denne meget vigtige regel kaldes log read-ahead reglen. [379]

Transaktioners egenskaber (ACID)

Transaktioner har 4 vigtige egenskaber: atomaritet, konsistens, isolation og stabilitet.

13.4 System recovery

Systemet må være indrettet på også at skulle håndtere globale fejl - dvs. fejl der ikke skyldes selve programmet; men derimod hændelser, som ligger udenfor programmets indflydelse. Det kunne f.eks. være strømsvigt. [380]

Med visse foruddefinerede intervaller - f.eks. når et vist antal oplysninger er skrevet til loggen - laver systemet automatisk et checkpoint. At lave et checkpoint omfatter

Når systemet genstartes efter en fejl, undersøges alle transaktioner, der var aktive ved sidste checkpoint samt de transaktioner, der startede senere. Alle transaktioner, som ikke var færdige, da fejlen skete, annulleres (UNDO) ved hjælp af loggen. Alle transaktioner, der var færdige, da fejlen skete, retableres (REDO) ved hjælp af loggen. [381]

13.5 Media Recovery

En mediefejl kan f.eks. være en diskfejl, hvor hele eller dele af databasen fysisk går tabt. Recovery efter denne type fejl starter med, at man gendanner databasen fra en backup kopi (dump). Derefter retableres databasen ved hjælp af loggen fra backup tidspunktet og så langt frem, som det kan lade sig gøre (loggen kan jo også være blevet berørt af mediefejlen). [382]

13.6 To-fase commit

To-fase commit er vigtigt, når en given transaktion interagerer med flere uafhængige ressource administratorer, som hver administrerer sit eget sæt af ressourcer og tilhørende log. (distribuerede databaser) [382]

  1. Hver deltagende ressourceadministrator skal sikre, at alle logmeddelelser for den aktuelle transaktion er skrevet ud på den lokale fysiske disk.
  2. Når koordinatoren har modtaget bekræftelse fra alle deltagere, udskrives en meddelelse i koordinatorens log vedrørende beslutningen om at fortsætte (commit) eller afbryde (rollback). Herefter informerer koordinatoren hver deltager om beslutningen, og hver deltager skal derefter udføre lokal commit eller rollback i overensstemmelse med koordinatorens instruktioner. [383]

Hvis der sker en fejl et eller andet sted i processen, vil genstartsproceduren lede efter beslutningen i koordinatorens log. Hvis den findes, kan to-fase commit processen genoptages herfra. Hvis den ikke findes, antager man, at beslutningen var rollback, hvorefter processen genoptages. [383]

indlagt 5. maj 1997