バッファキャッシュ：それは何であり、データベースのパフォーマンスにどのように影響しますか？

SQL Serverでは、バッファキャッシュは、頻繁にアクセスされるデータをすばやくクエリできるようにするメモリです。データがSQLServerデータベースに書き込まれるか、SQL Serverデータベースから読み取られると、バッファーマネージャーはそのデータをバッファーキャッシュ（別名バッファープール）にコピーします。いっぱいになると、古いデータページや使用頻度の低いデータページがハードディスクに移動されます。

バッファキャッシュを監視する必要があるのはなぜですか？

メモリの使用は、パフォーマンスに大きな影響を与える可能性があります。メモリが不足している場合、データページはバッファキャッシュから頻繁にパージされます。これにより、SQL Serverはデータページを見つけるためにディスクに移動し、データページをバッファキャッシュに復元してから、クエリ結果を返す前にページを読み取る必要があるため、クエリの速度が低下します。

クエリの実行が遅くなる理由はたくさんあります。ただし、メモリの問題を除外したい場合は、バッファキャッシュ内で何が起こっているかを確認してください。その中を覗くと、どのデータベース、テーブル、またはインデックスがメモリを占有し、バッファに圧力をかけているのかがわかります。

どのデータベースが最も多くのメモリを消費しているかを確認するには、次のクエリを使用します：

SELECT
CASE database_id
WHEN 32767 THEN 'ResourceDb'
ELSE db_name(database_id)
END AS database_name, COUNT(1)/128 AS megabytes_in_cache
FROM sys.dm_os_buffer_descriptors
GROUP BY DB_NAME(database_id) ,database_id
ORDER BY megabytes_in_cache DESC;

最も多くのメモリを消費するテーブルまたはインデックスを特定するには、検査するデータベースで次のクエリを実行します。

SELECT COUNT(1)/128 AS megabytes_in_cache
,name ,index_id
FROM sys.dm_os_buffer_descriptors AS bd
INNER JOIN
(
SELECT object_name(object_id) AS name
,index_id ,allocation_unit_id
FROM sys.allocation_units AS au
INNER JOIN sys.partitions AS p
ON au.container_id = p.hobt_id
AND (au.type = 1 OR au.type = 3)
UNION ALL
SELECT object_name(object_id) AS name
,index_id, allocation_unit_id
FROM sys.allocation_units AS au
INNER JOIN sys.partitions AS p
ON au.container_id = p.partition_id
AND au.type = 2
) AS obj
ON bd.allocation_unit_id = obj.allocation_unit_id
WHERE database_id = DB_ID()
GROUP BY name, index_id
ORDER BY megabytes_in_cache DESC;

メトリックを使用してメモリを管理する

データベースとインデックスのメモリの過剰使用をスポットチェックすることは役立ちますが、バッファキャッシュの指標を追跡することは、メモリへの内部圧力によって引き起こされるパフォーマンスの問題を特定して解決するための最良の方法です。

メモリ関連のパフォーマンスの問題を改善するために監視する上位5つの指標は次のとおりです。

1。バッファキャッシュヒット率

このメトリックは、SQLServerがバッファキャッシュをどのように利用するかを示します
ヒット率は、すべてのデータページリクエストに対する、バッファキャッシュからのデータページによって完了されたページリクエストの割合を識別します
バッファキャッシュにないページはディスクから読み取られますが、これははるかに低速です
理想的なバッファキャッシュの比率は100です（つまり、SQL Serverはバッファキャッシュからすべてのページを読み取り、ディスクからは読み取りません）
推奨されるバッファキャッシュ値は90を超えています

2。ページの平均余命（PLE）

ページの平均余命は、データページがバッファキャッシュにとどまる時間（秒単位）を測定します
PLEが長いほど、SQL Serverがバッファキャッシュからページを読み取り、ディスクに移動する必要がなくなる可能性が高くなります。
十分なメモリがない場合は、データページがバッファキャッシュからより頻繁にフラッシュされ、新しいページ用のスペースが解放されます。
これまで、システムのメモリが現在よりもはるかに少ない場合、「通常の」PLE値は300秒でした
現在、「適切な」PLEを決定するために数式が使用されています。ページの平均余命=サーバー上の4GBのRAMごとに300秒
長期にわたって監視する場合、PLEは安定した状態を維持する必要があります
速く頻繁に減少する場合は、メモリに問題があることを示しています
50％を超える低下は、すぐに調査する必要があります

3。ページ読み取り/秒（サーバーレベル）

このメトリックは、インスタンス上のすべてのデータベースで1秒間に発生した物理読み取り（つまり、ディスクからの読み取り）の数を示します
物理的な読み取りは高価で時間がかかります
より大きなデータキャッシュ、インテリジェントインデックス、より効率的なクエリを使用するか、データベースの設計を変更することで、物理的な読み取りを減らします
推奨値は90未満です
90より大きい値は、メモリ不足とインデックス作成の問題を示します

4。ページ書き込み/秒

この指標は、サーバーレベルで1秒間にページがディスクに書き込まれた回数を示します
推奨値は90未満です

5。ページ入力/秒およびページ出力/秒（メモリカウンター）

ページ入力/秒は、ディスクから1秒あたりに取り込まれるページ数です
ページ出力/秒は、バッファキャッシュに空きを作るためにディスクに毎秒書き込まれるページ数です
ページ/秒は、ページ入力/秒とページ出力/秒の合計です
ページ/秒の値が常に50を超える場合は、追加の調査が必要です

正常なバッファキャッシュは、SQLServerのクエリ速度を最適化するための重要なコンポーネントです。メモリの問題は、クエリの応答を遅くする可能性のあるいくつかの要因の1つにすぎませんが、識別と解決はかなり簡単です。これらの5つの主要な指標を追跡することで、データページをバッファプールに長く保持できるため、SQLServerがクエリ結果を返す前にディスクの検索に時間を費やす必要がなくなります。