Tilannevedoseristyvyydessä esiintyvät eristyvyysanomaliat

Transkriptio

1 Tilannevedoseristyvyydessä esiintyvät eristyvyysanomaliat Pasi Oja-Nisula Helsinki Tietokannat nyt -seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 Sisältö i 1 Johdanto 1 2 Tilannevedoseristyvyyden toimintaperiaate 1 3 Tilannevedoseristyvyys verrattuna kaksivaihelukitukseen 5 4 Tilannevedoseristyvyydelle ominaiset eristyvyysanomaliat Kirjoitusvääristymä Lisäyksiä koskeva anomalia Lukutransaktioita koskeva anomalia Yhteenveto 15 Lähteet 15

3 1 Johdanto 1 Tilannevedoseristyvyydessä transaktiolle tarjotaan tiettyyn ajanhetkeen sidottu näkymä tietokantaan. Tilannevedoseristyvyys toteutetaan versioinnin avulla siten, että lukutransaktiot saavat tarvitsemansa tiedot aina transaktion alkuhetkellä muodostettavasta tietokannan sitoutunutta tilaa kuvaavasta näkymästä eli tilannevedoksesta. Rinnakkaiset kirjoitustransaktiot operoivat samojen tietoalkioiden uusiin versioihin. Lukutransaktioiden ei tarvitse varata lukkoja tietoalkioihin, joten lukutransaktiot eivät joudu lainkaan odottamaan kirjoitustransaktioita. Tämä rinnakkaisuuden lisäys tekee tilannevedoseristyvyydestä houkuttelevan käytännön transaktioiden samanaikaisuuden hallintaan. Tilannevedoseristyvyys takaa hyvän eristyvyyden transaktioiden välille ja siinä vältetään monet perinteisen kaksivaiheiseen lukitukseen perustuvien järjestelmien ongelmat. Tilannevedoseristyvyys ei kuitenkaan takaa sarjallistuvuutta. Jo tilannevedoseristyvyyden määritelleessä artikkelissa [BBG + 95] kuvattiin anomalia, joka syntyy kahden päivitystransaktion lomittuessa sopivasti. Pitkään oletettiin tilannevedoseristyvyyden olevan lukutransaktioiden suhteen sarjallistuva, sillä lukutransaktiot lukevat vain tilannevedoksen sisältämää sitoutunutta tietoa eikä tilannevedoksessa näy keskeneräisten transaktioiden tekemiä kirjoituksia. Yllättäen on kuitenkin mahdollista muodostaa transaktioiden limite, jossa lukutransaktio saa virheellisen kuvan tietokannasta, vaikka rinnakkaiset kirjoitustransaktiot toimivatkin oikein. Tässä seminaarityössä kuvataan tällainen Feketen ja kumppaneiden artikkelissaan [FOO04] esittämä anomalia. Luvussa 2 esitetään esimerkki tilannevedoseristyvyyden vaatimasta versioinnista ja kuvataan tilannevedoseristyvyyden toimintaperiaate yleisellä tasolla. Luvussa kuvataan myös yleisesti käytännön toteutuksissa käytetty muunnelma rinnakkaisten päivitysten aiheuttamien konfliktien ratkaisemiseen. Luvussa 3 vertaillaan tilannevedoseristyvyyttä perinteiseen kaksivaihelukitukseen ja ANSI SQL:n eristyvyystasoihin. Luvussa 4 esitellään nimenomaisesti tilannevedoseristyvyydessä esiintyviä anomalioita. Ensin käsitellään rinnakkaisia päivityksiä koskeva anomalia ja sen rinnakkaisiin lisäyksiin kohdistuva muunnelma. Luvussa käsitellään myös lukutransaktioita koskeva anomalia Feketen ja kumppaneiden artikkelin pohjalta. Anomaliasta esitetään myös esimerkki SQL-kielellä ja esitetään ratkaisuvaihtoehtoja anomalian estämiseksi. Luku 5 on yhteenveto. 2 Tilannevedoseristyvyyden toimintaperiaate Tilannevedoseristyvyys (snapshot isolation) on versiointiin perustuva menetelmä, joka yhdistelee aikaleimakäytäntöä ja kaksivaihelukitusta. Menetelmä voidaan näh-

