Tietokantatapahtuman hallinta

1. Tietokantatapahtuman hallinta • Jotta tietokanta pysyisi luotettavana ja eheänä, tulee kiinnittää huomiota kolmeen lähellä toisiaan olevaan toimintoon: tietokantatapahtuman (transaction) tukeminen, samanaikaisuuden (concurrency) hallinta ja elvytysmekanismit (recovery). • Kaikki nämä kolme osa-aluetta ovat kiinteästi riippuvaisia toisistaan. • Jotta olisi helpompi ymmärtää samanaikaisuuden hallintaa ja elvytysmekanismeja, tulee ensiksi ottaa selville tietokantatapahtuman perusteet. tMyn

2. Tietokantatapahtuma (transaction) on mikä tahansa luku- tai muutostapahtuma tietokantaan, jonka tekee yksittäinen käyttäjä tai yksittäinen sovellusohjelma. • Edelleen: luku- tai muutostapahtuma tietokantaan voi puolestaan olla kokonainen sovellusohjelma, osa sitä tai sitten pelkästään yksittäinen SQL komento (vaikkapa INSERT tai UPDATE). Oleellista on, että tämä tapahtuma on tarkastelun kannalta yksittäinen looginen työn yksikkö (logical unit of work), joka kohdistetaan tarkasteltavaan tietokantaan. • Tyypillisesti sovellusohjelma tekee monia asioita saamillaan parametreilla, ja vain pieni osa koodista keskittyy tietokantatapahtumiin. tMyn

3. Tietokantatapahtuma voi päättyä kahdella tavalla. Jos kaikki sujuu toivotulla tavalla, niin tapahtuma vahvistetaan (COMMIT), ja tietokanta siirtyy uuteen, eheään tilaan. Jos jotakin ei-toivottua tapahtuu tapahtuman aikana, niin tapahtuma keskeytetään (abort). Tällaisessa tapauksessa tietokanta on palautettava lähtötilanteessa olleeseen eheään tilaan (ROLLBACK). • Jos tapahtuma on vahvistettu (COMMIT), niin sitä ei enää voida palauttaa (ROLLBACK) lähtötilanteessa olleeseen eheään tilaan. Uusi transaktio voi tietysti muuttaa tietoalkioiden arvoja edelleen. • Tietokantatapahtuman tilakaavio näyttää seuraavanlaiselta, kuva 1: tMyn

4. End Transaction Commit Begin Transaction Abort Abort Kuva 1. Tietokantatapahtuman tilakaavio. tMyn

5. Transaktion tilasiirtymämalliin kuvaan 1 oli merkitty seuraavat tilat: • Aktiivinen (active). Transaktio suorittaa varsinaisia operaatioitaan (luku/kirjoitus) • Osittain sitoutunut (partially committed). Transaktion ohjelmakoodi on suoritettu ja se on pyytänyt sitoutumista (commit-operaatiolla). • Sitoutunut (committed). DBMS on vahvistanut transaktion tietokantaan tekemät muutokset pysyviksi eli sitoutuminen on onnistunut. Tietokannan muutokset eivät enää ole peruttavissa ilman uutta transaktiota. tMyn

6. Epäonnistunut (failed). Sitoutuminen on epäonnistunut (esim. samanaikaisuuden hallintaan liittyvien tarkistusten takia). • Keskeytetty (aborted). Epäonnistunut transaktio on peruutettu eli tietokanta on palautettu ennen transaktion aloitusta vallinneeseen tilaan. tMyn

7. Tietokantajärjestelmä ei itsessään kykene päättelemään mikä käsky tai käskysarja muodostaa loogisesti yksittäisen tietokantatapahtuman. Se on siis erikseen kerrottava. • Tavallisesti tähän tehtävään on käytössä varatut sanat START TRANSACTION, COMMIT ja ROLLBACK. tMyn

8. Kaikkien tietokantatapahtumien tulisi täyttää seuraavat neljä ehtoa, ominaisuutta: ACID. • Atomicity (jakamattomuus). Tämä tarkoittaa ”kaikki tai ei mitään” –periaatetta. Tietokantatapahtuma suoritetaan kokonaisuudessaan tai sitten ei mitään osaa siitä. Tämän ominaisuuden hoitaa DBMS:n elvytysmekanismit. • Consistency (oikeellisuus, eheys). Transaktio säilyttää tietokannan eheyden eli ‘vie tietokannan eheästä tilasta eheään tilaan’. Eheyden säilyminen vaatii, että DBMS:n eheyskontrolli on kunnossa ja että sovellusohjelman toiminnot eivät riko eheyttä. Siispä transaktion oikeellisuuden säilyminen on tietokannan suunnittelijan ja tietokantasovelluksen ohjelmoijan vastuulla. tMyn

