RNDr. Jakub Lokoč, Ph.D.

Transkript

3. Teorie
uspořádatelnosti
2. Modely
transakcí
4. Plánování
běhu transakcí
RNDr. Jakub Lokoč, Ph.D.
5. Alternativní
protokoly
6. TP manažer a
zotavení systému
1. TP systémy
7. Distribuované
transakce
1






4
5
6
7
P. A. Bernstein, V. Hadzilacos, N. Goodman,
Concurrency Control and Recovery in Database Systems (1987 !!!)
J. Grey, A. Reuter, Transaction Processing: Concepts and Techniques (1992 !!!)
R. Ramakrishnan, J. Gehrke, Database Management Systems, 3rd edition (2003)
P. A. Bernstein, E. Newcomer, Principles of Transaction Processing, 2nd edition (2009)
U. Özsu, P. Valduriez, Principles of Distributed Database Systems, 3rd edition (2009)
Slajdy od doc. Petra Tůmy
Neoficiální, ale taky dobré zdroje


3
Doporučené zdroje


2
http://wiki.matfyz.cz/index.php?title=Transakce
Ideální je přečíst vše – spousta souvislostí…
4/20/2015
Transakce, RNDr. Jakub Lokoč, Ph.D., KSI MFF UK
2
1

2
3
4
5
6
7
Pravděpodobné
 Bodovaná písemka (60-75% = 3, 76-90% = 2, 91 – 100% = 1)
 Referáty = bonusové body (dle kvality referátu až 10%)
 Referáty dobrovolné, ale jen ostře PŘED první písemkou
(cca 20 minut na zadané téma)
 Důsledek – možnost získat více než 100% bodů 

Nepravděpodobné
 Ústní zkoušení po jednom
4/20/2015
3
1
2
3
4
5
6

Souběžné zpracování velkého množství úloh
nad stejnými daty/objekty

Robustní a spolehlivé systémy odolné proti
chybám
4/20/2015
7
4
1

2
3
4
5
6
7
Souběžné zpracování úloh
 Propustnost – tisíce úloh za sekundu
 Konkurence – úlohy pracují nad stejnými daty
 Korektnost – úlohy vidí jen konzistentní data
 Odezva – souběžnost příliš nezpomaluje
 Paralelismus – maximální využití zdrojů
 Zotavitelnost – např. z uváznutí
4/20/2015
5
1

2
3
4
5
6
7
Robustnost a spolehlivost








4/20/2015
Nedochází k výpadkům
Odolnost proti chybám
Z chyb se systém automaticky zotaví
Zachování konzistence dat
Garantovaná spolehlivost (nejsou v tom jen $)
Distribuovaná řešení – škálovatelnost
…
A přitom nízké náklady na vývoj a provoz
6
1

2
3
4
5
6
7
Dostupnost systému (Availability)
 Podíl přijatelné doby odezvy systému ku celkovému
nabízenému času (měřeno v %)
 Systémy se rozdělují na 7 tříd (log101/(1-A))
4/20/2015
Třída
Dostupnost
1 – Unmanaged
90%
2 – Managed
99%
3 – Well-managed
99.9%
4 – Fault-tolerant
99.99%
5 – High-availability
99.999%
Jaderný reaktor
6 – Very-high-availability
99.9999%
Telefonní ústředna
7 – Ultra-availability
99.99999%
Systémy v letadlech
Některé BC práce…
7
1
2
3
4
5



Systém se skládá z SW/HW modulů
Modul má specifikované a zjištěné chování
Sledovaný rozdíl = chybné chování (bug vs. feature)

Selhání/výpadek je způsobeno chybou v kódu (error programátor) nebo selháním systému (failure - havárie)

Zpoždění chyby (error latency) = doba mezi výskytem v
modulu a jejím projevením

Chyba je latentní/efektivní pokud se neprojevila/projevila
4/20/2015
6
7
8
1

2
3
4
5
6
7
Spolehlivost a dostupnost
 MTTF (mean time to failure) - čas do příští chyby
 MTTR (mean time to repair) - čas zotavení
 Dostupnost modulu = MTTF / (MTTF + MTTR)

Chyba je soft / hard pokud se z ní systém zotaví /
nezotaví

Failfast modul se zastaví hned po detekci chyby
– latentní chyby jsou vzácné
4/20/2015
9
1
3
4
5
6
7
Životní cyklus informačního systému
chybovost

2
(nasazování)
(dobíhání)
Výpadek proudu (frekvence vs. doba)
Frekvence

čas
doba trvání výpadku („rychlost“ opravy)
4/20/2015
10
1



2
3
4
5
6
7
Nechť A a B jsou nezávislé jevy
P(A and B) = P(A) * P(B)
P(A or B) = P(A) + P(B) - P(A) * P(B)
 Pro malé hodnoty P(A) a P(B) výraz P(A)*P(B) zanedbáme

Poruchovost je často nezávislá na době běhu systému
 Tzv. memoryless, pak se MT (mean time to event) spočítá
 MT(A) = 1 / P(A) ale jen pro hodně malé P(A)
 Pro první ze skupiny událostí pak platí vzorec
 MT(Group) = 1 / (P(A1) + … + P(An))
 MT(N * A) = MT(A) / N (pro události se stejnou MT)
4/20/2015
11
1

2
3
4
5
6
7
Máte dva roky staré levnější auto a dočtete se, že 1 z
1000 dvouletých modelů se ročně rozpadne…
A) Jaký je MTTF vašeho auta?
B) Jaký je poměr selhání za hodinu?
C) Když máte 100 takových aut, jaká je šance, že se
vám jedno z nich rozpadne?
 D) Proč je odpověď na první dotaz o tolik větší, než
je záruka auta?
 E) Když bude oprava trvat týden, jaká je dostupnost
vašeho auta?



4/20/2015
12
1

2
3
4
5
6
7
Spočítejte dostupnost a spolehlivost newyorské burzy
otevřené 250 dnů v roce, 8 hodin denně. Mezi 1980-90 měla
4 výpadky: 1 den kvůli sněhu, 4 hodiny kvůli požáru, 45
sekund kvůli SW chybě a 3 hodiny kvůli panice na burze.
A) Jaká je její spolehlivost?
 B) Dostupnost?
 C) Třída dostupnosti?

4/20/2015
13
1







2
3
4
5
6
7
konektory, kabely 1000y MTTF
logické obvody 3-20y MTTF soft/hard=1/1 až10/1
disky u PC 1y MTTF, dražší 5-20y MTTF (ale
hodně záleží na typu chyb, soft read error je
častější, některé chyby jednou za milion let)
workstations 3-5y MTTF, software 1w MTTF
SW: 3 chyby ve 100 řádcích kódu, 100/1 soft/hard
datové spoje v USA 10-9 BER (bit error rate) optika
LAN: většina chyb kvůli protokolům, 3w MTTF
4/20/2015
14
1

Celý systém spadne, je mimo provoz

Může mít drastické (až fatální) následky
2
3
4
5
6
7
 Výpadek systému během dlouho chystané a
neopakovatelné operace („Až mávnu rukou…“)
 Výpadek systému v letadle, na letišti

Co stojí za výpadky?
 Dnes je HW relativně spolehlivý, navíc chyby většinou
maskuje, dle studií má největší podíl na výpadku SW
 HW chyba je navíc často doprovázena SW chybou, chybou
operátora nebo chybou údržby
 V USA časté výpadky proudu
4/20/2015
15
1
2
3
4
5
6
7

Předcházení – vývoj bezchybného HW a SW,
snaha minimalizovat chyby

Zotavení při výskytu – oprava latentních nebo
efektivních chyb
4/20/2015
16
1

2
3
4
5
6
7
HW metody
 Zdvojování, N-plexing (porovnání výsledku)
 Obvyklé TMR (triple module redundancy)

SW metody




4/20/2015
Metody návrhu (NASA 5000$ na řádek kódu)
Redundantní programování (ala N-plexing)
Defenzivní programování (počítat se vším)
TRANSAKCE
17
1
2
3
4
5
6
7

Provede se vše, co je předmětem kontraktu,
jinak se vše vrací na začátek

Ideální kontrakt by byl atomický, tj. „z ruky do
ruky“

Kontrakty se ale většinou skládají z více
atomických operací
4/20/2015
18
1
2
3
4
5
6
7





Zaplacení částky
Převoz telat z místa A do místa B
Označkování telat
Převoz z místa B do místa C
…



Zde nelze použít forma „z ruky do ruky“
Po zaplacení částky je systém v nekonzistentním stavu
Je potřeba prostředníka, který dohlíží na legálnost
kontraktu (smlouvy, zákony)

Opět problém s konkurencí - kdo platí stáje za telata, když
je částka předána, ale telata jsou ještě v místě A?
4/20/2015
19
1

2
3
4
5
6
7
Vhodně navržený koncept
 Splňuje vlastnosti pro spolehlivost a konkurenci
 Intuitivní, použitelný v podstatě kdekoliv
▪ Transakce je … cokoliv (Gray – „Už staří Sumerové …“)
▪ Z pohledu PC - jednotka práce nad perzistentními daty
▪ Spuštěný program pracující se sdílenou DB (Bernstein)

Příklady oblastí, které potřebují transakce




4/20/2015
Bankovnictví – převod peněz z účtu na účet
Doprava, obchod – rezervace a platby
Pojišťovny – stažení nových verzí číselníků
Armáda – odpálení jaderné hlavice
20
1
2
3
4
5
6
7

Začátek (Begin) – od této chvíle jsou vykonávány
operace transakce, veškeré provedené změny
jsou viditelné až po potvrzení

Potvrzení (Commit) – transakce úspěšně skončila
svou práci, všechny změny provedené transakcí
jsou potvrzeny a zapsány

Zrušení (Abort, Rollback) – vykonávání transakce
je zastaveno (transakcí, databází, spadne
systém), provedené změny nejsou viditelné, ve
výsledku jako by transakce nikdy nezačala
4/20/2015
21
1

2
3
4
5
6
7
Atomicita (Atomicity)
 Vše nebo nic (problém s operacemi typu – odpálení rakety,
výběr peněz z bankomatu)

Konzistence (Consistency)
 Korektní transformace stavů

Izolovanost (Isolation)
 Nevznikají chyby způsobené souběžným během

Trvanlivost (Durability)
 Po potvrzení transakce se výsledky neztratí
4/20/2015
22
1
2
3
4
5
6
7

Atomicita je zásadní pro legálnost kontraktu

Pokud není možné transakci dokončit, je potřeba
vše vrátit zpět – logování všech akcí

Potvrzením je vše stvrzeno, není cesty zpět

Problém s akcemi, které nelze vrátit zpět
 Předčasné potvrzení – kompenzační transakce
 Havárie – zrušení transakce – kompenzační akce,
někdy ale dost složité (výběr peněz, odpálení hlavice)
4/20/2015
23
1
2
3
4
5

Řeší sama transakce, tj. programátor

Musí platit, že transakce transformuje DB z
konzistentního stavu S1 do druhého S2

Pak je sériové zapojení transakcí OK
6
7
 Současně ale spoléhá i na atomicitu a trvanlivost
 Při paralelním běhu též na izolaci
4/20/2015
24
1
2
3
4
5
6

Intuitivně - pokud běží více transakcí současně,
je výsledek stejný, jako kdyby běžely sériově –
jak to zajistit?

Celá teorie kontroly konkurence





4/20/2015
7
Problematika plánovačů
Zamykání
Úrovně izolace
Verzování
…
25
1

2
3
4
5
6
7
Po potvrzení je potřeba provést dodatečné
akce, ale může opět dojít k havárii
 Zápis dat z cache na disk
 Odeslání zpráv

Neodvolatelnost Potvrzení a Zrušení transakce

Nejčastěji implementováno manažery zdrojů
4/20/2015
26
1
2
3
4
5
6
7

Opakované spouštění jednoduchých i dávkových
operací nad sdílenou DB

Hodně (sofistikovaných) klientů (OLTP)

Vysoká dostupnost systému

Automatizace
 Zotavení po havárii
 Zajištění stability dat
 Vyvažování zátěže
4/20/2015
27
1

Dávkové zpracování

Time-sharing

Real-time processing

Klinet-server processing
4/20/2015
2
3
4
5
6
7
28
1
2
3
4
5
Dávkové zpracování
Time-sharing
Real-time
Klient-server
T.O.P.
Data
Soukromá
Soukromá
Soukromá
Sdílená
Sdílená
Doba
Dlouhá
Dlouhá
Velmi krátká
Dlouhá
Krátká
Spolehlivost
Běžná
Běžná
Velmi vysoká
Běžná
Velmi vysoká
Konzistence
Žádná
Žádná
Žádná
Žádná
ACID
Work pattern
Pravidlný
Pravidlný
Náhodný
Náhodný
Náhodný
Počet zařízení
10
100
1.000
100
10.000
Služby
Virtuální proc.
Virtuální proc.
Jednoduché fce
Jednoduché pož.
I složité fce
Kritéria výkonu
Propustnost
Čas odezvy
Čas odezvy
Oboje
Oboje
Dostupnost
Běžná
Běžná
Vysoká
Vysoká
Vysoká
Autorizace pro
Job
Uživatel
Žádná
Požadavek
Požadavek
4/20/2015
6
7
29
1
2
3
4
5
6
7

Přímé vs. frontované (ví se o existenci fronty)

Jednoduché vs. komplexní transakce
 Málo vs. hodně prostředků
 Rychlé vs. dlouhotrvající
 Nedochází vs. dochází k výměně zpráv

Lokální vs. distribuované transakce
4/20/2015
30
1
2
3

Prostředí, ve kterém se vytváří, spouští a
spravují TP aplikace

Umožňuje vyvíjet levněji TP aplikace
4
5
6
7
 Programátorské rozhraní
 Nástroje pro monitoring aplikací
 Umožní jednoduchou škálovatelnost
 Podpora distribuovaných transakcí
4/20/2015
31
1

2
3
4
5
6
7
Spolehlivé a výkonné systémy
 Zotavení z HW a SW chyb (SW je problém)
 Chybovost modulů se dá odhadovat – míra rizika
 Souběžné zpracování velkého počtu úloh

Transakce (ACID)




4/20/2015
Vhodný model splňující požadované vlastnosti
Výpočetní styl vhodný pro hodně aplikací
Implementováno a ověřeno v praxi
TP middleware – efektivní vývoj a správa TP aplikací
32
1
2
3
4
5
6
7

Transakční chování požadováno v různých SW systémech,
platformách, architekturách, prostředích

Transakční monitory byly vyvíjeny jako middleware
systémy zajišťující služby, které nebyly v dané době
dostupné v OS nebo jiných podpůrných platformách

Dnes se setkáváme více s pojmem transakční middleware,
představující komplexní balík řešení pro vývoj, řízení a
efektivní práci s transakcemi v distribuovaném prostředí

Transakční zpracování součástí různých standardů (např.
WS-Transactions, XA Interface, OTS, JTA, SCA, …)
4/20/2015
34
1

2
3
4
5
6
7
Vývoj od roku 1950/60
 SABRE – rezervační systém od IBM a American Airlines
 PARS-Financial, později TPF (ACID sémantika definována aplikací)

Příklady stále ještě používaných TP monitorů






Customer Information Control System (CICS) Transaction Server
Information Management System (IMS)
Tuxedo
ACMS
Pathway TS/MP
Podpora rozhraní do moderních TP prostředí
 Web Services wrappers, Java EE connectors, CORBA interfaces
 Možnost integrace s .NET Framework a Java EE
4/20/2015
35
1

Vyvinut v roce 1968 společností IBM

Průkopník mnoha technologií
2
3
4
5
6
7
 2PC protokol, transakční RPC

Využívá tzv. regiony (odpovídají procesům)
 Vlastní adresový prostor ve kterém simuluje více
vláken (vlastní implementace – musí řešit blokování)
 Všechny zdroje jsou v regionu (včetně prezentační
vrstvy) kvůli vysokým nákladům na komunikaci v
tehdejších systémech
 Komunikace mezi procesy pomocí synchronního DPL
4/20/2015
36
1
2
3
4
5
6
7

Vyvinut IBM společně s Rockwell a Caterpillar pro Apollo program
– inventář účtů pro Saturn V, tj. design zaměřen na velkou
hierarchickou DB

Jeden z prvních OLTP (1968), předtím se používalo dávkové
zpracování, které IMS též podporuje

Obsahuje IMS transakční manažer a hierarchický DB systém
(fungují nezávisle na sobě, je možné je použít zvlášť)

Využívá procesy operačního systému, které využívají služby TP
monitoru

Základní IMS TM používá fronty (možno obejít pomocí Fast Path)

Dnešní IMS aplikace používají DB2
4/20/2015
37
1

Vyvinut AT&T’s Bell Laboratories v roce 1984 pro potřeby
telekomunikačních aplikací, nyní vlastní práva Oracle

Design založen na IMS, původně měl IMS nahradit u US
telekomunikačních společností

Poskytuje dvě hlavní API
2
3
4
5
6
7
 CORBA C++ API a Application Transaction Monitor Interface (ATMI), což je
kolekce runtime služeb, které se dají volat přímo z C, C++ a Cobol aplikací
 ATMI silně závisí na systémových knihovnách UNIXu a externích službách DB

Služby poskytují podporu pro komunikaci, distribuované transakce a
management systému

Tuxedo bylo základem pro mnoho X/Open DTP standardů (DTP model,
XA, TX, XATMI), implementuje OTS přes své CORBA API
4/20/2015
38
1

Velká výzva – mnoho existujících architektur, modelů
programování, komunikačních protokolů, integrace, …

Cíle
2
3
4
5
6
7
 Portabilita – stejný transakční program na různých transakčních
middleware produktech (TMP)
 Interoperabilita – výměna dat a informací během zpracování jedné
transakce na různých TMP
 Integrace – umožnění kombinace komponent různých TMP

Příklady – WS-transactions, XA protocol, OTS, JTA

Vztahy mezi standardy
 XA protocol je zahrnut v OTS
 XA i OTS jsou zahrnuty v JTA
4/20/2015
39
1
2
3
4
5
6

Rozšiřuje WS (SOAP a WDSL) o transakční
kontext v hlavičce SOAP a definuje protokol pro
transakční interoperabilitu mezi WS

Zahrnuje tři specifikace
7
 WS-Coordination
▪ Koordinátor podporující různé protokoly (WS-AT, WS-BA)
▪ Definuje jak WS spolupracuje se koordinátorem
 WS-AtomicTransactions – 2PC protokol
 WS-BusinessActivity – definuje open nested
transakční protokol s kompenzujícími akcemi
4/20/2015
40
1

2
3
4
5
6
7
Komponenty DTP modelu dle X/Open
 Aplikační program – definuje hranice a akce transakce
 Manažer zdrojů – poskytuje přístup ke sdíleným zdrojům (např. k DB systému)
 Transakční manažer – řízení potvrzení/zrušení transakce v DP

X/Open definuje rozhraní pro komunikaci mezi moduly
Manažer zdrojů 1
Aplikační program
tx_open, tx_ close
tx_begin, tx_commit,
tx_rollback
4/20/2015
Manažer zdrojů 2
Transakční manažer
xa_open, xa_ close
xa_start, xa_end,
xa_prepare, xa_commit,
xa_rollback
xa_recover, xa_forget
41
1
2
3
4
5
6
7

Služba z CORBA specifikace, zahrnuto v Java EE pro
propagaci transakčního kontextu

Možnost používat různé CORBA objekty v transakcích

Transakční klient/server a recoverable server
představují aplikaci, transakční služby implementují
transakčního manažera

Komunikace přes ORB

Podporuje implicitní i explicitní model programování
4/20/2015
42
1
2
3
4
5

Definuje rozhraní v Javě pro TX a XA protokoly

Použito v JCA, JDBC a JMS

Skládá se ze tří hlavních částí
6
7
 Rozhraní umžňující aplikaci explicitně začít,
propagovat a ukončit transakci
 Java language mapping of the XA interface
 Rozhraní mezi transakčním manažerem a dalšími
komponentami aplikačního serveru
4/20/2015
43
1
2
3
4
5

Moderní prostředí pro vývoj a nasazení TP aplikací

Vícevrstvé TP aplikace
6
7
 Kient -> Databáze
 Klient -> Request Controller -> Databáze
 Klient -> Request Controller -> Transakční Server ->
Databáze

Explicitní vs. deklarativní model programování
transakcí

Databáze „dohánějí“ fce transakčního middleware
4/20/2015
44
1
2
3
4
5
6
7

Front-end: Swing Library, Servlets, Java Server Pages
a Java Server Faces

Request controllers a transakční servery: Enterprise
Java Beans (EJBs)

Transakční manažer: specifikace implementace v JTS,
přístupný přes rozhraní Java Transaction API (JTA)

Integrace s jinými systémy: The Java Connector
Architecture (JCA) API

Business procesy: WS-BPEL engine
4/20/2015
45
1
2
3
4
5
6
7

Front-end: Windows Presentation Foundation (WPF), ASP.NET,
Silverlight

Request controllers a transakční servery: Windows Communication
Foundation (WCF) a Internet Information Server (IIS)

Transakční manažer: Microsoft Distributed Transaction
Coordinator (DTC) a Lightweight Transaction Manager (LTM)

Integrace s jinými systémy: Host Integration Server (HIS) and
BizTalk Server

Business procesy: Windows Workflow Foundation (WF) a WS-BPEL
podpora v BizTalk Server
4/20/2015
46
1

3
4
5
6
7
Transaction Processing Performance Council (TPC)





2
Sdružení firem vytvářející univerzální benchmarky
Základní jednotka – transakce za sekundu (tps)
Cena/výkon = (cena HW + SW + 5let údržby) / tps
http://www.tpc.org/
Aktuální benchmarky
 TPC-C – OLTP test, dávkové a interaktivní transakce
 TPC-E – nová verze OLTP workload (robustní systémy)
 TPC-H – business-oriented ad-hoc dotazy a konkurentní
datové modifikace
4/20/2015
47
1

3
4
5
6
7
Služby s vlivem na programování aplikací







2
Řízení heterogenity (uzavření operací do transakce)
Řízení komunikace (TRPC)
Řízení terminálů (komunikace a zprávy též v transakci)
Prezentační služby – restart prostředí
Řízení kontextu – udržování kontextu
Start/restart – uvedení do konzistentního stavu
Další služby





4/20/2015
Řízení konfigurací
Autorizace
Administrace
Vyvažování zátěže
…
48
1

2
3
4
5
6
7
TP monitor musí řídit systémové zdroje
 Podobné jako v OS, který by se mohl rozšířit o TP

Pro každý terminál musí existovat proces,
který zpracovává jeho požadavky

Je potřeba pochopit aspekty mapování
požadavků na vybrané procesy
4/20/2015
49
1
Vyvolání
služby
N
1
Server
(1 proces)
N
1
N
N
1
1
N
Požadavek
obsahuje
TAC/TPN
4/20/2015
3
4
5
6
7
Server class
1
1
Služba
2
1
Aplikační
program
N
Jak mapovat požadavky na proces?
1
Aplikace
50
1
Jeden proces na terminál
Mnoho serverů, jeden plánovač
2
3
4
5
6
7
Jediný serverový proces
… a více plánovačů
Která architektura odpovídá datovému modelu z předchozího slajdu?
4/20/2015
51
1
2
3
4

