Read catalog (Content)

1 Concurrency Control Theory

2 isolation level

MySQL is achieved by concurrency control and locking MVCC, four isolation level, the data write mode and locking differently to meet different business needs.

In MSSQL, the also be achieved through locks and concurrency control line version of MVCC.

Each transaction, the type of lock, level, lock released, the isolation level is controlled by a transaction in MSSQL, the six isolation levels, different isolation levels for the lock is not the same application. This isolation level two, there are two applications MVCC mechanism, which is like a snapshot isolation levels: Read Commmitted Snapshot with Snapshot.

1 Concurrency Control Theory

In MSSQL, concurrency control theory is often used with pessimistic concurrency control optimistic concurrency control.

1.1 pessimistic concurrency control

Pessimistic concurrency, by default during a transaction operation, there will be other things competing for resources with it, so in the course of affairs operations, will add the data lock to avoid modifying the data during the operation of reading or other transactions under different circumstances , to ensure data consistency.

Pessimistic concurrency control, due to the inclusion of the lock mechanism, to a large extent will affect the concurrent scale. Mainly used in the data change frequently, and rolling back a transaction cost is greater than the cost of the lock data in the system .

1.2 optimistic concurrency control

Positive control, the default transaction at the time of reading data, and other matters such data is not in operation, so it will not lock, directly modify the data, the revised reading to see whether other users modify the data during the data, and if so, modify transaction itself is rolled back.

Optimistic concurrency control, data modification is applied frequently, and roll back the transaction cost less than the cost of a system lock data .

2 isolation level

In each transaction, are assigned a level of isolation, the isolation level defines the degree of isolation between the transaction with other transactions.

In MSSQL, there are six kinds of isolation levels, four isolation levels with two conventional snapshot isolation levels: Read UnCommitted, Read Committed, Read Commmitted (line version), Read Repeattable, Snapshot with Read Serializeble. Read Commmitted (line version) may come into contact with Snapshot cases is relatively small, but still explained.

In MySQL, the default isolation level is RR, but in SQL SERVER, the default isolation level is RC, Read Committed.

2.1 Isolation Level Description

How to set the default of the entire database isolation level?

Bowen explained inconsistent data before See: http://www.cnblogs.com/xinysu/p/7260227.html chapter four: data inconsistencies.

Hereinafter S said lock, not all locking procedure (MSSQL IS lock or the application).

Read UnCommitted

Referred to as RU, read uncommitted records, always read the latest record
Dirty reads, non-repeatable read may exist, phantom read other issues
S read process without a lock, the FROM tbName * is equivalent to the SELECT with (NOLOCK)

Read Committed

Referred to as RC, Read Committed record
There may not be repeatable read, phantom read other issues
The process of reading plus S lock, whether the transaction is completed, SELECT statement once completed, immediately release the S lock, wait until the end of the transaction will not only release the lock, follow the Strict 2-PL

Read Commmitted (line version)

Referred RCSI
MVCC principle application, version read, read committed records, but not necessarily to read the latest record
The same transaction, data is read are the same version
There is no dirty reads, non-repeatable read problem, there may be a problem phantom read
Version control Version data line isolation level, the database itself does not exist, but the presence of the tempdb, will hereinafter be described in detail the isolation level

Read Repeattable

Acronym RR, repeatable read record
There may be other issues phantom read
The process of reading plus S lock until the end of the transaction, before the release of the S-lock, follow the Stong Strict 2-PL

Snapshot

Referred to as SI
This will be described in detail below isolation levels

Read Serializeble

Acronym RS, the sequence of reading recorded
Dirty reads, non-repeatable read, phantom read, etc. there is no problem
During a read lock in addition to adding S, the lock range is also added; the process of modifying the data, in addition to adding X lock, the lock range is also added, to avoid the qualified data during operation, there are other qualified data come INSERT
Concurrency worst, unless explicitly demand the performance and impact business use only, have encountered the framework of a short message service using the default isolation level, on the line after the outbreak of the K on the deadlock, immediately analyze the Emergency Repair ....

