以下の構成のサーバーでホストされている、サイズが300 GBのデータベースの1つからデータをヒット/フェッチする、実行速度の遅いSQLサーバークエリの根本的な原因を解明しようとしています。
Windows Server 2003 R2、SP2、Enterprise Edition、16 GB RAM、12 CPU 32ビット
SQL Server 2005、SP4、Enterprise Edition、32ビット。
1か月以上かかる64ビットへのアップグレードについては、すでにお知らせしています。
しかし、現在の問題については、メモリプレッシャーを解決できるか、最終的にRAMを増やすという結論に達した場合に、データを収集しようとしています。
完了したアクション:インデックスの再作成と統計の更新は、このDBに適切です。
以下に示すように、ロード時間中に実行された過去5日間のセマフォのwaittypeに気づきました。
以下のクエリの後のいくつかの情報:バッファーのサイズ= 137272
SELECT SUM(virtual_memory_committed_kb)
FROM sys.dm_os_memory_clerks
WHERE type='MEMORYCLERK_SQLBUFFERPOOL'
およびセマフォメモリ=クエリごとに644024
SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores
以下は、dm_exec_query_resource_semaphores
およびsys.dm_exec_query_memory_grants
dmv
したがって、上記の情報が収集され、SP_Blitzデータごとにリソースセマフォが問題のようです。
メモリ 'target_memory_kb'に割り当てられているリソースセマフォIDは、16 GBと比較して低すぎますかRAM利用可能です。
注* 8時間実行の分析ごとに、「target_memory_kb」は常に1 GB未満ですが、16 GBが利用可能ですか?
ここで問題になる可能性があるものと解決方法、提案してください
ありがとう
ああ、良かった。ここに悪い知らせがある。
32ビットOSでは、SQL Serverは最初の4 GBのメモリのみをクエリワークスペースなどに使用します。 (そして、それはその4GBのOSとも戦っています-他の実行中のアプリもそのメモリをめぐって競合します。)
4GBのように聞こえるかもしれませんが、実行するために数GBのメモリを必要とするクエリを書くのは比較的簡単です。クエリが十分なメモリを要求すると、SQL ServerはRESOURCE_SEMAPHORE待機をスローします。これは、クエリを開始するために十分なメモリを取得できないためです。 RESOURCE_SEMAPHORE_QUERY_COMPILEは、実行プランをコンパイルするのに十分なメモリを取得することさえできないことを意味します-ええ、それはかなり悪いです。
それでは、どのように修正しますか?
32ビットの問題はひどいので、SQL Serverの古いバージョンでは本当に難しいので、最後の1つを言うのもためらいます。現在のものを使用している場合は、プランのキャッシュを調べ、クエリをメモリの付与によって並べ替え、許可の最大の受信者を見つけ、それらを調整できます。ただし、この古いアンティークのオプションではありません。