データウェアハウスサーバー。RAM / CPU仕様をどのように計算しますか？

計画中のデータウェアハウスアップグレード用のデータウェアハウスサーバーの仕様を記述しようとしています。

VMWareホストで仮想サーバーを実行すると、必要に応じてリソースを追加または削除できます。以前は、必要に応じてRAMとCPUを段階的に追加していました。需要が高まるにつれて、より多くのリソースを求めてロビー活動を行ってきました。（主にディスクとRAM）。

もっとお願いします。彼らは私たちにできるだけ少ないを与えます。

しかし、最近リソースについて話すときはいつでも、そもそもマシンを正しく指定していないと非難されており、開発ホストが使い果たされていると言われ、RAMはもうありません。

私たちは小さな地方自治体の組織であり、DWを50人まで定期的に利用しています。通常の日常使用では問題なく動作します。mdxクエリのパフォーマンスは良好で、レポートとダッシュボードは高速です。ユーザーは満足しています。

ただし、ETLプロセスは夜通し実行されるため、データマートを同時に処理すると、メモリプレッシャーの兆候が見え始めています。昨夜、SSISは「メモリ不足エラー」に関する警告で失敗しました。

私たちの既存のDWサーバーは4つのCPUと16GbのRAMを搭載したWin 2008 R2で、SQL 2012 Stdを実行しています。私が持っている最大サーバーメモリ等の当社の既存のDWは3マート/ OLAPキューブを持っており、我々はより多くの2を開発しているOSおよびサービスのための4ギガバイトを残して、12ギガバイトのセットを。

+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB |  Fact (Rows)  | Fact (Mb) | ETL & Process |
| OLAP cube|          |               |           | Time (hours)  |
+----------+----------+---------------+-----------+---------------+
| PBI      |       3  |  190,000      |  180      |  0.2          |
| FBI      |      30  |  26,100,000   |  10,000   |  1.5          |
| RBI      |     175  |  62,000,000   |  32,000   |  8.3          |
| ABI*     |     100  |  44,050,000   |  21,000   |  4.0          |
| EBI*     |      11  |  100,000,000  |  6,000    |  2.0          |
+----------+----------+---------------+-----------+---------------+
* Planned/Estimated

新しいサーバーは、SQL 2016 Enterpriseを実行するWin 2012になる予定です。SQL、SSIS、SSRS、SSASを実行します。ストレージは問題ではありませんが、RAMとCPUについてはわかりません。

SQL Server 2012のFast Trackデータウェアハウスリファレンスガイドによると、2ソケットマシンの場合、最低限必要なのは128Gbですが、これは少し過剰に見えます。SQL Server 2016をインストールするためのハードウェアおよびソフトウェアの要件では、SQL 2016には最低4GbのRAMを推奨しています。これはかなりの違いです！

だから、良い出発点は何ですか？32Gb？64Gb？開始位置（仕様）をITに正当化するにはどうすればよいですか？

サーバーリソースの計算方法に関する優れたガイドはありますか？

良い経験則はありますか？

DWコンテキストでのRAMサイジングの主要な要素/メトリックは何ですか？

• データ量？
• キューブの数は？
• ETLまたはキューブの処理にかかる時間は？
• ピーク時の処理負荷は夜間ですか、それともエンドユーザーが日中見たときのパフォーマンスですか？

素晴らしい質問です。数年前のTechEdで、「最速のSQLサーバーの構築」と呼ばれるセッションを行いました。

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328

その中で、データウェアハウスの場合、SQL Serverがデータを消費するのに十分な速度でデータを提供できるストレージが必要であることを説明します。Microsoftは、ハードウェアの詳細に入るFast Track Data Warehouseリファレンスアーキテクチャと呼ばれる一連の優れたホワイトペーパーを作成しましたが、基本的な考え方は、ストレージでは、CPUコアごとに200〜300 MB /秒のシーケンシャル読み取りパフォーマンスを提供できる必要があるということです。 CPUをビジー状態に保つため。

メモリにキャッシュできるデータが多いほど、処理速度が遅くなります。しかし、処理しているファクトテーブルをキャッシュするために必要なメモリよりも少ないメモリしか持っていないため、ストレージ速度が非常に重要になります。

次のステップは次のとおりです。

• そのビデオを見る
• CrystalDiskMarkを使用してストレージをテストする（方法は次のとおりです）
• 4コアの場合、少なくとも 800MB /秒の順次読み取りスループットが必要です。
• それがない場合は、問題がなくなるまでメモリを追加することを検討してください（RAMにデータベース全体をキャッシュすることは考えられないことではありません）

処理している200GBのデータベースがあり、コアをビジー状態に保つのに十分なストレージスループットが得られないとします。200 GBのRAMだけでなく、さらに多くのRAMが必要になることも考えられないわけではありません。結局のところ、SSISとSSASは実際にメモリ内で作業を行いたいので、エンジンのデータとSSISとSSASの作業スペースを用意する必要があります。

これが、人々がSSISとSSASを別々のVMに分離しようとする理由でもあります-それらはすべて同時にメモリを必要とします。

SQL Server 2012のFast Trackデータウェアハウスリファレンスガイドは、特にSQL Server 2016に移行する場合（本当に？電話してください）、時間だけでなく機能も特に古くなっています。

