언제 NOLOCK을 사용하는 것이 적당합니까?

Question

몇 가지 장기 실행 쿼리에서 수시로 시간 초과 문제 및 교착 상태가 발생합니다.

NOLOCK을 사용하는 것이 가장 적절한시기는 궁금합니다.

업데이트 & 삽입물에 사용합니까? 또는 읽습니까?

Answer 1

더티 읽기 및 팬텀 레코드가 허용되는 경우 사용하십시오. 정보의 정확도가 레코드 수에 대한보기가 있거나 다른 정보의 정확성이있는 경우 중요하지 않은 보고서를 정기적으로 실행하고있을 수 있습니다 미터법 (예 :

)

Answer 2

테이블 당 기준으로 nolock을 지정할 수 있습니다.

나는 일반적으로 복잡한 SELECT 쿼리에서 nolock을 사용했지만 거의 변경되지 않은 작은 조회 테이블과 디스플레이 전용 데이터에 대해서만 사용했습니다. 당신은 현재 절반 년 동안의 가격을 나열하는 테이블을 알고 있습니다. 또는 문자열에 ID를 조회하는 등 주요 업데이트로만 변경되는 항목이 있습니다. 그 후 서버는 대개 일상적으로 다시 시작됩니다.

이 성능이 크게 향상되어 가장 바쁜 시간에 교착 상태가 발생할 가능성이 줄어 들었습니다. 더 중요한 것은 많은 테이블을 건드린 쿼리에 대해 가장 눈에 띄는 순간이었습니다 (논리적 인 경우 잠금이 적음) , 그리고 그 사이드 테이블은 종종 거의 모든 곳에서 사용되며, 종종 잠글 필요가있는 7-8에서 4 개의 테이블로 감소합니다.)

그러나 추가 할 때는 매우 조심하고 서두르지 말고 일상적으로하지 마십시오. 제대로 사용하면 상처를 입지 않지만 부적절하게 사용하면 끔찍한 상처를 입을 수 있습니다.

매우 비판적인 물건, 계산하는 물건 등에 대해 사용하지 마십시오. 일관성이 없기 때문에 조만간 작성하게됩니다.

또 다른 최적화는 행 수준에서만 잠금 인 ROWLOCK입니다. 이것은 로그 레코드를 넣는 테이블 (삽입되는 순서는 중요하지 않음)과 같이 행이 서로 관련이없는 테이블을 업데이트 (또는 삭제) 할 때 주로 유용합니다. 로그 레코드가 어떤 테이블에 쓰여지는 트랜잭션의 어딘가에 스키마가 있다면, 이것은 또한 상당히 가속화 될 수 있습니다.

데이터베이스의 쓰기 비율이 비교적 낮은 경우에는 가치가 없을 수도 있습니다. 나는 2 : 1 이하의 읽기 : 쓰기 비율을 가졌다. 이 작업 때 저장

일부 URL :

http://www.developerfusion.com/article/1688/sql-server-locks/4/

Answer 3

더러워 데이터를 읽을 괜찮 때 NOLOCK을 사용해야합니다. nolock을 사용하면 지금까지 설정 한 데이터 만 반환하므로 데이터베이스에 많은 변경을 가할 수있는 대규모 트랜잭션이 계속 진행 중일 수 있습니다. 트랜잭션이 롤백되면보고있는 데이터가 잘못 될 수 있습니다. 그러므로, 당신이 돌아 오는 것이 잘못 될 수 있다는 것이 중요하지 않을 때만 사용해야합니다.

교착 상태는 일반적인 문제이지만 10 개 중 9 번은 전적으로 개발자 문제로 인해 발생합니다. 나는 놀럭을 사용하기보다는 교착 상태의 원인을 찾는 데 집중할 것입니다. 다른 모든 순서와는 다른 순서로 일을하는 것은 단지 하나의 거래 일 가능성이 높습니다. 모든 문제를 해결할 수있는 문제 만 해결하면됩니다.

Answer 4

SQL Server의 네 transaction isolation levels 있습니다

1. 가 읽어 UNCOMMITTED
2. READ COMMITTED
3. REPEATABLE READ가에 적용된 테이블에 대한
4. SERIALIZABLE

, NOLOCK는이다 "uncommitted 읽기"와 동일합니다. 즉, 향후 롤백 될 수있는 트랜잭션의 행과 다른 많은 이상한 결과를 볼 수 있습니다.

여전히, 실제로 매우 잘 작동합니다. 특히 약간의 잘못된 데이터를 표시하는 것이 비즈니스 보고서와 같이 세계의 끝이 아닌 읽기 전용 쿼리의 경우. 나는 업데이트 나 삽입물 근처에서, 또는 일반적으로 의사 결정 코드 근처에서, 특히 인보이스와 관련된 경우에는 그것을 피해야합니다.

nolock 대신 읽기 작업이 많고 쓰기 작업이 적은 데이터베이스에 대해 "읽기 커밋 된 스냅 샷"을 고려하십시오. 다음 주소로 설정할 수 있습니다.

