La memoria cache del database in Performance Monitor si riduce in modo significativo dopo DBCC CheckDB


8

Abbiamo monitorato alcune SQLServer: Memory Managermetriche e abbiamo notato che dopo il DBCC CheckDBlavoro, la metrica

Database Cache Memory (KB)

scende in modo significativo. Per l'esattezza, è passato da 140 GB di memoria cache cache a 60 GB. E dopo di ciò, lentamente risalire di nuovo durante la settimana. (Importo di " Free Memory KB", passato da 20 a 100 GB subito dopo CheckDB)

DBCC CheckDB viene eseguito ogni domenica, quindi la memoria cache del database deve tornare di nuovo ogni settimana

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

La seconda domanda è perché " buffer cache hit ratio" non è cambiato dopo il DBCC CheckDBcompletamento?

Era in media del 99,99% e dopo il DBCC CheckDBlavoro scende a ~ 98,00%, e ritorna al 99% abbastanza velocemente mentre mi aspettavo che " buffer cache hit ratio" scendesse significativamente perché i dati del database devono essere letti nuovamente dalla memoria alla RAM?


Per quanto riguarda BCHR, il motivo per cui non è diminuito ulteriormente può essere dovuto al fatto che il codice CHECKDB potrebbe essere eseguito utilizzando read-ahead (RA) e l'I / O eseguito da RA non è incluso nel calcolo del BCHR. Che a sua volta rende BCHR un contatore di perf piuttosto inutile.
Tibor Karaszi,

Risposte:


9

Abbiamo monitorato alcuni SQL Server: le metriche di Memory Manager e abbiamo notato che dopo il processo DBCC CheckDB, la metrica

La memoria cache del database (KB) si riduce in modo significativo. Per l'esattezza, è passato da 140 GB di memoria cache cache a 60 GB

Questo è corretto, puoi vedere chiaramente questo comportamento quando questo DBCC CHECKDBcomando di esempio viene completato in21h45

inserisci qui la descrizione dell'immagine inserisci qui la descrizione dell'immagine


Perché

Questo comportamento è dovuto al fatto che il comando database snapshotcreato è DBCCstato eliminato, rimuovendo tutti i suoi oggetti in memoria.

È possibile replicare il comportamento creando un'istantanea di un database, caricando alcuni dati in memoria e quindi rilasciando tale istantanea

  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 prima di eliminare l'istantanea

BufferSizeInMB
1061.70312  --before

Eliminazione dell'istantanea

USE master
GO
DROP DATABASE MY_DATABASE_SNAPSHOT ; 

BufferDimensione dopo aver rilasciato l'istantanea

BufferSizeInMB
824.179687 --after

La seconda domanda è perché "hit rate cache buffer" non è cambiato dopo il completamento di DBCC CheckDB?

Ciò dipende dalla velocità con cui i dati vengono caricati nuovamente nella cache del buffer.

Se il pool di buffer si riempie per un periodo di tempo più lungo, dovrebbe corrispondere a questo rapporto rimanendo in media più elevato.

Ciò corrisponde a questa parte della tua domanda:

... ( dimensione dei dati del pool di buffer ) è passato da 140 GB di memoria cache cache a 60 GB. e dopo, lentamente ritorna di nuovo durante la settimana ...


grazie Randi! quando parliamo di Snapshot del database interno realizzato da DBCC CheckDB, lo sta creando in memoria? o su disco? o entrambi
Aleksey Vitsko il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.