하나의 SELECT가 다른 SELECT를 어떻게 차단합니까?

SQL Server 2005에서 SP_WhoIsActive의 출력을보고 있는데 한 세션이 다른 세션을 차단하고 있음을 알 수 있습니다. 그러나 둘 다 SELECT를 실행 중입니다. 한 SELECT가 다른 SELECT를 어떻게 차단합니까? 그들은 둘 다 공유 잠금을 획득해야합니까 (서로 호환됩니까)?하나의 SELECT가 다른 SELECT를 어떻게 차단합니까?

일부 세부 정보 : 세션에 열린 트랜잭션 수가 없으므로 독립 실행 형입니다.

쿼리는 테이블과 뷰를 결합합니다.

많은 테이블과 결과를 결합하는 복잡한 쿼리로 10,000 번 정도 읽습니다.

모든 의견을 매우 높이 평가합니다.

출처

2010-06-08 Krip

SELECT 문은 다른 SELECT 문을 차단할 수 있습니다. 아마 둘 다 S 자물쇠만을 획득 했으므로 절대 차단해서는 안된다고 생각할 것입니다. 그러나 잠금은 잠금뿐만 아니라 다양한 유형의 자원에서 발생합니다. 일반적인 예는 메모리 제약입니다. SELECT 문을 보여주는 교착 상태 그래프를 첨부 한 질문에 대한 최근 답변을 보려고합니다. 하나는 병렬 교환 연산자 메모리 리소스 (버퍼)를 기다리는 것입니다.

<exchangeEvent id="Pipe894b0680" WaitType="e_waitPipeGetRow" nodeId="0"> 
    <owner-list> 
    <owner id="process824df048"/> 
    </owner-list> 
    <waiter-list> 
    <waiter id="process86ce0988"/> 
    </waiter-list> 
</exchangeEvent>

가이되지 않습니다 : 당신이 교착 상태 그래프를 연구하면 I have data about deadlocks, but I can't understand why they occur , 당신은 대기 목록에서 다음 리소스를 알 수 있습니다 : 여기에 업데이트

내가 이야기 교착 상태 정보와 링크입니다 잠금은 'e_waitPipeGetRow'자원이며, SELECT가 소유하고 다른 SELECT가 그것을 대기하고 있습니다. '쿼리 내 병렬 리소스'에 대한 설명은 Today's Annoyingly-Unwieldy Term: "Intra-Query Parallel Thread Deadlocks"에서 확인할 수 있습니다. 대부분의 토론에서는 교착 상태 문제에 초점을 맞추고 있지만 이것이 정상적인 차단이 이러한 리소스에서 발생할 수 없다는 것을 의미하지는 않습니다. sys.dm_exec_requests은 wait_type 및 wait_resource에 적절한 정보를 갖습니다.

출처

2010-06-08 18:49:22

그 정보에 대해 정말 고마워요! – Krip

첫 번째 선택은 행 잠금/테이블 잠금을 수행하고 있기 때문에 생각합니다. 테이블에 가입하는 동안 NO LOCK Hint를 제공 할 수 있습니다.

출처

2010-06-08 18:47:01 Chinjoo

오늘 제 경험으로 NO LOCK 힌트는 실제 내부 쿼리 병렬 스레드 교착 상태 이벤트를 중지하기에 충분하지 않습니다. –

NO LOCK을 사용하지 않는 것이 좋습니다. 더티 읽기 (중복 된 데이터, 누락 된 데이터)로 이어질 수 있습니다. 잠금은 데이터 일관성을 유지하기위한 의도적 인 메커니즘입니다. 당신의 위험에 아무 손잡이도 사용하십시오. http://blogs.sqlsentry.com/aaronbertrand/bad-habits-nolock-everywhere/ – Davos

하나의 SELECT가 다른 SELECT를 어떻게 차단합니까?

답변

관련 문제