7.4 SQL*Loaderの入力データおよびデータ・フィールド

SQL*Loaderがデータをロードし、レコード・フィールドを識別する方法を学習します。

7.4.1 SQL*Loaderによる入力データおよびデータ・ファイルの読取り方法

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

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

ノート:

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

7.4.2 固定レコード形式

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

固定レコード形式は最も柔軟性の低い形式ですが、これを使用すると、変数形式またはストリーム形式よりもパフォーマンスが向上します。また、固定形式は簡単に指定できます。次に例を示します:

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.3 可変レコード形式および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.4 ストリームレコード形式および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'を使用して終了記号文字列が指定されている場合に、ストリーム・レコード形式でデータをロードする方法を示しています。バックスラッシュを使用すると、文字列に印字不可能な改行文字を指定することができます。

関連項目:

例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.5 論理レコードおよびSQL*Loader

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

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

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

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

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

7.4.6 データ・フィールド設定およびSQL*Loader

論理レコードを形成した後にSQL*Loaderで論理レコードのフィールド設定がどのように決定されるかについて学習します。

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

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

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

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

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

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

Oracle AI Database 26ai以降、SQL*Loaderを使用して、スキーマレス・ドキュメント(JSONやXMLベースのアプリケーション・データなどの固定データ構造を持たないドキュメント)をSODAコレクションとしてOracle AI Databaseにロードできます。