커밋되지 않은 읽기 격리 수준을 사용해야하는 이유는 무엇입니까?

평범한 영어로, 사용의 단점과 장점은 무엇입니까

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

.NET 응용 프로그램 및보고 서비스 응용 프로그램에 대한 쿼리에서?

이 격리 수준은 더티 읽기를 허용합니다. 하나의 트랜잭션은 다른 트랜잭션에 의해 커밋되지 않은 변경 사항을 볼 수 있습니다.

최고 수준의 격리를 유지하기 위해 DBMS는 일반적으로 데이터에 대한 잠금을 획득하므로 동시성 손실과 높은 잠금 오버 헤드가 발생할 수 있습니다. 이 격리 수준은이 속성을 완화시킵니다.

몇 가지 예와 추가 정보 는 Wikipedia 기사READ UNCOMMITTED 를 확인하십시오 .

Jeff Overwood의 블로그 기사 에서 Stack Overflow 초기에 교착 상태 문제를 해결 한 방법에 대해 Jeff Atwood의 블로그 기사 를 확인하는 것이 좋습니다. Jeff에 따르면 :

그러나 nolock위험합니까? 에 잘못된 데이터를 읽게 될 수 read uncommitted있습니까? 예, 이론 상으로는 ACID 과학을 떨어 뜨리기 시작한 데이터베이스 아키텍처 우주 비행사가 부족하다는 것을 발견 할 수 있습니다 nolock. 사실이다 : 이론은 무섭다. 그러나 여기 제가 생각하는 것은 : "이론에는 이론과 실제에 차이가 없습니다. 실제로는 있습니다."

나는 nolock 데이터베이스 교착 상태 문제에 대해 일반적인 "당신을 위해 좋은"뱀 기름 수정으로 사용 하는 것을 권장하지 않을 것입니다. 먼저 문제의 원인을 진단해야합니다.

그러나 실제로 nolock당신이 절대적으로 알고있는 쿼리를 추가 하는 것은 간단하고 간단한 읽기 전용 문제는 결코 문제를 일으키지 않는 것 같습니다 .

READ UNCOMMITTED고려할 수 있는 수준 에 대한 한 가지 대안 은 READ COMMITTED SNAPSHOT입니다. Jeff를 다시 인용 :

스냅 샷은 완전히 새로운 데이터 변경 추적 방법에 의존합니다. 약간의 논리적 변경보다 서버가 데이터를 물리적으로 다르게 처리해야합니다. 이 새로운 데이터 변경 추적 방법이 활성화되면 모든 데이터 변경의 복사본 또는 스냅 샷이 생성됩니다. 경합 발생시 라이브 데이터가 아닌 이러한 스냅 샷을 읽으면 더 이상 읽기에 공유 잠금이 필요하지 않으며 전체 데이터베이스 성능이 향상 될 수 있습니다.

이것은 긴 삽입 쿼리의 진행 상황을 COUNT(*)보거나 대략 적인 추정 (예 : 또는 거칠기 SUM(*)) 등을 만드는 데 유용 할 수 있습니다 .

즉, 더티 읽기 쿼리가 반환하는 결과는 추정치로 간주하고이를 기반으로 중요한 결정을 내리지 않는 한 괜찮습니다.

내가 가장 좋아하는 유스 케이스 read uncommited는 트랜잭션 내부에서 발생하는 것을 디버깅하는 것입니다.

코드 라인을 단계별로 실행하는 동안 디버거에서 소프트웨어를 시작하면 트랜잭션이 열리고 데이터베이스가 수정됩니다. 코드가 중지 된 상태에서 쿼리 분석기를 열고 커밋되지 않은 읽기 격리 수준 을 설정하고 쿼리를 수행하여 진행 상황을 확인할 수 있습니다.

또한 장기 실행 프로 시저가 멈췄거나 데이터베이스를 올바르게 업데이트하는지 확인할 수 있습니다.

회사에서 지나치게 복잡한 저장 프로 시저를 만드는 것을 좋아한다면 좋습니다.

어떤 상황에서는 더 빠를 수 있다는 장점이 있습니다. 단점은 결과가 잘못되어 (아직 커밋되지 않은 데이터가 반환 될 수 있음) 결과가 반복 가능하다는 보장이 없다는 것입니다.

