ヘッダーをスキップ
Oracle Business Intelligence Applicationsデータ・ウェアハウス管理コンソール・ガイド
リリース7.9.4
E06114-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

6 DACで実行される共通タスク

この章の内容は次のとおりです。

DACメタデータのインポート

DACのインポート/エクスポート機能を使用すると、ソース・システム固有のDACメタデータを、DACリポジトリにインポートまたはDACリポジトリからエクスポートできます。この機能を使用すると、開発環境からテスト環境または本番環境へというように、環境間でDACメタデータを移行できます。

DACメタデータをインポートするには:

  1. DACのメニュー・バーで、「Tools」→「DAC Repository Management」→「 Import」を選択します。

  2. DACメタデータのインポート元ディレクトリを選択するか、デフォルトのディレクトリを受け入れます。

  3. 該当するソース・システム・コンテナを選択します。

  4. インポートするメタデータの適切なカテゴリーを、次から選択します。

    • Logical: 「Design」ビューに含まれている情報、およびデータベース接続情報をすべてインポートします。

    • System: 「Setup」ビューに含まれている情報を、サーバー用パスワードとデータベース接続用パスワードを除いて、すべてインポートします。

    • Run Time: ETL実行に関する情報をインポートします（「 Execute」ビューにあります）。

  5. メタデータを空白のリポジトリにインポートする場合、またはリポジトリ内の現在のメタデータと完全に置き換える場合は、「Truncate Repository Tables」を選択します。

    このアクションにより、現在のリポジトリの内容が上書きされます。「Truncate Repository Tables」オプションを選択すると、インポート・プロセスの速度が大幅に向上します。

  6. （省略可能）「Enable Batch Mode」を選択すると、インポートしたメタデータが、配列の挿入としてリポジトリに挿入されます。

    このアクションにより、インポート・プロセスの速度が向上します。

  7. 「OK」をクリックします。

  8. インポート・プロセスを確認するには、ログ・ファイル\OracleBI\DAC\log\import.logを調べます。

DACメタデータのエクスポート

DACのインポート/エクスポート機能を使用すると、ソース・システム固有のDACメタデータを、DACリポジトリにインポートまたはDACリポジトリからエクスポートできます。この機能を使用すると、開発環境からテスト環境または本番環境へというように、環境間でDACメタデータを移行できます。

DACメタデータをエクスポートするには:

  1. DACのメニュー・バーで、「Tools」→「DAC Repository Management」→「 Export」を選択します。

  2. DACメタデータのエクスポート先ディレクトリを選択するか、デフォルトのディレクトリを受け入れます。

  3. 該当するソース・システム・コンテナを選択します。

  4. エクスポートするメタデータの適切なカテゴリーを、次から選択します。

    • Logical: 「Design」ビューに含まれている情報、およびデータベース接続情報をすべてエクスポートします。

    • System: 「Setup」ビューに含まれている情報を、サーバー用パスワードとデータベース接続用パスワードを除いて、すべてエクスポートします。

    • Run Time: ETL実行に関する情報をエクスポートします（「 Execute」ビューにあります）。

  5. 「OK」をクリックします。

  6. エクスポート・プロセスを確認するには、ログ・ファイルの\OracleBI\DAC\log\export.logを調べます。

DACメタデータの配布

一般的には、開発、QA、本番など複数の環境があります。開発環境を変更したときには、テストしてから配信します。このとき、開発環境全体をエクスポートして他の環境に配布します。データはXMLファイルとしてエクスポートされ、エクスポートが実行されるクライアント・マシンのDAC\exportディレクトリに格納されます。

開発環境の変更を他の環境に適用するには、XMLファイルをすべてDAC\exportフォルダにコピーしてからそのデータをインポートします。DACメタデータをエクスポートするには、「DACメタデータのエクスポート」の手順に従います。DACメタデータをインポートするには、「DACメタデータのインポート」の手順に従います。

DACサーバーの自動実行

次の手順に従って、マシンを再起動したときに、DACサーバーが自動的に実行されるように設定します。

マシンの再起動時にDACサーバーが自動的に実行されるように設定するには:

  1. 「すべてのプログラム」にナビゲートし、「アクセサリ」→「システム ツール」→「タスク」を選択します。

  2. 「スケジュールされたタスクの追加」をダブルクリックします。

  3. タスク ウィザードで、startserver.batファイルを参照して「開く」をクリックします。

  4. 「コンピュータ起動時」を選択して「次へ」をクリックします。

  5. DACサーバーを起動するドメイン・ユーザー・アカウントとパスワードを入力して、「完了」をクリックします。

    「タスク」ウィンドウに、startserverのタスクが表示されます。

  6. タスクを右クリックして「プロパティ」を選択します。

  7. 「設定」タブで、「タスクの継続時間を指定する: 72時間」チェック・ボックスの選択を解除します。

DACサーバーをスケジュールされたタスクとして起動するには:

  1. 「すべてのプログラム」にナビゲートし、「アクセサリ」→「システム ツール」→「タスク」を選択します。

  2. startserverを右クリックしてから「実行」をクリックします。

DACサーバーをスケジュールされたタスクとして停止するには:

  1. 「すべてのプログラム」にナビゲートし、「アクセサリ」→「システム ツール」→「タスク」を選択します。

  2. startserverを右クリックしてから「タスクの終了」をクリックします。

DACサーバーが実行されているかどうかを確認するには:

  1. 「すべてのプログラム」にナビゲートし、「アクセサリ」→「システム ツール」→「タスク」を選択します。

  2. startserverのタスクを選択します。

  3. Windowsのメニュー・バーで、「表示」→「詳細」を選択します。

DACサーバーへのコマンドライン・アクセス

この項では、コマンドラインを使用してDACサーバーにアクセスする方法について説明します。この項の内容は次のとおりです。

実行プランを開始および停止する場合、またサーバー、データベース、および実行プランのステータス情報を取得する場合に、コマンドラインを使用してDACサーバーにアクセスできます。この機能を使用すると、DACクライアントを使用しないで、サードパーティの管理ツールを使用してDACサーバーにアクセスできます。

コマンドラインの操作

コマンドライン機能を使用すると、実行プランを開始したり、実行中の実行プランの操作を停止することができます。

実行プランの開始

DACサーバーは、実行プランの開始リクエストを受信すると、一連の確認作業を実行して、実行プランを開始できるかどうか確認します。最初に確認されるのは、リクエストされた名前を持つ実行プランが存在し、その実行プランがアクティブであることです。次に、最後に実行された実行プランのステータスが確認されます。ある実行プランの実行中に、DACサーバーが別の実行プランの開始リクエストを受信した場合には、そのリクエストは却下されます。実行プランが失敗した場合は、同じ実行プランの実行リクエストが再び実行されますが、別の実行プランの実行リクエストは却下されます。実行プランが前回正常に完了している場合には、新しい実行プランの実行リクエストが実行されます。