Použitelné jen pro malý počet klientů (10-100)

10.000 klientů = 10.000 procesů - nepoužitelné
5
6
7
 Co když většina procesů nic nedělá
 Nákladné přepínání kontextu
 Ne každý klient potřebuje všechny fce
 Příliš mnoho řídících struktur (každý proces vlastní)

Málo flexibilní vyvažování zátěže – priority procesů
řídí OS
4/20/2015
52
1
2
3
4
5
6

TP monitor má vše v rukou – priority řídí sám

Ale…
7
 Musí podporovat všechny protokoly
 Omezení jedním adresovým prostorem
 Pád procesu = pád všech spojení
 Jeden proces je úzké hrdlo (multiprocesory)
4/20/2015
53
1

2
3
4
5
6
7
Každý terminál je obsluhován jedním vláknem
 Problém s ochranou paměti

Vlákna pomocí Middleware
 Implementace na míru (rychlost)
 Mnoho funkcí je potřeba volat přes API, např. musí
kontrolovat I/O operace (proces nesmí usnout)

Vícevláknové OS
 Přepínání mezi vlákny = volání systémových funkcí
 Může využívat SMP nebo multicore procesory
 V dnešní době převažuje v TP produktech
4/20/2015
54
1

3
4
5
6
7
Plánovač – řídí příjem a distribuci požadavků






2
Speciálně vyčleněný proces – prezentační vrstva
Řeší autentikaci klientů
Identifikace požadavků
Distribuce jednotlivým aplikačním procesům
Úzké hrdlo pro případ velkého množství požadavků
Aplikační proces
 Aplikace jich může mít více
 Komunikuje jen s příslušnými zdroji
 Chráněny vůči sobě navzájem (vlastní adresový prostor)
4/20/2015
55
1
2
3
4
5
6

Zobecnění předchozí architektury

Více funkčně shodných procesů

Přijímají a dále distribuují požadavky klientů
4/20/2015
7
56
1
2
3
4
5
6
7
Vstupní fronta
TP monitor bere každý podsystém
jako resource manažera, který
poskytuje transakční přístup
k poskytovaným zdrojům
Často požadavek na perzistenci
front (hlavně výstupních), tj. po
pádu systému je možné zpětně
nabídnout výsledky potvrzených
transakcí klientovi
Autorizace
Lock manažer
Aplikační
servery
Recovery manažer
Log manažer
DB a RM
Výstupní fronta
4/20/2015
57
1

2
3
4
5
6
7
Prezentační služby
 Rozhraní odstiňující programátora od technických detailů

Správa front
 Příjem požadavku a zařazení do správné fronty
 Doručení výsledku na klienta (at least/most/exactly once)
 Požadavky jsou ve frontě pouze tehdy, pokud klient
potvrdí

Správa serverových tříd/procesů
 Vytvoření procesu a jeho spravování (práva, priority,
přepínání kontextu)
 Vytvoření front
4/20/2015
58
1

2
3
4
5
6
7
Plánování a časování požadavků
 Přeposílání požadavků na místo určení
 Vyvažování zátěže

Autorizace požadavků
 Statická vs. Dynamická (value-dependent) autorizace

Řízení kontextu
 Průběžné ukládání dat, kterých se transakce týká
 Rozesílání výsledků mezi servery
4/20/2015
59
1

2
3
4
5
6
7
Potřeba rozsáhlé repository
 Seznamy všech uzlů, SW a HW komponent
 Uživatelé, role, profily, konfigurace

Rozhraní pro TP monitor




4/20/2015
Nastartování a restart
Definice nového resource managera
Změna konfigurace serverového procesu
Zpracování TRPC požadavků
60
1

2
3
4
5
6
7
Vzdálené volání procedur (Remote Procedure Call)

RPC protokol umožňuje komunikaci procesů na dálku
 Volání vzdálené procedury se programátorovi navenek jeví jako lokální volání
 Stub procedury zajišťují marshalling/unmarshalling parametrů
 Potřeba jednotného IDL (Interface definition language), binding (jméno + port)
Klient
4/20/2015
Lokální
volání
funkce
Stub
procedura
klient
Vrácení
výsledku
Stub
procedura
klient
Síťové
služby
Server
Stub
procedura
server
Volání
skutečné
funkce
Stub
procedura
server
Vrácení
výsledku
61
1
2
3
4
5
6
7

Mnohem komplikovanější než RPC

Používají se resource mangery (RM), ty mohou
používat další TRPC …

Všechny začleněné RM se stávají součástí transakce

Každé TRPC volání musí mít ID, musí být evidováno ve
všech TRPC, které spustí

Vzniklé procesy, zprávy musí mít ID TRPC

Navíc musí vše proběhnout jako jedna transakce
4/20/2015
62
1

3
4
5
6
7
Řízení účastníků





2
Seznam resource manažerů (RM) na transakci
Před konečným potvrzením musí všichni potvrdit
Zařizuje transakční manažer (2PC)
Jednodušší RM nemusí potvrzovat potvrzení
Chránění informací o transakcích
 RM může být volaný několikrát jednou transakcí
 Každé volání může být zpracováno jiným procesem
 Každé volání může být iniciováno jiným procesem

Podpora transakčních protokolů
 ACID na všech RM pomocí TRPC
4/20/2015
63
1
2
3
4
5
6
7

Jsou různé typy resource manažerů dle
podporovaného rozhraní pro transakce

Rozhraní jsou definované i pro komunikaci
mezi resource manažery

A také pro administraci manažerů monitorem

Resource manažer nesmí být volán přímo, ale
přes prostředníka – tp monitor
4/20/2015
64
1

2
3
4
5
6
7
Proč udržovat kontext na RM?
 Několik operací jedné transakce na jednom RM
 Operace zpracována/vyvolána různými
procesy/klienty

Scénáře komunikace
 Nezávislá volání – operace volány nezávisle na sobě
 Sekvence volání – „dalších 10“ – je nutné znát
výsledek předchozí operace + její kontext
 Komplexní interakce – výsledky operací se musí
uchovat až do celkového potvrzení – tj. výsledek se na
závěr složí z průběžně volaných operací
4/20/2015
65
1
2
3
4
5

Používat sessions nebo volání služeb?

Pokud spolu mají delší dobu komunikovat, tak sessions

Jak tedy udržovat kontext?





6
7
Pomocí komunikačního systému
Posílání kontextu v těle zpráv
Uložení kontextu mimo server v DB
Uložení kontextu ve sdílené paměti
Typy kontextu
 Client-oriented (běžné komunikační systémy)
 Transaction-oriented (resource manažer)
4/20/2015
66
1

2
3
4
5
6
7
Proč nepoužívat přímé ale frontované transakce
 Load control – chvilkové přetížení se zbytečně neřeší
novým procesem
 End-user control – čekání na převzetí výsledků
uživatelem nezastaví celý proces
 Recoverable data entry – nezahlcuje se server, není
prioritou doba odezvy, ale průchodnost systému
 Multi-transaction request – u řetězce serverů mohou
fronty zvýšit průchodnost celého systému

Dva typy front – volatile a durable
4/20/2015
67
1
2
3
4
5
6

Slouží k implementaci přímého volání transakcí

Pokud je více požadavků než procesů, dojde k
7
 Zamítnutí požadavku
 Vytvoření nového procesu
 Vložení do fronty (uživateli skryto)

Organizace fronty většinou FIFO

Přístup ke frontě musí být chráněn
4/20/2015
68
1
2

Slouží pro asynchronní transakční zpracování

Klient po předání požadavku může potvrdit

Každá žádost = tři transakce
3
4
5
6
7
 Klientská žádost
 Výpočet na serveru
 Zpracování výsledku klientem

Manažer zdrojů může mít více front

Typy front – ASAP, timed (zpracování po čase),
threshold (zpracování až pro určitý počet požadavků)
4/20/2015
69
1

2
3
4
5
6
7
Zpracování prvků v FIFO frontě v případě abortu
 Odebrání prvku je součástí transakce, tj., abort = vrácení
„nejstaršího“ prvku do fronty
 T1 dělá na nejstarším prvku, na kterém prvku má dělat T2?
▪ Sériové zpracování – T2 čeká na výsledek, není moc efektivní
▪ Transakce T2 hledá nejstarší prvek, na kterém nedělá jiná transakce
▪ Pokud je požadováno striktní FIFO zpracování a T1 je zrušena, tak
musí být zrušena i T2

Jak se zbavit neproveditelného požadavku
 Použití čítače neúspěšných pokusů, po určitém počtu abortů
prvek z fronty vyhodit (abort ale nemůže dělat update)
 Update fronty buď jako nechráněná akce, nebo maskovat
abort za úspěšnou transakci, která změní čítač a potvrdí
4/20/2015
70
1

Rozvržení zátěže za účelem optimalizace
dynamické části systému

Kde dává smysl rozkládat zátěž?

Problémy s rozkládáním zátěže
2
3
4
5
6
7
 Interdependence of local loads – užírání ze stejného koláče
 Data affinity – přenos dat může zásadně zpomalit výpočet
 Context transfer – rozložení výpočtu = kontext navíc
 Decision overhead – náklady na rozkládání < zisk
4/20/2015
71
1

Rozdíly?

Problémy s implementací
2
3
4
5
6
7
 Kdy autentikovat, kdy autorizovat
 Na jaké granularitě objektů řešit autorizaci
 Jak delegovat autoritu mezi procesy
4/20/2015
72
1
2
3
4

Rozšíření/úprava flat ACID modelu

Rozšíření != vylepšení – vždy „trade-off“

Použití silně závisí na druhu aplikace
5
6
7
 Vícekrokové objednávky
 Dávkové vkládání
 Modelování součástek v CAD systémech
4/20/2015
74
1
2
3
4
5
6

Chráněné akce – ACID transakce, výsledky
jsou vidět až po úspěšném skončení akce

Nechráněné akce – jediné co zaručují je
konzistence, většinou se obalují transakcemi

Skutečné reálné akce – akce s reálným
efektem, není možné provést UNDO, proto
se jejich provedení přesouvá až těsně před
potvrzení transakce
4/20/2015
7
75
1
2
3
4
5
6
7

Chráněné akce – stavební bloky pro spolehlivé
distribuované aplikace

Nechráněné akce – musí být přímo kontrolované
aplikací nebo obalené chráněnou akcí. Pokud to
nelze zajistit, nesmí být na jejich výstupu nic
závislé

Skutečné reálné akce – vyžadují speciální
zacházení – systém je musí rozeznat a musí
zajistit, že jsou spuštěny až ve chvíli, kdy
všechny ostatní chráněné akce úspěšně potvrdily
4/20/2015
76
1
2
3
4
5
6
7
Vhodný pro krátké jednoduché operace, její účinky jsou patrné až po
potvrzení/zrušení, tj. ani zprávy o chybách nejsou odeslány před ukončením
 Stavový diagram je jednoduchý (až moc…)

NULL
Begin work
aktivní
Commit
work
Terminate
Rollback
work
Terminate
potvrzená

zrušená
Na první pohled je zřejmé, že chybí …
4/20/2015
77
1
2
3
4
5
6
7

Přístup „vše nebo nic“ má též chránit systém proti (skrytým) chybám,
kterých se programátor dopouští (opak defenzivního programování)

Výhodou modelu je relativně snadná implementace, nevýhodou modelu
je jeho přílišná jednoduchost – viz příklady:
BookFlight(Prague, Toronto)
Update(Price)
RentCar(Toronto,Niagara)
If Price + CarRent < Limit
Update(Price) and Commit
Else
Undo RentCar(Toronto,Niagara)
BuyBusTicket(Toronto, Niagara)
Commit
Nechceme dělat undo ručně,
rollback ale vezme s sebou vše
4/20/2015
Account A;
For i=1 to 100.000
{
A.Id = I;
A.Date = Now;
A.Debit = 0;
A.StoreInDB();
}
Abort po i=97.998 znamená ztrátu
veškeré práce, ač jsou nové účty OK
78
1

Příliš velký rozsah – VŠE nebo NIC

Neuvažuje vůbec vnitřní strukturu

Netoleruje dílčí neúspěchy

Transakce nespolupracují, nic nesdílí

Neřeší přirozený problém vnořování
4/20/2015
2
3
4
5
6
7
79
1

2
3
4
5
6
7
Pozorování – řízení výpočtů v distribuovaném
víceuživatelském prostředí vyžaduje
 Uchování efektů operací (možnost vrátit se zpět)
 Monitorování všech závislostí (kde se stala chyba)

Model „spheres of control“ (SoC)
 První pokus o formalizaci problematiky transakcí (Bjork,
Davies 1972 - 1973)
 Teorie, která popisuje a pojmenovává možné problémy
(zajištění hlavně zotavení systému)

Předběhl svou dobu, jednoduchost flat modelu byla
zkrátka rozhodující… nicméně, SoC stále inspiruje
4/20/2015
80
1
2
3
4

Přístup k prostředkům vždy v rámci SoC

SoC drží historii všech operací, dokud je třeba

SoC uchovává i všechny závislosti mezi operacemi – tj. co vše
zasáhne případné undo
5
6
7
 Strukturální závislosti
▪ SoC implementováno jako hierarchie abstraktních datových typů
▪ Výsledky vrácené přes rozhraní ADT = potvrzená lokálně korektní data
 Dynamické závislosti kvůli konzistenci mezi více ADT
▪ Info pro potvrzení dat (např. převod mezi účty), sdílení/externalizace dat
▪ Potvrzení dat může být mimo proces, který je vytvořil

Systém musí uchovávat v podstatě kompletní historii všech
operací, aplikace se musí postarat o zbytek
4/20/2015
81
1
2
3
4
5
6
7
Globální proměnná
Strukturální SoC
Dynamická SoC
Co všechno musí být uchováno v logu?
4/20/2015
82
1
2
3
4
5
6

Nikdy nebylo pořádně formalizováno

Závislosti v podstatě jakékoliv (vznikají i zpětně
při opravě chyb v systému) – velká složitost

V původním podobě velmi těžké na
implementaci, bylo popsáno CO udělat,
ale ne JAK toho dosáhnout

Důsledek – v praxi se uchytily jednoduché
modely vycházející z (rozšíření) flat modelu
4/20/2015
7
83
1

2
3
4
5
6
7
Notace z Graye
 Grafická notace
 Pravidla

ACTA (Chrysanthis, Ramamrithan 199x)





4/20/2015
Historie objektů
Transakční závislosti
Konfliktní relace mezi operacemi
Delegace objektů mezi transakcemi
Jaká data jsou vidět zvenku, kontrola kolizí
84
1

2
3
4
5
6
7
Složitější modely vychází ze základních ACID bloků
Abort
Begin Commit
Rozhraní pro vstupní signály,
které způsobují změnu stavu
Identifikátor akce
Aborted
4/20/2015
Committed
Identifikátor stavu po
provedení akce
85
1
2
3

Formální popis transakčních modelů (předchůdce ACTA)

Levá strana <rule identifier>:<preconditions>
Pravá strana <rule modifier list>, <signal list>, <state transition>
kde rule modifier list = +(<rule identifier | signal>) nebo delete(X)

4
5
6

Příklad – při spuštění transakce T se přidá pravidlo „Při abortu systému
zaslat abort signál T“ a pak změnit stav na aktivní
SB(T):
+(SA(system) | SA(T)), , Begin work

Tabulková notace (pro přehlednost, použito jen v této ppt)
Rule Id
SB(T)
4/20/2015
Prec.
Rule modifiers
+(SA(system) | SA(T))
Signals
7
State tran.
Begin work
86
1
Rule Id
Prec.
Rule modifiers
Signals
2
3
4
5
+(SA(system) | SA(T))
Begin work
SA(T)
delete(SC(T)), delete(SB(T))
Rollback work
SC(T)
delete(SA(T)), delete(SB(T))
Commit work
7
State tran.
SB(T)
4/20/2015
6
87
1
Anglický název
4/20/2015
Pokus o překlad
2
4
5
6
7
Zkratka
Flat model
FM
Spheres of control
SoC
Transaction with savepoints
Transakce se savepointy
SP
Chained transactions
Zřetězené transakce
ZT
Nested transactions
Hnízděné transakce
HT
Distributed transactions
Distribuované transakce
DT
Multi-level transactions
Víceúrovňové transakce
VT
Open nested transactions
HT bez omezení
ONT
Long-lived transactions
Dlouho trvající transakce
DTT
Exotics
Exotické modely
EM
3
88
1
2
3
4
5
6
7

Motivace – rollback NEPROVÁDĚT až na začátek

Zavádějí se místa, tzv. savepointy
 První SP většinou po startu transakce
 Flexibilní rollback – o kolik kroků zpět?

Dopředný rollback
 Rollback k rollbacknutým stavům
 Rollbacky se pak stávají součástí historie

Neřeší problém s tvrdým výpadkem systému
4/20/2015
89
1


2
3
4
5
6
7
Nechť R je SP ke kterému chceme provést rollback
Delete pravidla jsou vynechána (jsou stejné jako u flat modelu)
Rule Id
Prec.
SB(S1)
Rule modifiers
Signals
State tran.
+(SA(system) | SA(S1))
Begin work
delete(SC(S1)), delete(SB(S1))
Rollback work
SC(S1)
delete(SA(S1)), delete(SB(S1))
Commit work
SS(S1)
+(SA(S1) | SA(S2))
SA(S1)
R<S1
SB(S2)
…
SB(Sn)
SA(Sn)
Begin work
…
SA(Sn-1)
Rollback work
SC(Sn)
…
SC(Sn-1)
Commit work
SS(Sn)
+(SA(Sn) | SA(Sn + 1))
SB(Sn+1)
4/20/2015
R<Sn
90
1
2
3
4
5
6
7
Spuštění transakce
a vytvoření prvního SP1
Postupně se vytváří SP2 a SP3
4/20/2015
91
1

Systémový abort = abort všech SP

Perzistentní SP = Phoenix transakce

Problém po restartu u perzistentních SP
2
3
4
5
6
7
 Stav DB je nastaven na stav uložený v SP
 Kód provádějící transakci ale nemusí mít stejný stav

SP1 jediný nekonfliktní
4/20/2015
92
1
2
3
4
5
6
7
Programátor se po části výpočtu vzdá možnosti
rollbacku nad touto částí, tj. potvrdí část transakce
 Nechce ale ztratit kontext, kurzory, atp.
 Tj. je potřeba zavést atomickou operaci Chain work
= Commit + Begin
 Transakce může uvolnit zdroje (např. zámky)

Rule Id
Prec.
Rule modifiers
Signals
State tran.
SB(Cn)
+(SA(system) | SA(Cn))
Begin work
SA(Cn)
delete(SC(Cn)), delete(SB(Cn))
Rollback work
SC(Cn)
delete(SA(Cn)), delete(SB(Cn))
4/20/2015
SB(Cn+1)
Commit work
93
1
2
3
4
5
6
7
Spuštěna C1, start C2 je
podmíněn potvrzením C1
C1 potvrdí což vyvolá
start C2 která je nyní
strukturálně závislá na
systémové transakci
4/20/2015
94
1

2
3
4
5
6
7
Workflow
 Oba modely umožňují zachování pomocných struktur
(např. kurzory)

Commit vs. SP
 U SP modelu lze provést rollback ke kterémukoliv
vytvořenému SP (flexibilita)
 Commit naopak umožní uvolnit zdroje (např. zámky)

Restart
 ZT model – odolný vůči systémovému abortu
 Problém s rekonstrukcí stavu u SP i ZT
4/20/2015
95
1
2
3
4
5
6
7
K nedokončené transakci se vytvoří po restartu ‘, která dokončí
práci za a pak pokračuje na . Kde ale vzít vstup pro ‘?
4/20/2015
96
1

Zobecnění SP modelu

Počítá s hierarchicky strukturovanými úlohami

Definice hnízděných transakcí (HT)
2
3
4
5
6
7
 HT je nevyvážený strom transakcí, podstromem jsou buď jiné




4/20/2015
HT transakce nebo flat transakce
V listech jsou pouze flat transakce
Kořen stromu se nazývá top-level transakce, ostatní uzly se
nazývají podtransakce, rodič a potomek definované klasicky
Potomek potvrdí až poté, co potvrdí kořenová transakce
Rollback transakce vede k rollbacku všech jejich potomků
(podtransakce mají pouze ACI vlastnosti a ne D)
97
1
2
3
4
5
6
7

Commit pravidlo – po potvrzení podtransakce jsou výsledky
dostupné jen v rodičovské transakci, podtransakce skutečně
potvrdí až s potvrzením kořenové transakce

Rollback pravidlo – pokud je podtransakce zrušena, bere sebou
všechny své potomky (i když už lokálně potvrdili), když je zrušena
kořenová transakce …

Změny provedené podtransakcí jsou po lokálním potvrzení
viditelné jen rodičovské transakci, objekty držené rodičovskou
transakcí jsou přístupné potomkům, potomci jsou izolovaní v
případě souběžného spuštění

Rodič rozhoduje o řešení zrušení potomka (restartovat, zvolit
alternativní výpočet, abortovat)
4/20/2015
98
1
2
3
4
5

Atomicita – podtransakce jsou atomické jen z
rodičovské perspektivy

Konzistence – podtransakce jsou konzistentní
pouze vzhledem k lokální fci kterou
implementují

Izolace – stejně silná jako u flat modelu

Trvanlivost – neplatí kvůli Commit pravidlu
4/20/2015
6
7
99
1
System
System
2
3
4
5
6
7
System
Zde se potvrzení nepropaguje, ale je
podmíněné ukončením podtransakcí
4/20/2015
100
1


2
3
4
5
6
7
Uvažujme podtransakci Tkn s rodičem Tk
Chování je pak popsáno pravidly
Rule Id
Prec.
Rule modifiers
Signals
State tran.
SB(Tkn)
+(SA(Tk) | SA(Tkn))
Begin work
SA(Tkn)
delete(SC(Tkn)), delete(SB(Tkn))
Rollback work
delete(SA(Tkn)), delete(SB(Tkn))
Commit work
SC(Tkn)
C(Tk)
Jednoduchost modelu je způsobena jinými
restrikcemi kladenými na podtransakce
 Částečné vs. finální potvrzení

4/20/2015
101
1
2
3
4
5
6
7

Vytvoření SP pro každý uzel hierarchie, možnost
vracet se k hotovým SP

Problém s paralelním spuštěním podtransakcí –
ty nelze emulovat – SP se řadí lineárně za sebou,
rollback „jen přes některé“ není možný

Problém se zámky – u HT rozhoduje o přidělení
zámků rodič, ty se vrací po potvrzení
podtransakce, u SP patří všechno všem
4/20/2015
102
1
2
3
4
5
6
7

Typicky běží jako flat transakce, která musí
navštívit více uzlů v síti – „jde“ si pro data formou
spuštění podtransakce na jiném uzlu

HT vs. DT transakce
 HT struktura je určena fční dekompozicí aplikace
 DT struktura je dána distribucí dat v síti

Podtransakce nejsou potomci, ale spíše kopie
rodiče na menších datech
4/20/2015
103
1
2
3
4
5
6
7
System
Uzel 1
Uzel 2
4/20/2015
Uzel 3
104
1

2
3
4
5
6
7
Zobecnění HT transakcí
 povolují pre-commit (uvolní zámky, zpřístupní výsledky)
 zavádí kompenzující transakce (pro případ abortu)