정확성에 관심이 있다면 이것을 사용하지 마십시오.

자세한 내용은 MSDN에 있습니다 .

더티 읽기 또는 격리 수준 0 잠금을 구현합니다. 즉, 공유 잠금이 발행되지 않고 독점 잠금이 적용되지 않습니다. 이 옵션을 설정하면 커밋되지 않은 데이터 또는 더티 데이터를 읽을 수 있습니다. 트랜잭션이 끝나기 전에 데이터의 값을 변경하고 행이 데이터 세트에 나타나거나 사라질 수 있습니다. 이 옵션은 트랜잭션의 모든 SELECT 문에있는 모든 테이블에서 NOLOCK을 설정하는 것과 동일한 효과를 갖습니다. 이것은 네 가지 격리 수준 중에서 가장 제한이 적습니다.

언제 사용할 수 READ UNCOMMITTED있습니까?

엄지 손가락의 법칙

양호 : 지속적으로 변화하는 총계를 보여주는 큰 집계 보고서.

위험 : 거의 모든 것.

좋은 소식은 읽기 전용 대부분의 보고서가에 빠지게한다는 것입니다 좋은 종류.

자세한 세부 사항...

그것을 사용하십시오 :

• 현재 비 정적 데이터 (예 : 연도 별 매출)에 대한 거의 모든 사용자 대면 집계 보고서 오차 한계 (0.1 % 미만일 수 있음)가 발생하여 오차 입력과 같은 다른 불확실성 요소 나 정확히 1 분에서 정확히 데이터가 기록 될 때의 무작위성보다 훨씬 낮습니다.

SSRS와 같은 비즈니스 인텔리전스 부서가 수행 할 대부분의 작업이 여기에 해당합니다. 물론, $ 표시가 앞에있는 것은 예외입니다. 많은 사람들이 고객에게 서비스를 제공하고 그 돈을 창출하는 데 필요한 관련 핵심 메트릭스에 적용되는 것보다 훨씬 열성적인 돈을 설명합니다. (저는 회계사를 비난합니다).

위험 할 때

• 상세 수준으로 내려가는 모든 보고서. 세부 사항이 필요한 경우 일반적으로 모든 행이 결정과 관련이 있음을 의미합니다. 실제로, 작은 부분 집합을 차단하지 않고 당길 수 없다면 그것이 현재 편집되고있는 좋은 이유 일 수 있습니다.

• 과거 데이터. 실질적인 차이는 거의 없지만 사용자는 끊임없이 변화하는 데이터가 완벽 할 수는 없다는 것을 이해하지만 정적 데이터에 대해서는 동일하게 느끼지 않습니다. 더티 리딩은 여기서 아프지 않지만 더블 리딩은 때때로 일어날 수 있습니다. 어쨌든 정적 데이터에 대한 차단이 없어야하는 이유는 무엇입니까?

• 쓰기 기능이있는 응용 프로그램을 공급하는 거의 모든 것.

OK 시나리오에서도 OK가 아닙니다.

• 큰 단일 트랜잭션을 사용하는 응용 프로그램이나 업데이트 프로세스가 있습니까? 당신이보고있는 많은 기록을 제거한 다음 다시 삽입하는 것? 이 경우 실제로 NOLOCK해당 테이블에서 아무것도 사용할 수 없습니다 .

보고와 관련하여 Google은 모든보고 쿼리에서이 보고서를 사용하여 쿼리가 데이터베이스를 다운시키는 것을 방지합니다. 우리는 마이크로 초 단위의 데이터가 아닌 과거 데이터를 가져 오기 때문에 그렇게 할 수 있습니다.

소스가 변경 될 가능성이 거의없는 상황에서는 READ_UNCOMMITTED를 사용하십시오.

• 히스토리 데이터를 읽을 때. 예를 들어 이틀 전에 발생한 일부 배포 로그.
• 메타 데이터를 다시 읽을 때 메타 데이터 기반 애플리케이션.

페치 조작 중에 소스가 변경 될 수 있음을 알고있을 때 READ_UNCOMMITTED를 사용하지 마십시오.

