이 RX-X 잠금이 확장 이벤트에 나타나지 않는 이유는 무엇입니까?


13

문제

직렬화 가능한 격리에서 RX-X 잠금을 유발하는 쿼리 쌍이 있습니다. 그러나 확장 이벤트를 사용하여 잠금 획득을 볼 때 RX-X 잠금 획득은 표시되지 않으며 해제 만됩니다. 그거 어디서 났어?

재현

내 테이블은 다음과 같습니다.

CREATE TABLE dbo.LockTest (
ID int identity,
Junk char(4)
)

CREATE CLUSTERED INDEX CX_LockTest --not unique!
ON dbo.LockTest(ID)

--preload some rows
INSERT dbo.LockTest
VALUES ('data'),('data'),('data')

내 문제 배치는 다음과 같습니다.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

BEGIN TRAN

INSERT dbo.LockTest
VALUES ('bleh')

SELECT *
FROM dbo.LockTest
WHERE ID = SCOPE_IDENTITY()

--ROLLBACK

이 세션에서 보유한 잠금을 확인하고 RX-X를 참조하십시오.

SELECT resource_type, request_mode, request_status, resource_description
FROM sys.dm_tran_locks
WHERE request_session_id = 72 --change SPID!

dm_tran_locks

그러나 나는 또한에 확장 이벤트를 lock_acquired하고 lock_released. 적절한 associated_object_id에서 필터링합니다 .RX-X가 없습니다.

확장 이벤트 출력

롤백을 실행 한 후에는 RX-X (LAST_MODE)가 출시되지 않았음에도 불구하고 릴리스되었습니다.

LAST_MODE

내가 시도한 것

  • 확장 이벤트의 모든 잠금을 살펴 보았습니다 . 필터링은 없습니다. RX-X 잠금이 획득되지 않았습니다.

  • 나는 또한 Profiler : 같은 결과를 시도했다.

  • 잠금 에스컬레이션을 위해 XE를 실행했습니다.

  • 특별히 변환을위한 XE는 없지만 최소한 U에서 X 로의 잠금 변환이 캡처되었음을 확인할 수있었습니다. lock_acquired

또한 획득되었지만 결코 공개되지 않은 RI-N도 주목할 만하다. 현재의 가설은 여기에 설명 된대로 RX-X가 변환 잠금이라는 입니다. 일괄 처리에 겹치는 키 범위 잠금이있어 변환에 적합해야하지만 RX-X 잠금이 변환 테이블에 없습니다.

이 잠금은 어디에서 왔으며 확장 이벤트에서 선택되지 않는 이유는 무엇입니까?

답변:


12

단일 행 삽입은 X새 행에서 (독점) 잠금을 획득합니다 .

SELECT범위 - 공유 키를 획득하려는 시도는 (공유 RangeS-S) 잠금을.

이 요청은 lock_acquired확장 이벤트에서 mode = 로보고됩니다 RS_S.

프로파일 러 이벤트 클래스에 Lock:Acquired의해 모드 13 ( LCK_M_RS_S) 으로 보고됩니다 .

요청 된 모드는의 기존 독점 잠금 모드 와 결합 Lock::CalculateGrantMode되어 sqlmin.dll있습니다. 범위 공유, 키 독점 ( RangeS-X) 의 결합 모드가 없으므로 계산 결과는 범위 독점, 키 독점 ( RangeX-X)이며 이는 모드 15입니다.

위의 부여 모드 계산은 확장 이벤트가에 의해 생성되기 직전에 수행됩니다 lck_ProduceExtendedEvent<XeSqlPkg::lock_acquired>. 그럼에도 불구하고 프로파일 러 및 확장 이벤트 는 결과 잠금 모드가 아니라 요청 된 RangeS-S 모드를 기록 합니다 RangeX-X. 이것은 제한된 문서 와 반대입니다 .

모드 | int | 잠금이 획득 된 후 결과 모드.

확장 이벤트 의 모드 열에는 문서가 전혀 없으며 메타 데이터의 설명은 비어 있습니다. 아마도 마이크로 소프트 자신도 그 행동을 확신하지 못했을 것입니다.

잠금 이벤트가 요청 모드 와 결과 모드를 모두보고하면 더 유용 할 것이라고 생각 했지만, 이것이 우리의 것이 아닙니다. 현재 배열은 잠금 획득 및 해제를 추적하고 일치시키는 것이 거의 불가능합니다.

이러한 방식으로 잠금을보고해야하는 적절한 이유 가 있을 수 있습니다. 요구 사항을 충족하지 못하면 Microsoft에서 지원 사례를 열거 나 Azure Feedback 항목을 만들 수 있습니다.


LAST_MODE

신비한 LAST_MODE것은 에릭 달링이 전에 언급 한 것 입니다. 다음 map_key에 의해 노출되는 잠금 모드 목록에서 가장 높은 값입니다 sys.dm_xe_map_values.

SELECT
    DXMV.map_key,
    DXMV.map_value
FROM sys.dm_xe_map_values AS DXMV
WHERE 
    DXMV.[name] = N'lock_mode'
ORDER BY
    DXMV.map_key;
╔═════════╦═══════════╗
║ map_key ║ map_value ║
╠═════════╬═══════════╣
║       0 ║ NL        ║
║       1 ║ SCH_S     ║
║       2 ║ SCH_M     ║
║       3 ║ S         ║
║       4 ║ U         ║
║       5 ║ X         ║
║       6 ║ IS        ║
║       7 ║ IU        ║
║       8 ║ IX        ║
║       9 ║ SIU       ║
║      10 ║ SIX       ║
║      11 ║ UIX       ║
║      12 ║ BU        ║
║      13 ║ RS_S      ║
║      14 ║ RS_U      ║
║      15 ║ RI_NL     ║
║      16 ║ RI_S      ║
║      17 ║ RI_U      ║
║      18 ║ RI_X      ║
║      19 ║ RX_S      ║
║      20 ║ RX_U      ║
║      21 ║ LAST_MODE ║
╚═════════╩═══════════╝

DMV를 통해 액세스하는 메모리 구조 sqlmin!CMapValuesTable는 주소에서 시작하여 저장됩니다 sqlmin!XeSqlPkg::g_lock_mode. 구조의 각 16 바이트 항목에는 스트리밍 TVF에서 map_key반환 한 문자열에 대한 및 포인터가 포함되어 있습니다 map_value.

문자열은 위의 표에 표시된대로 정확하게 저장됩니다 (순서는 아님). 항목 21 map_value의 예상 "RX_X"대신 "LAST_MODE" 라는 오류가있는 것 같습니다 . Erik Darling이 Azure Feedback에 대한 문제를보고했습니다 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.