Abort rodičovské transakce způsobuje vyvolání kompenzující
transakce u těch potomků, kteří již potvrdili

Kompenzující transakce musí vždy potvrdit (zrušení KT by
znamenalo, že se nepovedlo celkové zrušení)
4/20/2015
105
1

2
3
4
5
6
7
„Anarchistická“ verze víceúrovňových transakcí
 Potomci mohou být potvrzeni/zrušeni nezávisle na
rodičích
 Rodič-potomek nemusí být dány sémantikou
 Jedná se o nechráněné akce

Slouží spíš jako start více top level trans.
 Nepoužívají sféru vlivu na celek
 Použití v klient-server prostředí
4/20/2015
106
1

2
3
4
5
6
7
Nejedná se přímo o model, ale spíše o koncept
 Transakce trvají velmi dlouho
 Rychlá rekonstrukce kontextu není možná

Speciální případ - transakce s otevřeným koncem
 Mohou být pouze zrušeny (není definováno potvrzení)
 Nekonečné nebo stále běžící výpočty
 Běh operačního systému, senzory, traffic monitoring, …
4/20/2015
107
1

2
3
4
5
6
7
Ale zpátky k problému s účty a úroky …
Account A;
For i=1 to 100.000
{
A.Id = I;
A.Date = Now;
A.Debit = 0;
A.StoreInDB();
}

Abort po i=97.998 znamená ztrátu veškeré práce, ač
jsou nové účty OK
4/20/2015
108
1

3
4
5
6
7
Jak se s ním vypořádávají již uvedené modely?





2
Flat (ACID) – ztráta veškeré práce
HT a SP jsou také ACID - opět vše nebo nic
VT – sice povoleno potvrzení, ale zase ACID – kompenzace
ZT – neztratí se práce, ALE problém s rekonstrukcí výpočtu, změny se
navíc projevují postupně
Požadavky na dlouhotrvající transakce
 Výpočty strukturované z více sekvenčně řazených operací
 Automatické udržování informací o kontextu výpočtu

Problém – program může pro stejný vstup dát jiný výstup, tj.
závisí i na kontextu, který je třeba získat
4/20/2015
109
1
2
3
4

Řešením jsou různé formy logů, problém je neexistující podpora v
běžných programovacích jazycích – důsledek – musí se řešit zvlášť

Jak tedy vyřešit problém s kontextem?

6
7
Kontext jako „skrytý“ vstup!
 Striktně vymezit kontext výpočtu
 Průběžně kontext ukládat
Vstup
5
?
Transakce
Výstup
Typy kontextu
 Žádný kontext – triviální, není co řešit (context-free programy)
 Lokální kontext – kontext se váže pouze na volající program (kurzory, …)
 Globální kontext – všechny globální proměnné, obsah celé DB, …
4/20/2015
110
1

2
3
4
5
6
7
Pokusy o řešení (neřeší ale kompletně ACID ...)
 Mini-Batch – zpracování po dávkách s vlastním ukládáním
kontextu
 Ságy – systémový přístup, podporují i rollback

Stále ale zůstává problém s viditelností výsledku

Kdo může být vlastníkem kontextu
 Transakce, program, koncové zařízení, uživatel, …

Zotavitelnost kontextu
 Ukazatel na konec souboru vs. čítač v programu
4/20/2015
111
1
2
3
4
5
6

Vhodné pro sadu sekvenčně řazených operací,
které lze rozdělit do dávek

Kontext výpočtu se průběžně ukládá do DB
7
 Použije se nová tabulka pro uložení kontextu
 Kontext = číslo poslední potvrzené operace

Neatomický - garantuje pouze provedení všeho

Izolovanost platí pouze pro prováděnou dávku
4/20/2015
112
1
2
3
4
5
6

Snaha o systémové řešení

Opět řetězce transakcí, ale obohacené o princip
kompenzačních transakcí

Ke každé transakci Si existuje kompenzační
transakce CSi (může i např. připočítat penále)

Možné výstupy
7
 Comit vede na posloupnost S1, .., Sn
 Abort vede na posloupnost S1, .., Sj, CSj-1, .., CS1
4/20/2015
113
1

2
3
4
5
6
7
Jak by vypadala základní pravidla pro ságy?
Rule Id
Prec.
SB(S1)
???
4/20/2015
Rule modifiers
Signals
+(SA(system) | SA(S1)), delete(SB(S1))
???
???
State tran.
Begin work
???
???
114
1
2
3
4
5
6
7

Exotická (z hlediska výskytu) je v podstatě většina
doposud uvedených modelů

Tyto modely se alespoň snažily zachovat ACID, daly se
popisovat jednoduše pravidly

Exotikou jsou myšleny takové modely, na které
principy ACID pohledu nestačí




4/20/2015
Kooperující transakce
Split transakce
Joint transakce
RCA
115
1
2
3
4
5
6
7

Vychází z potřeb CAD systémů, kde na jedné součástce dělá
tým lidí

Některé charakteristiky nehotové součástky je potřeba sdílet
s ostatními členy týmu
Zapůjčení objektu,
ten je jen pro čtení
Navrácení objektu
na vyžádání
4/20/2015
116
1

3
4
5
6
7
Rozdělení původní transakce Ta na dvě Ta a Tb






2
Podělí se o dosud provedené operace
Starají se pak o potvrzení/zrušení
Pro nekonfliktní operace povoleno sdílení dat
Sériový nebo nezávislý split
Možno štěpit dále – strom transakcí
Příklady použití
 Externalizace výsledků splitem – musí se hlídat abort
 Sdílení zamknutých dat mezi transakcemi
4/20/2015
117
1

2
3
4
5
6
7
Konec transakce může být i splynutí s jinou
 Odevzdá pak všechny zámky, objekty, logy
 Externalizace efektů až s potvrzením spojené transakce

Zajímavý model vzniká kombinací Split a Joint
transakcí

Výpočet se rozdělí na část ACID a na část kdy platí
„volnější“ pravidla transakčního zpracování
4/20/2015
118
1
2
3
4
5
6

Snaha o aplikaci zotavitelnosti pro komunikační
systémy

Je potřeba monitorovat abort-závislosti

Skupina závislých transakcí tvoří transakci vyššího
řádu

Na takové transakci je pak umožněn částečný
rollback
4/20/2015
7
119
1

3
4
5
6
7
Rozšíření flat ACID modelu pro konkrétní úlohy





2
Snaha o zachování korektně provedené práce
Podpora flexibilnějšího sdílené prostředků
Externalizace hotové práce
Ale stále jde o systémové zachování izolovanosti…
Některé modely jsou již podporované v běžných DB serverech
 MS SQL server 2008 a Oracle podporují Savepointy

Pravidla a grafické znázornění modelů
 Jaká jsou pravidla pro distribuované transakce?

Dále se budeme zabývat obecnými pravidly systémů, ve kterých
transakce běží – TP monitory
4/20/2015
120
1

2
3
4
5
6
7
Požadavky reálných aplikací
 Rychlá doba odezvy, propustnost
 Práce nad sdílenými daty
 Konkurentní výpočty, paralelismus

Problémy
 Konkurentní výpočet může vést k porušení invariantů systému
 Jak poznat, co vše je ovlivněno konkurentními transakcemi?

Invariant
 Predikát odolný (platný) vzhledem k prováděné transformaci
 Všechny invarianty splněny = systém je v konzistentním stavu
 Příklad – Array.Length() = Array.Add(0).Remove(o).Length()
4/20/2015
122
1

2
3
4
5
6
7
Konzistence dat v DB se dá popsat invarianty a je hlídána
 Samotným datovým modelem/schématem
 Omezeními (constraints) pomocí triggerů
 Vlastnostmi ACID u transakcí

Příklad s účty U1, U2, U3
 Nechť U1.zůstatek = U2.zůstatek = U3.zůstatek = 1000
 Celková suma v systému je 3000
 Typická transakce – převod peněz mezi účty
 Invariant – jakékoliv transfery peněz mezi účty nesmí změnit celkovou
sumu peněz v systému
4/20/2015
123
1

2
3
4
5
6
7
Základní operace v transakci obsahující příkazy SELECT a UPDATE

READ(X, @x) – načtení objektu X z DB do lokální proměnné @x
 WRITE(X, @x) – zapsání do objektu X v DB (pozor na cache!) z lokální proměnné @x
 COMMIT – potvrzení změn a ukončení transakce
 ABORT (ROLLBACK) – stornování změn a ukončení transakce

Transakci lze chápat jako DB program





Operace s DB (Read / Write) + další operace (aritmetické, pomocné, atp…)
Porušení izolace - R/W operace nad stejnými daty - na ty se budeme zaměřovat
Transakce - posloupnost R/W operací zakončená COMMIT nebo ABORT
Pro přehlednost můžeme v zápisu vynechávat lokální proměnné @zU, …
Např.
Úhrada(částka, zU, naU) = { Read(zU), Write(zU), Write(naU) , COMMIT}
 Operace transakce se také často zapisují pro přehlednost do sloupce
4/20/2015
124
1
2
3
4
5
6
7
Úhrada(@částka, @zÚčtu, @naÚčet)
SELECT @z1=zůstatek FROM Účet WHERE čÚčtu = @zÚčtu
// Read(zU)
SELECT @z2=zůstatek FROM Účet WHERE čÚčtu = @naÚčet
UPDATE Účet SET zůstatek = @z1 – @částka WHERE @čÚčtu = @zÚčtu
UPDATE Účet SET zůstatek = @z2 + @částka WHERE @čÚčtu = @naÚčet
// If (@z1 < částka) ZrušTransakci(„Nedostatek peněz na účtu!“)
// Read(naU)
// Write(zU)
// Write(naU)
Potvrdit transakci
Nebudeme pro
začátek uvažovat
// U1.zůstatek = U2 .zůstatek = U3 .zůstatek = 1000, suma = 3000
T1:Exec Úhrada(100, ‘U1’, ‘U2’);
// U1 .zůstatek = 900, U2 .zůstatek = 1100, U3 .zůstatek = 1000, suma = 3000
// U1 .zůstatek = 900, U2 .zůstatek = 1000, U3 .zůstatek = 1100, suma = 3000
// U1 .zůstatek = U2 .zůstatek = U3 .zůstatek = 1000, suma = 3000
4/20/2015
125
1
2
3
4
5
6
7

Uvažujme prostředí ve kterém může být současně spuštěno více
transakcí (zatím - každá končí příkazem COMMIT a bereme statické DB)

Sériové vykonávání
 Dokud není obsloužena aktuálně zpracovávaná transakce, ostatní čekají
 Nemusí se řešit konflikty u společných DB objektů - konzistence
 Během R/W operací je procesor nevytížen

Paralelní vykonávání
 všechny transakce jsou průběžně obsluhovány (tj. jedna čte data z DB, druhá
může provádět výpočty nad již dotaženými daty)
 Jedna velká „neodstřelí“ server - odezva
 Musí se řešit konflikty nad společnými DB objekty (Izolace)

Požadované chování SŘBD – paralelní vykonávání transakcí, kdy výsledný
stav DB je stejný jako při sériovém vykonávání
4/20/2015
126
1

2
3
4
5
6
7
Rozvrh je posloupnost operací které vykonávají průběžně běžící
transakce, operace jsou libovolně prokládány
 S = {T1.Read(X), T1.Write(Y), T2.Read(Y), T2.Read(X), T1.Read(Z), …}

Nelze naplánovat/vytvořit dopředu (rozvrhovač neví, které
transakce dorazí ke zpracování, dokonce ani nezná dopředu
jednotlivé kroky vykonávaných transakcí)

Tzn. rozvrh není vytvořen rozvrhovačem předem, rozvrh je jen
historie provedených operací

Rozvrhovač může jen garantovat vlastnosti rozvrhu pomocí
omezení, které klade na spouštěné transakce (např. pustí transakci
jakmile má potřebné zámky)
4/20/2015
127
1
2
3
4
5
6
7
Pokud by rozvrhovač pouštěl transakce ke slovu úplně náhodně,
tak by mohl vzniknout pro T4, T5, T6 např. následující rozvrh.
Nicméně, paralelní provedení zde nevede ke konzistentnímu stavu DB.
T4
T5
T6
Read(A, @a1)
Read(A, @a2)
@a 1= @a1 + 10
@a2 =@a2 + 5
Write(A, @a1)
Read(B, @b3)
@b3 = @b3 * 2
Write(A, @a2)
Read(C, @c2)
Write(B, @c2)
U libovolného sériového
rozvrhu pro T4, T5, T6
bude k A přičteno celkem
15. Po vykonání tohoto
rozvrhu bude hodnota
A větší pouze o 5. Problém
je v R/W konfliktech nad
společnými daty. Možné
konfliktní dvojice:
Write(C, @a1)
Write(B, @b3)
4/20/2015
R
W
R
ok
x
W
x
x
128
1
2
3
4

Nekontrolované paralelní vykonávání (náhodné, round robin)
může generovat libovolné rozvrhy = druhý extrém

Je potřeba definovat korektnost a konfliktní operace
5
6
7
 Korektnost, splnění invariantů  vztahujeme k sériovému rozvrhu (SR)
 Operace nad stejnými daty a alespoň jedna z operací je zápis

Nás budou zajímat pouze takové rozvrhy, které splňují určité
vlastnosti (+ jejich kombinace)






4/20/2015
Uspořádatelnost – stav DB je stejný, jako po provedení nějakého SR
Konfliktová uspořádatelnost – stejné konfliktní dvojice jako nějaký SR
Zotavitelnost – abort neovlivní data potvrzených transakcí
Vyloučení kaskádových abortů – abort s sebou nevezme víc transakcí
Striktnost – čtení a zápis pouze potvrzených dat
Pohledová uspořádatelnost – čtou se stejná data jako v nějakém SR
129
1
2
3
4
5
6
7

Rozvrh ekvivalentní (výsledkově, ne průběhem!)
nějakému sériovému rozvrhu, vždy korektní

Obecná uspořádatelnost– těžko detekovatelná

Proto hledáme slabší formu uspořádatelnosti
 Závislá pouze na operacích pracujících s DB
 DB operace jsou prozatím jen read a write

Následující příklad ukazuje, proč je složité
detekovat obecnou uspořádatelnost
4/20/2015
130
1

2
3
4
5
6
7
Vrátíme se opět k příkladu s úhradou, pro větší
názornost použijeme Read(x, @x) namísto Read(x)
Úhrada(@částka, @zÚčtu, @naÚčet)
SELECT @x=zůstatek FROM Účet WHERE čÚčtu = @zÚčtu
SELECT @y=zůstatek FROM Účet WHERE čÚčtu = @naÚčet
// If (z < částka) ZrušTransakci(„Nedostatek peněz na účtu!“)
UPDATE Účet SET zůstatek = @x – @částka WHERE @čÚčtu = @zÚčtu
UPDATE Účet SET zůstatek = @y + @částka WHERE @čÚčtu = @naÚčet
// READ(zU, @x)
// READ(naU, @y)
// WRITE(zU, @x)
// WRITE(naU, @y)
Potvrdit transakci
T1:Exec Úhrada(100, ‘U1’, ‘U2’); T2:Exec Úhrada(100, ‘U2’, ‘U1’);

Po provedení obou operací očekáváme, že systém bude
v původním stavu, tj. ve stavu před spuštěním operací
(T2 je v podstatě kompenzující transakce k T1)
4/20/2015
131
1

2
3
4
5
6
7
Sériové spuštění {T1, T2} a {T2, T1} – v systému stále 2000 Kč
T1
T2
Read(U1, @x)
U1
U2
1000
1000
T1
T2
U1
U2
Read(U2, @x)
1000
1000
Read(U2, @y)
Read(U1, @y)
@x = @x – 100
@x = @x – 100
@y = @y + 100
@y = @y + 100
Write(U1, @x)
900
1000
Write(U2, @x)
1000
900
Write(U2, @y)
900
1100
Write(U1, @y)
1100
900
4/20/2015
Read(U2, @x)
Read(U1, @x)
Read(U1, @y)
Read(U2, @y)
@x = @x – 100
@x = @x – 100
@y = @y + 100
@y = @y + 100
Write(U2, @x)
900
1000
Write(U1, @x)
1000
900
Write(U1, @y)
1000
1000
Write(U2, @y)
1000
1000
132
1

2
3
4
5
6
7
Prokládané spuštění T1 a T2
T1
T2
Read(U1, @x)
U1
U2
1000
1000
Read(U2, @y)
Rozvrh není uspořádatelný
@x = @x – 100
@y = @y + 100
Write(U1, @x)
900
1000
900
1100
Write(U2, @x)
900
900
Write(U1, @y)
1000
900
Důsledek – z banky zmizí 100Kč
Read(U2, @x)
Write(U2, @y)
Read(U1, @y)
@x = @x – 100
@y = @y + 100
4/20/2015
133
1

2
3
4
5
6
7
Jinak prokládané spuštění T1 a T2
T1
T2
Read(U1, @x)
U1
U2
1000
1000
Read(U2, @y)
Rozvrh není uspořádatelný
@x = @x – 100
@y = @y + 100
Důsledek – sice nezmizí peníze,
ale zmizí efekt T1 !!! (= lost update)
Read(U2, @x)
Read(U1, @y)
Write(U1, @x)
900
1000
Write(U2, @y)
900
1100
Write(U2, @x)
900
900
Write(U1, @y)
1100
900
@x = @x – 100
@y = @y + 100
4/20/2015
134
1

2
3
4
5
6
7
Stejně prokládané spuštění T1 a T2, ale teď T1 převádí 0 Kč
T1
T2
Read(U1, @x)
U1
U2
1000
1000
Tj. T1:Exec Úhrada(0, ‘U1’, ‘U2’);
Rozvrh je uspořádatelný!
Read(U2, @y)
@x = @x – 0
Důsledek – uspořádatelnost
závisí i na hodnotách v programu
@y = @y + 0
Read(U2, @x)
Read(U1, @y)
Write(U1, @x)
1000
1000
Write(U2, @y)
1000
1000
4/20/2015
Proto není možné jednoduše a
levně detekovat uspořádatelnost
@x = @x – 100
Dále se proto omezíme pouze na
operace s DB – Read a Write
@y = @y + 100
R
W
Write(U2, @x)
1000
900
R
ok
x
Write(U1, @y)
1100
900
W
x
x
135
1



2
3
4
5
6
7
Jako jediná nemá vliv na výsledek výpočtu (i konzistenci DB)
Pouze čtení společných dat, tj. na pořadí Ti a Tj nezáleží
Příklad
T1
T2
Předpoklad  A = 0
Read(A)
B = A + 10
Read(A)
C =A +5
Sériové vykonání
S(T1, T2)  A = 0, B = 10, C = 5
S(T2,T1)  A = 0, B = 10, C = 5
Write(C)
Paralelní vykonání
P  A = 0, B = 10, C = 5
Write(B)
COMMIT
COMMIT
4/20/2015
136
1

2
3
4
5
6
7
Neopakovatelné čtení (nonrepeatable read)
 Transakce T2 zapíše objekt A, který předtím přečetla zatím
nepotvrzená T1, příklad, který vede k nekonzistenci dat:
T1
T2
Read(A)
A = 10
Write(A)
C =A +5
A=A +5
Write(C)
Write(A)
Předpoklad  A = 0
S(T1, T2)  A = 10, B = 15, C = 15
S(T2,T1)  A = 15, B = 25, C = 15
P  A = 5, B = 15, C = 15
B = A + 10
Write(B)
COMMIT
COMMIT
4/20/2015
137
1

2
3
4
5
6
7
Čtení nepotvrzených dat (dirty read)
 T2 čte hodnotu A, kterou T1 zatím nepotvrdila, tj. mohou se číst
nekonzistentní data, viz příklad, který vede k nekonzistenci dat:
T1
T2
Read(A)
A = A - 1000
Předpoklad  A = 1000, B = 1000
Write(A)
Read(A)
Read(B)
A = A * 1.01, B = B * 1.01
Write(A)
Write(B)
COMMIT
S(T1, T2)  A = 0, B = 2020
S(T2,T1)  A = 10, B = 2010
P  A = 0, B = 2010
Read(B)
B = B + 1000
Write(B)
COMMIT
4/20/2015
138
1

2
3
4
5
6
7
Přepsání nepotvrzených dat
 T2 přepíše hodnotu B, kterou předtím zapsala stále
běžící T1, příklad, který vede k nekonzistenci dat:
T1
T2
A = B = 10
A = B = 20
Write(A)
Write(B)
Předpoklad  A = 0, B = 0
S(T1, T2)  A = 20, B = 20
S(T2,T1)  A = 10, B = 10
Write(B)
P  A = 10, B = 20
Write(A)
COMMIT
COMMIT
4/20/2015
139
1

2
3
4
5
6
7
Transakce je množina Ti s částečným uspořádáním <i kde
 Ti  {ri[x], wi[x] | x je objekt v DB}  {ai, ci}
 aiTi xor ciTi
 Pokud q{ai, ci} a qTi pak p Ti platí p <i q
 Pokud ri[x], wi[x]Ti pak ri[x] <i wi[x] nebo wi[x] <i ri[x]

x může být atribut, ntice, celý blok, tabulka, …

r,w,a,c = Read, Write, Abort, Commit, relace <i představuje „předcházení“

Transakci je možné zakreslit i jako orientovaný acyklický graf

Dá se zobecnit na multimnožiny (opětovné čtení a zápis hodnot)
4/20/2015
140
1

2
3
4
5
6
7
Nechť T7 = {r7 [x], w7 [x], c7} pak
 <7 = {(r 7 [x], w 7 [x]), (w7 [x], c7), (r7 [x], c7)}
 Graficky (tranzitivita se nezakresluje do grafu)
r7 [x]
w7 [x]
c7

Proč je relace <i pouze částečné uspořádání?

Nechť T8 = {r8 [x], r8 [y], w8 [x], c8}
 Chceme načíst x a y a součet uložit do x
 Není důležité, v jakém pořadí x a y načteme, proto v <8 není (r[x], r[y])
 <8 = {(r 8[x], w 8[x]), (r 8[y], w 8[x]), (w 8[x], c 8), (r 8[x], c 8) , (r 8[y], c 8)}
 Graficky
r 8[x]
r 8[y]
4/20/2015
w 8[x]
c8
141
1
2
3
4
5
6

Nechť T = {T1, .., Tn} je množina transakcí

Úplná historie nad T je definována jako množina H s částečným
uspořádáním <H kde
7
 H = ni=1 Ti
 <H  ni=1 <i
 Pro libovolnou konfliktní dvojici p, q  H platí p <H q nebo q <H p

<H může být i totální uspořádání, pak se historie zapisuje jako
řetězec bez šipek. Např. H = w1[x] r2[x] w2[y] c2 c1

Historie může obsahovat potvrzené, zrušené a aktivní transakce

Commit projekce historie, C(H) obsahuje pouze operace
potvrzených transakcí
4/20/2015
142
1
2
3
4
5
6
7

Pokud je alespoň jedna ze dvou prokládaných
operací nad společnými daty write

Dvě nekonfliktní operace lze prohodit

Prohozením konfliktní dvojice se změní výsledek
r1[x] w1[x]

r2[z]
r1[z] w2[y]
r1[y] w2[z]
Tvoří potvrzení konfliktní dvojice? Pokud
transakce neabortují, tak nás pořadí nemusí
zajímat – viz. dále zotavitelné rozvrhy…
4/20/2015
143
1


