Der Datenbank-Cache-Speicher im Leistungsmonitor sinkt nach DBCC CheckDB erheblich

Wir haben einige SQLServer: Memory ManagerMetriken überwacht und festgestellt, dass nach dem DBCC CheckDBJob Metriken

Database Cache Memory (KB)

fällt deutlich ab. Um genau zu sein, wurde der zwischengespeicherte DB-Speicher von 140 GB auf 60 GB reduziert. Und danach während der Woche langsam wieder hochfahren. (Menge von " Free Memory KB" ging direkt danach von 20 auf 100 GB CheckDB)

DBCC CheckDB wird jeden Sonntag ausgeführt, daher muss der Datenbank-Cache-Speicher jede Woche erneut hochgefahren werden

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

Die zweite Frage ist, warum sich " buffer cache hit ratio" nach DBCC CheckDBAbschluss nicht geändert hat.

Es war durchschnittlich 99,99% und nach dem DBCC CheckDBJob sinkt es auf ~ 98,00% und kehrt ziemlich schnell auf 99% zurück, während ich erwartet habe, dass " buffer cache hit ratio" signifikant sinken wird, weil Datenbankdaten wieder aus dem Speicher in den RAM gelesen werden müssen?

Wir haben einige Metriken von SQLServer: Memory Manager überwacht und festgestellt, dass nach dem DBCC CheckDB-Job eine Metrik vorliegt

Der Datenbank-Cache-Speicher (KB) sinkt erheblich. Um genau zu sein, wurde der zwischengespeicherte DB-Speicher von 140 GB auf 60 GB reduziert

Dies ist richtig. Sie können dieses Verhalten deutlich sehen, wenn dieser Beispielbefehl DBCC CHECKDBum ausgeführt wird21h45

Warum

Dieses Verhalten ist darauf zurückzuführen, dass der database snapshotdurch den DBCCBefehl erstellte Löschvorgang alle Objekte im Speicher entfernt.

Sie können das Verhalten replizieren, indem Sie einen Snapshot einer Datenbank erstellen, einige Daten in den Speicher laden und diesen Snapshot dann löschen

  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 vor dem Löschen des Snapshots

BufferSizeInMB
1061.70312  --before

Löschen des Schnappschusses

USE master
GO
DROP DATABASE MY_DATABASE_SNAPSHOT ; 

BufferSize nach dem Löschen des Snapshots

BufferSizeInMB
824.179687 --after

Die zweite Frage ist, warum sich die "Puffer-Cache-Trefferquote" nach Abschluss der DBCC-CheckDB nicht geändert hat.

Dies hängt davon ab, wie schnell die Daten wieder in Ihren Puffercache geladen werden.

Wenn sich Ihr Pufferpool über einen längeren Zeitraum füllt, sollte dieses Verhältnis im Durchschnitt höher bleiben.

Dies entspricht diesem Teil Ihrer Frage:

... Es ( Pufferpool-Datengröße ) wurde von 140 GB zwischengespeichertem DB-Speicher auf 60 GB gesenkt . und danach langsam wieder hoch während der Woche ...