| Oracle® Airlines Data Model実装およびオペレーション・ガイド 11gリリース2 (11.2) B72456-01 |
|
 前 |
 次 |
この章では、Oracle Airlines Data Modelウェアハウスを移入するために使用するETL(抽出、変換およびロード)プログラムについて説明します。内容は次のとおりです。
図2-1「Oracle Airlines Data Modelウェアハウスのレイヤー」は、Oracle Airlines Data Modelウェアハウスの3つのレイヤー、オプションのステージング・レイヤー、基盤レイヤーおよびアクセス・レイヤーを示しています。2つのタイプのETL(抽出、変換およびロード)を使用して、これらのレイヤーを移入します。
Source-ETL。ステージング・レイヤー(存在する場合)および基盤レイヤー(つまり、実表、参照表および検索表)にOLTPシステムのデータを移入するETLは、ソースETLと呼ばれます。
Oracle Airlines Data Modelは、Source-ETLスクリプトを含みません。使用しているのOLTPシステムを理解し、カスタマイズしたOracle Airlines Data Modelを使用して、自分でSource-ETLを作成する必要があります。Source-ETLの作成の詳細は、「Oracle Airlines Data Modelウェアハウスの基盤レイヤーのETL」を参照してください。
Intra-ETL。基盤レイヤーのデータを使用してアクセス・レイヤー(つまり、導出表、集計表、マテリアライズド・ビュー、OLAPキューブおよびデータ・マイニング・モデル)を移入するETLは、Intra-ETLと呼ばれます。
Oracle Airlines Data Modelは、Intra-ETLを含みます。デフォルトのIntra-ETLを変更して、カスタマイズした基盤レイヤーからカスタマイズしたアクセス・レイヤーに移入できます。Intra-ETLの詳細は、「Oracle Airlines Data ModelのIntra-ETLのカスタマイズ」を参照してください。
Oracle Airlines Data Modelウェアハウスの基盤レイヤー(つまり、実表、参照表および検索表)にOLTPシステムのデータを移入するETLは、Source-ETLと呼ばれます。
Oracle Airlines Data Modelウェアハウスの基盤レイヤーに移入するには、Oracle Warehouse Builderまたは別のETLツールを使用して固有のSource-ETLスクリプトを書き込み、それらのスクリプトを使用して基盤レイヤーに移入します。
次のトピックでは、Source-ETLの書込みの一般的な情報について説明します。
Oracle Airlines Data ModelのSource-ETLを設計および作成するときは、次の点に注意してください。
Oracle Airlines Data Modelで提供され、『Oracle Airlines Data Modelリファレンス』で説明されているカレンダ移入スクリプトを使用してカレンダ・データを移入できます。
表は次の順序で移入します。
検索表
参照表
実表
1つのカテゴリの表を分析してから、次のカテゴリの表をロードします(たとえば、参照表をロードする前に検索表を分析します)。また、Intra-ETLプロセスを実行する前に、Source-ETLでロードされたすべての表を分析する必要があります。
|
参照: 『Oracle Database管理者ガイド』の表、索引およびクラスタの分析に関するトピック。 |
ETLは、最初に元のソースからデータを抽出し、データの品質を確認して、元のソースのデータを一貫性のある状態にします。ETLは、問合せツール、レポート・ライター、ダッシュボードなどでデータにアクセスするため、物理オブジェクトに「クリーンな」データを移入します。
データの取得が行われる基本サービスは、次のとおりです。
データ・ソーシング
データ移動
データ変換
データのロード
論理アーキテクチャの観点から、データ取得サービスを提供するためにこれらの構築ブロックを構成する多くの異なる方法があります。データ・ウェアハウス・アーキテクチャ内を対象とする幅広いオプションを含む使用できる主要なアーキテクチャ・スタイルは、次のとおりです。
バッチ抽出、変換およびロードとバッチ抽出、ロード、変換、ロード
バッチ抽出、変換およびロード(ETL)およびバッチ抽出、ロード、変換、ロード(ELTL)は、データ・ウェアハウス実装の従来のアーキテクチャです。これらの違いは、変換がデータベースの内部または外部で発生するかどうかです。
バッチ・ハイブリッド抽出、変換、ロード、変換、ロード
バッチ・ハイブリッド抽出、変換、ロード、変換、ロード(ETLTL)は、ハイブリッド戦略です。この戦略は、変換設計に対するハンド・コーディング・アプローチを排除してメタデータドリブン・アプローチを適用する最も高い柔軟性を提供し、エンタープライズ・ウェアハウスのデータ処理機能を引き続き利用できます。このターゲットの設計では、ステージング表をロードする前の事前処理の手順として、変換処理がウェアハウスの外部で最初に実行され、サーゲット表に最後にロードする前に追加の変換処理がデータ・ウェアハウスの内部で実行されます。
リアルタイム抽出、変換、ロード
最新のデータのサービス・レベルでデータ・ウェアハウス環境の詳細な更新情報を要求する場合、リアルタイム抽出、変換、ロード(rETL)が適切です。このアプローチでは、rETLプロセスが適宜メッセージ・バス(キュー)から抽出するため、OLTPシステムで任意のイベントをアクティブに公開する必要があります。メッセージ・ベース・パラダイムは、公開およびサブスクライブ・メッセージ・バス構造または信頼性のあるキューのポイントツーポイント・メッセージングとともに使用します。
Oracle Airlines Data ModelのSource-ETLを設計する場合、ビジネス・ニーズを最適に満たすアーキテクチャを使用します。
抽出システムの構築を開始する前に、表の元のソース・フィールドとターゲット宛先フィールドのリレーションシップをマップする論理データ・インタフェース・ドキュメントを作成します。このドキュメントは、ETLシステムの最初から最後まで適用されます。
データ・マッピング・ドキュメントの列は、結合される場合があります。たとえば、ソース・データベース、表名および列名が単一のターゲット列に結合される場合があります。連結された列内の情報は、ピリオドで区切られます。形式に関係なく、論理データ・マッピング・ドキュメントの内容がETLプロセスの十分な計画に必要となる重要な要素であることが証明されました。
データ・クリーニングは、表に提供するデータを消去および検証し、データを一貫性のある状態にする既知のビジネス・ルールを適用するために必要なすべての手順で構成されます。クリーニングおよび準拠の手順の視点は、データの利点の可能性というよりも包含および制御になります。
データ品質の問題がある場合、問題の解決方法について、ITおよびビジネス・ユーザーとともに計画を構築します。
次の質問に回答します。
データが見つかりませんか。
データは不正ですか、またはデータに一貫性がありませんか。
問題をソース・システムで修正する必要がありますか。
データ品質レポート、アクション・プログラムおよび人の責任を設定します。
次に、次のプロセスおよびプログラムを設定します。
データ品質測定プロセスを設定します。
データ品質レポート、アクション・プログラムおよび人の責任を設定します。
ETLプロセス間のすべてのデータ移動は、ジョブで構成されます。ETLワークフローは、必要な依存性について、適切な順序でこれらのジョブを実行します。Oracle Warehouse Builderなどの一般的なETLツールは、このようなワークフロー、ジョブ設計および実行制御をサポートします。
ETLジョブおよびワークフローを設計する場合のヒントは、次のとおりです。
すべてのジョブで一般的な構造を使用します(ソース・システム、トランスフォーマ、ターゲット・データ・ウェアハウス)。
ソースからターゲットの1対1のマッピングを使用します。
ソース表ごとに1つのジョブを定義します。
汎用ジョブ構造およびテンプレート・ジョブを適用して、迅速な開発および一貫性を考慮します。
最適化されたジョブ設計を使用して、データ量に基づいてOracleロード・パフォーマンスを利用します。
パラメータ化されたジョブを設計して、ジョブのパフォーマンスおよび動作の高度な制御を考慮します。
ジョブのパラレル実行を最大化します。
使用しているETLツールまたは開発したマッピング・スクリプトは、ステータスおよびエラー処理表を生成します。
一般的な原則として、すべてのETLがステータスおよびエラーを表に記録します。ETLツールを使用するか、ログ表に直接問い合せて、実行ステータスを監視します。
マッピング・スクリプトを開発してステージング・レイヤーにロードするか、基盤レイヤーに直接ロードするかに関係なく、最も効率的な方法でデータをウェアハウスに格納することが目標です。ロード中の優れたパフォーマンスを実現するには、ロードするデータの場所およびデータベースにロードする方法から開始する必要があります。たとえば、シリアル・データベース・リンクまたは単一のJDBC接続を使用して、大量のデータを移動しないようにする必要があります。大量のデータをロードする最も一般的な推奨メカニズムは、フラット・ファイルからのロードです。
次のトピックでは、効率的なSource-ETLロードを保証するベスト・プラクティスについて説明します。
データ・ウェアハウス・システムのステージング・レイヤーにロードされる前にフラット・ファイルが格納される領域は、一般的にステージング領域と呼ばれます。ロードの全体の速度は、次の要素で決定されます。
ステージング領域からRAWデータを読み取ることができる速度。
RAWデータを処理してデータベースに挿入できる速度。
推奨: ステージング領域の使用
生データはできるだけ多くの物理ディスクにステージングし、生データの読取りがロード時のボトルネックにならないようにします。
また、Exadata Database Machineを使用している場合、データをステージングする最適な場所は、Exadataストレージ・セルに格納されているOracle Database File System(DBFS)内です。DBFSは、データベースに格納されたファイルへのアクセスに使用できるマウント可能なクラスタ・ファイル・システムを作成します。Database Machineの別のデータベースにDBFSを作成します。これにより、データ・ウェアハウスとは別にDBFSを管理および保守できます。
DIRECT_IOオプションを使用してファイル・システムをマウントし、ファイル・システムのRAWデータ・ファイルの移動中のシステム・ページ・キャッシュのスラッシングを回避します。
|
参照: DBFSの設定の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。 |
データ・ロードをパラレル化するには、OracleデータベースでRAWデータ・ファイルをグラニュルと呼ばれるチャンクに論理的に分割できる必要があります。バランスのとれたパラレル処理を保証するため、通常グラニュルの数は、パラレル・サーバー・プロセスの数よりも非常に多くなります。特定の時点で、処理する1つのグラニュルにパラレル・サーバー・プロセスが割り当てられます。パラレル・サーバー・プロセスがグラニュルの処理を完了した後、すべてのグラニュルが処理されてデータがロードされるまで、別のグラニュルが割り当てられます。
推奨: Source-ETLのRAWデータ・ファイルの準備
次の推奨事項に従います。
改行やセミコロンなどの認識される文字を使用して、各行を区切ります。これにより、単一のファイル内に複数のグラニュルを作成するためにRAWデータ・ファイル内が参照され、各行のデータの開始場所および終了場所が決定されます。
ファイルが配置可能および検索可能(たとえば、圧縮ファイル、ZIPファイルなど)ではない場合、ファイルをグラニュルに分割できません。ファイル全体が単一のグラニュルとして処理されます。この場合、1つのパラレル・サーバー・プロセスのみ、ファイル全体で使用できます。圧縮されたデータ・ファイルのロードをパラレル化するには、複数の圧縮されたデータ・ファイルを使用します。使用される圧縮されたデータ・ファイルの数は、ロードで使用される最大の並列度を決定します。
複数のデータ・ファイルをロードする場合(圧縮または非圧縮)
可能な場合、単一の外部表を使用します。
ファイルのサイズを同じにします。
ファイルのサイズを10MBの倍にします。
異なるサイズのファイルを使用する必要がある場合、最大から最小までファイルをリストします。デフォルトでは、フラット・ファイルがデータベースと同じキャラクタ・セットであると想定します。該当しない場合、外部表定義のフラット・ファイルのキャラクタ・セットを指定して、適切なキャラクタ・セット変換を実行できることを確認します。
Oracleは、複数のデータ・ロード・オプションを提供します。
外部表またはSQL*Loader
Oracle Data Pump(インポートおよびエクスポート)
Change Data CaptureおよびTrickleフィード・メカニズム(Oracle Golden Gateなど)
システムおよびメインフレームを開くOracle Database Gateways
Generic Connectivity(ODBCおよびJDBC)
実行するアプローチは、受信するデータのソースおよび形式に依存します。
推奨: フラット・ファイルのロード
ファイルからOracleにロードする場合、2つのオプション、SQL*Loaderまたは外部表を使用します。
外部表を使用すると、次の利点があります。
データベース内の透過的なパラレル化を実行できます。ステージング・データを回避して、外部表にアクセスする場合に任意のSQLまたはPL/SQL構成を使用してファイル・データに直接変換を適用できます。SQL Loaderでは、データをそのままデータベースに最初にロードする必要があります。
外部表のロードをパラレル化すると、個々のパラレル・ローダーが固有のトランザクションを使用した個別のデータベース・セッションであるSQL*Loaderよりも効率的な領域管理を実行できます。多くパーティション化した表の場合、多くの未利用領域が発生する可能性があります。
標準のCREATE TABLE文を使用して、外部表を作成できます。ただし、フラット・ファイルからロードするには、データベース外部のフラット・ファイルの場所の情報を文に含める必要があります。外部表からデータをロードする場合の最も一般的なアプローチは、CREATE TABLE AS SELECT (CTAS)文またはINSERT AS SELECT (IAS)文を既存の表に発行することです。
ダイレクト・パス・ロードは、外部表定義の説明に従って入力データを解析し、各入力フィールドのデータを対応するOracleデータ・タイプに変換して、データの列配列構造を作成します。これらの列配列構造を使用して、Oracleデータ・ブロックをフォーマットし、索引キーを作成します。新しくフォーマットされたデータベース・ブロックはデータベースに直接書き込まれるため、標準SQL処理エンジンおよびデータベース・バッファ・キャッシュが省略されます。
優れたロード・パフォーマンスの秘訣は、可能なかぎりダイレクト・パス・ロードを使用することです。
CREATE TABLE AS SELECT (CTAS)文は、常にダイレクト・パス・ロードを使用します。
単純なINSERT AS SELECT (IAS)文は、ダイレクト・パス・ロードを使用しません。IAS文でダイレクト・パス・ロードを実現するには、APPENDヒントをコマンドに追加する必要があります。
ダイレクト・パス・ロードはパラレルでも実行できます。ダイレクト・パス・ロードの並列度を設定するには、次のいずれかを実行します。
PARALLELヒントをCTAS文またはIAS文に追加します。
外部表およびデータをロードする表にPARALLEL句を設定します。
並列度の設定後:
CTAS文は、パラレルのダイレクト・パス・ロードを自動的に実行します。
IAS文は、パラレルのダイレクト・パス・ロードを自動的に実行しません。IAS文でパラレルのダイレクト・パス・ロードを有効にするには、次の文を実行して、セッションを変更してパラレルDMLを有効にする必要があります。
alter session enable parallel DML;
パーティション化の利点は、EXCHANGE PARTITIONコマンドを使用してビジネス・ユーザーの影響を最小限にデータを迅速かつ容易にロードする機能です。EXCHANGE PARTITIONコマンドは、パーティション化されていない表のデータをパーティション化された表の特定のパーティションにスワップできます。EXCHANGE PARTITIONコマンドは物理的にデータを移動しません。かわりに、データ・ディクショナリを更新してパーティションおよび表のポインタを交換します。
データの物理的な移動がないため、交換はREDOおよびUNDOを生成しません。つまり、交換は1秒以内の処理で、INSERTなどの従来のデータ移動アプローチよりもパフォーマンスへの影響が大幅に少なくなります。
推奨: 表のパーティション化
Oracle Airlines Data Modelウェアハウスの大きい表およびファクト表をパーティション化します。
例4-1 パーティション表でのパーティション交換文の使用
日単位でレンジ・パーティション化されるDWB_PNR_Hという大きい表があるとします。各営業日の最後に、オンライン航空会社システムのデータがウェアハウスのDWB_PNR_H表にロードされます。
次の手順により、日単位のデータがデータ・ウェアハウスのビジネス・ユーザーへの影響を最小限に最適な速度で正しいパーティションにロードされます。
オンライン・システムから取得するフラット・ファイル・データの外部表を作成します。
CTAS文を使用して、DWB_PNR_H表と同じ列構造を持つtmp_pnrというパーティション化されていない表を作成します。
tmp_pnr表のDWB_PNR_H表の索引を作成します。
EXCHANGE PARTITIONコマンドを発行します。
Alter table dwb_pnr_h exchange partition SYS_P1926 with table tmp_pnr including indexes without validation;
増分統計を使用して、新しく交換したパーティションのオプティマイザ統計を収集します。
この例のEXCHANGE PARTITIONコマンドは、名前が付いたパーティションおよびtmp_pnr表の定義をスワップするので、パーティション表の正しい場所にデータがすぐに配置されます。また、INCLUDING INDEXESおよびWITHOUT VALIDATION句を使用すると、索引の定義をスワップし、データが実際にパーティションに属するかどうかを確認しないため、交換が非常に迅速になります。
|
注意: この例の想定では、データの整合性がデータ抽出時間に確認されました。データの整合性がわからない場合、データベースでデータの妥当性を確認するため、WITHOUT VALIDATION句を省略します。 |
Intra-ETLは、Oracle Airlines Data Modelのコンポーネントとして提供されています。このIntra-ETLは、PKG_INTRA_ETL_PROCESSという名前のPL/SQLパッケージとして提供され、これは、アクセス・レイヤーに移入するプロシージャを持つ完全なIntra-ETLプロセスです。
PKG_INTRA_ETL_PROCESSパッケージは、個別のサブプロセス・プロシージャ、および各個別のプログラムの依存性を順守する機能で構成されます。主要なプロシージャは次の順序で実行されます。
Populate_Dimension: 参照表(DWR_)の内容に基づいて、ディメンション表(DWM_)に移入します。
Populate_Derived: 実表(DWB_)の内容に基づいて、導出表(DWD_)に移入します。
Populate_Aggregate: ディメンション表(DWM_)および導出表(DWD_)のデータを使用して、集計表(DWA_)のすべてをリフレッシュします。
Populate_Aw: Oracle Airlines Data Modelの集計表(DWA_)のデータをOracle Airlines Data Model Analytical Workspaceにロードし、予測データを計算します。DWC_OLAP_ETL_PARM表からOLAP ETLパラメータを読み取ります。
Populate_MINING: データ・マイニング・モデルをトリガーします。
PKG_INTRA_ETL_PROCESSパッケージは、デフォルトのOracle Airlines Data Modelで動作するように設計されています。モデルをカスタマイズしている場合は、Intra-ETLもカスタマイズする必要があります。Oracle Airlines Data Modelに提供されているIntra-ETLをカスタマイズするには、次の手順に従います。
PKG_INTRA_ETL_PROCESSパッケージの内容をよく理解します。特に、『Oracle Airlines Data Modelリファレンス』に記載されているプロシージャ、データ・フローおよびマップについて、ならびにプロシージャでDWC_ETL_PARAMETERとDWC_OLAP_ETL_PARM制御表、およびDWC_INTRA_ETL_PROCESSとDWC_INTRA_ETL_ACTIVITY制御表がどのように使用されるかについて理解します。次のトピックを確認してください: 「アクセス・レイヤーの初期ロードの実行」、「Oracle Airlines Data Modelウェアハウスのアクセス・レイヤーのリフレッシュ」、および「Oracle Airlines Data Model Intra-ETLの実行中のエラー管理」。
Oracle Airlines Data Modelに行った変更、およびそれらのモデル変更をサポートするためにIntra-ETLに行う必要のある変更を特定します。
変更する必要があるパッケージのコピーを作成します。コピーには別の名前を指定してください。
ステップ2で特定した変更を、ステップ3で作成したパッケージに行います。
オプションとして、独自のPL/SQLコードを記述するか、Oracle Warehouse BuilderなどのETLツールを使用して、新しいIntra-ETLを最初から作成できます。
Oracle Airlines Data Modelの初期ロードの実行は、複数ステップのプロセスです。
「基盤レイヤーの初期ロードの実行」の説明に従って、Oracle Airlines Data Modelウェアハウスの基盤レイヤー(つまり、参照表、検索表および実表)をロードします。
「アクセス・レイヤーの初期ロードの実行」の説明に従って、Oracle Airlines Data Modelウェアハウスのアクセス・レイヤー(つまり、導出表および集計表、導出表と集計表のディメンションを提供する表、マテリアライズド・ビュー、OLAPキューブおよびデータ・マイニング・モデル)をロードします。
作成したSource-ETLを使用して、基盤レイヤーの初期ロードを実行します。このETLの作成の詳細は、「Oracle Airlines Data Modelウェアハウスの基盤レイヤーのETL」を参照してください。
Oracle Airlines Data Modelウェアハウスのアクセス・レイヤー(導出表、集計表、マテリアライズド・ビュー、OLAPキューブおよびデータ・マイニング・モデル)の初期ロードを実行するには、次の手順に従います。
oadm_sysスキーマ内のDWC_ETL_PARAMETER制御表のパラメータを更新して、この情報(ETL期間の開始日と終了日)をアクセス・レイヤーへのデータのロード時にETLで使用できるようにします。
Oracle Airlines Data Modelウェアハウスの初期ロードでは、次の表に示す値を指定します。
| 列 | 値 |
|---|---|
PROCESS_NAME |
'OADM-INTRA-ETL' |
FROM_DATE_ETL |
ETL期間の開始日。 |
TO_DATE_ETL |
ETL期間の終了日。 |
|
参照: DWC_ETL_PARAMETER制御表の詳細は、『Oracle Airlines Data Modelリファレンス』を参照してください。 |
oadm_sysスキーマ内のDWC_OLAP_ETL_PARM制御表のOracle Airlines Data Model OLAP ETLパラメータを更新して、構築メソッドおよびその他の構築特性を指定し、この情報をOLAPキューブ・データのロード時にETLで使用できるようにします。
分析ワークスペースの初期ロードの場合は、表4-1のガイドラインに従って値を指定します。
表4-1 初期ロード用のDWC_OLAP_ETL_PARM表のOracle Airlines Data Model OLAP ETLパラメータの値
| 列名 | 値 |
|---|---|
|
|
|
|
|
|
|
|
構築するキューブを指定する次の値のいずれか。
|
|
|
このジョブに割り当てるパラレル・プロセス数を指定する10進値。(デフォルト値は |
|
|
予測キューブを計算するかどうかに応じて、次のいずれかの値。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
「デフォルトのOracle Airlines Data ModelのIntra-ETLの実行」で説明している方法の1つを使用して、Intra-ETLを実行します。
Oracleクライアント・ツール(SQL Plusなど)から次の文を発行して、PKG_INTRA_ETL_PROCESSプロセス・フローを実行します。
EXEC PKG_INTRA_ETL_PROCESS.RUN( )
PKG_INTRA_ETL_PROCESSによって実行されるPL/SQLコード:
適切な順序でマッピングを実行する前に、oadm_sysスキーマ内のDWC_ETL_PARAMETERおよびDWC_OLAP_ETL_PARM制御表から値を読み取ります。
各表のロードの結果は、DWC_INTRA_ETL_PROCESSおよびDWC_INTRA_ETL_ACTIVITY制御表で追跡されます。
Oracleクライアント内からPKG_INTRA_ETL_PROCESSを実行すると、プロセスの実行を監視する機能が提供されます。ただし、PKG_INTRA_ETL_PROCESS PL/SQLパッケージ内のRUNプロシージャを単純に実行できます。
どちらの場合でも、Intra-ETLを明示的に実行したり、他のプログラムまたはプロセス(たとえば、正常な実行の後のSource-ETLプロセスなど)または事前定義済のスケジュール(たとえば、Oracle Job Scheduling機能の使用など)で実行を起動したりできます。
「アクセス・レイヤーの初期ロードの実行」では、Oracle Airlines Data Modelデータ・ウェアハウスの初期ロードの実行方法について説明しています。この初期ロードの後に、ビジネス分析を容易にするという目的を満たせるように、Oracle Airlines Data Modelデータ・ウェアハウスに新規データを定期的にロードする必要があります。
Oracle Airlines Data Modelウェアハウスに新規データをロードするには、1つ以上の業務系システムからデータを抽出し、そのデータをウェアハウスにコピーする必要があります。データ・ウェアハウス環境では、多数のシステムにわたる大量のデータを統合、再配置および連結し、結果として、統一された新たな情報ベースをビジネス・インテリジェンスに提供することが課題になります。
継続的なロードおよび変換は、特定の順序でスケジュールして処理する必要があり、ビジネス・ニーズによって決定されます。操作または操作の一部が成功したか失敗したかに応じて、結果を追跡する必要があります。また、場合によっては後続の代替プロセスを開始できます。
Oracle Airlines Data Modelウェアハウスの完全増分ロードを実行するか、データを順次にリフレッシュできます。
どちらの場合でも、「Oracle Airlines Data ModelのIntra-ETL実行中のエラーの管理」の説明に従って、Intra-ETLの実行中のエラーを管理できます。
Oracle Warehouse Builderまたは別のETLツールを使用して書き込まれたSource-ETLスクリプトを使用して、基盤レイヤーをリフレッシュします。Source-ETLの作成の詳細は、「Oracle Airlines Data Modelウェアハウスの基盤レイヤーのETL」を参照してください。
Oracle Airlines Data Modelのアクセス・レイヤーのリフレッシュは、複数ステップのプロセスです。「デフォルトのOracle Airlines Data ModelのIntra-ETLの実行」の説明に従ってPKG_INTRA_ETL_PROCESSパッケージを実行することでアクセス・レイヤーの完全増分ロードを一度に実行するか、または、データを順次にリフレッシュできます。
どちらの場合でも、「Oracle Airlines Data ModelのIntra-ETL実行中のエラーの管理」の説明に従って、Intra-ETLの実行中のエラーを管理できます。
Oracle Airlines Data Modelの基盤レイヤーをリフレッシュした後。次の手順を実行して、Oracle Airlines Data Modelのアクセス・レイヤーのリレーショナル表およびビューのみをリフレッシュできます。
oadm_sysスキーマ内のDWC_ETL_PARAMETER制御表のパラメータを更新します。Oracle Airlines Data Modelウェアハウスの増分ロードの場合は、次の表で示す値を指定します(ETL期間の開始日と終了日)。
| 列 | 値 |
|---|---|
PROCESS_NAME |
'OADM-INTRA-ETL' |
FROM_DATE_ETL |
ETL期間の開始日。 |
TO_DATE_ETL |
ETL期間の終了日。 |
|
参照: DWC_ETL_PARAMETER制御表の詳細は、『Oracle Airlines Data Modelリファレンス』を参照してください。 |
「デフォルトのOracle Airlines Data ModelのIntra-ETLの実行」で説明しているPKG_INTRA_ETL_PROCESS PL/SQLパッケージ内の次のプロシージャを実行して、表をリフレッシュします。次の順序でプロシージャを実行します。
Populate_Dimension
Populate_Derived
Populate_Aggregate
スケジュールに基づいて、OLAPキューブの初期ロード以降にOracle Airlines Data Modelデータ・ウェアハウスに追加されたリレーショナル・データでOLAPキューブ・データを更新する必要があります。
Oracle Airlines Data Modelウェアハウス内のOLAPキューブ・データのみをリフレッシュするには、次の手順を実行します。
基礎となる集計表がリフレッシュされることを確認します。詳細は、「Oracle Airlines Data Modelのアクセス・レイヤーのリレーショナル表のリフレッシュ」を参照してください。
PKG_INTRA_ETL_PROCESS.Populate_Awプロシージャを実行して、キューブ・データをロードします。
必要に応じて、次の手順を実行して、Populate_Awの実行中に発生するエラーからリカバリします。
DWC_OLAP_ETL_PARM表のBUILD_METHOD列の値を"C"に変更します。
PKG_INTRA_ETL_PROCESS.Populate_Awを再実行します。
PKG_INTRA_ETL_PROCESS.Populate_Miningプロシージャは、ウェアハウスの初期ロードの一部としてデータ・マイニング・モデルのリフレッシュメントをトリガーします。ウェアハウスの初期ロード後に、データ・マイニング・モデルを毎月リフレッシュすることをお薦めします。
OLAPキューブをリフレッシュした後、データ・マイニング・モデルもリフレッシュできます。この場合、データ・マイニング・モデルをリフレッシュする方法は、すべてのデータ・マイニング・モデルまたは1つのデータ・マイニング・モデルのみをリフレッシュするかどうかによって異なります。
すべてのデータ・マイニング・モデルを手動でリフレッシュするには、次のプロシージャをコールします。
oadm_sys.pkg_oadm_mining.refresh_model(p_month_code,p_process_no)
このプロシージャは、各データ・マイニング・モデルで次のタスクを実行します。
oadm_sysスキーマの最新データに基づいてデータ・マイニング・モデルのソース・マテリアライズド・ビューをリフレッシュします。
新しいトレーニング・データで各データ・マイニング・モデルをトレーニングします。
各データ・マイニング・モデルを新規適用データ・セットに適用します。
1つのデータ・マイニング・モデルのみ手動で再作成するには、対応するoadm_sys.pkg_oadm_mining.create_プロシージャをコールします。
たとえば、顧客生涯価値回帰データ・マイニング・モデルを再作成するには、次のプロシージャをコールします。
oadm_sys.pkg_oadm_mining.create_cust_ltv_svm_rgrsn(p_month_cd);
「チュートリアル: 顧客生涯価値予測データ・マイニング・モデルのカスタマイズ」に、単一のデータ・マイニング・モデルをリフレッシュする詳細な手順を示します。
このトピックでは、Intra-ETL実行中のエラーを識別および管理する方法について説明します。この付録には、次の項があります。
Intra-ETLプロセスの実行は、2つのoadm_sysスキーマ制御表DWC_INTRA_ETL_PROCESSおよびDWC_INTRA_ETL_ACTIVITYによって監視されます。これらの表については、『Oracle Airlines Data Modelリファレンス』に記載されています。
個々のPKG_INTRA_ETL_PROCESSパッケージの通常の実行では、(エラー・リカバリ実行ではなく)次の手順を実行します。
単調に増加するシステム生成の一意のプロセス・キー、プロセス開始時刻としてのSYSDATE、プロセス・ステータスとしてのRUNNING、およびフィールドFROM_DATE_ETLとTO_DATE_ETLの入力日範囲で、DWC_INTRA_ETL_PROCESS表にレコードを挿入します。
適切な依存性の順序で各PKG_INTRA_ETL_PROCESSプロシージャが起動されます。各プログラムの起動前に、システム生成の一意のアクティビティ・キー、Intra-ETLプロセスに対応するプロセス・キー値、Activity Nameに個々のプログラム名、適切なアクティビティの説明、アクティビティ開始時間にSYSDATE、アクティビティ・ステータスにRUNNINGが指定されたレコードがIntra-ETLアクティビティ・ディテール表DWC_INTRA_ETL_ACTIVITYに挿入されます。
個々のETLプログラムが(正常にまたはエラーを戻して)完了するたびに、DWC_INTRA_ETL_ACTIVITY表内の対応するレコードのアクティビティ終了時間およびアクティビティ・ステータスが更新されます。アクティビティが正常に完了した場合、プロシージャはステータスを'COMPLETED-SUCCESS'として更新します。エラーが発生した場合は、アクティビティ・ステータスが'COMPLETED-ERROR'に更新され、ERROR_DTL列内の対応するエラーの詳細も更新されます。
すべての個々のIntra-ETLプログラムが完了した後、DWC_INTRA_ETL PROCESS表内のプロセスに対応するレコードのプロセス終了時間およびステータスが更新されます。すべての個々のプログラムが成功した場合、プロシージャは'COMPLETED-SUCCESS'にステータスを更新し、それ以外の場合は'COMPLETED-ERROR'にステータスを更新します。
最大プロセス・キーに対応するDWC_INTRA_ETL_PROCESSおよびDWC_INTRA_ETL_ACTIVITY表の内容を表示することで、現在のプロセス進行状況、個々のプログラムに要した時間、完了プロセスなど、Intra-ETLの実行状態を監視できます。監視は、Intra-ETLプロシージャの実行中および実行後に行うことができます。
PKG_INTRA_ETL_PROCESSパッケージの実行をリカバリするには、次の手順を実行します。
DWC_INTRA_ETL_ACTIVITY表の個々のプログラムに対して追跡されているエラー詳細を参照することでエラーを識別します。
エラーの原因を修正します。
PKG_INTRA_ETL_PROCESSパッケージを再実行します。
PKG_INTRA_ETL_PROCESSパッケージのプロシージャは、DWC_INTRA_ETL_ACTIVITY表を参照することで通常の実行かリカバリ実行かを識別します。リカバリの実行中、PKG_INTRA_ETL_PROCESSは、リカバリに必要なプロシージャのみを実行します。たとえば、前回の実行の一部として導出移入エラーが発生した場合、このリカバリ実行は、前回の実行でエラーを生成した個々の導出移入プログラムを実行します。正常完了後に、集計移入プログラムとマテリアライズド・ビューのリフレッシュが適切な順序で実行されます。
このように、Intra-ETLエラー・リカバリはほとんど透過的であり、データ・ウェアハウス管理者またはETL管理者は関与しません。管理者は、エラーの原因を修正して、PKG_INTRA_ETL_PROCESSパッケージを再起動するだけです。PKG_INTRA_ETL_PROCESSが、エラーを生成したプログラムを識別して実行します。
Intra-ETLのパフォーマンスをトラブルシューティングする手順は、次のとおりです。
「実行計画のチェック」の説明に従って、実行計画をチェックします。
「PARALLEL DML実行の監視」の説明に従って、パラレルDML実行を監視します。
「データ・マイニング・モデルの作成のトラブルシューティング」の説明に従ってデータ・マイニング・モデルが正しく作成されていることを確認します。
SQLDeveloperまたはその他のツールを使用して、Oracle Warehouse Builderで生成されたコードのパッケージ本体を表示します。
たとえば、マップを調べるには、次の手順に従います。
コード・ビューアからメインの問合せ文をコピーします。
"CURSOR "AGGREGATOR_c" IS …."から、別の"CURSOR "AGGREGATOR_c$1" IS"のすぐ上にある問合せの終了までコピーします。
SQLDeveloperワークシートで、次の文を発行してパラレルDMLをオンにします。
Alter session enable parallel dml;
メインの問合せ文を別のSQL Developerワークシートに貼り付け、F6をクリックして実行計画を表示します。
実行計画を慎重に調べて、有効な計画に従ってマッピングを実行します。
次のSQL文を実行して、実行された"Parallel DML/Query"文をカウントすることで、マッピングをパラレル・モードで実行していることを確認します。
column name format a50 column value format 999,999 SELECT NAME, VALUE FROM GV$SYSSTAT WHERE UPPER (NAME) LIKE '%PARALLEL OPERATIONS%' OR UPPER (NAME) LIKE '%PARALLELIZED%' OR UPPER (NAME) LIKE '%PX%' ;
マッピングをパラレル・モードで実行する場合は、マッピングが呼び出されるたびに"DML statements parallelized"が1つ増やされます。この増分が表示されない場合は、マッピングが"パラレルDML"として呼び出されていません。
かわりに"queries parallelized"が1つ増やされている場合は、通常、INSERTの内部のSELECT文はパラレル化されていますが、そのINSERT自体はパラレル化されていないことを意味します。
データ・マイニング・モデルが作成された後で、oadm_sys.dwc_intra_etl_activity表内のエラー・ログをチェックします。たとえば、次のコードを実行します。
set line 160 col ACTIVITY_NAME format a30 col ACTIVITY_STATUS format a20 col error_dtl format a80 select activity_name, activity_status, error_dtl from dwc_intra_etl_activity;
すべてのモデルが正常に作成されている場合、activity_statusはすべて"COMPLETED-SUCCESS"になります。特定のステップのactivity_statusが"COMPLETED-ERROR"の場合は、ERROR_DTL列をチェックし、問題を適宜修正します。
次の例で、Oracle Airlines Data Modelを操作する場合にERROR_DTLおよびACTIVITY_NAMEで戻される一般的なエラー・メッセージのトラブルシューティング方法を示します。
例4-2 メッセージはありません... [言語=ZHS]エラーのトラブルシューティング
戻されるエラーがメッセージはありません... [言語=ZHS]とします。
'ZHS'は言語のコードです。関連する言語名は、データベース環境に応じて異なる名前で表示されることがあります。このエラーは、oadm_sys.DWC_MESSAGE.LANGUAGEに現在の言語用のメッセージが含まれていない場合に発生します。
DWC_MESSAGE表の値をチェックし、必要に応じて、Oracleセッション変数USERENV('lang')で指定されている言語コードに更新します。
例4-3 ORA-40112のトラブルシューティング: 有効なデータ行数が不足しています
戻されるエラーが"create_cust_ltv_svm_rgrsn"モデルに対するORA-40112: 有効なデータ行数が不足していますとします。
このモデルでは、ターゲット列はoadm_sys.dmv_cust_ltv_src.tot_cpn_amtです。
このエラーをトラブルシューティングする手順は、次のとおりです。
次のSQL文を実行します。
SELECT count(tot_cpn_amt) FROM dmv_cust_ltv_src; SELECT count(frqtflr_card_key) FROM dmv_cust_ltv_src;
前述の2つの問合せで戻される値が、0(ゼロ)以上であることを確認します。最初のSELECT文で戻される値が、2番目のSELECT文で返される値よりも小さい場合、dmv_cust_ltv_srcのソース表およびマテリアライズド・ビューを確認します。
例4-4 ORA-40113のトラブルシューティング: 個別ターゲット値の数が不足しています
戻されるエラーが"create_ffp_pred_svm"モデルに対するORA-40113: 個別ターゲット値の数が不足していますとします。2クラス分類モデルの場合、ターゲット列には2つの個別の値が必要です。このエラーは、トレーニング・モデルのターゲット列に2つの値が期待されている場合に、1つの値のみ含まれているか、値が含まれていない場合に発生します。
たとえば、利用頻度の低い乗客の中での利用頻度の高い乗客予測svmモデルの場合、ターゲット列はoadm_sys.dmv_ffp_pred_src.ff_indとなります。
このエラーをトラブルシューティングする手順は、次のとおりです。
SQL問合せを実行して、この列に十分な値があるかどうかを確認します。利用頻度の高い乗客予測svmモデルを例として使用し、次の文を発行します。
SELECT ff_ind, count(*) FROM dmv_ffp_pred_src GROUP BY ff_ind;
問合せの結果を次に示します。
FF_IND COUNT(*)
------ --------
1 1296
0 990
次の問合せを発行して、次の表に利用頻度の高い乗客および利用頻度の低い乗客の両方が存在することを確認します。
SELECT NVL2(frqtflr_nbr,'FFP','Non_FFP') AS ffp_ind, count(*) FROM oadm_sys.dwd_bkg_fact GROUP BY NVL2(frqtflr_nbr,'FFP','Non_FFP');
この問合せの結果を次に示します。
FFP_IND COUNT(*) ------- -------- Non-FFP 77353 FFP 42647
次の文を実行して、マイニング・ソース・マテリアライズド・ビューをリフレッシュします。
exec pkg_oadm_mining.refresh_mining_source;
