レポートを生成するのに必要な時間は、レポート用のデータベースのサイズ、スクリプトに含まれるクエリーの数、およびレポート・バッファのサイズなどの要因によって決まります。
構成可能変数により、取得によって抽出されるデータの保管とソートに使用するバッファのサイズを指定します。バッファは、不要な読取りおよび書込みアクティビティを防ぐために十分な大きさである必要があります。レポート・エクストラクタを参照してください。
次のレポート変数は、条件付取得コマンドおよびデータ・ソート・コマンド内で使用します。
データベース取得バッファは、評価される前の抽出された行データ・セルを保持する、データベースごとのサーバー・バッファです。Essbaseの取得ウィザードやレポート・ライターなどの取得ツールでは、このバッファが使用されます。
取得バッファがいっぱいの場合、行は処理され、バッファは再使用されます。このバッファが小さすぎる場合は、この領域を頻繁に再使用することで取得時間が長くなる可能性があります。このバッファが大きすぎる場合、ユーザーが同時にクエリーを実行するときに使用されるメモリーが多すぎて、取得時間も長くなる可能性があります。
次の項では、取得バッファのサイズを管理する方法について説明します。
各データベースには、変更可能な取得バッファ設定(キロバイト単位)があります。デフォルトのバッファ・サイズは、32ビットのプラットフォームでは10 KB、64ビットのプラットフォームでは20 KBです。バッファのサイズを大きくする場合は、サイズ制限が100,000 KBに設定されている場合でも、100 KBを超えないようにすることをお薦めします。
取得バッファ・サイズを手動で設定するには、次のツールを使用します:
アウトラインに、動的計算メンバー、動的時系列メンバーおよび属性メンバーが含まれていない場合、VLBREPORT構成パラメータを使用すると取得バッファのサイズを動的に決定できます。その場合、データベースの取得バッファ・サイズの設定は無視されます。取得バッファ・サイズの動的な設定の使用可能化を参照してください。 |
データベースのブロック・サイズが大きく、複数のブロック全体で各ブロックから取得するセルの割合が大きい場合は、Essbase構成ファイルessbase.cfgのVLBREPORTオプションをTRUEに設定することを検討してください。
VLBREPORT設定がTRUEの場合は、Essbaseによって、複数のブロック全体で各ブロック内の20%を超えるセルへアクセスするレポート用に最適化された取得バッファ・サイズが、内部的に決定されます。この設定は、アウトラインに動的計算、動的時系列または属性メンバーが含まれていない場合のみ有効です。VLBREPORT構成設定により、手動で設定した取得バッファ・サイズが上書きされます。
VLBREPORTをTRUEに設定すると、各クエリーに必要なメモリー量はわずかに増えますが、同時クエリーや連続クエリーに対する応答時間を短縮できます。
取得ソート・バッファのサイズの設定は、レポート・ライターでの取得中、データをソートされた状態に保つサーバー・バッファのサイズを、KB単位で指定します。ソート・バッファがいっぱいになると、Essbaseによってエラー・メッセージが通知されます。
Essbaseでは、64ビットのプラットフォームには、32ビットのプラットフォームよりも大きな取得ソート・バッファが必要です。取得ソート・バッファ制限を超えたことを示すエラーが発生した場合は、この設定を2倍に増やしてください。
バッファ・サイズはデータベースごとに調整できます。デフォルトのバッファ・サイズは、32ビットのプラットフォームでは10 KB、64ビットのプラットフォームでは20 KBに設定されます。
RESTRICTコマンドで使用するNUMERICPRECISION構成設定によって、レポート・エクストラクタの内部数値比較で考慮される有効桁数が定義されます。データに必要以上の有効桁数を設定すると、取得時間が本来より長くなります。正確な有効桁数レベルを特定し、それに従ってNUMERICPRECISIONを調整してください。『Oracle Essbaseテクニカル・リファレンス』を参照してください。
レポート・ライターを使用する際、レポートの処理時間が第一に重要である場合は、すべてのレポートを対称にすることを検討してください。対称型レポートは、非対称型レポートより処理パフォーマンスが高くなります。
対称型レポートでは、レポート・エクストラクタは1パスを使用して、すべての可能なメンバーの組合せに基づいてメンバー・リストを構成します。次の例では、データ値(Actual JanおよびFebと、Budget JanおよびFeb)が1パスで取得されます。
Symmetric Report Member Combinations Supporting One Pass
Sales South
Actual Budget
Jan Feb Jan Feb
======== ======== ======== ========
100–10 757 773 930 950
100–20 450 487 550 590
100–30 #MISSING #MISSING #MISSING #MISSING
100 1,207 1,260 1,480 1,540
非対称型レポートでは、レポート・エクストラクタは可能なメンバーの組合せの各ブロックを別々に取得して処理する必要があります。次の例では、データ値(Actual JanとBudget Jan)が2パスで取得されます。
Asymmetric Report Member Combinations Requiring Multiple Passes
Sales South
Actual Budget
Jan Jan
======== ========
100–10 757 950
100–20 450 590
100–30 #MISSING #MISSING
100 1,207 1,540
レポート・エクストラクタを参照してください。
大きな次元に対するクエリーには、大抵の場合は大きなリソース要件があります。ただし、これらのクエリーは一般的には疎です。これは、戻される空以外の値の数が、入力クエリーのサイズと比べて小さいことを意味します。このような、大きくても疎のクエリーでは、Essbaseでメモリーとプロセッサのリソースをより効率的に使用するため、次のような特殊なMDXおよびレポート・ライター関数を使用することをお薦めします。これらの関数では、空以外の組合せのみの処理を試みることによって、取得パフォーマンスが最適化されます。
MDXのLeaves()関数
MDXのNonEmptySubset()関数
MDXの最適化プロパティ: NONEMPTYMEMBERおよびNONEMPTYTUPLE
レポート・ライターのLeavesコマンド
レポート・ライターのDescendantsおよびIdescendantsコマンドでの世代またはレベルの指定(Linkコマンド内で使用する場合)
レポート・エクストラクタでは、データがレポート・ライターでの特定の順序で抽出されます。フォーマットしたレポートを作成する必要がなく、レポート・ライターを使用している場合は、次のいずれかの方法を使用して、レポートの生成に要する時間を短縮できます:
大規模な運用レポートを作成する場合、これらの方法は特に効果的です。
レポート・エクストラクタでは、下から上、右から左にデータが検索され、まず下端の列メンバーから上端の列メンバーへ検索され、次に、最も内側の行メンバー(右)から最も外側の行メンバー(左)へ検索されます。
次の例では、列メンバーは密次元から取得され、行メンバーは疎次元から取得されます。レポートが読み取られる順序は、(1)のように、丸カッコで囲まれた1から3の数字で表されます:
Sales South
(3) Actual Budget (2)
Jan Jan (1)
======== ========
100–10 757 950
100–20 450 590
100–30 #MISSING #MISSING
100 1,207 1,540
データを抽出するための時間を短縮するには、まず密次元をグループ化し、次に、アウトライン内で表示される順序で、疎次元をグループ化します。
レポート列で密次元をネストすると、レポート・エクストラクタでは各データ・ブロックが一度のみ検査され、パフォーマンス時間が向上します。
属性は疎次元であり、動的に計算されるため、Essbaseでは、レポートに属性次元が含まれる場合は、疎のデータ抽出方法を使用できません。
動的計算および保管メンバーが含まれるデータベース・アウトラインにアクセスするレポートを生成する場合、最初にレポートを生成する時間が、以降に同じデータ・ブロックにアクセスして取得する時間より長くかかります。
動的計算または動的時系列メンバーが含まれるデータベース・アウトラインにアクセスするレポートを生成する場合、Essbaseでは、レポートの生成のたびにメンバーが計算され、レポート生成の時間が増大します。
データ値の動的計算。を参照してください。
透過メンバーが含まれるレポートを実行すると、必要なデータの取得で、複数のサーバーへアクセスする必要があるため、レポートの生成時間が増大します。
ユーザーがデータベースにリンクできるファイルのサイズは、制限できます。サイズを制限することで、ユーザーが非常に大きなオブジェクトを格納することによってサーバーのリソースが過度に消費されるのを防止できます。ストレージ保持のためのLROファイル・サイズの制限を参照してください。