DBS22 Databasegjenopprettingsteknikker

Størrelse: px
Begynne med side:

Download "DBS22 Databasegjenopprettingsteknikker"

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

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

Detaljer

DBS20 - Introduksjon til transaksjonsprosessering og teori

DBS20 - 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 Ø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

Detaljer

Repetisjonsforelesning, SQL og utover

Repetisjonsforelesning, 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

Detaljer

Systemfeil og logging

Systemfeil 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

Detaljer

Systemfeil og logging

Systemfeil 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

Detaljer

Systemfeil og logging

Systemfeil 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

Detaljer

Systemfeil og logging

Systemfeil 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

Detaljer

Transaksjoner. transaksjon. når starter/slutter 1 trans.?

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

Detaljer

Systemfeil og logging

Systemfeil 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

Detaljer

Normalisering. ER-modell

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

Detaljer

Systemfeil og logging

Systemfeil 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

Detaljer

Systemfeil og logging

Systemfeil 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

Detaljer

Transaksjonshåndtering Del 2

Transaksjonshå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

Detaljer

D: Ingen trykte eller håndskrevne hjelpemiddel tillatt. Bestemt, enkel kalkulator tillatt.

D: 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

Detaljer

INF3100 V2018 Obligatorisk oppgave nr. 2

INF3100 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,

Detaljer

Transaksjonshåndtering Del 2

Transaksjonshå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

Detaljer

Transaksjonshåndtering Del 2

Transaksjonshå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

Detaljer

Minikompendium TDT4145 databasemod og dbsys

Minikompendium 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

Detaljer

DBS21 Samtidighetskontrollteknikker

DBS21 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

Detaljer

INF1300 Introduksjon til databaser

INF1300 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

Detaljer

Dagens temaer. Kort repetisjon. Mer om cache (1) Mer om cache (2) Read hit. Read miss. Write hit. Hurtig minne. Cache

Dagens 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

Detaljer

Løsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Lø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

Detaljer

INF1300 Introduksjon til databaser

INF1300 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

Detaljer

Oppgave 1 Datamodellering 25 %

Oppgave 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:

Detaljer

Transaksjoner og flerbrukerproblematikk. Transaksjoner

Transaksjoner 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

Detaljer

Apache Derby som MMDB

Apache 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

Detaljer

D: Ingen trykte eller håndskrevne hjelpemiddel tillatt. Bestemt, enkel kalkulator tillatt.

D: 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

Detaljer

DBMS Database Management System (repetisjon) Programmeringsgrensesnitt. Serialiserbarhet

DBMS 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

Detaljer

Isolasjon i postgres og mysql

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

Detaljer

Andre sett obligatoriske oppgaver i INF3100 V2013

Andre 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,

Detaljer

Hva har vi gjort? SQL og Databasedesign

Hva 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

Detaljer

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

Detaljer

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Eksamensoppgave 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

Detaljer

EKSAMENSOPPGAVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER. Faglig kontakt under eksamen: Svein Erik Bratsberg og Roger Midtstraum

EKSAMENSOPPGAVE 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:

Detaljer

DBS18 - Strategier for Query-prosessering

DBS18 - 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

Detaljer

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Eksamensoppgave 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

Detaljer

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

Detaljer

Transaksjoner og flerbrukerproblematikk. Transaksjoner

Transaksjoner 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

Detaljer

D: Ingen trykte eller håndskrevne hjelpemiddel tillatt. Bestemt, enkel kalkulator tillatt.

D: 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

Detaljer

Løsningsforslag eksamen TDT4160 høsten 2005

Lø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

Detaljer

Løsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Lø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

Detaljer

EKSAMENSOPPGÅVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER

EKSAMENSOPPGÅ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

Detaljer

Skisse til løsning av eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Skisse 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:

Detaljer

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Eksamensoppgave 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

Detaljer

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Eksamensoppgave 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

Detaljer

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Eksamensoppgave 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

Detaljer

Transaksjonshåndtering Del 3

Transaksjonshå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

Detaljer

INF1300 Introduksjon til databaser

INF1300 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

Detaljer

Eksamensoppgåve i TDT4145 Datamodellering og databasesystem

Eksamensoppgå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

Detaljer

Transaksjonshåndtering Del 3

Transaksjonshå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.

Detaljer

