透過パーティション

Essbaseの透過パーティションにより、ユーザーは、リモートに保管されたデータをローカル・キューブ内のデータのように操作できます。ターゲット・キューブでユーザーが要求するたびに、リモート・データがソース・キューブから取得されます。

ターゲット・キューブで作業しているユーザーは、データが保管されている場所を知る必要はありません。これは、データがローカル・キューブの一部であるかのようにアクセスするためです。

図9-5 透過パーティション

データはデータソースから直接取得されるため、ユーザーは最新バージョンにアクセスします。データを更新すると、更新内容がデータソースに書き込まれます。このプロセスは、データソースとデータ・ターゲットの他のユーザーが、これらの更新内容にただちにアクセスできることを意味します。

透過パーティションを使用する場合は、ソース・データにアクセスするユーザーが増加すると、データソースとデータ・ターゲットでパフォーマンス速度が遅くなります。

たとえば、TBCのDBAは、透過パーティションを使用して、個別のコンピュータでScenarioディメンションの各メンバーを計算できます。このプロセスでは、ユーザーに同じデータ・ビューが提供されますが、計算時間が短縮されます。

透過パーティションは、次の目的を達成するために使用します。

• ユーザーに最新バージョンのデータを示します

• データ・ターゲットのユーザーにデータの更新を許可します

• ディスク領域のフットプリントを最小化します

透過パーティションを作成すると、データはソース・キューブに保管される必要があるため、ターゲット・キューブのデータ・スライスがクリアされて#MISSINGになります。パーティションを削除した場合もクリアされたままになります。

透過パーティションのルール

透過パーティションは、次のルールに従う必要があります。

• データソースとデータ・ターゲットのアウトラインの共有透過領域は同一である必要はありませんが、そのディメンションをマップできる必要があります。データソース内の各ディメンションとメンバーを、データ・ターゲット内の各ディメンションとメンバーにマップする方法をEssbaseに指定する必要があります。

• 非共有領域のデータソースのアウトラインとデータ・ターゲットのアウトラインは、マップできる必要はありませんが、属性の関連付けは同一である必要があります。そうでない場合、一部の取得で正しい結果が得られない可能性があります。たとえば、製品100-10-1010がソースのGrape Flavor属性と関連付けられているが、製品100-10-1010がターゲットのGrapeに関連付けられていない場合、New Yorkのすべてのグレープ味の売上の合計は正しくありません。

• パーティション定義には、保管済メンバーのみが含まれる必要があります。属性ディメンションまたはメンバーを使用して透過パーティションを定義できません。たとえば、Marketディメンションに関連付けられたMarket Type属性ディメンションには、Urban、SuburbanおよびRuralのメンバーがあります。Urban、Suburban、Ruralにはパーティションを定義できません。

• セルがデータソースからターゲットの集約ストレージ・データベースにマップされている場合、このセルのすべての依存項目も、同じパーティション定義にマップする必要があります。

• 複製パーティションの上に透過パーティションを作成できます。つまり、次の図に示すように、複製パーティションのソースを使用して透過パーティションのターゲットを作成できます。

  図9-6 有効な透過パーティション

  
  
  

• 次の図のように、透過パーティションは、複数の他のパーティションの上には作成できません。つまり、データベースの各セルを、1つの場所(ローカル・ディスクまたはリモート・ディスク)のみから取得する必要があるため、複数のソースからは透過パーティションのターゲットを作成できません。

  図9-7 無効な透過パーティション

  
  
  

• データソースとデータ・ターゲットのメンバーに割り当てる式は、慎重に検討してください。

透過パーティションの長所

透過パーティションによってデータベースの数多くの問題を解決できますが、透過パーティションが常に理想的なパーティション・タイプであるわけではありません。

データを1つのデータベースに保管するため、必要なディスク・スペースが少なくなります。

データ・ターゲットからアクセスされるデータは、常に最新のバージョンです。

ユーザーがデータソースのデータを更新すると、Essbaseにより、その変更がデータ・ターゲットに対して適用されます。

個々のデータベースが小さくなるため、より高速に計算できます。

データの配布は、エンドユーザーとエンドユーザーのツールには表示されません。

データソースまたはデータ・ターゲットのどちらからでもデータをロードできます。

透過パーティションの短所

次のデメリットが深刻すぎる場合は、かわりに複製パーティションまたはフェデレーテッド・パーティションの使用を検討してください。

透過パーティションによってネットワーク・アクティビティが増加し、ユーザーの取得時間が遅くなります。

ソース・データにアクセスするユーザーが増加するため、取得時間が長くなる可能性があります。

ソース・キューブが失敗した場合、ソースとターゲットの両方のユーザーが影響を受けます。したがって、ネットワークおよびソース・キューブは、ソースまたはターゲットに接続しているユーザーが必要なときにいつでも使用可能である必要があります。

