1. データベース・ユーティリティ
  2. SQL*Loader
  3. SQL*Loaderの概念

7 SQL*Loaderの概念

次の各項では、SQL*Loaderの概念について説明します。

SQL*Loaderを使用してOracleデータベースにデータをロードする前に、これらの基本概念を理解する必要があります。

親トピック: SQL*Loader

7.1 SQL*Loaderの機能

SQL*Loaderは、外部ファイルからOracle Databaseの表にデータをロードします。

強力なデータ解析エンジンによって、あらゆるデータ形式のデータファイルに対応できます。SQL*Loaderを使用して、次のことが可能です。

  • データ・ファイルがデータベースと異なるシステム上にある場合のネットワークを介したデータのロード。

  • 同一のロード・セッションでの複数のデータ・ファイルからのデータのロード。

  • 同一のロード・セッションでの複数の表へのデータのロード。

  • データの文字セットの指定。

  • ロード・データの選択(レコード値に基づいたロード)。

  • ロード前の、SQL関数を使用したデータ処理。

  • 指定した列に対する、一意の順序キーの生成。

  • オペレーティング・システムのファイル・システムを使用したデータ・ファイルへのアクセス。

  • ディスク、テープまたはNamed Pipeからのデータのロード。

  • 高度なエラー・レポートの生成による、トラブルシューティングの支援。

  • 複合オブジェクト・リレーショナル・データの任意のロード。

  • セカンダリ・データ・ファイルを使用した、LOBおよびコレクションのロード。

  • 従来型ロード、ダイレクト・パス・ロードまたは外部表ロードの使用。「従来型パス・ロード、ダイレクト・パス・ロードおよび外部表ロード」を参照してください。

SQL*Loaderは、制御ファイルを指定する場合と指定しない場合の2つの方法で使用できます。制御ファイルは、SQL*Loaderの動作と、ロードに使用される1つ以上のデータ・ファイルを制御します。制御ファイルを使用すると、ロード操作を詳細に制御できるため、より複雑なロード環境に対応できます。ただし、単純なロードでは、制御ファイルを指定せずにSQL*Loaderを使用できます(これはSQL*Loaderエクスプレス・モードと呼ばれます)。詳細は、「SQL*Loaderエクスプレス」を参照してください。

SQL*Loaderの出力先は、データがロードされるOracle Database、ログ・ファイル、不良ファイル(拒否されたレコードが存在する場合)で、廃棄ファイルに出力される場合もあります。

次の図に、制御ファイルを使用する標準的なSQL*Loaderセッションのフローの例を示します。

図7-1 SQL*Loaderの概要

図7-1の説明が続きます
図7-1 SQL*Loaderの概要の説明

親トピック: SQL*Loaderの概念

7.2 SQL*Loaderのパラメータ

SQL*Loaderは、sqlldrコマンドを指定すると起動しますが、オプションで、ロード操作の様々な特性を確立するパラメータを指定した場合も起動します。

常に、値がほとんど変わらない同じパラメータを使用する場合は、コマンドラインではなく、次の方法でパラメータを指定すると効率的です。

  • パラメータは、パラメータ・ファイルとしてグループ化できます。その後、PARFILEパラメータを使用して、そのパラメータ・ファイルの名前をコマンドラインで指定できます。

  • 一部のパラメータは、OPTIONS句を使用して、SQL*Loaderの制御ファイル内に指定することもできます。

コマンドラインで指定したパラメータは、パラメータ・ファイルまたはOPTIONS句で指定したパラメータ値を上書きします。

関連項目:

親トピック: SQL*Loaderの概念

7.3 SQL*Loader制御ファイル

制御ファイルは、SQL*Loaderが解釈できる言語で記述されたテキスト・ファイルです。

制御ファイルは、データの場所、データの分析と解釈方法、データの挿入先などをSQL*Loaderに通知します。

通常、制御ファイルには、次の3つの項目が次の順序で含まれます。

  • セッション全体の情報

  • 表およびフィールド・リストの情報

  • 入力データ(オプションの項目)

制御ファイルの構文には、次の注意事項があります。

  • 構文は、自由形式で記述できます(文は複数行になってもかまいません)。

  • 構文の大文字と小文字は、一重引用符または二重引用符で囲まれた文字列の場合のみ区別され、それ以外では区別されません。

  • 先頭にハイフンを2つ(--)続けて入力することによって、コメントを挿入できます。ハイフンから行の終わりまでがコメントになります。オプションである第3セクションでは、二重ハイフンがコメントとしてではなくデータとして解釈されるため、このセクションでのコメントはサポートされません。

  • CONSTANTおよびZONEキーワードは、SQL*Loaderでは特別な意味があり、予約されています。競合を回避するために、表または列の名前にCONSTANTまたはZONEという語を使用しないことをお薦めします。

    関連項目:

    制御ファイルの構文およびセマンティクスの詳細は、「SQL*Loader制御ファイル・リファレンス」を参照してください

親トピック: SQL*Loaderの概念

7.4 入力データおよびデータ・ファイル

制御ファイルに指定された1つ以上のデータ・ファイル(またはファイルのオペレーティング・システムに相当するもの)などから、SQL*Loaderにデータが読み込まれます。

SQL*Loaderから見ると、データ・ファイルのデータはレコードとして構成されています。データ・ファイルには、固定レコード形式、可変レコード形式またはストリーム・レコード形式があります。レコード形式は、INFILEパラメータを使用して制御ファイルに指定することができます。レコード形式が指定されない場合、デフォルトはストリーム・レコード形式になります。

