Isolering (databasesystemer) - Isolation (database systems)

I database systemer, isolation bestemmer, hvordan transaktion integritet er synligt for andre brugere og systemer.

Et lavere isolationsniveau øger mange brugeres mulighed for at få adgang til de samme data på samme tid, men øger antallet af samtidige effekter (f.eks. Beskidte læsninger eller mistede opdateringer), som brugere muligvis støder på. Omvendt reducerer et højere isolationsniveau de typer samtidige effekter, som brugerne kan støde på, men kræver flere systemressourcer og øger chancerne for, at en transaktion blokerer for en anden.

Isolering defineres typisk på databaseniveau som en egenskab, der definerer, hvordan eller hvornår de ændringer, der foretages af en operation, bliver synlige for andre. På ældre systemer kan det implementeres systemisk, f.eks. Ved hjælp af midlertidige tabeller. I to-trins systemer kræves en transaktionsbehandling (TP) manager for at opretholde isolation. I n-tiersystemer (såsom flere websteder, der forsøger at booke det sidste sæde på en flyvning), kræves en kombination af lagrede procedurer og transaktionsstyring for at foretage reservationen og sende bekræftelse til kunden.

Isolation er en af de fire ACID egenskaber, sammen med Atomicity , konsistens og holdbarhed .

Samtidig kontrol

Samtidig kontrol omfatter de underliggende mekanismer i en DBMS, der håndterer isolering og garanterer relateret korrekthed. Det bruges stærkt af database- og lagermotorer både for at garantere den korrekte udførelse af samtidige transaktioner og (via forskellige mekanismer) rigtigheden af ​​andre DBMS-processer. Transaktionen-relaterede mekanismer typisk begrænse databasedataene adgang operationer timing ( transaktions skemaer ) til visse ordrer karakteriseret som serializability og nyttiggørelse schedule egenskaber. Begrænsning af udførelse af databaseadgangsoperation betyder typisk reduceret ydeevne (målt ved udførelseshastigheder), og dermed er samtidige kontrolmekanismer typisk designet til at give den bedst mulige ydeevne under begrænsningerne. Når det er muligt uden at skade korrektheden, komprimeres egenskaben for seriabilitet ofte for bedre ydeevne. Gendannelsesmuligheden kan imidlertid ikke kompromitteres, da sådan typisk resulterer i en hurtig databasens integritetsovertrædelse .

To-faselåsning er den mest almindelige metode til transaktions samtidighedskontrol i DBMS'er, der bruges til at tilvejebringe både serialiserbarhed og gendannelse for korrekthed. For at få adgang til et databaseobjekt skal en transaktion først erhverve en lås til dette objekt. Afhængig af adgangsfunktionstypen (f.eks. Læsning eller skrivning af et objekt) og af låsetypen kan erhvervelse af låsen muligvis blive blokeret og udsat, hvis en anden transaktion holder en lås til det pågældende objekt.

Læs fænomener

ANSI / ISO-standarden SQL 92 henviser til tre forskellige læsefænomener, når Transaktion 1 læser data, som Transaktion 2 muligvis har ændret.

I de følgende eksempler finder to transaktioner sted. I den første udføres Forespørgsel 1. Derefter udføres og begås forespørgsel 2 i den anden transaktion. Endelig udføres forespørgsel 1 i den første transaktion igen.

Forespørgslerne bruger følgende datatabel:

brugere
id navn alder
1 Joe 20
2 Jill 25

Beskidt læser

En beskidt læsning (også kendt uafhængig afhængighed ) opstår, når en transaktion får lov til at læse data fra en række, der er blevet ændret af en anden kørende transaktion og endnu ikke er begået.

Beskidte læser fungerer på samme måde som ikke-gentagelige læser ; dog behøver den anden transaktion ikke at blive begået for den første forespørgsel for at returnere et andet resultat. Det eneste, der kan forhindres i LÆS UNCOMMITTED isolationsniveau, er opdateringer, der vises ude af rækkefølge i resultaterne; tidligere opdateringer vises altid i et resultatsæt før senere opdateringer.

I vores eksempel ændrer Transaktion 2 en række, men begår ikke ændringerne. Transaktion 1 læser derefter de ikke-forpligtede data. Nu hvis Transaktion 2 ruller sine ændringer tilbage (allerede læst af Transaktion 1) eller opdaterer forskellige ændringer i databasen, kan visningen af ​​dataene muligvis være forkert i posterne for Transaktion 1.