4 dä kehittyneempänä muunnelmana Bernsteinin ja kumppanien multiversion mixed -käytännöstä, jonka kuvaus löytyy lähteestä [BHG87, sivu 160]. Uusimmissa transaktioiden samanaikaisuudenhallintaa käsittelevissä artikkeleissa tilannevedoseristyvyys määritellään yleensä artikkelista [BBG + 95] löytyvällä tavalla. Tilannevedoseristyvyys tai sen muunnelmat ovat käytössä useissa tietokannanhallintajärjestelmissä. Oracle ja PostgreSQL ovat perustaneet samanaikaisuudenhallintansa tilannevedoseristyvyyteen jo pitkään. Microsoft SQL Server on aiemmin perustunut perinteiseen kaksivaihelukitukseen, mutta uudessa versiossa (SQL Server 2005) tämän rinnalle on tullut myös tilannevedoseristyvyys [FLO + 05]. Tilannevedoseristyvyydessä transaktion tekemät luvut kohdistuvat vain ennen transaktion alkua sitoutuneiden transaktioiden kirjoittamiin tietoalkioihin. Transaktio näkee näin ollen kuvan, tilannevedoksen, tietokannan tilasta aloitushetkellään. Samanaikaisesti aktiivisena olevien transaktioiden päivitykset eivät vaikuta transaktion näkemään tilannevedokseen. Poikkeuksen tästä muodostavat transaktion omat päivitykset, jotka voivat muuttaa transaktion omaa tilannevedosta [BBG + 95]. Tilannevedoseristyvyydessä käytetyn versioinnin teknisiä toteutustapoja on monia. Tämän esityksen puitteissa ei ole mahdollista käydä näitä tapoja tarkemmin läpi, mutta tilannevedoseristyvyyden hyöty tulee selkeimmin ilmi versiointia käsittelevän esimerkin avulla. Tarkastellaan siis Oraclen käyttämää versiointia hieman yksinkertaistetussa muodossa. Oraclessa jokaiselle transaktiolle annetaan sen alussa järjestelmämuutosnumero (system change number, SCN). Tämä on käytännössä aikaleimaa vastaavan laskurin numero, joka määrää transaktiolle tietokannassa näkyvän tilannevedoksen. Oraclessa versioinnin yksikkö on tietolohko (data block). Vaikka tietolohko ei teknisesti välttämättä olekaan saman kokoinen kuin sivu, versioinnin toteutusnäkökohtia tutkittaessa voidaan nämä käsitteet samaistaa. Tietolohkoa päivitettäessä siihen merkitään sitä päivittäneen transaktion SCN. Toinen oleellinen seikka on Oraclen tapa jakaa tietueiden tallennus eri segmentteihin. Tietueiden nykyversiot tallennetaan datasegmenttiin (data segment) ja vanhat versiot peruutussegmenttiin (rollback segment). Oraclen moniversioivan lukujohdonmukaisuuden toimintaa voidaan kuvata seuraavan esimerkin avulla [IBM02]. Kuvassa 1 on esitetty nuolella valituksi tulevat tietolohkot [Ora05, sivu 13-3]. 1. Transaktio suorittaa kyselyn select from T, joka kohdistuu taulun T kaikkiin tietueisiin. Kyselylle annetaan SCN ja aloitetaan taulun läpikäynti. 2. Luetaan tietolohko datasegmentistä puskurimuistiin. 3. Jokaisen tietolohkon kohdalla tutkitaan tietolohkon SCN. Jos se on pienempi kuin kyselyn SCN, luetaan tietolohko ja jatketaan skannausta seuraavasta tietolohkosta. Jos SCN on kuitenkin suurempi kuin kyselyllä (kuvassa 10024) siirrytään seuraavaan kohtaan. 4. Peruutussegmentistä haetaan tietolohkon edellinen versio (kuvassa tietoloh- 2

5 ko, jonka SCN on 10008). Jos tämänkin tietolohkon SCN on suurempi kuin kyselyllä, haetaan peruutussegmentistä lisää uusia tietolohkoja, kunnes löytyy kyselyn alkuhetkeä vanhempi versio. Tämä versio on lopullisesti se, josta kyselyn tulokset luetaan. 5. Siirrytään kohtaan 2 jatkamaan käsittelyä seuraavasta tietolohkosta. 3 select from T (SCN 10023) Peruutussegmentti Kuva 1: Oraclen moniversioivan lukujohdonmukaisuuden toimintaperiaate Kuvan 1 esimerkistä nähtiin lukutransaktion valmistuvan huolimatta samanaikaisista päivitystransaktioista. Mahdollisesti useat päivitystransaktiot olivat edelleen kesken ja osa taulun tietueista oli lukittuna kirjoituslukoilla. Kaksivaihelukitukseen perustuvissa järjestelmissä vastaavan suorituskyvyn saavuttamiseksi olisi vaadittu lukutransaktion suorittamista read uncommitted -eristyvyystasolla. Tilannevedoseristyvyydessä puolestaan lukutransaktio luki ainoastaan sitoutuneita tietueita. Huomattavaa on myös, että luetut tietueet olivat lukutransaktion alkuhetkellä viimeisimpiä sitoutuneita versioita. Näin ollen lukutransaktio näki aloitushetkellään tietokannassa vallinneen sitoutuneen tilanteen. Palataan Oraclen parista jälleen tarkastelemaan tilannevedoseristyvyyttä yleisemmällä tasolla. Tilannevedoseristyvyydessä tilannevedos toteutetaan siten, että transaktiolle annetaan alkuhetkellään aikaleima s-ts(t i ). Tämän aikaleiman jälkeen tapahtuvat kirjoitukset eivät näy transaktiolle. T i ei myöskään näe samanaikaisten, vielä sitoutumattomien, transaktioiden ennen aloitusaikaleimaa tekemiä päivityksiä. Tämä johtuu siitä, että tilannevedoseristyvyydessä transaktiot noudattavat niin sanottua ensimmäinen sitoutuja voittaa (first-committer-wins) -käytäntöä. Tämä

