| Oracle® Warehouse Builderデータ・モデリング、ETLおよびデータ・クオリティ・ガイド 11gリリース2 (11.2) B61350-02 |
|
 前 |
 次 |
この章は、パフォーマンス要件を満たすETLロジックを作成するためのガイドとして使用します。
この章の内容は次のとおりです。
このセクションでは、次の項目でPL/SQLマッピング設計を説明します。
Oracle Warehouse Builderでは、次の基準を満たすPL/SQLマッピングのコードが生成されます。
各演算子の出力コードは、その演算子の次のダウンストリーム演算子の入力コード要件を満たしている。
マッピングにPL/SQL出力のみを生成する演算子が含まれている場合は、すべてのダウンストリーム・データフロー演算子もPL/SQLによって実装可能である必要があります。このようなマッピングでのSQL演算子は、PL/SQL出力をターゲットにロードした後でのみ使用できます。
マッピングを設計する際に、マッピング内の各演算子の入力および出力コード・タイプを調べることで、マッピングの有効性を評価できます。
たとえば、図10-1のマッピングでは、Match Merge演算子MMはPL/SQL出力を生成しますが、後続のJoiner演算子はSQL入力のみを受け入れるため、無効であることがわかります。
マッピングが希望どおりの結果になるようにするには、Match Mergeを実行する前にソース表を結合するか、結合を実行する前にMatch-Mergeからステージング表に結果をロードすることを検討します。
図10-2は、Match-Merge演算前にソース表が結合されたマッピングを示しています。図10-3は、Match Merge演算子の結果が結合を実行する前にステージング表にロードされているマッピングを示しています。
表10-1および表10-2は、各Oracle Warehouse Builder演算子の実装タイプを示しています。これらの表は、PL/SQLコードにカーソルの演算子と関連付けられた演算があるかどうかも示しています。この情報は、特定のマッピング設計に有効なオペレーティング・モードを判断する際に使用します。また、エラー処理中に使用できる監査詳細の判断にも使用します。
表10-1 PL/SQLマッピングでのソースおよびターゲット演算子の実装
| 演算子 | 実装タイプ | セット・ベース・モードで有効か | 行ベース・モードで有効か | 行ベース(ターゲットのみ)で有効か |
|---|---|---|---|---|
|
ソース演算子: 表、ディメンション、キューブ、ビュー、外部表 |
SQL |
はい |
はい |
はい。カーソルの一部。 |
|
ターゲット演算子: 表、ディメンション、キューブ、ビュー |
SQL PL/SQL |
はい。ロードがUPDATEで、データベースが10gより前の場合を除く。 |
はい |
はい。カーソルの一部ではない。 |
|
ソースとしてのフラット・ファイル |
PL/SQLの場合は、外部表を作成。 |
はい |
はい |
はい。カーソルの一部。 |
|
ターゲットとしてのフラット・ファイル |
SQL |
はい。ロードがDELETEまたはUPDATEで、データベースが10gより前の場合を除く。 |
はい |
はい。カーソルの一部ではない。 |
|
ソースとしての順序 |
SQL |
はい |
はい |
はい。カーソルの一部。 |
表10-2 PL/SQLマッピングでのデータ・フロー演算子の実装
| 演算子名 | 実装タイプ | セット・ベース・モードで有効か | 行ベース・モードで有効か | 行ベース(ターゲットのみ)モードで有効か |
|---|---|---|---|---|
|
アグリゲータ |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
定数演算子 |
PL/SQL SQL |
はい |
はい |
はい |
|
データ・ジェネレータ |
SQL*Loaderのみ |
N/A |
N/A |
N/A |
|
デュプリケータ解除 |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
式 |
SQL PL/SQL |
はい |
はい |
はい |
|
フィルタ |
SQL PL/SQL |
はい |
はい |
はい |
|
ジョイナ |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
検索 |
SQL PL/SQL |
はい |
はい。「すべての行」オプションがLookup演算子の複数の一致行ページで選択されている場合は除く。 |
はい。「すべての行」オプションがLookup演算子の複数の一致行ページで選択されている場合は除く。 |
|
入力パラメータのマッピング |
SQL PL/SQL |
はい |
はい |
はい |
|
出力パラメータのマッピング |
SQL PL/SQL |
はい |
はい |
はい |
|
Match-Merge |
SQL入力 PL/SQL出力 (XREFグループからのPL/SQL入力のみ) |
いいえ |
はい |
はい。カーソルの一部ではない。 |
|
名前とアドレス |
PL/SQL |
いいえ |
はい |
はい。カーソルの一部ではない。 |
|
ピボット |
SQL PL/SQL |
はい |
はい |
はい |
|
マッピング後プロセス |
不適切 |
はい。データ・フローとは無関係。 |
はい |
はい |
|
マッピング前プロセス |
不適切 |
はい。データ・フローとは無関係。 |
はい |
はい |
|
集合 |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
ソーター |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部として。 |
|
スプリッタ |
SQL PL/SQL |
はい |
はい |
はい |
|
テーブル・ファンクション |
SQLまたはPL/SQL入力 SQL出力のみ |
はい |
はい |
はい |
|
プロシージャとしての変換 |
PL/SQL |
いいえ |
はい |
はい。カーソルの一部ではない。 |
|
DMLを実行しないファンクションとしての変換 |
SQL PL/SQL |
はい |
はい |
はい。カーソルに含まれる。 |
PL/SQL実装でのマッピングの場合は、次のオペレーティング・モードのうち1つを選択します。
セット・ベースから行ベースへのフェイルオーバー
セット・ベースから行ベース(ターゲットのみ)へのフェイルオーバー
選択するデフォルト・オペレーティング・モードは、期待するパフォーマンス、必要な監査データの量、マッピングの設計方法によって異なります。マッピングには、行ベースへのフェイルオーバー・モードのオプションを除いて、最低1つ、最高3つの有効なオペレーティング・モードがあります。コードの作成時には、指定したデフォルトのオペレーティング・モードと、選択していないモードのコードが生成されます。そのため、実行時には、デフォルト・オペレーティング・モードまたは他の有効なオペレーティング・モードのいずれかで実行するように選択できます。
マッピングでの演算子のタイプによって、選択可能なオペレーティング・モードが制限される場合があります。原則として、セット・ベース・モードで実行されるマッピングには、プロシージャとして使用されるMatch Merge、Name and Address、変換以外のすべての演算子を含めることができます。行ベース・モードおよび行ベース(ターゲットのみ)モードではすべての演算子を含めることができますが、Aggregator、JoinなどのSQLベースの演算子の使用方法には重要な制限があります。SQLベースの演算子を行ベース・モードのいずれかで使用するには、演算子と関連付けられた演算をカーソルに含めることができることを確認します。
これらの一般的なルールについては、次の各項で説明します。
セット・ベース・モードでは、すべてのデータを処理し、すべての演算を実行する単一のSQL文が生成されます。データをセットで処理するとパフォーマンスが向上しますが、使用できる監査情報は制限されます。ランタイム監査は、実行エラーのみの報告に制限されます。セット・ベース・モードでは、エラーを含む行は識別できません。
図10-4は、セット・ベースのオペレーティング・モードでの実行時に、マッピングのコード生成に使用される、単純なマッピングと関連ロジックを示しています。「TAB1」、「FLTR」および「TAB2」は、SQLを使用してセットとして処理されます。
セット・ベース・モードのマッピングを正確に設計するには、Match Merge演算子やName and Address演算子など、行ごとの処理を必要とする演算子を避けます。SQLで実行できないデータ・フローの演算子を含めた場合、セット・ベース・コードは生成されず、セット・ベース・モードでのパッケージの実行時にエラーが表示されます。
マッピングのターゲット演算子の場合、ロード・タイプINSERT/UPDATEおよびUPDATE/INSERTはセット・ベース・モードでは常に有効です。UPDATEロードがセット・ベース・モードでサポートされるのは、Oracle Databaseが10g以上の場合のみです。セット・ベース・モードでは、DELETEロード・タイプもサポートされます。セット・ベースのマッピングで演算子を処理する方法の全リストは、表10-2を参照してください。
行ベース・モードでは、データを行ごとに処理する文が生成されます。SQLカーソルには、SELECT文があります。以降の文はすべてPL/SQLです。PL/SQLで実行されたすべての演算子については、ランタイム監査の全情報にアクセスできますが、カーソルで実行された演算については、限られた情報にのみアクセスできます。
図10-5は、行ベースのオペレーティング・モードでの実行時に、マッピングのコード生成に使用される、単純なマッピングと関連ロジックを示しています。「TAB1」はカーソルに含まれ、SQLを使用してセットとして処理されます。「FLTR」および「TAB2」は、PL/SQLを使用して行ごとに処理されます。
PL/SQLで実行できないSQLベースの演算子がマッピングに含まれている場合は、カーソル内の演算を使用したコード生成が試行されます。有効な行ベース・コードを生成するには、次のSQLベース演算子のいずれかを含めた場合はその演算がカーソルに含まれるようにマッピングを設計します。
集計
デュプリケータ解除
ジョイナ
検索
順序
集合
ソーター
前述の演算子をカーソルに含める場合は、PL/SQLコードを生成する演算子を直前に配置しないでください。つまり、行ベース・モードのマッピングに、プロシージャとして実装された変換、ソースとして使用されるフラット・ファイル、Match-Merge演算子、Name and Address演算子の直後に7つのSQLベース演算子のいずれかが含まれている場合、そのマッピングは実行できません。有効な設計を行うには、PL/SQLを生成する演算子とSQLベース演算子の間にステージング表を含めます。
行ベース(ターゲットのみ)モードでは、SELECT文のカーソルが生成され、そのカーソルにできるだけ多くの演算が含まれます。各ターゲットには、行が個別に挿入されます。PL/SQLで実行されたすべての演算子については、ランタイム監査の全情報にアクセスできますが、カーソルで実行された演算については、限られた情報にのみアクセスできます。このモードは、データの抽出と変換には高速のセット・ベース演算を使用するが、エラーが発生しやすいデータのロードで高度な監査機能が必要な場合に使用します。
図10-6は、行ベース(ターゲットのみ)のオペレーティング・モードでの実行時に、マッピングのコード生成に使用される、単純なマッピングと関連ロジックを示しています。「TAB1」および「FLTR」はカーソルに含まれ、SQLを使用してセットとして処理されます。「TAB2」は行ごとに処理されます。
行ベース(ターゲットのみ)モードは、行ベースのオペレーティング・モードと同じ制限をSQLベース演算子に加えます。また、複数ターゲットのマッピングの場合は、各ターゲットのカーソルでコードが生成されます。
|
注意: リリース11.2.0.3以降は、セット・ベースから行ベースへのフェイルオーバー機能は非推奨です。 |
Oracle Warehouse Builderでデータをコミットする主な方法は2つあります。データのコミットまたはロールバックは、マッピング設計に基づいて実行できます。「マッピング設計に基づいたデータのコミット」で説明するいずれかのコミット制御方法を使用します。
また、PL/SQLマッピングの場合は、マッピング設計とは無関係にデータをコミットまたはロールバックできます。「マッピング設計に依存しないデータのコミット」の説明に従って、プロセス・フローを使用してデータをコミットするか、独自の方法を作成します。
デフォルトでは、マッピング設計に基づいてデータがロードされ、自動的にコミットされます。PL/SQLマッピングの場合は、デフォルト設定を上書きして、Oracle Warehouse Builderでデータがコミットされる時期と方法を制御できます。マッピングでデータをコミットする方法には、次のオプションがあります。
自動: これはデフォルト設定で、すべてのマッピング・タイプに有効です。Oracle Warehouse Builderでは、マッピング設計に基づいてデータがロードされ、自動的にコミットされます。マッピングに複数ターゲットがある場合は、他のターゲットに関係なく、ターゲットごとに別々にコミットとロールバックが行われます。不規則にロードされた複数ターゲットの結果が、大きくない場合や相関関係にない場合は、自動コミットを使用します。
自動相関: 自動相関コミットは自動コミットの特殊タイプで、複数ターゲットのPL/SQLマッピングにのみ適用されます。Oracle Warehouse Builderでは、すべてのターゲットが集合的に考慮され、データはすべてのターゲット間で均一にコミットまたはロールバックされます。ソースのすべての行が、影響を受けるターゲットすべてに均一な影響を確実に与えることが重要な場合は、相関コミットを使用します。自動相関コミットの詳細は、「単一のソースから複数ターゲットへのデータのコミット」を参照してください。
手動: 手動コミット制御を選択するのは、複雑なビジネス・ロジックを示したり、検証を実行したり、データのコミット前に他のマッピングを実行する必要のあるPL/SQLマッピングの場合です。例は、「マッピングへのコミット・ロジックの埋込み」および「マッピング設計に依存しないデータのコミット」を参照してください。
共通ソースに基づいて複数ターゲットを作成するには、ソースのすべての行がターゲットすべてに均一な影響を与えることを確認します。
図10-7は、このケースを示すPL/SQLマッピングです。ターゲット表はすべて、ソース表に依存しています。「SOURCE」の行によって、複数ターゲット(「TARGET_1」と「TARGET_2」など)が変更される場合、Oracle Warehouse Builderでは、影響を受ける両方のターゲットに対して適切なデータが同時にコミットされます。マッピングを再度実行したときにこの関係が維持されない場合、データは不正確になり、使用できなくなることもあります。
ソース表からの行数が比較的少ない場合、3つのターゲットを維持するのは難しくありません。ただし、共通ソースに依存するターゲットの手動による維持は、ソースからの行数を増加したり、より多くのターゲットと変換を持つさらに複雑なマッピングを設計する際に、手間がかかります。
ソースのすべての行がすべてのターゲットに正しく影響を与えていることを確認するには、相関コミット計画を使用するマッピングを構成します。
セット・ベース・モードでは、相関コミットがロールバック・セグメントのサイズに影響を与えます。データをマージ(insert/updateまたはupdate/insert)する際には、ロールバック・セグメントの空き領域が問題となる場合があります。
相関コミットは、PL/SQLバルク処理コードで透過的に操作されます。
相関コミット計画は、パーティション交換ロード用に構成されているモードで実行されるマッピングや、キュー、Match-Mergeまたはテーブル・ファンクション演算子を含むマッピングでは使用できません。
コミット計画とオペレーティング・モードの組合せによって、マッピング動作が決定されます。表10-3は、選択できる有効な組合せを示したものです。
表10-3 オペレーティング・モードの有効なコミット計画
| オペレーティング・モード | 自動相関コミット | 自動コミット |
|---|---|---|
|
セット・ベース |
有効(Valid) |
有効(Valid) |
|
行ベース |
有効(Valid) |
有効(Valid) |
|
行ベース(ターゲットのみ) |
適用不可 |
有効(Valid) |
相関コミットは、行ベース(ターゲットのみ)に対して適用できません。このオペレーティング・モードでは、カーソルをターゲットのできるだけ近くに配置するように定義されています。この結果、ほとんどの場合、各SELECT文に対するターゲットは1つのみとなり、複数ターゲットに対してデータをコミットする目的が失われます。行ベース(ターゲットのみ)と相関コミットの組合せでマッピングを設計した場合、マッピングは実行されますが、相関コミットは実行されません。
各オペレーティング・モードとコミット計画の組合せがマッピングに与える影響を理解するために、図10-7にあるマッピングについて考えてください。ソース表からのデータが1,000個の新規行であると仮定します。マッピングが正常に実行された場合は、各ターゲットに1,000行がロードされます。このマッピングでTarget__2への100番目の新規行のロードに失敗した場合は、コミット頻度や最大エラー数など他の構成設定からの影響を無視すると、次の結果が得られます。
セット・ベース/相関コミット: マッピングにエラーが1つでもあると、すべてのデータがロールバックされます。Target_2への挿入中にエラーが発生した場合、その表のエラーがレポートされ、行はロードされません。Target_1に挿入済のすべての行がロールバックされ、Target_3には行はロードされません。どのターゲット表にも行が追加されません。エラーの詳細には、Target_2へのロード中に発生したエラーのみがレポートされます。
行ベース/相関コミット: 各行が最初の行から個別に評価され、3つのターゲットすべてにロードされます。行のロードは、行100のTarget_2へのロード・エラーが発生するまで続行されます。Oracle Warehouse Builderによってエラーがレポートされ、行はロードされません。Target_1に挿入済の行100がロール・バックされ、Target_3には行100がロードされません。その後、Target_1への行101のロードが再開され、残りの行のロードが続行されます。他のエラーが発生しないと、各ターゲットに999個の新規行が挿入されて、マッピングが完了します。ソース行は、これらのターゲットに正確に反映されます。
セット・ベース/自動コミット: Target_2への挿入中にエラーが発生した場合、行はロードされず、その表のエラーがレポートされます。Target_3への行の挿入は続行されますが、Target_1の行はロールバックされません。他のエラーが発生しないと、Target_2に関する1つのエラー・メッセージがレポートされて、マッピングは完了します。Target_2に行は挿入されず、Target_1とTarget_3に1,000行ずつ挿入されます。ソース行は、これらのターゲットに正確に反映されません。
行ベース/自動コミット: 各行が最初の行から個別に評価され、ターゲットにロードされます。行のロードは、Target_2に行100をロードする際にエラーが発生し、そのエラーがレポートされるまで続行されます。Target_1の行100はロールバックされず、Target_3には行100が挿入されます。その後、残りの行のロードが続行されます。他のエラーが発生しないと、Target_2に999行が挿入されて、マッピングは完了します。他のターゲットには1,000行がそれぞれ挿入されます。ソース行は、これらのターゲットに正確に反映されません。
PL/SQLマッピングの場合のみ、SQL文でマッピング前またはマッピング後演算子を追加してデータをコミットおよびロールバックすることによって、コミット・ロジックをマッピング設計に埋め込むことができます。マッピングを実行すると、マッピング前プロセスまたはマッピング後プロセスの演算子に指定したSQL文のみに基づいて、データがコミットまたはロールバックされます。
Oracle Warehouse Builderの既存のマッピング演算子の設計に手間がかかったり、設計が不可能なビジネス・ルールを実装するには、次の手順を使用してください。たとえば、あるターゲットに1つの行が存在することを確認するとします。その場合は、必要なロジックをSQLで記述し、マッピング前またはマッピング後に演算子を使用してそのロジックをマッピングに導入します。
コミット・ロジックのマッピング設計への組込み手順:
マッピング前またはマッピング後演算子を含めるようにマッピングを設計します。いずれかの演算子を使用して、コミットおよびロールバックのSQL文を導入します。
「コミット制御」を「手動」に設定した状態で、マッピングを構成します。
プロジェクト・ナビゲータで、マッピングを右クリックし、「構成」を選択します。コード生成オプションの、 「コミット制御」で 「手動」を選択します。
手動によるデータのコミットを選択した場合の影響については、「手動コミット制御について」を参照してください。
マッピングを配布します。
マッピングを実行します。
マッピングは実行されますが、マッピング前プロセス演算子またはマッピング後プロセス演算子で記述したコミット・ロジックが処理されるまでデータはコミットされません。
次のいずれかの理由で、マッピング設計に依存せずにデータをコミットする必要が生じる場合があります。
データのコミット前に複数マッピングを実行: すべてのマッピングが正常に実行および検証されるまで、データをコミットしないまま、複数マッピングを実行する場合があります。たとえば、ディメンションのロードとキューブのロードに対して個別のマッピングがある場合です。
ターゲットの効率的な維持: 誤ったデータがロードされて非常に大きいターゲットにコミットされると、その障害の修復は困難で時間がかかる場合があります。回避するには、最初にデータをチェックし、次に、commitまたはrollbackコマンドを発行するかどうかを決定します。
これらの目的を実現するための最初の手順は、「コミット制御」を「手動」に設定してマッピングを構成することです。
手動コミット制御について
手動コミット制御を使用すると、マッピング設計に関係なく、Oracle Warehouse Builderでデータをコミットする時期を指定できます。手動コミット制御は監査統計に影響を与えません。これは、commitまたはrollbackコマンドを発行する前に、挿入済の行数およびその他の監査情報を表示できることを意味します。
手動コミットを使用するときは、このオプションがパフォーマンスに与える影響を考慮してください。ターゲットをロード後に読み込む必要がある設計では、パラレルに実行するマッピングがシリアルに実行される場合があります。これは、データを、リモート・ソースから移動する場合や同じ表にバインドされた2つのターゲットにロードする場合に発生します。
手動コミット制御を有効にすると、Oracle Warehouse Builderでは、PELがオフの状態でマッピングが実行されます。
この項では、マッピング設計に依存しないデータのコミットについて、2つの手順を説明します。最初の手順では、マッピングを実行してから、SQL*Plusセッションでデータをコミットする方法を説明します。この手順では、複数マッピングを実行してからデータをコミットする計画をテストしてデバッグします。次に、2番目の手順でその計画を自動化します。
両方の手順とも、各PL/SQLマッピングで生成されるメイン・プロシージャの使用を前提にしています。
メイン・プロシージャは、Oracle Warehouse Builderでマッピングを開始するためのロジックを公開するプロシージャです。このプロシージャは、PL/SQLスクリプトで使用したり、インタラクティブなSQL*Plusセッションで使用できます。
メイン・プロシージャを使用するときは、必須パラメータのp_statusを指定する必要があります。また、表10-4に示すように、マッピングの実行に関連する他のパラメータをオプションで指定できます。オプション・パラメータを指定しない場合、Oracle Warehouse Builderではデフォルト設定が使用されます。
表10-4 メイン・プロシージャのパラメータ
| パラメータ名 | 説明 |
|---|---|
|
p_status |
この必須パラメータを使用して、マッピングの完了時のステータスを記述します。このパラメータは、statusという事前定義済変数とともに機能します。 status変数は、たとえば、OKはマッピングがエラーなしで完了したことを示すように定義されています。OK_WITH_WARNINGSは、ユーザー・エラーが発生してマッピングが完了したことを示します。FAILUREは、マッピングでリカバリ不可能なエラーが発生したことを示します。 |
|
p_operating_mode |
このオプション・パラメータを使用して、SET_BASEDなどの「デフォルト・オペレーティング・モード」を渡します。 |
|
p_bulk_size |
このオプション・パラメータを使用して、「バルク・サイズ」を渡します。 |
|
p_audit_level |
このオプション・パラメータを使用して、COMPLETEなどの「デフォルト監査レベル」を渡します。 |
|
p_max_no_of_errors |
このオプション・パラメータを使用して、許容されている「エラーの最大数」を渡します。 |
|
p_commit_frequency |
このオプション・パラメータを使用して、「コミット頻度」を渡します。 |
PL/SQLマッピングの場合のみ、マッピングを実行して、SQL*Plusセッションからcommitおよびrollbackコマンドを発行できます。SQL*Plusに関する知識とメイン・プロシージャに基づいて、データのコミット前に複数のマッピングを手動で実行して検証できます。
実行時における手動でのデータ・コミット手順:
PL/SQLマッピングを設計します。たとえば、ディメンションをロードするためのマッピングを作成し、キューブをロードするための別のマッピングを作成します。
ここで説明する手順は、SQL*LoaderマッピングおよびABAPマッピングには該当しません。
「コミット制御」パラメータを「手動」に設定した状態で、両方のマッピングを構成します。
プロジェクト・ナビゲータで、マッピングを右クリックし、「構成」を選択します。コード生成オプションで、 「コミット制御」パラメータを「手動」に設定します。
各マッピングを生成します。
SQL*Plusセッションから次のコマンドを発行して、最初のマッピング(この例ではmap1)を実行します。
var status VARCHAR2(30); execute map1.main(:status);
最初の行では、表10-4で説明している事前定義済のstatus変数を宣言します。2行目では、p_statusがstatus変数に設定されます。map1が完了すると、SQL*Plusによって、OKなどのマッピング・ステータスが表示されます。
2番目のマッピングであるキューブ・マッピング(この例ではmap2)を実行します。
2番目のマッピングは前のマッピングと同じ方法で実行できます。または、表10-4に示す追加パラメータを指定して、この例のmap2の実行方法を指定することもできます。
map2.main (p_status => :status, \
p_operating_mode => 'SET_BASED', \
p_audit_level => 'COMPLETE');
2つのマッピングの実行結果を確認して、commitコマンドまたはrollbackコマンドのいずれかを送信します。
「プロセス・フロー・エディタを使用したマッピングのコミット」の手順に従って、コミット計画を自動化します。
PL/SQLマッピングの場合のみ、複数のマッピングをコミットまたはロールバックできます。Sqlplusアクティビティ、メイン・プロシージャおよびPL/SQLスクリプトの記述方法に関する知識に基づいて、プロセス・フローを使用すると、すべてのマッピングが正常に完了した後、またはマッピングに失敗した場合のデータのロールバック後にデータをコミットするロジックを自動化できます。
プロセス・フローを使用した複数のマッピングのコミット手順:
PL/SQLマッピングを設計します。
ここで説明する手順は、SQL*LoaderマッピングおよびABAPマッピングには該当しません。
各マッピングが同じスキーマに配布されていることを確認します。
すべてのマッピングには同じスキーマを指定するロケーションが必要です。これは、同じターゲット・モジュールにマッピングを設計することで実行できます。ターゲット・モジュールが複数ある場合は、ロケーションが同じスキーマを指定するようにしてください。
「コミット制御」パラメータを「手動」に設定した状態で、各マッピングを構成します。
プロジェクト・ナビゲータで、マッピングを右クリックし、「構成」を選択します。コード生成オプションで、 「コミット制御」パラメータを「手動」に設定します。
複数のマッピング・アクティビティではなく、1つのSqlplusアクティビティを使用してプロセス・フローを設計します。
典型的なプロセス・フローでは、マッピングごとにマッピング・アクティビティを追加し、プロセス・フローで各マッピング・アクティビティ後に暗黙的なコミットを実行します。ただし、この設計では、マッピング・アクティビティを追加しないでください。かわりに、Sqlplusアクティビティを1つ追加してください。
メイン・プロシージャを使用するPL/SQLスクリプトを作成して、各マッピングを実行します。次のスクリプトは、最初のマッピングが成功した場合のみの次のマッピングを実行する方法を示しています。
declare
status VARCHAR2(30);
begin
map1.main(status);
if status != 'OK' then
rollback;
else
map2.main(status);
if status != 'OK' then
rollback;
else
commit;
end if;
end if;
end;
PL/SQLスクリプトをSQL*PLUSアクティビティに貼り付けます。
エディタ・エクスプローラで、SQL*PLUSアクティビティの下のSCRIPTを選択し、オブジェクト・インスペクタの「値」 をダブルクリックします。
オプションで、「スケジュールの定義」の説明に従って、スケジュールをプロセス・フローに適用します。
マッピング、プロセス・フローおよびスケジュール(定義した場合)を配布します。
複数ターゲットのマッピングを設計するときは、Oracle Warehouse Builderによるターゲットのロードが特定の順序で行われることを確認する場合があります。これは、あるターゲットの1つの列が別のターゲットからデータを導出する場合があるためです。
PL/SQLマッピングにおける参照整合性を確認する手順は、次のとおりです。
複数ターゲットのPL/SQLマッピングを設計します。
(オプション)外部キーを指定して、2つのターゲット間に親子関係を定義します。
子表の外部キーは、親表の主キーを参照する必要があります。主キーとして定義した列が親にない場合は、列を追加して主キーとして設定する必要があります。この例は、「SQL*Loaderマッピングでの参照整合性を確認するための従来のロードの使用」を参照してください。
マッピングのプロパティで、このプロパティの右にある省略ボタンボタンをクリックして、「ターゲット・ロード順序」プロパティを表示します。
前の手順で外部キー関係を定義した場合、Oracle Warehouse Builderでは、子の前に親ターゲットをロードするデフォルトのロード順序が計算されます。外部キーを定義していない場合は、「ターゲット・ロード順序」ダイアログ・ボックスを使用して、ロード順序を定義します。
詳細は、 「マッピングにおけるターゲット・オブジェクトのロード順序の指定」を参照してください。
「ターゲット・ロード順序付けを使用」構成パラメータが、デフォルト値のTRUEに設定されていることを確認します。
この項の内容は次のとおりです。
マスター/ディテール構造を持つ複数レコード・タイプのファイルからデータを抽出して表にマッピングする場合は、順序演算子をマッピングに追加して、マスター・レコードとディテール・レコード間の関係をサロゲート主キーまたは外部キーの関係で保持します。マスター/ディテール・ファイル構造とは、マスター・レコードの後にディテール・レコードが続く構造です。例10-1では、「E」で始まるレコードは従業員(Employee)情報が保存されているマスター・レコードです。「P」で始まるレコードは、対応する従業員の給与(Payroll)情報が保存されているディテール・レコードです。
例10-1 マスター・ディテール構造を持つ複数レコード・タイプのフラット・ファイル
E 003715 4 153 09061987 014000000 "IRENE HIRSH" 1 08500 P 01152000 01162000 00101 000500000 000700000 P 02152000 02162000 00102 000300000 000800000 E 003941 2 165 03111959 016700000 "ANNE FAHEY" 1 09900 P 03152000 03162000 00107 000300000 001000000 E 001939 2 265 09281988 021300000 "EMILY WELLMET" 1 07700 P 01152000 01162000 00108 000300000 001000000 P 02152000 02162000 00109 000300000 001000000
例10-1では、マスター・レコードとディテール・レコード間の関係は、物理的なレコードの順序のみが継承されます。つまり、給与レコードはその前の従業員レコードに対応しています。ただし、これがディテール・レコードをそのマスターに関連付ける唯一の方法である場合、この関係は、Oracle Warehouse Builderによって各レコードがターゲット表にロードされるときに失われます。
マスター・レコードとディテール・レコードが共通フィールドを共有している場合は、その両レコード間の関係を維持できます。例10-1の従業員IDのフィールドが従業員レコードと給与レコードの両方に存在する場合、このフィールドを従業員表の主キー、給与表の外部キーとして使用すると、給与レコードを正しい従業員レコードに関連付けることができます。
ただし、マスター・レコードとディテール・レコードを結合するために必要な共通フィールドがファイルに存在しない場合は、順序列をマスター・ターゲットとディテール・ターゲットの両方に追加して、マスター・レコードとディテール・レコード間の関係を維持する必要があります(表10-5および表10-6を参照)。この追加する値を生成するには、順序演算子を使用します。
表10-5は、例10-1にあるファイルからマスター・レコードを抽出したターゲット表を示しています。このマスター・レコードのターゲット表には、従業員情報が格納されています。列E1からE10には、フラット・ファイルから抽出したデータが格納されています。列E11は、マスター順序番号を格納するために追加された列です。この番号は従業員1人につき1つずつ増加します。
表10-5 マスター・レコードが格納されたターゲット表
| E1 | E2 | E3 | E4 | E5 | E6 | E7 | E8 | E9 | E10 | E11 |
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表10-6は、例10-1にあるファイルからディテール・レコードを抽出したターゲット表を示しています。このディテール・レコードのターゲット表には、給与情報が格納されており、従業員1人につき1つ以上の給与レコードが存在します。列P1からP6には、フラット・ファイルから抽出したデータが格納されています。列P7は、ディテール順序番号を格納するために追加された列です。各給与レコードの番号は、表10-5の対応する従業員レコードの番号と一致します。
この項では、マスター・ディテール・フラット・ファイルからレコードを抽出し、そのレコードを2つの異なる表にロードするマッピングの作成方法を説明します。1つのターゲット表にはマスター・レコードを格納し、もう1つのターゲット表にはフラット・ファイルからのディテール・レコードを格納します。2つの表間のマスター・ディテール関係を維持するには、マッピング順序を使用します。
|
注意: この説明は、従来型パスによるロードを対象にしています。マスター・ディテール・レコードにダイレクト・パス・ロードを使用する手順は、「SQL*Loaderマッピングでの参照整合性を確認するためのダイレクト・パス・ロードの使用」を参照してください。 |
この手順では、このようなマッピングを構築するための一般的な手順を概説します。次に示す詳細な手順も参照してください。
『Oracle Warehouse Builderソースおよびターゲット・ガイド』
マスター・ディテール・フラット・ファイルから抽出し、マスター/ディテール関係を維持するには、次の手順を実行します。
マスター・レコードとディテール・レコードで構成されたフラット・ファイル・ソースをインポートして、サンプリングします。
ファイルのサンプリング時にレコード・タイプに名前を指定する場合は、マスター・レコードとディテール・レコードに説明的な名前を割り当てます。これによって、今後はこれらのレコードを容易に識別できます。
この複数レコード・タイプのフラット・ファイルに対する例では、フラット・ファイル・サンプル・ウィザードに部門情報と従業員情報が含まれています。従業員レコードのマスター・レコード・タイプにはEmployeeMasterという名前が指定され、給与情報のディテール・レコード・タイプにはPayrollDetailという名前が指定されます。
フラット・ファイル演算子をマッピング・エディタのキャンバスにドラッグ・アンド・ドロップし、データの抽出元のマスター・ディテール・ファイルを指定します。
順序演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
マスター・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前に作成した既存のワークスペース表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成できます。次に、必要なすべてのフィールドをフラット・ファイル演算子のマスター・レコードからマスター表演算子にマッピングまたはコピーし(列の作成)、アウトバウンド調整を実行して後で表を定義できるようにします。
この表には、ロードするマスター・フィールドに必要なすべての列と、順序の値をロードするための追加の数値列が含まれている必要があります。
ディテール・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前に作成した既存のワークスペース表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成できます。次に、必要なすべてのフィールドをフラット・ファイル演算子のマスター・レコードからマスター表演算子にマッピングまたはコピーし(列の作成)、アウトバウンド同期化を実行して後で表を定義できるようにします。
この表には、ロードするディテール・フィールドに必要なすべての列と、順序の値をロードするための追加の数値列が含まれている必要があります。
必要なすべてのフラット・ファイル・マスター・フィールドをマスター表に、ディテール・フィールドをディテール表にマッピングします。
図10-8に、このフィールドのマッピングを示します。
順序NEXTVAL属性を、マスター表の追加の順序列にマッピングします。
図10-8に、順序演算子のNEXTVAL属性からマスター表へのマッピングを示します。
順序CURRVAL属性を、ディテール表の追加の順序列にマッピングします。
図10-8は、マッピングが完成した状態を示しています。フラット・ファイルのマスター・フィールドはマスター・ターゲット表にマッピングされ、ディテール・フィールドはディテール・ターゲット表にマッピングされ、順序のマッピングのNEXTVAL属性とCURRVAL属性はマスター・ターゲット表とディテール・ターゲット表にそれぞれマッピングされています。
次のパラメータを使用してソース・データをターゲット表にロードするマッピングを構成します。
ダイレクト・モード: 選択しない
エラー許可: 0
行: 1
後続NULL列: True(すべての表)
この項では、ファイルのエラー数に応じたエラーの対処方法について説明します。
データ・ファイルにほとんどエラーがない場合は、次のように対処します。
順序演算子でマッピングを作成します。
次のパラメータを使用して、マッピングを構成します。
ダイレクト・モード=選択しない
行= 1
エラー許可= 0
コードを生成し、 SQL*Loaderスクリプトを実行します。
データ・ファイルにエラーがある場合は、最初のエラーが発生した時点でロードが停止します。
データ・ファイルを修正し、次の構成値を使用して制御ファイルを再度実行します。
CONTINUE_LOAD = TRUE
SKIP =ロード済のレコード数
データ・ファイルに少数のエラーがあると思われる場合は、次のように対処します。
seq_nextval列に基づいてマスター・レコードに主キー(PK)を作成します。
マスター表PKを参照するseq_currval列に基づいてディテール・レコードに外部キー(FK)を作成します。
この場合、エラーがあるマスター・レコードは、対応するすべてのディテール・レコードとともに拒否されます。次の手順に従って、これらのレコードを修復します。
マスター・レコードがない、失敗したディテール・レコードをすべて削除します。
不正なファイルのエラーを修正し、これらのレコードのみリロードします。
エラーが非常に少ない場合は、残りのレコードをロードし、正しい順序番号を使用して表を手動で更新することもできます。
ログ・ファイルでは、エラーで失敗したレコードを識別できます。これは、これらのエラーが整合性制約に違反しているためです。次に、エラーのあるログ・ファイル・レコードの例を示します。
Record 9: Rejected - Error on table "MASTER_T", column "C3". ORA-01722: invalid number Record 10: Rejected - Error on table "DETAIL1_T". ORA-02291: integrity constraint (SCOTT.FK_SEQ) violated - parent key not found Record 11: Rejected - Error on table "DETAIL1_T". ORA-02291: integrity constraint (SCOTT.FK_SEQ) violated - parent key not found Record 21: Rejected - Error on table "DETAIL2_T". ORA-02291: invalid number
データ・ファイルに常に多数のエラーが存在する場合は、次のように対処します。
順序演算子を使用しないで、すべてのレコードをロードします。
レコードを独立した表にロードします。ダイレクト・モードでデータをロードする際には、次のパラメータを使用すると、データのロードを高速化できます。
行>1
エラー許可= MAX
拒否されたすべてのレコードを修正します。
順序演算子を使用してファイルを再ロードします。
マスター・レコードに一意のフィールドがある(または複数のフィールドを連結した結果、一意の識別子がある)マスター・ディテール・フラット・ファイルを使用している場合は、オプションのダイレクト・パス・ロードを使用すると、ロードを高速化できます。
ダイレクト・パス・ロードの場合、各レコードのレコード番号(RECNUM)はマスター表とディテール表に格納されます。ロード後の手順では、RECNUMを使用して、各ディテール行を、対応するマスター行の一意の識別子で更新します。
この手順では、このようなマッピングを構築するための一般的な手順を概説します。次に示す詳細な手順も参照してください。
フラット・ファイル・ソースのインポートの詳細は、『Oacle Warehouse Builderソースおよびターゲット・ファイル』を参照してください。
ソースとしてのフラット・ファイルの使用方法の詳細は、「フラット・ファイル演算子」を参照してください。
表演算子の使用方法の詳細は、「演算子を追加するための演算子の追加ダイアログ・ボックスの使用」を参照してください。
データ・ジェネレータ演算子の使用方法の詳細は、「データ・ジェネレータ演算子」を参照してください。
定数演算子の使用方法の詳細は、「定数演算子」を参照してください。
マッピングの構成の詳細は、「マッピング構成のリファレンス」を参照してください。
ダイレクト・パス・ロードを使用してマスター・ディテール・フラット・ファイルから抽出し、マスター・ディテール関係を維持する手順は、次のとおりです。
マスター・レコードとディテール・レコードで構成されたフラット・ファイル・ソースをインポートして、サンプリングします。
ファイルのサンプリング時にレコード・タイプに名前を指定する場合は、マスター・レコードとディテール・レコードに説明的な名前を割り当てます。これにより、将来これらのレコードを識別する際に役立ちます。
フラット・ファイル・ソースからデータをロードするために使用するマッピングを作成します。
フラット・ファイル演算子をマッピング・キャンバスにドラッグ・アンド・ドロップし、データの抽出元のマスター・ディテール・ファイルを指定します。
データ・ジェネレータ演算子および定数演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
マスター・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前作成した既存のワークスペース表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成し、アウトバウンド同期化を実行して後で表を定義できるようにします。
この表には、ロードするマスター・フィールドに必要なすべての列と、RECNUM値をロードするための追加の数値列が含まれている必要があります。
ディテール・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前作成した既存のワークスペース表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成し、アウトバウンド同期化を実行して後で表を定義できるようにします。
表には、ロードするディテール・フィールドに必要なすべての列と、RECNUM値をロードするための追加の数値列、および対応するマスター表の行の一意の識別子で更新する列が含まれている必要があります。
必要なすべてのフラット・ファイル・マスター・フィールドをマスター表に、ディテール・フィールドをディテール表にマッピングします。
図10-9は、このマスター・フィールドとディテール・フィールドのマッピングを示しています。
データ・ジェネレータ演算子のRECNUM属性をマスター表とディテール表のRECNUM列にマップします。
図10-9は、データ・ジェネレータ演算子のRECNUM属性がRECORDNUMBER表の属性にマップされるマッピングを示しています。
定数演算子の定数属性を追加します。
マスター行の一意の識別子列がCHARデータ型である場合は、定数属性のプロパティ・インスペクタで、「データ型」プロパティをCHARに、「式」プロパティをアスタリスク(*)に設定します。
マスター行の一意の識別子列が数値である場合は、定数属性のプロパティ・インスペクタで、「データ型」プロパティをNUMBERに、「式」プロパティを0(ゼロ)に設定します。これにより、すべてのデータ行をロード済としてマークします。
定数演算子の定数属性をディテール表の列にマッピングします。この列には、対応するマスター表レコードの一意の識別子が後で格納されます。
図10-9は、マッピングが完成した状態を示しています。フラット・ファイルのマスター・フィールドはマスター・ターゲット表にマッピングされ、ディテール・フィールドはディテール・ターゲット表にマッピングされ、データ・ジェネレータ演算子のRECNUM属性はマスター・ターゲット表とディテール・ターゲット表にそれぞれマッピングされ、定数属性はディテール・ターゲット表にマッピングされています。
図10-9 ダイレクト・パス・ロードを使用したマスター・ディテール・フラット・ファイルからのマッピング
ダイレクト・モード: True
エラー許可: 0
後続NULL列: True(すべての表)
マッピングを検証し、SQL*Loaderスクリプトを生成した後は、更新後のPL/SQLプロシージャを作成し、それをOracle Warehouse Builderライブラリに追加します。
SQL*Loaderスクリプトを実行します。
更新後のPL/SQLプロシージャを実行するか、スクリプトを手動で実行して、UPDATE SQL文を実行します。
次に、生成されたSQL*Loader制御ファイルのスクリプトの例を示します。
OPTIONS ( DIRECT=TRUE,PARALLEL=FALSE, ERRORS=0, BINDSIZE=50000, ROWS=200, READSIZE=65536)
LOAD DATA
CHARACTERSET WE8MSWIN1252
INFILE 'g:\FFAS\DMR2.dat'
READBUFFERS 4
INTO TABLE "MATER_TABLE"
APPEND
REENABLE DISABLED_CONSTRAINTS
WHEN
"REC_TYPE"='P'
FIELDS
TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
(
"REC_TYPE" POSITION (1) CHAR ,
"EMP_ID" CHAR ,
"ENAME" CHAR ,
"REC_NUM" RECNUM
)
INTO TABLE "DETAIL_TABLE"
APPEND
REENABLE DISABLED_CONSTRAINTS
WHEN
"REC_TYPE"='E'
FIELDS
TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
(
"REC_TYPE" POSITION (1) CHAR ,
"C1" CHAR ,
"C2" CHAR ,
"C3" CHAR ,
"EMP_ID" CONSTANT '*',
"REC_NUM" RECNUM
次に、更新後のPL/SQLプロシージャの例を示します。
create or replace procedure wb_md_post_update(
master_table varchar2
,master_recnum_column varchar2
,master_unique_column varchar2
,detail_table varchar2
,detail_recnum_column varchar2
,detail_masterunique_column varchar2
,detail_just_load_condition varchar2)
IS
v_SqlStmt VARCHAR2(1000);
BEGIN
v_SqlStmt := 'UPDATE '||detail_table||' l '||
' SET l.'||detail_masterunique_column||' = (select i.'||master_unique_column||
' from '||master_table||' i '||
' WHERE i.'||master_recnum_column||' IN '||
' (select max(ii.'||master_recnum_column||') '||
' from '||master_table||' ii '||
' WHERE ii.'||master_recnum_column||' < l.'||detail_recnum_column||') '||
' ) '||
' WHERE l.'||detail_masterunique_column||' = '||''''||detail_just_load_condition||'''';
dbms_output.put_line(v_sqlStmt);
EXECUTE IMMEDIATE v_SqlStmt;
END;
/
データ・パーティションを使用すると、ターゲット・システムでデータをロードまたは削除するときのパフォーマンスが向上します。この方法は、パーティション交換ロード(PEL)と呼ばれています。
PELは、比較的少量のデータを、大量の履歴データを含むターゲットにロードする際に使用してください。ターゲットにできるものとしては、データ・ウェアハウスの表、ディメンション、キューブなどがあります。
この項の内容は次のとおりです。
ターゲット・システムのパーティションを操作すると、パーティション交換ロード(PEL)を使用して、即時にデータを追加または削除できます。表が空のパーティションで交換されると、新規データが追加されます。
PELを使用すると、新規データをパーティションとしてターゲット表と交換し、ロードできます。たとえば、新規データを保持する表は、パーティションのアイデンティティをターゲット表から引き継ぎ、このパーティションはソース表のアイデンティティを引き継ぎます。この交換プロセスは、実際のデータの移動を伴わないDDL操作です。
図10-10は、PELの例を示したものです。ソース表Sourceのデータが4つのパーティション(Target_P1、Target_P2、Target_P3およびTarget_P4)で構成されるターゲット表に挿入されます。新規データをTarget_P3にロードする場合、パーティション交換操作では実際のデータを移動せずに、データ・オブジェクトの名前のみを交換します。交換後は、以前のSourceという名前がTarget_P3に変更され、以前のTarget_P3という名前がSourceになります。ターゲット表には、Target_P1、Target_P2、Target_P3およびTarget_P4の4つのパーティションが含まれたままです。Oracle 9iで使用可能なパーティション交換操作は、データの移動なしにロード・プロセスを完了します。
パーティション交換ロードのマッピングを構成する手順は、次のとおりです。
プロジェクト・ナビゲータで、マッピングを右クリックし、「構成」を選択します。
マッピングの「構成」タブが表示されます。
デフォルトでは、PELはすべてのマッピングに対して無効です。パーティション交換ロードを使用するには、「PEL有効」を選択します。
「データ・コレクション頻度」を使用して、マッピングを実行するたびに収集する新規データの量を指定します。このパラメータを設定して、年、四半期、月、日、時間、分ごとのデータの収集を指定します。これによって、パーティション数が決定されます。
収集したデータをステージングする一時表を作成する場合は、パーティション交換を実行する前に、「送る」を選択します。このパラメータを選択しないと、一時表は作成されないまま、ソース表がパーティションとしてターゲット表に直接スワップされます。詳細は、「ダイレクトPELと間接PEL」を参照してください。
「データの置換」を選択すると、ターゲット・パーティションにある既存のデータが新しく収集したデータで置換されます。このパラメータを選択しない場合は、ターゲット・パーティションにある既存のデータは保持されます。新規データは、空ではないパーティションに挿入されます。このパラメータはローカル・パーティションに影響を与え、ターゲット表のパーティションを削除またはスワップするために必要です。TRUNCATE/INSERTプロパティは、表レベルで設定できます。
パーティション交換によってターゲットをロードする場合は、ターゲットを間接的または直接的にロードできます。
間接PEL: デフォルトでは、パーティション交換プロセスを開始する前に、ソース・データをステージングする一時表が作成され、維持されます。たとえば、マッピングにリモート・ソースまたは複数ソースの結合が含まれている場合は、間接PELを使用します。
ダイレクトPEL: ターゲット構造に一致するマッピングのソースを設計します。たとえば、マッピングでダイレクトPELを使用すると、以前実行したマッピングでロードしたファクト表をすぐに公開できます。
PELを使用して設計したマッピングにリモート・ソースまたは複数ソースの結合が含まれている場合、Oracle Warehouse Builderでは、パーティション交換を続行する前に、ソース処理を実行してデータをステージングする必要があります。したがって、このようなマッピングは、ダイレクトPELをFalseに設定した状態で構成します。Oracle Warehouse Builderでは、ソース処理の結果を格納する一時表が透過的に作成され、維持されます。PELの実行後に、この表は削除されます。
図10-11は、2つのソースを結合し、集計を実行するマッピングを示しています。ORDER_SUMMARY表にロードされたすべての新規データが常に同じパーティションにロードされる場合は、このマッピングで間接PELを使用して、ロードのパフォーマンスを改善できます。この場合、Oracle Warehouse Builderではアグリゲータ後とORDER_SUMMARY前に、一時表が透過的に作成されます。
Oracle Warehouse Builderでは、ターゲット表と同じ構造(列、索引、制約が同じ)を使用して、一時表が作成されます。この一時表は、パフォーマンス向上のためにパラレル・ダイレクト・パス・ロードINSERTを使用してロードされます。INSERTの後、一時表の索引と制約がパラレルで作成されます。
ソース表がローカルでデータの品質が高い場合は、ダイレクトPELを使用します。マッピングは、ソースとターゲットが同じデータベースにあり、同じ構造であるように設計する必要があります。ソースとターゲットの索引、制約、列数、列タイプおよび列の長さは同じである必要があります。
たとえば、図10-11でのマッピングと同じマッピングがあり、データをターゲットにロードするタイミングをより細かく制御するとします。データ量によってはロードに数時間がかかり、ターゲット表がいつ更新されるかもわかりません。
ダイレクト接PELを使用してデータを即時にターゲットにロードする手順は、次のとおりです。
ソース・データを結合し、必要に応じてデータを変換し、確実に検証してステージング表にロードするマッピングを1つ設計します。このマッピングはPELを使用するように構成しないでください。
ステージング表を、別のマッピングでロードする最終ターゲットの構造と完全に一致するように設計します。
たとえば、図10-11にあるステージング表のORDER_SUMMARYは、図10-12にある最終ターゲットORDER_CUBEと同じ構造である必要があります。
ステージング表から最終ターゲットにデータをロードする2番目のマッピングを作成します。このマッピングはダイレクトPELを使用するように構成してください。
図10-12は、ステージング表から最終ターゲットにデータをロードするマッピングを示しています。
Oracle Warehouse Builderのプロセス・フロー・エディタまたはOracle Workflowを使用して、最初のマッピングの完了後に2番目のマッピングを開始します。
次の条件がtrueの場合は、スケーラビリティの高いロード・パフォーマンスのためにPELを効果的に使用できます。
表のパーティション化と表領域: ターゲット表は、1つのDATE列ごとにレンジ・パーティション化される必要があります。すべてのパーティションは同じ表領域内に作成される必要があります。すべての表は同じ表領域内に作成されます。
既存の履歴データ: ターゲット表には大量の履歴データを格納できる必要があります。PELの使用例には、ターゲットがOLTPデータベースやWebログ・ファイルからデータを毎日収集するクリック・ストリーム・アプリケーションがあります。新規データは変換され、履歴データが格納されているターゲットにロードされます。
新規データ: 新規データはすべてターゲット表内の同じパーティションにロードする必要があります。たとえば、ターゲット表が日別に区切られている場合、日別のデータは1つのパーティションにロードされる必要があります。
ロード頻度: ロード頻度は、データ収集頻度以下である必要があります。
グローバル索引なし: ターゲット表にはグローバル索引は含めないでください。
PELのマッピングでターゲットを構成するには、次の手順を実行します。
パーティションは、実行中に自動的に作成されません。すべてのパーティションは、PELを使用する前に、「パーティションの定義」の説明に従って作成する必要があります。
たとえば、新しいデータ・コレクションの頻度として「月」を選択した場合、新規データの月ごとに必要なすべてのパーティションを作成する必要があります。オブジェクト・エディタを使用して、表、ディメンションまたはキューブのパーティションを作成します。
PELを使用するには、すべてのパーティションがネーミング規則に従って命名される必要があります。たとえば、2002年5月のデータを保持するパーティションの場合、そのパーティション名はY2002_Q2_M05という形式にする必要があります。
PELでパーティションを識別するには、次のいずれかの形式の名前をパーティションに指定する必要があります。
Ydddd
Ydddd_Qd
Ydddd_Qd_Mdd
Ydddd_Qd_Mdd_Ddd
Ydddd_Qd_Mdd_Ddd_Hdd
Ydddd_Qd_Mdd_Ddd_Hdd_Mdd
dには、10進数の数字が入ります。すべての文字は大文字にする必要があります。小文字は認識されません。
各パーティションを正しく命名すると、各パーティションの「上限値」プロパティが自動的に計算されます。そうでない場合は、Oracle Warehouse BuilderでDDL文が作成されるように、上限値を各パーティションに対して手動で構成する必要があります。次に、Oracle Warehouse Builderによって作成されたDDL文の例を示します。
. . .
PARTITION A_PARTITION_NAME
VALUES LESS THAN (TO_DATE('01-06-2002','DD-MM-YYYY')),
. . .
索引(ORDER_SUMMARY_PK_IDX)をORDER_SUMMARY表に追加します。この索引には、ORDER_DATEとITEM_IDの2つの列があります。表エディタの「索引」タブで次のように設定します。
「タイプ」列で「UNIQUE」を選択します。
「スコープ」列で「LOCAL」を選択します。
これで、表ORDER_SUMMARYにある一意のローカル索引のDDL文が作成できるようになります。
ローカル索引を使用すると、PELのパフォーマンスを最大限に活用できます。ローカル索引では、すべての索引が表と同じ方法でパーティション化されている必要があります。PELを使用して一時表をターゲット表にスワップすると、索引セグメントのアイデンティティもスワップされます。
ローカル索引として索引が作成されている場合、Oracleサーバーでは、パーティション・キー列を索引の最初の列にする必要があります。前述の例では、パーティション・キーはORDER_DATEで、索引ORDER_SUMMARY_PK_IDXの最初の列になります。
この手順では、すべての主キー制約および一意キー制約がUSING INDEXオプションを使用して作成されるように指定する必要があります。プロジェクト・ナビゲータで、表を右クリックして「構成」を選択します。その表の「構成」タブが表示されます。左パネルで主キーまたは一意キーを選択し、右パネルで「索引を使用」を選択します。
USING INDEXオプションを使用すると、表に制約を追加した際に索引が自動的に作成されなくなります。サーバーは制約と同じ列リストを持つ既存の索引を検索します。したがって、各主キー制約または一意キー制約は、ユーザー定義の一意のローカル索引で補足する必要があります。制約ORDER_SUMMARY_PKに必要な索引は、「手順2: ローカル・オプションを使用したすべての索引の作成」で作成したORDER_SUMMARY_PK_IDXです。
Oracle Warehouse BuilderでのPEL使用時の制限は次のとおりです。
日付パーティション・キーは1つのみ: 使用できるDATEデータ型のパーティション・キー列は1つのみです。数値パーティション・キーは、Oracle Warehouse Builderではサポートされていません。
一般的なカレンダのみ: 現在のPELメソッドは、世界中で採用されている一般的なカレンダのみをサポートしています。ユーザー定義の会計年度別や四半期別のビジネス・カレンダは、現時点ではサポートされていません。
すべての日付パーティションが同じ表領域内にあること: ターゲット(表、ディメンションまたはキューブ)のすべてのパーティションは、同じ表領域内に作成される必要があります。
すべての索引パーティションが同じ表領域内にあること: ターゲット(表、ディメンションまたはキューブ)のすべての索引は、同じ表領域内に作成される必要があります。ただし、索引とデータでは別の表領域を使用できます。
データベース・リンクを介してリモート・ソースにアクセスするマッピングを設計できますが、大量のデータを移動するとパフォーマンスが低下する可能性があります。同じバージョンのOracle Databaseのソースとターゲット間で大量のデータを移動するマッピングについては、トランスポータブル・モジュールを使用して、パフォーマンスを大幅に改善するためのオプションがあります。
コード・テンプレート(CT)マッピングを使用して、リモートOracleまたはその他の異種データベース・ソースから効率的にデータを抽出することも可能です。Oracle Warehouse Builderには、異なるデータ移動オプションのCTマッピングに使用できる事前定義済コード・テンプレートのセットが用意されています。
|
関連項目:
|
