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.

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.

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

Alt eller ingenting — enten gjøres alle stegene, eller ingen.
Konsistens bevares — integritetskrav (PK, FK, CHECK) holder etter commit.
Som om alene — to samtidige transaksjoner skal ikke se hverandre halvferdige.
Varig — etter commit overlever resultatet enhver krasj.

Disse fire er kjent som ACID. Hele kapittel 8 forklarer hvordan databasen faktisk leverer dem.

02 · Helhetsbilde

Kartet over alt som skjer

Tre hovedmekanismer jobber sammen i bakgrunnen hver gang du skriver BEGIN; … COMMIT;:

De tre delene av kapittelet henger på samme arkitektur: scheduler/lock manager håndterer Isolation, mens recovery manager sammen med loggen sikrer Atomicity og Durability.

Slides

Slidene transaksjoner.pdf dekker hele kapittelet. Underkapitlene under er bygd opp som lese-stier — figurer og quizzer underveis, ikke bare i slutten.

03 · 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, conflict serializability, recoverability/ACA/strict, 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

→

04 · 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.

05 · 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 er bare RAM som forsvinner ved strømbrudd. Recovery manager bruker logg-records på disk (WAL-regelen) til å rulle frem committed transaksjoner og rulle tilbake løsere etter krasj.

Klar? Begynn med 8A · Intro og teori.