ヘッダーをスキップ

Oracle Database ユーティリティ
10g リリース2(10.2)

B19211-01
目次
目次
索引
索引

戻る 次へ

10 オブジェクト、LOBおよびコレクションのロード

この章の内容は、次のとおりです。

列オブジェクトのロード

制御ファイルの列オブジェクトは、その属性によって記述されています。列オブジェクトの基になるオブジェクト型がNOT FINALであると宣言されると、制御ファイルの列オブジェクトは、基になるオブジェクト型から導出されたサブタイプの(導出および宣言された)属性によって記述されます。データ・ファイルでは、列オブジェクトの各属性に対応するデータは、単純なリレーショナル列に対応するデータ・フィールドと同様の形式でデータ・ファイルに記述されています。


注意:

SQL*Loaderによる列オブジェクトなどの複合データ型のサポートによって、制御ファイル内に、2つの同じフィールド名が存在する可能性があります。1つは列に対応し、もう1つは列オブジェクトの属性に対応する場合です。制御ファイルに同名のフィールドが存在する場合、特定の句がフィールド(たとえば、WHENNULLIFDEFAULTIFSIDOIDREFBFILEなど)を参照できるため、名前の重複が発生する場合があります。

そのため、フィールドを参照する句を使用する場合は、フルネームで指定する必要があります。たとえば、フィールドfld1COLUMN OBJECTに指定されており、そこにフィールドfld2が含まれる場合、NULLIFなどの句でfld2を指定する場合は、フィールドのフルネームfld1.fld2を使用する必要があります。 


次に、列オブジェクトのロードに関する例を示します。

ストリーム・レコード形式への列オブジェクトのロード

例10-1に、事前にサイズが決まっているフィールドにデータがある例を示します。終了文字は、物理レコードの終わりを示します。オペレーティング・システムのファイル処理句(os_file_proc_clause)のカスタム・レコード・セパレータを使用して、物理レコードの終わりを示すこともできます。

例10-1    ストリーム・レコード形式への列オブジェクトのロード

Control File Contents

LOAD DATA
INFILE 'sample.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) )

Datafile (sample.dat)

101 Mathematics  Johny Quest       30   1024
237 Physics      Albert Einstein   65   0000
注意
  1. この列オブジェクトの型指定は、ネストした列オブジェクトの記述にも繰り返し使用できます。

可変レコード形式への列オブジェクトのロード

例10-2に、デリミタ・フィールドにデータがある例を示します。

例10-2    可変レコード形式への列オブジェクトのロード

Control File Contents

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)) )

Datafile (sample.dat)

3  000034101,Mathematics,Johny Q.,30,1024,
   000039237,Physics,"Albert Einstein",65,0000,
注意
  1. "var"文字列には、各レコードの先頭にある長さフィールドのバイト数(この例では6)が含まれます。値が指定されない場合、デフォルトは5バイトです。可変レコードの最大サイズは、2の32乗-1で、それ以上の値を指定するとエラーになります。

  2. 位置を指定しなくても、一般構文では同じ結果(列オブジェクトの名前の後に、カッコで囲まれた属性のリストが続く)になります。また、省略された型指定については、デフォルトで長さが255のCHAR型になります。

  3. 最初の6バイト(斜体で示した部分)に、次のレコードの長さを指定します。これらの長さ指定には、emp_idフィールドの後の終了記号のために無視される改行文字も含まれます。

ネストした列オブジェクトのロード

例10-3に、ネストした列オブジェクト(他の列オブジェクト内にネストした1つの列オブジェクト)の制御ファイルの記述方法を示します。

例10-3    ネストした列オブジェクトのロード

Control File Contents

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))))

Datafile (sample.dat)

101,Mathematics,Johny Q.,30,1024,"Barbie",650-251-0010,
237,Physics,"Albert Einstein",65,0000,Wife Einstein,654-3210,
注意
  1. このエントリでは、列オブジェクトにネストした列オブジェクトを指定します。

導出サブタイプを使用した列オブジェクトのロード

例10-4に、NOT FINALのベース・オブジェクト型を拡張して新しく導出されたサブタイプを作成する例を示します。表定義の列オブジェクトは、ベース・オブジェクト型であると宣言されますが、サブタイプがベース・オブジェクト型から導出される場合は、SQL*Loaderによってサブタイプを列オブジェクトにロードできます。

例10-4    サブタイプを使用した列オブジェクトのロード

Object Type Definitions

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);

Control File Contents

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)))

Datafile (sample.dat)