ノート:

制御ファイル内部でデータが指定されている場合(INFILE *が制御ファイルに指定されている場合)、そのデータはデフォルトでレコード終了記号を使用したストリーム・レコード形式として解釈されます。

  • 固定レコード形式
    固定レコード形式のファイルでは、データ・ファイルにあるすべてのレコードが同じバイト長です。
  • 可変レコード形式およびSQL*Loader
    可変レコード形式のファイルでは、文字フィールドの各レコード長がデータ・ファイルの各レコードの開始位置に含まれています。
  • ストリーム・レコード形式
    ストリーム・レコード形式では、レコードのサイズ指定ではなく、SQL*Loaderでレコード終了記号を読み込むことによって、レコードが確認されます。
  • 論理レコード
    SQL*Loaderでは、入力データは、指定されたレコード形式で物理レコードに編成されます。デフォルトでは、1つの物理レコードが1つの論理レコードになります。
  • データ・フィールド
    論理レコードが作成されると、フィールドが設定されます。

親トピック: SQL*Loaderの概念

7.4.1 固定レコード形式

固定レコード形式のファイルでは、データ・ファイルにあるすべてのレコードが同じバイト長です。

この形式は柔軟性はありませんが、その結果、可変長またはストリーム形式よりも高いパフォーマンスを得ることができます。また、固定形式は簡単に指定できます。例:

INFILE datafile_name "fix n"

ここでは、特殊なデータ・ファイルが、SQL*Loaderによって全レコードがnバイト長の固定レコード形式で解釈されるように指定しています。

例7-1に、固定レコード形式で解釈されるデータ・ファイル(example1.dat)を指定する制御ファイルを示します。この例のデータ・ファイルには5つの物理レコードが含まれ、各レコードには従業員の番号と名前を含むフィールドがあります。5つの各フィールドは空白を含めて11バイト長です。この例を説明する目的で、レコードの空白を示すためにピリオドが使用されていますが、実際のレコードにはピリオドはありません。この点に注意すると、1つ目のレコード396,...ty,.は、ちょうど11バイトです(シングルバイト文字セットだとします)。2つ目のレコードは4922,beth,で、改行文字(\n)が後に続き、11バイトとなります。(改行文字は固定レコード形式では必要ありません。ここでは単に、使用された場合はレコード長のバイトとしてカウントされることを説明するために使用されています。)

文字長セマンティクスが使用されているファイルでも、長さは常にバイト単位で解析されます。これは、文字長セマンティクスで処理されるフィールドとバイト長セマンティクスで処理されるフィールドがファイル内に混在する可能性があるため必要です。詳細は、「文字長セマンティクス」を参照してください。

例7-1 固定レコード形式でのデータのロード

load data
infile 'example1.dat'  "fix 11"
into table example
fields terminated by ',' optionally enclosed by '"'
(col1, col2)

example1.dat:

396,...ty,.4922,beth,\n
68773,ben,.
1,.."dave",
5455,mike,.

親トピック: 入力データおよびデータ・ファイル

7.4.2 可変レコード形式およびSQL*Loader

可変レコード形式のファイルでは、文字フィールドの各レコード長がデータ・ファイルの各レコードの開始位置に含まれています。

この形式は、固定レコード形式より柔軟性があり、ストリーム・レコード形式よりパフォーマンスに優れています。可変レコード形式の場合、たとえば、次のように指定できます。

INFILE "datafile_name" "var n"

nには、レコード長フィールドのバイト数を指定します。nを指定しない場合、SQL*Loaderは長さを5バイトとみなします。nに、40より大きい値を指定すると、エラーになります。

次の例に、データ・ファイルexample2.datのデータを検索し、レコードの最初の3バイトがフィールドの長さを示す可変レコード形式を使用するようにSQL*Loaderに指示する制御ファイルの指定を示します。example2.datデータ・ファイルは、3つの物理レコードで構成されています。1つ目のレコードは009 (9)バイト長、2つ目のレコードは010 (10)バイト長(1バイトの改行を含む)、3つ目は012 (12)バイト長(1バイトの改行を含む)で指定されています。改行文字は、可変レコード形式では必要ありません。この例でも、データ・ファイルはシングルバイト文字セットであるとします。この例の説明目的として、example2.datのピリオドは空白を示していますが、フィールドには実際のピリオドは含まれません。

例7-2 可変レコード形式でのデータのロード

データのロード:

load data
infile 'example2.dat'  "var 3"
into table example
fields terminated by ',' optionally enclosed by '"'
(col1 char(5),
 col2 char(7))

example2.datの内容: 

009.396,.ty,0104922,beth,01268773,benji,

文字長セマンティクスが使用されているファイルでも、長さは常にバイト単位で解析されます。これは、文字長セマンティクスで処理されるフィールドとバイト長セマンティクスで処理されるフィールドがファイル内に混在する可能性があるため必要です。

関連トピック

親トピック: 入力データおよびデータ・ファイル

7.4.3 ストリーム・レコード形式

ストリーム・レコード形式では、レコードをサイズで指定してではなく、SQL*Loaderでレコード終了記号を読み込むことによって、レコードが確認されます。

