Crash recovery i DBMS

I et DBMS-system udføres der ved hver forespørgsel en række transaktioner. Disse transaktioner skal, som bekendt, overholde ACID-reglerne, som er: Atomicity, Consistency, Isolation og Durability.

Begreberne kan forkortes til: Atomicity = Vi må ikke miste noget ved udførelsen af en forespørgsel. Consistency = Vi skal mellem transaktioner flytte databasen fra en konsistent tilstand til en ny konsistent tilstand. Isolation = Vi skal kunne sikre, at hvis flere transaktioner kører samtidigt, så kan de køre isoleret uden at påvirke hinanden. Durability = Hvis vores database bryder ned, skal vi sikre os, at vi kan bringe den tilbage til tilstanden før nedbruddet.

Disse 4 begreber er essentielle for forståelsen af CRASH recovery i vores DBMS-system. En recovery manager i vores DBMS er ansvarlig for at overholde særligt Atomicity og Durability i vores database. Dette gør den bl.a. gennem sikker afbrydning af transaktioner, som ikke har committed, og ved at sikre, at transaktioner, der har committed, overlever et eventuelt system crash.

ARIES: En recovery algoritme

Vi har altså brug for at kunne sikre en korrekt recovery i forbindelse med et system crash. Her kan bl.a. ARIES benyttes, som er en recovery algoritme designet ved et steal, no-force approach.
Steal approachet skal forstås på den måde, at ARIES genbruger noget af det arbejde, som transaktionerne allerede har udført. Bl.a. igennem dens Write-ahead log (WAL), som sikrer, at alle transaktioner først skrives til en log FØR de udføres på den faktiske database. Denne log kan benyttes i forbindelse med gendannelse af databasens sidst stabile punkt og kan desuden benyttes til en række andre fordele, såsom:

Forhindring af unødvendige I/O-operationer, som ville forekomme ved en komplet genstart af transaktionsforløbet.
Redo logging, som involverer at udføre de gemte transaktioner, så databasen kan bringes tilbage til den tilstand, den var før system crashet.
Undo logging, som involverer at gå skridt for skridt tilbage på transaktioner, der har manipuleret data i databasen, men som grundet system crash ikke nåede at commit. Dette sikrer ligeledes, at databasen er stabil.

No-force approachet indebærer blot, at ARIES ikke tvinger opdateringer til systemets disk ved transaktionernes eksekvering. Den udsætter disse, indtil transaktionen har committed, og dermed udføres der ikke unødvendig skrivning til systemets disk, såfremt noget går galt, inden transaktionen får committed. Med forklaringen af, hvorfor ARIES er en steal, no-force approach algoritme, kan vi bevæge os videre til algoritmens 3 grundprincipper (dele af det er gennemgået ovenfor, men det er vigtigt at få stadfæstet disse, da de er grundprincipperne i algoritmens tilgang).

Write-ahead logging

ARIES-algoritmen sørger for, at enhver ændring af et databaseobjekt først gemmes i vores log. Ændringen skal først sikres at den er korrekt, før den kan skrives til disk.

Repeating History During Redo

Ved en genstart som følge af et system crash skal ARIES-algoritmen gennemgå alle handlinger udført af DBMS før crashet og bringe databasen tilbage til det eksakte stadie, som den var i før crashet. Herefter kan den fjerne alle handlinger udført af transaktioner, som stadig var aktive ved crash tidspunktet.

Logging Changes During Undo

Ændringer foretaget på databasen ved undo af transaktioner bliver gemt i logging for at sikre, at hvis en handling resulterer i gentagne restart, kan den overses.