나는 읽고 여기에 우리가 성능 저하를 볼 수 있지만 어떤 다른 위험이있다 할 수 있도록 몇 가지 여분의 데이터가 행마다 저장됩니다?
예. 이것이 데이터베이스 복구에 영향을 줍니까? 이것을 이용하기 위해해야 할 다른 일이 있습니까?
다음 명령을 실행할 계획입니다.
ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON
나는 이것이 하나의 트랜잭션이 다른 트랜잭션을 업데이트하면 여전히 이전 데이터를 읽을 수있는 오라클에 더 가까운 것을 줄 것이라고 믿습니다. 이 올바른지?
SQL Server 2005의 잠금 문제로 인해이 문제를 조사하고 있습니다. 사용자의 교착 상태를 줄이고 응용 프로그램의 전반적인 성능을 향상 시키며 개발자가 트랜잭션 당 하나 이상의 작업을 수행하도록 장려 할 수 있기를 바랍니다. 무서움.
답변:
요약
하중
또한 tempdb 및 CPU의 로드가 증가합니다 . 참조 :
안전
가장 중요한 스냅 샷 격리 는 많은 경우 기본적으로 안전하지 않습니다 . 읽기 "스냅 샷 격리"(위키 백과) 쓰기 스큐 이상에 대한 자세한 내용은. 다음 섹션은이 문제를 해결하기위한 "스냅 샷 격리 직렬화"입니다.
따라서 일반적으로 스냅 샷 격리는 잠재적 인 함정이나 가능한 솔루션을 인식하지 못할 수있는 사소한 제약 조건을 사용자에게 유지하는 문제 중 일부를 사용자에게 제공합니다. 이 전송의 장점은 더 나은 성능입니다.
참조 :
나는 이것이 오래된 스레드라는 것을 알고 있지만 큰 스냅 샷 격리 는 마법의 총알 이라고 말합니다 . 그것은 독자와 작가 사이의 모든 차단 을 제거 합니다 . 그러나 작성자가 다른 작성자를 차단 하지 못하게합니다. 그 주위에 방법이 없습니다.
필자의 경험에 따르면 TEMPDB에 대한 추가로드는 무시할 수 있으며 차단 된 리더를 줄이면 행 버전 관리의 이점이 엄청납니다.
참고로 행 버전 관리 (스냅 샷 격리)는 Oracle이 독자를 차단하지 않고 격리를 달성하기 위해 수십 년 동안 사용한 방법이며, 거의 20 년 동안 근무한 Oracle DB 는 SQL Server보다 차단 문제가 훨씬 적습니다. 대부분의 SQL 개발자는 기본 설정을 사용하는 데이터베이스에 대해서만 코드를 테스트했기 때문에 스냅 샷 격리를 사용하는 것을 주저합니다.
다른 답변에 추가 할 몇 가지 추가 사항 :
SET ALLOW_SNAPSHOT_ISOLATION ON데이터베이스에서 스냅 샷 격리 만 활성화합니다. 이를 활용하려면 코드를 다시 작성하고 SET TRANSACTION ISOLATION LEVEL SNAPSHOT적용하려는 트랜잭션을 사용해야합니다. 업데이트 충돌 오류를 처리하려면 호출 코드를 변경해야합니다.
이후 SET READ_COMMITTED_SNAPSHOT ON에 커밋 된 읽기 문은 행 버전 관리를 사용합니다. 이것은 읽기 전용의 명령문 레벨 행 버전입니다 . 업데이트의 경우 "실제"행이 검색되고 업데이트 잠금이 적용됩니다. 행 버전 관리 기반 격리 수준 이해 의 동작 요약 섹션을 참조하십시오.
철저한 테스트 없이는 시스템에 완전히 새로운 문제가 발생할 가능성이 높습니다.
나는 이것이 하나의 트랜잭션이 다른 트랜잭션을 업데이트하면 여전히 이전 데이터를 읽을 수있는 오라클에 더 가까운 것을 줄 것이라고 믿습니다. 이 올바른지?
예, 맞습니다 .
gbn의 답변에서 링크를 읽을 가치가 있으며 Snapshot Isolation 모드의 SQL Server와 Oracle의 기본 MVCC에도 동일하게 적용됩니다. 잠재적 인 함정을 이해하면 IMO의 이점이 추가 된 어려움보다 훨씬 큽니다 (Oracle 관점에서 말하면). 물론 잠금 문제가 합법적으로 사라집니다. 즉 MVCC의 요점입니다. 코드 문제로 인해 사라지지 않는 잠금 문제,하지만 이것을 이해한다고 가정합니다.
우리는 SQL Server DB를 사용하는 모든 프로젝트에서 SNAPSHOT ISOLATION을 사용하고 있습니다. 더 이상 1205 SQL 오류가 발생하지 않습니다.이 오류는 잘못된 응용 프로그램 코드로 인한 것이 아니라 기본 페이지 잠금 및 행 잠금 동작에서 발생합니다.
성능에 미치는 영향은 최소화되었으며 지금까지 7 년이 지났으며 SNAPSHOT ISOLATION과 관련하여 아무런 문제없이 다른 시스템에서 수억 건의 작업이 처리되었습니다.
여러 다른 스레드가 비즈니스 중요 정보를 한 행에 동시에 업데이트하는 상황은 매우 예외적이며 SNAPSHOT ISOLATION이 불일치 문제의 원인이 될 가능성은 거의 제로에 가깝습니다.
OLTP 시스템을 사용하는 경우 많은 스레드에서 현재 행 데이터를 기반으로 단일 행을 설계하여 업데이트하지만 물론 이러한 경우 SNAPSHOTS를 사용할 수 없습니다.