Có thể xem các giá trị LRU-K trong SQL Server không?


21

Trong SQL Server sys.dm_os_memory_cache_entries, có thể xem cả chi phí ban đầu của một mục trong bộ đệm cũng như chi phí hiện tại của mục nhập bộ đệm ( original_costcurrent_costtương ứng). DMVsys.dm_os_buffer_descriptors chứa bản ghi các trang hiện có trong bộ nhớ cũng như một số siêu dữ liệu về các trang. Một đoạn thông tin thú vị không có sẵn trong DVM là các giá trị LRU-K cho các trang dữ liệu.

Có thể lấy các giá trị LRU-K cho các trang dữ liệu trong vùng đệm trong SQL Server không? Nếu vậy thì thế nào?


Đây có phải là phiên bản cụ thể không?
JNK

1
@JNK - Trong một thế giới hoàn hảo, không, nhưng miễn là nó hoạt động trên SQL Server 2012, tôi không thực sự lo lắng.
Jeremiah Peschka

Câu trả lời:


21

Thực tế không có cách nào hữu ích để làm điều này như tôi có thể thấy.

Câu trả lời khác đề cập DBCC PAGEvà để lại cho người đọc để tìm ra các chi tiết. Từ thử nghiệm tôi cho rằng chúng có nghĩa bUse1.

Điều này không thể coi tài khoản đó DBCC PAGElà việc sử dụng trang và giá trị được cập nhật trước đó nó được hiển thị cho chúng tôi.

Một đoạn script thể hiện điều này ở bên dưới (mất 12 giây để chạy).

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

Kết quả điển hình là

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

Với kết quả thứ hai là

+---------+-------------------------+--------------+--------------------+
| 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 |
+---------+-------------------------+--------------+--------------------+

Đầu ra sau độ trễ 7 giây được tăng thêm 7 và sau độ trễ 5 giây thêm 5.

Vì vậy, có vẻ như rõ ràng rằng các giá trị LRU này là vài giây kể từ một số kỷ nguyên. Khởi động lại dịch vụ SQL Server không làm thay đổi kỷ nguyên nhưng khởi động lại máy thì có.

Giá trị cuộn qua mỗi 65.536 giây vì vậy tôi cho rằng nó chỉ sử dụng một cái gì đó như system_up_time mod 65536

Điều này không để lại một câu hỏi chưa được trả lời trong tâm trí của tôi (bất kỳ người tham gia?). SQL Server sử dụng LRU-Kvới K=2theo cuốn sách internals. Không nên có một bUse2? Nếu vậy thì ở đâu?

Có một cách để quan sát bUse1giá trị mà không thay đổi giá trị mà tôi biết và điều đó được thể hiện bởi Bob Ward ở đây.

Đính kèm trình gỡ lỗi vào quy trình SQL Server và hiển thị bộ nhớ được tham chiếu cho địa chỉ bộ nhớ của cấu trúc bộ đệm (hiển thị 0x00000002FE1F1440ở trên).

Tôi đã làm điều này ngay lập tức sau khi chạy đoạn script trên và thấy như sau.

nhập mô tả hình ảnh ở đây

(Từ thử nghiệm trước đây, tôi đã tìm thấy các byte được tô sáng là các byte duy nhất thay đổi giữa các lần chạy để chúng chắc chắn là các byte phù hợp).

Một khía cạnh đáng ngạc nhiên là SELECT CAST(0xc896 as int)= 51350.

Đây là chính xác ít hơn 3600 (một giờ) so với báo cáo DBCC PAGE.

Tôi tin rằng đây là một số nỗ lực để làm biến dạng các trang bị giữ trong bộ đệm bằng cách gọi DBCC PAGEchính nó. Đối với trang "bình thường", chọn điều chỉnh một giờ này không xảy ra. Sau khi chạy

SELECT *
FROM T

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

Giá trị hiển thị trong bộ nhớ là như mong đợi.

Các DBCClệnh thực sự cập nhật giá trị mà hai lần. Một lần tại

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

Với giá trị cao hơn thì một lần nữa tại

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

Với cái thấp hơn.

Tôi không biết bất kỳ cách nào để có được địa chỉ bộ đệm cho các trang mà không sử dụng DBCC BUFFER/ DBCC PAGEbất kỳ cách nào và sử dụng cả hai thay đổi này giá trị chúng tôi đang cố gắng kiểm tra!


3
Vâng, đây là một cách để dành Giáng sinh của bạn. :-)
RBarryYoung

3
@RBarryYoung Beats chơi Trivial Pursuit!
Martin Smith

Nếu tôi có thể cho điểm thưởng để sử dụng trình gỡ lỗi thích hợp, tôi sẽ làm thế.
Jeremiah Peschka

1
Làm tốt! (Và kỹ năng sửa lỗi tuyệt vời!)
DBArgenis 30/12/13

@DBArgenis - Cảm ơn! Thật xấu hổ vì dường như không có một giải pháp thực tế nào. Nó có thể khá nhiều thông tin nếu chúng ta có thể thấy điều này một cách dễ dàng.
Martin Smith

8

Như tôi đã đề cập với ông Peschka trên twitter, thông tin này được lưu giữ trên cấu trúc BUF giữ trang trong bộ nhớ. TRANG DBCC cung cấp cho bạn thông tin này như một phần của tiêu đề.


3
Bắt đầu, tôi cấp cho bạn "câu trả lời", @DBArgenis. Tôi vẫn duy trì đó DBCC PAGElà một cách khủng khiếp để tìm thấy bất cứ điều gì, nhưng bạn dường như là chính xác. Thật đáng tiếc rằng dữ liệu từ DBCC PAGE, một cách hiệu quả, vô nghĩa và không liên quan đến bất kỳ thời gian thực của hệ thống.
Jeremiah Peschka

8
Một ví dụ sẽ là một bổ sung hữu ích cho câu trả lời này.
Mark Storey-Smith

3
@ MarkStorey-Smith - Tôi đồng ý. Trừ khi DBArgenis có một số mánh khóe, tôi không thể thấy nó hữu ích như thế nào.
Martin Smith

2
Không có tài liệu tham khảo nào về TRANG DBCC bao giờ cho bất cứ điều gì hữu ích.
Jeremiah Peschka
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.