SQL Server 2008 R2の一般的なメモリ要件
私はDBAの仕事の経験はありませんが、SQLサーバーに追加のリソースを要求するためのケースを作ろうとしているので、何人かが実行すべき大まかな概算を提供してくれる賢い人たちに連絡してもらいたいと思っていました。 ITが本番SQLサーバーに割り当てたリソースの割り当てが少ないのではないかと思います。
ハードウェアとソフトウェア：
データベース：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
データベースファイル用ハードドライブ：300 GB
バックアップ用ハードドライブ：150GB
ログ用ハードドライブ：100GB
応用：
合計で約170GBのデータを追加する3つのメインデータベースと、同じサーバー上にあるReporting Servicesデータベース（SSRS）があり、毎日生成される10個の異なるレポート（それぞれ平均70万件のレコードを含む）を格納しています。私たちのユーザーベースは約20人の同時ユーザーです。そのうちの5人は、大量のデータを処理する大量のレポートを生成する「リソース集中型」と考えることができます。ユーザーの大多数は、asp.net WebサイトおよびレポートサーバーWebサイトを介してデータベースと対話します。さらに、開発者はサーバーに直接リモート処理することにより、BIDSでSSISを広範囲に使用します（最大2つのリモート接続）。最後に、かなり複雑なデータウェアハウジング操作があり、サーバーでも実行されるSSISパッケージを介して1日あたり300万件のレコードが取り込まれる可能性があります。
現在の問題：
慢性的なサーバータイムアウトがあり、Webサイトへの応答時間がかなり悪いです。私たちが持っているメモリの量（4GB）はおそらく大きなボトルネックだと思います。追加のメモリに対する以前の要求は、より多くのクエリ最適化を実行する必要があるという一般的な応答で拒否されました。私たちはsqlの専門家ではありませんが（セットアップでわかるように）db adminの専門家ではありませんが、ハードウェアがハードウェアである場合、潜在的なパフォーマンスをほとんど絞り出そうとして、すべての時間を費やさないようにしたいと思います。ボトルネック。
Tl; drを回避してくれてありがとう！
...何が実行されるべきかについての大まかな大まかな見積もりが得られることを期待していました。
クエリとデータサイズに関する詳細な情報がないと、正確な推定はもちろん、あらゆる種類の推定を行うことは非常に困難です。
データベース：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が必要です。それで、ボックスはすでに限界に達しており、 database がどれだけ必要になるかを考え出すことすらできませんでした。
ユーザーの大多数は、asp.net WebサイトおよびレポートサーバーWebサイトを介してデータベースと対話します。
言わなかったが、これらが同じボックスで実行されている場合、それらのメモリ要件も考慮する必要がある。
最後に、かなり複雑なデータウェアハウジング操作があり、サーバーでも実行されるSSISパッケージを介して1日あたり300万件のレコードが取り込まれる可能性があります。
これがシステムにライブユーザーがいない夜に実行されると仮定すると、実行に時間がかかりすぎない限り、これは問題とは見なされません。物事のこの部分はあなたの心配の中で最も少ないです。ライブユーザーの方が重要です。
追加のメモリに対する以前の要求は、より多くのクエリ最適化を実行する必要があるという一般的な応答で拒否されました。
上記で示したように、プロビジョニングされている現在のメモリ容量は完全に不十分です。ただし、同時に、全体データベースをメモリ内に保持するために十分なメモリをプロビジョニングできる可能性は非常に低いです。一度。
そのような包括的な応答を得たとしても（ところで、 actual リソース使用自体ではなく、追加のリソースの正当化の説得力にもっと関係している可能性があります） 、データベースの効率が向上する可能性が高いです。それでも、現在発生している問題を修正できる調整だけでは十分ではありません。それの提案は私にとって完全な出発点ではありません。
私は現在プロビジョニングされているメモリの量が必要最低限（できるだけ早く修正する必要があります）未満であり、ユーザーエクスペリエンスを使用可能なレベルに改善するには追加のリソースが必要になる可能性があるという全体的なアプローチを取ります while の改善により、システムの効率が向上します。
ここにいくつかの考えがあります（攻撃の順序で）：
より多くのリソースをプロビジョニングするたびにパフォーマンスがどれだけ向上するかを証明できれば、 win になります。可能な場合はWebサイトの応答時間を含め、パフォーマンスモニターのログを使用してパフォーマンスメトリックを追跡します（注：loggingの部分は非常に重要です）。他のことをする前に、これを今から始めてください。最終的に最小メモリ量に到達すると（すぐに32 GBになりません）、突然、 evidence が追加されたメモリによって改善されました...つまり、さらに/を追加すると、おそらく助けにもなるでしょう！現在の設定でベースラインを収集しないと、物事が最小推奨レベルに達したときにボートに乗り遅れることになります。
サーバーの 待機統計 を分析します。これにより、システムの最大のボトルネックがわかります。おそらく
PAGEIOLATCH_XXは、最も一般的/最長の待機時間として、ディスクからページをフェッチするために実行されているI/Oが多すぎることを示します。これはメモリを追加することで軽減できます。必要なデータがすでにメモリにあるため、物理I/Oの頻度は少なくなります。この分析はほぼ完全な結論ですが、これらの統計をすべて収集したという事実は、リソースの必要性を正当化する際により多くの弾薬を提供します。上で述べたように、メモリの最低限の要件が満たされていません。実行しているソフトウェアの all ソフトウェアの推奨ハードウェア要件のセットを収集し、タスクマネージャーのスクリーンショットも取得します。これだけでも、その場で少なくとも4〜8 GB以上を正当化するには十分です。それでも拒否される場合は、1週間試用できるように説得し、その後に返却してください（パフォーマンス統計を収集しているため、週の半ばに返却する必要がないため、返却する必要はありません。状況がどれだけ改善されたかを証明することができます）。彼らが still を拒否した場合、失敗するように設定されています。 [〜＃〜] urlt [〜＃〜] 。
ワークロードの一部をオフロードできる場合（特に、可能な場合はリモート処理を回避する）、これにより、データベースで使用可能なメモリの量が増加します。これは、より重要です。
データベース全体を一度にメモリに収めることはできません。つまり、SQL Serverの最大メモリ設定を慎重に prevent memory over-commit に設定する必要があります。これにより、他に何もない。オーバーコミットは、実際にはすべてのデータをメモリに収めることができないよりさらに悪いです。利用可能なメモリがまったくないという理由だけでこのシナリオにいる可能性が非常に高く、最大メモリ設定がデフォルト（無制限）に設定されている可能性があります。
SQL Server Enterprise Editionを実行していて、メモリが限られているため、 データ圧縮 の実装を強く検討します。これにより、CPU使用量の増加とメモリのスペース節約とがトレードオフされます（したがって、比較的非常に遅いディスクアクセスが削減されます）。
データベースを調整します。構造とクエリは、インデックス作成とアクセスパターンに関する限り、改善を使用できる可能性があります。また、大量のデータが頻繁にスキャンおよび集計される場合は、インデックス付きビュー、サマリーテーブル、または事前計算されたレポートを作成すると非常に役立ちます。
これはおそらくハードウェアのプロビジョニングを増やすことになるが、キャッシングソリューションを実装することになるため、長い道のりになるかもしれません。 最速のクエリはあなたが作成したものではありません 。
これらはほんの一部のアイデアです。結論としては、チューニングだけではここでの問題は解決されず、ハードウェアだけでも、おそらく当面の問題の大部分は緩和されます。それが実際の方法です。短期間に問題にハードウェアを投入して火を消し、根本原因をできる限り修正するために長期的に問題にチューニングを投入します。
これは「ビーンカウンター」の狂気です。あなたが使うであろう$ 1100- $ 2500 RAMはそれ自体で返済することができます1週間以内！
彼らは20人の従業員のタイムアウトを取得しており、そのうち5人は「リソース集約型」の作業を行っています。私は彼らの時間は安くないと思います、そしてそれらのレポートのいくつかは給与にサインオフしない上司が大好きなものです。それは、再送信して欲求不満に対処するために費やされた無駄な量です。
彼らはおそらくRAMのGBあたり15〜20ドルを見ていることを説明します。 128GBのRAMは現在およそ$ 2200- $ 2500で、現在RAM価格が少し上がっています。サーバーのマザーボードがサポートしていない場合でも（それは奇妙なことですが）、64 GBは$ 1100〜$ 1200になります（私が確認したところ、割引が適用されていないデルのサーバーRAMの品質です）。大きなテーブルのテーブルスキャン）。
どれだけの時間が浪費されているかを把握し、それが$ 1100〜$ 2500の価値があるかどうかを尋ねます。 $ 1100を費やして64 GBのRAMを取得する場合は、大きなテーブルでのテーブルスキャンを避けてください。大規模なスキャンによるメモリのダンプを回避するために、インデックスを備えたより多くのディスクを使用します（サポートするレイテンシがある場合）。