web-dev-qa-db-ja.com

DBCC CheckDBの後にパフォーマンスモニターのデータベースキャッシュメモリが大幅に低下する

私たちはいくつかのSQLServer: Memory Managerのメトリックを監視しており、DBCC CheckDBジョブの後、メトリックが

Database Cache Memory (KB)

大幅に低下します。正確には、140 GBのキャッシュDBメモリから60 GBに減少しました。その後、平日に再びゆっくりと上昇します。 （「Free Memory KB」の量は、CheckDBの直後に20 GBから100 GBになりました）

DBCC CheckDBは毎週日曜日に実行されるため、データベースキャッシュメモリは毎週再び増加する必要があります

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

2番目の質問は、buffer cache hit ratioの完了後に「DBCC CheckDB」が変更されなかった理由です。

それは平均で99.99％でしたが、DBCC CheckDBジョブの後、それは〜98.00％に低下し、データベースデータを読み取る必要があるため、 "buffer cache hit ratio"が大幅に低下すると予想していたのにかなり速く99％に戻りました。 RAMに再度保存しますか？

sql-serversql-server-2017dbcc-checkdbbuffer-poolperformance-monitor
8
Aleksey Vitsko

一部のSQLServer：Memory Managerのメトリックを監視しており、DBCC CheckDBジョブの後、メトリックが

データベースキャッシュメモリ（KB）が大幅に低下します。正確には、140 GBのキャッシュされたDBメモリから60 GBに減少しました

これは正しいです。この例のDBCC CHECKDBコマンドが21h45で完了すると、この動作がはっきりとわかります。

enter image description hereenter image description here

なぜ

この動作は、DBCCコマンドによって作成されたdatabase snapshotが削除され、メモリ内のオブジェクトがすべて削除されるためです。

データベースのスナップショットを作成し、一部のデータをメモリにロードして、そのスナップショットを削除することで、動作を再現できます

  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;

スナップショットを削除する前のバッファサイズ

BufferSizeInMB
1061.70312  --before

スナップショットの削除

USE master
GO
DROP DATABASE MY_DATABASE_SNAPSHOT ;

スナップショットをドロップした後のBufferSize

BufferSizeInMB
824.179687 --after

2番目の質問は、DBCC CheckDBの完了後に「バッファキャッシュヒット率」が変化しなかった理由です。

これは、データがバッファキャッシュにロードされる速度に依存します。

バッファープールが長時間にわたって満杯になる場合は、平均してこの比率にとどまるはずです。

これはあなたの質問のこの部分に対応します：

... It（Buffer pool datasize）は、140 GBのキャッシュされたDBメモリから60 GBに低下しました。その後、平日に再びゆっくりと上昇します...

9
Randi Vertongen