1 / 23

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

woody
Download Presentation

DAV B04 - Databasteknik

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  18. Illustrering av Shadowing pages

  19. Å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

  20. Å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...

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

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

  23. Å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".

More Related