Financial Reportingのレポートのパフォーマンスの問題の診断

設計が不十分なFinancial Reportingのレポートは、複数のマルチディメンショナル式(MDX)リクエストまたはOracle Essbase問合せを生成し、Oracle Enterprise Performance Management Cloudの大量のリソースを消費する可能性があります。過剰なリソース消費は、同時ユーザーがそのようなレポートにアクセスする際にパフォーマンスが低下します。

多数のMDXリクエストが生成される主な理由は、レポート内の複数のセグメントの存在です。この項では、セグメントの数を削減することでFinancial Reportingのレポートをさらに効率的にする方法について説明します。

レポートの再設計: ユース・ケース

元のレポート

次の図は、元のレポート設計を示しています:
元のレポート設計の例

このレポートの図には、次の設計要素が示されています:

それぞれのEntityメンバー100、200、403および500の複数の行。
各Entityメンバーには、勘定科目がそれぞれ異なる8行があります。

次の表は、元のレポート設計と最適化された設計の概要を示しています:

元のレポート設計最適化された設計

元のレポート設計	最適化された設計
`Entity`メンバーごとに複数の行: `100` `200` `300` `400`	`Entity`メンバーを1つのセグメントに結合: `100, 200, 403, 500`
各`Entity`メンバーには、勘定科目がそれぞれ異なる8行があります。メンバー100の例: `100 = Children of 1100` `100 = 1100` `100= Children of 1200` `100=1200` `100 = Children of 1300` `100 = 1300 100 =Children of 1400` `100 = 1400`	すべてのメンバーのすべてのセグメントを1つのセグメントに結合: `Entity members 100,200,403,500=Children of 11`

Entityメンバーごとに複数の行:

100

200

300

400

Entityメンバーを1つのセグメントに結合:

100, 200, 403, 500

各Entityメンバーには、勘定科目がそれぞれ異なる8行があります。メンバー100の例:

100 = Children of 1100

100 = 1100

100= Children of 1200

100=1200

100 = Children of 1300

100 = 1300 100 =Children of 1400

100 = 1400

すべてのメンバーのすべてのセグメントを1つのセグメントに結合:

Entity members 100,200,403,500=Children of 11

最適化されたレポート

次の図は、セグメント数を削減するように最適化されたレポート設計を示しています。セグメント数を削減すると、MDXリクエストの数が減少してレポートの実行が速くなります:
再設計されたレポートの例

レポート設計に関する他の重要な考慮事項

可能であれば、ASOキューブに対してレポートを設計してください。ASOキューブが使用可能でない場合にのみ、BSOキューブに対してレポートを設計します。
常に「抑制」で「欠落しているブロック」を選択して、欠落しているブロックがレポートに含まれないようにしてください。
行および列の数を最小限にしてください。ベスト・プラクティス: 列には密ディメンションを使用し、行には疎ディメンションを使用します。
メンバーの親レベルではなく、必要な子レベルで問い合せるようにレポートを設計してください。
レベル0のメンバーが動的計算としてタグ付けされているが、式がない場合は、動的計算のタグ付けを削除するか、それらの式を作成します。動的計算としてタグ付けされたレベル0のメンバーにデータをロードすることはできません。動的計算としてタグ付けされているが、値を計算するための式がないため、値を表示できません。このようなメンバーは、取得パフォーマンスに悪影響を与えます。
可能な場合は、大規模なメンバーの組合せがあるリレーショナル・タイプのレポート(関数を使用して複数の行ディメンションが展開されているレポート)は避けてください。大きいレポートは実行にかなりの時間を要する(または実行されない)場合があります。セルの数が1万を超えると、レポートは大きいと見なされます。これは、Financial Reportingを大規模なデータ抽出ツールとして取り扱うことに似ていますが、そうではありません。
データ・ソースから追加のメタデータを取得するテキスト関数(CellText、PlanningAnnotations、ListOfCellDocumentsなど)が指定されている多数のセルがあるレポートは避けてください。
レポートの実行時にすべてのページ・メンバーが一度に取得されるページ・ディメンションのかわりに、現在のPOV、プロンプトまたはブックを使用してください。
レポートのサイズに応じてパフォーマンスに影響する可能性があるため、条件付きフォーマットおよび条件付き抑制の影響を考慮してテストしてください。パフォーマンスは、レポート内で使用される基準のタイプと頻度によって決まります。データ値、メンバー名、メンバー別名、説明など、メタデータまたはデータ問合せの一部である基準は、高速にレンダリングされます。大規模なレポートでは、通常のメタデータまたはデータ問合せの一部でない基準の使用を最小限にしてください。このような基準の例としては、世代、レベル、勘定科目タイプ、属性値などがあります。
ディメンション・レイアウトを検討してください。たとえば、POVまたはページからレポートの本体に移動できるものを分析します。
常に、(非対称ではなく)対称レポートを設計してください。Essbase問合せは対称または非対称の場合があります。対称型問合せは、行または列で問合せされるメンバーがディメンション間レイアウトの問合せです。非対称型問合せは、問合せされるメンバーのディメンション間レイアウトが、行または列で変更される問合せです。
非対称問合せが検出されると、対称グリッドのみを処理するEssbaseハイブリッド問合せエンジンによって、複数の対称グリッドに自動的に分割されます。これらの対称グリッドは一度に1つずつ処理されてから元の非対称フォームで返されるため、プロセスの効率が低下します。

Financial Consolidation and Closeの取得パフォーマンスのトラブルシューティング

Financial Consolidation and Close環境のレポート・パフォーマンスのトラブルシューティングの詳細は、Financial Consolidation and Closeの取得パフォーマンスのトラブルシューティングを参照してください。

最近のアプリケーションの変更の確認

アプリケーションへの最近の変更に起因して、レポート生成速度が遅くなっているかどうかを特定します。そのためには、現在のアクティビティ・レポートのアプリケーション・サイズ表の情報を、レポートが良好に機能していた以前の日付のアクティビティ・レポートの情報と比較します。また、レポート設計と使用方法に対する最近の変更を確認し、それらの変更がレポートに影響を与えていないことを確認します。