Чи можливо переглядати значення LRU-K у SQL Server?

У SQL Server sys.dm_os_memory_cache_entriesможна переглянути як початкову вартість запису в кеші, так і поточну вартість запису кеша ( original_costі current_costвідповідно). DMV sys.dm_os_buffer_descriptorsмістить запис сторінок, які наразі знаходяться в пам'яті, а також деякі метадані про сторінки. Один цікавий фрагмент інформації, недоступної у DVM, - це значення LRU-K для сторінок даних.

Чи можливо отримати значення LRU-K для сторінок даних у буферному пулі на SQL Server? Якщо так, то як?

Насправді немає корисного способу зробити це, наскільки я бачу.

Інша відповідь згадує DBCC PAGEі залишає читачеві розібратися в деталях. З експерименту я припускаю, що вони означають bUse1.

Це не враховує той факт, що DBCC PAGEсам є використанням сторінки, і значення оновлюється до того, як воно буде показане нам.

Сценарій, що демонструє це, наведено нижче (для запуску потрібно 12 секунд).

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

Типові результати такі

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

З другим результатом

+---------+-------------------------+--------------+--------------------+
| 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 секунд збільшується на 7, а після 5-секундної затримки на 5.

Тож здається зрозумілим, що ці значення LRU - це секунди з певної епохи. Перезапуск послуги SQL Server не змінює епоху, а перезапуск машини.

Значення котиться кожні 65 536 секунд, тому я припускаю, що воно просто використовує щось подібне system_up_time mod 65536

Це не залишає жодних питань без відповіді (будь-які користувачі?). SQL Server використовує LRU-Kз K=2відповідно до книги внутрішніх справ. Чи не повинно бути bUse2? Якщо так, де це?

Є один із способів спостереження за bUse1цінністю, не змінюючи його, про який я знаю, і який демонструє тут Боб Уорд .

Приєднайте відладчик до процесу SQL Server і відображіть посилальну пам'ять для адреси пам'яті буферної структури (показано 0x00000002FE1F1440вище).

Я зробив це відразу після запуску сценарію вище і побачив наступне.

(З попереднього експерименту я виявив, що виділені байти були єдиними, що змінювались між прогонами, тому це, безумовно, правильні).

Один з дивовижних аспектів - це SELECT CAST(0xc896 as int)= 51350.

Це рівно на 3600 (на одну годину) менше, ніж повідомляли DBCC PAGE.

Я вважаю, що це якась спроба ошукання сторінок, що зберігаються в кеші, називаючи DBCC PAGEсебе. Для "звичайної" сторінки виберіть це одногодинне коригування. Після бігу

SELECT *
FROM T

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

Значення, показане в пам'яті, як очікується.

DBCCКоманда фактично оновлює це значення в два рази. Одного разу в

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

З більш високим значенням, то знову при

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

З нижньою.

Я не знаю жодного способу отримання буферних адрес для сторінок без використання DBCC BUFFER/ DBCC PAGEбудь-яким способом, хоча і використовуючи обидві ці зміни, значення, яке ми намагаємось перевірити!

Як я вже згадував пану Пешку на Twitter, ця інформація зберігається в структурі BUF, яка зберігає сторінку в пам'яті. DBCC PAGE надає вам цю інформацію як частину її заголовка.