A memória cache do banco de dados no Monitor de desempenho cai significativamente após o DBCC CheckDB


8

Temos monitorado algumas SQLServer: Memory Managermétricas e percebemos que após o DBCC CheckDBtrabalho, as métricas

Database Cache Memory (KB)

cai significativamente. Para ser exato, caiu de 140 GB de memória de banco de dados em cache para 60 GB. E depois disso, suba lentamente novamente durante a semana. (O valor " Free Memory KB" passou de 20 para 100 GB logo após CheckDB)

DBCC CheckDB é executado todo domingo, portanto, a Memória em Cache do Banco de Dados precisa aumentar novamente a cada semana

What is the behavior of this ? Why CheckDB pushes database pages out of memory ?

A segunda pergunta é por que " buffer cache hit ratio" não mudou após a DBCC CheckDBconclusão?

Foi de 99,99%, em média, e após o DBCC CheckDBtrabalho cai para ~ 98,00%, e retorna para 99% rapidamente, enquanto eu esperava " buffer cache hit ratio" cair significativamente porque os dados do banco de dados precisam ser lidos novamente do armazenamento para a RAM?


Em relação ao BCHR, a razão pela qual ele não caiu mais pode ser porque o código CHECKDB pode ser feito usando Read-ahead (RA), e a E / S feita pelo RA não é incluída no cálculo do BCHR. O que, por sua vez, torna o BCHR um contador de perfurações bastante inútil.
Tibor Karaszi 01/08/19

Respostas:


9

Monitoramos algumas métricas do SQLServer: Memory Manager e percebemos que, após o trabalho do DBCC CheckDB, a métrica

A memória cache do banco de dados (KB) diminui significativamente. Para ser exato, caiu de 140 GB de memória de banco de dados em cache para 60 GB

Isso está correto, você pode ver claramente esse comportamento quando este DBCC CHECKDBcomando de exemplo é concluído em21h45

insira a descrição da imagem aqui insira a descrição da imagem aqui


Por quê

Esse comportamento ocorre devido à queda database snapshotdo DBCCcomando criado , removendo todos os seus objetos na memória.

Você pode replicar o comportamento criando um instantâneo de um banco de dados, carregando alguns dados na memória e eliminando esse instantâneo

  CREATE DATABASE MY_DATABASE
     GO
     USE MY_DATABASE 
     GO
     CREATE TABLE dbo.bla(id int identity(1,1) PRIMARY KEY NOT NULL,
                          val int,
                          val2 char(100));



    INSERT INTO dbo.bla(val,val2)
    SELECT ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),'bla'
    FROM master..spt_values spt
    CROSS APPLY master..spt_values spt2;
    GO

    CREATE DATABASE MY_DATABASE_SNAPSHOT
     ON  
     (  
     NAME ='MY_DATABASE',  
     FILENAME ='D:\DATA\MY_DATABASE.ss'  
     ) 
     AS SNAPSHOT OF MY_DATABASE;

     GO


    USE MY_DATABASE_SNAPSHOT
    GO
    SELECT * FROM dbo.bla;

     SELECT
      COUNT(file_id) * 8/1024.0 AS BufferSizeInMB
    FROM sys.dm_os_buffer_descriptors;

BufferSize antes de descartar o instantâneo

BufferSizeInMB
1061.70312  --before

Soltando o instantâneo

USE master
GO
DROP DATABASE MY_DATABASE_SNAPSHOT ; 

BufferSize após descartar o instantâneo

BufferSizeInMB
824.179687 --after

A segunda pergunta é por que a "taxa de acertos do cache do buffer" não mudou após a conclusão do DBCC CheckDB?

Isso depende da rapidez com que os dados são carregados de volta no cache do buffer.

Se o seu pool de buffers ficar cheio por mais tempo, ele deverá atingir essa proporção, permanecendo mais alto, em média.

Isso corresponde a esta parte da sua pergunta:

... Ele ( tamanho do dado do buffer pool ) caiu de 140 GB de memória do banco de dados em cache para 60 GB. e depois disso, suba lentamente de novo durante a semana ...


obrigado Randi! quando falamos sobre o snapshot de banco de dados interno criado pelo DBCC CheckDB, ele está criando na memória? ou no disco? ou os dois #
Aleksey Vitsko
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.