DACサーバーは、実行プランの開始リクエストを受信すると、次のいずれかの条件に当てはまる場合には警告を発行します（警告は単なる通知であり、実行プランが開始されないという意味ではありません）。

  • （システム・プロパティで設定する）「Generic Task Concurrency Limit」の数字が正数でない。

  • サーバー・リストに、アクティブなInformaticaサーバーがない。

  • パスワードが定義されていないInformaticaサーバーが1つ以上ある。

  • 最大セッション数が適切に設定されていないInformaticaサーバーが1つ以上ある。

  • パスワードが定義されていないデータソースが1つ以上ある。

  • 最大接続数が適切に設定されていないデータソースが1つ以上ある。

  • （「Physical Data Sources」タブで設定する）番号が定義されていないデータソースが1つ以上ある。

実行プランの実行操作の停止

DACサーバーで実行プラン実行操作の停止リクエストが受信されると、そのリクエストは次の場合に失敗します。

  • 実行中の実行プランの名前が、リクエストの名前と異なっている。

  • 現在実行中の実行プランがない。

クエリーをモニターするコマンドライン・ステータス

コマンドライン機能を使用すると、次のステータス情報を取得できます。

  • リクエストされた実行プランの概要。同じ実行プランのインスタンスが複数ある場合は、最後に実行されたインスタンスの概要が返されます。概要に含まれる情報の例を次に示します。

    (c) 2003 Siebel Systems, Inc.
Siebel DAC Server comprising the etl execution-management,  scheduler, logger, and network server.
ETL details for the last run:
ETL Process Id : 255 ETL Name : Complete ETL Run Name : DRY RUN OF Complete ETL: ETL Run - 2004-06-17 18:30:13.201 DAC Server : (aqamarD510) DAC Port : 3141 Status: Stopped Log File Name: Complete_ETL.255.log Database Connection(s) Used :


OLTP jdbc:microsoft:sqlserver://vranganaw8:1433;DatabaseName=OLTP Data Warehouse jdbc:microsoft:sqlserver://vranganaw8:1433;DatabaseName=olap

Informatica Server(s) Used  :

InformaticaServer4-vranganaw8:(4)  InformaticaServer2-vranganaw8:(2)  InformaticaServer3-vranganaw8:(3)  InformaticaServer1-vranganaw8:(10)

Start Time: 2004-06-17 19:00:06.885 Message: ETL was interrupted Actual Start Time: 2004-06-17 18:30:13.357 End Time: 2004-06-17 19:05:56.781 Total Time Taken: 35 Minutes
Start Time For This Run: 2004-06-17 19:00:06.885 Total Time Taken For This Run: 5 Minutes
Total steps: 212 Running steps: 0 Complete steps: 142 Failed/Stopped steps:70

  • すべてのアクティブなデータベースおよびInformaticaサーバーに対する接続ステータスの概要。

DACサーバーへのコマンドライン・アクセスの設定

Command Lineユーティリティを使用すると、リモート・マシンまたはローカル・マシンで実行するDACサーバーに対してコマンドを起動できます。Command Lineユーティリティには、DAC環境全体が必要ではありません。DACサーバーに対してコマンドを起動するマシンに必要なファイルは、DAWSystem.jar、dac.propertiesおよびdacCmdLine.batのみです。

DACサーバーへのコマンドライン・アクセスを設定するには:

  1. サポートされているバージョンのJava SDKがインストールされていることを確認してください。

  2. OracleBI\DACディレクトリからローカル・ディレクトリに、次のファイルをコピーします。

    • DAWSystem.jar

    • dac.properties

    • dacCmdLine.bat

  3. dacCmdLine.batファイルで、次の操作を実行します。

    1. JAVA_HOME変数を編集して、Java SDKがインストールされているディレクトリをポイントさせます。

    パスの参照に空白がないことを確認します。

    1. DAC_HOME変数を編集して、DACがインストールされているディレクトリをポイントさせます。

  4. dac.propertiesファイルで、次のパラメータ値を編集します。

    パラメータ 値
    ServerHost= DACサーバーのホスト名。
    ServerPort= DACサーバーのポート。デフォルトは3141です。
    RepositoryStampVal= DACクライアントの「Login Details」画面に表示されるリポジトリ・スタンプ。

    この値を検索するには、DACクライアントで「Help」にナビゲートしてから、「Login Details」を選択します。

    dac.propertiesファイルは、次のようになっている必要があります。

    ServerHost=vranganaw8 ServerPort=3141 RepositoryStampVal=851E0677D5E1F6335242B49FCCd6519

コマンドラインの使用によるDACサーバーへのアクセス

次の手順に従って、コマンドラインを使用してDACサーバーにアクセスします。

コマンドラインを使用してDACサーバーにアクセスするには:

  • コマンド・プロンプトで、次のように入力します。

    dacCmdLine <method name> <optional execution plan name>

    ここでは、method nameは次のメソッド名のいずれかです。

    メソッド名 説明
    StartETL 実行プランを開始します。実行プラン名を指定する必要があります。
    StopETL 実行プランの操作を停止します。実行プラン名を指定する必要があります。
    ETLStatus 実行プラン名を指定しない場合は、最後に実行した実行プランのステータスが返されます。実行プラン名を指定した場合は、指定した実行プランのステータスが返されます。
    DatabaseStatus アクティブなデータベース接続すべてにDACサーバーが接続できるかどうかを確認します。実行プラン名を指定する必要はありません。
    InformaticaStatus アクティブなInformaticaサーバーすべてにDACサーバーがpingできるかどうかを確認します。


    注意:

    メソッド名は、大文字と小文字が区別されません。実行プラン名は、大文字と小文字が区別されます。また、実行プラン名にスペースが含まれる場合は、名前を二重引用符で囲みます。

    次に例を示します。

    コマンドライン 説明 
    dacCmdLine EtlStatus
    		最後に実行された実行プランのステータスを返します。 
    dacCmdLine EtlStatus Forecast
    		Forecast実行プランの最後のインスタンスのステータスを返します。 
    dacCmdLine StopEtl Forecast
    		現在実行中の実行プランがForecastの場合、操作は強制終了されます。それ以外の場合は、このリクエストは無視されます。 
    dacCmdLine databasestatus
    		DACサーバーのDACリポジトリで定義されている、すべてのデータベース接続の健全性ステータスを返します。 
    dacCmdLine InformaticaStatus
    		DACサーバーのDACリポジトリで定義されている、すべてのInformaticaサーバー接続の健全性ステータスを返します。

DACリポジトリのコマンドライン・オプション

この項では、AutomationUtils.batファイルで表示されるDACリポジトリのコマンドラインのパラメータについて説明します。このAutomationUtils.batは、OracleBI\DACフォルダに格納されています。

DACメタデータのアプリケーション別インポート