2
3
4
5
6
7
Nechť T7 = {r7 [x], w7 [x], c7} a T8 = {r8 [x], r8 [y], w8 [x], c8}
Jaké mohou vzniknout historie? Graf se rozšíří o červené šipky…
r7 [x]
w7 [x]
Možné
konfliktní
dvojice
Jak by vypadaly
příslušné relace <Hi ?
r 8[x]
r 8[x]
r 8[y]
4/20/2015
w7 [x]
c7
w 8[x]
c8
r7 [x]
r 8[x]
r 8[y]
r7 [x]
c8
r 8[x]
w7 [x]
c7
r7 [x]
w 8[x]
c8
w 8[x]
r 8[y]
r7 [x]
c7
r 8[y]
r 8[x]
r 8[y]
w7 [x]
c7
w 8[x]
c8
w7 [x]
c7
w 8[x]
c8
144
1
2
3
4
5
6
7

Slabší forma uspořádatelnosti, nicméně, lehce ověřitelná vlastnost

Dvě historie H a H’ nad stejnými transakcemi jsou konfliktově
ekvivalentní, když mají stejné konfliktní dvojice, tj. ve stejném
pořadí nad stejnými objekty

Konfliktová ekvivalence závisí pouze na konfliktních dvojicích

Rozvrh je konfliktově uspořádatelný, pokud je konfliktově
ekvivalentní k nějakému sériovému rozvrhu (v něm nejsou
konflikty)

Výstup konkurentního spuštění transakcí tedy závisí pouze na
uspořádání konfliktních operací
4/20/2015
145
1

2
3
4
5
6
7
Precedenční graf historie H nad množinou transakcí {T1, .., Tn} je orientovaný graf


Kde uzly jsou transakce z Commit projekce historie H
Hrana mezi uzlem Ti a Tj  operace z Ti předchází a je v konfliktu s nějakou operací z Tj

Konfliktová uspořádatelnost se dá detekovat pomocí precedenčního grafu – viz
následující tvrzení (the serializability theorem )

H je uspořádatelná právě tehdy, když precedenční graf neobsahuje cykly


V sériové historii tvoří hrany pořadí spuštění transakcí
Pokud je graf acyklický, můžeme jednoduše najít sériový rozvrh konfliktově ekvivalentní k H
T1
T2
RW
READ(X)
WRITE(X)
T2
T1
WRITE(X)
WW
COMMIT
COMMIT
4/20/2015
146
1

Nyní budeme uvažovat i případy, kdy T může abortovat

H = w1[x] r2[x] w2[y] c2 c1
2
3
4
5
6
7
 H je sice konfliktově uspořádatelná, ale...
 Co kdyby T1 abortovala? T2 potvrdila s hodnotami, které se ale abortem
musí změnit na původní – začíná nás zajímat pořadí potvrzení

Ti čte hodnotu x z Tj když





wj[x] < ri[x], aj nepředchází ri[x] v částečném uspořádání
Pokud existuje wk[x] takové že wj[x] < wk[x] < ri[x] pak ak< ri[x]
Tj. když už nějaká Tk přepíše hodnotu x, tak pak abortovala před ri[x]
Říkáme, že Ti čte z Tj, pokud existuje x takové, že Ti čte hodnotu x z Tj
Historie je zotavitelná (RC) tehdy, když
 Kdykoliv čte Ti hodnoty z Tj (i  j) a ciH, pak cj < ci
 Tj. H = w1[x] r2[x] w2[y] c1 c2
4/20/2015
147
1

2
3
4
5
6
7
H = w1[x] r2[x] w2[y] r3[y] w3[z] c1 c2 c3
 Konfliktově uspořádatelná a zotavitelná, ale…
 Pokud by T1 abortovala, vezme s sebou i T2 a T3
 Chceme po plánovači, aby této situaci předcházel

H předchází kaskádovému abortu (ACA)
tehdy, pokud kdykoliv čte Ti hodnotu x z Tj
(i  j) v H, pak cj < ri[x]
 Tj. H = w1[x] c1 r2[x] w2[y] c2 r3[y] w3[z] c3
4/20/2015
148
1

2
3
4
5
6
7
H = w1[x] w2[x] c1 c2
 Splňuje vše, co bylo doposud definováno, ale ...
 Co kdyby (opět) T1 abortovala?
 Chceme rozvrh zajišťující jednoduchost rollbacku

H je striktní (ST) tehdy, pokud kdykoliv wj[x] <
oi[x] (i  j), buď aj < oi[x] nebo cj < oi[x],
kde oi[x]  {ri[x], wi[x]}
 Tj. H = w1[x] c1 w2[x] c2

Data změněná transakcí Tj jsou přístupná jiné
transakci Ti teprve tehdy, až Tj skončí
4/20/2015
149
1
2
3
4
5
6
7

Pokud plánovač produkuje „korektní“ historii H, pak
kterýkoliv prefix H’ z H by měl být také „korektní“
uvažujemeli potvrzené transakce

V případě že po prefixu H’ dojde k pádu systému, musí
databázový systém promítnout jen C(H’), která by
měla být korektní

Vlastnost je prefix-commit-closed tehdy, pokud
kdykoliv platí pro historii H, platí také pro historii C(H’)
pro kterýkoliv prefix H’ z H
 (C)SR je prefix-commit-closed
 RC, ACA, a ST jsou prefix-commit-closed
4/20/2015
150
1

Nyní budeme uvažovat jiné kritérium pro ekvivalenci historií

Nevíme, jaký výpočet f(x) se odehrává mezi r[x] a w[x]
2
3
4
5
6
7

Víme, že je to funkce závislá na všech předchozích čteních
 Takže, pokud čtou dvě historie stejné hodnoty, pak by měly též zapsat to samé

Důsledek

Pokud každá transakce čte všechna svá data ze stejných zápisů v obou historiích, pak
všechny operace w[x] zapisují to samé v obou historiích
 Jestliže je pro každé x stejné poslední w[x] v obou historiích, pak je výsledná hodnota
všech dat stejná v obou historiích
r2[x] w2[y] r1[y] r3[y] w1[x] w2[x] w3[x] (pohledově usp. rozvrh)
r2[x] w2[y] w2[x] r1[y] w1[x] r3[y] w3[x] (sériový rozvrh)
4/20/2015
151
1
2
3
4
5
6
7

Poslední zápis hodnoty x v historii H je wi[x]  H takové, že
ai  H a pro každé wj[x]  H (j  i) buď wj[x] < wi[x] or aj  H

Historie H a H’ jsou pohledově ekvivalentní, když
 Vznikly pro stejnou množinu transakcí a stejné operace
 Pro libovolné Ti, Tj takové, že ai, aj  H (tj. taky ai, ai  H’) a pro
každé x, pokud Ti čte x z Tj v H pak Ti čte x z Tj v H’
 Pro každé x platí, pokud wi[x] je poslední zápis x v H pak je také
posledním zápisem x v H’

Nedefinované počáteční čtení (inicializace x) neřešíme

Používá se v algoritmech pro „multicopy“ data
4/20/2015
152
1



5
6
7
Historie H je (konfliktově) uspořádatelná, když je její Commit projekce C(H) (konfliktově)
ekvivalentní k nějaké sériové historii
H je pohledově uspořádatelná, když pro kterýkoliv prefix H’ z H, je C(H’) pohledově
ekvivalentní k nějaké sériové historii
Zdůrazněme “pro kterýkoliv prefix”, aby byla zaručena prefix-commit-closed vlastnost
Představme si historii H, která je neuspořádatelná, ale končí poslední transakcí, která přepíše
vše …
CSR je podmnožinou VSR



4
A teď pohledová uspořádatelnost (VSR)


3
Připomeňme konfliktovou uspořádatelnost (CSR)


2
Tj. pokud je historie CSR tak je také VSR
Opačně to ale obecně neplatí… Uvažujme H = w1[x] w2[x] w1[x]
Všechny praktické algoritmy pro kontrolu konkurence jsou conflict-based.

4/20/2015
Efektivní plánovač produkující přesně množinu všech pohledově uspořádatelných historií
může existovat pouze tehdy, když P=NP
153
1

2
3
4
5
6
7
Uvažujme jinou množinu DB operací
 Vložení/smazání/čtení unikátního záznamu

Je potřeba redefinovat pojem konflikt(ní dvojice)
 Matice kompatibility pro všechny operace
 Definice precedenčního grafu je – stejná
 Serialization theorem – stejný

Používáme pouze read/write operace kvůli
jednoduchosti a praktičnosti v db systémech

Nicméně, teorie uspořádatelnosti se dá použít na
různé množiny operací
4/20/2015
154
1












H1:
H2:
H3: w1[x] w1[y] r2[u] w2[x] r2[y] w2[y] c2 w1[z] c1
H4:
H5:
H6: w1[x] w1[y] r2[u] w2[x] r2[y] w2[y] w1[z] c1 c2
H7:
H8:
H9: w1[x] w1[y] r2[u] w2[x] w1[z] c1 r2[y] w2[y] c2
H10:
H11:
H12: w1[x] w1[y] r2[u] w1[z] c1 w2[x] r2[y] w2[y] c2
2
3
4
5
6
7
VSR
H1
H2
H3 CSR
H4
H5
H6
RC
H7
H8
H9
ACA
H10 H11 H12
ST
Serial
VSR – pohledově a CSR – konfliktově uspořádatelná
RC – zotavitelná, ACA – kaskádové aborty, ST striktní
4/20/2015
155
1

2
3
4
5
6
7
Konkurentním vykonáváním transakcí vzniká rozvrh, jehož
vlastnosti chceme mít pod kontrolou
 Chceme prokládané rozvrhy (paralelizace, odezva)
 Chceme korektní rozvrhy (výsledkově stejný jako SR)

Vlastnosti musí být (jednoduše) detekovatelné
 Zaměření jen na r, w operace s DB, neřešíme aborty
▪ Konfliktová uspořádatelnost – jednoduše z precedenčního grafu
▪ Pohledová uspořádatelnost – řešitelná, ale NP úplný problém 
 Zaměření na všechny operace s DB – r, w, a, c
▪ Problémy se zotavitelností, kaskádové aborty, jednoduchost rollbacku

V praxi se používají kombinace jednoduchých vlastností

Nyní se zaměříme na způsob, jak jich dosáhnout (protokoly)
4/20/2015
156
1

2
3
4
5
6
7
Rozvrh je posloupnost operací které vykonávají průběžně běžící
transakce, operace jsou libovolně prokládány
 S = {T1.Read(X), T1.Write(Y), T2.Read(Y), T2.Read(X), T1.Read(Z), …}

Nelze naplánovat/vytvořit dopředu (rozvrhovač neví, které
transakce dorazí ke zpracování, dokonce ani nezná dopředu
jednotlivé kroky vykonávaných transakcí)

Tzn. rozvrh není vytvořen rozvrhovačem předem, rozvrh je jen
historie provedených operací

Rozvrhovač může jen garantovat vlastnosti rozvrhu pomocí
omezení, které klade na spouštěné transakce (např. pustí transakci
jakmile má potřebné zámky)
4/20/2015
158
1
2
3
4
5
6

O plánování běhu transakcí se stará rozvrhovač transakcí (scheduler),
který se snaží dosáhnout izolace transakcí pomocí vhodného protokolu

Jaké má plánovač možnosti plánování?
7
 Obecně – provést operaci ihned, pozdržet nebo odmítnout
 Agresivní plánovač – snaha vykonat operace rychle – okamžitě nebo vůbec
 Konzervativní plánovač – předcházení odmítání – zpožďování

Existuje více strategií, jak zajistit izolaci transakcí






Zamykání objektů
Časová razítka
Pomocí precedenčního grafu
Certifikace
Integrované plánovače
Multiversion data
TP Monitor
r2[y], r1[x], w2[x], r1[y], w1[x], c1, …
Plánovač
r2[y], r1[x], r1[y], w1[x], c1, w2[x], …
Databáze
4/20/2015
159
1
2
3

Konfliktům se zamezuje pomocí zámků, tj. zámky brání přechodu do
nekonzistentního stavu

Zamykání musí být atomická a hlavně levná operace (jinak bottleneck)

Jakou zvolit pro zamykání granularitu (tabulka, stránka, záznam, atd.)?
4
5
6
7

Hrubá – delší pomlky při zpracování (transakce déle čekají na zamčená data), extrémní
případ je sériové zpracování
 Jemná – větší režie na zamykání a větší šance na uváznutí (než tisíce zámků, tak raději
blokovat celou tabulku)
 Různá – řeší problém neoptimální jednotné granularity pro všechny

Nové operace v transakci

rl[x] – read lock, ru[x] – read unlock
 wl[x] – write lock, wu[x] – write unlock
4/20/2015
rl
wl
rl
ok
x
wl
x
x
160
1

2
3
4
5
6
7
Komponenta zajišťující následující operace (dle typu značíme jako rl[x], wl[x], …)

Zamknout(Id transakce, Id objektu, typ zámku)
 Odemkount(Id transakce, Id objektu)
 Odemkount(Id transakce)

Používá paměťovou tabulku zámků

Pro objekt udržuje dva seznamy - držené a zatím nepřidělené zámky
 Implementováno jako hash tabulka

Příklad pro rozvrh S = {T1.Read(X), T1.Write(Y), T2.Read(Y), T3.Read(X), T1.Read(Z), …}
Držené zámky
4/20/2015
h(X)
[T1, read], [T3, read]
h(Y)
[T1, write]
h(Z)
[T1, read]
Požadavky na zámek
[T2, read]
161
1
2
3
4
5

Manažer zámků může pracovat s libovolným typem objektů, k
práci mu stačí pouze identifikátory objektů

Jaký typ objektu se používá závisí na manažeru dat, např. v
architektuře SQL Databáze lze požadovat zámky na
6
7
 Stránky - page-oriented file layer
 Záznamy - record-oriented layer
 Tabulky, sloupce - query executor/optimizer

Zvolená granularita závisí na
 Požadované úrovni souběžného zpracovávání
 Režii spojené se zamykáním
 Složitosti implementace

Zatím budeme uvažovat jednotnou granularitu zamykání
4/20/2015
162
1

4
5
6
7
Před r[x] je vždy rl[x] a před w[x] je vždy wl[x]
Příklady
r[x] w[y] c
rl[x] r[x] rl[y] w[y] c
rl[x] r[x] wl[y] w[y] c
rl[x] r[x] wl[y] w[y] ru[x] wu[y] c
není dobře formovaná
není dobře formovaná
je dobře formovaná
je dobře formovaná
Dvoufázová transakce


Dvě fáze – 1. pouze zamykání a 2. pouze odemykání
Příklady
rl[x] r[x] ru[x] wl[y] w[y] wu[y] c
rl[x] r[x] wl[y] ru[x] w[y] wu[y] c
r[x] w[y] c

3
Dobře formovaná transakce



2
není dvoufázová
je dvoufázová
je dvoufázová
Legální historie


Transakce dostane na objekt požadovaný zámek jen tehdy, je-li příslušný zámek k dispozici
Příklady pro T1 = {rl1 [x] r1 [x] ru1 [x] c1} a T2 = {wl2[x] w2 [x] wu2 [x] c2}
rl1 [x] r1 [x] wl2[x] w2 [x] wu2 [x] ru1[x]
wl2 [x] w2 [x] wu2 [x] rl1 [x] r1 [x] ru1 [x]
rl2 [x] r2 [x] rl1 [x] r1 [x] ru1 [x] ru2 [x]
4/20/2015
není legální
je legální
je legální
rl
wl
rl
ok
x
wl
x
x
163
1
2
3
4
5
6
7

Teorém 1 – Pokud jsou všechny transakce dobře formované a
dvoufázové, pak je jakákoliv legální historie vzniklá z jejich
konkurentního spuštění uspořádatelná.

Důsledek T1 - dobře formované a dvoufázové transakce garantují
korektní konkurentní běh těchto transakcí

Teorém 2 – Pokud není nějaká transakce dobře formovaná nebo není
dvoufázová, je možné vytvořit další transakci (již dobře formovanou
a dvoufázovou) takovou, že výsledný pár transakcí může vést k
historii s cyklem v příslušném precedenčním grafu.

Důsledek T2 - pokud není nějaká transakce dobře formovaná nebo
není dvoufázová, tak to MŮŽE (ale nemusí) vést k problémům
4/20/2015
164
1

2
3
4
5
6
7
Nechť pi[x] < qj[x] a alespoň jedna z nich je write
A) T jsou dobře formované
B) T jsou dvoufázové
C) Historie H je legální
pli[x]
pi[x]
pui[x]
oli[x]
kdyby qj[x] < pi[x]

Platí, že pui[x] < qlj[x]

Konflikt = cyklus v PG – jen pokud transakce pracují nad společnými daty
qlj[x]
qj[x]
quj[x]
 Z A & B & C plyne, že Tj musí vždy čekat, až Ti uvolní zámek, který má pro x
 Kvůli dvoufázovosti nemůže nad jediným x vzniknout cyklus mezi Ti a Tj
 Cyklus pro různé proměnné x, y také není možný, konfliktu předejde uváznutí
 Dokazuje se často sporem – cyklus v PG  pui[x] < pui[x]  spor
wl1[x] wl2[y] wl1[y] wl2[x]

Důsledek – pokud A & B & C  H je konfliktově uspořádatelná
4/20/2015
165
1

2
4
5
6
7
T1 není dobře formovaná, T2 je ok  H legální & neizolovaná
 Pokud není T dobře formovaná, tak nastává
▪ Buď operace p[x] na objektu x, která není chráněná pl[x]
▪ Nebo zápis w[x] do x, který je chráněn pouze rl[x]
T1
 Příklady historií H
▪ H1 = r1[x] wl2[x] w2[x] wu2[x] w1[x]
▪ H2 = rl2[x] r2[x] wl2[z] w2[z] rl1[x] w1[x] ru1[x] r2[x] ru2[x] wu2[z]

3
RW
T2
WW (WR u H2)
T1 není dvoufázová, T2 je ok  H legální & neizolovaná
 Pokud není T dvoufázová, tak nastává
▪ Zámek pl[x] na objektu x, poté co byl již jednou odemčen pu[x]
 Příklad historie H
▪ H3 = rl1[x] r1[x] ru1[x] wl2[x] w2[x] wu2[x] wl1[x] w1[x] wu1[x]
4/20/2015
166
1

2
3
4
5
6
7
Získá požadavek pi[x] od transakčního monitoru a otestuje, zda-li je pli[x]
v konfliktu s nějakým již dříve nastaveným qlj[x] (p, q  {r, w})
 Pokud ano, pak zdrží operaci pi[x], Ti musí čekat, až bude zámek k dispozici
 Pokud není v konfliktu, přidělí zámek pli[x] a pošle operaci pi[x] databázi

Jakmile je jednou zámek pli[x] přidělen, tak může být uvolněn nejdříve ve
chvíli, kdy databáze oznámí ukončení zpracování požadavku pi[x]

Jakmile transakce Ti uvolní jakýkoliv zámek, Ti již nemůže žádný jiný
dostat (dvoufázovost = zamykání a odemykání)

Je ale potřeba řešit problémy s uváznutím - wl1[x] wl2[y] wl1[y] wl2[x]
4/20/2015
167
1

2
3
4
5
6
7
Kdy může plánovač uvolnit zámek pli[x]?
 Ti již nebude s objektem x pracovat
 2PL → Ti už žádné zámky nebude požadovat
 Obecné řešení – uvolnit zámky jedině při ai nebo ci

Plánovač striktního 2PL může uvolňovat rl a wl různě
 Uvolní rli[x] zámky ve chvíli, kdy přijde požadavek ai nebo ci
 Uvolní wli[x] až jakmile databázové procesy abortují/potvrdí

S2PL užívaný ve většině implementací 2PL
 Triviálně řeší problém s uvolňováním zámků
 Řeší problémy zotavitelnosti a kaskádových abortů
 Stejně jako 2PLneřeší problémy s
▪ Uváznutím transakcí – vzájemné držení a požadování zdrojů
▪ „Hladověním“ transakcí – neustálé přidělování rl[x] brání přidělení wl[x]
4/20/2015
168
1


5
6
7
wi[x]
wui[x]
plj[x]
pj[x]
puj[x]
wli[x] < i wi[x] < i wui[x] a plj[x] < j pj[x] < j puj[x]
Z konfliktní tabulky zámků plyne


4
Z definice 2PL plyne


3
S2PL generuje CSR & striktní historie (H12) - uvažujme wi[x] <H pj[x] v H
wli[x]

2
wli[x] a plj[x] jsou konfliktní, proto wui[x] < H plj[x] nebo puj[x] < H wli[x]
Z toho plyne wui[x] < H plj[x]
V S2PL platí
H1
H2
H3 CSR
H4
H5
H6
RC
H7
H8
H9
ACA
H12
ST
H10 H11

Buď ai < H wui[x] or ci < H wui[x]
 Proto ai < H pj[x] or ci < H pj[x]
4/20/2015
VSR
Serial
169
1

2
3
4
5
6
7
Jak zabránit problému s uváznutím u (S)2PL?
 Každá transakce Ti předem deklaruje všechny zámky potřebné pro
všechna r[x] a w[x]
 Plánovač se je před startem Ti pokusí zamknout
▪ Pokud uspěje, Ti je spuštěna a pak jsou zámky uvolněny
▪ Pokud neuspěje, čeká ve frontě
 Jakmile nějaká Tj skončí, vybere takovou čekající transakci Ti, která
může dostat požadované zámky

U konzervativního 2PL nemůže dojít k uváznutí

Problém je ale v „ … Ti předem deklaruje …“
4/20/2015
170
1



2
3
4
5
6
7
Výskyt v dynamických DB (tj. uvažujeme i vkládání a mazání záznamů)
Jedna transakce pracuje s množinou entit a druhá ji mění  nekonzistence DB
V příkladu rozvrh s fantomem (mají být zamčeni všichni muži)
Jméno
Pohlaví
Věk
rl(Pohlavi = ‘M’)
Karel
M
44
@PocetMuzu = PocetOsob(‘M’)
Jana
Z
28
Petr
M
32
T1
T2
INSERT(‘Jan’, ‘M’, 42)
INSERT(‘Tom’, ‘M’, 50)
INSERT(‘Petra’, ‘Z’, 35)
COMMIT
@Prumer = SoucetVekuOsob(‘M’) / @PocetMuzu
S(T1, T2)  @Prumer = 38
S(T2, T1)  @Prumer = 42
PRINT(@Prumer)
ul(Pohlavi = ‘M’), COMMIT
4/20/2015
P  @Prumer = 84 !!!
171
1

2
3
4
5
6
7
Pokud transakce čte data opakovaně, musí načíst to samé!
T1: SELECT Count(*) FROM Osoba
WHERE Věk ≥ 38
T2: INSERT INTO Osoba
VALUES (‘Dan’, ‘M’, 47)
T1: SELECT Sum(*) FROM Osoba
WHERE Věk ≥ 38
Jméno
Pohlaví
Věk
Karel
M
44
Jana
Z
28
Petr
M
32
Jan
M
42
Tom
M
50
Petra
Z
35
Potřebujeme jiný mechanismus zamykání umožňující rl(Věk ≥ 38)
Jana
28
Petr
29
30
31
32
Petra
33
34
35
Jan
36
37
38
39
40
41
42
Karel
43
Dosud uvažované zamykání existujících záznamů nestačí!
4/20/2015
44
Tom
45
46
47
48
49
50
51
Dan
172
1

