Transaksjoner

Transaksjoner, kap. 20-22 Svein Erik Bratsberg, IDI/NTNU Versjon 21.april 2022

Innhold

• Kap. 20
  • Hvorfor transaksjoner?
  • Transaksjoner og SQL
  • Transaksjonsteori
• Kap. 21
  • Flerbrukerkontroll (CC)
  • Korrekthet
  • Låsing
  • Multiversjons-CC
• Kap. 22
  • Logging og recovery
  • Abortering av transaksjoner
  • Krasjrecovery

Hvorfor transaksjoner?

• Støtter deling og samtidig aksess av data
  • Flerbrukerkontroll: Kap. 20 og 21
• Støtter sikker, pålitelig, atomisk aksess til store mengder data
  • Recovery: Kap. 20 og 22

Databaseoperasjoner (20.1.2)

• X - databaseobjekt: post eller blokk
  • read(X)
  • r(X)
  • write(X)
  • w(X)
• Tilhørende transaksjon 1
  • read1(X)
  • r1(X)
  • Commit1 c1 suksess: avslutting av transaksjon 1
  • Abort1 a1 abortering av transaksjon 1

Samtidighetsproblemer, eksempel (20.1.3)

• To transaksjoner

Samtidighetsproblemer (2)

• r1(A); w1(A); r2(A); w2(A); r2(B); w2(B); r1(B); w1(B);

Samtidighetsproblemer, klasser (20.1.3)

• Dirty read (Lese data som er skrevet til men ikke committet)

• Lost update / dirty write (Overskrive data som ikke er committet)

• Example: Lost update / dirty write

  • w1(buyer=‘Alice’); w2(buyer=‘Bob’); w2(invoice=‘Bob’); w1(invoice=‘Alice’);

• Unrepeatable read (Data endret mellom to reads i samme transaksjon (eks. i nested loop join))

• Incorrect summery
  • En transaksjon beregner en aggregatfunksjon mens en annen gjør en oppdatering
  • Figur 20.3 (c)

Incorrect summary

Oppgave

• Se på følgende historier:
  • H1: r1(A); w1(A); r1(B); w2(A); w2(B); w1(B); c1; c2;
  • H2: r1(A); w1(A); r2(A); w2(A); c2; r1(B); a1;
• Hva er problemene for H1 og H2?
  • Unrepeatable read
  • Dirty read
  • Lost update

Hvorfor trenger vi recovery?

• To typer recovery (gjenoppretting)
• En transaksjon ruller tilbake (rollback, abortering)
  • Uventet situasjon
  • Manglende data
  • Brukeren bestemmer det
  • Samtidighetskontrollen bestemmer det (CC, concurrency control)
• Systemkrasjrecovery
  • Databasesystemet, OS’et eller datamaskinen krever en restart

ACID - egenskaper ved en transaksjon

Transaksjon: en gruppering av operasjoner mot databasen som er

• A - atomiske: enten kjører de fullstendig, eller så kjører de ikke
• C - consistency: overholder konsistenskrav (primary key, references, check, osv)
• I - isolation: som er isolert fra hverandre. Merker ikke at noen kjører samtidig.
• D - durability: er permanente, dvs. mistes ikke etter commit.

En transaksjon er vanligvis en logisk operasjon eller oppgave

Eksempler på transaksjoner

• En gruppering av operasjoner mot databasen
• Banktransaksjon
• Tegn en polylinje
• Fyll ut et skjema
• Lever en eksamen
• Setter inn poster som har indekselementer som også må oppdateres
• …..

Commit/Abort (20.2.2/20.2.3)

• En transaksjon slutter med
• COMMIT: Alt gikk bra og endringene fra transaksjonen finnes i databasen. Connection.commit();
• ROLLBACK (abort): Transaksjonen rulles tilbake (aborteres) og ingen endringer fra transaksjonen finnes i databasen. Connection.rollback();
• Autocommit: Hver SQL-setning er en egen transaksjon. Kan skrus på. Default av i Python/SQLite3-API. Settes via isolation_level i connection-objektet.

Commit/abort (2)

SET AUTOCOMMIT=0;
UPDATE Account SET b = b - 1000 WHERE id=123123;
UPDATE Account SET b = b + 1000 WHERE id=234234;
COMMIT;

Ekt-eksempel RegMålCtrl