IMPORTオプションにより、指定したソース・システム・コンテナのDACリポジトリにDACメタデータがインポートされます。インポート・プロセスでは、インポート済テーブルがすべて切り捨てられます。このコマンドでは、増分インポートを実行できません。

構文:

IMPORT <folderName> <contName1> <contName2> ...

パラメータの内容は次のとおりです。

パラメータ 説明
folderName インポート・ファイル構造のルートへのフルパス。
contName （省略可能）DACメタデータをインポートするソース・システム・コンテナの名前。どのコンテナも指定していない場合は、ファイル構造にあるコンテナがすべてインポートされます。

DACメタデータのアプリケーション別エクスポート

EXPORTオプションにより、指定したソース・システム・コンテナのDACリポジトリからDACメタデータがエクスポートされます。

構文:

EXPORT <folderName> <contName1> <contName2> ...

パラメータの内容は次のとおりです。

パラメータ 説明
folderName エクスポート・ファイル構造のルートへのフルパス。
contName （省略可能）DACメタデータをエクスポートするソース・システム・コンテナの名前。どのコンテナも指定していない場合は、ファイル構造にあるコンテナがすべてエクスポートされます。

DACメタデータのカテゴリー別インポート

IMPORTCATEGORYオプションにより、Logical、Run Time、Systemいずれかのカテゴリーに基づいて、DACリポジトリにDACメタデータがインポートされます。インポート・プロセスでは、インポート済テーブルがすべて切り捨てられます。このコマンドでは、増分インポートを実行できません。

構文:

IMPORTCATEGORY <folderName> <logical> <runtime> <system>

パラメータの内容は次のとおりです。

パラメータ 説明
folderName インポート・ファイル構造のルートへのフルパス。
logical カテゴリーがlogicalになっているデータをすべてインポートします（この情報はDACの「Design」ビューに含まれています）。
runtime カテゴリーがrun timeになっているデータをすべてインポートします（この情報はDACの「Execute」ビューに含まれています）。
system カテゴリーがsystemになっているデータをすべてインポートします（この情報はDACの「Setup」ビューに含まれています）。

DACメタデータのカテゴリー別エクスポート

EXPORTCATEGORYオプションにより、Logical、Run Time、Systemいずれかのカテゴリーに基づいて、DACリポジトリからDACメタデータがエクスポートされます。

構文:

EXPORTCATEGORY <folderName> <logical> <runtime> <system>

パラメータの内容は次のとおりです。

パラメータ 説明
folderName インポート・ファイル構造のルートへのフルパス。
logical カテゴリーがlogicalになっているデータをすべてエクスポートします（この情報はDACの「Design」ビューに含まれています）。
runtime カテゴリーがrun timeになっているデータをすべてエクスポートします（この情報はDACの「Execute」ビューに含まれています）。
system カテゴリーがsystemになっているデータをすべてエクスポートします（この情報はDACの「Setup」ビューに含まれています）。

スキーマの作成

CREATESCHEMAオプションにより、新しいDACリポジトリのスキーマが作成されます。

構文:

CREATESCHEMA <unicodeFlag> <workSpace name>

パラメータの内容は次のとおりです。

パラメータ 説明
unicodeFlag このパラメータの値がtrueの場合は、スキーマはUnicodeとして作成されます。値がfalseの場合は、スキーマはUnicodeとして作成されません。
workSpace name スキーマが作成されるワークスペースの名前。

スキーマの削除

DROPSCHEMAオプションにより、DACリポジトリのスキーマが削除されます。

構文:

DROPSCHEMA

分析

ANALYZEオプションにより、DACリポジトリのテーブルが分析されます。

構文:

ANALYZE

アップグレード

UPGRADEオプションにより、DACリポジトリがアップグレードされます。

構文:

UPGRADE

パスワードの設定

SETPASSWORDオプションにより、InformaticaサーバーのパスワードとDACリポジトリの物理データソースのパスワードが設定されます。

構文:

SETPASSWORD <type> <logicalName> <password>

パラメータの内容は次のとおりです。

パラメータ 説明
type 可能な値は、serverまたはdbconnです。
logicalName サーバーの論理名、またはDACのデータソース・レコードの論理名。


注意:

論理名またはパスワードに空白が含まれる場合には、引用符が必要です。

InformaticaワークフローのカスタムSQLファイルとの置換

InformaticaワークフローをカスタムSQLファイルに置き換えると、ロードのパフォーマンスを改善できます。

InformaticaワークフローをカスタムSQLファイルに置き換えるには:

  1. テーブルのロードに使用するSQLファイルを作成し、そのユニット・テストを実行します。

  2. DACが認識できるフォーマットで1つ以上のSQL文を使用して、XMLファイルまたはSQLファイルを作成します。

    XMLファイルまたはSQLファイルの作成の詳細は、「DACでSQLファイルを実行タイプとして使用」を参照してください。

    完全ロード用と増分ロード用にファイルを1つずつ作成できます。また、同一ファイルを完全ロードと増分ロードの両方に使用することもできます。

  3. ファイルをOracleBI\DAC\CustomSQLsディレクトリに保存します。

  4. DACの「Design」ビューの「Tasks」タブで、Informaticaワークフローを置き換えるタスクにクエリーを実行します。

  5. 「Command for Incremental Load」フィールドまたは「Command for Full Load」フィールドのワークフロー名を、XMLファイルまたはSQLファイルに置き換えます。

  6. 実行タイプをSQLに変更します。

Informatica Serverの最大セッション・パラメータ設定の決定

「Maximum Sessions」パラメータの値は、DACクライアントにInformatica Serverを登録するときに設定します。このパラメータは、Informaticaサーバーでパラレルに実行できるワークフローの最大数を指定します。セッションの数が0に指定されているか、または何も指定されていない場合は、DACサーバーではデフォルト値として10が割り当てられます。

「Maximum Sessions」パラメータの値を決定するときには、次の要因を検討する必要があります。

図6-1 パフォーマンスの実行のサンプル

この図は様々なETLの実行を示したグラフです。

トランザクション・データベースおよびデータ・ウェアハウス・データベースの接続数の決定

この項では、DACサーバーとトランザクション・データベースの間、およびDACサーバーとデータ・ウェアハウス・データベースの間に必要な、データベース接続の最大数を決定する方法について説明します。トランザクション・データベースとデータ・ウェアハウス・データベースの接続を作成するときには、「Max Num Connections」パラメータを設定します。

トランザクション・データベースの場合は、DACサーバーではこれらの接続を使用してチェンジ・キャプチャを実行します。この接続プールに設定した接続数により、同時に実行できるチェンジ・キャプチャのプロセス数が決まります。強力なトランザクション・データベース・サーバーがあり、オフピーク時にETLプロセスを実行しようとする場合、「Max Num Connections」の設定を15または20まで増やせます（デフォルトは10）。トランザクション・データベース・サーバーがそれほど強力でない場合には、ETLプロセスで基幹業務システムに負荷をかけすぎないようにしてください。その場合は、10より少ない値を設定してください。