SQL Server 2012では、ファストトラックのベースとなっているバージョンでは、非クラスター化列ストアインデックスしか使用できませんでした。これらはメインテーブルとは別の構造であるため、データの圧縮コピーにもかかわらず、追加のストレージと処理のオーバーヘッドが発生します。

SQL Server 2014以降では、列ストアインデックスをクラスター化できます。これらは、集約/要約クエリの大規模な圧縮と潜在的なパフォーマンスの向上を提供します。これらはファクトテーブルに完全に適しているため、32 GBのファクトテーブルは8〜12 GBのようになります。YMMV。少し風景が変わりますね。あなたのテーブル（そして空中の親指）を見ると、32 GBで十分かもしれませんが、64 GB（1 TBを要求しているようではありません）で撮影し、他のサービスと成長のための部屋を残します。これにより、最大のテーブルをメモリに保持し、成長の余地と他のサービスの余地を確保する。圧縮について彼らに話す必要はありません。サイジングで注意しなければならないことの1つは、現在のデータのサイジングだけではなく、1年後のデータのサイズをどのようにするかです。ただし、ポイントルックアップのパフォーマンスは恐ろしいものになる可能性がありますが、SQL Server 2016に移行するときに、追加のインデックスを追加することも、リアルタイム運用分析用の列ストアインデックスを常に検討することもできますが、そのためにより多くのメモリが必要になります。 ：）

ちなみにCTPはどのように進んでいますか？現在CTP3.3では、使用したい機能のほとんどが利用できるため、試用のためのリソースはありませんが、Windows Azureの試用版を入手できます、VMを起動し、サンプルデータを作成し、圧縮、主要機能のパフォーマンス、クエリなどを無料でテストします。または、MSDNライセンスを持っている場合は、これが組み込まれています。

要約すると、最大のテーブルをメモリ（およびその他のもの）に入れることができるサイズ、または簡単なトライアルを（クラウドで無料で）セットアップして、必要な証拠を取得します。完了したら、必ずVMの割り当てを解除してください：）

おそらくローカル開発マシンでETLパッケージを開発および保守しているときに、本番環境で期待するものと同様またはそれ以上の規模のテストデータを使用する場合があります。そうでない場合は、そうすることを検討します（匿名の実際のデータまたはアルゴリズムによって生成されたテストデータ、実際のデータがまったく機密である場合）。

これが当てはまる場合は、さまざまなメモリ条件下でプロセスを実行してプロファイリングし、RAMの増加が大きな違いを生み出さなくなるポイントを確認します。経験則や推測に基づくのと同じくらい便利ですが、ベンチマークやプロファイリングでは、はるかに具体的な答えは得られません。ボーナスとして、最適化が容易な可能性のある明らかなボトルネックが明らかになる場合があります。もちろん、開発/テスト環境が本番環境と正確に一致しない場合があるため、経験を使用して結果がどのように変化するかを解釈する必要がある場合があります。

データベースと同じマシンでSSISを実行している場合は、すべてのメモリを要求しないようにSQL Serverエンジンインスタンスが設定されていることを確認してください。メモリが不足すると、SSISでOOMエラーが発生するだけでなく、それよりもずっと前に、バッファをディスクにスプールするときにバッファをRAMに保持できるため、パフォーマンスに重大な問題を引き起こす可能性があります。SSISおよびその他のタスク用に予約する必要がある量はプロセスによって大きく異なるため、プロファイリングはこれを評価するための良い方法です。多くの場合、これを管理しやすくするためにSSISを別のマシンで実行することをお勧めしますが、ネットワークスループットやライセンスの問題を考慮する必要がある場合もあります。

更新

コメントに従って、割り当てられているRAMが少なすぎる場合にパフォーマンスが低下する場所（および/またはOOMエラーや関連する問題が発生し始める場所）を測定するための現実的なベンチマークを実行するためのリソースがない場合、状況はかなり手波になります。倉庫とETLプロセスの詳細な知識なし。ウェアハウスデータベース自体の経験則：最も一般的に使用されるすべてのインデックス全体を保持できる十分なRAMが必要です。次に、あまり使用されないデータを考慮に入れ、近い将来の予想される成長を可能にするためにさらに必要なRAMが必要です。 /中程度の未来。

これを計算すると、fafになる可能性があります。sp_spaceUsedは、インデックスごとに分解しないので、sys.allocation_unitsとそのフレンドを直接クエリする必要があります。あなたが始めるためにそこにいくつかの例があります、http：//blog.sqlauthority.com/2010/05/09/sql-server-size-of-index-table-for-each-index-solution-2 /は、クイック検索から得られた最初のいくつかの中で最高のようです。

ウェアハウスDB自体を実行する必要性に加えて、同じマシンで実行する場合はSSISのRAM要件を追加し、SQL ServerにRAM制限があることを確認して、このメモリが実際に利用可能であることを確認してくださいSSIS。

全体的なデータサイズから、私の腸は、32 GbがデータベースエンジンとSSISのみに推奨される絶対的な最小値であり、SQLインスタンスを最大で26に設定し、実行しているため、同じマシン上のSSRSとその他のサービスの実用的な最小値は、将来の保証付きで64Gbになります（他のサービスと予約が削減された後は、現在のデータの3分の2がそれに収まるはずです）。明らかに、私の直感を引用しても、インフラストラクチャの人々との議論にそれほど遠くまでは行きません...