プロシージャキャッシュヒット率が95％未満であると私が知ることができることは問題です。私のボックスでは、値は85から95％に移動します。
この問題を解決するにはどうすればよいですか？サーバーには十分なRAMがあるようですので、問題にはなりません。他に何ができますか？
回答:
スプレッドシートの重要なデータポイントをまとめます（そして丸めます）。
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527したがって、最初の行は、計画のキャッシュの約2/3を占める、悪いものを示しています（ほとんどの場合、一度だけ使用されるもので、いくつかの非常に小さな例外があります）。あなたはできる限りこれらの多くを取り除くようにする必要があります。2行目は良いものを示しています。これらは、プランキャッシュ（大量の再利用を伴うプラン）に必要なものです。残りのデータは、主にIMHOとは無関係です。もう1つのポイント：アクセスはストアドプロシージャを介してのみ行われると言いますが、それらのプロシージャが動的SQLを使用する場合、それらのステートメントはAdHocプランではなくProcプランとしてキャッシュされます。
2008年以降は、電源を入れoptimize for ad hoc workloadsて次の問題に移ります。これは、使い捨てプランが現在占有しているMBの量を、ほとんど何もないところまで減らします。残念ながら、2005年、あなたのオプションは、かなりの使用文レベルにこれらのストアドプロシージャのリファクタリングとは別に、限定されているOPTION (RECOMPILE)および/または以下/なし動的SQLを、またはオンにデータベースレベルで強制パラメータのうち、より良いプランの再利用を取得しようとします-リテラルをプランマッチングの目的でパラメーターとして扱うことによる同様のクエリ。計画ガイドは臆病者向けではないため、言及することをためらいます。この回答の後半で説明するように、計画キャッシュが確実にパフォーマンスのソースであることがわかっている場合を除いて、その道を進む価値があるかどうかはわかりません。問題。
私が質問し@@VERSIONたのは、SP2以前は、プランキャッシュに割り当てることができるメモリ量のアルゴリズムが比較的緩やかだったためです。SP2以降、彼らはそれをかなり厳しくしました（変更はこの投稿とこの投稿で文書化され、説明されています）。あなたの場合、プランのキャッシュは比較的いっぱいなので、キャッシュミスが発生するのは当然のことです。26 GB = 5.8 GBの上限。スプレッドシートに約4.5 GBが表示されますが、ここでは、知らない計算または構成の違いがある可能性があります。
このMSDNの記事ではoptimize for ad hoc workloads、2008年に追加されたサーバー設定について説明し、さらに多くのメモリをキャッシュに割り当てることができるトレースフラグ8032について言及しています（おそらくサーバーレベルでこの設定を設定していない場合、これをすべてのユーザーに推奨します）顧客、または少なくとも2005年には存在しない99％）。私はこのトレースフラグを2005 SP3またはSP4でテストしたことはありません。正直なところ、いつ導入されたのかさえわかりません。それがあなたの問題を解決するのか、それをシフトするだけなのかもわかりません。キャッシュに割り当てられているRAMが％増えていたとしても、それが満たされ、キャッシュミスが多いため、ストアドプロシージャ。
または、もちろん、解決すべき問題さえある場合、それはプランキャッシュに直接関係します。キャッシュヒット率が予想よりも高くないからといって、それが問題の原因であるとは限りません。もちろん、キャッシュヒット率が100％であっても、キャッシュヒット率は現実的ではないようです。計画の1つは使い捨てでアドホックです。ユーザーは、何か他のものによって引き起こされるパフォーマンスの問題に完全に苦しんでいる可能性があります。
私の提案は、計画のキャッシュヒット率よりも優れた喫煙銃を探すことです。ユーザーのパフォーマンスに関する苦情の詳細を確認します。すべてのクエリは常に遅いですか？特定のクエリ？1日の特定の時間/週/ビジネスサイクル？レポートのクエリだけが遅いですか？SQL Serverのベストプラクティス、特に待機とキューに関するセクションについて、この明らかに乾いた長いドキュメントを真剣に読んでください。これは、パフォーマンスの問題を特定、診断、解決するための論理的なアプローチを策定するのに役立ちます。ダッシュボードのいくつかの数字をより見栄えよくする-あなたが直接知らない数字が問題に寄与している-は非常に満足できるかもしれませんが、それがユーザーのパフォーマンスの問題を解決しない場合、それは本当にあなたを獲得していませんどこでも。
これらは、コンパイル/再コンパイルおよびプランキャッシュの再利用について読む際にも役立ちます。これらのいくつかは2008（特にアドホックワークロードの設定に関するもの）に焦点を当てていますが、情報の多くは2005年や、アップグレードのヒント（ヒント、ヒント）をよりよく理解するために依然として役立ちます。