Muita transaktioiden hallintamenetelmiä H. Berenson, P. Bernstein, J. Gray, J. Melton, E. O Neil & P. O Neil: A critique of ANSI SQL isolation levels. Proc. of the 1995 ACM SIG- MOD Internat. Conf. on Management of Data, 1 10; kohdat 4.1 (cursor stability), 4.2 (snapshot isolation) ja 4.3 (other multi-version systems). M. Kifer, A. Bernstein & P. M. Lewis: Database Systems. An Application-Oriented Approach. Complete Version. Pearson Addison Wesley, 2006; sivut 903 912, luvun 21 (isolation in relational databases) kohta 21.5 (multiversion concurrency controls). C. Mohan: Commit_LSN: a novel and simple method for reducing locking and latching in transaction processing systems. VLDB 90, Proc. of the 16th Internat. Conf. on Very Large Data Bases, 406 418. A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Fifth Edition. McGraw-Hill, 2006; sivut 658 661, luvun 16 (concurrency control) kohdat 16.5.2 (multiversion two-phase locking) ja 16.6.1 (deadlock prevention); sivut 667 669, kohta 16.8 (weak levels of consistency); sivut 947 950; sivut 1017 1019, luvun 27 (Oracle) kohta 27.5 (concurrency control and recovery). 273
Päivitykseen varautumislukot, s. 275. Yleisiä lukkiumien estämismenetelmiä, s. 279. Heikommat eristyvyysasteet, s. 285. Commit-LSN-mekanismi, s. 289. Elvytys ja samanaikaiset transaktiot, s. 293. Moniversioiva samanaikaisuuden hallinta, s. 297. Tilannevedoseristyvyys, s. 306. 274
Päivitykseen varautumislukot Lukon korotuksesta aiheutuvat lukkiumat voidaan estää päivitykseen varautumislukoilla (update-mode lock, U-lock). Transaktio varaa tietoalkioon x U-lukon S-lukon sijasta, kun on mahdollista, että lukko joudutaan myöhemmin korottamaan X- lukoksi. S-lukkoa ei tässä käytännössä ole lupa korottaa X-lukoksi (eikä U- lukoksi). U-lukko on mahdollista varata x:ään silloin kun S-lukkokin, ts. kun muilla transaktioilla ei ole x:ään X-lukkoa (eikä U-lukkoa). Kun transaktio on ehtinyt saada U-lukon x:ään, eivät muut transaktiot enää voi saada mitään lukkoja x:ään (niiden S-lukkojen lisäksi, joita niillä ehkä vielä x:ään on). 275
Päivitystä varten on transaktion korotettava U-lukkonsa X-lukoksi. Tätä varten transaktion on odotettava, että x:n lukijat ovat kaikki vapauttaneet S-lukkonsa. Kun transaktiolla T on U-lukko x:ään, niin operaatio lock(t, x, X, d) siis aiheuttaa mahdollisesti T :n odotuksen, kunnes lukko voidaan myöntää. U-lukkojen automaattinen varaus edellyttää, että kyselykielessä on mahdollista vihjaista asiasta järjestelmälle. Kun sulautetun SQL-ohjelman kohdistin (cursor) on esitelty määritettä for update käyttäen, kohdistimen koskettamiin monikoihin varataan U-lukkoja S-lukkojen sijaan. Jos kohdistimen nykymonikkoa päivitetään, U-lukko korotetaan X- lukoksi, joka pidetään sitoutumispisteeseen asti. Jos nykymonikkoa ei päivitetä, niin U-lukko joko lasketaan S- lukoksi (eristyvyystasolla 3 ) tai vapautetaan kokonaan (eristyvyystasolla 2 ), kun kohdistin siirretään seuraavaan monikkoon. 276
Lukkotyyppijoukon {S,U,X} yhteensopivuusmatriisi on epäsymmetrinen: Comp m 1 -lukko m 2 -lukko S U X S true false false U true false false X false false false 277
Lukkotyyppijoukon {S,U,X} lukonkorotusmatriisi: Upgr omistama pyytämä S U X S S U X U U X X X X Arvo tarkoittaa, ettei lukon korotus ole sallittu. {S,U,X}-lukituskäytäntö estää lukon korotuksesta syntyvän lukkiuman, koska vain yhdelle transaktiolle kerrallaan suodaan samaan tietoalkioon U-lukko. U-lukon korotusta X-lukoksi voi siis olla odottamassa vain yksi transaktio. 278
Yleisiä lukkiumien estämismenetelmiä Tarkastellaan yleisiä menetelmiä lukkiumien estämiseksi, kun transaktioiden samanaikaisuuden hallinnassa käytetään lukkoja. Eräs ratkaisu olisi vaatia, että jokainen transaktio varaa tarvitsemansa lukot yhdellä kertaa yhdellä operaatiolla. Tämä on kuitenkin vaikeaa tai mahdotonta toteuttaa automaattisesti. Monikoiden todellinen käyttöaste jäisi sitä paitsi vähäiseksi. Myös nälkiintyminen (starvation) olisi mahdollista: transaktio voisi joutua rajatta odottamaan pääsyä suosittuun tietoalkioon. Lukituskäytäntö, jossa jokainen transaktio lukitsee monikot aina etukäteen sovitussa järjestyksessä eikä koskaan korota lukkojaan (ellei transaktiolla ole korotukseen yksinoikeutta), takaa lukkiutumattomuuden. 279
Avainvälimallissamme lukkiumat estyvät, jos jokainen transaktio T lukitsee käsittelemänsä avainarvot niiden nousevassa suuruusjärjestyksessä eikä koskaan korota S-lukkoa X-lukoksi. Ts. jos T :n täytyy pitää lukkoa yhtäaikaa avainarvoihin x ja y, missä x < y, niin T :n täytyy lukita ensin x ja vasta sitten y. Tämäkin vaatimus olisi liian rajoittava yleiskäyttöisessä tietokantajärjestelmässä, jossa transaktiot eivät noudata mitään edeltä käsin sovittua muotoa. 280
Lukkiumiin mahdollisesti johtavat odotukset voidaan estää käyttämällä lukkojen lisäksi transaktioiden aikaleimoja. Järjestelmä asettaa jokaiselle järjestelmään tulevalle transaktiolle T yksikäsitteisen aikaleiman (timestamp) ts(t ). Aikaleima ts(t ) saadaan esim. järjestelmän kellosta tai sitten käytetään juoksevaa järjestysnumeroa. Transaktion aikaleiman perusteella päätetään, sallitaanko transaktion odottaa vai keskeytetäänkö se. Keskeytetyn ja peruutetun transaktion keskeytyksen syy välitetään sovellukselle, joka voi nyt yrittää käynnistää saman transaktion uudestaan vanhalla aikaleimalla. 281
Oletetaan, että transaktio T pyytää lukkoa transaktion T varaamaan, pyydetyn lukon kanssa yhteensopimattomasti lukittuun tietoalkioon n. Kaksi eri käytäntöä: (1) Odota tai kuole (wait or die). T :lle sallitaan odotus vain, jos T on vanhempi (so. aikaisempi) kuin T ; muutoin T peruutetaan. (2) Haavoita tai odota (wound or wait). T :lle sallitaan odotus vain, jos T on nuorempi (so. myöhäisempi) kuin T ; muutoin peruutetaan T ja kaikki muut n:ään pääsyä odottavat transaktiot. Kumpikin käytäntö estää paitsi lukkiumat myös nälkiintymiset. 282
Lukkiumat on estetty odota tai kuole -käytännössä, koska transaktiot voivat odottaa toisiaan vain nousevassa ikäjärjestyksessä. Lukkiumat on estetty haavoita tai odota -käytännössä, koska transaktiot voivat odottaa toisiaan vain laskevassa ikäjärjestyksessä. Nälkiintymiset on estetty odota tai kuole -käytännössä, koska transaktio T ei lopulta enää ole nuori, vaan pääsee odottamaan ja siis aikanaan käsiksi n:ään. Transaktio ei näet nuorru peruutuksista. Nälkiintymiset on estetty haavoita tai odota -käytännössä, koska lukonhaltijaa vanhempi transaktio pääsee aina välittömästi käsiksi n:ään. 283
Esimerkki. Sovelletaan haavoita tai odota -käytäntöä. Transaktioiden ikäjärjestys: ts(t 1 ) < ts(t 2 ) < ts(t 3 ). T 2 :lla on lukko avainarvoon x ja T 3 odottaa pääsyä x:ään. T 1 pyytää pääsyä x:ään. Koska T 1 on vanhempi kuin x:n haltija T 2, peruutetaan T 2 ja T 3. T 1 saa pääsyn x:ään. T 2 ja T 3 alkavat uudestaan entisin aikaleimoin. T 2 pyytää pääsyä x:ään ja joutuu odottamaan. T 3 pyytää pääsyä x:ään ja joutuu odottamaan. T 1 vapauttaa x:n lukon. T 2 saa pääsyn x:ään. T 2 vapauttaa x:n lukon. T 3 saa pääsyn x:ään. 284
Heikommat eristyvyysasteet Täyden sarjallistuvuuden (eristyvyysasteen 4 ) vaatiminen eli eristyvyysanomalioiden täydellinen välttäminen ei aina salli riittävästi rinnakkaisuutta. Transaktio T, joka tuottaa raportin koko tietokannasta, estää samanaikaiset kirjoitukset tietokannan niihin monikoihin, jotka T on jo käsitellyt. T varaa S-lukkoja monikoiden (x, v) avainarvoihin x sitä mukaa kuin T lukee monikoita. Kaikki lukot on lukituskäytännön mukaisesti pidettävä T :n sitoutumispisteeseen asti. Toinen transaktio T pääsee kirjoittamaan tai poistamaan T :n lukemia monikoita tai lisäämään uusia monikoita T :n lukemien monikoiden väliin vasta T :n sitouduttua tai päätettyä peruutuksensa. Transaktio T kuitenkin lukee kunkin monikon vain kerran eikä lainkaan päivitä tietokantaa, joten toistokelvottomien lukujen sallimisesta ei ehkä olisi niin suurta haittaa. Transaktion T eristyvyysaste voitaisiin pudottaa 2 :ksi muuttamalla T :ssä lukulukot lyhytkestoisiksi. T :n tuottama raportti ei kylläkään silloin välttämättä edustaisi tarkasti mitään tietokannan eheää tilaa. 285
Tarkastellaan seuraavaa toistokelvottoman luvun erikoistapausta. Päivityksen menetys (lost update) esiintyy, kun transaktio T 1 jättää huomiotta toisen transaktion T 2 tekemän päivityksen. T 1 lukee avainvälin, minkä jälkeen T 2 päivittää jotain avainväliin kuuluvaa avainta x ja sitoutuu. Sitten myös T 1 päivittää x:ää: H =...R 1 [y,θz]...o 2 [x]...c 2...o 1 [x]... Tässä o 1 [x] ja o 2 [x] ovat avainarvolla x varustetun monikon päivityksiä (lisäyksiä, poistoja tai kirjoituksia) ja y x θ z. T 1 saattaa perustaa x:n päivityksensä lukuoperaation R 1 [y,θz] tulokseen. Päivityksen menetys on mahdollista, jos y:n lukemista varten varattu S-lukko on lyhytkestoinen. Kun T 1 :n operaatiota R 1 [y,θz] varten avainarvoon y varaama S-lukko vapautetaan operaation päätteeksi, voi T 2 saada operaatiotaan o 2 [x] varten X-lukot avainarvoon x ja sen seuraajaan. 286
Esimerkki. Pankkitilitietokannan transaktiot: T 1 = BR[x,v 1 ]W[x,u 1,v 1 100]C (100 euron otto tililtä x). T 2 = BR[x,v 2 ]W[x,u 1,v 2 200]C (200 euron otto tililtä x). Seuraava ajoitus voidaan ajaa jokaisessa tietokannassa, joka sisältää monikon (x,v). B 1 R 1 [x,v]b 2 R 2 [x,v]w 2 [x,v,v 200]C 2 W 1 [x,v 200,v 100]C 1. Ainoa tässä ajoituksessa esiintyvä eristyvyysanomalia on toistokelvoton luku R 1 [x,v]. Se on mahdollinen, koska T 1 vapauttaa avainarvoon x ottamansa S- lukon heti lukemisen jälkeen, jolloin T 2 voi saada x:ään X-lukon kirjoitusoperaatiotaan W 2 [x,v,v 200] varten. Tilin x saldoksi jää v 100, missä v on alkuperäinen saldo. T 1 perusti päivityksensä tilin vanhaan saldoon, ja T 2 :n päivitys kirjoitettiin yli. 287
Miten voidaan varmistua siitä, että päivitys perustuu aina monikon (x,v) tuoreeseen arvoon? Luetaan (x, v) ja pidetään avainarvon x S-lukko siihen asti, kunnes selviää, pitääkö monikkoa vielä päivittää. Jos osoittautuu, että monikkoa on tarpeen päivittää, korotetaan avainarvon S-lukko X-lukoksi, joka sitten pidetään sitoutumispisteeseen asti. Jos monikkoa ei ole tarpeen päivittää, voidaan S-lukko vapauttaa. Päivitysten menetykset on näin estetty. Muun tyyppisiä toistokelvottomia lukuja voi tietysti edelleenkin esiintyä. Asteiden 2 ja 3 väliin jäävää eristyvyysastetta, joka kieltää päivitysten menetykset, kutsutaan kirjallisuudessa nimellä kohdistimen vakaus (cursor stability). SQL:n kohdistimen nykymonikon avainarvoon otetaan S-lukko, joka korotetaan pitkäkestoiseksi X-lukoksi, jos monikkoa päivitetään. Muutoin S-lukkoa pidetään vain siihen asti, kun siirrytään seuraavaan monikkoon (fetch). Muulla tavalla kuin kohdistimen kautta tapahtuvat luvut on pakko suojata pitkäkestoisilla S-lukoilla. 288
Commit-LSN-mekanismi Oletetaan, että transaktioilta vaaditaan ainoastaan sitoutuneen lukemisen eristyvyystaso 2. Esitetyissä lukituskäytännöissä tämä taso saavutetaan, kun jokaista monikon päivitystä varten varataan pitkäkestoinen X-lukko ja monikon lukemista varten lyhytkestoinen S-lukko. S-lukon tehtävänä on silloin pelkästään estää likainen luku, so. varmistaa, että luettava monikko on lukuhetkellä sitoutuneessa tilassa. Transaktion varaamien lukkojen lukumäärä on kuitenkin sama kuin korkeimman eristyvyystason takaavassa lukituksessa, ja lyhytkestoisten S-lukkojen vapautus yksitellen sitä paitsi vie enemmän aikaa kuin yhtä monen pitkäkestoisen lukon vapautus yhdellä kertaa transaktion sitoutumispisteessä. 289
Varattavien lyhytkestoisten S-lukkojen määrää voidaan vähentää käyttämällä hyväksi seuraavaa yksinkertaista ideaa. Olkoon Commit-LSN parhaillaan aktiivisten transaktioiden aloituskirjauksien lokijärjestysnumeroiden minimi. Commit-LSN on siis vanhimman vielä aktiivisen transaktion T aloituskirjauksen T,B LSN. Commit-LSN:n ylläpitoa varten transaktiotaulussa säilytetään jokaisesta transaktiosta sen tunnisteen, tilan (etenevä/peruuntuva) ja Undo-Next-LSN-arvon lisäksi myös arvo Begin-LSN, joka on transaktion aloituskirjauksen LSN. 290
Oletetaan, että transaktio T haluaa lukea monikoita tietosivulta p, joka on jo T :tä tuottavan prosessin naulitsema ja lukusalpaama. Jos Page-LSN(p) < Commit-LSN, ei sivulla p voi olla minkään aktiivisen transaktion (ei edes T :n itsensä) tekemää päivitystä. On kylläkin mahdollista, että jollakin transaktiolla T on jo varattuna X-lukko sivun p johonkin monikkoon sen vastaista päivitystä varten. Tätä päivitystä ei kuitenkaan vielä ole tehty, koska kerran Page- LSN(p) on pienempi kuin T :n aloituskirjauksen LSN, eikä voida tehdäkään ennen kuin T :tä tuottava prosessi on vapauttanut p:hen varaamansa lukusalvan. 291
Huolimatta siitä, onko jollain T :lla tällaista X-lukkoa varattuna vai ei, likaista lukua ei tapahdu, vaikka T :n annetaan lukea p:n kaikki monikot varaamatta niihin mitään lukkoa. Kun T on lukenut p:n monikot, p:n salpaus ja naulinta vapautetaan. Säästö lukitusoperaatioissa voi olla merkittävä, jos T lukee useilta tietosivuilta kaikki monikot. S-lukko on varattava vain niiden sivujen p monikoihin, joissa Page- LSN(p ) on suurempi kuin Commit-LSN. Commit-LSN-mekanismin käyttökelpoisuutta lisää, kun transaktion aloituskirjaus tehdään vasta juuri ennen sen ensimmäistä päivitystä, ja kun pelkästään lukuoperaatioita sisältävästä transaktiosta ei kirjata lokiin aloitusta eikä päättymistä. 292
Elvytys ja samanaikaiset transaktiot Lukituskäytäntöä (tai muuta samanaikaisuuden hallintakäytäntöä) on yleensä tarpeen soveltaa ainoastaan normaalin transaktionkäsittelyn aikana, jolloin transaktioita tuotetaan useammista samanaikaisista prosesseista. Häiriöstä elvytyksen toistovaiheen aikana ei ole tarpeen varata mitään lukkoja, sillä toistovaiheen operaatiot suoritetaan aina täsmälleen alkuperäisen ja siis aikanaan hyväksytyn ajoituksen mukaisessa järjestyksessä. Myöskään elvytyksen peruutusvaiheen aikana ei ole tarpeen varata lukkoja. 293
Edellä eristyvyyttä ja peruuntuvuutta tarkastelevassa kohdassa olemme näet todenneet, että kun normaalissa transaktionkäsittelyssä likaiset kirjoitukset on estetty, niin aktiiviset transaktiot voidaan aina täydentää peruutuksensa päättäneiksi transaktioiksi limittämällä peruutusvaiheiden käänteisoperaatiot mielivaltaisella tavalla. Näin täydennetyssä ajoituksessa ei esiinny likaisia kirjoituksia eikä myöskään muita eristyvyysanomalioita, jollei alkuperäinen ajoitus sellaisia sisällä. ARIES-algoritmissa peruutusvaiheiden käänteisoperaatiot suoritetaan yhdellä lokin selauksella vastaavien etenemisvaiheiden operaatioiden kronologisen järjestyksen käänteisjärjestyksessä, mikä siis on vain yksi mahdollinen järjestys (kylläkin luonnollisin). Elvytyksen ollessa käynnissä järjestelmään ei oteta vastaan uusia transaktioita. 294
Häiriöstä elvytys voi kestää kauan ja tietokannan tiedot voivat sen vuoksi olla pitkän ajan käyttäjien ulottumattomissa. Tiedon saatavuuden (data availability) ylläpitämiseksi uusia transaktioita pitäisiä hyväksyä järjestelmään niin pian häiriön jälkeen kuin mahdollista. Elvytyksen peruutusvaihe voidaankin toteuttaa myös siten, että yksittäisten transaktioiden annetaan peruuntua kuten normaalin transaktionkäsittelyn aikana ja suorittaa käänteisoperaatioitaan samanaikaisesti järjestelmään otettujen uusien transaktioiden kanssa. Peruutusvaihetta varten luodaan yksi tai useampia prosesseja peruuntuvien transaktioiden peruutusvaiheiden suorittamiseksi. Menettely toimii vain, jos peruuntuville transaktioille hankitaan ensin lokista tarvittavat X-lukot. Luku-kirjoitusmallin ankarassa kaksivaihelukituksessa tämä on helposti toteutettavissa tarkastelemalla W[x, u, v]-operaatioiden lokikirjauksia. Avainvälilukituksessa täytyy monikon poisto-operaatiosta D[x, v] tätä varten kirjata lokiin myös avainarvon x seuraaja y, jotta siihen voitaisiin lokista hankkia tarvittava pitkäkestoinen X-lukko. 295
Vaihtoehtona lukkojen hankinnalle on Commit-LSN-mekanismin käyttö elvytyksen peruutusvaiheen aikana. Tässä vaihtoehdossa elvytyksen peruutusvaihe toteutetaan entiseen tapaan yhdellä lokiselauksella hankkimatta mitään lukkoja. Elvytyksen analyysivaiheessa määrätään Commit-LSN:ksi vanhimman aktiivisen transaktion aloituskirjauksen LSN. Elvytyksen peruutusvaiheen alettua hyväksytään järjestelmään heti uusia transaktioita (jotka tietysti varaavat tarpeelliset lukot normaaliin tapaan). Uuden transaktion sallitaan kuitenkin operoida sivulle p vain jos Page-LSN(p) on pienempi kuin Commit-LSN. Jos Page-LSN(p) on suurempi kuin Commit-LSN, uusi transaktio pannaan odottamaan elvytyksen peruutusvaiheen päättymistä. 296
Moniversioiva samanaikaisuuden hallinta Edellä tarkastellut transaktioiden eristyvyyskäsitteet liittyvät tietokantamalliin, jossa kustakin loogisen tietokannan tietoalkiosta on kulloinkin olemassa ja saatavilla ainoastaan yksi versio, tietoalkion tuorein eli nykyversio. Kun transaktiolle sallitaan sille asetetun eristyvyystason puitteissa tietyn tietoalkion luku tai päivitys, luettavaksi tai päivitettäväksi annetaan aina tietoalkion nykyversio. Moniversioiva samanaikaisuuden hallinta (multiversion concurrency control) liittyy tietokantamalliin, jossa loogisen tietokannan tietoalkioista on saatavilla joko pysyvästi tai ainakin jonkin aikaa transaktioiden käsittelyn kuluessa nykyversion lisäksi myös sitä vanhempia versioita. Tietokantamallissamme tämä tarkoittaa, että monikon avainarvoa x kohti voi samanaikaisesti olla olemassa (luettavissa) useampia monikkoversioita (x,v 1 ),(x,v 2 ),...,(x,v n ). 297
Menettelyn tarkoituksena on tehostaa erityisesti lukutransaktioiden (read-only transaction) suoritusta. Lukutransaktio on transaktio, jossa esiintyy ainoastaan lukuoperaatioita ja joka esitellään sellaiseksi (set transaction read-only). Muita transaktioita kutsutaan päivitystransaktioiksi (read/write transaction, update transaction). Loogisen tietokannan versio eli tilannevedos (snapshot) tietyllä hetkellä τ on tietokannan sitoutuneiden tietoalkioiden joukko kyseisellä hetkellä. Hetken τ tilannevedokseen kuuluu monikko (x,v) silloin ja vain silloin, kun τ:hun mennessä viimeisen x:ään kohdistuvan päivityksen (lisäys tai kirjoitus) teki τ:hun mennessä sitoutunut transaktio. Hetken τ tilannevedoksesta puuttuu avainarvolla x varustettu monikko silloin ja vain silloin, kun τ:hun mennessä viimeinen x:ään kohdistuva päivitys oli poisto ja sen teki τ:hun mennessä sitoutunut transaktio (tai jos tietokannassa ei ole koskaan ollutkaan avainarvolla x varustettua monikkoa). 298
Transaktiotason lukujohdonmukaisuuden (transaction-level read consistency) täyttävä lukutransaktio lukee aina samasta tilannevedoksesta, moniversiointiin perustuvissa menetelmissä yleensä transaktion aloitushetken tilannevedoksesta. Seuraavassa ajoituksessa transaktio T 2 = BR[y,w]R[x,v 1 ]C lukee monikkoversion (x,v 1 ), joka kuuluu T 2 :n aloitushetken tilannevedokseen, vaikka lukuhetkellä on jo olemassa tuoreempi sitoutunut versio: B 1 W 1 [x,v 0,v 1 ]C 1 B 2 R 2 [y,w]b 3 W 3 [x,v 1,v 2 ]C 3 R 2 [x,v 1 ]C 2. Ajoitus on sarjallistuva, mutta transaktioiden sarjallistuvuusjärjestys ei ole niiden sitoutumisjärjestys. Sarjallistuvuusjärjestys on näet T 1 < T 2 < T 3. 299
Lukutransaktioiden moniversioivassa samanaikaisuuden hallinnassa (read-only multiversion concurrency control) menetellään seuraavasti: (1) Lukutransaktiot lukevat aina transaktion aloitushetken tilannevedoksesta varaamatta mitään lukkoja. (2) Päivitystransaktiot kohdistavat lukunsa ja päivityksensä normaaliin tapaan tietoalkion tuoreimpaan versioon ja suojaavat luku- ja päivitysoperaationsa tavanomaisen lukituskäytännön mukaisesti. Lukutransaktio ei siis koskaan odota eikä peruunnu minkään muun transaktion vuoksi, eikä mikään transaktio koskaan odota lukutransaktiota. Kun päivitystransaktiot soveltavat sarjallistuvuuden takaavaa lukituskäytäntöä, on kaikkien transaktioiden ajoituskin sarjallistuva. 300
Tietoalkioiden versioiden hallintaa varten järjestelmä pitää yllä versiolaskuria (version counter), jota kasvatetaan yhdellä aina kun päivitystransaktio T sitoutuu. Versiolaskurin uutta arvoa kutsutaan T :n sitoutumisaikaleimaksi (commit timestamp) ct(t ). Oraclessa tätä kutsutaan järjestelmän muutosnumeroksi (system change number, SCN). Versiolaskuria säilytetään pysyvässä muistissa ja siihen operoinnit pitää suojata salpaamalla (tai lyhytkestoisella lukolla). 301
Tarkastellaan päivitystransaktion T suorittamaa operaatiota W[x]. Kun T on saanut X-lukon avainarvoon x, se noutaa avainarvolla x varustetun monikon nykyversion (eli tuoreimman sitoutuneen version) (x,v) ja kohdistaa päivityksen siihen; olkoon tuloksena monikko (x,v ). Vanha versio (x,v) säilyy (jollei muualla niin ainakin lokissa). Uusi versio (x,v ) on vielä vailla versionumeroa. T :n mahdolliset myöhemmät päivitykset kohdistetaan aina T :n jo luomaan monikkoversioon. Kun T sitoutuu, versiolaskuria kasvatetaan ja laskurin uusi arvo ct(t ) liitetään versionumeroksi kaikkiin T :n luomiin monikkoversioihin. Voimme ajatella versioidun monikon olevan muotoa (x,τ,v), missä τ on versionumero. 302
Kun lukutransaktio T alkaa (tai kun se suorittaa ensimmäisen lukuoperaationsa), sille osoitetaan tilannevedosnumeroksi (snapshot number) eli aloitusaikaleimaksi (start timestamp) st(t ) versiolaskurin senhetkinen arvo. Lukutransaktio ei ota huomioon lukkoja eikä siis koskaan tutki lukkotaulua. Kun lukutransaktio T suorittaa operaation R[x], luetuksi tulee monikkoversio (x,τ,v), missä τ on suurin ehdon τ st(t ) täyttävä versionumero. Mikäli tämän ehdon täyttävää monikkoversiota ei enää ole (vaivatta) saatavilla, T keskeytetään. Näin voi käydä pitkäkestoiselle lukutransaktiolle, jonka tilannevedosnumero on hyvin varhainen. Esim. Oraclessa transaktioiden peruutukseen ja moniversioivaan samanaikaisuuden hallintaan käytettävä peruutussegmentti (rollback segment) on rajallinen. Mietittävää: minkä monikkoversion lukee R[x,θ z]? 303
Sovelluksille, jotka sietävät toistokelvottomia lukuja, eräät kaupalliset tietokannan hallintajärjestelmät kuten Oracle käyttävät lausetason lukujohdonmukaisuuteen (statement-level read consistency) perustuvaa samanaikaisuuden hallintaa. Tässä käytännössä lukulukkoja ei käytetä lainkaan, ts. päivitystransaktiotkaan eivät suojaa lukuoperaatioitaan lukoilla, vaan kohdistavat lukuoperaationsa tiettyihin tilannevedoksiin: (1) Lukutransaktioille taataan transaktiotason lukujohdonmukaisuus kuten edellä on selostettu. (2) Päivitystransaktion päivitysoperaatio suoritetaan tietoalkion tuoreimpaan sitoutuneeseen versioon ja suojataan pitkäkestoisella kirjoituslukolla. (3) Päivitystransaktion lukuoperaatio lukee asianomaisen SQLkyselyn suorituksen aloitushetken tilannevedoksesta. Siis kaikki saman SQL-kyselyn tarvitsemat monikot luetaan samasta tilannevedoksesta. Päivitystransaktion aloitusaikaleimaa st(t ) tavallaan edistetään kunkin transaktioon sisältyvän uuden lukuoperaatiosarjan (SQLkyselyn) suorituksen alkaessa. Jos kuitenkin luku kohdistuu transaktion itsensä päivittämään tietoalkioon, luetaan tämä tuore, sitoutumaton versio. 304
Lausetason lukujohdonmukaisesti ajettavat transaktiot eivät selvästikään tee likaisia kirjoituksia eivätkä likaisia lukuja. Lausetason lukujohdonmukaisuus implikoi siis SQL:n sitoutuneen lukemisen (read committed) eristyvyystason. Tämä onkin Oraclen toteutus sitoutuneen lukemisen eristyvyystasolle. Lausetason lukujohdonmukaisuus sallii mm. päivityksen menetyksen tyyppiset toistokelvottomat luvut. Esimerkiksi edellä esitettyjen pankkitilitietokannan transaktioiden T 1 = BR[x,v 1 ]W[x,u 1,v 1 100]C (100 euron otto tililtä x) ja T 2 = BR[x,v 2 ]W[x,u 1,v 2 200]C (200 euron otto tililtä x) ajoitus B 1 R 1 [x,v]b 2 R 2 [x,v]w 2 [x,v,v 200]C 2 W 1 [x,v 200,v 100]C 1. on mahdollinen, kun lukuoperaatio tuotetaan select-kyselystä ja kirjoitusoperaatio update-lauseesta. Transaktiot ovat lausetason johdonmukaisia. Mikäli tililtäottotransaktio tuotetaan yhdestä lauseesta update r set V = V m where X = :x, päivitettävän monikon avainarvo X-lukitaan heti, jolloin päivityksen menetyksen sisältävää ajoitusta ei voi syntyä. 305
Tilannevedoseristyvyys Moniversiointiin perustuvista eristyvyystasoista tarkastellaan seuraavassa vielä tilannevedoseristyvyyttä (snapshot isolation), jonka toteutuksia esiintyy kaupallisissa tietokannan hallintajärjestelmissä. Itse asiassa tilannevedoseristyvyys on Oraclen toteutus SQL:n sarjallistuvalle eristyvyystasolle, vaikka tilannevedoseristyneet transaktiot eivät välttämättä olekaan sarjallistuvia. Tilannevedoseristyvyydessä ei tehdä eroa luku- ja päivitystransaktioiden välillä: (1) Transaktion kaikki lukuoperaatiot kohdistetaan transaktion aloitushetken tilannevedokseen. Kaikille transaktioille taataan siis transaktiotason lukujohdonmukaisuus. (2) Samanaikaisilla transaktioilla tulee olla erillisten kirjoitusten ominaisuus (disjoint-write property), ts. jos kaksi transaktiota T 1 ja T 2 ovat samanaikaisia (so. jollakin hetkellä molemmat aktiivisia), niin T 1 :n kirjoitusjoukon ja T 2 :n kirjoitusjoukon pitää olla erillisiä. Transaktion T kirjoitusjoukko (write set) ws(t ) on T :n päivittämien tietoalkioiden tunnisteiden joukko. 306
Erillisten kirjoitusten ominaisuus estää päivitysten menetykset. Ajoituksen B 1 R 1 [x,v]b 2 R 2 [x,v]w 2 [x,v,v 200]C 2 W 1 [x,v 200,v 100]C 1. transaktiot T 1 ja T 2 eivät ole tilannevedoseristyneitä, sillä ne ovat samanaikaisia ja avainarvo x sisältyy kummankin kirjoitusjoukkoon. Vain toisen transaktioista T 1 ja T 2 voidaan sallia sitoutuvan, nimittäin sen (eli T 2 :n), joka ehtii ensiksi. Seuraavassa tarkastellaan erillisten kirjoitusten ominaisuuden kahta toteutusta. Molemmat perustuvat versiolaskuriin, jota kasvatetaan aina päivitystransaktion (so. ainakin yhtä tietoalkiota päivittäneen transaktion) T sitouduttua. Kuten edellä, versiolaskurin uusi arvo on T :n sitoutumisaikaleima ct(t ) ja T :n luoman uuden tietoalkioversion versionumero. Kummassakin menetelmässä jokainen transaktio T saa tilannevedosnumerokseen eli aloitusaikaleimakseen st(t ) versiolaskurin arvon sillä hetkellä, kun T tekee ensimmäisen luku- tai päivitysoperaationsa. Pätee aina: st(t ) < ct(t ). 307
Ensimmäisen sitoutujan voittoon (first-committer-wins) perustuvassa toteutuksessa transaktion T sallitaan sitoutua vain jos jokaiselle ehdon st(t ) < ct(t ) < ct(t ) täyttävälle transaktiolle T pätee: ws(t ) ws(t ) = /0. Ts. mikään toinen transaktio T, joka sitoutui T :n alkamisen jälkeen mutta ennen T :n sitoutumispyyntöä, ei ole päivittänyt yhtään niistä tietoalkioista, joita myös T on päivittänyt. Jos mainittu ehto ei päde, T keskeytetään. Ensimmäisen sitoutujan voiton toteuttava samanaikaisuuden hallintamenetelmä selvästikin takaa erillisten kirjoitusten ominaisuuden. 308
Ensimmäisen sitoutujan voitto on toteutettavissa ilman kirjoituslukkoja viivästettyjen päivitysten järjestelmässä (deferred-update system), so. järjestelmässä, jossa transaktion tekemät päivitykset asennetaan tietokantaan viivästetysti eli vasta sitten, kun transaktiolle on myönnetty sitoutuminen. (Tavanomaista järjestelmää, jossa transaktion tekemät päivitykset asennetaan tietokantaan välittömästi, kutsutaan välittömien päivitysten järjestelmäksi (immediate-update system).) Viivästettyjen päivitysten järjestelmässä aktiivisen transaktion T tekemät päivitykset sijoitetaan kirjoitusaikomuslistaksi (write-intentions list) kutsuttuun puskuriin (transaktion yksityiseen työtilaan). T :n päättyessä T :n kirjoitusjoukko ws(t ) koostuu siis T :n kirjoitusaikomuslistan tietoalkioiden tunnisteista (tietokantamallissamme monikoiden (x,v) avainarvoista x). 309
Esimerkiksi päivitysoperaatio W[x, v] tallennettaisiin listaan muodossa W[x, p,i,v], missä (p,i) on avainarvolla x varustetun monikon monikkotunniste sillä hetkellä, kun se paikannettiin tietokannasta operaatiota W[x, v] aloitettaessa. Operaation esitys W[x, p, i, v] sisältää siis arvauksen operaation kohteen sijaintipaikasta käytettäväksi hyväksi siinä vaiheessa, kun operaation tulos asennetaan tietokantaan. Mikäli monikon sijaintipaikka on siinä vaiheessa jo muuttunut, on monikko paikannettava uudestaan avainarvon x perusteella. Mikäli monikkoversioiden tallennus tietokantaan on pysyvää (kuten esim. PostgreSQL:ssä), versioidun monikon esitystapa tietokantasivulla voisi olla (x,(τ 1,v 1 ),...,(τ n,v n )), missä τ j on monikkoversion (x,τ j,v j ) luoneen transaktion sitoutumisleima ct(t ). Poistettua monikkoa tarkoittava monikkoversio esitetään erityisellä arvolla (τ j, ). 310
Kun transaktio T on päässyt loppuun ja pyytää sitoutumista, sen sitoutumiskelpoisuus tarkistetaan (validate). T on sitoutumiskelpoinen, jos st(t ) on suurempi tai yhtä suuri kuin kirjoitusjoukon ws(t ) tietoalkioiden versionumerot. Tarkistusta varten versiolaskuri salvataan. Jos näet T :n pyytäessä sitoutumista jollakin T :n päivittämällä tietoalkiolla x on versio (x,τ,v), missä τ > st(t ), niin jokin toinen transaktio T, nimittäin se, jolle τ = ct(t ), on päivittänyt x:n ja sitoutunut T :n ollessa aktiivisena. Tässä tapauksessa T pitää keskeyttää, koska T on ensimmäinen sitoutuja ja siis voittaa. Jos taas T :n pyytäessä sitoutumista T :n päivittämien tietoalkioiden x versionumerot ovat pienempiä tai yhtäsuuria kuin st(t ), niin mikään toinen samoja tietoalkioita päivittänyt transaktio ei ole ehtinyt sitoutua. Siispä T :lle myönnetään sitoutuminen: versiolaskuria kasvatetaan, asetetaan versiolaskurin arvo ct(t ):ksi, T :n kirjoitusaikomuslista käydään läpi, luodaan päivitettyjen tietoalkioiden uudet versiot versionumeroin ct(t ), asennetaan ne tietokantaan ja kirjataan päivitykset lokiin. Versiolaskuri pidetään salvattuna koko asennuksen kestoajan. 311
Edellä esitetty tilannevedoseristyvyyden toteutus sisältää optimistiselle samanaikaisuuden hallinnalle (optimistic concurrency control) tyypillisen piirteen: Transaktion annetaan tehdä lukuja ja päivityksiä toisia transaktioita odottamatta, so. varaamatta mitään lukkoja. Kun transaktio on päässyt loppuun, tarkistetaan, voidaanko transaktiolle myöntää sitoutuminen asetetun eristyvyystason puitteissa. Mikäli eristyvyyden havaitaan rikkoutuneen, transaktio keskeytetään ja peruutetaan. Lukitukseen perustuvat samanaikaisuuden hallintamenetelmät ovat tässä mielessä pessimistisiä, so. varautuvat eristysvyyden rikkomuksiin estämällä ne. Pessimistisissä menetelmissä transaktioita joudutaan keskeyttämään ainoastaan lukkiumatilanteissa. Lukkiumia taas ei puolestaan lainkaan esiinny sellaisissa optimistisissa käytännöissä, joissa ei käytetä mitään lukkoja. Lukkiumia ei myöskään esiinny eräissä pessimistisissä käytännöissä, kuten aikaleimakäytännöissä (timestamp protocol), joissa transaktioiden keskinäiseksi sarjallistuvuusjärjestykseksi pakotetaan transaktioiden (aloitus)aikaleimojen mukainen järjestys. (Lukituskäytännöissä kahden transaktion keskinäinen sarjallistuvuusjärjestys määräytyy ensimmäisen konfliktoivan operaation perusteella.) 312
Viivästettyjen päivitysten järjestelmässä keskeytetyn transaktion peruutus on sikäli yksinkertaista, ettei päivitysten käänteisoperaatioita ole lainkaan tarpeen suorittaa, koska päivityksiäkään ei ole asennettu tietokantaan. Mutta käänteisoperaatioiden suoritusta kirjoitusaikomuslistaan tarvitaan kuitenkin osittaisperuutuksissa. Viivästettyjen päivitysten järjestelmät ovat käytännössä harvinaisia niihin liittyvien ongelmien vuoksi. Päivitysten viivästämisen hallinta kirjoitusaikomuslistoineen on monimutkaista ja pitkän transaktion tapauksessa tilaavievää. Ja miten ja missä vaiheessa toteutetaan fyysisen tietokannan rakennemuutokset? Transaktion sitoutumiskelpoisuuden tarkistaminen ja päivitysten asennus ovat raskaita operaatioita, kun transaktio on tehnyt paljon päivityksiä. Vain yksi transaktio voi kerrallaan olla sitoutumassa ja asentamassa päivityksiä. 313
Tilannevedoseristyvyys voidaan toteuttaa myös välittömien päivitysten järjestelmässä käyttämällä kirjoituslukkoja, kuten menetellään Oraclessa. Erillisten kirjoitusten ominaisuus taataan seuraavasti: Kun transaktio T haluaa päivittää tietoalkion x, tutkitaan lukkotaulusta, onko millään toisella transaktiolla kirjoituslukkoa x:ää. (1) Jos millään toisella transaktiolla ei ole kirjoituslukkoa x:ään, määrätään x:n suurin versionumero τ. Jos τ > st(t ), T keskeytetään. Jos taas τ st(t ), T :lle myönnetään pitkäkestoinen kirjoituslukko x:ään ja siis lupa päivittää x. (2) Jos toisella transaktiolla T on kirjoituslukko x:ään, T odottaa T :n sitoutumista tai peruuntumista. Jos T sitoutuu, T keskeytetään. Jos taas T peruuntuu, T :lle myönnetään pitkäkestoinen kirjoituslukko x:ään ja siis lupa päivittää x (edellyttäen, ettei mikään muu transaktio ole odottamassa samaa lukkoa). Lukulukkoja ei siis käytetä. Luvut eivät siis koskaan odota mitään muita operaatioita eivätkä päivitykset koskaan odota lukuja, mutta päivitykset voivat odottaa päivityksiä, ja transaktio saatetaan keskeyttää kirjoituslukkoa odottaessaan (joko lukon haltijan sitoutumisen tai lukkiuman vuoksi). 314
Vaikka tilannevedoseristyvyys estää monet eristyvyysanomaliat, se ei kuitenkaan takaa sarjallistuvuutta. Tarkastellaan aiemmin esillä ollutta esimerkkiä toistokelvottoman luvun aiheuttamasta eheysrajoitteen rikkoutumisesta. Pankkitilitietokannan eheysrajoite lausuu, että tilien x ja y saldojen summa ei koskaan saa olla negatiivinen. Seuraavat transaktiot T 1 ja T 2 ovat eheysrajoitteen suhteen oikeellisia: kumpikin nollaa saldojen summan ottamalla sen yhdeltä tililtä. T 1 = BR[y,v]W[x,u, v]c (saldojen summan u + v otto tililtä x). T 2 = BR[x,u]W[y,v, u]c (saldojen summan u + v otto tililtä y). Transaktioiden ajoitus B 1 R 1 [y,v]b 2 R 2 [x,u]w 2 [y,v, u]c 2 W 1 [x,u, v]c 1 kuitenkin rikkoo eheysrajoitteen, kun saldojen summa u + v on positiivinen. Ajoituksen ainoa eristyvyysanomalia on T 1 :n toistokelvoton luku R 1 [y,v]. Transaktiot ovat triviaalisti tilannevedoseristyneitä, koska ws(t 1 ) ws(t 2 ) = {x} {y} = /0. 315
L O P P U 316