6 tarkoittaa sitä, että T i sitoutuu vain, mikäli mikään samanaikaisesti suorituksessa ollut, mutta aiemmin sitoutunut transaktio T k ei ole päivittänyt tietoalkioita, joita T i aikoo päivittää. Tämä tarkistus tehdään käyttäen transaktion T i alkuaikaleimaa s-ts(t i ) ja sitoutumisaikaleimaa c-ts(t i ). Jos jokin ehdon s-ts(t i ) < c-ts(t k ) < c- ts(t i ) täyttävä transaktio T k on kirjoittanut samoja tietoalkioita kuin T i, aiheuttaa tämä T i :n peruuntumisen. Sitoutumisen onnistuessa tulevat kaikki T i :n tekemät päivityksen näkyviin aikaleiman c-ts(t i ) jälkeen aloittaville transaktioille [BBG + 95]. Tilannevedoseristyvyydessä siis transaktion tekemät kirjoitukset voidaan ajatella suoritettaviksi yhdellä ajanhetkellä transaktion sitoutuessa, vastaavasti kuin luvutkin suoritetaan tiettyyn ajanhetkeen kohdistuen. Ensimmäinen sitoutuja voittaa -käytännöstä on olemassa muunnelma, jota käytetään esimerkiksi Oraclessa ja PostgreSQL:ssä. Muunnelmaa kutsutaan nimellä ensimmäinen päivittäjä voittaa (first updater wins). Ensimmäinen päivittäjä voittaa -käytännössä voittajan tarkistus suoritetaan aina päivityksen yhteydessä, jolloin transaktion peruuntuessa hukkaan menee mahdollisimman vähän prosessointia. Oraclen ensimmäinen päivittäjä voittaa -algoritmi toimii seuraavasti. Oletetaan että transaktio T i päivittää tietoalkiota x ja saa siihen kirjoituslukon. Jos T i :n kanssa rinnakkain suoritettava transaktio T j yrittää päivittää x:ää, se ei saa lukkoa ja joutuu odottamaan. T j :n kohtalo riippuu tämän jälkeen T i :n lopputuloksesta. Jos T i sitoutuu, aiheuttaa se T j :n peruuntumisen. Jos T i peruuntuu, saa T j lukon haltuunsa ja voi jatkaa suoritustaan [FLO + 05]. Seuraavassa esitetään esimerkki Oraclen ensimmäinen päivittäjä voittaa -käytännöstä. Esimerkissä transaktio T 1 jää odottamaan T 2 :n sitoutumista. Transaktion T 2 sitouduttua T 1 :n päivitys päättyy sarjallistuvuusvirheeseen (serialization error), ORA SQL> /* T1 */ SQL> select sal from emp where empno=7934; SAL SQL> update emp set sal = sal where empno=7934; ERROR at line 1: ORA-08177: can t serialize access for this transaction SQL> /* T2 */ SQL> update emp set sal = sal + 100; 14 rows updated.