101,Mathematics,Johny Q.,301189453,10249,
237,Physics,"Albert Einstein",128606590,10030,
注意
  1. TREAT AS句で指定すると、SQL*Loaderでは、実際の宣言型がperson_typeである列オブジェクトpersonが、導出型employee_typeであると宣言されたかのように処理されます。

  2. empid属性はemployee_typeの属性であるため、ここで使用できます。TREAT AS句が指定されていない場合、この属性は、列の宣言型の属性ではないためエラーを返します。

オブジェクトに対するNULL値の指定

非スカラー・データ型でNULL値を指定する場合、スカラー・データ型で指定するよりも複雑です。オブジェクトは、その属性のサブセットをNULLにするか、すべての属性をNULL(NULLオブジェクトにかぎります)にするか、またはオブジェクト自身をNULL(アトミックNULLオブジェクト)にできます。

NULL属性の指定

オブジェクト列に対応するフィールドでは、NULLIF句を使用して、特殊属性をNULLに初期化するフィールド条件を指定できます。例10-5に例を示します。

例10-5    NULLIF句を使用したNULL属性の指定

Control File Contents

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.emp_id=BLANKS))

Datafile (sample.dat)

2  101             Johny Quest            1024
   237   Physics   Albert Einstein   65   0000
注意
  1. 各属性に対応するNULLIF句は、属性値をNULLにする条件を示します。

  2. dept_mgrのage属性の値はNULLです。dept_nameの値もNULLです。

アトミックNULLの指定

列オブジェクトがNULL値(アトミックNULL)を取る条件を制御ファイルで指定するには、NULLIF句で使用するオブジェクトの名前は、マップ・フィールドの論理的な組合せに基づいている必要があります(たとえば、例10-5では、指定されたマップ・フィールドは、dept_nodept_namenameageおよびemp_idです。dept_mgrは、データ・ファイルのどのフィールドにも対応していない(マップされていない)ため、指定されたマップ・フィールドではありません)。

前述の方法は使用可能ですが、オブジェクトがNULL値を取るための条件が、マップ・フィールドに依存していない場合は、理想的な方法ではありません。このような場合は、FILLERフィールドを使用できます。

FILLERフィールドをデータ・ファイルのフィールドにマップし(列オブジェクトがアトミックNULLかどうかを示す)、そのFILLERフィールドを列オブジェクトのNULLIF句のフィールド条件で使用できます。この例を例10-6に示します。

例10-6    FILLERフィールドを使用したデータのロード

Control File Contents

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)

Datafile (sample.dat)

101,Mathematics,n,Johny Q.,,1024,"Barbie",608-251-0010,,
237,Physics,,"Albert Einstein",65,0000,,650-654-3210,n,

注意
  1. FILLERフィールド(データ・ファイルがマップされており、対応する列がない)はCHAR型(デリミタ付きフィールドであるため、CHARのデフォルトはCHAR(255))のフィールドです。NULLIF句は、FILLERフィールド自体には使用できません。

  2. is_nullフィールドが空白の場合は、NULL(アトミックNULL)の値を取得します。

    参照:

    「FILLERフィールドの指定」 

ユーザー定義コンストラクタを使用した列オブジェクトのロード

Oracleデータベースでは、すべてのオブジェクト型に対してデフォルトのコンストラクタが自動的に提供されます。このコンストラクタを使用するには、コンストラクタに対するコールで、その型のすべての属性を引数として指定する必要があります。オブジェクトの新しいインスタンスが作成されると、その属性は引数リスト内の対応する値を取ります。このコンストラクタは、属性値コンストラクタと呼ばれます。SQL*Loaderでは、列オブジェクトのロード時に、デフォルトで属性値コンストラクタが使用されます。

1つ以上のユーザー定義コンストラクタを作成することによって、属性値コンストラクタを上書きできます。ユーザー定義コンストラクタを作成する場合、オブジェクトの新しいインスタンスが作成されると、常に、ユーザー定義論理を実行する型本体を指定する必要があります。ユーザー定義コンストラクタの引数リストは、属性値コンストラクタと同じ場合もありますが、型本体で実装される論理は異なります。

ユーザー定義コンストラクタのファンクションの引数リストが属性値コンストラクタの引数リストと一致する場合、従来型パスとダイレクト・パスではSQL*Loaderの動作が異なります。従来型パス・モードでは、ユーザー定義コンストラクタがコールされます。ダイレクト・パス・モードでは、属性値コンストラクタがコールされます。この相違点を例10-7に示します。

例10-7    一致するコンストラクタを使用した列オブジェクトのロード

Object Type Definitions

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);

Control File Contents

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,
注意
  1. この制御ファイルが従来型パス・モードで実行された場合、名前フィールドのJohny Q.およびAlbert Einsteinは、両方とも大文字でロードされます。これは、従来型パス・モードではユーザー定義コンストラクタがコールされるためです。これに対し、この制御ファイルがダイレクト・パス・モードで実行された場合、名前フィールドは入力データに表示されているとおりにロードされます。これは、ダイレクト・パス・モードでは属性値コンストラクタがコールされるためです。

