Transaksjonsisolasjonsnivåer

2.1 Les uforpliktet

"Transaksjonsisolasjonsnivået" refererer til graden av beskyttelse gitt av de interne mekanismene til DBMS (det vil si at de ikke krever spesiell programmering) fra alle eller noen av de ovennevnte typene datainkonsekvenser som oppstår under parallell utførelse av transaksjoner. SQL-92-standarden definerer en skala med fire isolasjonsnivåer:

• Les uforpliktende
• Les engasjert
• Repeterbar lesning
• Serialiserbar

Den første av dem er den svakeste, den siste er den sterkeste, hver påfølgende inkluderer alle de foregående.

Det laveste (første) isolasjonsnivået. Hvis flere parallelle transaksjoner forsøker å endre den samme tabellraden, vil den siste raden ha en verdi som bestemmes av hele settet med vellykket fullførte transaksjoner. I dette tilfellet er det mulig å lese ikke bare logisk inkonsistente data, men også data hvis endringer ennå ikke er registrert.

En typisk måte å implementere dette isolasjonsnivået på er å låse data mens endringskommandoen utføres, noe som sikrer at modifikasjonskommandoer på de samme radene som kjøres parallelt faktisk utføres sekvensielt og ingen av endringene går tapt. Skrivebeskyttede transaksjoner blokkerer aldri under dette isolasjonsnivået.

2.2 Les engasjert

De fleste industrielle DBMS, spesielt Microsoft SQL Server, PostgreSQL og Oracle, bruker dette nivået som standard. På dette nivået gis beskyttelse mot utkast, "skitten" lesing, men under driften av en transaksjon kan en annen fullføres og endringene som er gjort av den, fikses. Som et resultat vil den første transaksjonen fungere med et annet datasett.

Implementeringen av en fullstendig lesing kan være basert på en av to tilnærminger: blokkering eller versjonering.

Blokkering av lesbare og mutbare data.

Den består i det faktum at skrivetransaksjonen blokkerer mutbare data for lesing av transaksjoner som opererer på leseforpliktet nivå eller høyere til den fullføres, og forhindrer dermed "skitten" lesing, og dataene som er låst av lesetransaksjonen frigis umiddelbart etter at operasjonen er fullført SELECT(Dermed kan en "ikke-repeterbar lesning"-situasjon oppstå på et gitt isolasjonsnivå).

Lagre flere versjoner av rader som endres parallelt.

Hver gang en rad endres, oppretter DBMS en ny versjon av denne raden, som transaksjonen som endret dataene fortsetter å fungere med, mens enhver annen "lesende" transaksjon returnerer den siste forpliktede versjonen. Fordelen med denne tilnærmingen er at den er raskere fordi den forhindrer blokkering. Det krever imidlertid, sammenlignet med den første, et betydelig større forbruk av RAM, som brukes på å lagre radversjoner.

I tillegg, når flere transaksjoner endrer data parallelt, kan det skape en situasjon der flere samtidige transaksjoner gjør inkonsistente endringer i de samme dataene (siden det ikke er noen låser, vil ingenting forhindre at dette skjer). Da vil transaksjonen som forplikter seg først lagre endringene i hoveddatabasen, og de resterende parallelle transaksjonene vil være umulige å forplikte (da dette vil føre til tap av oppdateringen av den første transaksjonen). Det eneste DBMS kan gjøre i en slik situasjon er å rulle tilbake resten av transaksjonene og gi en feilmelding "Recorden er allerede endret".

En spesifikk implementeringsmetode velges av DBMS-utviklerne, og i noen tilfeller kan den tilpasses. Så, som standard, bruker MS SQL låser, men (i versjon 2005 og høyere) når du angir databaseparameteren READ_COMMITTED_SNAPSHOT, bytter den til versjonsstrategien, Oracle fungerer i utgangspunktet bare i henhold til den versjonerte ordningen. I Informix kan du forhindre konflikter mellom lese- og skrivetransaksjoner ved å sette et konfigurasjonsalternativ USELASTCOMMITTED(fra og med versjon 11.1) som gjør at den leste transaksjonen mottar de siste kommitterte dataene.

2.3 Repeterbar lesing

Nivået som en lesetransaksjon "ikke ser" endres til dataene den tidligere har lest. Samtidig kan ingen annen transaksjon endre dataene som leses av den gjeldende transaksjonen før den avsluttes.

Låser i delt modus brukes på alle data som leses av en instruksjon i en transaksjon og holdes til transaksjonen fullføres. Dette forhindrer andre transaksjoner fra å endre rader som ble lest av den ventende transaksjonen. Andre transaksjoner kan imidlertid sette inn nye linjer som samsvarer med søkebetingelsene for instruksjoner i den gjeldende transaksjonen. Når setningen startes på nytt av gjeldende transaksjon, vil nye rader bli hentet, noe som resulterer i en fantomlesing.

Gitt at delte låser holdes til slutten av transaksjonen, i stedet for å bli frigitt på slutten av hver uttalelse, er samtidighetsgraden lavere enn isolasjonsnivået READ COMMITTED. Derfor anbefales det generelt ikke å bruke dette og høyere transaksjonsnivåer unødvendig.

2.4 Serialiserbar

Det høyeste nivået av isolasjon; transaksjoner er fullstendig isolert fra hverandre, hver enkelt utføres som om det ikke var noen parallelle transaksjoner. Det er bare på dette nivået at samtidige transaksjoner ikke er gjenstand for "fantomlesing"-effekten.

2.5 Støtte for transaksjonsisolering i ekte DBMS

Transaksjons-DBMS støtter ikke alltid alle fire nivåene, og kan også introdusere flere. Det er også ulike nyanser i å gi isolasjon.

Så, i prinsippet, støtter ikke Oracle nullnivået, siden implementeringen av transaksjoner utelukker "skitne avlesninger", og formelt ikke tillater innstilling av gjentatt lesenivå, det vil si at den bare støtter (som standard) Read committedog Serializable. Samtidig, på nivået til individuelle kommandoer, garanterer den faktisk lesegjentakbarhet (hvis en kommando SELECTi den første transaksjonen velger et sett med rader fra databasen, og på dette tidspunktet endrer en parallell andre transaksjon noen av disse radene, vil resultatsett mottatt av den første transaksjonen vil inneholde uendrede rader, som om det ikke var noen andre transaksjon). Oracle støtter også såkalte READ-ONLYtransaksjoner, som tilsvarer Serializable, men kan ikke endre dataene selv.

Og Microsoft SQL Server støtter alle fire standard transaksjonsisolasjonsnivåer, og i tillegg SNAPSHOT-nivået, der transaksjonen ser datatilstanden som ble begått før den ble lansert, samt endringene som er gjort av seg selv, det vil si at den oppfører seg som hvis den mottok ved oppstart, et øyeblikksbilde av DB-dataene og fungerer med dem. Forskjellen fra Serialized er at ingen låser brukes, men som et resultat kan det hende at det ikke er mulig å foreta endringer hvis en samtidig transaksjon har endret de samme dataene før; i dette tilfellet vil den andre transaksjonen, når du forsøker å utføre, COMMITvise en feilmelding og bli kansellert.