11 SQL*Loaderを使用したオブジェクト、LOBおよびコレクションのロード
SQL*Loaderを使用して、様々な形式で列オブジェクトがロードでき、オブジェクト表、REF列、LOBおよびコレクションのロードができます。
- 列オブジェクトのロード
制御ファイルの列オブジェクトは、その属性によって記述されています。 - オブジェクト表のロード
オブジェクト表のロードに必要な制御ファイルの構文は、典型的なリレーショナル表のロードの場合とほぼ同じです。 - REF列のロード
SQL*Loaderは、システム生成OIDのREF列、主キーベースのREF列および主キーを使用できる有効範囲のないREF列をロードできます。 - SQL*Loaderを使用したLOBのロード
SQL*Loaderでロードでロードできるラージ・オブジェクト型について調べて、LOBデータのロード方法を示す例を確認してください。 - SQL*Loaderを使用したBFILE列のロード
BFILEデータ型には、データベースの外側にあるオペレーティング・システム・ファイルの非構造化バイナリ・データが格納されます。 - コレクション(ネストした表およびVARRAY)のロード
LOBと同様、コレクションも、プライマリ・データ・ファイル(データ・インライン)またはSDF(データ・アウトライン)のいずれかからロードできます。 - 動的または静的SDF指定の選択
SQL*Loaderを使用すると、SDFを静的に指定(実際のファイル名を指定)したり、または動的に指定(FILLERフィールドをファイル名のソースとして使用)したりできます。 - 親表を子表から分割してのロード
ネストした表の列を含む表をロードする場合、親表を子表から分割してロードする場合があります。
親トピック: SQL*Loader
11.1 列オブジェクトのロード
制御ファイルの列オブジェクトは、その属性によって記述されています。
列オブジェクトの基になるオブジェクト型がNOT FINALであると宣言されると、制御ファイルの列オブジェクトは、基になるオブジェクト型から導出されたサブタイプの(導出および宣言された)属性によって記述されます。データ・ファイルでは、列オブジェクトの各属性に対応するデータは、単純なリレーショナル列に対応するデータ・フィールドと同様の形式でデータ・ファイルに記述されています。
ノート:
SQL*Loaderによる列オブジェクトなどの複合データ型のサポートによって、制御ファイル内に、2つの同じフィールド名が存在する可能性があります。1つは列に対応し、もう1つは列オブジェクトの属性に対応する場合です。制御ファイルに同名のフィールドが存在する場合、特定の句がフィールド(たとえば、WHEN、NULLIF、DEFAULTIF、SID、OID、REF、BFILEなど)を参照できるため、名前の重複が発生する場合があります。
したがって、フィールドを参照する句を使用する場合、フルネームを使用する必要があります。たとえば、フィールドfld1がCOLUMN OBJECTであると指定され、フィールドfld2を含む場合、NULLIFなどの句でfld2を指定するときは、完全なフィールド名fld1.fld2を使用する必要があります。
次に、列オブジェクトのロードに関する例を示します。
- ストリーム・レコード形式での列オブジェクトのロード
ストリーム・レコード形式を使用すると、列オブジェクトにデリミタを指定することで、複数行のフィールドが含まれているレコードをSQL*Loaderでロードできます。 - 可変レコード形式での列オブジェクトのロード
列オブジェクトを可変レコード形式でロードできます。 - ネストした列オブジェクトのロード
ネストした列オブジェクトをロードできます。 - 導出サブタイプを使用した列オブジェクトのロード
導出サブタイプを使用した列オブジェクトをロードできます。 - オブジェクトに対するNULL値の指定
オブジェクトに対してNULL値を指定できます。 - ユーザー定義コンストラクタを使用した列オブジェクトのロード
ユーザー定義コンストラクタを使用した列オブジェクトをロードできます。
11.1.1 ストリーム・レコード形式への列オブジェクトのロード
ストリーム・レコード形式を使用すると、列オブジェクトにデリミタを指定することで、複数行のフィールドが含まれているレコードをSQL*Loaderでロードできます。
os_file_proc_clause)のカスタム・レコード・セパレータを使用して、物理レコードの終わりを示すこともできます。
例11-1 ストリーム・レコード形式への列オブジェクトのロード
制御ファイルの内容
LOAD DATA
INFILE 'example.dat'
INTO TABLE departments
(dept_no POSITION(01:03) CHAR,
dept_name POSITION(05:15) CHAR,
1 dept_mgr COLUMN OBJECT
(name POSITION(17:33) CHAR,
age POSITION(35:37) INTEGER EXTERNAL,
emp_id POSITION(40:46) INTEGER EXTERNAL) )
データ・ファイル(example.dat)
101 Mathematics Johnny Quest 30 1024
237 Physics Albert Einstein 65 0000この例では、dept_mgr COLUMN OBJECTのコールアウト1に注目してください。このタイプの列オブジェクト指定は、ネストした列オブジェクトの記述に再帰的に適用できます。
親トピック: 列オブジェクトのロード
11.1.2 可変レコード形式への列オブジェクトのロード
可変レコード形式で列オブジェクトをロードできます。
例11-2に、デリミタ付きフィールドにデータがある例を示します。
例11-2 可変レコード形式への列オブジェクトのロード
制御ファイルの内容
LOAD DATA 1 INFILE 'sample.dat' "var 6" INTO TABLE departments FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' 2 (dept_no dept_name, dept_mgr COLUMN OBJECT (name CHAR(30), age INTEGER EXTERNAL(5), emp_id INTEGER EXTERNAL(5)) )
データ・ファイル(sample.dat)
3 000034101,Mathematics,Johny Q.,30,1024, 000039237,Physics,"Albert Einstein",65,0000,
ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
"var"文字列には、各レコードの先頭にある長さフィールドのバイト数(この例では6)が含まれます。値が指定されない場合、デフォルトは5バイトです。可変レコードの最大サイズは、2^32-1です。それ以上の値を指定するとエラーになります。 -
位置を指定しなくても、一般構文では同じ結果(列オブジェクトの名前の後に、カッコで囲まれた属性のリストが続く)になります。また、省略された型指定については、デフォルトで長さが255の
CHAR型になります。 -
最初の6バイト(斜体で示した部分)に、次のレコードの長さを指定します。これらの長さ指定には、
emp_idフィールドの後の終了記号のために無視される改行文字も含まれます。
親トピック: 列オブジェクトのロード
11.1.3 ネストした列オブジェクトのロード
ネストした列オブジェクトをロードできます。
例11-3に、ネストした列オブジェクト(他の列オブジェクト内にネストした1つの列オブジェクト)の制御ファイルの記述方法を示します。
例11-3 ネストした列オブジェクトのロード
制御ファイルの内容
LOAD DATA
INFILE `sample.dat'
INTO TABLE departments_v2
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(dept_no CHAR(5),
dept_name CHAR(30),
dept_mgr COLUMN OBJECT
(name CHAR(30),
age INTEGER EXTERNAL(3),
emp_id INTEGER EXTERNAL(7),
1 em_contact COLUMN OBJECT
(name CHAR(30),
phone_num CHAR(20))))
データ・ファイル(sample.dat)
101,Mathematics,Johny Q.,30,1024,"Barbie",650-251-0010, 237,Physics,"Albert Einstein",65,0000,Wife Einstein,654-3210,
ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
このエントリでは、列オブジェクトにネストした列オブジェクトを指定します。
親トピック: 列オブジェクトのロード
11.1.4 導出サブタイプを使用した列オブジェクトのロード
導出サブタイプを使用して列オブジェクトをロードできます。
例11-4に、NOT FINALのベース・オブジェクト型を拡張して新しく導出されたサブタイプを作成する例を示します。表定義の列オブジェクトは、ベース・オブジェクト型であると宣言されますが、サブタイプがベース・オブジェクト型から導出される場合は、SQL*Loaderによってサブタイプを列オブジェクトにロードできます。
例11-4 サブタイプを使用した列オブジェクトのロード
オブジェクトの型定義
CREATE TYPE person_type AS OBJECT (name VARCHAR(30), ssn NUMBER(9)) not final; CREATE TYPE employee_type UNDER person_type (empid NUMBER(5)); CREATE TABLE personnel (deptno NUMBER(3), deptname VARCHAR(30), person person_type);
制御ファイルの内容
LOAD DATA
INFILE 'sample.dat'
INTO TABLE personnel
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(deptno INTEGER EXTERNAL(3),
deptname CHAR,
1 person COLUMN OBJECT TREAT AS employee_type
(name CHAR,
ssn INTEGER EXTERNAL(9),
2 empid INTEGER EXTERNAL(5)))
データ・ファイル(sample.dat)
101,Mathematics,Johny Q.,301189453,10249, 237,Physics,"Albert Einstein",128606590,10030,
ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
TREATAS句で指定すると、SQL*Loaderでは、実際の宣言型がperson_typeである列オブジェクトpersonが、導出型employee_typeであると宣言されたかのように処理されます。 -
empid属性はemployee_typeの属性であるため、ここで使用できます。TREATAS句が指定されていない場合、この属性は列の宣言型の属性ではないため、エラーが発生します。
親トピック: 列オブジェクトのロード
11.1.5 オブジェクトに対するNULL値の指定
オブジェクトに対してNULL値を指定できます。
非スカラー・データ型に対するNULL値の指定は、スカラー・データ型に対する指定より多少複雑になります。オブジェクトは、その属性のサブセットをNULLにするか、すべての属性をNULL(NULLオブジェクトにかぎります)にするか、またはオブジェクト自身をNULL(アトミックNULLオブジェクト)にできます。
- NULL属性の指定
NULL属性を指定できます。 - アトミックNULLの指定
アトミックNULLを指定できます。
親トピック: 列オブジェクトのロード
11.1.5.1 NULL属性の指定
NULL属性を指定できます。
列オブジェクトに対応するフィールドでは、NULLIF句を使用して、特殊属性をNULLに初期化するフィールド条件を指定できます。例11-5に、これを示します。
例11-5 NULLIF句を使用したNULL属性の指定
制御ファイルの内容
LOAD DATA INFILE 'sample.dat' INTO TABLE departments (dept_no POSITION(01:03) CHAR, dept_name POSITION(05:15) CHAR NULLIF dept_name=BLANKS, dept_mgr COLUMN OBJECT 1 ( name POSITION(17:33) CHAR NULLIF dept_mgr.name=BLANKS, 1 age POSITION(35:37) INTEGER EXTERNAL NULLIF dept_mgr.age=BLANKS, 1 emp_id POSITION(40:46) INTEGER EXTERNAL NULLIF dept_mgr.empid=BLANKS))
データ・ファイル(sample.dat)
2 101 Johny Quest 1024
237 Physics Albert Einstein 65 0000ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
各属性に対応する
NULLIF句は、属性値をNULLにする条件を示します -
dept_mgrのage属性の値はNULLです。dept_nameの値もNULLです。
親トピック: オブジェクトに対するNULL値の指定
11.1.5.2 アトミックNULLの指定
アトミックNULLを指定できます。
列オブジェクトがNULL値(アトミックNULL)を取る条件を制御ファイルで指定するには、NULLIF句で使用するオブジェクトの名前は、マップ・フィールドの論理的な組合せに基づいている必要があります(たとえば、例11-5では、指定されたマップ・フィールドは、dept_no、dept_name、name、ageおよびemp_idです。dept_mgrは、データ・ファイルのどのフィールドにも対応していない(マップされていない)ため、指定されたマップ・フィールドではありません)。
前述の方法は使用可能ですが、オブジェクトがNULL値を取るための条件がマップ・フィールドに依存していない場合は、理想的な方法ではありません。このような場合は、FILLERフィールドを使用できます。
FILLERフィールドをデータ・ファイルのフィールドにマップし(列オブジェクトがアトミックNULLかどうかを示す)、そのFILLERフィールドを列オブジェクトのNULLIF句のフィールド条件で使用できます。この例を例11-6に示します。
例11-6 FILLERフィールドを使用したデータのロード
制御ファイルの内容
LOAD DATA INFILE 'sample.dat' INTO TABLE departments_v2 FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' (dept_no CHAR(5), dept_name CHAR(30), 1 is_null FILLER CHAR, 2 dept_mgr COLUMN OBJECT NULLIF is_null=BLANKS (name CHAR(30) NULLIF dept_mgr.name=BLANKS, age INTEGER EXTERNAL(3) NULLIF dept_mgr.age=BLANKS, emp_id INTEGER EXTERNAL(7) NULLIF dept_mgr.emp_id=BLANKS, em_contact COLUMN OBJECT NULLIF is_null2=BLANKS (name CHAR(30) NULLIF dept_mgr.em_contact.name=BLANKS, phone_num CHAR(20) NULLIF dept_mgr.em_contact.phone_num=BLANKS)), 1 is_null2 FILLER CHAR)
データ・ファイル(sample.dat)
101,Mathematics,n,Johny Q.,,1024,"Barbie",608-251-0010,, 237,Physics,,"Albert Einstein",65,0000,,650-654-3210,n,
ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
FILLERフィールド(データ・ファイルがマップされており、対応する列がない)は
CHAR型(デリミタ付きフィールドであるため、CHARのデフォルトはCHAR(255))のフィールドです。NULLIF句は、FILLERフィールド自体には使用できません -
is_nullフィールドが空白の場合は、NULL(アトミックNULL)の値を取得します。
親トピック: オブジェクトに対するNULL値の指定
11.1.6 ユーザー定義コンストラクタを使用した列オブジェクトのロード
ユーザー定義コンストラクタを使用して列オブジェクトをロードできます。
Oracle Databaseでは、すべてのオブジェクト型に対してデフォルトのコンストラクタが自動的に提供されます。このコンストラクタを使用するには、コンストラクタに対するコールで、その型のすべての属性を引数として指定する必要があります。オブジェクトの新しいインスタンスが作成されると、その属性は引数リスト内の対応する値を取ります。このコンストラクタは、属性値コンストラクタと呼ばれます。SQL*Loaderでは、列オブジェクトのロード時に、デフォルトで属性値コンストラクタが使用されます。
1つ以上のユーザー定義コンストラクタを作成することによって、属性値コンストラクタを上書きできます。ユーザー定義コンストラクタを作成する場合、オブジェクトの新しいインスタンスが作成されると、常に、ユーザー定義論理を実行する型本体を指定する必要があります。ユーザー定義コンストラクタの引数リストは、属性値コンストラクタと同じ場合もありますが、型本体で実装される論理は異なります。
ユーザー定義コンストラクタのファンクションの引数リストが属性値コンストラクタの引数リストと一致する場合、従来型パスとダイレクト・パスではSQL*Loaderの動作が異なります。従来型パス・モードでは、ユーザー定義コンストラクタがコールされます。ダイレクト・パス・モードでは、属性値コンストラクタがコールされます。例11-7に、この違いを示します。
例11-7 一致するコンストラクタを使用した列オブジェクトのロード
オブジェクトの型定義
CREATE TYPE person_type AS OBJECT
(name VARCHAR(30),
ssn NUMBER(9)) not final;
CREATE TYPE employee_type UNDER person_type
(empid NUMBER(5),
-- User-defined constructor that looks like an attribute-value constructor
CONSTRUCTOR FUNCTION
employee_type (name VARCHAR2, ssn NUMBER, empid NUMBER)
RETURN SELF AS RESULT);
CREATE TYPE BODY employee_type AS
CONSTRUCTOR FUNCTION
employee_type (name VARCHAR2, ssn NUMBER, empid NUMBER)
RETURN SELF AS RESULT AS
--User-defined constructor makes sure that the name attribute is uppercase.
BEGIN
SELF.name := UPPER(name);
SELF.ssn := ssn;
SELF.empid := empid;
RETURN;
END;
CREATE TABLE personnel
(deptno NUMBER(3),
deptname VARCHAR(30),
employee employee_type);
制御ファイルの内容
LOAD DATA
INFILE *
REPLACE
INTO TABLE personnel
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(deptno INTEGER EXTERNAL(3),
deptname CHAR,
employee COLUMN OBJECT
(name CHAR,
ssn INTEGER EXTERNAL(9),
empid INTEGER EXTERNAL(5)))
BEGINDATA
1 101,Mathematics,Johny Q.,301189453,10249,
237,Physics,"Albert Einstein",128606590,10030,ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
この制御ファイルが従来型パス・モードで実行された場合、名前フィールドの
JohnyQ.およびAlbertEinsteinは、両方とも大文字でロードされます。これは、従来型パス・モードではユーザー定義コンストラクタがコールされるためです。これに対し、この制御ファイルがダイレクト・パス・モードで実行された場合、名前フィールドは入力データに表示されているとおりにロードされます。これは、ダイレクト・パス・モードでは属性値コンストラクタがコールされるためです。
引数リストが属性値コンストラクタと一致しないユーザー定義コンストラクタの作成もできます。この場合は、従来型パス・モードおよびダイレクト・パス・モードの両方で、属性値コンストラクタがコールされます。例11-8に示す定義について考えてみます。
例11-8 一致しないコンストラクタを使用した列オブジェクトのロード
オブジェクトの型定義
CREATE SEQUENCE employee_ids
START WITH 1000
INCREMENT BY 1;
CREATE TYPE person_type AS OBJECT
(name VARCHAR(30),
ssn NUMBER(9)) not final;
CREATE TYPE employee_type UNDER person_type
(empid NUMBER(5),
-- User-defined constructor that does not look like an attribute-value
-- constructor
CONSTRUCTOR FUNCTION
employee_type (name VARCHAR2, ssn NUMBER)
RETURN SELF AS RESULT);
CREATE TYPE BODY employee_type AS
CONSTRUCTOR FUNCTION
employee_type (name VARCHAR2, ssn NUMBER)
RETURN SELF AS RESULT AS
-- This user-defined constructor makes sure that the name attribute is in
-- lowercase and assigns the employee identifier based on a sequence.
nextid NUMBER;
stmt VARCHAR2(64);
BEGIN
stmt := 'SELECT employee_ids.nextval FROM DUAL';
EXECUTE IMMEDIATE stmt INTO nextid;
SELF.name := LOWER(name);
SELF.ssn := ssn;
SELF.empid := nextid;
RETURN;
END;
CREATE TABLE personnel
(deptno NUMBER(3),
deptname VARCHAR(30),
employee employee_type);
例11-7で説明した制御ファイルがこれらの定義に従って使用された場合、名前フィールドは、入力データに表示されているとおりに(大文字と小文字の組合せで)ロードされます。これは、従来型パス・モードおよびダイレクト・パス・モードの両方で属性値コンストラクタがコールされるためです。
SQL式でユーザー定義コンストラクタを明示的に参照することによって、従来型パス・モードを使用してこの表をロードすることもできます。例11-9に、この方法を示します。
例11-9 コンストラクタが一致しない場合のSQLを使用した列オブジェクトのロード
制御ファイルの内容
LOAD DATA
INFILE *
REPLACE
INTO TABLE personnel
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(deptno INTEGER EXTERNAL(3),
deptname CHAR,
name BOUNDFILLER CHAR,
ssn BOUNDFILLER INTEGER EXTERNAL(9),
1 employee EXPRESSION "employee_type(:NAME, :SSN)")
BEGINDATA
1 101,Mathematics,Johny Q.,301189453,
237,Physics,"Albert Einstein",128606590,ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
この制御ファイルが従来型パス・モードで実行された場合、名前フィールドの
JohnyQ.およびAlbertEinsteinは、両方とも大文字でロードされます。これは、従来型パス・モードではユーザー定義コンストラクタがコールされるためです。これに対し、この制御ファイルがダイレクト・パス・モードで実行された場合、名前フィールドは入力データに表示されているとおりにロードされます。これは、ダイレクト・パス・モードでは属性値コンストラクタがコールされるためです。
例11-9に示した制御ファイルがダイレクト・パス・モードで使用された場合は、次のエラーが通知されます。
SQL*Loader-951: Error calling once/load initialization ORA-26052: Unsupported type 121 for SQL expression on column EMPLOYEE.
親トピック: 列オブジェクトのロード
11.2 オブジェクト表のロード
オブジェクト表のロードに必要な制御ファイルの構文は、典型的なリレーショナル表のロードの場合とほぼ同じです。
例11-10に、主キーベースのオブジェクト識別子(OID)を使用したオブジェクト表のロード例を示します。
例11-10 主キーOIDを使用したオブジェクト表のロード
制御ファイルの内容
LOAD DATA INFILE 'sample.dat' DISCARDFILE 'sample.dsc' BADFILE 'sample.bad' REPLACE INTO TABLE employees FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' (name CHAR(30) NULLIF name=BLANKS, age INTEGER EXTERNAL(3) NULLIF age=BLANKS, emp_id INTEGER EXTERNAL(5))
データ・ファイル(sample.dat)
Johny Quest, 18, 007, Speed Racer, 16, 000,
前述の制御ファイルを見ただけでは、ロードされる表がシステム生成OIDを持つオブジェクト表か、主キーOIDを持つオブジェクト表か、またはリレーショナル表かを判断できません。
すでにシステム生成OIDを含むデータをロードし、新しいOIDを生成するのではなく、データ・ファイル内の既存のOIDを使用するように指定する必要がある場合もあります。そのような場合は、INTO TABLE句に続けてOID句を使用します。
OID (fieldname)
この場合、fieldnameには、システム生成OIDを含むデータ・フィールドにマップされた、フィールド指定リストのフィールド名(通常はFILLERフィールド)を指定します。SQL*Loaderでは、その指定されたOIDが、正しい形式で、グローバルな独自性を保持したOIDであるとみなされます。そのため、OracleのOIDジェネレータを使用してOIDを生成し、ロードされたOIDの一意性を確保する必要があります。
また、そのOID句は、主キーOIDではなく、システム生成のOIDでのみ使用できます。
例11-11に、行オブジェクトを使用したシステム生成OIDのロード例を示します。
例11-11 OIDのロード
制御ファイルの内容
LOAD DATA INFILE 'sample.dat' INTO TABLE employees_v2 1 OID (s_oid) FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' (name CHAR(30) NULLIF name=BLANKS, age INTEGER EXTERNAL(3) NULLIF age=BLANKS, emp_id INTEGER EXTERNAL(5), 2 s_oid FILLER CHAR(32))
データ・ファイル(sample.dat)
3 Johny Quest, 18, 007, 21E978406D3E41FCE03400400B403BC3,
Speed Racer, 16, 000, 21E978406D4441FCE03400400B403BC3,ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
OID句には、s_oidのロード・フィールドがOIDを含むように指定します。カッコが必要です -
s_oidに有効な16進数が含まれていない場合、そのレコードは拒否されます。 -
データ・ファイルのOIDは文字列で、32バイトの16進数として解釈されます。32バイトの16進数は、後で16バイトの
RAWに変換されてオブジェクト表に格納されます。
- サブタイプを使用したオブジェクト表のロード
オブジェクト表の列オブジェクトがNOT FINALに基づいている場合、SQL*Loaderによって導出サブタイプをオブジェクト表にロードできます。
11.2.1 サブタイプを使用したオブジェクト表のロード
オブジェクト表の列オブジェクトがNOT FINALに基づいている場合、SQL*Loaderによって導出サブタイプをオブジェクト表にロードできます。
例11-12 サブタイプを使用したオブジェクト表のロード
オブジェクト型の定義を確認して、制御ファイルの構成方法を理解するためにコールアウト(bold)を確認してください。
オブジェクトの型定義
CREATE TYPE employees_type AS OBJECT
(name VARCHAR2(30),
age NUMBER(3),
emp_id NUMBER(5)) not final;
CREATE TYPE hourly_emps_type UNDER employees_type
(hours NUMBER(3));
CREATE TABLE employees_v3 of employees_type;
制御ファイルの内容
LOAD DATA
INFILE 'sample.dat'
INTO TABLE employees_v3
1 TREAT AS hourly_emps_type
FIELDS TERMINATED BY ','
(name CHAR(30),
age INTEGER EXTERNAL(3),
emp_id INTEGER EXTERNAL(5),
2 hours INTEGER EXTERNAL(2))
データ・ファイル(sample.dat)
Johny Quest, 18, 007, 32, Speed Racer, 16, 000, 20,
ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
TREAT AS句はオブジェクト表を、実際に宣言された型(employee_type)ではなく、hourly_emps_type型として宣言されたものとして扱うようにSQL*Loaderに指示します。 -
hours属性はhourly_emps_typeの属性であるため、ここで使用できます。TREAT AS句が指定されていない場合にこの属性を使用すると、オブジェクト表の宣言された型の属性ではないため、エラーが発生します。
親トピック: オブジェクト表のロード
11.3 SQL*Loaderを使用したREF列のロード
SQL*Loaderは、システム生成OIDのREF列、主キーベースのREF列および主キーを使用可能な有効範囲なしREF列をロードできます。
REFとはOracleの組込みデータ型で、オブジェクト表内のオブジェクトを指す論理的なポインタです。これらのREF列の型ごとに、その型に応じた適切な表名を指定する必要があります。
- REF句における表名の指定
次の例を使用して、SQL*Loader制御ファイルでのREF句の記述方法を確認し、大/小文字の区別について理解してください。 - システム生成OID REF列
システム生成のREF列をロードする場合、SQL*LoaderはREF列を構築する実際のOIDが、データとともにデータ・ファイル内にあるとみなします。 - 主キーREF列
主キーREF列をロードするには、SQL*Loader制御ファイルのフィールドで列名の後にREF句を記述する必要があります。 - 主キーが使用可能な有効範囲なしREF列
主キーが使用可能な有効範囲なしREF列は、システム生成と主キーの両方のREFを参照できます。
11.3.1 REF句における表名の指定
次の例を使用して、SQL*Loader制御ファイルでのREF句の記述方法を確認し、大/小文字の区別について理解してください。
ノート:
この項で説明する内容は、SQL*LoaderおよびOracle Databaseのリリースがいずれも11gリリース1(11.1)以上の環境にのみ適用されます。SQL*LoaderとOracle Databaseのどちらか(またはその両方)が以前のリリースの環境には適用されません。
例11-13 SQL*Loader制御ファイルでのREF句の記述
SQL*Loader制御ファイルでは、REF列に対応するフィールドの記述は、列名の後にREF句を記述することによって行います。REF句には、引数として表名とロードされるREF列の型に適用可能な属性を取ります。表名は、(FILLERフィールドを使用して),動的に、または定数として指定できます。また、表名は、スキーマ名の有無にかかわらず指定できます。
-
ユーザー
SCOTTが、小文字で表名を引用符で囲まずにtable2という名前の表を作成する場合、その表は次のいずれの方法でもREF句で使用できます。-
REF(constant 'TABLE2', ...) -
REF(constant '"TABLE2"', ...) -
REF(constant 'SCOTT.TABLE2', ...)
-
-
ユーザー
SCOTTが、大文字と小文字を組み合せた名前を引用符で囲んで"Table2"という名前の表を作成する場合、その表は次のいずれの方法でもREF句で使用できます。-
REF(constant 'Table2', ...) -
REF(constant '"Table2"', ...) -
REF(constant 'SCOTT.Table2', ...)
-
いずれの状況においても、constantがFILLERフィールドに置換された場合、同じ値がデータ・セクションに書き込まれると、例に示したとおり値が処理されます。
親トピック: SQL*Loaderを使用したREF列のロード
11.3.2 システム生成OID型のREF列
システム生成のREF列をロードする場合、SQL*LoaderはREF列を構築する実際のOIDが、データとともにデータ・ファイル内にあるとみなします。
REF列に対応するフィールドの記述は、列名の後にREF句を記述することによって行います。
REF句には、引数として表名とOIDを取ります。その引数は、定数として、または(FILLERフィールドを使用して)動的に指定できます。詳細は、SQL*Loaderのref_specの構文を参照してください。
例11-14 システム生成REF列のロード
次の例は、システム生成のOID REF列をロードする方法を示しています。boldのコールアウトに注目してください。
制御ファイルの内容
LOAD DATA
INFILE 'sample.dat'
INTO TABLE departments_alt_v2
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(dept_no CHAR(5),
dept_name CHAR(30),
1 dept_mgr REF(t_name, s_oid),
s_oid FILLER CHAR(32),
t_name FILLER CHAR(30))
データ・ファイル(sample.dat)
22345, QuestWorld, 21E978406D3E41FCE03400400B403BC3, EMPLOYEES_V2,
23423, Geography, 21E978406D4441FCE03400400B403BC3, EMPLOYEES_V2,ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
指定した表が存在しない場合、レコードは拒否されます。また、
dept_mgrフィールド自体には、データ・ファイルのフィールドはマップされません。
関連トピック
親トピック: SQL*Loaderを使用したREF列のロード
11.3.3 主キーREF列
主キーREF列をロードするには、SQL*Loader制御ファイルのフィールドで列名の後にREF句を記述する必要があります。
REF句には、カンマで区切ったフィールド名および定数値のリストが引数として必要です。最初の引数は表名で、その後にロードするREF列の基になる主キーOIDを指定する引数を記述します。詳細は、ref_specのSQL*Loader構文を参照してください。
SQL*Loaderでは、引数の順序は、参照されている表で主キーOIDを作成する列の相対順序に一致しているとみなされます。
例11-15 主キーREF列のロード
次の例は、主キーREF列のロード方法を示しています。
制御ファイルの内容
LOAD DATA
INFILE 'sample.dat'
INTO TABLE departments_alt
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(dept_no CHAR(5),
dept_name CHAR(30),
dept_mgr REF(CONSTANT 'EMPLOYEES', emp_id),
emp_id FILLER CHAR(32))
データ・ファイル(sample.dat)
22345, QuestWorld, 007,
23423, Geography, 000,関連トピック
親トピック: SQL*Loaderを使用したREF列のロード
11.3.4 主キーが使用可能な有効範囲なしREF列
主キーが使用可能な有効範囲なしREF列によって、システム生成および主キーの両方の型のREFを参照できます。
有効範囲なしのREF列にデータをロードする構文は、システム生成のOID REF列または主キーベースのREF列にデータをロードするときに使用する構文と同じです。
主キーが使用可能な有効範囲なしREF列をロードする場合は、次の制限が適用されます。
-
単一表へのロード中は、この列からシステム生成または主キーのいずれかの型の
REFのみを参照できます。両方は参照できません。両方の型の参照を試行すると、データ行が拒否され、参照表名が無効であることを示すエラー・メッセージが表示されます。 -
この列に有効範囲なし主キー
REFをロードする場合、単一表へのロード中は、1つのオブジェクト表のみ参照できます。複数の有効範囲なし主キーREF(いくつかのREFはオブジェクト表Xを指し、その他のREFはオブジェクト表Yを指す)をロードする場合は、次のいずれかの操作を実行する必要があります。- 単一表へのロードを2回実行します。
- 有効範囲なし主キー
REFのオブジェクト表名など、WHEN句によってデータのいくつかの要素が指定されている複数のINTO TABLE句を使用して、ロードを1回実行します。
これらの方法のいずれも使用しない場合は、データ行が拒否され、参照されている表の名前が無効であることを示すエラー・メッセージが表示されます。
-
SQL*Loaderは、コレクション内の有効範囲なし主キー
REFをサポートしていません。 -
この
REF列にシステム生成のREFをロードする場合は、システム生成のOID REF列に適用される制限も適用されます。 -
この
REF列に主キーREFをロードする場合は、主キーREF列に適用される制限も適用されます。ノート:
主キーが使用可能な有効範囲なし
REF列の場合、SQL*Loaderは最初の有効なオブジェクト表(解析されたもの)を取得します(REFディレクティブまたはデータ行から取得します)。次にSQL*Loaderは、そのオブジェクト表のOIDタイプを使用して、単一表ロードで参照可能なREFタイプを判断します。
例11-16 複数のINTO TABLE句を使用した単一ロードの方法
この例では、WHEN句は、有効範囲なし主キーREF表のcust_tblとcust_noのオブジェクト表名で指定される"CUSTOMERS_PK"データからキーを外します。
LOAD DATA
INFILE 'data.dat'
INTO TABLE orders_apk
APPEND
when CUST_TBL = "CUSTOMERS_PK"
fields terminated by ","
(
order_no position(1) char,
cust_tbl FILLER char,
cust_no FILLER char,
cust REF (cust_tbl, cust_no) NULLIF order_no='0'
)
INTO TABLE orders_apk
APPEND
when CUST_TBL = "CUSTOMERS_PK2"
fields terminated by ","
(
order_no position(1) char,
cust_tbl FILLER char,
cust_no FILLER char,
cust REF (cust_tbl, cust_no) NULLIF order_no='0'
)
親トピック: SQL*Loaderを使用したREF列のロード
11.4 SQL*Loaderを使用したLOBのロード
SQL*Loaderでロードでロードできるラージ・オブジェクト型について調べて、LOBデータのロード方法を示す例を確認してください。
- プライマリ・データ・ファイルからのLOBデータのロード
プライマリ・データ・ファイルから、内部LOB (BLOB、CLOB、NCLOB)またはXML列をロードできます。 - LOBFILEからのLOBデータのロード
LOBデータは、非常に長いデータであるため、プライマリ・データ・ファイルからではなく、LOBFILEからロードすると有効です。 - LLSフィールドを含むデータ・ファイルのロード
データ・ファイルのフィールドがLOBロケーション指定子(LLS)フィールドの場合、LLS句を使用してこのことを示すことができます。
11.4.1 プライマリ・データ・ファイルからのLOBデータのロード
プライマリ・データ・ファイルから、内部LOB (BLOB、CLOB、NCLOB)またはXML列をロードできます。
プライマリ・データ・ファイルから内部LOBまたはXML列をロードするには、次の標準SQL*Loader形式を使用できます。
-
事前にサイズが決まっているフィールド
-
デリミタ付きフィールド
-
Length-Value Pairフィールド
- 事前に決められたサイズのフィールドのLOBデータ
事前にサイズが決まっているフィールドにLOBをロードすることで、LOBのロードが非常に高速になることと、概念的に単純な形式になることを示します。 - デリミタ付きフィールドのLOBデータ
SQL*Loaderで同じ列(データ・ファイル・フィールド)内に異なるサイズのLOBをロードするときには、デリミタ付きフィールドの使用を検討してください。 - Length-Value PairフィールドのLOBデータ
Length-Value Pairフィールドで編成されたLOBデータのロードには、VARCHAR、VARCHARCまたはVARRAWデータ型を使用できます。
親トピック: SQL*Loaderを使用したLOBのロード
11.4.1.1 事前に決められたサイズのフィールドのLOBデータ
事前にサイズが決まっているフィールドにLOBをロードすることで、LOBのロードが非常に高速になることと、概念的に単純な形式になることを示します。
ノート:
ロードするLOBデータはサイズが異なるため、サイズが小さいデータ・フィールドに空白を埋め込み、全LOBデータが同じサイズになるようにできます。
事前にサイズが決まっているフィールドを使用してLOBをロードするには、ロードするデータ型としてCHARまたはRAWを使用する必要があります。
例11-17 事前に決められたサイズのフィールドのLOBデータ
制御ファイルとデータ・ファイルのサンプルを確認して、boldのコールアウトに注目してください。制御ファイルの内容
LOAD DATA
INFILE 'sample.dat' "fix 501"
INTO TABLE person_table
(name POSITION(01:21) CHAR,
1 "RESUME" POSITION(23:500) CHAR DEFAULTIF "RESUME"=BLANKS)
データ・ファイル(sample.dat)
Julia Nayer Julia Nayer
500 Example Parkway
jnayer@us.example.com ...ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
DEFAULTIF句が使用されているため、RESUMEが含まれているデータ・フィールドが空の場合、NULLのLOBではなく、空のLOBになります。ただし、DEFAULTIFではなくNULLIF句が使用されている場合は、空のデータ・フィールドではなくNULLになります。また、ロード時に、
CHAR以外にもSQL*Loaderのデータ型を使用できます。たとえば、BLOBのロード時、RAWデータ型を使用する場合があります。
親トピック: プライマリ・データ・ファイルからのLOBデータのロード
11.4.1.2 デリミタ付きフィールドのLOBデータ
SQL*Loaderで同じ列(データ・ファイル・フィールド)内に異なるサイズのLOBをロードするときには、デリミタ付きフィールドの使用を検討してください。
デリミタ付きフィールド形式で、同じ列(データ・ファイルのフィールド)で異なるサイズのLOBを問題なく処理できます。ただし、このような柔軟性によって、SQL*Loaderでデリミタ文字列を探してデータをスキャンする必要があるため、パフォーマンスに影響します。
単一キャラクタのデリミタで、文字列のデリミタを指定する場合は、データ・ファイルの文字セットに注意してください。データ・ファイルの文字セットが制御ファイルの文字セットと異なる場合は、デリミタを16進数の表記法(つまりX'hexadecimal string')で指定できます。デリミタを実際に16進数の表記法で指定する場合は、入力データ・ファイルの文字セット中の有効な文字で指定する必要があります。一方、16進数の表記法で指定しない場合、デリミタは、クライアント(制御ファイル)の文字セットで指定してください。この場合、デリミタは、SQL*Loaderによってデータ・ファイル内で検索される前に、データ・ファイルの文字セットに変換されます。
次の点に注意してください。
-
文字列デリミタを使用した区切り構文がサポートされます(囲みデリミタを区切りとします)。
-
マルチ・キャラクタの囲みデリミタの前に空白は入れられません。
-
フィールドが
WHITESPACEで終わる場合、先頭の空白は切り捨てられます。ノート:
SQL*Loaderによる
CLOBデータ移動時のフィールドのデフォルト最大長は255バイトですが、最大2GBまでの値を指定できます。デリミタ付きフィールドでは、長さが指定されている場合、その長さが最大長として使用されます。値が指定されない場合、デフォルトは255バイトです。デリミタ付きで255バイトを超えるCHARフィールドの場合、最大長を指定する必要があります。CHARデータ型の詳細は、「CHAR」を参照してください。
例11-18 デリミタ付きフィールドのLOBデータのロード
この例を確認して、デリミタ付きフィールドにLOBデータをロードする方法を理解してください。boldのコールアウトに注目してください。
制御ファイルの内容
LOAD DATA
INFILE 'sample.dat' "str '|'"
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name CHAR(25),
1 "RESUME" CHAR(507) ENCLOSED BY '<startlob>' AND '<endlob>')
データ・ファイル(sample.dat)
Julia Nayer,<startlob> Julia Nayer
500 Example Parkway
jnayer@example.com ... <endlob>
2 |Bruce Ernst, .......ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
<startlob>および<endlob>は、囲み文字列です。デフォルトのバイト長セマンティクスでは、CHAR(507)を使用して読み込むことができるLOBの最大長は507バイトです。文字長セマンティクスが使用された場合、最大長は507文字になります。詳細は、文字長セマンティクスを参照してください。 -
レコード・セパレータ
'|'は、<endlob>のすぐ後にあり、その後に改行文字が続く場合、改行は、次のレコードの一部として解釈されます。代替方法は、レコード・セパレータに改行部分を作成することです(たとえば'|\n'、または16進ではX'7C0A')。
関連トピック
親トピック: プライマリ・データ・ファイルからのLOBデータのロード
11.4.1.3 Length-Value PairフィールドのLOBデータ
Length-Value Pairフィールドで編成されたLOBデータのロードには、VARCHAR、VARCHARCまたはVARRAWデータ型を使用できます。
Length-Value Pairフィールドでデータをロードすると、デリミタ付きフィールドを使用するよりもパフォーマンスが向上します。ただし、この方法では柔軟性が低下することもあります(たとえば、ロード前に各LOBのLOB長を知っている必要があります)。
例11-19 Length-Value PairフィールドへのLOBデータのロード
制御ファイルとデータ・ファイルの例を確認して、Length-Value PairフィールドにLOBデータをロードする方法を理解してください。boldのコールアウトに注目してください。制御ファイルの内容
LOAD DATA
1 INFILE 'sample.dat' "str '<endrec>\n'"
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name CHAR(25),
2 "RESUME" VARCHARC(3,500))
データ・ファイル(sample.dat)
Julia Nayer,479 Julia Nayer
500 Example Parkway
jnayer@us.example.com... <endrec>
3 Bruce Ernst,000<endrec>ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
バックスラッシュ・エスケープ文字がサポートされていない場合、例の中でレコード・セパレータとして使用されている文字列は、16進数の表記法で表現されます。
-
"RESUME"は、CLOB列に対応するフィールドです。制御ファイルでは、VARCHARCがそのフィールドで、フィールド長は3バイト、最大サイズは500バイト(バイト長セマンティクスで)です。文字長セマンティクスが使用された場合、長さは3文字で最大サイズは500文字です。詳細は、「文字長セマンティクス」を参照してください。 -
VARCHARCのlengthサブフィールドは、0(サブフィールドの値が空)です。このため、LOBインスタンスは、空に初期化されます。
関連トピック
親トピック: プライマリ・データ・ファイルからのLOBデータのロード
11.4.2 LOBFILEからのLOBデータのロード
LOBデータは、非常に長いデータであるため、プライマリ・データ・ファイルからではなく、LOBFILEからロードすると有効です。
LOBFILEでは、LOBデータのインスタンスは、フィールド(事前に決められたサイズ、デリミタ付き、Length-Value Pair)内にあるとみなされますが、これらのフィールドは、レコードに編成されていません(LOBFILEにはレコードの概念がありません)。そのため、レコードを扱うことによって発生するオーバーヘッドを回避できます。このようなデータの編成方法は、LOBのロードにとって理想的です。
LOBFILEからロードしたLOBをメモリーに合わせる必要はありません。SQL*Loaderでは、64KB単位でLOBFILEが読み込まれます。
LOBFILEのデータ・フィールドは、次のいずれかの型です。
-
ファイルの内容全体を読み込む単一のLOBフィールド
-
サイズが決められたフィールド(固定長フィールド)
-
デリミタ付きフィールド(
TERMINATEDBYまたはENCLOSEDBY)PRESERVEBLANKS句は、LOBFILEから読み込むフィールドには使用できません。 -
Length-Value Pairフィールド(可変長フィールド)
この型のフィールドからデータをロードするには、
VARRAW、VARCHARまたはVARCHARCSQL*Loaderデータ型を使用します。
これらの各フィールド型の使用例については、「LOBFILEからのLOBデータのロードの例」を参照してください。前述のすべてのフィールド型は、XML列のロードに使用できます。
LOBFILE構文については、「lobfile_spec」を参照してください。
- 動的および静的LOBFILE指定
LOBFILEを静的に指定(制御ファイルにファイル名を指定)するか、または動的に指定(FILLERフィールドをファイル名のソースとして使用)できます。 - LOBFILEからのLOBデータのロードの例
この項では、LOBFILEの様々なタイプのフィールドからデータをロードする例を示します。 - LOBFILEからLOBをロードする際の考慮事項
SQL*LoaderでLOBFILESからラージ・オブジェクト型(LOB)をロードする際に適用される制限事項とガイドラインに注意してください。
親トピック: SQL*Loaderを使用したLOBのロード
11.4.2.1 動的および静的LOBFILE指定
LOBFILEを静的に指定(制御ファイルにファイル名を指定)するか、または動的に指定(FILLERフィールドをファイル名のソースとして使用)できます。
いずれの場合も、LOBFILEがEOFで終了しない場合は、LOBFILEの終わりに到達するとファイルがクローズされ、そのファイルからさらにデータを読み込む場合は、空のフィールドからデータを読み込むことになります。
ただし、LOBFILEをEOFで終了する場合は、ファイルからデータを読み込むと、常に、ファイル全体が戻されます。
同じLOBFILEを、2つの異なるフィールドのソースとして指定しないでください。指定すると、通常、2つのフィールドは、データを別々に読み取ります。
親トピック: LOBFILEからのLOBデータのロード
11.4.2.2 LOBFILEからのLOBデータのロードの例
この項では、LOBFILEの異なるフィールド型からデータをロードする例を示します。
- ファイルごとに1つのLOB
ラージ・オブジェクト型(LOB)データをロードするときには、各LOBFILEが1つのLOBのソースになります。 - 事前に決められたサイズのLOB
事前に決められたサイズのLOBを使用してLOBデータをロードできます。 - デリミタ付きLOB
サイズが異なるラージ・オブジェクト型(LOB)には、事前に決められたサイズのLOBが使用できないため、デリミタ付きLOBをSQL*Loaderで使用することを検討してください。 - Length-Value Pairで指定したLOB
ラージ・オブジェクト型(LOB)のロードにLength-Value Pairの指定を使用するとパフォーマンスが向上します。ただし、柔軟性は低下します。
親トピック: LOBFILEからのLOBデータのロード
11.4.2.2.1 ファイルごとに1つのLOB
ラージ・オブジェクト型(LOB)データをロードするときには、各LOBFILEが1つのLOBのソースになります。
LOBFILEが1つのLOBのソースになるように編成されたLOBをロードする方法について理解してください。
例11-20 LOBFILE当たり1つのLOBを使用したLOBデータのロード
この例では、列名またはフィールド名の後にLOBFILEデータ型の指定が続いている点に注目してください。boldのコールアウトに注目してください。
制御ファイルの内容
LOAD DATA
INFILE 'sample.dat'
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name CHAR(20),
1 ext_fname FILLER CHAR(40),
2 "RESUME" LOBFILE(ext_fname) TERMINATED BY EOF)
データ・ファイル(sample.dat)
Johny Quest,jqresume.txt,
Speed Racer,'/private/sracer/srresume.txt',
セカンダリ・データ・ファイル(jqresume.txt)
Johny Quest 500 Oracle Parkway ...セカンダリ・データ・ファイル(srresume.txt)
Speed Racer
400 Oracle Parkway
...ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
FILLERフィールドは、SQL*Loaderの
CHARデータ型を使用して読み込まれる、40バイトのデータ・フィールドにマップされています。ここでは、デフォルトのバイト長セマンティクスの使用を想定しています。文字長セマンティクスが使用された場合、フィールドは40文字データ・フィールドにマップされます -
SQL*Loaderでは、FILLERフィールド
ext_fnameのLOBFILE名が使用されます。(CHARデータ型を使用する) LOBFILEの最初のバイトからEOF文字までのデータがロードされます。既存のLOBFILEが指定されていない場合、RESUMEフィールドは空に初期化されます。
親トピック: LOBFILEからのLOBデータのロードの例
11.4.2.2.2 事前に決められたサイズのLOB
事前に決められたサイズのLOBを使用してLOBデータをロードできます。
例11-21では、制御ファイルの特定の列にロードするLOBのサイズを指定します。ロード時、列にロードしたLOBデータは、指定したサイズとみなされます。事前に決められたサイズのフィールドでは、データ解析機能を最適に実行できます。ただし、すべてのLOBデータが必ずしも同じサイズであるとはかぎりません。
例11-21 事前に決められたサイズのLOBを使用したLOBデータのロード
制御ファイルの内容
LOAD DATA
INFILE 'sample.dat'
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name CHAR(20),
1 "RESUME" LOBFILE(CONSTANT '/usr/private/jquest/jqresume.txt')
CHAR(2000))
データ・ファイル(sample.dat)
Johny Quest, Speed Racer,
セカンダリ・データ・ファイル(jqresume.txt)
Johny Quest
500 Oracle Parkway
...
Speed Racer
400 Oracle Parkway
...ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
このエントリでは、現行のロード・セッション中、最後にロードされたバイト位置に続けてロードを開始し、
CHARデータ型を使用して、jqresume.txtLOBFILEから2000バイトのデータをロードするように指定しています。ここでは、デフォルトのバイト長セマンティクスの使用を想定しています。文字長セマンティクスが使用された場合、SQL*Loaderでは、最後にロードされた文字の直後の文字から順番に、2000文字のデータがロードされます。詳細は、「文字長セマンティクス」を参照してください。
親トピック: LOBFILEからのLOBデータのロードの例
11.4.2.2.3 デリミタ付きLOB
サイズが異なるラージ・オブジェクト型(LOB)には、事前に決められたサイズのLOBが使用できないため、デリミタ付きLOBをSQL*Loaderで使用することを検討してください。
デリミタ付きのLOBデータ・インスタンスをロードする場合は、同じ列にサイズの異なるLOBをロードしても問題は発生しません。ただし、このような柔軟性によって、SQL*Loaderでデリミタ文字列を探してデータをスキャンする必要があるため、パフォーマンスに影響します。
例11-22 デリミタ付きLOBを使用したLOBデータのロード
この例では、boldのコールアウトに注目してください。
制御ファイルの内容
LOAD DATA
INFILE 'sample.dat'
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name CHAR(20),
1 "RESUME" LOBFILE( CONSTANT 'jqresume') CHAR(2000)
TERMINATED BY "<endlob>\n")
データ・ファイル(sample.dat)
Johny Quest,
Speed Racer,
セカンダリ・データ・ファイル(jqresume.txt)
Johny Quest
500 Oracle Parkway
... <endlob>
Speed Racer
400 Oracle Parkway
... <endlob>ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
CHARの最大長に2000が指定されているため、SQL*Loaderで、フィールドの最大長を推測でき、メモリーの使用量を最適化できます。最大長を指定する場合、小さすぎる値は指定しないように注意してください。TERMINATED BY句は、LOBを終了する文字列を指定します。かわりに、ENCLOSED BY句も使用できます。ENCLOSED BY句を使用すると、LOBFILE内のLOBの相対的な配置により柔軟性が少し高まります。これは、LOBFILE内のLOBが連続している必要がないためです。
親トピック: LOBFILEからのLOBデータのロードの例
11.4.2.2.4 Length-Value Pairで指定したLOB
ラージ・オブジェクト型(LOB)のロードにLength-Value Pairの指定を使用するとパフォーマンスが向上します。ただし、柔軟性は低下します。
Length-Value Pairを指定したLOBの場合は、LOBFILE内の各LOBの前に長さが付加されます。このように編成されたLOBデータのロードには、VARCHAR、VARCHARCまたはVARRAWデータ型を使用できます。
このロード方法を使用すると、デリミタ付きフィールドを使用するより高いパフォーマンスを得ることができます。ただし、柔軟性は損なわれます(たとえば、各LOBのロード前に、LOBの長さの確認が必要です)。
例11-23 Length-Value Pairを指定したLOBを使用したLOBデータのロード
制御ファイルの内容
次の例では、boldのコールアウトに注目してください。
LOAD DATA
INFILE 'sample.dat'
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name CHAR(20),
1 "RESUME" LOBFILE(CONSTANT 'jqresume') VARCHARC(4,2000))
データ・ファイル(sample.dat)
Johny Quest,
Speed Racer,
セカンダリ・データ・ファイル(jqresume.txt)
2 0501Johny Quest
500 Oracle Parkway
...
3 0000 ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
VARCHARC(4,2000)のエントリによって、LOBFILEのLOBがLength-Value Pair形式であり、最初の4バイトが長さを示すことをSQL*Loaderに指定します。この2000という値は、フィールドの最大サイズが2000であることを示します。ここでは、デフォルトのバイト長セマンティクスの使用を想定しています。文字長セマンティクスが使用された場合、最初の4文字は文字単位の長さとして解釈されます。フィールドの最大サイズは2000文字です。詳細は、「文字長セマンティクス」を参照してください。 -
JohnyQuestの前の0501は、次の501文字がLOBのデータであることを示します。 -
このエントリは、LOBが空である(NULLではない)ことを示します。
親トピック: LOBFILEからのLOBデータのロードの例
11.4.2.3 LOBFILEからLOBをロードする場合の考慮点
SQL*LoaderでLOBFILESからラージ・オブジェクト型(LOB)をロードする際に適用される制限事項とガイドラインに注意してください。
LOBFILEを使用してデータをロードする際には、次の点に注意が必要です。
-
LOBおよび
XML列のみがLOBFILEからロードできます。 -
特定のLOBのロードが失敗した場合、そのLOBを含むレコードは拒否されません。かわりに、結果は空のLOBを含むレコードになります。
XML列の場合、LOBのロードに失敗するとNULL値が挿入されます。 -
LOB列に対応するフィールドの最大長を指定する必要はありません。最大長を指定すると、SQL*Loaderでは最大長をメモリー使用量の最適化のヒントに使用します。そのため、最大長の指定では、実際の最大長よりも小さい値を指定しないでください。
-
LOBFILEからデータをロード中、位置指定(
pos_spec)はできません。 -
NULLIFまたはDEFAULTIFのフィールド条件は、LOBFILEから読み込まれたフィールドに基づくことはできません。 -
存在しないLOBFILEをフィールドのデータ・ソースに指定すると、そのフィールドは初期化されて空になります。そのフィールドを空にできない場合は、NULLに初期化されます。
-
表レベル・デリミタは、LOBFILEから読み込まれるフィールドには指定できません。
-
従来型パス・モードでSQL式を使用して
XML列をロードするか、LOB列を参照する場合は、SQL*LoaderでLOBデータを一時LOBとして処理する必要があります。こうした場合に最高のロード・パフォーマンスを得られるようにするために、一時LOBのパフォーマンスに関するガイドラインを参照してください。
関連トピック
親トピック: LOBFILEからのLOBデータのロード
11.4.3 LLSフィールドを含むデータ・ファイルのロード
データ・ファイルのフィールドがLOBロケーション指定子(LLS)フィールドの場合、LLS句を使用してこのことを示すことができます。
用途
LLSフィールドには、ファイル名、データ・ファイル内のLOBデータのオフセットおよび長さが含まれます。SQL*Loaderでは、この情報を使用してLOB列のデータを読み取ります。
使用上のノート
LOBは一部または全体をロードでき、任意の位置から任意の長さで開始できます。SQL LoaderではLLSフィールドの内容はfilename.ext.nnn.mmm/であると予期され、各要素の定義は次のとおりです。
-
filename.extは、LOBを含むファイルの名前です。 -
nnnは、ファイル内のLOBのバイト単位のオフセットです。 -
mmmは、バイト単位のLOBの長さです。-1の値は、LOBがNULLであることを示します。0の値は、LOBは存在するものの、空であることを示します。 -
スラッシュ(
/)は、フィールドの終端となります。
SQL*LoaderパラメータSDF_PREFIXを指定した場合、SQL*LoaderはSDF_PREFIXで指定されたディレクトリでファイルを検索します。指定しない場合、SQL*Loaderはデータ・ファイルと同じディレクトリを検索します。
次のいずれかに該当する場合、エラーが報告され、行は拒否されます。
-
ファイル名に相対パスまたは絶対パスの指定が含まれています。
-
ファイルが見つからない、オフセットが無効である、または長さがファイルの終わりを超えています。
-
フィールドの内容が予期した書式ではありません。
-
LLSフィールドに関連付けられた列のデータ型が
CLOB、BLOBまたはNCLOBではありません。
制限事項
-
LLSフィールドが制御ファイルの他のフィールドの句(
NULLIF句など)によって参照される場合、句の評価に使用される値は、データ・ファイル内の文字列であり、その文字列で示されるファイルのデータではありません。 -
LLS句で示されるファイルのデータの文字セットは、データ・ファイルと同じ文字セットとみなされます。 -
SQL*Loaderを実行するユーザーには、データ・ファイルへの読取りアクセス権限が必要です。
LLS句の指定例
次に、LLS句を含むSQL*Loader制御ファイルの例を示します。列はLOB型である必要があるため、列指定ではデータ型は必要ありません。
LOAD DATA
INFILE *
TRUNCATE
INTO TABLE tklglls
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' TRAILING NULLCOLS
(col1 , col2 NULLIF col1 = '1' LLS)
BEGINDATA
1,"tklglls1.dat.1.11/"親トピック: SQL*Loaderを使用したLOBのロード
11.5 SQL*Loaderを使用したBFILE列のロード
BFILEデータ型には、データベースの外側にあるオペレーティング・システム・ファイルの非構造化バイナリ・データが格納されます。
Oracle BFILEデータ型は、最大サイズ4GBのバイナリ・データへの参照を格納するOracle LOBデータ型です。
BFILE列または属性には、データを含む外部ファイルを示すロケータが格納されます。BFILEとしてロードする必要があるファイルは、ロード時に存在している必要はなく、後で作成できます。BFILEを使用するには、いくつかのデータベース管理タスクの実行が必要になります。ディレクトリ・オブジェクトとBFILEオブジェクトに対する制限もあります。そうした制限には、オペレーティング・システム・ファイルの構成方法に関する要件や、オペレーティング・システムのディレクトリ・パスに関する要件などがあります。Oracle Database 18c以降のリリースでは、BFILEデータ型で使用するディレクトリ・オブジェクトのパス名に、シンボリック・リンクを使用できません。SQL*Loaderでは、必要なオブジェクト(サーバーのファイル・システム上の物理ディレクトリに対する論理的な別名)がすでに作成されていると想定しています。
BFILE列に対応する制御ファイルのフィールドの記述は、列名の後にBFILE句を記述して行います。BFILE句には、引数としてディレクトリ・オブジェクト(server_directoryの別名)名の後にBFILE名が必要です。両方の引数を文字列の定数として指定することも、別のフィールドを通じて動的にロードすることもできます。
次にBFILEのロード例を示します。最初の例ではファイル名のみを動的に指定しますが、2番目の例ではBFILEとディレクトリ・オブジェクトの両方を動的に指定する方法を示します。
例11-24 BFILEを使用したデータのロード: ファイル名のみを動的に指定
制御ファイルの内容を次に示します。ディレクトリ名scott_dir1は引用符に囲まれており、そのまま使用されるため、文字列は大文字にせずそのまま指定します。
LOAD DATA
INFILE sample.dat
INTO TABLE planets
FIELDS TERMINATED BY ','
(pl_id CHAR(3),
pl_name CHAR(20),
fname FILLER CHAR(30),
pl_pict BFILE(CONSTANT "scott_dir1", fname))
データ・ファイルsample.datの内容を次に示します。
1,Mercury,mercury.jpeg,
2,Venus,venus.jpeg,
3,Earth,earth.jpeg,例11-25 BFILEを使用したデータのロード: ファイル名およびディレクトリを動的に指定
制御ファイルの内容を次に示します。dnameは、ロードしたファイルに対応するディレクトリ名を含む、データ・ファイルのフィールドにマップされていることに注意してください。
LOAD DATA
INFILE sample.dat
INTO TABLE planets
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(pl_id NUMBER(4),
pl_name CHAR(20),
fname FILLER CHAR(30),
dname FILLER CHAR(20),
pl_pict BFILE(dname, fname) )
データ・ファイルsample.datの内容を次に示します。
1, Mercury, mercury.jpeg, scott_dir1,
2, Venus, venus.jpeg, scott_dir1,
3, Earth, earth.jpeg, scott_dir2,11.6 コレクション(ネストした表およびVARRAY)のロード
LOBと同様、コレクションも、プライマリ・データ・ファイル(データ・インライン)またはSDF(データ・アウトライン)のいずれかからロードできます。
コレクション・データをロードする場合、コレクションに属するデータのインスタンスが終了したことをSQL*Loaderに伝える機能が必要です。これには、2つの方法があります。
-
それぞれのネストした表または
VARRAYインスタンスにロードされる行または要素の数を指定するには、DDL構文のCOUNT関数を使用します。COUNTに指定する値は、数字または数字を含む文字列のいずれかで、制御ファイルでCOUNT句よりも先に記述する必要があります。この位置の依存性は、COUNT句に固有です。COUNT(0)またはCOUNT(cnt_field)を指定して、カレント行のcnt_fieldが0の場合は、NULLIF句によって上書きされないかぎり、空のコレクション(NULLではない)になります。詳細は、「count_spec」を参照してください。制御ファイルで
COUNT句によってフィールドが指定され、そのフィールドがカレント行でNULLに設定されている場合、そのカウントを使用するコレクションは、カレント行でも空に設定されます。 -
TERMINATEDBYおよびENCLOSEDBY句を使用して、一意のコレクション・デリミタを指定します。SDF句が使用されている場合、この方法は使用できません。
制御ファイルでは、コレクションは、列オブジェクトと同様に記述します。一部、次のような相違点があります。
-
コレクションの記述には、前述の2つの機能を使用します。
-
コレクションの記述には、セカンダリ・データ・ファイル(SDF)を指定できます。
-
同じSDFのフィールド上にないかぎり、
NULLIFまたはDEFAULTIF句ではSDFのフィールドを参照できません。 -
フィールド名を引数として使用する句には、同じコレクションのフィールドに対するDDL指定でないかぎり、コレクション内のフィールド名を使用できません。
-
フィールド・リストには、非FILLERフィールドが1つと、複数のFILLERフィールドが含まれている必要があります。
VARRAYが列オブジェクトのVARRAYの場合、列オブジェクトの属性は、ネストしたフィールド・リストに記述されます。
- ネストした表およびVARRAYでの制限事項
ネストした表およびVARRAYに対しては制限があります。 - セカンダリ・データ・ファイル(SDF)
大きなネストした表とVARRAYのロードが必要なときには、セカンダリ・データ・ファイル(SDF)を使用できます。概念としてはプライマリ・データ・ファイルと同様です。
11.6.1 ネストした表およびVARRAYでの制限事項
ネストした表およびVARRAYに対しては制限があります。
ネストした表およびVARRAYには次の制限事項があります。
-
field_listには、collection_fld_specを含めることはできません。 -
VARRAY内にネストしたcol_obj_specには、collection_fld_specを含めることはできません。 -
field_listの一部として指定したcolumn_nameは、VARRAYパラメータを前に付けたcolumn_nameと同一である必要があります。
また、ネストした表を含む表にロードする場合、複数のロードへの細分化およびSIDの生成は自動的に行われないため注意してください。
例11-26に、VARRAYおよびネストした表のロード例を示します。
例11-26 VARRAYおよびネストした表のロード
制御ファイルの内容
LOAD DATA
INFILE 'sample.dat' "str '\n' "
INTO TABLE dept
REPLACE
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(
dept_no CHAR(3),
dname CHAR(25) NULLIF dname=BLANKS,
1 emps VARRAY TERMINATED BY ':'
(
emps COLUMN OBJECT
(
name CHAR(30),
age INTEGER EXTERNAL(3),
2 emp_id CHAR(7) NULLIF emps.emps.emp_id=BLANKS
)
),
3 proj_cnt FILLER CHAR(3),
4 projects NESTED TABLE SDF (CONSTANT "pr.txt" "fix 57") COUNT (proj_cnt)
(
projects COLUMN OBJECT
(
project_id POSITION (1:5) INTEGER EXTERNAL(5),
project_name POSITION (7:30) CHAR
NULLIF projects.projects.project_name = BLANKS
)
)
)
データ・ファイル(sample.dat)
101,MATH,"Napier",28,2828,"Euclid", 123,9999:0 210,"Topological Transforms",:2
セカンダリ・データ・ファイル(SDF)(pr.txt)
21034 Topological Transforms 77777 Impossible Proof
ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
TERMINATEDBY句では、VARRAYのインスタンス終了記号(COUNT句は使用されていないことに注意)を指定します。 -
このFILLERフィールドの存在によって発生するフィールド名の競合は、フルネームによるフィールド参照(ドット表記法を使用)によって解決されます。
-
proj_cntは、COUNT句に対する引数として使用するFILLERフィールドです。 -
このエントリでは、次の内容が指定されます。
-
pr.txtと呼ばれるSDFをデータのソースとして指定します。また、SDF内で固定レコード形式を指定します。 -
COUNT句が0の場合、コレクションは空に初期化されます。コレクションを空に初期化するもう1つの方法は、DEFAULTIF句を使用する方法です。ネストした表のフィールドの記述に対応するメイン・フィールド名は、そのネストした非FILLERフィールドのフィールド名、特に、列オブジェクトのフィールド名の記述と同じです。
-
親トピック: コレクション(ネストした表およびVARRAY)のロード
11.6.2 セカンダリ・データ・ファイル(SDF)
大きなネストした表とVARRAYのロードが必要なときには、セカンダリ・データ・ファイル(SDF)を使用できます。概念としてはプライマリ・データ・ファイルと同様です。
プライマリ・データ・ファイルと同様に、SDFは、レコードおよびフィールドで構成されたレコードの集まりです。SDFは、制御ファイルのフィールドごとに指定されます。これは、大きいネストした表およびVARRAYをロードする場合に有効です。
ノート:
SDFをデータ・ソースとして命名できるのは、collection_fld_specのみです。
SDFを指定するには、SDFパラメータを使用します。SDFパラメータの後に、ファイル指定文字列、または1つ以上のファイル指定文字列を含むデータ・フィールドにマップされたFILLERフィールドを指定します。
プライマリ・データ・ファイルの場合、各SDFについて次を指定できます。
-
レコード形式(固定、ストリームまたは可変)の指定。また、ストリーム・レコード形式が使用される場合、レコード・セパレータを指定できます。
-
レコード・サイズの指定。
-
CHARACTERSET句を使用した、SDFの文字セットの指定(「異なる文字コード体系の処理」を参照)。 -
特にSDF指定(SDF指定を含むコレクションのすべてのメンバー・フィールドまたは属性で、LOBFILEフィールドを含むフィールドを除く)のあるフィールドに対するデフォルトのデリミタの指定(デリミタ指定を使用)
SDFについては、次のことにも注意してください。
-
存在しないSDFをフィールドのデータ・ソースに指定すると、そのフィールドは初期化されて空になります。そのフィールドを空にできない場合は、NULLに初期化されます。
-
表レベル・デリミタは、SDFから読み込まれるフィールドには指定できません。
-
64KBを超えるSDFをロードするには、
READSIZEパラメータを使用してより大きな物理レコード・サイズを指定できます。コマンドラインからでも、OPTIONS句の一部としてでもREADSIZEパラメータを指定できます。関連項目:
親トピック: コレクション(ネストした表およびVARRAY)のロード
11.7 動的または静的SDF指定の選択
SQL*Loaderを使用すると、SDFを静的に指定(実際のファイル名を指定)したり、動的に指定(FILLERフィールドをファイル名のソースとして使用)したりできます。
動的または静的SDF指定では、SDFのend-of-file (EOF)に達するとファイルが閉じられます。そのファイルから、さらにデータを読み取ってみると、空のフィールドからデータを読み取ることと同じ結果が得られます。
動的セカンダリ・ファイル指定では、動作は多少異なります。参照ファイルの指定が変更されると、常に、古いファイルはクローズされ、データは新しい参照先ファイルの最初から読み込まれます。
データ・ソース・ファイルの動的な切替えは、リセットの効果があります。たとえば、SQL*Loaderを使用して、現行のファイルから前回オープンしていたファイルに切り替える場合、前回オープンしていたファイルを再オープンし、そのファイルの最初からデータが読み込まれます。
同じSDFを、2つの異なるフィールドのソースとして指定しないでください。指定すると、通常、2つのフィールドは、データを別々に読み取ります。
11.8 親表を子表から分割してのロード
ネストした表の列を含む表をロードする場合、親表を子表から分割してロードする場合があります。
SID(システム生成またはユーザー定義)がロード時にわかっている場合(SIDがデータとともにデータ・ファイルにある場合)、親表と子表を別々にロードできます。
次の例は、ユーザー指定SIDを持つ親および子表をロードする方法を示しています。
例11-27 ユーザー定義SIDを使用した親表のロード
制御ファイルの内容
LOAD DATA
INFILE 'sample.dat' "str '|\n' "
INTO TABLE dept
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
( dept_no CHAR(3),
dname CHAR(20) NULLIF dname=BLANKS ,
mysid FILLER CHAR(32),
1 projects SID(mysid))
データ・ファイル(sample.dat)
101,Math,21E978407D4441FCE03400400B403BC3,| 210,"Topology",21E978408D4441FCE03400400B403BC3,|
ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
mysidは、実際のSIDを含むデータ・ファイルのフィールドにマップされているFILLERフィールドで、SID句に対する引数として指定できます。
例11-28 ユーザー定義SIDを使用した子表のロード
制御ファイルの内容
LOAD DATA
INFILE 'sample.dat'
INTO TABLE dept
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
1 SID(sidsrc)
(project_id INTEGER EXTERNAL(5),
project_name CHAR(20) NULLIF project_name=BLANKS,
sidsrc FILLER CHAR(32))
データ・ファイル(sample.dat)
21034, "Topological Transforms", 21E978407D4441FCE03400400B403BC3, 77777, "Impossible Proof", 21E978408D4441FCE03400400B403BC3,
ノート:
例の左に付けた太字の数字は、次のノートと対応しています。
-
表レベルの
SID句を指定すると、SQL*Loaderによって、ネストした表の記憶表がロードされます。sidsrcは、実際のSIDのソースである、FILLERフィールド名です。
- VARRAY列ロード時のメモリーの問題
VARRAY列のロード時にメモリーの問題が発生する場合があります。
11.8.1 VARRAY列ロード時のメモリーの問題
VARRAY列のロード時にメモリーの問題が発生する場合があります。
次に、VARRAY列をロードする場合の注意事項を示します。
-
VARRAYは、データベースにロードされる前にクライアント・メモリーに作成されます。VARRAYの各要素には、データベースにロードする前に、4バイトのクライアント・メモリーが必要です。そのため、1000個の要素を持つVARRAYをロードする場合は、VARRAYをデータベースにロードする前に、それぞれのVARRAYインスタンスに、4000バイト以上のクライアント・メモリーが必要です。多くの場合、SQL*Loaderでは、VARRAYの構築やロードに、2倍から3倍のメモリー量を必要とします。 -
BINDSIZEパラメータを使用して、SQL*Loaderでレコードのロードに割り当てるメモリーの量を指定します。BINDSIZEに指定された値に応じて、SQL*Loaderで、ロード中の各フィールドのサイズを考慮し、1回のトランザクションでロードできる行数を判断します。行数が多ければトランザクションは少なくなり、パフォーマンスは向上します。ただし、システムのメモリー量に制限がある場合、パフォーマンスを優先せず、SQL*Loaderで算出した値より低い値をROWSに指定できます。 -
非常に大きい
VARRAYまたは多数の小さいVARRAYが原因で、ロード中にメモリーが不足する場合があります。この場合は、BINDSIZEまたはROWSにより小さい値を指定し、再ロードします。
親トピック: 親表を子表から分割してのロード