ストリーム・レコード形式は最も柔軟性のある形式ですが、パフォーマンスに影響する場合があります。ストリーム・レコード形式として解釈されるようにデータ・ファイルを指定するには、次のように指定します。 

INFILE datafile_name ["str terminator_string"]

strは、ファイルがストリーム・レコード形式であることを示しています。terminator_stringには、次の'char_string'またはX'hex_string'を指定します。

  • 'char_string'は、一重引用符または二重引用符で囲まれた文字列です。

  • X'hex_string'は、16進形式のバイト列です。

terminator_stringに、特別な(印字不可能な)文字が含まれる場合、X'hex_string'で指定する必要があります。ただし、一部の印字不可能な文字列('char_string')はバックスラッシュを使用すると指定できます。例:

  • \nは、LFを示します。

  • \tは、水平タブを示します。

  • \fは、改ページを示します。

  • \vは、垂直タブを示します。

  • \rは、改行を示します。

セッションのNLS_LANG初期化パラメータで指定される文字セットがデータ・ファイルの文字セットと異なる場合、文字列はデータ・ファイルの文字セットに変換されます。これはSQL*Loaderがデフォルトのレコード終了記号を確認する前に実行されます。

16進文字列はデータ・ファイルの文字セット内にあるとみなされ、変換は実行されません。

UNIXベースのプラットフォームでは、terminator_stringを指定しない場合、デフォルトで改行文字\nが使用されます。

Windowsベースのプラットフォームでは、terminator_stringを指定しない場合、SQL*Loaderでは\nまたは\r\nのうちデータ・ファイル内で先に現れる文字がレコード終了記号として使用されます。つまり、データ・ファイルの1つ以上のレコードで、フィールドに\nが埋め込まれていることがわかっている場合に、\r\nをレコード終了記号として使用するには、これを指定する必要があります。

例7-3に、terminator_stringが文字列'|\n'で指定されている場合に、ストリーム・レコード形式でデータをロードする方法を示します。バックスラッシュを使用すると、文字列に印字不可能な改行文字を指定することができます。

関連項目:

例7-3 ストリーム・レコード形式でのデータのロード

load data
infile 'example3.dat'  "str '|\n'"
into table example
fields terminated by ',' optionally enclosed by '"'
(col1 char(5),
 col2 char(7))

example3.dat:
396,ty,|
4922,beth,|

親トピック: 入力データおよびデータ・ファイル

7.4.4 論理レコード

入力データは、指定されたレコード形式で物理レコードに編成されます。デフォルトでは、1つの物理レコードが1つの論理レコードになります。

柔軟性の向上により、SQL*Loaderでは複数の物理レコードを1つの論理レコードに結合することもできます。

論理レコードは、次のいずれかの方針に従って構成できます。

  • 固定数の物理レコードを結合してそれぞれの論理レコードを構成する

  • 特定の条件が真である場合に物理レコードを結合して論理レコードを構成する

    関連項目:

親トピック: 入力データおよびデータ・ファイル

7.4.5 データ・フィールド

論理レコードが作成されると、フィールドが設定されます。

フィールド設定では、制御ファイルのフィールド指定を使用して、論理レコードのデータのどの部分が制御ファイルのフィールドに対応しているのかをSQL*Loaderで判断します。2つ以上のフィールド指定に同じデータを使用できます。また、論理レコードに、制御ファイルのフィールド指定で使用されないデータを含めることもできます。

ほとんどの場合、制御ファイルのフィールドに、論理レコードの特定の位置や長さの指定が必要です。この部分は、次のような形式で指定します。

  • データ・フィールドの開始バイト位置または終了位置(あるいはその両方)を指定できます。この指定形式に柔軟性はありませんが、フィールド設定によって高パフォーマンスが得られます。

  • 特定のデータ・フィールドの区切り(囲みまたは終了、あるいはその両方)文字列を指定できます。デリミタ付きデータ・フィールドは、データ・フィールドの開始バイト位置が指定されている場合を除いて、直前のデータ・フィールドの終了位置から始まるとみなされます。

  • バイト・オフセットまたはデータ・フィールドの長さ(あるいはその両方)を指定できます。この方法では、各フィールドは、直前のフィールドが終了した位置から、指定されたバイト数の位置で始まり、指定された長さの位置で終了します。

  • 長さと値のペアのデータ型を使用できます。この場合、データ・フィールドの最初のnバイト数に、データ・フィールドの残りの長さについての情報が含まれています。

    関連項目:

親トピック: 入力データおよびデータ・ファイル

7.5 LOBFILEおよびセカンダリ・データ・ファイル(SDF)

LOBデータは、非常に長いデータであるため、LOBFILEからロードすると有効です。

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

たとえば、従業員の名前、IDおよび履歴を格納する表があるとします。この表をロードする場合、従業員名および従業員IDをメイン・データ・ファイルから読み込み、非常に長い従業員の履歴をLOBFILEから読み込むことができます。

また、簡単にXMLデータをロードする場合にLOBFILEを使用するとします。XML列を使用して、構造化データおよび半構造化データのモデルを保持できます。そのようなデータは、非常に長いデータです。

セカンダリ・データ・ファイル(SDF)とプライマリ・データ・ファイルの概念は類似しています。プライマリ・データ・ファイルと同様に、SDFは、レコードおよびフィールドで構成されたレコードの集まりです。SDFは、制御ファイルのフィールドごとに指定されます。SDFをデータ・ソースとして命名できるのは、collection_fld_specのみです。

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

