| Oracle Warehouse Builderユーザーズ・ガイド 11gリリース1（11.1） E05734-03 |
|
 戻る |
 次へ |
この章は、パフォーマンス要件を満たすETLロジックを作成するためのガイドとして使用します。
この章の内容は次のとおりです。
このセクションでは、次の項目でPL/SQLマッピング設計を説明します。
Warehouse Builderでは、次の基準を満たすPL/SQLマッピングのコードが生成されます。
各演算子の出力コードは、その演算子の次のダウンストリーム演算子の入力コード要件を満たしている。
マッピングにPL/SQL出力のみを生成する演算子が含まれている場合は、すべてのダウンストリーム・データフロー演算子もPL/SQLによって実装可能である必要がある。このようなマッピングでのSQL演算子は、PL/SQL出力をターゲットにロードした後でのみ使用できます。
マッピングを設計する際に、マッピング内の各演算子の入力および出力コード・タイプに注目することで、マッピングの有効性を評価できます。
たとえば、図22-1のマッピングでは、Match-Merge演算子MMはPL/SQL出力を生成しますが、後続の結合演算子はSQL入力のみを受け入れるため、無効であることがわかります。
マッピングが希望どおりの結果になるようにするには、Match-Mergeを実行する前にソース表を結合するか、結合を実行する前にMatch-Mergeからステージング表に結果をロードすることを検討します。
図22-2は、Match-Mergeの前にソース表を結合するマッピングを示しています。図22-3は、結合を実行する前にMatch-Mergeからステージング表に結果をロードするマッピングを示しています。
表22-1および表22-2は、各Warehouse Builder演算子の実装タイプを示しています。これらの表は、PL/SQLコードにカーソルの演算子と関連付けられた操作があるかどうかも示しています。この情報は、特定のマッピング設計に有効なオペレーティング・モードを判断する際に使用します。また、エラー処理中に使用できる監査詳細の判断にも使用します。
表22-1 PL/SQLマッピングでのソースおよびターゲット演算子の実装
| 演算子 | 実装タイプ | セット・ベース・モードで有効か | 行ベース・モードで有効か | 行ベース（ターゲットのみ）で有効か |
|---|---|---|---|---|
|
ソース演算子: 表、ディメンション、キューブ、ビュー、外部表 |
SQL |
はい |
はい |
はい。カーソルの一部。 |
|
ターゲット演算子: 表、ディメンション、キューブ、ビュー |
SQL PL/SQL |
はい。ロードが=UPDATEで、データベースが10gより前の場合を除く。 |
はい |
はい。カーソルの一部ではない。 |
|
ソースとしてのフラット・ファイル |
PL/SQLの場合は、外部表を作成。 |
はい |
はい |
はい。カーソルの一部。 |
|
ターゲットとしてのフラット・ファイル |
SQL |
はい。ロードが=DELETEまたは=UPDATEで、データベースが10gより前の場合を除く。 |
はい |
はい。カーソルの一部ではない。 |
|
ソースとしての順序 |
SQL |
はい |
はい |
はい。カーソルの一部。 |
表22-2 PL/SQLマッピングでのデータ・フロー演算子の実装
| 演算子名 | 実装タイプ | セット・ベース・モードで有効か | 行ベース・モードで有効か | 行ベース（ターゲットのみ）モードで有効か |
|---|---|---|---|---|
|
アグリゲータ |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
定数演算子 |
PL/SQL SQL |
はい |
はい |
はい |
|
データ・ジェネレータ |
SQL*Loaderのみ |
N/A |
N/A |
N/A |
|
デュプリケータ解除 |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
式 |
SQL PL/SQL |
はい |
はい |
はい |
|
フィルタ |
SQL PL/SQL |
はい |
はい |
はい |
|
ジョイナ |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
キー参照 |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
入力パラメータのマッピング |
SQL PL/SQL |
はい |
はい |
はい |
|
出力パラメータのマッピング |
SQL PL/SQL |
はい |
はい |
はい |
|
Match-Merge |
SQL入力 PL/SQL出力 （XREFグループからのPL/SQL入力のみ） |
いいえ |
はい |
はい。カーソルの一部ではない。 |
|
Name and Address |
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、変換以外のすべての演算子を含めることができます。行ベース・モードおよび行ベース（ターゲットのみ）モードではすべての演算子を含めることができますが、アグリゲータ、ジョイナ、キー検索などのSQLベースの演算子の使用方法には重要な制限があります。SQLベースの演算子を行ベース・モードのいずれかで使用するには、演算子と関連付けられた演算をカーソルに含めることができることを確認します。
これらの一般的なルールについては、次の各項で説明します。
セット・ベース・モードでは、すべてのデータを処理し、すべての演算を実行する単一のSQL文が生成されます。データをセットで処理するとパフォーマンスが向上しますが、使用できる監査情報は制限されます。ランタイム監査は、実行エラーのみの報告に制限されます。セット・ベース・モードでは、エラーを含む行を識別できません。
図22-4は、セット・ベースのオペレーティング・モードでの実行時に、マッピングのコード生成に使用される、単純なマッピングと関連ロジックを示しています。「TAB1」、「FLTR」、「TAB2」は、SQLを使用してセットとして処理されます。
セット・ベース・モードのマッピングを正確に設計するには、Match-Merge演算子やName and Address演算子など、行ごとの処理を必要とする演算子を避けます。SQLで実行できないデータ・フローの演算子を含めた場合、セット・ベース・コードは作成されず、セット・ベース・モードでのパッケージの実行時にエラーが表示されます。
マッピングのターゲット演算子の場合、ロード・タイプINSERT/UPDATEおよびUPDATE/INSERTはセット・ベース・モードでは常に有効です。UPDATEロードがセット・ベース・モードでサポートされるのは、Oracle Databaseが10g以上の場合のみです。セット・ベース・モードでは、DELETEロード・タイプもサポートされます。セット・ベースのマッピングで演算子を処理する方法の全リストは、表22-2を参照してください。
行ベース・モードでは、データを行ごとに処理する文が生成されます。SQLカーソルには、SELECT文があります。後続のすべての文はPL/SQLです。PL/SQLで実行されたすべての演算子については、ランタイム監査の全情報にアクセスできますが、カーソルで実行された演算については、限られた情報にのみアクセスできます。
図22-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で実行されたすべての演算子については、ランタイム監査の全情報にアクセスできますが、カーソルで実行された演算については、限られた情報にのみアクセスできます。このモードは、データの抽出と変換には高速のセット・ベース演算を使用するが、エラーの発生しやすいデータのロードには高度な監査機能が必要な場合に使用します。
図22-6は、行ベース（ターゲットのみ）のオペレーティング・モードでの実行時に、マッピングのコード生成に使用される、単純なマッピングと関連ロジックを示しています。「TAB1」および「FLTR」はカーソルに含まれ、SQLを使用してセットとして処理されます。「TAB2」は、行ごとに処理されます。
行ベース（ターゲットのみ）は、行ベースのオペレーティング・モードと同じ制限をSQLベース演算子に加えます。また、複数ターゲットのマッピングの場合は、各ターゲットのカーソルでコードが生成されます。
Warehouse Builderでデータをコミットする主な方法は2つあります。データのコミットまたはロールバックは、マッピング設計に基づいて実行できます。そのためには、「マッピング設計に基づいたデータのコミット」で説明するいずれかのコミット制御方法を使用します。
また、PL/SQLマッピングの場合は、マッピング設計とは無関係にデータをコミットまたはロールバックできます。「マッピング設計に依存しないデータのコミット」の説明に従って、プロセス・フローを使用してデータをコミットするか、独自の方法を作成します。
デフォルトでは、マッピング設計に基づいてデータがロードされ、自動的にコミットされます。PL/SQLマッピングの場合は、デフォルト設定を上書きして、Warehouse Builderでデータがコミットされる時期と方法を制御できます。マッピングでデータをコミットする方法には、次のオプションがあります。
自動: これはデフォルト設定で、すべてのマッピング・タイプに有効です。Warehouse Builderでは、マッピング設計に基づいてデータがロードされ、自動的にコミットされます。マッピングに複数ターゲットがある場合は、他のターゲットに関係なく、ターゲットごとに別々にコミットとロールバックが行われます。不規則にロードされた複数ターゲットの結果が、大きくない場合や相関関係にない場合は、自動コミットを使用します。
自動相関: 自動相関コミットは、自動コミットの特殊タイプで、複数ターゲットのPL/SQLマッピングにのみ適用されます。Warehouse Builderでは、すべてのターゲットは集合的に扱われ、全ターゲットにわたってコミットまたはロールバックが均一に実行されます。ソースのすべての行が、影響を受けるターゲットすべてに均一な影響を確実に与えることが重要な場合は、相関コミットを使用します。相関コミットの詳細は、「単一のソースから複数ターゲットへのデータのコミット」を参照してください。
手動: PL/SQLマッピングの手動コミット制御は、データのコミット前に、複雑なビジネス・ロジックの挿入、検証、または他のマッピングを実行する場合に選択します。この例は、「マッピングへのコミット・ロジックの埋込み」および「マッピング設計に依存しないデータのコミット」を参照してください。
共通ソースに基づいて複数ターゲットを作成する場合は、ソースのすべての行が、影響を受けるターゲットすべてに均一な影響を与えることを確認します。
図22-7は、このケースを示すPL/SQLマッピングです。ターゲット表はすべて、ソース表に依存しています。「SOURCE」の行によって、複数ターゲット（「TARGET_1」と「TARGET_2」など）が変更される場合、Warehouse Builderでは、影響を受ける両方のターゲットに対して適切なデータが同時にコミットされます。マッピングを再度実行したときにこの関係が維持されない場合、データは不正確になり、使用できなくなることもあります。
ソース表からの行数が比較的少ない場合、3つのターゲットを維持するのは難しくありません。ただし、共通ソースに依存するターゲットの手動による維持は、ソースからの行数を増加したり、より多くのターゲットと変換を持つさらに複雑なマッピングを設計する際に、手間がかかります。
ソースのすべての行がすべてのターゲットに正しく影響を与えていることを確認するには、相関コミット計画を使用するマッピングを構成します。
セット・ベース・モードでは、相関コミットがロールバック・セグメントのサイズに影響を与えます。データをマージ（insert/updateまたはupdate/insert）する際には、ロールバック・セグメントの空き領域が問題となる場合があります。
相関コミットは、PL/SQLバルク処理コードで透過的に操作されます。
相関コミット計画は、パーティション交換ロード用に構成されているモードで実行されるマッピングや、アドバンスト・キュー、Match-Mergeまたはテーブル・ファンクション演算子を含むマッピングでは使用できません。
コミット計画とオペレーティング・モードの組合せによって、マッピング動作が決定されます。表22-3に、選択できる有効な組合せを示します。
表22-3 オペレーティング・モードの有効なコミット計画
| オペレーティング・モード | 自動相関コミット | 自動コミット |
|---|---|---|
|
セット・ベース |
有効（Valid） |
有効（Valid） |
|
行ベース |
有効（Valid） |
有効（Valid） |
|
行ベース（ターゲットのみ） |
適用不可 |
有効（Valid） |
相関コミットは、行ベース（ターゲットのみ）に対して適用できません。このオペレーティング・モードでは、カーソルをターゲットのできるだけ近くに配置するように定義されています。この結果、ほとんどの場合、各SELECT文に対するターゲットは1つのみとなり、複数ターゲットに対してデータをコミットする目的が失われます。行ベース（ターゲットのみ）と相関コミットの組合せでマッピングを設計した場合、マッピングは実行されますが、相関コミットは実行されません。
各オペレーティング・モードとコミット計画の組合せがマッピングに与える影響を理解するために、図22-7にあるマッピングについて考えてください。ソース表からのデータが1,000個の新規行であると仮定します。マッピングが正常に実行された場合は、各ターゲットに1,000行がロードされます。このマッピングでTarget__2への100番目の新規行のロードに失敗した場合は、コミット頻度や最大エラー数など他の構成設定からの影響を無視すると、次の結果が得られます。
セット・ベース/相関コミット: マッピングにエラーが1つでもあると、すべてのデータがロールバックされます。Target_2への挿入中にエラーが発生した場合、その表のエラーがレポートされ、行はロードされません。Target_1に挿入済のすべての行がロールバックされ、Target_3には行がロードされません。どのターゲット表にも行が追加されません。エラーの詳細には、Target_2へのロード中に発生したエラーのみがレポートされます。
行ベース/相関コミット: 各行が最初の行から個別に評価され、3つのターゲットすべてにロードされます。行のロードは、行100のTarget_2へのロード・エラーが発生するまで続行されます。エラーがレポートされ、行はロードされません。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文のみに基づいて、データがコミットまたはロールバックされます。
Warehouse Builderの既存のマッピング演算子の設計に手間がかかったり、設計が不可能なビジネス・ルールを実装するには、次の手順を使用してください。たとえば、あるターゲットに1つの行が存在することを確認するとします。その場合は、必要なロジックをSQLで記述し、マッピング前またはマッピング後に演算子を使用してそのロジックをマッピングに導入します。
コミット・ロジックをマッピング設計に組み込む手順は、次のとおりです。
マッピング前またはマッピング後演算子を含めるようにマッピングを設計します。いずれかの演算子を使用して、コミットおよびロールバックのSQL文を導入します。
「コミット制御」を「手動」に設定した状態で、マッピングを構成します。
プロジェクト・エクスプローラで、マッピングを右クリックして「構成」を選択します。「コード生成オプション」の「コミット制御」で「手動」を選択します。
手動によるデータのコミットを選択した場合の影響については、「手動コミット制御について」を参照してください。
マッピングを配布します。
マッピングを実行します。
マッピングは実行されますが、マッピング前プロセス演算子またはマッピング後プロセス演算子で記述したコミット・ロジックが処理されるまでデータはコミットされません。
次のいずれかの理由で、マッピング設計に依存せずにデータをコミットする必要が生じる場合があります。
データのコミット前に複数マッピングを実行: すべてのマッピングが正常に実行および検証されるまで、データをコミットしないまま、複数マッピングを実行する場合があります。たとえば、ディメンションのロードとキューブのロードに対して個別のマッピングがある場合です。
ターゲットの効率的な維持: 誤ったデータがロードされて非常に大きいターゲットにコミットされると、その障害の修復は困難で時間がかかる場合があります。これを回避するには、最初にデータをチェックし、次に、commitまたはrollbackコマンドを発行するかどうかを決定します。
これらの目的を実現するための最初の手順は、「コミット制御」を「手動」に設定してマッピングを構成することです。
手動コミット制御について
手動コミット制御を使用すると、マッピング設計に関係なく、Warehouse Builderでデータをコミットする時期を指定できます。手動コミット制御は監査統計に影響を与えません。これは、commitまたはrollbackコマンドを発行する前に、挿入済の行数およびその他の監査情報を表示できることを意味します。
手動コミットを使用するときは、このオプションがパフォーマンスに与える影響を考慮してください。ターゲットをロード後に読み込む必要がある設計では、パラレルに実行するマッピングがシリアルに実行される場合があります。これは、データを、リモート・ソースから移動する場合や同じ表にバインドされた2つのターゲットにロードする場合に発生します。
手動コミット制御を有効にすると、Warehouse Builderでは、PELがオフの状態でマッピングが実行されます。
この項では、マッピング設計に依存しないデータのコミットについて、2つの手順を説明します。最初の手順では、マッピングを実行してから、SQL*Plusセッションでデータをコミットする方法を説明します。この手順では、複数マッピングを実行してからデータをコミットする計画をテストしてデバッグします。次に、2番目の手順でその計画を自動化します。
両方の手順とも、各PL/SQLマッピングで生成されるメイン・プロシージャの使用を前提にしています。
メイン・プロシージャは、Warehouse Builderでマッピングを開始するためのロジックを示すプロシージャです。このプロシージャは、PL/SQLスクリプトで使用したり、インタラクティブなSQL*Plusセッションで使用できます。
メイン・プロシージャを使用するときは、必須パラメータのp_statusを指定する必要があります。また、表22-4に示すように、マッピングの実行に関連する他のパラメータをオプションで指定できます。オプション・パラメータを指定しない場合、Warehouse Builderではデフォルト設定が使用されます。
表22-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);
最初の行では、表22-4で説明している定義済status変数を宣言します。2行目では、p_statusがstatus変数に設定されます。map1が完了すると、SQL*Plusによって、OKなどのマッピング・ステータスが表示されます。
2番目のマッピングであるキューブ・マッピング（この例ではmap2）を実行します。
2番目のマッピングは、最初のマッピングと同じ方法で実行できます。または、表22-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アクティビティを使用してプロセス・フローを設計します。
典型的なプロセス・フローでは、マッピングごとにマッピング・アクティビティを追加し、プロセス・フローで各マッピング・アクティビティ後に暗黙的なコミットを実行します。ただし、この設計では、マッピング・アクティビティを追加しないでください。かわりに、1つのSqlplusアクティビティを追加してください。
メイン・プロシージャを使用する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スクリプトをSqlplusアクティビティに貼り付けます。
エディタ・エクスプローラで、Sqlplusアクティビティの下のSCRIPTを選択し、オブジェクト・インスペクタの「値」 をダブルクリックします。
図22-8は、SCRIPTが選択されている「エクスプローラ」パネルおよび「オブジェクト・インスペクタ」パネルを示しています。
オプションで、「スケジュールを定義および使用するプロセス」の手順に従って、スケジュールをプロセス・フローに適用します。
マッピング、プロセス・フローおよびスケジュール（定義した場合）を配布します。
複数ターゲットのマッピングを設計するときは、Warehouse Builderによるターゲットのロードが特定の順序で行われることを確認する場合があります。これは、あるターゲットの1つの列が別のターゲットからデータを導出する場合があるためです。
PL/SQLマッピングにおける参照整合性を確認する手順は、次のとおりです。
複数ターゲットのPL/SQLマッピングを設計します。
（オプション）外部キーを指定して、2つのターゲット間に親子関係を定義します。
子表の外部キーは、親表の主キーを参照している必要があります。主キーとして定義した列が親にない場合は、列を追加して主キーとして定義する必要があります。この方法の例は、「SQL*Loaderマッピングでの参照整合性を確認するための従来のロードの使用」を参照してください。
マッピングのプロパティで、このプロパティの右にある省略ボタンボタンをクリックして、「ターゲット・ロード順序」プロパティを表示します。
前の手順で外部キー関係を定義した場合、Warehouse Builderでは、子の前に親ターゲットをロードするデフォルトのロード順序が計算されます。外部キーを定義していない場合は、「ターゲット・ロード順序」ダイアログ・ボックスを使用して、ロード順序を定義します。
詳細は、「ターゲット・ロード順序」を参照してください。
「ターゲット・ロード順序付けを使用」構成プロパティが、デフォルト値のTRUEに設定されていることを確認します。
この項の内容は次のとおりです。
マスター・ディテール構造を持つ複数レコード・タイプのファイルからデータを抽出して表にマッピングする場合は、順序のマッピング演算子をマッピングに追加して、マスター・レコードとディテール・レコード間の関係をサロゲート主キーまたは外部キーの関係で保持します。マスター/ディテール・ファイル構造とは、マスター・レコードの後にディテール・レコードが続く構造です。例22-1では、"E"で始まるレコードは従業員（Employee）情報が保存されているマスター・レコードです。"P"で始まるレコードは、対応する従業員の給与（Payroll）情報が保存されているディテール・レコードです。
例22-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
例22-1では、マスター・レコードとディテール・レコード間の関係は、物理的なレコードの順序のみが継承されます。つまり、給与レコードはその前の従業員レコードに対応しています。ただし、これがディテール・レコードをそのマスターに関連付ける唯一の方法である場合、この関係は、Warehouse Builderによって各レコードがターゲット表にロードされるときに失われます。
マスター・レコードとディテール・レコードが共通フィールドを共有している場合は、その両レコード間の関係を維持できます。たとえば、例22-1の従業員IDのフィールドが従業員レコードと給与レコードの両方に存在する場合は、このフィールドを従業員表の主キー、給与表の外部キーとして使用すると、給与レコードを適切な従業員レコードに関連付けることができます。
ただし、共通フィールドがファイルに存在せず、マスター・レコードとディテール・レコードを結合できない場合は、順序列をマスター・ターゲットとディテール・ターゲットの両方に追加して、マスター・レコードとディテール・レコード間の関係を維持する必要があります（表22-5および表22-6を参照）。この追加する値を生成するには、順序のマッピング演算子を使用します。
表22-5は、例22-1にあるファイルからマスター・レコードを抽出したターゲット表を示しています。このマスター・レコードのターゲット表には、従業員情報が格納されています。列E1からE10には、フラット・ファイルから抽出したデータが格納されています。列E11は、マスター順序番号を格納するために追加された列です。この番号は従業員1人につき1ずつ増加します。
表22-5 マスター・レコードが格納されたターゲット表
| E1 | E2 | E3 | E4 | E5 | E6 | E7 | E8 | E9 | E10 | E11 |
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表22-6は、例22-1にあるファイルからディテール・レコードを抽出したターゲット表を示しています。このディテール・レコードのターゲット表には、給与情報が格納されており、従業員1人につき1つ以上の給与レコードが存在します。列P1からP6には、フラット・ファイルから抽出したデータが格納されています。列P7は、ディテール順序番号を格納するために追加された列です。各給与レコードの番号は、表22-5の対応する従業員レコードの番号と一致します。
この項では、マスター・ディテール・フラット・ファイルからレコードを抽出し、そのレコードを2つの異なる表にロードするマッピングの作成方法を説明します。1つのターゲット表にはマスター・レコードを格納し、もう1つのターゲット表にはフラット・ファイルからのディテール・レコードを格納します。2つの表間のマスター・ディテール関係を維持するには、順序のマッピングを使用します。
|
注意: この説明は、従来型パスによるロードを対象にしています。マスター・ディテール・レコードにダイレクト・パス・ロードを使用する手順は、「SQL*Loaderマッピングでの参照整合性を確認するためのダイレクト・パス・ロードの使用」を参照してください。 |
この手順では、このようなマッピングを構築するための一般的な方法を概説します。次に示す詳細な手順も参照してください。
マスター・ディテール・フラット・ファイルから抽出し、マスター/ディテール関係を維持するには、次の手順を実行します。
マスター・レコードとディテール・レコードで構成されたフラット・ファイル・ソースをインポートして、サンプリングします。
ファイルのサンプリング時にレコード・タイプに名前を指定する場合は、マスター・レコードとディテール・レコードに説明的な名前を割り当てます。これによって、今後はこれらのレコードを容易に識別できます。
図22-9は、部門と従業員情報が含まれた複数レコード・タイプのフラット・ファイルに対するフラット・ファイル・サンプル・ウィザードを示しています。（従業員レコードの）マスター・レコード・タイプにはEmployeeMasterという名前が指定され、（給与情報の）ディテール・レコード・タイプにはPayrollDetailという名前が指定されます。
図22-9 フラット・ファイルのマスター・レコード・タイプおよびディテール・レコード・タイプのネーミング
フラット・ファイル演算子をマッピング・エディタのキャンバスにドラッグ・アンド・ドロップし、データの抽出元のマスター・ディテール・ファイルを指定します。
順序演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
マスター・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前作成した既存のワークスペース表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成できます。次に、必要なすべてのフィールドをファイル演算子のマスター・レコードからマスター表演算子にマッピングまたはコピーし（列の作成）、アウトバウンド調整を実行して後で表を定義できるようにします。
この表には、ロードするマスター・フィールドに必要なすべての列と、順序の値をロードするための追加の数値列が含まれている必要があります。
ディテール・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前作成した既存のワークスペース表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成できます。次に、必要なすべてのフィールドをファイル演算子のマスター・レコードからマスター表演算子にマッピングまたはコピーし（列の作成）、アウトバウンド同期化を実行して後で表を定義できるようにします。
この表には、ロードするディテール・フィールドに必要なすべての列と、順序の値をロードするための追加の数値列が含まれている必要があります。
必要なすべてのフラット・ファイル・マスター・フィールドをマスター表に、ディテール・フィールドをディテール表にマッピングします。
図22-10に、このフィールドのマッピングを示します。
順序NEXTVAL属性を、マスター表の追加の順序列にマッピングします。
図22-10に、順序演算子のNEXTVAL属性からマスター表へのマッピングを示します。
順序CURRVAL属性を、ディテール表の追加の順序列にマッピングします。
図22-10は、マッピングが完成した状態を示しています。フラット・ファイルのマスター・フィールドはマスター・ターゲット表にマッピングされ、ディテール・フィールドはディテール・ターゲット表にマッピングされ、順序のマッピングの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を使用して、各ディテール行を、対応するマスター行の一意の識別子で更新します。
この手順では、このようなマッピングを作成するための一般的な方法を概説します。次に示す詳細な手順も参照してください。
フラット・ファイル・ソースのインポート方法の詳細は、「インポート・メタデータ・ウィザードの使用」を参照してください。
ソースとしてフラット・ファイルを使用する方法の詳細は、「フラット・ファイル演算子」を参照してください。
表演算子の使用方法の詳細は、「ワークスペース・オブジェクトにバインドする演算子の追加」を参照してください。
データ・ジェネレータ演算子の使用方法の詳細は、「データ・ジェネレータ演算子」を参照してください。
定数演算子の使用方法の詳細は、「定数演算子」を参照してください。
マッピングの構成方法の詳細は、「マッピング構成のリファレンス」を参照してください。
ダイレクト・パス・ロードを使用してマスター・ディテール・フラット・ファイルから抽出し、マスター・ディテール関係を維持する手順は、次のとおりです。
マスター・レコードとディテール・レコードで構成されたフラット・ファイル・ソースをインポートして、サンプリングします。
ファイルのサンプリング時にレコード・タイプに名前を指定する場合は、図22-9に示すように、マスター・レコードとディテール・レコードに説明的な名前を割り当てます。これによって、今後はこれらのレコードを容易に識別できます。
フラット・ファイル・ソースからデータをロードするために使用するマッピングを作成します。
フラット・ファイル演算子をマッピング・キャンバスにドラッグ・アンド・ドロップし、データの抽出元のマスター・ディテール・ファイルを指定します。
データ・ジェネレータ演算子および定数演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
マスター・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前作成した既存のワークスペース表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成し、アウトバウンド同期化を実行して後で表を定義できるようにします。
この表には、ロードするマスター・フィールドに必要なすべての列と、RECNUM値をロードするための追加の数値列が含まれている必要があります。
ディテール・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前作成した既存のワークスペース表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成し、アウトバウンド同期化を実行して後で表を定義できるようにします。
表には、ロードするディテール・フィールドに必要なすべての列と、RECNUM値をロードするための追加の数値列、および対応するマスター表の行の一意の識別子で更新する列が含まれている必要があります。
図22-12に示すように、必要なすべてのフラット・ファイル・マスター・フィールドをマスター表にマップし、ディテール・フィールドをディテール表にマップします。
図22-12に示すように、データ・ジェネレータ演算子のRECNUM属性を、マスター表とディテール表のRECNUM列にマッピングします。
定数演算子の定数属性を追加します。
マスター行の一意の識別子列がCHARデータ型である場合は、式'*'を使用して定数属性をCHAR型にします。
マスター行の一意の識別子列が数値である場合は、式'0'を使用して定数属性をNUMBERにします。
図22-11は、式プロパティが0に設定された定数属性を示しています。この定数は、すべてのデータ行がロード済であることを示しています。
定数演算子の定数属性をディテール表の列にマッピングします。この列には、対応するマスター表レコードの一意の識別子が後で格納されます。
図22-12は、マッピングが完成した状態を示しています。フラット・ファイルのマスター・フィールドはマスター・ターゲット表にマッピングされ、ディテール・フィールドはディテール・ターゲット表にマッピングされ、データ・ジェネレータ演算子のRECNUM属性はマスター・ターゲット表とディテール・ターゲット表にそれぞれマッピングされ、定数属性はディテール・ターゲット表にマッピングされています。
図22-12 ダイレクト・パス・ロードを使用したマスター・ディテール・フラット・ファイルからのマッピング
ダイレクト・モード: True
エラー許可: 0
後続NULL列: True（すべての表）
マッピングを検証し、SQL*Loaderスクリプトを生成した後は、更新後のPL/SQLプロシージャを作成し、それを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操作です。
図22-13は、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を使用して設計したマッピングにリモート・ソースまたは複数ソースの結合が含まれている場合、Warehouse Builderでは、パーティション交換を続行する前に、ソース処理を実行し、データをステージングする必要があります。したがって、このようなマッピングは、ダイレクトPELをfalseに設定した状態で構成します。Warehouse Builderでは、ソース処理の結果を格納する一時表が透過的に作成され、維持されます。この表は、PELの実行後に削除されます。
図22-14は、2つのソースを結合し、集計を実行するマッピングを示しています。ORDER_SUMMARY表にロードされたすべての新規データが常に同じパーティションにロードされる場合は、このマッピングで間接PELを使用して、ロードのパフォーマンスを改善できます。この場合、Warehouse Builderでは、アグリゲータ後かつORDER_SUMMARY前に、一時表が透過的に作成されます。
Warehouse Builderでは、ターゲット表と同じ構造（列、索引、制約が同じ）を使用して、一時表が作成されます。この一時表は、パフォーマンス向上のために、パラレル直接パス・ロードINSERTを使用してロードされます。INSERTの後、Warehouse Builderでは、一時表の索引と制約がパラレルで作成されます。
ソース表がローカルで、データの品質が高い場合は、ダイレクトPELを使用します。マッピングは、ソースとターゲットが同じデータベースにあり、完全に同じ構造であるように設計する必要があります。ソースとターゲットの索引、制約、列数、列タイプおよび列の長さは、すべて同じである必要があります。
たとえば、図22-14でのマッピングと同じマッピングがあり、データをターゲットにロードするタイミングをより細かく制御するとします。データ量によってはロードに数時間がかかり、現状では、ターゲット表がいつ更新されるかもわかりません。
ダイレクトPELを使用してデータを即時にターゲットにロードする手順は、次のとおりです。
ソース・データを結合し、必要に応じてデータを変換し、確実に検証してステージング表にロードするマッピングを1つ設計します。このマッピングはPELを使用するように構成しないでください。
ステージング表を、別のマッピングでロードする最終ターゲットの構造に正確に一致するように設計します。たとえば、図22-14にあるステージング表のORDER_SUMMARYは、図22-15にある最終ターゲットORDER_CUBEと同じ構造である必要があります。
図22-15に示すように、ステージング表から最終ターゲットにデータをロードする2番目のマッピングを作成します。このマッピングはダイレクトPELを使用するように構成してください。
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進数の数字が入ります。すべての文字は、大文字にする必要があります。小文字は認識されません。
各パーティションを正しく命名すると、各パーティションの「上限値」プロパティが自動的に計算されます。そうでない場合は、Warehouse BuilderでDDL文が作成されるように、上限値を各パーティションに対して手動で構成する必要があります。次に、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: 「LOCAL」オプションを使用したすべての索引の作成」で作成したORDER_SUMMARY_PK_IDXです。
Warehouse BuilderでのPELの使用には、次の制限があります。
日付パーティション・キーは1つのみ: 許容されるDATEデータ型のパーティション・キー列は1つのみです。数値パーティション・キーは、Warehouse Builderではサポートされていません。
一般的なカレンダのみ: 現在のPELメソッドは、世界中で採用されている一般的なカレンダのみをサポートしています。ユーザー定義の会計年度別や四半期別のビジネス・カレンダは、現時点ではサポートされていません。
すべての日付パーティションが同じ表領域内にあること: ターゲット（表、ディメンションまたはキューブ）のすべてのパーティションは、同じ表領域内に作成される必要があります。
すべての索引パーティションが同じ表領域内にあること: ターゲット（表、ディメンションまたはキューブ）のすべての索引は、同じ表領域内に作成される必要があります。ただし、索引とデータでは、別の表領域を使用できます。
データベース・リンクを介してリモート・ソースにアクセスするマッピングを設計できますが、大量のデータを移動するとパフォーマンスが低下する可能性があります。同じバージョンのOracleデータベースのソースとターゲット間で大量のデータを移動するマッピングについては、トランスポータブル・モジュールを使用して、パフォーマンスを大幅に改善するためのオプションがあります。
|
関連項目: トランスポータブル・モジュールを使用する手順は、Oracle Warehouse Builderインストレーションおよび管理ガイドの大量のデータの移動に関する項を参照してください。 |
設計フェーズの前半では、Warehouse Builderの設計オブジェクトを使用してターゲット・システムの論理モデルを定義しました。この章では、マッピングとプロセス・フローに物理プロパティを割り当てるためのリファレンス情報を提供します。構成プロパティは、ユーザー・インタフェースに表示される順序で示されています。
この章の内容は次のとおりです。
マッピングを適切に構成すると、ETLのパフォーマンスを向上させることができます。そのためには、この項を参考にして、データのロード方法とコードの最適化方法を制御する構成パラメータを設定します。
この項の内容は次のとおりです。
マッピングの物理プロパティを構成する手順は、次のとおりです。
プロジェクト・エクスプローラでマッピングを右クリックして、「構成」を選択します。
Warehouse Builderにはマッピングの「構成プロパティ」ダイアログ・ボックスが表示されます。マッピングのプロパティおよびマッピング内の演算子を構成できます。
「配布可能」を選択し、配布可能としてマークされたマッピング・エンティティについて一連のスクリプトを生成できるようにします。
「配布可能」はデフォルトで有効になっています。これを無効にすると、そのマッピングのスクリプトは生成されません。
「言語」を、選択したマッピング用に生成するコードのタイプに設定します。
選択できるオプションは、マッピングにおける演算子の設計と使用に応じて異なります。Warehouse Builderでは、マッピングに応じて「PL/SQL」、「SQL*Loader」、「ABAP」（SAPソース・マッピングの場合）などの適切な値に設定されます。
あらかじめ定義したスケジュールに基づいてマッピングを実行するように設定する場合は、「参照カレンダ」をクリックします。
スケジュールの作成および使用手順は、第26章「ETLオブジェクトのスケジューリング」を参照してください。
ランタイム・パラメータ を展開して、配布するマッピングを構成します。
各ランタイム・パラメータの詳細は、「ランタイム・パラメータ」を参照してください。
「コード生成オプション」を開き、マッピング用に生成されたコードを最適化するパフォーマンス・オプションを有効化します。
各オプションの詳細は、「コード生成オプション」を参照してください。
マッピングの各演算子を表すノードに移動して、それぞれの物理プロパティを設定します。
マッピングのソースとターゲットの構成方法は、「ソースとターゲットのリファレンス」を参照してください。フラット・ファイルのソースとターゲットを使用してマッピングを構成するには、「フラット・ファイル演算子の構成」を参照してください。
マッピングのランタイム・パラメータの構成時に、マッピングのデフォルト動作を設定します。これらのパラメータは、コントロール・センター、プロセス・フロー・エディタまたはOracle Enterprise Managerでマッピングを実行する際に上書きできます。
「ランタイム・パラメータ」には、次のパラメータがあります。
「バルク・サイズ」を使用して、PL/SQLバルク処理の各バルクの行数を指定します。Warehouse Builderで「バルク・サイズ」パラメータが使用されるのは、「バルク処理コード」オプションを選択し、オペレーティング・モードを「行ベース」に設定している場合のみです。詳細は、Oracle PL/SQLリファレンス・ガイドを参照してください。
「表分析文」オプションを選択すると、Warehouse Builderではターゲット表の統計の収集時期が予想されます。データがターゲット表にロードされた後、各ターゲット表についてコストベース最適化に使用された統計が収集されます。このパラメータは、各ターゲット表でこの分析に使用された行の割合に設定できます。
コミット頻度は、非バルク・モードのマッピングにのみ適用されます。バルク・モードのマッピングは、バルク・サイズに従ってコミットされます。
「デフォルト・オペレーティング・モード」を「行ベース」に設定し、「バルク処理コード」の選択を解除した場合には、「コミット頻度」パラメータを使用して、コミット前に処理する行数を指定します。このパラメータで指定した行数を処理すると、Warehouse Builderがデータをデータベースにコミットします。
「バルク処理コード」オプションを選択した場合は、「コミット頻度」を「バルク・サイズ」と同じ値に設定します。2つの値が異なる場合は、「バルク・サイズ」が「コミット頻度」に優先し、コミットはバルク・サイズごとに暗黙的に実行されます。
PL/SQL実装を使用したマッピングについて、デフォルト・オペレーティング・モードを選択します。選択したオペレーティング・モードは、マッピングのパフォーマンスに大きく影響する可能性があります。オペレーティング・モードがパフォーマンスに及ぼす影響の詳細は、「セット・ベースと行ベースのオペレーティング・モードの比較」を参照してください。次のオペレーティング・モードから1つ選択できます。
セット・ベース: すべてのデータを挿入し、そのデータに対してすべての操作を実行するSQL文が1つ生成されます。これにより、データ操作言語（DML）操作が高速になります。セット・ベース・モードは最適なパフォーマンスを提供しますが、生成される監査詳細は最小限となります。
行ベース: データを1行ずつ処理する文が生成されます。SELECT文はSQLカーソルです。以降の文はすべてPL/SQLです。データが1行ずつ処理されるため、行ベースのオペレーティング・モードではパフォーマンスが最低ですが、監査は最も詳細になります。
行ベース(ターゲットのみ): CURSOR SELECT文が生成され、カーソルにできるかぎり多数の操作が追加されます。ターゲットごとにPL/SQL INSERT文が生成され、各行がターゲットに個別に挿入されます。
セット・ベースから行ベースへのフェイルオーバー: マッピングがセット・ベース・モードで実行されます。エラーが発生すると実行に失敗し、マッピングが行ベース・モードで再開されます。このモードはテスト環境で使用する場合にのみお薦めします。本番環境での使用はお薦めしません。
セット・ベースから行ベース(ターゲットのみ)へのフェイルオーバー: 最初にセット・ベース・モードでマッピングが実行されます。エラーが発生すると、実行が行ベース（ターゲットのみ）モードにフェイルオーバーします。このモードはテスト環境で使用する場合にのみお薦めします。本番環境での使用はお薦めしません。
「デフォルト監査レベル」を使用して、パッケージの実行時に使用する監査レベルを指定します。監査レベルは、パッケージの実行時にランタイム・スキーマ内で取得される監査情報の量を示します。監査レベルの設定は、次のとおりです。
なし: 実行時に監査情報は記録されません。
統計: 実行時に統計監査情報が記録されます。
エラーの詳細: 実行時にエラー情報と統計監査情報が記録されます。
完了: 実行時にすべての監査情報が記録されます。監査レベルを「完了」に設定してマッピングを実行すると、大量の診断データが生成され、割当済の表領域がすぐにいっぱいになってしまう可能性があります。
「デフォルト・パージ・グループ」はパッケージの実行時に使用されます。ランタイム・スキーマ内の各監査レコードは、指定したパージ・グループに割り当てられます。
このオプションを選択すると、ANSI SQL構文が生成されます。このオプションを選択しなければ、Oracle SQL構文が生成されます。
自動: これはデフォルト設定です。マッピング設計に基づいてデータがロードされ、自動的にコミットされます。この設定は、すべてのマッピング・タイプに有効です。1つのマッピングに複数のターゲットが存在する場合、データはターゲット単位の処理（INSERT、UPDATE、DELETE）に基づいてコミットされます。
自動相関: 自動相関コミットは特殊なタイプの自動コミットであり、複数のターゲットを持つPL/SQLマッピングにのみ適用されます。Warehouse Builderでは、すべてのターゲットが集合的に考慮され、データはすべてのターゲット間で均一にコミットまたはロールバックされます。
マッピング動作は、選択したオペレーティング・モードに応じて異なります。相関コミットの詳細は、「単一ソースから複数ターゲットへのデータのコミット」を参照してください。
手動: 手動コミット制御を選択するのは、複雑なビジネス・ロジックを示したりデータのコミット前に検証を実行する必要のあるPL/SQLマッピングの場合です。
手動コミットの指定には、次のオプションが用意されています。
「マッピングへのコミット・ロジックの埋込み」の説明に従って、マッピング内のコミット・ロジックを定義できます。
「マッピング設計に依存しないデータのコミット」の説明に従って、プロセス・フローまたはSQLPlusセッションでデータをコミットする方法もあります。
コミットなし: このオプションを設定すると、OWBマッピングはマッピングの実行中にコミットを発行しません。
このオプションを選択すると、ロード後のターゲット表が元のサイズの2倍または半分の場合に、ターゲットのロード後にターゲット表を分析するためのコードが生成されます。
ターゲット表がマッピングと同じスキーマにない場合に、その表を分析するには、マッピングを所有するスキーマにANALYZE ANYを付与する必要があります。
このオプションを選択すると、実行時にパラレルDMLが有効化されます。DML文をパラレルに実行することで、データ・ウェアハウスに存在する大規模データベースにおけるデータ集中型操作のレスポンス時間が短縮されます。
このオプションを選択すると、スプリッタ演算子と複数のターゲット表への挿入が含まれているマッピングのパフォーマンスが向上します。このオプションを選択してOracle 9i以降でマッピングを実行すると、1つのSQL文（multi_table_insert）が生成されます。このSQL文は、同一のソース・データ・セットに基づいたデータを複数の表に挿入します。
複数表挿入が実行されるのは、このオプションが選択されていて、Oracleターゲット・モジュール・データベースがOracle 9i以降の場合のみなので注意してください。スプリッタ演算子が含まれていて、スプリッタとターゲットの間にアグリゲータ演算子やジョイナ演算子などのアクティブな演算子が存在しないセット・ベース・モードのマッピングに対してのみ、複数表挿入が実行されます。なお、複数挿入を使用できるのは表の場合のみで、ビュー、マテリアライズド・ビュー、ディメンションまたはキューブには使用できません。各ターゲット表の列数は999より少なくなるようにする必要があります。複数のターゲットを使用するマッピングの作成手順の詳細は、「例: 複数のターゲットを使用するマッピングの作成」を参照してください。
行ベース・モードで実行されるマッピング、またはOracle 8iサーバーで実行されるマッピングに対してこのオプションは選択しません。また、監査が要求された場合もこのオプションを選択しません。
このオプションを選択した場合、すべてのターゲットについてSELECTとINSERTの合計カウントが1つ戻されます。
コードの生成時に使用するAUTHIDオプションを指定します。オプションは「Current_User」、「Definer」または「None」のいずれかを選択できます。
複数のターゲットを持つPL/SQLマッピングの場合は、ターゲットのロード順序を定義するコードを生成できます。この順序は、マッピングの複数のターゲット間に親子関係が存在する場合に重要になります。このオプションはデフォルトで選択されます。
このフィールドで、エラー・トリガー・プロシージャの名前を指定します。
この構成パラメータを選択し、オペレーティング・モードを「行ベース」に設定すると、Warehouse BuilderでPL/SQLバルク処理コードが生成されます。PL/SQLバルク処理では、行を1行ずつではなくバルク単位で収集、処理して書き込むことにより、行ベースETLのパフォーマンスが向上します。各バルクのサイズは、構成パラメータ「バルク・サイズ」により決定されます。最適なパフォーマンスが得られるのはセット・ベース・モードで、続いてバルク処理、最後が行ベース・モードです。詳細は、Oracle PL/SQLリファレンス・ガイドを参照してください。
デフォルトでは、マッピング用のコードの生成時に、可能な全オペレーティング・モードのためのコードが生成されます。つまり、「生成モード」が「すべてのオペレーティング・モード」に設定されている場合は、「デフォルト・オペレーティング・モード」を「セット・ベース」に設定しても、可能な全オペレーティング・モードのためのコードが生成されます。これにより、実行時にテストの目的でオペレーティング・モードを切り替えることができます。
表、ビューおよびキューブなど、リレーショナルおよびディメンショナルなソースとターゲットの場合、Warehouse Builderでは演算子ごとに次の一連のプロパティが表示されます。
デフォルトではこの設定が有効になっており、LCR APIが使用可能な場合はLCR APIを使用してDMLが実行されます。LCR APIが使用できない場合は、標準的なDMLが使用されます。
このパラメータは、下位互換性のためにのみ維持されています。
以前のリリースでは、データベース・リンクをリストから名前で選択できました。スキーマとデータベース・リンクについてソース演算子は構成できましたが、ターゲットを構成できるのはスキーマの場合のみです。ソースとターゲットを異なるスキーマに配置できますが、両者は同じデータベース・インスタンスに存在する必要があります。
この設定では、ソース演算子またはターゲット演算子へのアクセスに使用するロケーションを指定します。
この設定を有効化すると、LCR APIを使用したDML中に生じる可能性のある競合を検出して解決できます。
このパラメータは、下位互換性のためにのみ維持されています。
以前のリリースでは、「スキーマ」フィールドをクリックして名前を入力すると、マッピングを特定のスキーマにリンクできました。
このセクションの設定を使用して、ターゲット表へのパーティション交換ロード（PEL）を有効化します。それぞれの設定に固有の情報と、PEL用のマッピングの設計方針は、「パーティション交換ロードを使用したパフォーマンスの向上」を参照してください。
ロードまたは抽出のヒントを定義します。アプリケーション開発者は、データを処理する方法を絶えず発展させていくものです。たとえば、開発者は、一連の表をどのような順序で結合すると問合せの実行速度が大幅に向上するかを把握しています。Warehouse Builderでは、このような処理方法を、生成済SQLコードのパッケージにSQLオプティマイザ・ヒントとして組み込むことができます。
「ヒント」ダイアログ・ボックスからヒントを選択する場合、ヒントは「既存のヒント」フィールドに表示されます。付加テキスト列に適切な付加テキストを入力します。エディタによってマッピング定義にヒントがそのまま追加されます。このテキストの検証やチェックは行われません。
INSERTまたはUPDATEモードでデータをロードするマッピングに対して、ロードのヒントを定義できます。デフォルトでは、APPENDやPARALLELなどの一般に使用されるヒントが追加されます。INSERTを除くすべてのロード・モードでは、APPENDヒントは効果がないため、削除することも可能です。
ヒントはマッピング構成時に表示できます。ヒントを構成する手順は次のとおりです。
プロジェクト・エクスプローラで、「データベース」フォルダを開きます。
「データベース」で、「リポジトリ」モジュールを開きます。
「リポジトリ」モジュールで、「マッピング」を開きます。
「マッピング」で、必要なマッピングを選択します。
「マッピング」を右クリックして、「構成」を選択します。
構成プロパティ・ウィンドウで、必要な演算子を開きます。
ファンクション演算子を選択します。
インライン・ビューのヒント・ウィンドウを開くには、構成プロパティ・ウィンドウの「インライン・ビューのヒント」オプションの横にある省略記号ボタンをクリックします。
オプティマイザ・ヒントとその使用方法の詳細は、Oracle 9i Designing and Tuning for Performanceを参照してください。
次の制約管理パラメータを構成します。
例外表名: 再有効化中に外部キー制約に違反したすべての行が、指定の例外表に記録されます。ロード前後には、この表の自動切捨ては実行されません。制約違反はランタイム監査エラー表にもロードされます。
SQLおよびPL/SQLロードの場合、例外表を指定しなければ、無効な行はデフォルト表領域にある一時表にロードされてから、ランタイム監査エラー表にロードされます。ロードが終了すると、表が削除されます。
SQL*Loaderのダイレクト・パス・ロードを使用している場合は、例外表を指定する必要があります。詳細は、SQL*Loaderのマニュアルを参照してください。
制約の有効化: このオプションを選択すると、データのロード前にターゲット表の外部キー制約が保存されます。このオプションを選択しなければ、ターゲット表の外部キー制約はデータのロード前に無効化され、ロード後に再度有効化されます。再度有効化する間に見つかった制約違反はランタイム監査エラー表で識別され、指定した場合は例外表にロードされます。
制約を無効化すると、制約チェックが実行されないためロード速度が向上します。ただし、再有効化中にいずれかの行で例外が発生すると、その行に対する制約は未検証状態のままになります。この種の行は、そのROWIDを使用してランタイム監査エラー表に記録されます。エラー行を手動で検査し、必要な訂正処理を行う必要があります。
制約の有効化および無効化はターゲット表に対して行われます。「制約の有効化」プロパティを無効化すると、ターゲット表の制約はデータをロードする前に無効化され、データをロードした後に再有効化されます。制約が再有効化されると、表全体がスキャンされ、制約に違反する行が例外表に記録されて監査ブラウザに制約違反エラーとしてレポートされます。
ターゲット表が空で、「制約の有効化」プロパティが無効化されているシナリオについて考えます。最初に、ソース表には10行あり、そのうち2行がターゲット表の制約に違反しているとします。マッピングを実行すると、まずターゲット表の制約が無効化されます。次に、データ（10行すべて）がロードされてからターゲット表の制約が再有効化されます。制約が再有効化されると、制約に違反する2行が例外表に記録されます。監査ブラウザによって、2つの制約違反エラーがあることがレポートされます。
その後、ターゲット表の制約に違反する5行を含む20行から構成される新規ソース表を使用して、マッピングが再度実行されます。データ（20行すべて）がターゲット表にロードされると、ターゲット表は30行になります。ターゲット表の制約が再有効化されると、7行が例外表に記録されて制約違反エラーとして監査ブラウザでレポートされます。この7行は、最初にレポートされた2行と、新規にレポートされた5行から構成されます。これは、Warehouse Builderがターゲット表全体をスキャンするためです。30行すべてがチェックされるため、最初のデータ・ロードの違反ありの2行も含まれます。Warehouse Builderでは、マッピングが2回目に実行されたときに追加された新規の行のみの識別はできません。したがって、データをロードするたびに事前にターゲット表を切り捨てないかぎり、以前のデータ・ロードの制約違反が必ず毎回レポートされます。
「制約の有効化」を選択解除に設定するには、次の制限を伴います。
「セット・ベース」オペレーティング・モードの場合、「選択解除」に設定すると、ターゲットの外部キー制約がロード前に無効化され、ロード後に再有効化されます。このプロパティは、ターゲット表を参照する他の表の外部キー制約には影響しません。ロードにSQLまたはPL/SQLパッケージではなくSQL*Loaderが使用される場合は、.ctlファイルに再有効化句が追加されます。
オペレーティング・モードが「セット・ベースから行ベースへのフェイルオーバー」および「セット・ベースから行ベース(ターゲットのみ)へのフェイルオーバー」の場合、選択解除に設定すると、ターゲットの外部キー制約がロード前に無効化され、セット・ベース・モードによるロードに成功した場合は再有効化されます。この設定は、他の表を参照している外部キーには影響しません。ロードが行ベースにフェイルオーバーした場合は、行ベース・モードでロードが繰り返され、すべての制約は有効化されたままになります。
|
注意: 再有効化中に制約違反が作成されると、ロードはセット・ベース・モードから行ベース・モードにフェイルオーバーしません。 |
「行ベース」または「行ベース(ターゲットのみ)」オペレーティング・モードの場合は、このオプションが選択されなくても、すべての外部キー制約は有効化されたままです。
TRUNCATE/INSERT DMLタイプの場合は、選択解除に設定すると、デフォルト・オペレーティング・モードに関係なく、ターゲット表を参照する他の表の外部キー制約がロード前に無効化されてロード後に再有効化されます。
フラット・ファイルからの入力を含む表演算子を使用する場合は、次の「SQL*Loaderパラメータ」プロパティを構成する必要があります。
パーティション名: ロードがパーティション・レベルであることを示します。パーティション・レベル・ロードでは、表で指定した1つ以上のパーティションまたはサブパーティションをロードできます。完全データベース、ユーザーおよびトランスポータブル表領域の各モードによるロードでは、パーティション・レベル・ロードはサポートされていません。増分ロード（増分、累積および完了）を実行できるのは完全データベース・モードの場合のみで、増分ロードにパーティション・レベル・ロードは指定できません。どのモードでも、パーティション化されたデータは、パーティションまたはサブパーティションを選択的にロードできるような形式でロードされます。
ソート済索引句: データの事前ソートに使用される索引を識別します。この句を使用できるのは、ダイレクト・パス・ロードの場合のみです。ある索引用にソートされたデータの順序は、通常、他の索引には適切でないため、SORTED INDEXES句には索引を1つのみ指定します。複数の索引でデータが同じ順序の場合は、一度にすべての索引を指定できます。SORTED INDEXES句にリストされた索引はすべて、ダイレクト・パス・ロードの開始前に作成しておく必要があります。
単一行: システムのメモリーに制限がある場合や、大きい表に少数のレコードをロードする場合に、ダイレクト・パス・ロード中にAPPENDとともに使用することを意図しています。このオプションを選択すると、各索引エントリは一度に1レコードずつ索引に直接挿入されます。SQL*Loaderでは、デフォルトで表にレコードを追加するためにSINGLEROWが使用されることはありません。索引エントリは一時領域に格納され、ロードの終了時に元の索引とマージされます。この方法ではパフォーマンスが向上して最適な索引が生成されますが、余分な記憶域が必要になります。マージ中には、元の索引、新規の索引、新規エントリ用の領域が、すべて同時に記憶域を使用します。SINGLEROWオプションを使用すると、新規索引エントリや新規索引のための記憶域を必要としません。生成後の索引は新規にソートした索引ほど最適でない可能性はありますが、生成に使用される領域は少なくなります。また、索引の挿入ごとにUNDO情報が追加生成されるため、所要時間も長くなります。このオプションは、使用可能な記憶域がかぎられている場合や、ロード対象のレコード数が表のサイズに比べて小さい（1:20以下である）場合にお薦めします。
後続NULL列: SQL*Loaderを、レコードに存在せずに相対位置を持つ列をNULL列として処理するように設定します。
スキップ対象レコード: SQL*LoaderでSKIPコマンドを起動します。SKIPでは、ファイルの先頭を基準にしてロード対象外となる論理レコードの数を指定します。デフォルトでは、レコードはスキップされません。このパラメータを指定すると、なんらかの理由で中断されたロードが続行されます。これは、すべての従来型パスによるロード、単一表のダイレクト・ロード、各表にロードされるレコード数が同一の場合の複数表のダイレクト・ロードに使用されます。各表にロードされるレコード数が異なる場合、複数表のダイレクト・ロードには使用されません。
データベース・ファイル名: インポートするエクスポート・ファイルの名前を指定します。デフォルト拡張子は.dmpです。複数のエクスポート・ファイルをエクスポートできるため、インポート対象ファイル名の複数指定が必要になることがあります。インポートされたファイルへの読取りアクセス権限が必要です。また、IMP_FULL_DATABASEロールも必要です。
「構成プロパティ」ダイアログ・ボックスには、マッピングでの演算子の使用方法によっては、フラット・ファイルのマッピング演算子に関する追加設定が表示されます。
ターゲットとしてのフラット・ファイル演算子: PL/SQL配布コード・パッケージが生成されます。ターゲットとして使用するフラット・ファイルのマッピング演算子に関連するパラメータの構成については、「ターゲットとしてのフラット・ファイル演算子」を参照してください。
ソースとしてのフラット・ファイル演算子: SQL*Loaderスクリプトが生成されます。ソースとして使用するフラット・ファイルのマッピング演算子に関連するパラメータについては、「ソースとしてのフラット・ファイル演算子」を参照してください。
フラット・ファイルをターゲットとして使用するマッピングに固有のプロパティを構成する手順は、次のとおりです。
プロジェクト・エクスプローラでマッピングを選択し、メニュー・バーから「設計」→「構成」を選択します。
または、構成するマッピングを右クリックして、「構成」を選択します。
Warehouse Builderに「構成プロパティ」ダイアログ・ボックスが表示されます。
構成するパラメータを選択し、パラメータ名の右側の空白をクリックしてパラメータ値を編集します。
パラメータごとに、リストからオプションを選択するか、値を入力するか、または省略記号ボタンをクリックして別の「プロパティ」ダイアログ・ボックスを表示できます。
「配布可能」オプションを選択し、配布可能としてマークされたマッピング・オブジェクトについて一連のスクリプトを生成します。このオプションを選択していないマッピングの場合、スクリプトは生成されません。
「言語」を、選択したマッピング用に生成するコードのタイプに設定します。選択できるオプションは、マッピングにおける演算子の設計と使用に応じて異なります。マッピングに応じて、「PL/SQL」、「ABAP」（SAPソース・マッピングの場合）または「SQL*Loader」から選択できます。
マッピングの配布先ロケーションを指定します。
「ランタイム・パラメータ」で、「デフォルト・オペレーティング・モード」を「行ベース(ターゲットのみ)」に設定します。このタイプのマッピングの場合、他のデフォルト・オペレーティング・モードではコードが生成されません。各ランタイム・パラメータの詳細は、「ランタイム・パラメータ」を参照してください。
「コード生成オプション」の説明に従って「コード生成オプション」を設定します。
「ソースとターゲットの参照」の説明に従って「ソースとターゲットの参照」を設定します。
「アクセス指定」では、「ターゲット・データファイル名」にフラット・ファイル・ターゲットの名前を指定します。「ターゲット・データファイルのロケーション」では、Runtime Platformがインストールされているコンピュータにあるターゲット・ファイルを指定します。出力をxmlファイルにする場合は、「XMLファイルとして出力」を選択します。
フラット・ファイル演算子をソースとして使用するマッピングを構成する手順は、次のとおりです。
プロジェクト・エクスプローラでマッピングを選択し、メニュー・バーから「設計」→「構成」を選択します。または、構成するマッピングを右クリックして、「構成」を選択します。
構成するパラメータを選択し、パラメータ名の右側の空白をクリックしてパラメータ値を編集します。
各パラメータについて、選択するかどうかを指定するか、リストからオプションを選択するか、値を入力するか、省略記号ボタンをクリックして他の「プロパティ」ダイアログ・ボックスを表示できます。
SQL*Loaderスクリプトが生成されるように「配布可能」オプションを選択します。
「ログ・ファイルのロケーション」と「ログ・ファイル名」を指定します。
「ロード継続」を選択します。
SQL*Loaderによりデータ行または索引エントリのための領域がすべて使用されてしまうと、ロードが中断されます。「ロード継続」オプションが選択されている場合は、中断したロードの継続が試行されます。
「NLSキャラクタ・セット」で、CHARACTERSET句に置くキャラクタ・セットを指定します。
「ダイレクト・モード」を選択して、ダイレクト・パス・ロードが実行されるように指定します。このオプションを設定しなければ、従来型パスによるロードが実行されます。通常はダイレクト・モードの方が高速です。
「リカバリ可能操作」を選択してロードがリカバリ可能になるように指定します。このオプションを選択しなければ、ロードはリカバリ不可能になり、レコードはREDOログに記録されません。
フラット・ファイル・ソースを使用したマッピング用に生成されるSQL*LoaderスクリプトのOPTIONS句に影響する次のパラメータを構成します。
パラレル・ロードの実行: このオプションを選択すると、ダイレクト・ロードを複数のコンカレント・セッションで実行できます。
エラー許可: 0（ゼロ）より大きい値を指定すると、ERRORS = nオプションが生成されます。SQL*Loaderは、このエラー上限に達した後の最初の一致ポイントでロードを終了します。
スキップ対象レコード: 0より大きい値を指定すると、SKIP = nオプションが生成されます。この値は、ファイルの先頭を基準としてロード対象外のレコード数を示します。値を指定しなければ、レコードはスキップされません。
ロード対象レコード: 0より大きい値を指定すると、LOAD = nオプションが生成されます。この値は、ロード対象の最大レコード数を示します。値を指定しなければ、すべてのレコードがロードされます。
コミットごとの行: 0より大きい値を指定すると、ROWS = nオプションが生成されます。ダイレクト・パス・ロードの場合、この値はデータの保存前にソースから読み取る行数を識別します。従来型パスによるロードの場合は、バインド配列の行数を指定します。
読取りサイズ: 0より大きい値を指定すると、READSIZE = nオプションが生成されます。この値は、読取りバッファのサイズ指定に使用されます。
バインド・サイズ: 0より大きい値を指定すると、BINDSIZE = nオプションが生成されます。この値は、バインド配列の最大バイト数を示します。
読取りバッファ: 0より大きい値を指定すると、READBUFFERS n句が生成されます。READBUFFERSでは、ダイレクト・パス・ロード中に使用するバッファの数を指定します。READBUFFERSの値は、必要な場合にのみ指定してください。
空白を保持: このオプションを選択すると、PRESERVE BLANKS句が生成されます。この句により、オプションの囲みデリミタが存在しない場合に先行の空白が保持されます。また、事前に決定済のサイズでフィールドが指定されている場合も、後続の空白がそのまま保持されます。
データベース・ファイル名: このパラメータを使用すると、ロード対象の物理ファイルの特性を指定できます。これらのパラメータの初期値は、マッピングに使用するフラット・ファイルのプロパティから設定されます。
このパラメータを空白以外の値に設定すると、FILE=オプションが生成されます。指定した値は、生成コードでは一重引用符で囲まれます。
制御ファイルのロケーションおよび制御ファイル名: 監査詳細に必要な制御ファイル名。
SQL*Loaderオプションおよび句の詳細は、Oracle Databaseユーティリティを参照してください。
「ランタイム・パラメータ」を開き、マッピングを配布用に構成します。
監査: このオプションを設定すると、パッケージの実行時に監査が実行されます。
デフォルト・パージ・グループ: 「デフォルト・パージ・グループ」はパッケージの実行時に使用されます。ランタイム・スキーマ内の各監査レコードは、指定したパージ・グループに割り当てられます。
ソースとターゲットの参照を開き、「ソースとターゲットの参照」の説明に従ってマッピングの演算子の物理プロパティを設定します。
プロセス・フロー・モジュールを構成する手順は、次のとおりです。
プロセス・フロー・モジュールを右クリックして「構成」を選択します。
プロセス・フロー・モジュールの「構成プロパティ」ダイアログ・ボックスが表示されます。
「評価ロケーション」と「識別ロケーション」のプロパティを設定します。
「評価ロケーション」は、このプロセス・フローの評価元ロケーションです。
「識別ロケーション」は、生成済コードの配布先ロケーションです。
プロセス・フロー・パッケージを構成する手順は、次のとおりです。
プロセス・フロー・パッケージを右クリックして「構成」を選択します。
プロセス・フロー・モジュールの「構成プロパティ」ダイアログ・ボックスが表示されます。
「参照カレンダ」と「生成コメント」のプロパティを設定します。
「参照カレンダ」は、このパッケージに関連付けるスケジュールを提供します。
「生成コメント」は、生成済コードに関する追加のコメントを提供します。
パッケージのアクティビティのいずれかをクリックすると、そのプロパティが表示されます。
「パスの設定」を使用し、プロセス・フローの各アクティビティについて次のプロパティを設定します。
実行ロケーション: このアクティビティの実行元ロケーションです。Oracle Enterprise Managerを構成済の場合は、プロセス・フローを実行するOEMエージェントを選択できます。
リモート・ロケーション: FTPアクティビティ専用のリモート・ロケーション。
作業ロケーション: FTP、FILE EXISTSおよび外部プロセス・アクティビティ専用の作業ロケーション。
配布ロケーション: 配布ロケーション。この設定は変換アクティビティにのみ適用されます。事前定義済の変換を参照するアクティビティの場合は、設定を「デフォルトのロケーションを使用」から変更して有効なロケーションを指定する必要があります。
「一般プロパティ」では、バウンド名（プロセス・フロー内でアクティビティが表すオブジェクトの名前）を参照できます。バウンド名を持つのは、マッピング・アクティビティ、変換アクティビティおよびサブプロセス・アクティビティのみです。
「実行の設定」で、オプション「ステータスとしてリターンを使用」を選択します。
この設定は、出力でNUMBERを戻すアクティビティの動作を制御します。この種のアクティビティには、FTP、ユーザー定義および変換などがあります。「ステータスとしてリターンを使用」を選択すると、プロセス・フロー・エディタではアクティビティの次の数値戻り値に基づいて送信推移条件が割り当てられます。
1 = 正常終了推移
2 = 警告推移
3 = エラー推移
