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 PAGE
và để 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 PAGE
là 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-K
với K=2
theo 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 bUse1
giá 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.

(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 PAGE
chí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 DBCC
lệ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 PAGE
bấ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!