IT i Organisationer och databasteknik 2I1033 2002-11-05 Relationsdatabashanteringssystem RDBHS

Relationsdatabashanteringssystem Ett antal program för att möjliggöra • lagring, återvinning och uppdatering av data • behörighetskontroller • kontrollerad hantering av data för datakonsekvens • återskapande av data efter fel av olika slag • transaktionshantering • samtidig bearbetning av data utan att data förvanskas • effektivisera den interna hanteringen av data

RDBHS Optimization kap 18 Concurrency kap 19-20 Recovery kap 21 Security kap 22 Integrity (kap 7)

OPTIMERING QUERY OPTIMIZATION optimerar utsökning av information ur en databas I de traditionella databasmodellerna, hierarkiska och nätverk, måste detta överlåtas åt applikations- programmeraren. Relationsdatabashanteringssystemet har inbyggda s.k. optimizers!

Optimeraren Styrka att kunna optimera! • väljer väg • har tillgång till mer info • kan testa fler varianter • kan utnyttja kunskap som DBA, system prog. och forskare byggt in Styrka att kunna optimera! (DBMS konkurrensmedel)

Uppgift för optimeraren Minimera total accesskostnad för SQL-kommandon Bestämmer hur utsökning skall genomföras Bestämmer vilka index som skall användas Undviker eller minimerar sorteringar Bestämmer Join-strategi

Så vad är en optimerare ? Expertsystem, med kunskaper som forskare byggt in ”Svart låda” (DBMS konkurrensmedel) Optimeraren har tillgång till mer info än användaren Tabellstorlek, lagringsstruktur och index för tabellerna Statistik för tabellinnehållet defaultvärden framställd statistik (update statistics)

Frågetransformering SQL-fråga Relationsalgebra Optimering Syntaxkontroll Scanner resp parser Optimerad Relationsalgebra Syntaktisk korrekt SQL-fråga Strategival Validering Exekveringsplan Giltig SQL-fråga Interpreterad Kompilerad Kodgenerering Översättning Query tree eller Query graph Kod

Sökstrategier 1. Sekvensiell genomsökning (scanning) 2. Binärsökning 3. Hashad nyckel eller primärindex (= PK) för enstaka rad 4. Primärindex för flera rader (> PK eller < PK) 5. Klustrat index för flera rader (> attr med klustr index) 6. B*-index som sekundärt index 7. Sökning med sammansatta index 8. Snitt av index (matchning av postpekare)

JOIN-strategier! 1. Nested loop 2. Använda index eller hashnyckel 3. Sort-merge join 4. Hash-join

Nested loop Slutsats: Välj den minsta tabellen som "yttre loop". Alt 1: Alla rader i R1 jämföres med alla rader i R2: 4 + 4 * 8 = 36 rader läses Alt 2: Alla rader i R2 jämföres med alla rader i R1: 8 + 8 * 4 = 40 rader läses R1 R2 A B C D 1 C 3 D 4 C 6 B 7 A 9 A 12 C 14 B Slutsats: Välj den minsta tabellen som "yttre loop". OBS: I verkligheten är "filerna" förstås blockade

Använda index eller hashnyckel Effektiv när det gäller att göra join på två tabeller när man söker ett fåtal värden. (Matchning PK - FK) Den ena tabellen läses i sin helhet och joinattributet (ofta Främmande nyckeln) användes för att läsa den andra tabellens rader en i taget med hjälp av index eller hashing. R2 R1 1 C 3 D 4 C 6 B 7 A 9 A 12 C 14 B A B C D R1 läses radvis, och för varje rad användes R2´s primärindex för att läsa motsvarande rad i R2. Resultatet hamnar i en resultat-buffert i primärminnet

Sort-Merge join Alla ingående tabeller måste vara sorterade på samma attribut En mycket effektiv metod om hög "träffgrad" väntas. Inledande sorteringar + sort-merge realistiskt alternativ

Hash JOIN Båda tabellernas rader läggs in i samma minnesbuffert med hjälp av en hashalgoritm som appliceras på join-attributen. Tabellernas rader kan vara i godtycklig ordning. Fördel att båda tabellerna bara läses en gång. Om mellanresultatet blir så stort att det inte ryms i PM är metoden ej effektiv.