関連項目:

親トピック: SQL*Loaderの概念

7.6 データ変換およびデータ型の指定

従来型パス・ロード中に、データ・ファイルのデータ・フィールドが、データベースの列に変換されます(概念的にはダイレクト・パス・ロードと同様ですが、実装は異なります)。

変換には、次の2つのステップがあります。

  1. SQL*Loaderで、制御ファイルにあるフィールド指定を使用してデータ・ファイルの形式を解釈し、次に、入力データを解析します。そのデータを使用してSQL INSERT文に対応するバインド配列を移入します。バインド配列は、SQL*Loaderがロード対象のデータを格納するメモリー内の領域です。バインド配列が一杯の場合、データはデータベースに転送されます。バインド配列のサイズは、SQL*LoaderのBINDSIZEおよびREADSIZEパラメータによって制御されます。

  2. データベースがデータを受け取り、INSERT文を実行してデータベースにデータを格納します。

Oracle Databaseでは、列のデータ型を使用して最終的な格納形式にデータを変換します。データ・ファイル内のフィールドとデータベース内の列の違いに注意する必要があります。また、SQL*Loaderの制御ファイルで定義されているフィールドのデータ型は、列のデータ型と同じではないことにも注意してください。

関連項目:

親トピック: SQL*Loaderの概念

7.7 廃棄レコードおよび拒否レコード

入力ファイルから読み込まれたすべてのレコードが、データベースに挿入されるわけではありません。

挿入されないレコードは、不良ファイルまたは廃棄ファイルに書き込まれます。

  • 不良ファイル
    不良ファイルには、SQL*LoaderまたはOracle Databaseによって拒否レコードが書き込まれます。
  • 廃棄ファイル
    SQL*Loaderの実行によって、廃棄ファイルをコールするファイルが作成されることがあります。

親トピック: SQL*Loaderの概念

7.7.1 不良ファイル

不良ファイルには、SQL*LoaderまたはOracle Databaseによって拒否レコードが書き込まれます。

不良ファイルを指定していない場合に拒否されたレコードがあると、SQL*Loaderによって不良ファイルが自動的に作成されます。ファイルの名前はデータ・ファイルと同じで、拡張子は.badになります。次に、その理由を示します。

親トピック: 廃棄レコードおよび拒否レコード

7.7.1.1 SQL*Loaderによって拒否されたレコード

入力形式が不適切なデータ・ファイル・レコードは、SQL*Loaderによって拒否されます。

たとえば、2番目の囲みデリミタがない場合や、デリミタ付きフィールドが最大長を超えている場合、レコードは、SQL*Loaderによって拒否されます。拒否レコードは、不良ファイルに書き込まれます。

親トピック: 不良ファイル

7.7.1.2 SQL*Loaderの操作中にOracle Databaseによって拒否されたレコード

データ・ファイル・レコードは、SQL*Loaderによって受け取られた後、データベースに送られ、行として表に挿入されます。

データベースによって有効であると判断された行は、表に挿入されます。行が無効であると判断された場合、レコードは拒否され、SQL*Loaderにより不良ファイルに書き込まれます。行が無効であると判断される例としては、キーが重複している場合、必須入力フィールドに対応するデータがNULL値の場合、またはフィールドにOracleデータ型ではないデータ型が指定された場合が考えられます。

関連項目:

親トピック: 不良ファイル

7.7.2 廃棄ファイル

SQL*Loaderの実行によって、廃棄ファイルをコールするファイルが作成されることがあります。

ファイルが作成されるのは必要な場合のみで、廃棄ファイルを使用可能にすることを指定してある場合にかぎります。廃棄ファイルには、制御ファイルに指定されているレコード選択基準に一致しなかったため、ロード対象から除外されたレコードが入ります。

したがって、廃棄ファイルには、データベースのどの表にも挿入されなかったレコードが格納されます。廃棄ファイルに格納可能なレコードの最大数を指定できます。レコードのデータがいずれかの表に書き込まれる場合、このレコードは廃棄ファイルには書き込まれません。

関連項目:

親トピック: 廃棄レコードおよび拒否レコード

7.8 ログ・ファイルおよびログ情報

SQL*Loaderで処理が開始されると、ログ・ファイルが作成されます。

ログ・ファイルを作成できない場合、処理は終了します。このログ・ファイルにはロード中に発生したエラーに関する記述など、ロードに関する詳細情報が記録されます。

親トピック: SQL*Loaderの概念

7.9 従来型パス・ロード、ダイレクト・パス・ロードおよび外部表ロード

SQL*Loaderでデータをロードするには、いくつかの方法があります。

  • 従来型パス・ロード
    従来型パス・ロードでは、入力レコードがフィールド指定を基に解析され、各データ・フィールドが対応するバインド配列(SQL*Loaderがロードするデータを格納するメモリー内の領域)にコピーされます。
  • ダイレクト・パス・ロード
    ダイレクト・パス・ロードでは、入力レコードがフィールド指定を基に解析され、入力フィールド・データが列のデータ型に変換されて列配列が作成されます。
  • 外部表ロード
    外部表はデータベース内に存在しない表として定義されている表で、アクセス・ドライバが用意されている任意の形式が可能です。
  • 外部表およびSQL*Loaderの選択
    外部表とSQL*Loaderのレコード解析は類似しているため、通常、同じレコード形式での大幅なパフォーマンスの違いはありません。ただし、外部表とSQL*Loaderのアーキテクチャは異なるため、一方の方法が他方より適している場合があります。
  • SQL*Loaderと外部表との処理内容の違い
    この項では、外部表を使用したデータのロード方法(ORACLE_LOADERアクセス・ドライバを使用)と、SQL*Loaderの従来型パス・ロードおよびダイレクト・パス・ロードを使用したデータのロード方法の重要な違いについて説明します。

