SNAPSHOT-isolationsniveauet

Enhver serialiserbar transaktion, der udføres korrekt, når den køres alene, vil fortsætte med at udføre korrekt med enhver kombination af samtidige transaktioner, eller den vil blive rullet tilbage med en fejlmeddelelse (typisk et dødvande i SQL Servers implementering).

Ikke-serialiserbare isolationsniveauer, inklusive snapshot-isolering, giver ikke de samme stærke garantier for korrekthed.

Uaktuelle data

Snapshot-isolation virker næsten forførende enkel. Læsninger kommer altid fra forpligtede data fra et enkelt tidspunkt, og skrivekonflikter registreres og håndteres automatisk. Hvordan er dette ikke en perfekt løsning til alle samtidighedsrelaterede vanskeligheder?

Et potentielt problem er, at snapshot-læsninger ikke nødvendigvis afspejler den aktuelle forpligtede tilstand af databasen. En snapshot-transaktion ignorerer fuldstændigt alle forpligtede ændringer foretaget af andre samtidige transaktioner, efter at snapshot-transaktionen begynder. En anden måde at sige det på er at sige, at en øjebliksbilledetransaktion ser forældede, forældede data. Selvom denne adfærd kan være præcis, hvad der er nødvendigt for at generere en nøjagtig rapport på tidspunktet, er den måske ikke helt så egnet under andre omstændigheder (f.eks. når den bruges til at håndhæve en regel i en trigger).

Skriv skævt

Snapshot-isolation er også sårbar over for et noget relateret fænomen kendt som skriveskævhed. Læsning af forældede data spiller en rolle i dette, men dette problem hjælper også med at afklare, hvad snapshot 'skrivekonfliktdetektion' gør og ikke gør.

Skriveskævhed opstår, når to samtidige transaktioner hver læser data, som den anden transaktion ændrer. Der opstår ingen skrivekonflikt, fordi de to transaktioner ændrer forskellige rækker. Ingen af ​​transaktionerne ser ændringerne foretaget af den anden, fordi begge læser fra et tidspunkt, før disse ændringer blev foretaget.

Et klassisk eksempel på skriveskævhed er problemet med hvid og sort marmor, men jeg vil gerne vise et andet simpelt eksempel her:

-- Create two empty tables
CREATE TABLE A (x integer NOT NULL);
CREATE TABLE B (x integer NOT NULL);
 
-- Connection 1
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRANSACTION;
INSERT A (x) SELECT COUNT_BIG(*) FROM B;
 
-- Connection 2
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRANSACTION;
INSERT B (x) SELECT COUNT_BIG(*) FROM A;
COMMIT TRANSACTION;
 
-- Connection 1
COMMIT TRANSACTION;

Under snapshot-isolering ender begge tabeller i det script med en enkelt række, der indeholder en nulværdi. Dette er et korrekt resultat, men det kan ikke serialiseres:det svarer ikke til nogen mulig seriel transaktionsudførelsesordre. I enhver virkelig seriel tidsplan skal den ene transaktion fuldføres, før den anden starter, så den anden transaktion vil tælle rækken, der er indsat af den første. Dette lyder måske som en teknikalitet, men husk, at de kraftfulde serialiserbare garantier kun gælder, når transaktioner virkelig kan serialiseres.

En subtilitet til at opdage konflikter

En snapshot-skrivekonflikt opstår, når en snapshot-transaktion forsøger at ændre en række, der er blevet ændret af en anden transaktion, der blev udført, efter at snapshot-transaktionen begyndte. Der er to finesser her:

1. Transaktionerne behøver faktisk ikke at ændres eventuelle dataværdier; og
2. Transaktionerne behøver ikke at ændre nogen fælles kolonner .

Følgende script demonstrerer begge punkter:

-- Test table
CREATE TABLE dbo.Conflict
(
    ID1 integer UNIQUE,
    Value1 integer NOT NULL,
    ID2 integer UNIQUE,
    Value2 integer NOT NULL
);
 
-- Insert one row
INSERT dbo.Conflict
    (ID1, ID2, Value1, Value2)
VALUES
    (1, 1, 1, 1);
 
-- Connection 1
BEGIN TRANSACTION;
 
UPDATE dbo.Conflict
SET Value1 = 1
WHERE ID1 = 1;
 
-- Connection 2
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRANSACTION;
 
UPDATE dbo.Conflict
SET Value2 = 1
WHERE ID2 = 1;
 
-- Connection 1
COMMIT TRANSACTION;

Bemærk følgende:

• Hver transaktion lokaliserer den samme række ved hjælp af et andet indeks
• Ingen opdatering resulterer i en ændring af de data, der allerede er gemt
• De to transaktioner 'opdaterer' forskellige kolonner i rækken.

På trods af alt dette, når den første transaktion begår, afsluttes den anden transaktion med en opdateringskonfliktfejl:

