Oracle® Business Intelligence Applications

ETLガイド

11g リリース1 (11.1.1.8.1)

E57854-01(原本部品番号:E51481-01)

2014年3月

ETLプロセスの設定方法、実行方法およびモニター方法について説明します。

Oracle Business Intelligence Applications ETLガイド, 11g リリース1 (11.1.1.8.1)

E57854-01

Copyright © 2014, Oracle and/or its affiliates. All rights reserved.

原本主著者: Dan Hilldale

原本協力者: Oracle Business Intelligence開発チーム、製品管理チームおよび品質保証チーム。

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracleおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

図一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

Oracle BI ApplicationsのETL管理者向けの新機能

- Oracle BI ApplicationsのETL管理者向けの新機能

1 ETLの概要

- ETLプロセスの実行を開始する前に

- ETLアーキテクチャについて

- ETLのフェーズについて

- ODIリポジトリについて

- ロード・プランについて

- チェンジ・データ・キャプチャについて

- ナレッジ・モジュールについて

- リバース・ナレッジ・モジュールについて

- マルチソース環境について

- ETLのロールについて

2 ロード・プランの管理

- ロード・プランのライフ・サイクルの概要

- ロード・プランの定義

- ロード・プランの複製

- ロード・プランの編集

- ロード・プランの生成

- ロード・プランのスケジューリング

- ロード・プランの実行

- ロード・プラン実行のモニター

- ロード・プランの再開

- ロード・プランの再開可能性の概要

- 再開可能性の単位について

- ロード・プランの再開

- ODI Studioを使用した再開

- ODIコンソールを使用した再開

- ロード・プランのトラブルシューティング

- ロード・プランの再開用の代替オプション

- 「完了としてマーク」の使用

- シナリオのスタンドアロン実行

- 関連機能および考慮事項

- ロード・プランの停止

3 追加の管理タスク

- SiebelソースのETL表の作成

- DDL Warehouseスクリプトの生成

- ロギングおよび診断

A 「ロード・プランの管理」ユーザー・インタフェースのリファレンス

- 「ロード・プランの管理」ツールバーのオプション

- 「ロード・プランの管理」メイン・ページ

- 「ロード・プランの管理: ファクト・グループ」タブ

- 「ロード・プランの管理: データ・ロード・パラメータ」タブ

- 「ロード・プランの管理: ドメインとマッピング」タブ

- 「ロード・プランの管理: スケジュール」タブ

- 「ロード・プランの定義」ページ

- 「ロード・プランの複製」ページ

- 「ロード・プランの編集」ページ

- 「ロード・プランの詳細」ページ

- 「ロード・プランのスケジュール」ダイアログ

B ナレッジ・モジュールのリファレンス

- IKM BIApps Oracle Control Append

- IKM BIAPPS Oracle Event Queue Delete Append

- IKM BIAPPS Oracle Fact Incremental Update

- IKM BIAPPS Oracle Incremental Update

- IKM BIAPPS Oracle Period Delete Append

- IKM BIAPPS Oracle Slowly Changing Dimension

- IKM BIAPPS SQL Target Override

- ネストされたIKM BIAPPS Oracle Control Append

- ネストされたIKM BIAPPS Oracle Event Queue Delete Append

図一覧

- 1-1 オンプレミスのETLアーキテクチャ

- 1-2 ロード・プランのパターン

- 1-3 マルチソースのロード・プラン

はじめに

Oracle Business Intelligence Applicationsは、広範なインテリジェンスを組織全体に提供する、事前構築済の包括的なソリューション・スイートです。これにより、最前線で活動するユーザーから経営幹部まで、あらゆるレベルのユーザーに対して、有効性の最大化に必要な重要情報を提供します。直感的なロールベースのソリューションは、様々なエンタープライズ・ソースおよび企業データ・ウェアハウスからのデータを変換し、より効果的な行動、意思決定、プロセスを可能にする実用的なインサイトに統合します。

Oracle BI Applicationsは、包括的な一連のエンタープライズ・ビジネス・インテリジェンス・ツールおよびインフラストラクチャであるOracle Business Intelligence Suite Enterprise Edition (Oracle BI EE)を基盤として構築されており、拡張性のある効率的な問合せおよび分析サーバー、非定型の問合せおよび分析ツール、インタラクティブ・ダッシュボード、プロアクティブ・インテリジェンスとアラート、エンタープライズ・レポート・エンジンなどが含まれます。

対象読者

このドキュメントは、Oracle BI Applicationsのマネージャおよび実装者を対象としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleカスタマは、My Oracle Supportから電子サポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs(聴覚障害者向け)を参照してください。

関連ドキュメント

