MS SQL Serverのバージンクエリのパフォーマンスを向上させる方法は？
ASP.NET Webサイトで、独自の独立したデータキャッシングを行っており、データが長期間変更されないため、同じクエリでSQL Serverに2回クエリする必要はありません。そのSQL Serverへの初回（バージン）クエリのパフォーマンスを改善する必要があります。一部のクエリは、SQL Serverがtempdbを使用する原因となるほど大量のデータを処理します。一時テーブル変数や一時テーブルは使用しないので、SQL Serverは必要なときにいつでもtempdbを単独で使用することにしました。
私のデータベースサイズは16Gbですが、サーバーマシンで32Gbの物理RAMを使用できます。
MS SQL Serverのキャッシュ戦略は、同じデータを再度ロードする必要がある場合に、同様のクエリのパフォーマンスを高速化するためにRAMにデータを保持しようとすることを理解しています。さらに、tempdbの代わりに使用可能なRAMを使用して、ディスクアクセスを引き起こさずにパフォーマンスを高速化しようとします。
Tempdb SQL Serverに何かを格納する必要があるクエリが来て、十分なRAMが利用できない場合、SQL Serverには2つの選択肢があると思います。
1）キャッシュされたデータをアンロードし、tempdbの代わりにスペアのRAMを使用してディスクの書き込みを回避する
2）今後のクエリのためにキャッシュデータを保持し、tempdbの使用を開始します。これにより、ディスクへの書き込みが遅くなります。
この状況でSQL Serverがどのような選択をするかはわかりませんが、最初の（バージン）クエリのパフォーマンスのみに関心があるため、SQL Serverに同じクエリを再度送信することはないため、選択＃1を行いたいと思います。 （私は同様のクエリを送信することがあります）。
このシナリオのSQL Serverキャッシュ戦略は何ですか？
新しいクエリのtempdbの回避と2回目のクエリの速度の間でRAMの使用をどのようにバランスさせますか？
選択＃1を行うようにSQL Serverを構成することは可能ですか？はいの場合、どのように？
他にどのようにしてすべてのバージンSQLクエリのパフォーマンスを向上させることができますか？
SQL Serverのキャッシュ戦略がわからないので、RAMディスクにデータベースを配置します。これにより、SQL Serverが常に＃1を選択する場合でも、バージンクエリがキャッシュされていないデータを高速でロードできるようになります。 SQL Serverが選択肢＃2を選択し続けると、SQL Serverがより多くのtempdbをより少ないRAM（RAM Diskに16Gbを使用した後、残りは16Gbのみ）で使用し始める可能性があります。 tempdbへのスピルを引き起こす未使用のクエリを遅くします。
SQL 2008 R2のソリューションに興味がありますが、おそらくSQL 2008、SQL 2005でも同じであり、SQL 2000かもしれません。
説明：
そのボックスで実行されている他のアプリケーションはありません。それはSQL Server専用です。ウェブサイトは別のボックスで実行されます。
Windows Server 2008 R2 Enterprise 64ビット上のSQL Server 2008 R2 Standard Edition 64ビットです。
私は読み取り専用クエリのみを実行し、データベースはread-onlyに設定されています。
すでに適切なインデックスがあるであると仮定しましょう。この質問は、SQL Serverが選択肢＃1と選択肢＃2を作ること、それを制御する方法があり、RAM Diskがバージンクエリの正しい選択を行うのに役立つかどうかについてです。
あなたの質問は基本的に「クエリメモリ付与はどのように機能するのですか？」と言い換えることができます。この件に関する適切な資料は SQLサーバーのメモリ許可について です。クエリを実行する前に、クエリを実行しますmayソートとハッシュ、およびその他のメモリを大量に消費する操作のためのメモリ許可が必要です。このメモリ許可は見積もりです。現在のシステム状態（実行中および保留中の要求の数、使用可能なメモリなど）に基づいて、システムはクエリにメモリ許可を付与します最大必要な量。メモリが許可されると、クエリは実行を開始します（許可を取得する前に、恐ろしい「リソースセマフォ」キューで待機する必要がある場合があります）。実行時には、システムによってメモリが付与されます保証。このメモリ量は、データページと共有できます（常にディスクにフラッシュできるため）。ただし、他のメモリ使用量と共有することはできません（つまり、「スチール」することはできません）。したがって、クエリがその許可からコミットされたメモリを要求し始めると、エンジンは「戦略＃1」と呼ばれるものをデプロイします：データページmay削除される（ダーティの場合はフラッシュされる）クエリにクエリを提供する約束された記憶。見積もりが正しく、許可が要求されたメモリの100％であった場合、クエリは「スピル」しないはずです。ただし、見積もりが正しくなかった場合（カーディナリティの見積もりに要約されるため、古くなった統計の対象となります）orクエリが要求したすべての許可を得られなかった場合、クエリは「スピル」します。 tempdbが登場し、通常はパフォーマンスが向上する時期です。
このプロセスで何かを制御するあなたが自由に使える唯一のつまみは Resource Governor です。 RGは、プールの[〜＃〜] min [〜＃〜]設定を指定するために使用できるため、メモリの予約に使用できます特定のワークロードについてgetsそれが要求するメモリ許可。もちろん、メモリの付与が減少したことを示す適切な調査を行った後are原因であり、もちろんotherワークロードへの影響が評価されました。もちろん、テスト済みです。
では、元の質問に戻りましょう。あなたの調査が正しい場合（非常に大きな場合）、2つの問題を指摘したいと思います。
- web siteのメモリ許可を必要とする本番クエリで実行します。これは大きなノーノーです。メモリ許可は、HTTPリクエストを処理する場所がない分析クエリを示します。
- クエリはおそらく、要求するメモリ許可を取得するイベントではありません。繰り返しになりますが、Webサイトの場合と同様に、レイテンシが重要なワークロードの場合は、さらに多くの禁止事項があります。
つまり、それはあなたに根本的な設計と建築上の問題があるということです。 Webサイトはレイテンシ主導型で、OLTPのようなワークロードを作成します。メモリの付与はなく、クエリへのメモリの負荷もありません。流出は言うまでもありません。分析クエリはオフラインジョブで実行し、保存する必要があります。前処理された結果により、HTTPリクエストで必要になったときにすぐに利用可能.
言及していないのは、データベースに対して実行されるクエリの種類と、クエリのパフォーマンスを高速化する適切なインデックスがあるかどうかです。
同じボックスで他のアプリケーションが実行されているかどうかも確認する必要があります。ボックスには32 GBのRAMが搭載されていますが、データベースサーバーに最大メモリ設定を設定して、人為的な制限を設けていませんか。同じサーバー上で実行されているアプリがある場合、SQLと他のアプリがリソースを競合している可能性があり、SQLはメモリを大量に消費することに注意してください。
SQL Serverはtempdbを内部の並べ替え、ハッシュ結合/集計、またはスプールオペレーターなどに使用します。この動作を制御することはできません。できることは、返されるデータの量を制限することです。
このボックスの待機統計を確認しましたか？ SQL Serverがリソースを待機するたびに、SQL Serverは待機リソースを追跡し、その情報を確認するのに役立ちます。
Glenn Berryの診断クエリを見てください。これは良いスタートです。
http://weblogs.sqlteam.com/dang/archive/2009/06/27/Forced-Parameterization-A-Turbo-Button.aspx で述べられているように強制されるパラメータ化も見てください
この質問は現在、問題を探す解決策のようになっています。 RAMディスクが解決策であり、誰かにその選択を検証してもらいたいと思っています。申し訳ありませんが、起こりません。
Tempdbへの流出を測定して観察した場合は、ほとんどの場合、ソートまたはハッシュ操作とクエリメモリの不足が原因です。処理するデータの量によってはこれは避けられないかもしれませんが、それを回避するためにクエリやインデックス作成を改善する可能性は十分あります。
バッファ管理 を参照して、SQL Serverがメモリを管理する方法をよりよく理解し、 SQL Serverメモリ管理の説明 を見て、メモリが割り当てられている場所を理解するための基本的なツールとDMVクエリを確認してください。
他にどのようにしてすべてのバージンSQLクエリのパフォーマンスを向上させることができますか？
これは大きな話題です。クエリを投稿して計画を立てると、的を絞ったフィードバックが得られます。