データ・ウェアハウス・データベースの場合は、DACサーバーではこれらの接続を使用して、テーブルの切捨て、インデックスの削除および作成、テーブルの分析などのプロセスを実行します。「Max Num Connections」の値は、「Maximum Sessions」パラメータの値（Informaticaサーバーでパラレルに実行できるワークフローの最大数）より高く設定しないでください。これらの値には、1対1の関係があるためです。

同じマシンでの2つのDACサーバーの実行

2つのDACサーバーが異なるポートでリスニングし、2つの異なるリポジトリを指していれば、それらを同じマシンで実行できます。

同じマシンで2つのDACサーバーを実行するには:

  1. OracleBI\DACフォルダを、同じマシンの別フォルダにコピーします。

    たとえば、C:\OracleBI\DACフォルダをC:\DAC_SERVER2\DACにコピーします。

  2. config.batファイルを編集して、DAC_HOME変数を各インスタンスに対して適切に設定します。

    たとえば、C:\OracleBI\DACフォルダをC:\DAC_SERVER2\DACにコピーする場合は、C:\DAC_SERVER2\DAC\config.batファイルが適切に構成されていることを確認してください。

  3. 各DACクライアントを起動するには、DACディレクトリにナビゲートして、startclient.batファイルをダブルクリックします。

  4. 各インスタンスに対して、DACリポジトリの接続を構成します。

    1. 「Tools」にナビゲートして、「DAC Server Management」→「DAC Server Setup」を選択します。

      通知ダイアログに、この操作はDACサーバーを実行しているマシンで実行する必要があると表示されます。続行するかどうかが尋ねられます。

    2. 「Yes」をクリックします。

    3. 「Repository Connection Information」タブで、各インスタンスに適切な情報を入力します。データベース・ホストは各インスタンスで同一である必要があり、データベース・ポートはインスタンスごとに異なっている必要があります。

  5. 各インスタンスに対して、DACサーバーのシステム・プロパティを設定します。

    1. 「Setup」にナビゲートしてから、「DAC System Properties」を選択します。

    2. 「DAC Server Host」、「DAC Server OS」および「DAC Server Port」のプロパティを設定します。

  6. 各DACサーバーをそのディレクトリから起動します。

Index構文およびAnalyze Table構文のカスタマイズ

OracleBI\DAC\CustomSQLsディレクトリに格納されているcustomsql.xmlファイルには、インデックスの削除および作成に使用する構文、およびテーブルの分析に使用する構文が含まれています。customsql.xmlファイルを編集して、これらの操作による動作を変更できます。

Analyze Table構文を編集するには:

  1. OracleBI\DAC\CustomSQLsディレクトリに格納されているcustomsql.xmlファイルを開きます。

  2. 適切なデータベースタイプに対応するAnalyze Table構文を検索します。

    たとえば、Oracleデータベースの構文は次のとおりです。

    <SqlQuery name = "ORACLE_ANALYZE_TABLE" STORED_PROCEDURE = "TRUE"> DBMS_STATS.GATHER_TABLE_STATS(ownname => '@TABLEOWNER', tabname => '%1', estimate_percent => 30, method_opt => 'FOR ALL COLUMNS SIZE AUTO',cascade => true ) </SqlQuery>

  3. この構文を編集します。

    たとえば、インデックスが付けられたカラムのみの統計を収集するには、構文を次のように編集します。

    <SqlQuery name = "ORACLE_ANALYZE_TABLE" STORED_PROCEDURE = "TRUE"> DBMS_STATS.GATHER_TABLE_STATS(ownname => '@TABLEOWNER', tabname => '%1', estimate_percent => 30, method_opt => 'FOR ALL INDEXED COLUMNS',cascade => true ) </SqlQuery>

    注意:

    @TABLEOWNER、%1、%2などの変数には、文の実行時に、DACによって適切な値が代用されます。

Create Index構文を編集するには:

  1. OracleBI\DAC\CustomSQLsディレクトリに格納されているcustomsql.xmlファイルを開きます。

  2. 適切なデータベースタイプに対応するCreate Index構文を検索して、その構文を編集します。

DACでSQLファイルを実行タイプとして使用

DACで実行できるカスタムSQLファイルには、XMLフォーマットの.xmlファイルとプレーンテキストの.sqlファイルの2種類があります。XMLファイルとSQLファイルの例については、Oracle BI\DAC\CustomSQLsフォルダに格納されているsamplesql.sqlファイルおよびsamplesql.xmlファイルを参照してください。

XMLフォーマットのファイル

XMLファイルは、XML属性を使用して様々なオプションが定義されている一連のSQL文で構成されています。タグの名前と値は、大文字と小文字が区別されます。使用できるタグは次のとおりです。

name

SQLブロックの名前。DACサーバーは、この名前を使用してエラーをレポートします。

type

SQLブロックのタイプ。可能な値は「SQL」と「Stored Procedure」です。

  • 値が「SQL」の場合は、結果セットを返さない通常のSQLブロックを示します。たとえば、INSERT文、UPDATE文およびDELETE文は使用できますが、SELECT文は使用できません。

  • 値が「Stored Procedure」の場合は、適切なパラメータが設定されたストアド・プロシージャ名を示します。

デフォルト値は「SQL」です。

ContinueOnFail

エラーが発生した場合にETL実行を続行するかどうかを示します。可能な値はtrueとfalseです。

  • 値がtrueに設定されている場合は、次の文（存在する場合）に進みます。それ以降に文がない場合は、このタスクには「Completed」というマークが付けられます。

  • 値がfalseに設定されている場合は、実行は停止し、それ以降の文は実行されません。このタスクには「Failed」というマークが付けられます。

デフォルト値はfalseです。

dbConnType

文が実行される接続タイプを示します。可能な値はsource、targetおよびbothです。

  • 値がsourceに設定されている場合は、文はソース接続に対して実行されます。

  • 値がtargetに設定されている場合は、文はターゲット接続に対して実行されます。

  • 値がbothに設定されている場合は、文はソース接続およびターゲット接続に対して実行されます。

dbConnTypeの値が指定されていない場合は、文はターゲットに対して実行されます。SQL文に@DAC_TABLEキーワード（「キーワードの実行時代入」を参照）が指定されている場合は、この文はソース・テーブルとターゲット・テーブルのそれぞれに一度ずつ実行されます。

@DAC_TABLEキーワードで指定されたテーブルに、接続の優先（「Tasks」タブの「Source Tables」サブタブおよび「Target Tables」サブタブにある「Data Source」フィールドに示されている）がある場合は、優先接続が使用されます。

validDBPlatforms

SQLブロックが実行されるデータベース・プラットフォーム・タイプを示します。可能な値はDB2、DB2-390、MSSQL、OracleおよびTeradataです。この値が空白のままの場合、または指定されていない場合は、SQLブロックはすべてのデータベースタイプに対して実行できます。

