Transactie-isolatieniveaus

2.1 Lees vrij

Het "transactie-isolatieniveau" verwijst naar de mate van bescherming die wordt geboden door de interne mechanismen van het DBMS (d.w.z. waarvoor geen speciale programmering vereist is) tegen alle of sommige van de bovenstaande soorten gegevensinconsistenties die optreden tijdens parallelle uitvoering van transacties. De SQL-92-standaard definieert een schaal van vier isolatieniveaus:

• Lees vrijblijvend
• Lees toegewijd
• Herhaalbaar lezen
• Serialiseerbaar

De eerste is de zwakste, de laatste is de sterkste, elke volgende omvat alle voorgaande.

Het laagste (eerste) isolatieniveau. Als verschillende parallelle transacties dezelfde tabelrij proberen te wijzigen, heeft de laatste rij een waarde die wordt bepaald door de hele reeks met succes voltooide transacties. In dit geval is het mogelijk om niet alleen logisch inconsistente gegevens uit te lezen, maar ook gegevens waarvan de wijzigingen nog niet zijn vastgelegd.

Een typische manier om dit isolatieniveau te implementeren, is door gegevens te vergrendelen terwijl de wijzigingsopdracht wordt uitgevoerd, wat ervoor zorgt dat wijzigingsopdrachten op dezelfde rijen die parallel worden uitgevoerd daadwerkelijk opeenvolgend worden uitgevoerd en dat geen van de wijzigingen verloren gaat. Alleen-lezen transacties worden nooit geblokkeerd onder dit isolatieniveau.

2.2 Lees vastgelegd

De meeste industriële DBMS, met name Microsoft SQL Server, PostgreSQL en Oracle, gebruiken dit niveau standaard. Op dit niveau wordt bescherming geboden tegen tocht, "vuile" uitlezing, maar tijdens de uitvoering van de ene transactie kan een andere met succes worden voltooid en worden de aangebrachte wijzigingen hersteld. Hierdoor zal de eerste transactie met een andere dataset werken.

De implementatie van een volledige uitlezing kan op twee manieren worden gebaseerd: blokkeren of versiebeheer.

Leesbare en veranderlijke gegevens blokkeren.

Het bestaat uit het feit dat de schrijftransactie veranderlijke gegevens blokkeert voor leestransacties die werken op het leescommit-niveau of hoger totdat deze is voltooid, waardoor "vuile" lezen wordt voorkomen, en de gegevens die door de leestransactie zijn vergrendeld, worden onmiddellijk vrijgegeven nadat de bewerking is voltooid. SELECT(er kan dus een "niet-herhaalbare lees"-situatie optreden bij een bepaald isolatieniveau).

Het opslaan van meerdere versies van rijen die parallel veranderen.

Elke keer dat een rij wordt gewijzigd, maakt het DBMS een nieuwe versie van deze rij, waarmee de transactie die de gegevens heeft gewijzigd, blijft werken, terwijl elke andere "lees" -transactie de laatste vastgelegde versie retourneert. Het voordeel van deze aanpak is dat het sneller is omdat het blokkering voorkomt. Het vereist echter, in vergelijking met de eerste, een aanzienlijk groter RAM-verbruik, dat wordt besteed aan het opslaan van rijversies.

Wanneer meerdere transacties tegelijkertijd gegevens wijzigen, kan er bovendien een situatie ontstaan ​​waarin verschillende gelijktijdige transacties inconsistente wijzigingen aanbrengen in dezelfde gegevens (aangezien er geen vergrendelingen zijn, kan niets dit voorkomen). Vervolgens zal de transactie die als eerste vastlegt de wijzigingen opslaan in de hoofddatabase, en de resterende parallelle transacties kunnen niet worden vastgelegd (aangezien dit zal leiden tot het verlies van de update van de eerste transactie). Het enige dat het DBMS in zo'n situatie kan doen, is de rest van de transacties terugdraaien en een foutmelding geven "Het record is al gewijzigd".

