1 / 48

Tietokantatapahtuman hallinta

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).

shona
Télécharger la présentation

Tietokantatapahtuman hallinta

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related