複数の値を入力するときにはカンマで区切ります。

retries

エラーが発生した場合に、DACサーバーが文の実行を試行する回数を示します。この値は整数である必要があります。値が指定されていない場合、または整数以外の値が指定されている場合は、値はデフォルトの1に設定されます。エラー発生後に文が正常に実行された場合は、この値で指定されたループは中断します。

CDATAセクションの使用

SQL文がCDATAセクションに表示され、XML構造を中断しないで特殊文字（<、>、\など）を使用することができます。SQL文は、CDATAセクションごとに1つのみです。

キーワードの実行時代入

キーワードを使用すると、実行時にタグに値を代入できます。パラメータ名の前に接頭辞@DAC_を付けると、任意のソース・システム・パラメータをキーワードとして使用できます。

たとえば、$$LAST_REFRESH_DTという名前のソース・システム・パラメータがある場合は、@DAC_$$LAST_REFRESH_DTを使用してこのパラメータを参照できます。

共通のキーワードをいくつか次に示します。

@DAC_TABLE

dbConnTypeタグの値に応じて、このキーワードに代入されるのは、タスクのソース・テーブルとターゲット・テーブルのいずれかになります。この文は、ソース・テーブルまたはターゲット・テーブルの数と同じ回数だけ実行されます。

@DAC_DATASOURCE_ID

このキーワードに代入されるのは、「Physical Data Sources」タブに表示された「Data Source Number」です。

@DAC_SYSDATE

このキーワードに代入されるのは、現在のタイムスタンプです。

@DAC_TBL_REFRESH_DATE

このキーワードに代入されるのは、接続名とテーブルの組合せの更新日です。この値が代入されるのは、@DAC_TABLEキーワードも使用されている場合のみです。

@DAC_CURRENT_PROCESS_ID

このキーワードに代入されるのは、「Process ID」です。これは、「Execute」ビューの「Current Run」タブの「Process ID」カラムにあります。

XMLフォーマットのファイルの例

XMLフォーマットのファイルの例を次に示します。

<!-- The following statement will be executed once on the target connection.--><sql name="Insert Statement" type="SQL"> <![CDATA[  insert into test_trgt (id) values (999)  ]]></sql><!-- The following stored procedure will be executed once per target tableon the table connection or task's target connection if table doesn't haveit's own defined.Even if there is an error, the execution will continue.Database platform type does not matter.--><sql name="Stored Procedure1" type="Stored Procedure" continueOnError="true"> <![CDATA[ test_procedure ('abc', 2, '@DAC_TABLE') ]]></sql><!-- The following statement will be executed once per target table on the table connection or task's target connection if table doesn't have it's own defined.The statement will be executed as many times as there are target tables.The statement will be executed only if target table connection is DB2-390 or Oracle--><sql name="insert new row" type="SQL" dbConnType="target" continueOnFail="true" validDBPlatforms="DB2-390, Oracle"><![CDATA[insert into @DAC_TABLE (INTEGRATION_ID, DATASOURCE_NUM_ID, ETL_PROC_WID) values ('1', @DAC_DATASOURCE_NUM_ID, @DAC_CURRENT_PROCESS_ID)]]></sql><!--The following statement will be executed once per source table on the table connection or task's source connection if table doesn't have it's own defined.Database platform type does not matter.--><sql name="UPDATE ETL_PROCESS_ID" type="SQL" dbConnType="source" continueOnFail="true"><![CDATA[UPDATE @DAC_TABLE SET DATASOURCE_NUM_ID= @DAC_DATASOURCE_NUM_ID]]></sql><!--The following statement uses one of the DAC Source System Parameters.Assume there was a variable defined as $$LAST_REFRESH_DATE that need to reflect the last refresh date ofthe target table, here is how the sql will look like.Database platform type does not matter.--><sql name="UPDATE ETL_PROCESS_ID SINCE LAST REFRESH" type="SQL" dbConnType="target" continueOnFail="true"><![CDATA[UPDATE @DAC_TABLE SET DATASOURCE_NUM_ID= @DAC_DATASOURCE_NUM_IDWHERE LAST_UPD = @DAC_$$LAST_REFRESH_DATE]]></sql></CustomSQLs>

プレーンテキストのSQLファイル

プレーンテキストのSQLファイルは、一連のSQL文で構成されています（ストアド・プロシージャ・コールはなし）。SQL文はセミコロン（;）で区切られ、コメント・タグが許可されます（//、/* comment */、--）。SQL文のいずれかが失敗した場合は、タスクの実行ステータスが「Failed」になります。

プレーンテキストのSQLファイルの例を次に示します。

CREATE TABLE w_etl_temp (name varchar(50))
;
UPDATE w_etl_temp
SET name = 'that's right' //this line demonstrates the use of ' in a text area
WHERE name LIKE 'gone fishing%';

/*
*some
*query
*statement
*/
 SELECT * FROM w_etl_temp
;
DROP TABLE w_etl_temp
;
/*end of file*/

チェンジ・キャプチャのプロセスの概要（Siebelソースのみ）

この項では、Siebelトランザクション・データベースからデータを抽出するときに使用するチェンジ・キャプチャのプロセスについて説明します。この項の内容は次のとおりです。

最初のデータ・キャプチャ

データの抽出元となる各Siebelトランザクション・ソース・テーブル（S_）には、S_ETL_I_IMG_テーブルとS_ETL_R_IMG_テーブルが1つずつあります。

最初にステージング・テーブルが抽出されるときは、指定した期間の行が選択され、適切なS_ETL_R_IMG_テーブルに挿入されます。指定する期間は、「Execution Plans」タブの「Prune Days」パラメータで設定します。「Prune Days」パラメータの詳細は、「「Execution Plans」タブ」を参照してください。

チェンジ・キャプチャのメカニズム

使用するチェンジ・キャプチャのメカニズムには、次の2種類があります。

  • テーブルを使用するチェンジ・キャプチャ

    これは、最も一般的な方法です。S_ETL_I_IMG_テーブルタイプとS_ETL_R_IMG_テーブルタイプ、およびソース・テーブルのLAST_UPDカラムを使用します。

  • 日付カラムを使用するチェンジ・キャプチャ

    場合によっては、事前定義された日付カラムを使用してチェンジ・キャプチャを有効化することができます（S_ETL_I_IMG_テーブルとS_ETL_R_IMG_テーブルは使用しないで）。

テーブルを使用するチェンジ・キャプチャ

S_テーブルを抽出するときには、プロセスはID行の情報を探します（S_テーブルのROW_IDとMODIFICATION_NUMの組合せ）。この情報は行のイメージ・テーブル（S_ETL_R_IMG_）には存在しません。また、LAST_REFRESH_DATEの値から「Prune Days」パラメータの設定が差し引かれた値よりLAST_UPDの値のほうが新しいカラムには存在しません。この情報がS_ETL_I_IMGテーブルに挿入されます。S_ETL_I_IMG_テーブルは、SDE抽出プロセス時に基本テーブルと結合し、更新時にチェンジ・キャプチャの行のみが抽出されます。