引数リストが属性値コンストラクタと一致しないユーザー定義コンストラクタの作成もできます。この場合は、従来型パス・モードおよびダイレクト・パス・モードの両方で、属性値コンストラクタがコールされます。例10-8に示す定義について考えてみます。

例10-8    一致しないコンストラクタを使用した列オブジェクトのロード

Object Type Definitions

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);

例10-7で説明した制御ファイルがこれらの定義に従って使用された場合、名前フィールドは、入力データに表示されているとおりに(大文字と小文字の組合せで)ロードされます。これは、従来型パス・モードおよびダイレクト・パス・モードの両方で属性値コンストラクタがコールされるためです。

SQL式でユーザー定義コンストラクタを明示的に参照することによって、従来型パス・モードを使用してこの表をロードすることもできます。例10-9に例を示します。

例10-9    コンストラクタが一致しない場合のSQLを使用した列オブジェクトのロード

Control File Contents

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,
注意
  1. この場合、従業員列オブジェクトが、SQL式を使用してロードされます。この式によって、正しい数の引数が含まれているユーザー定義コンストラクタが起動されます。名前フィールドのJohny Q.およびAlbert Einsteinは、両方とも小文字でロードされます。また、各行の従業員列オブジェクトの従業員識別子は、employee_ids順序番号から値を取ります。

例10-9に示した制御ファイルがダイレクト・パス・モードで使用された場合は、次のエラーが通知されます。

SQL*Loader-951: Error calling once/load initialization
ORA-26052: Unsupported type 121 for SQL expression on column EMPLOYEE.

オブジェクト表のロード

オブジェクト表のロードに必要な制御ファイルの構文は、典型的なリレーショナル表のロードの場合とほぼ同じです。例10-10に、主キーOIDを使用したオブジェクト表のロード例を示します。

例10-10    主キーOIDを使用したオブジェクト表のロード

Control File Contents

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))

Datafile (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でのみ使用できます。

例10-11に、行オブジェクトを使用したシステム生成OIDのロード例を示します。

例10-11    OIDのロード

Control File Contents

   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))

Datafile (sample.dat)

3  Johny Quest, 18, 007, 21E978406D3E41FCE03400400B403BC3,
   Speed Racer, 16, 000, 21E978406D4441FCE03400400B403BC3,
注意
  1. OID句には、s_oidのロード・フィールドがOIDを含むように指定します。カッコが必要です。

  2. s_oidに有効な16進数が含まれていない場合、そのレコードは拒否されます。

  3. データ・ファイルのOIDは文字列で、32バイトの16進数として解釈されます。32バイトの16進数は、後で16バイトのRAWに変換されてオブジェクト表に格納されます。

サブタイプを使用したオブジェクト表のロード

オブジェクト表の列オブジェクトがNOT FINALに基づいている場合、SQL*Loaderによって導出サブタイプをオブジェクト表にロードできます。前述のとおり、オブジェクト表に導出サブタイプをロードする場合に必要な構文は、典型的なリレーショナル表のロードの場合とほぼ同じです。ただし、この場合、実際に使用するサブタイプがオブジェクト表で有効であるかどうかをSQL*Loaderで判断できるように、サブタイプに名前を指定する必要があります。この概念を例10-12に示します。

例10-12    サブタイプを使用したオブジェクト表のロード

Object Type Definitions

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;

Control File Contents

   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))

Datafile (sample.dat)

   Johny Quest, 18, 007, 32,
   Speed Racer, 16, 000, 20,
注意
  1. TREAT AS句で指定すると、SQL*Loaderでは、実際の宣言型がemployee_typeであるオブジェクト表が、hourly_emps_type型であると宣言されたかのように処理されます。

  2. hours属性はhourly_emps_typeの属性であるため、ここで使用できます。TREAT AS句が指定されていない場合、この属性は、オブジェクト表の宣言型の属性ではないためエラーを返します。

REF列のロード

SQL*Loaderは、システム生成OIDのREF列、主キーREF列および主キーを使用可能な有効範囲なしREF列をロードできます。

システム生成OID型のREF列

システム生成REF列をロードする場合、SQL*Loaderでは、REF列を構築する実OIDが残りのデータとともにデータ・ファイル内にあるとみなされます。REF列に対応するフィールドの記述は、列名の後にREF句を記述することによって行います。

REF句には、引数として表名とOIDを取ります。その引数は、定数として、または(FILLERフィールドを使用して)動的に指定できます。適切な構文については、「ref_spec」を参照してください。例10-13に、システム生成OID型のREF列のロード例を示します。

