COMPUTERWORLD
pod kapotou
Uspo°ßdateln² rozvrh

Ji₧ standard SQL92 stanovuje, aby volßnφ paraleln∞ provßd∞n²ch transakcφ bylo uspo°ßdatelnΘ. O co se jednΘ, p°edm∞tem dneÜnφ databßzovΘ abecedy.

Jde vlastn∞ o podmφnku t²kajφcφ se rozvrhu transakcφ. SΘriovΘ rozvrhy zachovßvajφ operace ka₧dΘ transakce pohromad∞. Nejprve se provedou operace prvnφ transakce a potom druhΘ transakce. Pro dv∞ transakce tedy existujφ 2 sΘriovΘ rozvrhy, pro N transakcφ lze sestavit N! r∙zn²ch sΘriov²ch rozvrh∙. Pro zφskßnφ korektnφho v²sledku vÜak m∙₧eme pou₧φt i rozvrhu, kde jsou operace navzßjem proklßdßny. P°irozen²m po₧adavkem na korektnost je, aby efekt paralelnφho zpracovßnφ transakcφ byl t²₧, jako by byly transakce provedeny v n∞jakΘm sΘriovΘm rozvrhu. P°edpoklßdßme-li toti₧, ₧e ka₧dß transakce je korektnφ program (tj. zachovßvß konzistenci databßze), m∞l by b²t vΘst v²sledek sΘriovΘho zpracovßnφ ke konzistentnφmu stavu. O systΘmu zpracovßnφ transakcφ (SZT), kter² zaruΦuje tuto vlastnost se °φkß, ₧e zaruΦuje uspo°ßdatelnost.

Bohu₧el, lze nalΘzt mnoho p°φklad∙, kdy libovolnΘ prolo₧enφ operacφ vφce transakcφ nevede ke smysluplnΘmu v²sledku. Jako p°φklad uve∩me jednoduch² rezervaΦnφ systΘm s ΦφtaΦem X, kde se p°iΦφtajφ Φi odeΦφtajφ poΦty nov²ch, resp. ruÜen²ch rezervacφ. V tabulce 1 b∞₧φ shora dol∙ paraleln∞ 2 transakce, t°etφ sloupec komentuje stav souboru.

T1

T2

stav

READ(X)

 

X = 80

X:=X-5

 

zruÜenφ 5 rezervacφ

READ(X)

X = 80

X:=X+4

p°idßnφ 4 rezervacφ

WRITE(X)

 

X = 75

READ(Z)

 

WRITE(X)

X = 84

Z:=Z+N

 

Tab. 1 P°φklad rozvrhu dvou transakcφ

P°esto₧e by hodnota X v databßzi m∞la b²t 79, je 84.

TΘto kolizi se tradiΦn∞ °φkß ztrßta aktualizace. Mezi dalÜφ pat°φ doΦasnß aktualizace, kdy transakce T1 provede aktualizaci X, T2 provede dalÜφ aktualizaci X a ·sp∞Ün∞ ukonΦφ prßci, avÜak po chyb∞ systΘmu dßle je transakce T1 zruÜena. P°esto₧e ukonΦenß transakce T2 aktualizovala X, je tato aktualizace ztracena, proto₧e SZT uvede X pomocφ ROLLBACK do stavu p°ed zapoΦetφm T1.

DalÜφ nekorektnosti objevφme v souvislosti s pou₧itφm kurzoru v SQL92. ProblΘmem je, ₧e vÜichni v²robci relaΦnφch S╪BD nezaruΦujφ vlastnost uspo°ßdatelnosti. Pro mnoho aplikacφ staΦφ, je-li garantovßna stßlost kurzoru, tj. provßdφ-li aplikace v²b∞r Φi aktualizaci prost°ednictvφm kurzoru, je postaΦujφcφ garantovat, ₧e °ßdky zφskanΘ operacφ FETCH neobsahujφ data z nepotvrzen²ch transakcφ.

Pohnul-li se kurzor k dalÜφmu °ßdku, je ji₧ p°edchozφ k dispozici jin²m transakcφm. P°i dodr₧ovßnφ uspo°ßdatelnosti toto ovÜem nenφ mo₧nΘ. N∞jakß transakce nem∙₧e modifikovat °ßdek, kter² byl manipulovßn transakcφ, kterß prßv∞ b∞₧φ (tento princip je ovÜem zeslaben ve zpracovßnφ pod dvoufßzov²m uzamykacφm protokolem - viz p°φÜtφ dφl DatabßzovΘ abecedy). Stßlost kurzoru ovÜem korektnost zcela nezaruΦuje. V SQL92 jsou navr₧eny tzv. ·rovn∞ izolace, kterΘ p°esn∞ definujφ korektnost pro jednotlivΘ ·rovn∞ se vztahem pro r∙znΘ typy ·loh.

Vidφme, ₧e libovolnΘ proklßdßnφ operacφ z transakcφ vede obecn∞ k nekonzistentnφmu stavu databßze. Mechanismy, kterΘ °φdφ paralelnφ zpracovßnφ transakcφ musφ za°φdit, aby po skonΦenφ vÜech transakcφ byly databßze v konsistentnφm stavu.

Abychom mohli pro n∞jak² rozvrh urΦit jeho korektnost, staΦφ, abychom ukßzali, ₧e je v n∞jakΘm smyslu ekvivalentnφ n∞jakΘmu sΘriovΘmu rozvrhu. Teorie i praxe zavedla vφce zp∙sob∙, jak zavΘst takovou ekvivalenci. V∞tÜina z nich je zalo₧ena na pojmu konfliktnφch operacφ. P°φstupy se liÜφ, jak je konflikt mezi operacemi definovßn.

