プライマリ・コンテンツに移動
Oracle® Databaseユーティリティ
11gリリース2 (11.2)
B56303-08
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

7 SQL*Loaderの概念

この章では、SQL*LoaderによるOracle Databaseへのデータのロードについて、基本的な概念を説明します。この章の内容は、次のとおりです。

SQL*Loaderの機能

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

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

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

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

  • データのキャラクタ・セットの指定。

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

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

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

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

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

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

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

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

  • 従来型パス・ロードまたはダイレクト・パス・ロードの使用。従来型パス・ロードでは高い柔軟性を、ダイレクト・パス・ロードでは優れたロード・パフォーマンスを提供します。「第12章」を参照してください。

一般的なSQL*Loaderセッションでは、SQL*Loaderの動作を制御する制御ファイルと1つ以上のデータ・ファイルが入力用に使用されます。SQL*Loaderの出力先は、データがロードされるOracle Database、ログ・ファイル、不良ファイルで、廃棄ファイルに出力される場合もあります。図7-1に、SQL*Loaderセッションの流れの例を示します。

図7-1 SQL*Loaderの概要

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

SQL*Loaderのパラメータ

SQL*Loaderは、sqlldrコマンドを指定すると起動します。また、オプションで、セッション特性を確立するパラメータを指定した場合も起動します。

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

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

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

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


参照:


SQL*Loader制御ファイル

制御ファイルは、SQL*Loaderが解釈できる言語で記述されたテキスト・ファイルです。制御ファイルは、データの場所、データの分析と解釈方法、データの挿入先などをSQL*Loaderに通知します。

制御ファイルには、大きく分けて3つのセクションがあります。

第1セクションには、セッション全体の情報が記述されます。たとえば、次のような情報です。

  • バインドサイズ、行、スキップ・レコードなどのようなグローバル・オプション

  • 入力データの配置先を指定するINFILE

  • ロードされるデータ

第2セクションは、1つ以上のINTO TABLEブロックで構成されています。それぞれのブロックには、表名、その表の列などの、データがロードされる表についての情報が含まれています。

第3セクションはオプションで、このセクションがある場合は、入力データが記述されます。

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

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

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

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

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


    参照:

    制御ファイルの構文およびセマンティクスの詳細は、第9章を参照してください。

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

制御ファイルに指定された1つ以上のファイル(またはファイルのオペレーティング・システムに相当するもの)などから、SQL*Loaderにデータが読み込まれます。SQL*Loaderから見ると、データ・ファイルのデータはレコードとして構成されています。データ・ファイルには、固定レコード形式、可変レコード形式またはストリーム・レコード形式があります。レコード形式は、INFILEパラメータを使用して制御ファイルに指定することができます。レコード形式が指定されない場合、デフォルトはストリーム・レコード形式になります。


注意:

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

固定レコード形式

固定レコード形式のファイルでは、データ・ファイルにあるすべてのレコードが同じバイト長です。この形式は柔軟性はありませんが、その結果、可変長またはストリーム形式よりも高いパフォーマンスを得ることができます。また、固定形式は簡単に指定できます。次に例を示します。

INFILE datafile_name "fix n"

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

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

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

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

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

example.dat:

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

可変レコード形式

可変レコード形式のファイルでは、文字フィールドの各レコード長がデータ・ファイルの各レコードの開始位置に含まれています。この形式は、固定レコード形式より柔軟性があり、ストリーム・レコード形式よりパフォーマンスに優れています。可変レコード形式の場合、たとえば、次のように指定できます。

INFILE "datafile_name" "var n"

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

例7-2に、ファイル名がexample.datでレコード長フィールドが3バイト長の可変レコード形式の入力データに対する制御ファイルのSQL*Loaderへの指定を示します。example.datデータ・ファイルは、3つの物理レコードで構成されています。1つ目のレコードは009(すなわち9)バイト長、2つ目のレコードは010(すなわち1バイトの改行を含めて10)バイト長、3つ目は012(同様に1バイトの改行を含む)バイト長で指定されています。改行文字は、可変レコード形式では必要ありません。この例でも、データ・ファイルはシングルバイト・キャラクタ・セットであるとします。

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

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

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

example.dat:
009hello,cd,010world,im,
012my,name is,

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

ストリーム・レコード形式では、レコードをサイズで指定してではなく、SQL*Loaderでレコード終了記号を読み込むことによって、レコードが確認されます。ストリーム・レコード形式は最も柔軟性のある形式ですが、パフォーマンスに影響する場合があります。ストリーム・レコード形式として解釈されるようにデータ・ファイルを指定するには、次のように指定します。