7 Edellistä esimerkkiä hieman muokaten voidaan havainnollistaa toinenkin tilanne, jossa päädytään sarjallistuvuusvirheeseen. Oletetaan edelleen, että T i ja T j ovat rinnakkaisia transaktioita. Nyt kuitenkin T i sitoutuu ennen kuin T j yrittää päivitystä tietoalkioon x [FLO + 05]. Tällöin T i :n yrittäessä päivitystä tiedetään heti T j :n suorittaneen sitoutuneen päivityksen ja T i :lle palautetaan sarjallistuvuusvirhe. Edellisessä esimerkissä tilanne saataisiin aikaan siirtämällä T 1 :n update-lause suoritettavaksi T 2 :n sitoutumisen jälkeen. Tällöin sarjallistuvuusvirhe palautuu heti, sillä T 2 sitoutumista ei tarvitse enää odottaa. 5 3 Tilannevedoseristyvyys verrattuna kaksivaihelukitukseen ANSI SQL määrittelee transaktioille neljä eristyvyystasoa: read uncommitted, read committed, repeatable read ja serializable. Tilannevedoseristyvyyttä ei voi suoraan sijoittaa ANSI SQL:n eristyvyystasojen hierarkiaan, johtuen lähinnä ANSIn määritelmien vahvasta nojautumisesta lukituksiin perustuviin toteutuksiin. Tilannevedoseristyvyys on kuitenkin laajalti käytetty eristyvyystaso, ja määritelmästä riippumatta sillä saavutetaan hyvä eristyvyys transaktioiden välille. Seuraavassa tarkastellaan tilannevedoseristyvyyttä verrattuna ANSI SQL:n määrittelemiin eristyvyystasoihin. Versioivien järjestelmien historioita käsiteltäessä transaktioiden T 1, T 2,..., T n tekemiä lukuja, kirjoituksia, peruuntumista ja sitoutumista merkitään normaaliin tapaan r i [x], w i [y], a i ja c i. Tarvittaessa voidaan merkitä myös tietoalkion x arvo näkyviin operaation kohdalle, esimerkiksi r 1 [x = 10]. Versiointiin perustuvissa käytännöissä kirjoitusoperaatio w[x] luo aina uuden version tietoalkiosta x. Versionumero kirjoitetaan näkyviin tietoalkion yhteyteen. Esimerkiksi r 1 [x 0 = 10] tarkoittaa, että transaktio T 1 lukee transaktion T 0 kirjoittaman x:n arvon 10. Kirjoitusoperaatiossa w i [x i ] luodun uuden version numero on siis aina kirjoittavan transaktion numero. Transaktiolla T 0 viitataan kuvitteelliseen tietokannan alkuarvot kirjoittavaan transaktioon. Tilannevedoseristyvyys ei kärsi sitoutuneiden transaktioiden likaisista kirjoituksista, sillä sitoutumisvaiheessa suoritettava tarkistus aiheuttaa transaktion peruuntumisen, mikäli transaktion kirjoittamaa tietoalkiota on sen elinaikana muutettu. Myöskään likaisia lukuja ei tapahdu, sillä aikaleimakäytännön ansiosta transaktiot lukevat vain sitoutuneita tietoja [BBG + 95]. Tämä tekee tilannevedoseristyvyydestä vähintään yhtä vahvan eristyvyystason kuin read committed. Tarkastellaan historiaa H 1 : r 1 [x 0 = 50] r 2 [x 0 = 50] w 2 [x 2 = 70] c 2 w 1 [x 1 = 60] a 1. Yksiversiokäytäntöön ja kaksivaihelukitukseen perustuvassa järjestelmässä read committed -eristyvyystasolla suoritettaessa historian H 1 yksiversiomuunnelma olisi mahdollinen ja transaktio T 1 sitoutuisi lopussa aiheuttaen hukatun päivityksen. Tämä

8 johtuu read committed -eristyvyystason lyhytkestoisista lukulukoista. Tilannevedoseristyvyydessä historia kuitenkin hylätään, sillä sitoutumisvaiheen tarkistuksessa huomataan T 1 :n kanssa rinnakkaisen sitoutuneen transaktion T 2 kirjoittaneen tietoalkion, jonka T 1 olisi aikeissa kirjoittaa. Tilannevedoseristyvyys ei siis mahdollista historioita, joissa tapahtuu hukattu päivitys, toisin kuin read committed - eristyvyystaso. Näin ollen voidaan sanoa tilannevedoseristyvyyden olevan read committed -tasoa vahvempi [FLO + 05]. Repeatable read -eristyvyystason kohdalla vertailu ei ole enää aivan suoraviivaista. ANSI SQL:n määritelmän mukaan toistokelvoton luku tapahtuu, kun transaktio T 1 lukee tietoalkion x, minkä jälkeen toinen transaktio T 2 päivittää x:ää, ja T 2 :n sitouduttua T 1 lukee x:n uudelleen. Koska tilannevedoseristyvyydessä luvut kohdistuvat tietyllä ajanhetkellä voimassa olleeseen tilanteeseen, ei tällaista anomaliaa luonnollisestikaan voi tapahtua. Tässä mielessä tilannevedoseristyvyys on vahvempi kuin repeatable read. Jos edelleen pitäydytään ANSIn määritelmissä eristyvyysanomalioille, myöskään haamuja ei tilannevedoseristyvyydessä esiinny. Tästä näkökulmasta katsottuna tilannevedoseristyvyyden voisi sanoa olevan jopa yhtä vahva kuin serializable [BBG + 95]. Tilannevedoseristyvyys kärsii kuitenkin myöhemmin esiteltävästä lukulukkojen puuttumisen aiheuttamasta anomaliasta ja on toisaalta siis heikompi kuin serializable ja jopa repeatable read -eristyvyystasot. Kaikkiaan voidaan siis sanoa, että vaikka tilannevedoseristyvyys tarjoaa hyvän eristyvyyden transaktioiden välille, se ei tarjoa tietokantateorian mukaista sarjallistuvuutta [BHG87, sivu 32]. Tilannevedoseristyvyyteen perustuvat tietokannat, esimerkiksi Oracle ja Postgre- SQL, kuitenkin sisältävät serializable-eristyvyystason. Tämä johtuu siitä, että tietokantavalmistajien kielenkäytössä sarjallistuvuus on seuraus ANSI SQL -standardissa mainittujen anomalioiden (likaisten lukujen, toistokelvottomien lukujen ja haamujen) esiintymättömyydestä. SQL 2003-standardiin on lisätty mielenkiintoinen huomautus tähän liittyen. Eristyvyystasojen määrittelyn yhteydessä standardissa todetaan serializable-eristyvyystasolla suoritettaessa anomalioiden esiintymättömyyden olevan nimenomaan seuraus transaktioiden sarjallistuvuudesta [ISO03, sivu 118]. Tämä ero sarjallistuvuuskäsitteen määritelmässä johtaa siihen, että myöhemmin tässä luvussa esiteltävät sarjallistumattomat historiat ovat mahdollisia tilannevedoseristyvyyteen perustuvien järjestelmien serializable-eristyvyystasolla. 6 4 Tilannevedoseristyvyydelle ominaiset eristyvyysanomaliat Versiointiin perustuvasta luonteestaan johtuen tilannevedoseristyydessä esiintyy joitain eristyvyysanomalioita, jotka vältetään kaksivaihelukitusta käyttävissä järjestelmissä. Erityisesti IBM on korostanut kaksivaihelukituksen paremmuutta tilannevedoseristyvyyteen nähden [IBM02]. Tässä luvussa kuvattujen anomalioiden esiintyminen ei kuitenkaan välttämättä ole yleistä todellisissa tietokantasovelluksissa. Esimerkiksi monia sovellustyyppejä edustava TPC-C -testi ei sisällä lainkaan näitä