一部の管理操作は、ローカル・データに対してのみ実行できます。たとえば、ターゲット・キューブをアーカイブする場合、Essbaseはターゲットのみをアーカイブし、ソース・キューブはアーカイブしません。次の管理操作は、ブロック・ストレージ・データベース内のローカル・データにのみ影響を及ぼします。

• CLEARDATA計算コマンド

• DATACOPY計算コマンド

• EXPORTコマンド

• VALIDATEコマンド

• BEGINARCHIVEコマンドおよびENDARCHIVEコマンド

透過パーティションで計算を実行すると、Essbaseではローカル・データと透過の依存項目の最新の値を使用して計算が実行されます。Essbaseでは、ソースとターゲットのアウトラインが異なっていて、計算が不正確になる場合があるため、透過の依存項目は再計算されません。すべてのパーティションを計算するには、個々のパーティションに対してCALC ALLコマンドを発行し、各パーティションの新しい値を使用して、最上位でCALC ALLコマンドを実行します。

次の例を考えてみます:

• ターゲット・キューブのアウトラインに、East、West、SouthおよびCentralのメンバーを持つMarketディメンションが含まれています

• ソース・キューブのアウトラインに、New YorkとNew Jerseyのメンバーを持つEastディメンションが含まれています

ターゲット・キューブの計算を試みた場合、Eastをレベル0のメンバーと想定する可能性があります。ただし、ソース・キューブでは、EastはNew YorkとNew Jerseyを加算して導出されます。一方、ターゲットでの計算では、この情報は認識されず、ソースのNew YorkおよびNew Jerseyに加えられた変更は反映されません。そのため、正確な計算を実行するには、ソースでEastを計算してから、ターゲットを計算します。

ソース・キューブのメンバーに割り当てられた式は、ターゲット・キューブで定義された式または集計と矛盾する計算結果をソース・キューブで生成する場合があり、その逆もあります。

透過パーティションのパフォーマンスの考慮事項

透過パーティションのパフォーマンスを改善するには、パーティションを作成するとき、次のガイドラインを考慮してください。

• 密ディメンションに沿ってパーティション化すると、密ディメンションを使用してデータ・ブロックの構造とコンテンツが特定されるため、パフォーマンスが大幅に低下する可能性があります。

  パフォーマンスを改善するには、領域定義に1つ以上の疎ディメンションを含めることで、疎メンバーとの組合せの数が必要なブロック数の上限になるようにすることを検討してください。

• 属性は疎ディメンションに関連付けられるため、透過パーティションがディメンションの属性値に基づくようにすると、取得時間が長くなることがあります。この場合、属性に関連付けられたレベルより上位のレベルでパーティション化すると、取得時間が改善されます。たとえば、Sample.BasicデータベースのProductディメンションで、子100-10、200-10および300-10 (レベル0)が属性に関連付けられている場合、その親100、200および300 (レベル1)をパーティション化すると、取得パフォーマンスが改善されます。

• ターゲット・キューブからソース・キューブにデータをロードすると、パフォーマンスが大幅に低下する可能性があります。可能な場合は、ローカルでデータソースにデータをロードします。

• ユーザーはネットワークを介してデータにアクセスするため、取得時間が長くなります。

• 透過パーティションがターゲットである場合、次の構成設定の使用を検討してください:

  • ソース・キューブから透過パーティション・ターゲット・キューブに送信される要求の場合、ENABLE_DIAG_TRANSPARENT_PARTITION構成設定を使用してトランザクションの応答時間を記録できます。これらのメッセージをログに記録すると、遅すぎる応答時間のトラブルシューティングに役立ちます。

  • 透過パーティションのターゲットが集約ストレージ(ASO)キューブである場合、MAX_REQUEST_GRID_SIZEおよびMAX_RESPONSE_GRID_SIZEの構成設定を使用して、要求グリッドと応答グリッドの最大サイズを指定できます。

• 基本ディメンションをパーティション化すると、パフォーマンスが大幅に低下することがあります。

透過パーティションの計算

リモート・データに依存するローカル・データを計算する場合は、Essbaseでボトムアップの計算を使用する必要があります。ターゲット・キューブで最適化された計算機キャッシュを使用していることを確認してください。「計算機キャッシュのサイズ設定」を参照してください。

透過パーティションで計算を実行すると、Essbaseではローカル・データと透過の依存項目の最新の値を使用して計算が実行されます。リモート・データに依存するローカル・データを計算するときは、Essbaseでボトムアップの計算が実行されます。ボトムアップの計算は、ターゲット・データベースで計算機キャッシュが適切に使用されている場合にかぎり実行できます。「ボトムアップ計算とトップダウン計算」を参照してください。