例10-13    システム生成REF列のロード

Control File Contents

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))

Datafile (sample.dat)

22345, QuestWorld, 21E978406D3E41FCE03400400B403BC3, EMPLOYEES_V2,
23423, Geography, 21E978406D4441FCE03400400B403BC3, EMPLOYEES_V2,
注意
  1. 指定した表が存在しない場合、レコードは拒否されます。また、dept_mgrフィールド自体には、データ・ファイルのフィールドはマップされません。

主キーREF列

主キーREF列をロードするには、SQL*Loader制御ファイルのフィールドで列名の後にREF句を記述する必要があります。REF句には、カンマで区切ったフィールド名および定数値のリストが引数として必要です。最初の引数は表名で、その後にロードするREF列の基になる主キーOIDを指定する引数を記述します。適切な構文については、「ref_spec」を参照してください。

SQL*Loaderでは、引数の順序は、参照されている表で主キーOIDを作成する列の相対順序に一致しているとみなされます。例10-14に、主キーREF列のロード例を示します。

例10-14    主キーREF列のロード

Control File Contents

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))

Datafile (sample.dat)

22345, QuestWorld, 007,
23423, Geography, 000,

主キーが使用可能な有効範囲なしREF列

主キーが使用可能な有効範囲なしREF列によって、システム生成および主キーの両方の型のREFを参照できます。このようなREF列をロードするための構文は、システム生成OID型のREF列または主キーREF列にロードする場合と同じです。例10-13「システム生成REF列のロード」および例10-14「主キーREF列のロード」を参照してください。

主キーが使用可能な有効範囲なしREF列をロードする場合は、次の制限が適用されます。

LOBのロード

LOBは、ラージ・オブジェクト型です。SQL*Loaderでは、次のLOB型がサポートされています。

LOBは列データ型で、NCLOB以外は、オブジェクトの属性データ型です。LOBは実際の値を持ち、その値はNULLでも「値なし(空)」でもかまいません。LOBに格納される長さ0のフィールドがある場合は、SQL*Loaderによって空のLOBが作成されます。(他のデータ型の場合は、このデータ型とは異なり、長さ0の文字列に対して、列はSQL*LoaderによってNULLに設定されます。)つまり、NULL値をLOB列にロードする方法は、NULL句を使用する方法のみです。

XML列は、SYS.XMLTYPE型であると宣言された列です。SQL*Loaderは、XML列をCLOBと同様に処理します。次の項で説明するプライマリ・データ・ファイルまたはLOBFILESからのLOBデータのロード方法は、XML列のロードに適用できます。


注意:

LOBフィールドにSQL文字列は指定できません。これは、LOBFILE_specを指定する場合も同じです。 


LOBは非常に大きなデータであるため、SQL*Loaderでは、LOBデータをプライマリ・データ・ファイル(残りのデータを持つインライン)またはLOBFILEのいずれかからロードできます。この項では、次の項目について説明します。

プライマリ・データ・ファイルからのLOBデータのロード

プライマリ・データ・ファイルから内部LOB(BLOBCLOBおよびNCLOB)またはXML列をロードするには、次の標準SQL*Loader形式を使用できます。

これらの各形式については、次の項で説明します。

事前に決められたサイズのフィールドのLOBデータ

例10-15に示すように、これはLOBデータをロードする場合、最も高速で、概念的に単純な形式です。


注意:

ロードするLOBデータは、サイズが均等ではないため、サイズが小さいデータ・フィールドに空白を埋め込み、全LOBデータが同じサイズになるようにできます。 


この形式でLOBをロードするには、ロード時のデータ型としてCHARまたはRAWを使用する必要があります。

例10-15    事前に決められたサイズのフィールドのLOBデータ

Control File Contents

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)

Datafile (sample.dat)

Johny Quest      Johny Quest
             500 Oracle Parkway
             jquest@us.oracle.com ...
注意
  1. DEFAULTIF句が使用されているため、RESUMEが含まれているデータ・フィールドが空の場合、NULLのLOBではなく、空のLOBになります。ただし、DEFAULTIFではなくNULLIF句が使用されている場合は、空のデータ・フィールドではなくNULLになります。

    また、ロード時に、CHAR以外にもSQL*Loaderのデータ型を使用できます。たとえば、BLOBのロード時、RAWデータ型を使用する場合があります。

デリミタ付きフィールドのLOBデータ

この形式で、同じ列(データ・ファイルのフィールド)で異なるサイズのLOBを、問題なく処理できます。ただし、このような柔軟性によって、SQL*Loaderで区切り文字列を探してデータをスキャンする必要があるため、パフォーマンスに影響します。