Løsning til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Lø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

Detaljer

Eksamensoppgåve i TDT4145 Datamodellering og databasesystem

Eksamensoppgå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

Detaljer

Andre sett obligatoriske oppgaver i INF3100 V2012

Andre 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,

Detaljer

INF2270. Input / Output (I/O)

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

Detaljer

Transaksjonshåndtering Del 3

Transaksjonshå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

Detaljer

Plan. Oppgaver og repetisjon Eksempler med fikspunkt og induksjon: 1. sortering 2. divisjon 3. Heis? IN 315: Foilsett 9: Unity: Arkitekturer

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

Detaljer

Transaksjonshåndtering Del 3

Transaksjonshå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

Detaljer

Samtidighetsfenomener og anomalier i eksekveringsplaner. INF Ellen Munthe-Kaas 1

Samtidighetsfenomener 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

Detaljer

Andre sett obligatoriske oppgaver iinf3100v2011

Andre 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

Detaljer

Databasemodellering og DBMS. Oppsummering

Databasemodellering 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

Detaljer

Samtidighetsfenomener og anomalier i eksekveringsplaner (kursorisk) INF3100 Ellen Munthe-Kaas 1

Samtidighetsfenomener 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

Detaljer

Heap* En heap er et komplett binært tre: En heap er også et monotont binært tre:

Heap* 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

Detaljer

Presentasjon av doktorgradsprosjekt

Presentasjon 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

Detaljer

Dagens 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 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

Detaljer

Effektiv eksekvering av spørsmål

Effektiv 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

Detaljer

Effektiv eksekvering av spørsmål

Effektiv 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

Detaljer

Løsningsforslag for Eksamensoppgave i TDT4190 Distribuerte systemer

Lø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

Detaljer

Transaksjonshåndtering Del 3

Transaksjonshå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:

! 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

Detaljer

Effektiv eksekvering av spørsmål

Effektiv 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

Detaljer

4/5 store parallelle maskiner /4 felles hukommelse in 147, våren 1999 parallelle datamaskiner 1. når tema pensum.

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

Detaljer

Brukermanual. For app.minmemoria.no

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

Detaljer

Hvordan å rulle tilbake en driver og gjenoppretting Driver UpdatesHow to Roll back a Driver and Restore Driver Updates

Hvordan å 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

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

Detaljer

Transaksjonshåndtering og samtidighetskontroll

Transaksjonshå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

Detaljer

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Eksamensoppgave 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

Detaljer

Fakultet for informasjonsteknologi,

Fakultet 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

Detaljer

Deling av data Transaksjoner

Deling 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 =>

Detaljer

Deling av data Transaksjoner

Deling 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 =>

Detaljer

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Eksamensoppgave 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:

Detaljer

Forelesning 3.11. Hurtigbuffer Kap 4.5

Forelesning 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:

Detaljer

Sikkerhetskopiering og gjenoppretting Brukerhåndbok

Sikkerhetskopiering 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

Detaljer

Løsningsforslag Eksamen i TDT4190 Distribuerte systemer

Lø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

Detaljer

HTML: Publiser nettsiden din. Publiser nettsiden din på Internett. Github. Brukernavn.github.io

HTML: 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

Detaljer

Løsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Lø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

Detaljer

INF2270. Input / Output (I/O)

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

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET 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

Detaljer

Lars Vidar Magnusson

Lars 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

Detaljer

Characteristics of a good design

Characteristics 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

Detaljer

Effektiv Systemadministrasjon

Effektiv 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

Detaljer

Skisse til løsning for eksamensoppgave i TDT4186 Operativsystemer

Skisse 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

Detaljer

Kapittel 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 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

Detaljer

Transaksjonshåndtering Del 3

Transaksjonshå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

Detaljer

HØGSKOLEN I SØR-TRØNDELAG

HØ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:

Detaljer

INF2270. Minnehierarki

INF2270. Minnehierarki INF2270 Minnehierarki Hovedpunkter Bakgrunn Kort repetisjon Motivasjon Teknikker for hastighetsøkning Multiprosessor Økt klokkehastighet Raskere disker Økt hurtigminne Bruksområder Lagringskapasitet Aksesstider

Detaljer

Eksamensoppgåve i TDT4145 Datamodellering og databasesystemer

Eksamensoppgå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