Analysis Services の配置に関する要件と注意点
Microsoft SQL Server Analysis Services プロジェクトを配置する前に、Analysis Services インストールの信頼性とパフォーマンスを向上させるために検討すべき問題があります。たとえば、サーバー上の既存のインスタンスに Analysis Services の別のインスタンスを追加する場合や、プロジェクト内の複雑なキューブを処理する場合は、ハードウェア リソースを増やすことが必要な場合があります。また、ハードウェアまたはソフトウェアで障害が発生した場合や、特定の処理タスク時に、プロジェクトの可用性を確認するための手順を実行することも必要です。最後に、パフォーマンスの要件に基づいて複数のコンピューターで SQL Server または Analysis Services のインスタンスのスケーリングを検討します。
要件と注意点
配置に関する要件と検討事項については、次のセクションで説明します。
リソース要件
可用性に関する注意点
スケーラビリティに関する注意点
リソース要件
Analysis Services プロジェクトを配置する前に、インストールのリソース要件を検討する必要があります。特に、メモリおよびプロセッサの要件とディスク容量の要件を検討してください。
メモリおよびプロセッサの要件
次のような場合、Analysis Services にはより大きなメモリおよびプロセッサ リソースが必要です。
大規模または複雑なキューブを処理する場合。このようなキューブには、小規模または単純なキューブよりも大きなメモリおよびプロセッサ リソースが必要です。
1 つのデータベース内のキューブ数が増加した場合。
Analysis Services の 1 つのインスタンス内のデータベース数が増加した場合。
1 つのコンピューター上の Analysis Services のインスタンス数が増加した場合。
Analysis Services リソースに同時にアクセスするユーザー数が増加した場合。
Analysis Services で使用可能なメモリおよびプロセッサ リソースの量は、サーバー コンピューターにインストールされている Microsoft Windows のバージョンによって異なります。オペレーティング システムで使用可能なプロセッサの最大数およびメモリの最大量の詳細については、「Hardware and Software Requirements」を参照してください。
.gif "重要な注意事項") 重要 |
|---|
Analysis Services は、コンピューターにインストールされている実際のメモリの量に関係なく、Windows の 32 ビット版で最大 3 GB のメモリに対応できます。/3GB スイッチの詳細については、サポート技術情報 (KB) の資料 283037 を参照してください。 |
ディスク空き容量の要件
Analysis Services インストールのさまざまな側面とオブジェクト処理に関連するタスクによって、必要なディスクの空き容量が異なります。次の一覧では、このような要件について説明します。
キューブ
大きなファクト テーブルを持つキューブでは、小さなファクト テーブルを持つキューブよりも大きなディスク空き容量が必要です。同様に、小さなエクステントでも、多くの大きなディメンションを持つキューブでは、ディメンション メンバーが少ないキューブよりも大きなディスク空き容量が必要です。通常、Analysis Services データベースでは、基になるリレーショナル データベースに保存されている同じデータに必要な空き容量の約 20% が必要です。集計
集計では、追加される集計に比例した空き容量が必要であり、集計が多くなるほど、大きな空き容量が必要です。不要な集計を作成しないようにするには、通常、集計に必要な追加の空き容量が、基になるリレーショナル データベースに保存されているデータのサイズの約 10% を超えないようにする必要があります。データ マイニング
既定では、マイニング構造によって、トレーニングされるデータセットがディスクにキャッシュされます。このキャッシュされたデータをディスクから削除するには、マイニング構造オブジェクトで [構造消去の処理] の処理オプションを使用できます。詳細については、「データ マイニング オブジェクトの処理」を参照してください。オブジェクトの処理
Analysis Services では、処理が終了するまで、処理トランザクションで処理中のオブジェクトのコピーがディスクに保存されます。処理が終了すると、オブジェクトの処理済みのコピーによって元のオブジェクトが置き換えられます。このため、処理する各オブジェクトの 2 番目のコピー用に十分な空き容量を確保する必要があります。たとえば、1 つのトランザクションでキューブ全体を処理する場合、キューブ全体の 2 番目のコピーを保存するために十分なハード ディスク容量が必要です。
トップに戻る
可用性に関する注意点
Analysis Services 環境では、ハードウェアまたはソフトウェアの障害によって、キューブまたはマイニング モデルをクエリに使用できない場合があります。また、キューブも処理する必要があるので使用できない場合があります。
ハードウェアまたはソフトウェアの障害時における可用性の提供
ハードウェアやソフトウェアでは、さまざまな理由により障害が発生します。ただし、Analysis Services インストールの可用性を維持すると、そのような障害の原因をトラブルシューティングできるだけでなく、障害が発生した場合にユーザーがシステムの使用を続行できるように代替のリソースを提供することもできます。サーバーのクラスター化と負荷分散は、通常、ハードウェアまたはソフトウェアの障害が発生した場合に可用性の維持に必要な代替のリソースを提供するために使用されます。
ハードウェアまたはソフトウェアの障害が発生した場合に可用性を維持するには、Analysis Services をフェールオーバー クラスターに配置することを検討してください。フェールオーバー クラスターでは、なんらかの理由でプライマリ ノードで障害が発生した場合や、プライマリ ノードを再起動する必要がある場合、Microsoft Windows のクラスター化によってセカンダリ ノードにフェールオーバーされます。フェールオーバーは非常に短時間で行われ、その後にユーザーがクエリを実行すると、そのクエリはセカンダリ ノードで実行されている Analysis Services のインスタンスにアクセスします。
可用性の問題に対する別の解決方法としては、Analysis Services プロジェクトを 2 つ以上の実稼働サーバーに配置することです。Windows サーバーのネットワーク負荷分散 (NLB) 機能を使用して、実稼働サーバーを 1 つのクラスターに結合できます。NLB クラスターでは、クラスター内のサーバーがハードウェアまたはソフトウェアの問題が原因で使用できない場合、NLB サービスによって使用可能なサーバーにクエリするように指示されます。Windows のクラスター化と NLB の詳細については、Microsoft Windows Server 2003 Web サイトの「テクノロジ」の下にある「クラスター サービス」を参照してください。
構造的変更の処理時における可用性の提供
キューブに特定の変更を行うと、キューブが処理されるまで使用できなくなることがあります。たとえば、キューブ内のディメンションに構造的変更を行うと、ディメンションを再処理した場合でも、変更したディメンションを使用する各キューブも処理する必要があります。このようなキューブを処理しない限り、そのキューブをクエリできません。また、変更したディメンションが含まれているキューブに基づいたマイニング モデルもクエリできません。
Analysis Services プロジェクトの 1 つまたは複数のキューブに影響を与える可能性がある構造的変更を処理しているときに可用性を確保するには、ステージング サーバーを組み込むか、データベースの同期ウィザードを使用することを検討してください。この機能を使用すると、ステージング サーバー上でデータとメタデータを更新し、実稼働サーバーとステージング サーバーの同期をオンラインで実行できます。詳細については、「Analysis Services データベースの同期」を参照してください。
ソース データの増分更新を簡単に処理するには、プロアクティブ キャッシュを有効にします。プロアクティブ キャッシュでは、新しいソース データを使用してキューブが更新されます。手動での処理は必要なく、キューブの可用性に影響を与えることもありません。詳細については、「プロアクティブ キャッシュ (パーティション)」を参照してください。
トップに戻る
スケーラビリティに関する注意点
同じコンピューター上に Microsoft SQL Server と Analysis Services の複数のインスタンスがあると、パフォーマンスの問題が発生する場合があります。このような問題を解決する 1 つの方法は、サーバー上のプロセッサ、メモリ、およびディスク リソースを増やすことです。ただし、複数のコンピューターで SQL Server と Analysis Services のインスタンスをスケーリングすることが必要な場合もあります。
複数のコンピューターにおける Analysis Services のスケーリング
複数のコンピューターで Analysis Services のインストールをスケーリングするには、いくつかの方法があります。これらのオプションについては、次の一覧を参照してください。
1 つのコンピューターに Analysis Services の複数のインスタンスがある場合は、1 つまたは複数のインスタンスを別のコンピューターに移動できます。
1 つのコンピューターに複数の Analysis Services データベースがある場合は、1 つまたは複数のデータベースを別のコンピューターの Analysis Services の独自のインスタンスに移動できます。
1 つまたは複数のリレーショナル データベースから Analysis Services データベースにデータが提供される場合は、これらのデータベースを別のコンピューターに移動できます。データベースを移動する前に、Analysis Services データベースと基になるデータベース間に存在するネットワークの速度と帯域幅を検討してください。ネットワークが低速であるか混雑している場合、基になるデータベースを別のコンピューターに移動すると、処理のパフォーマンスに影響を与えます。
処理がクエリのパフォーマンスに影響を与えるが、クエリの負荷が低いときに処理できない場合は、処理タスクをステージング サーバーに移動し、実稼働サーバーとステージング サーバーの同期をオンラインで実行することを検討してください。詳細については、「Analysis Services データベースの同期」を参照してください。また、リモート パーティションを使用して、Analysis Services の複数のインスタンスに処理を分散することもできます。リモート パーティションの処理では、ローカル コンピューターのリソースではなく、リモート サーバーのプロセッサおよびメモリ リソースを使用します。リモート パーティションの管理の詳細については、「Analysis Services パーティションの管理」を参照してください。
クエリのパフォーマンスは低いが、ローカル サーバーのプロセッサおよびメモリ リソースを増やすことができない場合は、2 つ以上の実稼働サーバーに Analysis Services プロジェクトを配置することを検討してください。ネットワーク負荷分散 (NLB) を使用して、サーバーを 1 つのクラスターに結合できます。NLB クラスターでは、クエリは NLB クラスター内のすべてのサーバーに自動的に分散されます。詳細については、Microsoft Windows Server 2003 Web サイトの「テクノロジ」の下にある「クラスター サービス」を参照してください。
トップに戻る
関連項目