Dans SQL Server sys.dm_os_memory_cache_entries
, il est possible d'afficher à la fois le coût d'origine d'une entrée dans le cache ainsi que le coût actuel de l'entrée du cache ( original_cost
et current_cost
respectivement). Le DMV sys.dm_os_buffer_descriptors
contient un enregistrement des pages actuellement en mémoire ainsi que des métadonnées sur les pages. Un morceau intéressant d'informations non disponibles dans le DVM sont les valeurs LRU-K pour les pages de données.
Est-il possible d'obtenir les valeurs LRU-K pour les pages de données dans le pool de tampons dans SQL Server? Si c'est le cas, comment?
sql-server
Jeremiah Peschka
la source
la source
Réponses:
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 signifientbUse1
.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).
Les résultats typiques sont
Le deuxième résultat étant
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
avecK=2
selon le livre interne. Ne devrait-il pas y en avoirbUse2
? 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 couruLa valeur affichée en mémoire est celle attendue.
La
DBCC
commande met à jour cette valeur deux fois. Une fois àAvec la valeur plus élevée, puis à nouveau à
Avec le plus bas.
Je ne connais aucun moyen d'obtenir des adresses de tampon pour les pages sans utiliser
DBCC BUFFER
/ deDBCC PAGE
toute façon et en utilisant ces deux changements la valeur que nous essayons d'inspecter!la source
Comme je l'ai mentionné à M. Peschka sur Twitter, ces informations sont conservées dans la structure BUF qui conserve la page en mémoire. DBCC PAGE vous donne ces informations dans le cadre de son en-tête.
la source
DBCC PAGE
c'est une façon terrible de trouver quoi que ce soit, mais vous semblez avoir raison. Il est dommage que les données proviennentDBCC PAGE
, effectivement, de charabia et ne se rapportent à aucune heure système réelle.