ALTER DATABASE YourDb SET READ_COMMITTED_SNAPSHOT ON; 

SQL Server 2005 이상에서 사용할 수 있습니다. 이것이 오라클이 기본적으로 작동하는 방식이며, stackoverflow 자체가 사용하는 방식입니다. 심지어 그것에 대해 coding horror 블로그 항목이 있습니다.

P. 장시간 실행되는 쿼리 및 교착 상태는 SQL Server가 잘못된 가정을 사용하고 있음을 나타낼 수도 있습니다. 통계 또는 색인이 오래 되었습니까?

SELECT 
    object_name = Object_Name(ind.object_id), 
    IndexName = ind.name, 
    StatisticsDate = STATS_DATE(ind.object_id, ind.index_id) 
FROM SYS.INDEXES ind 
order by STATS_DATE(ind.object_id, ind.index_id) desc 

주간 유지 관리 계획에서 통계를 업데이트해야합니다.

Answer 5

읽기 잠금이없는 트랜잭션 일관성있는보기의 경우 SQL Server에서 스냅 숏 격리를 사용하도록 설정하는 것이 좋습니다.

정보를 읽을 때 결과가 항상 커밋되지 않은 데이터를 볼 가능성이 아니라 커밋 된 데이터 버전을 반영한다는 점에서 NOLOCK과 약간 다릅니다. 이것은 더 명확한 결과를 갖는 NOLOCK ("읽기"잠금 없음)과 동일한 잠금 동시성을 제공합니다.

트랜잭션 일관성을 유지하더라도 표시 또는 표시되는 데이터는 잘못 표시되거나 오래된 것으로 간주 될 수 있습니다. 너무 많은 사람들이 데이터를 충분히 빨리 사용하거나 쿼리/트랜잭션 내에서 사용하면 문제가 없다고 생각합니다. 이것은 어리석은 짓입니다. 반복적 인 일관성 수준은 나쁜 행동을 조장하기 때문에 처음부터 구현되어서는 안됩니다. Oracle에는 존재하지 않습니다.

개인적으로 중요하지 않은 데이터보기 및 보고서에 대한 잠금을 해제하는 것이 개인적으로 시스템에 부담을 덜 주므로 약간 부정확 한 결과를 제공하는 작은 문제는 문제가되지 않습니다.

반복 읽기 일관성 수준을 활용하고 사용자 입력을 위해 열린 트랜잭션을 유지하는 것과 같은 커밋 죄는 초기 개발면에서 개발자에게는 약간 쉬울 수도 있지만 거의 항상 소망대로 주요 도로 "차단"으로 이어질 것입니다. 합리적으로 응용 프로그램을 확장합니다.

필자의 시각은 모든 데이터에 업데이트를 적용하기 위해 반드시 충족해야하는 조건을 "다시 확인"하는 것이 가장 좋은 방법입니다.

나쁜 :

UPDATE myaccount SET balance = 2000 

더 나은 : 아직

UPDATE myaccount SET balance = balance + 2000 

더 나은 : 마지막으로 응용 프로그램이 있는지 행의 예상 숫자가 실제로 업데이트 된 있도록 행 수를 확인해야합니다

UPDATE myaccount SET balance = 2000 WHERE balance = 0 AND accountstatus = 1 

성공 피드백을 사용자에게 제시합니다.

Answer 6

마지막 수단으로 nolock을 사용하십시오. 대부분의 교착 상태 문제는 쿼리를 조정하거나 인덱스를 조정하여 해결할 수 있습니다. 나는 지난 5 년 동안 두 가지 중 하나를 튜닝하여 해결할 수없는 교착 상태를 보았다고 생각합니다.

또한 NOLOCK은 select 문에만 적용됩니다. 데이터 수정은 항상 잠금으로 설정되며 해당 동작을 변경할 수 없습니다. 따라서 작가/작가의 교착 상태 (매우 일반적인 문제)가있는 경우 잠금 장치가 전혀 도움이되지 않습니다.

더러운 데이터를 반환하는 것 외에도 nolock은 중복 행 (기본 테이블에서 두 번 읽는 행)과 누락 된 행 (읽지 않은 기본 테이블의 행)을 초래할 수 있습니다.

은 NOLOCK는 기본적으로

스냅 숏 격리는 옵션입니다 '내 결과가 약간 부정확 한 경우 난 상관 없어'SQL 서버를 의미합니다. 트랜잭션이 얼마나 빈번하고 자주 발생하는지에 따라 TempDB의 증가 된로드가 심각 할 수 있으므로 먼저주의 깊게 테스트해야합니다. 또한 스냅 샷 격리에서 교착 상태가 표시되지 않지만 업데이트 충돌이 발생할 수 있습니다. 다시 한 번 테스트하고 앱이 제대로 작동하는지 확인하고 오류가 발생하면이를 처리 할 수 ​​있습니다.