Relationsdatabashanteringssystem RDBHS

Transkript

1 Databasteknik 2I1075, 2I1104 Relationsdatabashanteringssystem RDBHS Silberschatz-Korth-Sudarshan kapitel Administration Ad Ministra = Att styra Administration allmänt sett: Planera Organisera Leda Samordna Kontrollera 2 1

2 Företagets resurser Personal Maskiner Material Pengar DATA 3 Databasadministrationen är en funktion inom företaget som är ansvarig för databasens underhåll och all omgivande miljö: Människor Säkerhet Tekniska funktioner Standards Dokumentation m.m. 4 2

3 Databasadministratör DBA-ansvar: Vilken info skall finnas Vilka kontroller skall finnas Lagringsformer Säkerhet (Backup och loggning) Kontrollera prestanda Trimma databasen Behörighetskontroll Service mot användarna 5 Relationsdatabashanteringssystem Ett antal program för att möjliggöra lagring, återvinning och uppdatering av data behörighetskontroller kontrollerad hantering av data för datakoncistens återskapande av data efter fel av olika slag transaktionshantering samtidig bearbetning av data utan att data förvanskas effektivisera den interna hanteringen av data 6 3

4 RDBHS Optimization Concurrency Recovery Security Integrity 7 Transaktionshantering Vad är en transaktion? Internt: allt 'jobb' som en användares atomära transaktion genererar Exempel Flytta pengar från konto A till konto B Läs konto A, finns pengar?, subtrahera belopp, skriv A, läs B,addera belopp, skriv B DBMS-krav: Allt eller inget! 8 4

5 Databastransaktion Logical Unit of Work Före transaktionens start är databasen i consistent state Under transaktionen är databasen i inconsistent state Transaktionen kan avslutas på två sätt: COMMIT eller ABORT COMMIT för databasen till ett nytt konsekvent läge ABORT återställer databasen till läget före BEGIN TRANSACTION 9 Transaction state Partially committed committed active failed aborted Fig

6 A C I D Krav på DBMS A C I D Atomicity (transaktionen är atomär) Concistency (koncistensen skall vidmakthållas) Isolation. Varje transaktion verkar köras isolerad Duration. Oavsett om olika fel inträffar skall resultatet av en rätt utförd transaktion bestå. 11 Transaktion Exempel: Registrera en order om X antal av artikel Y för kund Z! Internt: - Läs Y - finns X st Y i lager? - läs Z - är Z kreditvärdig för X*Y kronor? - i så fall minska krediten med motsvarande belopp - minska antal i lager för Y med X! - skriv tillbaka Y och Z OBS!!!! En transaktion är atomär, dvs odelbar 12 6

7 Concurrency Parallellitetsstyrning, handlar om att skydda data i databasen från skadlig påverkan av interfolierande (samtidiga) transaktioner. Löses med hjälp av lås. 13 Den förlorade uppdateringen Trans A tid Trans B Läs Tal = 20 Add 50 = 70 Skriv Tal = 70 = 20 Läs Tal = 0 Sub 20 = 0 Skriv Tal Värdet i databasen för Tal = 0. Korrekt värde skall vara 50! ( ) 14 7

8 Beroende till en backad trans Trans A tid Trans B Läs Tal = 70 = 20 Läs Tal = 70 Add 50 = 20 ROLLBACK Trans A ser data som "aldrig existerat"! (s.k. dirty data ) 15 Beroende till en backad trans Trans A tid Trans B Läs Tal = 70 Add 20 = 90 = 20 Läs Tal = 70 Add 50 = 20 ROLLBACK Trans A opererar på data som "aldrig existerat"! 16 8

9 Locking protocol Läslås Shared Lock (PS) Shared lock sättes på ett objekt som skall läsas. Andra transaktioner tillåts att läsa objektet Skrivlås Exclusive Lock (PX) Exclusive lock sättes på ett objekt som skall skrivas. Andra transaktioner får ej tillgång till objektet 17 Serialiserbara transaktioner Def: En given interfolierad exekvering av ett antal transaktioner är serialiserbar om och endast om den producerar samma resultat som en seriell exekvering av samma transaktioner Korrekthetsvillkor: En given interfolierad exekvering av ett antal transaktioner är korrekt om den är serialiserbar Varje transaktion är är korrekt i i sig Transaktionerna är är logiskt oberoende av av varandra 18 9