이렇게하면 더티 읽기가 이루어지고 아직 커밋되지 않은 트랜잭션이 표시됩니다. 이것이 가장 확실한 대답입니다. 나는 단지 당신의 독서 속도를 높이기 위해 이것을 사용하는 것이 좋지 않다고 생각합니다. 좋은 데이터베이스 디자인을 사용하는 경우 다른 방법이 있습니다.

일어나지 않는 것을 주목하는 것도 흥미 롭습니다. READ UNCOMMITTED는 다른 테이블 잠금 만 무시하지 않습니다. 또한 자체 잠금을 발생시키지 않습니다.

큰 보고서를 생성하거나 크고 복잡한 SELECT 문을 사용하여 데이터베이스에서 데이터를 마이그레이션하는 것을 고려하십시오. 이로 인해 트랜잭션 기간 동안 공유 잠금이 공유 테이블 잠금으로 에스컬레이션 될 수 있습니다. 다른 트랜잭션은 테이블에서 읽을 수 있지만 업데이트는 불가능합니다. 프로덕션이 완전히 중지 될 수 있으므로 프로덕션 데이터베이스 인 경우 나쁜 아이디어 일 수 있습니다.

READ UNCOMMITTED를 사용하는 경우 테이블에 공유 잠금을 설정하지 않습니다. 일부 새 트랜잭션에서 결과를 얻거나 데이터가 삽입 된 테이블 및 SELECT 트랜잭션이 읽은 시간에 따라 달라질 수 있습니다. 예를 들어 페이지 분할이 발생하는 경우 동일한 데이터를 두 번 얻을 수도 있습니다 (데이터 파일의 다른 위치로 데이터가 복사 됨).

따라서 SELECT를 수행하는 동안 데이터를 삽입 할 수있는 것이 매우 중요한 경우 READ UNCOMMITTED가 의미가있을 수 있습니다. 보고서에 약간의 오류가있을 수 있지만 결과를 선택하는 동안 수백만 행을 기반으로하고 그 중 몇 개만 업데이트되는 경우 "충분히 좋을 수 있습니다"라는 것을 고려해야합니다. 행의 고유성이 보장되지 않으므로 트랜잭션이 모두 실패 할 수도 있습니다.

더 좋은 방법은 SNAPSHOT ISOLATION LEVEL을 사용하는 것이지만이를 사용하려면 응용 프로그램에서 약간의 조정이 필요할 수 있습니다. 이에 대한 한 가지 예는 응용 프로그램이 다른 사용자가 읽지 못하고 UI에서 편집 모드로 들어 가지 못하도록 행에 독점 잠금을 설정하는 경우입니다. SNAPSHOT ISOLATION LEVEL에는 상당한 성능 저하가 있습니다 (특히 디스크에서). 그러나 문제에 하드웨어를 던져서이를 극복 할 수 있습니다. :)

데이터웨어 하우스에 데이터를보고하거나로드하는 데 사용할 데이터베이스 백업 복원을 고려할 수도 있습니다.

기존 테이블에 대한 업데이트가없고 다른 테이블에 대한 fk가없는 삽입 전용 감사 테이블과 같은 간단한 테이블에 사용할 수 있습니다. 인서트는 롤백 가능성이 거의없는 간단한 인서트입니다.

나는 항상 지금 커밋되지 않은 읽기를 사용합니다. 최소한의 문제로 빠릅니다. 다른 격리를 사용하면 거의 항상 일부 차단 문제가 발생합니다.

자동 증분 필드를 사용하고 인서트에 약간 더주의를 기울이는 한 벌금 문제에 대해서는 작별 인사를 할 수 있습니다.

COMMUNCOMMITED READ로 오류를 만들 수 있지만 솔직히 말하면 인서트가 완전한 증거인지 확인하는 것은 매우 쉽습니다. 선택의 결과를 사용하는 삽입 / 업데이트는주의해야합니다. (READ COMMITTED를 사용하거나 더티 판독으로 인해 문제가 발생하지 않도록하십시오)

Dirty Reads (특히 큰 보고서의 경우)로 이동하면 소프트웨어가 더 부드럽게 실행됩니다.