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

DAV B04 - Databasteknik