DAV B04 - Databasteknik
description
Transcript of DAV B04 - Databasteknik
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".