SQL Server Read Committed Snapshot

Question

Ich frage mich gerade etwas über Snapshot Verhalten auf Read Committed Isolation Level. Nehmen wir an, ich habe eine Tabelle mit dem Namen "A". Hier ist die erste Transaktion:

Select blabla 
From A 

Insert Into A blabla 

und zweite Transaktion hat die gleichen

Select blabla 
From A 

Insert Into A blabla 

und davon ausgeht, dass unter Timeline aufgetreten:

Tran1: select 
Tran1: insert (not yet committed) 
Tran2: select (I don't know it is possible or not) 
Tran2: insert 

Soweit ich weiß, in Standard-Lese begangen isolation level, trans2 select query würde blockiert werden, weil der Befehl tran1 noch nicht festgeschrieben oder zurückgesetzt wurde. Aber während "is_read_committed_snapshot" aktiviert ist, erwarte ich, dass während des Einfüge- oder Aktualisierungsbefehls keine der Sperren erfasst wird.

Was wird mit tran2 passieren?

Ich erwarte, dass trans2 Select Abfrage wird nicht die Daten, die von tran1 eingefügt, weil es "Dirty Read" wäre. Aber es würde auch nicht blockieren.

Aufgrund der Tran1-Einfügeabfrage erhält keine Sperre, wäre diese Situation kein Problem über die gleichzeitige Ausführung dieser beiden Transaktionen?

Answer 1

ich gehe davon aus, dass jede der Sperre nicht während des Einsatz erworben oder Befehl aktualisieren.

Das ist falsch. Selbst wenn Sie RCSI aktiviert haben, blockieren Schreiber immer noch Schreiber, und X Sperren werden immer noch akquiriert.

Was unterscheidet RC und RCSI ist lesen Verhalten. Bei Arbeiten an pessimistischen RC wird SELECT von Tran2 blockiert X Sperre auf A gehalten, während die Arbeit an RCSI Tran2 SELECT nicht blockiert wird, wird es mit der letzten festgeschriebenen Version von A, dh mit dem Status A bereitgestellt werden vor Tran1 hat es modifiziert.

Was dann geschah, hängt von Ihrer Tabellenorganisation und davon ab, was Sie INSERT.

Einige Beispiele.

1) Tabelle A ist ein Heap, Sie tun Single einfügen in beiden Transaktionen.

In diesem Fall Ihre INSERT in TRAN2 in jedem Fall gelingen wird, es den gleichen Wert, die Sie versuchen, in beiden Transaktionen einfügen oder nicht, weil das, was der Server erwirbt in diesem Fall ist IX auf einem Tisch (das kompatibel ist IX von TRAN1 gehalten mit), IX auf einer Seite (das ist auch kompatibel mit IX von TRAN1 gehalten, auch wenn es die gleichen Seite) ist, und X auf RID (während TRAN1 hat X auf andere RID), so Es gibt keinen Konflikt.

2) Tabelle A ist gruppierte Tabelle, Sie versuchen, den gleichen neuen Schlüssel in dieser Tabelle einzufügen.

In diesem Fall werden Ihre Tran2's INSERT gesperrt wegen des Konflikts zwischen zwei X Sperre auf der gleichen Taste, die erste wird von Tran1 gehalten, die secont wird von Tran2 angefordert und ist blockiert.

3) Tabelle A ist gruppierte Tabelle, Sie versuchen, verschiedene Schlüssel in dieser Tabelle einzufügen.

insert2 wird gelingen, weil X Sperre auf Schlüssel von TRAN2 angefordert wird gewährt, als TRAN1 IX auf dem Tisch hält, IX auf Seite und X auf another Schlüssel.

Answer 2

Lassen Sie uns sagen Sie es auf diese Weise tun:

SELECT id FROM customers 

BEGIN TRAN new_tran 
UPDATE customers 

SET ID = '1' WHERE '01' ID =

Wenn Ihre Abfrage so etwas wie dieses:

SET TRANSACTION ISOLATION LEVEL SNAPSHOT 
GO 
BEGIN TRAN 
SELECT * 
FROM customers 
WHERE id = '01' 

Ergebnis- Auch wenn wir den Wert auf 01 geändert haben, sehen wir immer noch den alten Datensatz in Sitzung 2 (2, TWO).

Nun lassen Sie uns Transaktion in der Sitzung begehen 1

können nun sagen Sie, die Transaktion, in der Sitzung 2, jetzt verpflichten Sie werden den neuen aktualisierten Wert erhalten:

COMMIT 
SELECT * 
FROM DemoTable 
WHERE i = 2 

Sie können mehr über lesen es auf Pinal Dave Blog: blog.sqlauthority.com/2015/07/03/sql-server-difference-between-read-committed-snapshot-and-snapshot-isolation-level/