DAV B04 - Databasteknik Återhämtning (kap 19)

Återhämtning (Recovery) Innebär att man: återhämtar/återställer databasen till dess senast konsistenta tillstånd efter det att något fel (t ex en krasch) medfört att databasen hamnat i ett misstänkt inkonsistent tillstånd Typer av återhämtnig Transaktionsåterhämtning Systemåterhämtning Mediaåterhämtning

Fel som kan inträffa under transaktioner Transaktionsfel t ex division med noll Exceptions t ex data för transaktion saknas, underskott Datorfel - hårdvaru-, mjukvaru-, nätverksfel Concurrency control visar att transaktionen ej kan utföras på ett korrekt sätt eller deadlock inträffar Diskfel read/write, headcrash Katastrof brand, fel tape

Repetition transaktioner En transaktion är en mängd operationer, utförda i sekvens, som tillsammans bildar en logisk enhet. BEGIN TRANSACTION ; INSERT ( { S#: 'S5', P#: 'P1', QTY:1000 } ) INTO SP ; IF any error occurred THEN GO TO UNDO ; UPDATE P WHERE P# = 'P1' TOTQTY := TOTQTY + 1000; COMMIT TRANSACTION ; GO TO FINISH ; UNDO : ROLLBACK TRANSACTION ; FINISH : RETURN ; En transaktion förflyttar databasen från ett konsistent tillstånd till ett annat konsistent tillstånd, men garanterar inte konsistens under tiden transaktionen utförs.

Systemloggen Alla transaktionsoperationer som påverkar värden på objekt i databasen loggas i en systemlogg Loggen ligger alltid på sekundärminne Innan en transaktion gör COMMIT: En commit point etableras. Vid denna säkerhetsställs att alla uppdateringar är loggade. Dessutom skrivs en commit record [commit, T] till loggen. Först därefter får uppdateringar till sekundärminnet göras (”Write ahead log rule”) När COMMIT har gjorts, garanterar systemet att alla uppdateringar är permanent lagrade Om ett fel inträffar efter COMMIT men innan transaktionens ändringar har skrivits till sekundärminne, måste transaktionen göras om (REDO) Om däremot ett fel inträffar innan en transaktion gjort COMMIT, görs alla uppdateringar ”ogjorda” (UNDO)

Caching Caching av disk-block data som skall uppdateras cachas i primärminnet datan uppdateras i primärminnet. datan skrivs tillbaka till disken. Speciellt cachningsminne för DB (DBHS cache) Ibland måste data skrivas tillbaka till disk för att lämna plats för ny data

Strategier för återskrivning In-place updating Skriver över ursprungsvärdet till samma diskutrymme (vanligast) OBS! det gamla värdet måste skrivas till loggen (som måste skriva det till disk) innan värdet uppdateras på disk The write-ahead log rule Shadowing Skriver en uppdaterad buffer till ett annat diskutrymme, vilket innebär att flera versioner av datan existerar. Gamla värdet – before image (BFIM) Nya värdet – after image (AFIM)

Strategier för återskrivning (2) no-steal - cache-info som blivit uppdaterad av en transaktion kan inte skrivas till disken innan transaktionen gjort commit steal - uppdaterad information i buffern (cache-minnet) kan skrivas innan transaktionen gjort commit. force - all information som blivit uppdaterad av en transaktion skrivs omedelbart till disken så fort en transaktion gjort commit. no-force - uppdaterad information behöver inte skrivas till disk direkt efter att en transaktion gjort commit.

Checkpoints Med bestämda mellanrum gör systemet en avstämning, en checkpoint: Alla transaktioner stoppas temporärt Innehållet i databasbuffrar som har blivit modifierade skrivs till disk En checkpoint record skrivs till loggen och loggen skrivs till disk alla transaktioner startas igen

Systemåterhämtning Två huvudsakliga tekniker används: Uppskjuten uppdatering/ deferred update Skjuter upp eventuella uppdateringar till databasen tills dess att transaktionen avslutat sin exekvering och gjort commit (no-steal) Omedelbar uppdateing/ immediate update Uppdateringar kan skrivas till databasen innan transaktionen gjort commit (”omedelbart”) (steal)

Strategi för uppskjuten uppdatering En transaktion kan inte ändra databasens innehåll förrän den gjort commit En transaktion kan inte göra commit förrän alla dess uppdateringsoperationer har blivit inskrivna i loggen och loggen har blivit skriven till disken NO-UNDO/REDO recovery algorithm

Uppskjuten uppdatering i ett fleranvändarsystem Återhämtningsprocedur Systemet använder sig av två listor, commit list och active list. commit list: här finns alla transaktioner som har gjort commit sen senaste checkpointen active list: här finns alla aktiva transaktioner (dvs de som inte hade gjort commit när systemet kraschade) Gör om (redo) alla uppdateringsoperationer som transaktioner på commit-listan gjort, i den ordning som de är skrivna i loggen Transaktioner på active list måste startas om vid ett senare tillfälle

Återhämtning Uppskjuten uppdatering i ett fleranvändarsystem (fig. 19.3)

Omedelbar uppdatering När en transaktion gör en uppdateringsoperation uppdateras databasen omedelbart. uppdateringsoperationen måste dock skrivas till loggen innan uppdateringen så att återhämtning kan ske UNDO/NO-REDO Algorithm alla uppdateringar skrivs till DB innan transaktionen gjort commit UNDO/REDO Algorithm transaktioner får göra commit innan alla dess uppdateringar skrivits till DB

Omedelbar uppdatering i ett fleranvändarsystem Återhämtningsprocedur Systemet använder sig av två listor, commit list och active list. Spola tillbaka (undo) alla uppdateringsoperationer som transaktioner på active list gjort, i omvänd ordning som de är skrivna i loggen Gör om (redo) alla uppdateringsoperationer som transaktioner på commit-listan gjort, i den ordning som de är skrivna i loggen Transaktioner på active list måste startas om vid ett senare tillfälle

Mediaåterhämtning Med ett mediafel menas att någon del av databasen har blivit fysiskt skadad Vid sådana fel måste en tidigare backup-kopia av databasen laddas in Efter det måste transaktioner som gjort COMMIT sedan kopian togs göras om (med hjälp av loggen)

Shadowing pages NO-UNDO/NO-REDO recovery algorithm alla uppdateringar görs hela tiden i en ny katalog och den gamla versionen sparas i en s.k. skuggkatalog vid fel byter man helt enkelt tillbaka till den gamla katalogen

Illustrering av Shadowing pages

Återhämtning i ett system med flera databaser Two-phase commit används om en given transaktion involverar flera "resurshanterare" t ex i ett distribuerat databassystem Om en transaktion uppdaterar två olika databaser, får det inte hända att uppdateringar görs i den ena databasen men inte i den andra

Återhämtning i ett system med flera databaser En komponent i systemet, koordinatorn, har som uppgift att garantera att båda databaserna utför samma operation (båda gör COMMIT eller båda gör ROLLBACK), även om systemet kraschar mitt i processen. Om koordinatorn bestämmer att operationen skall vara COMMIT gås två faser igenom...

Strategi för återhämtning i ett system med flera databaser Fas 1 koordinatorn instruerar alla resurshanterare att göra sig klara för att avsluta transaktionen det betyder att alla deltagare i processen måste skriva all information de har om transaktionen till loggen om detta gick bra, svarar resurshanteraren "OK", annars "not OK" till koordinatorn.

Strategi för återhämtning i ett system med flera databaser Fas 2 när koordinatorn har fått svar från alla deltagare, skriver den sitt beslut till sin egen logg om alla svar var "OK" blir beslutet "commit”, annars blir det "rollback” koordinatorn informerar sedan alla deltagare om sitt beslut, vilket de alla måste rätta sig efter

Återhämtning i ett system med flera databaser Om systemet kraschar mitt i processen, letar omstartproceduren efter koordinatorns beslut i loggen. Om den hittar det, kan processen fortsätta där den slutade. Om inte, så antas beslutet ha varit "rollback".