| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.3.0) E90110-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.3.0) E90110-03 |
|
|
前 |
次 |
データ・ウェアハウスの多くの専門家は、高度に集約された問合せのパフォーマンスを向上させるために集計データ表を作成します。集計表にはあらかじめ計算された結果が格納され、その結果はディメンションの一連の属性に対する、組み合されたメジャー(通常は合計)です。集計表を使用すると、意志決定サポート・システムにおいて問合せの応答時間を改善できます。
SQL問合せを使用する場合、またはどの表が存在するかのみを理解しその意味を理解していないツールを使用する場合、集計表の数が増加するにつれて集計表の使用がより複雑になります。Oracle BIサーバーの集計ナビゲーション機能を使用すると、問合せにおいて集計表に格納されている情報を自動的に使用することが可能になります。Oracle BIサーバーを利用することにより、ユーザーは適切なビジネス上の質問を行うことに集中でき、最も高速に回答を返す表がどれであるかはサーバーによって判断されます。
Oracle Business Intelligenceは、ソース・データベースの集計を利用します。論理表ソース(マッピング)の管理を参照してください。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" ;
集計を格納するために使用されるターゲット・スキーマを適切に保護し、そのスキーマへのアクセスを制限する必要があります。このスキーマには、表や索引への接続、およびそれらの作成や削除に関する権限を設定する必要があります。デフォルトでは、管理者権限を持つユーザーのみが集計を管理できます。
仮想プライベート・データベース(VPD)のセキュリティ・フィルタがアクティブになっている表に対しては、集計の永続性を使用しないでください。VPDフィルタが適用されずに集計情報が永続化されると、セキュリティ上のリスクが生じます。
Oracle Business Intelligenceはより便利な集計を自動的に作成し、データ・セット・エラーまたはモデリングの問題を修正する必要なく集計を作成します。
代理キー
集計の永続性により、代理キーが作成され、ディメンションをファクト集計表に結合することができます。
ほとんどの場合、ソース・データベースとターゲット・データベースは同じインスタンスではありません。
Oracle BIサーバーでは、ハッシュ結合を使用することにより代理キーの作成が改善されました。可能な場合、リクエスト変数がファクト集計母集団問合せへ新たに自動追加されます。このリクエスト変数が設定されると、問合せエンジンでパラレルのディメンション表に対してファクト表の結合の前にハッシュ結合が作成されます。
Oracle BIサマリー・ウィザードに「代理キーの使用」オプションが表示され、代理キーを使用する必要がある時を知らせます。このオプションが選択されると、using_surrogate_key句が集計指定内のすべてのレベルに追加されます。
レベル・キーの自動修正(ハードニング)
集計の永続性は、一意ではないレベル・キーを自動修正、またはハードニングします。
Oracle BIサマリー・アドバイザは、定義によって一意になるレベル・キーを使用した集計、またはキーが一意になるように自動修正(ハードニング)されるレベル・キーを使用した集計を推奨します。基礎となるデータの変更は、このような集計に影響を与える可能性があります。
パフォーマンスの向上のために、自然キーのかわりに代理キーを使用して集計を作成することをお奨めします。自然キーを使用している場合、自動修正またハードニングはあまり効果的ではありません。特に準備-作成モードの操作で機能しません。
非バランス型(不規則)およびスキップレベル階層
集計の永続性により、非バランス型またはスキップレベル階層のある論理ディメンションに対する集計が作成されます。集計は、代理キーを使用してもしなくても作成できます。Oracle BIサマリー・アドバイザは、非バランス型またはスキップレベル階層のある論理ディメンションに対する集計を推奨します。
時系列キー
Oracle BIサーバーでは、AGO、TODATEおよびPERIODROLLINGなどの時系列関数をサポートするために、時系列キーが必要です。
論理ディメンションの最下位キーのみが時系列である場合にのみ、時系列関数が正しく処理を実行します。
集計の永続性により、時系列キーのない時間レベルにはCK_接頭辞の付いた時系列キーが生成されます。新しい列が物理ディメンション集計表に追加されて、時系列キーの値を保存し、新しい論理列が時間ディメンションの論理表に追加されます。この列は、物理ディメンション集計表に追加される新しい列にマッピングされます。
delete aggregates文は、生成された時系列キーをサポートするために作成されたすべてのメタデータを自動的に削除します。
重複していない件数メジャー
Oracle BIサーバーは重複していない件数メジャーのある集計を使用して、高グレインでのメジャーに対する問合せを処理します。
集計の永続性ウィザードには「「重複を除いた件数」メジャーをRAW値として永続化」オプションが含まれ、これを選択すると、指定された有効な重複していない件数メジャーのすべてにas_raw_valuesが付加されます。「「重複を除いた件数」メジャーをRAW値として永続化」オプションが選択されると、集計の永続性によって、システム生成された集計論理表ソースへの対応する論理列に、集計式が上書きされます。Oracle BIサマリー・アドバイザでは、重複していない件数メジャーに対する永続性の方法の両方の使用をお薦めします。
ネットワーク障害、データベースのディスク領域なし、不正な集計リクエストなどが発生すると、集計の永続性エラーになります。
一連の集計の作成中に1つの集計の作成が失敗すると、集計の永続性エンジンは失敗した集計の作成とその依存関係をスキップし、リストでの次の集計に進みます。ログ・ファイルをチェックして、失敗した集計を特定します。
エラーが生じた場合は、次の方法のいずれかで失敗した集計を削除する必要があります。
メタデータとデータベースから手動で集計を削除します。集計メタデータを特定するには、物理表および論理表ソースに対してIs System Generatedフィルタを使用してリポジトリに問い合せします。「リポジトリの問合せ」を参照してください。
集計削除指定を使用して失敗した集計を自動的に削除します。特に、この方法を使用して、孤立集計ディメンション(他のファクト表と結合していない)を削除します。
モデル・チェック・マネージャを実行して、Oracle BIサマリー・アドバイザと集計の永続性のパフォーマンスと結果に影響を及ぼす可能性があるモデリングの問題がリポジトリに含まれていないことを確認します。「モデル・チェック・マネージャを使用したモデリングの問題のチェック」を参照してください。
集計の作成時には、集計データによって大きな利点が得られるのはどの問合せであるかを特定する必要があります。
可能なかぎり高いレベルで集計することによって、最良の結果が得られます。
遅い問合せを特定するには、次のタスクを実行します。
Oracle BIサーバーの使用状況トラッキングを有効にします使用状況トラッキングの統計情報は、データベースの最適化、集計の戦略、ユーザーや部門が利用したリソースに基づく課金など、様々な方法で利用できます。Oracle BIサーバーは、詳細な問合せレベルで使用状況を追跡します。使用状況トラッキングを有効にすると、すべての問合せの統計情報が使用状況ログ・ファイルに書き込まれるか、またはデータベースの表に挿入されます。
注意:
使用状況トラッキングでは、データベースへの直接インサートの手法を使用することを強くお薦めします。使用状況トラッキングの詳細は、Oracle Business Intelligence Enterprise Editionシステム管理者ガイドの使用状況トラッキングの管理を参照してください。
問合せの実行時間を分析し、最も時間のかかる問合せを集計の候補として特定します集計の作成にかかる実行時間は、ユーザーが選択する集計の種類によって異なります。大きなファクト表の集計作成は、小さな表よりも時間がかかります。作成する集計の選択は慎重に行ってください。
Oracle Exalytics Machine上でOracle Business Intelligenceを実行している場合、Oracle BIサマリー・アドバイザ機能を使用して、問合せのパフォーマンスが向上するのはどの集計であるのか特定し、推奨集計を作成するスクリプトを生成できます。
注意:
Oracle Exalytics Machine上でOracle Business Intelligenceを実行していない場合、Oracle BIサマリー・アドバイザ機能は使用できません。
この項では、次の項目について説明します。
問合せ時間を短縮するために、ロールアップ・データを含む問合せに対して事前に計算された結果を格納する集計表を作成できます。
集計を作成する前に、使用状況トラッキング統計を分析し、問合せのパフォーマンスが向上する可能性があるのはどの集計であるのかを特定する必要があります。サマリー・アドバイザを使用して、特定のリソースの制約を満たしつつ、最大の問合せパフォーマンスを得る可能性がある問合せパターンに基づいた集計表の最適なリストを取得できます。サマリー・アドバイザによって集計作成スクリプトが生成され、それを実行すると、推奨集計表を作成できます。
この項では、次の項目について説明します。
サマリー・アドバイザで推奨を生成するには、その前に、サマリー・アドバイザが使用する使用状況統計の代理サンプルを取得する必要があります。
使用状況トラッキングとサマリー・アドバイザ・ロギングを有効化すると、本番システムのパフォーマンスにわずかに影響します。
次のいずれかのアプローチを実行して、サマリー・アドバイザ統計を収集します。
本番システム上で使用状況トラッキングおよびサマリー・アドバイザ・ロギングを有効にして、ユーザーが数日間にわたってOracle BIサーバーに対する問合せを実行できるようにします。サマリー・アドバイザ統計表に、使用状況統計が移入されます。「使用状況トラッキングの有効化」および「サマリー・アドバイザ・ロギングの有効化」を参照してください。
テスト環境で、Oracle BIサーバーに対して代理ワークロードを実行し、サマリー・アドバイザ統計を収集します。代理ワークロードは、一般的に要求される論理SQL文のリストです。通常、代理ワークロードは本番環境から取得します。
代理ワークロードが用意できたら、テスト環境のOracle BIサーバーで使用状況トラッキングとサマリー・アドバイザ・ロギングを有効化し、nqcmdユーティリティを使用してそのOracle BIサーバーに対してワークロードを実行します。「リポジトリのテストおよび絞込みのためのnqcmdの使用方法」を参照してください。サマリー・アドバイザ統計表に、使用状況統計が移入されます。
サマリー・アドバイザ統計表に代理データが移入された後、サマリー・アドバイザによってデータを分析し、集計の推奨を生成して問合せを高速化できます。
管理ツールのOracle BIサマリー・アドバイザ・ウィザードを実行して集計指定を生成し、nqcmdを使用してその集計指定を使用して集計を作成します。「集計指定スクリプトの生成」および「Oracle BIサーバーに対する集計指定の実行」を参照してください。
Oracle BIサマリー・アドバイザは、Oracle TimesTen In-Memory Databaseまたは Oracle BI EEの集計の作成をサポートしています。また、Oracle ExalyticsでOracle Database In-Memoryを使用しているときに集計の作成をサポートします。「システム要件と動作要件」を参照してください。
サマリー・アドバイザのオプションをファイルに保存し、同じオプションを再入力することなく、後でOracle BIサマリー・アドバイザ・ウィザードを再実行することもできます。
集計および特定のメジャーを含むサマリー・アドバイザの使用について学習します。
サマリー・アドバイザ・ウィザードで、「問合せで使用されているメジャーのみ含める」オプションが設定されていると、サマリー・アドバイザは、分析済の問合せワークロードに存在していて、集計が作成された場合に問合せワークロードを最適化できる特定のメジャーが含まれている集計のみを推奨します。
注意:
サマリー・アドバイザには、お薦めされる集計の問合せワークロードで使用されないメジャーは含まれません。
集計ファクト表のサイズの見積りは、見積りの際に論理ファクト表のすべてのメジャーを使用するのではなく、推奨メジャー・サブセットに基づいて行われます。
サマリー・アドバイザには、お薦めされる集計において集計の永続性に無効なメジャーは含まれません。
Oracle BIサマリー・アドバイザ機能を使用する前に、収集した統計を格納するデータベースを設定する必要があります。
ターゲット・データベースでリポジトリ作成ユーティリティ(RCU)を実行し、必要な統計スキーマを作成する必要があります。
『Oracle Business Intelligenceのインストールと構成』を参照してください。
Oracle Business Intelligenceとともに使用するためにインストールしたデータベースを統計データベースとして使用します。これは、このデータベースにはすでにRCUで作成したスキーマが存在するためです。サマリー・アドバイザ用にRCUで作成した表の名前は、S_NQ_SUMMARY_ADVISORです。
また、そのデータベースを、Oracle BIリポジトリの物理レイヤーにインポートすることも必要です。
サマリー・アドバイザには、使用状況トラッキングに使用するものと同じデータベースを使用する必要があります。使用状況トラッキング用にデータベースとスキーマをすでに設定済である場合は、この項のステップを省略できます。
「リレーショナル・データ・ソースからのメタデータのインポート」を参照してください。
リポジトリのアップロード・コマンドを使用して、リポジトリをアップロードし、問合せに使用できるようにします。「リポジトリを問合せで使用可能にする」を参照してください。
S_NQ_SUMMARY_ADVISOR表の列を確認します。
| 列 | 説明 |
|---|---|
GROUPBYCOLUMNIDVECTOR |
処理パスでグループ化列を表す論理列オブジェクトのアップグレードID。 処理パスはOracle BIサーバーの内部用語です。これは、1つのファクト論理表ソースを含む副問合せを表します。 |
LOGICALFACTTABLEID |
論理ファクト表のアップグレードID。 |
LOGICALTABLESOURCEIDVECTOR |
論理表ソースのアップグレードID。 |
LOGICAL_QUERY_ID |
|
MEASURECOLUMNIDVECTOR |
処理パスでメジャーを表す論理列オブジェクトのアップグレードID。 |
PROCESSINGTIMEINMILLISEC |
この処理パスで費やされた時間(ミリ秒)。 |
QUERYLEVELIDVECTOR |
処理パスにおける論理レベルのアップグレードID。 |
QUERYSTATUS |
内部使用のみに対応しています。 |
ROW_COUNT |
処理パスで取得された行数。この列のデータは、Oracle BIサマリー・アドバイザが使用するために予約されています。 |
SOURCECELLLEVELIDVECTOR |
論理表ソースにおける論理レベルのアップグレードID。 |
VERSION |
Oracle BIサーバーのバージョン番号。 |
サマリー・アドバイザ統計を収集する前に、使用状況トラッキングを有効化する必要があります。
Oracle Business Intelligence Enterprise Editionシステム管理者ガイドの使用状況トラッキングの管理に関する項を参照してください。
統計を収集する準備ができたら、サマリー・アドバイザ・ロギングを有効化できます。新しい(アップグレードしたものではない)インストールの場合、サマリー・アドバイザ・パラメータは中央で管理します。アップグレードのお客様の場合は、サマリー・アドバイザ・パラメータはデフォルトでは中央で管理されません。
サマリー・アドバイザ・ロギングの有効化
サマリー・アドバイザのパラメータは、NQSConfig.INIを使用して管理できます。
これらのパラメータに対して中央管理が無効になっている場合にNQSConfig.INIでサマリー・アドバイザ・ロギングを有効化するには、次のステップに従います。
NQSConfig.INIファイルを開きます。このファイルは次の場所にあります:ORACLE_INSTANCE/config/OracleBIServerComponent/coreapplication_obisn
編集する前に、ファイルのバックアップ・コピーを作成します。
[USAGE_TRACKING]セクションで、次のパラメータを更新します。
SUMMARY_STATISTICS_LOGGINGを次のいずれかのオプションに設定します。
YES: サマリー・アドバイザ・ロギングを有効にします。
LOG_OUTER_JOINT_QUERIES_ONLY: 外部結合を含む論理問合せに対してのみサマリー・アドバイザ・ロギングを有効にします。完全なSummary Advisorのロギングを有効にすることによる小さいパフォーマンスへの影響が問題となる場合は、このオプションを使用することを検討してください。
統計を収集するデータベース表の完全修飾名に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ファイルでこれらのステップを繰り返します。
管理ツール・メニューへのサマリー・アドバイザの追加
bi-config.xmlを開きます。
UNIXの場合: $DOMAIN_HOME/config/fmwconfig/biconfig/core/bi-config.xml
Windowsの場合: %DOMAIN_HOME%\config\fmwconfig\biconfig\core\bi-config.xml
<bi:hw-acceleration>という属性を検索します。
この属性をtrueに設定します。
Business Intelligenceサービスを再起動します。これで、メニュー・オプションが表示されるはずです。
サマリー・アドバイザ統計の生成後に、Oracle BIサマリー・アドバイザ・ウィザードを実行すると、集計指定スクリプトを生成できます。このスクリプトは集計を作成する際に実行できます。
サマリー・アドバイザ・ウィザードは、オンライン・モードでのみで実行できます。また、Oracle BIサマリー・アドバイザ・ウィザードはコマンドラインから実行することもできます。「nqaggradvisorユーティリティを使用してOracle BIサマリー・アドバイザを実行」を参照してください。
サマリー・アドバイザ・ウィザードを実行する前に、集計を作成するために使用するターゲット・データベースを物理レイヤーにマップする必要があります。必要なデータベース、接続プールおよび物理スキーマ・オブジェクトを手動で作成する必要があります。
Oracle BIサマリー・アドバイザ・ウィザードを以前に使用したことがあり、フィルタ基準、ターゲットおよびその他のオプションをXMLファイルとして保存してある場合は、「ファイルからパラメータのロード」をクリックし、前に保存したオプションを現在のウィザード・セッションにロードできます。
Oracle BIサマリー・アドバイザ・ウィザードは、Oracle BI EEを実行している場合、またはOracle ExalyticsでOracle Database In-Memoryを使用している場合に使用できます。Oracle Exalytics上のOracle Database In-Memoryをターゲットとして使用して、集計スクリプト(サマリー・アドバイザによって推奨された集計または手動で定義した集計)を実行できます。
サマリー・アドバイザ表(システムMBeanブラウザのSummaryAdvisorTableName、または NQSConfig.INIのSUMMARY_ADVISOR_TABLE_NAMEパラメータで指定)が空の場合、サマリー・アドバイザは続行できません。
サマリー・アドバイザ設定の推奨事項
サマリー・アドバイザの「その他」ページでは、次のようにすることをお薦めします。
「代理キーの使用」を選択して、集計を使用する問合せのパフォーマンスを向上させます。
「優先オプティマイザ見積り」を選択して、サマリー・アドバイザの処理時のパフォーマンスを向上させます。
「優先オプティマイザ見積り」オプションにより、サマリー・アドバイザは、可能なときには実際の行数問合せを発行するかわりに、データベース問合せオプティマイザから発生するカーディナリティの見積りを使用するようになります。「優先オプティマイザ見積り」オプションは、Oracle Database、Microsoft SQL Server、およびIBM DB2で使用できます。
データベース問合せオプティマイザの見積りを使用するサマリー・アドバイザは、関連データベース・オブジェクトの最新の統計情報を取得します。詳細は、Oracle Databaseのドキュメントを参照してください。
「優先オプティマイザ見積り」オプションを選択していないと、サマリー・アドバイザはバックエンドのデータ・ソースに行数問合せを発行して、そのデータ・ソースの特定の問合せの行数(カーディナリティ)を取得しますが、この実行には時間がかかることがあります。最良の見積りを取得する方法のガイドラインについては、適切なデータベースのドキュメントを参照してください。たとえば、Oracle Databaseを使用している場合は、複数列の問合せのカーディナリティ見積りを改善するために、列グループ機能の使用が必要になることがあります。
特定のグレインに対するエントリがサマリー・アドバイザのキャッシュ・ファイルにすでに存在している場合は、実際の行数問合せであるか、またはカーディナリティ見積りの問合せであるかどうかに関係なく、そのグレインのサンプリングを試みる問合せはサマリー・アドバイザでは発行されません。
「優先オプティマイザ見積り」オプションの選択時または選択解除時には、サマリー・アドバイザのキャッシュ・ファイルを削除してください。これを行うには、Oracle BI管理ツールのコンピュータで、次のディレクトリにあるNQAggregate.Stats.Cache.txtおよびNQAggregate.LTS.Stats.Cache.txtを削除します。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\ coreapplication_obisn\aggr
「問合せで使用されているメジャーのみ含める」を選択し、問合せで使用されているメジャーを含めます。「メジャー・サブセットの推奨事項について」を参照してください。
このオプションを選択しないと、論理ファクト表内のすべてのメジャーが推奨事項内に含まれます。これには、サマリー・アドバイザで分析済のワークロードで使用されないメジャーも含まれます。
「サマリー・アドバイザの停止基準による実行の制約」を参照してください。
Oracle BIサマリー・アドバイザのパフォーマンスと結果に影響を及ぼす可能性のあるモデリングの問題がリポジトリに含まれないよう、モデル・チェック・マネージャを実行することをお薦めします。「モデル・チェック・マネージャを使用したモデリングの問題のチェック」を参照してください。
モデル・チェックは、オフピークの期間に実行することをお薦めします。モデル・チェック・マネージャは、いくつかのチェックのためにバックエンド・データ・ソースに対する問合せを実行します。巨大なリポジトリに対してモデル・チェック・マネージャを実行すると、時間がかかることがあります。パフォーマンスを向上させるには、「統計によるフィルタ処理」を使用するか、選択したオブジェクトに対してのみモデル・チェック・マネージャを実行するようにしてください。
「Oracle BIに対する集計指定の実行」を参照してください。
サマリー・アドバイザ・ウィザードの「停止基準」ページでは、推奨のセットに対する実行の制約を指定できます。
次の点を考慮してください。
サマリー・アドバイザが結果を返すまでの最大時間を指定できます。
新しい集計を追加する際に、そのワークロードで影響を受けるすべての問合せのパフォーマンスに対する最小向上パーセンテージを指定できます。
サマリー・アドバイザは、反復最適化アルゴリズムを使用します。サマリー・アドバイザでは、反復の回ごとに、異なるセットの集計が評価されます。この画面で最小向上パーセンテージを指定すると、サマリー・アドバイザによって、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%
Oracle BI管理ツールを使用するかわりに、コマンドラインからOracle BIサーバー・ユーティリティnqaggradvisorを使用して、サマリー・アドバイザを実行できます。
サマリー・アドバイザ統計を生成した後、nqaggradvisorを使用して集計指定スクリプトを生成し、それを実行して集計を作成できます。nqaggradvisorユーティリティは、Oracle Business IntelligenceをOracle Exalytics Machine上で実行している場合にのみ使用できます。
nqaggradvisorユーティリティの場所は、次のとおりです。
BI_DOMAIN/bi/bitools/bin
構文
nqaggradvisorユーティリティは次のパラメータを取ります。
nQAggrAdvisor -d dataSource | -u userName | -o outputFile | -c tupleInQuotes [-p password] [-F factFilter] [-z maxSizeAggr] [-g gainThreshold] [-l minQueryTime] [-t timeoutMinutes] [-s startDate] [-e endDate] [-C on/off] [-M on/off] [-K on/off]
説明:
dataSourceは、接続してサマリー・アドバイザを実行するOracle BIサーバーのODBCデータ・ソース名です。
userNameは、データ・ソースにログインするユーザー名です。指定されたユーザーは、管理ツールをオンライン・モードでオープンし、Oracle BIサマリー・アドバイザを使用するために必要な権限を持つ必要があります。
outputFileは、集計指定スクリプトの出力の完全修飾パスおよびファイル名です。
tupleInQuotesは、集計の永続性ターゲットです。完全修飾接続プール、完全修飾スキーマ名およびMB単位の容量を指定する必要があります。
passwordは、userName に対応するパスワードです。これを指定しないと、nQAggrAdvisorを実行する際に、ユーザーがパスワードを求められます。
factFilterは、ファクト・フィルタ・ファイル名です。ファクト・フィルタ・ファイルには、サマリー・アドバイザの推奨事項を生成する論理表の完全修飾名が含まれます。個々の論理ファクト表の完全修飾名を、別々の行に追加します。ファクト・フィルタを指定しないと、リポジトリ内のすべての論理ファクト表が分析に含まれます。
maxSizeAggrは、集計のMB単位の最大サイズです。
gainThresholdは、反復最適化アルゴリズムに新しい集計を追加する場合に、サマリー・アドバイザに必要なワークロード内で影響を受けるすべての問合せのパフォーマンス・ゲインが改善された割合の最少パーセンテージです。この値が満たされない場合、サマリ・アドバイザが停止します。デフォルト値は1です。
minQueryTimeは、サマリー・アドバイザの実行に含まれる前に、各論理表ソースで必要な秒単位の最少の問合せ時間しきい値です。デフォルト値は0です。
timeoutMinutesは、結果を返すまでのサマリー・アドバイザの分単位の最長実行時間です。0を指定すると、無制限になります。デフォルト値は0です。
startDateは、サマリー・アドバイザの実行に含める統計の開始日です。
endDateは、サマリー・アドバイザの実行に含める統計の終了日です。
-Cは、オプティマイザの予測を使用するかどうかを指定します。onまたはoffを指定します。デフォルトはoffです。
-Mは、推奨事項にどのメジャーを含めるかを指定します。onを指定して、ワークロードで使用中のメジャーを含めます。offを選択すると、論理ファクト表内のすべてのメジャーがふくまれます。これには、サマリー・アドバイザで分析済のワークロードで使用されないメジャーも含まれます。デフォルトはoffです。
-Kは、代用キーを使用するかどうか指定します。onまたはoffを指定します。デフォルトはonです。
例
次の例では、tupleInQuotesパラメータを正常に指定する方法を示します。
nQAggrAdvisor -d "AnalyticsWeb" -u "Administrator" -p "ADMIN" -o "C:\temp\aggr_advisor.out.txt" -c "DW_Aggr"."Connection Pool","DW_Aggr".."AGGR",1000
次の例では、gainThreshold、startDateおよびendDateパラメータを正常に指定する方法を示します。
nQAggrAdvisor -d "AnalyticsWeb" -u "Administrator" -p "ADMIN" -o "C:\temp\aggr_advisor.out.txt" -F "C:\temp\fact_filter.txt" -g 10 -c "TimesTen_instance1"."Connection Pool","dbo",2000 -s "2011-05-02 08:00:00" -e "2011-05-07 18:30:00" -C on -M on -K off
集計の永続性ウィザードを使用してSQLファイルを作成すると、それを使用して集計表を作成およびロードし、それらをメタデータにマップできます。
この結果作成されるSQLファイルを、実行中のOracle BIサーバーに対して実行します。
集計の永続性ウィザードは集計指定の生成時に必要な多くの制約を自動的に適用するため、このウィザードの使用をお薦めします。ただし、このウィザードを使用せずに、集計論理SQLを手動で記述することもできます。
集計の永続性ウィザードを実行する前に、物理レイヤーに集計を作成する予定のターゲット・データベースをマップする必要があります。これを行うには、必要なデータベース、接続プールおよび物理スキーマ・オブジェクトを手動で作成します。
注意:
Oracle Exalyticsマシン上でOracle Business Intelligenceを実行している場合、集計の永続性ウィザードのかわりにサマリー・アドバイザ機能を使用して、問合せのパフォーマンスが向上するのはどの集計であるのか特定し、推奨集計を作成するスクリプトを生成できます。
次を参照してください。
注意:
モデル・チェック・マネージャは、一部のチェックのためにバックエンドのデータ・ソースに対して問合せを実行するので、オフピーク時に実行することをお薦めします。また、大規模なリポジトリに対してモデル・チェック・マネージャを実行すると、長い時間がかかることがあります。パフォーマンスを向上させるには、「統計によるフィルタ処理」を使用するか(使用可能な場合)、選択したオブジェクトに対してのみモデル・チェック・マネージャを実行するようにしてください。
モデル・チェック・マネージャを実行して、リポジトリに、集計の作成とパフォーマンスに影響を及ぼす可能性があるモデリングの問題が含まれていないことを確認します。
管理ツールでリポジトリを開きます(まだ開いていない場合)。
モデル・チェック・マネージャは、オンライン・モードで実行する必要があります。ただし、集計の永続性・ウィザードは、オンライン・モードでもオフライン・モードでも実行できます。
「ツール」、「ユーティリティ」、「集計の永続性」の順に選択し、「実行」をクリックします。
「ファイルの場所の選択」で、集計作成スクリプトの完全なパスおよびファイル名を指定します。
新しいファイル名、既存のファイル名のいずれも指定することができます。
通常、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]キーを押しながらクリックします。
「「重複を除いた件数」メジャーをRAW値として永続化」を選択して、as_raw_values句をすべての有効な重複しない件数メジャーに追加し、システム生成された集計論理表ソースへの対応する論理列に、集計式の上書きを設定します。このオプションを設定すると、集計の永続性は重複を除いた件数の実際の値を保存します。このオプションを選択しないと、集計の永続性は指定されたレベルの組合せに対するあらかじめ計算された件数を保存します。
最初の集計表ブロックの作成時には、「スクリプトの表示」ボタンは利用できません。
適切なメジャーを選択したら、「次へ」をクリックします。
「レベルの選択」画面で、1つ以上のディメンションの論理レベルを選択することによって集計のレベルを指定します。ファクト-ディメンションの結合で使用する代理キーを指定できます。
集計対象のファクト表とディメンション表の間のデフォルトの結合オプションは、選択した論理レベルに定義されている主キーです。このレベルの主キーが大きくて複雑である場合、ファクト表への結合はコストが高くなります。したがって、この場合は代理キーを使用することをお薦めします。代理キーは人工的に生成されたキーであり、通常は数字です。たとえば、レベル集計表内の代理キーはこの結合を簡素化させ、ファクト表から不要な(レベルの主キーの)列が削除されます。これにより、ファクト表は軽量化されます。
代理キーの使用によって変化するのは問合せの応答時間のみであり、問合せの論理的な結果に違いはありません。ただし、代理キーの生成によって集計表のロード時間が長くなるという副作用が生じる場合があります。したがって、推奨設定は次のようになります。
選択した論理レベルの主キーが単一の数値列である場合、通常は代理キーを使用するオプションは選択しません。なぜなら、これを選択してもパフォーマンス上のメリットはなく、ロード処理にかかる時間が増えるだけだからです。
選択した論理レベルの主キーがテキスト文字列であるか、または複数の論理列から構成されている場合は、この集計ディメンションに結合される問合せのパフォーマンスを向上させるため、通常は代理キーを使用します。ただし、代理キーの生成によって、その集計ディメンション表のロード時間が長くなる場合があることに注意してください。
適切な集計レベルを選択したら、「次へ」をクリックします。
「接続プールの選択」画面で、集計表の場所を指定するための適切な項目を選択します。
デフォルトの集計表の名前が設定されており、表の名前に接頭辞が付加されています。生成されるファクト表のデフォルトの接頭辞はagです。ディメンション(レベル)集計に対して作成される表の場合、デフォルト接頭辞はSA_です。NQSConfig.INIにあるAGGREGATE_PREFIXプロパティを更新することによって、接頭辞を変更できます。
接続プールの情報を設定したら、「次へ」をクリックします。
「終了」画面では、「スクリプトの表示」ボタンが利用可能になっており、論理SQLスクリプトを表示して確認することができます。別の集計を定義するか(デフォルト)、またはウィザードを終了するかを選択し、「次へ」をクリックします。
「スクリプトの終了」画面に、完全なパスとファイル名が表示されます。「終了」をクリックします。
モデル・チェック・マネージャを使用して、Oracle BIサマリー・アドバイザと集計の永続性エンジンに影響を及ぼす可能性のあるモデリングの問題をチェックする方法について説明します。
この項では、次の項目について説明します。
モデル・チェック・マネージャを使用して、Oracle BIサマリー・アドバイザまたは集計の永続性エンジンの正常な実行に影響を及ぼす可能性のある問題がリポジトリ・メタデータにあるかどうかをチェックできます。
モデル・チェック・マネージャは、一部のチェックのために、サマリー統計表(「統計によるフィルタ処理」の使用時)およびバックエンドのデータ・ソースへのアクセスを必要とします。バックエンド問合せの一部はパフォーマンスを圧迫する可能性があるため、モデル・チェック・マネージャはオフピーク時に実行する必要があります。
モデル・チェック・マネージャはオンライン・モードでのみ実行できます。
モデル・チェック・マネージャは、リポジトリ・メタデータに何も変更を加えません。モデル・チェック・マネージャでは、発生する可能性がある問題にフラグ付けるのみです。
モデル・チェック・マネージャからは、エラー・メッセージと警告メッセージの両方が返されます。モデル・チェック・マネージャで特定したエラーを修正する必要があります。エラーを修正しないと、Oracle BIサマリー・アドバイザによる推奨事項が正しくないものになったり、集計の永続性エンジンによる集計の作成が失敗することがあります。警告を修正する必要があります。警告で特定された問題は、Oracle BIサマリー・アドバイザによる推奨事項の的確性を損なったり、集計の永続性エンジンのパフォーマンスを低下させたりすることにつながります。
モデル・チェック・マネージャは、パフォーマンス改善のために、データベースに対してパラレル問合せを実行します。デフォルトでは、24個のスレッドが有効になっています。モデル・チェック・マネージャのデフォルトのスレッド数を変更するには、オペレーティング・システムの環境変数としてMODEL_CHECKER_MAX_THREADSを作成し、設定します。指定可能な最大スレッド数は100です。
Oracle BIサマリー・アドバイザに対しては、Oracle BIサマリー・アドバイザ・ウィザードの実行前ではなく、サマリー・アドバイザ統計の収集後にモデル・チェック・マネージャを実行します。
管理ツールを使用してモデル・チェック・マネージャをグローバルに実行するには、「ファイル」メニュー→「モデルのチェック」を選択します。次のオプションを使用できます。
完全: Oracle BIリポジトリのビジネス・モデルとマッピング・レイヤーにあるすべてのオブジェクトをチェックします。
統計によるフィルタ処理: 統計表に従ってアクティブな問合せの対象となった、ビジネス・モデルとマッピング・レイヤーにあるファクト表オブジェクトおよび関連するディメンションのみをチェックします。大規模なリポジトリに対するプロセスを高速化するには、このオプションを選択します。
このオプションは、Oracle Exalytics Machineでのみ使用可能です。Exalytics以外のシステムで統計によるフィルタ処理を実行しようとしたり、統計表が使用可能でないときにフィルタ処理を実行しようとしたりすると、モデル・チェック・マネージャは統計によるフィルタ処理を行うことができないことを説明する警告が表示されます。
サマリー・アドバイザの統計表の設定の詳細は、後続のセクションを参照してください。
管理ツールを使用して選択したオブジェクトに対してモデル・チェック・マネージャを実行するには、1つまたは複数のビジネス・モデル、ディメンション・オブジェクトまたは論理ファクト表を右クリックし、「モデルのチェック」を選択します。そして、前述のように、サブメニューから「完全」または「統計によるフィルタ処理」を選択します。「統計によるフィルタ処理」メニュー・オプションは、ファクト表オブジェクトおよびビジネス・モデル・オブジェクトでのみ使用可能です。
大規模なリポジトリでモデル・チェック・マネージャを使用する場合は、パフォーマンスを向上させるために、「統計によるフィルタ処理」を使用するか、選択したオブジェクトに対してのみモデル・チェック・マネージャを実行することをお薦めします。
1つまたは複数のオブジェクトに対してモデル・チェック・マネージャを実行すると、「モデル・チェック・マネージャ」ダイアログが開いて、リポジトリのエラーを修正できるようになります。
Oracle BIサーバーのvalidaterpdユーティリティを使用し、-Lオプションを指定して、コマンドラインからモデルをチェックできます。
-Lを指定してこのユーティリティを実行すると、管理ツールでモデル・チェック・マネージャがチェックする場合と同様のモデル・チェックを実行できます。validaterpdユーティリティは、WindowsシステムとUNIXシステムの両方で使用できます。
モデル・チェック・モードでvalidaterpdを実行するには、実行中の管理ツールのDSNを指定する必要があります。
validaterpdユーティリティの場所は、次のとおりです。
BI_DOMAIN/bi/bitools/bin
「validaterpdユーティリティを使用したリポジトリの整合性チェック」を参照してください。
構文
validaterpdユーティリティは、モデル・チェック・モードで次のパラメータを取ります。
validaterpd -L -D DSN_name -U DSN_user_name [-P DSN_password]
{-O output_txt_file_name |-C output_csv_file_name | -X output_xml_file_name} [-W]
[-S] [-8]
説明:
-L: モデル・チェック・モードを指定します。
-D: 実行中のOracle BIサーバーのDSN。
-U: Oracle BIサーバーのDSNのユーザー名。
-P: Oracle BIサーバーのDSNのパスワード。
パスワード引数はオプションです。パスワード引数を指定しなかった場合、コマンドの実行時にパスワードを入力するように求められます。セキュリティ侵害のリスクを最小限にとどめるために、パスワード引数をコマンドラインやスクリプトで指定しないことをお薦めします。
注意:
パスワード引数は下位互換性のためにのみサポートされています。スクリプト上の理由から、標準入力によってパスワードを指定できます。
-O 結果をテキスト・ファイルで出力するには、このオプションを使用します。
-C 結果をCSVファイルで出力するには、このオプションを使用します。
-X 結果をXMLファイルで出力するには、このオプションを使用します。
-8 UTF-8出力を指定するには、このオプションを使用します(オプション)。
-W ホワイトリストされたオブジェクトのファイルを含めることができます。このテキスト・ファイルでは、チェックする必要のある論理オブジェクトの限定数が指定されます。各論理オブジェクトの完全修飾名を1行に入力します。-Wが指定されていない場合は、すべての論理オブジェクトがチェックされます。
-S 統計表に従ってアクティブな問合せの対象となったオブジェクトのみをチェックするには、このオプションを使用します。-Sが指定されていない場合は、すべてのオブジェクトがチェックされます。-Wも同時に指定された場合、ホワイトリスト・ファイルにはビジネス・モデルと論理ファクト表のみを含めることができ、その他のオブジェクトはチェックされません。このオプションは、Oracle Exalyticsマシンでのみ使用可能です。
例
validaterpd -L -D DSNName -U Username -O results.txt Give password: my_dsn_password
前出の例では、DSNName接続を使用してRPDに接続し、RPD内のすべてのモデルをチェックし、出力をresults.txtに書き込んでいます。
validaterpd -L -D DSNName -U Username -O results.txt -W whitelist.txt -S Give password: my_dsn_password
前出の例では、DSNName接続を使用してRPDに接続し、モデル・チェックを実行して、出力をresults.txtに書き込んでいます。whitelist.txtにリストされたオブジェクトのみがチェックされます。また、-Sが指定されているため、統計表に従ってアクティブな問合せの対象となったオブジェクトのみがチェックされます。
-Wと-Sを同時に指定した場合、ホワイトリストにはビジネス・モデルと論理ファクト表のみを含めることができます。その他のオブジェクトはチェックされません。
集計の永続性ウィザードを使用してスクリプト・ファイルを作成するかわりに、スクリプト・ファイルを手動で記述できます。集計の永続性ウィザードを使用することをお薦めします。
集計の作成時に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文は、Delete文の後に実行する必要があります。
集計を作成する文の構文は次のとおりです。
Create|Prepare aggregates aggr_name_1 for logical_fact_table_1 [(logical_fact_column_1, logical_fact_column_2, count_distinct_logical_fact_column_1 as_raw_values, ...)] 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] ;
as_raw_valuesは、単一の集計ルールを持つ重複しない件数のメジャーを伴っている必要があります。単一の集計ルールには、ルールが1つだけあり、ディメンション・ベースではありません。
次のガイドラインを使用して、1つの集計作成の文の中に複数の集計を指定します。
複数の集計指定はカンマで区切り、集計作成スクリプト全体の終わりにはセミコロンを入力します。
このファイルでは、集計削除文は先頭に1つのみ指定するようにします。1回のETLの実行で削除は1回のみ実行されるようにします(リセットが必要な場合を除く)。
注意:
初回以降に実行されるすべての集計スクリプトでは、集計削除文は含めないようにするか、または以前に作成したすべての集計を削除するようにしてください。
オプションのWhere句をCreate文に追加できます。
Where句は集計するデータをフィルタし、断片化された集計またはベース・ファクト表のデータの断片のみの集計を作成します。Where句は、「論理表ソース」ダイアログにある「断片化の内容」フィールドも設定します。ほとんどの場合、断片化された集計の作成は問合せの高速化を最大化し、集計の作成および維持のコストを最小限に抑えます。
次の例は、断片化された集計を使用する場合を示しています。
時間ディメンションを操作し、集計に過去3年のみのデータを含める場合。
主に米国の売上を報告し、集計に米国のデータのみを含める場合。
次に示すのは、有効なWHERE句のCreate文の例です。
Create Aggregates
Revenue_By_Year
for "sales"."sales" at levels("sales".timedim.year)
where("sales"."time"."calendar year"=2007)
using connection pool aggrtarget.cp1
in aggrtarget..schema1
論理列の要件
Where句で指定する論理列は、次の要件を満たす必要があります。
論理列は、ディメンションに属する必要があります。
論理列が集計指定に含まれるディメンションに属する場合、集計のレベル以上である必要があります。
operational_operを使用する場合、論理列のデータ型はinlistの定数のデータ型と一致する必要があります。
inclusion_operを使用する場合、論理列のデータ型はinlistのすべての定数のデータ型と一致する必要があります。
Where句の文法
集計の作成指定のWhere句の文法は、論理SQLフィルタのWhere文法のサブセットです。Oracle BIサーバーが集計の作成指定にサポートする文法は、論理SQLフィルタとわずかに異なります。
次のCreate文およびWhere句を確認してください。
create aggregate aggr1 for fact1 at levels(11,12...) where (filter_list) using ....
許容できる文法のルールは、次のとおりです。
filter_list ::= filter logical_oper filter_list
| filter
| '(' filter_list ')'
filter ::= logical_column relational_oper constant
| logical_column inclusion_oper '(' inlist ')'
relational_oper ::= '=' | '!=' | '<' | '>' | '<=' | '>=' | 'like'
inlist ::= constant ',' inlist
| constant
logical_oper ::= 'and' | 'or'
inclusion_oper ::= 'in' | 'not in' ファクト表とレベル集計表との結合オプションのデフォルトでは、レベル集計の主キーが使用されます。
このレベルの主キーが大きくて複雑である、つまり多数の列で構成されている場合、ファクト表への結合はコストが高くなります。代理キーは人工的に生成されたキーであり、通常は数字です。レベル集計表内の代理キーはこの結合を簡素化させ、ファクト表から不要な(レベルの主キーの)列が削除されます。これにより、ファクト表のサイズが小さくなります。代理キーをディメンション(レベル)集計表に追加すると、ファクト表への結合を簡素化でき、問合せのパフォーマンスが向上することがあります。代理キーによって、各集計表が一意の識別子を持つようになります。
複数のファクト表間でレベルが共有される場合があります。この場合、あるファクトでは代理キーが使用され、別のファクトではディメンション集計の主キーがされる可能性があります。この状況を解決するためのいくつかのオプションを次に示します。
レベルに対して、代理キー、主キーのいずれが使用されるかを示すメタデータ・プロパティを設定します。
常にレベル集計用の代理キーを作成します。代理キーまたは主キーを使用してファクト集計を作成する必要があるかどうかは、パフォーマンスを観察した後で決定できます。
スター全体に代理キーを使用するように指定した結果、より構文は簡潔になりますが、使用可能なユーザー・オプションが制限され、集計作成プロセスの速度が低下することがあります。
集計の作成/準備のための構文には、変更箇所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は切り詰められます。
データベースのレベル集計の場合は、Using_Surrogate_Key結合オプションを使用すると、次が行われます。
レベル集計表は、levelName_upgradeIDSKという名前の対応する列を持ちます。RCOUNT()を使用して、表に移入できます。
物理メタデータのファクト集計の場合は、Using_Surrogate_Key結合オプションを使用すると、次が行われます。
ファクト集計表には、レベルの主キーの列は含まれません。
かわりに、レベル集計の代理キーに対応する新しい列が表に追加されます。
この列の型はレベルの代理キーと同じです。
この列の名前は、レベル集計の列の名前と同じであり、競合がチェックされます。
ファクト表とレベル表は、この代理キーのみを使用して結合されます。
データベースのファクト集計の場合は、Using_Surrogate_Key結合オプションを使用すると、次が行われます。
ファクト集計表は対応する代理キーを持ちます。Populateを通じて使用可能な新機能を使用して、データが表に移入されます。
Oracle BIサーバーに対して集計指定スクリプトを実行する方法を説明します。
このスクリプトを実行する前に、Oracle BIサーバーのODBC DSN (データ・ソース名)を作成し、適切なログ・レベルを設定する必要があります。Oracle BIサーバーのDSNは、単一ノード・デプロイメントに対して集計指定を実行するように手動で作成する必要があります。デプロイメントがマルチノード・クラスタの場合は、ソースOracle BIサーバーに対して集計指定を直接実行する必要があります。集計指定を実行する対象となるソースOracle BIサーバーに対して非クラスタDSNを作成します。管理ツールの「クラスタ・マネージャ」をオンライン・モードで使用して、どのOracle BIサーバーがソースであるのかを判断します。
注意:
クラスタ化環境では、集計指定スクリプトは、宛先Oracle BIサーバーのローリング再起動をバックグラウンドで実行します。集計の永続性スクリプトの実行中は、Fusion Middleware Controlまたは構成ファイルで、その他の構成変更を行わないようにしてください。ローリング再起動では、宛先サーバーのみが再起動されます。構成を変更すると、Oracle BIサーバーが宛先Oracle BIサーバーとは異なる構成設定のセットを送信する可能性があります。構成を変更した場合は、ソースOracle BIサーバーを再起動します。
DSNを作成すると、BI Administratorsグループのメンバーであるユーザーとして、nqcmdを使用してスクリプトを実行できます。「リポジトリのテストおよび絞込みのためのnqcmdの使用方法」を参照してください。
Oracle BI EE 11gバージョンを使用している場合、問合せとエラーはnqquery.logに記録されます。Oracle BI EE 12cを使用している場合、問合せとエラーはDOMAIN_Home/servers/obis1/logs内のobis1_query.logに記録されます。
Oracle BIサーバーのODBC DSNを作成する方法の詳細は、Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイドの「Oracle Business Intelligenceへの他のクライアントの統合」を参照してください。
トレース・ログは、ロギング・レベルを2以上にすると記録されます。ログの対象となるイベントには、集計の実行計画や、集計の作成および削除の順序が含まれます。ロギング・レベルが高いほど、問合せおよび実行計画に関してより詳細な情報が提供されます。たとえば、実行される問合せを調べるには、ロギング・レベル4以上を指定します。エラー・ログは、ロギング・レベルを1以上にすると記録されます。このログは、ロギング・レベルにかかわらずnqserver.logに記録されます。
次のいずれかの方法で、ロギング・レベルを設定します。
スクリプトを実行するユーザーのリポジトリ・ユーザー・オブジェクトでロギング・レベルを設定する。『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の「問合せログの管理」を参照してください。
LOGLEVELシステム・セッション変数を作成して設定する。LOGLEVELによって、個別のユーザーに設定されているロギング・レベルが上書きされます。「セッション変数の作成」を参照してください。
SQLスクリプトを実行すると、Oracle BIサーバーのメタデータ内、およびバックエンド・データベース内に集計が作成され、永続化されます。
一連の集計の作成中に1つの集計の作成が失敗すると、集計の永続性エンジンは失敗した集計の作成とその依存関係をスキップし、リストでの次の集計に進みます。
ログ・ファイルをチェックして、失敗した集計を特定します。孤立した集計ディメンション(他のどのファクト表にも結合していないもの)が作成された場合は、Delete Aggregatesコマンドを使用して、そのディメンションを削除します。
この表は、様々なライフ・サイクル・ユースケースに対して集計を永続化するためのユーザー・タスクをまとめたものです。
ライフ・サイクル・ユースケースは、単一または複数の集計の永続性ターゲットに対する操作に焦点を当てており、単一または複数ノード・デプロイメントに対する操作を説明するものではありません。ユーザー・タスクは、単一ノード・デプロイメントと複数ノード・デプロイメントの両方に対して同じであり、唯一の違いはクラスタ化されたデプロイメントに関連するものです。クラスタ化されたデプロイメントでは、コントローラOracle BIサーバーに接続する必要があります。下位のサーバーのローリング再起動はバックグラウンドで実行されます。「集計指定スクリプトの実行」を参照してください。
| 番号 | ユース・ケース | 説明 |
|---|---|---|
1 |
単一の集計の永続性ターゲットに対する集計の作成 |
集計の作成のみを実行するには、集計作成スクリプトを変更し、先頭の集計削除文を削除します。その後、 |
2 |
単一の集計の永続性ターゲットに対する集計の削除 |
集計を削除するには、 Delete aggregates [list of fully qualified physical fact table names];
例: Delete aggregates; または Delete aggregates "src".."INCR"."fact_1", "src".."INCR"."fact_2"; |
3 |
単一の集計の永続性ターゲットに対する集計のリフレッシュ |
かわりに、ユース・ケース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";
すべてのターゲット用のブロックをコピーして変更したら、スクリプトを保存します。その後、 |
5 |
複数の集計の永続性ターゲットに対する集計の削除 |
複数のターゲット上の集計を削除するには、 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"' :
非アクティブ・スキーマとしてリフレッシュされていないスキーマのみ指定します。すでにリフレッシュ済または削除済のスキーマを指定しないでください。
複数の非アクティブ・スキーマを指定する場合は、カンマ区切りのリストを使用します。リストに空白がないことを確認します。
「2つのターゲット上の集計クローンのリフレッシュ」の例は、2つのターゲット上で集計をリフレッシュするためのダブル・バッファリングの使用方法を示しています。
注意:
複数の集計の永続性ターゲットにまたがる集計クローンがある場合、追加のインスタンスが、初期インスタンスのリフレッシュ時に問合せの負荷を引き受けるホット・スペアとなります。集計クローンは、受信問合せのロード・バランシングでは使用されません。
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";
次のようにして最初のターゲット上の集計クローンを削除します。
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";
これらのトピックでは、TimesTenソースでの集計作成に関連する構成ステップと機能について説明します。
TimesTenの圧縮表で集計を作成するには、Oracle BI管理ツールで「データベース」ダイアログの「機能」タブでCOMPRESSED_COLUMNSを有効にする必要があります。「データ・ソースでサポートされるSQL機能の指定」を参照してください。
この項では、次の項目について説明します。
TimesTenソースの設定に関する具体的な手順は、Oracle Exalyticsを参照してください。
TimesTenソース上に集計を作成するには、そのインスタンスに対してPL/SQLが有効化されており、そのPL/SQLの最初の接続属性PLSQLが1に設定されていることを確認する必要があります。
PL/SQLは、インストール時に有効にすることも、インストール後にttmodinstallユーティリティを実行して有効にすることもできます。『Oracle TimesTen In-Memory Databaseインストール・ガイド』を参照してください。