Oracle Business Intelligence Applicationsの関連ドキュメントについては、Oracle Business Intelligence Applicationsのドキュメント・ライブラリ(http://docs.oracle.com/cd/E51479_01/index.htm)を参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

Oracle BI ApplicationsのETL管理者向けの新機能

ここでは、Oracle Business Intelligence ApplicationsのETLに関連する新機能について説明します。

Oracle BI ApplicationsのETL管理者向けの新機能

このリリースでは、ETLの新機能はありません。

1 ETLの概要

この章では、Oracle BI ApplicationsのETLプロセスに関連する基本概念について、概要を説明します。

この章には次のトピックが含まれます:

- ETLプロセスの実行を開始する前に

- ETLアーキテクチャについて

- ETLのフェーズについて

- ODIリポジトリについて

- ロード・プランについて

- チェンジ・データ・キャプチャについて

- ナレッジ・モジュールについて

- リバース・ナレッジ・モジュールについて

- マルチソース環境について

- ETLの各ロールについて

- ロード・プランの管理

ETLプロセスの実行を開始する前に

Oracle BI ApplicationsのETLプロセスの実行を開始する前に、Oracle BI Applicationsのインストールと設定を完了しておく必要があります。詳細は、『Oracle Business Intelligence Applicationsインストレーション・ガイド』を参照してください。

また、ドメインのロード・プラン(Oracle BI Applications構成マネージャの表にソース固有のデータをロードする)を実行しておく必要もあります。これにより、設定オブジェクトのドロップダウン・リストの選択肢として、構成マネージャで適切なソース固有の値を表示できるようになります。ドメインのロード・プランを実行する方法については、『Oracle Business Intelligence Applicationsインストレーション・ガイド』を参照してください。

ETLアーキテクチャについて

図1-1に、オンプレミスのETLアーキテクチャを示します。一般に、抽出、ロード、変換プロセスには、主要なステップが2つあります。最初のステップは、抽出およびステージ・ロード・ステップで、2つ目のステップは、ロード変換ステップです。抽出およびステージ・ロード・ステップは、メイン・インタフェースとネストされた一時インタフェースを組み合せたものから生成されます。ロード変換ステップは、統合ナレッジ・モジュール(IKM)の結果として生成されます。この例のステップ1では、GL_SET_OF_BOOKS表とHR_ORGANIZATION_INFORMATION表を結合するSQL文がソースで発行されます。この結合は、ソース・データベースで実行され、結果データがステージングされます。次に、ロード変換ステージでは、W_DOMAIN_G表と一時ステージ表の間で2つ目の結合が行われます。その結果、ステージ表W_INV_ORG_DSがロードされます。

Oracle Databaseは、Oracle BI Applicationsのリポジトリ・スキーマとBusiness Analytics Warehouseでサポートされる唯一のデータベース・タイプであることに注意してください。

図1-1 オンプレミスのETLアーキテクチャ

図1-2に、一般的なロード・プランのパターンを示します。主なステージは4つあります。SDE (ソース依存抽出)タスクでは、ソース・ディメンションとファクト表からデータを抽出して、そのデータを共通ディメンション表とファクト・ステージング表にロードします。SILタスクは共通のタスクであり、共通ステージング表のデータをウェアハウス・ステージング表にロードします。図1-2には、ディメンション表とファクト表の間の依存関係が示されています。このため、SIL FACTより先にSIL DIMを実行して、ディメンション・キーを解決しておく必要があります。SIL DIMには、このキーを生成するデータベース・シーケンスがあります。SIL FACTでは、ファクト・ステージング表のロード時にそのキーが参照されます。

図1-2 ロード・プランのパターン

ETLのフェーズについて

Oracle BI ApplicationsのETLプロセスには、次のフェーズがあります。

- SDE。SDEは、ソース依存抽出(Source Dependent Extract)の略称です。最初のフェーズでは、SDEタスクがソース・システムからデータを抽出し、そのデータをステージング表にステージします。SDEタスクは、ソース固有になります。

- SIL。SILは、ソース非依存ロード(Source Independent Load)の略称です。ロード・タスクは、ステージング表のデータを変換して、基本ファクト表またはディメンション表に移植します。SILタスクは、ソースに依存していません。

- PLP。PLPは、ロード後プロセス(Post Load Process)の略称です。PLPタスクは、ディメンション表とファクト表の移入後にのみ実行されます。PLPタスクの一般的な使用法として、基本ファクト表のデータを変換して、そのデータを集計表にロードする場合があげられます。PLPタスクは、ソースに依存していません。

ODIリポジトリについて

Oracle BI ApplicationsのODIリポジトリは、次の2つのリポジトリで構成されます。

- マスター・リポジトリ。リソース、セキュリティ、バージョン管理のトポロジです。マスター・リポジトリは通常、複数の作業リポジトリに関連付けられていますが、作業リポジトリは、常に単一のマスター・リポジトリにアタッチされます。

- 作業リポジトリ。データ・モデルとプロジェクトを格納します。これは、開発および実行用のリポジトリです。

マスター・リポジトリと作業リポジトリは、同一のデータベース・スキーマ内に常駐する必要があり、データベース・タイプはOracleである必要があります。マスター・リポジトリと作業リポジトリは、どちらもOracle BI Applicationsのインストール・プロセス中に設定されます。

デフォルトのODIリポジトリIDは500です。このIDは、ODIリポジトリ内で作成される各オブジェクトに対する、内部IDの一部になります。リポジトリIDは、500以上であることが重要です。これにより、ユーザーが作成するオブジェクトが、現在または将来のOracle BI Applicationsオブジェクトと重複する事態を防げます。デフォルトのODIリポジトリIDを変更するときには、新しい値が500より大きいことを必ず確認してください。

ロード・プランについて

ロード・プランとは、ETLプロセスを実行する子オブジェクト(ステップと呼ばれる)から構成および編成される、実行可能なオブジェクトのことです。ロード・プランは、各種ステップのシーケンスからなります。各ステップには、複数の子ステップを含めることもできます。ステップの種類によっては、条件付き、パラレルまたはシリアルでステップを実行できます。

ロード・プランは、Oracle BI Applications構成マネージャで、データ・ソースと1つ以上のファクト・グループを選択することによって定義します。この選択により、ETLプロセス中に実行する必要のあるステップが決まります。各ファクト・グループは、特定の機能領域または1つ以上のオファリングに関連付けられた領域に属しています。この領域は、1つのデータ・サーバーに関連付けられています。トランザクション・データ・ソースは、1つ以上のデータ・サーバーに関連付けられています。

ロード・プランを定義したら、そのロード・プランを生成して、ODIリポジトリに作成します。その後、ロード・プランを実行して、ETLプロセスを実行します。

Oracle BI Applicationsのロード・プランに対する作業の詳細は、第2章「ロード・プランの管理」を参照してください。Oracle Data Integrator関連のロード・プランのトピックについては、Oracle Fusion Middleware Oracle Data Integrator開発者ガイドを参照してください。

チェンジ・データ・キャプチャについて

Oracle BI Applicationsには、フル・モード、増分モードという、Oracle Business Analytics Warehouseへのデータ・ロード用の2つのETLモードがあります。

フル・ロード時には、Oracle BI Applicationsは次のものを抽出します。

- ディメンション表のソース表のすべてのレコード。

- ファクト表のソース表の、初期抽出日以降に作成されたレコード。初期抽出日では、レコードのすべてがデータ・ウェアハウスにロードされてしまわないように期限を定義します。データ・ソースごとの初期抽出日の値は、Oracle BI Applications構成マネージャで設定します。

1つのETLプロセスでは、1つの表からレコードを抽出することも、複数の表から抽出することもできます。レコードが複数の表を結合した後の成果物である場合、それらの表のいずれかがベース表として識別されます。この表により、レコードの粒度が定義されます。ファクト・レコードの抽出時には、ベース表の「作成日」と初期抽出日のみが比較されます。

増分ロード時には、最終抽出日の後で変更されたレコードまたは作成されたレコードが抽出されます。これは、最終抽出日の値と、ソース表の最終更新日(LUD)タイプ列を比較することで行われます。このような列がソース表に含まれていない場合、Oracle BI Applicationsでは、その表からすべてのレコードが抽出されます。最終抽出日の値は、その表から最後にデータを抽出した時点から削除日数の値を差し引いて計算されます。削除日数パラメータは、ETLを前回実際に実行した時点より前に、ETL抽出の時間枠を戻すために使用します。これにより、前回のETLでは見逃されていた可能性のあるレコードが、次回のETLで取り出されるようになります。ETLプロセスの実行中に更新され、ETLが完了するまでコミットされなかったレコードは、そのETLプロセスで見逃されることがあります。

削除日数パラメータの値は、Oracle BI Applications構成マネージャで設定します。小さな値を設定すると、ETLで抽出するレコード数が少なくなるためにパフォーマンスが向上しますが、レコードが検出されない危険性が高くなります。不定期に実行するETLには大きな値の設定が実用的ですが、これによりデータ・ウェアハウスで抽出および更新されるレコードの数が多くなります。そのため、削除日数の値は非常に大きな数には設定しないでください。大きな削除日数の数値は、以前に処理した、変更のないレコードの再抽出をトリガーするためにも使用されます。削除日数の値は、絶対に0に設定しないでください。

前述したように、1つのETLプロセスで単一の表から1つのレコードを抽出できますが、複数の表を結合した後の成果物である複数のレコードの抽出に使用するほうが一般的です。複数の表から抽出するときには、1つの表がベース表として識別されます。この表により、レコードの粒度が定義されます。ベース表に変更があると、レコードの抽出がトリガーされます。ただし、ベース表以外の表に変更が加えられたにもかかわらず、ベース表自体には変更がない場合があります。ベース表以外に変更があったときにもレコードの抽出をトリガーする必要がある場合は、これらの表を補助表として参照します。つまり、レコードの抽出が必要かどうかを判断するときに、ベース表のLUD列だけでなく、すべての補助表のLUD列も比較されるということです。これらの表のいずれかでLUD列に変更があると、レコードが抽出されます。抽出のトリガー操作に関連付けられていない表に変更があった場合、増分フィルタリング・ロジックでは、この表のLUD列が比較されません。

ナレッジ・モジュールについて

ナレッジ・モジュール(KM)は、Oracle Business Analytics Warehouseシステム内の各種タスクを実装します。使用可能な各種のKMは次のとおりです。

- リバースエンジニアリング(RKM)。ソース・データベースから表などのオブジェクト・メタデータを読み取って、表、列、索引をモデルにインポートするために使用します。RKMの詳細は、「リバース・ナレッジ・モジュールについて」を参照してください。

- ローディング(LKM)。ステージング領域へのロード時に、ソース・データベースからのデータ抽出を効率化するために使用します(使用可能な場合は、データベース固有のバルク・アンロード・ユーティリティを使用できる)。

- 統合(IKM)。各種の戦略(遅延変更ディメンションや、挿入/更新戦略など)を使用してターゲットにデータをロードするために使用します。

- チェック(CKM)。データの検証とクレンジングに使用します。

- ジャーナル化(JKM)。単一の表またはビューのいずれか、または表やビューの一貫したセットの中にある、新しいデータと変更されたデータを記録するために使用します。

- サービス(SKM)。Webサービスの形式でデータを公開します。

Oracle BI Applicationsで使用可能なKMの詳細は、付録B「ナレッジ・モジュールのリファレンス」を参照してください。

リバース・ナレッジ・モジュールについて

Oracle BI Applicationsでは、ODIリーバス・エンジニアリング・プロセスを使用して、ソース・システムのメタデータをリポジトリに移入します。RKMは、データ・ストレージからメタデータを取得して、そのメタデータをリポジトリにロードします。たとえば、RKMは、データベースから表、列、データ型、制約の説明およびコメントを検出して、リポジトリにロードします。RKMは、データベース、XMLファイル、各種のフラット・ファイルなど、様々なテクノロジをサポートしています。また、RKMを使用して、データベースまたはアプリケーション(Oracle E-Business Suite、Siebel CRM、PeopleSoftなど)から非標準のメタデータを取得することもできます。

RKMロールは、モデルに対してカスタマイズされたリバース・エンジニアリングを実行するためのものです。RKMは、アプリケーションまたはメタデータ・プロバイダへの接続とメタデータの変換、およびその結果のODIリポジトリへの書き込みを処理します。メタデータは、一時表に書き込まれます。その後、RKMがODI APIを呼び出して、これらの表からメタデータを読み取ってから、それらを作業リポジトリのODIメタデータ表に増分更新モードで書き込みます。

Oracle BI ApplicationsのODIリポジトリには、関連するソース・データの各モデルが格納されています。そのため、RKMの実行は、ソース・システムにカスタマイズされた表があって、その変更内容をODIリポジトリにインポートする場合にのみ必要になります。表とタスクのカスタマイズの詳細は、『Oracle Business Intelligence Applications管理者ガイド』を参照してください。

マルチソース環境について

Oracle BI Applicationsでは、Oracle Business Analytics Warehouseへの複数のソース・システムからのデータ・ロードがサポートされています。2つの異なるソースで同一のアダプタが必要な場合は、ODIリポジトリで複製するアダプタのモデルとマップが必要になります。

マルチソースの例

PeopleSoft 9.0ソースとOracle EBS 11.5.10ソースがあって、その両方がターゲット・ファクト表ASTXACT_FGをロードしているシナリオについて考えてみましょう。このターゲット表のロードには、次の3つのシリアル・ステップが含まれます。

1. ターゲット表(ASTXACT_FG)の初期化。

2. ターゲット表(ASTXACT_FG)のロード。

3. ターゲット表(ASTXACT_FG)のファイナライズ。

図1-3に、ODI Studioにおけるこれらのロード・プラン・ステップを示します。

図1-3 マルチソースのロード・プラン

両方のソース(PeopleSoft 9.0およびOracle EBS 11.5.10)からのデータは、初めてターゲット表(ASTXACT_FG)にロードされています。つまり、フル・ロードが行われます。一般に、フル・ロードの実行時にはターゲット表が切り捨てられます。この場合、これらのデータ・ソースは相互に依存していないため、ロード・プランをパラレルで実行できます。ただし、2つ目のソースからのロードによって、ターゲット表が切り捨てられないようにする必要があります(最初のソースのデータがすでに格納されている場合)。この問題は、次のように解決します。ターゲット表の初期化ステップでターゲット表を切り捨てます。その次のターゲット表のロード・ステップに、2つの子パラレル・ステップを含めます。これらでは、それぞれターゲットが各ソース・システムからロードされます。最後に、ターゲット表のファイナライズ・ステップで、索引が作成されて表が分析されます。したがって、生成されたロード・プランでは、必要なときにのみ(ここでは、ソース・システムが表をロードする前の1回のみ)表が切り捨てられます。

リソースごとに個別のロード・プランを用意できますが、ロード・プランのパラレル実行はできません。

注意:

Oracle BI Applications構成マネージャおよびODIでは、ロード・プランのパラレル実行が禁止されていませんが、これは、次の理由から実行しないことをお薦めします。

- すべてのロード・プランでは、初期ロード時にターゲット表が切り捨てられます。ロード・プランをパラレルで実行すると、前のロード・プランでロードしたデータが、もう一方のロード・プランで切り捨てられることがあります。

- SILOS以降のマッピングは、共通のものであり、ソース・システムに基づいていません。ロード・プランをパラレルで実行すると、最初のソースからロードされたデータが原因で、2つ目のソースのデータが部分的にしかロードされない状況が発生することがあります。この問題を解決するには、最初のロード・プランが正常に完了したことを確認してから、2つ目のロード・プランを実行する必要があります。
つまり、ファクト表のロード時には、最終的なデータを得るためにファクト表が複数のディメンション表やルックアップ表に接続している可能性があるということです。ロード・プランをパラレルで実行しているときには、ディメンション表、ルックアップ表、ステージング表の一部に2つ目のソースのデータが含まれている可能性もあります。この場合、ロードが完了していないことが原因で、2番目のソースの一部のルックアップ表とディメンション表で適切な値が返されないことがあります。

ETLのロールについて

Oracle BI Applicationsには、ETL操作用の2つの職務ロールがあります。

- ロード・プラン・オペレータ職務

- ロード・プラン管理者職務

Oracle BI Applicationsには、次の追加の職務ロールがあります。

- BI Applications管理者職務

- BI Applications機能開発者職務

- BI Applications実装マネージャ職務

構成マネージャおよび機能設定マネージャへのアクセスは、これらの職務ロールによって制御されています。

セキュリティ管理者は、ユーザーのジョブ職責に基づいて、適切な職務ロールをユーザーに付与する必要があります。各職務ロールがアクセスできる構成マネージャおよび機能設定マネージャの画面については、『Oracle Business Intelligence Applicationsセキュリティ・ガイド』を参照してください。

BI Applications管理者、ロード・プラン・オペレータ、ロード・プラン管理者の各ユーザーは、ODIへの適切なアクセス権が必要になります。これらのユーザーは、LDAPシステムのみでなく、ODIリポジトリで作成する必要があります。また、スーパーバイザ・プロファイルまたは適切なODIプロファイルを付与する必要もあります。BI Applications管理者には、ODIのスーパーバイザ・ロールを付与する必要があります。セキュリティ管理者と協働して、適切な職務ロールを取得してください。

ODIでのセキュリティ管理の詳細は、Oracle Fusion Middleware Oracle Data Integrator開発者ガイドを参照してください。

2 ロード・プランの管理

この章では、Oracle BI Applications構成マネージャを使用した、Oracle BI Applicationsのロード・プランの管理について説明します。

ロード・プランを管理するタスクは通常、ETL開発者またはETLオペレータが実行します。次に示すように、この項の各タスクは、一般に特定のタスクを実行するロール別にグループ化されています。

ETL開発者のタスク

- ロード・プランの定義

- ロード・プランの複製

- ロード・プランの編集

- ロード・プランの生成

- ロード・プランのスケジューリング

- ロード・プランの実行

ETLオペレータのタスク

- ロード・プラン実行のモニター

- ロード・プランの再開

- ロード・プランの停止

ロード・プランのライフ・サイクルの概要

ロード・プランのライフ・サイクルは、次の各フェーズで構成されています。

- フェーズ1: ロード・プランの定義
このフェーズでは、Oracle BI Applications構成マネージャでロード・プランのプロパティを定義します。これには、データ・ソースおよび1つ以上のファクト・グループの選択が含まれます。この選択により、ETLプロセス中に実行する必要のあるステップが決まります。

- フェーズ2: ロード・プランの生成
このフェーズでは、Oracle BI Applications構成マネージャから生成プロセスを開始します。これにより、ロード・プランの作成場所であるODIリポジトリに、ロード・プランのプロパティが伝播されます。

- フェーズ3: ロード・プランの実行
このフェーズでは、Oracle BI Applications構成ウィザードからロード・プラン実行を開始します。これにより、ロード・プランの各ステップが実行されます。ロード・プランを実行すると、ロード・プラン・インスタンスと、初回ロード・プラン実行が作成されます。実行を再開すると、このロード・プラン・インスタンスに新しいロード・プラン実行が作成されます。ロード・プラン・インスタンスの実行を試行するたびに、その試行内容が個別のロード・プラン実行としてログに保存されます。

- フェーズ4: ロード・プランのモニター
このフェーズでは、ロード・プラン実行をOracle BI Applications構成マネージャの「ロード・プランの詳細」ページでモニターします。「ロード・プランの詳細」ページでは、Oracle Data Integratorコンソールを通じてODIリポジトリのビューが表示されます。

ロード・プランの定義

次の手順を実行して、ロード・プランを定義します。

ロード・プランを定義するには:

1. Oracle BI Applications構成マネージャの「タスク」ペインで、「ロード・プラン管理」という見出しの下に表示される「ロード・プランの管理」を選択します。
「ロード・プランの管理」ページが表示されます。

2. 「ロード・プラン」ツールバーで、「追加」アイコンをクリックします。
「ロード・プランの定義」ページが表示されます。

3. 一連の「ロード・プランの定義」の最初のページで、次の情報を指定します。

フィールド

説明

名前

ロード・プランの一意の名前を入力します。

摘要

(オプション)ロード・プランについての追加情報を入力します。

ロード・プランタイプ

ロード・プラン・タイプを選択します。使用可能な値は次のとおりです。

- ソース抽出(SDE): ソースから抽出して、ステージング表にデータをロードするタスクのみを含めます。

- ソースの抽出とロード(SDE、SILおよびPLP): ソースから抽出して、データ・ウェアハウス表をロードするタスクをすべて含めます。

- ウェアハウス・ロード(SILおよびPLP): ステージング表から抽出して、データ・ウェアハウス表にロードするタスクのみを含めます。
ソース固有のロード・プランとデータ・ウェアハウス固有のロード・プランを個別に生成することが役立つ場合があります。ロード・プランを分離することで、ほとんどのユーザーがソース・システムを使用していない時間帯にソース固有のロード・プランをスケジュールして、ほとんどのユーザーがデータ・ウェアハウスを使用していないときに別個のデータ・ウェアハウスのロードをスケジュールできるようになります。

- ドメインのみの抽出とロード(SDEおよびSIL): ドメイン関連のレコードをソースから抽出し、Oracle Business Analytics Warehouseのドメイン関連の表にデータをロードするためのタスクをすべて含めます。Oracle BI Applications構成マネージャでは、ドメインが広範に使用されているため、通常のロード・プランを実行する前に、いくつかのプロパティを構成しておく必要があります。該当するプロパティは、トランザクション・データベースで検出されたドメインの値によって決まります。

ソース・インスタンス

ファクト・グループの選択元になるデータ・ソースを選択します。

4. 「次へ」をクリックします。
一連の「ロード・プランの定義」の2ページ目が表示されます。

5. 「使用可能な選択項目」タブで、ロード・プラン定義に含めるファクト・グループを選択します。
ファクト・グループは、ファクト・グループの階層に属している可能性があります。最上位レベルの親ファクト・グループのみを選択できます。子ファクト・グループは選択できません。

ロード・プランには、少なくとも1つのファクト・グループを含める必要があります。1つまたは複数のデータ・ソースから複数のファクト・グループを選択することもできます。

6. 「保存」をクリックします。次のオプションが含まれるサブメニューが表示されます。

- 「保存」をクリックすると、ロード・プランが保存されます。保存したロード・プランは、「ロード・プラン」マスター・リストに表示されます。

- 「ロード計画の保存および生成」をクリックすると、ロード・プランが、保存されてからすぐに生成されます。

ロード・プランの複製

次の手順を実行して、既存のロード・プランを複製します。

既存のロード・プランを複製するには:

1. Oracle BI Applications構成マネージャの「タスク」ペインで、「ロード・プラン管理」という見出しの下に表示される「ロード・プランの管理」を選択します。
「ロード・プランの管理」ページが表示されます。

2. 「ロード・プラン」マスター・リストで、複製するロード・プランを選択します。

3. 「ロード・プラン」ツールバーで、「複製」アイコンをクリックします。
「ロード・プランの複製」ページが表示されます。

4. 一連の「ロード・プランの複製」の最初のページで、次の情報を指定します。

フィールド

説明

名前

ロード・プランの一意の名前を入力します。

摘要

(オプション)ロード・プランについての追加情報を入力します。

ロード・プランタイプ

(オプション)ロード・プラン・タイプを選択します。使用可能な値は次のとおりです。

- ソース抽出(SDE)

- ソースの抽出とロード(SDE、SILおよびPLP)

- ウェアハウス・ロード(SILおよびPLP)

- ドメインのみの抽出とロード(SDEおよびSIL)

ソース・インスタンス

(オプション)ファクト・グループの選択元になるデータ・ソースを選択します。

5. 「次へ」をクリックします。
一連の「ロード・プランの複製」の2ページ目が表示されます。

6. 「使用可能な選択項目」タブで、ロード・プラン定義に含めるファクト・グループを選択します。
ファクト・グループは、ファクト・グループの階層に属している可能性があります。最上位レベルの親ファクト・グループのみを選択できます。子ファクト・グループは選択できません。

ロード・プランには、少なくとも1つのファクト・グループを含める必要があります。1つまたは複数のデータ・ソースから複数のファクト・グループを選択することもできます。

7. 「保存」をクリックします。次のオプションが含まれるサブメニューが表示されます。

- 「保存」をクリックすると、ロード・プランが保存されます。保存したロード・プランは、「ロード・プラン」マスター・リストに表示されます。

- 「ロード計画の保存および生成」をクリックすると、ロード・プランが、保存されてからすぐに生成されます。

ロード・プランの編集

次の手順を実行して、既存のロード・プランを編集します。

既存のロード・プランを編集するには:

1. Oracle BI Applications構成マネージャの「タスク」ペインで、「ロード・プラン管理」という見出しの下に表示される「ロード・プランの管理」を選択します。
「ロード・プランの管理」ページが表示されます。

2. 「ロード・プラン」マスター・リストで、編集するロード・プランを選択します。

3. 「ロード・プラン」ツールバーで、「編集」アイコンをクリックします。
「ロード・プランの編集」ページが表示されます。

4. 次のプロパティを編集できます。

フィールド

説明

名前

ロード・プランの一意の名前を入力します。

摘要

(オプション)ロード・プランについての追加情報を入力します。

ロード・プランタイプ

(オプション)ロード・プラン・タイプを選択します。使用可能な値は次のとおりです。

- ソース抽出(SDE)

- ソースの抽出とロード(SDE、SILおよびPLP)

- ウェアハウス・ロード(SILおよびPLP)

- ドメインのみの抽出とロード(SDEおよびSIL)

ソース・インスタンス

(オプション)ファクト・グループの選択元になるデータ・ソースを選択します。

5. 「次へ」をクリックします。
一連の「ロード・プランの編集」の2ページ目が表示されます。

6. 「使用可能な選択項目」タブで、ロード・プラン定義に含めるファクト・グループを選択します。
ファクト・グループは、ファクト・グループの階層に属している可能性があります。最上位レベルの親ファクト・グループのみを選択できます。子ファクト・グループは選択できません。

ロード・プランには、少なくとも1つのファクト・グループを含める必要があります。1つまたは複数のデータ・ソースから複数のファクト・グループを選択することもできます。

7. 「保存」をクリックします。次のオプションが含まれるサブメニューが表示されます。

- 「保存」をクリックすると、ロード・プランが保存されます。保存したロード・プランは、「ロード・プラン」マスター・リストに表示されます。

- 「ロード計画の保存および生成」をクリックすると、ロード・プランが、保存されてからすぐに生成されます。

ロード・プランの生成

ロード・プランを生成すると、そのロード・プランがODIリポジトリで作成されます。ロード・プランは、実行前に正常に生成しておく必要があります。

注意: ロード・プランは、逐次生成しないと処理に失敗します。あるロード・プランの生成が進行中の場合は、2つ目のロード・プランの生成を開始しないでください。最初の生成プロセスが完了するまで待機してから、次の生成プロセスを開始する必要があります。

ロード・プランを生成するには:

1. Oracle BI Applications構成マネージャの「タスク」ペインで、「ロード・プラン管理」という見出しの下に表示される「ロード・プランの管理」を選択します。
「ロード・プランの管理」ページが表示されます。

2. 「ロード・プラン」マスター・リストで、生成するロード・プランを選択します。

3. 「ロード・プラン」ツールバーで、「生成」アイコンをクリックします。
次のアイコンは、「ロード・プラン」マスター・リストの「生成ステータス」列に表示される、使用可能な生成ステータスを示しています。「リフレッシュ」アイコンをクリックして、表示をリフレッシュします。

「生成ステータス」アイコン

説明

開始

進行中

成功

失敗

正常に生成されたロード・プランは、実行したり、後で実行するようにスケジューリングすることができます。

ロード・プランのスケジューリング

次の手順を実行して、ロード・プランの実行をスケジューリングします。

ロード・プランの実行をスケジューリングするには:

1. Oracle BI Applications構成マネージャの「タスク」ペインで、「ロード・プラン管理」という見出しの下に表示される「ロード・プランの管理」を選択します。
「ロード・プランの管理」ページが表示されます。

2. 「ロード・プラン」リストで、スケジューリングするロード・プランを選択します。

3. 「スケジュール」タブを選択します。

4. 「スケジュール」タブのツールバーで、「追加」をクリックします。
「ロード・プランのスケジュール」ダイアログが表示されます。

5. 次の情報を指定します。

フィールド

説明

コンテキスト

ロード・プランの実行時に使用するODIコンテキスト。サポートされるコンテキストは、「グローバル」のみです。

ローカル・エージェント

ロード・プランの実行時に使用するODIローカル・エージェント。

ログ・レベル

保持するロギング情報のレベル。Oracle BI Applications構成マネージャでは、Oracle Diagnostic Loggingを使用します。ログ・ファイルと診断データの管理については、『Oracle Fusion Middleware管理者ガイド』を参照してください。

ステータス

スケジュールのステータス。使用可能な値は次のとおりです。

- アクティブ

- 非アクティブ

- アクティブ期間

反復

発生頻度。使用可能な値は次のとおりです。

- エージェント起動時

- 単純

- 毎時

- 毎日

- 毎週

- 毎月(月日付)

- 毎月(曜日)

- 毎年

「反復」オプションの選択内容に応じて、日時の選択オプションが動的に表示されます。

6. 「スケジュール」をクリックします。

ロード・プランの実行

次の手順を実行して、ロード・プランを実行します。次の点に注意してください。

- リソースごとに個別のロード・プランを用意できますが、ロード・プランのパラレル実行はできません。

- ロード・プランは、正常に生成されている場合にのみ実行できます。手順については、「ロード・プランの生成」を参照してください。

ロード・プランを実行するには:

1. Oracle BI Applications構成マネージャの「タスク」ペインで、「ロード・プラン管理」という見出しの下に表示される「ロード・プランの管理」を選択します。
「ロード・プランの管理」ページが表示されます。

2. 「ロード・プラン」リストで、実行するロード・プランを選択します。

3. 「ロード・プラン」ツールバーで、「実行」アイコンをクリックします。
「ロード・プランの実行ダイアログ」が表示されます。

4. 次の情報を指定します。

フィールド

説明

コンテキスト

ロード・プランの実行時に使用するODIコンテキスト。サポートされるコンテキストは、「グローバル」のみです。

ローカル・エージェント

ロード・プランの実行時に使用するODIローカル・エージェント。

Oracle Data Integrator作業リポジトリ

ODI作業リポジトリの名前。

5. 「OK」をクリックします。
次のアイコンは、「ロード・プラン」マスター・リストの「実行ステータス」列に表示される、使用可能な実行ステータスを示しています。「リフレッシュ」アイコンをクリックして、表示をリフレッシュします。

「生成ステータス」アイコン

説明

開始

進行中

成功

失敗

実行しない

6. (オプション)「実行ステータスの詳細の表示」アイコンをクリックして、実行のステータスに関する詳細情報を表示します。

ロード・プラン実行のモニター

ロード・プラン実行は、Oracle BI Applications構成マネージャの「ロード・プラン実行の詳細」ページの実行ステータス情報を参照することでモニターできます。

ロード・プラン実行の詳細を表示するには:

1. Oracle BI Applications構成マネージャの「タスク」ペインで、「ロード・プラン管理」という見出しの下に表示される「ロード・プランの管理」を選択します。
「ロード・プランの管理」ページが表示されます。

2. 「ロード・プラン」マスター・リストで、参照するロード・プラン実行を選択します。

3. 「ロード・プラン」ツールバーで、「実行ステータスの詳細の表示」アイコンをクリックします。
Oracle Data Integratorコンソールが表示されます。

4. 適切な「ユーザーID」と「パスワード」を入力して、Oracle Data Integratorコンソールにログインします。
「ロード・プランの詳細」ページが表示されます。

このページに表示される情報の説明については、「「ロード・プランの詳細」ページ」を参照してください。

ロード・プランの再開

この項では、失敗したロード・プランの再開について説明します。次の項が含まれます:

- ロード・プランの再開可能性の概要

- 再開可能性の単位について

- ロード・プランの再開

- ロード・プランのトラブルシューティング

- ロード・プランの再開用の代替オプション

- 関連機能および考慮事項

ロード・プランの再開可能性の概要

ETLを実行して、ソース・システムのデータをOracle Business Analytics Warehouseにロードする場合、失敗したETLロードの再開が必要になることがあります。この項では、再開用に使用可能なオプションと、これらの各オプションを使用したときの影響について説明します。

ロード・プランが失敗する状況と原因の例には、次のものがあります。

- ネットワーク障害、ユーザー名とパスワードの期限切れや誤りを原因とする、ソースまたはターゲット・データベースへのアクセスの問題。

- ODIエージェントの障害。

- 領域またはストレージの問題。ソースまたはターゲット・データベースに接続できても、一時領域やディスク領域の不足により、問合せの実行に失敗する場合などです。ファイルの場合は、ファイルの配置場所に十分な空き領域がないことが原因になります。

- データの問題。たとえば、ターゲット列が保持できる長さを超えている不適切なデータや、「NOT NULL」列におけるNull値などがあります。

ETLの実行中にこのような失敗が発生した場合、失敗したロード・プラン全体の再開(すべてのETLタスクの再実行が必要になる非能率的な作業)を回避するには、失敗の原因を診断および解決した後で、ロード・プラン実行の同じポイント(失敗が発生した時点)からロードを再開する必要があります。

再開可能性の単位について

失敗したロード・プランを再開するときには、失敗の発生場所やロード・プランのステップ間の依存関係によっては、失敗の厳密な発生ポイントから再開できないことがあります。再開可能なポイントとは、ロード・プランの失敗の種類に関係なく、ロード・プラン実行の最終結果が同じになるポイントのことです。

次の例では、完了済のステップを再実行する際の依存関係を対象とした要件について説明します。あるロード・プランには2つのステップがあり、最初のステップでは表が切り捨てられ、2つ目のステップでは表にレコードが挿入されます(その間にレコードがコミットされる)。このロード・プランを実行すると、2つ目のステップが空き領域の問題が原因で失敗します。問題の解決後に、2つ目のステップからロード・プランを再開することは不適切な処理です。ターゲットには複数の行が挿入されているからです。そうではなく、最初のステップから再開する必要があります。これにより、ターゲット表が再度切り捨てられるため、新たに挿入したデータによって重複が発生することはなくなります。

再開時におけるデータの整合性を保持するために、その単位は、失敗したステップのステップ階層での位置や、ロード・プラン・マネージャのステップの「再開」設定に応じて変化します。

ロード・プラン・マネージャの「ステップ階層」では、ステップの「再開」設定を「再開」列で参照および編集できます。階層内の各ステップに応じたデフォルト設定により、再開時のデータ整合性が確保されます。

- ルート・ステップは、シリアルの場合は「失敗から再開」に、パラレルの場合は「失敗した子から再開」に設定されます。

- サブ・ステップは、シリアルの場合は「失敗から再開」に、パラレルの場合は「失敗した子から再開」に設定されます。

- シナリオ・ステップは、「失敗したステップから再開」に設定されます。

次の例では、ロード・プラン・ステップのタイプごとの影響について説明します。

シリアルのロード・プラン・ステップ

シリアル・ステップは、ロード・プラン・マネージャのステップ階層では水平アイコンで表されています。また、デフォルトでは、「再開」の設定が「失敗から再開」に設定されています。個々のディメンションを複数のシリアル・サブステップでロードする、ディメンション・グループのロード用ステップを実行する場合、ロード・プランが失敗したときは、再開時のロード・プランが、失敗の原因となった個々のサブステップから開始されます。正常に完了したシリアル・サブステップは、再実行されません。

パラレルのロード・プラン・ステップ

パラレル・ステップは、ロード・プラン・マネージャのステップ階層では垂直アイコンで表されています。また、デフォルトでは、「再開」の設定が「失敗した子から再開」に設定されています。通常の実行の場合、5つのパラレル・サブステップを配下に置く1つのパラレル・ステップでは、5つのサブステップがすべてパラレルで実行されます(使用可能な空きセッションが存在することが条件です)。これら5つのステップのうちの2つが完了しているときにロード・プランが失敗した場合、ロード・プランが再開されると、完了しなかったステップと失敗したステップがすべて再開されます。

シナリオ・ステップ

あらゆるロード・プランの最下位に位置するのがシナリオ・ステップです。親ステップは、(シリアルまたはパラレルにかかわらず)依存関係の設定に使用されますが、シナリオ・ステップは、表のロードを行います。1つのシナリオ・ステップには、パッケージ内のステップ数に応じて1つ以上のサブステップが含まれていることもあります。

実行時にシナリオ・ステップが失敗した場合、そのシナリオ・ステップが複数のステップを含んでいる可能性があることに注意してください。オペレータ・ログでは、同じセッションの下にそれらがすべて記載されていますが、異なるステップ番号(0、1、2など)で識別されています。再開する場合、シナリオは失敗した親シナリオ・ステップから実行されます(すべてのサブステップが再実行される)。

注意:

ロード・プランの生成にロード・プラン・ジェネレータを使用すると、ロード・プランが前述の標準に自動的に準拠するようになります。生成されたロード・プランを手動で変更する場合や、ロード・プラン・ジェネレータを使用しないで新しいロード・プランを作成する場合は、前述の標準に準拠するようにしてください。

ロード・プランの再開

ODI StudioまたはODIコンソールを使用して、ロード・プランを再開します。この項では、ロード・プランの再開方法について説明します。次の項が含まれます:

- ODI Studioを使用した再開

- ODIコンソールを使用した再開

ODI Studioを使用した再開

次の手順を実行して、ODI Studioを使用してロード・プランを再開します。再開オプションは、ロード・プランの最終実行でのみ有効になります。ロード・プランは何度でも再開できます。また、そのたびに前回の失敗より前にロード・プランが進みます。

ODI Studioを使用してロード・プランを再開するには:

1. ODIオペレータで、オペレータ・ログに移動して、ロード・プランの最後に失敗した実行を選択します。

2. ロード・プラン実行をダブルクリックして、「再開」オプションを選択します。オペレータ・ログで最終実行を右クリックして、「再開」を選択することもできます。

ODIコンソールを使用した再開

次の手順を実行して、ODIコンソールを使用してロード・プランを再開します。再開オプションは、ロード・プランの最終実行でのみ有効になります。ロード・プランは何度でも再開できます。また、そのたびに前回の失敗より前にロード・プランが進みます。

ODIオペレータを使用してロード・プランを再開するには:

1. ODIコンソールで「ランタイム」に移動し、「セッション/ロード計画実行」を選択してから、失敗したロード・プラン実行を選択します。

2. 「再開」をクリックします。「再開」ボタンは、選択したロード・プランが最後に実行したロード・プランの場合にのみ表示されます。

ロード・プランのトラブルシューティング

エラーで停止したロード・プランは、再開する必要があります。再開が必要になる別の状況としては、ロード・プランで何も実行されていない場合があります。たとえば、ロード・プランが実行されてから30分経ったのに何の変化もない場合があります。次のチェックリストは、無反応のロード・プランをトラブルシューティングする際に使用してください。

1. エージェントに対して設定した、実行可能な最大セッション数を確認します。ODIオペレータで、実行中のセッション数がこの最大数と等しいことを確認します。その場合、他のセッションは実行中のセッションの完了を待機しています。次のステップに進みます。

2. 失効したセッションを除去します。失効したセッションとは、エージェントまたはリポジトリのクラッシュ後に、誤って実行中の状態が保持されているセッションのことです。セッションの開始後に、エージェントがクラッシュしたり、リポジトリへの接続を失ったりすると、リポジトリでセッションのステータスを更新できなくなり、そのようなセッションが失効してしまいます。失効したセッションが除去されるまで、リポジトリではそのセッションが実行中として示されますが、実際にはそうではありません。
失効したセッションは複数の方法で除去できます。次に、いくつかの例を示します。

- オペレータ・ナビゲータまたはトポロジ・ナビゲータで、特定のエージェントに対して、失効したセッションを除去するように手動で要求できます。

- 失効したセッションは、エージェントの再開時に除去されます。

- エージェントは新しいセッションを開始するときに、失効したセッションを確認して解決します。ただし、エージェントがリポジトリへの接続を失うと、失効したセッションを除去できなくなります。

3. エージェントが動作しているかどうかを確認します。エージェントが実行中であり、リポジトリへの接続を維持しているかどうかを確認するテストを行うには、ODI Studioのトポロジ・ナビゲータでエージェントを開いて、「テスト」タブを選択します。エージェントのテストに失敗した場合は、問題の修正後にエージェントを再開します。

4. ODIリポジトリと、このリポジトリをホストしているサーバーが実行中であり、障害が発生していないことを確認します。

5. エラーが発生したロード・プランで、前述のすべての項目を確認した後、ロード・プランを再開します。

ロード・プランの再開用の代替オプション

この項では、失敗したロード・プランを再開するための代替方法について説明します。次の項が含まれます:

- 「完了としてマーク」の使用

- シナリオのスタンドアロン実行

「完了としてマーク」の使用

ほとんどの場合は、この項の前半で説明したロード・プランの再開方法が推奨されたアプローチです。このアプローチでは、データ整合性が確保されるため、手動エラーの余地はありません。ただし、ロード・プラン・ステップを手動で実行することが必要になる場合もあります。たとえば、あるステップが重複レコードを挿入していることが失敗の原因であるときに、そのステップを再実行すると重複レコードがまた挿入されてしまいます。このような場合、ロード・プランとは別に手動でデータを修正して、そのステップをロード・プランの再開時にスキップする必要があることがあります。このような状況では、「完了としてマーク」オプションを使用できます。

ロード・プラン・ステップを完了としてマークすると、ロード・プランの再開時に、マークされているステップは実行されません。この設定を行った担当者は、そのステップのロードをロード・プランとは別に実施する責任を負います。

ステップを完了としてマークするには、ステップを右クリックして「完了としてマーク」を選択します。これは、シナリオ・ステップ、またはそれより上位のステップで行えます。

ステップ階層のより上位にあるレベルで、ステップを完了としてマークすると、ロード・プランの再開時に、その親ステップの下にあるすべての子ステップが(実際には実行対象である場合でも)実行されなくなります。このような理由から、ステップを完了としてマークすることは高度なタスクと見なされており、その影響を完全に理解してから実行する必要があります。すべてのケースに当てはまる単一の推奨事項はありません。そのため、この設定は慎重にケース・バイ・ケースの判断で行ってください。

シナリオのスタンドアロン実行

ロード・プランをモニターしているときに、シナリオ・ステップの失敗を修正する方法が完全にはわからないこともあります。このような場合、完全な解決策を待つのではなく、「完了としてマーク」オプションの使用を望むことがあります。これにより、1つのステップの失敗でロード・プラン全体の完了が妨げられることがなくなる一方、失敗したシナリオ・ステップに関する情報をETLチームに通知して、解決に取り組めるようになります。その後、ETLチームがシナリオを修正し、そのシナリオをロード・プランとは別にスタンドアロンで実行してロードを完了することがあります。

ステップを完了としてマークする場合と同様に、シナリオをスタンドアロンで実行することは高度なタスクと見なされているため、シナリオ実行の担当者は、次の点に注意する必要があります。

- ロード・プランとは別に実行されるシナリオ自体で、表メンテナンス・プロセスが起動されます。これにより、設定によっては、ロード前に表が切り捨てられます。
これを理解するために、あるシナリオをロード・プランの内部で実行するときに、明示的なステップとして表メンテナンス・タスクが実行される場合について考えてみましょう(このステップの親ステップ名は「初期化」または「ファイナライズ」になる)。このシナリオは、ロード・プラン内から実行された場合は、表メンテナンス・プロセスを呼び出しません。正確にいうと、これはEXECUTION_ID変数で制御されています。これは、ロード・プランのインスタンスIDに設定されます。シナリオの実行時に、この変数が0より大きな値である場合、インスタンスIDを指定してロード・プラン内からシナリオを実行した場合と同様、表メンテナンス・プロセスが呼び出されなくなります。一方、この変数が0より大きな値でない場合は、シナリオが表メンテナンス・プロセスを呼び出します。これは、ロード・プランとは別にシナリオが実行されたときの状態です。ロード・プランとは別にシナリオを呼び出しているときに、EXECUTION_IDに値を設定すると、表メンテナンスのステップが呼び出されなくなります。

- シナリオ・ステップでは、多くの変数値が設定されていることがあります。ロード・プラン内では、この値は、動的に設定(変数のリフレッシュの場合)されるか、明示的に設定(そのシナリオ・ステップで値をオーバーライドする)されます。ロード・プランとは別にシナリオを実行すると、すべてのシナリオ変数にデフォルト値のみが設定されるようになります。このような理由から、ロード・プランとは別にシナリオを呼び出す前に、該当する変数を慎重かつ適切に設定しておく必要があります。ロード・プラン内に存在する変数の値は、オペレータ・ログを調べることで確認できます(ロード・プランの実行時に、ログ・レベルを6に設定した場合)。Oracle BI Applications構成マネージャでは、Oracle Diagnostic Loggingを使用します。ログ・ファイルと診断データの管理については、『Oracle Fusion Middleware管理者ガイド』を参照してください。

関連機能および考慮事項

この項では、再開可能性に関連するOracle BI Applicationsの機能のいくつかを示し、関連する考慮事項の一部を説明します。

CKMを使用した誤ったデータのフィルタ処理

シナリオ・ステップが不正なソース・データが原因で失敗するときには、CKMオプションを有効化して、有効なレコードをロードして、エラー・レコードを別の表にルーティングすることが望ましい場合があります。このような状況の例として、値が必要なときにNull値をロードする場合や、ターゲット列で許容されている長さを超えるデータをロードする場合です。ロードの完了後は、誤ったデータを修正して、後続のロードで自動的に取得できます。

注意:

CKMを使用すると、ロードの速度が大幅に低下することがあります。これは、すべてのレコードと列がロード前に確認されることがあるためです。このため、このオプションをロード・プラン全体に対して有効にしないでください。

ロード・プラン実行中のシナリオの再生成

ロード・プランを開始した後、あるシナリオ・ステップで失敗する場合について考えてみましょう。問題を修正し、シナリオを再生成した後で、そのロード・プランを再開すると、新しいシナリオが取得されることが予期されますが、実際にはそうなりません。ロード・プランがすでに開始されていたときにシナリオを再生成すると、再生成されたシナリオ・コードは、そのロード・プランの再開時に取得されません。再生成したシナリオの取得を強制するには、次の2つのオプションを実行します。

- 新しいロード・プラン実行を開始します(ロードを最初から再開することに付随するオーバーヘッドを許容する)。

- 再生成したシナリオをロード・プランとは別にスタンドアロンとして実行します(ロード・プランを再開する前に、そのシナリオ・ステップをロード・プラン内で完了としてマークする)。これらのオプションを使用した場合の影響については、「「完了としてマーク」の使用」および「シナリオのスタンドアロン実行」を参照してください。

長時間実行ジョブの再開

実行に2時間かかるシナリオがある場合について考えてみましょう。このシナリオは、C$ステップとI$ステップのロード後に、新しい行を挿入するステップで失敗します。再開時には、シナリオでC$の再ロードが再試行されます。そうするのではなく、新しい行を挿入するステップからのみの再開が望まれますが、このような使用はサポートされていません。再開可能性のメカニズムは、ロード・プランを再開するだけで十分になるように導入されています。各ロード・プラン実行の間でデータをクリーンアップする必要はありません。これは、すべてのナレッジ・モジュールのステップが成功した後にのみ、ターゲット表にデータがコミットされるためです。正常に完了する前にロードが失敗した場合は、失敗したセッションの一環として、特定のターゲット表にデータがコミットされることはありません。(注意: C$表とI$表は再開時に新規作成されるため、それらの表に対するデータは、操作の合間にコミットされます)。

注意:

新しいC$表とI$表は再開時に作成されるため、それらの表に対するデータは、ロード・プランの開始と再開の合間にコミットされます。

失効したC$表およびI$表

再開時には、新しいC$表とI$表が作成されますが、前回のロードは完了していないため、前回のセッションからのこれらの表は削除されていません。ロード・プラン・ジェネレータを使用して生成したロード・プランには、ロード・プランの最後の部分に「失効した作業表の除去」というステップが含まれています。このステップは、ETL_DTOP_STG_OLDER_THAN_DAYSという変数をとります。この変数のデフォルト値は30日です。このステップを実行すると、指定された変数値よりも古いC$表とI$表が削除されます。

注意:

C$表とI$表は、失敗したシナリオをデバッグする際に役立つ表です。デバッグ用の重要情報が失われてしまう可能性があるため、ETL_DTOP_STG_OLDER_THAN_DAYSに小さすぎる値(たとえば、1日)を設定することはお薦めできません。

ロード・プランの停止

ロード・プラン実行は、構成マネージャの「ロード・プラン実行」ページ(ツールバーの「実行ステータスの詳細の表示」をクリックする)にアクセスすることで停止することも、ODI Studioから停止することもできます。

ODI Studioからロード・プラン実行を停止するには:

1. オペレータ・ナビゲータの「ロード計画実行」アコーディオンから、停止する実行中のロード・プラン実行または待機中のロード・プラン実行を選択します。

2. 右クリックして、「標準停止」または「即時停止」を選択します。

- 標準停止: 標準停止モードでは、ロード・プランの停止を担当するエージェントが、このロード・プランのセッションを実行している各エージェントに「標準停止」信号を送信します。各エージェントは、セッションの現在のタスクが完了するまで待機して、セッションをエラー状態で終了します。ロード・プランによる例外ステップの実行は行われなくなり、すべての例外が終了するとロード・プランがエラー状態に移行します。

- 即時停止: 即時停止モードでは、ロード・プランの停止を担当するエージェントが、このロード・プランのセッションを実行している各エージェントに「即時停止」信号を送信します。各エージェントは、セッションをエラー状態で即時終了し、セッションの現在のタスクの完了を待機しません。ロード・プランによる例外ステップの実行は行われなくなり、すべての例外が終了するとロード・プランがエラー状態に移行します。

3. 「ロード・プランの停止」ダイアログで、ロード・プランを停止するエージェントを選択します。

4. 「OK」をクリックします。
ODI Studioからロード・プラン実行を停止する方法の詳細は、Oracle Fusion Middleware Oracle Data Integrator開発者ガイドを参照してください。

3 追加の管理タスク

この章では、Oracle BI ApplicationsのETLプロセスに関連する管理トピックについて説明します。

この章には次のトピックが含まれます:

- SiebelソースのETL表の作成

- DDL Warehouseスクリプトの生成

- ロギングおよび診断

SiebelソースのETL表の作成

ソース・システムがSiebelで、次のオファリングの1つをデプロイする場合は、SiebelデータベースでS_ETL表を作成する必要があります。

- Oracle Marketing Analytics

- Oracle Price Analytics

- Oracle Sales Analytics

- Oracle Service Analytics

S_ETL表を作成するには、DDLスクリプトを生成してSiebel DBAに提出する必要があります。Siebel DBAは、Siebelデータベースで必要な表を作成する必要があります。

ETL接続に使用するDBユーザーは、S_ETL表に対するすべてのDML権限(SELECT、INSERT、DELETE、UPDATES)とDDL権限(TRUNCATE)を必要とすることに注意してください。

SiebelソースのS_ETL表を作成するDDLスクリプトを生成するには:

1. ODI Studioを起動して、デザイナ・ナビゲータを表示します。

2. プロジェクト・エディタで、「BIAppsプロジェクト」、「コンポーネント」、「ソース」、「Siebel」、「Oracle」、「Siebel DDLの生成」、「パッケージ」、「Siebel DDLの生成」、「シナリオ」の各フォルダを開きます。

3. 「GENERATE_SIEBEL_DDLバージョン001」を右クリックして、「実行」をクリックします。

4. 「コンテキスト」→「ODIエージェント」→「ログ・レベル」を選択して、「OK」をクリックします。

5. 次の情報を指定します。

オプション

説明

CREATE_SCRIPT_FILE

「最新の値」を選択して、「値」フィールドにYと入力します。

REFRESH_MODE

FULLと入力します。

CHAR_CLAUSE

Unicodeサポート用に提供されています。「Y」に設定すると、DDLにCHAR句が含められます。

RUN_DDL

Nと入力します。

SCRIPT_LOCATION

スクリプトの作成先パスを入力します。

ファイル名は、BIA_Siebel_Schema_DDL_<実行ID>.sqlのようになります。

TABLE_MASK

デフォルト値「%」はすべての表を比較します。

DDL Warehouseスクリプトの生成

Business Analytics Warehouseの表は、インストール・プロセス中、Business Analytics Applications Suiteのリポジトリ作成ユーティリティ(RCU)が付属のDDLスクリプトを実行するときに、自動的にデプロイされます。RCUでは、個々の表と関連する索引に割り当てる表領域の指定を求めるプロンプトが表示されません。また、付属のDDLを変更するメカニズムも用意されていません。Business Analytics Warehouseデータ・モデルに変更を加えるには、ODIを使用して新しいDDLスクリプトを生成します。

DDLスクリプトの生成と、表および索引への表領域の割当てについては、『Oracle Business Intelligence Applicationsインストレーション・ガイド』のDDLの生成と表および索引への表領域の割当てに関する項を参照してください。

ロギングおよび診断

Oracle BI Applications構成マネージャでは、Oracle Diagnostic Loggingを使用します。ログ・ファイルと診断データの管理については、『Oracle Fusion Middleware管理者ガイド』を参照してください。

A 「ロード・プランの管理」ユーザー・インタフェースのリファレンス

この項では、Oracle BI Applications構成マネージャの「ロード・プランの管理」ユーザー・インタフェースの要素に関するリファレンス情報について説明します。

この項には次のトピックが含まれます:

- 「ロード・プランの管理」ツールバーのオプション

- 「ロード・プランの管理」メイン・ページ

- 「ロード・プランの定義」ページ

- 「ロード・プランの複製」ページ

- 「ロード・プランの編集」ページ

- 「ロード・プランの詳細」ページ

- 「ロード・プランのスケジュール」ダイアログ

「ロード・プランの管理」ツールバーのオプション

「ロード・プランの管理」ウィンドウには、次のアイコンとメニュー・オプションがあります。

アイコンまたはメニュー・オプション

説明

「アクション」メニュー:

データ・ウェアハウス・リセット・シナリオの実行

このコマンドは、W_ETL_LOAD_DATES表を切り捨てることで、データ・ウェアハウスをリセットします。これにより、後続のロードでは、すべてのターゲット表が切り捨てられて、新たにフル・ロードが実行されるようになります。

複製

選択したロード・プラン定義と同じファクト・グループで新しいロード・プランを定義できます。ただし、異なる名前と識別子を使用します。

生成

ODIリポジトリにロード・プランを作成するプロセスを開始します。ロード・プランは、実行前に正常に作成しておく必要があります。

生成ステータスの詳細の表示

ロード・プランに含まれる各ステップについて、生成ステータスを示します。

生成ステータスのリセット

生成ステータスを「生成しない」にリセットします。

ロード・プランの詳細の表示

Oracle Data Integratorコンソールを起動します。このコンソールでは、選択したロード・プランに関する詳細情報を表示できます。

実行

正常に生成されているロード・プランを実行します。

実行ステータスの詳細の表示

実行したロード・プランについて、実行の詳細を表示します。

生成ステータス: 生成しない

ロード・プランが生成されていないことを示します。または、構成マネージャでロード・プランが、再生成されずに変更されていることを示します。

生成ステータス: 進行中

ロード・プランが生成処理中であることを示します。

「生成ステータス」および「実行ステータス」: 成功

「生成ステータス」列は、ロード・プランが正常に生成されたことを示します。

「実行ステータス」列は、ロード・プラン実行が正常に完了したことを示します。

「生成ステータス」および「実行ステータス」: 失敗

「生成ステータス」列は、ロード・プランの生成に失敗したことを示します。

「実行ステータス」列は、エラーが原因で、ロード・プラン実行が失敗したことを示します。

実行ステータス: 実行しない

ロード・プランが実行されなかったことを示します。

実行ステータス: 実行中

ロード・プランが現在実行中であることを示します。

「ロード・プランの管理」メイン・ページ

「ロード・プランの管理」メイン・ページを使用すると、既存のロード・プランを表示して編集したり、新しいロード・プランの定義を作成することができます。既存のロード・プランは、マスター・リスト・パネルの上にある「検索」をクリックして検索できます。検索の入力フィールドでは、大/小文字が区別されません。

「ロード・プラン」リストには、構成マネージャのリポジトリ内にあるロード・プランが表示されます。このページにあるツールバーのオプションについては、「「ロード・プランの管理」ツールバーのオプション」を参照してください。

「ロード・プランの管理: ファクト・グループ」タブ

このタブを使用すると、「ロード・プラン」リストで選択したロード・プランに関連付けられているファクト・グループを表示できます。表示されるファクト・グループは、ファクト・グループの階層に属している可能性があります。ファクト・グループのノードを開いて、階層を表示できます。ファクト・グループが階層内の別のファクト・グループの子である場合、そのファクト・グループはツリー内に2回出現します。これは、機能領域と親ファクト・グループの両方に関連付けられているためです。

「ロード・プランの管理: データ・ロード・パラメータ」タブ

このタブを使用すると、「ロード・プラン」リストで選択したロード・プランに関連付けられているデータ・ロード・パラメータを表示および編集できます。「データ・ロード・パラメータ」リストには、アプリケーション固有のパラメータとグローバル・パラメータの両方が含まれます。アプリケーション固有のパラメータは、ロード・プラン定義に含まれる1つ以上のファクト・グループに関連付けられています。グローバル・パラメータは、すべてのアプリケーションに適用されます。また、特定のファクト・グループに関連付けることもできます。

「データ・ロード・パラメータ」タブの要点は次のとおりです。

- リストされたパラメータが値を必要としているにもかかわらず値が割り当てられていない場合、表の各行にエラー・アイコンがタグ付けされます。値を必要としないパラメータ(値をNullにできる)は、値が割り当てられていない場合でもタグ付けされません。

- パラメータのリストをフィルタして、値を持たないデータ・ロード・パラメータのみを表示できます(ツールバーの「表示」ドロップダウン・リストを使用する)。

- 表に表示された内容は、ツールバーの「エクスポート」アイコンをクリックすることで、Microsoft Excel形式のファイルにエクスポートして保存できます。

- パラメータの値は、リスト内でパラメータを選択してから、ツールバーの「編集」アイコンをクリックすることで変更できます。「パラメータ値の編集」ダイアログが表示されます。パラメータ値を変更するには、ユーザーに適切な権限を持つロールが割り当てられている必要があります。

「ロード・プランの管理: ドメインとマッピング」タブ

「ドメインとマッピング」タブを使用すると、「ロード・プラン」リストで選択したロード・プランに関連するドメインとマッピングを表示および編集できます。ドメインとマッピングは、ロード・プラン定義に含まれるファクト・グループに関連付けられています。

「ドメインとマッピング」タブの要点は次のとおりです。

- リストに示されるソース・ドメインに、適切なウェアハウス・ドメイン・メンバーにマップされていないメンバーが含まれる場合、表の行にエラー・アイコンがタグ付けされます。一部のソース・ドメイン・メンバーは該当しないため、マップされていない場合でもタグ付けされません。

- マッピングのリストをフィルタして、マップされていないソース・メンバーを持つドメインのみを表示できます(ツールバーの「表示」ドロップダウン・リストを使用する)。

- 表に表示された内容は、ツールバーの「エクスポート」アイコンをクリックすることで、Microsoft Excel形式のファイルにエクスポートして保存できます。

- ドメインのマッピングは、リスト内でマッピングを選択してから、ツールバーの「編集」アイコンをクリックすることで変更できます。「ドメイン・メンバー・マッピングの編集」ダイアログが表示されます。ドメイン・メンバー・マッピングを変更するには、ユーザーに適切な権限を持つロールが割り当てられている必要があります。

「ロード・プランの管理: スケジュール」タブ

「スケジュール」タブを使用すると、ロード・プランの実行スケジュールを表示、作成、編集および削除できます。ロード・プランのスケジュールには、次の必須プロパティが含まれます。

- コンテキスト: ロード・プランの実行時に使用するODIコンテキスト。サポートされるコンテキストは、「グローバル」のみです。

- 論理エージェント: ロード・プランの実行時に使用するODIエージェント。

- 反復: 発生頻度。使用可能な値は次のとおりです。

- エージェント起動時

- 単純

- 毎時

- 毎日

- 毎週

- 毎月(月日付)

- 毎月(曜日)

- 毎年

- ステータス: スケジュールのステータス。使用可能な値は次のとおりです。

- アクティブ

- 非アクティブ

- アクティブ期間

- スケジュール済時間: ロード・プランを実行する日時。

「スケジュール」タブのツールバー・アイコン

ツールバー・アイコンには、次の機能があります。

- 追加: このコマンドは、「ロード・プランのスケジュール」ダイアログを起動します。このダイアログでは、選択したロード・プランの新しいスケジュールを定義できます。

- 編集: 選択したスケジュールに適用されます。このコマンドは、「ロード・プランのスケジュール」ダイアログを起動します。このダイアログでは、選択したスケジュールを変更できます。

- 削除: このコマンドは、リポジトリからスケジュールを削除します。

- スケジュールの更新: このコマンドは、エージェントがODIですでに起動されている場合に、ODIエージェント・スケジューラにスケジュールを追加します。Oracle BI Applications構成マネージャでスケジュールを定義するときに、ODIエージェントがすでに実行されている場合は、「スケジュールの更新」をクリックして、ODIエージェント・スケジューラにスケジュールを追加する必要があることに注意してください。

「ロード・プランの定義」ページ

「ロード・プランの定義」ページを使用すると、新しいロード・プランを定義できます。ロード・プランは、1つ以上のファクト・グループと追加のプロパティで構成されます。

要素

説明

「ロード・プランの定義」の最初のページ

一連の「ロード・プランの定義」の最初のページでは、次の情報が要求されます。

- 名前: (必須)ロード・プランの一意の名前。

- 摘要: (オプション)ロード・プランについての追加情報。

- ロード・プランタイプ: (オプション)使用可能な値は次のとおりです。

- ソース抽出(SDE)

- ソースの抽出とロード(SDE、SILおよびPLP)

- ウェアハウス・ロード(SILおよびPLP)

- ドメインのみの抽出とロード(SDEおよびSIL)

- ソース・インスタンス: (オプション)ファクト・グループの選択元になるデータ・ソース。

「ロード・プランの定義」の2ページ目

一連の「ロード・プランの定義」の2ページ目には、次のタブが含まれます。

- 使用可能な選択項目: ロード・プラン定義に含めるファクト・グループを選択できます。ツールバーの「表示」ドロップダウン・リストを使用すると、すべてのファクト・グループ、選択されたファクト・グループのみ、または選択されていないファクト・グループのみを表示できます。

- 選択されたファクト・グループ: 「使用可能なセクション」タブで選択したファクト・グループを表示します。「削除」アイコンを使用すると、選択されたファクト・グループを削除できます。

「ロード・プランの複製」ページ

「ロード・プランの複製」ページを使用すると、既存のロード・プランを複製できます。「ロード・プランの複製」ページには、コピーするロード・プランのロード・プラン情報が表示されます。複製するロード・プランには、一意の名前を付ける必要があります。オプションで、次の情報を変更できます。

- 一連の「ロード・プランの複製」の最初のページ

- 摘要

- ロード・プランタイプ

- ソース・インスタンス

- 一連の「ロード・プランの複製」の2ページ目

- ファクト・グループ

「ロード・プランの編集」ページ

「ロード・プランの編集」ページを使用すると、既存のロード・プランを編集できます。次の情報が編集可能です。

- 一連の「ロード・プランの編集」の最初のページ

- 名前

- 摘要

- ソース・インスタンス

- 一連の「ロード・プランの編集」の2ページ目

- ファクト・グループ

「ロード・プランの詳細」ページ

「ロード・プランの詳細」ページを使用すると、「ロード・プラン」リストで選択したロード・プランの定義と実行ステータスに関する詳細情報を表示できます。

要素

説明

「ナビゲーション」タブ

「ナビゲーション」タブでは、リポジトリに格納されているオブジェクトを参照できます。オブジェクトまたはノードを選択すると、このオブジェクトまたはノードで使用可能なアクションのアイコンが「ナビゲーション」タブのツールバーに表示されます。このオブジェクトで使用できないアクションの場合は、アイコンがグレー表示されます。

- 参照: 「参照」タブを使用すると、ランタイム・オブジェクト、デザインタイム・オブジェクトおよびトポロジ・オブジェクトを参照できます。

- 管理: 「管理」タブを使用すると、リポジトリ接続情報を表示できます。

「ロード・プラン」タブ

「ロード・プラン」タブには、次の情報を含む3つのパネルが表示されます。

- 定義: このパネルには、名前、ID、親フォルダおよびログの詳細など、ロード・プラン定義に関する情報が表示されます。

- 作成および更新情報: このパネルには、ロード・プランの作成日時および更新日時や、アクションを実行したユーザーに関する情報が表示されます。

- 関係: このパネルには、次の情報が表示されます。
ステップ: ロード・プランに含まれるステップがリストされます。

例外: 例外がステップ番号別にリストされます。

変数: ロード・プランに関連付けられた変数がリストされます。

実行: ロード・プランの各実行が実行ステータスとともにリストされます。

「ロード計画実行」タブ

「ロード計画実行」タブには、次の情報を含む3つのパネルが表示されます。

- 実行: このパネルには、ステータスおよびエラー・メッセージを含む、ロード・プラン実行に関する情報が表示されます。

- 定義: このパネルには、名前、ID、親フォルダおよびログの詳細など、ロード・プラン定義に関する情報が表示されます。

- 関係: このパネルには、次の情報が表示されます。
ステップ: ロード・プランに含まれるステップがリストされます。

変数: ロード・プランに関連付けられた変数がリストされます。

セッション: ロード・プランに含まれるセッションに関する情報が、開始日と終了日とともにリストされます。

「ロード・プランのスケジュール」ダイアログ

「ロード・プランのスケジュール」ダイアログを使用すると、ロード・プラン実行のスケジュールを作成および編集できます。ロード・プランのスケジュールには、次のプロパティが含まれます。

- コンテキスト: ロード・プランの実行時に使用するODIコンテキスト。サポートされるコンテキストは、「グローバル」のみです。

- 論理エージェント: ロード・プランの実行時に使用するODIエージェント。

- ログ・レベル: 保持するロギング情報のレベル。Oracle BI Applications構成マネージャでは、Oracle Diagnostic Loggingを使用します。ログ・ファイルと診断データの管理については、『Oracle Fusion Middleware管理者ガイド』を参照してください。

- ステータス: スケジュールのステータス。使用可能な値は次のとおりです。

- アクティブ

- 非アクティブ

- アクティブ期間

- 反復: 発生頻度。使用可能な値は次のとおりです。

- エージェント起動時

- 単純

- 毎時

- 毎日

- 毎週

- 毎月(月日付)

- 毎月(曜日)

- 毎年
「反復」オプションの選択内容に応じて、日時の選択オプションが動的に表示されます。

B ナレッジ・モジュールのリファレンス

この項では、Oracle BI Applicationsで使用可能な統合ナレッジ・モジュール(IKM)について詳しく説明します。

この項には次のトピックが含まれます:

- IKM BIApps Oracle Control Append

- IKM BIAPPS Oracle Event Queue Delete Append

- IKM BIAPPS Oracle Fact Incremental Update

- IKM BIAPPS Oracle Incremental Update

- IKM BIAPPS Oracle Period Delete Append

- IKM BIAPPS Oracle Slowly Changing Dimension

- IKM BIAPPS SQL Target Override

- ネストされたIKM BIAPPS Oracle Control Append

- ネストされたIKM BIAPPS Oracle Event Queue Delete Append

IKM BIApps Oracle Control Append

このIKMは、Oracleターゲット表にデータを追加モードで統合します。すべてのレコードは、キー・チェックなしで挿入されます。データの制御は、エラー表の無効なデータを分離してから、修正後にリサイクルすることで行えます。

前提条件

このIKMを使用するための前提条件は次のとおりです。

- 「ジャーナルからの削除の同期」プロセスを実行すると、ターゲットで削除した行がコミットされます。

- FLOW_CONTROLおよびRECYCLE_ERRORSオプションを使用するには、インタフェースで更新キーを設定する必要があります。

機能のオプション

- 未指定のレコード。ターゲット表がディメンションの場合、このオプションをTRUEに設定して、未指定のレコードを自動的に挿入します。その他のディメンション・レコードが一致しない場合、これがファクトによって参照されます。デフォルトの列値は、ユーザー定義関数GET_UNSPEC_VALUEを使用して、モデルの命名標準で決定されます。

パフォーマンス・チューニングのオプション

- ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。

- ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。

SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';

IKM BIAPPS Oracle Event Queue Delete Append

このIKMは、増分変更を処理するイベント・キューを使用して、Oracleターゲット表にデータを統合します。このIKMは、経時的にバージョン管理されるデータ(遅延変更ディメンションに類似している)を操作するときに使用します。フル・ロードの場合は、すべてのレコードが挿入されます。イベント・キューは、変化している自然キーと、変更が発生した最初の日付を追跡します。自然キーごとに、最初の変更以降の既存ターゲット・レコードはすべて削除され、新しいレコードが挿入されます。

有効開始日と有効終了日がある場合、これらがフル・ロードと増分ロードの両方で自動的に保持されます。

データの制御は、エラー表の無効なデータを分離することで行えますが、データのリサイクルはサポートされていません。

前提条件

このIKMを使用するための前提条件は次のとおりです。

- イベント・キュー表は、「イベント・キュー表」オプションを使用して定義する必要があります。

- EARLIEST_CHANGE_DATE列(DATE型)が含まれている必要があります。

- 標準命名規則に従って、末尾に_EQ_TMPを付加する必要があります。

- ターゲット表とイベント・キューの間の結合は、「イベント・キューの結合」オプションを使用して定義する必要があります。

- ターゲット表では、次の項目にSCD動作を設定する必要があります。

- 自然キー

- 開始/終了のタイムスタンプ

- インタフェースでは、変化しているソース・データのみ(変化している自然キーおよび変更の最初の日付をリストするイベント・キューで制御されている)を選択する必要があります。

- データは、増分データのみが格納された一時表やステージング表から選択するか
または

- ネストされたIKM BIAPPS Oracle Event Queue Delete Appendを使用して、増分ロードのイベント・キューに結合を含めます。

- 「ジャーナルからの削除の同期」プロセスを実行すると、ターゲットで削除した行がコミットされます。

機能のオプション

- イベント・キュー表。増分変更を保持するイベント・キュー表の名前です。このオプションは必須です。
このオプションの前提条件は次のとおりです。

- イベント・キュー表には、EARLIEST_CHANGE_DATE列(DATEデータ型)が含まれている必要があります。

- Oracle BI Applicationsの表の命名標準に従って、末尾に_EQ_TMPが付加されます。

- イベント・キューの結合。ターゲット表の別名がTで、イベント・キュー表の別名がQであると想定して、ターゲット表とイベント・キュー表の間に等価結合を定義します。これは、「イベント・キューの更新」ステップと「イベント・キューの削除」ステップで使用されますが、どちらのステップも不要であるという、まれなケースでは省略してもかまいません。EARLIEST_CHANGE_DATEに対するフィルタは、結合オプションに含めることはできません。

- イベント・キューの削除。増分ロードで処理されているターゲット表のレコードを削除するかどうか。ほとんどの場合、これは有効化する必要がありますが、複数のインタフェースでターゲット表をロードするという、まれなケースでは最初のインタフェースでのみ有効化する必要があります。

- イベント・キューの更新。増分ロードの影響を受けるターゲット表のレコードで有効日を修正するかどうか。ほとんどの場合、これは有効化する必要がありますが、複数のインタフェースでターゲット表をロードするという、まれなケースでは最後のインタフェースでのみ有効化する必要があります。

- 高いデータ値。最大の終了タイムスタンプに使用するデフォルト値です。ほとんどの場合、#HI_DATEのデフォルト値で十分ですが、OLTPを反映する一部の永続化されたステージング表では、別の値(たとえば、#ORA_HI_DATE)を使用することがあります。

- 未指定のレコード。ターゲット表がディメンションの場合、これをTRUEに設定して、未指定のレコードを自動的に挿入します。その他のディメンション・レコードが一致しない場合、これがファクトによって参照されます。デフォルトの列値は、ユーザー定義関数GET_UNSPEC_VALUEを使用して、モデルの命名標準で決定されます。

パフォーマンス・チューニングのオプション

- ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。

- ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。

SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';

IKM BIAPPS Oracle Fact Incremental Update

このIKMは、Oracleターゲット表にデータを追加モードで統合します。すべてのレコードは、キー・チェックなしで挿入されます。データの制御は、エラー表の無効なデータを分離してから、修正後にリサイクルすることで行えます。

前提条件

このIKMを使用するための前提条件は次のとおりです。

- LOAD_PARTITION_METADATAシナリオは、インタフェースの前に実行する必要があります。その際には、このKMを使用して、ターゲット表の名前をパラメータとして渡します。これにより、必要なメタデータとともにW_ETL_PART_TABLESおよびW_ETL_PART_TABLE_PARTSがロードされます。

機能のオプション

このIKMで使用可能なオプションについては、「IKM BIAPPS Oracle Incremental Update」のオプションの説明を参照してください。

IKM BIAPPS Oracle Incremental Update

このIKMは、Oracleターゲット表にデータを増分更新モードで統合します。新しいレコードが挿入され、既存のレコードは更新されます。データの制御は、エラー表の無効なデータを分離してから、修正後にリサイクルすることで行えます。

前提条件

このIKMを使用するための前提条件は次のとおりです。

- 更新キーはインタフェースで定義する必要があり、キー列は索引付けされている必要があります。

- 「ジャーナルからの削除の同期」プロセスを実行すると、ターゲットで削除した行がコミットされます。

機能のオプション

- ソフト削除。ソフト削除オプションを有効にすると、いくつかの追加ステップを実行できます。#SOFT_DELETE_FEATURE_ENABLED(グローバル)および#SOFT_DELETE_PREPROCESS(ファクトまたはディメンション・グループごとに設定可能)変数により、どのステップを実行するかを正確に制御できます。
ソース・システムでの削除を効率的にキャプチャするトリガーが実装可能な場合は、負荷の高い前処理のステップ(全ソース・レコードを抽出して、それを全ターゲット・レコードと比較する)を無効にして、そのかわりに削除表への直接移入を行うことができます。

ステップ

アクション

制御

ソフト削除の前処理

「削除識別」ステップを実行します。このステップは、プライマリ抽出表とターゲット表のデータを比較して、廃止されたターゲット行を削除表に記録します。

- #LAST_ARCHIVE_DATEを使用して、CREATED_ON_DTシステム列でターゲットをフィルタします(これを無効化するには、変数をNULLに設定する)。

- プライマリ抽出を実装したデータ・ソースのみが含まれます。データ・ソースのプライマリ抽出表にレコードがない場合は、そのデータ・ソースの削除表にはレコードが追加されません。

#SOFT_DELETE_FEATURE_ENABLED

#SOFT_DELETE_PREPROCESS

ターゲットのソフト削除

「ソフト削除」ステップを実行します。このステップは、削除対象として識別されたレコードについて、ターゲット表のDELETE_FLG列を「Y」に更新します。

#SOFT_DELETE_FEATURE_ENABLED

削除表の切捨て

処理が終了したレコードを削除表から削除します。

#SOFT_DELETE_FEATURE_ENABLED

これらのステップはすべて、ターゲット表へのその他の挿入および更新とともに、まとめてコミットされる点に注意してください。これにより、データ・ウェアハウスの一貫性が保たれます。

このオプションを使用するための前提条件は次のとおりです。

- ターゲット表には、ETL_PROC_WIDおよびW_UPDATE_DTシステム列が必要です。

- <target>_PEおよび<target>_DEL表は、インタフェース・キーの列で作成する必要があります。

- ターゲット表にCREATED_ON_DT列が含まれていない場合は、#LAST_ARCHIVE_DATEをNULLにする必要があります。

- #SOFT_DELETE_PREPROCESSは、Oracle BI Applications構成マネージャから、ロード・プラン・コンポーネント単位でリフレッシュする必要があります。

- 日付追跡。(遅延変更ディメンションの場合と同様に)ターゲット表の有効開始日と有効終了日を自動的に保持します。日付または数値(通常はYYYYMMDDなどの日付キー)を処理できます。これにより、現行フラグ列を設定することもできます。この列は、最新レコードの場合は「Y」になり、古いレコードの場合は「N」になります。
このオプションを使用するための前提条件は次のとおりです。

- モデル内の次の表の列で、遅延変更ディメンションの動作を設定します。
- 自然キー

- 開始/終了のタイムスタンプ

- 現行フラグ(オプション)

- 自然キー列と開始タイムスタンプ列は、索引付けする必要があります(更新キー索引の対象でない場合)。インタフェースでは、有効終了日の列を、ターゲットで実行するように設定された定数の最大値(通常は#HI_DATE)にマップします。

- 現行フラグを使用する場合は、そのフラグを「Y」にマップします(再度ターゲットで実行する)。

- ETL_PROC_WIDは、索引付けされている必要があります。

- 変更のキャプチャ。ターゲット表の変更をイメージ表にキャプチャすることで変更反映プロセスを集約し、合理化します。

ステップ

アクション

制御

変更イメージ表の切捨て

イメージ表を消去して、現在のプロセスの変更をキャプチャする準備を整えます。

常に実行

事前ロードの変更のキャプチャ

これから更新されるターゲット表のレコードをキャプチャします。

常に実行

ソフト削除の変更のキャプチャ

これからソフト削除対象としてマークされるターゲット表のレコードをキャプチャします。

ソフト削除機能が有効な場合に実行

ロード後の変更のキャプチャ

挿入または更新されたターゲット表のレコードをキャプチャします。

常に実行

これらのステップはすべて、ターゲット表へのその他の挿入および更新とともに、まとめてコミットされます。これにより、データ・ウェアハウスの一貫性が保たれます。

このオプションを使用するための前提条件は次のとおりです。

- W_FACT_Fでは、ターゲット表のすべての列を含むイメージ表W_FACT_CMG、および次の列を作成する必要があります。
CHANGED_IN_TASK

PHASE_CODE

PHASE_MULTIPLIER

- 未指定のレコード。ターゲット表がディメンションの場合、これをTRUEに設定して、未指定のレコードを自動的に挿入します。その他のディメンション・レコードが一致しない場合、これがファクトによって参照されます。デフォルトの列値は、ユーザー定義関数GET_UNSPEC_VALUEを使用して、モデルの命名標準で決定されます。

パフォーマンス・チューニングのオプション

- ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。

- ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。

SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';

- ターゲットの分析: KMオプションのANALYZE_TARGETがTrueに設定されている場合、ロード前のターゲット表に関する統計が収集されます。デフォルトでは、Falseに設定されています。

- フロー表の分析: KMオプションのANALYZE_FLOW_TABLEがTrueに設定されている場合、ロード後のフロー表(I$)に関する統計が収集されます。デフォルトでは、Falseに設定されています。このオプションは、フル・ロード時の有効日の計算方法にも影響します(日付追跡オプションが有効な場合)。フロー表が分析されていない場合、有効終了日の設定にUPDATE文が使用されます。それ以外の場合は、MERGE文が使用されます。

- バルク・モード(#ETL_BULK_MODE変数): 有効にすると、バルク・モードでターゲットへのダイレクト・パス書込み(ヒントの追加)が使用され、I$表がバイパスされます(フロー制御、リサイクル・エラー、日付追跡などのその他のKMオプションが必要としない場合)。バルク・モード変数は、次の値に設定できます。
Y: 有効

F: フル・ロードにのみ有効

N: 無効

IKM BIAPPS Oracle Period Delete Append

このIKMは、Oracleターゲット表にデータを統合します(期間ごとにデータを集計する)。新しいレコードは挿入されます。また、既存の期間に対する変更は、その期間の古いデータを削除してから、新しいデータを挿入することで処理されます。古い期間のデータは、パージされることがあります。データの制御は、エラー表の無効なデータを分離してから、修正後にリサイクルすることで行えます。

前提条件

このIKMを使用するための前提条件は次のとおりです。

- 「削除期間タイプ」オプションには、ターゲット表が基づいている期間タイプを指定する必要があります。

- カレンダ期間では、ターゲット表に期間最終日キーの列を含める必要があります。
- 日付WID型(YYYYMMDD)にする必要があります。

- PERIOD_END_DT_WIDという名前にする必要があります。「UD1」チェック・ボックスを使用してマッピングで特定することもできます。

- MCALカレンダ期間では、ターゲット表に次のものを含める必要があります。
- 期間キー。通常はMCAL_PERIOD_WIDまたはMCAL_DAY_WIDです。「UD1」チェック・ボックスを使用してマッピングで特定することもできます。

- カレンダ・キー。通常はMCAL_CAL_WIDです。「UD2」チェック・ボックスを使用してマッピングで特定することもできます。

- 前述のキー列に対するビットマップ索引。

カレンダ期間

サポート対象のカレンダ期間は、日、週、月、四半期および年です。これらの期間タイプの場合、増分ロードでは、インタフェースによって現行期間のみのデータがロードされていると想定します。増分更新は、現行期間の既存データを削除することで機能します。その後、現行期間用の新しいデータ・セットを挿入します。必要に応じて、「保持する期間数」オプションで、指定した経過期間より古いデータを自動的にパージできます。「削除する期間数」オプションは、カレンダ期間には適用されません。

MCALカレンダ期間

MCALカレンダ期間(MCAL日およびMCAL期間)がサポートされます。これらの期間タイプの場合、増分ロードでは、インタフェースによって現行期間のデータと、指定した数の前期間のデータがロードされていると想定します。増分更新は、該当する期間の既存データを削除することで機能します。その後、新しいデータ・セットを挿入します。「削除する期間数」オプションは、インタフェースによって増分ロードされている前期間(および現行期間)の数を制御します。たとえば、値が1の場合は、ロードするたびに現行期間とその前の期間が再処理されることになります。「保持する期間数」オプションは、MCALカレンダ期間には適用されません。

機能のオプション

- 削除期間タイプ: ターゲット表が基づいているカレンダ期間のタイプです。再処理のために現行期間を削除する場合や、廃止された期間をパージする場合に使用します。有効な値は次のとおりです。
カレンダ期間: CAL_DAY、CAL_WEEK、CAL_MONTH、CAL_QTR、CAL_YEAR。

MCALカレンダ期間: MCAL_DAY、MCAL_PERIOD。

このオプションを使用するための前提条件は次のとおりです。

- カレンダ期間では、ターゲット表に期間最終日キーの列を含める必要があります。
- PERIOD_END_DT_WIDという名前にする必要があります。「UD1」チェック・ボックスを使用してマッピングで特定することもできます。

- 日付WID型(YYYYMMDD)にする必要があります。

- MCALカレンダ期間では、ターゲット表に次のものを含める必要があります。
- 期間キー。通常はMCAL_PERIOD_WIDまたはMCAL_DAY_WIDです。「UD1」チェック・ボックスを使用してマッピングで特定することもできます。

- カレンダ・キー。通常はMCAL_CAL_WIDです。「UD2」チェック・ボックスを使用してマッピングで特定することもできます。

- 削除する期間数: このオプションは、MCALカレンダ期間のみの追加機能を構成するためのものです。カレンダ期間の場合は、デフォルト値(0: 現行期間のみ削除)のままにする必要があります。このオプションの値をN > 0に設定すると、削除期間タイプに基づいて、Nユリウス歴期間数分のデータが削除されます。たとえば、1に設定すると、現行期間とその前の期間が削除されます。

- 保持する期間数: このオプションは、カレンダ期間のみの追加機能を構成するためのものです。カレンダ期間の場合は、デフォルト値(0: すべての期間を保持)のままにする必要があります。このオプションの値をN > 0に設定すると、現在のユリウス歴期間よりNユリウス歴期間数分前の期間データが削除されます。

パフォーマンス・チューニングのオプション

- ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。

- ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。

SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';

IKM BIAPPS Oracle Slowly Changing Dimension

このIKMは、タイプ2遅延変更ディメンションとしてモデル化されたOracleターゲット表にデータを統合します。新しいレコードは挿入されます。また、既存のレコードに対する変更によって、挿入または更新のいずれかがトリガーされることがあります(タイプ2列に対する変更があるかどうかによる)。データの制御は、エラー表の無効なデータを分離してから、修正後にリサイクルすることで行えます。このオプションは、#TYPE2_FLGおよび#UPDATE_ALL_HISTORY変数を使用して動作を制御します。

前提条件

このIKMを使用するための前提条件は次のとおりです。

- 更新キーはインタフェースで定義する必要があり、キー列(通常は、INTEGRATION_ID、DATASOURCE_NUM_ID、SRC_EFF_FROM_DT)は索引付けされている必要があります。遅延変更ディメンションの動作は、すべてのターゲット表の列に対して設定(モデルで設定)されている必要があり、次のものを含める必要があります。
- サロゲート・キー(通常は、ROW_WID)

- 自然キー(通常は、INTEGRATION_ID、DATASOURCE_NUM_ID)

- 開始と終了のタイムスタンプ(通常は、EFFECTIVE_FROM_DTとEFFECTIVE_TO_DT)

- 現行フラグ(通常は、CURRENT_FLG)

- 終了タイムスタンプは、最大値(通常は、#HI_DATE)にマップされている必要があります。

- 現行フラグは、Yにマップされている必要があります。

- ソースの開始日と終了日は、Nullにはできません(#LOW_DATEまたは#HI_DATEにデフォルト設定される)。

- ETL_PROC_WIDは、索引付けされている必要があります。

列の分類

次の表では、ディメンションの列の分類方法と、分類ごとの異なる動作について説明します。分類は、モデル内の個別の表の列に対して行われます。

列

説明

SCDの動作

その他のフレックスフィールド

サロゲート・キー

ウェアハウスで生成されたディメンション用の主キー

サロゲート・キー

自然キー

ビジネス・キーまたはソース・キー(時間との組合せで一意になる)

自然キー

開始タイムスタンプ

時間レコードの有効開始日

開始タイムスタンプ

終了タイムスタンプ

時間レコードの有効終了日

終了タイムスタンプ

現行フラグ

レコードが最新の有効日かどうか

現行フラグ

タイプ2列

タイプ2列のいずれかに変更がある場合は、レコードの新しいバージョンを作成(挿入)します

変更時に挿入

更新履歴列

常に現行レコードからの値に設定されます

変更時に上書き

システム列ではありません

その他のシステム列

挿入/更新として保持されます

変更時に上書き

システム列

変更列

該当する列に変更がない場合はレコードが拒否されます

変更時に上書き

変更列およびシステム列

SCD1キー

ウェアハウスで生成された自然キーに対応するキー

変更時に上書き

SCD1 WID(列フレックスフィールド)

遅延変更ディメンションの機能

- タイプ2の変更: #TYPE2_FLG変数がオフ(「N」に設定)の場合、ディメンションはタイプ1ディメンションのように動作します。開始日/終了日のメンテナンスは実行されないため、自然キーは一意にする必要があります(履歴は使用不可)。#TYPE2_FLGがオン(「Y」に設定)の場合、新しいレコードは挿入されます。少なくとも1つのタイプ2列を更新する変更も挿入をトリガーします(いくつかの制限がある)。また、それ以外の変更は、既存のレコードを更新します。
タイプ2の変更は、次のようにトリガーされます。

- 入力レコードには、現在のディメンション・レコードと比較した場合に、相違があるタイプ2列が少なくとも1列含まれている必要があります。

- 新しいタイプ2レコードの開始タイムスタンプは、次のように計算されます。日付値がNull以外の変更列がある場合、その値を使用します(Oracle BI Applicationsの標準では、変更列としてCHANGED_ON_DTを使用します)。それ以外の場合は、現在のタイムスタンプ(sysdate)を使用します。

- すべての履歴の更新: #TYPE2_FLGと#UPDATE_ALL_HISTORYの両方がオン(「Y」に設定)の場合、すべての更新履歴列は、現行バージョンのレコード(同一の自然キーを持つ最新のレコード)からの値で更新されます。

機能のオプション

- 未指定のレコード: ターゲット表がディメンションの場合は、これをTRUEに設定して、未指定のレコードを自動的に挿入します。その他のディメンション・レコードが一致しない場合、これがファクトによって参照されます。デフォルトの列値は、ユーザー定義関数GET_UNSPEC_VALUEを使用して、モデルの命名標準で決定されます。

- SCD1キー: TRUEに設定すると、サロゲート自然キーまたはタイプ1キーが自動的に保持されます。これは、標準パターンに従って命名されたタイプ1表を使用して管理されます。ディメンション表がW_DIMENSION_Dの場合、タイプ1表はW_DIMENSION_T1_Dになります。タイプ1キーの生成シーケンスも標準パターンに従って命名されます。前述の例に従うと、W_DIMENSION_D_S1Wという名前になります。同じ単位(タイプ1)の追加列がUD1フラグでマークされている場合は、タイプ1表で自動的に保持できます。
W_DIMENSION_Dの前提条件は次のとおりです。

- タイプ1キー列は、モデル内のSCD1 WIDフレックスフィールドで識別される必要があります。

- タイプ1キー列は、ソースまたはステージングで定数値(例: 0)にマップされる必要があります。

- タイプ1キー列は、挿入専用にする必要があります。

- タイプ1表(W_DIMENSION_T1_D)には、少なくとも次の列を含める必要があります。
- タイプ1キー列

- 自然キー列

- システム列W_INSERT_DT、W_UPDATE_DTおよびETL_PROC_WID

- UD1としてマークされた列

- タイプ1表(W_DIMENSION_T1_D)には、タイプ1キー列と自然キー列に対する索引を含める必要があります。

- タイプ1キーのシーケンスを作成する必要があります(W_DIMENSION_D_S1W)。タイプ1キーのシーケンスを作成する必要があります(W_DIMENSION_D_S1W)。

- 間隔の補填: TRUEに設定すると、以前の日付をカバーするように最初のレコードが自動的に拡張されます。

- ソフト削除。ソフト削除オプションを有効にすると、いくつかの追加ステップを実行できます。#SOFT_DELETE_FEATURE_ENABLED(グローバル)および#SOFT_DELETE_PREPROCESS(ファクトまたはディメンション・グループごとに設定可能)変数により、どのステップを実行するかを正確に制御できます。
ソース・システムでの削除を効率的にキャプチャするトリガーが実装可能な場合は、負荷の高い前処理のステップ(全ソース・レコードを抽出して、それを全ターゲット・レコードと比較する)を無効にして、そのかわりに削除表への直接移入を行うことができます。

ステップ

アクション

制御

ソフト削除の前処理

「削除識別」ステップを実行します。このステップは、プライマリ抽出表とターゲット表のデータを比較して、廃止されたターゲット行を削除表に記録します。

- #LAST_ARCHIVE_DATEを使用して、CREATED_ON_DTシステム列でターゲットをフィルタします(これを無効化するには、変数をNULLに設定する)。

- プライマリ抽出を実装したデータ・ソースのみが含まれます。データ・ソースのプライマリ抽出表にレコードがない場合は、そのデータ・ソースの削除表にはレコードが追加されません。

#SOFT_DELETE_FEATURE_ENABLED

#SOFT_DELETE_PREPROCESS

ターゲットのソフト削除

「ソフト削除」ステップを実行します。このステップは、削除対象として識別されたレコードについて、ターゲット表のDELETE_FLG列を「Y」に更新します。

#SOFT_DELETE_FEATURE_ENABLED

削除表の切捨て

処理が終了したレコードを削除表から削除します。

#SOFT_DELETE_FEATURE_ENABLED

これらのステップはすべて、ターゲット表へのその他の挿入および更新とともに、まとめてコミットされる点に注意してください。これにより、データ・ウェアハウスの一貫性が保たれます。

このオプションを使用するための前提条件は次のとおりです。

- ターゲット表には、ETL_PROC_WIDおよびW_UPDATE_DTシステム列が必要です。

- <target>_PEおよび<target>_DEL表は、インタフェース・キーの列で作成する必要があります。

- ターゲット表にCREATED_ON_DT列が含まれていない場合は、#LAST_ARCHIVE_DATEをNULLにする必要があります。

- #SOFT_DELETE_PREPROCESSは、Oracle BI Applications構成マネージャから、ロード・プラン・コンポーネント単位でリフレッシュする必要があります。

パフォーマンス・チューニングのオプション

- 検出戦略: 変更が発生していない表の更新を避けるために、入力データが変更列のセットの既存レコードと比較されます。これはモデル列フレックスフィールド(OBI_CHANGE_COLUMN)で定義されます。そうでない場合は、すべての列が比較されます。常に変更を処理する場合は、このオプションを無効にできます。

- 「ヒント」および「全履歴」: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。

- ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。

SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';

- ターゲットの分析: KMオプションのANALYZE_TARGETがTrueに設定されている場合、ロード前のターゲット表に関する統計が収集されます。デフォルトでは、Falseに設定されています。

IKM BIAPPS SQL Target Override

ターゲット表に対して実行するカスタムSQL文を指定できるという点で、これは特異なIKMであるといえます。このSQL文は、インタフェースから返されたソース・レコードごとに1回実行されます。このSQL文の特定の実行に対して、ソース・レコードからの値をパラメータとしてSQLで参照できます。

このIKMのユース・ケースは多岐に亘りますが、そのインタフェースは、ODIインタフェースの標準的な方法に従って実装されていないため、カスタマイズされることのないシステム定義ロジックの実装用にのみ使用してください。

カスタムSQLがすべてのターゲット・テクノロジには適合しない場合、そのかわりにプラットフォーム固有のSQL文を指定できます。このIKMは、実行時にターゲット・テクノロジに対応するオプションでSQLを実行します(使用可能な場合)。それ以外の場合は、汎用オプションのSQLが使用されます。

前提条件

このIKMを使用するための前提条件は次のとおりです。

- カスタマイズできないシステム・ロジックを実装してください。

- パフォーマンスや互換性などの問題が原因で、汎用のSQLオーバーライドが特定のプラットフォームに適合しない場合は、プラットフォーム固有のSQLオーバーライド・オプションを指定する必要があります。

- SQL文は、INSERT、UPDATEまたはDELETEキーワードで始まる必要があります。

- SQLに、ヒントのプレースホルダが含まれていることを確認する必要があります。

- 必要な索引がすべて用意されていることを確認する必要があります。

ソース・データの参照

SQLオーバーライドでソース・データからのデータを使用するには、次の操作を行います。

- 参照対象のソース・データを、インタフェース上のいずれかのターゲット列にマップします。

- SQLオーバーライドで、TARGET_COLUMN構文を使用して参照します。

機能のオプション

SQLオーバーライドのオプション: 汎用のSQLオーバーライド・オプションが使用できます。また、各種ターゲット・テクノロジの構文やパフォーマンスが異なる場合に備えて、プラットフォーム固有のオプションも用意されています。このオプションを使用するための前提条件は次のとおりです。

- SQL文は、INSERT、UPDATEまたはDELETEキーワードで始めます。

- パフォーマンスや互換性などの問題が原因で、汎用のSQLオーバーライドが特定のプラットフォームに適合しない場合は、プラットフォーム固有のSQLオーバーライド・オプションを指定する必要があります。

パフォーマンス・チューニングのオプション

- ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。

- ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。

SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';

ネストされたIKM BIAPPS Oracle Control Append

ネストされたインタフェースまたは一時インタフェースでこのIKMを使用することで、ネストされたSQLブロック用の生成されたSQLで追加の機能を提供できます。主な利点として、ヒントが追加できるようになることがあげられます。また、一部のアプリケーションでは、「ルックアップの集約」と「ソースSQLのオーバーライド」の機能が役立つこともあります。

機能のオプション

- ルックアップの集約: ユーザー・フレックスフィールドを使用して、SQLブロックを集約します。このフレックスフィールドでは、レコードのグループ化を定義することで、グループごとの出力が1行に制限されるようにします。
このオプションを使用するための前提条件は次のとおりです。

- インタフェースでは、次のユーザー・フレックスフィールドを設定する必要があります。
- UD1: GROUP BY列。通常、この列が結合の対象になります。

- UD2: 集約列。返されるフィールドです。

- UD3: アクティブ・ルックアップ(LKP_ACTIVE)の列。これは、1に設定されます。

- ソースSQLのオーバーライド: 生成済のネストされたSQLブロックをオーバーライドできるようにします。これは、SQLをより動的なものにする必要がある場合に役立ちます(動的な表の参照に変数を使用する場合など)。
このオプションを使用するための前提条件は次のとおりです。

- ターゲット・インタフェース列ごとに、同じ別名の列がSQLオーバーライドのSELECT句に存在している必要があります。

- このオプションの使用はお薦めしません。実装前に、Oracle BI Applications標準化グループが、そのユース・ケースをレビューするようにしてください。

パフォーマンス・チューニングのオプション

- ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。

ネストされたIKM BIAPPS Oracle Event Queue Delete Append

メイン・インタフェースの一部として、このIKMをイベント・キュー制御の更新で使用する際には、ネストされたインタフェースまたは一時インタフェースでもこのIKMを使用することで、ネストされたSQLブロック用の生成されたSQLで追加の機能を提供できます。主な利点として、増分ロードではイベント・キュー表を駆動表として使用しながらも、フル・ロードではイベント・キュー表全体を除外できることがあげられます。また、ヒントの使用もサポートされています。

ネストされたKMを使用する場合の前提条件

- メイン・インタフェースでは、このKMを使用する必要があります。

- イベント・キュー表は、「イベント・キュー表」オプションで指定する必要があります。

- インタフェースには、次のもののみを含める必要があります。

- メイン・ソース表

- イベント・キュー表

- これらの間の結合(ANSI構文を使用)

イベント・キュー列のマッピング

ある場合、親インタフェースでのイベント・キュー列の参照が必要になります。この列がUD1フレックスフィールドで識別されているときは、ネストされたインタフェースで直接マップできます。これにより、生成されたSQLブロックにその列が含められます(増分ロードでイベント・キュー表も含まれている場合)。フル・ロードの場合は、イベント・キュー表と、その表からマップされた列が除外されます。

機能のオプション

イベント・キュー表: 増分ロードを制御するイベント・キュー表に、明示的に名前を付けます。これは、ネストされたインタフェースの2つのソース表のいずれかにする必要があります。

パフォーマンス・チューニングのオプション

- ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。