単一キャラクタのデリミタで、文字列のデリミタを指定する場合は、データ・ファイルのキャラクタ・セットに注意してください。データ・ファイルのキャラクタ・セットが制御ファイルのキャラクタ・セットと異なる場合は、デリミタを16進文字列の表記法で指定できます(X'hexadecimal string')。デリミタを実際に16進文字列で指定する場合は、入力データ・ファイルのキャラクタ・セット中の有効な文字で指定する必要があります。一方、16進文字列で指定しない場合、デリミタは、クライアント(制御ファイル)のキャラクタ・セットで指定してください。この場合、デリミタは、SQL*Loaderによってデータ・ファイル内で検索される前に、データ・ファイルのキャラクタ・セットに変換されます。

次のことに注意してください。

例10-16にデリミタ付きフィールドへのLOBデータのロードの例を示します。

例10-16    デリミタ付きフィールドのLOBデータのロード

Control File Contents

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>')

Datafile (sample.dat)

Johny Quest,<startlob>        Johny Quest
                          500 Oracle Parkway
                          jquest@us.oracle.com ...   <endlob>
2  |Speed Racer, .......
注意
  1. <startlob>および<endlob>は、囲み文字列です。デフォルトのバイト長セマンティクスでは、CHAR(507)を使用して読み込むことができるLOBの最大長は507バイトです。文字長セマンティクスが使用された場合、最大長は507文字になります。詳細は、「文字長セマンティクス」を参照してください。

  2. レコード・セパレータ'|' は、<endlob>のすぐ後にあり、その後に改行文字が続く場合、改行は、次のレコードの一部として解釈されます。代替方法は、レコード・セパレータに改行部分を作成することです(たとえば'|\n'、または16進ではX'7C0A')。

Length-Value PairフィールドのLOBデータ

VARCHARVARCHARCまたはVARRAWデータ型を使用して、Length-Value Pairフィールドで編成されたLOBデータをロードできます。このロード方法を使用すると、デリミタ付きフィールドを使用するより高いパフォーマンスを得ることができます。ただし、柔軟性は損なわれます(たとえば、ロード前に各LOBの長さの確認が必要です)。例10-17に、Length-Value PairフィールドのLOBデータのロード例を示します。

例10-17    Length-Value PairフィールドへのLOBデータのロード

Control File Contents

  LOAD DATA 
1 INFILE 'sample.dat' "str '<endrec>\n'"
  INTO TABLE person_table
  FIELDS TERMINATED BY ','
     (name       CHAR(25),
2    "RESUME"    VARCHARC(3,500))

Datafile (sample.dat)

  Johny Quest,479                Johny Quest
                             500 Oracle Parkway
                             jquest@us.oracle.com
                                    ... <endrec>
3    Speed Racer,000<endrec>
注意
  1. バックスラッシュ・エスケープ文字がサポートされていない場合、例の中でレコード・セパレータとして使用されている文字列は、16進数の表記法で表現されます。

  2. "RESUME" は、CLOB列に対応するフィールドです。制御ファイルでは、VARCHARCがそのフィールドで、フィールド長は3バイト、最大サイズは500バイト(バイト長セマンティクスで)です。文字長セマンティクスが使用された場合、長さは3文字で最大サイズは500文字です。詳細は、「文字長セマンティクス」を参照してください。

  3. VARCHARCのlengthサブフィールドは、0(サブフィールドの値が空)です。このため、LOBインスタンスは、空に初期化されます。

LOBFILEからのLOBデータのロード

LOBデータは、非常に長いデータであるため、プライマリ・データ・ファイルからではなく、LOBFILEからロードすると有効です。LOBFILEでは、LOBデータのインスタンスは、フィールド(事前に決められたサイズ、デリミタ付き、Length-Value)内にあるとみなされますが、これらのフィールドは、レコードに編成されていません(LOBFILEにはレコードの概念がありません)。そのため、レコードを扱うことによって発生する処理のオーバーヘッドを回避できます。このようなデータの編成方法は、LOBのロードにとって理想的です。

LOBFILEからロードしたLOBをメモリーに合わせる必要はありません。SQL*Loaderでは、64KB単位でLOBFILEが読み込まれます。

LOBFILEのデータ・フィールドは、次のいずれかの型です。

これらの各フィールド型の使用例については、「LOBFILEからのLOBデータのロードの例」を参照してください。前述のすべてのフィールド型は、XML列のロードに使用できます。

LOBFILE構文については、「lobfile_spec」を参照してください。

動的および静的LOBFILE指定

LOBFILEを静的に指定(制御ファイルにファイル名を指定)するか、または動的に指定(FILLERフィールドをファイル名のソースとして使用)できます。いずれの場合も、LOBFILEがEOFで終了しない場合は、LOBFILEの終わりに到達するとファイルがクローズされ、そのファイルからさらにデータを読み込む場合は、空のフィールドからデータを読み込むことになります。