2
3
4
5
6
7
Problémy se zamykáním v dynamické DB
 Zámky se přidělují objektům, ne všechny jsou ale v DB
 Co zamknout, když je výsledek dotazu ?
 Co zamknout, když mažeme? Vkládáme?

Triviálně lze řešit zamknutím celé DB  SR rozvrh

V praxi se spíš řeší jemnějším zamykáním
 Predikátové zámky
 Rozsahové zámky
 Granulované zámky
4/20/2015
173
1
2
3
4

Zámek je nastaven na výběrový predikát (… WHERE Věk ≥ 38)

Dva zámky jsou pak v konfliktu, když se jejich predikáty nevylučují
5
6
7
 p1(x) = x.Věk ≥ 38, p2(x) = x.Věk ≤ 45, existuje x takové, že p1(x) ˄ p2(x) ??

Problémy
 Náklady na realizaci – test na konflikt dvou predikátů je NP-úplný problém, ale
v praxi je potřeba rychlý algoritmus (časté zamykání)
 Pesimismus - pro predikáty P1, P2 a systémový invariant I může platit, že P1 &
P2 = true, ale P1 & P2 & I = false
 Zdroj predikátu – jak vlastně získat potřebný predikát pro zadaný dotaz,
update?

Precision locks – jednodušší test na konflikt dvou predikátů
 Pro predikáty, které se musí zamknout, se musí po každé operaci
▪ Ověřit výsledek oproti predikátům nebo čekat, pokud dojte ke konfliktu
 Velká pravděpodobnost uváznutí, navíc není moc efektivní (hodně ověřování)
4/20/2015
174
1

2
3
4
5
6
7
Vhodné pro struktury využívající uspořádání záznamů
 Jsou data vůbec uspořádatelná?
 Existence záznamů – jak ohlídat „díry“ v uspořádaných datech?

Zjednodušení predikátů - omezení pouze na intervaly v
uspořádáních daných indexy

Typy intervalů
 Statické intervaly – nezávisí na datech
 Dynamické intervaly – hranice intervalu jsou klíče, které se vyskytují v
indexu
4/20/2015
175
1

2
3
4
5
6
7
Použijeme pro sémantiku zamykání polouzavřené intervaly
 Zámek na klíči implikuje i zamčení intervalu (tj. díry) mezi dvěma klíči!
 Zamykání následujícího klíče – schopnost zamknout +∞, používá zleva otevřený
interval (x, y], pro neexistující klíč zamkne první větší tj. ten následující
 Zamykání předcházejícího klíče – schopnost zamknout nejnižší hodnotu,
používá zprava otevřený interval [x, y), pro neexistující klíč zamkne první menší

Uvažujeme následující typy operací nad uspořádanými daty
 Pokud chce Ti číst x které neexistuje, žádná Tj nemůže vytvořit x dokud Ti
neskončí
 Pokud čte Ti x a čte i následující y, tak nemůže žádná Tj vložit objekt mezi x a y
dokud Ti neskončí
 Pokud Ti smaže x, pak se to ostatní Tj dozví až poté, co Ti skončí
4/20/2015
176
1

3
4
5
6
7
Dejme tedy tradičnímu zamykání následující sémantiku

Zamykání předcházejícího klíče – pro sekvenci x, y, z zamkne zámek na y interval [y, z)
Zamykání následujícího klíče – pro sekvenci x, y, z zamkne zámek na y interval – (x, y]


2
Pravidla pro načtení unikátního a následujícího záznamu pomocí zamykání předcházejícího klíče

Načtení unikátního x mezi w a y
▪
▪

transakce musí při opakovaném čtení
načíst to samé, zamčený objekt hlídá
interval, kde se nesmí vyskytnout insert
Pokud x existuje, zamkne pro čtení x, což implikuje zámek [x, y)
Pokud x neexistuje, zamkne pro čtení w, což implikuje zámek [w, y)
Načtení následujícího y poté, co načte unikátní x mezi w a y
▪
▪
Již zamknuto pro čtení x, což implikuje existenci zámku [x, y)
Zamkne pro čtení y, což implikuje zámek [y, z)
Jana
28
Petr
29
30
31
32
Petra
33
34
35
Jan
36
37
38
39
40
41
42
Karel
43
44
Tom
45
46
47
48
49
50
51
rl(38)
rl(42)
4/20/2015
177
1

3
4
5
6
7
Dejme tedy tradičnímu zamykání následující sémantiku

Zamykání předcházejícího klíče – pro sekvenci x, y, z zamkne zámek na y interval [y, z)
Zamykání následujícího klíče – pro sekvenci x, y, z zamkne zámek na y interval – (x, y]


2
Pravidla pro vkládání a mazání pomocí zamykání předcházejícího klíče

Vložení x mezi w a y
▪
▪
▪

aby transakce mohla vložit objekt mezi w a y,
tak nesmí jiná transakce držet zámek na w
při vkládání se musí zamknout i „neexistující“ x !!!
Zamkne pro zápis w, což implikuje zámek [w, y)
Zamkne pro zápis x, což implikuje zámek [x, y)
Vloží x, změní se interval zámku z [w, y) na [w, x)
Smazání x mezi w a y
▪
▪
▪
Jana
28
Petr
29
30
31
wl(28)
INSERT(30)
wl(28)
4/20/2015
aby transakce T mohla smazat objekt mezi w a y,
tak nesmí jiná transakce držet zámek na w, jinak
by T nemohla zamknout [w, y) pro případný abort
Zamkne pro zápis w, což implikuje zámek [w, x)
Zamkne pro zápis x, což implikuje zámek [x, y)
Smaže x, zámek na w pak implikuje interval zámku [w, y)
32
;
Petra
33
34
35
Jan
36
37
38
39
wl(35)
wl(30)
40
41
42
Karel
43
44
Tom
45
46
47
48
49
50
51
;
wl(42)
DELETE(42)
wl(35)
178
1

2
3
4
5
6
7
Používají se pro data organizovaná do logických hierarchií, kde zámek na
určitém uzlu hierarchie implikuje zámky na všech potomcích

Jednoduchá forma predikátových zámků – predikát představuje objekty v podstromu
 Velké transakce tak mohou zamykat celé tabulky – málo zámků
 Jednoduché transakce zamykají jen jednotlivé záznamy – propustnost

Používá se obvykle s 2PL protokolem

Lze je použít i pro intervalové zamykání (různá velikost intervalů)

Příklad - strukturální hierarchie V MS SQL 2008

DB, …, File, Table, Heap or B-Tree, Extent (8 pages), Page (8KB), Key (range), RID
 Systém automaticky volí vhodnou granularitu pro danou transakci
4/20/2015
179
1



4
5
6
7
Než se přidělí uzlu zámek, je potřeba vyloučit existenci konfliktních zámků u všech jeho potomků !!!
Průchod grafem je neefektivní a pomalý
Uzel již zamčen jako…
Používají se intenční zámky - il




il
rl
wl
il
Ano
Ano
Ne
Ne
rl
Ano
Ne
Ano
Ne
Ano
Ne
Ne
Ne
Chceme
Pravidla pro zamykání s il


3
Jak ale zajistit zamykání na hierarchiích?


2
Zámky se získávají od kořene k listům
wl
Zámky se uvolňují směrem od listů ke kořenu
Před zamčením uzlu musí být zamčený rodič intention zámkem
Tabulka pro vydání požadovaného zámku
Problém - jednoduché il zámky umožní kolizi dvou rl zámků na různých úrovních


Proto se ještě zvlášť rozlišují il pro čtení (irl) a pro zápis (iwl)
Pravidla se pak upraví následně
▪
▪
4/20/2015
Zámky se získávají od kořene k listům a uvolňují od listů ke kořenu
Před zamčením uzlu rl/wl zámkem, musí být rodič zamknutý irl/iwl zámkem
180
1

2
3
4
5
6
7
Intenční zámky a tabulka kompatibility zámků
 irl – v podstromu bude požadován rl
 iwl – v podstromu bude požadován wl
 riwl – uzel uzamčen pro čtení, v podstromu bude požadován wl

irl
iwl
rl
riwl
wl
irl
Ano
Ano
Ano
Ano
Ano
Ne
iwl
Ano
Ano
Ano
Ne
Ne
Ne
rl
Ano
Ano
Ne
Ano
Ne
Ne
riwl
Ano
Ano
Ne
Ne
Ne
Ne
wl
Ano
Ne
Ne
Ne
Ne
Ne
Chceme
4/20/2015
181
1

3
4
5
6
7
Po načtení objektu často dochází k zesílení rl na wl – může docházet k uváznutí


2
… rl3[x] r3[x] rl1[x] r1[x] rl2[x] r2[x] c3 wl1[x] wl2[x]  uváznutí
Proto se množina zámků rozšiřuje ještě o tzv. update zámky ul



Update zámek lze získat i když je objekt zamčen pro čtení, ale ne naopak
Pouze update a riwl zámek lze zesílit na wl  méně uváznutí
… rl3[x] r3[x] ul1[x] r1[x] c3 wl1[x] w1[x] c1 ul2[x] r2[x] wl2[x] w2[x] …

irl
iwl
rl
riwl
ul
wl
irl
Ano
Ano
Ano
Ano
Ano
Ne
Ne
iwl
Ano
Ano
Ano
Ne
Ne
Ne
Ne
rl
Ano
Ano
Ne
Ano
Ne
Ne
Ne
riwl
Ano
Ano
Ne
Ne
Ne
Ne
Ne
ul
Ano
Ano
Ne
Ano
Ne
Ne
Ne
wl
Ano
Ne
Ne
Ne
Ne
Ne
Ne
Chceme
4/20/2015
182
1
2
3
4
5

Pokud je v T objekt x uzamčen pl[x] a je v T
požadován v jiném módu ql[x], tak je výsledekm
maximum módů pl[x] a ql[x]

Částečné uspořádání zámků je dáno obrázkem
iwl
7
riwl
irl
wl
rl
4/20/2015
6
ul
183
1
2
3

Pokud se ukáže, že zvolená granularita zamykání není optimální

Příklady
4
5
6
7
 Projíždíme celou tabulku, nemá cenu zamykat po řádku
 Systém udělá chybu, zbytečně zamkne hodně záznamů

Řešení
 Změnit například irl za rl v uzlu hierarchie

Escalation treshold – většinou 1000 zámků
4/20/2015
184
1
2
3
4

Transakce může přistoupit k datům jen za použití B+-stromu (každá
relace musí mít aspoň jeden), neplést s granulovanými zámky !!!

Používá 2PL protokol pro vnitřní uzly na cestě k listu

Vyhledávání
5
6
7
 Transakce musí uzamknout uzly zámkem pro čtení
 Drží zámek na list i když neobsahuje hledaná data

Vkládání/mazání/změna dat
 Musí obdržet exkluzivní zámky na uzly
 Musí aktualizovat i všechny indexy pro danou relaci (tj. nejen data)

Garantuje prevenci fantoma, ale nevyužívá dalších informací
 Vyšší vrstvy B+-stromu pouze směrují vyhledávání
 Vnitřní uzly se musí zamykat jen v případě, že k nim může dorazit štěpení
4/20/2015
185
1
2
3
4
5
6
7

B+-strom je populární datová struktura pro relačních databáze

B+-strom je potřebný hlavně k optimalizaci vyhledávání a je
proto neustále využívanou strukturou

Používat 2PL na cestu od kořene k listu je příliš omezující !!!

Snaha o dřívější uvolňování zámků na vnitřní uzly
 Crabbing protokol (odvozeno od chůze kraba)
 B-link protokol
4/20/2015
186
1

2
3
4
5
6
7
Vyhledávání
 Zamkne se aktuálně zpracovávaný uzel pro čtení
 Až poté co zamkne všechny jeho potomky pro čtení uvolní zámek na uzlu

Vkládání/mazání
 Cestou k listu stejně jako při vyhledávání (neblokuje se s dotazy)
 Zesílí zámek držený pro daný list na zámek pro zápis
 Při štěpení/slévání uzlů zamkne rodičovský uzel pro zápis

Náchylné k uváznutí
 Vyhledávání se vzájemně blokuje se zámky potřebnými pro štěpení/slévání
 Možno řešit restartem transakce, která jde směrem k listu

Namísto restartu se může modifikovat zamykání a odemykání rodiče
 Používat jen exkluzivní zámky pro vkládání/mazání (blokování dotazů)
 Odemknout uzly až ve chvíli, kdy je jasné že se k nim nebude propagovat
štěpení (např. některý z potomků není plný)
4/20/2015
187
1
2
3
4
5

Úprava struktury - sourozenci na každé úrovni B+-stromu jsou
propojeni ukazateli (tvoří spojový seznam)

Vyhledávání
6
7
 Používá zámky pro čtení, zámek pro rodiče je uvolněn ještě před
zamčením potomka
 Neblokuje rodiče pro případné štěpení, čeká až proběhne, pak stejně
načte co má díky propojení uzlů na stejné úrovni
▪ Před štěpením potomka T nenašla v rodičovském uzlu nový směrovací záznam
▪ Štěpený potomek je ale ve výsledku propojený s nově vzniklým uzlem!
▪ „Přeskočení“ nového směrovacího záznamu tak nemá vliv na výsledek

Vkládání/mazání
 Stejné jako hledání, jen používá exkluzivní zámky pro listy
 V případě štěpení zamkne rodičovský uzel pro zápis (nyní již není
blokován jinou transakcí)
4/20/2015
188
1
2
3
4
5

Transakce Ti žádá prostředky, které drží jiná transakce Tj. Ta požaduje
zase prostředky, které drží transakce Ti. Obě jsou tudíž zablokovány

Může nastat i při S2PL

Jak se vypořádat s uváznutím
6
7
 Detekce a vyřešení
▪ Waits-for graf, transakce dlouho nic nedělá, …
▪ Restartovat (i jen částečně) transakci dle nějakého kritéria (log, čas)
 Prevence
▪ Konzervativní 2PL protokol (všechny zámky už na začátku)
▪ Prioritní/časové upřednostňování (časové razítko určuje prioritu)
4/20/2015
189
1
2
3

Na začátku běhu získá transakce časové razítko

Wait/Die
4
5
6
7
 Dříve spuštěná transakce může čekat na zámek držený
později spuštěnou transakcí
 Později spuštěná transakce nikdy – je zrušena

Wound/Wait strategie
 Dříve spuštěná transakce zruší později spuštěnou transakci
v případě konfliktu zámků
 V opačném případě později spuštěná transakce čeká

Restart probíhá s původním časovým razítkem – proč?
4/20/2015
190
1

2
3
4
5
6
7
Aby nastalo uváznutí, musí být současně splněny všechny čtyři
následující podmínky
 Vzájemné vyloučení - prostředek přidělen jen jednomu procesu
 Držení prostředků - proces může držet a přitom žádat další prostředky
 Neodnímatelnost - prostředky může vrátit pouze proces, který je
vlastní
 Čekání do kruhu - existuje cyklus ve waits-for grafu

Obecná řešení uváznutí





T1 chce prostředky držené T2
T1
T2
Vůbec si problému nevšímat
T2 chce prostředky držené T1
Detekce a zotavení
Opatrné přidělování zámků (dynamická metoda)
Prevence zajištěná nesplněním jedné ze čtyř podmínek
Transakce podporují rollback – uváznutí je možné řešit i triviálně
4/20/2015
191
1

6
7
Čekání na prostředky musí být vzácné (jinak je systém špatně navržen)
Uváznutí je pak o to víc vzácné
R zdroji, N+1 transakcemi a A+1 update akcemi
Předpokládáme N * A << R (většina zdrojů odemčena)
N transakcí, každá má zamčeno A/2 z R zdrojů
Pakce = N * A / (2 * R)
Pravděpodobnost, že je transakce blokovaná


5
Pravděpodobnost, že je akce blokovaná


4
Uvažujme systém s



3
Hypotéza



2
A pokusů o uzamčení
Ptransakce = 1 – (1 – Pakce)A  N * A2 / (2 * R)
Pravděpodobnost, že dojde k uváznutí

4/20/2015
Uvažujeme cykly délky 2, delší jsou ještě vzácnější
Puváznutí  Ptransakce 2 / N = N * A4 / (4 * R2)
192
1

2
3
4
5
6
7
Problém je v dlouhotrvajících transakcích
 Měřeno v počtu vyžádaných zámků
 Oprávňuje používání krátkodobých zámků
 Oprávňuje používání zámků jen pro čtení

Problém je ve velkém počtu transakcí
 Oprávňuje architekturu s transakčním monitorem

Pokud je čekání vzácné, uváznutí je vzácné2
4/20/2015
193
1
2
3
4
5

Sice známe postačující podmínky pro zajištění izolace,
ale…

V řadě situací jsou příliš omezující
6
7
 Např. průměr hodnot ve velké DB = zamknout vše

Důsledek – je potřeba hledat kompromisy – jak zamykat,
aby byl výsledek dostatečně izolovaný a přitom moc
nebrzdil

Jedno z řešení jsou stupně izolace – kompromisy
 Uživatel ví co dělá, popř. se mohou některé povolit jen pro čtení

Možnost kombinace stupňů izolace
4/20/2015
194
1
2
3
4
5
6
7

Stupeň 0: Transakce nepřepíše cizí data, pokud ta jsou
součástí transakce alespoň stupně 1, tj. zamykání je dobře
formované s ohledem na zápis ale není dvoufázové.

Stupeň 1: Transakce nebude mít lost updates - zamykání je
dvoufázové s ohledem na exkluzivní zámky a dobře
formované s ohledem na zápis.

Stupeň 2: Transakce nebude mít lost updates ani dirty
reads - zamykání je dvoufázové s ohledem na exkluzivní
zámky a dobře formované.

Stupeň 3: Transakce bude úplně izolovaná - zamykání je
dvoufázové a dobře formované.
4/20/2015
195
1

Úroveň
WR
RW
Fantom
READ UNCOMMITTED
(read only transakce)
možná
možná
možná
READ COMMITTED
Ne
možná
možná
REPEATABLE READ
Ne
Ne
možná
SERIALIZABLE
Ne
Ne
Ne
2
3
4
5
6
7
READ UNCOMMITTED v MS SQL




4/20/2015
Nepoužívají se zámky na čtení, S2PL na zápis
Je možné číst nekonzistentní data
Je možné načíst podruhé jiná data
Není prevence fantoma
196
1

Úroveň
WR
RW
Fantom
READ UNCOMMITTED
možná
možná
možná
READ COMMITTED
Ne
možná
možná
REPEATABLE READ
Ne
Ne
možná
SERIALIZABLE
Ne
Ne
Ne
2
3
4
5
6
7
READ COMMITTED v MS SQL
 Čtení je dobře formované ale ne dvoufázové , S2PL na zápis
 Zámek se uvolní po přečtení záznamu/stránky/tabulky
 Je možné načíst podruhé jiná data
 Není prevence fantoma
4/20/2015
197
1

Úroveň
WR
RW
Fantom
READ UNCOMMITTED
možná
možná
možná
READ COMMITTED
Ne
možná
možná
REPEATABLE READ
Ne
Ne
možná
SERIALIZABLE
Ne
Ne
Ne
2
3
4
5
6
7
REPEATABLE READ v MS SQL
 Čtení i zápis S2PL
 Není prevence fantoma
4/20/2015
198
1

Úroveň
WR
RW
Fantom
READ UNCOMMITTED
možná
možná
možná
READ COMMITTED
Ne
možná
možná
REPEATABLE READ
Ne
Ne
možná
SERIALIZABLE
Ne
Ne
Ne
2
3
4
5
6
7
SERIALIZABLE v MS SQL
 Čtení i zápis S2PL
 Intervalové zámky pro prevenci fantoma
4/20/2015
199
1
2
3
4
5
6


7







Zamykání objektů
Časová razítka
Certifikace
Multiversion data
TP Monitor
r2[y], r1[x], w2[x], r1[y], w1[x], c1, …
Plánovač
r2[y], r1[x], r1[y], w1[x], c1, w2[x], …
Databáze
4/20/2015
201
1

Nepoužívá zámky, zatím se v komerčních systémech moc neujalo

Je založeno na časovém uspořádání (Time Ordering)




5
6
7
Každá transakce má přiřazeno unikátní časové razítko ts(Ti)
Pro každé dvě různé transakce platí ts(Ti) < ts(Tj) nebo ts(Tj) < ts(Ti)
Každá operace pi[x] je označena pomocí ts(Ti)
Jednoduchý monitor – počítadlo, hodiny
Více monitorů v systému – [počítadlo, TM_Id] jako razítko
Pokud pi[x] a qj[x] jsou konfliktní operace, pak databáze zpracuje pi[x] před qj[x] právě tehdy,
když ts(Ti) < ts(Tj)
Pokud je H historie reprezentující výpočet plánovaná pomocí TO pravidla, pak je H uspořádatelná




4
TO pravidlo – konfliktní operace jsou seřazeny dle odpovídajících časových razítek


3
Jak transakci přiřadit časové razítko?



2
Pokud v PG existuje hrana mezi Ti  Tj, pak v H existuje konfliktní dvojice pi[x] < qj[x]
Z toho plyne, že používáním TO pravidla musí platit ts(Ti) < ts(Tj)
V případě cyklu T1  ..  Tn  T1 v PG by muselo platit ts(T1) < ts(T1)  SPOR
Používání TO pravidla má stejný efekt, jako sériový rozvrh uspořádaný dle časových razítek
4/20/2015
202
1


4
5
6
7
Plánovač přeposílá pi[x] z monitoru do DB (FIFO)
Posloupnost pi[x] qj[x] oi[x] která vede ke konfliktu poruší TO pravidlo - oi[x] požadavek přišel
pozdě
V takovém případě (odmítnutí oi[x]) dojde k abortu Ti, Ti pak musí dostat nové časové razítko
Jak poznat, že požadavek poruší TO pravidlo (přišel pozdě)?


Pro každou datovou položku udržujeme maximální časové razítko pro čtení a zápis, např. v
polích rts[x] a wts[x]
Plánovač po obdržení požadavku ri[x]
▪
▪

Pokud ts(Ti) < wts[x] pak odmítne ri[x], tj. abortuje Ti
Jinak pustí ri[x] a pokud ts(Ti) > rts[x] pak rts[x] = ts(Ti)
Plánovač po obdržení požadavku wi[x]
▪
▪

3
Jednoduchá agresivní implementace TO pravidla



2
Pokud ts(Ti) < rts[x] nebo ts(Ti) < wts[x] pak odmítne wi[x], tj. abortuje Ti
Jinak pustí wi[x] a pokud ts(Ti) > wts[x] pak wts[x] = ts(Ti)
Plánovač by měl garantovat, že bude databáze zpracovávat požadavky ve
stejném pořadí, v jakém jsou předloženy (čekání na potvrzení z DB)
4/20/2015
203
1

2
3
4
5
6
7
Pro každou datovou položku si plánovač uchovává počet r[x]
a w[x], které byly odeslány do DB ale nebyly potvrzeny
 Použijeme pole r-nepotvrzeno[x] a w-nepotvrzeno[x]

Je potřeba fronta požadavků na DB, uspořádaná dle
časového razítka, plánovač pak funguje následovně
 Po obdržení požadavku ri[x]
