17. Fejl-håndtering1 Fejl-håndtering 17. Coping With System Failures.

Præsentationer af emnet: "17. Fejl-håndtering1 Fejl-håndtering 17. Coping With System Failures."— Præsentationens transcript:

1 17. Fejl-håndtering1 Fejl-håndtering 17. Coping With System Failures

2 17. Fejl-håndtering2 Fejl-håndtering, intro., 875 Fejl sker, men data må ikke forsvinde! Teknik –Lav backup af data. kan genskabe data som de var på backup- tidspunktet –Alle vigtige begivenheder skrives i log. kan genskabe data efter backup-tidspunktet.

3 17. Fejl-håndtering3 Fejl-typer, 876 Forkert indtastning –svært at detektere –referentiel integritet (fremmednøgler skal peget på noget) kan mindske antallet af forkerte indtastninger. Medie fejl (dårlig harddisk) –indlæs backup kopi –flere online-kopier af data (det har bankerne) System fejl (strømsvigt og lign) –data i RAM tabt –systemet genstartes –igangværende transaktioner skal håndteres

4 17. Fejl-håndtering4 Transaktioner, 878 Enhed for logisk arbejde på en database. ACID-reglerne Transaction manager (del af DBMS) –sørger for at transaktioner udføres i overensstemmelse med ACID-reglerne –Fig. 17.1, side 878

5 17. Fejl-håndtering5 Database "elementer", 879 En database består af "elementer" –Relationer (tabeller)STOR –Disk-blokke (pages) –Individuelle tupler (rækker)LILLE Læsninger / skrivninger af data udføres oftest på hele disk-blokke. Disk-blokke opbevares midlertidigt i buffer i RAM –for langsomt at bruge disk hele tiden.

6 17. Fejl-håndtering6 Database-operationer, 880 1.Input(X) Kopier disk-blok indeholdende element X fra disk til RAM. 2.Read(X, t) Kopier database-elementet X til den lokale variable t 3.Write(X, t) Kopier indholdet af den lokale variable t til database- elementet X 4.Output(X) Kopier disk-blok med X fra buffer til disk. Generel antagelse: Et database-element kan være i en enkelt disk-blok.

7 17. Fejl-håndtering7 Transaktioner i operations- perspektiv, 882 En transaktion kan anskues som en sekvens af database-operationer. Flere samtidige transaktioner kan give mange interleavings (indflettede sekvenser af database-operationer) –Eksempel 17.1, side 882-883 –Forskellige interleavings kan give forskellige resultater (database-tilstande)!

8 17. Fejl-håndtering8 Logging, 884 En log er en sekvens af log records. Hver log record indeholder information om 1 database-operation. Log gemmes på et separat medium –ikke sammen med data Log bruges til recovery efter crash. Forskellige typer logging –undo logging –redo logging –undo / redo logging

9 17. Fejl-håndtering9 Undo logging, 884 Transaktioner, der er i gang under et crash, skal undo ved recovery. Typer af log records – start på ny transaktion – opdatering: Transaktionen T har tildelt database- elementet X en ny værdi. Den gamle værdi var v.

10 17. Fejl-håndtering10 Undo logging regler, 886 skal skrives i log før X opdateres fysisk på disken. skal skrives i log efter alle opdateringer er fysisk på disk. Fig. 17.3, side 887

11 17. Fejl-håndtering11 Undo logging recovery, 889 Der er sket et crash og nu skal recovery manager i gang med recovery: –Nogle opdateringer er skrevet til disk andre er ikke. –Database skal bringes tilbage til en konsistent tilstand. Alle ufærdige transaktioner skal undo'es. –Find alle ufærdige transaktioner Søg i log efter uden matchende Gen-etabler gammel værdi fra Loggen læses bagfra (nyeste først) Log: som afslutning på hidtil ufærdige transaktioner Eksempel fig. 17.3, crash efter (12)

12 17. Fejl-håndtering12 Undo logging: Crash under recovery, 891 Crash kan ske når som helst –også under recovery Recovery må være idempotent –idem: det samme –potent: kraft –samme effekt, uanset hvor mange gange recovery udføres

13 17. Fejl-håndtering13 Undo logging: Checkpointing, 890 Problem –Tidskrævende at gennemgå hele loggen efter crash. Løsning: Checkpointing –Alle transaktioner afsluttes og skrives til disk + i log. –Recovery: Skal kun læse log (bagfra) indtil –Problem: DBMS skal stoppes under checkpointing –Løsning: Checkpointing med udstrækning i tid (så igangværende transaktioner kan stoppe - og nye starte)

14 17. Fejl-håndtering14 Redo logging, 897 Problem med undo logging: –commit: Alle opdateringer skal skrives på disk tager tid! Løsning: Redo logging –Ide: Genskabe resultat af committed transaktioner, der ikke er skrevet til disk. –Regel: og skal skrives i log før X opdateres på disk. v er nu den nye værdi! –Fig. 17.7, side 898

15 17. Fejl-håndtering15 Redo logging: Recovery, 898 Ufærdige transaktioner (intet ) har intet skrevet til disk –Behandles som om de aldrig eksisterede. : Transaktion er muligvis skrevet til disk. –skal redo'es –log læses forfra (ældste først)

16 17. Fejl-håndtering16 Redo logging: Checkpointing, 900 Problem: –Committed transaktion kan skrives til disk lang tid efter commit. –Dirty buffer: Buffer med data, der er opdateret, men ikke skrevet til disk. –Buffer manager skal holde styr på dirty buffers

17 17. Fejl-håndtering17 Ulemper ved undo og redo logging, 903 Undo logging –data skal skrives til disk straks efter commit. –meget disk I/O (tager tid) Redo logging –data skal holdes i buffer indtil commit –kræver meget buffer Løsning –kombination af undo og redo logging!

18 17. Fejl-håndtering18 Undo / redo regler, 903 Opdatering – vgammel værdi (til undo) wny værdi (til redo) skal skrives på disk før opdateringer skrives til disk. Eksempel 17.10, fig. 17.9, side 904

19 17. Fejl-håndtering19 Undo / redo recovery, 904 Redo alle committed transaktioner –forfra i loggen Undo alle ufærdige transaktioner –bagfra i loggen

20 17. Fejl-håndtering20 Log vs. backup, 909 Logging beskytter mod –crash, der ødelægger data i buffer (RAM) strømafbrydelse –log kunne i princippet bruges til at genskabe alle data, men det kræver at log aldrig slettes - og det vil tage meget tid. Backup beskytter mod –crash, der ødelægger data på disk dårlig harddisk

21 17. Fejl-håndtering21 Backup, 909 Kaldes archive i bogen. Kopi af data. Opbevares et andet sted end data. 3 typer backup –Total: Alle data kopieres. –Inkrementel: Kun data, der er ændret siden forrige inkrementelle backup, kopieres. –Kombination: Total backup f.eks. 1 gang om ugen, og inkrementel backup hver dag. Backup tages bedst med et stoppet system, men kan også tages på et kørende system.

22 17. Fejl-håndtering22 Recovery med backup, 913 Indlæs nyeste totale backup. Indlæs inkrementelle backups efter denne. Brug log til redo / undo af de nyeste data.