9 nimenomaisesti tilannevedoseristyvyyttä haittaavia anomalioita [FLO + 05]. Eräs ongelma tilannevedoseristyvyydessä on ollut sarjallistuvuuden varmistavan analyysimenetelmän puute. Artikkelissaan [FLO + 05] Fekete ja kumppanit kuvaavat menetelmän, jolla tilannevedoseristyvyydessä suoritettavat transaktiot voidaan analysoida ja tarvittaessa muokata sovelluksista versiot, jotka päätyvät sarjallisten historioiden kanssa samaan lopputulokseen. Menetelmä soveltuu kuitenkin huonosti suurten tietokantasovellusten analysointiin, sillä analyysi on varsin raskas prosessi ja heikosti automatisoitavissa. Käytännön tietokantajärjestelmissä tilannevedoseristyvyyden anomaliat estetään parhaiten ymmärtämällä tilannevedoseristyvyyden toimintaperiaatteet ja suunnittelemalla transaktiot tämä huomioiden. Kaikki tässä luvussa esitetyt anomaliat voidaan estää käyttäen hyväksi joko sopivaa tietokannan taulurakennetta tai tietokantajärjestelmän tarjoamia lukitusominaisuuksia Kirjoitusvääristymä Tarkastellaan seuraavaa tilannevedoseristyvyyteen perustuvassa järjestelmässä suoritettavaa esimerkkiä [BBG + 95]. Oletetaan, että x ja y esittävät pankkitilien saldoja. Annetaan tietokantaan eheysrajoite, että tili voidaan ylittää, kunhan tilien yhteissumma säilyy positiivisena, eli x + y > 0. Ajatellaan tilannevedoseristyvyystasolla suoritettavaksi historia H 2 : r 1 [x 0 = 70] r 2 [x 0 = 70] r 1 [y 0 = 80] r 2 [y 0 = 80] w 1 [x 1 = 30] c 1 w 2 [y 2 = 20] c 2 Historiassa H 2 esiintyy Berensonin ja kumppaneiden määrittelemä anomalia A5B, kirjoitusvääristymä (write skew). Ensimmäinen sitoutuja voittaa -käytäntö ei kuitenkaan estänyt tilannetta, sillä anomalian aiheuttavat eri tietoalkioihin kohdistuvat päivitykset. Tarkastellaan samaa esimerkkiä Oraclessa.

10 8 SQL> /* T1 */ SQL> select * from bank where account in (1,2); ACCOUNT BALANCE SQL> /* Eheystarkistus */ SQL> /* T2 */ SQL> select * from bank where account in (1,2); ACCOUNT BALANCE SQL> update bank set balance=-30 where account=1; 1 row updated. SQL> /* Eheystarkistus */ SQL> update bank set balance=-20 where account=2; 1 row updated. Edellisestä esimerkistä voidaan havaita, että lukulukkojen puuttuminen aiheuttaa tietokannan eheydelle ongelman. Eheystarkistus ajatellaan tapahtuvaksi sovellustasolla heti kun tilien 1 ja 2 saldot on luettu. Koska transaktioiden T 1 ja T 2 päivitykset kohdistuvat eri riveihin, ei päivityksistä aiheudu konfliktia. Tämän takia molemmat transaktiot saavat suoritettua päivityksen ja sitoutumisen. T 1 :n ja T 2 :n loputtua tietokannassa sekä tilin 1 että 2 saldot ovat negatiivisia. Erikseen kummassa tahansa järjestyksessä T 1, T 2 tai T 2, T 1 suoritettuina sovelluksen eheystarkistus huomaisi ongelman ja jälkimmäinen päivitys jätettäisiin suorittamatta. Edellisen esimerkin ongelma voi esiintyä myös kaksivaiheihelukitukseen perustuvassa tietokantajärjestelmässä, mutta vain jos transaktioita suoritetaan read committed -eristyvyystasolla [JBD + 95]. Repeatable read -eristyvyystasolla toimittaessa pitkäkestoiset lukulukot olisivat estäneet tilanteen.

