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;IF any error occurred THEN GO TO UNDO ;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

1. data som skall uppdateras cachas i primärminnet

2. datan uppdateras i primärminnet.3. 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

1. En transaktion kan inte ändra databasens innehåll förrän den gjort commit

2. 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

1. 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)

2. Gör om (redo) alla uppdateringsoperationer som transaktioner på commit-listan gjort, i den ordning som de är skrivna i loggen

3. 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

1. Systemet använder sig av två listor, commit list och active list.

2. Spola tillbaka (undo) alla uppdateringsoperationer som transaktioner på active list gjort, i omvänd ordning som de är skrivna i loggen

3. Gör om (redo) alla uppdateringsoperationer som transaktioner på commit-listan gjort, i den ordning som de är skrivna i loggen

4. 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".