Tapahtuman eristystaso on ehdollinen arvo, joka määrittää, missä määrin epäjohdonmukaiset tiedot sallitaan DBMS:n loogisesti rinnakkaisten tapahtumien suorittamisen seurauksena. Tapahtuman eristystasojen asteikko sisältää useita arvoja, jotka on luokiteltu alimmasta korkeimpaan; korkeampi eristystaso vastaa parempaa tietojen johdonmukaisuutta, mutta sen käyttö voi vähentää fyysisesti rinnakkaisten tapahtumien määrää. Toisaalta alempi eristystaso mahdollistaa enemmän rinnakkaisia tapahtumia, mutta heikentää tietojen tarkkuutta. Näin ollen tietojärjestelmän kehittäjä, valitessaan käytettävän tapahtumaeristyksen tason, antaa jossain määrin valita työn nopeuden ja järjestelmästä vastaanotettujen tietojen taatun johdonmukaisuuden välillä.
Kun tapahtumat suoritetaan rinnakkain , seuraavat ongelmat ovat mahdollisia:
Harkitse tilanteita, joissa näitä ongelmia voi esiintyä.
Tilanne, jossa, kun yhtä datalohkoa muutetaan samanaikaisesti eri tapahtumilla, yksi muutoksista menetetään.
Oletetaan, että kaksi tapahtumaa on käynnissä samanaikaisesti:
| Tapahtuma 1 | Tapahtuma 2 |
|---|---|
| UPDATE tbl1 SET f2=f2+20 WHERE f1=1; | UPDATE tbl1 SET f2=f2+25 WHERE f1=1; |
Molemmissa tapahtumissa f2-kentän arvo muuttuu; kun se on valmis, kentän arvoa on suurennettava 45:llä. Itse asiassa voi tapahtua seuraava toimintosarja:
Tämän seurauksena f2-kentän arvo voi molempien tapahtumien päätyttyä nousta ei 45:llä, vaan 20:lla tai 25:llä, eli yksi dataa muuttavista tapahtumista "katoaa".
Lukee dataa, joka on lisätty tai jota on muokattu tapahtumalla, jonka sitominen epäonnistuu myöhemmin (palautus).
Oletetaan, että meillä on kaksi tapahtumaa, jotka on avattu eri sovelluksilla, jotka suorittavat seuraavat SQL-käskyt:
| Tapahtuma 1 | Tapahtuma 2 |
|---|---|
| UPDATE tbl1 SET f2=f2+1 WHERE f1=1; | |
| SELECT f2 FROM tbl1 WHERE f1=1; | |
| ROLLBACK WORK; |
Tapahtumassa 1 kentän f2 arvoa muutetaan ja sitten tapahtumassa 2 tämän kentän arvo valitaan. Tämän jälkeen peruutetaan tapahtuma 1. Tämän seurauksena toisen tapahtuman vastaanottama arvo poikkeaa tietokantaan tallennetusta arvosta.
Tilanne, kun saman tapahtuman sisällä uudelleen luettaessa aiemmin luetut tiedot osoittautuvat muuttuneiksi.
Oletetaan, että eri sovellukset avaavat kaksi tapahtumaa, joissa suoritetaan seuraavat SQL -käskyt :
| Tapahtuma 1 | Tapahtuma 2 |
|---|---|
| SELECT f2 FROM tbl1 WHERE f1=1; | |
| UPDATE tbl1 SET f2=f2+3 WHERE f1=1; | |
| COMMIT; | |
| SELECT f2 FROM tbl1 WHERE f1=1; |
Tapahtumassa 2 valitaan kentän f2 arvo, sitten tapahtumassa 1 muutetaan kentän f2 arvoa. Jos yrität uudelleen valita arvon tapahtuman 2 kentästä f2, tulos on erilainen. Tämä tilanne on erityisen mahdoton hyväksyä, kun tiedot luetaan sen osittaiseksi muokkaamiseksi ja sen kirjoittamiseksi takaisin tietokantaan.
Tilanne, jossa toistuvan lukemisen aikana saman tapahtuman sisällä sama valinta antaa eri riviä.
Oletetaan, että eri sovellukset avaavat kaksi tapahtumaa, jotka suorittavat seuraavat SQL-käskyt:
| Tapahtuma 1 | Tapahtuma 2 |
|---|---|
| SELECT SUM(f2) FROM tbl1; | |
| INSERT INTO tbl1 (f1,f2) VALUES (15,20); | |
| COMMIT; | |
| SELECT SUM(f2) FROM tbl1; |
Tapahtuma 2 suorittaa SQL-käskyn, joka käyttää kaikkia kentän f2 arvoja. Sitten tapahtumaan 1 lisätään uusi rivi, jolloin tapahtuman 2 SQL-käskyn uudelleen suorittaminen tuottaa erilaisen tuloksen. Tätä tilannetta kutsutaan phantom-lukemiseksi (haamulukemiseksi). Se eroaa ei-toistetusta lukemisesta siinä, että toistuvan tiedonhaun tulos ei ole muuttunut itse tiedon muutoksen/poiston vuoksi, vaan uuden (haamu)datan ilmaantumisen vuoksi.
" Tapahtumien eristystaso " viittaa DBMS:n sisäisten mekanismien tarjoamaan suojausasteeseen (eli ei vaadi erityistä ohjelmointia) kaikilta tai joillakin edellä mainituista datan epäjohdonmukaisuuksista, joita esiintyy tapahtumien rinnakkaisen suorittamisen aikana. SQL-92-standardi määrittelee neljän eristystason asteikon: Read uncommitted, Read sitoutuneet, Toistettavissa oleva luku, Serialisoitava. Ensimmäinen niistä on heikoin, viimeinen on vahvin, jokainen seuraava sisältää kaikki edelliset.
Alin (ensimmäinen) eristystaso [1] . Jos useat rinnakkaiset tapahtumat yrittävät muokata samaa taulukon riviä, viimeisellä rivillä on arvo, jonka määrittää kaikki onnistuneesti suoritetut tapahtumat. Tällöin on mahdollista lukea paitsi loogisesti ristiriitaista tietoa myös tietoja, joiden muutoksia ei ole vielä tallennettu.
Tyypillinen tapa toteuttaa tämä eristystaso on lukita tiedot muutoskomentoa suoritettaessa, mikä varmistaa, että samoilla riveillä olevat muutoskomennot suoritetaan todella peräkkäin eikä mikään muutoksista katoa. Vain luku -tapahtumat eivät koskaan estä tämän eristystason alla.
Useimmat teolliset tietokantajärjestelmät, erityisesti Microsoft SQL Server , PostgreSQL ja Oracle , käyttävät tätä tasoa oletuksena. Tällä tasolla on suojattu luonnoksia, "likaa" lukemista vastaan, mutta yhden tapahtuman aikana toinen voidaan suorittaa onnistuneesti ja sen tekemät muutokset korjata. Tämän seurauksena ensimmäinen tapahtuma toimii eri tietojoukon kanssa.
Täydellisen lukemisen toteuttaminen voi perustua jompaankumpaan kahdesta lähestymistavasta: estoon tai versiointiin.
Lukevan ja muunnettavan tiedon estäminen. Se koostuu siitä, että kirjoitustapahtuma lukitsee muuttuvat tiedot lukutapahtumien lukemista varten, jotka toimivat lukusitoumustasolla tai sitä korkeammalla, kunnes se on valmis, mikä estää "likaisen" lukemisen, ja lukutapahtuman lukitsemat tiedot vapautetaan välittömästi lukutapahtuman valmistumisen jälkeen. SELECT-toiminto (siten "ei-toistettavissa oleva luku" voi tapahtua tietyllä eristystasolla). Tallennetaan useita versioita riveistä, jotka muuttuvat rinnakkain. Joka kerta kun riviä muutetaan, DBMS luo tästä rivistä uuden version, jonka kanssa tietoja muuttanut tapahtuma jatkaa toimintaansa, kun taas mikä tahansa muu "lukutapahtuma" palauttaa viimeisen sitovan version. Tämän lähestymistavan etuna on, että se tarjoaa enemmän nopeutta, koska se estää tukkeutumisen. Se vaatii kuitenkin ensimmäiseen verrattuna huomattavasti suuremman määrän RAM-muistia, joka kuluu riviversioiden tallentamiseen. Lisäksi kun useat tapahtumat muuttavat tietoja rinnakkain, se voi luoda tilanteen, jossa useat samanaikaiset tapahtumat tekevät epäjohdonmukaisia muutoksia samoihin tietoihin (koska lukituksia ei ole, mikään ei estä tätä tapahtumasta). Tällöin ensimmäisenä sitoutunut tapahtuma tallentaa muutokset päätietokantaan, ja jäljellä olevia rinnakkaisia tapahtumia ei voida sitoa (koska tämä johtaa ensimmäisen tapahtuman päivityksen menettämiseen). Ainoa asia, jonka DBMS voi tehdä tällaisessa tilanteessa, on peruuttaa loput tapahtumat ja antaa virheilmoituksen "Tietue on jo muutettu".DBMS-kehittäjät valitsevat tietyn toteutustavan, ja joissain tapauksissa sitä voidaan mukauttaa. Joten oletusarvoisesti MS SQL käyttää lukkoja, mutta (versiossa 2005 ja uudemmissa) kun READ_COMMITTED_SNAPSHOT-parametri on asetettu, tietokanta siirtyy versiointistrategiaan, Oracle toimii aluksi vain versioidun mallin mukaan. Informix , voit estää luku- ja kirjoitustapahtumien väliset ristiriidat asettamalla konfiguraatioparametrin USELASTCOMMITTED (versiosta 11.1 lähtien), mikä saa lukutapahtuman vastaanottamaan viimeiset sitovat tiedot [2]
Taso, jolla lukutapahtuma "ei näe" muuttuu aiemmin lukemiin tietoihin. Samanaikaisesti mikään muu tapahtuma ei voi muuttaa nykyisen tapahtuman lukemia tietoja ennen kuin se päättyy.
Jaetun tilan lukituksia sovelletaan kaikkiin dataan, joka luetaan minkä tahansa tapahtuman käskyn avulla, ja niitä säilytetään, kunnes tapahtuma on valmis. Tämä estää muita tapahtumia muokkaamasta rivejä, jotka odottava tapahtuma on lukenut. Muut tapahtumat voivat kuitenkin lisätä rivinvaihtoja, jotka vastaavat nykyisen tapahtuman sisältämien ohjeiden hakuehtoja. Kun nykyinen tapahtuma käynnistää lausunnon uudelleen, uudet rivit noudetaan, mikä johtaa haamulukuun. Koska jaetut lukot säilytetään tapahtuman loppuun saakka sen sijaan, että ne vapautettaisiin jokaisen käskyn lopussa, samanaikaisuusaste on pienempi kuin READ COMMITTED -eristystasolla. Siksi ei yleensä suositella tämän ja korkeampien tapahtumatasojen käyttämistä tarpeettomasti.
Korkein eristyksen taso; tapahtumat ovat täysin eristettyjä toisistaan, jokainen niistä suoritetaan ikään kuin rinnakkaisia tapahtumia ei olisi. Vain tällä tasolla samanaikaiset tapahtumat eivät ole "haamuluku"-vaikutuksen alaisia.
Transaktioiden tietokannanhallintajärjestelmät eivät aina tue kaikkia neljää tasoa, ja ne voivat myös ottaa käyttöön uusia. Eristyksen tarjoamisessa on myös erilaisia vivahteita.
Joten periaatteessa Oracle ei tue nollatasoa, koska sen tapahtumien toteuttaminen sulkee pois "likaiset lukemat" ja muodollisesti ei salli Toistettavan lukutason asettamista, eli se tukee vain Read-sitoutunutta (oletuksena) ja Serialisoitavaa. Samalla yksittäisten komentojen tasolla se itse asiassa takaa lukujen toistettavuuden (jos SELECT-komento ensimmäisessä tapahtumassa valitsee joukon rivejä tietokannasta, ja tällä hetkellä rinnakkainen toinen tapahtuma muuttaa joitakin näistä riveistä, ensimmäisen tapahtuman vastaanottama tulosjoukko sisältää muuttumattomia rivejä, ikään kuin toista tapahtumaa ei olisi). Oracle tukee myös niin kutsuttuja READ-ONLY -tapahtumia, jotka ovat Serializable-standardin mukaisia, mutta eivät voi muuttaa tietoja itse.
Microsoft SQL Server tukee kaikkia neljää vakiotapahtumien eristystasoa ja lisäksi SNAPSHOT-tasoa, jolla tapahtuma näkee datatilan, joka oli sitoutunut ennen sen aloittamista, sekä itsensä tekemät muutokset, eli se käyttäytyy kuin se sai käynnistää tilannekuvan tietokannan tiedoista ja työskennellä sen kanssa. Ero Serializediin on se, että lukkoja ei käytetä, mutta sen seurauksena muutosten tekeminen ei välttämättä ole mahdollista, jos samanaikainen tapahtuma on muuttanut samoja tietoja aiemmin; tässä tapauksessa toinen tapahtuma, kun yrittää COMMITia, antaa virheilmoituksen ja se peruutetaan.
"+" - estää, "-" - ei estä.
| eristystaso | haamuluku | Ei toistuvaa luettavaa | "Likaista" luettavaa | Kadonnut päivitys [3] |
|---|---|---|---|---|
| SARJOITTAVA | + | + | + | + |
| TOISTETTU LUE | - | + | + | + |
| LUE SITOUTUNUT | - | - | + | + |
| LUE EI SITOTETTU | - | - | - | + [4] |