Transaktionsisoleringsnivåer

2.1 Läs oengagerad

"Transaktionsisoleringsnivån" hänvisar till graden av skydd som tillhandahålls av DBMS:s interna mekanismer (det vill säga inte kräver speciell programmering) från alla eller några av ovanstående typer av datainkonsekvenser som uppstår under parallell utförande av transaktioner. SQL-92-standarden definierar en skala med fyra isoleringsnivåer:

• Läs oengagerad
• Läs engagerad
• Upprepningsbar läsning
• Serialiserbar

Den första av dem är den svagaste, den sista är den starkaste, varje efterföljande inkluderar alla tidigare.

Den lägsta (första) isoleringsnivån. Om flera parallella transaktioner försöker modifiera samma tabellrad, kommer den sista raden att ha ett värde som bestäms av hela uppsättningen av framgångsrikt genomförda transaktioner. I det här fallet är det möjligt att läsa inte bara logiskt inkonsekventa data, utan också data vars ändringar ännu inte har registrerats.

Ett typiskt sätt att implementera denna isoleringsnivå är att låsa data medan ändringskommandot körs, vilket säkerställer att modifieringskommandon på samma rader som körs parallellt faktiskt exekveras sekventiellt och ingen av ändringarna går förlorade. Skrivskyddade transaktioner blockeras aldrig under denna isoleringsnivå.

2.2 Läs engagerad

De flesta industriella DBMS, särskilt Microsoft SQL Server, PostgreSQL och Oracle, använder denna nivå som standard. På denna nivå tillhandahålls skydd mot utkast, "smutsig" läsning, men under driften av en transaktion kan en annan slutföras framgångsrikt och ändringarna som görs av den fixas. Som ett resultat kommer den första transaktionen att fungera med en annan datamängd.

Implementeringen av en fullständig läsning kan baseras på en av två metoder: blockering eller versionshantering.

Blockerar läsbar och föränderlig data.

Den består i det faktum att skrivtransaktionen blockerar föränderlig data för att läsa transaktioner som fungerar på läskommitterad nivå eller högre tills den slutförs, vilket förhindrar "smutsig" läsning, och data som låsts av lästransaktionen släpps omedelbart efter att operationen har slutförts SELECT(sålunda kan en "icke-repeterbar läsning"-situation inträffa på en given isoleringsnivå).

Sparar flera versioner av rader som ändras parallellt.

Varje gång en rad ändras skapar DBMS en ny version av denna rad, med vilken transaktionen som ändrade data fortsätter att fungera, medan alla andra "läsande" transaktioner returnerar den senast bekräftade versionen. Fördelen med detta tillvägagångssätt är att det är snabbare eftersom det förhindrar blockering. Det kräver dock, i jämförelse med den första, en betydligt större förbrukning av RAM, som går åt till att lagra radversioner.

Dessutom, när flera transaktioner ändrar data parallellt, kan det skapa en situation där flera samtidiga transaktioner gör inkonsekventa ändringar av samma data (eftersom det inte finns några lås, kommer ingenting att förhindra att detta händer). Då kommer transaktionen som först begås att spara sina ändringar i huvuddatabasen, och de återstående parallella transaktionerna kommer att vara omöjliga att begå (eftersom detta kommer att leda till att uppdateringen av den första transaktionen går förlorad). Det enda som DBMS kan göra i en sådan situation är att rulla tillbaka resten av transaktionerna och utfärda ett felmeddelande "Posten har redan ändrats".

En specifik implementeringsmetod väljs av DBMS-utvecklarna, och i vissa fall kan den anpassas. Så, som standard, använder MS SQL lås, men (i version 2005 och högre) när du ställer in databasparametern READ_COMMITTED_SNAPSHOTväxlar den till versionsstrategin, Oracle fungerar initialt endast enligt det versionerade schemat. I Informix kan du förhindra konflikter mellan läs- och skrivtransaktioner genom att ställa in ett konfigurationsalternativ USELASTCOMMITTED(från och med version 11.1) som gör att den lästa transaktionen tar emot de senaste committed data.

2.3 Repeterbar läsning

Den nivå på vilken en avläsningstransaktion "inte ser" ändras till den data som den tidigare har läst. Samtidigt kan ingen annan transaktion ändra data som läses av den aktuella transaktionen förrän den avslutas.

Lås i delat läge tillämpas på all data som läses av en instruktion i en transaktion och hålls kvar tills transaktionen slutförs. Detta förhindrar andra transaktioner från att ändra rader som lästes av den väntande transaktionen. Andra transaktioner kan dock infoga nyrader som matchar sökvillkoren för instruktioner som finns i den aktuella transaktionen. När satsen startas om av den aktuella transaktionen, kommer nya rader att hämtas, vilket resulterar i en fantomläsning.

Med tanke på att delade lås hålls till slutet av transaktionen, snarare än att de släpps i slutet av varje uttalande, är graden av samtidighet lägre än isoleringsnivån READ COMMITTED. Därför rekommenderas det i allmänhet inte att använda denna och högre transaktionsnivåer i onödan.

2.4 Serialiserbar

Den högsta nivån av isolering; transaktioner är helt isolerade från varandra, var och en utförs som om det inte fanns några parallella transaktioner. Det är bara på denna nivå som samtidiga transaktioner inte är föremål för "fantomläsnings"-effekten.

2.5 Stöd för transaktionsisolering i riktiga DBMS

Transaktions-DBMS stöder inte alltid alla fyra nivåerna och kan även introducera ytterligare. Det finns också olika nyanser i att tillhandahålla isolering.

Så i princip stöder Oracle inte nollnivån, eftersom dess implementering av transaktioner utesluter "smutsiga läsningar", och formellt inte tillåter inställning av den repeterbara läsnivån, det vill säga det stöder bara (som standard) Read committedoch Serializable. Samtidigt, på nivån för individuella kommandon, garanterar den faktiskt läsrepeterbarhet (om ett kommando SELECTi den första transaktionen väljer en uppsättning rader från databasen, och vid denna tidpunkt ändrar en parallell andra transaktion några av dessa rader, då resultatuppsättning som tas emot av den första transaktionen kommer att innehålla oförändrade rader, som om det inte fanns någon andra transaktion). Oracle stöder även så kallade READ-ONLYtransaktioner, som motsvarar Serializable, men kan inte själva ändra data.

Och Microsoft SQL Server stöder alla fyra standardtransaktionsisoleringsnivåerna, och dessutom SNAPSHOT-nivån, där transaktionen ser datatillståndet som begicks innan det lanserades, såväl som de ändringar som gjorts av sig själv, det vill säga den beter sig som om den togs emot vid start, en ögonblicksbild av DB-data och fungerar med den. Skillnaden mot Serialized är att inga lås används, men som ett resultat kan det inte vara möjligt att utföra ändringar om en samtidig transaktion har ändrat samma data tidigare; i detta fall kommer den andra transaktionen, när den försöker utföras, COMMITatt visa ett felmeddelande och avbrytas.