Tapahtuma on joukko peräkkäisiä operaatioita tietokannan kanssa , joka on looginen työskentelyyksikkö tietojen kanssa. Tapahtuma voidaan joko suorittaa onnistuneesti päätökseen tietojen eheyttä kunnioittaen ja muista samanaikaisista tapahtumista riippumatta tai jättää suorittamatta ollenkaan, jolloin sillä ei pitäisi olla vaikutusta. Tapahtumat käsitellään tapahtumajärjestelmissä , joiden aikana luodaan tapahtumahistoria .
Erottele peräkkäiset (normaalit), rinnakkaiset ja hajautetut tapahtumat . Hajautetut tapahtumat sisältävät useamman kuin yhden tapahtumajärjestelmän käytön ja vaativat paljon monimutkaisempaa logiikkaa (esimerkiksi kaksivaiheinen vahvistus - kaksivaiheinen tapahtumasitoumusprotokolla ). Jotkin järjestelmät toteuttavat myös itsenäisiä tapahtumia tai alitapahtumia, jotka ovat itsenäinen osa emotapahtumaa.
Esimerkki: sinun on siirrettävä pankkitililtä numero 5 tilille numero 7 10 rahayksikköä. Tämä voidaan saavuttaa esimerkiksi seuraavalla toimintosarjalla:
Nämä toiminnot edustavat loogista työyksikköä "summan siirtämiseksi tilien välillä" ja ovat siten tapahtuma. Jos tämä tapahtuma keskeytyy esimerkiksi kesken, eikä kaikkia muutoksia peruuteta, on helppo jättää tilinumero 5 omistaja ilman 10 yksikköä, kun taas tilinumero 7 omistaja ei saa niitä.
Yksi yleisimmistä tapahtumien ja transaktiojärjestelmien vaatimuksista on ACID - joukko (Atomicity, Consistency, Isolation, Durability). ACID-vaatimukset muotoili pääasiassa 1970-luvun lopulla Jim Gray [1] . Samaan aikaan on olemassa erikoisjärjestelmiä, joiden transaktioominaisuudet ovat heikentyneet [2] .
Ihannetapauksessa eri käyttäjien tapahtumat tulisi suorittaa siten, että syntyy illuusio, että nykyisen tapahtuman käyttäjä on ainoa. Todellisuudessa DBMS tarjoaa kuitenkin suorituskyvyn syistä ja joidenkin erityistehtävien suorittamiseksi eritasoisia tapahtumia.
Tasot on kuvattu järjestyksessä, joka lisää tapahtumien eristyneisyyttä ja vastaavasti tiedon kanssa työskentelyn luotettavuutta.
Mitä korkeampi eristysaste, sitä enemmän resursseja tarvitaan sen tarjoamiseen. Näin ollen eristyneisyyden lisääntyminen voi johtaa rinnakkaisten tapahtumien nopeuden hidastumiseen, mikä on "maksu" luotettavuuden lisäämisestä.
DBMS:ssä tapahtuman eristystaso voidaan valita sekä kaikille tapahtumille kerralla että yhdelle tietylle tapahtumalle. Oletuksena useimmat tietokannat käyttävät tasoa 1 (luettu sitoutunut). Tasoa 0 käytetään ensisijaisesti pitkäaikaisten tapahtumien muutosten seurantaan tai harvoin muuttuvien tietojen lukemiseen. Tasoja 2 ja 3 käytetään lisäämään tapahtumien eristämistä koskevia vaatimuksia.
Eristystasojen ja ACID-ominaisuuksien täydellinen toteuttaminen ei ole triviaali tehtävä. Saapuvien tietojen käsittely johtaa moniin pieniin muutoksiin, mukaan lukien sekä itse taulukoiden että indeksien päivittäminen. Nämä muutokset voivat epäonnistua: levytila loppuu, toiminto kestää liian kauan (aikakatkaisu) jne. Järjestelmän on palautettava tietokanta oikein tapahtumaa edeltävään tilaan epäonnistuessa.
Varhaiset kaupalliset DBMS-järjestelmät (kuten IBM:n DB2 ) käyttivät yksinomaan tietojen pääsyn lukitusta tarjotakseen ACID-ominaisuuksia. Mutta suuri määrä lukkoja johtaa merkittävään suorituskyvyn heikkenemiseen. Tähän ongelmaan on olemassa kaksi suosittua ratkaisuperhettä, jotka vähentävät estämistä:
Molemmissa tapauksissa kaikki päivitettävät tiedot on suljettava. Eristystasosta ja toteutuksesta riippuen kirjoituslukot asetetaan myös tapahtuman lukemille tiedoille.
Ennakoivan kirjauksen avulla , jota käytettiin Sybasessa ja MS SQL Serverissä ennen versiota 2005, kaikki muutokset kirjoitetaan lokiin ja vasta onnistuneen suorittamisen jälkeen tietokantaan. Tämä mahdollistaa DBMS:n palata toimintatilaan odottamattoman järjestelmän kaatumisen jälkeen. Varjosivut sisältävät kopiot näistä tietokantasivuista tapahtuman alussa, jossa muutoksia tapahtuu. Nämä kopiot aktivoidaan onnistuneen valmistumisen jälkeen. Vaikka varjosivut on helpompi toteuttaa, ennakoiva kirjaus on tehokkaampaa [4] .
Tietokannan hallintateknologioiden jatkokehitys johti estottoman teknologian syntymiseen. Idea samanaikaisuuden ohjauksesta aikaleimapohjaisella samanaikaisuuden ohjauksella kehitettiin ja johti moniversioisen arkkitehtuurin syntymiseen MVCC . Nämä tekniikat eivät vaadi muutoslokia tai varjosivuja. Oracle 7.x :ssä ja uudemmissa toteutettu arkkitehtuuri kirjoittaa vanhemmat versiot sivuista erityiseen palautussegmenttiin, mutta ne ovat silti luettavissa. Jos tapahtuma osuu luettaessa sivulle, jonka aikaleima on uudempi kuin lukemisen alku, tiedot otetaan palautussegmentistä (eli "vanhaa" versiota käytetään). Tämän työn tueksi pidetään tapahtumalokia, mutta toisin kuin "proaktiivinen loki", se ei sisällä tietoja. Työskentely sen kanssa koostuu kolmesta loogisesta vaiheesta:
Tapahtumaloki yhdessä palautussegmentin kanssa (alue, joka tallentaa kopion kaikista tapahtuman aikana muuttuvista tiedoista) takaa tietojen eheyden. Vian sattuessa käynnistetään palautusmenettely, joka tarkastelee yksittäisiä tietueita seuraavasti:
Firebirdillä ei ole lainkaan muutoslokia tai palautussegmenttiä, vaan se toteuttaa MVCC :n kirjoittamalla uusia versioita taulukon riveistä suoraan aktiiviseen tietotilaan. Saman tekee MS SQL 2005. Teoriassa tämä tehostaa dataa rinnakkain, mutta hintana on tarve "roskien keräämiseen" eli vanhojen ja tarpeettomien versioiden poistamiseen tiedosta.
Tapahtumakäsittelyn tarkoituksena on pitää tietokonejärjestelmä (yleensä tietokanta tai jotkin nykyaikaiset tiedostojärjestelmät ) tunnetussa, johdonmukaisessa tilassa varmistamalla, että kaikki järjestelmässä tapahtuvat toiminnot ovat toisistaan riippuvaisia ja joko kaikki onnistuneesti suoritettuja tai kokonaan ja peruutettu onnistuneesti. [5]
Harkitse esimerkiksi tyypillistä pankkitapahtumaa, jossa 700 dollaria siirretään asiakkaan säästötililtä asiakkaan shekkitilille. Tämä tapahtuma on yksi pankkitapahtuma, mutta se sisältää ainakin kaksi erillistä tapahtumaa tietokoneella: 700 dollaria hyvitetään talletustilille ja 700 dollaria sekkitilille. Jos veloitustapahtumat onnistuvat ja luottotapahtumat eivät (tai päinvastoin), pankin kirjanpidossa ei ole saldoa päivän lopussa. Siksi on oltava keino varmistaa, että molemmat toiminnot joko onnistuvat tai epäonnistuvat, jotta pankin tietokannassa ei koskaan ole epäjohdonmukaisuutta kokonaisuudessaan. Tapahtumakäsittely on suunniteltu tarjoamaan tämä.
Tapahtumakäsittely mahdollistaa useiden erillisten tapahtumien automaattisen linkittämisen yhdeksi, jakamattomaksi tapahtumaksi. Tapahtumankäsittelyjärjestelmät varmistavat, että joko kaikki tapahtuman toiminnot suoritetaan ilman virheitä tai ei yhtään niistä. Jos osa toiminnoista on suoritettu loppuun, mutta virheellisesti ja toiset ilman, tapahtumankäsittelyjärjestelmä käskee "palauttamaan" kaikki tapahtuman tapahtumat (mukaan lukien onnistuneet), mikä tarkoittaa kaikkien toiminnon jälkien poistamista ja järjestelmän palauttamista johdonmukainen tunnettu tila, joka oli ennen tapahtumaprosessin alkamista. Jos tapahtuman kaikki toiminnot on suoritettu onnistuneesti, tapahtuma sitoutuu järjestelmässä ja kaikista tietokannan muutoksista tulee "pysyviä" ( sitoutuneita ); liiketoimia ei voi peruuttaa, jos ne on jo tehty.
Tapahtuman käsittely suojaa laitteisto- ja ohjelmistovirheiltä, jotka voivat jättää tapahtuman osittain valmiiksi, jolloin järjestelmä jää tuntemattomaan, epäjohdonmukaiseen tilaan. Jos tietokonejärjestelmä epäonnistuu keskellä tapahtumaa, tapahtuman käsittely varmistaa, että kaikki sitomattomien (eli täysin käsiteltyjen) tapahtumien tapahtumat peruutetaan.
Tapahtumat järjestetään tiukasti kronologisessa järjestyksessä. Jos tapahtuma N+1 aikoo koskettaa samaa tietokannan osaa kuin tapahtuma N, tapahtuma N+1 ei ala ennen kuin tapahtuu tapahtuma N. Ennen tapahtumia kaikki muut samaan järjestelmän osaan vaikuttavat tapahtumat on myös suoritettava; aikaisempien tapahtumien järjestyksessä ei voi olla "reikiä". [6] [5]
Kaikkien tapahtumien käsittelyjärjestelmien perusperiaatteet ovat samat. Terminologia voi kuitenkin vaihdella tapahtumankäsittelyjärjestelmästä toiseen, eivätkä alla käytetyt termit välttämättä ole yleismaailmallisia. [7]
Palautus ( eng. rollback )Tapahtumankäsittelyjärjestelmät varmistavat tietokannan eheyden kirjaamalla tietokannan välitilan ennen sen muuttamista ja käyttämällä sitten näitä tietueita tietokannan palauttamiseen tunnettuun tilaan, jos tapahtumaa ei voida sitoa. Esimerkiksi järjestelmä tekee kopiot tietokannassa olevista tiedoista ennen kuin tapahtuma muutti niitä ennen tapahtumaa, joka voi tehdä muutoksia (joskus kutsutaan ennen kuvaa ). Jos jokin tapahtuman osa epäonnistuu ennen kuin se on sitoutunut, näitä kopioita käytetään palauttamaan tietokanta tilaan, jossa se oli ennen tapahtuman alkamista ( Rollback ). [6]
Juokse ( eng. rulla eteenpäin )Voit myös pitää erillistä lokia kaikista tietokannan muutoksista (joskus kutsutaan kuvien mukaan ); tämä ei edellytä epäonnistuneiden toimintojen palauttamista, mutta se on hyödyllinen tietokannan päivittämiseen tietokannan vian sattuessa, minkä vuoksi jotkut tapahtumankäsittelyjärjestelmät tarjoavat tämän ominaisuuden. Jos tietokanta epäonnistuu kokonaan, se on palautettava viimeisestä varmuuskopiosta. Varmuuskopiot eivät heijasta toimintoja, jotka on suoritettu sen luomisen jälkeen. Kuitenkin, kun tietokanta on palautettu, after images -lokia voidaan käyttää tietokantaan ( rollforward ) sen päivittämiseksi. Kaikki epäonnistumisen aikaan käynnissä olevat tapahtumat voidaan peruuttaa. Tuloksena on tunnetussa johdonmukaisessa tilassa oleva tietokanta, joka sisältää kaikkien epäonnistumiseen asti sitoutuneiden tapahtumien tulokset. [6]
Keskinäinen esto ( eng. lukkiutumiset )Joissakin tapauksissa kaksi tapahtumaa voivat käsittelyn aikana yrittää päästä samaan tietokannan osaan samanaikaisesti tavalla, joka estää niiden suorittamisen loppuun. Esimerkiksi tapahtuma A voi käyttää tietokannan osaa X ja tapahtuma B voi käyttää tietokannan osaa Y. Jos tässä vaiheessa tapahtuma A yrittää päästä tietokannan osaan Y, kun tapahtuma B yrittää päästä osaan X, tapahtuu lukkiutumistilanne eikä tapahtumaa voida jatkaa. Tapahtumankäsittelyjärjestelmät on suunniteltu havaitsemaan tällaiset tilanteet. Yleensä molemmat tapahtumat kumotaan ja perutaan, ja sitten ne käynnistetään automaattisesti eri järjestyksessä, jotta lukkiutuminen ei toistu. Tai joskus vain yksi lukkiutuneista tapahtumista peruutetaan, peruutetaan ja yritetään automaattisesti uudelleen lyhyen viiveen jälkeen.
Umpikuja voi tapahtua kolmen tai useamman tapahtuman välillä. Mitä enemmän tapahtumia on yhdistetty, sitä vaikeampi ne on havaita. Tapahtumankäsittelyjärjestelmät ovat jopa asettaneet käytännön rajan umpikujalle, joita ne voivat havaita.
| Tietokanta | |
|---|---|
| Käsitteet |
|
| Objektit |
|
| Avaimet | |
| SQL | |
| Komponentit | |