Transaktion 1 Transaktion 2 
/* Query 1 */
SELECT age FROM users WHERE id = 1;
/* will read 20 */

/* Query 2 */
UPDATE users SET age = 21 WHERE id = 1;
/* No commit here */

/* Query 1 */
SELECT age FROM users WHERE id = 1;
/* will read 21 */

ROLLBACK; /* lock-based DIRTY READ */

Men i dette tilfælde findes der ingen række, der har en id på 1 og en alder på 21.

Ikke-gentagelig læser

En ikke-gentagelig læsning opstår, når en række i løbet af en transaktion hentes to gange, og værdierne inden for rækken adskiller sig mellem læsninger.

Ikke-gentagelig læserfænomen kan forekomme i en låsebaseret samtidighedskontrolmetode, når læselåse ikke erhverves, når der udføres en SELECT , eller når de erhvervede låse på berørte rækker frigives, så snart SELECT-operationen udføres. Under multiversion-samtidighedskontrolmetoden kan ikke-gentagelige læsninger forekomme, når kravet om, at en transaktion, der er berørt af en begå konflikt, skal rulles tilbage, er lempet.

Transaktion 1 Transaktion 2 
/* Query 1 */
SELECT * FROM users WHERE id = 1;

/* Query 2 */
UPDATE users SET age = 21 WHERE id = 1;
COMMIT; /* in multiversion concurrency
   control, or lock-based READ COMMITTED */

/* Query 1 */
SELECT * FROM users WHERE id = 1;
COMMIT; /* lock-based REPEATABLE READ */

I dette eksempel forpligter Transaktion 2 sig med succes, hvilket betyder, at dens ændringer i rækken med id 1 skal blive synlige. Transaktion 1 har dog allerede set en anden værdi for alderen i den række. På isolationsniveauerne SERIALIZABLE og REPEATABLE READ skal DBMS returnere den gamle værdi for det andet SELECT. Ved LÆS UDGIVET og LÆS UKOMMITERET kan DBMS muligvis returnere den opdaterede værdi; dette er en ikke-gentagelig læsning.

Der er to grundlæggende strategier, der bruges til at forhindre ikke-gentagelige læser. Den første er at udsætte udførelsen af ​​Transaktion 2, indtil Transaktion 1 er forpligtet eller rullet tilbage. Denne metode bruges, når låsning anvendes, og producerer den serielle tidsplan T1, T2 . En seriel tidsplan viser gentagelig læseadfærd .

I den anden strategi, som brugt i multiversion-samtidighedskontrol , er Transaktion 2 tilladt at begå først, hvilket giver bedre samtidighed. Transaktion 1, der startede før Transaktion 2, skal dog fortsætte med at fungere på en tidligere version af databasen - et øjebliksbillede af det øjeblik det blev startet. Når Transaktion 1 til sidst forsøger at begå, kontrollerer DBMS, om resultatet af at begå Transaktion 1 svarer til tidsplanen T1, T2 . Hvis det er tilfældet, kan Transaktion 1 fortsætte. Hvis det ikke kan ses at være ækvivalent, skal Transaktion 1 dog rulle tilbage med en serialiseringsfejl.

Ved hjælp af en låsebaseret samtidighedskontrolmetode i isolationsfunktionen GENTAGELIG LÆS ville rækken med ID = 1 blive låst og dermed blokere forespørgsel 2, indtil den første transaktion blev begået eller rullet tilbage. I LÆS KOMMITTET tilstand, anden gang forespørgsel 1 blev udført, ville alderen have ændret sig.

Under multiversion-samtidighedskontrol på SERIALIZABLE-isolationsniveau ser begge SELECT-forespørgsler et øjebliksbillede af databasen taget i starten af ​​Transaktion 1. Derfor returnerer de de samme data. Imidlertid, hvis Transaktion 2 derefter også forsøgte at OPDATERE den række, ville der opstå en serialiseringsfejl, og Transaktion 1 ville blive tvunget til at rulle tilbage.

På LÆS KOMMITTET isolationsniveau ser hver forespørgsel et øjebliksbillede af databasen taget i starten af ​​hver forespørgsel. Derfor ser de hver især forskellige data for den opdaterede række. Ingen serialiseringsfejl er mulig i denne tilstand (fordi der ikke gives løfte om serialiserbarhed), og Transaktion 1 behøver ikke at blive prøvet igen.