計算機キャッシュに割り当てるメモリーを増やすと、透過パーティションでの計算パフォーマンスが大幅に改善されます。計算が開始されると、アプリケーション・ログ・ファイルのメッセージで、ターゲット・データベースで計算機キャッシュが有効であるか無効であるかが示されます。ターゲット・データベースで計算機キャッシュを使用すると、計算時にデータソースから要求されるブロック数が減少します。要求されるブロック数が減少すると、ネットワーク経由でブロックを転送することにより発生するネットワーク・トラフィックが減少します。

透過パーティション計算パフォーマンス

透過パーティションのターゲットでデータを計算すると、計算前にEssbaseがネットワーク全体の依存ブロックをソースから取り出す必要がある場合、パフォーマンスが低下する可能性があります。透過的な計算を最適化するには、動的計算を使用し、計算機キャッシュを管理し、トップダウン式を回避し、領域定義メンバーで複雑な計算式を回避します。

Essbaseで、トップダウンのメンバー式を含むデータ・ターゲットの一部に対してトップダウンの計算を実行する必要がある場合も、透過計算のパフォーマンスが低下する可能性があります。データ・ターゲットにトップダウンのメンバー式が含まれない場合、Essbaseでは、はるかに高速のボトムアップの計算をデータ・ターゲットに対して実行できます。

Essbaseでソース・キューブに対する計算が実行される場合は、常にボトムアップの計算を実行できます。

次の代替の計算を使用することを検討してください。

• ターゲット・パーティションの計算スクリプトでリモート・データにアクセスしないことが確実である場合は、計算スクリプトでSET REMOTECALC OFF計算コマンドを使用して、ソース・パーティションからの取得を停止できます。

• 動的計算メンバーを透過データの親として実装し、取得時にその場でデータが計算されます。このプロセスでは、バッチ処理時間が短縮されます。Essbaseでは、この計算はユーザーが要求した場合にかぎり実行されます。

• 下位の透過データと上位のローカル・データの間に複製レイヤーを実装します。

次のパフォーマンス戦略を検討してください。

• 計算機キャッシュ領域内で、パーティションを完全に保持します。つまり、パーティション定義のすべての疎メンバーが計算機キャッシュに含まれる必要があります。たとえば、Sample Basicキューブで、パーティション定義に@IDESC(East)が含まれる場合は、Eastのすべての子孫が計算機キャッシュ内にある必要があります。

• 計算機キャッシュを有効にして、十分なメモリー量を計算機キャッシュに割り当てます。

• パーティションを定義するメンバーに対しては、複雑な式を使用しないでください。たとえば、Sample Basicで、New YorkまたはNew Jersey (どちらもEastの子)に対して複雑な式を割り当てた場合、Essbaseで強制的にトップダウンの計算方法が採用されます。

透過パーティションとメンバー式

メンバー式が異なる点を除いて、データ・ターゲットとデータソースのアウトラインが同一である場合は、パーティション定義で、必要な計算結果が生成されることを確認してください。

たとえば、データソースとデータ・ターゲットの両方のアウトラインに、NorthとSouthのメンバー、およびNorthの子とSouthの子を持つMarketディメンションが含まれているとします。データ・ターゲットで、Marketが、データソースのNorthとSouthのメンバー(およびその子)のデータから計算されます。データソースのこれらのメンバーのいずれかにメンバー式が含まれる場合、これらの式が計算されて、データ・ターゲットのMarketの計算される値に影響します。これらの結果は、これらの式が存在しないデータ・ターゲットのNorthとSouthのメンバーからのMarketメンバーの計算とは異なる場合があります。

データソースとデータ・ターゲットのメンバーに割り当てる式により、必要な結果が生成されるようにします。

透過パーティションとポートの使用方法

一意のユーザーとマシンの組合せごとに、1つのポートが使用されます。ユーザーが、同じユーザー名を使用して、1つのサーバーで複数の透過パーティションを定義した場合、1つのポートのみが使用されます。

透過パーティションで、ユーザー(user1)が、ソース・データにアクセスするターゲットの領域をドリルする場合、user1はパーティション定義で宣言されたユーザー名(パーティション・ユーザー)を使用して、ソース・データベースのデータにアクセスします。このアクセスでは、異なるユーザー(user1とパーティション・ユーザー)がアプリケーションに接続しているため、追加のポートが使用されます。

2番目のユーザー(user2)がターゲット・データベースに接続し、ドリルダウンしてソース・データにアクセスする場合、user2も、パーティション定義で宣言されたユーザー名(パーティション・ユーザー)を使用します。パーティション・ユーザーはすでにソース・データベースに接続しているため、user2が同じソース・データベースにアクセスしているかぎり、パーティション・ユーザーに対する追加のポートは不要です。