INSERT INTO Reg VALUES (1,123123,31,100);
INSERT INTO Reg VALUES (2,123123,32,120);
….
INSERT INTO Reg VALUES (9,123123,175,245);
UPDATE Loper SET status = ‘ok’
WHERE brikkenr=123123;
COMMIT;

SQLs isolasjonsnivå

SET TRANSACTION ISOLATION LEVEL
	READ UNCOMMITTED
	READ COMMITTED
	REPEATBALE READ
	SERIALIZABLE (default)

• Mer isolasjon/ «korrekthet» nedover
• Mindre samtidighet nedover
• Egenskaper vi vil unngå:
  • Dirty read
  • Unrepeatable read
  • Unngå fantomer: Hvis T leser en mengde verdier basert på en søkebetingelse, så vil ikke denne mengden endres av andre før T er ferdig. Aktuelt ved reskanning (nested loop f.eks.)

SQLs isolasjonsnivå (2)

Quiz 1

• Hvorfor må en transaksjon rulles tilbake?

1. Tabellen er ikke på 1. normalform ❌
2. Samtidighetskontrollen bestemte det ✅
3. Pga. dirty read ❓
4. Brukeren angret seg ✅

• ACID betyr

1. Atomicity, Concurrency, Isolation, Durability ❌
2. Atomicty, Consistency, Isolation, Database ❌
3. Attribute, Consistency, Isolation, Durability ❌
4. Atomicity, Consistency, Isolation, Durability ✅

• Hva er AUTOCOMMIT?

1. Databasen har en konsistent tilstand ❌
2. SQL commiter når loggen er full ❌
3. Hver SQL-setning er en egen transaksjon ✅
4. Du har bestemt deg for bilkjøpet ❌

• Hva er problemet med SERIALIZABLE?

1. Du får mye dirty read ❌
2. Tillater lite samtidighet ✅
3. Svak isolasjon ❌
4. Vanskelig å få til DURABILITY ❌

READ COMMITTED

1. When reading from the database, you will only see data that has been committed (no dirty reads).
2. When writing to the database, you will only overwrite data that has been committed (no dirty writes).

READ COMMITED default in Oracle, MS SQL Server and PostgresSQL. There are two ways used to support this.

1. Locking. The transaction sets write locks before writing a data item. Release of this lock is done at commit of the transaction. Before reading an item, the transaction sets a read lock on the item, but this read lock is released after the read is done.
2. Snapshot isolation. Most databases prevent dirty reads by keeping old values for writes until the transactions commit. Read transactions may read the old value. Only when the new value is committed do transactions switch over to reading the new value. To keep single record locks would cost too much, since one writer may cause multiple readers to wait. This is also called multi-version concurrency control.

Repeatable Read

• Solve the problems of re-reading some items
• Usually supported by snapshot isolation (as previously)
• Real confusion in commercial databases on the use of the terms SERIALIZABLE and REPEATABLE READ

Transaksjonshistorie (20.4.1)

• Historie (schedule)
  • Liste av aksjoner (read, write, abort, commit) for en mengde transaksjoner

Fra figur 20.3 a) og b):

Ha: r1(X);r2(X);w1(X);r1(Y);w2(X);w1(Y);
Hb: r1(X);w1(X);r2(X);w2(X),r1(Y);a1;

Transaksjonshistorie - konflikt

• To operasjoner fra en historie er i konflikt hvis
  • (1) de tilhører forskjellige transaksjoner
  • (2) de bruker samme dataelement
  • (3) minst en av operasjonene er en write
• Eksempler
  • Ha: r1(X) og w2(X) er i konflikt
  • Ha: w1(X) og w2(X) er i konflikt
  • Ha: r1(X) og r2(X) er ikke i konflikt
• To operasjoner er i konflikt hvis endring av rekkefølgen endrer resultatet på databasen

Transaksjoner og gjenopprettbarhet (20.4.2)

• Gjenopprettbar historie (recoverable schedule): Hver transaksjon committer etter at transaksjoner de har lest fra har committet.
  • H1: w2(A); w1(B); w1(A); r2(B); c1; c2;
• ACA (avoid cascading abort) Historier som unngår galopperende abort: Når transaksjoner kun kan lese verdier skrevet av committede transaksjoner.
  • H1 er ikke ACA.
  • H2: w1(A); w1(B); w2(A); c1; r2(B); c2;