親トピック: SQL*Loaderの概念

7.9.1 従来型パス・ロード

従来型パス・ロードでは、入力レコードがフィールド指定を基に解析され、各データ・フィールドが対応するバインド配列(SQL*Loaderがロードするデータを格納するメモリー内の領域)にコピーされます。

バインド配列が一杯の場合(または読み取るデータが残っていない場合)、配列挿入操作が実行されます。

SQL*Loaderでは、バインドの配列に挿入後、LOBフィールドが格納されます。そのため、LOBフィールドの処理にエラーが発生した場合(たとえば、LOBFILEがないなど)、LOBフィールドは空のままになります。配列の挿入の実行後にLOBデータがロードされるため、BEFOREおよびAFTER行トリガーはLOB列に対して機能しない場合もあります。これは、SQL*Loaderで列にLOBの内容をロードする機会を持つ前にトリガーが起動されるためです。たとえば、LOB列C1にデータをロードして、BEFORE行トリガーを使用してそのLOB列の内容を調べ、その結果を基に、他の列C2にロードされる値を導出するとします。これは、トリガーの起動時にLOBの内容がロードされていないため不可能です。

関連項目:

親トピック: 従来型パス・ロード、ダイレクト・パス・ロードおよび外部表ロード

7.9.2 ダイレクト・パス・ロード

ダイレクト・パス・ロードでは、入力レコードがフィールド指定を基に解析され、入力フィールド・データが列のデータ型に変換されて列配列が作成されます。

この列配列は、Oracle Databaseブロック形式でデータ・ブロックを作成するブロック・フォーマッタに渡されます。新しくフォーマットされたデータベース・ブロックはデータベースに直接書き込まれるため、通常行われるデータ処理の大部分が省略されます。ダイレクト・パス・ロードによる処理は、従来型パス・ロードと比較すると非常に高速ですが、制限事項がいくつかあります。

  • パラレル・ダイレクト・パス
    パラレル・ダイレクト・パス・ロードでは、複数のダイレクト・パス・ロード・セッションで同じデータ・セグメントを同時にロードできます(セグメント内の並列化が可能です)。

親トピック: 従来型パス・ロード、ダイレクト・パス・ロードおよび外部表ロード

7.9.2.1 パラレル・ダイレクト・パス

パラレル・ダイレクト・パス・ロードでは、複数のダイレクト・パス・ロード・セッションで 同じデータ・セグメントを同時にロードできます(セグメント内の並列化が可能です)。

パラレル・ダイレクト・パスには、ダイレクト・パスより多くの制約事項があります。

7.9.3 外部表ロード

外部表はデータベース内に存在しない表として定義されている表で、アクセス・ドライバが用意されている任意の形式が可能です。

Oracle Databaseでは、ORACLE_LOADERおよびORACLE_DATAPUMPの2つのアクセス・ドライバが提供されています。外部表を記述するメタデータを提供することで、外部表内のデータをあたかも標準的なデータベース表内に存在しているデータのように公開できます。

外部表ロードでは、外部データ・ファイルに含まれているデータの外部表が作成されます。ロード処理では、INSERT文が実行され、データ・ファイルのデータがターゲット表に挿入されます。

従来型パス・ロードおよびダイレクト・パス・ロードではなく、外部表ロードを使用した場合のメリットは、次のとおりです。

  • データ・ファイルが大きい場合、外部表のロードではパラレルでファイルのロードを試みます。

  • 外部表ロードでは、外部表の作成に使用されるINSERT文の一部としてSQL関数およびPL/SQLファンクションを使用することによってロードされるデータを変更できます。

ノート:

Windowsオペレーティング・システムでの名前付きパイプを使用した外部表ロードは、サポートされません。

関連項目:

親トピック: 従来型パス・ロード、ダイレクト・パス・ロードおよび外部表ロード

7.9.4 外部表およびSQL*Loaderの選択

外部表とSQL*Loaderのレコード解析は類似しているため、通常、同じレコード形式での大幅なパフォーマンスの違いはありません。ただし、外部表とSQL*Loaderのアーキテクチャは異なるため、一方の方法が他方より適している場合があります。

次の状況では、最適なロード・パフォーマンスを得るために外部表を使用します。

  • データベースへのロード時にデータを変換する場合

  • 透過的にパラレル処理を行う前に、外部データを分割する必要がない場合

次の状況では、最適なロード・パフォーマンスを得るためにSQL*Loaderを使用します。

  • リモートでデータをロードする場合

  • データに対して変換を行う必要がなく、そのデータをパラレルでロードする必要がない場合

  • データをロードする必要があり、ステージング表に索引を追加する必要がある場合

親トピック: 従来型パス・ロード、ダイレクト・パス・ロードおよび外部表ロード

7.9.5 SQL*Loaderと外部表との処理内容の違い

この項では、外部表を使用したデータのロード方法(ORACLE_LOADERアクセス・ドライバを使用)と、SQL*Loaderの従来型パス・ロードおよびダイレクト・パス・ロードを使用したデータのロード方法の重要な違いについて説明します。

