LRU-K değerlerini SQL Server'da görüntülemek mümkün müdür?

SQL Server’da sys.dm_os_memory_cache_entries, hem önbellekteki bir girişin orijinal maliyetini hem de önbellek girişinin geçerli maliyetini ( original_costve current_costsırasıyla) görüntülemek mümkündür. DMV sys.dm_os_buffer_descriptors, şu anda bellekte olan sayfaların yanı sıra sayfalarla ilgili bazı meta verilerin kaydını içerir. DVM'de bulunmayan ilginç bir bilgi yığını, veri sayfaları için LRU-K değerleridir.

SQL Server'da tampon havuzundaki veri sayfaları için LRU-K değerlerini almak mümkün müdür? Öyleyse nasıl?

Aslında bunu görebildiğim kadarıyla yapmanın bir yolu yok.

Diğer cevap DBCC PAGE, detayları bulmak için onu okur ve yazar. Deneyden kastettiklerini farz ediyorum bUse1.

Bu DBCC PAGE, sayfanın kendisinin bir kullanımıdır ve bize gösterilmeden önce değer güncellenir .

Bunu gösteren bir betik aşağıdadır (çalışması 12 saniye sürer).

USE tempdb;

CREATE TABLE T(X INT);

INSERT INTO T VALUES(1);

DECLARE @DBCCPAGE NVARCHAR(100);

SELECT @DBCCPAGE = 'DBCC PAGE(0,' + CAST(file_id AS VARCHAR) + ',' + CAST(page_id AS VARCHAR) + ',0) WITH TABLERESULTS;'
FROM   T CROSS APPLY  sys.fn_PhysLocCracker (%%physloc%%)

DECLARE @DbccResults TABLE 
(
      ID INT IDENTITY,
      ParentObject VARCHAR(1000)NULL,
      Object VARCHAR(4000)NULL,
      Field VARCHAR(1000)NULL,
      ObjectValue VARCHAR(MAX)NULL
)    
INSERT INTO @DbccResults EXEC(@DBCCPAGE)  
WAITFOR DELAY '00:00:07'
INSERT INTO @DbccResults EXEC(@DBCCPAGE)  
WAITFOR DELAY '00:00:05'
INSERT INTO @DbccResults EXEC(@DBCCPAGE)             

SELECT *
FROM @DbccResults   
WHERE Field = 'bUse1'    
ORDER BY ID

EXEC(@DBCCPAGE) 

DROP TABLE T

Tipik sonuçlar

+----+--------------+-------------------------+-------+-------------+
| ID | ParentObject |         Object          | Field | ObjectValue |
+----+--------------+-------------------------+-------+-------------+
|  8 | BUFFER:      | BUF @0x00000002FE1F1440 | bUse1 |       54938 |
| 49 | BUFFER:      | BUF @0x00000002FE1F1440 | bUse1 |       54945 |
| 90 | BUFFER:      | BUF @0x00000002FE1F1440 | bUse1 |       54950 |
+----+--------------+-------------------------+-------+-------------+

İkinci sonuç

+---------+-------------------------+--------------+--------------------+
| BUFFER: | BUF @0x00000002FE1F1440 | bpage        | 0x00000002F4968000 |
| BUFFER: | BUF @0x00000002FE1F1440 | bhash        | 0x0000000000000000 |
| BUFFER: | BUF @0x00000002FE1F1440 | bpageno      | (1:120)            |
| BUFFER: | BUF @0x00000002FE1F1440 | bdbid        | 8                  |
| BUFFER: | BUF @0x00000002FE1F1440 | breferences  | 0                  |
| BUFFER: | BUF @0x00000002FE1F1440 | bcputicks    | 0                  |
| BUFFER: | BUF @0x00000002FE1F1440 | bsampleCount | 0                  |
| BUFFER: | BUF @0x00000002FE1F1440 | bUse1        | 54950              |
| BUFFER: | BUF @0x00000002FE1F1440 | bstat        | 0x9                |
| BUFFER: | BUF @0x00000002FE1F1440 | blog         | 0x1c9a             |
| BUFFER: | BUF @0x00000002FE1F1440 | bnext        | 0x0000000000000000 |
+---------+-------------------------+--------------+--------------------+

7 saniyelik gecikmeden sonraki çıkış 7, 5 saniyelik gecikmeden sonra 5 artırılır.

Bu nedenle, bu LRU değerlerinin bazı dönemlerden bu yana saniye olduğu açıktır. SQL Server hizmetini yeniden başlatmak, devreyi değiştirmez, ancak makineyi yeniden başlatır.

Bu değer her 65.536 saniyede bir değişiyor, bu yüzden sadece bunun gibi bir şey kullandığını varsayıyorum system_up_time mod 65536

Bu, aklımda cevaplanmamış bir soru bırakıyor (herhangi bir alıcı?). SQL Server , iç kitabına göre LRU-Kile kullanır K=2. Olmamalı mı bUse2? Eğer öyleyse bu nerede?

bUse1Değerini değiştirmeden gözlemlemenin bir yolu var, ancak benim bildiğim ve buradaki Bob Ward tarafından gösterilmiş .

SQL Server işlemine bir hata ayıklayıcı ekleyin ve arabellek yapısının bellek adresi için başvurulan belleği görüntüleyin ( 0x00000002FE1F1440yukarıda gösterildiği gibi).

Yukarıdaki betiği çalıştırdıktan hemen sonra bunu yaptım ve aşağıdakileri gördüm.

(Önceki denemede, vurgulanan baytların, koşular arasında değişen ve kesinlikle doğru olanlardır.

Şaşırtıcı bir yönü, bu SELECT CAST(0xc896 as int)= 51350.

Bu tam olarak 3600 (bir saat) bildirilenden daha az DBCC PAGE.

Bunun, DBCC PAGEkendisini arayarak önbellekte tutulan sayfaların gizlenmemesi girişimi olduğuna inanıyorum . "Normal" bir sayfa için bu bir saatlik ayarlama yapılmaz. Koşudan sonra

SELECT *
FROM T

SELECT ((ms_ticks) % 65536000) / 1000 AS [Roughly Expected Value]
FROM sys.dm_os_sys_info

Bellekte gösterilen değer beklendiği gibi.

DBCCKomut aslında iki katı değerini günceller. Bir zamanlar

sqlmin.dll!BPool::Touch()  + 0x3bfe bytes   
sqlmin.dll!BPool::Get()  + 0x12e bytes  
sqlmin.dll!LatchedBuf::ReadLatch()  + 0x14f bytes   
sqlmin.dll!UtilDbccDumpPage()  + 0x364 bytes    
sqlmin.dll!DbccPage()  + 0xfa bytes 
sqllang.dll!DbccCommand::Execute()  + 0x153 bytes

Daha yüksek bir değerle tekrar

sqlmin.dll!LatchedBuf::FreeAndUnlatch()  + 0x71 bytes   
sqlmin.dll!UtilDbccDumpPage()  + 0x545 bytes    
sqlmin.dll!DbccPage()  + 0xfa bytes 
sqllang.dll!DbccCommand::Execute()  + 0x153 bytes   

Alt ile.

Sayfalar için arabellek adresleri almanın hiçbir şekilde DBCC BUFFER/ DBCC PAGEher halükarda kullanmadan ve bu değişikliklerin her ikisini de kullanarak incelemeye çalıştığımız değeri bilmiyorum!

Twitter'daki Peschka'ya bahsettiğim gibi, bu bilgiler, sayfayı bellekte tutan BUF yapısında tutulur. DBCC PAGE size bu bilgiyi başlığının bir parçası olarak verir.