2.2 Read Commmitted Snapshot Isolation 与 Snapshot Isolation

Read Commmitted Snapshot Isolation uses row versioning statement-level snapshots, when the data is modified or deleted in a transaction, call the written copy mechanism to ensure that older versions of rows of data written to meet the consistency of affairs before the operation. RCSI ensure that the statement-level read consistency.

Snapshot Isolation uses row versioning transaction-level snapshots, when the beginning of the transaction, call the write replication mechanism. SI ensure that transaction-level read consistency.

How to manage information line version of it?

Line version of both information is stored in the tempdb database is not stored in the database itself, which requires tempdb must have enough space to store version information, if tempdb space is insufficient, the line version of the write fails, resulting in the isolation level It does not work properly.

Storage engines for transactions using RCSI or SI isolation level, the transaction started when SI assigns a transaction sequence number XLN, each allocation is incremented by one, in order to achieve transaction-level consistency, where attention RCSI transaction sequence number is not a transaction a serial number, but in the affairs of each SQL transaction serial number, in order to achieve the statement level snapshot. Both the isolation level required to maintain copies of all data modifications performed logical (i.e. line version), which is stored in the tempdb logical copy, each logical copy (line version) for this transaction are marked transaction sequence number XLN . The latest row value that is stored in the current database, and line version history information including the latest version, stored in tempdb. Here note, when modifying data within a transaction write line version of the information, first written to the cache pool, in refreshed tempdb file to avoid too much impact on performance.

This time, you may ask? Would not it tempdb to store a lot of historical versions of data, there is no mechanism to delete it?

This is there, on the one hand, the version information line will not be immediately deleted, as required to ensure that control transactions running under row versioning-based isolation levels, to ensure that concurrent transactions If you are using tempdb-line version of the information will not be affected. On the other hand, database storage engine tracks the transaction sequence number of the earliest available, then periodically delete smaller than the sequence number of all lines of XLN version.

How to read the information on-line version of it?

When reading data transaction under snapshot isolation level of the two, being read will not get shared lock on the data, it will not clog being modified transaction, due to the reduced number of locks applications and can provide its DB concurrency . But where will acquire schema locks table, if the table is found schema modifications (such as increasing the column modification, etc.), it will be blocked.

How to read the right line version, there is a difference between RCSI with SI.

RCSI: each time the statement started , submit all data simultaneously read in tempdb latest transaction sequence, which makes each statement in the transaction can be viewed at RCSI start each sentence existence of the latest snapshot of the data, that is, the transaction within multiple SQL queries gaps there are other transaction modifies data, so many times the same SQL query results with the transaction will appear inconsistent.

SI: Every time the transaction starts , all data submitted, but less than the closest reading itself snapshot transaction sequence number, which is the number of SQL queries within a transaction, the read data is the same version, even if multiple queries there are other matters gap to modify the data, read the result is the same.

How to modify the information line version of it?