ただし、LOBFILEをEOFで終了する場合は、ファイルからデータを読み込むと、常に、ファイル全体が戻されます。

同じLOBFILEを、2つの異なるフィールドのソースとして指定しないでください。指定すると、通常、2つのフィールドは、データを別々に読み込みます。

LOBFILEからのLOBデータのロードの例

この項では、LOBFILEの異なるフィールド型からデータをロードする例を示します。

ファイル当たり1つのLOB

例10-18では、各LOBFILEは、それぞれ1つのLOBのソースです。この方法で編成されたLOBデータをロードするには、列名またはフィールド名の後にLOBFILEデータ型を指定します。

例10-18    LOBFILE当たり1つのLOBを使用したLOBデータのロード

Control File Contents

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)

Datafile (sample.dat)

Johny Quest,jqresume.txt,
Speed Racer,'/private/sracer/srresume.txt',

Secondary Datafile (jqresume.txt)

             Johny Quest
         500 Oracle Parkway
            ...

Secondary Datafile (srresume.txt)

         Speed Racer
     400 Oracle Parkway
        ...
注意
  1. FILLERフィールドは、SQL*LoaderのCHARデータ型を使用して読み込まれる、40バイトのデータ・フィールドにマップされています。ここでは、デフォルトのバイト長セマンティクスの使用を想定しています。文字長セマンティクスが使用された場合、フィールドは40文字データ・フィールドにマップされます。

  2. SQL*Loaderでは、FILLERフィールドext_fnameのLOBFILE名が使用されます。(CHARデータ型を使用する)LOBFILEの最初のバイトからEOF文字までのデータがロードされます。既存のLOBFILEが指定されていない場合、RESUMEフィールドは空に初期化されます。

事前に決められたサイズのLOB

例10-19では、制御ファイルの特定の列にロードするLOBのサイズを指定します。ロード時、列にロードしたLOBデータは、指定したサイズとみなされます。事前に決められたサイズのフィールドでは、データ解析機能を最適に実行できます。ただし、すべてのLOBデータが必ずしも同じサイズであるとはかぎりません。

例10-19    事前に決められたサイズのLOBを使用したLOBデータのロード

Control File Contents

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))

Datafile (sample.dat)

Johny Quest,
Speed Racer,

Secondary Datafile (jqresume.txt)

             Johny Quest
         500 Oracle Parkway
            ...
             Speed Racer
         400 Oracle Parkway
            ...
注意
  1. このエントリでは、現行のロード・セッション中、最後にロードされたバイト位置に続けてロードを開始し、CHARデータ型を使用して、jqresume.txt LOBFILEから2000バイトのデータをロードするように指定しています。ここでは、デフォルトのバイト長セマンティクスの使用を想定しています。文字長セマンティクスが使用された場合、SQL*Loaderでは、最後にロードされた文字の直後の文字から順番に、2000文字のデータがロードされます。詳細は、「文字長セマンティクス」を参照してください。

デリミタ付きフィールドのLOB

例10-20では、LOBFILEがデリミタ付きフィールドである場合の、LOBデータの例を示します。この形式では、サイズの異なるLOBを同じ列にロードしても、問題は発生しません。ただし、このような柔軟性によって、SQL*Loaderで区切り文字列を探してデータをスキャンする必要があるため、パフォーマンスに影響します。

例10-20    デリミタ付きフィールドのLOBを使用したLOBデータのロード

Control File Contents

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")

Datafile (sample.dat)

Johny Quest,
Speed Racer,

Secondary Datafile (jqresume.txt)

             Johny Quest
         500 Oracle Parkway
            ... <endlob>
             Speed Racer
         400 Oracle Parkway
            ... <endlob>
注意
  1. CHARの最大長に2000が指定されているため、SQL*Loaderで、フィールドの最大長を推測でき、メモリーの使用量を最適化できます。最大長を指定する場合、小さすぎる値は指定しないように注意してください。TERMINATED BY句は、LOBのロードを終了する文字列を指定します。かわりに、ENCLOSED BY句も使用できます。ENCLOSED BY句を使用すると、LOBFILE(LOBFILE内のLOBには順序が不要)内でのLOBの相対的な位置指定に関して、多少柔軟に対応できます。

Length-Value Pairで指定したLOB

例10-21では、LOBFILEの各LOBの先頭でデータ長が定義されています。VARCHARVARCHARCまたはVARRAWデータ型を使用して、この方法で編成されたLOBデータをロードできます。

このロード方法を使用すると、デリミタ付きフィールドを使用するより高いパフォーマンスを得ることができます。ただし、柔軟性は損なわれます(たとえば、各LOBのロード前に、LOBの長さの確認が必要です)。