Heuristisk optimering optimerad relationsalgebra  kundnamn, kundadress Tag fram namn och adress för alla kunder som beställt bokhyllan POMPE (artnr 105436-8)  artnr = 105436-8  |X| kundnrnr KUND |X| ordernr ORDER ORDERRAD

Optimerat träd     Tag fram namn och adress för alla kunder som beställt bokhyllan POMPE (artnr 105436-8)  kundnamn, kundadress |X| kundnrnr  Kundnr, kundnamn, kundadress |X| ordernr KUND  Ordernr, kundnr  Ordernr  artnr = 105436-8 ORDER ORDERRAD

Tumregler 1. Gör SELECT så tidigt som möjligt! Utnyttja "lagarna" för att föra selektionen så långt ned i trädet som möjligt 2. Gör PROJECT tidigt! Utnyttja "lagarna" för att föra projektionen så långt ned i trädet som möjligt 3. Minimera mellanresultat! Använd associativa lagen så att den selection som ger minsta mellanresultatet utföres först 4. Gör JOIN först när det är nödvändigt

Relationsalgebraiska lagar 1. Associativa lagen (R * S) * T = R * (S * T) 2. Kommutativa lagen R * S = S * R 3. Distributiva lagen (Cascades) u(R * S) = u(R) * u(S) Läroboken visar de olika lagarna med exempel

Vad kostar en fråga? Optimeringen görs inte enbart med hänsyn till heuristiska regler. Kostnaden uppskattas för olika alternativ så att den billigaste frågestrategin kan väljas. • Access-kostnad till sekundärminne - typ av access-struktur index klustrade index • Lagringskostnad för mellanresultat • Bearbetningskostnad sortering, sökning, join, beräkningar

Statistik Optimeraren måste ha statistikuppgifter för att kunna sköta jobbet! Antal rader per tabell (kardinalitet) Radlängd Antal olika värden i en kolumn (selektivitet) Max/Min-värden inom en kolumn DATA DICTIONARY (Systemkatalogen) av avgörande betydelse för optimeraren

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!

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 konsistent läge ABORT återställer databasen till läget före BEGIN TRANSACTION

A C I D Krav på DBMS A Atomicity (transaktionen är atomär) C Concistency (koncistensen skall vidmakthållas) I Isolation. Varje transaktion verkar köras isolerad D Duration. Oavsett om olika fel inträffar skall resultatet av en rätt utförd transaktion bestå*. * Kan dock ändras med kompensationstransaktion

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.

Den förlorade uppdateringen Trans A tid Trans B Läs Tal = 20 = 20 Läs Tal Add 50 = 70 = 0 Sub 20 Skriv Tal = 70 = 0 Skriv Tal Värdet i databasen för Tal = 0. Korrekt värde skall vara 50! (20 +50 -20)

Beroende till en backad trans Trans A tid Trans B = 20 Läs Tal = 70 Add 50 Läs Tal = 70 = 20 ROLLBACK Trans A ser data som "aldrig existerat"! (s.k. ”dirty data”)

Beroende till en backad trans Trans A tid Trans B = 20 Läs Tal = 70 Add 50 Läs Tal = 70 Add 20 = 90 = 20 ROLLBACK Trans A opererar på data som "aldrig existerat"!

Locking protocol Läslås Shared Lock (PS) Skrivlås Exclusive Lock (PX) 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

Locking protocol Läslås Shared Lock Shared lock sättes på ett objekt som skall läsas. Andra transaktioner tillåts att läsa objektet Skrivlås Exclusive Lock Exclusive lock sättes på ett objekt som skall skrivas. Andra transaktioner får ej tillgång till objektet

Scheduler producerar exekveringsplan Scheduler ställer upp en Conflct-graph (konflikt-graf, precedensgraf) T2 T1 T4 T3 Seriell ordning: T1 - T3 - T2 - T4

Two-Phase Locking (2PL) Alla transaktioner följer följande regler: I. Innan den opererar på något objekt sätter den ett lås på objektet II. Efter att 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

Serialiserbarhet Def: En given interfolierad exekvering av ett antal transaktioner är serialiserbara 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 korrekt i sig Transaktionerna är logiskt oberoende av varandra

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 skrivlås samtidigt efter commit.Rigorous 2PL håller samtliga lås tills commit.

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 T1 T4 T2 T3

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

