이것은 /programming/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically 의 후속 질문입니다.
큰 보고서를 동시에 실행할 때 ASP.NET 응용 프로그램에서 교착 상태 / 시간 초과 상황이 계속 발생 READ_COMMITTED_SNAPSHOT ON합니다.
그래서 두 가지 질문이 있습니다.
- 트랜잭션 격리 수준 스냅 샷 이 예상대로 작동하는지 확인하려면 어떻게 해야합니까?
- 웹 테이블의 보고서 테이블에 대한 외래 키가 교착 상태를 담당한다고 가정합니다. 이 흥미로운 기사를 찾았습니다 .
참고 트랜잭션이 읽기 커밋 된 스냅 숏 (행 버전 관리를 사용하여 커밋 된 읽기) 또는 스냅 숏 격리 수준을 사용하더라도 외래 키의 유효성을 검사 할 때 SQL Server는 공유 잠금을 얻습니다. 이러한 트랜잭션 격리 수준을 사용할 때 트랜잭션에서 교착 상태 그래프를 검사 할 때이 점에 유의하십시오. 공유 잠금이 표시되면 외래 키가 참조하는 객체에서 잠금이 수행되는지 확인하십시오.
FK가 교착 상태 / 시간 초과 상황에 실제로 책임이 있는지 어떻게 확인할 수 있습니까? 즉, 교착 상태를 방지하기 위해 외래 키를 삭제할 수 있습니까 (허용 가능한 노력은 무엇입니까)?
참고 : 교착 상태를 유발하는 테이블에서만 읽습니다.
이 주제에 대한 의견은 대단히 감사합니다.
여기 교착 상태 그래프가 편집 됩니다. 어쩌면 누군가 교착 상태의 원인을 이해하도록 도울 수 있습니다. 두 트랜잭션이 동일한 테이블을 작성하려고 할 때 웹 응용 프로그램으로 인한 보고서 만 실행되지 않은 것으로 보입니다 (하나의 업데이트와 하나의 삽입, 삽입은 저장 프로 시저와 같습니다). 왜 페이지 잠금을 요구하고 행 잠금 만 활성화합니까? Insert-SP는 이미 사용합니다 TRANSACTION ISOLATION LEVEL REPEATABLE READ.
두 개의 트리거 (하나의 업데이트와 하나의 삽입)가 교착 상태를 담당한다는 강한 의혹이 있습니다. 삽입 트리거는 다음과 같습니다.
CREATE TRIGGER [dbo].[CreateRMAFiDates]
ON [dbo].[RMA]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
UPDATE RMA
SET [fiCreationDate]=(SELECT idDate FROM tdefDate
WHERE CONVERT(VARCHAR, INSERTED.Creation_Date, 112) = tdefDate.Text),
[fiPopDate]=(SELECT idDate FROM tdefDate
WHERE CONVERT(VARCHAR, INSERTED.POP_Date, 112) = tdefDate.Text),
[fiManufactureDate]=(SELECT idDate FROM tdefDate
WHERE CONVERT(VARCHAR, INSERTED.Manufacture_Date, 112) = tdefDate.Text)
FROM INSERTED;
END따라서이 트리거는 RMA-Table을 업데이트하여 업데이트 트리거를 발생시키는 원인 (유사한 것)을 나타냅니다. 교착 상태 그래프가 내 가정을 확인합니까? 이 트리거는 SSAS-Cube (Molap) 전용이기 때문에 이러한 트리거를 삭제하고 하루에 한 번 실행되는 SP를 작성하면 충분하다고 생각합니다.
편집 : 그건 그렇고,이 트리거를 삭제 한 이후 더 이상 교착 상태가 없었습니다 :)