この章では、SQL*LoaderによるOracle Databaseへのデータのロードについて、基本的な概念を説明します。この章の内容は、次のとおりです。
SQL*Loaderを使用して、外部ファイルのデータをOracle Databaseの表にロードします。強力なデータ解析エンジンによって、あらゆるデータ形式のデータ・ファイルに対応できます。SQL*Loaderを使用して、次のことが可能です。
データ・ファイルがデータベースと異なるシステム上にある場合のネットワークを介したデータのロード。(「ネットワークを介したデータのロード」を参照)
同一のロード・セッションでの複数のデータ・ファイルからのデータのロード。
同一のロード・セッションでの複数の表へのデータのロード。
データのキャラクタ・セットの指定。
ロード・データの選択(レコード値に基づいたロード)。
ロード前の、SQL関数を使用したデータ処理。
指定した列に対する、一意の順序キーの生成。
オペレーティング・システムのファイル・システムを使用したデータ・ファイルへのアクセス。
ディスク、テープまたはNamed Pipeからのデータのロード。
高度なエラー・レポートの生成による、トラブルシューティングの支援。
複合オブジェクト・リレーショナル・データの任意のロード。
セカンダリ・データ・ファイルを使用した、LOBおよびコレクションのロード。
従来型パス・ロードまたはダイレクト・パス・ロードの使用。従来型パス・ロードでは高い柔軟性を、ダイレクト・パス・ロードでは優れたロード・パフォーマンスを提供します。「第12章」を参照してください。
一般的なSQL*Loaderセッションでは、SQL*Loaderの動作を制御する制御ファイルと1つ以上のデータ・ファイルが入力用に使用されます。SQL*Loaderの出力先は、データがロードされるOracle Database、ログ・ファイル、不良ファイルで、廃棄ファイルに出力される場合もあります。図7-1に、SQL*Loaderセッションの流れの例を示します。
SQL*Loaderは、sqlldr
コマンドを指定すると起動します。また、オプションで、セッション特性を確立するパラメータを指定した場合も起動します。
常に、値がほとんど変わらない同じパラメータを使用する場合は、コマンドラインではなく、次の方法でパラメータを指定すると効率的です。
パラメータは、パラメータ・ファイルとしてグループ化できます。その後、PARFILE
パラメータを使用して、そのパラメータ・ファイルの名前をコマンドラインで指定できます。
一部のパラメータは、OPTIONS
句を使用して、SQL*Loaderの制御ファイル内に指定することもできます。
コマンドラインで指定したパラメータは、パラメータ・ファイルまたはOPTIONS
句で指定したパラメータ値を上書きします。
制御ファイルは、SQL*Loaderが解釈できる言語で記述されたテキスト・ファイルです。制御ファイルは、データの場所、データの分析と解釈方法、データの挿入先などをSQL*Loaderに通知します。
制御ファイルには、大きく分けて3つのセクションがあります。
第1セクションには、セッション全体の情報が記述されます。たとえば、次のような情報です。
バインドサイズ、行、スキップ・レコードなどのようなグローバル・オプション
入力データの配置先を指定するINFILE
句
ロードされるデータ
第2セクションは、1つ以上のINTO TABLE
ブロックで構成されています。それぞれのブロックには、表名、その表の列などの、データがロードされる表についての情報が含まれています。
第3セクションはオプションで、このセクションがある場合は、入力データが記述されます。
制御ファイルの構文には、次の注意事項があります。
構文は、自由形式で記述できます(文は複数行になってもかまいません)。
大文字と小文字は、一重引用符または二重引用符で囲まれた文字列の場合のみ区別され、それ以外では区別されません。
先頭にハイフンを2つ(--)続けて入力することによって、コメントを挿入できます。ハイフンから行の終わりまでがコメントになります。オプションである第3セクションでは、二重ハイフンがコメントとしてではなくデータとして解釈されるため、このセクションでのコメントはサポートされません。
CONSTANT
およびZONE
キーワードは、SQL*Loaderでは特別な意味があり、予約されています。競合を回避するために、表または列の名前にCONSTANT
またはZONE
という語を使用しないことをお薦めします。
制御ファイルに指定された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バイトとなります。(改行文字は固定レコード形式では必要ありません。ここでは単に、使用された場合はレコード長のバイトとしてカウントされることを説明するために使用されています。)
文字長セマンティクスが使用されているファイルでも、長さは常にバイト単位で解析されます。これは、文字長セマンティクスで処理されるフィールドとバイト長セマンティクスで処理されるフィールドがファイル内に混在する可能性があるため必要です。詳細は、「文字長セマンティクス」を参照してください。
可変レコード形式のファイルでは、文字フィールドの各レコード長がデータ・ファイルの各レコードの開始位置に含まれています。この形式は、固定レコード形式より柔軟性があり、ストリーム・レコード形式よりパフォーマンスに優れています。可変レコード形式の場合、たとえば、次のように指定できます。
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バイトの改行を含む)バイト長で指定されています。改行文字は、可変レコード形式では必要ありません。この例でも、データ・ファイルはシングルバイト・キャラクタ・セットであるとします。
文字長セマンティクスが使用されているファイルでも、長さは常にバイト単位で解析されます。これは、文字長セマンティクスで処理されるフィールドとバイト長セマンティクスで処理されるフィールドがファイル内に混在する可能性があるため必要です。詳細は、「文字長セマンティクス」を参照してください。
ストリーム・レコード形式では、レコードをサイズで指定してではなく、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'
で指定されている場合に、ストリーム・レコード形式でデータをロードする方法を示します。バックスラッシュを使用すると、文字列に印字不可能な改行文字を指定することができます。
入力データは、指定されたレコード形式で物理レコードに編成されます。デフォルトでは、1つの物理レコードが1つの論理レコードになりますが、複数の物理レコードが1つの論理レコードに結合される場合もあります。
論理レコードは、次のいずれかの方針に従って構成できます。
固定数の物理レコードを結合してそれぞれの論理レコードを構成する
特定の条件が真である場合に物理レコードを結合して論理レコードを構成する
論理レコードが作成されると、フィールドが設定されます。フィールド設定では、制御ファイルのフィールド指定を使用して、論理レコードのデータのどの部分が制御ファイルのフィールドに対応しているのかをSQL*Loaderで判断します。2つ以上のフィールド指定に同じデータを使用できます。また、論理レコードに、制御ファイルのフィールド指定で使用されないデータを含めることもできます。
ほとんどの場合、制御ファイルのフィールドに、論理レコードの特定の位置や長さの指定が必要です。この部分は、次のような形式で指定します。
データ・フィールドの開始バイト位置または終了位置(あるいはその両方)を指定できます。この指定形式に柔軟性はありませんが、フィールド設定によって高パフォーマンスが得られます。
特殊なデータ・フィールドの区切り(囲みまたは終了(あるいはその両方))文字列を指定できます。デリミタ付きデータ・フィールドは、データ・フィールドの開始バイト位置が指定されている場合を除いて、直前のデータ・フィールドの終了位置から始まるとみなされます。
バイト・オフセットまたはデータ・フィールドの長さ(あるいはその両方)を指定できます。この方法では、各フィールドは、直前のフィールドが終了した位置から、指定されたバイト数の位置で始まり、指定された長さの位置で終了します。
Length-Valueデータ型が使用できます。この場合、データ・フィールドの最初のn
バイト数に、データ・フィールドの残りの長さについての情報が含まれています。
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つの手順があります。
SQL*Loaderで、制御ファイルにあるフィールド指定を使用してデータ・ファイルの形式を解釈し、次に、入力データを解析します。そのデータを使用してSQL INSERT
文に対応するバインド配列を移入します。
Oracle Databaseがデータを受け取り、INSERT
文を実行してデータベースにデータを格納します。
Oracle Databaseでは、列のデータ型を使用して最終的な格納形式にデータを変換します。データ・ファイル内のフィールドとデータベース内の列の違いに注意する必要があります。また、SQL*Loader制御ファイルで定義されているフィールドのデータ型が、データベースの列のデータ型と同じではないことにも注意してください。
入力ファイルから読み込まれたすべてのレコードが、データベースに挿入されるわけではありません。挿入されないレコードは、不良ファイルまたは廃棄ファイルに書き込まれます.。
不良ファイルには、SQL*LoaderまたはOracle Databaseによって拒否レコードが書き込まれます。不良ファイルを指定していない場合に拒否されたレコードがあると、SQL*Loaderによって不良ファイルが自動的に作成されます。ファイルの名前はデータ・ファイルと同じで、拡張子は.badになります。次に、その理由を示します。
入力形式が不適切なデータ・ファイル・レコードは、SQL*Loaderによって拒否されます。たとえば、2番目の囲みデリミタがない場合や、デリミタ付きフィールドが最大長を超えている場合、レコードは、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_LOADER
とORACLE_DATAPUMP
という2つのアクセス・ドライバが用意されています。外部表を説明するメタデータをデータベースに提供することにより、外部表のデータが通常のデータベース表に存在するかのように、データベースにデータを公開できます。
外部表ロードでは、データ・ファイルに含まれているデータの外部表が作成されます。ロード処理では、INSERT
文が実行され、データ・ファイルのデータがターゲット表に挿入されます。
従来型パス・ロードおよびダイレクト・パス・ロードではなく、外部表ロードを使用した場合のメリットは、次のとおりです。
データ・ファイルが大きい場合、外部表のロードではパラレルでファイルのロードを試みます。
外部表ロードでは、外部表の作成に使用されるINSERT
文の一部としてSQL関数およびPL/SQLファンクションを使用することによってロードされるデータを変更できます。
参照:
|
外部表とSQL*Loaderのレコード解析は類似しているため、通常、同じレコード形式での大幅なパフォーマンスの違いはありません。ただし、外部表とSQL*Loaderのアーキテクチャは異なるため、一方の方法が他方より適している場合があります。
次の状況では、最適なロード・パフォーマンスを得るために外部表を使用します。
データベースへのロード時にデータを変換する場合
透過的にパラレル処理を行う前に、外部データを分割する必要がない場合
次の状況では、最適なロード・パフォーマンスを得るためにSQL*Loaderを使用します。
リモートでデータをロードする場合
データに対して変換を行う必要がなく、そのデータをパラレルでロードする必要がない場合
データをロードする必要があり、ステージング表に索引を追加する必要がある場合
この項では、外部表を使用したデータのロード方法(ORACLE_LOADER
アクセス・ドライバを使用)と、SQL*Loaderの従来型パス・ロードおよびダイレクト・パス・ロードを使用したデータのロード方法の重要な違いについて説明します。ここで示す情報は、ORACLE_DATAPUMP
アクセス・ドライバには適用されません。
SQL*Loaderのロードを使用したプライマリ入力データ・ファイルが複数存在する場合は、入力データ・ファイルごとに不良ファイルおよび廃棄ファイルが作成されます。外部表ロードでは、すべての入力データ・ファイルに対する不良ファイルおよび廃棄ファイルは、1つずつのみです。外部表ロードでパラレル・アクセス・ドライバが使用される場合は、各アクセス・ドライバに不良ファイルおよび廃棄ファイルが含まれます。
次の操作は、外部表ロードではサポートされていません。
CONTINUEIF
またはCONCATENATE
を使用した、1つの論理レコードへの複数の物理レコードの結合
SQL*Loaderデータ型(GRAPHIC
、GRAPHIC EXTERNAL
およびVARGRAPHIC
)のロード
データベースの列型(LONG
、ネストした表、VARRAY
、REF
、主キー、REF
およびSID
)の使用
SQL*Loaderでは、プライマリ・データ・ファイルにUnicodeキャラクタ・セット(UTF8またはUTF16)が使用され、バイト順序マーク(BOM)が含まれている場合、バイト順序マークは対応する不良ファイルおよび廃棄ファイルの先頭に書き込まれます。外部表ロードでは、バイト順序マークは不良ファイルおよび廃棄ファイルの先頭に書き込まれません。
データ・ファイルのフィールドでは、クライアントのNLS環境変数によって、デフォルトのキャラクタ・セット、日付マスクおよび小数点区切りが決定されます。外部表のフィールドでは、NLSパラメータのデータベース設定によって、デフォルトのキャラクタ・セット、日付マスクおよび小数点区切りが決定されます。
SQL*Loaderでは、次のようにバックスラッシュ(\)エスケープ文字を使用して、一重引用符を一重引用符として使用できます。
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\''
外部表では、文字列内でバックスラッシュ・エスケープ文字を使用すると、エラーが発生します。解決策としては、次のように分離文字列に二重引用符を使用します。
TERMINATED BY ',' ENCLOSED BY "'"
オブジェクト、コレクションおよびLOBをバルク・ロードするためにSQL*Loaderを使用できます。読者は『Oracle Database概要』と『Oracle Database管理者ガイド』に記載されているオブジェクトの概念と、Oracleによるオブジェクト・サポートの実装について、よく理解しているものとします。
SQL*Loaderでは、次の2つのオブジェクト型のロードがサポートされています。
表の列が、なんらかのオブジェクト型である場合、その列のオブジェクトは列オブジェクトと呼ばれます。概念的には、そのようなオブジェクトは、行の単一の列位置に全体が格納されます。これらのオブジェクトにはオブジェクト識別子がなく、参照することはできません。
列オブジェクトのオブジェクト型がNOT FINALであると宣言されると、SQL*Loaderで導出された型(またはサブタイプ)を列オブジェクトにロードできます。
SQL*Loaderでは、次の2つのコレクション型のロードがサポートされています。
SQL*Loaderでは、データベース内のパーティション・オブジェクトのロードをサポートしています。Oracle Databaseでは、グループ化されたパーティション(部分)で構成される表または索引が、パーティション・オブジェクトに相当します。一般に、パーティションは共通の論理属性によってグループ化されます。たとえば、2000年度の売上データを、月別にパーティション化するとします。この場合、各月のデータは、売上表の中のそれぞれ別のパーティションに保存されます。このパーティションはそれぞれ、データベース内の異なるセグメントに保存されます。また、パーティションごとに異なる物理属性を指定できます。
次に、パーティション・オブジェクトがサポートされたことによって、SQL*Loaderでロードが可能になったものを示します。
パーティション表中の個別パーティション
パーティション表中の全パーティション
非パーティション表
アプリケーション開発のために、ダイレクト・パス・ロードAPIが提供されています。詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。
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
にしてください)。
システム・プロンプトでsqlplus
と入力し、[Enter]を押してSQL*Plusを起動します。ユーザー名のプロンプトで、scott
と入力します。パスワードのプロンプトで、tiger
と入力します。
SQLプロンプトが表示されます。
SQLプロンプトで、事例用のSQLスクリプトを実行します。たとえば、事例1のSQLスクリプトを実行するには、次のように入力します。
SQL> @ulcase1
事例用の表が準備および移入されると、システム・プロンプトに戻ります。
システム・プロンプトで、次のように入力し、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を起動して、事例でロードされた表から選択操作を実行します。次のように行います。
システム・プロンプトでsqlplus
と入力し、[Enter]を押してSQL*Plusを起動します。ユーザー名のプロンプトで、scott
と入力します。パスワードのプロンプトで、tiger
と入力します。
SQLプロンプトが表示されます。
SQLプロンプトでSELECT
文を使用して、事例がロードされた表からすべての行を選択します。たとえば、emp
表がロードされた場合、次のように入力します。
SQL> SELECT * FROM emp;
emp
表の各行の内容が表示されます。