9. Isolation (eristyvyys). Transaktio suoritetaan ikään kuin muita transaktioita ei olisi samanaikaisesti käynnissä. Kun niitä kuitenkin on, eristyvyys asettaa vaatimuksen, etteivät muiden transaktioiden operaatiot saa vaikuttaa tietyn transaktion suoritukseen (haitallisesti). Transaktion T kannalta näyttää, että jokainen muu transaktio T’ olisi suoritettu kokonaisuudessaan ennen T:tä tai vasta sen jälkeen. Tästä on vastuussa DBMS:n samanaikaisuuden hallinta-alijärjestelmä. tMyn

10. Durability (pysyvyys). Kun transaktio on suoritettu onnistuneesti loppuun (sitoutunut, COMMIT), sen muutokset tietokannan tilaan jäävät pysyvästi voimaan. Pysyvyys on suhteessa valmiiseen transaktioon: mikään häiriö ei saa enää muuttaa tilaa; uusi transaktio voi tietysti muuttaa tietoalkioiden arvoja. DBMS:n elvytysalijärjestelmä on vastuussa pysyvyyden hallinnasta. tMyn

11. Samanaikaisuuden hallinta – kyky hallita tietokantaan kohdistuvia samanaikaisia operaatioita niin, että ne eivät häiritse toisiaan. • Käydään läpi kolme erityyppistä tilannetta, jossa käy hyvin ilmi samanaikaisuuden hallinnan tärkeys. Kaikki kolme esimerkkiä edustavat eristyvyysrikkomusta. • Ensimmäisenä esimerkkinä olkoot ”menetetty päivitys, likainen kirjoitus”, the lost update problem, dirty write. Tässä tilanteessa transaktio kirjoittaa toisen, sitoutumattoman, transaktion kirjoittaman tietoalkion päälle: tMyn

12. Tietokantatapahtumat T1 ja T2 ovat samanaikaisia. Kummatkin lukevat saman tilin arvon, ja huomaavat arvoksi vaikkapa 100. T2 haluaa kasvattaa arvoa 100:lla, ja päivittää (UPDATE) siis arvon 200:ksi. Saman aikaisesti (mutta käytännössä hieman T2:n jälkeen) T1 pienentää samaisen tilin arvoa – vaikkapa 10:llä – ja siis päivittää (UPDATE) arvon 90:ksi. • Nyt siis tililtä hävisi tuo ensimmäinen päivitys, eli 100. • Tilanne olisi estynyt, jos oltaisiin estetty T1:stä lukemasta tilin arvoa ennen kuin T2:n päivitys oli viety loppuun (COMMITTED). tMyn

13. Toisena esimerkkinä on ”likainen luku”, the uncommitted dependency problem, dirty read. Tässä transaktio lukee likaisen eli ei-pysyvän tietoalkion arvon: • Olkoon tilin arvo taas vaikkapa 100. Transaktio T4 päivittää arvon (UPDATE) arvoksi 200 (osittain sitoutunut, PARTIALLY COMMITTED). Tapahtuma kuitenkin keskeytetään (ABORT), ja tietokanta tulisi palauttaa ennen transaktion aloitusta vallinneeseen tilaan (100). tMyn

14. Nyt kuitenkin ehti käymään niin, että transaktio T3 ehti lukemaan tilin arvon (200), ja käytti sitä päivittämään (UPDATE) uudeksi arvoksi 200-10=190. • Oikea toiminta olisi saatu aikaan estämällä T3:sta lukemasta tilin arvoa ennen kuin T4 olisi sitoutunut (COMMITTED). tMyn

15. Kolmantena esimerkkinä on ”epäjohdonmukainen analyysi” (the inconsistent analysis problem). • Olkoot kaksi samanaikaista transaktiota T5 ja T6. • T6 laskee kolmen tilin summan. Olkoot 1. tilin arvo 100, 2. tilin arvo 50 ja 3. tilin arvo 25. T6 alkaa 1. tilin ja 2. tilin arvojen lukemisella, ja niiden arvojen summaamisella (juu, summaksi tulee 150). Tässä vaiheessa transaktio T5 siirtää arvon 10 1. tilistä tiliin 3. Tilin 3 arvoksi siis tulee 35 (ja 1. tilin arvoksi tulee 90). Nyt kun T6 suorittaa 3. tilin lukemisen ja summaamisen aikaisemman osasumman kanssa, niin vastaukseksi kolmen tilin summalle tulee 185. Eli arvo on 10 pieleen! tMyn

