RESOURCE_SEMAPHOREおよびRESOURCE_SEMAPHORE_QUERY_COMPILEの待機タイプを解決する方法

以下の構成のサーバーでホストされている、サイズ300 GBのデータベースの1つからデータをヒット/フェッチする、実行速度の遅いSQLサーバークエリの根本原因を突き止めようとしています。

Windows Server 2003 R2、SP2、Enterprise Edition、16 GB RAM、12 CPU's 32ビット

SQL Server 2005、SP4、Enterprise Edition、32ビット。

64ビットへのアップグレードについては既に1か月以上かかるとの情報を提供しています。

しかし、現在の問題では、メモリのプレッシャーを解決できるか、最終的にRAMを増やすという結論に達することができる場合、データを収集しようとしています。

完了したアクション：このデータベースでは、インデックスの再作成と統計の更新が適切です。

以下に示すように、過去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_grantsDMV から収集された詳細情報です。

したがって、上記の情報が収集され、SP_Blitzデータごとにリソースセマフォが問題のようです。

リソースセマフォIDに割り当てられたメモリ 'target_memory_kb'は、使用可能な16 GB RAMと比較して低すぎますか。

注* 8時間の分析ごとに 'target_memory_kb'を実行すると、使用可能な16 GBと比較して常に1 GB未満になりますか？

ここで問題になる可能性のあるものと解決方法は、提案してください

ありがとう

ああ、良かった、ここに悪いニュースがある。

32ビットOSでは、SQL Serverはクエリワークスペースなどに最初の4GBのメモリのみを使用します。（そして、それはその4GBのためにOSと戦っています-他の実行中のアプリもそのメモリを奪い合います。）

4GBは多くのように聞こえるかもしれませんが、実行するために数GBのメモリを必要とするクエリを書くのは比較的簡単です。クエリが十分なメモリを必要とする場合、クエリを開始するためにクエリが十分なメモリを取得できないため、SQL ServerはRESOURCE_SEMAPHORE待機をスローします。RESOURCE_SEMAPHORE_QUERY_COMPILEは、実行計画をコンパイルするのに十分なメモリを取得することさえできないことを意味します-そして、それはかなり悪いことです。

それでは、どうやって修正しますか？

• 64ビットOSに切り替えます（実行しているOSはとにかくサポート対象外です）
• SQL Serverの64ビットビルドに切り替える
• サーバーのメモリ要求を減らします（このボックスで他のアプリを実行しないでください。これは、4GBに制限されているため、32ビットボックスでは特に重要です）
• AWE / PAEスイッチでより多くのメモリを使用します-ただし、SQL Serverはクエリワークスペースに最初の4GBしか使用できないため、RESOURCE_SEMAPHORE待機では機能しません。
• 必要なメモリが少なくなるようにクエリとインデックスを調整します

32ビットの問題はひどく、古いバージョンのSQL Serverでは本当に難しいので、最後の1つを言うことをためらいます。現在のプランを使用している場合は、プランキャッシュを調べ、クエリをメモリ許可によってソートし、最大の許可受信者を見つけて、それらを調整できます。ただし、この古いアンティークのオプションではありません。