ここで示す情報は、ORACLE_DATAPUMPアクセス・ドライバには適用されません。

  • 複数のプライマリ入力データ・ファイル
    SQL*Loaderのロードを使用したプライマリ入力データ・ファイルが複数存在する場合は、入力データ・ファイルごとに不良ファイルおよび廃棄ファイルが作成されます。
  • 構文およびデータ型
    この項では、外部表ロードでサポートされていない構文およびデータ型について説明します。
  • バイト順序マーク
    SQL*Loaderでは、プライマリ・データ・ファイルにUnicode文字セット(UTF8またはUTF16)が使用され、バイト順序マーク(BOM)が含まれている場合、バイト順序マークは対応する不良ファイルおよび廃棄ファイルの先頭に書き込まれます。
  • デフォルトの文字セット、日付マスク、小数点区切り
    データ・ファイルのフィールドでは、クライアントのNLS環境変数によって、デフォルトの文字セット、日付マスクおよび小数点区切りが決定されます。
  • バックスラッシュ・エスケープ文字の使用
    この項では、バックスラッシュ・エスケープ文字の使用方法について説明します。

親トピック: 従来型パス・ロード、ダイレクト・パス・ロードおよび外部表ロード

7.9.5.1 複数のプライマリ入力データ・ファイル

SQL*Loaderのロードを使用したプライマリ入力データ・ファイルが複数存在する場合は、入力データ・ファイルごとに不良ファイルおよび廃棄ファイルが作成されます。

外部表ロードでは、すべての入力データ・ファイルに対する不良ファイルおよび廃棄ファイルは、1つずつのみです。外部表ロードでパラレル・アクセス・ドライバが使用される場合は、各アクセス・ドライバに不良ファイルおよび廃棄ファイルが含まれます。

7.9.5.2 構文およびデータ型

この項では、外部表ロードでサポートされていない構文およびデータ型について説明します。

  • CONTINUEIFまたはCONCATENATEを使用した、1つの論理レコードへの複数の物理レコードの結合

  • SQL*Loaderデータ型(GRAPHIC、GRAPHIC EXTERNALおよびVARGRAPHIC)のロード

  • データベースの列型(LONG、ネストした表、VARRAY、REF、主キーREFおよびSID)の使用

7.9.5.3 バイト順序マーク

SQL*Loaderでは、プライマリ・データ・ファイルにUnicode文字セット(UTF8またはUTF16)が使用され、バイト順序マーク(BOM)が含まれている場合、バイト順序マークは対応する不良ファイルおよび廃棄ファイルの先頭に書き込まれます。

外部表ロードでは、バイト順序マークは不良ファイルおよび廃棄ファイルの先頭に書き込まれません。

7.9.5.4 デフォルトの文字セット、日付マスク、小数点区切り

データ・ファイルのフィールドでは、クライアントのNLS環境変数によって、デフォルトの文字セット、日付マスクおよび小数点区切りが決定されます。

データ・ファイルのフィールドでは、クライアントのNLS環境変数によって、デフォルトの文字セット、日付マスクおよび小数点区切りが決定されます。外部表のフィールドでは、NLSパラメータのデータベース設定によって、デフォルトの文字セット、日付マスクおよび小数点区切りが決定されます。

7.9.5.5 バックスラッシュ・エスケープ文字の使用

この項では、バックスラッシュ・エスケープ文字の使用方法について説明します。

SQL*Loaderでは、次のようにバックスラッシュ(\)エスケープ文字を使用して、一重引用符を囲み文字として使用できます。

FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\''

外部表では、文字列内でバックスラッシュ・エスケープ文字を使用すると、エラーが発生します。解決策として、次のように二重引用符を使用して、一重引用符を囲み文字として使用できます。

TERMINATED BY ',' ENCLOSED BY "'"

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

オブジェクト、コレクションおよびLOBをバルク・ロードするためにSQL*Loaderを使用できます。

親トピック: SQL*Loaderの概念

7.10.1 サポートされるオブジェクト型

SQL*Loaderでは、列オブジェクト型および行オブジェクト型のロードがサポートされています。

  • 列オブジェクト
    表の列が、なんらかのオブジェクト型である場合、その列のオブジェクトは列オブジェクトと呼ばれます。
  • 行オブジェクト
    これらのオブジェクトはオブジェクト表と呼ばれる表に格納され、オブジェクト表にはオブジェクトの属性に対応する列があります。

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

7.10.1.1 列オブジェクト

表の列が、なんらかのオブジェクト型である場合、その列のオブジェクトは列オブジェクトと呼ばれます。

概念的には、そのようなオブジェクトは、行の単一の列位置に全体が格納されます。これらのオブジェクトにはオブジェクト識別子がなく、参照することはできません。

列オブジェクトのオブジェクト型がNOT FINALであると宣言されると、SQL*Loaderで導出された型(またはサブタイプ)を列オブジェクトにロードできます。

7.10.1.2 行オブジェクト

これらのオブジェクトはオブジェクト表と呼ばれる表に格納され、オブジェクト表にはオブジェクトの属性に対応する列があります。

さらに、そのオブジェクト表にはシステムが生成するSYS_NC_OID$という列があり、その列に、表の各オブジェクトに対してシステムが生成する一意の識別子(OID)が格納されます。他の表の列は、これらのオブジェクトをOIDを使用して参照できます。