11 Oraclessa kirjoitusvääristymä-anomalia voidaan estää select for update -lauseen avulla. Select for update lukitsee luetut rivit sitoutumiseen asti, jolloin esimerkin jälkimmäisen transaktion select-lause jäisi odottamaan lukkojen vapautumista. Koska transaktio T 1 suorittaa kuitenkin päivityksen, lukkojen vapauduttua T 2 :lle ilmoitettaisiin sarjallistuvuusvirheestä Lisäyksiä koskeva anomalia Berenson ja kumppanit kritisoivat artikkelissaan [BBG + 95] ANSIn eristyvyystasojen määritelmiä ja esittävät anomalioiden laajennetut määritelmät. Tällainen laajan määritelmän mukainen haamuilmiö voi tapahtua myös tilannevedoseristyvyydessä, mikäli transaktiot suorittavat useiden tietoalkioiden lisäyksiä. Seuraavassa on esitetty Berensonin ja kumppaneiden artikkelissa kuvaama anomalia. Tässä esityksessä käytetään Feketen ja kumppaneiden artikkelissaan [FLO + 05] kuvaamien tietokantataulujen nimiä. Tarkastellaan työajanseurantajärjestelmää, johon tallennetaan tietoa työntekijöiden ajankäytöstä projekteittain. Työntekijän (tietokannan employees-taulu) työpäivä koostuu erillisistä tehtävistä (assignments), joista jokainen kuuluu tiettyyn projektiin (projects). Tehtävä koostuu työntekijän (eid) ja projektin tunnisteista (projid), työpäivästä (workdate) ja tehtävään varatuista tunneista (hours). Tietokannassa vallitsee eheysrajoite, joka rajaa työntekijän työpäivän kokonaiskeston 8 tuntiin. Historiassa esiintyvä operaatio pr tarkoittaa predikaattiin kohdistuvaa lukua. Historiassa H 3 : pr 1 [P, ] w 1 [y 1 = ( e1234, 2, , 5)] pr 2 [P, ] w 2 [z 2 = ( e1234, 3, , 5)] c 1 c 2 predikaatti P määrittelee luvun kohdistuvan tietueisiin, joille eid= e1234 ja workdate= Tällaisia tietueita ei tietokannassa vielä ole, joten transaktiot T 1 ja T 2 lukevat tyhjän tulosjoukon. Tämän perusteella molemmat transaktiot päättelevät työntekijälle olevan mahdollista lisätä vielä 5 tunnin mittaisen tehtävän. Koska transaktiot T 1 ja T 2 eivät päivitä samaa tietoalkiota, ensimmäinen sitoutuja voittaa -käytäntö ei estä tilannetta. Sarjallisesti suoritettuna tilanne ei olisi mahdollinen, sillä jälkimmäisen transaktion kohdalla eheysrajoite estäisi työtehtävän lisäyksen [BBG + 95]. Anomalia on oleellisilta osiltaan esitetty seuraavien SQL-lauseiden avulla.

12 10 SQL> /* T1 */ SQL> select sum(hours) from assignments where eid = e1234 and workdate = ; SUM(HOURS) SQL> /* Alle 8 tuntia, lisätään! */ SQL> insert into assignment (eid, projid, workdate, hours) values ( e1234, 2, , 5); 1 row created. SQL> /* T2 */ SQL> select sum(hours) from assignments where eid= e1234 and workdate= ; SUM(HOURS) SQL> /* Alle 8 tuntia, lisätään! */ SQL> insert into assignment (eid, projid, workdate, hours) values ( e1234, 3, , 5); 1 row created. Anomalia johtuu selvästi eri tietoalkiohin kohdistuvista päivityksistä aivan kuten kirjoitusvääristymäkin. Kyseessä on kuitenkin erillinen anomalia, sillä tässä tapauksessa select for update -lauseella ei voida korjata tilannetta. Koko taulun lukitseminen estäisi anomalian, mutta rajoittaisi rinnakkaisuutta tarpeettomasti. Anomalia on kuitenkin mahdollista välttää lisäämällä tietokantaan työntekijän työpäivän kes-

