1.7 バージョン対応表へのバルク・ロード

SQL*Loaderを使用するとバージョン対応表へのバルク・ロードを実行できますが、Workspace Managerの特殊プロシージャもコールする必要があり、ある程度の制限が適用されます。

最新バージョンの作業領域またはルート・バージョン(バージョン番号0のLIVE作業領域)に対して、データのダイレクト・パスによるバルク・ロードと従来型パスによるバルク・ロードの両方を実行できます。ルート・バージョンは他のすべてのバージョンの祖先であるため、ルート・バージョンのデータは他のすべての作業領域から参照可能です(LIVE以外の作業領域に更新済のデータがない場合)。

バージョン対応表に対してバルク・ロードを実行する一般ステップは、次のとおりです。

1. BeginBulkLoadingプロシージャをコールして、表をバルク・ロード用に準備します。バージョン対応表へのデータのバルク・ロード中は、表に対するDML操作も作業領域操作も実行できませんが、この表に関係しない作業領域操作は実行できます。BeginBulkLoadingプロシージャにより、この表に対する無効な操作の実行が回避されます。
2. SQL*Loaderを使用してバルク・ロードを実行します。<table_name>_LT名を指定するために制御ファイルで変更する必要がある行は1行のみです。たとえば、既存の制御ファイルに次の行があると仮定します。

   Load data into table departments (name, loc)
   

   制御ファイルで、バージョン対応表へのバルク・ロードに関するこの行を次のように変更する必要があります。

   Load data into table departments_LT (name, loc)

   ノート:

   12.1より前のバージョンのWorkspace Managerでは、wm_version列を含める必要がありました。この列には、Workspace Managerにより自動的にデータが移入されるようになりました。このため、この行に明示的に移入すると、エラーが生成されます。これにより、バルク・ロードされるすべての行が適切なバージョンで確実にタグ付けされ、各行ではWorkspace Manager固有の他の列が確実にNULL値となります。

   表が履歴オプション指定のあるバージョン対応だった場合は、作成時刻と削除または変更の時刻を<table_name>_LTのwm_createtime列とwm_retiretime列にバルク・ロードできます。

3. バルク・ロード処理を完了するには、CommitBulkLoadingプロシージャをコールしてバルク・ロードによる変更をコミットするか、RollbackBulkLoadingプロシージャをコールしてバルク・ロードによる変更をロールバックします。

バルク・ロードによる変更をコミットすると、Workspace Managerでは必要な作業領域内およびバージョン内でデータが更新されていることが確認されます。デフォルトでは、バルク・ロードされたデータは、表に対して定義済の一意制約または参照制約に対してそれぞれチェックされ、バルク・ロードされた行のうち、いずれかの制約に違反する行はCommitBulkLoadingプロシージャのパラメータに指定した廃棄表に移動します。重複(つまり、バルク・ロードされたデータのうち主キー列に同じ値を持つレコード)の有無をチェックするように指定した場合は、重複レコードのうち最小のROWID値を持つレコードのみが表にロードされ、他のレコードは廃棄表に移動します。

現行のリリースの場合、バージョン対応表を使用したバルク・ロードには次の制限が適用されます。

• 自己参照型の整合性制約を持つ表にはバルク・ロードできません。

• LIVEを除き、連続的にリフレッシュされる子作業領域を持つ作業領域にはバルク・ロードできません。

• 表の所有者またはWM_ADMINシステム権限が付与されているユーザーのみが、バージョン対応表へのバルク・ロードを実行できます。

• バージョン対応表をバルク・ロードするユーザーには、<table_name>_LTに対するINSERT権限が必要です。

• バルク・ロード中は、バージョン対応表に対するユーザー定義トリガーは実行されません。

• バルク・ロードされた行には、セッションのロック・モードは規定されません。この種の行をロックするにはLockRowsプロシージャを使用します。