누군가 with (nolock)
가 쿼리를 사용해야하거나 사용하지 않아야 할 때 쿼리 에 사용하는 의미를 설명 할 수 있습니까 ?
예를 들어, 특정 테이블에 높은 트랜잭션 속도와 많은 데이터가 포함 된 뱅킹 애플리케이션이있는 경우 어떤 유형의 쿼리가 문제가되지 않습니까? 항상 사용하거나 사용하지 않아야 할 경우가 있습니까?
누군가 with (nolock)
가 쿼리를 사용해야하거나 사용하지 않아야 할 때 쿼리 에 사용하는 의미를 설명 할 수 있습니까 ?
예를 들어, 특정 테이블에 높은 트랜잭션 속도와 많은 데이터가 포함 된 뱅킹 애플리케이션이있는 경우 어떤 유형의 쿼리가 문제가되지 않습니까? 항상 사용하거나 사용하지 않아야 할 경우가 있습니까?
답변:
WITH (NOLOCK)은 READ UNCOMMITED를 트랜잭션 격리 수준으로 사용하는 것과 같습니다. 따라서 롤백 된 커밋되지 않은 행 (예 : 데이터베이스로 만들지 않은 데이터)을 읽을 위험이 있습니다. 따라서 다른 작업에서 읽기 교착 상태를 방지 할 수는 있지만 위험이 따릅니다. 트랜잭션 속도가 높은 뱅킹 응용 프로그램에서는 IMHO로 해결하려는 모든 문제에 대한 올바른 솔루션이 아닐 수 있습니다.
NOLOCK
와 함께 사용 SELECT
하면 선택을 수행하는 동안 데이터가 테이블에 삽입되거나 업데이트되는 경우 동일한 행을 두 번 이상 (중복 된 데이터) 반환 할 위험이 있습니다.
문제는 더 나쁜 것입니다.
재무 데이터베이스의 경우 교착 상태가 잘못된 값보다 훨씬 나쁩니다. 소리가 거꾸로 들리지만 내 말을들을 수 있습니다. DB 트랜잭션의 전통적인 예는 두 행을 업데이트하여 하나에서 빼고 다른 행에 추가하는 것입니다. 그건 잘못이야
재무 데이터베이스에서는 비즈니스 트랜잭션을 사용합니다. 즉, 각 계정에 하나의 행을 추가해야합니다. 이러한 트랜잭션이 완료되고 행이 성공적으로 작성되는 것이 가장 중요합니다.
계정 잔액을 일시적으로 잘못받는 것은 큰 문제가 아닙니다. 즉, 최종 조정입니다. 그리고 데이터베이스에서 커밋되지 않은 읽기로 인해 두 개의 ATM이 한 번에 사용되므로 계정에서 초과 인출이 발생할 가능성이 훨씬 높습니다.
즉, SQL Server 2005는 NOLOCK
필요한 대부분의 버그를 수정했습니다 . 따라서 SQL Server 2000 이전 버전을 사용하지 않는 한 필요하지 않습니다.
추가 읽기
행 수준 버전 관리
불행히도 커밋되지 않은 데이터를 읽는 것이 아닙니다. 백그라운드에서 페이지를 두 번 읽거나 (페이지가 분할 된 경우) 페이지를 모두 놓칠 수 있습니다. 따라서 결과가 심하게 왜곡 될 수 있습니다.
Itzik Ben-Gan의 기사를 확인 하십시오 . 발췌문은 다음과 같습니다.
"NOLOCK 힌트 (또는 세션의 격리 수준을 READ UNCOMMITTED로 설정)를 사용하면 일관성을 기대하지 않는다고 SQL Server에 알릴 수 있으므로 보장 할 수는 없습니다."일관되지 않은 데이터 "는 나중에 롤백 된 커밋되지 않은 변경 사항이나 트랜잭션의 중간 상태에서 데이터 변경 사항이 표시 될 수도 있습니다. 또한 간단한 쿼리에서 모든 테이블 / 인덱스 데이터를 검색하는 SQL Server가 검색 위치를 잃거나 끝날 수 있음을 의미합니다 같은 행을 두 번 얻는 것 입니다. "
금융 거래를 데이터베이스 거래로 래핑하지 않는 이유를 확실하지 않습니다 (한 계좌에서 다른 계좌로 자금을 이체 할 때와 같이 한 번에 거래의 한 쪽을 완결하지 않기 때문에 명시 적 거래가 존재하는 이유). 코드가 비즈니스 트랜잭션에서 생각보다 혼란스러워도 모든 트랜잭션 데이터베이스는 오류 또는 실패시 암시 적 롤백을 수행 할 수 있습니다. 나는이 토론이 당신의 머리 위에 있다고 생각합니다.
잠금 문제가있는 경우 버전 관리를 구현하고 코드를 정리하십시오.
잠금은 잘못된 값을 반환 할뿐 아니라 팬텀 레코드와 복제본을 반환합니다.
항상 쿼리 실행 속도를 높이는 것은 일반적인 오해입니다. 테이블에 쓰기 잠금이 없으면 차이가 없습니다. 테이블에 잠금이 있으면 쿼리가 더 빨라질 수 있지만 처음에 잠금이 발명 된 이유가 있습니다.
공평하게, 다음은 nolock 힌트가 유용성을 제공 할 수있는 두 가지 특별한 시나리오입니다.
1) 라이브 OLTP 데이터베이스에 대해 긴 쿼리를 실행해야하는 2005 년 이전 SQL Server 데이터베이스 (유일한 방법 일 수 있음)
2) 기록을 잠그고 UI에 제어권을 반환하는 잘못 작성된 응용 프로그램 및 판독기는 무기한 차단됩니다. 응용 프로그램을 수정할 수없고 (타사 등) 데이터베이스가 2005 년 이전이거나 버전 관리를 켤 수없는 경우 Nolock이 도움이 될 수 있습니다.
NOLOCK
상당이다 READ UNCOMMITTED
, 그러나 마이크로 소프트는 당신이 그것을 사용하지 말아야 말한다 UPDATE
또는 DELETE
문 :
UPDATE 또는 DELETE 문의 경우 :이 기능은 이후 버전의 Microsoft SQL Server에서 제거됩니다. 새로운 개발 작업에서이 기능을 사용하지 말고 현재이 기능을 사용하는 응용 프로그램을 수정하십시오.
http://msdn.microsoft.com/en-us/library/ms187373.aspx
이 문서는 SQL Server 2005에 적용되므로 NOLOCK
해당 버전을 사용하는 경우 지원 이 제공됩니다. 미래를 보장하기 위해 (더티 읽기를 사용하기로 결정했다고 가정) 코드를 저장 프로 시저에서 사용할 수 있습니다.
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
데이터를 읽을 때만 사용할 수 있으며 아직 커밋되지 않은 데이터를 다시 가져올 지 여부는 신경 쓰지 않습니다.
읽기 작업에서 더 빠를 수는 있지만 실제로 얼마나 말할 수는 없습니다.
일반적으로 사용하지 않는 것이 좋습니다. 커밋되지 않은 데이터를 읽는 것은 약간 혼란 스러울 수 있습니다.
일반적으로 괜찮은 또 다른 경우는 데이터가 이미 오래되고 쓰기가 발생하지 않는보고 데이터베이스에 있습니다. 그러나이 경우 기본 격리 수준을 변경하여 관리자가 데이터베이스 또는 테이블 수준에서 옵션을 설정해야합니다.
일반적인 경우 : 당신이 때 당신은 그것을 사용할 수 있습니다 매우 확실이 이전 데이터를 읽을 괜찮아있다. 기억해야 할 중요한 점 은 잘못 이해하기가 매우 쉽다는 것 입니다. 예를 들어, 쿼리를 작성할 당시에는 문제가 없더라도 앞으로 이러한 업데이트를 더욱 중요하게 만들기 위해 데이터베이스에 어떤 변화가 없을 것입니까?
나는 아마 그것이 아마 뱅킹 앱에는 좋지 않다는 . 또는 재고 앱. 또는 거래에 대해 생각하고있는 어느 곳에서나.
간단한 대답-SQL이 데이터를 변경하지 않고 잠금을 통해 다른 활동을 방해 할 수있는 쿼리가있을 때마다.
특히 쿼리에 1 초 이상 걸리는 경우 보고서에 사용되는 모든 쿼리를 고려해야합니다.
OLTP 데이터베이스에 대해 실행중인 OLAP 유형 보고서가있는 경우 특히 유용합니다.
그러나 가장 먼저해야 할 질문은 "왜 이것에 대해 걱정하고 있습니까?"입니다. 내 경험에 따르면 누군가가 "뭔가 시도"모드에있을 때 기본 잠금 동작을 푸는 것이 종종 발생하며 예기치 않은 결과가 발생하지 않는 경우입니다. 너무 이른 경우는 너무 이른 최적화의 경우이고 "경우에 따라"애플리케이션에 너무 쉽게 내장 될 수 있습니다. 왜하고 있는지, 어떤 문제가 해결되는지, 실제로 문제가 있는지 이해하는 것이 중요합니다.
짧은 답변:
WITH (NOLOCK)
클러스터형 인덱스가있는 테이블의 SELECT 문 에서만 사용하십시오 .
긴 대답 :
WITH (NOLOCK)은 종종 데이터베이스 읽기 속도를 높이는 마법의 방법으로 악용됩니다.
결과 세트에는 아직 커미트되지 않은 행이 포함되어있을 수 있으며이 행은 종종 나중에 롤백됩니다.
비 클러스터형 인덱스가있는 테이블에 WITH (NOLOCK)을 적용하면 행 데이터가 결과 테이블로 스트리밍되므로 다른 트랜잭션에서 행 인덱스를 변경할 수 있습니다. 이는 결과 집합에 행이 누락되거나 동일한 행이 여러 번 표시 될 수 있음을 의미합니다.
READ COMMITTED는 여러 사용자가 동일한 셀을 동시에 변경하는 단일 열 내에서 데이터가 손상되는 추가 문제를 추가합니다.
READ UNCOMITTED
영향을 미치지 않습니다. 그것이 ANSI 표준에 포함 된 이유가 있습니다.
내 2 센트- WITH (NOLOCK
보고서를 생성해야 할 때 사용하는 것이 좋습니다 . 이 시점에서 데이터는 많이 변경되지 않으며 해당 레코드를 잠그고 싶지 않습니다.
금융 거래를 처리하는 경우 절대 사용하지 않을 것 nolock
입니다. nolock
업데이트가 많은 대형 테이블에서 선택하는 것이 가장 좋으며 레코드가 오래된 것일 수도 있습니다.
재무 기록 (및 대부분의 응용 프로그램에서 거의 모든 다른 기록)의 nolock
경우 기록중인 레코드에서 데이터를 다시 읽을 수 있고 올바른 데이터를 얻지 못할 수 있으므로 혼란에 빠질 수 있습니다.
할 일에 대한 "다음 배치"를 검색하는 데 사용했습니다. 이 경우 정확한 항목은 중요하지 않으며 동일한 쿼리를 실행하는 많은 사용자가 있습니다.
"더러운"데이터에 문제가 없으면 nolock을 사용하십시오. 이는 nolock이 수정 및 / 또는 커밋되지 않은 데이터를 처리하는 데이터를 읽을 수도 있음을 의미합니다.
트랜잭션이 많은 환경에서 사용하는 것은 일반적으로 좋은 생각이 아니므로 쿼리의 기본 옵션이 아닙니다.
특히 활동이 많은 SQL Server 2000 데이터베이스에서 (nolock) 힌트를 사용합니다. 그러나 SQL Server 2005에 필요한지 확실하지 않습니다. 최근에 클라이언트의 DBA 요청에 따라 SQL Server 2000에이 힌트를 추가했습니다. 왜냐하면 그는 많은 SPID 레코드 잠금을 알아 채기 때문입니다.
내가 말할 수있는 것은 힌트를 사용하는 것이 우리를 해치지 않았고 잠금 문제를 스스로 해결 한 것으로 보입니다. 해당 고객의 DBA는 기본적으로 우리가 힌트를 사용한다고 주장했습니다.
그건 그렇고, 내가 다루는 데이터베이스는 엔터프라이즈 의료 청구 시스템의 백엔드이므로 많은 조인에서 수백만 건의 레코드와 20 개 이상의 테이블에 대해 이야기하고 있습니다. 나는 일반적으로 조인의 각 테이블에 WITH (nolock) 힌트를 추가합니다 (파생 테이블이 아닌 경우 특정 힌트를 사용할 수 없음)