13 toa kuvaava taulu (total work hours). Transaktioiden on päivitettävä tämän taulun työntekijä/päivä -parin yksilöimää riviä aina lisättyään uuden tehtävän työntekijälle. Nyt transaktioiden välille aiheutuu konflikti tämän taulun päivityksestä ja jälkimmäisenä sitoutumista (päivitystä) yrittävä transaktio peruutetaan Lukutransaktioita koskeva anomalia Tilannevedoseristyvyyden ajateltiin pitkään olevan sarjallistuva lukutransaktioiden suhteen. Kyselyiden ei koskaan tarvitse odottaa tai peruuntua päivitystransaktioiden takia, vaan ne lukevat tietokannan tilanteen tietyllä ajanhetkellä. Koska tietyn ajanhetken tilanne sisältää vain sitoutuneiden transaktioiden kirjoittamaa tietoa, ajateltiin tämän olevan implisiittinen tae kyselyiden sarjallistuvuudesta. Artikkelissaan Fekete ja kumppanit esittelevät kuitenkin kyselyitä koskevan anomalian, joka esiintyy nimenomaisesti tilannevedoseristyvyydessä [FOO04]. Kyselyitä koskeva anomalia on esitelty seuraavassa. Oletetaan jälleen, että x ja y esittävät pankkitilejä, mutta tällä kertaa molempien saldo on alussa 0. Jälleen tietokannassa on voimassa tilien yhteissummaa koskeva rajoite. Rajoite määrää, että mikäli tililtä noston seurauksena summa x + y < 0, tililtä veloitetaan ylimääräisenä sakkona 1 yksikkö. Historiassa esiintyvä transaktio T 1 tallettaa 20 tilille y, transaktio T 2 nostaa 10 tililtä x ja kysely T 3 hakee tilien saldot tulostusta varten. Tilannevedoseristyvyydessä transaktiot voivat tuottaa historian H 4 : r 2 [x 0 = 0] r 2 [y 0 = 0] r 1 [y 0 = 0] w 1 [y 1 = 20] c 1 r 3 [x 0 = 0] r 3 [y 1 = 20] c 3 w 2 [x 2 = 11] c 2. Historia H 4 tuottaa anomalian, jossa kyselytransaktio T 3 näkee tilien arvot 0 ja 20, vaikka tietokannassa arvot ovat transaktioiden suorituksen jälkeen -11 ja 20. Ongelma on siinä, että kysely T 3 näkee tilannevedoseristyvyydessä sitoutuneen transaktion T 1 lopputuloksen, mutta ei samanaikaisen transaktion T 2 tuloksia. Kuitenkin tietokannassa esiintyvän lopputuloksen kannalta päivitystransaktiot tulisi sarjallisesti suorittaa järjestyksessä T 2, T 1. Tilannevedoseristyvyydessä siis sitoutumisjärjestys voi olla jokin muu kuin sarjallisesti transaktiot suoritettaessa [FOO04]. Artikkelissaan Fekete ja kumppanit eivät käsittele anomalian esiintymistä käytännön tietokantajärjestelmissä. Anomalian estämisen tarkastelua varten tällainen tarkastelu on kuitenkin hyödyllistä. Seuraavassa historian H 4 luvut ja kirjoitukset on muunnettu Oraclen SQL-lauseiksi.

14 12 A BALANCE x 0 y 0 SQL> /* T1 */ SQL> select balance from accounts where accid= y ; BALANCE SQL> update accounts set balance=20 where accid= y ; 1 row updated. SQL> /* T2 */ SQL> select accid, balance from accounts where accid in ( x, y ); SQL> /* T3 */ SQL> select accid, balance from accounts where accid in ( x, y ); SQL> update accounts set balance=-11 where accid= x ; 1 row updated. A BALANCE x 0 y 20

15 Oraclessa suoritus tuotti saman anomalian kuin historiassa H 4. Lukutransaktioita koskevan anomalian estäminen ei ole yhtä suoraviivaista kuin kirjoitustransaktioita koskevien transaktioiden tapauksessa. Ensimmäinen ratkaisuehdotus on kyselytransaktion T 3 muuttaminen käyttämään select for update -lausetta. Lopputulos näkyy seuraavassa. Tilan säästämiseksi suorituksesta näytetään vain muuttuneet osat. 13 SQL> /* T2 */... SQL> /* T3 */ SQL> select accid, balance from accounts where accid in ( x, y ) for update; SQL> update accounts set balance=-11 where accid= x ; ERROR at line 1: ORA-08177: can t serialize access for this transaction A BALANCE x 0 y 20 Select for update -lause transaktiossa T 3 aiheutti sarjallistuvuusvirheen transaktion T 2 päivitykseen. Kun transaktio T 2 käynnistetään uudelleen, se lukee alussa T 1 :n päivityksen ja asettaa tilin y saldoksi -10. Transaktiot sarjallistuivat nyt järjestyksessä T 1, T 2. Lisäksi transaktio T 3 luki tietokannasta eheän, transaktion T 1 suorituksen jälkeen vallinneen, tilan. Ratkaisun ongelma on kuitenkin kyselytransaktion toiselle transaktiolle aiheuttama sarjallistuvuusvirhe, joka voidaan tulkita tilannevedoseristyvyyden periaatteiden vastaiseksi. Parempi ratkaisuehdotus voisi olla select for update -lauseen käyttö transaktioiden T 1 ja T 2 suorituksessa. Tarkastellaan tämän ratkaisuvaihtoehdon vaikutuksia.