Låsningsgranularitet Granularitet = storlek på objektet man låser Databas Tabell Tablespace (eller motsvarande) 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

Level of Isolation 1. "Dirty read" Låt denna process se dirty data 2. Committed read Låt inte denna process se dirty data 3. Cursor stability Låt ingen annan uppdatera min rad som är "current" 4. Repeatable read Låt ingen annan uppdatera någon av de rader jag sett förrän jag är klar

Två huvudsakliga metoder Pessimistiska protokoll som antar att konkurrerande uppdateringar sker frekvent. Metod för att hantera konkurrensen innefattar ofta tidsstämpling Optimistiska protokoll som utgår ifrån att konflikter är sällsynta

Time-stamping Lösning: Återstarta den begärande transaktionen • varje transaktion stämplas. • varje dataelement (sida) har två stämplar, en läs- och en skrivtid. (När sidan senast lästes eller skrevs) • konflikt uppstår när en transaktion vill - se en post som en yngre trans uppdaterat - uppdatera en post som redan setts eller uppdaterats av en yngre trans Lösning: Återstarta den begärande transaktionen

Undvika deadlock En transaktion Ta försöker låsa X som är låst av Tb wait-die: Om Ta är äldre än Tb så får Tavänta , annars så backas Ta ut och startas om senare med oförändrad tidsstämpel wound-wait: Om Ta är äldre än Tb så backas Tb ut och startas om senare med oförändrad tidsstämpel

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”

Intent locking Ett protokoll för INTENT LOCKING medger att sätta 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 tabeller. Om nödvändigt kommer Intent lock att escalera i granularitet Kompatibilitetsmatris IS IX S SIX X 1 1 1 1 0 1 1 0 0 0 1 0 1 0 0 1 0 0 0 0 0 0 0 0 0 IS IX S SIX X

Recovery (Återskapande) Recovery handlar om återskapande av data efter olika slags fel. • systemkrasch • mediakrasch • systemfel • programfel • ”DBMS-fel” (t ex deadlock, triggers) DBMS förutsätts stödja olika typer av "loggar"

Logg Before Back-up After Databas Logg 2 Back-up (UNDO) 1 3 5 After Databas 4 (REDO) Logg 1 och 2 före bearbetning 3 - 5 efter bearbetning Loggar användes vid rcovery (återskapande) av databasen

Å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

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!

Systemloggen Varje transaktion tilldelas en unik systemgenererad identifikation. Systemloggen finns på disk men kopieras ofta ut till band eller skuggskrivs eller speglas på flera ställen. Systemloggen innehåller t ex följande info: [start_transaction,T]: Start för transaktion T [write_item,T,X,old_value,new_value]: Gammalt och nytt värde för "item" X. Värdet på X ändrat av T. [read_item,T,X]: T har läst värdet på "item" X [commit,T]: T har avslutats felfritt och av T gjorda uppdateringar kan permanentas till disk. [abort,T]: T har avbrutits

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

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

System-krasch Time tc tf T1 T2 T3 T4 T5 checkpoint time failure time

Å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

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

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

Security Säkerhet: Koncistens: Att endast behöriga kommer åt data i databasen! Koncistens: Att vad som görs är rätt d v s att data alltid är korrekta!

Säkerhet SPECIELLT FÖR DATABASER: VEM SKALL FÅ GÖRA VAD ? Fysiskt: Lås, kortläsare, behörighetsområde Policy: Vem skall ha behörighet till access av data Password: Underhåll av lösen Hårdvarusäkerhet: Underhållsavtal SPECIELLT FÖR DATABASER: VEM SKALL FÅ GÖRA VAD ?

VEM? Lösenord, auktorisation, användar- definierade procedurer Behörighetskontroll VEM? Lösenord, auktorisation, användar- definierade procedurer VAD? Views*, auktorisation, kryptering HUR? Behörighetsmatris, klassificering, statistiska databaser * views motsvaras i ACCESS av frågeresultat

Datorbaserade kontroller Identifikation (Autenticitet) Aktorisation Vyer Kryptering

