| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 11g リリース1 (11.1.1) B63028-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 11g リリース1 (11.1.1) B63028-03 |
|
前 |
次 |
この章では、Oracle Business Intelligenceで集計の永続性を設定し、使用する方法について説明します。
データ・ウェアハウスの多くの専門家は、高度に集約された問合せのパフォーマンスを大幅に向上させるために集計データ表を作成します。これらの集計表にはあらかじめ計算された結果が格納され、その結果はディメンションの一連の属性を範囲とする集計メジャー(通常は合計)です。集計表の使用は、意志決定サポート・システムにおいて問合せの応答時間を向上させるために一般的に使用されるテクニックです。
SQL問合せを使用する場合、またはどの表が存在するかのみを理解しその意味を理解していないツールを使用する場合、集計表の数が増加するにつれて集計表の使用がより複雑になります。Oracle BIサーバーの集計ナビゲーション機能を利用すると、問合せにおいて集計表に格納されている情報を自動的に使用することが可能になります。Oracle BIサーバーを利用することにより、ユーザーは適切なビジネス上の質問を行うことに集中でき、最も高速に回答を返す表がどれであるかはサーバーによって判断されます。
Oracle Business Intelligenceには、ソース・データベース内の集計を利用するための集計ナビゲーション機能があります(詳細は第11章を参照)。ただし、データ集計の作成と維持、およびデータベース・スクリプトのロードと対応するメタデータのマッピングには時間がかかることがあります。そのため、Oracle Business Intelligenceには、集計表の作成とロード、およびOracle Business Intelligenceの対応するメタデータのマッピングを自動化する、集計の永続性機能が用意されています。
この章には次のトピックが含まれます:
集計の永続性を使用して、Oracle BIサーバーの問合せ用の集計を作成します。集計の永続性ウィザードを使用することにより、集計指定スクリプトの作成が自動化されます。このスクリプトを稼働中のOracle BIサーバーに対して実行すると、集計の永続性エンジンによって集計表が作成され、ナビゲーション用のメタデータにマップされます。集計の永続化を行うと、パフォーマンス向上のための索引および統計がリレーショナル表に作成されます。
集計の永続性ウィザードは、Oracle BIサーバーに対して、スケジュールに基づいて実行できるSQLスクリプトを作成します。集計の永続性ウィザードで、自身のパフォーマンス・デザインに基づいて、各スターまたはキューブのメジャー、ディメンションおよびその他のパラメータを指定します。このスクリプトは、ベースレベル表の各ロードの後に実行する必要があり、それによって、ロード・ウィンドウが完了してユーザーが問合せの実行を始めるときには、常に、集計が詳細レベルのデータと同期しているようになります。
集計作成は、クラスタ内のマスター・サーバーに対して実行します。メタデータの変更がスレーブに伝播されるまで多少時間がかかります。クラスタのリフレッシュ時間はユーザーによる制御が可能なオプションですが、スレーブ・サーバーがリフレッシュされる前にスレーブ・サーバーに対する問合せが行われると、正しくない結果が返される可能性があります。適切なクラスタ・リフレッシュ間隔を設定するのは管理者の役目です。
集計の永続性では、集計が格納されるターゲット・データベースに表またはキューブを作成するための専用の接続プールが必要になります。Oracle BIリポジトリではフェデレーションが可能なため、集計のターゲットは、詳細ソースと同じデータベース、完全に別のデータベースのいずれでも構いません。この専用の接続プールは、集計の永続性ウィザードの手順の中で選択するため、このウィザードを実行する前に作成する必要があります。
ディメンション(レベル)の集計には、デフォルトの接頭辞SA_が自動的に追加されます。NQSConfig.INIファイルのAGGREGATE_PERSISTENCEセクションにあるAGGREGATE_PREFIXパラメータを更新することによって、このデフォルトの接頭辞を変更することができます。
AGGREGATE_PREFIX = "prefix_name" ;
集計を格納するのに使用されるターゲット・スキーマは適切に保護する必要があり、パブリック・アクセスを許可してはいけません。このスキーマには、表や索引への接続、およびそれらの作成や削除に関する権限を設定する必要があります。デフォルトでは、BIAdministratorsグループに属するユーザーのみが集計を管理できます。
仮想プライベート・データベース(VPD)のセキュリティ・フィルタがアクティブになっている表に対しては、集計の永続性を使用しないでください。VPDフィルタが適用されずに集計情報が永続化される可能性があり、セキュリティ上のリスクが生じます。
集計の作成時には、集計データによって大きな利点が得られるのはどの問合せであるかを特定する必要があります。可能なかぎり高いレベルで集計することによって、最良の結果が得られます。遅い問合せを特定するには、次のタスクを実行します。
Oracle BIサーバーの使用状況トラッキングを有効にします。使用状況トラッキングの統計情報は、データベースの最適化、集計の戦略、ユーザーや部門が利用したリソースに基づく課金など、様々な方法で利用できます。Oracle BIサーバーは、詳細な問合せレベルで使用状況を追跡します。使用状況トラッキングを有効にすると、すべての問合せの統計情報が使用状況ログ・ファイルに書き込まれるか、またはデータベースの表に挿入されます。
|
注意: 使用状況トラッキングでは、データベースへの直接インサートの手法を使用することを強くお薦めします。使用状況トラッキングの完全な情報は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の使用状況トラッキングの管理に関する項を参照してください。 |
問合せの実行時間を分析し、最も時間のかかる問合せを集計の候補として特定します。集計の作成にかかる実行時間は、ユーザーが選択する集計の種類によって異なります。大きなファクト表の集計作成は、小さな表よりも時間がかかります。作成する集計の選択は慎重に行ってください。
Oracle Exalytics Machine上でOracle Business Intelligenceを実行している場合、Oracle BIサマリー・アドバイザ機能を使用して、問合せのパフォーマンスが向上するのはどの集計であるのか特定し、推奨集計を作成するスクリプトを生成できます。
|
注意: Oracle Exalytics Machine上でOracle Business Intelligenceを実行していない場合、Oracle BIサマリー・アドバイザ機能は使用できません。 |
この項には次のトピックが含まれます:
問合せ時間を短縮するために、ロールアップ・データを含む問合せに対して事前に計算された結果を格納する集計表を作成できます。ただし、集計を作成する前に、使用状況トラッキング統計を分析し、問合せのパフォーマンスが向上するのはどの集計であるのかを特定する必要があります。多くの時間と労力を要する手動による集計の特定のかわりに、特定のリソースの制約を満たしつつ、最大の問合せパフォーマンスを得られる問合せパターンに基づいた集計表の最適なリストをインテリジェントにお薦めするサマリー・アドバイザ機能を使用できます。その後、サマリー・アドバイザによって集計作成スクリプトが生成され、それを実行すると、推奨集計表を作成できます。
サマリー・アドバイザ機能には、次のようないくつかの部分があります。
指定された統計データベースへの統計収集。サマリー・アドバイザ統計を収集するには、使用状況トラッキング機能を有効化する必要があります。
収集された統計と推奨集計を評価するための、管理ツールのサマリー・アドバイザ・ウィザードによるサマリー・アドバイザの実行。
後続の項では、これらの作業を説明します。
サマリー・アドバイザで推奨を生成するには、その前に、サマリー・アドバイザが使用する使用状況統計の代理サンプルを取得する必要があります。この作業を実行するには、次の方法のいずれかを使用します。
本番システム上で、使用状況トラッキングおよびサマリー・アドバイザ・ロギングを有効化し、数日間にわたってユーザーにBIサーバーに対する問合せを実行してもらいます。サマリー・アドバイザ統計表に、使用状況統計が移入されます。詳細は、「使用状況トラッキングの有効化」および「サマリー・アドバイザ・ロギングの有効化」を参照してください。
使用状況トラッキングとサマリー・アドバイザ・ロギングを有効化すると、本番システムのパフォーマンスにわずかに影響します。
テスト環境で、Oracle BIサーバーに対して代理ワークロードを実行し、サマリー・アドバイザ統計を収集します。代理ワークロードは、一般的に要求される論理SQL文のリストです。通常、代理ワークロードは本番環境から取得します。
代理ワークロードが用意できたら、テスト環境のOracle BIサーバーで使用状況トラッキングとサマリー・アドバイザ・ロギングを有効化し、nqcmdユーティリティを使用してそのOracle BIサーバーに対してワークロードを実行します。nqcmdの使用方法の詳細は、「リポジトリのテストおよび絞込みのためのnqcmdの使用方法」を参照してください。サマリー・アドバイザ統計表に、使用状況統計が移入されます。
システムで、使用状況トラッキングは有効化されていたが、サマリー・アドバイザ・ロギングは有効化されていなかった場合は、サマリー・アドバイザ統計の生成ツールを実行して、使用状況トラッキング・データをサマリー・アドバイザ統計表に転送できます。このシナリオは、11.1.1.6.0より前のユーザーがOracle BIサマリー・アドバイザ機能のあるOracle BI Enterprise Editionの最新バージョンにアップグレードする場合が対象となります。これらのユーザーは、使用状況トラッキング・データを持っていても、サマリー・アドバイザ統計を持っていない場合があります。
サマリー・アドバイザ統計表に代理データが移入された後、サマリー・アドバイザによってデータを分析し、集計の推奨を生成して問合せを高速化できます。
これを行うには、管理ツールのOracle BIサマリー・アドバイザ・ウィザードを実行して集計指定を生成し、nqcmdを使用してその集計指定を使用して集計を作成します。詳細は、「Oracle BIサマリー・アドバイザ・ウィザードの使用方法」および「Oracle BIに対する集計指定の実行」を参照してください。
現在、Oracle BIサマリー・アドバイザでは、Oracle TimesTen In-Memory Database上の集計の作成のみがサポートされています。サポートされるバージョンについては、「システム要件と動作要件」を参照してください。
同じオプションを再度入力することなく、後でOracle BIサマリー・アドバイザ・ウィザードを再実行できるように、サマリー・アドバイザのオプションをファイルに保存することもできます。
Oracle BIサマリー・アドバイザ機能を使用する前に、収集した統計を格納するデータベースを設定する必要があります。ターゲット・データベースでリポジトリ作成ユーティリティ(RCU)を実行し、必要な統計スキーマを作成する必要があります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』のリポジトリ作成ユーティリティ(RCU)を使用したデータベース・スキーマの作成に関する項を参照してください。
通常、Oracle Business Intelligenceとともに使用するためにインストールしたデータベースを統計データベースとして使用します。それは、このデータベースにはすでにRCUで作成したスキーマが存在するためです。サマリー・アドバイザ用にRCUで作成した表の名前は、S_NQ_SUMMARY_ADVISORです。
また、そのデータベースを、Oracle BIリポジトリの物理レイヤーにインポートすることも必要です。
サマリー・アドバイザには、使用状況トラッキングに使用するものと同じデータベースを使用する必要があります。使用状況トラッキング用にデータベースとスキーマをすでに設定済である場合は、この項の手順を省略できます。
統計データベースを設定する手順は、次のとおりです。
選択した外部データベース上でリポジトリ作成ユーティリティを実行します。Oracle Business Intelligenceとともに使用するためにインストールしたデータベースをサマリー・アドバイザ統計に使用するように選択した場合は、そのデータベースには、すでにRCUで作成された表があるため、この手順を省略できます。
管理ツールを開き、データベースを物理レイヤーにインポートします。詳細は、「リレーショナル・データ・ソースからのメタデータのインポート」を参照してください。
リポジトリを保存して閉じます。
Fusion Middleware Controlを使用して、リポジトリをアップロードし、問合せに使用できるようにします。詳細は、「リポジトリを問合せで使用可能にする」を参照してください。
サマリー・アドバイザ統計を収集する前に、使用状況トラッキングを有効化する必要もあります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の使用状況トラッキングの管理に関する項を参照してください。
統計を収集する準備ができたら、サマリー・アドバイザ・ロギングを有効化できます。新しい(アップグレードしたものではない)インストールの場合、サマリー・アドバイザ・パラメータは中央で管理します。Fusion Middleware ControlのシステムMBeanブラウザを使用して、サマリー・アドバイザ・パラメータを設定します。
システムMBeanブラウザを使用してサマリー・アドバイザ・ロギングを有効化する手順は、次のとおりです。
Fusion Middleware Controlの「ナビゲータ」ウィンドウで、「WebLogicドメイン」フォルダを開き、bifoundation_domainノードを開きます。
「AdminServer」ノードを右クリックし、「システムMBeanブラウザ」を選択します。
「アプリケーション定義のMBeans」を開き、oracle.biee.adminを開いてbifoundation_domainを開きます。
次のようにしてそのドメインをロックします。
BIDomainを開き、group=ServiceのBIDomain MBeanを選択します。
「操作」タブを表示します。
「ロック」リンクをクリックします。
BIDomain.BIInstance.ServerConfigurationを開き、BIDomain.BIInstance.ServerConfiguration MBeanを選択します。
UsageTrackingCentrallyManaged属性がtrueに設定されていることを確認します。UsageTrackingCentrallyManagedがfalseに設定されている場合は、次のパラメータは、システムMBeanブラウザではなく、各Oracle BIサーバー・コンピュータ上のNQSConfig.INIファイルを使用して管理します。
SummaryAdvisorTableName
SummaryStatisticsLogging
UsageTrackingConnectionPool
UsageTrackingDirectInsert
UsageTrackingEnabled
UsageTrackingPhysicalTableName
統計を収集するデータベース表の完全修飾名にSummaryAdvisorTableName属性を(Oracle BIリポジトリの物理レイヤーに表示されているとおりに)設定します。例:
"My_DB"."DEV_BIPLATFORM"."S_NQ_SUMMARY_ADVISOR"
指定する表名は、使用状況トラッキングに使用するものと同じデータベース・オブジェクトおよび接続プールに属している必要があります。
SummaryStatisticsLoggingを次のいずれかのオプションに設定します。
サマリー・アドバイザ・ロギングを有効にするには、YESと入力します。
外部結合を含む論理問合せに対してのみサマリー・アドバイザ・ロギングを有効にするには、LOG_OUTER_JOINT_QUERIES_ONLYと入力します。サマリー・アドバイザ・ロギングを完全に有効にすることで生じるパフォーマンスへの多少の影響が気になる場合は、このオプションの使用を検討してください。
変更を適用した後、次のようにしてドメインのロックを解放します。
oracle.biee.admin、Domain:bifoundation_domain、BIDomainの下のgroup=ServiceのBIDomain MBeanに戻ります。
「操作」タブを表示します。
コミット操作の1つをクリックします。
Oracle Business Intelligenceの「概要」ページに移動し、「再起動」をクリックします。
アップグレードのお客様の場合は、サマリー・アドバイザ・パラメータはデフォルトでは中央で管理されません。前の手順で説明したようにUsageTrackingCentrallyManagedをtrueに設定し、システムMBeanブラウザを使用してパラメータを更新するか、NQSConfig.INIを使用してサマリー・アドバイザ・パラメータを管理できます。
これらのパラメータに対して中央管理が無効になっている場合にNQSConfig.INIでサマリー・アドバイザ・ロギングを有効化するには、次の手順に従います。
Oracle BIサーバー・コンピュータで、テキスト・エディタでNQSConfig.INIファイルを開きます。このファイルは、次の場所にあります。
ORACLE_INSTANCE/config/OracleBIServerComponent/coreapplication_obisn
編集する前に、ファイルのバップアック・コピーを作成します。
[USAGE_TRACKING]セクションで、次のパラメータを更新します。
SUMMARY_STATISTICS_LOGGINGを次のいずれかのオプションに設定します。
YES: サマリー・アドバイザ・ロギングを有効にします。
LOG_OUTER_JOINT_QUERIES_ONLY: 外部結合を含む論理問合せに対してのみサマリー・アドバイザ・ロギングを有効にします。サマリー・アドバイザ・ロギングを完全に有効にすることで生じるパフォーマンスへの多少の影響が気になる場合は、このオプションの使用を検討してください。
統計を収集するデータベース表の完全修飾名にSUMMARY_ADVISOR_TABLE_NAMEを(Oracle BIリポジトリの物理レイヤーに表示されているとおりに)設定します。例:
SUMMARY_ADVISOR_TABLE_NAME = "My_DB"."DEV_BIPLATFORM"."S_NQ_SUMMARY_ADVISOR";
指定する表名は、使用状況トラッキングに使用するものと同じデータベース・オブジェクトおよび接続プールに属している必要があります。
ファイルを保存して閉じます。
Oracle BIサーバーを再起動します。
複数のOracle BIサーバー・インスタンスがある場合は、すべてのOracle BIサーバー・インスタンスについて、各NQSConfig.INIファイルでこれらの手順を繰り返します。
サマリー・アドバイザ統計を生成した後、管理ツールのOracle BIサマリー・アドバイザ・ウィザードを実行して集計指定スクリプトを生成し、それを実行して集計を作成できます。サマリー・アドバイザ・ウィザードは、オンライン・モードでのみで実行できます。
サマリー・アドバイザ・ウィザードを実行する前に、物理レイヤーに集計を作成する予定のターゲット・データベースをマップする必要があります。これを行うには、必要なデータベース、接続プールおよび物理スキーマ・オブジェクトを手動で作成します。
Oracle BIサマリー・アドバイザ・ウィザードを実行する手順は、次のとおりです。
オンライン・モードで、管理ツールでリポジトリを開きます。
モデル・チェック・マネージャを実行して、リポジトリに、Oracle BIサマリー・アドバイザのパフォーマンスと結果に影響を及ぼすモデリングの問題が含まれていないことを確認することをお薦めします。詳細は、「モデル・チェック・マネージャを使用したモデリングの問題のチェック」を参照してください。
|
注意: モデル・チェック・マネージャは、一部のチェックのためにバックエンドのデータ・ソースに対して問合せを実行するので、オフピーク時に実行することをお薦めします。また、大規模なリポジトリに対してモデル・チェック・マネージャを実行すると、長い時間がかかることがあります。パフォーマンスを向上させるには、「統計によるフィルタ処理」を使用するか、選択したオブジェクトに対してのみモデル・チェック・マネージャを実行するようにしてください。 |
「ツール」→「ユーティリティ」を選択します。
スクロールして「Oracle BIサマリー・アドバイザ」を選択し、「実行」をクリックします。
Oracle BIサマリー・アドバイザ・ウィザードは、Oracle Exalytics Machine上でOracle Business Intelligenceを実行している場合にのみ使用できます。
Oracle BIサマリー・アドバイザ・ウィザードの最初のページの「フィルタ・ログ - 論理ファクト表」で、オプションでサマリー・アドバイザの推奨を生成する特定の論理ファクト表を選択できます。デフォルトでは、すべての論理ファクト表が含められています。
Oracle BIサマリー・アドバイザ・ウィザードを以前に使用したことがあり、フィルタ基準、ターゲットおよびその他のオプションをXMLファイルとして保存してある場合は、「ファイルからパラメータのロード」をクリックし、前に保存したオプションを現在のウィザード・セッションにロードできます。ファイルへの基準の保存の詳細は、手順11を参照してください。
サマリー・アドバイザ表(システムMBeanブラウザのSummaryAdvisorTableName、またはNQSConfig.INIのSUMMARY_ADVISOR_TABLE_NAMEパラメータで指定)が空である場合、サマリー・アドバイザは続行できません。「統計の生成」をクリックし、既存の使用状況トラッキング・データに基づいてサマリー・アドバイザ・ロギング統計を生成します。詳細は、「統計を生成するためのOracle BIサマリー・アドバイザ統計ジェネレータの使用方法」を参照してください。
次の画面に進む準備ができたら、「次」をクリックします。
「フィルタ・ログ - 時間ウィンドウ」画面で、オプションで、期間に基づいてサマリー・アドバイザ・ロギング統計にフィルタを適用できます。これを行うには、サマリー・アドバイザの実行に含める統計の「開始日」および「終了日」を入力します。期間を入力したら、「更新」をクリックして、ビューをリフレッシュします。
次の画面に進む準備ができたら、「次」をクリックします。
「フィルタ・ログ - 実行時間しきい値」画面で、オプションで、論理表ソースごとに最小問合せ時間しきい値を設定することでフィルタを適用できます。たとえば、「最小累積時間」に5秒を指定した場合、累積合計問合せ時間が5秒以上の論理表ソースのみがサマリー・アドバイザの推奨に含められます。
次の画面に進む準備ができたら、「次」をクリックします。
「ターゲット」画面で、集計用のターゲット・コンテナおよび関連付ける接続プールを選択します。この場所に、集計表が作成されます。オプションで、複数のターゲット・コンテナを指定できます。
「データベース・スキーマ」、「接続プール」、およびターゲットの「容量」(MB単位)を指定し、「ターゲットの追加」をクリックしてリストにそれを追加します。「すべてクリア」をクリックしてターゲットの既存のリストをクリアするか、個別のターゲットの横にある「削除」ボタンをクリックしてそれを削除します。
Oracle BIサマリー・アドバイザでの使用に対して現在サポートされているのは、Oracle TimesTen In-Memory Databaseのデータベース・スキーマのみです。
次の画面に進む準備ができたら、「次」をクリックします。
「ファイルの場所の選択」画面で、「参照」をクリックし、集計指定(SQLスクリプト)を格納する場所を選択します。
「次へ」をクリックします。
「停止基準」画面で、次のように推奨のこのセットに対してオプションで実行の制約を指定できます。
結果を返すまでのサマリー・アドバイザの最長実行時間を指定できます。
新しい集計を追加する際に、そのワークロードで影響を受けるすべての問合せのパフォーマンスに対する最小向上パーセンテージを指定できます。
サマリー・アドバイザは、反復最適化アルゴリズムを使用します。サマリー・アドバイザでは、反復の回ごとに、異なるセットの集計が評価されます。この画面で最小向上パーセンテージを指定すると、サマリー・アドバイザによって、2つの連続する回の推定される向上が比較され、その向上が、指定した最小パーセンテージに満たない場合は停止されます。
各回の推定される向上を示す計算式は次のとおりです。
Estimated Gain = [(total query time at the beginning of the round) - (total query time at the end of the round)] / (Initial total query time prior to the first round)
例:
初期合計問合せ時間= 1000秒
1回目の終わり:
合計問合せ時間= 500秒
向上= (1000 - 500)/1000 = 50%
2回目の終わり:
合計問合せ時間= 250秒
向上= (500 - 250)/1000 = 25%
次の画面に進む準備ができたら、「次」をクリックします。
「その他」画面で、オプションで、1つの集計の最大サイズをMB単位で指定できます。将来のサマリー・アドバイザ・セッションで再使用するために、このセッションの基準およびオプションを格納するXML出力ファイルの場所を指定することもできます。
「次へ」をクリックします。
「実行」画面で、「実行」をクリックし、サマリー・アドバイザ・プロセスを使用して推奨を生成します。
このプロセスを停止するには、任意の時点で「停止」をクリックします。サマリー・アドバイザを停止したり、完了するまで実行した場合は、それまでに見つかった集計の推奨が表示されます。
このプロセスが完了したら、「次へ」をクリックします。
「フィルタ集計」画面で、集計の推奨の現在のセットを確認します。オプションで、特定の集計の行の「含める」オプションをオフにすることで、それを作成プロセスから除外できます。
「次へ」をクリックします。
「スクリプトの終了」画面で、生成されるスクリプトを確認します。問題がない場合は、「終了」をクリックしてスクリプトを保存します。
SQLファイルを使用した集計表の作成の詳細は、「Oracle BIに対する集計指定の実行」を参照してください。
Oracle BIサマリー・アドバイザ統計ジェネレータを使用して、既存の使用状況トラッキング・データに基づいてサマリー・アドバイザ・ロギング統計を生成できます。
統計ジェネレータを実行するユーザーは、oracle.bi.server.impersonateUser権限を持っている必要があります。権限の管理の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のFusion Middleware Controlを使用したアプリケーション・ポリシーの作成に関する項を参照してください。
Oracle BIサマリー・アドバイザ統計を生成する手順は、次のとおりです。
Oracle BIサマリー・アドバイザ・ウィザードの最初のページで「統計の生成」をクリックすることで、統計ジェネレータを起動します。「Oracle BIサマリー・アドバイザ統計ジェネレータ」画面が表示されます。
図13-1は、統計ジェネレータの画面を示しています。
「コンテナ」および「表」には、使用状況トラッキング・データ(入力表)を含むOracle BIリポジトリの物理表の完全修飾名を形成する適切なオプションを選択します。この表に基づいた問合せは、サマリー・アドバイザ統計を生成するために使用されます。
UsageTrackingPhysicalTableName MBean、またはNQSConfig.INIのPHYSICAL_TABLE_NAMEパラメータで指定されているものとは異なる入力使用状況トラッキング表を指定することをお薦めします。異なる表を指定することで、入力使用状況トラッキング表が、統計ジェネレータの実行によって生成される新しいデータから影響を受けることはなくなります。
また、入力使用状況トラッキング表のQUERY_BLOB物理列オブジェクトは、基盤となるデータに合った長さを持っている必要があります。これは、統計ジェネレータがそれから論理SQL文字列を読み取るときに、切捨てが行われないようにするために必要です。QUERY_BLOB列が存在しない場合、統計ジェネレータはQUERY_TEXT列から論理SQL文字列を読み取ります。
「開始日」および「終了日」には、オプションで、使用状況トラッキング・データにフィルタを適用するための開始日と終了日を入力します。指定した日もデータ範囲に含まれます。
「最短問合せ時間」には、オプションで、問合せ時間にフィルタを適用するための秒数を入力します。このフィルタを指定すると、指定した値以上の時間がかかる問合せの使用状況トラッキング・データのみが使用されます。
「論理レポジトリ名」には、オプションで、リポジトリ名にフィルタを適用するための1つ以上のOracle BIリポジトリの名前を入力します。このフィルタを指定すると、これらのリポジトリに対して要求された問合せの使用状況トラッキング・データのみが使用されます。
値はカンマ区切り形式(RPD_name_1[,RPD_name_2,...])で指定します。
オプションで、そのような問合せを含めるには「行制限を超えた問合せを含める」を選択します。このオプションを選択しない場合は、正常に完了した問合せの使用状況トラッキング・データのみが使用されます。
「実行モード」については、サマリー・アドバイザ統計の生成中の物理問合せの実行を可能にするには、オプションで「より正確なタイミング・データを生成する問合せの実行(低速)」を選択します。
「統計の生成」をクリックし、指定した使用状況トラッキング・データからOracle BIサマリー・アドバイザ統計を生成します。
集計の永続性ウィザードを使用してSQLファイルを作成すると、それを使用して集計表を作成およびロードし、それらをメタデータにマップできます。この結果作成されるSQLファイルは、実行中のOracle BIサーバーに対して実行する必要があります。
集計の永続性ウィザードは集計指定の生成時に必要な多くの制約を自動的に適用するため、このウィザードの使用を強くお薦めします。ただし、このウィザードを使用せずに、集計論理SQLを手動で記述することもできます。独自の集計指定を記述する場合は、「集計指定作成の手動での記述」に記載されているガイドラインに従ってください。
集計の永続性ウィザードを実行する前に、物理レイヤーに集計を作成する予定のターゲット・データベースをマップする必要があります。これを行うには、必要なデータベース、接続プールおよび物理スキーマ・オブジェクトを手動で作成します。
|
注意: Oracle Exalytics Machine上でOracle Business Intelligenceを実行している場合、集計の永続性ウィザードのかわりにサマリー・アドバイザ機能を使用して、問合せのパフォーマンスが向上するのはどの集計であるのか特定し、推奨集計を作成するスクリプトを生成できます。詳細は、「集計の問合せの候補を特定するためのOracle BIサマリー・アドバイザの使用方法」を参照してください。 |
集計の永続性ウィザードを使用するには:
モデル・チェック・マネージャを実行して、リポジトリに、集計の作成とパフォーマンスに影響を及ぼすモデリングの問題が含まれていないことを確認することをお薦めします。詳細は、「モデル・チェック・マネージャを使用したモデリングの問題のチェック」を参照してください。
|
注意: モデル・チェック・マネージャは、一部のチェックのためにバックエンドのデータ・ソースに対して問合せを実行するので、オフピーク時に実行することをお薦めします。また、大規模なリポジトリに対してモデル・チェック・マネージャを実行すると、長い時間がかかることがあります。パフォーマンスを向上させるには、「統計によるフィルタ処理」を使用するか(使用可能な場合)、選択したオブジェクトに対してのみモデル・チェック・マネージャを実行するようにしてください。 |
管理ツールでリポジトリを開きます(まだ開いていない場合)。
モデル・チェック・マネージャは、オンライン・モードで実行する必要があります。ただし、集計の永続性・ウィザードは、オンライン・モードでもオフライン・モードでも実行できます。
「ツール」→「ユーティリティ」→「集計の永続性」を選択し、「実行」をクリックします。
「ファイルの場所の選択」画面で、集計作成スクリプトの完全なパスおよびファイル名を指定します。新しいファイル名、既存のファイル名のいずれも指定することができます。
通常、Oracle BIサーバーに対してSQLスクリプトを実行する場合、DDLが作成され、それがターゲット・データベース・スキーマに対して実行され、集計表が作成されます。次に、ソースからそれらがロードされ、最後にOracle BIサーバーのメタデータが作成されます。これにより、集計ナビゲーション機能で新しい表が使用できるようになります。
また、Oracle BIサーバーのSQLスクリプトとは別のファイルにDDLを保存する場合は、ターゲットDDLを別のファイルに生成を選択することもできます。このオプションを選択すると、自動生成されたDDLを変更して、それをOracle BIサーバーから独立して実行することが可能になり、柔軟性が向上します。たとえば、記憶域パラメータや索引の設定を変更することができます。
別のファイルにターゲットDDLを生成を選択すると、2つのSQLスクリプトが「場所」フィールドに指定したディレクトリに生成されます。
集計作成スクリプト(script_name)
集計準備スクリプト(script_name_DDL)
別のファイルにターゲットDDLを生成を選択し、ウィザードのステップを完了した後は、一般的に次のように実行します。
サーバーに対して、集計準備スクリプトを実行します。このアクションによって、次の場所にDDLファイルが作成されます。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\ aggr
生成されたDDLファイルをターゲット・データベースに対して実行し、表を作成します。
集計作成スクリプトを実行し、表に移入します。
「ファイルの場所の選択」画面でオプションの指定が完了したら、「次へ」をクリックします。
「ビジネス・メジャーの選択」画面で、集計するメジャーを選択します。これを行うには、上部ペインでビジネス・モデルを選択し、次に下部ペインで1つのファクト表またはメジャーのセットを選択します。複数のファクト表にまたがるメジャーを選択することはできません。複数のメジャーを選択するには、[Ctrl]キーを押しながらクリックします。連続する範囲のメジャーを選択するには、[Shift]キーを押しながらクリックします。
最初の集計表ブロックの作成時には、「スクリプトの表示」ボタンは利用できないことに注意してください。
図13-2は、「ビジネス・メジャーの選択」画面を示しています。
適切なメジャーを選択したら、「次へ」をクリックします。
「レベルの選択」画面で、1つ以上のディメンションの論理レベルを選択することによって集計のレベルを指定します。ファクト-ディメンションの結合で使用される代理キーを指定することができます。
集計対象のファクト表とディメンション表の間のデフォルトの結合オプションは、選択した論理レベルに定義されている主キーです。このレベルの主キーが大きくて複雑である場合、ファクト表への結合はコストが高くなります。したがって、この場合は代理キーを使用することをお薦めします。代理キーは人工的に生成されたキーであり、通常は数字です。たとえば、レベル集計表内の代理キーはこの結合を簡素化させ、ファクト表から不要な(レベルの主キーの)列が削除されます。これにより、ファクト表は軽量化されます。
代理キーの使用によって変化するのは問合せの応答時間のみであり、問合せの論理的な結果に違いはありません。ただし、代理キーの生成によって集計表のロード時間が長くなるという副作用が生じる場合があります。したがって、推奨設定は次のようになります。
選択した論理レベルの主キーが単一の数値列である場合、通常は代理キーを使用するオプションは選択しません。なぜなら、これを選択してもパフォーマンス上のメリットはなく、ロード処理にかかる時間が増えるだけだからです。
選択した論理レベルの主キーがテキスト文字列であるか、または複数の論理列から構成されている場合は、この集計ディメンションに結合される問合せのパフォーマンスを向上させるため、通常は代理キーを使用します。ただし、代理キーの生成によって、その集計ディメンション表のロード時間が長くなる場合があることに注意してください。
代理キーの詳細は、「ディメンション集計表への代理キーの追加」を参照してください。
図13-3は、「レベルの選択」画面を示しています。
適切な集計レベルを選択したら、「次へ」をクリックします。
「接続プールの選択」画面で、集計表の場所を指定するための適切な項目を選択します。
デフォルトの集計表の名前が設定されており、表の名前に接頭辞が付加されています。生成されるファクト表のデフォルトの接頭辞はagです。ディメンション(レベル)集計用に作成される表のデフォルトの接頭辞はSA_であり、これはNQSConfig.INIのAGGREGATE_PREFIXプロパティを更新することによって変更できます。構成設定の変更の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。
図13-4は、「接続プールの選択」画面を示しています。
接続プールの情報を設定したら、「次へ」をクリックします。
「終了」画面では、「スクリプトの表示」ボタンが利用可能になっており、論理SQLスクリプトを表示して確認することができます。別の集計を定義するか(デフォルト)、またはウィザードを終了するかを選択し、「次へ」をクリックします。
「スクリプトの終了」画面に、完全なパスとファイル名が表示されます。「終了」をクリックします。
SQLファイルを使用した集計表の作成の詳細は、「Oracle BIに対する集計指定の実行」を参照してください。
この項では、モデル・チェック・マネージャを使用して、Oracle BIサマリー・アドバイザと集計の永続性エンジンに影響を及ぼす可能性のあるモデリングの問題をチェックする方法について説明します。
この項には次のトピックが含まれます:
モデル・チェック・マネージャを使用して、一意でないレベル主キーの特定など、Oracle BIサマリー・アドバイザと集計の永続性エンジンの正常な実行に影響を及ぼす可能性のある問題についてリポジトリ・メタデータをチェックできます。
モデル・チェック・マネージャの実行のユーザー・エクスペリエンスは、整合性チェック・マネージャの実行に非常によく似ていますが、これら2つのツールには、次のような3つの主な違いがあります。
モデル・チェック・マネージャは、整合性チェック・マネージャとは異なり、一部のチェックのために、サマリー統計表(「統計によるフィルタ処理」の使用時)およびバックエンドのデータ・ソースへのアクセスを必要とします。バックエンド問合せの一部は高負荷になる可能性があるため、モデル・チェック・マネージャはオフピーク時に実行することをお薦めします。
モデル・チェック・マネージャは、オンライン・モードでのみ実行できます。
モデル・チェック・マネージャは、リポジトリ・メタデータに何も変更を加えません。問題の可能性があることを示すフラグを設定するだけです。
モデル・チェック・マネージャは、整合性チェック・マネージャと同様に、エラー・メッセージと警告メッセージの両方を返します。モデル・チェック・マネージャによって特定されたエラーを修正する必要があります。そうしないと、Oracle BIサマリー・アドバイザによる推奨事項が正しくないものになったり、集計の永続性エンジンによる集計の作成が失敗したりすることがあります。警告を修正することをお薦めしますが、必須ではありません。警告で特定された問題は、Oracle BIサマリー・アドバイザによる推奨事項の的確性を損なったり、集計の永続性エンジンのパフォーマンスを低下させたりすることにつながります。
Oracle BIサマリー・アドバイザに対しては、Oracle BIサマリー・アドバイザ・ウィザードの実行前ではなく、サマリー・アドバイザ統計の収集後にモデル・チェック・マネージャを実行します。集計の永続性に対しては、集計の永続性・ウィザードの実行直前にモデル・チェック・マネージャを実行します。または、初期集計作成の失敗後、モデル・チェック・マネージャを実行して、選択したオブジェクトに関する問題を特定することができます。
モデル・チェック・マネージャをグローバルに実行するには、「ファイル」メニュー→「モデルのチェック」を選択します。サブメニューから次のいずれかのオプションを選択します。
完全: すべてのオブジェクトをチェックします。
統計によるフィルタ処理: 統計表に従ってアクティブに問合せされたファクト表オブジェクトおよび関連するディメンションのみをチェックします。大規模なリポジトリに対するプロセスを高速化するには、このオプションを選択します。
このオプションは、Oracle Exalytics Machineでのみ使用可能です。Exalytics以外のシステムで統計によるフィルタ処理を実行しようとしたり、統計表が使用可能でないときにフィルタ処理を実行しようとしたりすると、モデル・チェック・マネージャは統計によるフィルタ処理を行うことができないことを説明する警告が表示されます。
選択したオブジェクトに対してモデル・チェック・マネージャを実行するには、1つまたは複数のビジネス・モデル、ディメンション・オブジェクトまたは論理ファクト表を右クリックし、「モデルのチェック」を選択します。そして、前述のように、サブメニューから「完全」または「統計によるフィルタ処理」を選択します。「統計によるフィルタ処理」メニュー・オプションは、Oracle Exalytics Machine上のファクト表オブジェクトおよびビジネス・モデル・オブジェクトでのみ使用可能であることに注意してください。
大規模なリポジトリでモデル・チェック・マネージャを使用する場合、パフォーマンスを向上させるには、「統計によるフィルタ処理」を使用するか(使用可能な場合)、選択したオブジェクトに対してのみモデル・チェック・マネージャを実行することをお薦めします。
1つまたは複数のオブジェクトに対してモデル・チェック・マネージャを実行すると、図13-5に示されているように、「モデル・チェック・マネージャ」ダイアログが表示されます。
リポジトリを編集して問題を修正するには、行をダブルクリックして、そのオブジェクトのプロパティのダイアログを開くか、行を選択して「移動」をクリックします。問題を修正し、「OK」をクリックします。
「モデル・チェック・マネージャ」ダイアログで次のアクションを実行することもできます。
「表示」ボックスのオプションを使用して、エラーのみを表示する、警告のみを表示する、またはその両方を表示することを選択できます。
列のヘッダーをクリックして、メッセージの行をソートします。
モデル・チェック・マネージャの結果をテキスト、CSVまたはXML形式に保存するには、「名前を付けて保存」をクリックします。
メッセージをコピーして、スプレッドシートなどの他のファイルに貼付けできるようにするには、1つまたは複数の行を選択し、「コピー」をクリックします。行を選択せずに「コピー」をクリックすると、すべてのメッセージがコピーされます。
モデルを再度チェックするには、「全オブジェクトのチェック」をクリックしてグローバル・チェックを実行します。または、右上隅の「リフレッシュ」ボタンをクリックして、前回のチェックでエラーがあったオブジェクトのみをチェックします。
「オブジェクト」列でオブジェクトの修飾名を表示するには、「修飾名の表示」をクリックします。
ステータス・バーには、どのオブジェクトがチェックされたか、および表示されているすべての行のサマリーが表示されます。
スクリプト・ファイルの作成に集計の永続性ウィザードを使用しないことを選択した場合、このファイルを手動で記述することができます。ただし、集計の永続性ウィザードを使用することをお薦めします。
集計の作成時にOracle BIサーバーによってデータベースが変更されるのを望まない場合は、集計の永続性ウィザードでターゲットDDLを別のファイルに生成オプションを選択することによって、それを指定することができます。集計の永続性ウィザードによって、空の集計表を作成するためのDDLファイル(集計準備スクリプト)が作成されます。この後、集計表にデータを移入するために、集計作成スクリプトを実行する必要があります。このオプションは、表作成のためのデータベースへのアクセスが制限されている場合に柔軟性を提供します。集計作成スクリプトを実行する前に集計準備スクリプトを実行する必要があることに注意してください。
この項には次のトピックが含まれます:
作成プロセス時には次の制約が課されます。
有効なメジャー。有効なメジャーは有効な集計ルールを持っている必要があります。レベルベース・メジャーには次の制約が適用されます。
レベルが総計のエイリアスである場合、その集計指定のレベルのリスト内にそのディメンションが存在してはいけません。
このメジャーに定義される他のすべてのレベルは、その集計指定のレベルのリスト内に存在している必要があります。
前述の制約が満たされない場合、集計指定全体が破棄されます。また、次のいずれかの条件に当てはまる場合、作成プロセスにおいてメジャーは無視されます。
メジャーがセッションまたはリポジトリ変数にマップされています。
メジャーが導出メジャーです。
メジャーにデフォルトの集計ルール(なし)が設定されています。
無視されたメジャーは、必ずしも集計指定に影響するとは限りません。集計の作成には残りのメジャーが使用されます。
有効なレベル。有効なレベルは有効な主キーを持つ必要があります。レベルが無効である場合、集計指定は破棄されます。また、次のいずれかの条件に当てはまる場合、レベルまたはその主キーの属性は無視されます。
属性がセッションまたはリポジトリ変数にマップされています。
属性が同一の論理表からのものではありません。
有効な集計指定。有効な集計指定は次のプロパティを持ちます。
名前の長さが1 - 18文字です(1文字、18文字も可)。
1つ以上の有効なレベルが指定されています。
1つ以上の有効なメジャーが指定されています。
有効な接続プールを持つ必要があります。
有効な出力コンテナを持つ必要があります(データベース/カタログ/スキーマ)。
接続プールとコンテナは同一のデータベースに属する必要があります。
各ディメンションに指定可能なレベルは1つのみです。
メジャーは同一のファクト表からのものでなくてはなりません。
指定内のすべての論理コンポーネントは、同一のサブジェクト・エリアのものでなくてはなりません。
レベルの集計はデータベース全体をスコープとするため、出力コンテナ内に同じ名前がすでに存在する場合、集計指定は無視されます。ただし、同一のファクト集計名に対して異なるカタログまたはスキーマが指定される場合、同一のデータベース内の別のスコープであれば、同じ名前の複数のファクトを持つことが許可されます。
ファクトに結合されていないディメンションが存在する場合、集計指定は破棄されることに注意してください。
すべてのメタデータの名前(論理ファクト列を除く)は完全修飾です。操作には、作成と削除の2つのモードがあります。すべての集計指定を1つの集計作成文に含めることを強くお薦めします。
集計指定を記述する際は、次のガイドラインに従ってください。
スクリプト・ファイルの最初にはDelete文を置きます。新しい集計を作成する前にシステムによって生成された集計を削除することが不可欠です。これにより、データの一貫性が保たれること、および作成操作の実行前に無効な集計や不完全な集計が削除されることが保証されます。集計を削除する文の構文は次のとおりです。
Delete aggregates [list of fully qualified physical table names];
例:
Delete aggregates "src".."INCR"."fact_1", "src".."INCR"."fact_2";
オプションで、削除する物理表のカンマ区切りリストを含めることができます。含める表は、集計作成スクリプトの前回の実行によってシステムで生成されたものである必要があります。リストされたファクト表に結合されているすべてのディメンション表も削除されます。
ディメンション表が複数のファクト表に結合されている場合、それは、他の結合されている表もリストされていないかぎり削除されません。
ファクト表に加えて、Delete文を使用して、孤立ディメンション表(他のどのファクト表にも結合されていないディメンション表)を削除することもできます。集計作成が失敗すると、孤立ディメンション表が発生することがあります。
次にCreate文を配置します。集計を作成する文の構文は次のとおりです。
Create|Prepare aggregates aggr_name_1 for logical_fact_table_1 [(logical_fact_column_1, logical_fact_column_2,…)] at levels (level_1, level_2, …) using connection pool connection_pool_name_1 in schema_name_1 [ ,aggr_name_2 for logical_fact_table_3 [(logical_fact_column_5, logical_fact_column_2,…)] at levels (level_3, level_2, …) using connection pool connection_pool_name_2 in schema_name_2] ;
1つの集計作成の文の中に複数の集計を指定する場合は、次のガイドラインに従ってください。
複数の集計指定はカンマで区切り、集計作成スクリプト全体の終わりにはセミコロンを入力します。
このファイルでは、集計削除文は先頭に1つのみ指定するようにします。1回のETLの実行で削除は1回のみ実行されるようにします(リセットが要求される場合を除く)。
|
注意: 初回以降に実行されるすべての集計スクリプトでは、集計削除文は含めないようにするか、または以前に作成したすべての集計を削除するようにしてください。 |
代理キーを使用する集計の作成は、次の項を参照してください。
ファクト表とレベル集計表との結合オプションのデフォルトでは、レベル集計の主キーが使用されます。このレベルの主キーが大きくて複雑である(多数の列で構成されている)場合、ファクト表への結合はコストが高くなります。代理キーは人工的に生成されたキーであり、通常は数字です。レベル集計表内の代理キーはこの結合を簡素化させ、ファクト表から不要な(レベルの主キーの)列が削除され、ファクト表のサイズが小さくなります。代理キーをディメンション(レベル)集計表に追加すると、ファクト表への結合を簡素化でき、問合せのパフォーマンスが向上することがあります。さらに、代理キーによって、各集計表が一意の識別子を持つようになります。
複数のファクト表間でレベルが共有される場合があります。この場合、あるファクトでは代理キーが使用され、別のファクトではディメンション集計の主キーがされる可能性があります。この状況を解決するためのいくつかのオプションを次に示します。
レベルに対して、代理キー、主キーのいずれが使用されるかを示すメタデータ・プロパティを設定します。
レベルの集計では常に代理キーを作成します(処理のコストは比較的低い)。ファクト集計をそれに結合する際に代理キーと主キーのいずれを使用するかについては、後で決定します。
各ディメンションに対して結合タイプを指定する方法の他に、スター全体で代理キーを使用するかどうかを指定する方法があります。これにより構文が簡潔になる場合がありますが、ユーザー・オプションの利用に制限が生じたり、集計作成プロセスの速度が低下したりすることがあります。
集計の作成/準備のための次の構文には、変更箇所[Using_Surrogate_Key]が含まれています。各レベルに代理キー・オプションを指定することができます。このオプションを指定しないと、ファクト表およびディメンション表は、レベル集計の主キーを使用して結合されます。
Create|Prepare aggregates aggr_name_1 [file output_file_name] for logical_fact_table_1 [(logical_fact_column_1, logical_fact_column_2,…)] at levels (level_1 [Using_Surrogate_Key], level_2, …) using connection pool connection_pool_name_1 in schema_name_1 [ ,aggr_name_2 for logical_fact_table_3 [(logical_fact_column_5, logical_fact_column_2,…)] at levels (level_3, level_2, …) using connection pool connection_pool_name_2 in schema_name_2] ;
現在のプロセスへの変更は、リポジトリおよびデータベース内の物理メタデータ・レイヤーに制限されています。
Using_Surrogate_Key結合オプションを使用すると、次のような結果になります。
レベル集計の場合、次のようになります。
物理メタデータでは次のようになります。
レベル集計表は、levelName_upgradeIDSKという名前の新しい列を持ちます(競合がチェックされます)。これは、ディメンション集計の代理キーの列です。全文字数が18文字を超える場合、levelNameは切り詰められることに注意してください。
データベースでは次のようになります。
レベル集計表は、levelName_upgradeIDSKという名前の対応する列を持ちます。ここでも、全文字数が18文字を超える場合、levelNameは切り詰められます。
これはRCOUNT()を使用してデータが設定されます。
ファクト集計の場合、次のようになります。
物理メタデータでは次のようになります。
ファクト集計表には、レベルの主キーの列は含まれません。
かわりに、レベル集計の代理キーに対応する新しい列が表に追加されます。
この列の型はレベルの代理キーと同じです。
この列の名前は、レベル集計の列の名前と同じです(競合がチェックされます)。
ファクト表とレベル表は、この代理キーのみを使用して結合されます。
データベースでは次のようになります。
ファクト集計表も対応する代理キーを持ちます。
移入を通じて利用可能な新機能を使用してデータを設定します。
この項では、Oracle BIサーバーに対して集計指定スクリプトを実行する方法を説明します。このスクリプトを実行する前に、Oracle BIサーバーに対してODBC DSNを作成し、適切なログ・レベルが設定されるようにする必要があります。その後、BI Administratorsグループのメンバーであるユーザーとしてnqcmdを使用してこのスクリプトを実行できます。
集計指定スクリプトを実行する手順は、次のとおりです。
集計作成スクリプトを実行するには、クラスタ化DSNではなく実行中のOracle BIサーバーのDSNに直接接続する必要があります。次の点に注意してください。
単一ノード・クラスタ: 各Oracle BIサーバーのインストール時に作成されるDSNは、単一ノード・デプロイメントの場合でもデフォルトでクラスタ化されているため、集計指定を実行する対象となるOracle BIサーバーに対して手動でDSNを作成する必要があります。
複数ノード・クラスタ: マスターOracle BIサーバーに対して直接、集計指定を実行する必要があります。集計指定を実行する対象となるマスターOracle BIサーバーに対して非クラスタDSNを作成します。オンライン・モードで管理ツールの「クラスタ・マネージャ」を使用して、どのOracle BIサーバーがマスターであるのか判別できます。
Oracle BIサーバーのODBC DSNの作成方法の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイド』のOracle Business Intelligenceと他のクライアントとの統合に関する項を参照してください。
スクリプトを実行する前に、適切なロギング・レベルを設定することをお薦めします。ロギング・レベルを2以上にすると、nqquery.logにトレース・ログが記録されます。ログの対象となるイベントには、集計の実行計画や、集計の作成および削除の順序が含まれます。ロギング・レベルが高いほど、問合せおよび実行計画に関してより詳細な情報が提供されます。たとえば、実行される問合せを調べるには、ロギング・レベル4以上を指定します。ログ・レベルを1以上にすると、nqquery.logにエラー・ログが記録されます。また、nqserver.logにはログ・レベルに関係なくログが記録されます。
最初に、次のいずれかの方法を使用してロギング・レベルを設定します。
スクリプトを実行するユーザーのリポジトリ・ユーザー・オブジェクトでロギング・レベルを設定する。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の問合せログの管理に関する項を参照してください。
LOGLEVELシステム・セッション変数を作成して設定する。LOGLEVELによって、個別のユーザーに設定されているロギング・レベルが上書きされます。詳細は、「セッション変数の作成」を参照してください。
その後、集計作成スクリプトを直接編集し、各集計削除文または集計作成文のリクエスト変数としてロギング・レベルを設定する必要があります。例:
set variable LOGLEVEL=7 : delete aggregates; set variable LOGLEVEL=7 : create aggregates... ;
nqcmdを使用してリクエスト変数を設定するときは、デリミタとしてコロンを使用する必要があります。
BI Administratorsグループのユーザーとして、nqcmdを使用して、ステップ1で作成したOracle BIサーバーの非クラスタDSNに接続します。その後、集計指定スクリプトを実行します。
nqcmdの実行の詳細は、「リポジトリのテストおよび絞込みのためのnqcmdの使用方法」を参照してください。
|
注意: クラスタ化環境では、集計指定スクリプトは、バックグラウンドでスレーブOracle BIサーバーのローリング再起動を実行します。集計の永続性スクリプトの実行中は、Fusion Middleware Controlまたは構成ファイルで他の構成変更を行わないことをお薦めします。ローリング再起動ではスレーブ・サーバーのみが再起動されるため、マスターOracle BIサーバーに、スレーブOracle BIサーバーとは異なる構成設定のセットがロードされる状況になる場合があります。これが発生した場合、マスターOracle BIサーバーを再起動します。 |
SQLスクリプトを実行すると、Oracle BIサーバーのメタデータ内、およびバックエンド・データベース内に集計が作成され、永続化されます。
一連の集計が作成されるとき、1つの集計の作成が失敗すると、集計の永続性エンジンは、失敗した集計とその依存性の作成をスキップし、リストの次の集計に進むことに注意してください。
表 13-1は、様々なライフ・サイクル・ユース・ケースに対して集計を永続化するためのユーザー・タスクをまとめたものです。
これらのユース・ケースは、単一または複数の集計の永続性ターゲットに対する操作に焦点を当てており、単一または複数ノード・デプロイメントに対する操作を説明するものではありません。多くの部分において、ユーザー・タスクは、単一ノード・デプロイメントと複数ノード・デプロイメントの両方に対して同じです。唯一の違いは、クラスタ化デプロイメントでは、マスターOracle BIサーバーに接続する必要があり、スレーブ・サーバーのローリング再起動は、バックグラウンドで実行されることです。詳細は、「Oracle BIに対する集計指定の実行」を参照してください。
表13-1 集計の永続性のライフ・サイクル・ユースケース
| 番号 | ユースケース | 説明 |
|---|---|---|
|
1 |
単一の集計の永続性ターゲットに対する集計の作成 |
集計の作成のみを実行するには、集計作成スクリプトを変更し、先頭の集計削除文を削除します。その後、nqcmdを使用して、スクリプトを実行します。 |
|
2 |
単一の集計の永続性ターゲットに対する集計の削除 |
集計を削除するには、nqcmdを使用して、次のように集計削除文を直接実行します。
Delete aggregates [list of fully qualified physical fact table names];
例: Delete aggregates; または Delete aggregates "src".."INCR"."fact_1", "src".."INCR"."fact_2"; |
|
3 |
単一の集計の永続性ターゲットに対する集計のリフレッシュ |
nqcmdを使用して集計作成スクリプトを実行します。これには、最初に集計を削除する文、次に作成する文が含まれています。 かわりに、ユース・ケース2の説明に従って集計を手動で削除してから、ユース・ケース1に示すように集計を作成することもできます。この手動による方法は、すべての集計を削除するが、集計作成スクリプトでは特定の集計のみが削除されるように指定されている場合に便利です。 |
|
4 |
複数の冗長な集計の永続性ターゲットに対する集計の作成 |
複数のターゲット上に集計クローンを作成するには、集計作成スクリプトを変更し、集計作成文を、ターゲットの数だけコピーします。 たとえば、次の集計作成文を含むスクリプトがあるとします。
set variable LOGLEVEL=7 : create aggregates
"myfactaggr"
for "FACT_1"("MEASURE_1")
at levels ("INCR"."DIM1_LEVEL1Dim"."DIM1_LEVEL1 Detail")
using connection pool "tgt1"."cp"
in "tgt1".."double1";
そのブロックをコピーし、それを最初のブロックの下に貼り付け、2番目のターゲット用に接続プールとスキーマ情報を変更します。例:
set variable LOGLEVEL=7 : create aggregates
"myfactaggr"
for "FACT_1"("MEASURE_1")
at levels ("INCR"."DIM1_LEVEL1Dim"."DIM1_LEVEL1 Detail")
using connection pool "tgt2"."cp"
in "tgt2".."double2";
すべてのターゲット用のブロックをコピーして変更したら、スクリプトを保存します。その後、nqcmdを使用して、集計作成スクリプトを実行します。 |
|
5 |
複数の集計の永続性ターゲットに対する集計の削除 |
複数のターゲット上の集計を削除するには、nqcmdを使用して、影響を受けるファクト表に対して集計削除文を直接実行します。例: set variable LOGLEVEL=7 : delete aggregates "tgt1".."double1"."myfactaggr"; set variable LOGLEVEL=7 : delete aggregates "tgt2".."double2"."myfactaggr"; |
|
6 |
複数の冗長な集計の永続性ターゲットに対する集計のリフレッシュ |
このユース・ケースの詳細は、「可用性の高い集計をリフレッシュするためのダブル・バッファリングの使用方法」を参照してください。 |
|
7 |
複数のパーティション化された集計の永続性ターゲットに対する集計のリフレッシュ |
場合によっては、様々な集計が複数のターゲットにわたってパーティション化されていることもあります。この手法は、メモリー使用量が最大になりますが、可用性の高い集計を提供しません。パーティション化された集計をリフレッシュするには、次の中からデプロイメントに合った方法を実行してください。
|
複数の集計の永続性ターゲットにわたる集計クローンがある場合、集計をリフレッシュする際はダブル・バッファリングを使用して停止時間を作らないようにできます。これを行うには、リフレッシュを制御するように集計作成および削除SQL文を手動でコールします。
始めに、最初のターゲット上の集計を削除します。次に、最初のターゲットで集計を作成し、非アクティブ・スキーマとして集計が削除されていないターゲットを指定し、リフレッシュで古いデータが使用されないようにします。その後、各ターゲットに対してこのプロセスを繰り返します。最後のターゲットをリフレッシュする際は、その時点までに他のスキーマのデータはすでにリフレッシュされているため、非アクティブ・スキーマを指定する必要はありません。
非アクティブ・スキーマを指定するには、集計作成文の前にリクエスト変数INACTIVE_SCHEMASを設定します。例:
set variable INACTIVE_SCHEMAS='"tgt2".."double2"' :
非アクティブ・スキーマとしてリフレッシュされていないスキーマのみ指定します。すでにリフレッシュ済または削除済のスキーマを指定しないでください。
複数の非アクティブ・スキーマを指定するには、カンマ区切りリストを使用します。リストに空白がないことを確認します。
例13-1は、2つのターゲット上で集計をリフレッシュするためのダブル・バッファリングの使用方法を示しています。
例13-1 2つのターゲット上の集計クローンのリフレッシュ
ターゲットtgt1とtgt2上に次の集計クローンがあるとします。
"myfactaggr"
for "FACT_1"("MEASURE_1")
at levels ("INCR"."DIM1_LEVEL1Dim"."DIM1_LEVEL1 Detail")
using connection pool "tgt1"."cp"
in "tgt1".."double1",
"myfactaggr"
for "FACT_1"("MEASURE_1")
at levels ("INCR"."DIM1_LEVEL1Dim"."DIM1_LEVEL1 Detail")
using connection pool "tgt2"."cp"
in "tgt2".."double2";
リフレッシュ中に少なくとも1つの集計クローンを使用可能にするには、次の手順に従います。
次のようにして最初のターゲット上の集計クローンを削除します。
set variable LOGLEVEL=7 : delete aggregates "tgt1".."double1"."myfactaggr";
最初のターゲットの集計を作成し、2番目のターゲットを非アクティブ・スキーマとして指定して、そのデータがリフレッシュで使用されないようにします。
set variable LOGLEVEL=7, INACTIVE_SCHEMAS='"tgt2".."double2"' : create aggregates
"myfactaggr"
for "FACT_1"("MEASURE_1")
at levels ("INCR"."DIM1_LEVEL1Dim"."DIM1_LEVEL1 Detail")
using connection pool "tgt1"."cp"
in "tgt1".."double1";
次のようにして2番目のターゲットの集計クローンを削除します。
set variable LOGLEVEL=7 : delete aggregates "tgt2".."double2"."myfactaggr";
2番目のターゲットの集計クローンを作成します。最初のターゲットはすでにリフレッシュされているめた、非アクティブ・スキーマは指定しないでください。
set variable LOGLEVEL=7 : create aggregates
"myfactaggr"
for "FACT_1"("MEASURE_1")
at levels ("INCR"."DIM1_LEVEL1Dim"."DIM1_LEVEL1 Detail")
using connection pool "tgt2"."cp"
in "tgt2".."double2";
|
注意: 複数の集計の永続性ターゲットにまたがる集計クローンがある場合、追加のインスタンスが、初期インスタンスのリフレッシュ時に問合せの負荷を引き受けるホット・スペアとなります。集計クローンは、受信問合せのロード・バランシングでは使用されません。 |
この項では、サマリー・アドバイザおよび集計の永続性プロセスのトラブルシューティング方法について説明します。内容は次のとおりです。
エラーが発生するいくつかの原因を次に示します。
ネットワークの障害
データベースのディスク容量不足
不正な集計のリクエスト
集計の作成においてエラーが発生すると、集計リクエスト全体が中断され、以降の集計は作成されません。すでに作成されチェックインされた集計は、チェックインされたままになります。エラーが発生した場合は、エラーの発生時または次回のETLの実行時に、次のいずれかの方法によって集計を削除する必要があります。
メタデータとデータベースから手動で集計を削除します。集計メタデータを特定するには、物理表および論理表ソースに対してIs System Generatedフィルタを使用してリポジトリに問い合せします。詳細は、「リポジトリの問合せ」を参照してください。
集計削除指定を使用してすべての集計を自動的に削除します。
モデル・チェック・マネージャを実行して、リポジトリに、Oracle BIサマリー・アドバイザと集計の永続性のパフォーマンスと結果に影響を及ぼすモデリングの問題が含まれていないことを確認します。詳細は、「モデル・チェック・マネージャを使用したモデリングの問題のチェック」を参照してください。
TimesTenソース上に集計を作成するには、そのインスタンスに対してPL/SQLが有効化されており、そのPL/SQLの最初の接続属性PLSQLが1に設定されていることを確認する必要があります。PL/SQLは、インストール時に有効にすることも、インストール後にttmodinstallユーティリティを実行して有効にすることもできます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。
Oracle BIサーバーがTimesTenソースに対する集計を構築する場合、TimesTenへの挿入文中に取消しが発行されても、そのSQLCancelコールは効力を持ちません。現在の挿入文が完了した後に、Oracle BIサーバーからコール元に返されます。
Oracle Exalytics Machine上のTimesTenソースの設定の具体的な手順は、『Oracle Fusion Middleware Oracle Exalytics In-Memory Machineインストレーションおよび管理ガイド』も参照してください。
