La mémoire cache de la base de données dans l'Analyseur de performances diminue considérablement après DBCC CheckDB

Nous avons surveillé certaines SQLServer: Memory Managermesures et avons remarqué qu’après le DBCC CheckDBtravail, les mesures

Database Cache Memory (KB)

baisse considérablement. Pour être exact, il est passé de 140 Go de mémoire DB mise en cache à 60 Go. Et après cela, remontez lentement au cours de la semaine. (La quantité de " Free Memory KB" est passée de 20 à 100 Go juste après CheckDB)

DBCC CheckDB est exécuté tous les dimanches, donc la mémoire cache de base de données doit remonter chaque semaine

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

La deuxième question est pourquoi " buffer cache hit ratio" n'a pas changé après la DBCC CheckDBfin?

Il était de 99,99% en moyenne et après le DBCC CheckDBtravail, il tombe à ~ 98,00%, et revient à 99% assez rapidement alors que je m'attendais à ce que " buffer cache hit ratio" baisse de manière significative car les données de la base de données doivent être lues de nouveau du stockage vers la RAM?

Nous avons surveillé certaines métriques de SQLServer: Memory Manager, et nous avons remarqué qu'après le travail DBCC CheckDB, métrique

La mémoire cache de la base de données (Ko) diminue considérablement. Pour être exact, il est passé de 140 Go de mémoire DB mise en cache à 60 Go

C'est correct, vous pouvez clairement voir ce comportement lorsque cet exemple de DBCC CHECKDBcommande se termine à21h45

Pourquoi

Ce comportement est dû au fait que database snapshotla DBCCcommande a été supprimée, supprimant tous ses objets en mémoire.

Vous pouvez reproduire le comportement en créant un instantané d'une base de données, en chargeant certaines données en mémoire, puis en supprimant cet instantané

  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 avant de supprimer l'instantané

BufferSizeInMB
1061.70312  --before

Suppression de l'instantané

USE master
GO
DROP DATABASE MY_DATABASE_SNAPSHOT ; 

BufferSize après la suppression de l'instantané

BufferSizeInMB
824.179687 --after

La deuxième question est de savoir pourquoi le "taux d'accès au cache de tampon" n'a pas changé après la fin de DBCC CheckDB?

Cela dépend de la vitesse à laquelle les données sont chargées dans votre cache tampon.

Si votre pool de tampons se remplit sur une plus longue période, il devrait s'élever à ce ratio restant plus élevé en moyenne.

Cela correspond à cette partie de votre question:

... Il ( taille du pool de tampons ) est passé de 140 Go de mémoire DB mise en cache à 60 Go. et après cela, remontez lentement pendant la semaine ...