Il n'y a en fait aucun moyen utile de le faire pour autant que je puisse voir.
L'autre réponse mentionne DBCC PAGE
et laisse au lecteur le soin de comprendre les détails. D'après l'expérimentation, je suppose qu'ils signifient bUse1
.
Cela ne prend pas en compte qui DBCC PAGE
est en soi une utilisation de la page et la valeur est mise à jour avant qu'elle ne nous soit montrée.
Un script démontrant ceci est ci-dessous (prend 12 secondes pour s'exécuter).
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
Les résultats typiques sont
+----+--------------+-------------------------+-------+-------------+
| ID | ParentObject | Object | Field | ObjectValue |
+----+--------------+-------------------------+-------+-------------+
| 8 | BUFFER: | BUF @0x00000002FE1F1440 | bUse1 | 54938 |
| 49 | BUFFER: | BUF @0x00000002FE1F1440 | bUse1 | 54945 |
| 90 | BUFFER: | BUF @0x00000002FE1F1440 | bUse1 | 54950 |
+----+--------------+-------------------------+-------+-------------+
Le deuxième résultat étant
+---------+-------------------------+--------------+--------------------+
| 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 |
+---------+-------------------------+--------------+--------------------+
La sortie après le délai de 7 secondes est incrémentée de 7 et après le délai de 5 secondes de 5.
Il semble donc clair que ces valeurs LRU sont des secondes depuis une certaine époque. Le redémarrage du service SQL Server ne modifie pas l'époque mais le redémarrage de la machine le fait.
La valeur est reportée toutes les 65 536 secondes, donc je suppose qu'elle utilise simplement quelque chose comme system_up_time mod 65536
Cela laisse une question sans réponse dans mon esprit (des preneurs?). SQL Server utilise LRU-K
avec K=2
selon le livre interne. Ne devrait-il pas y en avoir bUse2
? Si oui, où est-ce?
Il y a une façon d'observer la bUse1
valeur sans la changer que je sache et c'est Bob Ward démontre ici.
Attachez un débogueur au processus SQL Server et affichez la mémoire référencée pour l'adresse mémoire de la structure de la mémoire tampon (affichée comme étant 0x00000002FE1F1440
ci-dessus).
J'ai fait cela immédiatement après avoir exécuté le script ci-dessus et j'ai vu ce qui suit.

(D'après une expérimentation précédente, j'avais trouvé que les octets en surbrillance étaient les seuls à avoir changé entre les exécutions, ce sont donc certainement les bons).
Un aspect surprenant est que SELECT CAST(0xc896 as int)
=51350
.
C'est exactement 3600 (une heure) de moins que ce qui est rapporté par DBCC PAGE
.
Je pense que c'est une tentative de défavoriser les pages gardées en cache en s'appelant DBCC PAGE
. Pour une page "normale" sélectionnez ce réglage d'une heure ne se produit pas. Après avoir couru
SELECT *
FROM T
SELECT ((ms_ticks) % 65536000) / 1000 AS [Roughly Expected Value]
FROM sys.dm_os_sys_info
La valeur affichée en mémoire est celle attendue.
La DBCC
commande met à jour cette valeur deux fois. Une fois à
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
Avec la valeur plus élevée, puis à nouveau à
sqlmin.dll!LatchedBuf::FreeAndUnlatch() + 0x71 bytes
sqlmin.dll!UtilDbccDumpPage() + 0x545 bytes
sqlmin.dll!DbccPage() + 0xfa bytes
sqllang.dll!DbccCommand::Execute() + 0x153 bytes
Avec le plus bas.
Je ne connais aucun moyen d'obtenir des adresses de tampon pour les pages sans utiliser DBCC BUFFER
/ de DBCC PAGE
toute façon et en utilisant ces deux changements la valeur que nous essayons d'inspecter!