オブジェクト表のオブジェクト型がNOT FINALであると宣言されると、SQL*Loaderで導出された型(またはサブタイプ)を行オブジェクトにロードできます。

7.10.2 サポートされるコレクション型

SQL*Loaderでは、ネストした表およびVARRAYコレクション型のロードがサポートされています。

  • ネストした表
    ネストした表は、別の表に列があるように見える表です。
  • VARRAY
    VARRAYは、可変サイズの配列です。

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

7.10.2.1 ネストした表

ネストした表は、別の表に列があるように見える表です。

別の表に対して実行できるすべての操作は、ネストした表に対しても実行できます。

7.10.2.2 VARRAY

VARRAYは、可変サイズの配列です。

配列は、要素と呼ばれる、一連の組込み型またはオブジェクトの順序付けられた集合です。各配列の要素は同一の型であり、VARRAY内の要素の位置に対応する一意の番号(index)を持ちます。

VARRAY型の作成時に、最大サイズを指定する必要があります。VARRAY型を宣言すると、リレーショナル表の列のデータ型、オブジェクト型属性、またはPL/SQL変数として使用することができます。

関連項目:

SQL*Loader制御ファイルのデータ定義言語を使用してこれらのコレクション型をロードする方法の詳細は、「コレクション(ネストした表およびVARRAY)のロード」を参照してください。

親トピック: サポートされるコレクション型

7.10.3 サポートされるLOBデータ型

LOBは、ラージ・オブジェクト型です。

今回のリリースのSQL*Loaderでは、4つのLOBデータ型のロードをサポートしています。

  • BLOB: 構造化されていないバイナリ・データを含むLOB。

  • CLOB: 文字データを含むLOB。

  • NCLOB: データベースの各国語文字セットの文字を含むLOB。

  • BFILE: サーバー側のオペレーティング・システム・ファイルのデータベース表領域外に格納されるBLOB。

LOBは、列のデータ型にすることができ、NCLOB以外はオブジェクトの属性のデータ型にすることもできます。LOBには、実際の値、NULLまたは「値なし(空)」を指定できます。

関連項目:

SQL*Loader制御ファイルのデータ定義言語を使用してこれらのLOB型をロードする方法の詳細は、「LOBのロード」を参照してください。

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

7.11 パーティション・オブジェクトのサポート

SQL*Loaderでは、データベース内のパーティション・オブジェクトのロードをサポートしています。

Oracle Databaseでは、グループ化されたパーティション(部分)で構成される表または索引が、パーティション・オブジェクトに相当します。一般に、パーティションは共通の論理属性によってグループ化されます。たとえば、特定の年度の売上データを、月別にパーティション化するとします。この場合、各月のデータは、売上表の中のそれぞれ別のパーティションに保存されます。このパーティションはそれぞれ、データベース内の異なるセグメントに保存されます。また、パーティションごとに異なる物理属性を指定できます。

次に、パーティション・オブジェクトがサポートされたことによって、SQL*Loaderでロードが可能になったものを示します。

  • パーティション表中の個別パーティション

  • パーティション表中の全パーティション

  • 非パーティション表

親トピック: SQL*Loaderの概念

7.12 アプリケーション開発: ダイレクト・パス・ロードAPI

アプリケーション開発のために、ダイレクト・パス・ロードAPIが提供されています。

詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

親トピック: SQL*Loaderの概念

7.13 SQL*Loaderの事例

SQL*Loaderの機能が様々な事例で示されています。

事例は、ユーザーscottが、デモンストレーション用のOracle Databaseのemp表およびdept表を所有している場合を想定して作成してあります。(事例の中では、さらに列が追加されていることもあります。)事例は、簡単なものから複雑なものの順に1から11までの番号が付けられています。

ノート:

事例に使用するファイルは、$ORACLE_HOME/rdbms/demoディレクトリにあります。これらのファイルは、Oracle Database 12c Examplesメディア(以前のCompanionメディア)をインストールするとインストールされます。これらのファイル名の詳細は、表7-1を参照してください。

次に、事例の概要を示します。

  • 事例1: 可変長データのロード: ストリーム形式のレコードをロードします。ここで扱うレコードのフィールドは、カンマで区切るか、または引用符で囲みます。データは制御ファイルの終わりに入っています。

  • 事例2: 固定形式フィールドのロード: 別のデータ・ファイルからデータをロードします。

  • 事例3: 自由区分形式ファイルのロード: フィールドがデリミタ付きで順序番号が付いている、ストリーム形式のレコードのデータをロードします。データは制御ファイルの終わりに入っています。

  • 事例4: 結合された物理レコードのロード: 複数の物理レコードを結合して、データベースの1行に対応する論理レコードを構成します。

  • 事例5: 複数表へのデータのロード: 1回の実行で、データを複数の表にロードします。

  • 事例6: ダイレクト・パス・ロード方式を使用したデータのロード: ダイレクト・パス・ロード方法を使用してデータをロードします。

  • 事例7: 書式化されたレポートからのデータの抽出: 書式化されたレポートからデータを抽出します。

  • 事例8: パーティション化された表のロード: パーティション表をロードします。

  • 事例9: LOBFILEのロード(CLOB): resumeというCLOB列をemp表に追加し、FILLERフィールド(res_file)を使用して、複数のLOBFILEをemp表にロードします。

  • 事例10: REFフィールドおよびVARRAYのロード: OIDを主キーとして利用するカスタマ表をロードして、注文した商品をVARRAYに格納します。カスタマ表およびVARRAYの注文商品を参照する注文表をロードします。

  • 事例11: Unicode文字セットのデータのロード: Unicode文字セットのUTF16データを、リトル・エンディアンのバイト順序でロードします。この事例は、文字長セマンティクスを使用します。

  • 事例用ファイル
    この項では、事例用ファイルについて説明します。
  • 事例の実行
    この項では、事例の実行について説明します。
  • 事例用ログ・ファイル
    事例用のログ・ファイルは、$ORACLE_HOME/rdbms/demoディレクトリにあらかじめ用意されているわけではありません。
  • 事例の結果確認
    事例の実行結果を確認するには、SQL*Plusを起動して、事例でロードされた表から選択操作を実行します。

