バッファの問題をデバッグするにはどうすればよいですか？
「Microsoft SQL Server 2012（SP1）-11.0.3128.0（X64）」という本番環境で、奇妙なバッファとページの平均余命（PLE）の症状が出ています。
私はサーバーでこれを毎分実行しています（この問題を追跡するため）：
SELECT @ple = CAST([cntr_value] AS VARCHAR(20))
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Manager%'
AND [counter_name] = 'Page life expectancy'
SELECT @usedBufferPages = CAST(COUNT(*) /128 AS VARCHAR(20))
FROM sys.dm_os_buffer_descriptors
DECLARE @StartDate VARCHAR(8) = Convert(VARCHAR(8), GETDATE(), 14)
RAISERROR ('%s. PLE at %s and Used Buffers at %s at %s ', 0,
1,@runCountString ,@ple, @usedBufferPages, @StartDate) WITH NOWAIT
これはいくつかの出力例です：
16。 PLEは858、使用済みバッファは7290で09:51:42 17。 PLEが918で、使用済みバッファーが7342が09:52:42 18です。 978のPLEおよび09:53:43の7408の使用済みバッファ 19。 PLEが1039、使用済みバッファーが7547が09:54:43 20。 1100のPLEおよび09:55:44の7697の使用済みバッファ 21。 1160のPLEおよび09:56:45の7901の使用済みバッファ 22。 1221のPLEおよび09:57:46の7961の使用済みバッファ 23。 1282でのPLEおよび09:58:46での8012での使用済みバッファ 24。 11時のPLEおよび09:59:46の313時の使用済みバッファ 25。 31時のPLEと10:00:46時の966の使用済みバッファ 26。 90でのPLEおよび10:01:47での1580での使用済みバッファ 27。 PLEが151、使用済みバッファーが3072が10:02:47 28。 211でのPLEおよび10:03:47での3152での使用済みバッファ 29。 271のPLEおよび10:04:47の3729の使用済みバッファ
項目＃24で、SQL ServerはPLEが1,282から11に変化することを報告します。 SQL Serverは、使用されたバッファが8,012から313までであることも報告します。
最初に、実行中のクエリを探しましたが、いくつか修正されました（問題に影響はありませんでした）。しかし、PLE/Bufferの問題が発生している時間に関連する問題のクエリは見つかりません。また、実行中のクエリが適切でなかった場合、バッファはそのクエリのデータでいっぱいになると思います。空/欠落/エラーではありません。
次に、これが発生したときに仮想マシンのメモリが制限されていると思いました。しかし、私は私のシステム管理者に尋ねたところ、彼はメモリが動的ではなく、何らかの方法で共有されていないことを保証してくれました。 （割り当てられているものは常に取得されます。）また、このスクリプトは10分ごとに実行され、PLEのレポートが50未満の場合は次のようになります。
SELECT * FROM sys.dm_os_sys_memory
そして、PLE/Buffersが高い場合と低い場合に同じ/類似の値を報告します。完全を期すために、上記の＃24の前後の値の例を次に示します。
【.____。】total_physical_memory_kb available_physical_memory_kb total_page_file_kb available_page_file_kb system_cache_kb kernel_paged_pool_kb kernel_nonpaged_pool_kb system_high_memory_signal_state system_low_memory_signal_state system_memory_state_desc [.____。】20970996 4758672 24378868 7929404 4844160 686076 182752 1 0使用可能な物理メモリが[.____。】高い20970996 24378868 4743468 7892632 4845000 686580 182688 1 0使用可能な物理メモリが多い
システムヘルスセッションを確認しましたが、関連するものは何も表示されません。 （それはすべて、なりすましの悪魔であり、それらの時間はPLE /バッファが問題を示す時間と相関していません。
これが発生する頻度を追跡しましたが、パターンが表示されないか、ジョブまたはスケジュールされたアクティビティに接続できません。
21時間にわたるPLEとバッファを示すグラフは次のとおりです。
だから私は困惑しています。問題の核心はPLEではなくバッファにあると思います。 （すべてのバッファがどういうわけかなくなっているので、PLEは低の誤ったレポートを受け取っていると思います。）
しかし、私はこれが起こり得る方法を考えることはできません。または次に何をすべきか。
チェックすべき追加事項に関するアドバイスや、この問題が何であるかについての提案が欲しいです。
コメント内の質問からの更新：
それで、サーバーにはどのくらいのメモリが与えられていますか？VMには20 GBのメモリがあります。
最大サーバーメモリとは何ですか？
name value value_in_use description max server memory（MB）13000 13000 maximum size of server memory（MB） min server memory（MB）0 16 minimum size of server memory（MB ）
注：私はこれについて少し読んだところ、これらの設定は私のサーバーでは間違っているようです。
データベースのサイズはどれくらいですか？このサーバーでは2つのトランザクションデータベースが実行されています（サーバーを分離するための処理を行っています）。サイズは383 GBと378 GBです。
そのサーバーで他にどのようなアプリケーションとサービスが実行されていますか？このサーバーは私のアプリケーションのデータをホストします。それを打つ他のものはありません。 （レポートなどの複製されたオペレーショナルデータストアがあります。
VM technologyVM Ware。
これはVM同様のリソース割り当てを持つVMのみをホストするホスト上で実行されていますか？弊社には多くのVMがあります。サイズはさまざまですが、これは最大のものの1つです。
システム管理者がメモリ割り当てについて何を言っているかを、彼を信じるだけで確認できますか？わかりません。これらのツールにアクセスできません。
（私の経験では、システム管理者は、何もする必要がないことを意味する場合、金銭を渡してアプリや他の人を責めるために多くのことを言うでしょう）私その感情を完全に理解できます。
そのパターンは確かに厳しいメモリプレッシャーのように見えます私は同意します。 SQLがメモリのプレッシャーを感じていることを証明するものを見つけたいと思っていました。そのため、システム管理者に送り返してさらに調査することができます。
待機時間統計
WaitType Wait_S Resource_S Signal_S WaitCount Percentage AvgWait_S AvgRes_S AvgSig_S ---------------------- --------- ------------ --------- ---------- ------------ ------ ---- --------- --------- PAGEIOLATCH_SH 16250.10 16219.14 30.96 2171649 29.59 0.0075 0.0075 0.0000 CXPACKET 14214.03 13238.56 975.47 1187935 25.88 0.0120 0.0111 0.0008 PAGEIOLATCH_EX 6814.59 6806.21 8.38 638725 12.41 0.0107 0.0107 0.0000 WRITELOG 5157.42 4873.44 283.98 3588476 9.39 0.0014 0.0014 0.0001 BACKUPIO 2569.51 2538.12 31.39 1704119 4.68.10_CK_IX_15_15_15_L_15_15_15_15_15_15_15_15_15_15_15_15_15_15_15_15_15_15_15_15 ____ 15 0.05 113 4.51 21.9217 21.9213 0.0004 ASYNC_IO_COMPLETION 2079.99 2079。 66 0.33 836 3.79 2.4880 2.4876 0.0004 BACKUPBUFFER 1807.75 1759.11 48.64 380189 3.29 0.0048 0.0046 0.0001 IO_COMPLETION 986.23 985.84 0.39 116112 1.80 0.0085 0.0085 0.0000
このSEスレッド で議論され、OPによって確認されました。
この問題はSQl Server 2012のバグが原因です。このバグは SQL Server 2012 SP1 CU4 で修正されました。または、より安全にするには、CU4を使用する代わりに SQL Server 2012 SP2 を適用することをお勧めします。
Microsoftバグ修正の詳細に従って
SQL Server 2012でパフォーマンスが低下することがあります。SQLServerパフォーマンスモニターツールを確認すると、次のように表示されます。
•SQLServer：Buffer Manager\Pageの平均余命パフォーマンスカウンター値の急激な減少。この問題が発生すると、カウンターは0に近くなります。
あなたのバッファプールは13GBのみであり、データベースは383 GBと378 GBであり、これらはOLTP-頻繁に実行される小さなトランザクションです。
上記の状況は、私が想像する必要がある場合、以下のようになります：
（出典：Googleフォト）
SQL Serverが情報を格納する方法を理解する必要があります。
SQL Serverは、メモリキャッシュと呼ばれる構造でメモリに情報を格納します。 キャッシュ内の情報は、データ、インデックスエントリ、コンパイルされたプロシージャプラン、およびその他のさまざまな種類のSQL Server情報です。情報の再作成を回避するために、情報はメモリキャッシュとして保持されます。可能な限り古すぎて役に立たない場合、または新しい情報のためにメモリ領域が必要な場合、通常はキャッシュから削除されます。古い情報を削除するプロセスは、メモリスイープと呼ばれます。メモリスイープは頻繁なアクティビティですが、継続的ではありません。
データベースサイズの膨大な量と不十分なバッファプールが原因で、メモリ不足が発生するのは確実です。 - たとえば、理想的なメモリを決定する方法]を参照してください
収集 待機統計 および 無駄なバッファプールメモリから発生するパフォーマンスの問題を確認
推奨：
サーバーインスタンスにメモリを追加し、適切なメモリを使用して、異なるVM上の2つのデータベースを分離します。
ここでデバッグすることはほとんどありません。メモリを追加するか、データベースを複数のVMに論理的に分割するか、限られたメモリで行う必要があるシャッフルがパフォーマンスの問題と揮発性のPLEにつながることを理解する必要があります。 800 GBのデータを13 GBのメモリに収めようとすることは、バックパックに収納しようとするようなものです。
実行中のクエリをよく見てください。データベースのメモリ使用量だけでは、通常、測定基準を粗くして改善することはできません。クエリ（ブラックボックスアプリケーション）に影響を与えることができないと仮定しても、メモリ使用量に影響しているものを理解することには価値があります。たとえば、バッチプロセスでは、大規模なテーブルのすべてのデータをクエリすることにより、1回のヒットですべてのバッファ領域を使用する場合があります。
特に、テーブル全体をスキャンする原因となる欠落しているインデックスを探します。これらは、サーバー上のキャッシュを効果的にフラッシュできるためです。
SQL Serverには、リアルタイムで監視できる優れたアナライザーツールのセットがあり、調べてみると何かが痛いのではないかと思います。
データベーススキーマを変更することをお勧めしているわけではありませんが、注意しなければならないことの1つは、過度に大きなvarcharフィールドです。これらのフィールドは、大規模なデータベースのキャッシュスペースを実際に消費する可能性があります。