• Strikt historie: Når transaksjonene verken kan lese eller skrive ikke-committede verdier
  • H3: w1(A); r1(B); w2(B); c; w2(A); c2;
• Kan gjøre undo recovery ved before image fra loggen
• Sammenheng:
  • Strikt $\subset$ ACA $\subset$ Gjenopprettbar $\subset$ Alle historier

Oppgaver

Historier og serialiserbarhet (20.5.1)

• Seriell historie
  • Historie som ikke fletter operasjoner fra forskjellige transaksjoner. Kjører etter hverandre
• Serialiserbar historie
  • Historie som har samme effekt på databasen som en seriell historie (resultatekvivalent)
• Figur 20.5

Historier og serialiserbarhet (2)

• Vi ønsker serialiserbare og ikke kreve serielle historier fordi vi ønsker samtidighet

1. Parallelle tråder
2. Diskaksess - andre tråder kan jobbe så lenge

Konfliktserialiserbarhet (20.5.1)

• Konflikt mellom to operasjoner
  • r1(A) og w2(A)
  • w1(A) og r2(A)
  • w1(A) og w2(A)
• To historier er konfliktekvivalente hvis de har samme rekkefølge for operasjoner med konflikt
• En historie er konfliktserialiserbar hvis den er konfliktekvivalent med en seriell historie
• Konfliktserialiserbarhet impliserer serialiserbarhet, men ikke nødvendigvis motsatt
• Figur 20.5 c) og d)

Konfliktserialiserbarhet

Presedensgraf (20.5.2)

• Rettet graf
• Noder: transaksjoner i historie H
• Kanter: T1 -> T2 finnes når det finnes en operasjon i T1 som er i konflikt med en operasjon i T2, og T1s operasjon skjer før T2s operasjon
• Hvis en presendensgraf ikke har sykler, er historien konfliktserialiserbar
• H1: r2(A); r1(B); w2(A); r3(A); w1(B); w3(A); r2(B); w2(B);
• H2: r2(A); r1(B); w2(A); r2(B); r3(A); w1(B); w3(A); w2(B);

Serialiserbarhet ved låsing (21.1.1)

• Bruker låser av dataelement (poster eller blokker) for å garantere konfliktserialiserbarhet
  • Låsetyper
  • Read_lock (X) (delt lås)
  • Write_lock (X) (eksklusiv lås)
• Flere transaksjoner kan ha read_lock (delt lås) på samme dataelement samtidig.
• Det er også mulig med oppgradering og nedgradering av låser.
  • Read_lock -> Write_lock
  • Write_lock -> Read_lock

Implementasjon av låser (21.1.1)

• Låsetabell i minne
• Postlåser
• Blokklåser
• Tabellåser
• Verdiområdelåser (unngå fantomer)
• Predikatlåser (unngå fantomer)
• Eksempel:
• w2

(B); r1 (A); r2 (A); r1 (B); r3 (B); 34 Låseimplementasjon

• w2

(B); r1 (A); r2 (A); r1 (B); r3 (B); 35 2PL - tofaselåsing (two-phase locking)

• En transaksjon har tofaselåsing hvis alle låseoperasjoner

skjer før alle opplåsingsoperasjoner T1 T2 Write_lock(X) Write_lock(X) Read(X) wait X = X + 1000 wait Write(X) wait Commit / Unlock(X) Read(X) X = X - 100 Write(X) Commit / Unlock(X) 36 2PL og «incorrect summary» T1 T2 Write_lock(X) Sum = 0 Read(X) Read_lock(X) X = X - 100 Wait Write(X) Wait Write_lock(Y) Wait Read(Y) Wait Y = Y + 100 Wait Write(Y) Wait Commit / Unlock (X, Y) Wait Read(X) Sum = Sum + X Read_lock(Y) Read(Y) Sum = Sum + Y Commit / Unlock (X,Y) 37 2PL impliserer serialiserbarhet 38 2PL-modeller

• Tofaselåsing impliserer serialiserbarhet
• Basic 2PL: «Symmetrisk fjell»
• Konservativ 2PL: Låser alt man trenger aller først
• Strict 2PL: Opplåsing av skrivelåser etter commit/abort
• Rigorous 2PL: Opplåsing etter commit/abort

39 Vranglås (21.1.3)

• To eller flere transaksjoner venter gjensidig på

hverandres låser

• Kan løses ved forskjellige metoder
• Unngåelse
• Oppdagelse
• Timeout

