Tietokantatapahtuman hallinta

Esitys aiheesta: "Tietokantatapahtuman hallinta"— Esityksen transkriptio:

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. Tietokantatapahtuman hallinta 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. Tietokantatapahtuman hallinta tMyn

3 Tietokantatapahtuman tilakaavio näyttää seuraavanlaiselta, kuva 1:
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: Tietokantatapahtuman hallinta tMyn

4 PARTIALLY COMMITTED COMMITTED End Transaction Commit Begin Transaction ACTIVE Abort FAILED ABORTED Abort Kuva 1. Tietokantatapahtuman tilakaavio. Tietokantatapahtuman hallinta 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. Tietokantatapahtuman hallinta tMyn

6 Epäonnistunut (failed). Sitoutuminen on epäonnistunut (esim
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. Tietokantatapahtuman hallinta 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. Tietokantatapahtuman hallinta 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. Tietokantatapahtuman hallinta tMyn

9 Isolation (eristyvyys)
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ä. Tietokantatapahtuman hallinta tMyn

10 Durability (pysyvyys)
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. Tietokantatapahtuman hallinta 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: Tietokantatapahtuman hallinta tMyn

12 Nyt siis tililtä hävisi tuo ensimmäinen päivitys, eli 100.
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). Tietokantatapahtuman hallinta 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). Tietokantatapahtuman hallinta 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 =190. Oikea toiminta olisi saatu aikaan estämällä T3:sta lukemasta tilin arvoa ennen kuin T4 olisi sitoutunut (COMMITTED). Tietokantatapahtuman hallinta tMyn

15 Olkoot kaksi samanaikaista transaktiota T5 ja T6.
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 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! Tietokantatapahtuman hallinta 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). Tietokantatapahtuman hallinta tMyn

17 T9: SELECT SUM(palkka)…WHERE tNro=5…;
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). Tietokantatapahtuman hallinta 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. Tietokantatapahtuman hallinta 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. Tietokantatapahtuman hallinta 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. Tietokantatapahtuman hallinta tMyn

21 MySQL:ssä oletustasona on 3.
4. Sarjallistuva (SERIALIZABLE). Kuten 3; lisäksi ns. haamuilmiöiden esiintyminen on kielletty. MySQL:ssä oletustasona on 3. Tietokantatapahtuman hallinta 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. Tietokantatapahtuman hallinta tMyn

23 Lukitusmenetelmä on yleisimmin käytössä.
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ä. Tietokantatapahtuman hallinta 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. Tietokantatapahtuman hallinta 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”. Tietokantatapahtuman hallinta tMyn

26 5. Levyvirhe on turmellut levyn sisältöä.
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. Tietokantatapahtuman hallinta tMyn

27 Lokiin perustuvan elvytyksen periaatteet:
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). Tietokantatapahtuman hallinta tMyn

28 Vastaavat tiedostot ovat:
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: Tietokantatapahtuman hallinta tMyn

29 Luodaan tarkoitukseen sopiva taulu:
Tietokantatapahtuman hallinta tMyn

30 Tietokantatapahtuman hallinta
tMyn

31 Tietokantatapahtuman hallinta
tMyn

32 Tehdään sopiva HTML-lomake:
Tietokantatapahtuman hallinta tMyn

33 Tietokantatapahtuman hallinta
tMyn

34 Tehdään sopiva logiikka Web-palvelimelle:
Tietokantatapahtuman hallinta tMyn

35 Tietokantatapahtuman hallinta
tMyn

36 Tietokantatapahtuman hallinta
tMyn

37 Tietokantatapahtuman hallinta
tMyn

38 Tietokantatapahtuman hallinta
tMyn

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

40 Tietokantatapahtuman hallinta
tMyn

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

42 Tietokantatapahtuman hallinta
tMyn

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

44 Tietokantatapahtuman hallinta
tMyn

45 Tietokantatapahtuman hallinta
tMyn

46 Tietokantatapahtuman hallinta
tMyn

47 Ja ei kun naputtelemaan lisää pareja…:
Tietokantatapahtuman hallinta tMyn

48 Tietokantatapahtuman hallinta
tMyn