실제로 내가 볼 수있는 한이를 수행하는 유용한 방법은 없습니다.
다른 답변 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
내가 아는 값을 바꾸지 않고 값 을 관찰하는 한 가지 방법이 있으며 여기에서 Bob Ward 가 시연 합니다.
디버거를 SQL Server 프로세스에 연결하고 버퍼 구조의 메모리 주소에 대한 참조 메모리를 표시하십시오 ( 0x00000002FE1F1440
위 그림 참조).
위의 스크립트를 실행 한 직후이 작업을 수행하여 다음을 확인했습니다.
(이전 실험에서 강조 표시된 바이트가 실행간에 변경된 유일한 바이트이므로 확실히 올바른 바이트임을 알았습니다.)
놀라운 측면 중 하나는 SELECT CAST(0xc896 as int)
= 51350
입니다.
이보고 한 것보다 정확히 3600 (1 시간) 짧습니다 DBCC PAGE
.
나는 이것이 DBCC PAGE
자신 을 호출하여 캐시에 보관되는 페이지를 싫어하는 일부 시도라고 생각 합니다. "일반"페이지의 경우이 1 시간 조정이 발생하지 않습니다를 선택하십시오. 실행 후
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
방법을 모릅니다.이 두 가지 변경 사항을 모두 사용하여 검사하려고하는 값을 사용하십시오!