親トピック: SQL*Loaderの概念

7.13.1 事例用ファイル

この項では、事例用ファイルについて説明します。

通常、各事例は次の種類のファイルで構成されています。

  • 制御ファイル(ulcase5.ctlなど)

  • データ・ファイル(ulcase5.datなど)

  • セットアップ・ファイル(ulcase5.sqlなど)

これらのファイルは、Oracle Database 12c Examplesメディア(以前のCompanionメディア)をインストールするとインストールされます。ファイルは、$ORACLE_HOME/rdbms/demoディレクトリにインストールされます。

事例用のサンプル・データが制御ファイルに含まれている場合、その事例の.datファイルはありません。

事例2では特別な設定が不要なため、事例2の.sqlスクリプトはありません。事例7では、開始(セットアップ)スクリプトと終了(クリーンアップ)スクリプトの両方を実行する必要があります。

表7-1に、各事例に関連のあるファイルを示します。

表7-1 事例用ファイルおよび関連ファイル

事例 .ctl .dat .sql

1

ulcase1.ctl

適用外

ulcase1.sql

2

ulcase2.ctl

ulcase2.dat

適用外

3

ulcase3.ctl

適用外

ulcase3.sql

4

ulcase4.ctl

ulcase4.dat

ulcase4.sql

5

ulcase5.ctl

ulcase5.dat

ulcase5.sql

6

ulcase6.ctl

ulcase6.dat

ulcase6.sql

7

ulcase7.ctl

ulcase7.dat

ulcase7s.sql

ulcase7e.sql

8

ulcase8.ctl

ulcase8.dat

ulcase8.sql

9

ulcase9.ctl

ulcase9.dat

ulcase9.sql

10

ulcase10.ctl

適用外

ulcase10.sql

11

ulcase11.ctl

ulcase11.dat

ulcase11.sql

親トピック: SQL*Loaderの事例

7.13.2 事例の実行

この項では、事例の実行について説明します。

通常、事例は次のステップで実行します(カレント・ディレクトリは、事例ファイルの格納場所である$ORACLE_HOME/rdbms/demoにしてください)。

  1. システム・プロンプトでsqlplusと入力し、[Enter]を押してSQL*Plusを起動します。ユーザー名のプロンプトで、scottと入力します。パスワードのプロンプトで、tigerと入力します。

    SQLプロンプトが表示されます。

  2. SQLプロンプトで、事例用のSQLスクリプトを実行します。たとえば、事例1のSQLスクリプトを実行するには、次のように入力します。
    SQL> @ulcase1

    事例用の表が準備および移入されると、システム・プロンプトに戻ります。

  3. システム・プロンプトで、次のように入力し、SQL*Loaderを起動して事例を実行します。
    sqlldr USERID=scott CONTROL=ulcase1.ctl LOG=ulcase1.log

    CONTROLパラメータとLOGパラメータを適切な制御ファイル名とログ・ファイル名に置き換え、[Enter]を押します。パスワードを入力するように要求されたら、tigerと入力して[Enter]を押します。

各事例を実行する前に、制御ファイルを確認する必要があります。制御ファイルの先頭には、事例で実施される内容に関する情報と把握する必要があるその他の特別な情報が含まれています。たとえば、事例6では、SQL*LoaderのコマンドラインにDIRECT=TRUEを追加する必要があります。

親トピック: SQL*Loaderの事例

7.13.3 事例用ログ・ファイル

事例用のログ・ファイルは、$ORACLE_HOME/rdbms/demoディレクトリにあらかじめ用意されているわけではありません。

これは、各事例のログ・ファイルは、事例を実行したときに生成されるためです(ただし、LOGパラメータを使用していることが条件です)。ログ・ファイルを生成しない場合は、コマンドラインでLOGパラメータを指定しないようにします。

親トピック: SQL*Loaderの事例

7.13.4 事例の結果確認

事例の実行結果を確認するには、SQL*Plusを起動して、事例でロードされた表から選択操作を実行します。

次のように行います。

  1. システム・プロンプトでsqlplusと入力し、[Enter]を押してSQL*Plusを起動します。ユーザー名のプロンプトで、scottと入力します。パスワードのプロンプトで、tigerと入力します。

    SQLプロンプトが表示されます。

  2. SQLプロンプトでSELECT文を使用して、事例がロードされた表からすべての行を選択します。たとえば、emp表がロードされた場合、次のように入力します。
    SQL> SELECT * FROM emp;

    emp表の各行の内容が表示されます。

親トピック: SQL*Loaderの事例