7 SQL*Loaderの使用方法の理解
SQL*Loaderを使用してOracle Databaseにデータをロードする前に知っておく必要がある基本概念について学習します。
- SQL*Loaderの機能
SQL*Loaderは、外部ファイルからOracle Databaseの表にデータをロードします。 - SQL*Loaderのパラメータ
SQL*Loaderは、sqlldr
コマンドを指定するか、ロード操作の様々な特性を確立するパラメータを指定すると起動します。 - SQL*Loader制御ファイル
制御ファイルは、SQL*Loaderが解釈できる言語で記述されたテキスト・ファイルです。 - SQL*Loaderによる入力データおよびデータ・ファイルの読取り方法
制御ファイルに指定された1つ以上のデータ・ファイル(またはファイルのオペレーティング・システムに相当するもの)などから、SQL*Loaderにデータが読み込まれます。 - LOBFILEおよびセカンダリ・データ・ファイル(SDF)
ラージ・オブジェクト(LOB)データは、非常に長いデータであるため、LOBFILEからロードすると有効です。 - データ変換およびデータ型の指定
従来型パス・ロード中に、データ・ファイルのデータ・フィールドが、データベースの列に変換されます(概念的にはダイレクト・パス・ロードと同様ですが、実装は異なります)。 - SQL*Loaderの廃棄レコードと拒否レコード
SQL*Loaderは、入力ファイルから読み取ったレコードの一部を拒否または廃棄することがあります。これは、ファイルに問題がある場合またはレコードのロードからの除外を選択した場合に発生します。 - ログ・ファイルおよびログ情報
SQL*Loaderで処理が開始されると、ログ・ファイルが作成されます。 - 従来型パス・ロード、ダイレクト・パス・ロードおよび外部表ロード
SQL*Loaderでデータをロードするには、いくつかの方法があります。 - SQL*Loaderによるオブジェクト、コレクションおよびLOBのロード
実社会のエンティティ(顧客と発注など)のモデル化に必要な列、行、LOBおよびJSONデータベース・オブジェクトを一括ロードできます。 - SQL*Loaderでのパーティション・オブジェクトのサポート
パーティション・データベース・オブジェクトを使用すると、データのセクションをまとめて管理することも個別に管理することもできます。SQL*Loaderでは、パーティション・オブジェクトのロードをサポートしています。 - アプリケーション開発: ダイレクト・パス・ロードAPI
ダイレクト・パス・ロードを使用すると、外部表からのデータを表とパーティションにロードできます。Oracleでは、アプリケーション開発者のためにダイレクト・パス・ロードAPIを提供しています。 - 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セッションのフローの例を示します。
親トピック: 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の使用方法の理解
7.4 SQL*Loaderによる入力データおよびデータ・ファイルの読取り方法
制御ファイルに指定された1つ以上のデータ・ファイル(またはファイルのオペレーティング・システムに相当するもの)などから、SQL*Loaderにデータが読み込まれます。
SQL*Loaderから見ると、データ・ファイルのデータはレコードとして構成されています。データ・ファイルには、固定レコード形式、可変レコード形式またはストリーム・レコード形式があります。レコード形式は、INFILE
パラメータを使用して制御ファイルに指定することができます。レコード形式が指定されない場合、デフォルトはストリーム・レコード形式になります。
ノート:
制御ファイル内部でデータが指定されている場合(INFILE *
が制御ファイルに指定されている場合)、そのデータはデフォルトでレコード終了記号を使用したストリーム・レコード形式として解釈されます。
- 固定レコード形式
固定レコード形式のファイルでは、データ・ファイルにあるすべてのレコードが同じバイト長です。 - 可変レコード形式およびSQL*Loader
可変レコード形式のファイルでは、文字フィールドの各レコード長がデータ・ファイルの各レコードの開始位置に含まれています。 - ストリーム・レコード形式およびSQL*Loader
ストリーム・レコード形式では、レコードのサイズ指定ではなく、SQL*Loaderでレコード終了記号を読み込むことによって、レコードが確認されます。 - 論理レコードおよびSQL*Loader
SQL*Loaderでは、入力データは、指定されたレコード形式で物理レコードに編成されます。デフォルトでは、1つの物理レコードが1つの論理レコードになります。 - データ・フィールド設定およびSQL*Loader
論理レコードを形成した後にSQL*Loaderで論理レコードのフィールド設定がどのように決定されるかについて説明します。
親トピック: SQL*Loaderの使用方法の理解
7.4.1 固定レコード形式
固定レコード形式のファイルでは、データ・ファイルにあるすべてのレコードが同じバイト長です。
固定レコード形式は最も柔軟性の低い形式ですが、これを使用すると、変数形式またはストリーム形式よりもパフォーマンスが向上します。また、固定形式は簡単に指定できます。たとえば:
INFILE datafile_name "fix n"
ここでは、特殊なデータ・ファイルが、SQL*Loaderによって全レコードがn
バイト長の固定レコード形式で解釈されるように指定しています。
次の例は、固定レコード形式で解釈されるデータ・ファイル(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
ストリーム・レコード形式では、レコードをサイズで指定してではなく、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
をレコード終了記号として使用するには、これを指定する必要があります。
次の例は、文字列'|\n'
を使用して終了記号文字列が指定されている場合に、ストリーム・レコード形式でデータをロードする方法を示しています。バックスラッシュを使用すると、文字列に印字不可能な改行文字を指定することができます。
関連項目:
-
Language and Character Set File Scanner (LCSSCAN)ユーティリティを使用して不明なファイル・テキストの言語および文字セットを確認する方法の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。
例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 論理レコードおよびSQL*Loader
SQL*Loaderでは、入力データは、指定されたレコード形式で物理レコードに編成されます。デフォルトでは、1つの物理レコードが1つの論理レコードになります。
柔軟性の向上により、SQL*Loaderでは複数の物理レコードを1つの論理レコードに結合することもできます。
論理レコードは、次のいずれかの方針に従って構成できます。
-
固定数の物理レコードを結合してそれぞれの論理レコードを構成する
-
特定の条件が真である場合に物理レコードを結合して論理レコードを構成する
7.4.5 データ・フィールド設定およびSQL*Loader
論理レコードを形成した後にSQL*Loaderで論理レコードのフィールド設定がどのように決定されるかについて学習します。
フィールド設定では、制御ファイルのフィールド指定を使用して、論理レコードのデータのどの部分が制御ファイルのフィールドに対応しているのかをSQL*Loaderで判断します。2つ以上のフィールド指定に同じデータを使用できます。また、論理レコードに、制御ファイルのフィールド指定で使用されないデータを含めることもできます。
ほとんどの場合、制御ファイルのフィールドに、論理レコードの特定の位置や長さの指定が必要です。この部分は、次のような形式で指定します。
-
データ・フィールドの開始バイト位置または終了位置(あるいはその両方)を指定できます。この指定形式に柔軟性はありませんが、フィールド設定によって高パフォーマンスが得られます。
-
特定のデータ・フィールドの区切り(囲みまたは終了、あるいはその両方)文字列を指定できます。デリミタ付きデータ・フィールドは、データ・フィールドの開始バイト位置が指定されている場合を除いて、直前のデータ・フィールドの終了位置から始まるとみなされます。
-
バイト・オフセットまたはデータ・フィールドの長さ(あるいはその両方)を指定できます。この方法では、各フィールドは、直前のフィールドが終了した位置から、指定されたバイト数の位置で始まり、指定された長さの位置で終了します。
-
長さと値のペアのデータ型を使用できます。この場合、データ・フィールドの最初の
n
バイト数に、データ・フィールドの残りの長さについての情報が含まれています。
関連トピック
7.5 LOBFILEおよびセカンダリ・データ・ファイル(SDF)
ラージ・オブジェクト(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つのステップがあります。
-
SQL*Loaderで、制御ファイルにあるフィールド指定を使用してデータ・ファイルの形式を解釈し、次に、入力データを解析します。そのデータを使用してSQL
INSERT
文に対応するバインド配列を移入します。バインド配列は、SQL*Loaderがロード対象のデータを格納するメモリー内の領域です。バインド配列が一杯の場合、データはデータベースに転送されます。バインド配列のサイズは、SQL*LoaderのBINDSIZE
およびREADSIZE
パラメータによって制御されます。 -
データベースがデータを受け取り、
INSERT
文を実行してデータベースにデータを格納します。
Oracle Databaseでは、列のデータ型を使用して最終的な格納形式にデータを変換します。データ・ファイル内のフィールドとデータベース内の列の違いに注意する必要があります。また、SQL*Loaderの制御ファイルで定義されているフィールドのデータ型は、列のデータ型と同じではないことにも注意してください。
親トピック: SQL*Loaderの使用方法の理解
7.7 SQL*Loaderの廃棄レコードと拒否レコード
SQL*Loaderは入力ファイルから読み込まれ一部のレコードを拒否または破棄できます。これは、ファイルの問題のため、またはロードからレコードをフィルタ処理することを選択したためです。
拒否レコードは不良ファイルに格納され、廃棄レコードは廃棄ファイルに格納されます。
- SQL*Loader不良ファイル
不良ファイルには、SQL*LoaderまたはOracle Databaseによって拒否レコードが書き込まれます。 - SQL*Loader廃棄ファイル
SQL*Loaderの実行時に、一部のレコードがロードから除外されるようにして、廃棄ファイルというファイルが作成されるようにすることもできます。
親トピック: SQL*Loaderの使用方法の理解
7.7.1 SQL*Loader不良ファイル
不良ファイルには、SQL*LoaderまたはOracle Databaseによって拒否レコードが書き込まれます。
不良ファイルを指定していない場合に拒否されたレコードがあると、SQL*Loaderによって不良ファイルが自動的に作成されます。拒否レコードはデータ・ファイルと同じ名前になりますが、拡張子.bad
が付きます。拒否には、いくつかの原因があります。
- SQL*Loaderによって拒否されたレコード
入力形式が不適切なデータ・ファイル・レコードは、SQL*Loaderによって拒否されます。 - SQL*Loaderの操作中にOracle Databaseによって拒否されたレコード
データ・ファイル・レコードは、SQL*Loaderによって受け取られた後、データベースに送られ、行として表に挿入されます。
親トピック: SQL*Loaderの廃棄レコードと拒否レコード
7.7.1.1 SQL*Loaderによって拒否されたレコード
入力形式が不適切なデータ・ファイル・レコードは、SQL*Loaderによって拒否されます。
たとえば、2番目の囲みデリミタがない場合や、デリミタ付きフィールドが最大長を超えている場合、レコードは、SQL*Loaderによって拒否されます。拒否レコードは、不良ファイルに書き込まれます。
親トピック: SQL*Loader不良ファイル
7.7.1.2 SQL*Loaderの操作中にOracle Databaseによって拒否されたレコード
データ・ファイル・レコードは、SQL*Loaderによって受け取られた後、データベースに送られ、行として表に挿入されます。
データベースによって有効であると判断された行は、表に挿入されます。行が無効であると判断された場合、レコードは拒否され、SQL*Loaderにより不良ファイルに書き込まれます。行が無効であると判断される例としては、キーが重複している場合、必須入力フィールドに対応するデータがNULL値の場合、またはフィールドにOracleデータ型ではないデータ型が指定された場合が考えられます。
親トピック: SQL*Loader不良ファイル
7.7.2 SQL*Loader廃棄ファイル
SQL*Loaderの実行時に、一部のレコードがロードから除外されるようにして、廃棄ファイルというファイルが作成されるようにすることもできます。
廃棄ファイルが作成されるのは、廃棄ファイルが必要な場合と、廃棄ファイルを有効にするように指定した場合のみです。廃棄ファイルには、制御ファイルに指定されているレコード選択基準に一致しなかったため、ロード対象から除外されたレコードが入ります。
廃棄ファイルにはロードから除外されたレコードが格納されているため、廃棄ファイルの内容はデータベースのどの表にも挿入されなかったレコードになります。廃棄ファイルに格納可能なレコードの最大数を指定できます。レコードのデータがいずれかの表に書き込まれる場合、このレコードは廃棄ファイルには書き込まれません。
親トピック: SQL*Loaderの廃棄レコードと拒否レコード
7.8 ログ・ファイルおよびログ情報
SQL*Loaderで処理が開始されると、ログ・ファイルが作成されます。
SQL*Loaderでは、ログ・ファイルを作成できないと処理は終了します。このログ・ファイルにはロード中に発生したエラーに関する記述など、ロードに関する詳細情報が記録されます。
親トピック: SQL*Loaderの使用方法の理解
7.9 従来型パス・ロード、ダイレクト・パス・ロードおよび外部表ロード
SQL*Loaderでデータをロードするには、いくつかの方法があります。
- 従来型パス・ロード
従来型パス・ロードでは、入力レコードがフィールド指定を基に解析され、各データ・フィールドが対応するバインド配列(SQL*Loaderがロードするデータを格納するメモリー内の領域)にコピーされます。 - ダイレクト・パス・ロード
ダイレクト・パス・ロードでは、入力レコードがフィールド指定を基に解析され、入力フィールド・データが列のデータ型に変換されて列配列が作成されます。 - パラレル・ダイレクト・パス
パラレル・ダイレクト・パス・ロードでは、複数のダイレクト・パス・ロード・セッションで同じデータ・セグメントを同時にロードできます(セグメント内の並列化が可能です)。 - 外部表ロード
外部表はデータベース内に存在しない表として定義されている表で、アクセス・ドライバが用意されている任意の形式が可能です。 - 外部表およびSQL*Loaderの選択
データのロード時にロード・パフォーマンスが最も高い方法を学習します。 - SQL*Loaderと外部表との処理内容の違い
外部表を使用したデータのロード(ORACLE_LOADER
アクセス・ドライバを使用)と、SQL*Loaderの従来型パス・ロードおよびダイレクト・パス・ロードを使用したデータのロードとの違いを確認することをお薦めします。 - オブジェクト・ストレージに格納されているデータを使用した表のロード
SQL*Loaderを使用して、オブジェクト・ストレージから標準のOracle Database表にデータをロードする方法について学習します。
親トピック: 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.3 パラレル・ダイレクト・パス
パラレル・ダイレクト・パス・ロードでは、複数のダイレクト・パス・ロード・セッションで 同じデータ・セグメントを同時にロードできます(セグメント内の並列化が可能です)。
パラレル・ダイレクト・パスには、ダイレクト・パスより多くの制約事項があります。
7.9.4 外部表ロード
外部表はデータベース内に存在しない表として定義されている表で、アクセス・ドライバが用意されている任意の形式が可能です。
Oracle Databaseでは、ORACLE_LOADER
,およびORACLE_DATAPUMP
の2つのアクセス・ドライバが提供されています。外部表を記述するメタデータを提供することで、外部表内のデータをあたかも標準的なデータベース表内に存在しているデータのように公開できます。
外部表ロードでは、外部データ・ファイルに含まれているデータの外部表が作成されます。ロード処理では、INSERT
文が実行され、データ・ファイルからデータがターゲット表に挿入されます。
従来型パス・ロードおよびダイレクト・パス・ロードではなく、外部表ロードを使用した場合のメリットは、次のとおりです。
-
データ・ファイルが大きい場合、外部表のロードではパラレルでファイルのロードを試みます。
-
外部表ロードでは、外部表の作成に使用される
INSERT
文の一部としてSQL関数およびPL/SQLファンクションを使用することによってロードされるデータを変更できます。
ノート:
Windowsオペレーティング・システムでの名前付きパイプを使用した外部表ロードは、サポートされません。
7.9.5 外部表およびSQL*Loaderの選択
データのロード時にロード・パフォーマンスが最も高い方法を学習します。
外部表とSQL*Loaderのレコード解析は類似しているため、通常、同じレコード形式での大幅なパフォーマンスの違いはありません。ただし、外部表とSQL*Loaderのアーキテクチャは異なるため、一方の方法が他方より適している場合があります。
次の状況では、最適なロード・パフォーマンスを得るために外部表を使用します。
- データベースへのロード時にデータを変換する場合
- 透過的にパラレル処理を行う前に、外部データを分割する必要がない場合
次の状況では、最適なロード・パフォーマンスを得るためにSQL*Loaderを使用します。
- リモートでデータをロードする場合
- データに対して変換を行う必要がなく、そのデータをパラレルでロードする必要がない場合
- データをロードする必要があり、ステージング表に索引を追加する必要がある場合
7.9.6 SQL*Loaderと外部表との処理内容の違い
外部表を使用したデータのロード(ORACLE_LOADER
アクセス・ドライバを使用)と、SQL*Loaderの従来型パス・ロードおよびダイレクト・パス・ロードを使用したデータのロードとの違いを確認することをお薦めします。
この項で示す情報は、ORACLE_DATAPUMP
アクセス・ドライバには当てはまりません。
- 複数のプライマリ入力データ・ファイル
SQL*Loaderのロードを使用したプライマリ入力データ・ファイルが複数存在する場合は、入力データ・ファイルごとに不良ファイルおよび廃棄ファイルが作成されます。 - 構文およびデータ型
この項では、外部表ロードでサポートされていない構文およびデータ型について説明します。 - バイト順序マーク
SQL*Loaderでは、バイト順序マークが書き込まれるかどうかは、文字セットまたは表ロードによって決まります。 - デフォルトの文字セット、日付マスク、小数点区切り
NLS文字セットの表示は、SQL*Loaderと外部表の各種設定で制御します。 - バックスラッシュ・エスケープ文字の使用
SQL*Loaderと外部表では、一重引用符を囲み文字として識別するために様々な表記規則が使用されます。
7.9.6.1 複数のプライマリ入力データ・ファイル
SQL*Loaderのロードを使用したプライマリ入力データ・ファイルが複数存在する場合は、入力データ・ファイルごとに不良ファイルおよび廃棄ファイルが作成されます。
外部表ロードでは、すべての入力データ・ファイルに対する不良ファイルおよび廃棄ファイルは、1つずつのみです。外部表ロードでパラレル・アクセス・ドライバが使用される場合は、各アクセス・ドライバに不良ファイルおよび廃棄ファイルが含まれます。
親トピック: SQL*Loaderと外部表との処理内容の違い
7.9.6.2 構文およびデータ型
この項では、外部表ロードでサポートされていない構文およびデータ型について説明します。
-
CONTINUEIF
またはCONCATENATE
を使用した、1つの論理レコードへの複数の物理レコードの結合 -
SQL*Loaderデータ型(
GRAPHIC
、GRAPHIC EXTERNAL
およびVARGRAPHIC
)のロード -
データベースの列型(
LONG
、ネストした表、VARRAY
、REF
、主キーREF
およびSID
)の使用
親トピック: SQL*Loaderと外部表との処理内容の違い
7.9.6.3 バイト順序マーク
SQL*Loaderでは、バイト順序マークが書き込まれるかどうかは、文字セットまたは表ロードによって決まります。
プライマリ・データ・ファイルにUnicode文字セット(UTF8
またはUTF16
)が使用され、バイト順序マーク(BOM)が含まれている場合、バイト順序マークは対応する不良ファイルおよび廃棄ファイルの先頭に書き込まれます。
外部表ロードでは、バイト順序マークは不良ファイルおよび廃棄ファイルの先頭に書き込まれません。
親トピック: SQL*Loaderと外部表との処理内容の違い
7.9.6.4 デフォルトの文字セット、日付マスク、小数点区切り
NLS文字セットの表示は、SQL*Loaderと外部表の各種設定で制御します。
SQL*Loaderでは、デフォルトの文字セット、日付マスクおよび小数点区切りが、クライアント側でのNLS環境変数の設定によって決まります。
外部表のフィールドでは、NLSパラメータのデータベース設定によって、デフォルトの文字セット、日付マスクおよび小数点区切りが決定されます。
親トピック: SQL*Loaderと外部表との処理内容の違い
7.9.6.5 バックスラッシュ・エスケープ文字の使用
SQL*Loaderと外部表では、一重引用符を囲み文字として識別するために様々な表記規則が使用されます。
SQL*Loaderでは、一重引用符が囲み文字として識別されるようにするために、バックスラッシュ(\
)エスケープ文字を使用できます。たとえば
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\''
外部表では、文字列内でバックスラッシュ・エスケープ文字を使用すると、エラーが発生します。解決策として、二重引用符を使用することで、一重引用符を囲み文字として使用できます。たとえば:
TERMINATED BY ',' ENCLOSED BY "'"
親トピック: SQL*Loaderと外部表との処理内容の違い
7.9.7 オブジェクト・ストレージに格納されたデータを使用した表のロード
SQL*Loaderを使用して、オブジェクト・ストレージから標準のOracle Database表にデータをロードする方法について学習します。
次の例では、データをロードする表(T
)があります。
SQL> create table t (x int, y int);
この表にロードするfile1.txt
という名前のデータ・ファイルがあります。内容は次のとおりです。
X,Y
1,2
4,5
この表をオブジェクト・ストアにロードするには、次の手順を実行します。
-
オブジェクト・ストアの入出力(I/O)を有効にするために必要なライブラリをインストールします。
% cd $ORACLE_HOME/rdbms/lib % make -f ins_rdbms.mk opc_on
-
ファイル
file1.txt
をオブジェクト・ストレージのバケットにアップロードします。オブジェクト・ストレージにファイルをアップロードする最も簡単な方法は、Oracle Cloudコンソールからファイルをアップロードすることです。
- Oracle Cloudコンソールを開きます。
- オブジェクト・ストレージのタイルを選択します。
- まだ作成していない場合は、バケットを作成します。
- アップロードをクリックし、ファイル
file1.txt
を選択してバケットにアップロードします。
-
Oracle Databaseで、ウォレットおよび資格証明を作成します。
たとえば:
$ orapki wallet create -wallet /home/oracle/wallets -pwd mypassword-auto_login $ mkstore -wrl /home/oracle/wallets -createEntry oracle.sqlldr.credential.myfedcredential.username oracleidentitycloudservice/myuseracct@example.com $ mkstore -wrl /home/oracle/wallets -createEntry oracle.sqlldr.credential.myfedcredential.password "MhAVCDfW+-ReskK4:Ho-zH"
この例では、フェデレーテッド・ユーザー・アカウント(
myfedcredential
)の使用方法を示します。Oracle Cloud Infrastructureドキュメントで説明されているように、パスワードは自動的に生成されます。(「資格証明の管理」の認証トークンの作成に関する項を参照)。 - ウォレットを作成した後、
$ORACLE_HOME/network/admin
ディレクトリのsqlnet.ora
ファイルに場所を追加します。たとえば:
vi test.ctl LOAD DATA INFILE 'https://objectstorage.eu-frankfurt-1.oraclecloud.com/n/dbcloudoci/b/myobjectstore/o/file1.txt' truncate INTO TABLE T FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' (X,Y)
-
SQL*Loaderを実行して、データをオブジェクト・ストアにロードします。
たとえば:
sqlldr test/mypassword@pdb1 /home/oracle/test.ctl credential=myfedcredentiallog=test.log external_table=not_used
7.10 SQL*Loaderによるオブジェクト、コレクションおよびLOBのロード
実社会のエンティティ(顧客と発注など)のモデル化に必要な列、行、LOBおよびJSONデータベース・オブジェクトを一括ロードできます。
- サポートされるオブジェクト型
SQL*Loaderでは、列オブジェクト型および行オブジェクト型のロードがサポートされています。 - サポートされるコレクション型
SQL*Loaderでは、ネストした表およびVARRAY
コレクション型のロードがサポートされています。 - サポートされるLOBデータ型
LOBは、ラージ・オブジェクト型です。
親トピック: SQL*Loaderの使用方法の理解
7.10.1 サポートされるオブジェクト型
SQL*Loaderでは、列オブジェクト型および行オブジェクト型のロードがサポートされています。
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
コレクション型のロードがサポートされています。
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のロード」を参照してください。
7.11 SQL*Loaderでのパーティション・オブジェクトのサポート
パーティション・データベース・オブジェクトを使用すると、データのセクションをまとめて管理することも個別に管理することもできます。SQL*Loaderでは、パーティション・オブジェクトのロードをサポートしています。
Oracle Databaseインスタンスでは、グループ化されたパーティション(部分)で構成される表または索引がパーティション・オブジェクトに相当します。一般に、パーティションは共通の論理属性によってグループ化されます。たとえば、特定の年度の売上データを、月別にパーティション化するとします。この場合、各月のデータは、売上表の中のそれぞれ別のパーティションに保存されます。このパーティションはそれぞれ、データベース内の異なるセグメントに保存されます。また、パーティションごとに異なる物理属性を指定できます。
次に、パーティション・オブジェクトがサポートされたことによって、SQL*Loaderでロードが可能になったものを示します。
-
パーティション表中の個別パーティション
-
パーティション表中の全パーティション
-
非パーティション表
親トピック: SQL*Loaderの使用方法の理解
7.12 アプリケーション開発: ダイレクト・パス・ロードAPI
ダイレクト・パス・ロードを使用すると、外部表からのデータを表とパーティションにロードできます。Oracleでは、アプリケーション開発者のためにダイレクト・パス・ロードAPIを提供しています。
親トピック: SQL*Loaderの使用方法の理解
7.13 SQL*Loaderの事例
SQL*Loaderの機能の使用方法を学習できるように、Oracleでは実行可能な様々な事例を提供しています。
- 事例用ファイル
SQL*Loaderの各事例ファイルには、その事例の使用に必要なファイルのセットが含まれています。 - 事例の実行
SQL*Loaderの事例を実行するための一般的なステップは、その他の事例を実行する場合とほとんど同じです。 - 事例用ログ・ファイル
事例用のログ・ファイルは、$ORACLE_HOME/rdbms/demo
ディレクトリにあらかじめ用意されているわけではありません。 - 事例の結果確認
事例の実行結果を確認するには、SQL*Plusを起動して、事例でロードされた表から選択操作を実行します。
親トピック: SQL*Loaderの使用方法の理解
7.13.1 事例用ファイル
SQL*Loaderの各事例用ファイルには、その事例の使用に必要なファイルのセットが含まれています。
使用上のノート
通常、各事例は次の種類のファイルで構成されています。
-
制御ファイル(
ulcase5.ctl
など) -
データ・ファイル(
ulcase5.dat
など) -
セットアップ・ファイル(
ulcase5.sql
など)
これらのファイルは、Oracle Database Examples (以前のCompanion)メディアをインストールするとインストールされます。ファイルは$ORACLE_HOME/rdbms/demo
ディレクトリにインストールされます。
事例用の例データが制御ファイルに含まれている場合、その事例の.dat
ファイルはありません。
事例2では特別な設定が不要なため、事例2の.sql
スクリプトはありません。事例7では、開始(セットアップ)スクリプトと終了(クリーンアップ)スクリプトの両方を実行する必要があります。
次の表に、各事例に関連のあるファイルを示します。
表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 事例の実行
SQL*Loaderの事例を実行するための一般的なステップは、その他の事例を実行する場合とほとんど同じです。
$ORACLE_HOME/rdbms/demo
ディレクトリに移動していることを確認してください。事例用ファイルは、このディレクトリに格納されています。
また、各事例を実行する前に、制御ファイルを確認する必要もあります。制御ファイルの先頭には、事例で実施される内容に関する情報と把握する必要があるその他の特別な情報が含まれています。たとえば、事例6では、SQL*LoaderのコマンドラインにDIRECT=TRUE
を追加する必要があります。
親トピック: SQL*Loaderの事例
7.13.3 事例用ログ・ファイル
事例用のログ・ファイルは、$ORACLE_HOME/rdbms/demo
ディレクトリにあらかじめ用意されているわけではありません。
これは、各事例のログ・ファイルは、事例を実行したときに生成されるためです(ただし、LOG
パラメータを使用していることが条件です)。ログ・ファイルを生成しない場合は、コマンドラインでLOG
パラメータを指定しないようにします。
親トピック: SQL*Loaderの事例