▪ Pokud w-nepotvrzeno[x] > 0 pak vloží ri[x] do fronty
▪ Jinak pustí ri[x] a inkrementuje r-nepotvrzeno[x]++
 Po obdržení požadavku wi[x]
▪ Pokud r-nepotvrzeno[x] + w-nepotvrzeno[x] > 0 pak vloží wi[x] do fronty
▪ Jinak pustí wi[x] a inkrementuje w-nepotvrzeno[x]++
4/20/2015
204
1

3
4
5
6
7
Základní TO pravidlo zajišťuje uspořádatelnost, ale ne zotavitelnost – viz. příklad



2
ts(T1) = 1, ts(T2) = 2, H = w1[x] r2[x] w2[y] c2
H je CSR ale ne RC (potvrzující T2 čte z T1, která nepotvrdila)
Pravidla pro striktní TO



w-nepotvrzeno[x] je buď 0 nebo 1, protože zápis blokuje další zápisy
w-nepotvrzeno je nastaveno na 0 pouze tehdy, když plánovač obdrží od DB potvrzení o ci nebo ai
Když nastane ci nebo ai, w-nepotvrzeno[x] je nastaveno na 0 pro jakékoliv x pro které bylo wi[x]
zasláno databázi transakcí Ti

V základním TO pravidle je w-nepotvrzeno nastaveno na 0 pokud DB potvrdí přijetí wi[x]

Pokud je w-nepotvrzeno[x] nastaveno na 1, tak dojde k blokování všech konfliktních
operací


4/20/2015
Tj. dojde ke zdržení rj[x] a wj[x] s ts(Tj) > ts(Ti) do doby, než Ti potvrdí nebo abortuje
A proto je výsledná historie striktní, navíc, protože Tj čeká na Ti pouze tehdy, pokud ts(Tj) > ts(Ti), tak
nemůže dojít k uváznutí
205
1

2
3
4
5
6
7
Nastavení w-nepotvrzeno[x] se chová podobně jako zámek
 Získali jsme tak z TO pravidla 2PL plánovač? Uvažujme historii H
H = r2[x] w3[x] c3 w1[y] c1 r2[y] w2[z] c2

H je ekvivalentní sériové historii T1 T2 T3
 (r2[x] < w3[x], w1[y] < r2[y]) a tak SR

H je striktní (w1[y] < r2[y], ale c1 < r2[y])
 Uvažujme TO
▪ Pokud ts(T1) < ts(T2) < ts(T3) pak H vznikla užitím striktního TO plánovače
 Uvažujme 2PL
▪ T2 musí uvolnit zámek rl2[x] před spuštěním w3[x]
▪ T2 nemůže nastavit rl2[y] dokud nepřijde c1 kvůli w1[y]
▪ Kvůli w3[x] < w1[y] dojde k porušení dvoufázovosti
4/20/2015
206
1
2
3
4
5
6
7

Pokud agresivní plánovač získává často operace různých časových
razítek (1, 4, 3, 1, 4, 2, …), tak to může vést k příliš častým abortům

Konzervativnější verze TO plánovače
 Pozdržet některé operace (čekat na operace starších transakcí )
 Ale, zdržení operace = zdržení transakce = holt něco za něco …

Ultimátní konzervativní TO plánovač nikdy neabortuje transakce
 Požadavky na systém
▪ Deklarovat předem všechna r[x] a w[x]
▪ Spouštět operace v pořadí časových razítek
 Pokud není splněné (např. nemáme deklarace r[x] a w[x])
▪ Fronta operací uspořádaná dle časových razítek
▪ Plánovat pouze hlavu fronty, pokud fronta obsahuje alespoň jednu operaci z
každé aktivní transakce
 Produkuje sériové historie…
4/20/2015
207
1
2
3
4
5
6


7







Zamykání objektů
Časová razítka
Certifikace
Multiversion data
TP Monitor
r2[y], r1[x], w2[x], r1[y], w1[x], c1, …
Plánovač
r2[y], r1[x], r1[y], w1[x], c1, w2[x], …
Databáze
4/20/2015
208
1
2
3
4
5

Opět nepoužívá zámky, zatím se v komerčních systémech
moc neujalo

Je postaveno na udržování lehce modifikovaného
precedenčního grafu, ve kterém se hlídá acykličnost

Modifikovaný precedenční graf (MPG)
6
7
 Neobsahuje všechny potvrzené transakce (jsou odebrány takové,
které byly dávno ukončené)
 Uzly všech aktivních transakcí jsou uloženy (až na zrušené a
potvrzené)
4/20/2015
209
1

2
3
4
5
6
7
Plánovač obdrží pi[x] z monitoru
 Přidá do MPG uzel Ti v případě, že tam ještě není
 Přidá hranu z Tj do Ti pro každou dříve plánovanou operaci qj[x], která
je konfliktní s pi[x]

Pokud MPG obsahuje cyklus pak zamítne pi[x]
 Abortuje Ti, tj. zašle ai databázi a smaže Ti z MPG
 Smaže z MPG také všechny hrany incidentní s Ti
 Tímpádem zůstane MPG acyklický

Pokud zůstane MPG acyklický pak přijme pi[x]
 Plánuje pi[x] poté, co databáze potvrdí všechny dříve zaslané operace
konfliktní s pi[x]
 Implementováno podobně jako u základního TO pomocí FIFO fronty a
pomocí polí r-nepotvrzeno[x] a w-nepotvrzeno[x]
4/20/2015
210
1

3
4
5
6
7
Jak zjistit všechny dříve plánované operace qj[x], které jsou konfliktní s pi[x] ??


2
Pro každou Ti v MPG je potřeba udržovat seznam objektů x, pro které bylo plánováno
čtení a zápis - použijeme pole r-plánováno[Ti] a w-plánováno[Ti]
pi[x] je konfliktní s dříve plánovanou operací qj[x] z Tj když
x  q-plánováno[Tj] pro q konfliktní s p, tj.
ri[x] je konfliktní s dříve plánovanou operací wj[x] z Tj když x  w-plánováno[Tj]
 wi[x] je konfliktní s dříve plánovanou operací qj[x] z Tj když
x  r-plánováno[Tj] nebo x  w-plánováno[Tj]


Kdy je možné smazat r-plánováno[Ti] a w-plánováno[Ti]? Ne s potvrzením Ti!!!

Uvažujme H = rk+1[x] w1[x] w1[y1] c1 w2[x] w2[y2] c2 … wk[x] wk[yk] ck
 Uvažujme wk+1[z], pokud z  {x, y1, …, yk} pak vznikne cyklus v MPG
 Ač T1, …, Tk potvrdily, je potřeba stále ještě udržovat jejich pole q-plánováno !!!
4/20/2015
211
1

2
3
4
5
6
7
Takže, kdy je možné smazat r-plánováno[Ti] a w-plánováno[Ti] ???
 V případě, že se Ti již nemůže vyskytnout v žádném cyklu v MPG
 Cyklus zahrnující Ti implikuje alespoň jednu vstupní Tj  Ti a jednu výstupní
hranu Ti  Tk
▪ Nová výstupní hrana se může objevit po skončení
▪ Nová vstupní hrana se nemůže objevit po skončení
 Důsledek – jakmile z uzlu Ti hrany pouze vychází, tak již Ti nemůže být součástí
cyklu a pokud již skončila, tak může být odebrána

Testováním MPG na cyklus plánovač umožňuje prokládání čtení a zápisů
x, která vedou k uspořádatelnému rozvrhu

Je shovívavější než…
 TO plánovač - umožňuje jen takové prokládání, které je dáno časovými razítky
operací ri[x] a wi[x] – tj. u TO neprojde například rozvrh r1[x], r2[x], w1[x]
 2PL plánovač - neumožňuje určitá prokládání čtení a zápisů - w1[x], r2[x], w1[y]

Nicméně – udržování MPG a zjišťování cyklů přináší velkou režii
4/20/2015
212
1
2
3

Namísto abortování pozdržuje operace

Každá transakce Ti předem deklaruje objekty, se
kterými bude pracovat – r-data[Ti] a w-data[Ti]

Jakmile je Ti spuštěna, tak plánovač
4
5
6
7
 Uloží množiny r-data[Ti] a w-data[Ti]
 Vytvoří uzel Ti v MPG a přidá Tj  Ti pro každou Tj v MPG
takovou, že p-data[Tj]  q-data[Ti]   pro všechny páry
konfliktních operací p a q

Což v podstatě znamená, že plánovač rozhodne, v
jakém pořadí mají být transakce zpracovány
4/20/2015
213
1

r-data[T1] = {x, y, z}, w-data[T1] = {x, z}

r-data[T2] = {y, z}, w-data[T2] = {y, z}
 r-data[T1]  w-data[T2] = {y, z}
 w-data[T1]  r-data[T2] = {z}
3
4
5
6
7
T1
 w-data[T1]  w-data[T2] = {z}

2
T2
r-data[T3] = {x}, w-data[T3] = {x}
 r-data[T1]  w-data[T3] = {x}
 w-data[T1]  r-data[T3] = {z}
T3
 w-data[T1]  w-data[T3] = {x}
 T2 a T3 nepracují se stejnými objekty
4/20/2015
214
1
2
3
4
5
6
7

Pro každý objekt x pak queue[x] uchovává pozdržené operace na x

Konfliktní operace jsou uložené ve stejném pořadí jako hrany MPG
 Pokud je v MPG Tj  Ti pak je qj[x] blíž hlavě queue[x] než pi[x]
konfliktní s qj[x]
 Nekonfliktní operace jsou uloženy v pořadí jejich obdržení (na nich
nezáleží)

pi[x] může být zasláno databázi pouze tehdy, když
 Všechny operace konfliktní s pi[x] zaslané DB jsou potvrzeny
 Pro každou Tj takovou, že Tj  Ti  MPG, a pro každou operaci q
konfliktní s p platí, buď x  q-data[Tj] nebo qj[x] již byla přijata
plánovačem, jinými slovy, x  q-plánováno[Tj]
4/20/2015
215
1
2
3
4
5

První pravidlo zaručuje, že jsou konfliktní operace zpracovány v
pořadí, v jakém jsou naplánovány

Druhé pravidlo brání abortu kvůli operacím, které dorazí příliš
pozdě (způsobí cyklus)
6
7
 Všechny operace Tj by měly být zpracovány před všemi konfliktními
operacemi z Ti aby se zabránilo cyklu v MPG, což je zaručeno
pozdržením pi[x]
 K vyhodnocení této podmínky je potřeba udržovat q-plánováno[Tj]

Podtrženo a sečteno…
 Pokaždé když dorazí pi[x] z monitoru nebo potvrzení(qj[x]) z DB,
plánovač zkontroluje, jestli je hlava queue[x] připravena
▪ Pokud je připravena, tak odebere operaci z fronty a zašle do DB
▪ Pokud není připravena, tak operaci ve frontě pozdrží
 Způsob odebrání Ti z MPG je stejný jako v základním plánování PG
4/20/2015
216
1
2
3
4
5
6

Základní a konzervativní plánování pomocí PG
vytváří uspořádatelné historie, které ale nejsou RC,
ACA a ST

Aby plánovač vytvářel striktní historie, tak může
použít stejnou techniku jako striktní TO
7
 Nastavit w-nepotvrzeno[x] na 1 po zaslání wi[x] do DB
 Nesnížit w-nepotvrzeno[x] po potvrzení wi[x] z DB, ale až
po potvrzení ai nebo ci z DB
4/20/2015
217
1
2
3
4
5
6


7







Zamykání objektů
Časová razítka
Certifikace
Multiversion data
TP Monitor
r2[y], r1[x], w2[x], r1[y], w1[x], c1, …
Plánovač
r2[y], r1[x] , w2[x], r1[y], w1[x], c1, …
Databáze
Konflikt??
4/20/2015
218
1

2
3
4
5
6
7
Techniky plánování, které agresivně oddalují
testování korektnosti - optimistické plánování
 Každá operace je ihned odeslána DB
 Korektnost se testuje až při potvrzení

Certifikace může být založena na různých
algoritmech – 2PL, TO, PG certifikátory
4/20/2015
219
1

3
4
5
6
7
Když plánovač obdrží operaci z monitoru, tak




2
Uloží operaci a objekt x na kterém byla provedena (vytváří si log)
Zašle operaci databázi, která ji okamžitě spustí
2PL certifikace sice nepoužívá zámky, ale chová se podobně v případě konfliktu
Když plánovač obdrží požadavek na potvrzení transakce, tak

Všechny operace provedené transakcí jsou ověřeny oproti všem konfliktním operacím
provedeným jinou aktivní transakcí na stejných datech
▪
▪
Pokud existuje konfliktní operace, tak je transakce zrušena
Pokud neexistuje konfliktní operace, tak je transakce potvrzena

Když plánovač obdrží ri[x]/wi[x], přidá x do r-plánováno[Ti]/w-plánováno [Ti].
Když plánovač obdrží ci, r-plánováno[Ti] a w-plánováno[Ti] obsahuje množinu
čtených a zapisovaných objektů transakcí Ti

Zpracování ci probíhá tak, že certifikátor ověří pro všechny aktivní Tj, zda-li



4/20/2015
r-plánováno[Ti]  w-plánováno[Tj] = 
w-plánováno[Ti]  r-plánováno[Tj] = 
w- plánováno[Ti]  w-plánováno[Tj] = 
220
1

2
3
4
5
6
7
Protože se neudržuje informace o pořadí prováděných operací, tak
se může stát, že certifikátor abortuje transakce, které by dokonce i
u 2PL úspěšně potvrdily
 r2[x], r1[y], w1[y], w2[y], w2[x], c2, c1

K zajištění zotavitelnosti je potřeba, aby plánovač abortující
transakci Ti abortoval i všechny transakce Tj, které četly data z Ti

ACA a ST by se daly zajistit, ale jen pozdržováním operací, což jde
proti filosofii certifikování

Výkon závisí na počtu konfliktních operací
 Pro malý počet funguje certifikátor stejně dobře, jako základní 2PL
plánovač, i když šetří hypotetické náklady na zamykání
 Pro velký počet konliktních operací dochází přiliš často k abortům –
neefektivní opakování výpočtů
4/20/2015
221
1

2
3
4
5
6
7
Když plánovač obdrží operaci z monitoru, tak
 Si uloží danou operaci a objekt na kterém byla provedena
 Zašle operaci databázi, která ji okamžitě spustí

Když plánovač obdrží požadavek ci na potvrzení transakce, tak jsou
 Všechny operace provedené transakcí Ti zkontrolovány oproti všem
konfliktním operacím provedeným na stejných datech jinou aktivní transakcí
▪ Pokud konfliktní operace poruší pořadí dané časovými razítky, tak transakci zruší
▪ Pokud konfliktní operace dodrží pořadí dané časovými razítky, tak transakci potvrdí

Použité datové struktury jsou stejné, jako u základního TO plánovače

Certifikátor používá stejnou podmínku jako základní TO plánovač, ale
nechává doběhnout transakce, které mají abortovat. Proto je preferován
základní TO plánovač
4/20/2015
222
1

2
3
4
5
6
7
Když plánovač obdrží operaci pi[x] z monitoru, tak
 Přidá hrany odpovídající operaci pi[x] do MPG
 Zašle operaci pi[x] databázi, která ji okamžitě spustí

Když plánovač obdrží požadavek na potvrzení transakce, tak
 Zkontroluje MPG, jestli v něm není potvrzená transakce součástí nějakého
cyklu
▪ Pokud je součástí cyklu, tak je transakce zrušena
▪ Pokud není součástí cyklu, tak je transakce potvrzena

Použité datové struktury jsou stejné, jako u základního PG plánovače

Zůstávají stejné problémy s neefektivním využitím místa, takže je
potřeba stejných opatření, redukujících velikost MPG

K zajištění zotavitelnosti je potřeba, aby plánovač abortující transakci Ti
abortoval i všechny transakce Tj, které četly data z Ti
4/20/2015
223
1
2
3
4
5
6


7







Zamykání objektů
Časová razítka
Certifikace
Multiversion data
TP Monitor
r2[y], r1[x], w2[x], r1[y], w1[x], c1, …
Plánovač
r2[y], r1[x], r1[y], w1[x], c1, w2[x], …
Databáze
4/20/2015
224
1

2
3
4
5
6
7
Dekomponují problém plánování na
 Plánování r[x] oproti w[x] a w[x] oproti r[x] (RW_WR)
 Plánování w[x] oproti w[x] (WW)

Každý problém řeší jinou metodou a pak zkombinují
výsledky (pozor - kombinace musí být korektní!)
 Lze použít 2PL, TO, PG plánovače
 Pure (2PL+2PL, …) vs. mixed integrované plánování

Proč to vlastně komplikovat integrováním?
 Předpokládáme, že kombinace rozšíří množinu historií
4/20/2015
225
1

2
3
4
5
6
Uvažujme TO plánovač, který obdrží wi[x] po wj[x], které již bylo zasláno DB a
přitom ts(Ti) < ts(Tj)


TO plánovač by wi[x] zamítl (operace přišla pozdě)
Pokud ale plánovač řeší WW konfliktní dvojice zvlášť, tak je zamítnutí zbytečné, protože
kdyby wi[x] přišlo před wj[x] jak mělo, bylo by ve výsledku v DB stejně jen wj[x]

Pomocí Thomas Write pravidla (TWR) může WW TO plánovač potichu ignorovat
opožděné zápisy, zatímco pro RW_WR může používat základní TO

Integrovaný plánovač TO/TWR by tedy vypadal takto






7
Plánovač zamítne ri[x] tehdy, když již bylo wj[x] plánováno a ts(Ti) < ts(Tj)
Jinak plánuje ri[x]
Plánovač zamítne wi[x] tehdy, když již bylo rj[x] plánováno a ts(Ti) < ts(Tj)
Plánovač ignoruje wi[x] tehdy, když již bylo wj[x] plánováno a ts(Ti) < ts(Tj)
Jinak plánuje wi[x]
Pozdní zápis je zamítnut pouze tehdy, když již bylo plánováno konfliktní čtení
4/20/2015
226
1

3
4
5
6
7
Použití striktního 2PL pro RW_WR konfliktní dvojice a TWR pro WW konfliktní
dvojice - zde je kombinace již složitější, protože



2
Plánovače garantují acyklický PGrw(H) a PGww(H)
Acyklické ale musí být i jejich sjednocení !!!
Aby byl PG(H) acyklický, tak je potřeba zajistit, aby bylo ts(Ti) < ts(Tj) pro každou
hranu z Ti do Tj v PGrw(H) (to je již dostačující podmínka, protože v PGww(H) to již
platí)



Pokud existuje hrana z Ti do Tj, pak Tj nemůže skončit před Ti, protože Ti drží zámky, které
bude Tj potřebovat
To znamená, že Ti potvrdí před Tj (zrušení neřešíme - nejsou v PG)
Je tedy dostačující, abychom zajistili, že pro každé dvě transakce platí – pokud Ti potvrdí před
Tj pak, ts(Ti) < ts(Tj)

Jednoduché řešení – přiřadit transakcím časová razítka ve chvíli, kdy potvrdí
(namísto jejich startu)

TWR ale potřebuje pro rozhodování časová razítka – plánování zápisů je pak
odloženo až do chvíle potvrzení (problém se čtením vlastních dat – můžou se pak
lokálně číst opožděné zápisy z fronty plánovaných operací write)
4/20/2015
227
1
2
3
4
5
6


7







Zamykání objektů
Časová razítka
Certifikace
Multiversion data
TP Monitor
r2[y], r1[x], w2[x], r1[y], w1[x], c1, …
Plánovač
r2[y], r1[x], r1[y], w1[x], c1, w2[x], …
Databáze
4/20/2015
228
1
2
3
4
5

Doteď jsme uvažovali, že každá operace wi[x] přepíše
hodnotu objektu x v databázi a tímpádem se k původní
hodnotě jiné (dříve) spuštěné transakce již nedostanou

Nový přístup – wi[xi] vytvoří novou verzi xi
6
7
 Řeší problém s operacemi, které dorazí pozdě
 Plánovač navíc nemusí řešit w/w dvojice – přestávají být
konfliktní – nejsou nad stejnou proměnnou

S tím jsou ale spojené nové problémy
 Plánovač musí doplnit operaci čtení o informaci, jakou verzi číst
(od toho by měl být uživatel odstíněn)
 Ukládání všech verzí zvětší velikost databáze …
… ale stejně by se verze ukládaly kvůli zotavení
4/20/2015
229
1
2
3

Pro analýzu korektnosti historií nad MV daty je
potřeba rozšířit teorii uspořádatelnosti

Rozšíření vyžaduje dva nové typy historií
4
5
6
7
 MV historie – reprezentuje výpočet na MV DB
 1V historie – reprezentuje interpretaci MV historie z
„jednoverzového“ pohledu uživatele, MV DB je jen nástroj
pro izolaci, měla by být tudíž skrytá uživateli

Jak tedy chápat korektnost?
 Korektní je určitě sériová 1V historie
 Je tedy potřeba dokázat, že každá produkovaná MV
historie je ekvivalentní nějaké 1V sériové historii
4/20/2015
230
1

2
3
4
5
6
7
MV historie je podobná jednoverzové, až na
 wi[x] nové transakce Ti vždy vytvoří novou verzi značenou wi[xi]
 ri[x] transakce Ti vždy specifikuje, jakou verzi číst, značeno ri[xj]

Kompletní MV historie (CMV) je MV historie, kde
 Každé ri[xj] je předcházeno wj[xj] – čtení existující verze
 Každé ri[x] po wi[xi] je ri[xi] – čtení poslední verze v rámci Ti
 Každá operace ci po ri[xj] je předcházena operací cj – zotavitelnost

Proč se zahrnuje zotavitelnost do CMV historie?
 Potřebujeme, aby Commit projekce C(H) byla CMV, tj. nechceme
čtení nepotvrzených (abortovatelných) verzí dat
 Zotavitelnost to zajišťuje
4/20/2015
231
1
2
3
4
5

Opět nás zajímá taková MV historie, která je „nějak“ ekvivalentní nějaké 1V
sériové historii

Problém – tradiční (a jednoduchá) konfliktová ekvivalence nestačí
6
7
H1 = w1[x1]c1 w2[x2]c2 r3[x1]w3[y3]c3 jiný pohled na konfliktní dvojice pro x a y
H2 = w1[x] c1 w2[x] c2 r3[x] w3[y] c3 z pohledu uživatele totiž verze nejsou



Pouze w1[x1] a r3[x1] tvoří konfliktní dvojici H1 (jiná verze = jiná proměnná!)
Pořadí w1[x] a r3[x] je přitom stejné jako v 1V sériové H2
Ale r3 v H1 čte jinou hodnotu x než r3 v H2 – tj. stejné konfliktní dvojice nestačí

Proto se musí použít pohledová ekvivalence (rozlišuje odkud se čte)

Budou nás zajímat „one copy“ sériové MV historie (1SMV), kde 1SMV je historie,
která je pohledově ekvivalentní nějaké 1V sériové historii

Problém – nelze přímo porovnávat MV a 1V historie
4/20/2015
232
1

2
3
4
5
6
7
Pohledově ekvivalentní MV historie
 Obsahují stejné operace
 Čtou stejné verze dat

U pohledové ekvivalence v 1V historii jsou ještě potřeba
stejné finální zápisy, ale v MV jsou vlastně všechny finální