S_ETL_R_IMGテーブルには、ROW_ID、MODIFICATION_NUM、およびLAST_UPDが格納されています。これらは、定義された「Prune Days」の期間のLAST_UPDが格納されているS_テーブルの行に対するものです。LAST_UPDカラムは、S_ETL_R_IMGテーブルからレコードを削除する場合に使用されます。レコードは、「Prune Days」の期間を超えるとすぐに削除されます。このテーブルを使用して、レコードが実際に更新されていなければ、「Prune Days」の期間に該当するレコードが、更新としてキャプチャされないことを確認します。これにより、チャンジ・キャプチャの更新が、効率的でより迅速になります。

ETLプロセスが完了したら、チェンジ・キャプチャのイメージ・テーブル（S_ETL_I_IMG_）のデータが、行イメージ（S_ETL_R_IMG）テーブルに取り込まれます。それ以降、S_ETL_R_IMG_情報が次の更新で使用されます。

Siebelトランザクション・テーブルのLAST_UPDカラムはチェンジ・キャプチャに使用されますが、タイムスタンプは、実際のトランザクション・イベントの時刻ではなく、データがデータベースにコミットされた時刻を反映します。これは、リモート同期化、ハンドヘルド同期化、UTC変換など、トランザクションの時刻とそれがデータベースにコミットされる時刻の間に大きなずれが発生する可能性のあるプロセスによるものです。そのため、最後の更新が実行された日付よりもLAST_UPD日付のほうが古いトランザクション・データベースに、データ行をコミットできます。したがって、抽出が単にLAST_UPDの日付に基づいている場合、抽出時に一部の行が欠落することがあります。

ただし、LAST_UPD日付のカラムでは、比較する必要のある行の数を制限することで、効率的なチェンジ・キャプチャのプロセスがまだ可能です。トランザクション・テーブルの行は、除去日数を差し引いたLAST_REFRESH_DATEより新しいLAST_UPDの日付に基づいて絞り込まれます。次に、ROW_IDとMODIFICATION_NUMの組合せが行イメージ・テーブルと比較され、変更されたレコードが検出されます。

「Prune Days」パラメータにより、LAST_REFRESH_DATEよりLAST_UPDの値のほうが古い行が欠落しなくなります。このパラメータは、（リモート同期化のように）レコードを欠落させる可能性のあるプロセスの経験に基づいて、ユーザーが設定できます。

プライマリ・テーブルおよび補助テーブル

DACでは、プライマリ・テーブルと補助テーブルの両方に対して、チェンジ・キャプチャが実行されます。複数のソース・テーブルが関連する場合は、補助テーブルとプライマリ・テーブル両方のレコードに、変更済というマークを付ける必要があります。補助テーブルの場合は、補助マッピングを書き込んで、プライマリ・テーブルに変更済というマークを付ける必要があります。これを実行するSQLクエリーは、マッピングSDEINC_FindAux_の一部です。

抽出ロジックでは、レコードがプライマリ・テーブルで更新されていない（したがって、SDEプロセス時に抽出された）場合でも、行を変更済とみなすことが必要になる場合もあります。この状況が発生するのは、子テーブルの行が変更されており、一貫性のあるセットとともにデータ・ウェアハウス・テーブルをロードするためにヘッダー行およびマスター行を抽出する必要があるときです。

S_CONTACT_X行が変更されたときには、対応するS_CONTACTも抽出する必要があります。この場合、S_CONTACTの行にも、チェンジ・キャプチャの行イメージ・テーブルに行を挿入することで、変更済というマークが付けられます。

S_ORDERITEM行が変更されたときには、対応するS_DOC_ORDERも抽出する必要があります。この場合、S_DOC_ORDERの行にも、チェンジ・キャプチャの行イメージ・テーブルに行を挿入することで、変更済というマークが付けられます。

これらの補助チェンジ・キャプチャのプロセスは、データ・ウェアハウスのデータモデルに大きく依存しており、ETLロジックをサポートするために必要です。

例: アカウント次元のロードのためのS_ETL_I_IMG_テーブルの構築

この項では、テーブルを使用したチェンジ・キャプチャのプロセスの例をさらに示します。

  1. 関連するソース・テーブルすべてのイメージ・テーブルをロードします。

    このエンティティの内容は、S_ORG_EXTテーブルとS_ORG_EXT_Xテーブルから取り込まれたものです。これらのテーブルのいずれかで任意の行が変更されると、そのレコードには必ず変更済というマークが付けられます。

    S_ORG_EXTのイメージ・テーブルは、S_ETL_I_IMG_26です。イメージ・テーブルの接頭辞は、任意のソース・テーブルの表示にDACを使用して検索できます。このテーブルは、あらゆる更新時に新しいデータをロードする前に切り捨てられます。

    ETLでは、S_ORG_EXTのROW_ID情報を選択することによって、S_ETL_I_IMG_26にプロセス行が挿入されます。このプロセス行は、（ROW_IDとMODIFICATION_NUMの組合せで）S_ETL_R_IMG_26に存在しておらず、LAST_REFRESH_DATEから「Prune Days」設定が差し引かれた値よりLAST_UPDの値のほうが新しいものです。これは、ETL実行の際に、DACの内部イメージ構築タスクにより実行されます。

    同様に、S_ORG_EXT_Xのイメージ・テーブルS_ETL_I_IMG_27がロードされます。

  2. 補助テーブル・ベースの変更に対するイメージ・テーブルをロードします。

    基本的なチェンジ・キャプチャ以外に、ETLの特殊要件により、追加処理が必要になる場合があります。この例では、S_ORG_EXT_Xのみが変更された場合でも、S_ORG_EXTを抽出して処理する必要がある場合を示しています。理由としては、テーブルが結合されてW_ORG_Dが形成されること、およびW_ORG_D（SDEマッピング）の抽出プロセスで、プライマリ・テーブルS_ORG_EXTのみに対して、チェンジ・キャプチャの行イメージ・テーブルで変更済のROW_IDが検索されることの両方があります。そのため、S_ORG_EXTのROW_IDが行イメージ・テーブルに存在する場合にのみ、抽出処理が発生します。

    この場合、S_ORG_EXT_Xが変更されたときには、S_ORG_EXT.ROW_IDで対応する行をチェンジ・キャプチャの行イメージ・テーブルに挿入するために、SDEINC_FindAux_マッピングが必要になります。次の論理文でメソッドを示します。

    S_ORG_EXT_X（S_ETLI_IMG_27の行）テーブルで変更されたレコードを特定してから、S_ORG_EXTで対応する行を検索します。S_ORG_EXTでそれらに対応する行のROW_IDとMODIFICATION_NUMを、S_ETL_I_IMG_26テーブルに挿入します。

    Informaticaを使用して、データ・ウェアハウスの抽出ロジックに応じて、補助マッピングSDEINC_FindAux_を、リクエストする各プライマリ・テーブルに書き込む必要があります。DACを使用して、基本テーブル（この場合はS_ORG_EXT）の抽出マッピングに、この補助タスクを親としてリンクする必要があります。

    これは、SDEINC_FindAux Informaticaマッピングに対するSQLオーバーライドです。

    SELECT
   S_ORG_EXT.ROW_ID,
   S_ORG_EXT.MODIFICATION_NUM,
   S_ORG_EXT.LAST_UPD