T1 T2 Read_lock(X) Read_lock(Y) Write_lock(Y) Write_lock(X) 40 Vranglåsoppdagelse (21.1.3)

• Den vanligste løsningen
• Konstruer wait-for-grafen:
• Hver transaksjon er en node
• Hvis Ti venter på en lås holdt av Tj

, får vi en rettet kant Ti -> Tj

• Vi har vranglås hvis grafen har sykler
• Prøv å abortere en transaksjon og se om sykelen

forsvinner 41 Timeout (21.1.3)

• Den enkleste løsningen
• La hver transaksjon ha en timeout.
• Hvis timeouten går, aborter transaksjonen
• Vanskelig å sette timeouten riktig

42 Rigorous 2PL eksempel

• H1

: r1 (A); w2 (A); w2 (B); w3 (B); w1 (B); C1 ; C2 ; C3 ;

• H2

: r1 (A); w2 (B); w2 (A); w3 (B); w1 (B); C1 ; C2 ; C3 ;

• For låsing: Hvis en transaksjon blir blokkert, blir alle operasjoner i

transaksjonen satt på vent, mens de neste operasjonene i historien blir utført i sekvens. 43 Multiversjons-CC (21.3)

• CC = Concurrency Control
• Brukes mye i dagens SQL-databaser
• La en leseoperasjon som er i konflikt, lese en gammel

versjon.

• Basert på tidsstempelordning (timestamp ordering):
• Hver transaksjon har et tidsstempel TS(T)
• Hvert dataelement kan finnes i flere versjoner

(X1 ,X2 , …., Xk )

• For hver versjon Xi

lagres

• read_TS(Xi

): Største tidsstempel for en trans som har lest den

• write_TS(Xi

): Tidsstempel for transaksjon som skrev Xi .

• Når en transaksjon skriver Xi

, settes begge til TS(T) 44 Multiversjons-CC (2)

• Regler for å sikre serialiserbarhet

1. T ønsker å utføre write(X)

• Hvis write_TS(Xi

) <= TS(T) AND read_TS(Xi ) > TS(T)

• Rull tilbake T
• Ellers
• Lag ny versjon Xi med read_TS(Xi

) = write_TS(Xi ) = TS(T) 2. T ønsker å utføre read(X)

• Finn i som har høyest write_TS(Xi

) <= TS(T)

• read_TS(Xi

) = Max(TS(T), read_TS(Xi ))

• Returner Xi
• Sikrer alltid suksess ved lesing
• Ulempe: Administrasjon av mange versjoner, mer plass, ikke

update-in-place? 45 Multiversjons-CC (3)

• To måter i praksis

1. Lagrer flere versjoner av poster i databasen og kjører GC

(søppeltømming) når de gamle versjonene ikke trenges lengre: Microsoft SQL, PostgresSQL, MySQL InnoDB (consistent reads).

2. Lagrer kun siste versjon av posten, men kan konstruere den

forrige versjonen vha. undo: Oracle

• Noen systemer bruker både låsing og multiversjons-CC,

«Multiversion 2PL»

1. Read/write-transaksjoner bruker låser og 2PL
2. Read-transaksjoner bruker multiversjons-CC

46 Recovery (kap. 22)

• Databasesystemet støtter sikker, atomisk aksess til store

mengder data

• Transaksjonene er
• A - atomiske: Enten har de kjørt helt, eller overhodet ikke
• C
• I
• D - durability: Er permanente. Etter commit mistes ikke data.

47 Transaksjoner etter krasjrecovery

• Vinnere: T1, T2 og T3 skal være permanente.
• Tapere: T4 og T5. Må aborteres. Hvorfor?

48 Force/steal-klassifisering av Logging & Recovery-algoritmer

• Utgangspunkt: Hvor fleksibel (uavhengig) er buffer

manager til logging/recovery

• Når kan skitne (dirty) blokker skrives?
• Når må skitne blokker skrives?
• Force: Må en skitten (oppdatert) blokk tvinges til disk

ved commit.

• Tregt: datablokkene kan være spredd over hele disken
• Steal: Kan en transaksjon stjele plassen i bufferet til en

skitten blokk?

• Hvis ikke, må en aktiv transaksjon ha alle skitne blokker i buffer

inntil commit. 49 Force/Steal (2) No steal Steal Force Shadowing (ikke logging) kap. 22.4 Undo-logging No-redo, kap. 22.3 No-force Redo-logging No-undo, kap. 22.2 Undo/redo-logging Aries, kap.- 22.5 50 Write-ahead logging (WAL) (22.1.3)