16. Ongelmasta olisi vältytty, jos tapahtuma T6 ei olisi pystynyt lukemaan 1. tilin eikä 3. tilin arvoa ennen kuin T5 on suoritettu loppuun. • Vähän saman tapainen tilanne syntyy, kun transaktio T7 lukee jonkin arvon uudelleen (josta sillä on siis aikaisempi tieto). Kahden lukukerran välissä on kuitenkin tapahtunut transaktio T8, joka on muuttanut tietoalkion arvon. Nyt siis T7:lla on kaksi erilaista arvoa tietoalkiosta. Tätä kutsutaan toistokelvottomaksi luvuksi (nonrepeatable read). tMyn

17. Vielä voidaan erottaa omanlaisensa ilmiö tällä alueella. Tauluun lisätään transaktiossa T8 rivi, joka täyttää toisen transaktion T9 käsittelemien rivien valintaehdon. Esim. T8: INSERT INTO Tyontekija (tNro, …) VALUES (5,…); T9: SELECT SUM(palkka)…WHERE tNro=5…; Ajoitus (T8, T9) ottaa mukaan myös uuden työntekijän palkan, ajoitus (T9, T8) sitä vastoin ei. Jos T9 ehtii ottaa relaation käyttöönsä ennen lisäystä, kesken laskennan ilmestyvä uusi rivi on haamurivi (phantom read). tMyn

18. Sarjallisella suorituksella (serializability) tarkoitataan sitä, että T1 suoritetaan kokonaan ennen transaktiota T2 tai päinvastoin. Yleistettynä tämä sarjallinen suoritus aiheuttaa kuitenkin joidenkin transaktioiden huomattavan viivästymisen tai pahimmillaan suorituksen estymisen. • Samanaikaisuuden hallinnan alijärjestelmän tehtävänä on lieventää hallitusti sarjallisuuden vaatimuksia eli sallia rinnakkaisuutta, mutta eliminoida sen haitat. • Transaktiohistorialla tai transaktioajoituksella (schedule) tarkoitetaan sitä järjestystä missä eri transaktioiden luku- ja kirjoitusoperaatiot suoritetaan. tMyn

19. Rinnakkainen ajoitus on oikea, jos se on ekvivalenttinen jonkin sarjallisen ajoituksen kanssa. Ekvivalenssi voidaan määritellä eri tavoilla (tulosekvivalenssi, konfliktiekvivalenssi, näkemysekvivalenssi). • Ajoitus on sarjallistuva (serializable), jos se on ekvivalentti jonkin sarjallisen suorituksen kanssa. Ekvivalenssi määritellään yleensä konfliktiekvivalenssina: siis keskenään konfliktoivien eli ”vaarallisten” operaatioiden järjestys säilyy ajoituksissa samana. • Operaatiot konfliktoivat, jos ne kuuluvat eri transaktioihin, ne kohdistuvat samaan tietoalkioon, ja ainakin toinen operaatio on kirjoitusoperaatio. tMyn

20. SQL:ssä on lause SET TRANSACTION, jolla sovellusohjelmassa voidaan valita aloitettavan transaktion eristyvyystaso (isolation level). Mahdolliset tasot vaativuudeltaan nousevassa järjestyksessä: 1. Lue sitoutumatonta (READ UNCOMMITTED). Transaktio saattaa lukea likaista tietoa tai toistokelvottomasti, mutta ei kirjoita likaista. 2. Lue sitoutunutta (READ COMMITTED). Transaktio saattaa lukea toistokelvottomasti, mutta ei kirjoita eikä lue likaista. 3. Toistokelpoinen luku (REPEATABLE READ). Transaktio ei kirjoita eikä lue likaista eikä lue toistokelvottomasti. tMyn

21. 4. Sarjallistuva (SERIALIZABLE). Kuten 3; lisäksi ns. haamuilmiöiden esiintyminen on kielletty. • MySQL:ssä oletustasona on 3. tMyn

22. Samanaikaisuuden hallinnan sisältämä kontrolli transaktioiden suoritukselle (eristyvyyden takaaminen) voidaan hoitaa usealla menetelmällä: • Asettamalla tietoalkioille lukkoja: operointi on sallittu vain transaktiolle, joka on saanut haltuunsa tietoalkion lukon (käyttöoikeuden). • Seuraamalla transaktioiden ajoitusta niihin liittyvien aikaleimojen (timestamp) avulla. • Ylläpitämällä tietoalkioiden useita arvoja (”vanha” ja ”uusi”) moniversiotekniikalla. tMyn