FROM
   S_ORG_EXT,
   S_ORG_EXT_X,
   S_ETL_I_IMG_27 IMG
WHERE
   (
   IMG.ROW_ID = S_ORG_EXT_X.ROW_ID
   AND
   S_ORG_EXT_X.PAR_ROW_ID = S_ORG_EXT.ROW_ID
   )
   AND NOT EXISTS
   (  SELECT 'X'
      FROM
      S_ETL_I_IMG_26 IMG1
      WHERE
      IMG1.ROW_ID = S_ORG_EXT.ROW_ID
   )

  3. チェンジ・キャプチャのイメージ情報を使用して、ソース・テーブルの情報を抽出します。

    新しいレコードまたは変更されたレコードが特定された後に、それらの行がステージング・テーブルに書き込まれます。ステージング・テーブルをロードするInformaticaマッピングでは、イメージ・テーブルに取り込まれたROW_ID情報が使用されます。

    この例では、ステージング・テーブルW_ORG_DSのロードを示します。このテーブルにポピュレート入力するメインのロジックは、マッピングするSDE_OrganizationDimensionのSQLオーバーライドにあります。

    DACでは、抽出されているテーブルに対するビューが作成されます。このビューは、テーブルが初めて抽出されるものか、チェンジ・キャプチャで抽出されるものかに応じて異なります。

    • 初めて抽出される場合は、このビューはSELECT * FROM S_ORG_EXTとして作成されます。

    • チェンジ・キャプチャで抽出される場合は、このビューはSELECT * FROM S_ORG_EXT, S_ETL_I_IMG_26 IMG WHERE S_ORG_EXT.ROW_ID = IMG.ROW_IDとして作成されます。

    マッピングにおけるSQLオーバーライドでは、データの抽出にビューが使用されます。

    SELECT
   S_ORG_EXT.ROW_ID,
   S_ORG_EXT.NAME, …..
   ….
   ….
FROM
   V_ORG_EXT,
   S_ORG_EXT_X,
   …..
WHERE
   {
      V_ORG_EXT S_ORG_EXT
      LEFT OUTER JOIN S_ORG_EXT_X ON
      S_ORG_EXT.ROW_ID = S_ORG_EXT_X.PAR_ROW_ID
      …..
   }
AND
   S_ORG_EXT.ROW_ID <> 'INT_COMPANY_ID'

日付カラムを使用するチェンジ・キャプチャ

予想は、イメージ・テーブルを使用しないで抽出されます。値S_FCSTSER_DATEは、日付カラムARCHIVE_TSを使用して追跡されます。管理者は、提出済予想、確定済予想、およびOracle Business Analytics Warehouseへのロード準備ができた予想に対して、ARCHIVE_TSを設定します。S_ETL_RUNは、予想が抽出された前回のETL日付、および予想が抽出中である現在のETL日付を格納します。前回のETL日付および（現在のETL日付より小さい）前回のARCHIVE_TSの値より現在のARCHIVE_TSの値のほうが大きい予想はすべて、現在のETLで抽出されます。ETL日付および（現在のETL日付より小さい）ARCHIVE_TSは両方とも、S_ETL_CURR_RUNに格納されます。


注意:

Oracle Business Analytics Warehouseの予想が更新されることはありません。一度ロードされると、その予想は確定します。		 

SELECT
…..
FROM
   S_FCSTSER_DATE,
   S_FCSTSER,
   S_ETL_CURR_RUN,
   ……..
WHERE
   S_FCSTSER_DATE.FCSTSER_ID =  S_FCSTSER.ROW_ID
   AND S_FCSTSER_DATE.ARCHIVE_TS > S_ETL_CURR_RUN.PREV_LOAD_DT
   AND S_FCSTSER_DATE.ARCHIVE_TS <= S_ETL_CURR_RUN.LOAD_DT

チェンジ・キャプチャのフィルターの使用

チェンジ・キャプチャのフィルターを使用すると、Siebelトランザクション・データベースのデータを選択して、データ・ウェアハウスにロードできます。ChangeCaptureFilter.xmlファイルの条件を設定して、特定のテーブルのデータを絞り込むことができます。このファイルは、OracleBI\DAC\CustomSQLsディレクトリに格納されています。そこにはXMLのサンプルが用意されていますので、コピーし、必要に応じて変更できます。この機能の使用法についての詳細な手順は、ファイルの冒頭に記載されています。

削除されたレコードの追跡

Oracle Business Analytics Warehouseのチェンジ・キャプチャのプロセスでは、Siebelトランザクション・データベースで削除対象とするレコードを特定するときに、削除トリガーが使用されます。削除されたレコードは、S_ETL_D_IMGテーブルに格納されます。チェンジ・キャプチャのプロセスでは、DACサーバーがS_ETL_D_IMGテーブルのデータをS_ETL_I_IMGテーブルに移動します。S_ETL_I_IMGテーブルでは、OPERATIONカラムに「D」と表示され、そのレコードが削除されたことが示されます。チェンジ・キャプチャの同期化プロセスでは、S_ETL_I_IMGテーブルに移動されたS_ETL_D_IMGテーブルのレコードがフラッシュされます。DACでは、「Design」ビューの「Tasks」タブで右クリック・コマンド「Output to File」を使用すると、チェンジ・キャプチャのプロセス時およびチェンジ・キャプチャの同期化プロセス時に、実行中のSQLを表示できます。

事前構成されたETLのプロセスでは、ターゲット・テーブルのW_ORG_DおよびW_PERSON_D、すなわちS_ORG_EXT、S_CONTACTおよびS_PRSP_CONTACTのソース・テーブルに対して、削除されたレコードが取り込まれます。これらのソース・テーブルには、削除されたレコードを追跡できるように、Siebelトランザクション・データベースで作成された削除トリガーが格納されている必要があります。

垂直統合型アプリケーションでは、事前構成されたETLプロセスにより、W_FUND_FおよびW_ALIGNMT_DHに対して、削除されたレコードが取り込まれます。追加テーブルのS_MDF_TXN、S_ASGN_GRP_POSTN、S_ASGN_RULE_ITEMに対するトランザクション・データベースに、削除トリガーを作成する必要があります。

