初期化ブロックのメンテナンス
Oracle Analytics Cloudでデータ・ゲートウェイまたはリモート・データ・コネクタを使用すると、各問合せ実行の期間に少量のオーバーヘッドが発生します。
それは0.3秒未満であるため、レポートの実行時にこの追加の期間に気付くことはありません。 ただし、初期化ブロック問合せはシリアルに実行されるため、誰かがサインインするたびに多くの初期化ブロックが実行されると(その回数はパフォーマンス要件に応じて異なります)、パフォーマンスの問題が発生することがあります。 このトピックでは、セッション初期化ブロックの数を減らす方法を提案します。
初期化ブロックは最初のダッシュボード・ページを開いたときに実行されるため、初期化ブロックの遅延オプションを使用してもこの問題は修正されません。
「Oracle BIアプリケーション」を使用すると、200を超える初期化ブロックが実行されるため、これは問題です。 Oracle Analytics Cloudの場合、これらのパフォーマンスの問題を回避する最善の方法は、初期化ブロックの数を減らすことです。
セッション初期化ブロックの数を減らすことができる次の方法をお薦めします。
- 必要のないすべての初期化ブロックを無効にします。
たとえば、「Oracle BIアプリケーション」では、使用しなくなった「Oracle BIアプリケーション」モジュールを参照する初期化ブロックを無効にします。
- 優先順位ルールがある場合を除き、同じ接続プールを使用するすべての
row_wise
初期化ブロックをマージし、問合せ間でUNION ALL
を使用して同じデータ型を返します。たとえば:
Init block 1: query1 Init block 2: query2 Merged init block: query1 union all query2
dual
またはW_DUAL_G
からハードコードされた値を選択するすべての初期化ブロックを無効にし、対応する変数のデフォルト・イニシャライザにハードコードされた値を格納します。- デュアルからデータを選択する残りの初期化ブロックを1つの
select
文にマージします。 - 「Oracle BIアプリケーション」顧客の場合、対応する属性が使用されていない場合(標準デフォルト値
HIDE
がこれらの変数の現在の値である場合)、またはOracle Human Capital Managementを「Oracle BIアプリケーション」データ・ソースとして使用しない場合(「Oracle BIアプリケーション」に100個の初期化ブロックが存在する場合)は、Oracle Human Capital Managementカスタム属性の名前と値の取得に使用されるすべての初期化ブロックを無効にします:HR xxx Attribute yyy
row_wise
ではない残りの初期化ブロックをすべてマージし、同じ接続プールを使用します。 たとえば:初期化ブロック1は、query1に基づいています:
select colA from tableA where….
初期化ブロック2は、query2に基づいています:
select colB from tableB where….
次のような問合せを使用してそれらを単一の初期化ブロックにマージできます:
Select MAX(colA), MAX(colB) from ( select cola as cola, null as colB from tableA whereâ¦. Union all Select null, colB from tableB whereâ¦) tmp
必要な数だけUNIONを実行して、単一の問合せで同じ接続プールからすべての変数を取得できます。
この場合、実装やメンテナンスは簡単ではなく、問合せを作成してすべての変数を単一の初期化ブロックに割り当てるときに間違いが発生するリスクがあります。
初期化ブロックの問合せと変数を慎重に実装およびメンテナンスすれば、サインインして最初のダッシュボード・ページを表示するのにかかる時間を大幅に短縮できます。