Kapittel 8 · Forelesning 14–16 · Del 2

Transaksjoner — ACID i praksis

Hvordan databasen gir alt-eller-ingenting selv når mange brukere kjører samtidig og strømmen plutselig går.

Bratsbergs notater 15–18 Forelesning 14–16 transaksjoner.pdf

01 · Motivasjon

Hvorfor finnes transaksjoner?

Tenk deg en bankoverføring: «trekk 100 kr fra konto A, sett 100 kr inn på konto B». To skriveoperasjoner. Hvis maskinen krasjer mellom dem, har banken nettopp slettet 100 kr av kundens penger — og 100 kr fra balansen. To samtidige overføringer kan også havne i klinsj og ende i tull selv uten krasj.

Hele kapittel 8 finnes for å gjøre venstre kolonne umulig. Mekanismene heter ACID — og resten av kapittelet viser hvordan.

En transaksjon er en logisk arbeidsenhet som binder slike steg sammen. Databasen lover fire ting — kjent som ACID:

Atomicity

Alt eller ingenting — enten gjøres alle stegene, eller ingen.

løses i 8C

Consistency

Integritetskrav (PK, FK, CHECK) holder før og etter hver commit.

tverrgående

Isolation

To samtidige transaksjoner skal ikke se hverandre halvferdige.

løses i 8B

Durability

Etter commit overlever resultatet enhver krasj.

løses i 8C

02 · Helhetsbilde

Kartet over alt som skjer

Tre hovedmekanismer jobber sammen i bakgrunnen hver gang du skriver BEGIN; … COMMIT;. Hver av dem garanterer én eller flere bokstaver i ACID:

De tre delene av kapittelet henger på samme arkitektur: scheduler/lock manager (begreper som 2PL og MVCC forklares i 8B) håndterer Isolation, mens recovery manager (med WAL og ARIES, forklart i 8C) sammen med loggen sikrer Atomicity og Durability.

3 undersider · 8A · 8B · 8C

A I D tre ACID-bokstaver løses

2PL låser → Isolation

WAL logg → Atomicity + Durability

Mental modell

Tenk på lock manager som en trafikkdirigent (ingen kjører over hverandre — Isolation), og recovery manager + logg som en flyboksopptaker (vi kan alltid spole frem committed arbeid og spole tilbake løse arbeid — Atomicity + Durability). De jobber uavhengig, men deler buffer pool og disk.

03 · Reisen gjennom kapittelet

Én transaksjon — tre kapittel-deler

Hver del av kapittelet adresserer ett trinn i transaksjonens liv. Følg pilen: 8A gir vokabularet, 8B viser hva som kan gå galt under samtidighet og hvordan låser fikser det, 8C viser hva som skjer når strømmen går.

Transaksjonens livsløp på toppen, kapittel-delene under, ACID-bokstavene nederst. Følg en pil — du leser kapittelet i rekkefølge når du følger livsløpet.

Slides og kompendium

Hovedkilde: transaksjoner.pdf + Bratsbergs kompendium kap. 15–18. Underkapitlene er lese-stier med figurer og quizzer underveis — ikke bare summert til slutt.

04 · Deler

Tre forelesninger, tre spor

Hver underside er bygd opp progressivt: konsept → figur → eksempel → quiz. Følg dem i rekkefølge første gang.

Intro og teori

F14 · Notater kap. 15–16 · ACID, schedules (operasjonsrekkefølger), conflict serializability, recoverability og strenge schedule-klasser, presedensgraf

→ 8B

Samtidighet og låser

F15 · Notater kap. 16–17 · Anomalier, S/X-låser, 2PL, deadlocks, MVCC/snapshot, isolation levels

→ 8C

Recovery

F16 · Notater kap. 18 · Logg, WAL, force/steal, undo/redo, ARIES sine tre faser, sjekkpunkter

→

05 · Vokabular

Begrepene du møter igjen

Disse går igjen i alle tre delene. Trenger du å slå dem opp senere — det er her.

Begrep	Forkortet	Hva det betyr
Transaksjon	T_i	Atomisk arbeidsenhet — ender med commit eller abort.
Schedule (historie)	H	Sekvens av `r/w/c/a`-operasjoner fra flere transaksjoner.
Conflict	—	To operasjoner på samme dataelement, ulike transaksjoner, minst én er write.
Serializable	—	Schedule har samme effekt som en eller annen seriell rekkefølge.
Two-phase locking	2PL	Først alle låser, så ingen flere — garanterer conflict-serializability.
MVCC	—	Multi-version. Reads ser snapshot, writes lager ny versjon.
Log Sequence Number	LSN	Monotont voksende ID på log-record. Også per side (PageLSN).
WAL-regel	—	Loggen må på disk før dataen.
Compensating Log Record	CLR	«Undo som er en redo» — gjør tilbakerulling idempotent.
Dirty Page Table	DPT	Sider som har endringer i buffer som ikke er på disk.

06 · Forhåndssjekk

Sjekk hva du allerede har med deg

Tre raske spørsmål før du dykker inn. Du finner full forklaring i underkapitlene.

Forhåndssjekk 1 · Lett

Hvilken bokstav i ACID handler om at ingen andre transaksjoner skal se en halvferdig endring?

AAtomicity — alt eller ingenting

CConsistency — integritetskrav holder

IIsolation — det ser ut som om transaksjonen er alene

DDurability — endringene overlever krasj

Riktig — Isolation. Det er Isolation som styrer at samtidige transaksjoner ikke skal forstyrre hverandre. Atomicity handler om alt-eller-ingenting innad i én transaksjon, og Durability handler om hva som overlever krasj.

Forhåndssjekk 2 · Middels

Hva er hovedgrunnen til at vi ikke bare kjører transaksjoner serielt etter hverandre?

ASQL-standarden forbyr det

BVi taper massiv ytelse — moderne maskiner og I/O-venting krever samtidighet

CDet bryter med ACID

DDet er umulig å implementere

Riktig — ytelse. Serielle schedules er helt korrekte, men sløser CPU og I/O. Mens én transaksjon venter på disk kan andre kjøre. Hele triksen er å la flere kjøre samtidig og bevise at resultatet er det samme som en eller annen seriell rekkefølge.

Forhåndssjekk 3 · Vanskelig

Hvilken komponent garanterer Atomicity og Durability når strømmen plutselig går?

ALock manager (2PL)

BRecovery manager + loggen, via WAL og undo/redo

CBuffer-pool — sidene er der allerede

DSQL-kompilatoren — den vet hva som skal kjøres

Riktig — recovery + logg. Lock manager har ansvar for Isolation, ikke kraschsikkerhet. Buffer-pool (sider midlertidig holdt i RAM) forsvinner ved strømbrudd. Recovery manager bruker loggposter på disk (etter WAL-regelen: logg på disk før dataen — forklares i 8C) til å rulle frem committed transaksjoner og rulle tilbake løse etter krasj.

Klar? Begynn med 8A · Intro og teori.