10 Scheduler producerar exekveringsplan Scheduler ställer upp en Conflct-graph (konflikt-graf, precedensgraf) T2 T1 T4 T3 Seriell ordning: T1 -T3 -T2 -T4 19 Two-Phase Locking (2PL) Alla transaktioner följer följande regler: I. I. Innan den opererar på pånågot objekt sätter den ett lås på påobjektet II. Efter att ha ha släppt ett lås begär den aldrig några nya lås Detta medför att alla interfolierade exekveringar av sådana transaktioner är serialiserbara 20 10

11 Two-Phase Locking De två faserna är: - en växande fas, där låsen begäres - en krympande fas, där låsen släpps antal lås transaktionens tid Flera varianter av 2PL finns. De vanligaste är basic 2PL (ovan), Conservative 2PLsom sätter alla sina lås samtidigt och Strict 2PL som släpper alla sina lås samtidigt efter commit. 21 Deadlock Ett system som tillämpar låsning riskerar DEADLOCK. Systemet måste ha en rutin för att upptäcka DEADLOCK. I regel går detta till så att systemet har en väntegraf (Wait-for-graph) WFG som man analyserar för att upptäcka om det finns cykler i grafen. Vanligtvis sker analysen antingen när någon begärt ett lås men satts på väntelista eller annars periodiskt T 1 T 4 T 2 T

12 Lösa deadlock En transaktion utses till "offer" och rullas ut för senare återstart. Man väljer t ex den yngsta den som har minst antal lås den som gjort minst antal uppdateringar den som har mest kvar Passa "starvation", dvs att samma trans väljs som offer under lång tid. Tid är vanligast p g a rättvisekrav 23 Låsningsgranularitet Granularitet = storlek på objektet man låser Databas Tabell Tablespace (db2) Sida Rad Systemet kan alltid låsa en större enhet än vad som är logiskt nödvändigt Systemet kan alltid hålla låsen längre än vad som är logiskt nödvändigt 24 12

13 Intent locking Ett protokoll för INTENT LOCKING sätter INTENT lock på en högre granularitet. IX (intent exclusive) på en tabell betyder att det finns X-lås på t ex en sida eller på rader inom tabellen. FILER TABLE-SPACE SIDOR TABELLER RADER o DATABAS o IX oix o o o IX o oix o o oix o o o o ox-lås o o X- och S-lås får inte sättas förrän alla föregångare i hierarkin satt IX- resp IS-lås. 2PL gäller förstås. 25 Optimistisk metod En transaktion begär att en datasida läses in i UWA (User Working Area) Uppdaterande data sparas också i UWA. Uppdatering sker i en lokal kopia i UWA Lås begäres på sidan Sidan läses in och kontrolleras mot sidan i UWA Om den ser likadan ut så har ingen mellankommande transaktion uppdaterat sidan och den lokala kopian kan skrivas till databasen Om den är förändrad så gör man om hela proceduren men nu med den uppdaterade sidan som original Alltså: Läs A spara i B och C Uppdatera C Lås A Läs A Om A = B så skriv ut den uppdaterade sidan C, släpp låset Annars släpp låset och spara A i B och C och börja om 26 13

14 Timestamping varje transaktion stämplas konflikt uppstår när en trans vill - se en post som en yngre trans uppdaterat - uppdatera en post som redan setts/uppdaterats av en yngre trans lösning: Två protokoll: Wait-Die Om A > B väntar A, annars dör A (roll-back) Wound-wait Om A > B såras (dödas) B, annars väntar A 27 Timestamp Ordering Timestamp ordering säkerställer att alla konflikterande läs- och skrivoperationer görs i tidsordning (timestamp order) Antag att T i begär läs(q) Om TS(T i ) < W-timestamp(Q), så betyder det att T i skulle behöva läsa ett värde på Q som är överskrivet. T gör ROLLBACK! Om TS(T i ) > W-timestamp(Q) så utföres läsningen och R-timestamp får den högsta timstamp av TS(T i ) och R-timestamp(Q) Antag att T i begär skriv(q) Om TS(T i ) < R-timestamp(Q), så betyder det att Q har lästs av en annan transaktion. T gör ROLLBACK! Om TS(T i ) < W-timestamp(Q) så betyder det att T i vill skriva ett gammalt värde på Q och T i gör ROLLBACK! Annars exekveras skrivoperationen och W-timestamp(Q) får den högsta timstamp av TS(T i ) och W-timestamp(Q) T som gör ROLLBACK får en ny tidsstämpel och startas om! 28 14