Fantom læser

En fantomlæsning opstår, når nye rækker i løbet af en transaktion tilføjes eller fjernes af en anden transaktion til de poster, der læses.

Dette kan forekomme, når der ikke opnås rækkevidde ved udførelse af en SELECT ... WHERE- operation. Den fantom læser anomali er et særligt tilfælde af ikke-gentagelig læser når handel 1 gentager en varierede SELECT ... WHERE forespørgsel og mellem begge operationer, handel 2 skaber (dvs. INSERT ) nye rækker (i måltabellen), som opfylder at WHERE klausul.

Transaktion 1 Transaktion 2 
/* Query 1 */
SELECT * FROM users
WHERE age BETWEEN 10 AND 30;

/* Query 2 */
INSERT INTO users(id, name, age) VALUES (3, 'Bob', 27);
COMMIT;

/* Query 1 */
SELECT * FROM users
WHERE age BETWEEN 10 AND 30;
COMMIT;

Bemærk, at Transaktion 1 udførte den samme forespørgsel to gange. Hvis det højeste niveau af isolering blev opretholdt, skulle det samme sæt af rækker returneres begge gange, og det er faktisk det, der er forpligtet til at forekomme i en database, der fungerer på SQL SERIALIZABLE-isolationsniveau. På de lavere isolationsniveauer kan et andet sæt rækker imidlertid returneres anden gang.

I SERIALIZABLE-isolationstilstand ville forespørgsel 1 resultere i, at alle poster med alderen i intervallet 10 til 30 låses, og forespørgsel 2 vil således blokere, indtil den første transaktion blev begået. I REPEATABLE READ-tilstand ville området ikke blive låst, så posten kunne indsættes. Derfor ville den anden erklæring fra forespørgsel 1 ikke returnere det samme resultat som den første.

Isolationsniveauer

Af de fire ACID- egenskaber i et DBMS (Database Management System) er isolationsegenskaben den mest afslappede. Når du forsøger at opretholde det højeste niveau af isolation, erhverver en DBMS normalt låse på data, der kan resultere i et tab af samtidighed eller implementerer multiversion-samtidighedskontrol . Dette kræver tilføjelse af logik, for at applikationen kan fungere korrekt.

De fleste DBMS'er tilbyder et antal transaktionsisoleringsniveauer , der styrer graden af ​​låsning, der opstår, når der vælges data. For mange databaseapplikationer kan størstedelen af ​​databasetransaktioner konstrueres for at undgå at kræve høje isolationsniveauer (f.eks. SERIALISERET niveau), hvilket reducerer låsekostnaden for systemet. Programmøren skal omhyggeligt analysere adgangskoden til databasen for at sikre, at enhver lempelse af isolation ikke forårsager softwarefejl, der er svære at finde. Omvendt, hvis der anvendes højere isolationsniveauer, øges muligheden for blokering , hvilket også kræver omhyggelig analyse og programmeringsteknikker for at undgå.

Da hvert isolationsniveau er stærkere end nedenunder, idet intet højere isolationsniveau tillader en handling, der er forbudt af en lavere, tillader standarden en DBMS at køre en transaktion på et isolationsniveau, der er stærkere end det anmodede (f.eks. En "Læs begået" transaktion kan faktisk udføres på et "Repeatable read" isolationsniveau).

Isolationsniveauerne defineret af ANSI / ISO SQL- standarden er angivet som følger.

Serialiserbar

Dette er det højeste isolationsniveau.

Med en låsebaseret DBMS-implementering af samtidighedskontrol kræver serialiserbarhed læse- og skrivelåse (erhvervet på udvalgte data) for at blive frigivet i slutningen af ​​transaktionen. Også spænder-låse skal erhverves, når en SELECT forespørgsel anvender en varierede WHERE klausul, især for at undgå fantom læser fænomen.

Når du bruger ikke-låsebaseret samtidighedskontrol, erhverves der ingen låse; dog hvis systemet registrerer en skrivekollision blandt flere samtidige transaktioner, er det kun en af ​​dem, der har lov til at begå. Se isolering af snapshot for at få flere oplysninger om dette emne.

