Azure SQL Server V12에서 deadlock_xml을 이해할 수 없습니다. 같은 자원의 업데이트 잠금을 원하는SQL Server 교착 상태 그래프 : 설명해주세요
그래서 우 프로세스가 발행 한 업데이트 잠금과 좌 과정 : 여기 (기본 XML과 일치) 그래프이다 , 기다려야한다.
그런 다음 rhs 프로세스는 lhs 프로세스의 업데이트 잠금으로 인해 차단 된 것으로 보이는 동일한 리소스에 대한 배타적 잠금을 요청합니다 (이유는 요청한 이유는 무엇입니까?!).
내 질문 :
왜 X 잠금에 U 잠금을 제한 할 수없는 우 공정?
두 프로세스는 SP가 upsert 연산을 수행하는 동일한 SP
를 실행했다 : 나는 그럼에도 불구하고, 높은 수준에서 이해하지만하려고
, 여기에 세부 사항입니다 : 삽입하지 않는 곳 삽입 (Select ...); @@ ROWCOUNT = 0 업데이트 인 경우 ...
두 작업 모두 동일한 테이블에 영향을줍니다. 기본 키 색인 "PK_Product"에 키 잠금이 표시됩니다.
나는 쉬운 예에 넣어보십시오
한 남자가 방으로 와서 말한다 : "나는이 벽을 철거거야" 그의 도구를 얻으려고 나간다. 또 다른 사람이 들어 와서 이렇게 말합니다. "나는이 벽을 칠할거야!" 색상을 얻으려고 나간다. 이제 다시 돌아와서 일을 시작하고 싶습니다. 벽을 찢어 버리면 조금 더 일찍 시작됩니다. 이제 두 번째 사람에게는 기다리는 데 아무런 의미가 없습니다. 이러한 프로세스는 직렬화 할 수 없습니다. 그는 첫 번째 것이 끝날 때까지 기다릴 수 없습니다. 첫 번째 사람의 작업은 작업의 기반을 바꾸어 불가능하게 만들었습니다.
의미 : 두 프로세스 모두 "이 테이블을 업데이트하려고하지만 특정 조건을 먼저 확인합니다"라고 말합니다. INSERT이 기본 키에 영향을 미치기 때문에 두 번째 프로세스는 대기하고 잠시 후 계속할 수 없습니다. 이 과정은 죽이고 다시 시작할 수 있습니다.
MERGE-command을 보시면 한 번에 업서 트를 수행 할 수 있습니다.
@ Shungo 답변 해 주셔서 감사합니다. 지금 나에게 분명하다. 나는 육체적 인 차원보다는 논리적 인 차원에서의 잠금을 기대할 정도로 순진했다. 분리 레벨 "serializable"과의 병합은 실제로 내 upsert 문제에 대한 해결책입니다. 불행히도 공개 답변을 upvote하기에 충분한 담당자가 없습니다. – PBof