DBS22 Databasegjenopprettingsteknikker
|
|
- Leif Isaksen
- 7 år siden
- Visninger:
Transkript
1 Side 1 for Databaser DBS22 Databasegjenopprettingsteknikker onsdag 1. juni Pensum: , side Gjenopprettingskonsepter Recovery outline and categorization of recovery algorithms Gjenoppretting betyr typisk at databasen er gjenopprettet til en tidligere konsistent tilstand før en feil. Informasjon for å kunne utføre gjenoppretting er typisk bevart i systemloggen. Typisk strategi: 1) Hvis det er stor skade på databasen, gjenopprettes en kopi fra en back up (for eksempel magnetisk tape), og operasjoner fra en back-up av systemloggen blir gjort på nytt av. 2) Hvis disken ikke er fysisk skadet, er gjenopprettingsstrategien å identifisere endringer som forårsaker inkonsistens. Punkt (2) kan deles to fremgangsmåter: Utsatt oppdatering (deferred update) Oppdateringer blir ikke lagret på disk før etter commit, men blir lagret persistent i systemlogg. No-undo/redo. Trenger ikke undo siden ingenting er endret i databasen ved abort. umiddelbar oppdatering (immediate update). Operasjoner kan bli skrevet til disk før commit, men da må de også logges i systemloggen med force-writing først. Undo/redo. Undo/no-redo. Alle operasjoner må skrives til disk før commit. Undo/redo må være idempotent, at utføring av en operasjon flere ganger er det samme som å utføre den bare én gang Caching (buffering) av disk-blokker DBMS-cachen holder styr på buffer og diskblokker. Hver buffer har en dirty bit som sier om blokken i bufferet er endret eller ikke (1 = endring), og en pinunpin bit som sier om man får lov å skrive blokken tilbake til disk. Kun buffer der dirty bit er 1 skal skrives tilbake til disk, og det er to metoder: In-place oppdatering. Blokken blir skrevet tilbake til samme plass den var før. Shadowing. Blokken blir skrevet tilbake til en ny plass, så man har flere versjoner av dataelementene Write-ahead logging, steal/no-steal, force/no-force BFIM - before image, verdien et dataelement hadde før oppdatering. AFIM - after image, verdien et dataelement har etter oppdatering. Write ahead-logging. Sørg for at BFIM blir logget, og loggen blir skrevet til disk før BFIM blir overskrevet av AFIM på disk. I logger som skal brukes til REDO, trenger man AFIM og i logger som skal brukes til UNDO trenger man BFIM. Man har typisk også buffer til loggfilblokker og indeksfilblokker. Det er typisk satt av buffer til n loggfilblokker, og en loggfilblokk må skrives til disk før en endret blokk kan skrives til disk med write-ahead.
2 Side 2 for Databaser No-steal. Hvis en oppdatert blokk ikke kan skrive tilbake til disk før transaksjonen committer. Pin-unpin settes til 1 (så blokken ikke blir byttet ut). Undo trengs ikke Steal. Hvis en oppdatert blokk kan skrives tilbake til disk før en transaksjon committer. Da trengs også undo. Man unngår behovet for masse bufferplass. Undo trengs. Force approach. Hvis alle oppdaterte blokker blir skrevet til disk umiddelbart, før transaksjonen committer. Redo trengs ikke No-force. Ikke force approach. En blokk kan fortsette å være i minnet, så andre transaksjoner kan bruke den. Reduserer I/O. Redo trengs. Mange databaser følger en Steal/No-force-fremgangsmåte Sjekkpunkter i systemloggen og "fuzzy checkpointing" Et sjekkpunkt er også med i systemloggen. Når man tar sjekkpunkt, lagres en post [checkpoint, liste med aktive transaksjoner] i loggen. Et sjekkpunkt består av følgende handlinger: 1) Pause transaksjoner midlertidig 2) Force-write alle buffer som er endret til disk 3) Skriv en [checkpoint]-post til loggen, og force-write loggen til disk. 4) Start transaksjoner igjen. Resultatet er at alle transaksjoner som har [commit, T] i loggen før et sjekkpunkt ikke trenger å skrives på nytt av. Det er en liste med aktive transaksjoner i posten, slik at det under gjenoppretting er enkelt å identifisere disse. Sjekkpunkt kan for eksempel tas hver m-te minutt eller etter at t transaksjoner har committed. Fuzzy checkpointing går ut på at transaksjoner kan starte igjen etter [begin_checkpoint], i stedet for å vente på steg (2). Når steg (2) er ferdig, skrives en [end_checkpoint, ]-post til loggen, med relevant informasjon. Mens dette foregår, må forrige sjekkpunkt være gyldig Transaksjonstilbakerulling og gallopperende tilbakerulling Cascading rollback er når en transaksjon må tilbakerulles, fordi den leste en verdi til en annen transaksjon som ble tilbakerullet, fordi den leste en verdi til en tredje transaksjon som ble tilbakerullet Det er vanskelig å implementere databaser som støtter dette, så det er mer vanlig å implementere databaser der dette ikke skjer, ved at det garanteres historier som er cascadeless eller strict Transaksjonshandlinger som ikke påvirker databasen Transaksjoner kan også utføre handlinger som ikke påvirker databasen, men som for eksempel er ment som rapporter til brukeren. Disse bør bare kjøres hvis man vet at transaksjonen var vellykket, for eksempel etter at den har
3 Side 3 for Databaser committet NO-UNDO/REDO gjenoppretting basert på utsatt oppdatering Med utsatt oppdatering blir ikke data skrevet på disk før etter commit. I loggen trengs bare REDO-informasjon, som inkluderer AFIM (den nye verdien). Det er vanskelig å få til i praksis, siden man kan gå tom for bufferplass hvis for mange blokker i bufferet blir pinned. Typisk eksempel på utsatt oppdateringsprotokoll: 1) No-steal policy 2) Write ahead-logging Hvis dette blir brukt sammen med strikt 2PL, der opplåsing av skrevne verdier skjer etter commit, og man har med sjekkpunkt, kan dette være en mulig løsning: Gjenoppretting: Har to lister med transaksjoner, commit list og active transactions. REDO alle transaksjoner i commit-lista i samme rekkefølge som de er skrevet til loggen. De aktive transaksjonene blir avbrutt. REDO: Finn AFIM (new_value) i loggen for transaksjon T: [write_item, T, X, new_value] Ulemper: Kan bruke masse bufferplass Hindrer samtidighet pga. strikt 2PL Fordeler: Trenger ikke å rulle tilbake transaksjoner siden de ikke blir lagret på disk før etter commit. En transaksjon vil ikke lese en skitten verdi, siden alle dataelementer er låst til etter commit, så det vil ikke være noen cascading rollbacks Gjenopprettingsteknikker basert på umiddelbar oppdatering Når en transaksjon blir oppdatert, kan denne skrives tilbake med én gang, i stedet for å vente på commit. Det må være mulig å angre effektene av en transaksjon som feiler, så man må ha med BFIM (old_value) i loggen. To hovedkategorier for oppdateringsalgoritmer 1) Hvis det sørges for at alle oppdateringer til en transaksjon blir skrevet til disk før commit, så trengs ikke REDO. Dette er en UNDO/NO-REDO gjenopprettingsalgoritme. Må bruke steal/force-strategien. 2) Hvis transaksjonen kan committe før alle oppdateringer er skrevet til disk, er det en UNDO/REDO gjenopprettingsalgoritme. Da brukes en steal/no-force-strategi. Denne er mest vanlig og mest kompleks. Et eksempel på UNDO/REDO, med sjekkpunkt og strikte historier (for eksempel strikt 2PL). Gjenoppretting: 1) To lister: Committede transaksjoner siden siste sjekkpunkt og aktive transaksjoner 2) UNDO alle operasjoner gjort av de aktive transaksjonene, i motsatt
4 Side 4 for Databaser 3) rekkefølge av hvordan de ble lagt inn i loggen. REDO alle skriveoperasjoner av de committede transaksjonene, i samme rekkefølge som de ble lagt inn i loggen (REDO fra 22.2). UNDO: Sjekk logg-verdien, [write_item, T, X, old_value, new_value], og sett X til old_value, BFIM Shadow paging Side ARIES gjenoppretting Steal/no-force Write ahead Loggendringer during UNDO Gjentagende historikk during REDO Spore opp alle handlinger ARIES består av tre steg: Analyse, UNDO og REDO, og trenger systemloggen, transaksjonstabellen og Dirty Page-tabellen, i tillegg til sjekkpunkt. Analyse. Identifiserer skitne blokker i bufferet og transaksjonene som var aktive ved krasjet. Den finner også det punktet der REDO bør startes. REDO. De oppdateringene som trengs å gjøres fra loggen blir gjort på nytt av i databasen, og den vil gjøre alle oppdateringer til slutten av loggen. UNDO. Loggen blir scannet bakover, og transaksjoner som var aktive ved krasjet blir UNDO-et i reversert rekkefølge. Hver loggpost har et loggsekvensnummer, LSN, som er monotont økende og indikerer adressen til loggposten på disken. Hver LSN korresponderer til en spesifikk endring av en transaksjon, og hver diskblokk vil lagre LSN til den siste loggposten til en endring av datablokken. Mulige handlinger som blir lagret i loggen: Write, commit, abort, undo (for å slippe å gjøre det igjen) og end, for om en transaksjon avsluttes ved abort eller commit. Vanlig felt i loggposter inkluderer previouslsn, transaksjonsid og typen loggpost. For write-loggposter er det en blokkid (pageid), lengden på elementet, offset fra begynnelsen av blokken, BFIM og AFIM. Transaksjonstabellen har en post for alle aktive transaksjoner, med transaksjonsid, transaksjonsstatus og LSN til den siste loggposten til transaksjonen. Dirty page-tabellen har en post for alle skitne blokker i bufferet, med pageid og LSN til den tidligste oppdateringen. Når systemet krasjer, vil disse tabellene oppdateres i analyse-delen, ved å se på systemloggen. Fuzzy checkpoint. Har begin_checkpoint og end_checkpoint. Ved end_checkpoint blir transaksjonstabellen og dirty page-tabellen lagt til på slutten av loggen. Innholdet i bufferet trenger ikke flushes til disk, siden nødvendig inforasjon for recovery ligger i transaksjonstabellen og dirty pagetabellen. I analysefasen begynner gjenopprettingsmanageren på begin_checkpoint og går i gjennom loggpostene til slutten. Da kan den gjøre endringer på
5 Side 5 for Databaser transaksjonstabellen og dirty page-tabellen. I REDO-fasen gjør den alle operasjoner som er nødvendig å gjøre på nytt av. Den vil starte på den transaksjonen med samme LSN som den laveste LSN-verdien i dirty pagetabellen. En skriveoperasjon trenger ikke gjøres hvis Page ikke er i dirty page-tabellen Page er i dirty page-tabellen, men LSN(Page) er større enn LSN(loggpost). I UNDO-fasen vil den gå bakover i loggen og UNDO alle operasjoner som ikke ble committet.
Transaksjonsmodell. Samtidighet (1) ACID-transaksjoner. Samtidighet (2) Systemkræsj (1) Kapittel 17, Coping With System Failure
SIF8020 Datamodellering og databasesystemer: Transaksjonsmodell Kapittel 17, Coping With System Failure 20. april 2004, Roger Midtstraum, IDI/ ACID-transaksjoner Atomicity Alt eller ingenting Consistency
DetaljerDBS20 - Introduksjon til transaksjonsprosessering og teori
Side 1 for Databaser DBS20 - Introduksjon til transaksjonsprosessering og teori søndag 29. mai 2016 21.15 Pensum: 20.1-20-6, side 745-776, untatt 2.5.4 og 2.5.5 20.1 Introduksjon til transaksjonsprosessering
DetaljerØving 5: Transaksjonshåndtering, logging og normalisering
Øving 5: Transaksjonshåndtering, logging og normalisering Lars Kirkholt Melhus Oppgave 1 a) ACID Atomic En transaksjon er en minste enhet. Alle ledd i transaksjonen må gå feilfritt for at transaksjonen
DetaljerRepetisjonsforelesning, SQL og utover
Repetisjonsforelesning, SQL og utover Evgenij Thorstensen V18 Evgenij Thorstensen Repetisjon V18 1 / 23 Temaer SQL, semantikk Databasearkitektur Spørringskompilering og optimisering Indekser Transaksjonshåndtering
DetaljerSystemfeil og logging
UNIVERSITETET I OSLO Systemfeil og logging Institutt for Informatikk INF3100 2.3.2016 Ellen Munthe-Kaas 1 Integritetsregler Vi ønsker at data alltid skal være korrekte: Integritetsregler er predikater
DetaljerSystemfeil og logging
INF3100 Databasesystemer Systemfeil og logging Basert på lysark laget av Hector Garcia-Molina Oversatt og bearbeidet av Ragnar Normann Integritet eller korrekthet av data Vi ønsker at data alltid skal
DetaljerSystemfeil og logging
UNIVERSITETET I OSLO Systemfeil og logging Basert på lysark laget av Hector Garcia-Molina Oversatt og bearbeidet av Ragnar Normann INF3100 19.4.2005 Ragnar Normann 1 Integritet eller korrekthet av data
DetaljerSystemfeil og logging
UNIVERSITETET I OSLO Systemfeil og logging Institutt for Informatikk INF3100 7.3.2014 Ellen Munthe-Kaas 1 Integritetsregler Vi ønsker at data alltid skal være korrekte: Integritetsregler er predikater
DetaljerTransaksjoner. transaksjon. når starter/slutter 1 trans.?
Transaksjoner IBE211 Kap. 10 feil mediefeil: disk feiler må gjenopprette (fra sikkerhetskopi, kap. 11) instansfeil: databasen stopper midt i noe tilbakeføring (rollback) til konsistent samtidighet når
DetaljerSystemfeil og logging
UNIVERSITETET IOSLO Systemfeil og logging Institutt for Informatikk INF3100 28.2.2011 Ellen Munthe-Kaas 1 Korrekthet av data Vi ønsker at data alltid skal være riktige og nøyaktige Eksempel på tvilsomme
DetaljerNormalisering. ER-modell
Normalisering Hensikten med normalisering: En informasjonsenhet ett sted. Forhindrer anomalier Anomalier: Innsettingsanomalier. F.eks være avhengig av å sette inn flere verdi, selv om det er det er bare
DetaljerSystemfeil og logging
UNIVERSITETET I OSLO Systemfeil og logging Basert på lysark laget av Hector Garcia-Molina INF3100 23.4.2006 Ellen Munthe-Kaas 1 Integritet eller korrekthet av data Vi ønsker at data alltid skal være riktige
DetaljerSystemfeil og logging
UNIVERSITETET I OSLO Systemfeil og logging For en stor del basert på lysark laget av Hector Garcia-Molina Bearbeidet av Ragnar Normann INF3100 3.3.2008 Ragnar Normann Institutt for Informatikk 1 Korrekthet
DetaljerTransaksjonshåndtering Del 2
UNIVERSITETET I OSLO Transaksjonshåndtering Del 2 Ragnar Normann Noen figurer er basert på en original laget av Hector Garcia-Molina INF3100 3.5.2005 Ragnar Normann 1 En ny type serialiseringsprotokoll
DetaljerD: Ingen trykte eller håndskrevne hjelpemiddel tillatt. Bestemt, enkel kalkulator tillatt.
Side 1 av 7 Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap LØSNINGSFORSLAG TIL KONTINUASJONSEKSAMEN I FAG TDT4145 DATAMODELLERING OG DATABASESYSTEMER
DetaljerINF3100 V2018 Obligatorisk oppgave nr. 2
INF3100 V2018 Obligatorisk oppgave nr. 2 Oppgavesettet skal løses og leveres individuelt. Gjennomføring og innlevering av oppgaven skal skje i henhold til gjeldende retningslinjer ved Institutt for informatikk,
DetaljerTransaksjonshåndtering Del 2
UNIVERSITETET I OSLO Transaksjonshåndtering Del 2 Ragnar Normann Noen figurer er basert på en original laget av Hector Garcia-Molina INF3100 10.3.2008 Ellen Munthe-Kaas 1 En ny type serialiseringsprotokoll
DetaljerTransaksjonshåndtering Del 2
UNIVERSITETET I OSLO Transaksjonshåndtering Del 2 Institutt for Informatikk INF3100 14.3.2014 Ellen Munthe-Kaas 1 En ny type serialiseringsprotokoll Hittil har vi bare sett på 2PL-baserte protokoller Alle
DetaljerMinikompendium TDT4145 databasemod og dbsys
Minikompendium TDT4145 databasemod og dbsys Pages og records Her er det viktig å holde tunga rett i munnen så man ikke blander begrepene. Page Den minste dataenheten databasesystemet leser og skriver til
DetaljerDBS21 Samtidighetskontrollteknikker
Side 1 for Databaser DBS21 Samtidighetskontrollteknikker mandag 30. mai 2016 21.25 Pensum: 21.1, side 781-792, og 21.3 side 795-796 tom 21.3.1 21.1 Tofaselåsingsteknikker for samtidighetskontroll 21.1.1
DetaljerINF1300 Introduksjon til databaser
UNIVERSITETET I OSLO INF1300 Introduksjon til databaser Dagens tema: SQL: Outer join Denormalisering og splitting Transaksjoner og ACID-reglene DBMSer en introduksjon til INF3100 INF1300 19.11.2007 Ragnar
DetaljerDagens temaer. Kort repetisjon. Mer om cache (1) Mer om cache (2) Read hit. Read miss. Write hit. Hurtig minne. Cache
Dagens temaer Dagens emner er hentet fra Englander kapittel side 338-35 (gammel utgave). Mer om design av cache. Kort repetisjon er en spesiell type rask hukommelse som inneholder et subsett av det som
DetaljerLøsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer
Institutt for datateknikk og informasjonsvitenskap Løsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Eksamensdato: 23. mai 2013 Eksamenstid (fra-til): 09:00-13:00 Hjelpemiddelkode/Tillatte
DetaljerINF1300 Introduksjon til databaser
UNIVERSITETET I OSLO INF1300 Introduksjon til databaser Dagens tema: ORM og normalisering Denormalisering og splitting Transaksjonshåndtering INF1300 17.11.2010 Ellen Munthe-Kaas 1 ORM og normalisering
DetaljerOppgave 1 Datamodellering 25 %
Side 1 av 6 Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap LØSNINGSFORSLAG TIL EKSAMENSOPPGAVE I FAG TDT4145 DATAMODELLERING OG DATABASESYSTEMER Eksamensdato:
DetaljerTransaksjoner og flerbrukerproblematikk. Transaksjoner
LC238D http://www.aitel.hist.no/fag/_dmdb/ Transaksjoner og flerbrukerproblematikk Transaksjoner side 2-4 Låseteknikker side 5 Isolasjonsnivåer side 6-7 Flerbrukerproblemer i fbm utførelse av transaksjoner
DetaljerApache Derby som MMDB
Apache Derby som MMDB Knut Magne Solem Master i datateknikk Oppgaven levert: Juni 2007 Hovedveileder: Svein Erik Bratsberg, IDI Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk
DetaljerD: Ingen trykte eller håndskrevne hjelpemiddel tillatt. Bestemt, enkel kalkulator tillatt.
Side 1 av 6 Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap LØSNINGSFORSLAG TIL EKSAMENSOPPGAVE I FAG TDT4145 DATAMODELLERING OG DATABASESYSTEMER, ver
DetaljerDBMS Database Management System (repetisjon) Programmeringsgrensesnitt. Serialiserbarhet
DBMS Database Management System (repetisjon) Spesialisert SW Karakteristika: Persistens Transaksjonshåndtering A tomicity C onsistency I solation D urability Programmeringsgrensesnitt INF212 v2003 1 Serialiserbarhet
DetaljerIsolasjon i postgres og mysql
Isolasjon i postgres og mysql Evgenij Thorstensen V19 Evgenij Thorstensen Isolasjon i postgres og mysql V19 1 / 20 Isolasjonsnivåer Read uncommitted Read committed Repeatable read Serializable SELECT...
DetaljerAndre sett obligatoriske oppgaver i INF3100 V2013
Andre sett obligatoriske oppgaver i INF3100 V2013 Oppgavesettet skal i utgangspunktet løses av grupper på to og to studenter som leverer felles besvarelse. Vi godkjenner også individuelle besvarelser,
DetaljerHva har vi gjort? SQL og Databasedesign
Hva har vi gjort? SQL og Databasedesign HVA? Begrepsmessig databasedesign E/R diagram Logisk databasedesign Tabeller HVORDAN? Fysisk databasedesign Filer Indekser Etter vi har behandlet de mer statiske
DetaljerInnhold. Virtuelt minne. Paging i mer detalj. Felles rammeverk for hukommelseshierarki. 02.04.2001 Hukommelseshierarki-2 1
Innhold Virtuelt minne Paging i mer detalj Felles rammeverk for hukommelseshierarki 02.04.200 Hukommelseshierarki-2 Virtuelt minne Lagringskapasiteten i RAM må deles mellom flere ulike prosesser: ûoperativsystemet
DetaljerEksamensoppgave i TDT4145 Datamodellering og databasesystemer
Institutt for datateknikk og informasjonsvitenskap Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Faglig kontakt under eksamen: Roger Midtstraum: 995 72 420 Svein Erik Bratsberg: 995 39
DetaljerEKSAMENSOPPGAVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER. Faglig kontakt under eksamen: Svein Erik Bratsberg og Roger Midtstraum
Side 1 av 5 Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap EKSAMENSOPPGAVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER Faglig kontakt under eksamen:
DetaljerDBS18 - Strategier for Query-prosessering
Side 1 for Databaser DBS18 - Strategier for Query-prosessering søndag 22. mai 2016 13.03 Pensum 18.1-18.4, side 655-674, unntatt 18.4.4 og 18.4.5 En spørring som blir skrevet i et høynivå-språk, må bli
DetaljerEksamensoppgave i TDT4145 Datamodellering og databasesystemer
Institutt for datateknikk og informasjonsvitenskap Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Faglig kontakt under eksamen: Svein Erik Bratsberg: 995 39 963 Roger Midtstraum: 995 72
DetaljerInnhold. Introduksjon til parallelle datamaskiner. Ulike typer parallelle arkitekturer. Prinsipper for synkronisering av felles hukommelse
Innhold Introduksjon til parallelle datamaskiner. Ulike typer parallelle arkitekturer Prinsipper for synkronisering av felles hukommelse Multiprosessorer koblet sammen av én buss 02.05 2001 Parallelle
DetaljerTransaksjoner og flerbrukerproblematikk. Transaksjoner
LC238D http://www.aitel.hist.no/fag/_dmdb/ Transaksjoner og flerbrukerproblematikk Transaksjoner side 2-4 Låseteknikker side 5 Isolasjonsnivåer side 6-7 Flerbrukerproblemer i fbm utførelse av transaksjoner
DetaljerD: Ingen trykte eller håndskrevne hjelpemiddel tillatt. Bestemt, enkel kalkulator tillatt.
Side 1 av 5 Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap Løsningsforslag til EKSAMENSOPPGAVE I FAG TDT4186 OPERATIVSYSTEMER Versjon: 17.jan 2013 Faglig
DetaljerLøsningsforslag eksamen TDT4160 høsten 2005
Løsningsforslag eksamen TDT4160 høsten 005 NB! Ved en feil er summen av prosentvektene for alle oppgavene 90 % og ikke 100 %. For å korrigere dette, ble alle resultater delt på 0,9. Oppgave 1 Alternativ
DetaljerLøsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer
Institutt for datateknikk og informasjonsvitenskap Løsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Eksamensdato: 26. mai 2014 Eksamenstid (fra-til): 09:00-13:00 Hjelpemiddelkode/Tillatte
DetaljerEKSAMENSOPPGÅVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER
Side 1 av 5 Noregs teknisk-naturvitskapelege universitet Institutt for datateknikk og informasjonsvitskap EKSAMENSOPPGÅVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER Fagleg kontakt under eksamen: Svein
DetaljerSkisse til løsning av eksamensoppgave i TDT4145 Datamodellering og databasesystemer
Skisse til løsning av eksamensoppgave i TDT4145 Datamodellering og databasesystemer Vers: 17.aug 2016 Faglig kontakt under eksamen: Roger Midtstraum: 995 72 420 Svein Erik Bratsberg: 995 39 963 Eksamensdato:
DetaljerEksamensoppgave i TDT4145 Datamodellering og databasesystemer
Institutt for datateknikk og informasjonsvitenskap Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Faglig kontakt under eksamen: Svein Erik Bratsberg: 995 39 963 Roger Midtstraum: 995 72
DetaljerEksamensoppgave i TDT4145 Datamodellering og databasesystemer
Institutt for datateknikk og informasjonsvitenskap Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Faglig kontakt under eksamen: Roger Midtstraum: 995 72 420 Svein Erik Bratsberg: 995 39
DetaljerEksamensoppgave i TDT4145 Datamodellering og databasesystemer
Institutt for datateknologi og informatikk Eksamensoppgave i TDT445 Datamodellering og databasesystemer Faglig kontakt under eksamen: Roger Midtstraum: 995 72 420 Eksamensdato: 7. juni 207 Eksamenstid
DetaljerTransaksjonshåndtering Del 3
UNIVERSITETET I OSLO Transaksjonshåndtering Del 3 Ragnar Normann INF3100 24.3.2009 Ragnar Normann 1 Serialiserbarhet Vi har tidligere definert serialiserbarhet på denne måten: En eksekveringsplan kalles
DetaljerINF1300 Introduksjon til databaser
UNIVERSITETET IOSLO INF1300 Introduksjon til databaser Dagens tema: ORM og normalisering Denormalisering og splitting Triggere og databasefunksjoner Transaksjonshåndtering INF1300 2.11.2011 Ellen Munthe-Kaas
DetaljerEksamensoppgåve i TDT4145 Datamodellering og databasesystem
Institutt for datateknikk og informasjonsvitskap Eksamensoppgåve i TDT4145 Datamodellering og databasesystem Fagleg kontakt under eksamen: Roger Midtstraum: 995 72 420 Svein Erik Bratsberg: 995 39 963
DetaljerTransaksjonshåndtering Del 3
UNIVERSITETET I OSLO Transaksjonshåndtering Del 3 Ragnar Normann INF3100 12.4.2010 Ragnar Normann 1 Samtidighetsfenomener og -anomalier Dette er uønskede «merkverdigheter» som kan inntreffe i eksekveringsplaner.
DetaljerLøsning til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer
Institutt for datateknikk og informatikk Løsning til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Faglig kontakt under eksamen: Roger Midtstraum: 995 72 420 Svein Erik Bratsberg: 995 39
DetaljerEksamensoppgåve i TDT4145 Datamodellering og databasesystem
Institutt for datateknikk og informasjonsvitskap Eksamensoppgåve i TDT4145 Datamodellering og databasesystem Fagleg kontakt under eksamen: Roger Midtstraum: 995 72 420 Svein Erik Bratsberg: 995 39 963
DetaljerAndre sett obligatoriske oppgaver i INF3100 V2012
Andre sett obligatoriske oppgaver i INF3100 V2012 Oppgavesettet skal i utgangspunktet løses av grupper på to og to studenter som leverer felles besvarelse. Vi godkjenner også individuelle besvarelser,
DetaljerINF2270. Input / Output (I/O)
INF2270 Input / Output (I/O) Hovedpunkter Innledning til Input / Output Ulike typer I/O I/O internt i datamaskinen I/O eksternt Omid Mirmotahari 3 Input / Output En datamaskin kommuniserer med omverdenen
DetaljerTransaksjonshåndtering Del 3
UNIVERSITETET I OSLO Transaksjonshåndtering Del 3 Institutt for Informatikk INF3100 15.3.2012 Ellen Munthe-Kaas 1 Samtidighetsfenomener og -anomalier Dette er uønskede «merkverdigheter» som kan inntreffe
DetaljerPlan. Oppgaver og repetisjon Eksempler med fikspunkt og induksjon: 1. sortering 2. divisjon 3. Heis? IN 315: Foilsett 9: Unity: Arkitekturer
Plan Tema: Ulike arkitekturer og avbildninger 1. asynkron arkitektur med felles variable 2. synkron arkitektur med felles variable 3. distribuert arkitektur med kanal-kommunikasjon 4. program-skjemaer
DetaljerTransaksjonshåndtering Del 3
UNIVERSITETET I OSLO Transaksjonshåndtering Del 3 Institutt for Informatikk INF3100 17.3.2014 Ellen Munthe-Kaas 1 Samtidighetsfenomener og -anomalier Dette er uønskede «merkverdigheter» som kan inntreffe
DetaljerSamtidighetsfenomener og anomalier i eksekveringsplaner. INF Ellen Munthe-Kaas 1
Samtidighetsfenomener og anomalier i eksekveringsplaner INF3100 15.3.2012 Ellen Munthe-Kaas 1 Liste over fenomener og anomalier P0 Skitten skriv w 1 (x)..w 2 (x)..(c 1 eller a 1 ) P1 Skitten les w 1 (x)..r
DetaljerAndre sett obligatoriske oppgaver iinf3100v2011
Andre sett obligatoriske oppgaver iinf3100v2011 Oppgavesettet skal i utgangspunktet løses av grupper på to og to studenter som leverer felles besvarelse. Vi godkjenner også individuelle besvarelser, men
DetaljerDatabasemodellering og DBMS. Oppsummering
Databasemodellering og DBMS Oppsummering Alexander Nossum 2006 alexander@nossum.net 1/46 Innholdsfortegnelse Databasemodellering og DBMS...1 Oppsummering... 1 1. Modellering...5 1.1 ER vs. Relasjonsmodellen...5
DetaljerSamtidighetsfenomener og anomalier i eksekveringsplaner (kursorisk) INF3100 Ellen Munthe-Kaas 1
Samtidighetsfenomener og anomalier i eksekveringsplaner (kursorisk) INF3100 Ellen Munthe-Kaas 1 Liste over fenomener P0 Skitten skriv w 1 (x)..w 2 (x)..(c 1 eller a 1 ) P1 Skitten les w 1 (x)..r 2 (x)..(c
DetaljerHeap* En heap er et komplett binært tre: En heap er også et monotont binært tre:
Heap Heap* En heap er et komplett binært tre: Alle nivåene i treet, unntatt (muligens) det nederste, er alltid helt fylt opp med noder Alle noder på nederste nivå ligger til venstre En heap er også et
DetaljerPresentasjon av doktorgradsprosjekt
Presentasjon av doktorgradsprosjekt Fredag Jon Grov Tre deler Del 1 - litt om transaksjonshåndtering. Del 2 - om doktorgradsarbeidet. Del 3 - bittelitt om Python og SimPy (bare hvis vi har tid). 1 av 14
DetaljerDagens temaer. Fra kapittel 4 i Computer Organisation and Architecture. Kort om hurtigminne (RAM) Organisering av CPU: von Neuman-modellen
Dagens temaer Fra kapittel 4 i Computer Organisation and Architecture Kort om hurtigminne (RAM) Organisering av CPU: von Neuman-modellen Register Transfer Language (RTL) Instruksjonseksekvering Pipelining
DetaljerEffektiv eksekvering av spørsmål
UNIVERSITETET I OSLO Effektiv eksekvering av spørsmål Basert på foiler av Hector Garcia-Molina, Ragnar Normann Oversikt Spørsmålshåndtering Modell for kostnadsberegning Kostnad for basis-operasjoner Implementasjons-algoritmer
DetaljerEffektiv eksekvering av spørsmål
UNIVERSITETET I OSLO Effektiv eksekvering av spørsmål Spørsmålshåndtering Modell for kostnadsberegning Kostnad for basisoperasjoner Implementasjonsalgoritmer Institutt for Informatikk INF3100 6.4.2016
DetaljerLøsningsforslag for Eksamensoppgave i TDT4190 Distribuerte systemer
Institutt for datateknikk og informasjonsvitenskap Løsningsforslag for Eksamensoppgave i TDT4190 Distribuerte systemer Faglig kontakt under eksamen: Jon Olav Hauglid Tlf.: 93 80 58 51 Eksamensdato: Onsdag
DetaljerTransaksjonshåndtering Del 3
UNIVERSITETET I OSLO Transaksjonshåndtering Del 3 Institutt for Informatikk INF3100 4.4.2016 Ellen Munthe-Kaas 1 Samtidighetsfenomener og -anomalier Dette er uønskede «merkverdigheter» som kan inntreffe
Detaljer! Ytelsen til I/O- systemer avhenger av flere faktorer: ! De to viktigste parametrene for ytelse til I/O er:
Dagens temaer! Ulike kategorier input/output! Programmert! Avbruddstyrt! med polling.! Direct Memory Access (DMA)! Asynkrone vs synkrone busser! Med! Fordi! -enheter menes de enheter og mekanismer som
DetaljerEffektiv eksekvering av spørsmål
UNIVERSITETET I OSLO Effektiv eksekvering av spørsmål Spørsmålshåndtering Modell for kostnadsberegning Kostnad for basisoperasjoner Implementasjonsalgoritmer Institutt for Informatikk INF3100 23.3.2015
Detaljer4/5 store parallelle maskiner /4 felles hukommelse in 147, våren 1999 parallelle datamaskiner 1. når tema pensum.
Parallellitet når tema pensum 27/4 felles hukommelse 9.2 9.3 4/5 store parallelle maskiner 9.4 9.6 in 147, våren 1999 parallelle datamaskiner 1 Tema for denne forelesningen: kraftigere enn én prosessor
DetaljerBrukermanual. For app.minmemoria.no
Brukermanual For app.minmemoria.no Innhold Kom i gang... 4 Registrering... 4 Opprette en Memoriaprofil til pasienten... 4 Koble pasienten til institusjon... 4 Memoriaprofilen... 5 Sidepanelet... 5 Om personen...
DetaljerHvordan å rulle tilbake en driver og gjenoppretting Driver UpdatesHow to Roll back a Driver and Restore Driver Updates
ReviverSoft Blog Tips and Tricks to Make You Love Your Computer Again http://www.reviversoft.com/no/blog Hvordan å rulle tilbake en driver og gjenoppretting Driver UpdatesHow to Roll back a Driver and
Detaljer... Når internminnet blir for lite. Dagens plan: Løsning: Utvidbar hashing. hash(x) katalog. O modellen er ikke lenger gyldig ved
Dagens plan: Utvidbar hashing (kapittel 5.6) B-trær (kap. 4.7) Abstrakte datatyper (kap. 3.1) Stakker (kap. 3.3) Når internminnet blir for lite En lese-/skriveoperasjon på en harddisk (aksesstid 7-12 millisekunder)
DetaljerTransaksjonshåndtering og samtidighetskontroll
UNIVERSITETET I OSLO Transaksjonshåndtering og samtidighetskontroll Institutt for Informatikk INF3100 7.3.2016 Ellen Munthe-Kaas 1 Transaksjoner En transaksjon er en sekvens av operasjoner som bevarer
DetaljerEksamensoppgave i TDT4145 Datamodellering og databasesystemer
Institutt for datateknikk og informasjonsvitenskap Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Faglig kontakt under eksamen: Svein Erik Bratsberg: 995 39 963 Roger Midtstraum: 995 72
DetaljerFakultet for informasjonsteknologi,
Side 1 av 9 NTNU Norges teknisk naturvitenskapelige universitet Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Løsning på SIF8037 Distribuerte
DetaljerDeling av data Transaksjoner
Deling av data Transaksjoner INF5040 Foreleser: Olav Lysne SRL & Ifi/UiO 1 Introduksjon Tjenere kan tilby samtidig aksess fra klienter til de objekter/data tjenerne innkapsler o fler-trådede tjenere =>
DetaljerDeling av data Transaksjoner
Deling av data Transaksjoner INF5040 Foreleser: Olav Lysne SRL & Ifi/UiO 1 Introduksjon Tjenere kan tilby samtidig aksess fra klienter til de objekter/data tjenerne innkapsler o fler-trådede tjenere =>
DetaljerEksamensoppgave i TDT4145 Datamodellering og databasesystemer
Institutt for datateknikk og informatikk Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Faglig kontakt under eksamen: Roger Midtstraum: 995 72 420 Svein Erik Bratsberg: 995 39 963 Eksamensdato:
DetaljerForelesning 3.11. Hurtigbuffer Kap 4.5
TDT4160 Datamaskiner Grunnkurs Forelesning 3.11 Hurtigbuffer Kap 4.5 Dagens tema Hurtigbuffer (4.5) Repetisjon: Hva, hvorfor og hvordan Avbildning Skriveoperasjoner Hurtigbuffer ( cache ): Hvorfor? Hurtigbuffer:
DetaljerSikkerhetskopiering og gjenoppretting Brukerhåndbok
Sikkerhetskopiering og gjenoppretting Brukerhåndbok Copyright 2007-2009 Hewlett-Packard Development Company, L.P. Windows er et registrert varemerke for Microsoft Corporation i USA. Informasjonen i dette
DetaljerLøsningsforslag Eksamen i TDT4190 Distribuerte systemer
Institutt for datateknikk og informasjonsvitenskap Løsningsforslag Eksamen i TDT4190 Distribuerte systemer Faglig kontakt under eksamen: Norvald Ryeng Tlf.: 97 17 49 80 Eksamensdato: Fredag 6. juni 2014
DetaljerHTML: Publiser nettsiden din. Publiser nettsiden din på Internett. Github. Brukernavn.github.io
HTML: Publiser nettsiden din Publiser nettsiden din på Internett Nå har du laget ditt eget nettsted. Du ønsker vel å vise det frem, gjør du ikke? Erfaren Web Husker du servere fra den første økten? Servere
DetaljerLøsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer
Institutt for datateknikk og informasjonsvitenskap Løsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Eksamensdato: 1. juni 2015 Eksamenstid (fra-til): 09:00-13:00 Hjelpemiddelkode/Tillatte
DetaljerINF2270. Input / Output (I/O)
INF2270 Input / Output (I/O) Hovedpunkter Innledning til Input / Output Ulike typer I/O I/O internt i datamaskinen I/O eksternt Omid Mirmotahari 3 Input / Output En datamaskin kommuniserer med omverdenen
DetaljerUNIVERSITETET I OSLO
UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i INF3100 Databasesystemer Eksamensdag: 11. juni 2013 Tid for eksamen: 9.00 13.00 Oppgavesettet er på 6 sider. Vedlegg: ingen Tillatte
DetaljerLars Vidar Magnusson
B-Trær Lars Vidar Magnusson 5.3.2014 Kapittel 18 B-trær Standard operasjoner Sletting B-Trær B-trær er balanserte trær som er designet for å fungere bra på sekundære lagringsmedium e.g. harddisk. Ligner
DetaljerCharacteristics of a good design
Characteristics of a good design (PPT. side 1) Innledning Høykvalitetsdesign bør ha visse karakteristikker for å oppnå kvalitetsprodukter, dvs.: enkelt å forstå enkelt å implementere enkelt å teste enkelt
DetaljerEffektiv Systemadministrasjon
Effektiv Systemadministrasjon UBW MILESTONE WILLIAM NILSEN Introduksjon William Nilsen ASP/Cloud avdelingen i Evry Jobbet flere år med generelt teknisk drift og ca 3 år med drift av UBW ASP/Cloud avdelingen
DetaljerSkisse til løsning for eksamensoppgave i TDT4186 Operativsystemer
Institutt for datateknikk og informasjonsvitenskap Skisse til løsning for eksamensoppgave i TDT4186 Operativsystemer Faglig kontakt under eksamen: Svein Erik Bratsberg: 9953 9963 Eksamensdato: 9. desember
DetaljerKapittel 7, Minne RAM DIMM, SIMM ROM, PROM, EPROM, EEPROM FLASH DIM SUM. Cache Virtuelt minne
Kapittel 7, Minne RAM DIMM, SIMM ROM, PROM, EPROM, EEPROM FLASH DIM SUM Cache Virtuelt minne 26.04.2013 Data Cache Les adresse 99 Adresse 99 Prosessor med registre Cache Cache L2 Data Data Les side Adresse
DetaljerTransaksjonshåndtering Del 3
UNIVERSITETET I OSLO Transaksjonshåndtering Del 3 Institutt for Informatikk INF3100 10.3.2015 Ellen Munthe-Kaas 1 Samtidighetsfenomener og -anomalier Dette er uønskede «merkverdigheter» som kan inntreffe
DetaljerHØGSKOLEN I SØR-TRØNDELAG
HØGSKOLEN I SØR-TRØNDELAG Eksamensdato: 26. mai 25 Varighet: 3 timer ( 9: 12: ) Avdeling for informatikk og e-læring Fagnummer: Fagnavn: LO249D Operativsystemer med Linux Klasser: BADR 1. ING FU Studiepoeng:
DetaljerINF2270. Minnehierarki
INF2270 Minnehierarki Hovedpunkter Bakgrunn Kort repetisjon Motivasjon Teknikker for hastighetsøkning Multiprosessor Økt klokkehastighet Raskere disker Økt hurtigminne Bruksområder Lagringskapasitet Aksesstider
DetaljerEksamensoppgåve i TDT4145 Datamodellering og databasesystemer
Institutt for datateknikk og informatikk Eksamensoppgåve i TDT4145 Datamodellering og databasesystemer Fagleg kontakt under eksamen: Roger Midtstraum: 995 72 420 Svein Erik Bratsberg: 995 39 963 Eksamensdato:
Detaljer