Uvedeme neformßlnφ definici takovΘ ekvivalence zalo₧enΘ na komutativit∞ operacφ READ a WRITE. Komutativita °φkß, ₧e dv∞ operace jsou konfliktnφ, jestli₧e v²sledky jejich r∙znΘho sΘriovΘho volßnφ nejsou ekvivalentnφ. Neznßme-li nic o sΘmantice operacφ, pak z°ejm∞ {READ(A), WRITE(A)}nedßvß stejnou hodnotu atributu A jako rozvrh {WRITE(A), READ(A)}. Operace WRITE je tedy v₧dy v konfliktu s operacφ READ nebo WRITE. Dv∞ operace, kterΘ nejsou konfliktnφ se naz²vajφ kompatibilnφ. Kompatibilita a konflikty se obvykle zadßvajφ tabulkou (zde tabulka 2). Indexy znamenajφ Φφslo transakce, + , resp. - oznaΦuje kompatibilitu, resp. konflikt.

 

READj(A)

WRITEj(A)

READi(A)

+

-

WRITEi(A)

-

-

Tab. 2 Komutativita operacφ READ a WRITE

Mßme-li rozvrhy S1 a S2 pro mno₧inu transakcφ T = {T1,...,TN}, pak S1 s S2 jsou ekvivalentnφ (vzhledem ke konflikt∙m), jsou-li spln∞ny dv∞ podmφnky:

(1) Jestli₧e se v jednom rozvrhu vyskytuje READ(A) v transakci Ti a tato hodnota vznikla z WRITE(A) v transakci Tj, potom totΘ₧ musφ b²t zachovßno v druhΘm rozvrhu.

(2) Jestli₧e se v jednom rozvrhu vyvolß poslednφ operace WRITE(A) v transakci Ti, pak totΘ₧ musφ b²t zachovßno i v druhΘm rozvrhu.

Podmφnka (1) zajiÜ¥uje, ₧e ka₧dß operace READ Φte po stejnΘ operaci WRITE v obou rozvrzφch, podmφnka (2) zajiÜ¥uje, ₧e koneΦn² stav databßze je stejn² v obou rozvrzφch. Jin²mi slovy °eΦeno, relativnφ po°adφ konfliktnφch operacφ je stejnΘ v obou rozvrzφch.

Uva₧ujme transakce

T3: {READ(A),akce1(A),WRITE(A),READ(B),akce2(B),WRITE(B)}

T4: {READ(A),akce3(A),WRITE(A),READ(B),akce4(B),WRITE(B)}

a sΘriovΘ rozvrhy S3:{T3,T4}, S4:{T4,T3}.

DalÜφ dva rozvrhy nejsou sΘriovΘ:

S3 S4

T3

T4

T3

T4

READ(A)

 

READ(A)

akce1(A)

 

akce1(A)

WRITE(A)

   

READ(A)

READ(A)

 

akce3(A)

akce3(A)

 

WRITE(A)

WRITE(A)

 

READ(B)

READ(B)

 

WRITE(A)

akce2(B)

 

READ(B)

WRITE(B)

 

akce2(B)

READ(B)

WRITE(B)

akce4(B)

 

akce4(B)

WRITE(B)

 

WRITE(B)

Symbolem º budeme znaΦit ekvivalenci rozvrh∙. Z°ejm∞ S1 º S2, avÜak S1 ù º S3. Vztah S4 k ostatnφm rozvrh∙m vy°eÜφme pozd∞ji.

O rozvrhu °φkßme, ₧e je uspo°ßdateln², jestli₧e existuje sΘriov² rozvrh s nφm ekvivalentnφ.

Testovßnφ uspo°ßdatelnosti lze provßd∞t algoritmicky. SpφÜe teoretick² p°φstup p°edpoklßdß, ₧e mßme dva rozvrhy a zjiÜ¥ujeme jejich uspo°ßdatelnost pomocφ precedenΦnφho grafu. Tento graf mß za uzly transakce a hrany jsou definovßny podle toho, v jakΘm po°adφ se v rozvrhu vyskytujφ konfliktnφ operace. ProblΘm, zdali je rozvrh uspo°ßdateln² je p°eveden na hledßnφ cykl∙ v precedenΦnφm grafu. Existuje-li cyklus, rozvrh nenφ uspo°ßdateln². Nap°. tak lze ov∞°it ₧e rozvrh S4 nenφ uspo°ßdateln². Tato metoda je jednoduchß, ovÜem v praxi ne p°φliÜ pou₧itelnß, proto₧e je p°φliÜ statickß. Navφc funguje v p°φpad∞, ₧e operaci WRITE(X) p°edchßzφ v transakci operace READ(X), co₧ obecn∞ nenφ pravda. Obecn∞jÜφ p°φpad je algoritmicky p°φliÜ nßroΦn². U₧iteΦn∞jÜφ a dnes v praxi rozÜφ°enΘ jsou p°edevÜφm metody zalo₧enß na zßmcφch.

Na zßv∞r p°ipome≥me, ₧e se pohybujeme ve sv∞t∞ ploch²ch transakcφ (₧ßdnΘ hnφzd∞nφ) s velmi jednoduch²mi objekty (atributy). TakΘ pojetφ uspo°ßdatelnosti nenφ jednφm mo₧n²m kritΘriem korektnosti. Mohou existovat rozvrhy, kterΘ nejsou ekvivalentnφ se ₧ßdn²m sΘriov²m rozvrhem podle naÜφ definice a p°esto produkujφ stejn² v²sledek jako n∞jak² sΘriov² rozvrh. Pojem konfliktu je v pokroΦilejÜφch systΘmech zalo₧en na znalosti sΘmantiky operacφ.



<seznam dφl∙ serißlu>   <COMPUTERWORLD>