No SQL Server sys.dm_os_memory_cache_entries
é possível visualizar tanto o custo original de uma entrada no cache quanto o custo atual da entrada no cache ( original_cost
e current_cost
respectivamente). O DMV sys.dm_os_buffer_descriptors
contém um registro das páginas que estão atualmente na memória, bem como alguns metadados sobre as páginas. Uma informação interessante não disponível no DVM são os valores LRU-K para as páginas de dados.
É possível obter os valores LRU-K para páginas de dados no buffer pool no SQL Server? Em caso afirmativo, como?
Na verdade, não há uma maneira útil de fazer isso, até onde posso ver.
A outra resposta menciona
DBCC PAGE
e deixa para o leitor descobrir os detalhes. Pela experimentação, presumo que eles signifiquembUse1
.Isso não leva em conta que
DBCC PAGE
é um uso da página e o valor é atualizado antes de ser mostrado para nós.Um script demonstrando isso está abaixo (leva 12 segundos para ser executado).
Os resultados típicos são
Sendo o segundo resultado
A saída após o atraso de 7 segundos é incrementada em 7 e após o atraso de 5 segundos em 5.
Portanto, parece claro que esses valores de LRU são segundos desde alguma época. Reiniciar o serviço do SQL Server não altera a época, mas reiniciar a máquina sim.
O valor rola a cada 65.536 segundos, então presumo que use algo como
system_up_time mod 65536
Isso deixa uma pergunta sem resposta em minha mente (algum candidato?). O SQL Server usa
LRU-K
comK=2
de acordo com o livro interno. Não deveria haver umbUse2
? Se sim, onde é isso?Existe uma maneira de observar o
bUse1
valor sem alterá-lo que eu conheço e que é demonstrada por Bob Ward aqui.Anexe um depurador ao processo do SQL Server e exiba a memória referenciada para o endereço de memória da estrutura do buffer (mostrado
0x00000002FE1F1440
acima).Fiz isso imediatamente após executar o script acima e vi o seguinte.
(Na experiência anterior, descobri que os bytes destacados eram os únicos que mudavam entre as execuções, então esses são definitivamente os corretos).
Um aspecto surpreendente é que
SELECT CAST(0xc896 as int)
=51350
.Isso é exatamente 3600 (uma hora) a menos do que o relatado por
DBCC PAGE
.Acredito que seja uma tentativa de desfavorecer as páginas mantidas em cache chamando a
DBCC PAGE
si mesmo. Para uma página "normal", selecione este ajuste de uma hora não ocorre. Depois de correrO valor mostrado na memória é o esperado.
Na
DBCC
verdade, o comando atualiza esse valor duas vezes. Uma vez emCom o valor mais alto, novamente em
Com o inferior.
Não tenho conhecimento de nenhuma maneira de obter endereços de buffer para páginas sem usar
DBCC BUFFER
/ deDBCC PAGE
qualquer maneira e usar essas duas alterações o valor que estamos tentando inspecionar!Como mencionei ao Sr. Peschka no twitter, essas informações são mantidas na estrutura do BUF que mantém a página na memória. DBCC PAGE fornece essas informações como parte de seu cabeçalho.