Een specifieke implementatiemethode wordt gekozen door de DBMS-ontwikkelaars en kan in sommige gevallen worden aangepast. MS SQL gebruikt dus standaard sloten, maar (in versie 2005 en hoger) READ_COMMITTED_SNAPSHOTschakelt het bij het instellen van de databaseparameter over naar de versiebeheerstrategie, Oracle werkt aanvankelijk alleen volgens het versieschema. In Informix kunt u conflicten tussen lees- en schrijftransacties voorkomen door een configuratie-optie in te stellen USELASTCOMMITTED(vanaf versie 11.1) die ervoor zorgt dat de leestransactie de laatste vastgelegde gegevens ontvangt.

2.3 Herhaalbare lezing

Het niveau waarop een leestransactie "niet ziet" verandert in de gegevens die het eerder heeft gelezen. Tegelijkertijd kan geen enkele andere transactie de gegevens wijzigen die door de huidige transactie zijn gelezen totdat deze eindigt.

Vergrendelingen in gedeelde modus worden toegepast op alle gegevens die worden gelezen door een instructie in een transactie en worden vastgehouden totdat de transactie is voltooid. Dit voorkomt dat andere transacties rijen wijzigen die zijn gelezen door de lopende transactie. Andere transacties kunnen echter nieuwe regels invoegen die overeenkomen met de zoekvoorwaarden voor instructies in de huidige transactie. Wanneer de instructie opnieuw wordt gestart door de huidige transactie, worden nieuwe rijen opgehaald, wat resulteert in een fantoomlezing.

Aangezien gedeelde vergrendelingen worden vastgehouden tot het einde van de transactie, in plaats van te worden vrijgegeven aan het einde van elk overzicht, is de mate van gelijktijdigheid lager dan het isolatieniveau READ COMMITTED. Daarom wordt het over het algemeen niet aanbevolen om deze en hogere transactieniveaus onnodig te gebruiken.

2.4 Serialiseerbaar

Het hoogste niveau van isolatie; transacties zijn volledig geïsoleerd van elkaar, elke transactie wordt uitgevoerd alsof er geen parallelle transacties zijn. Alleen op dit niveau zijn gelijktijdige transacties niet onderhevig aan het "phantom read"-effect.

2.5 Ondersteuning voor transactie-isolatie in echt DBMS

Transactionele DBMS ondersteunen niet altijd alle vier niveaus en kunnen ook extra niveaus introduceren. Er zijn ook verschillende nuances in het aanbrengen van isolatie.

Dus in principe ondersteunt Oracle het nulniveau niet, aangezien de implementatie van transacties "dirty reads" uitsluit en het formeel niet toestaat om het herhaalbare leesniveau in te stellen, dat wil zeggen, het ondersteunt alleen (standaard) Read committeden Serializable. Tegelijkertijd garandeert het op het niveau van individuele commando's leesherhaalbaarheid (als een commando SELECTin de eerste transactie een set rijen uit de database selecteert, en op dit moment verandert een parallelle tweede transactie enkele van deze rijen, dan resultaatset ontvangen door de eerste transactie zal ongewijzigde rijen bevatten, alsof er geen tweede transactie was). Oracle ondersteunt ook zogenaamde READ-ONLYtransacties, die overeenkomen met Serializable, maar de gegevens zelf niet kunnen wijzigen.

En Microsoft SQL Server ondersteunt alle vier standaard transactie-isolatieniveaus, en bovendien het SNAPSHOT-niveau, waarop de transactie de gegevensstatus ziet die was vastgelegd voordat deze werd gelanceerd, evenals de wijzigingen die door hemzelf zijn aangebracht, dat wil zeggen, het gedraagt ​​zich als als het bij het opstarten een momentopname van de DB-gegevens heeft ontvangen en ermee werkt. Het verschil met Serialized is dat er geen vergrendelingen worden gebruikt, maar als gevolg daarvan is het misschien niet mogelijk om wijzigingen door te voeren als een gelijktijdige transactie eerder dezelfde gegevens heeft gewijzigd; in dit geval zal de tweede transactie, bij een poging tot uitvoering, COMMITeen foutmelding geven en worden geannuleerd.