例10-21    Length-Value Pairを指定したLOBを使用したLOBデータのロード

Control File Contents

LOAD DATA 
INFILE 'sample.dat'
INTO TABLE person_table
FIELDS TERMINATED BY ','
   (name          CHAR(20),
1  "RESUME"       LOBFILE(CONSTANT 'jqresume') VARCHARC(4,2000))

Datafile (sample.dat)

Johny Quest,
Speed Racer,

Secondary Datafile (jqresume.txt)

2      0501Johny Quest
       500 Oracle Parkway
          ... 
3      0000
注意
  1. VARCHARC(4,2000)のエントリによって、LOBFILEのLOBがLength-Value Pair形式であり、最初の4バイトが長さを示すことをSQL*Loaderに指定します。この2000という値は、フィールドの最大サイズが2000であることを示します。ここでは、デフォルトのバイト長セマンティクスの使用を想定しています。文字長セマンティクスが使用された場合、最初の4文字は文字単位の長さとして解釈されます。フィールドの最大サイズは2000文字です。詳細は、「文字長セマンティクス」を参照してください。

  2. Johny Questの前の0501は、次の501文字がLOBのデータであることを示します。

  3. このエントリは、LOBが空である(NULLではない)ことを示します。

LOBFILEからLOBをロードする場合の考慮点

LOBFILEからLOBをロードする場合は、次のことに注意してください。

BFILE列のロード

BFILEデータ型には、データベースの外側にあるオペレーティング・システム・ファイルの非構造化バイナリ・データが格納されます。BFILE列または属性には、データを含む外部ファイルを示すロケータが格納されます。BFILEとしてロードされるファイルは、ロード時に存在している必要はなく、後で作成できます。SQL*Loaderでは、必要なオブジェクト(サーバーのファイル・システム上の物理ディレクトリに対する論理的な別名)がすでに作成されていると想定しています。詳細は、『Oracle Databaseアプリケーション開発者ガイド - ラージ・オブジェクト』を参照してください。

BFILE列に対応する制御ファイルのフィールドの記述は、列名の後にBFILE句を記述して行います。BFILE句には、引数としてディレクトリ・オブジェクト(server_directoryの別名)名の後にBFILE名が必要です。いずれの引数も文字列定数として指定するか、他のフィールドを介して動的にロードできます。詳細は、『Oracle Database SQLリファレンス』を参照してください。

次の2つのBFILEのロード例を示します。例10-22では、1つのファイル名のみを動的に指定する方法を、例10-23では、BFILEとディレクトリ・オブジェクトの両方を動的に指定する方法を示します。

例10-22    BFILEを使用したデータのロード: ファイル名のみを動的に指定

Control File Contents

LOAD DATA
INFILE sample.dat
INTO TABLE planets
FIELDS TERMINATED BY ','
   (pl_id    CHAR(3), 
   pl_name   CHAR(20),
   fname     FILLER CHAR(30),
1  pl_pict   BFILE(CONSTANT "scott_dir1", fname))

Datafile (sample.dat)

1,Mercury,mercury.jpeg,
2,Venus,venus.jpeg,
3,Earth,earth.jpeg,
注意
  1. ディレクトリ名は引用符に囲まれており、そのまま使用されるため、文字列は大文字にせずそのまま指定します。

例10-23    BFILEを使用したデータのロード: ファイル名およびディレクトリを動的に指定

Control File Contents

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),
1  dname     FILLER CHAR(20),
   pl_pict   BFILE(dname, fname) )

Datafile (sample.dat)

1, Mercury, mercury.jpeg, scott_dir1,
2, Venus, venus.jpeg, scott_dir1,
3, Earth, earth.jpeg, scott_dir2,
注意
  1. dnameは、ロードしたファイルに対応するディレクトリ名を含む、データ・ファイルのフィールドにマップされています。

コレクション(ネストした表およびVARRAY)のロード

LOBと同様、コレクションも、プライマリ・データ・ファイル(データ・インライン)またはSDF(データ・アウトライン)のいずれかからロードできます。SDFの詳細は、「セカンダリ・データ・ファイル(SDF)」を参照してください。

コレクション・データをロードする場合、コレクションに属するデータのインスタンスが終了したことをSQL*Loaderに伝える機能が必要です。これには、2つの方法があります。

制御ファイルでは、コレクションは、列オブジェクトと同様に記述します。詳細は、「列オブジェクトのロード」を参照してください。一部、次のような相違点があります。

ネストした表およびVARRAYでの制限事項

ネストした表およびVARRAYには次の制限事項があります。

また、ネストした表を含む表にロードする場合、複数のロードへの細分化およびSIDの生成は自動的に行われないため注意してください。