Fra: (Second Informal Review Draft) ISO / IEC 9075: 1992, Database Language SQL - 30. juli 1992: Udførelsen af ​​samtidige SQL-transaktioner på isolationsniveau SERIALIZABLE garanteres at blive serieliserbar. En serieliserbar udførelse defineres som en udførelse af operationerne ved samtidig udførelse af SQL-transaktioner, der giver den samme effekt som en eller anden seriel udførelse af de samme SQL-transaktioner. En seriel udførelse er en, hvor hver SQL-transaktion udføres til afslutning, inden den næste SQL-transaktion begynder.

Gentagende læser

På dette isolationsniveau holder en låsebaseret DBMS-implementering af samtidighedskontrol læsning og skrivelåse (erhvervet på udvalgte data) indtil transaktionens afslutning. Imidlertid styres rækkevidde ikke, så fantomlæsninger kan forekomme.

Det er muligt at skrive skævt på dette isolationsniveau i nogle systemer. Skriv skævt er et fænomen, hvor to skrivninger er tilladt til samme kolonne (r) i en tabel af to forskellige forfattere (som tidligere har læst de kolonner, de opdaterer), hvilket resulterer i, at kolonnen har data, der er en blanding af de to transaktioner .

Læs engageret

I dette isolationsniveau holder en låsebaseret samtidighedskontrol- DBMS-implementering skrivelåse (erhvervet på udvalgte data) indtil afslutningen af ​​transaktionen, men læselåse frigives, så snart SELECT- operationen udføres (så det ikke-repeterbare læser fænomen kan forekomme i dette isolationsniveau). Som i det foregående niveau styres rækkevidde-låse ikke.

Ved at sætte det i enklere ord er læst begået et isolationsniveau, der garanterer, at læst data begås i det øjeblik, de læses. Det begrænser simpelthen læseren fra at se nogen mellemliggende, uforpligtende, 'beskidte' læst. Det giver intet løfte om, at hvis transaktionen genudsteder læsningen, vil den finde de samme data; data kan ændres gratis, efter at de er læst.

Læs uforpligtende

Dette er det laveste isolationsniveau. På dette niveau er beskidte læsninger tilladt, så en transaktion ser muligvis ikke-forpligtede ændringer foretaget af andre transaktioner.

Standard isolationsniveau

Den standard isolation niveau af forskellige DBMS 's varierer ganske meget. De fleste databaser, der indeholder transaktioner, giver brugeren mulighed for at indstille ethvert isolationsniveau. Nogle DBMS'er kræver også yderligere syntaks, når man udfører en SELECT-sætning for at erhverve låse (f.eks. SELECT ... FOR UPDATE for at erhverve eksklusive skrivelåse på rækker, der er adgang til).

Definitionerne ovenfor er imidlertid blevet kritiseret for at være tvetydige og som ikke nøjagtigt afspejler isolationen fra mange databaser:

Dette papir viser en række svagheder i anomali-tilgangen til at definere isolationsniveauer. De tre ANSI-fænomener er tvetydige og udelukker selv i deres løseste fortolkninger ikke noget unormalt adfærd ... Dette fører til nogle kontraintuitive resultater. Især har låsebaserede isolationsniveauer forskellige karakteristika end deres ANSI-ækvivalenter. Dette er foruroligende, fordi kommercielle databasesystemer typisk bruger låseimplementeringer. Derudover skelner ANSI-fænomenerne ikke mellem et antal typer adfærd på isolationsniveau, der er populære i kommercielle systemer.

Der er også anden kritik vedrørende ANSI SQLs isolationsdefinition, idet den tilskynder implementatorer til at gøre "dårlige ting":

... det bygger på subtile måder på en antagelse om, at et låseskema bruges til samtidighedskontrol i modsætning til et optimistisk eller flerversioners samtidighedsskema. Dette indebærer, at den foreslåede semantik er dårligt defineret .

Isolationsniveauer, læse fænomener og låse

Isolationsniveauer vs læste fænomener

'+' - muligt
'-' - ikke muligt


             Læs fænomener


Isolationsniveau

 Beskidt læser Mistede opdateringer Ikke-gentagelig læser Fantomer
Læs Uforpligtet + + + +
Læs Forpligtet - + + +
Gentagelig læsning - - - +
Serialiserbar - - - -

Anomali Serializable er ikke det samme som Serializable. Det vil sige, det er nødvendigt, men ikke tilstrækkeligt, at en Serialiserbar tidsplan skal være fri for alle tre fænomentyper.

Se også

Referencer

eksterne links