...何が実行されるべきかについての大まかな大まかな見積もりが得られることを期待していました。
クエリとデータサイズに関する詳細な情報がないと、正確な見積もりはもちろん、あらゆる種類の見積もりを行うことは非常に困難です。
データベース：SQL Server 2008 R2エンタープライズデータベース
Windows：Windows 2008 r2 Enterprise 64ビット、VMwareで実行していることを確認してください。
プロセッサー：Intel（R）Xeon（R）CPU E7-4860 @ 2.27GHz 2.26 GHz（2プロセッサー）
搭載メモリ：4GB
2つのプロセッサ（これはVMで2つのコアとして公開されていると想定しています）は、十分にプロビジョニングされていない場合があります。VMに割り当てられたコアは、必ずしも物理コアに直接マッピングされるとは限りません（または、必要に応じてシングルコアの100％を使用することもできます！）。これは、メモリよりも柔軟なリソースである場合があります。ワークロードまたはハードウェア/仮想化構成に関する情報がこれ以上ない場合、これを4に増やすと便利です。
メモリ割り当て。ああ少年。これは、ワークロードに対して大幅にプロビジョニングされていません。Windows自体は、最低限2〜3 GBが必要です。ボックス上でBIDSを実行する2人のユーザーはそれぞれ、少なくとも500 MBを必要とします。それで、ボックスはすでに限界に達しており、データベースがどれだけの量を必要とするかを考え出すことすらできませんでした。
ユーザーの大半は、asp.net WebサイトおよびレポートサーバーWebサイトを介してデータベースと対話します。
言わなかったが、これらが同じボックスで実行されている場合、それらのメモリ要件も考慮する必要がある。
最後に、かなり複雑なデータウェアハウジング操作があり、サーバーでも実行されるSSISパッケージを介して、おそらく1日あたり300万件のレコードを取り込みます。
これがシステムにライブユーザーがいない夜に実行されると仮定すると、実行に時間がかかりすぎない限り、これは問題とは見なされません。物事のこの部分はあなたの心配の中で最も少ないです。ライブユーザーの方が重要です。
以前の追加メモリの要求は、より多くのクエリ最適化を実行する必要があるという一般的な応答で拒否されました。
上記で示したように、プロビジョニングされている現在のメモリ容量は完全に不十分です。しかし同時に、スペクトルの反対側では、データベース全体を一度にメモリ内に保持するために十分なメモリをプロビジョニングできる可能性はほとんどありません。
そのような包括的な応答が得られたとしても（実際には、実際のリソースの使用自体ではなく、追加のリソースの正当化の説得力にもっと関係している可能性があります）、データベースの効率が高い可能性があります改善されました。それでも、現在発生している問題を修正できる調整だけでは十分ではありません。それの提案は私にとって完全な出発点ではありません。
私は現在プロビジョニングされたメモリの量は、（できるだけ早く修正されなければならない）が必要最小値を下回っていることを全体的なアプローチを取る、追加のリソースが使用可能なレベルにユーザー体験を向上させるために必要とされてもよいしながら改良が効率を上げるために行われますシステム。
ここにいくつかの考えがあります（攻撃の順序で）：
あなたはなり勝ち、あなたがプロビジョニングされた多くのリソースを取得するたびに改善し、どのくらいの性能を証明することができます。可能な場合はWebサイトの応答時間を含め、パフォーマンスモニターのログを使用してパフォーマンスメトリックを追跡します（注：ログの部分は非常に重要です）。他のことをする前に、今すぐ始めてください。最終的に最小メモリ量に到達すると（すぐに32 GBを取得する予定はありません）、突然、メモリを追加することで状況が改善されたという証拠があります。現在の構成のベースラインを収集しないと、物事が最小推奨レベルに達したときにボートに乗り遅れることになります。
サーバーの待機統計を分析します。これにより、システムの最大のボトルネックがわかります。おそらくPAGEIOLATCH_XX、最も一般的/最長の待機時間が発生します。これは、ディスクからページをフェッチするために実行されているI / Oが多すぎることを示しています。これはメモリを追加することで軽減できます。必要なデータがすでにメモリにあるため、物理I / Oの頻度は少なくなります。この分析はほぼ完全な結論ですが、これらの統計を収集したという事実は、リソースの必要性を正当化するときに弾薬をより多く提供します。
上で述べたように、メモリの最低限の要件が満たされていません。実行しているすべてのソフトウェアの推奨ハードウェア要件のセットを収集し、タスクマネージャーのスクリーンショットも取得します。これだけでも、その場で少なくとも4〜8 GB以上を正当化するには十分です。それでも拒否される場合は、1週間試してもらい、その後で返却できるように説得してください（パフォーマンス統計を収集しているため、週の半ばに返却する必要はありません）状況がどれだけ改善されたかを証明することができます）。彼らは場合は、まだ拒否し、あなたは失敗するように設定されています。URLT。
ワークロードの一部をオフロードできる場合（特に、可能な場合はリモート処理を回避する）、これにより、データベースで使用可能なメモリの量が増加します。これは、より重要です。
あなたがすることは非常に慎重にSQL Serverの最大メモリ設定を設定する必要があることを意味する、一度にメモリにデータベース全体をフィットすることができませんオーバーコミットメモリを防ぐようにパフォーマンスを殺す、何もありません。オーバーコミットは実際には、単にすべてのデータをメモリに収められないよりもさらに悪いものです。利用可能なメモリがまったくないという理由だけでこのシナリオにいる可能性が非常に高く、最大メモリ設定がデフォルト（無制限）に設定されている可能性があります。
SQL Server Enterprise Editionを実行していて、メモリが限られているため、データ圧縮の実装を強く検討します。これにより、CPU使用量の増加とメモリのスペース節約とがトレードオフされます（したがって、比較的非常に遅いディスクアクセスが削減されます）。
データベースを調整します。構造とクエリは、インデックス作成とアクセスパターンに関する限り、改善を使用できる可能性があります。また、大量のデータが頻繁にスキャンおよび集計される場合は、インデックス付きビュー、サマリーテーブル、または事前計算済みレポートを作成すると非常に役立ちます。
これはおそらくハードウェアのプロビジョニングを増やすことになるが、キャッシングソリューションを実装することになるため、長い道のりになるかもしれません。最速のクエリは、決して作成したものではありません。
これらはほんの一部のアイデアです。結論としては、チューニングだけではここでの問題は解決されず、ハードウェアだけでも、おそらく当面の問題の大部分は緩和されます。それが実際の方法です。短期間に問題にハードウェアを投入して火を消し、根本的な原因をできる限り修正するために長期的に問題にチューニングを投入します。