Specifikováním verze čtených dat v MV historii se redukuje
problém ekvivalence MV historií na triviální požadavek , a to,
že ekvivalentní MV historie mají stejné operace
4/20/2015
233
1

2
3
4
5
6
7
CMV historie je sériová (SMV) když pro každé dvě transakce Ti a Tj platí, buď že
všechny operace Ti předchází všechny operace Tj nebo naopak

Pozor - né všechny MV historie se chovají jako sériové 1V historie!
H1: w1[x1] w1[y1] c1 r2[x1] r2[y1] w2[x2] w2[y2] c2 r3[x1] r3[y2] c3

SMV historie je „one copy“ sériová historie (1SMV) když pro každé i, j a x platí,
když Ti čte x z Tj, pak buď i=j nebo Tj je poslední transakce před Ti která zapsala
verzi x. H1 není 1SMV kvůli r3[x1], a přitom w1[x1] již bylo přepsáno w2[x2]

Intuitivně, 1SMV je ekvivalentní nějaké sériové 1V historii (každá aktivní transakce
pracuje jen s poslední verzí proměnné, což je dost silné omezení)

A teď už stejně jako u 1V uspořádatelnosti – MV historie je „one copy“
uspořádatelná historie (1SR), jestliže je její Commit projekce ekvivalentní nějaké
1SMV historii

Co se stalo s požadavkem “pro libovolný prefix” z VSR ?


4/20/2015
Není potřeba pro MV historie
Vlastnost 1SR již je prefix commit closed
234
1

2
3
4
5
6
7
Konstrukce podobná jako u jednoduchého PG
 Uzly tvoří transakce
 Hrany značí uspořádání konfliktních dvojic
▪ Konfliktní dvojice, které již nevzniknou – wi[xi] < wj[xi] a rj[xi] < wi[xi]
▪ Zůstává tedy pouze jeden typ konfliktní dvojice (wi[xi] < rj[xi])
▪ Tento konflikt popisuje, že Tj čte hodnotu x zapsanou Ti

Čtení stejných dat je ale přesně principem pohledové
ekvivalence – proto pokud Hi = Hj pak MVPG(Hi) =
MVPG(Hj).

Tento graf ale pořád ještě není vhodný pro detekci
1SR, kde chceme, aby rk[x] četlo vždy poslední verzi x
4/20/2015
235
1

2
3
4
5
6
7
Přidají se nové hrany, které tvoří uspořádání mezi verzemi
 Pro všechny páry wi[xi] a rk[xj]
▪ Přidá se hrana z Ti do Tj pokud i < j
▪ Přidá se hrana z Tk do Ti pokud j < i
w1 [x1]
r2 [x2]
r3 [x1]
w2 [x2]

Uvažujme tvorbu tohoto grafu z pohledu 1V historie
 Obě hrany společně garantují, že rk bude číst z wj (jinak cyklus v MVPG)
 První typ hrany brání posunu wi za proběhlou wj
 Druhý typ hrany brání posunu wi před proběhlou rk
w2 [x]

w1 [x]
r2 [x]
w2 [x]
r3 [x]
w2 [x]
MV historie je 1SR právě tehdy, když je její modifikovaný MVPG
acyklický
4/20/2015
236
1
2
3
4
5
6
7
H1: w1[x1] w1[y1] w2[y2] c2 r3[y2] w3[z3] c3 r1[z3] c1
Modifikovaná verze PG
Pro všechny páry wi[xi] a rk[xj]
Přidá se hrana z Ti do Tj pokud i < j
Přidá se hrana z Tk do Ti pokud j < i
T1
T2
T1
T2
y2
z3
y2
z3
T3
4/20/2015
y2
T3
237
1
2
3
4
5
6
7
Modifikovaná verze PG
Pro všechny páry wi[xi] a rk[xj]
Přidá se hrana z Ti do Tj pokud i < j
Přidá se hrana z Tk do Ti pokud j < i
x1, y1
T1
x1 , y 1
T2
x1
y2
T1
x1
x1, y2
T3
4/20/2015
T2
y2
T3
238
1

2
3
4
5
6
7
MV TO Plánovač pracuje následovně
 Každá operace je naplánována okamžitě
 Každé čtení ri[x] je přeloženo na ri[xj] kde j je nejvyšší dostupné časové razítko pro x
které je menší rovno i
 Každý zápis wi[x] je přeložen na wi[xi] kde i je časové razítko transakce
▪ Pokud již proběhlo čtení rj[xk] takové, že ts(Tk) < ts(Ti) < ts(Tj), tak zápis zamítne
▪ Pokud takové čtení neexistuje, tak zápis projde

Jak zjistit časové razítko při ri[x], případně jak detekovat konflikt u wi[x]
 Pro každou verzi xi se udržují časová razítka [wts, rts], wts = ts(Ti) a rts je max ts čtení
 Při ri[x] hledá pro všechna razítka x takové wts, že wts ≤ ts(Ti), aktualizuje rts
 Při wi[x] hledá max wts takové, že wts < ts(Ti) a zjišťuje, jestli rts > ts(Ti)
▪ Pokud podmínka platí, tak odmítne wi[x]
▪ Jinak zašle wi[x] do DB a vytvoří novou dvojici časových razítek wts = rts = ts(Ti)

Pro zotavitelnost – ci je pozdrženo do operace cj pro všechny Tj které
zapsaly verzi čtenou Ti
▪ Verze jsou průběžně promazávány, takže čtení příliš starých dat může být zamítnuto
4/20/2015
239
1
2
3
4
5
6
7

V klasickém 2PL, w[x] brání získání r[x], čemuž se dá vyhnout
udržováním dvou verzí x – 2V 2PL

Když Ti zapisuje do x, tak vytvoří novou verzi xi objektu x a nastaví zámek
bránící jiným Tj ve čtení xi nebo vytvoření nové verze x

Nicméně, jiné transakce Tj mohou číst a pracovat s původní verzí x, její
zápis je pak ale odložen

Jakmile transakce měnící x potvrdí, tak se předchozí dostupná verze x
znepřístupní
4/20/2015
240
1

2
3
4
5
6
7
MV 2PL plánovač pracuje následovně
 Každé čtení vyžaduje zámek na čtení pro čtenou položku
 Každý zápis vyžaduje zámek na zápis pro zapisovanou položku
 Zámek pro zápis brání
▪ Čtení položky, ne však jejich předchozích verzí
▪ Vytvoření nové verze položky

Toto schéma vyžaduje udržování pouze dvou verzí objektu, tzv.
certifikační zámky použité při potvrzení a upravenou tabulku
konfliktních zámků
Chceme

Lehce flexibilnější varianta 2PL plánovače
 Čtení nejen nejaktuálnějších verzí položek
 Které ale může vést na kaskádové aborty
4/20/2015
rl
wl
cl
rl
Ano
Ano
Ne
wl
Ano
Ne
Ne
cl
Ne
Ne
Ne
241
1

2
3
4
5
7
2V 2PL plánovač používá tyto zámky (viz. tabulka na předchozím slajdu)



Zámek na čtení, který koliduje s certifikačním zámkem (ale ne se zámkem na čtení a zápis)
Zámek na zápis který koliduje se zámky pro zápis a cerifikaci (ale ne se zámkem pro čtení)
Certifikační zámek který koliduje se všemi zámky

Když dorazí požadavek na zápis wi[x], tak se plánovač pokusí nastavit wli[x].
Jakmile je tento zámek nastaven, tak je zápis upraven na wi[xi] a plánován

Když dorazí požadavek na čtení ri[x], tak se plánovač pokusí nastavit rli[x].
Jakmile je zámek nastaven, tak



6
Pokud Ti již vlastní wli[x], tak je čtení upraveno na ri[xi] a plánováno
Jinak je čtení upraveno na ri[xj], kde xj je poslední potvrzená verze x, a pak plánováno
Pokud dorazí požadavek na potvrzení ci, tak se plánovač pokusí změnit všechny
zámky na zápis wli[x] na certifikační zámky cli[x]. To způsobí, že plánovač pozdrží
potvrzení do doby, dokud nejsou uvolněny všechny zámky pro čtení dat, které se
Ti chystá přepsat
4/20/2015
242
1

2
3
4
5
6
7
Co ještě dodat k 2V2PL?
 Konverze zámků může vést k uváznutí
 Čtena pouze potvrzená data, tj. 2V2PL zabraňuje
kaskádovým abortům

Může být dále zobecněno
 Odebrání zámků pro zápis umožňuje více verzí
 Certifikace musí čekat ještě na verze čtení, aby byla sama
certifikovaná

Podtrženo, sečteno – MV data dávají plánovači větší
možnosti při plánování čtení. Pokud je předem
známo, že transakce pouze čte, dá se toho využít
4/20/2015
243
1
2
3
4
5
6

Rozděluje transakce na read only dotazy ROQ a read
write aktualizace RWU a plánuje je zvlášť – vede na
lepší prokládání operací

Používá MV TO pro ROQ a striktní 2PL pro RWU
7
 Všechny RWU používají striktní 2PL a při potvrzení jim je
přiřazeno časové razítko, každý zápis vytvoří novou verzi
 Všem ROQ je přiřazeno časové razítko starší než razítko
kteréhokoliv aktivního RWU. Všechna čtení ROQ používají
verzi s nejbližším starším časovým razítkem

Důsledek, ROQ čtou pouze potvrzená data a navíc
čtená data nemusí zamykat (nebrzdí tak RWU)
4/20/2015
244
1
2
3
4
5
6

Udržovat časová razítka přiřazená při potvrzení může být
nákladné (časové razítko pro w[x] je dostupné až při
potvrzení, takže je potřeba měněné objekty při potvrzení
znovu načíst, označit časovým razítkem a zase zapsat)

Namísto toho se používá tzv. Commit list
7
 Seznam identifikátorů potvrzených transakcí
 Každý ROQ je přiřazen ke Commit listu všech RWU které
potvrdily v čase kdy ROQ začal
 Čtení v ROQ používají nejaktuálnější verze potvrzené nějakým
RWU z komit listu

Commit list musí být uložen velmi efektivně a musí být
ořezáván od příliš starých položek
4/20/2015
245
4/20/2015
246
1

2
3
4
5
6
7
Některým chybám lze těžko zabránit
 Chyba v kódu – porušení konzistence – lepší metodika návrhu a
validace SW
 Chyba operátora/technika – školení, zálohování
 Přírodní katastrofa, atd.

Techniky zotavení alespoň řeší důsledky těchto chyb a
následné navrácení DB do konzistentního stavu

Kde může dojít k chybě/selhání systému




4/20/2015
Transakce – (abort, uváznutí, …) DB v nekonzistentním stavu
Systém – (pád systému, …) ztráta informací z dočasné paměti
Úložiště – (proud, selže pevný disk, …) ztráta trvalé paměti
Síť – (spojení, …) týká se distribuovaných systémů
247
1

Závisí na způsobu ukládání změn do DB

Přepisování původních dat v DB (in-place)
2
3
4
5
6
7
 Informace o změnách pak uchovány v logu
 Využívá se buffer (jak data tak log)

Vytváření „nových“ verzí dat (out-of-place)
 Shadowing – dvě verze diskových stránek pro novou a původní
verzi záznamu (systém R)
 Differential files
▪ DB je readonly, udržují se k ní dva soubory s novými I a smazanými D
záznamy (update = delete + insert)
▪ Skutečný stav DB je pohled (DB + I) – D
▪ I a D jsou periodicky promítány do DB
4/20/2015
248
1

2
3
4
5
6
7
TP manažer je komponenta TP monitoru, která má na starosti
 Řízení potvrzení a zrušení transakce
 Zotavení úložiště
 Restart manažera zdrojů a systémový restart

Definuje dvě základní rozhraní - pro aplikace a pro manažera
zdrojů

Koncepty transakčního manažera
 DO-UNDO-REDO protokol
 Různé modality logování
 FIX, WAL, Force-log-at-commit

Využívá služby log manažera
4/20/2015
249
1

Aplikační rozhraní definuje
obvykle následující funkce, které
používají aplikace a které mají
jasnou sémantiku:

 begin_work, commit_work,




4/20/2015
abort_work (normální primitiva
pro zahájení a ukončení transakce)
save_work, rollback_work,
chain_work (speciální primitiva pro
zahájení a ukončení transakce),
prepare_work (pro dvoufázový
commit)
read_context,
get_transaction_status, my_trid
(získávání stavových informací),
leave_transaction,
resume_transaction (pro
suspendování a probuzení
transakce)
2
3
4
5
6
7
Rozhraní manažera zdrojů je
rozhraní, které vyžaduje (ve
formě pointrů na callback
funkce) transakční manažer po
manažerech zdrojů zapojených
do transakce:
 prepare, commit, abort,
 savepoint(LSN),
undo_savepoint(LSN),
redo_savepoint(LSN),
 undo, redo,
 TM_startup,
 Checkpoint

LSN je tzv. log sequence
number, tj., jednoznačný
identifikátor záznamu v logu
250
1
2
3
4
5
6
7

DO – operace provádí něco s objektem a
zaznamenává to do logu

UNDO – změněný objekt je možné vrátit pomocí
logu do podoby před provedením DO

REDO – původní objekt je možné vrátit pomocí
logu do podoby po provedení DO
 Někdy může být problém, např. Resend, Posuň o x°
 Idempotence – f(f(x)) = f(x), např. Posuň na [x, y]
 Je možné též testovat, zda-li již byla akce provedena
4/20/2015
251
1

2
3
4
5
6
7
Fyzický log
 Zaznamenává informaci o staré a nové hodnotě jednoho záznamu
 Nevýhodou je velikost logu – všechny změny objektů, indexů, atp…

Logický log
 Orientace na operace, tj., co a s jakými parametry bylo provedeno
 Jeden záznam v logu pokryje spousty záznamů ve fyzickém logu

Fyzicko-logický log
 Transakce se rozdělí na mini transakce, kde každá mini transakce
používá fyzické logy a exkluzivní zámky
 Celá transakce pak používá logický log
4/20/2015
252
1

2
3
4
5
6
7
Další obecné zásady pro práci s logem
 FIX (fixing the page) – čtení a zápisy na fyzické
úrovni musí být vždy pokryty semaforem na
úrovni stránky, dokud není vše zapsáno v logu
 WAL (write ahead logging) – do logu by se mělo
zapsat vždy dříve, než se provede a uloží samotná
změna objektu do perzistentní paměti
 Force-log-at-commit – při commitu je log vždy
uložen do perzistentní paměti
4/20/2015
253
1
2
3
4
5
6

Log manažer se stará o zaznamenávání všech
provedených operací do logu

Funkce logu proto musí být velice rychlé (hodně
prováděných operací) a musí podporovat konkurentní
zpracování požadavků

Jaké operace umožní log? Informace z logu potřebné pro
7
 Rollback transakce – rekonstrukce původních hodnot
 Commit/Undo/Redo při restartu po havárii systému

A proč to teda bez nějaké formy logu nejde? Z důvodu
optimalizace systémů se často využívají různé typy
bufferů, které uchovávají data dočasně pouze v RAM
4/20/2015
254
1

2
3
4
5
6
7
Datové záznamy jsou na HDD obvykle organizovány ve
stránkách o pevné velikosti
 Disk využívá „pomalé“ čtecí hlavy a rotační plotny
 Nejdražší operací je přesun hlavy na určitou pozici (seek)
 Data je potřeba přizpůsobit tomuto mechanismu (alespoň do
doby, dokud nebudou použitelné SSD disky s rychlým seekem)

U HDD je sekvenční přístup velice efektivní
 Stránky představují sekvenční bloky (načíst sekvenčně 1 nebo
1000 malých záznamů trvá téměř stejně dlouho)
 Stránky přitom mají rozumnou velikost, tj., pro skupinu
požadovaných záznamů se nečte do RAM velká část DB
 Pokud jsou navíc data organizována tak, že žádaná data jsou u
sebe v jedné stránce (tvoří shluky), pak „není co řešit“
4/20/2015
255
1

Učebnicový příklad pro nutnost logování operací v SŘBD

Buffer je kus hlavní paměti pro dočasné uchování diskových
stránek, diskové stránky se mapují do rámců v paměti 1:1

3
4
5
6
7
Manažer dat
Každý rámec má 2 příznaky



2
pin_count - počet referencí na stránku v rámci
dirty - příznaky modifikace záznamů
Slouží k urychlení opakovaného přístupu ke stránkám správce bufferu implementuje operace read, write a řeší
výpadky stránek
RAM

Červená buňka v obrázku představuje rámec obsahující
záznam, který byl upraven, ale ještě nebyl zapsán na pevný
disk

Co když jsou po potvrzení ACID transakce v bufferu „červené
buňky“ a TP systém havaruje? Navíc může systém používat i
jiné buffery – např. buffer pro odesílané zprávy.
Pevný disk

Proto je potřeba tzv. transakční log
Aktuální stav DB
4/20/2015
256
1
2
3
4
5
6
7

Datové položky se nezapisují přímo na disk (viz.
operace write) a záznamy logu se nezapisují okamžitě
do stabilní paměti

Nicméně, je potřeba dodržovat určité zásady práce
 Transakce Ti se dostává do stavu potvrzení teprve až po
uložení záznamu <Ti, commit > do stabilní paměti
 Před záznamem <Ti, commit > musí být do stabilní paměti
uloženy všechny záznamy žurnálu týkající se transakce Ti
(aby bylo možné garantovat zotavitelnost)
 Před uložením bloku dat do databáze musí být uloženy
všechny záznamy žurnálu, týkající se daného bloku (tzv.
pravidlo WAL (write-ahead logging))
4/20/2015
257
1
2
3
4
5
6
7

Typ vztahu manažera zotavení a buffer manažera má
vliv na implementaci a složitost zotavení

Může buffer manažer zapisovat stránky na disk v
průběhu zpracování transakce (no-FIX/steal) nebo
čeká na příkaz od manažera zotavení (FIX/no-steal)?

Bude se zapisovat na disk až s potvrzením (noflush/no-force) nebo i v průběhu zpracování transakce
(flush/force)?

Jsou možné všechny kombinace
4/20/2015
258
1
2
3
4
5
6

Znám jako redo/undo algoritmus z Bernsteina

Potvrzení transakce – zapíše se do logu pouze
informace o potvrzení, zašle plánovači zprávu o
potvrzení

Zrušení transakce - buffer manažer mohl zapisovat
kdykoliv, je potřeba dělat UNDO transakce, nakonec
zašle plánovači zprávu o úspěšném zrušení transakce

Zotavení – částečné REDO a globální UNDO od
začátku logu
4/20/2015
7
259
1
2
3
4
5
6
7

Znám jako undo/no-redo algoritmus z Bernsteina

Potvrzení transakce – buffer manažer dostane příkaz
zapsat všechny změněné stránky na disk, zapíše se do
logu informace o potvrzení, zašle plánovači zprávu o
potvrzení

Zrušení transakce - buffer manažer mohl zapisovat
kdykoliv, je potřeba dělat UNDO transakce, nakonec
zašle plánovači zprávu o úspěšném zrušení transakce

Zotavení – pouze globální UNDO
4/20/2015
260
1
2
3
4
5
6
7

Znám jako redo/no-undo algoritmus z Bernsteina

Buffer manažer nepoužívá příkaz fetch ale příkaz fix

Potvrzení transakce – zapíše se do logu pouze informace o
potvrzení a odemknou se používané stránky příkazem
unfix, zašle plánovači zprávu o potvrzení

Zrušení transakce – je potřeba pouze odemknout
používané stránky příkazem unfix, zapíše se do logu
informace o zrušení transakce, zašle plánovači zprávu o
úspěšném zrušení transakce

Zotavení – pouze částečné REDO
4/20/2015
261
1
2
3
4
5
6

Znám jako no-undo/no-redo algoritmus z Bernsteina

Buffer manažer nepoužívá příkaz fetch ale příkaz fix

Potvrzení transakce – odemknou se používané stránky příkazem
unfix a buffer manažer dostane příkaz zapsat všechny změněné
stránky na disk, zapíše se do logu informace o potvrzení a zašle
plánovači zprávu o potvrzení. Je potřeba provést atomicky!

Zrušení transakce – je potřeba pouze odemknout používané
stránky příkazem unfix, zapíše se do logu informace o zrušení
transakce, zašle plánovači zprávu o úspěšném zrušení transakce

Zotavení – není třeba dělat nic
4/20/2015
7
262
1

3
4
5
6
7
Log by mohl být i SQL tabulka, operace nad logem jsou však specifické





2
Log je hodně velký, navíc neustále roste (stará data mohou být „offline“)
Drtivá většina operací je zápis na konec logu (ale po stránkách)
Občas potřeba číst, ale jen konec logu (fáze zotavení)
Log může být lokální nebo distribuovaný
Logovací tabulky
 Dávkové transakce mívají více úrovní logů – hlavní log není zbytečně blokován
 Samotný log je často sekvenční soubor, ke kterému existuje katalog v SQL

Proč je potřeba log manažer?
 Netriviální logika při nabíhání systému
 Bezpečné protokoly zápisu dat – např. duplikace záznamů
 Session-based komunikace (hlavičky při přihlášení k logu a pak už jen zprávy –
efektivita)
4/20/2015
263
1

2
3
4
5
6
7
K logu nelze přistupovat libovolně – práva k objektům musí platit i
pro záznamy v logu
 Komunikace i se security manažerem
 Potřeba speciální log authority – prevence před neustálým dotazováním
security manažera

Dva různé přístupy k rozhraní
 Record-at-time – přímý přístup k souboru, čtení jen hlavičky nebo části
potenciálně velkého záznamu
 Set-oriented – obdoba SQL dotazů

Další zásady
 Neexistuje přímý přístup do logu
 Nelze inkrementálně zapisovat jeden velký záznam (problém s
restartem)
 Minimalizace datových přesunů mezi komponentami
4/20/2015
264
1
2
3
4
5
6

Log není měněn, tj. stačí hlídat (zamykat) jen zápis dat na konec
logu

Opatrný zápis – pokud se ukládá neúplná stránka do logu,
přepisuje předchozí verzi této stránky a dojde k pádu systému –
pak je poslední stránka nekonzistentní
7
 Dvojitý zápis na dvě stránky za sebou, vyplatí se zapisovat rovnou celé
stránky
 Ping-pong – střídání zápisu na i a i+1 stránku, při zotavení se přečtou
poslední dvě stránky a podle časového razítka se pozná, která je
novější a tudíž platná

Pokud je potřeba minimální latence zápisu do logu, tak se dá
problém řešit i speciálním driverem a algoritmem write-ahead
data set (WADS) = dedikovaný cilindr jen pro zápisy do logu, jak se
zaplní, tak se přesune do skutečného logu
4/20/2015
265
1

3
4
5
6
7
Zjednodušeně je log posloupnost všech modifikací databáze
zaznamenaných ve formě (bez společných polí)






2
<Ti, start> Ti zahájila provádění
<Ti, update, H=(PageId, Length, Offset), Hold, Hnew> Ti zapsala položku H
<Ti, commit> Ti potvrdila změny
<Ti, abort> Ti byla zrušena
<Ti, undo, H=(PageId, Length, Offset), Hnew, Hold> Ti vrátila položku H
Různé strategie zápisu do logu a DB