例10-24に、VARRAYおよびネストした表のロード例を示します。

例10-24    VARRAYおよびネストした表のロード

Control File Contents

   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
    )
  )
)

Datafile (sample.dat)

 101,MATH,"Napier",28,2828,"Euclid", 123,9999:0
 210,"Topological Transforms",:2

Secondary Datafile (SDF) (pr.txt)

21034 Topological Transforms
77777 Impossible Proof
注意
  1. TERMINATED BY句では、VARRAYのインスタンス終了記号(COUNT句は使用されていないことに注意)を指定します。

  2. このFILLERフィールドの存在によって発生するフィールド名の競合は、フルネームによるフィールド参照(ドット表記法を使用)によって解決されます。

  3. proj_cntは、COUNT句に対する引数として使用するFILLERフィールドです。

  4. このエントリでは、次の内容が指定されます。

    • pr.txtと呼ばれるSDFをデータのソースとして指定します。また、SDF内で固定レコード形式を指定します。

    • COUNT句が0の場合、コレクションは空に初期化されます。コレクションを空に初期化するもう1つの方法は、DEFAULTIF句を使用する方法です。ネストした表のフィールドの記述に対応するメイン・フィールド名は、そのネストした非FILLERフィールドのフィールド名、特に、列オブジェクトのフィールド名の記述と同じです。

セカンダリ・データ・ファイル(SDF)

SDFとプライマリ・データ・ファイルの概念は類似しています。プライマリ・データ・ファイルと同様に、SDFは、レコードおよびフィールドで構成されたレコードの集まりです。SDFは、制御ファイルごとに指定されます。SDFは、大きいネストした表およびVARRAYをロードする場合に有効です。


注意:

SDFをデータ・ソースとして命名できるのは、collection_fld_specのみです。 


SDFを指定するには、SDFパラメータを使用します。SDFパラメータの後に、ファイル指定文字列、または1つ以上のファイル指定文字列を含むデータ・フィールドにマップされたFILLERフィールドを指定します。

プライマリ・データ・ファイルについては、各SDFに対して次の指定ができます。

SDFについては、次のことにも注意してください。

動的および静的SDF指定

SDFを静的に指定(実際のファイル名を指定)するか、または動的に指定(FILLERフィールドをファイル名のソースとして使用)できます。いずれの場合も、SDFのEOFに到達するとファイルはクローズされ、そのファイルからさらにデータを読み込む場合は、空のフィールドからデータを読み込むことになります。

動的セカンダリ・ファイル指定では、動作は多少異なります。参照ファイルの指定が変更されると、常に、古いファイルはクローズされ、データは新しい参照先ファイルの最初から読み込まれます。

このようなデータ・ソース・ファイルの動的な切替えは、リセットの効果があります。たとえば、SQL*Loaderを使用して、現行のファイルから前回オープンしていたファイルに切り替える場合、前回オープンしていたファイルを再オープンし、そのファイルの最初からデータが読み込まれます。

同じSDFを、2つの異なるフィールドのソースとして指定しないでください。指定すると、通常、2つのフィールドは、データを別々に読み込みます。

親表を子表から分割してのロード

ネストした表の列を含む表をロードする場合、親表を子表から分割してロードする場合があります。SIDがロード時にわかっている場合(SIDがデータとともにデータ・ファイルにある場合)、親表と子表を別々にロードできます。

例10-25に、ユーザー定義SIDを使用した親表のロード方法を示します。

例10-25    ユーザー定義SIDを使用した親表のロード

Control File Contents

   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))

Datafile (sample.dat)

101,Math,21E978407D4441FCE03400400B403BC3,|
210,"Topology",21E978408D4441FCE03400400B403BC3,|
注意
  1. mysidは、実際のSIDを含むデータ・ファイルのフィールドにマップされているFILLERフィールドで、SID句に対する引数として指定できます。

例10-26に、ユーザー定義SIDを使用した子表(ネストした表の記憶表)のロード方法を示します。

例10-26    ユーザー定義SIDを使用した子表のロード

Control File Contents

   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))

Datafile (sample.dat)

21034, "Topological Transforms", 21E978407D4441FCE03400400B403BC3,
77777, "Impossible Proof", 21E978408D4441FCE03400400B403BC3,
注意
  1. 表レベルのSID句を指定すると、SQL*Loaderによって、ネストした表の記憶表がロードされます。sidsrcは、実際のSIDのソースである、FILLERフィールド名です。

VARRAY列ロード時のメモリーの問題

次に、VARRAY列をロードする場合の注意事項を示します。


戻る 次へ
Oracle
Copyright © 2005 Oracle Corporation.

All Rights Reserved.
目次
目次
索引
索引