RCSI is the row versioning of the Read Committed Isolation Level. Isolation Level that comes with SQL Server 2005.<\/p>\n
Unlike other Isolation Levels, it is not set by the SET TRANSACTION ISOLATION LEVEL command.<\/p>\n
This Isolation Level can be set based on the database. When set, all transactions in the database will work this way.<\/p>\n
Because of this, it is not necessary to make much changes in the application when going to this Isolation Level.<\/p>\n
On the other hand, this may cause inconsistencies in some cases.<\/p>\n
I will talk about these situations when examining the problems that might occur on the RCSI with SNAPSHOT in the 3rd part of the isolation level series.<\/p>\n
You can set it as follows.<\/p>\n
USE [master]\r\nGO\r\nALTER DATABASE [AdventureWorks2012] SET READ_COMMITTED_SNAPSHOT ON WITH NO_WAIT\r\nGO<\/pre>\n<\/p>\n
If your database is being used by other sessions, you may get an error like the following when you run the above script.<\/p>\n
<\/p>\n
Msg 5070, Level 16, State 2, Line 1<\/span><\/em><\/p>\n
Database state cannot be changed while other users are using the database \u2018AdventureWorks2012\u2019<\/span><\/em><\/p>\n
Msg 5069, Level 16, State 1, Line 1<\/span><\/em><\/p>\n
ALTER DATABASE statement failed.<\/span><\/em><\/p>\n
<\/p>\n
You can perform your transaction by rolling back other transactions with the WITH ROLLBACK IMMEDIATE command.<\/p>\n
In this Level, you will no longer have to wait for select queries.<\/p>\n
Provides statement-based read consistency.<\/p>\n
If each select statement starts, and the selected record is updated by another transaction, and the update has not yet been committed, the select query returns the most recently committed state of the data without waiting for the update to commit.<\/p>\n
It guarantees to see this value until the Statement is finished. However, on a transaction basis this does not guarantee.<\/p>\n
This check is done at the beginning of each statement in the transaction.<\/p>\n
<\/p>\n
For example, suppose you have two select statements in a transaction.<\/p>\n
As I mentioned earlier on the first select statement, read the last commit of the data.<\/p>\n
When the second select begins and the data to be read is committed, the two select will read the different values.<\/p>\n
<\/p>\n
How does the process of reading the most recently committed state of the data occur?<\/h3>\n
RCSI provides this feature with row versioning. That is, the data is being versioned using tempdb.<\/p>\n
Let’s say it’s an update operation.<\/p>\n
When the update operation is performed on the data (no commit yet), the most recently committed version of the data (before the update operation) is stored in tempdb.<\/p>\n
In the new version of Data, a link to the version in temdb is being created.<\/p>\n
In this way, when a select request comes in from within another transaction, it can read the last committed transaction in tempdb.<\/p>\n
This read is called Optimistic Read. When you enable RCSI in the database, row versioning starts.<\/p>\n
Each incoming update and delete operation (some insert operations) is versioned.<\/p>\n
14 bytes are added to each affected row in the database to keep the row versioning information that provides this feature.<\/p>\n
In this Isolation Level, update, delete and some inserts can use system resources more heavily since data is versioned on tempdb.<\/p>\n
But if tempdb uses more memory, this disadvantage can be reduced to a minimum. <\/span><\/p>\n
Also, before you set this feature, you should be sure that tempdb can handle this load<\/span>.<\/span><\/p>\n
Now let’s go back to our previous examples.<\/p>\n
At this Isolation Level, Lost Update, Non-repeatable read and Phantom Read will continue as read committed.<\/p>\n
<\/p>\n
Dirty Read:<\/h3>\n
Unlike READ COMMITTED, in the second session, select will read the most recently committed state without waiting.<\/p>\n
Select query will not do dirty read, and will not wait.<\/p>\n
<\/p>\n
SNAPSHOT ISOLATION LEVEL:\u00a0<\/span><\/h2>\n
Snapshot is the other Isolation Level that works with Row versioning. <\/span><\/p>\n
Unlike RCSI, it provides transaction-based read consistency. <\/span><\/p>\n
With this feature you will have solved many concurrency problems.<\/span><\/p>\n
When we repeat our examples, we will see how these problems are overcome.<\/p>\n
As I mentioned in the RCSI, for example, the first select statement reads the most recently committed state of the data.<\/p>\n
At the moment the second select begins, the second select reads the same value as the first select, even though the data to be read is committed.<\/p>\n
Database-based activation is required. You can activate it with the following script.<\/p>\n
ALTER DATABASE [AdventureWorks2012] SET ALLOW_SNAPSHOT_ISOLATION ON\r\nGO<\/pre>\nThe other difference from RCSI is that it does not apply to all transactions even though it is activated in the database.<\/p>\n
Only for transactions you specify with SET TRANSACTION ISOLATION LEVEL SNAPSHOT.<\/p>\n
Because of this, the workload will increase when the application passes to this Isolation Level.<\/p>\n
As an important point to be noted, If you grant SNAPSHOT to a database-based instance, update, delete and some inserts will start to be versioned even if you do not use SNAPSHOT in your transactions.<\/p>\n
This will cause heavy usage in tempdb. Now we need to run our samples at the SNAPSHOT Isolation Level.<\/p>\n
The Dirty Read example will behave as in the RCSI.<\/p>\n
<\/p>\n
Non-repeatable read:<\/h3>\n
The only difference from the REPEATABLE READ ISOLATION LEVEL is that the second session will continue without waiting and the first session will continue to return the same result in both selects.<\/p>\n
As you can see, transaction-based read consistency prevents non-repeatable reads.<\/p>\n
<\/p>\n
Lost update:<\/h3>\n
When we run our samples, we see that the second session completes the operation and returns 1100 values.<\/p>\n
The first session gets an error like below. Snapshot isolation transaction aborted due to update conflict.<\/p>\n
You can not use snapshot isolation to access table ‘Production.Product’ directly or indirectly in database ‘AdventureWorks2012’ to update, delete, or insert the row that has been modified or deleted by another transaction.<\/p>\n
Retry the transaction or change the isolation level for the update \/ delete statement.<\/p>\n
As you can see, he did not allow the first transaction to be crashed.<\/p>\n
However, the session that read the data first was aborted.<\/p>\n
<\/p>\n
Phantom Read:<\/span>\u00a0<\/span><\/h3>\n
Unlike the SERIALIZABLE Isolation Level, the second session was able to insert without waiting for the first session to finish. <\/span><\/p>\n
But as I mentioned earlier, SNAPSHOT provided transaction-based read consistency, so the second select read the same value in the first select. <\/span><\/p>\n
This way the Phantom Read has been blocked.<\/span><\/p>\n