INFILE datafile_name ["str terminator_string"]

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 NTでは、terminator_stringを指定しない場合、SQL*Loaderは\nまたは\r\nのうちデータ・ファイル内で先に現れる文字をレコード終了記号として使用します。つまり、データ・ファイルの1つ以上のレコードで、フィールドに\nが埋め込まれていることがわかっている場合に、\r\nをレコード終了記号として使用するには、これを指定する必要があります。

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

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

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

example.dat:
hello,world,|
james,bond,|

論理レコード

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

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

データ・フィールド

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. SQL*Loaderで、制御ファイルにあるフィールド指定を使用してデータ・ファイルの形式を解釈し、次に、入力データを解析します。そのデータを使用してSQL INSERT文に対応するバインド配列を移入します。

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

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

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

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

不良ファイル

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

SQL*Loaderによる拒否

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

Oracle Databaseによる拒否

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


参照:


廃棄ファイル

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

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


参照:


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

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

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

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

従来型パス・ロード

従来型パス・ロードでは、入力レコードがフィールド指定を基に解析され、各データ・フィールドが対応するバインド配列にコピーされます。バインド配列が一杯になるか、または最終レコードが読み込まれた時点で配列の挿入が実行されます。

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

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

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

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

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

外部表ロード

外部表はデータベース内に存在しない表として定義されている表で、アクセス・ドライバが用意されている任意の形式が可能です。Oracle Databaseには、ORACLE_LOADERORACLE_DATAPUMPという2つのアクセス・ドライバが用意されています。外部表を説明するメタデータをデータベースに提供することにより、外部表のデータが通常のデータベース表に存在するかのように、データベースにデータを公開できます。

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

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

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

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


注意:

Windows NTでは、名前付きパイプを使用する外部表ロードはサポートされていません。


参照:


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

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

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

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

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

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

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

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

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

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

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

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

SQL*Loaderのロードを使用したプライマリ入力データ・ファイルが複数存在する場合は、入力データ・ファイルごとに不良ファイルおよび廃棄ファイルが作成されます。外部表ロードでは、すべての入力データ・ファイルに対する不良ファイルおよび廃棄ファイルは、1つずつのみです。外部表ロードでパラレル・アクセス・ドライバが使用される場合は、各アクセス・ドライバに不良ファイルおよび廃棄ファイルが含まれます。

構文およびデータ型

次の操作は、外部表ロードではサポートされていません。

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

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

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

バイト順マーク

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

デフォルトのキャラクタ・セット、日付マスク、小数点区切り

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

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

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

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

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

TERMINATED BY ',' ENCLOSED BY "'"

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

オブジェクト、コレクションおよびLOBをバルク・ロードするためにSQL*Loaderを使用できます。読者は『Oracle Database概要』『Oracle Database管理者ガイド』に記載されているオブジェクトの概念と、Oracleによるオブジェクト・サポートの実装について、よく理解しているものとします。

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

SQL*Loaderでは、次の2つのオブジェクト型のロードがサポートされています。

列オブジェクト

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

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

行オブジェクト

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

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

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

SQL*Loaderでは、次の2つのコレクション型のロードがサポートされています。

ネストした表

ネストした表は、別の表に列があるように見える表です。別の表に対して実行できるすべての操作は、ネストした表に対しても実行できます。

VARRAY

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

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


参照:

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

サポートされるLOB型

LOBは、ラージ・オブジェクト型です。今回のリリースのSQL*Loaderでは、4つのLOB型のロードをサポートしています。

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

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

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

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

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


参照:

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

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

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

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

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

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

  • 非パーティション表

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

アプリケーション開発のために、ダイレクト・パス・ロードAPIが提供されています。詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

SQL*Loaderの事例

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


注意:

事例に使用するファイルは、$ORACLE_HOME/rdbms/demoディレクトリにあります。これらのファイルは、Oracle Database 11g 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データを、リトル・エンディアンのバイト順序でロードします。この事例は、文字長セマンティクスを使用します。

事例用ファイル

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

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

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

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

これらのファイルは、Oracle Database 11g 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


事例の実行

通常、事例は次の手順で実行します(カレント・ディレクトリは、事例ファイルの格納場所である$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を追加する必要があります。

事例用ログ・ファイル

事例用のログ・ファイルは、$ORACLE_HOME/rdbms/demoディレクトリにあらかじめ用意されているわけではありません。これは、各事例のログ・ファイルは、事例を実行したときに生成されるためです(ただし、LOGパラメータを使用していることが条件です)。ログ・ファイルを生成しない場合は、コマンドラインでLOGパラメータを指定しないようにします。

事例の結果確認

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

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

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

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

    SQL> SELECT * FROM emp;
    

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