커밋 된 스냅 샷 및 스냅 샷 격리 수준 읽기

커밋 된 스냅 샷 및 스냅 샷 격리 수준 읽기

---

누군가 SQL Server에서 READ COMMITTED SNAPSHOT을 통해 SNAPSHOT 격리 수준을 사용하는시기를 이해하도록 도와 주시겠습니까?

대부분의 경우 READ COMMITTED SNAPSHOT이 작동하지만 언제 SNAPSHOT 격리가 필요한지 확실하지 않다는 것을 이해합니다.

감사

---

READ COMMITTED SNAPSHOT낙관적 읽기와 비관적 쓰기를 수행합니다. 반대로 SNAPSHOT낙관적 읽기와 낙관적 쓰기를 수행합니다.

Microsoft는 READ COMMITTED SNAPSHOT행 버전 관리가 필요한 대부분의 앱에 권장 됩니다.

Microsoft 문서 : Choosing Row Versioning-based Isolation Levels를 읽어보십시오 . 두 격리 수준의 이점과 비용을 설명합니다.

그리고 여기에 더 자세한 내용이 있습니다. http://msdn.microsoft.com/en-us/library/ms345124(SQL.90).aspx

---

[! [격리 수준 테이블] [2]] [2]

아래 예를 참조하십시오.

커밋 된 스냅 샷 읽기

아래와 같이 데이터베이스 속성을 변경하십시오.

ALTER DATABASE SQLAuthority
SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE
GO

세션 1

USE SQLAuthority
GO
BEGIN TRAN
UPDATE DemoTable
SET i = 4
WHERE i = 1

세션 2

USE SQLAuthority
GO
BEGIN TRAN
SELECT *
FROM   DemoTable
WHERE i = 1

결과 – 세션 2의 쿼리는 현재 트랜잭션이 커밋되지 않았기 때문에 이전 값 (1, ONE)을 표시합니다. 이것은 차단을 피하고 커밋 된 데이터를 읽는 방법이기도합니다.

세션 1

COMMIT

세션 2

USE SQLAuthority
GO
SELECT *
FROM   DemoTable
WHERE i = 1

결과 – 세션 2의 쿼리는 세션 1에서 행이 업데이트되었으므로 행이 표시되지 않습니다. 따라서 다시 커밋 된 데이터가 표시됩니다.

스냅 샷 격리 수준

이것은 SQL Server 2005부터 사용할 수있는 새로운 격리 수준입니다. 이 기능의 경우 새로운 격리 수준을 사용해야하므로 애플리케이션에 변경이 필요합니다.

아래를 사용하여 데이터베이스 설정을 변경하십시오. 데이터베이스에 트랜잭션이 없는지 확인해야합니다.

ALTER DATABASE SQLAuthority SET AllOW_SNAPSHOT_ISOLATION ON

이제 아래를 사용하여 연결의 격리 수준도 변경해야합니다.

세션 1

USE SQLAuthority
GO
BEGIN TRAN
UPDATE DemoTable
SET i = 10
WHERE i = 2

세션 2

SET TRANSACTION ISOLATION LEVEL SNAPSHOT
GO
USE SQLAuthority
GO
BEGIN TRAN
SELECT *
FROM   DemoTable
WHERE i = 2

결과-값을 10으로 변경 한 경우에도 세션 2 (2, TWO)에서 이전 레코드를 볼 수 있습니다.

Now, let’s commit transaction in session 1

Session 1

COMMIT

Let’s come back to session 2 and run select again.

Session 2

SELECT *
FROM   DemoTable
WHERE i = 2

We will still see the record because session 2 has stated the transaction with snapshot isolation. Unless we complete the transaction, we will not see latest record.

Session 2

COMMIT
SELECT *
FROM   DemoTable
WHERE i = 2

Now, we should not see the row as it's already updated.

See: SQL Authority, Safari Books Online

---

No comparison of Snapshot and Snapshot Read Committed is complete without a discussion of the dreaded "snapshot update conflict" exception that can happen in Snapshot, but not Snapshot Read Committed.

In a nutshell, Snapshot isolation retrieves a snapshot of committed data at the start of a transaction, and then uses optimistic locking for both reads and writes. If, when attempting to commit a transaction, it turns out that something else changed some of that same data, the database will rollback the entire transaction and raise an error causing a snapshot update conflict exception in the calling code. This is because the version of data affected by the transaction is not the same at the end of the transaction as it was at the start.

Snapshot Read Committed does not suffer from this problem because it uses locking on writes (pessimistic writes) and it obtains snapshot version information of all committed data at the stat of each statement.

The possibility of snapshot update conflicts happening in Snapshot and NOT Snapshot Read Committed is an extremely significant difference between the two.

---

Still relevant, starting with Bill's comments I read more and made notes that might be useful to someone else.

By default single statements (including "SELECT") work on "committed" data (READ COMMITTED), the question is: do they wait for data to be "idle" and stop others from working when reading?

Setting via right click DB “Properties -> Options -> Miscellaneous”:

Concurrency/Blocking: Is Read Committed Snapshot On [defaults off, should be on]:

• Use SNAPSHOT for select (read), do not wait for others, nor block them.
• Effects operation without code change
• ALTER DATABASE SET READ_COMMITTED_SNAPSHOT [ON|OFF]
• SELECT name,is_read_committed_snapshot_on FROM sys.databases

Consistency: Allow Snapshot Isolation [defaults off, debatable – OK off]:

• Allow client to request SNAPSHOT across SQL statements (transactions).
• Code must request “transaction” snapshots (like SET TRANSACTION...)
• ALTER DATABASE SET ALLOW_SNAPSHOT_ISOLATION [ON|OFF]
• SELECT name,is_read_committed_snapshot_on FROM sys.databases

To the question: it is not one or the other between Read Committed Snapshot and Allow Snapshot Isolation. They are two cases of Snapshot, and either could be on or off independently, with Allow Snapshot Isolation a bit more of an advanced topic. Allow Snapshot Isolation allows code to go a step further controlling Snapshot land.

The issue seems clear if you think about one row: by default the system has no copy, so a reader has to wait if anyone else is writing, and a writer also has to wait if anyone else is reading – the row must lock all the time. Enabling “Is Read Committed Snapshot On” activates the DB to support “snapshot copies” to avoid these locks.

Rambling on...

In my opinion “Is Read Committed Snapshot On” should be “TRUE” for any normal MS SQLServer databases, and that it is a premature optimization that it ships “FALSE” by default.

그러나 한 행 잠금은 테이블에서 여러 행을 처리 할 수있을뿐만 아니라 SQL Server에서 행 잠금이 "블록"수준 잠금 (스토리지 근접성과 관련된 임의의 행 잠금)을 사용하여 구현되기 때문에 더 나빠진다고합니다. 다중 잠금이 테이블 잠금을 트리거하는 임계 값이 있습니다. 아마도 사용량이 많은 데이터베이스에서 문제를 차단할 위험이있는보다 "낙관적 인"성능 최적화 일 것입니다.

참고 URL : https://stackoverflow.com/questions/2741016/read-committed-snapshot-vs-snapshot-isolation-level