In use RCSI transaction, using obstructive scan (which will be used when reading a data value update lock (U lock) on a data line is completed to update the row selection, rows satisfy the condition of the lock to update the upgrade exclusive lock, Note that this is not the scan-line version of tempdb inside information, but the latest actual database rows inside, with the same mechanism of modified data RC. If the data row does not meet the conditions update, then the bank will release the update lock, while after locking the next line and scans it. holding the lock, then the data update, after the end of the transaction, the lock is released.

In use SI affairs, data modification using optimistic: Use line version of the data, data modification, until the data modification is completed, the only acquire locks on actual data, when the data rows that match the updated standard, then submit the modified data row . If the data has been modified in line outside the snapshot transaction, an update conflict will occur, while snapshot transactions will be terminated. Update conflict is handled by the database engine, you can not disable the update conflict detection.

From simple SQL to analyze, WHERE conditions are the primary key (only personal guess test):

The same transaction, repeatedly SELECT * FROM tbname WHERE id = 2

RCSI, in the same transaction, each SQL start time , submit the data to the tempdb form (personal speculation, should be assigned a similar hash string like, if multiple queries with the same transaction in the result, should do not start at the time of each SQL repeated line version submitted to tempdb) , read from tempdb in the latest version information , if tempdb no version information, read from the database, and to read the records are stored in tempdb. There will be the same one transaction, read many cases data inconsistent results.
SI, in the same transaction, the same SQL within the same transaction reads from tempdb in the current transaction from the latest version , the entire internal affairs are using this version of SQL data, if tempdb no version information, read from the database taken, and the record is stored in the read tempdb. With a transaction, there will be no case of multiple reads data inconsistent results.

UPDATE tbname SET colname='xinysu' WHERE id=18

RCSI, directly read the data in the database, based on the master key plus X lock, the update data, the RC operation with the isolation level is the same.
SI, read data line version, select the row on row versions need to be updated, modified after the modified data to the database to the actual period if the actual data in the database during this operation has been modified value other matters, update conflict occurs, the transaction would stop error. Ie, SI during the UPDATE, an update conflict detection.

Why first row update on the version, the last update to the actual data?
Suppose a need to run UPDATE 3s, but only updates a row record, if the update directly on actual data, you need to lock scan recording 3s, the last update, will plug the middle to query the data of other transactions, but if the line updates, you do not need to lock the actual data on the release, last updated 1 rows of time, very quickly, to avoid prolonged congestion and improve concurrency .

Attributes	Use row versioning isolation level of Read Committed	Snapshot isolation level
Database-level option to start	READ_COMMITTED_SNAPSHOT	ALLOW_SNAPSHOT_ISOLATION
Transaction Set	Use the default read-committed isolation level, or run the SET TRANSACTION ISOLATION LEVEL statement to specify the isolation level READ COMMITTED	SET TRANSACTION ISOLATION LEVEL to specify the SNAPSHOT isolation level before the transaction is started
Line version of the process	All data submitted prior to the start of each statement.	All data submitted prior to the start of each transaction.
Update process	Line version to recover from the actual data, to select the rows to update and uses update locks on the selected data line. Obtain an exclusive lock on the data you want to modify the actual line. No update conflict detection.	Use row versions to select rows to update. Try to acquire an exclusive lock on the actual rows of data to be modified, if the data has been modified by another transaction, an update conflict occurs, while snapshot transactions will be terminated.
Update conflict detection	no	Integration support. You can not be disabled.

3 isolation level test

View the current session of the database isolation level: DBCC USEROPTIONS, see [set options] = 'isolation level', you can view the current transaction isolation level.

Bowen explained inconsistent data before See: http://www.cnblogs.com/xinysu/p/7260227.html chapter four: data inconsistencies.

2-PL application before lock release description See Bowen: http://www.cnblogs.com/xinysu/p/7260227.html Chapter 3: Data inconsistencies.

Set the database isolation level:

RU , the beginning of a transaction, set the SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
RC , at the beginning of the transaction, set the SET TRANSACTION ISOLATION LEVEL READ COMMITTED
RCSI , the entire database level READ_COMMITTED_SNAPSHOT set to ON, note that this set of needs when acquiring exclusive rights to the database, which is the current thread does not allow users connect to the database, whether the person would have been in this setting SQL congestion. If the current default isolation level of the database is RC, then after setting, the default is RCSI, whether the person is required at the beginning of the transaction, set the SET TRANSACTION ISOLATION LEVEL READ COMMITTED

Database settings: Under the current database, execute ALTER DATABASE dbname SET READ_COMMITTED_SNAPSHOT ON
Transaction settings: SET TRANSACTION ISOLATION LEVEL READ COMMITTED

RR , the beginning of a transaction, set the SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
RS , the beginning of a transaction, set the SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
SI , the entire database level ALLOW_SNAPSHOT_ISOLATION set to ON, and set transaction isolation level to SNAPSHOT. Note that there is also a need to set ALLOW_SNAPSHOT_ISOLATION acquire an exclusive lock on the data.

Database settings: Under the current database, execute ALTER DATABASE dbname SET ALLOW_SNAPSHOT_ISOLATION ON
Transaction settings: SET TRANSACTION ISOLATION LEVEL SNAPSHOT;

During the test, divided into three forms: no index, an index, a unique index.

CREATE TABLE tb_no_index ( id int primary key not null identity(1,1), age int not null, name varchar(100) );
CREATE TABLE tb_index ( id int primary key not null identity(1,1), age int not null, name varchar(100) );
CREATE TABLE tb_unique_index ( id int primary key not null identity(1,1), age int not null,name varchar(100) );
 
CREATE INDEX IX_age ON tb_index(age)
CREATE INDEX IX_unique_age ON tb_index(age)
 
INSERT INTO tb_no_index(age) values(2),(9),(21),(4),(7),(25);
INSERT INTO tb_index(age) values(2),(9),(21),(4),(7),(25);
INSERT INTO tb_unique_index(age) values(2),(9),(21),(4),(7),(25);

3.1 Read Uncommitted

Data inconsistencies test shots.

RU test results

In RU isolation level

Updates will not lose the case (lock mechanism), but the situation is dirty reads, non-repeatable reads and phantom reads can occur.
Read without line lock, you can read uncommitted data

3.2 Read Committed

Data inconsistencies test shots.

Reading test case
RC test results

In RC isolation level

Updates will not lose the case (lock mechanism), dirty read phenomenon, but the situation will not be repeated read and phantom read occurs
Reading need to apply for a lock, so the situation does not appear dirty read
Follow strong 2-PL mode, a read lock in the affairs immediate release read, write locks until the transaction commit was released.

3.3 Read Commit Snapshot Isolation

Test environment setup

Implementation sets the database isolation levels are:
Check the default isolation level for the current session:

Data inconsistencies test shots.

Update conflict test
RCSI test results

Reading is not locked, but the lock architecture of the application form, read data line version
Lost update does not exist, dirty reads the situation, but there are non-repeatable read and phantom read case
No update conflict detection, RCSI like update handling of RC

3.4 Read Reaptable

数据不一致情况测试截图

RR测试结论

读加S锁，事务结束后才释放S锁
不存在丢失更新、脏读及不可重复读情况，但是存在幻读情况

3.5 Read Serializable

数据不一致情况测试截图
RS 测试结论

读加S锁，事务结束后才释放S锁
增加了范围锁
不存在丢失更新、脏读、不可重复读、幻读情况
并发能力最差

3.6 Snapshot Isolation

数据不一致情况测试截图
更新冲突测试

SI 测试结论

不存在丢失更新、脏读、幻读等数据不一致情况
读不加锁，为读行版本数据
具有冲突监测，无法禁用，如果使用这个隔离级别，程序要做更新冲突的回滚处理

4 总结

隔离级别	说明	脏读	不可重复读	幻影	并发控制模型
Read UnCommitted	未提交读	YES	YES	YES	悲观
Read Committed	已提交读	NO	YES	YES	悲观
Read Commmitted (行版本)	已提交读（快照）	NO	YES	YES	乐观
Read Repeattable	可重复读	NO	NO	YES	悲观
Snapshot	快照	NO	NO	NO	乐观
Read Serializeble	可串行化	NO	NO	NO	悲观

如果转载，请注明博文来源： www.cnblogs.com/xinysu/ ，版权归博客园苏家小萝卜所有。望各位支持！

MSSQL- concurrency control various isolation levels of sqlserver -2-Isolation msql