La memoria caché de la base de datos en el Monitor de rendimiento cae significativamente después de DBCC CheckDB

Hemos estado monitoreando algunas SQLServer: Memory Managermétricas y notamos que después del DBCC CheckDBtrabajo, métricas

Database Cache Memory (KB)

cae significativamente. Para ser exactos, se redujo de 140 GB de memoria DB en caché a 60 GB. Y después de eso, aumente lentamente nuevamente durante la semana. (Cantidad de " Free Memory KB", pasó de 20 a 100 GB justo después CheckDB)

DBCC CheckDB se ejecuta todos los domingos, por lo que la memoria de la memoria caché de la base de datos debe volver a aumentar cada semana

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

La segunda pregunta es ¿por qué " buffer cache hit ratio" no cambió después de DBCC CheckDBcompletarse?

Fue de 99.99% en promedio y después del DBCC CheckDBtrabajo se redujo a ~ 98.00%, y regresó a 99% bastante rápido mientras esperaba que " buffer cache hit ratio" cayera significativamente porque los datos de la base de datos deben leerse desde el almacenamiento a la RAM nuevamente.

Hemos estado monitoreando algunos SQLServer: métricas del Administrador de memoria, y notamos que después del trabajo DBCC CheckDB, la métrica

La memoria caché de la base de datos (KB) cae significativamente. Para ser exactos, se redujo de 140 GB de memoria DB en caché a 60 GB

Esto es correcto, puede ver claramente este comportamiento cuando este DBCC CHECKDBcomando de ejemplo se completa en21h45

Por qué

Este comportamiento se debe al hecho database snapshotde que el DBCCcomando se descarta y elimina todos sus objetos en la memoria.

Puede replicar el comportamiento creando una instantánea de una base de datos, cargando algunos datos en la memoria y luego soltando esa instantánea

  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 soltar la instantánea

BufferSizeInMB
1061.70312  --before

Soltando la instantánea

USE master
GO
DROP DATABASE MY_DATABASE_SNAPSHOT ; 

BufferSize después de soltar la instantánea

BufferSizeInMB
824.179687 --after

La segunda pregunta es ¿por qué la "proporción de aciertos de la memoria caché del búfer" no cambió después de que se completa DBCC CheckDB?

Esto depende de qué tan rápido se carguen los datos en su caché de búfer.

Si su grupo de búferes se llena durante un tiempo más largo, debería equivaler a que esta proporción se mantenga más alta en promedio.

Esto corresponde con esta parte de su pregunta:

... ( Tamaño de datos del grupo de búferes ) se redujo de 140 GB de memoria DB en caché a 60 GB. y después de eso, aumenta lentamente de nuevo durante la semana ...