• Basis for undo/redo-logging
• Hver endring (insert/delete/update) har en loggpost i

loggen.

• Regler:
• Skriv en loggpost som endret en datablokk til disk før du skriver

datablokken (for undoformål)

• Skriv loggen til disk før en transaksjon committer (for redoformål)

«Force log at commit» 51 WAL-konsepter i ARIES (22.5)

• LSN - loggsekvensnummer. ID for loggpost. Stigende nr.
• PageLSN - LSN til loggpost som sist endret en blokk
• FlushedLSN - LSN til nyeste skrevne loggpost til disk
• Ved skriving av datablokk til disk, sjekk

PageLSN < FlushedLSN

• Hvis ikke, skriv (flush) logg først.

52 LSN-begreper (log sequence number) 53 Loggpost i ARIES

• PrevLSN: Peker til forrige loggpost i samme transaksjon.

For abortering av transaksjon.

• OpType: Update/insert/delete
• PageId: Hvilken blokk ble endret (BlokkId)
• Offset: Hvor i blokken ble det endret?
• BeforeImage: Verdi før endring
• AfterImage: Verdi etter endring

LSN TransID PrevLSN OpType PageId Offset BeforeImage AfterImage 54 Datastruktur for recovery (ARIES, 22.5)

• Transaksjonstabell
• Et element per aktiv transaksjon
• TransId
• Tilstand: aktiv, committed, aborting, aborted
• LastLSN: Peker til nyeste loggpost i transaksjonen
• Dirty page table (DPT)
• Et element per skitten (dirty) blokk i buffer
• PageID
• RecLSN: Peker til eldste loggpost som gjorde blokken skitten

55 Sjekkpunkting (22.5)

• Periodisk lager DBMSet et sjekkpunkt i loggen som skal

minimalisere tiden det tar å gjøre recovery

• Du slipper å skanne hele loggen ved recovery
• Begin checkpoint
• Lag start sjekkpunkt-loggpost
• End checkpoint
• Lag slutte sjekkpunkt-loggpost som inneholder
• Transtabell
• DPT - dirty page table
• Lagre LSN til sjekkpunktloggpost på sikkert sted. Logganker
• I noen systemer er sjekkpunkting koblet til det å skrive

skitne blokker til disk (ikke ARIES) 56 Abortering av transaksjon (22.5)

• Finn LastLSN fra transaksjonstabellen
• For hver loggpost i transaksjonen (bakover)
• Lag CLR - kompenserende loggpost, som gjør det motsatte av

loggposten (non-CLR)

• Gjør REDO av CLRen
• Fjern transaksjonen fra transaksjonstabellen
• CLRen er grunnlag for låser på radnivå

(mer presise enn låser på blokker) 57 Recovery etter krasj (22.5)

• Mål:
• Sørge for at vinnertransaksjoner er permanente.

De som har committed før krasj.

• Sørge for at tapertransaksjoner blir borte (aborted).

De som ikke committed før krasj.

• Faser:

1. Analyse: Finn vinnere og tapere. Rekonstruer DPT/TransTab
2. REDO: Redo alle loggposter
3. UNDO: Undo effekten av alle tapertransaksjoner

58 3 faser i Recovery 59 Recovery - eksempel Feil i læreboka: C=1 i DPT etter analysen 60 REDO av loggpost (ARIES, 22.5)

• Loggposten trenger ikke REDO hvis

1. Den tilhørende blokken ikke er i dirty page table (DPT)
2. Blokken er i DPT, men recLSN for blokken er større enn

loggpostens LSN 3. Blokkens pageLSN er større eller lik loggpostens LSN. Her må blokken leses inn.

• Ellers redo loggpost:

1. Sett inn / skriv after image inn i blokken.
2. Oppdater blokkens pageLSN til loggpostens LSN

61 Andre recoveryteknikker (22.2/22.3/22.4)

• Undo/no-redo: Som ARIES, men kun undo-logging
• No-undo/redo: Som ARIES, men kun redo-logging
• Shadowing: bruker ikke logging, men lager kopier av

data ved oppdatering. Committer transaksjonen ved å kopiere inn pekere til nye data. Må ha katalog med pekere til data.

• Skiller mellom update-in-place og shadowing.