15 Recovery (Återskapande) Recovery handlar om återskapande av data efter olika slags fel. systemkrasch mediakrasch systemfel programfel DBMS förutsätts stödja olika typer av "loggar" 29 Logg Back-up 2 Before (UNDO) 1 3 Databas 5 4 After (REDO) Logg 1 och 2 före bearbetning 3-5 efter bearbetning Loggar användes vid rcovery (återskapande) av databasen 30 15

16 Återskapande av vad? Ett koncistent nuläge oavsett störningar (ROLLFORWARD) Total recovery Back-up + after image Selektiv recovery Translogg, buffertar Ett tidigare koncistent läge ROLLBACK before image, translogg, buffert 31 Felaktiga program En transaktion måste backas och sedan startas om Transaktion = LUW Logic Unit of Work 32 16

17 Mediakrasch Databasen måste återskapas genom att ladda senaste backup-kopian av databasen. Med hjälp av loggen omstartas korrekt avslutade transar. Om "after-image-log" finnes kopieras den in i senaste backup-kopian Utbackning krävs ej! 33 System-krasch För att skydda systemet från verkan av av system-krasch sätts systemgenererade checkpoints, t ex ex med jämna tidsintervaller. Time pc tc T1 T2 T3 T4 T5 wait wait prepare checkpoint checkpoint Systemet väntar tills alla pågående transaktioner avslutas och tillåter inga nya transaktioner att starta. När allt är "lugnt" tas en checkpoint 34 17

18 Sofistikerad Checkpoints (synchpoint, breakpoint) Töm alla buffertar till disk (databasen) Skriv en "check-point"-post på logg-tapen Alla aktiva processers status skrivs i "loggposten" Skriv loggpostens adress (läge) på logg-tapen i en särskild återstartspost på disk 35 System-krasch Time tc tf T1 T2 T3 T4 T5 checkpoint time failure time 36 18

19 Återstart med hjälp av check-point 1. Lägg alla aktiva transaktioner vid CP i en UNDO-lista. Skapa en tom REDO-lista. 2. Sök framåt i loggen från CP 3. Om en BEGIN TRANSACTION påträffas läggs den i UNDO-listan 4. Om COMMIT påträffas flyttas transen från UNDO till REDO-listan 5. När recovery-processen nått slutet på loggen söker den bakåt i loggen och backar ut transarna på UNDO-listan 6. När checkpoint-postens början nåtts så går CP-processen framåt igen och gör om transarna på REDO-listan 37 Olika strategier för loggning/dumpning Spegling (dubblering) av data Skuggskrivning (Shadowing) av data Periodisk "dumping" av data - all data - endast data som uppdaterats (inkrementell dump) - endast data som inte uppdaterats ( residual dump) Loggning av transaktioner Loggning av förändringar - före ändring - efter ändring - både före och efter ändring 38 19

20 Deferred update Deferred update (fördröjd uppdatering) innebär att den fysiska databasen aldrig uppdateras förrän man nått COMMIT. All uppdatering mot databasen sker i en minnes-buffert. När COMMIT gjorts skrivs de gjorda uppdateringarna först på logfilen Därefter permanentas uppdateringarna i databasen. I detta läge finns det inget behov av UNDO 39 Immediate update Immediate update (omedelbar uppdatering ) innebär att uppdatering av databasen sker utan att invänta COMMIT. De gjorda uppdateringarna skrivs alltid på logfilen före uppdatering i databasen För att möjliggöra recovery behövs både UNDO och REDO 40 20