透過的なパーティション

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

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

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


このイメージは、透過パーティションのデータ・ターゲットのユーザーに、3つのデータソースからのデータが表示される仕組みを示しています。

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

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

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

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

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

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

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

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

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

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

  • データはソース・キューブに格納されます。ターゲット・キューブはデータを格納または管理しませんが、アクセス・ポイントとして機能します。書込みアクセス権が有効な場合、ターゲット・キューブにアクセスするユーザーはソース・キューブ内のデータを更新できます。

  • ソース・キューブとターゲット・キューブの両方が集約ストレージ(ASO)キューブの場合、ターゲット・キューブからソース・キューブへのデータ・マージはサポートされていません。

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

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

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

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

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

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


    このイメージは、透過パーティションのターゲットには透過パーティションまたは複製パーティションのソースからのデータを含めることができる仕組みを示しています。

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

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


    このイメージは、透過パーティションには1つのみのパーティションのソースからのデータを含めることができる仕組みを示しています。

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

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

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

データを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とS Southのメンバー(およびその子)のデータから計算されます。データソースのこれらのメンバーのいずれかにメンバー式が含まれる場合、これらの式が計算されて、データ・ターゲットのMarketの計算される値に影響します。これらの結果は、これらの式が存在しないデータ・ターゲットのNorthおよびSouthのメンバーからのMarketメンバーの計算とは異なる場合があります。

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

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

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

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

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