Opsummering:Konfliktdetektion fungerer altid på niveau med en hel række, og en 'opdatering' behøver faktisk ikke at ændre nogen data. (Hvis du undrede dig, tæller ændringer af LOB- eller SLOB-data uden for rækken også som en ændring af rækken til konfliktdetekteringsformål).

Problemet med fremmednøgle

Konfliktregistrering gælder også for den overordnede række i et fremmednøgleforhold. Når du ændrer en underordnet række under snapshot-isolering, kan en ændring af den overordnede række i en anden transaktion udløse en konflikt. Som før gælder denne logik for hele den overordnede række - forældreopdateringen behøver ikke at påvirke selve kolonnen med fremmednøgle. Enhver handling på den underordnede tabel, der kræver en automatisk kontrol af fremmednøgle i eksekveringsplanen, kan resultere i en uventet konflikt.

For at demonstrere dette skal du først oprette følgende tabeller og eksempeldata:

CREATE TABLE dbo.Dummy
(
    x integer NULL
);
 
CREATE TABLE dbo.Parent
(
    ParentID integer PRIMARY KEY,
    ParentValue integer NOT NULL
);
 
CREATE TABLE dbo.Child 
(
    ChildID integer PRIMARY KEY,
    ChildValue integer NOT NULL,
    ParentID integer NULL FOREIGN KEY REFERENCES dbo.Parent
);
 
INSERT dbo.Parent 
    (ParentID, ParentValue) 
VALUES (1, 1);
 
INSERT dbo.Child 
    (ChildID, ChildValue, ParentID) 
VALUES (1, 1, 1);

Udfør nu følgende fra to separate forbindelser som angivet i kommentarerne:

-- Connection 1
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRANSACTION;
SELECT COUNT_BIG(*) FROM dbo.Dummy;
 
-- Connection 2 (any isolation level)
UPDATE dbo.Parent SET ParentValue = 1 WHERE ParentID = 1;
 
-- Connection 1
UPDATE dbo.Child SET ParentID = NULL WHERE ChildID = 1;
UPDATE dbo.Child SET ParentID = 1 WHERE ChildID = 1;

Læsningen fra dummy-tabellen er der for at sikre, at snapshot-transaktionen officielt er startet. Udsender BEGIN TRANSACTION er ikke nok til at gøre dette; vi skal udføre en form for dataadgang på en brugertabel.

Den første opdatering af Child-tabellen forårsager ikke en konflikt, fordi indstilling af referencekolonnen til NULL kræver ikke en overordnet tabelkontrol i udførelsesplanen (der er intet at kontrollere). Forespørgselsprocessoren rører ikke den overordnede række i udførelsesplanen, så der opstår ingen konflikt.

Den anden opdatering til Child-tabellen udløser en konflikt, fordi der automatisk udføres en fremmednøglekontrol. Når den overordnede række tilgås af forespørgselsprocessoren, kontrolleres den også for en opdateringskonflikt. Der opstår en fejl i dette tilfælde, fordi den refererede overordnede række har oplevet en forpligtet ændring, efter at øjebliksbilledetransaktionen startede. Bemærk, at ændringen af ​​den overordnede tabel ikke påvirkede selve kolonnen med fremmednøgle.

En uventet konflikt kan også opstå, hvis en ændring af tabellen underordnet refererer til en overordnet række, der er oprettet ved en samtidig transaktion (og den transaktion begået efter øjebliksbilledetransaktionen startede).

Resumé:En forespørgselsplan, der inkluderer en automatisk udenlandsk nøglekontrol, kan give en konfliktfejl, hvis den refererede række har oplevet nogen form for ændring (inklusive oprettelse!), siden snapshot-transaktionen startede.

Truncate Table Issue

En snapshot-transaktion vil mislykkes med en fejl, hvis en tabel, den får adgang til, er blevet afkortet, siden transaktionen begyndte. Dette gælder, selvom den trunkerede tabel ikke havde nogen rækker til at begynde med, som nedenstående script viser:

CREATE TABLE dbo.AccessMe
(
    x integer NULL
);
 
CREATE TABLE dbo.TruncateMe
(
    x integer NULL
);
 
-- Connection 1
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRANSACTION;
SELECT COUNT_BIG(*) FROM dbo.AccessMe;
 
-- Connection 2
TRUNCATE TABLE dbo.TruncateMe;
 
-- Connection 1
SELECT COUNT_BIG(*) FROM dbo.TruncateMe;

Det endelige SELECT mislykkes med fejlen:

Dette er endnu en subtil bivirkning, du skal tjekke efter, før du aktiverer snapshot-isolering på en eksisterende database.

Næste gang

Det næste (og sidste) indlæg i denne serie vil tale om det læste uforpligtende isolationsniveau (kærligt kendt som "nolock").