Authentification En mekanism som avgör om en användare är den han/hon utger sig för lösenord röstanalys fingeravtryck ögonbottenanalys (användes ej p g a risk för ögonskador) mönstermatchning kort med PIN-kod

Behörighet Det finns två behörighetsnivåer: Account level Bestämmer vad en användare får göra oberoende av tabeller. T ex skapa en ny databas, skapa vyer, ändra tabeller m m Relation level Bestämmer vilka tabeller och/eller vyer en användare har tillgång till och vad användaren får göra

Aktorisation GRANT privilege_list ON object … TO subject … Bestämmer vad ett SUBJEKT får göra med ett OBJEKT GRANT privilege_list ON object … TO subject … [WITH GRANT OPTION] SUBJECT kan vara användare, grupper och roller OBJECT kan vara databas, tabeller, vyer, procedurer, applikationer

Insert [ (column [, column] … ) ] Update [ (column [, column] … ) ] GRANT, priveleges GRANT privilege_list ON object … TO subject … All Select Delete Insert [ (column [, column] … ) ] Update [ (column [, column] … ) ] References [ (column [, column] … ) ]

Grant GRANT Select On ANSTÄLLD TO Bosse GRANT Update (Saldo) ON KUND TO Sonja, Stig GRANT All ON ARTIKEL TO PUBLIC GRANT Insert ON KUND TO Ada, Beda, Osborn WITH GRANT OPTION GRANT Reference (Säljarnr) ON KUND TO Oscar

REVOKE REVOKE privilege_list ON object … FROM authorization_id_list [RESTRICT | CASCADES] Revoke tar tillbaka given behörighet CASCADES medför att även underliggande vyer tas bort RESTRICTED innebär att behörigheten inte kan tas tillbaka om det finns underliggande vyer. REVOKE tar bort behörigheten även för dem som fått den m h a WITH GRANT OPTION.

VIEW med CHECK OPTION CREATE VIEW artikel AS SELECT * FROM PRODUCT WHERE färg IN (’Gul’, ’Röd’, ’Grön’) AND pris > 500 AND pris < 1000; All uppdatering sker mot vyn som då inte kommer att acceptera rader som inte har godkända värden i färg resp pris.

Audit Audit - dels loggning, dels systemgenererade kontroller - garantera korrekta indata - garantera korrekta körningar - Upptäcka och förebygga programfel - Dokumentera programunderhåll och exekvering - Förhindra icke-aktoriserade programändringar - Logga åtkomst och begäran om åtkomst till data -Garantera att dokumentationen uppdateras

DBMSs and Web Security Proxy servers Firewalls Digital signatures Message digest algoritms and sigital signatures Kerberos SSL Secure socket layer and SHTTP Secure HTTP

Kontrollerad hantering av data för datakoncistens Integrity Domän Entity integrity Referential integrity (+ foreign key business rules) Olika bearbetningar kan förses med regler (triggers) Data i databasen liksom hanteringen av den måste följa givna regler

Integrity Enhancement Feature ISO 1992 Required Data Domain constraint Entity integrity Referential integrity Enterprise constraint

Domän CREATE DOMAIN domain-name [AS] data-type [DEFAULT default-option] [CHECK (search-condition)] Ex) CREATE DOMAIN kön AS CHAR(1) CHECK (VALUE IN (’M’, ’K’)); Ex) CREATE DOMAIN ktyp AS VARCHAR(5) CHECK (VALUE IN (SELECT kundtyp FROM kategori));

TRIGGERS EVENT - CONDITION - ACTION CREATE TRIGGER Trigger_name BEFORE | AFTER <trigger_event> ON >table_name> [REFERENCING <old_or_new_values_alias_list> ] [FOR EACH ROW | STATEMENT ] [WHEN (trigger_condition) ] <trigger_body> EVENT - CONDITION - ACTION

Triggers medför dock ... Komplexitet: När funktionalitet flyttas från applikationen till databasen blir DBA mer komplext Dold funktionalitet: Om funktionaliteten flyttas till en eller flera triggers döljs funktionaliteten från användaren. Det är mestadels positivt, men kan ha motsatt effekt, eftersom användaren inte längre har kontroll över vad som sker. Overhead: Triggers i ”högfrekventa” transaktioner kan förorsaka problem under högtrafik.