23. Optimistisilla menetelmillä: antamalla transaktioiden suorittaa varsinaiset operaationsa ja tarkistamalla sitten validointivaiheessa, ettei suoritukseen sisälly ristiriitaisia tilanteita. Operaatiot kohdistuvat tietoalkioiden tilapäisiin kopioihin, joten menetelmä on tavallaan moniversioinen. • Lukitusmenetelmä on yleisimmin käytössä. tMyn

24. Lukkoja on erityyppisiä: • Lukulukko (READ) antaa oikeuden lukea tietoalkion, mutta ei kirjoittaa sitä. Lukulukko tiettyyn tietoalkioon voi olla samanaikaisesti usealla transaktiolla. • Kirjoituslukko (WRITE) antaa oikeuden kirjoittaa (ja lukea) tietoalkion arvon. Vain yhdellä transaktiolla voi olla samanaikaisesti kirjoituslukko tietoalkioon. • MySQL:llä näyttää olevan lukot READ, READ LOCAL, LOW_PRIORITY WRITE ja WRITE . • Tyypillisesti samanaikaisuuden hallinta kuuluu DBMS:n oletuksiin, joten sovellusohjelmoijan ei tarvitse huolehtia tietoalkioiden lukituksesta. tMyn

25. Tietokannan elvytys. • Transaktion atomisuus tai pysyvyys voi vaarantua monen häiriötilanteen takia: 1. Järjestelmä ”romahtaa” laitteisto-, ohjelmisto- tai tietoliikennevirheen takia. Yleensä keskusmuistin (tietokantapuskurien) sisältöä menetetään. 2. Yksittäisen transaktion suoritus keskeytyy ohjelman poikkeustilanteeseen (divide by zero tms) tai loogisen ohjelmavirheen takia. Käyttäjä voi myös keskeyttää kyselyn suorituksen ”väkivalloin”. tMyn

26. 3. Transaktion suoritus keskeytetään hallitusti; esim. transaktion koodissa suoritetaan jonkin ehdon täyttymisen seurauksena ROLLBACK-pyyntö. Esim. ei löydy transaktion tarvitsemaa syötettä tai se on virheellinen. 4. Samanaikaisuuden hallinnan alijärjestelmä joutuu keskeyttämään transaktion, jotta muut transaktiot voisivat edetä (lukkiutuma tai lievempi suoritusjärjestykseen liittyvä häiriö). 5. Levyvirhe on turmellut levyn sisältöä. 6. Ulkopuolinen häiriötekijä (operointivirhe, sähkökatko,…) keskeyttää transaktion. tMyn

27. Tyypin 5 ja 6 häiriöt ovat harvinaisia, niiden kohdalla elvytys voi sisältää edellisen varmuuskopion käyttöönoton. Lokin avulla voidaan suorittaa uudelleen menetetyt toiminnot. • Tyypin 1-4 häiriöt ovat normaaleja ja ne hoidetaan tapahtumanhallinnan toimin. • Lokiin perustuvan elvytyksen periaatteet: • Peruutetaan (undo) keskeytyneiden transaktioiden suorittamien tietokantapäivitysten vaikutukset. • Suoritetaan uudelleen (redo) sellaisten sitoutuneiden transaktioiden suorittamat tietokantapäivitykset, joita ei häiriön sattuessa ollut ehditty kirjoittaa levylle (vaan vasta puskurissa olevaan levyjaksoon). tMyn

28. Tietokantajärjestelmä ei itsessään kykene päättelemään mikä käsky tai käskysarja muodostaa loogisesti yksittäisen tietokantatapahtuman. Kerrotaan se varatuilla sanoilla START TRANSACTION, COMMIT ja ROLLBACK. • Taulukkoon lisätään kaksi riviä HTML-lomakkeen avulla. Jos saman perusavaimen arvoa yritetään käyttää kaksi kertaa, niin sitten ei tehdä kumpaakaan muutosta. • Vastaavat tiedostot ovat: tMyn

29. Luodaan tarkoitukseen sopiva taulu: tMyn

30. tMyn

31. tMyn

32. Tehdään sopiva HTML-lomake: tMyn

33. tMyn

34. Tehdään sopiva logiikka Web-palvelimelle: tMyn

35. tMyn

36. tMyn

37. tMyn

38. tMyn

39. Ensimmäiset 2 riviä onnistutaan lisäämään: tMyn

40. tMyn

41. Nyt taitaa tulla vaikeuksia, perusavaimen arvo jo käytössä: tMyn

42. tMyn

43. Tehdään pieni muutos palvelinohjelmaan, jotta päästäisiin kätevästi syöttämään lisää rivejä: tMyn

44. tMyn

45. tMyn

46. tMyn

47. Ja ei kun naputtelemaan lisää pareja…: tMyn

48. tMyn