この章では、1つ以上のExpression列が存在する場合にSQL*Loaderおよびデータ・ポンプ・エクスポート・ユーティリティとデータ・ポンプ・インポート・ユーティリティを使用する方法について説明します。
バルク・ロードにより、大量のASCIIデータをOracleデータベースにインポートできます。データのバルク・ロードにはSQL*Loaderユーティリティを使用します。
SQL*Loader操作では、式データはデータベース表のVARCHAR2
列にロードされる文字列として扱われます。データファイルにはVARCHAR2
データに許可される任意の書式で式データを保持でき、制御ファイルでは式を格納する列をVARCHAR2
データ型の列として参照できます。
次の例に、Consumer
表に数行をロードするためのサンプル制御ファイルを示します。
LOAD DATA INFILE * INTO TABLE Consumer FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' (CId, Zipcode, Phone, Interest) BEGINDATA 1,32611,"917 768 4633","Model='Taurus' and Price < 15000 and Mileage < 25000" 2,03060,"603 983 3464","Model='Mustang' and Year > 1999 and Price < 20000" 3,03060,"603 484 7013","HorsePower(Model, Year) > 200 and Price < 20000"
Expression列にロードされたデータは、その列に関連付けられた属性セットを使用して自動的に検証されます。この検証は、式を格納する列に定義されているBEFORE ROW
トリガーにより実行されます。したがって、表に1つ以上のExpression列がある場合はダイレクト・ロードを使用できません。
式を格納する列に式フィルタ索引が定義されている場合は、SQL*Loader操作中に自動的に維持されます。バルク・ロードを高速化するために、次の手順で式の検証を迂回できます。
表のExpression列に定義されている式フィルタ索引を削除します。
DROP INDEX InterestIndex;
UNASSIGN_ATTRIBUTE_SET
プロシージャを使用して属性セットの割当てを解除し、Expression列を元のVARCHAR2
列に変換します。
BEGIN DBMS_EXPFIL.UNASSIGN_ATTRIBUTE_SET (expr_tab => 'Consumer', expr_col => 'Interest'); END; /
バルク・ロード操作を実行します。Expression列は前述の手順でVARCHAR2
列に変換されているため、この手順でダイレクト・ロードを実行できます。
ASSIGN_ATTRIBUTE_SET
プロシージャのforce
引数に値TRUE
を割り当てて、式データを含むVARCHAR2
列をExpression列に変換します。
BEGIN DBMS_EXPFIL.ASSIGN_ATTRIBUTE_SET ( attr_set => 'Car4Sale', expr_tab => 'Consumer', expr_col => 'Interest', force => 'TRUE'); END; /
実行時検証エラーを回避するために、DBMS_EXPFIL.VALIDATE_EXPRESSIONS
プロシージャを使用して表内の式を検証できます。
BEGIN DBMS_EXPFIL.VALIDATE_EXPRESSIONS (expr_tab => 'Consumer', expr_col => 'Interest'); END; /
Expression列の索引を再作成します。
1つ以上のExpression列を含む表をエクスポートし、同じデータベースまたは異なるOracleデータベースにインポートできます。Expression列を含む表をOracleデータベースにインポートする場合は、式フィルタがインストールされていることを確認してください。
次のガイドラインおよびExpression列を含む表のエクスポートとインポートに関連した既知の動作は、この操作に役立ちます。
1つ以上のExpression列を含む表をエクスポートすると、対応する属性セット定義がオブジェクト型定義とともにエクスポート・ダンプ・ファイルに置かれます。ダンプ・ファイルに置かれた属性セット定義には、デフォルトの索引パラメータと、承認済ユーザー定義関数のリストが含まれています。ただし、ユーザー定義関数の定義は、エクスポート・ダンプ・ファイルに置かれません。
1つ以上のExpression列を含む表をエクスポート・ダンプ・ファイルからインポートする間に、それと一致する属性セットがインポート先スキーマに存在すると、属性セットの作成に失敗します。属性セットがオブジェクト型の1つ以上の(埋込み)属性で定義されている場合は、その属性セットをインポートするデータベースにも、これらの型が存在する必要があります。
デフォルトの索引パラメータとユーザー定義関数のリストのインポート中は、欠落している依存オブジェクトが検出されても、インポート・ドライバはインポート処理を続行します。たとえば、Consumer
表をインポートするスキーマにHorsePower
関数が存在しない場合も、表と属性セットのインポートはエラーなしで進行します。ただし、式フィルタ・ディクショナリ内の対応するエントリでは、オブジェクト型フィールドまたは出力データ型フィールドにNULL値が表示されます。これは、インポート処理が完了しなかったことを示します。
Expression列に定義されている式フィルタ索引をエクスポートすると、すべてのメタデータがエクスポート・ダンプ・ファイルに置かれます。このメタデータには、索引用に構成済のストアド属性と索引付き属性すべてのリストが含まれています。このリストはインポート時に使用されます。デフォルトの索引パラメータからは属性は導出されません。索引をインポートするスキーマ内で有効でないオブジェクト参照(関数)が1つ以上のストアド属性で使用されている場合は、エラーになり索引を作成できません。ただし、索引のメタデータは式フィルタ・ディクショナリに保持されます。
依存スキーマ・オブジェクト(関数リスト内、デフォルトの索引パラメータ・リスト内および完全索引パラメータ・リスト内)への参照の破損が原因で表が不完全にインポートされると、以降の式の評価時や式の変更時(DMLを使用)に実行時エラーが発生する可能性があります。この種の表のインポートは、破損した参照をすべて解決すればSQL*Plusセッションから完了できます。Expression Validationユーティリティ(DBMS_EXPFIL.VALIDATE_EXPRESSIONS
プロシージャ)を実行すると、式のメタデータと式自体のエラーを識別できます。このユーティリティで識別された欠落オブジェクトを作成し、式セット内のエラーがすべて解決されるまでプロセスを繰り返すことができます。すべてのエラーを解決した後に、SQLのALTER INDEX ... REBUILD
文を使用して式フィルタ索引をリカバリできます。