4/20/2015
Odložená modifikace DB
Okamžitá modifikace DB
Kontrolní body
Správa vyrovnávací paměti
266
1
2
3
4
5
6
7

Modifikace jdou pouze do žurnálu, zápis do DB až s potvrzením

Výhoda – zotavení pak používá pouze funkci REDO
Ti
Operace
Log
Databáze
T0:
Read(x, @x)
<T0, start>
x = 100, y = 200
Zotavení
@x = @x*1,1
Write(x, @x)
<T0, x, 100, 110>
Read(y, @y)
@y = @y*1,1
Write(y, @y)
T1:
4/20/2015
Read(x, @x)
<T0, x, 200, 220>
<T0, commit> = write
x = 110, y = 220
<T1, start>
x = 110, y = 220
Redo(T0)
@x = @x - 20
Redo(T0)
…
…
267
1

Nepotvrzené modifikace jdou rovnou i do DB

Zotavení pak používá funkci REDO i UNDO
Ti
Operace
Log
Databáze
Zotavení
T0:
Read(x, @x)
<T0, start>
x = 100, y = 200
Undo(T0)
@x = @x*1,1
Write(x, @x)
T1:
4/20/2015
<T0, x, 100, 110>
x = 110, y = 200
4
5
6
7
Undo(T0)
Undo(T0)
@y = @y*1,1
Undo(T0)
Read(x, @x)
3
Undo(T0)
Read(y, @y)
Write(y, @y)
2
<T0, x, 200, 220>
Undo(T0)
<T0, commit>
x = 110, y = 220
Redo(T0) Undo(T1)
<T1, start>
x = 110, y = 220
Redo(T0) Undo(T1)
@x = @x - 20
Redo(T0) Undo(T1)
…
…
268
1
2
3
4

Kontrolní bod (checkpoint) je technika periodického ukládání obsahu
vyrovnávacích pamětí na disk

Vede ke snížení režie zotavení po výpadku a řídí se následujícím postupem
5
6
7

Uloží se všech záznamy logu z hlavní paměti (ano i ten může mít buffer)
 Uloží se všechny modifikované bloky DB z vyrovnávací paměti na disk
 Uložení záznamu <checkpoint, T1, T2, ... > na disk

Zotavení pak probíhá následovně

Nalezne se množina transakcí T, které probíhaly nebo byly zahájeny po posledním
kontrolním bodu
 Aplikuje se zotavovací procedury redo(Ti) a undo(Ti) na každou transakci Ti z T podle
použité techniky
4/20/2015
T1
T2
redo
redo
T3
undo
269
1

2
3
4
5
6
7
TP manažer zajišťuje restart v případu pádu systému
 Hotstart – restart za chodu systému
 Warmstart – start za použití perzistentní paměti
 Coldstart – start z archivu

Zopakujme důvody pro restart
 Pád systému – je ztracen obsah RAM, perzistentní paměť je
zachována – tj. je možné provést REDO a UNDO na příslušné
transakce
 Poškození média – je potřeba duplikovat data (RAIDy)
 Abort transakce – např. v případě uváznutí – UNDO a restart transakce

Předpokládáme okamžitou modifikaci DB, ke všem operacím
existuje UNDO operace
4/20/2015
270
1

3
4
5
6
7
Stavy transakce vzhledem k 2PC





2
Completed – po druhé fázi 2PC protokolu, každý RM je už o potvrzení informován
Completing – po první fázi 2PC protokolu, někteří RM ještě nedostali potvrzení o finálním
potvrzení (tedy uprostřed druhé fáze)
Persistent – v první fázi 2PC nebo v persistentním savepointu (nelze provést potvrzení ani abort)
Active – uprostřed práce (pak dělá i UNDO)
Stavy transakce podle toho, kdy začaly a kdy skončily





4/20/2015
Transakce začala i skončila před posledním checkpointem – není co řešit…
T1 - transakce začala před posledním checkpointem, ale skončila dříve, než nastal pád systému.
Zde je potřeba provést znovu ztracené operace mezi checkpointem a potvrzením
T2 - transakce začala po posledním checkpointu, ale skončila dříve, než nastal pád systému. Zde
je potřeba provést znovu operace mezi checkpointem a potvrzením
T3 - transakce začala po posledním checkpointu a byla aktivní v době pádu systému. Je potřeba
provést UNDO
T4 - transakce začala před posledním checkpointem a byla aktivní v době pádu systému – je
T4
potřeba provést UNDO
T1
T2
redo
redo
T3
undo
undo
271
1
2
3
4
5
6
7

Low-water-mark je identifikátor záznamu logu, odkud se musí provést REDO

Manažer zotavení používá dva seznamy: UNDO list, který iniciálně obsahuje
všechny aktivní transakce v době posledního checkpointu (jejich seznam je
uložen v logu), a REDO list, který je na počátku prázdný

Prohledává se od low-water mark po konec logu. Pokud se najde BEGIN WORK
nějaké transakce, přidá se tato transakce do UNDO seznamu. Když se najde
COMMIT WORK nějaké transakce z UNDO seznamu, tak se tato transakce
přesune z UNDO seznamu do REDO seznamu. Tímto prvním "REDO" čtením se
dostane transakční manažer do stavu, ve kterém se nacházel v okamžiku pádu
systému

Pak se prohledává zpátky od konce logu po low-water mark a provádí se UNDO
transakcí z UNDO seznamu

Nakonec se prochází znovu od low-water mark po konec logu a provede se REDO
všech transakcí z REDO seznamu
4/20/2015
272
1

2
3
4
5
6
7
Algoritmus navržen pro přístup no-fix/no-flush
 Fix/flush je sice triviální, ale má špatnou propustnost
 No-flush se týká jen db stránek, ne logu!

Využívá mnoho optimalizací pro větší efektivitu

Zotavení probíhá ve třech fázích
 Analýza – zjišťování „dirty pages“ a aktivních transakcí v době pádu
 REDO – zopakování všech akcí od posledního checkpointu
 UNDO – zrušení akcí transakcí které nestihly potvrdit

Hlavní principy ARIES
 WAL a opakování historie (REDO)
 Logování změn během UNDO (neopakování undo operací během
opakovaného pádu systému)
4/20/2015
273
1

2
3
4
5
6
7
Log sequence number (LSN) – id záznamu
 Rostoucí posloupnost, index do souboru (pro ARIES)
 Každá stránka v DB obsahuje LSN log záznamu nejnovější
operace s danou stránkou (pageLSN)

Log záznam je vytvořen pro operace – update,
commit, abort, end, undoing update

Každý záznam v logu má následující položky
 prevLSN – předchozí záznam transakce
 transID – id transakce
 Typ operace
4/20/2015
274
1

2
3
4
5
6
7
Kompenzační záznam (CLR)
 Zapsán do logu předtím, než je provedena operace UNDO
záznamu ZId
 Obsahuje undoNextLSN (=prevLSN ZId), které
představuje Id následujícího záznamu, pro které se bude
volat UNDO

Popisuje akci, na které nebude nikdy voláno UNDO
(neodvolatelnost abortu)
 Důsledek – je znám max počet CLR záznamů

Opět princip WAL, je možné volat REDO na CLR při
pádu během zotavení
4/20/2015
275
1

2
3
4
5
6
7
Tabulka transakcí
 Jeden řádek jedna aktivní transakce
 Obsahuje mimo jiné TId, status, lastLSN

Tabulka „dirty pages“
 Jeden řádek jedna dirty page v bufferu (všechny
změněné stránky nezapsané zatím na disk)
 Obsahuje recLSN – první záznam v logu, který
způsobil příznak dirty (první záznam pro REDO)

V případě pádu systému jsou tabulky obnoveny
během první fáze analýzy
4/20/2015
276
1

2
3
4
5
6
7
Skládá se ze tří kroků
 Begin_checkpoint je zapsán do logu
 End_checkpoint je vytvořen (obsahuje tabulky transakcí a dirty
pages) a zapsán do logu
 Master record z LSN Begin_checkpointu je zapsán na určené
místo na disku

Všechny transakce běží vesele dál, jediné co je
garantováno jsou uložené tabulky odpovídající časově
LSN Begin_checkpointu

Stránky z bufferu nejsou přesunuty na disk

Efektivita této techniky závisí na hodnotě nejstarší recLSN
4/20/2015
277
1

2
3
4
5
6
7
Fáze analýzy
 Detekuje odkud se začne provádět REDO
 Zjistí tabulky transakcí a dirty pages a aktualizuje je o záznamy
mezi begin a end checkpointem

REDO
 Opakuje všechny změny z logu pro stránky, které jsou v tabulce
dirty pages (začne od nejstaršího recLSN)
 Postupuje od nejstaršího záznamu po nejnovější

UNDO
 Zruší efekt transakcí, které nepotvrdily
 Postupuje od nejnovějšího záznamu po nejstarší
 Pro každou UNDO operaci zapíše kompenzační záznam do logu
4/20/2015
278
4/20/2015
279
1

2
3
4
5
6
7
Výhody
 Rozložení zátěže/dat na více výpočetních uzlů
 Navíc možnost efektivní replikace dat
▪ Robustní chování v případě výpadku části systému
▪ Efektivnější výpočty

Nevýhody
 Pomalejší komunikace, různá rozhraní
 Heterogenní systémy, synchronizace uzlů
 Komunikační linky – další místo, kde se může něco pokazit,
těžko detekovatelné (techniky s timeout)

Transakce ale musí být ACID pořád, nezávisle na
fragmentaci a replikaci dat!
4/20/2015
280
1

2
3
4
5
6
7
Synchronní replikace
 Před potvrzením musí být aktualizovány všechny kopie, velká režije na
zámky + komunikace
 Hlasování – většina kopií musí být přepsána (potřeba čtení většiny
kopií x při R(x))
 Read-any write-all – pokud je čtení hodně časté (zámky na všechny
kopie x u W(x))

Asynchronní replikace
 Kopie nemusí být aktualizovány všechny – různé kopie v době čtení
(snížení konzistence)
 Primární/sekundární kopie – pouze primární kopii je možné měnit
 Peer-to-peer replikace – je možné měnit přímo více kopií, je potřeba
řešit konflikty
4/20/2015
281
1
2
3
4
5
6

Budeme uvažovat S2PL, které kopie objektů
zamykat závisí na typu replikace

Zámky v distribuovaném prostředí
7
 Centralizované – všechny objekty jsou zamykány
na jednom místě
 Primární kopie – zamyká se jen primární kopie
záznamu (každá může být ale jinde)
 Plně distribuované – řeší manažer zámků na
serveru, kde je uložena požadovaná kopie
4/20/2015
282
1
2
3
4
5

Uvažujeme detekci a zotavení z uváznutí

Lokální waits-for graf na každém uzlu nezachycuje globální závislosti

Příklad
6
7
 T1 na uzlu A, T2 na uzlu B, read-any write-all
 T1 = {r(x), w(y)} a T2 = {r(y), w(x)}, x, y na A i B
 rl1[x]A r1[x]A rl2[y]B r2[y]B wl1[y]A wl1[y]B wl2[x]B wl2[x]A

Pomalá komunikace může vést k tzv. fantom deadlock – transakce T1 je
zrušena, ale ještě nestihne uvolnit zámky – může dojít ke zrušení T2

Existuje několik algoritmů pro detekci uváznutí v distribuovaném
prostředí (neřeší ale fantom deadlock)
4/20/2015
283
1

2
3
4
5
6
7
Centralizované zpracování lokálních waits-for grafů
 Globální graf vytvořen sjednocením lokálních grafů

Kontrola jestli transakce čeká déle než zvolený time-out
 Jednoduché řešení, někdy jediné možné pro případy, kdy nelze získat
waits-for graf od některých zúčastněných uzlů

Hierarchie uzlů (např. kraje, okresy, obce)
 Pozorování - uváznutí je běžnější u souvisejících dat
 Každý uzel udržuje waits-for graf pro svůj podstrom
 Periodicky posílají grafy rodičům – frekvence závisí na pozici v
hierarchii (čím níž, tím častěji), jednou za čas se vše sjednotí v kořenu
4/20/2015
284
1
2
3
4
5

Transakce může využívat více manažerů zdrojů na více strojích

Co je na tom těžkého?
6
7
 Co když některý z manažerů spadne, zatímco transakce potvrdí na
jiném stroji?
 Co když probíhá zotavení a některé zúčastněné stroje/manažeři
nejsou dostupné?
 Co když transakce nepozná, jestli manažer zdrojů spadl nebo jen
pokračuje v práci?

Předpokládáme
 Každý manažer zdrojů nezávisle potvrdí/abortuje atomicky na
vlastních datech
 Koordinátor transakce rozhodne, kdy bude transakce potvrzovat
 Koordinátor nepovolí potvrzení, dokud transakce neskončí na všech
zúčastněných uzlech
4/20/2015
285
1
2
3

Vycházíme z předpokladu, že transakce T
pracovala s daty manažerů zdrojů R1, …, Rn

Cílem je pak
4
5
6
7
 Potvrdit transakci T na všech R1, …, Rn uzlech
 Nebo abortovat T na všech R1, …, Rn uzlech
 I v případě, že manažeři zdrojů, uzly a komunikační
kanály havarují během potvrzení/zrušení

Nemůže nastat potvrzení na Ri a zrušení na Rk
4/20/2015
286
1
2
3
4
5

Standardní protokol pro zajištění atomicity
potvrzení/zrušení v distribuovaném prostředí

Zúčastněné role
6
7
 Koordinátor – komponenta řídící potvrzení
 Účastník – manažer zdrojů volaný transakcí, je
připraven potvrdit ve chvíli, kdy má všechna změněná
data na stabilním médiu

Koordinátor nesmí potvrdit transakci, dokud
nejsou všichni účastníci připraveni
4/20/2015
287
1
2
3
4
5

Potvrzení je možné provést až po hlasování, že s ním všichni
zainteresovaní účastníci souhlasí

Potvrzení řídí centrální transakční manažer

První fáze – zpráva PREPARE (každý RM odpoví jestli potvrdí)

Druhá fáze – zpráva ABORT nebo COMMIT
6
7
připraven?
x, y
commit (x = y = ANO)
abort (x = NE or y = NE)
4/20/2015
288
1

Koordinátor zašle zprávu request-to-prepare všem účastníkům

Koordinátor čeká jak všichni účastnící odpoví

Každý účastník může



2
3
4
5
7
Odpovědět připraven, když je připraven potvrdit
Odpovědět nelze potvrdit (z libovolného důvodu)
Pozdržet odpověď jak dlouho chce

Pokud koordinátor obdrží zprávu připraven od všech, rozhone pro potvrzení transakce.
Jinak ji abortuje.

Koordinátor rozešle info o rozhodnutí všem účastníkům

Účastníci potvrdí příjem
4/20/2015
6
připraven?
x, y
289
1
2
3
4
5
6
7

Když jde vše dobře (pouze potvrzení), tak 2PC potřebuje 3
volání na rozhodnutí

Poslední potvrzení je jen pro úplnost logování
 Neovlivní dobu odezvy, navíc mohou být odesílány dávkově

Účastník, který hlasuje připraven se ocitá na chvíli v
nejistotě
 Odkryl karty a neví co ostatní
 Musí čekat na koordinátora
 Pokud spadne nebo je odpojen,
tak se později musí při zotavení
dozvědět výsledek
4/20/2015
připraven?
ANO
???
290
1

2
3
4
5
6
7
Co když koordinátor nebo účastník neobdrží zprávu (timeout)
 Když účastník neobdrží request-to-prepare, tak abortuje
 Když koordinátor neobdrží zprávu od účastníka, tak také abortuje
 Když účastník odeslal připraven a nedočkal se potvrzení od
koordinátora
▪ Je blokován, použije terminační protokol, aby rozhodl co dál. Naivní protokol –
zůstat blokovaný až do chvíle, kdy se koordinátor zotaví.
 Koordinátor se nedočká potvrzení příjmu
▪ Připomene účastníkům že mají poslat potvrzení příjmu, může čekat dlouho

Kdy je možné konečně opustit transakci?
 Účastník ve chvíli, kdy se dozví výsledek hlasování
 Jakmile koordinátor obdrží potvrzení příjmu ode všech
 Účastník nesmí potvrdit příjem dokud nemá vše zalogované (jinak by
koordinátor již nemusel vědět výsledek hlasování)
4/20/2015
291
1
2
3
4
5
6
7

Koordinátor není nikdy blokován – může sám rozhodnout o zrušení transakce

Účastník odešle zprávu že je připraven potvrdit, během čekání na výsledek je
blokován – neví, jestli má potvrdit nebo zrušit podtransakci, přitom drží zámky

Teorém 1 – každý potvrzovací protokol (nejen 2PC) může být blokován z důvodu
chyby v komunikační vrstvě (má řešit chyby, přitom může být chybou blokován!)

Teorém 2 – žádný potvrzovací protokol nemůže zaručit nezávislé zotavení
účastníků u kterých došlo k chybě (koordinátor může být zrovna mimo provoz)

Existuje několik přístupů, které se snaží
vypořádat s důsledky předchozích teorémů



4/20/2015
Odhadnout výsledek (nějak skončit a alespoň uvolnit zámky)
Kooperativní terminační protokol (zjistit od ostatních účastníků)
3PC protokol (brání blokování, ale komunikace musí být 100%)
připraven?
ANO
???
292
1

2
3
4
5
6
7
Logování může být okamžité (synchronní) – uloženo na disk
před dalším odesláním zprávy, nebo líné (asynchronní)
Koordinátor
Log Start2PC
(+ seznam Ui)
Účastníci Ui
připraven?
x, y
Log commit
Log prepared
Log commited
Log done
4/20/2015
293
1

Optimalizace pro případy, kdy je jen jeden účastník

Stačí pouze tři kola pro komunikaci
1.
2.
3.
2
3
4
5
6
7
Koordinátor odešle připrav se a přeber koordinaci
Účastník se připraví, potvrdí a vrátí zprávu o potvrzení
Původní koordinátor potvrdí a odešle done

Účastník si musí pamatovat že potvrdil dokud nepřijde zpráva
done (u 2. se může zpráva ztratit)

Dá se použít pro implementaci 2PC do systému, kde právě jeden z
účastníků nepodporuje fázi prepare
1.
2.
3.
4/20/2015
Tradiční hlasování zbývajících účastníků
Delegování koordinace na účastníka nepodporujícího prepare
Jakmile skončí, tak na základě výsledku poslat rozhodnutí
294
1
2
3
4
5

Někteří účastníci si mohou vzájemně držet
data v bufferech

Fáze nula je pro seznam těchto účastníků
6
7
 Koordinátor jim pošle zprávu
 Daní účastnící provedou flush bufferu a dokončí
všechny operace potřebné pro první fázi u 2PC
 Pokud některý z účastníků neodpoví, je transakce
zrušena, jinak přejde do první fáze 2PC
4/20/2015
295
1
2
3
4
5
6
7

2PC startuje v době, kdy ještě nejsou všechny
podtransakce hotové (např. trigger na závěr)

Účastník A odeslal prepared, účastník B ne a
modifikuje data uložená v A (reinfikuje A)

Pokud by B odeslal prepared, mohl by koordinátor
potvrdit transakci před dokončením operací na
reinfikovaném uzlu A

Proto musí A před navrácením výsledku B nejdříve vše
dokončit, uložit data a znovu poslat prepared
4/20/2015
296
1

2
3
4
5
6
7
Pokud účastník pouze čte data, tak není třeba
 Držet zámky pro čtení pro všechny fáze 2PC
 Čekat na výsledek hlasování (stačí jen první fáze)

Uvolní zámky s request-to-prepare

Odpoví prepared-read-only čímž oznámí
koordinátorovi, že danému účastníkovi nemusí
zasílat výsledek hlasování

Obtížné implementovat – problémy spojené s
reinfection – možné porušení 2PL
4/20/2015
297
1
2
3

Koordinátor neloguje start 2PC – při zotavení pak odpovídá
účastníkům commit (našel log commit) nebo abort

Předpokládá abort T když nenajde v logu informaci o T

Předpoklad implikuje
4
5
6
7
 Pokud nejsou informace v logu, tak je transakce určitě zrušena
 Pokud je transakce zrušena, tak účastníkovi stačí asynchronně zapsat
abort záznam do logu a neposílá done koordinátorovi
 Pokud je transakce zrušena, nemusí koordinátor zapsat done záznam

Populární optimalizace používaná ve většině implementací 2PC

V [Ramakrishnan, Gehrke] jsou součástí i read-only transakce
4/20/2015
298
1
2
3
4
5
6
7

Účastník se zotavuje, v logu má jen prepared, musí zjistit výsledek
a koordinátor je mimo provoz

Každý účastník potřebuje adresy ostatních – obdrží je od
koordinátora v request-to-prepare

Zotavení pak probíhá následovně
 Dotáže se ostatních účastníků na výsledek
 Oslovený účastník reaguje následovně
▪ Pokud zná výsledek, tak odpoví commit nebo abort
▪ Pokud nebyl ani ve fázi prepared, odpoví abort (to samé by udělal koordinátor)
▪ Pokud je na tom stejně jako volající (v logu jen prepared), odpoví uncertain
 Pokud se od některého účastníka dozví výsledek, provede commit
nebo abort a informuje všechny účastníky, co odpověděli uncertain

Je výhodné držet informaci o výsledku transakce
4/20/2015
299
1
2
3
4
5
6
7

Poté co obdrží kladné odpovědi na prepare zprávu, odeše precommit
zprávu (nezapíše zatím commit log) a čeká na potřebný počet odpovědí
(dáno počtem potenciálních chyb k ošetření)

Zabraňuje blokování v případě, že nedochází ke komunikačním
výpadkům. Není moc realistické, ale i kdyby vůči nim odolný byl, tak by
zase mohl blokovat

3PC je daleko složitější než 2PC, a přitom jej vylepšuje jen lehce (brání jen
pár blokujícím situacím kdy je koordinátor mimo provoz)

3PC proto není moc používaný v praxi

3PC zajišťuje, že pokud je některý proces v neurčitém stavu, tak žádný
jiný proces nepotvrdí. Pokud jsou všechny v takovém stavu, tak mohou i
bez koordinátora rozhodnout o abortu
4/20/2015
300
1

Obecně – co nejvíce příklady, obrázky, atp… a taky zdroje

MTTF a MTTR u dnešních systémů

Příklady na DB modely + rozdíly (na příkladech)



2
3
4
5
7
Hnízděné transakce
Transakce se savepointy
Ságy

Reálné příklady na historie H1 – H12

Příklady (hlavně obrázky) na granulované zámky

Příklady historií, kde konverze zámků zvýší paralelismus

Uváznutí – prevence vs. detekce a řešení, pravděpodobnost uváznutí

DAG zámky na více hierarchiích

Časová razítka – příklad zpracování transakcí pomocí základních TO pravidel
4/20/2015
6
301

RNDr. Jakub Lokoč, Ph.D.

Transkript

Podobné dokumenty

Databáze - Státnice

Transakce

Herní design

15 milníků v historii sdružení CESNET 15 Milestones in the CESNET

obsah úvod doporučení pro aplikaci přípravku entero zoo a

incoterms 2010 incoterms 2010

Diplomová práce

Medveduv pruvodce po LibUCW

Rozhraní SAX, SAX vs. SAX2

relační databáze - Ostravská univerzita

Návod k obsluze Řada X

Bc. Správa počítačových systémů