Oracle Business Analytics Warehouseでは、事前構成された可視性テーブルは非アクティブ化されています。可視性テーブルをアクティブ化する場合は、オプションのテーブルにも削除トリガーを作成する必要があります。

事前構成された可視性テーブルのSIA AccountおよびContactは、垂直統合型アプリケーションに対して、デフォルトでアクティブ化されています。所属する組織で可視性テーブルをまったく使用しない場合は、DACで非アクティブ化する必要があります。

削除したレコードが追跡されるターゲット・テーブルでは、INACTIVE_FLGカラムに「D」と表示され、ソース・レコードが削除されたときにそのレコードが削除されたことが示されます。レコードに削除済というフラグを立てるこの方法は、ソフト削除と呼ばれています。これに対して、レコードを物理的に削除することをハード削除と呼びます。削除されたレコードを、可視性に関連するデータ・ウェアハウス・テーブルで追跡するときには、レコードは物理的に削除されます。他のテーブルで参照されるテーブルでは、ソフト削除を使用する必要があるというのが一般的なルールです。テーブルが他のどのテーブルでも参照されない場合は、ハード削除を使用できます。

集計テーブルは、各ETLプロセスで再構築されます。そのため、レコードを基本テーブルから物理的に削除しても影響はありません。ソフト削除方法を使用する場合は、削除されたレコードを除外するために、集計構築マッピングの変更を検討する必要があります。


注意:

Oracle BI Serverでは、ソフト削除は認識されません。そのため、.rpdファイルを変更して、ソフト削除されたレコードがレポートに取り込まれないようにする必要があります。

事前構成されたETLのチェンジ・キャプチャに対して削除トリガーを作成するには:

  1. DACのメニュー・バーで、「Tools」→「ETL Management」→「Configure」を選択します。

  2. 「Sources」ダイアログで、ターゲット・データベースおよびトランザクション・データベースのデータベース・プラットフォームを選択して、「OK」をクリックします。

  3. Data Warehouse Configurationウィザードで、「Transaction Database」チェック・ボックスの「Create Delete Triggers」を選択して、「Next」をクリックします。

    「Delete Triggers」タブがアクティブになります。

  4. 次のいずれかを選択します。

    オプション 説明
    Create Triggers トリガー文を直接実行します。
    Write Script to File トリガー文をファイルに書き込みます。これは、データベース管理者が実行できます。

  5. DACで定義されているデータベースタイプを選択します。

  6. DB2 zSeriesデータベースの場合は、基本テーブルの所有者を入力します。

  7. （省略可能）「Include Optional Triggers」チェック・ボックスを選択して、オプション・テーブルのトリガーを作成します。

  8. 「Start」をクリックします。

新しいソース・テーブルに対して削除トリガーを作成するには:

  1. DACで、「Design」ビューにナビゲートしてから「Tables」を選択します。

  2. 削除されたレコードを追跡するテーブルを選択します。

    テーブルにイメージの接頭辞があることを確認します。

  3. テーブルを右クリックして「Change Capture Scripts」→「Generate Image and Trigger Scripts」を選択します。

  4. 「Triggers and Image Tables」ダイアログで、ソース・データベースのデータベースタイプを選択します。

  5. 「Generate Image Table Scripts」オプションおよび「Generate Trigger Script(s)」オプションが選択されていることを確認します。

  6. データベースに対してスクリプトを実行します。

削除されたレコードを追跡するには:

  1. 削除トリガーが該当するテーブルで有効になっていることを確認します。

  2. WHERE operation = 'D'という句を使用して、カスタムInformaticaワークフローを該当するI_IMGテーブルに書き込み、次元テーブルおよび要素テーブルに取り込みます。

  3. DACでは、ワークフローをタスクとして登録します。

  4. 該当する依存性を定義します。

    そのようなワークフローの例については、事前構成されたタスクSDE_OrganizationDimension_LoadDeletedRowsを参照してください。

複数のInformaticaサーバーで単一のInformaticaリポジトリを指す

複数のInformaticaサーバーをインストールし、それらで単一のInformaticaリポジトリを指すようにすることができます。各Informatica ServerをDACに登録して、一意のマシン名とサーバー名を指定する必要があります。DACにInformatica Serverを登録する手順については、『Oracle Business Intelligence Applicationsインストレーションおよび構成ガイド』を参照してください。

DACでのETL障害の処理

この項の内容は次のとおりです。

実行プランの実行が失敗した場合

実行プランの実行時にタスクが失敗した場合は、失敗したタスクに依存するタスクのステータスが「Stopped」に変わります。タスクがまだ実行中のときには、実行プランのステータスは「Running」です。すべてのタスクが実行されているときに、1つ以上のタスクが失敗した場合は、実行プランのステータスが「Failed」に変わります。

失敗したタスクを「Execute」ビューの「Current Run」で確認し、問題を修正してから、失敗したタスクのステータスを「Queued」に変更してタスクを再びキューに格納することができます。その後でETLを再開できます。これで、すべてのタスクが再実行されます。手動でタスクを実行して、そのステータスを「Completed」に変更してからETLを再開することもできます。ステータスが「Completed」になっているタスクはスキップされます。


注意:

DACサーバーでは、手動で実行されたタスクは検証されません。

失敗したETLを再開するには、「Execute」ビューの「Current Run」タブで「Run Now」をクリックします。

DACサーバーが異常終了した場合

ETLの実行中にDACサーバーが失敗した場合は、ETL実行のステータスは「Running」のままです。DACサーバーを再起動したとき、「Auto Restart ETL DAC」システム・プロパティが「True」に設定されている場合は、ETLが自動的に実行されます。同じシステム・プロパティが「False」に設定されている場合は、サーバーが再起動すると、正しいステータスである「Failed」に設定されます。ETLを障害発生時点から実行するには、サーバーにリクエストを再送信します。

DACサーバーは、DACリポジトリへの接続が中断されると、自動的に終了します。

現在実行中の実行プランの破棄

失敗した実行プランを破棄するには、「Current Run」タブにナビゲートし、実行プランを右クリックしてステータスを「Mark as Completed」に変更します。これで、実行ステータスが強制的に「Completed」に更新されます。別の実行リクエストを送信すると、DACサーバーではその別のインスタンスが作成されます。


注意:

この手順は、開発環境またはテスト環境でのみ実行してください。これは、データが整合性のない状態のまま残され、データをすべてリロードすることが必要になる可能性があるためです。

「Sorted Input」によるAggregator変換タスクの失敗

Informatica Aggregator変換を使用するタスクは、「Sorted Input」オプションがアクティブのときに失敗する可能性があります。SDE_DTLFORECASTFACTタスクおよびSDE_COSTLISTタスクは、そのような状況で失敗する可能性があるタスクの例です。

そのようなタスクが失敗しないようにするには、Informatica Designerで「Mapping Designer」にナビゲートし、対応するマッピングを開き、「Aggregator transformation」で「Sorted Input」チェック・ボックスの選択を解除します。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引