Sorun

Ben serileştirilebilir izolasyon altında bir RX-X kilit neden sorguları bir çift var. Ancak, kilit alımını izlemek için Genişletilmiş Olaylar'ı kullandığımda, RX-X kilit alımı hiçbir zaman görünmez, yalnızca serbest bırakılır. Nereden geliyor?

Repro

İşte masam:

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')

İşte benim sorun toplu iş:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

BEGIN TRAN

INSERT dbo.LockTest
VALUES ('bleh')

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

--ROLLBACK

Bu oturum tarafından tutulan kilitleri kontrol ediyorum ve RX-X'i görüyorum:

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

Ama lock_acquiredve üzerinde Genişletilmiş bir Etkinlik var lock_released. Ben ilgili related_object_id filtre ... Ben RX-X yoktur.

Geri alma işlemini gerçekleştirdikten sonra, RX-X'in (LAST_MODE) hiçbir zaman edinilmemiş olmasına rağmen yayınlandığını görüyorum.

Ne Denedim

• Genişletilmiş Etkinliklerde tüm kilitlere baktım - filtreleme yok. Hiçbir RX-X kilidi alınmadı.

• Ben de Profiler denedim: aynı sonuçlar (tabii ki adı doğru alır ... hayır "LAST_MODE").

• Kilit yükselmeleri için XE'yi çalıştırdım - orada değil.

• Dönüşümler için özel olarak XE yoktur, ancak en azından U'dan X'e kilit dönüşümünün lock_acquired

Ayrıca, edinilen ancak asla serbest bırakılmayan RI-N de dikkat çekicidir. Şu anki hipotezim, RX-X'in burada açıklandığı gibi bir dönüşüm kilidi olduğudur . Toplu işimde dönüşüm için uygun olmaları gerektiği gibi çakışan anahtar aralığı kilitleri var, ancak RX-X kilidi dönüşüm tablosunda değil.

Bu kilit nereden geliyor ve neden Genişletilmiş Etkinlikler tarafından alınmıyor?

Tek sıralı insert Xyeni sıra üzerinde (özel) bir kilit alır.

SELECTBir aralık paylaşılmış anahtarı elde etmek girişimleri (paylaşılan RangeS-S) kilit.

Bu istek lock_acquiredGenişletilmiş Olay tarafından mode = olarak bildirilir RS_S.

Profiler olay sınıfı Lock:Acquiredtarafından mod 13 ( LCK_M_RS_S) olarak bildirilir .

İstenen mod mevcut ile birleştirilir özel kilit modu Lock::CalculateGrantModeiçinde sqlmin.dll. Aralık paylaşımlı, anahtar özel ( RangeS-X) birleşik modu yoktur, bu nedenle hesaplama sonucu, aralık RangeX-X15 , anahtar özel ( ) olur ve bu da mod 15 olur.

Yukarıdaki hibe modu hesaplaması, genişletilmiş olay tarafından oluşturulmadan hemen önce gerçekleştirilir lck_ProduceExtendedEvent<XeSqlPkg::lock_acquired>. Bununla birlikte, hem Profiler hem de Genişletilmiş Olaylar , ortaya çıkan kilit modunu değil, istenen RangeS-S modu günlüğe kaydeder RangeX-X. Bu sınırlı belgelerin tersidir:

Modu | int | Kilit alındıktan sonra sonuç modu.

Modu uzatılmış olayın sütun da hiç belgelerine sahiptir, ve meta veri tanımı boştur. Belki de Microsoft'un kendileri davranıştan bile emin değildi.

Sık sık kilit olayları iki bildirildi eğer daha yararlı olacağını düşündüm talep ve ortaya çıkan modları, fakat elimizde değil. Mevcut düzenleme, kilit edinimini ve serbest bırakılmasını izlemeyi ve eşleştirmeyi neredeyse imkansız hale getiriyor.

Orada olabilir kilitler bu şekilde raporlama için iyi bir neden olabilir. İhtiyaçlarınızı karşılamıyorsa, Microsoft ile bir destek vakası açabilir veya bir Azure Geri Bildirim öğesi oluşturabilirsiniz.

LAST_MODE

Gizemli LAST_MODE, Erik Darling'in daha önce bahsettiği bir şey . Aşağıdakilerin map_keymaruz kaldığı kilit modları listesindeki en yüksek değerdir 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 (kullanılarak sqlmin!CMapValuesTable) üzerinden erişilen bellek yapısı adresten başlayarak saklanır sqlmin!XeSqlPkg::g_lock_mode. Yapıdaki her 16 baytlık giriş , akışlı TVF tarafından map_keydöndürülen dizeye ve bir işaretçi içerir map_value.

Dizeler tam olarak yukarıdaki tabloda gösterildiği gibi saklanır (bu sırada olmasa da). Giriş 21'in map_valuebeklenen "RX_X" yerine "LAST_MODE" değerine sahip olması bir hata gibi görünüyor . Erik Darling, Azure Feedback ile ilgili sorunu bildirdi .