16 14 SQL> /* T2 */ SQL> select accid, balance from accounts where accid in ( x, y ) for update; SQL> /* T1 */ SQL> select balance from accounts where accid= y for update; A BALANCE x 0 y 0 SQL> update accounts set balance=-11 where accid= x ; 1 row updated. ERROR at line 1: ORA-08177: can t serialize access for this transaction Tämä ratkaisu toimii paremmin, sillä nyt select for update -lause pakottaa jälkimmäisen päivitystransaktion jäämään odottamaan kirjoituslukkoa tiliin. Kun lukko saadaan, huomataan heti sarjallistuvuusvirhe. Tässä vaiheessa transaktio voidaan aloittaa uudelleen. Näin ollen transaktiot itse asiassa suoritetaan sarjallisesti järjestyksessä T 2, T 1, kuten tietokannassa näkyvä lopputulos vaatiikin. Edelliseen esimerkkiin ei ole merkitty näkyviin transaktiota T 3, mutta on helppoa nähdä, että sijoitettiinpa se mihin väliin tahansa, se ei voi enää nähdä ainoastaan transaktion T 1 lopputulosta. Ratkaisun ongelma on luonnollisesti päivitystransaktioiden suorituskyvyn heikkeneminen. Tilannevedoseristyvyyden oleellisin hyöty eli lukutransaktioiden suoritus kirjoitustransaktioista riippumatta säilyy kuitenkin entisellään.

17 5 Yhteenveto 15 Edellä esitettyjen anomalioiden valossa on selvää, että tilannevedoseristyvyys ei välttämättä tuota sarjallistuvia historioita. Tästä syystä sarjallistuvia historioita tuottavaa kaksivaihelukitusta voitaisiin pitää parempana samanaikaisuuden hallinnan menetelmänä. Transaktioiden sarjallistuvuuden varmistaminen rajoittaa kuitenkin järjestelmän suorituskykyä. Tämän takia kaikkien suurten tietokantavalmistajien kaksivaihelukitukseen perustuvat tietokantajärjestelmät toimivat oletuksena sarjallistuvuutta matalammalla eristyvyystasolla. Tästä näkökulmasta katsottuna tilannevedoseristyvyys tarjoaakin kilpailukykyisen kompromissin suorituskyvyn ja eristyvyyden suhteen. Monet tilannevedoseristyvyydessä esiintyvät anomaliat ovat korjattavissa kohtuullisen helposti tässäkin esityksessä kuvatuilla tavoilla. Tietokantasovelluksen oikean toiminnan kannalta onkin oleellista huomioida myös samanaikaisuudenhallinnan mekanismi transaktioita ohjelmoitaessa. Lähteet BBG + 95 BHG87 FLO + 05 FOO04 IBM02 ISO03 JBD + 95 Berenson, H., Bernstein, P., Gray, J., Melton, J., O Neil, E. ja O Neil, P., A critique of ANSI SQL isolation levels. SIGMOD 95: Proceedings of the 1995 ACM SIGMOD International Conference on Management of Data, New York, NY, USA, 1995, ACM Press, sivut Bernstein, P. A., Hadzilacos, V. ja Goodman, N., Concurrency Control and Recovery in Database Systems. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, Fekete, A., Liarokapis, D., O Neil, E., O Neil, P. ja Shasha, D., Making snapshot isolation serializable. ACM Trans. Database Syst., 30,2(2005), sivut Fekete, A., O Neil, E. ja O Neil, P., A read-only transaction anomaly under snapshot isolation. SIGMOD Rec., 33,3(2004), sivut IBM Software Group Toronto Laboratory, A technical discussion of multi version read consistency, August ftp://ftp.software. ibm.com/software/data/pubs/papers/readconsistency.pdf. [ ] ISO, ISO/IEC :2003 Information technology Database languages SQL Part 2: Foundation (SQL/Foundation), http: // [ ] Jacobs, K., Bamford, R., Doherty, G., Haas, K., Holt, M., Putzolu, F. ja Quigley, B., Concurrency control: transaction isolation and serializabi-

18 lity in SQL92 and Oracle7. Oracle White Paper A33745, Oracle Corp., July Ora05 Oracle Corp., Oracle Database Concepts 10g Release 2 (10.2). Oracle Corp., June 2005.