Oracle® Database

ユーティリティ

12c リリース1 (12.1.0.2)

B71303-09(原本部品番号:E41528-10)

2018年4月

Oracle Databaseユーティリティ 12c リリース1 (12.1.0.2)

B71303-09

Copyright © 1996, 2018, Oracle and/or its affiliates.  All rights reserved.

原本著者: Rhonda Day

原本協力者:   Lee Barton、George Claborn、Steve DiPirro、Dean Gagne、John Kalogeropoulos、Joydip Kundu、Rod Payne、Ray Pfau、Rich Phillips、Mike Sakayeda、Marilyn Saunders、Jim Stenoish、Roy Swonger、Randy Urbano、William Wright、Hui-ling Yu

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 構文図

- 表記規則

Oracle Databaseユーティリティの今回のリリースでの変更点

- Oracle Database 12cリリース1 (12.1.0.2)での変更点

- Oracle Database 12cリリース1 (12.1.0.1)での変更点

- 新機能

- 非推奨となった機能

- サポート対象外機能

第I部 Oracle Data Pump

1 Oracle Data Pumpの概要

- データ・ポンプのコンポーネント

- データ・ポンプによるデータの移動方法

- データ・ファイル・コピーを使用したデータ移動

- ダイレクト・パスを使用したデータ移動

- 外部表を使用したデータ移動

- 従来型パスを使用したデータ移動

- ネットワーク・リンク・インポートを使用したデータ移動

- CDBでのデータ・ポンプの使用

- データ・ポンプを使用したCDBへのデータベースの移動

- データ・ポンプの使用によるCDB内または間のPDBの移動

- データ・ポンプ・エクスポートおよびデータ・ポンプ・インポートの操作に必要なロール

- データ・ポンプ・ジョブ実行中に行われる処理

- ジョブの調整

- ジョブ内での進捗状況の追跡

- ジョブ実行中のデータおよびメタデータのフィルタ処理

- ジョブ実行中のメタデータの変換

- ジョブ・パフォーマンスの最大化

- データのロードおよびアンロード

- ジョブの状態の監視

- ジョブの実行状況の監視

- ファイルの割当て

- ファイルの指定およびダンプ・ファイルの追加

- ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置

- Oracle RACに関する考慮点

- Oracle Automatic Storage Managementを使用可能にした場合のディレクトリ・オブジェクトの使用方法

- DATA_PUMP_DIRディレクトリ・オブジェクトおよびプラガブル・データベース

- 置換変数の使用方法

- 異なるデータベース・リリース間のエクスポートとインポート

- SecureFiles LOBに関する考慮点

- データ・ポンプの終了コード

- データ・ポンプ・ジョブの監査

- データ・ポンプによるタイムスタンプ・データの処理方法

- TIMESTAMP WITH TIME ZONEの制限事項

- ソースおよびターゲットのタイムゾーン・ファイルのバージョン

- データ・ポンプによるTIMESTAMP WITH TIME ZONEデータのサポート

- TIMESTAMP WITH LOCAL TIME ZONEの制限事項

- キャラクタ・セットおよびグローバリゼーション・サポートに関する考慮点

- ユーザー・データ

- 変換によるキャラクタ・セットのソート順への影響

- DDL

- シングルバイト・キャラクタ・セットとエクスポートおよびインポート

- マルチバイト・キャラクタ・セットとエクスポートおよびインポート

2 データ・ポンプ・エクスポート

- データ・ポンプ・エクスポート・ユーティリティとは

- データ・ポンプ・エクスポートの起動

- データ・ポンプ・エクスポートのインタフェース

- データ・ポンプ・エクスポートのモード

- 全体モード

- スキーマ・モード

- 表モード

- 表領域モード

- トランスポータブル表領域モード

- ネットワークに関する考慮点

- エクスポート操作中のフィルタ処理

- データ・フィルタ

- メタデータ・フィルタ

- エクスポート・ユーティリティのコマンドライン・モードで使用可能なパラメータ

- ABORT_STEP

- ACCESS_METHOD

- ATTACH

- CLUSTER

- COMPRESSION

- COMPRESSION_ALGORITHM

- CONTENT

- DATA_OPTIONS

- DIRECTORY

- DUMPFILE

- ENCRYPTION

- ENCRYPTION_ALGORITHM

- ENCRYPTION_MODE

- ENCRYPTION_PASSWORD

- ENCRYPTION_PWD_PROMPT

- ESTIMATE

- ESTIMATE_ONLY

- EXCLUDE

- FILESIZE

- FLASHBACK_SCN

- FLASHBACK_TIME

- FULL

- HELP

- INCLUDE

- JOB_NAME

- KEEP_MASTER

- LOGFILE

- LOGTIME

- METRICS

- NETWORK_LINK

- NOLOGFILE

- PARALLEL

- PARFILE

- QUERY

- REMAP_DATA

- REUSE_DUMPFILES

- SAMPLE

- SCHEMAS

- SERVICE_NAME

- SOURCE_EDITION

- STATUS

- TABLES

- TABLESPACES

- TRANSPORT_FULL_CHECK

- TRANSPORT_TABLESPACES

- TRANSPORTABLE

- VERSION

- VIEWS_AS_TABLES

- エクスポート・ユーティリティの対話方式コマンド・モードで使用可能なコマンド

- ADD_FILE

- CONTINUE_CLIENT

- EXIT_CLIENT

- FILESIZE

- HELP

- KILL_JOB

- PARALLEL

- START_JOB

- STATUS

- STOP_JOB

- データ・ポンプ・エクスポートの使用例

- 表モード・エクスポートの実行

- 選択した表および行のデータのみのアンロード

- 表モード・エクスポートに必要なディスク領域の見積り

- スキーマ・モード・エクスポートの実行

- パラレル全データベース・エクスポートの実行

- 対話方式モードを使用したジョブの停止および再接続

- データ・ポンプ・エクスポートの構文図

3 データ・ポンプ・インポート

- データ・ポンプ・インポート・ユーティリティとは

- データ・ポンプ・インポートの起動

- データ・ポンプ・インポートのインタフェース

- データ・ポンプ・インポートのモード

- 全体インポート・モード

- スキーマ・モード

- 表モード

- 表領域モード

- トランスポータブル表領域モード

- ネットワークに関する考慮点

- インポート操作中のフィルタ処理

- データ・フィルタ

- メタデータ・フィルタ

- インポート・ユーティリティのコマンドライン・モードで使用可能なパラメータ

- ABORT_STEP

- ACCESS_METHOD

- ATTACH

- CLUSTER

- CONTENT

- DATA_OPTIONS

- DIRECTORY

- DUMPFILE

- ENCRYPTION_PASSWORD

- ENCRYPTION_PWD_PROMPT

- ESTIMATE

- EXCLUDE

- FLASHBACK_SCN

- FLASHBACK_TIME

- FULL

- HELP

- INCLUDE

- JOB_NAME

- KEEP_MASTER

- LOGFILE

- LOGTIME

- MASTER_ONLY

- METRICS

- NETWORK_LINK

- NOLOGFILE

- PARALLEL

- PARFILE

- PARTITION_OPTIONS

- QUERY

- REMAP_DATA

- REMAP_DATAFILE

- REMAP_SCHEMA

- REMAP_TABLE

- REMAP_TABLESPACE

- REUSE_DATAFILES

- SCHEMAS

- SERVICE_NAME

- SKIP_UNUSABLE_INDEXES

- SOURCE_EDITION

- SQLFILE

- STATUS

- STREAMS_CONFIGURATION

- TABLE_EXISTS_ACTION

- TABLES

- TABLESPACES

- TARGET_EDITION

- TRANSFORM

- TRANSPORT_DATAFILES

- TRANSPORT_FULL_CHECK

- TRANSPORT_TABLESPACES

- TRANSPORTABLE

- VERSION

- VIEWS_AS_TABLES (ネットワーク・インポート)

- VIEWS_AS_TABLES (非ネットワーク・インポート)

- インポート・ユーティリティの対話方式コマンド・モードで使用可能なコマンド

- CONTINUE_CLIENT

- EXIT_CLIENT

- HELP

- KILL_JOB

- PARALLEL

- START_JOB

- STATUS

- STOP_JOB

- データ・ポンプ・インポートの使用例

- データのみ表モード・インポートの実行

- スキーマ・モード・インポートの実行

- ネットワーク・モード・インポートの実行

- データ・ポンプ・インポートの構文図

4 データ・ポンプのレガシー・モード

- パラメータのマッピング

- データ・ポンプでのオリジナルのエクスポート・パラメータの使用

- データ・ポンプでのオリジナルのインポート・パラメータの使用

- データ・ポンプ・レガシー・モードでのファイルの場所の管理

- データ・ポンプのログ・ファイルとエラーに対する既存のスクリプトの調整

- ログ・ファイル

- エラー

- 終了状態

5 データ・ポンプ・ユーティリティのパフォーマンス

- データ・ポンプ・エクスポート・ユーティリティおよびデータ・ポンプ・インポート・ユーティリティのデータ・パフォーマンスの改善点

- パフォーマンスのチューニング

- リソース消費の制御

- 圧縮および暗号化によるパフォーマンスへの影響

- 統計のエクスポートおよびインポートにおけるメモリーの考慮事項

- データ・ポンプ・ユーティリティのパフォーマンスに影響する初期化パラメータ

- Streams環境でのバッファ・キャッシュ・サイズの設定

6 データ・ポンプAPI

- データ・ポンプAPIのクライアント・インタフェースの動作

- ジョブの状態

- データ・ポンプAPIを使用する場合の基本手順

- データ・ポンプAPIの使用例

第II部 SQL*Loader

7 SQL*Loaderの概念

- SQL*Loaderの機能

- SQL*Loaderのパラメータ

- SQL*Loader制御ファイル

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

- 固定レコード形式

- 可変レコード形式

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

- 論理レコード

- データ・フィールド

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

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

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

- 不良ファイル

- SQL*Loaderによって拒否されたレコード

- SQL*Loaderの操作中にOracle Databaseによって拒否されたレコード

- 廃棄ファイル

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

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

- 従来型パス・ロード

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

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

- 外部表ロード

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

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

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

- 構文およびデータ型

- バイト順マーク

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

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

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

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

- 列オブジェクト

- 行オブジェクト

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

- ネストした表

- VARRAY

- サポートされるLOBデータ型

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

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

- SQL*Loaderの事例

- 事例用ファイル

- 事例の実行

- 事例用ログ・ファイル

- 事例の結果確認

8 SQL*Loaderコマンドライン・リファレンス

- SQL*Loaderの起動

- コマンドラインでのパラメータの指定

- SQL*Loaderのパラメータ指定の代替方法

- ネットワークを介してデータをロードするためのSQL*Loaderの使用

- SQL*Loaderのコマンドライン・パラメータ

- BAD

- BINDSIZE

- COLUMNARRAYROWS

- CONTROL

- DATA

- DATA_CACHE

- DEGREE_OF_PARALLELISM

- DIRECT

- DISCARD

- DISCARDMAX

- DNFS_ENABLE

- DNFS_READBUFFERS

- ERRORS

- EXTERNAL_TABLE

- FILE

- LOAD

- LOG

- MULTITHREADING

- NO_INDEX_ERRORS

- PARALLEL

- PARFILE

- PARTITION_MEMORY

- READSIZE

- RESUMABLE

- RESUMABLE_NAME

- RESUMABLE_TIMEOUT

- ROWS

- SILENT

- SKIP

- SKIP_INDEX_MAINTENANCE

- SKIP_UNUSABLE_INDEXES

- STREAMSIZE

- TRIM

- USERID

- 終了コードによる結果の検査と表示

9 SQL*Loader制御ファイル・リファレンス

- 制御ファイルの内容

- 制御ファイルのコメント

- 制御ファイル中でのコマンドライン・パラメータの指定

- OPTIONS句

- ファイル名およびオブジェクト名の指定

- SQLおよびSQL*Loaderの予約語と競合するファイル名

- SQL文字列の指定

- オペレーティング・システムに関する考慮点

- 完全パスの指定

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

- 移植不能文字列

- エスケープ文字としてのバックスラッシュの使用

- エスケープ文字が使用できない場合

- XMLType表の識別

- フィールド順序の指定

- データ・ファイルの指定

- INFILE構文の例

- 複数のデータ・ファイルの指定

- CSV形式のファイルの指定

- BEGINDATAによる制御ファイルのデータの識別

- データ・ファイル形式およびバッファリングの指定

- 不良ファイルの指定

- 不良ファイル名指定の例

- LOBFILEおよびSDFを使用した不良ファイルの処理方法

- 拒否レコードの条件

- 廃棄ファイルの指定

- 制御ファイルでの廃棄ファイルの指定

- 廃棄レコード数の上限付け

- 廃棄ファイル名指定の例

- 廃棄レコードの条件

- LOBFILEおよびSDFを使用した廃棄ファイルの処理方法

- コマンドラインからの廃棄ファイルの指定

- 表レベルでのNULLIF句の指定

- 表レベルでの日時書式の指定

- 異なる文字コード体系の処理

- マルチバイト(アジア系言語)・キャラクタ・セット

- Unicodeキャラクタ・セット

- データベース・キャラクタ・セット

- データ・ファイル・キャラクタ・セット

- 入力文字の変換

- VARRAYまたは主キー・ベースREFへのデータ・ロード時の考慮事項

- CHARACTERSETパラメータ

- 制御ファイル・キャラクタ・セット

- 文字長セマンティクス

- シフト・センシティブ文字データ

- 中断されたロード

- 中断された従来型パス・ロード

- 中断されたダイレクト・パス・ロード

- 領域エラーによって中断されたロード

- エラーが最大数を超えたことによって中断されたロード

- 致命的エラーによって中断されたロード

- [Ctrl]キーを押しながら[C]キーを押すことによって中断されたロード

- ロードの中断後の表および索引の状態

- ログ・ファイルを使用したロード状態の確認

- 単一表へのロードの継続

- 物理レコードからの論理レコードの作成

- CONCATENATEを使用した論理レコードの作成

- CONTINUEIFを使用した論理レコードの作成

- 表への論理レコードのロード

- 表名の指定

- INTO TABLE句

- 表固有のロード方法

- 空の表へのデータのロード

- INSERT

- 空でない表へのデータのロード

- APPEND

- REPLACE

- 既存の行の更新

- TRUNCATE

- 表固有のOPTIONSパラメータ

- 条件に基づいたレコードのロード

- LOBFILEおよびSDFでのWHEN句の使用

- デフォルトのデータ・デリミタ(区切り記号)の指定

- fields_spec

- termination_spec

- enclosure_spec

- データが欠落しているショート・レコードの処理

- TRAILING NULLCOLS句

- 索引オプション

- SORTED INDEXES句

- SINGLEROWオプション

- 複数のINTO TABLE句を使用するメリット

- 複数の論理レコードの抽出

- デリミタに基づく相対的な位置指定

- 異なる入力レコード形式の区別

- POSITIONパラメータに基づく相対的な位置指定

- 異なる入力行オブジェクトのサブタイプの区別

- 複数表へのデータのロード

- 複数のINTO TABLE句使用のサマリー

- バインド配列および従来型パス・ロード

- バインド配列のサイズ要件

- バインド配列のパフォーマンスに関する考慮点

- 行数およびバインド配列サイズの指定

- バインド配列サイズを確認するための計算

- 長さインジケータのサイズの決定

- フィールド・バッファ・サイズの計算

- バインド配列用のメモリー所要量の最小化

- 複数のINTO TABLE句に対するバインド配列サイズの計算

10 SQL*Loaderフィールド・リスト・リファレンス

- フィールド・リストの内容

- データ・フィールドの位置指定

- タブを含むデータでのPOSITIONの使用

- 複数表のロードでのPOSITIONの使用

- POSITIONを使用した例

- 列およびフィールドの指定

- FILLERフィールドの指定

- データ・フィールドのデータ型の指定

- SQL*Loaderのデータ型

- 移植不能なデータ型

- INTEGER(n)

- SMALLINT

- FLOAT

- DOUBLE

- BYTEINT

- ZONED

- DECIMAL

- VARGRAPHIC

- VARCHAR

- VARRAW

- LONG VARRAW

- 移植可能なデータ型

- CHAR

- 日時データ型と期間データ型

- DATE

- TIME

- TIMEWITHTIMEZONE

- TIMESTAMP

- TIMEWITHTIMEZONE

- TIMESTAMPWITHLOCALTIMEZONE

- INTERVALYEARTOMONTH

- INTERVALDAYTOSECOND

- GRAPHIC

- GRAPHIC EXTERNAL

- 数値型EXTERNAL

- RAW

- VARCHARC

- VARRAWC

- システム固有のデータ型フィールド長の競合

- LENGTH-VALUEデータ型のフィールド長

- データ型変換

- 日時データ型および期間データ型のデータ型変換

- デリミタの指定

- 終了および囲みの指定に関する構文

- データ中のデリミタ記号

- デリミタ付きデータの最大長

- デリミタを使用した後続の空白のロード

- デリミタ付きデータの処理方法

- TERMINATED BYのみを使用するフィールド

- TERMINATED BYなしでENCLOSED BYを使用するフィールド

- TERMINATED BYとともにENCLOSED BYを使用するフィールド

- TERMINATED BYとともにOPTIONALLY ENCLOSED BYを使用するフィールド

- 文字データ型フィールド長の競合

- 事前にサイズが決まっているフィールド

- デリミタ付きフィールド

- 日付フィールド・マスク

- フィールド条件の指定

- フィールドとBLANKSの比較

- フィールドと文字列の比較

- WHEN、NULLIFおよびDEFAULTIF句の使用

- WHEN、NULLIFおよびDEFAULTIF句の使用

- 異なるプラットフォーム間でのデータのロード

- バイト順序

- バイト順序の指定

- バイト順序マーク(BOM)の使用

- BOMの確認の抑止

- すべてが空白のフィールドのロード

- 空白の切捨て

- 空白の切捨てが可能なデータ型

- 空白の切捨てが可能なデータ型に対するフィールド長指定

- 事前にサイズが決まっているフィールド

- デリミタ付きフィールド

- フィールドの相対的な位置指定

- フィールドの開始位置が指定されていない場合

- 前のフィールドの終端がデリミタで指定されている場合

- 前のフィールドに囲みデリミタおよび終了デリミタの両方が含まれる場合

- 先頭の空白

- 前のフィールドが空白で区切られている場合

- オプションの囲みデリミタ

- 後続の空白の切捨て

- 囲まれたフィールドの切捨て

- 空白の切捨てに対するPRESERVE BLANKSオプションの影響

- [NO] PRESERVE BLANKSとデリミタ句の併用

- フィールドへのSQL演算子の適用

- フィールドの参照

- フィールド指定でのSQL演算子の共通使用

- SQL演算子の組合せ

- 日付マスク付きのSQL文字列の使用

- 書式化されたフィールドの解析

- SQL文字列を使用したANYDATAデータベース型へのロード

- SQL*Loaderを使用した入力データの生成

- ファイルを使用しないデータのロード

- 列への定数値の設定

- CONSTANTパラメータ

- 列への式の値の設定

- EXPRESSIONパラメータ

- データファイル・レコード番号への1列の設定

- RECNUMパラメータ

- 列への現在の日付の設定

- SYSDATEパラメータ

- 列への一意の順序番号の設定

- SEQUENCEパラメータ

- 複数の表に対する順序番号の生成

- 例: 挿入ごとの順序番号の生成

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

- 列オブジェクトのロード

- ストリーム・レコード形式への列オブジェクトのロード

- 可変レコード形式への列オブジェクトのロード

- ネストした列オブジェクトのロード

- 導出サブタイプを使用した列オブジェクトのロード

- オブジェクトに対するNULL値の指定

- NULL属性の指定

- アトミックNULLの指定

- ユーザー定義コンストラクタを使用した列オブジェクトのロード

- オブジェクト表のロード

- サブタイプを使用したオブジェクト表のロード

- REF列のロード

- REF句における表名の指定

- システム生成OID型のREF列

- 主キーREF列

- 主キーが使用可能な有効範囲なしREF列

- LOBのロード

- 「プライマリ・データ・ファイルからのLOBデータのロード」

- 事前に決められたサイズのフィールドのLOBデータ

- デリミタ付きフィールドのLOBデータ

- Length-Value PairフィールドのLOBデータ

- LOBFILEからのLOBデータのロード

- 動的および静的LOBFILE指定

- LOBFILEからのLOBデータのロードの例

- ファイル当たり1つのLOB

- 事前に決められたサイズのLOB

- デリミタ付きフィールドのLOB

- Length-Value Pairで指定したLOB

- LOBFILEからLOBをロードする場合の考慮点

- BFILE列のロード

- コレクション(ネストした表およびVARRAY)のロード

- ネストした表およびVARRAYでの制限事項

- セカンダリ・データ・ファイル(SDF)

- 動的および静的SDF指定

- 親表を子表から分割してのロード

- VARRAY列ロード時のメモリーの問題

12 従来型パス・ロードおよびダイレクト・パス・ロード

- データのロード方法

- ROWID列のロード

- 従来型パス・ロード

- 単一パーティションの従来型パス・ロード

- 従来型パスを使用する場合

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

- ダイレクト・パス・ロード時のデータ変換

- パーティション表またはサブパーティション表のダイレクト・パス・ロード

- 単一パーティションまたはサブパーティションのダイレクト・パス・ロード

- ダイレクト・パス・ロードのメリット

- ダイレクト・パス・ロード使用上の制限

- 単一パーティションのダイレクト・パス・ロードでの制限

- ダイレクト・パスを使用する場合

- 整合性制約

- ダイレクト・パスのフィールド・デフォルト

- シノニムへのロード

- ダイレクト・パス・ロードの使用

- ダイレクト・パス・ロードのセットアップ

- ダイレクト・パス・ロードの指定

- 索引の作成

- パフォーマンスの向上

- 一時セグメント記憶域要件

- 使用禁止状態(Index Unusable)のままの索引

- データ・セーブを使用したデータ損失の防止

- ROWSパラメータの使用

- データ・セーブとコミット

- ダイレクト・パス・ロード時のデータ・リカバリ

- メディア・リカバリおよびダイレクト・パス・ロード

- インスタンス・リカバリおよびダイレクト・パス・ロード

- LONG型データ・フィールドのロード

- PIECEDとしてのデータのロード

- ダイレクト・パス・モードを使用するSQL*Loader操作の監査

- ダイレクト・パス・ロードのパフォーマンスの最適化

- 高速ロードのための記憶域の事前割当て

- 高速索引付けのためのデータの事前ソート

- SORTED INDEXES句

- 未ソートのデータ

- 複数列索引

- 最適ソート順序の選択方法

- データ・セーブの回数の削減

- REDOログの最小限の使用

- アーカイブの使用禁止

- SQL*LoaderのUNRECOVERABLE句の指定

- SQL NOLOGGINGパラメータの設定

- 列配列の行数およびストリーム・バッファ・サイズの指定

- 「データ・キャッシュの値の指定」

- 複数CPUシステムのダイレクト・パス・ロードの最適化

- 索引メンテナンスの回避

- ダイレクト・パス・ロード、整合性制約およびトリガー

- 整合性制約

- 使用可能な制約

- 使用禁止の制約

- 制約を使用可能に戻す方法

- 挿入トリガー

- 挿入トリガーの整合性制約への置換

- 自動制約が使用できない場合

- 準備

- 更新トリガーの使用

- 例外処理と同じ処理の実現

- ストアド・プロシージャの使用

- 永続的に使用禁止のトリガーおよび制約

- 従来型パスの同時ロードによるパフォーマンスの向上

- パラレル・データ・ロード・モデル

- 従来型パスによる同時ロード

- ダイレクト・パスによるセグメント間同時処理

- ダイレクト・パスによるセグメント内同時処理

- パラレル・ダイレクト・パス・ロードの制限

- 複数のSQL*Loaderセッションの初期化

- パラレル・ダイレクト・パス・ロードのパラメータ

- FILEパラメータを使用した一時セグメントの指定

- FILEパラメータの使用

- STORAGEパラメータの使用方法

- パラレル・ダイレクト・パス・ロード後の制約の使用可能化

- 主キー制約および一意制約

- 一般的なパフォーマンス改善のヒント

13 SQL*Loaderエクスプレス

- SQL*Loaderエクスプレス・モードとは

- SQL*Loaderエクスプレス・モードの使用方法

- SQL*Loaderエクスプレス・モードで使用されるデフォルト値

- SQL*Loaderエクスプレス・モードによるバイト順序の処理方法

- SQL*Loaderエクスプレス・モードのパラメータ・リファレンス

- BAD

- CHARACTERSET

- CSV

- DATA

- DATE_FORMAT

- DEGREE_OF_PARALLELISM

- DIRECT

- DNFS_ENABLE

- DNFS_READBUFFERS

- ENCLOSED_BY

- EXTERNAL_TABLE

- FIELD_NAMES

- LOAD

- NULLIF

- OPTIONALLY_ENCLOSED_BY

- PARFILE

- SILENT

- TABLE

- TERMINATED_BY

- TIMESTAMP_FORMAT

- TRIM

- USERID

- SQL*Loaderエクスプレス・モードの構文図

第III部 外部表

14 外部表の概要

- 外部表の作成方法

- データ・ファイルおよび出力ファイルの位置

- アクセス・パラメータ

- 外部表の使用時のデータ型の変換

15 ORACLE_LOADERアクセス・ドライバ

- access_parameters句

- record_format_info句

- FIXED

- VARIABLE

- DELIMITED BY

- CHARACTERSET

- EXTERNAL VARIABLE DATA

- PREPROCESSOR

- PREPROCESSOR句によるパラレル処理の使用

- PREPROCESSOR句を使用する際の制限事項

- LANGUAGE

- TERRITORY

- DATA IS...ENDIAN

- BYTEORDERMARK(CHECK | NOCHECK)

- STRING SIZES ARE IN

- LOAD WHEN

- BADFILE | NOBADFILE

- DISCARDFILE | NODISCARDFILE

- LOGFILE | NOLOGFILE

- SKIP

- FIELD NAMES

- READSIZE

- DISABLE_DIRECTORY_LINK_CHECK

- DATA_CACHE

- string

- condition_spec

- [directory object name:] [filename]

- condition

- range start : range end

- IO_OPTIONS clause

- DNFS_DISABLE | DNFS_ENABLE

- DNFS_READBUFFERS

- field_definitions句

- delim_spec

- 例: 終了デリミタを含む外部表

- 例: 囲みデリミタおよび終了デリミタを含む外部表

- 例: オプションの囲みデリミタを含む外部表

- trim_spec

- MISSING FIELD VALUES ARE NULL

- field_list

- pos_spec句

- start

- *

- increment

- end

- length

- datatype_spec句

- [UNSIGNED] INTEGER [EXTERNAL] [(len)]

- DECIMAL [EXTERNAL]およびZONED [EXTERNAL]

- ORACLE_DATE

- ORACLE_NUMBER

- 浮動小数点数

- DOUBLE

- FLOAT [EXTERNAL]

- BINARY_DOUBLE

- BINARY_FLOAT

- RAW

- CHAR

- date_format_spec

- DATE

- MASK

- TIMESTAMP

- INTERVAL

- VARCHARおよびVARRAW

- VARCHARCおよびVARRAWC

- init_spec句

- column_transforms句

- transform

- column_name FROM

- NULL

- CONSTANT

- CONCAT

- LOBFILE

- lobfile_attr_list

- STARTOF source_field (長さ)

- ORACLE_LOADERアクセス・ドライバのパラレル・ロードに関する考慮点

- ORACLE_LOADERアクセス・ドライバを使用する際のパフォーマンスのヒント

- ORACLE_LOADERアクセス・ドライバ使用時の制限事項

- ORACLE_LOADERアクセス・ドライバの予約語

16 ORACLE_DATAPUMPアクセス・ドライバ

- access_parameters句

- コメント

- COMPRESSION

- ENCRYPTION

- LOGFILE | NOLOGFILE

- LOGFILEのファイル名

- VERSION句

- SQL ENCRYPT句の使用による影響

- ORACLE_DATAPUMPアクセス・ドライバを使用したデータのアンロードとロード

- パラレル・ロードおよびパラレル・アンロード

- ダンプ・ファイルの結合

- サポートされるデータ型

- サポートされないデータ型

- BFILEデータ型のアンロードおよびロード

- LONGおよびLONG RAWデータ型のアンロード

- FINALオブジェクト型を含む列のアンロードおよびロード

- FINALオブジェクト型の表

- ORACLE_DATAPUMPアクセス・ドライバを使用する際のパフォーマンスのヒント

- ORACLE_DATAPUMPアクセス・ドライバ使用時の制限事項

- ORACLE_DATAPUMPアクセス・ドライバの予約語

第IV部 その他のユーティリティ

17 ADRCI: ADRコマンド・インタプリタ

- ADRコマンド・インタプリタ(ADRCI)ユーティリティ

- 定義

- ADRCIの起動とヘルプの利用

- 対話方式モードでのADRCIの使用方法

- ヘルプの利用

- バッチ・モードでのADRCIの使用方法

- ADRCIコマンドを使用する前のADRCIホームパスの設定

- アラート・ログの表示

- トレース・ファイルの検索

- インシデントの表示

- インシデントのパッケージ化

- インシデントのパッケージ化

- インシデント・パッケージの作成

- 論理インシデント・パッケージの作成

- 論理インシデント・パッケージへの診断情報の追加

- 物理インシデント・パッケージの生成

- ADRCIコマンド・リファレンス

- CREATE REPORT

- ECHO

- EXIT

- HOST

- IPS

- IPSコマンドでの<ADR_HOME>および<ADR_BASE>変数の使用

- IPS ADD

- IPS ADD FILE

- IPS ADD NEW INCIDENTS

- IPS COPY IN FILE

- IPS COPY OUT FILE

- IPS CREATE PACKAGE

- IPS DELETE PACKAGE

- IPS FINALIZE

- IPS GENERATE PACKAGE

- IPS GET MANIFEST

- IPS GET METADATA

- IPS PACK

- IPS REMOVE

- IPS REMOVE FILE

- IPS SET CONFIGURATION

- IPS SHOW CONFIGURATION

- IPS SHOW FILES

- IPS SHOW INCIDENTS

- IPS SHOW PACKAGE

- IPS UNPACK FILE

- PURGE

- QUIT

- RUN

- SELECT

- AVG

- CONCAT

- COUNT

- DECODE

- LENGTH

- MAX

- MIN

- NVL

- REGEXP_LIKE

- SUBSTR

- SUM

- TIMESTAMP_TO_CHAR

- TOLOWER

- TOUPPER

- SET BASE

- SET BROWSER

- SET CONTROL

- SET ECHO

- SET EDITOR

- SET HOMEPATH

- SET TERMOUT

- SHOW ALERT

- SHOW BASE

- SHOW CONTROL

- SHOW HM_RUN

- SHOW HOMEPATH

- SHOW HOMES

- SHOW INCDIR

- SHOW INCIDENT

- SHOW LOG

- SHOW PROBLEM

- SHOW REPORT

- SHOW TRACEFILE

- SPOOL

- ADRCIのトラブルシューティング

18 DBVERIFY: オフライン・データベース検査ユーティリティ

- DBVERIFYを使用した単一データ・ファイルのディスク・ブロックの検査

- 単一ファイルのブロックを検査する際のDBVERIFY構文

- 単一ファイルのブロックを検査する際のDBVERIFYパラメータ

- 単一データ・ファイルに対するDBVERIFYの出力例

- DBVERIFYを使用したセグメントの検査

- セグメントを検査する際のDBVERIFY構文

- 単一のセグメントを検査する際のDBVERIFYパラメータ

- 検査対象のセグメントに対するDBVERIFYの出力例

19 DBNEWIDユーティリティ

- DBNEWIDユーティリティとは

- DBIDおよびDBNAMEの変更による影響

- グローバル・データベース名に関する考慮点

- データベースのDBIDおよびDBNAMEの変更

- DBIDおよびデータベース名の変更

- データベースIDのみの変更

- データベース名のみの変更

- DBNEWIDのトラブルシューティング

- DBNEWIDユーティリティの構文

- DBNEWIDパラメータ

- 制限事項および使用上の注意

- Oracle Database 10gより前のリリースに対する制限事項

20 REDOログ・ファイル分析のためのLogMinerの使用

- LogMinerのメリット

- LogMinerの概要

- LogMinerの構成

- LogMiner構成のサンプル

- 要件

- LogMiner操作の指定および分析するデータの取得

- CDBのLogMinerの使用

- CDBでのLogMiner V$ビューおよびDBAビュー

- CDBでのV$LOGMNR_CONTENTSビュー

- CDBでのサプリメンタル・ロギングの有効化

- CDBでのフラット・ファイル・ディクショナリの使用

- LogMinerディクショナリ・ファイルとREDOログ・ファイル

- LogMinerディクショナリ・オプション

- オンライン・カタログの使用

- REDOログ・ファイルへのLogMinerディクショナリの抽出

- フラット・ファイルへのLogMinerディクショナリの抽出

- REDOログ・ファイル・オプション

- LogMinerの起動

- 分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ

- V$LOGMNR_CONTENTSビューへの移入方法

- 列の値に基づいたV$LOGMNR_CONTENTSの問合せ

- MINE_VALUE関数によって返されるNULL値の意味

- MINE_VALUE関数およびCOLUMN_PRESENT関数の使用規則

- MINE_VALUEファンクションを使用してNCHAR値を取得する際の制限事項

- XMLType列およびXMLType表に基づいたV$LOGMNR_CONTENTSの問合せ

- XMLTypeデータを使用するLogMinerの使用上の制限

- XMLTypeデータを作成するためのPL/SQLプロシージャの例

- V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定

- コミット済トランザクションのみの表示

- REDO破損のスキップ

- 時刻によるデータのフィルタ処理

- SCNによるデータのフィルタ処理

- 再実行のために再構築されたSQL文の書式設定

- 返されるデータの可読性向上のための表示方法の書式設定

- V$LOGMNR_CONTENTSに返されたDDL文の再適用

- DBMS_LOGMNR.START_LOGMNRの複数回のコール

- サプリメンタル・ロギング

- データベース・レベルのサプリメンタル・ロギング

- 最小サプリメンタル・ロギング

- データベース・レベルの識別キー・ロギング

- データベース・レベルのサプリメンタル・ロギングの無効化

- 表レベルのサプリメンタル・ロギング

- 表レベルの識別キー・ロギング

- 表レベルのユーザー定義サプリメンタル・ログ・グループ

- ユーザー定義のサプリメンタル・ログ・グループを使用する場合の注意事項

- LogMinerディクショナリでのDDL文の追跡

- DDL_DICT_TRACKINGおよびサプリメンタル・ロギングの設定

- DDL_DICT_TRACKINGおよび指定された時間範囲またはSCN範囲

- ビューでのLogMiner操作情報へのアクセス

- V$LOGMNR_LOGSの問合せ

- サプリメンタル・ロギング設定に関するビューの問合せ

- 一般的なLogMinerセッションの手順

- 一般的なLogMinerセッション・タスク1: サプリメンタル・ロギングの有効化

- 一般的なLogMinerセッション・タスク2: LogMinerディクショナリの抽出

- 一般的なLogMinerセッション・タスク3: 分析用のREDOログ・ファイルの指定

- 一般的なLogMinerセッション・タスク4: LogMinerの起動

- 一般的なLogMinerセッション・タスク5: V$LOGMNR_CONTENTSの問合せ

- 一般的なLogMinerセッション・タスク6: LogMinerセッションの終了

- LogMinerの使用例

- 分析するREDOログ・ファイルの明示的指定によるマイニングの例

- 例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索

- 例2: コミット済トランザクションへのDML文のグループ化

- 例3: 再構築されたSQLの書式設定

- 例4: REDOログ・ファイル内のLogMinerディクショナリの使用

- 例5: 内部ディクショナリでのDDL文の追跡

- 例6: 時間範囲による出力のフィルタ処理

- REDOログ・ファイルのリストを明示的に指定しないマイニングの例

- 例1: 指定した時間範囲でのREDOログ・ファイルのマイニング

- 例2: 指定したSCN範囲でのREDOログ・ファイルのマイニング

- 例3: 問合せに将来の値を含めるCONTINUOUS_MINEオプションの使用

- 使用例

- 使用例1: LogMinerを使用した特定のユーザーによる変更の追跡

- 使用例2: LogMinerを使用した表アクセス統計の計算

- サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン

- サポートされるデータ型と表記憶域属性

- 互換性要件

- サポートされないデータ型と表記憶域属性

- サポートされるデータベースとREDOログ・ファイルのバージョン

- SecureFiles LOBに関する考慮点

21 メタデータAPIの使用

- DBMS_METADATA APIを使用する理由

- DBMS_METADATA APIの概要

- オブジェクトのメタデータを取得するためのDBMS_METADATA APIの使用

- 基本的なメタデータ取得の通常手順

- 複数のオブジェクトの取得

- 変換の条件指定

- 特定のメタデータ属性へのアクセス

- 取得したオブジェクトを再作成するためのDBMS_METADATA APIの使用

- 異なるオブジェクト型のコレクションを取得するためのDBMS_METADATA APIの使用

- 異種オブジェクト型の返りのフィルタ

- オブジェクトのメタデータを比較するためのDBMS_METADATA_DIFF APIの使用

- DBMS_METADATA APIのプログラム・インタフェースに関するパフォーマンスのヒント

- DBMS_METADATA APIの使用例

- DBMS_METADATAの例で行われる処理

- GET_PAYROLL_TABLESプロシージャで生成される出力

- DBMS_METADATAプロシージャの要約

- DBMS_METADATA_DIFFプロシージャの要約

22 オリジナルのエクスポート

- エクスポート・ユーティリティとは

- エクスポート・ユーティリティを使用する前に

- catexp.sqlまたはcatalog.sqlの実行

- エクスポート操作に必要な十分なディスク領域の確保

- エクスポート操作およびインポート操作のアクセス権の確認

- エクスポート・ユーティリティの起動

- SYSDBAでのエクスポート・ユーティリティの起動

- コマンドライン

- パラメータ・ファイル

- 対話方式モード

- 対話方式でのエクスポートを使用する際の制限事項

- オンライン・ヘルプの利用

- エクスポート・モード

- 表レベル・エクスポートおよびパーティション・レベル・エクスポート

- 表レベル・エクスポート

- パーティション・レベル・エクスポート

- エクスポート・パラメータ

- BUFFER

- 例: バッファ・サイズの計算

- COMPRESS

- CONSISTENT

- CONSTRAINTS

- DIRECT

- FEEDBACK

- FILE

- FILESIZE

- FLASHBACK_SCN

- FLASHBACK_TIME

- FULL

- 全データベースのエクスポートおよびインポートについての考慮点

- GRANTS

- HELP

- INDEXES

- LOG

- OBJECT_CONSISTENT

- OWNER

- PARFILE

- QUERY

- QUERYパラメータを使用する際の制限事項

- RECORDLENGTH

- RESUMABLE

- RESUMABLE_NAME

- RESUMABLE_TIMEOUT

- ROWS

- STATISTICS

- TABLES

- 表名の制限

- TABLESPACES

- TRANSPORT_TABLESPACE

- TRIGGERS

- TTS_FULL_CHECK

- USERID(ユーザー名/パスワード)

- VOLSIZE

- エクスポート・セッションの例

- 全体データベース・モードのエクスポート・セッションの例

- ユーザー・モードのエクスポート・セッションの例

- 表モードのエクスポート・セッションの例

- 例1: DBAによる2人のユーザー用の表のエクスポート

- 例2: ユーザーによる自身が所有している表のエクスポート

- 例3: パターン一致を使用した様々な表のエクスポート

- パーティション・レベル・エクスポートでのエクスポート・セッションの例

- 例1: パーティションを指定しない表のエクスポート

- 例2: パーティションを指定した表のエクスポート

- 例3: コンポジット・パーティションのエクスポート

- 警告、エラーおよび完了メッセージ

- ログ・ファイル

- 警告メッセージ

- リカバリ不能なエラー・メッセージ

- 完了メッセージ

- 終了コードによる結果の検査と表示

- 従来型パス・エクスポートとダイレクト・パス・エクスポート

- ダイレクト・パス・エクスポートの起動

- ダイレクト・パス・エクスポートに関するセキュリティ上の考慮点

- ダイレクト・パス・エクスポートに関するパフォーマンス上の考慮点

- ダイレクト・パス・エクスポートに関する制限事項

- ネットワークに関する考慮点

- ネットワークを介してエクスポート・ファイルを転送する方法

- Oracle Netを使用したエクスポート

- キャラクタ・セットおよびグローバリゼーション・サポートに関する考慮点

- ユーザー・データ

- 変換によるキャラクタ・セットのソート順への影響

- DDL

- シングルバイト・キャラクタ・セットとエクスポートおよびインポート

- マルチバイト・キャラクタ・セットとエクスポートおよびインポート

- エクスポート・ユーティリティおよびインポート・ユーティリティでのインスタンス親和性の使用

- データベース・オブジェクトのエクスポート時の考慮点

- エクスポート順序

- LONGおよびLOBデータ型のエクスポート

- 外部関数ライブラリのエクスポート

- オフライン・ローカル管理表領域のエクスポート

- ディレクトリ別名のエクスポート

- BFILE列および属性のエクスポート

- 外部表のエクスポート

- オブジェクトの型定義のエクスポート

- ネストした表のエクスポート

- AQ表のエクスポート

- シノニムのエクスポート

- Javaシノニムに関連して発生する可能性があるエクスポート・エラー

- ファイングレイン・アクセス・コントロールに対するサポート

- トランスポータブル表領域

- 読取り専用データベースからのエクスポート

- エクスポート・ユーティリティおよびインポート・ユーティリティを使用したデータベース移行のパーティション化

- 移行をパーティション化する場合のメリット

- 移行をパーティション化する場合のデメリット

- エクスポート・ユーティリティおよびインポート・ユーティリティを使用したデータベース移行のパーティション化方法

- リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用

- リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用時の制限事項

- リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用例

23 オリジナルのインポート

- インポート・ユーティリティとは

- 表オブジェクト: インポートの順序

- インポート・ユーティリティを使用する前に

- catexp.sqlまたはcatalog.sqlの実行

- インポート操作のアクセス権の確認

- オブジェクトをスキーマにインポートする方法

- 権限のインポート

- 他のスキーマへのオブジェクトのインポート

- システム・オブジェクトのインポート

- 処理上の制限事項

- 既存の表へのインポート

- データのインポート前に手動で表を作成する方法

- 参照制約を使用禁止にする方法

- 手動によるインポートの順序付け

- インポート操作上のスキーマおよびデータベース・トリガーの影響

- インポート・ユーティリティの起動

- コマンドライン

- パラメータ・ファイル

- 対話方式モード

- SYSDBAでのインポート・ユーティリティの起動

- オンライン・ヘルプの利用

- インポート・ユーティリティのモード

- インポート・パラメータ

- BUFFER

- COMMIT

- COMPILE

- CONSTRAINTS

- DATA_ONLY

- DATAFILES

- DESTROY

- FEEDBACK

- FILE

- FILESIZE

- FROMUSER

- FULL

- 全データベースのエクスポートおよびインポートについての考慮点

- GRANTS

- HELP

- IGNORE

- INDEXES

- INDEXFILE

- LOG

- PARFILE

- RECORDLENGTH

- RESUMABLE

- RESUMABLE_NAME

- RESUMABLE_TIMEOUT

- ROWS

- SHOW

- SKIP_UNUSABLE_INDEXES

- STATISTICS

- STREAMS_CONFIGURATION

- STREAMS_INSTANTIATION

- TABLES

- 表名の制限

- TABLESPACES

- TOID_NOVALIDATE

- TOUSER

- TRANSPORT_TABLESPACE

- TTS_OWNERS

- USERID(ユーザー名/パスワード)

- VOLSIZE

- インポート・セッションの例

- 特定のユーザーの表を選択してインポートする例

- 別のユーザーによってエクスポートされた表をインポートする例

- あるユーザーの表を別のユーザーへインポートする例

- パーティション・レベル・インポートでのインポート・セッションの例

- 例1: パーティション・レベル・インポート

- 例2: コンポジット・パーティション表のパーティション・レベル・インポート

- 例3: 別の列での表の再パーティション化

- パターン一致を使用して様々な表をインポートする例

- 終了コードによる結果の検査と表示

- インポート中のエラー処理

- 行エラー

- 整合性制約違反

- 無効なデータ

- データベース・オブジェクトのインポートでのエラー

- 既存オブジェクト

- 順序

- リソース・エラー

- ドメイン索引メタデータ

- 表レベル・インポートおよびパーティション・レベル・インポート

- 表レベル・インポートの使用に関するガイドライン

- パーティション・レベル・インポートの使用に関するガイドライン

- パーティションと表の間のデータ移行

- 索引作成およびメンテナンスの制御

- 索引作成の延期

- 索引作成およびメンテナンスの制御

- 索引更新延期の例

- ネットワークに関する考慮点

- キャラクタ・セットおよびグローバリゼーション・サポートに関する考慮点

- ユーザー・データ

- 変換によるキャラクタ・セットのソート順への影響

- DDL

- シングルバイト・キャラクタ・セット

- マルチバイト・キャラクタ・セット

- インスタンス親和性の使用方法

- データベース・オブジェクトのインポートに関する考慮点

- オブジェクト識別子のインポート

- 既存のオブジェクト表およびオブジェクト型の含まれている表のインポート

- ネストした表のインポート

- REFデータのインポート

- BFILE列およびディレクトリ別名のインポート

- 外部関数ライブラリのインポート

- ストアド・プロシージャ、ファンクションおよびパッケージのインポート

- Javaオブジェクトのインポート

- 外部表のインポート

- AQ表のインポート

- LONG列のインポート

- トリガーが存在する場合のLOB列のインポート

- ビューのインポート

- パーティション表のインポート

- ファイングレイン・アクセス・コントロールに対するサポート

- スナップショットおよびスナップショット・ログ

- スナップショット・ログ

- スナップショット

- スナップショットのインポート

- 異なるスキーマへのスナップショットのインポート

- トランスポータブル表領域

- 記憶域パラメータ

- OPTIMALパラメータ

- OID索引とLOB列の記憶域パラメータ

- 記憶域パラメータの上書き

- 読取り専用表領域

- 表領域を削除する方法

- 表領域を再編成する方法

- 統計情報のインポート

- エクスポート・ユーティリティおよびインポート・ユーティリティを使用したデータベース移行のパーティション化

- 移行をパーティション化する場合のメリット

- 移行をパーティション化する場合のデメリット

- エクスポート・ユーティリティおよびインポート・ユーティリティを使用したデータベース移行のパーティション化方法

- インポート操作のチューニングに関する考慮点

- システム・レベル・オプションの変更

- 初期化パラメータの変更

- インポート・オプションの変更

- 大量のLOBデータの処理

- 大量のLONGデータの処理

- リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用

- リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用時の制限事項

- リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用例

第V部 付録

A SQL*Loaderの構文図

索引

表一覧

- 1-1 データ・ポンプの終了コード

- 2-1 データ・ポンプ・エクスポートの対話方式コマンド・モードでサポートされているコマンド

- 3-1 データ・ポンプ・インポートのTRANSFORMパラメータの有効なオブジェクト型

- 3-2 データ・ポンプ・インポートの対話方式コマンド・モードでサポートされているコマンド

- 4-1 データ・ポンプ・エクスポートでのオリジナルのエクスポート・パラメータの扱い

- 4-2 データ・ポンプ・インポートでのオリジナルのインポート・パラメータの扱い

- 6-1 DBMS_DATAPUMPプロシージャを実行できる有効なジョブの状態

- 7-1 事例用ファイルおよび関連ファイル

- 8-1 SQL*Loaderの終了コード

- 9-1 INFILEキーワードのパラメータ

- 9-2 CONTINUEIF句のパラメータ

- 9-3 固定長フィールド

- 9-4 非グラフィック・フィールド

- 9-5 グラフィック・フィールド

- 9-6 可変長フィールド

- 10-1 位置指定句のパラメータ

- 10-2 日時データ型および期間データ型のデータ型変換

- 10-3 デリミタの指定に使用するパラメータ

- 10-4 フィールド条件句のパラメータ

- 10-5 空白の切捨てに関する動作のサマリー

- 10-6 列指定に使用されるパラメータ

- 17-1 バッチ操作用のADRCIのコマンドライン・パラメータ

- 17-2 ADRCIコマンドのリスト

- 17-3 IPSのコマンド・セット

- 17-4 IPS ADDコマンドの引数

- 17-5 IPS CREATE PACKAGEコマンドの引数

- 17-6 IPS PACKコマンドの引数

- 17-7 IPS REMOVEコマンドの引数

- 17-8 IPS構成パラメータ

- 17-9 PURGEコマンドのフラグ

- 17-10 SELECTコマンドのフラグ

- 17-11 SELECTコマンドのADRCIユーティリティ関数

- 17-12 SHOW ALERTコマンドのフラグ

- 17-13 SHOW ALERTのアラート・フィールド

- 17-14 状態モニターの実行に使用するフィールド

- 17-15 SHOW INCIDENTコマンドのフラグ

- 17-16 SHOW INCIDENTのインシデント・フィールド

- 17-17 SHOW LOGコマンドのフラグ

- 17-18 SHOW LOGのログ・フィールド

- 17-19 SHOW PROBLEMコマンドのフラグ

- 17-20 SHOW PROBLEMの問題フィールド

- 17-21 SHOW TRACEFILEコマンドの引数

- 17-22 SHOW TRACEFILEコマンドのフラグ

- 19-1 DBNEWIDユーティリティのパラメータ

- 21-1 複数オブジェクトの取得に使用するDBMS_METADATAプロシージャ

- 21-2 ブラウザ・インタフェースで使用するDBMS_METADATAプロシージャ

- 21-3 XMLの送信で使用するDBMS_METADATAのプロシージャおよびファンクション

- 21-4 DBMS_METADATA_DIFFのプロシージャおよびファンクション

- 22-1 各モードでエクスポートされるオブジェクト

- 22-2 2人のユーザーによる更新時のイベント順序

- 22-3 ダンプ・ファイルの最大サイズ

- 22-4 エクスポート・ユーティリティの終了コード

- 22-5 リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用

- 23-1 自分のスキーマにオブジェクトをインポートするために必要な権限

- 23-2 権限のインポートに必要な権限

- 23-3 各モードでインポートされるオブジェクト

- 23-4 インポート・ユーティリティの終了コード

- 23-5 リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用

はじめに

このマニュアルでは、Oracle Databaseユーティリティを使用して、データ転送、データ・メンテナンスおよびデータベース管理を行う方法について説明します。

対象読者

このマニュアルのユーティリティは、データベース管理者(DBA)、アプリケーション・プログラマ、セキュリティ管理者、システム・オペレータを対象としています。また、次の作業を行うOracleユーザーも対象としています。

- エクスポート・ユーティリティおよびインポート・ユーティリティ(オリジナルおよびデータ・ポンプ版の両方)を使用した、データのアーカイブ、Oracle DatabaseのバックアップおよびOracle Database間のデータ移動

- SQL*Loaderを使用したオペレーティング・システムのファイルからOracle表へのデータのロード、または外部表機能を使用した外部ソースからOracle表へのデータのロード

- DBVERIFYユーティリティを使用した、オフライン・データベース上での物理データ構造に対する整合性チェックの実行

- DBNEWIDユーティリティを使用した、オペレーショナル・データベースの内部データベース識別子(DBID)およびデータベース名(DBNAME)の維持

- メタデータAPIを使用した、データベース・オブジェクトに対するメタデータの完全な表現の抽出および処理

- LogMinerユーティリティを使用した、(SQLインタフェースからの)REDOログ・ファイルの問合せおよび分析

- 自動診断リポジトリ・コマンド・インタプリタ(ADRCI)ユーティリティを使用した、Oracle Database診断データの管理

このマニュアルを使用するには、SQLおよびOracleの基礎知識が必要です。これらの情報は、『Oracle Database概要』で参照できます。また、SQL*Loaderを使用するには、オペレーティング・システムのファイル管理機能の使用方法を理解しておく必要があります。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のOracleドキュメントを参照してください。

特に、Oracle Databaseに関連するドキュメントは、次のとおりです。

- 『Oracle Database概要』

- 『Oracle Database SQL言語リファレンス』

- Oracle Database管理者ガイド

- 『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』

このマニュアル内の例の一部で、Oracle Databaseのインストール時にデフォルトとしてインストールされるシード・データベースのサンプル・スキーマを使用しています。これらのスキーマの作成方法および使用方法の詳細は、『Oracle Databaseサンプル・スキーマ』を参照してください。

構文図

このマニュアルでは、様々なSQL、PL/SQL、あるいはその他のコマンド・ライン構成の構文記述に、図形式またはバッカス正規形(BNF)を使用しています。これらの記述を解釈する方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

表記規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

Oracle Databaseユーティリティの今回のリリースでの変更点

この章では、Oracle Databaseユーティリティの変更点をリストします。

Oracle Database 12cリリース1 (12.1.0.2)での変更点

Oracle Database 12cリリース1 (12.1.0.2)のOracle Databaseユーティリティの変更点は次のとおりです。

- 2つの新しい変換、INMEMORYおよびINMEMORY_CLAUSEがデータ・ポンプ・インポートのTRANSFORMパラメータで使用可能です。インポート中のOracle Databaseのインメモリー列ストア(IM列ストア)のサポートが提供されています。詳細は、TRANSFORMパラメータの説明を参照してください。

Oracle Database 12cリリース1 (12.1.0.1)での変更点

Oracle Database 12cリリース1 (12.1.0.1)のOracle Databaseユーティリティの変更点は次のとおりです。

新機能

この項では、次のユーティリティの新機能について説明します。

- Oracle Data Pumpエクスポートおよびインポート

- Oracle SQL*Loader

- Oracle外部表

- Oracle LogMiner

Oracle Data Pumpエクスポートおよびインポート

今回のリリースでのデータ・ポンプの新機能は次のとおりです。

- 全体モード・エクスポートおよびインポート中にトランスポータブル・オプションを使用して、必要に応じてトランスポータブル表領域テクノロジを通じてデータベース全体を移動できます。この新しいモードは、全体トランスポータブル・エクスポートおよび全体トランスポータブル・インポートと呼ばれます。詳細は、エクスポートの「FULL」パラメータおよびインポートの「FULL」パラメータを参照してください。全体トランスポータブル・エクスポートおよびインポートの詳細は、『Oracle Database管理者ガイド』も参照してください。

- データ・ポンプ・エクスポートおよびインポートでは、マルチテナント・コンテナ・データベース(CDB)およびプラガブル・データベース(PDB)がサポートされます。データ・ポンプを使用すると、データベースの全部または一部の非CDBからPDBへの移行、同じかまたは異なるCDB内のPDB間での移行、PDBから非CDBへの移行が可能です。詳細は、「CDBでのデータ・ポンプの使用」を参照してください。

- 新しいVIEWS_AS_TABLESパラメータでは、1つ以上のビューを表としてエクスポートできます。詳細は、エクスポートの「VIEWS_AS_TABLES」パラメータを参照してください。その後、インポートの「VIEWS_AS_TABLES (非ネットワーク・インポート)」パラメータを使用してダンプ・ファイルをインポートできます。表としてのビューのネットワーク・インポートも実行できます。詳細は、「VIEWS_AS_TABLES (ネットワーク・インポート)」を参照してください。

- インポート・ジョブ中に、アーカイブ・ログに書き込まれるデータの量を削減できます。詳細は、インポートの「TRANSFORM」パラメータの新しいDISABLE_ARCHIVE_LOGGINGオプションを参照してください。

- インポート・ジョブ中に、マテリアライズド・ビューに記憶域を提供する表を含め、ジョブのすべての表の圧縮タイプを変更できます。詳細は、インポートの「TRANSFORM」パラメータのTABLE_COMPRESSION_CLAUSEオプションを参照してください。

- インポート・ジョブ中に、マテリアライズド・ビューに記憶域を提供する表を含め、ジョブのすべての表のLOB記憶域(SECUREFILEまたはBASICFILE)を変更できます。詳細は、インポートの「TRANSFORM」パラメータのLOB_STORAGEオプションを参照してください。

- データ・ポンプ・ジョブで統合監査を有効にできます。詳細は、「データ・ポンプ・ジョブの監査」を参照してください。

- 新しいENCRYPTION_PWD_PROMPTパラメータでは、コマンドラインでパスワードを入力するかわりに、データ・ポンプによって暗号化パスワードの入力を要求するかどうかを指定できます。詳細は、エクスポートの「ENCRYPTION_PWD_PROMPT」パラメータおよびインポートの「ENCRYPTION_PWD_PROMPT」パラメータを参照してください。

- 新しいCOMPRESSION_ALGORITHMパラメータでは、ダンプ・ファイル・データの特定レベルの圧縮を指定できます。これによって、環境、ワークロードの特性、およびデータのサイズとタイプに基づいて圧縮レベルを選択できます。詳細は、「COMPRESSION_ALGORITHM」を参照してください。

- VARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズが32KBに増加しました(COMPATIBLE初期化パラメータが12.0以上に設定され、MAX_STRING_SIZE初期化パラメータがEXTENDEDに設定されている場合)。データ・ポンプでは、データ・ポンプのVERSIONパラメータが12.1より前の値に設定されていないかぎり、この増加したサイズがサポートされます。詳細は、エクスポートの「VERSION」パラメータおよびインポートの「VERSION」パラメータを参照してください。

- ダイレクト・パス・ロード方法は、LOB列にドメイン索引が設定されていてもサポートされます。データ・ポンプがダイレクト・パスによる方法を使用する場合と使用しない場合の詳細は、「ダイレクト・パスを使用したデータ移動」を参照してください。

- データ・ポンプ・エクスポートおよびインポートで使用できる新しいLOGTIMEコマンドライン・パラメータでは、エクスポートおよびインポート操作中に表示されるメッセージにタイムスタンプを付けるように指定できます。タイムスタンプを使用すると、データ・ポンプ操作の異なる処理間の経過時間を確認できるため、パフォーマンス問題を診断する場合や、将来の同じような操作の時間を見積もる場合に役立ちます。詳細は、エクスポートの「LOGTIME」パラメータおよびインポートの「LOGTIME」パラメータを参照してください。

Oracle SQL*Loader

今回のリリースのSQL*Loaderの新機能は次のとおりです。

- 新しいSQL*Loaderエクスプレス・モードでは、単純な列データ型を含む表と、デリミタ付きの文字データのみを含むデータ・ファイルを高速かつ簡単にロードするための効率的な方法が提供されます。詳細は、「SQL*Loaderエクスプレス」を参照してください。

- 新しいDNFS_ENABLEパラメータでは、SQL*Loader操作中の入力データ・ファイルに対するDirect NFSクライアントの使用を有効化および無効化できます。また、新しいDNFS_READBUFFERSパラメータでは、Direct NFSクライアントによって使用される読取りバッファの数を制御できます。詳細は、「DNFS_ENABLE」および「DNFS_READBUFFERS」を参照してください。

- VARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズが32KBに増加しました(COMPATIBLE初期化パラメータが12.0以上に設定され、MAX_STRING_SIZE初期化パラメータがEXTENDEDに設定されている場合)。SQL*Loaderでは、この新しい最大サイズがサポートされます。SQL*Loaderのデータ型の詳細は、「SQL*Loaderのデータ型」を参照してください。

- ダイレクト・パス・モードを使用するSQL*Loader操作の監査を有効にできます。詳細は、「ダイレクト・パス・モードを使用するSQL*Loader操作の監査」を参照してください。

- SQL*Loader制御ファイルには、その使用を簡略化するいくつかの新しい句が用意されています。また、いくつかの既存のパラメータが変更され、新しいパラメータがロード実行を効率化するために追加されています。

- INFILE句にワイルドカード文字を指定できます。詳細は、「データ・ファイルの指定」を参照してください。

- SQL*Loaderでカンマ区切り値(CSV)形式のファイルであるデータ・ファイルにアクセスできます。詳細は、「CSV形式のファイルの指定」を参照してください。

- 表レベルで、日時書式を指定してすべての日時フィールドに適用できます。詳細は、「表レベルでの日時書式の指定」を参照してください。

- 表レベルで、NULLIFを指定してすべての文字フィールドに適用できます。詳細は、「表レベルでのNULLIF句の指定」を参照してください。

- SQL*Loaderで、データ・ファイルの最初のレコードに含まれるフィールド名の順序からフィールド順序を決定するように指定できます。詳細は、「フィールド順序の指定」を参照してください。

- SQL*Loaderコマンドラインには、ロード実行を効率化するために役立つ新しいパラメータと変更されたパラメータがあります。

- 新しいTRIMコマンドライン・パラメータでは、外部表オプションの使用時に、デフォルトのTRIM=LDRTRIMを上書きできます。詳細は、「TRIM」を参照してください。

- 新しいDEGREE_OF_PARALLELISMコマンドライン・パラメータでは、外部表オプションの使用時に、ロードで使用する並列度を指定できます。詳細は、「DEGREE_OF_PARALLELISM」を参照してください。

- SQL*Loaderコマンドラインで不良ファイル、廃棄ファイルおよびログ・ファイルを指定する場合、ディレクトリ名のみを指定するオプションを使用できます。詳細は、「BAD」、「DISCARD」および「LOG」を参照してください。

Oracle外部表

今回のリリースの外部表の新機能は次のとおりです。

- 新しいDNFS_ENABLEおよびDNFS_DISABLEパラメータでは、外部表操作中の入力データ・ファイルに対するDirect NFSクライアントの使用を有効化および無効化できます。また、新しいDNFS_READBUFFERSパラメータでは、Direct NFSクライアントによって使用される読取りバッファの数を制御できます。詳細は、「DNFS_DISABLE | DNFS_ENABLE」および「DNFS_READBUFFERS」を参照してください。

- ORACLE_DATAPUMPアクセス・ドライバを使用して、外部表を処理する場合の圧縮レベルを指定できます。詳細は、「COMPRESSION」を参照してください。

- VARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズが32KBに増加しました(COMPATIBLE初期化パラメータが12.0以上に設定され、MAX_STRING_SIZE初期化パラメータがEXTENDEDに設定されている場合)。外部表機能では、この新しい最大サイズがサポートされます。外部表によるデータ型の処理方法の詳細は、「外部表の使用時のデータ型の変換」を参照してください。

- ORACLE_LOADERアクセス・パラメータ・リストには、その使用を簡略化するいくつかの新しい句が用意されています。

- LOCATION句にワイルドカード文字を指定できます。詳細は、「外部表の作成方法」を参照してください。

- 不良ファイル、廃棄ファイルおよびログ・ファイルを指定する場合、ディレクトリ・オブジェクトのみを指定できます。詳細は、「[directory object name:] [filename]」を参照してください。

- 外部表でカンマ区切り値形式のファイルであるデータ・ファイルにアクセスできます。詳細は、「CSV」を参照してください。

- 日時書式を指定してすべての日時フィールドに適用できます。詳細は、「DATE_FORMAT」を参照してください。

- NULLIFを指定してすべての文字フィールドに適用できます。詳細は、「NULLIF | NO NULLIF」を参照してください。

- SQL*Loaderで、データ・ファイルの最初のレコードに含まれるフィールド名の順序からフィールド順序を決定するように指定できます。詳細は、「FIELD NAMES」を参照してください。

- アクセス・ドライバに対し、すべてのフィールドが存在し、それらが外部表の列と同じ順序であることを指定できます。その後、特殊な定義が含まれるフィールドを指定するだけで済みます。詳細は、「ALL FIELDS OVERRIDE」を参照してください。

Oracle LogMiner

今回のリリースのLogMinerの新機能は次のとおりです。

- SecureFiles LOBが完全にサポートされます(SecureFiles LOB列の重複除外およびSecureFiles Database File System (DBFS)操作を含む)。詳細は、「SecureFiles LOBに関する考慮点」を参照してください。

- オブジェクトおよびコレクションがサポートされます。詳細は、「サポートされるデータ型と表記憶域属性」を参照してください。

- CDBはLogMinerでサポートされています。詳細は、「CDBでのLogMinerの使用」を参照してください。

- VARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズが32KBに増加しました(COMPATIBLE初期化パラメータが12.0以上に設定され、MAX_STRING_SIZE初期化パラメータがEXTENDEDに設定されている場合)。LogMinerでは、この新しい最大サイズがサポートされます。LogMinerでサポートされるデータ型の詳細は、「サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン」を参照してください。

非推奨となった機能

- データ・ポンプ・エクスポートのDATA_OPTIONS=XML_CLOBSパラメータは、非推奨になりました(Oracle Database 12cリリース1 (12.1)からはCLOBとして格納されるXMLTypeが非推奨になったため)。
XMLType表および列は、現在はバイナリXMLとして格納されます。

バイナリXML記憶域の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

サポート対象外機能

このドキュメントで以前に記述されていた機能の一部は、Oracle Database12cリリース1(12.1)ではサポートされません。サポートされなくなった機能の一覧は、『Oracle Databaseアップグレード・ガイド』を参照してください。

第I部 Oracle Data Pump

次の内容について説明します。

- Oracle Data Pumpの概要
データベース間でデータおよびメタデータを非常に高速に移動できるOracle Data Pumpテクノロジについて説明します。

- データ・ポンプ・エクスポート
Oracle Data Pump Exportユーティリティについて説明します。このユーティリティは、ダンプ・ファイル・セットと呼ばれる一連のオペレーティング・システム・ファイルに、データおよびメタデータをアンロードする場合に使用します。

- データ・ポンプ・インポート
エクスポート・ダンプ・ファイル・セットをターゲット・データベースにロードするために使用するOracle Data Pump Importユーティリティについて説明します。また、ファイルを介さずにソース・データベースから直接ターゲット・データベースにロードする、ネットワーク・インポートを実行する方法についての情報も提供されます。

- データ・ポンプのレガシー・モード
データ・ポンプのレガシー・モードについて説明します。このモードにより、オリジナルのエクスポート・パラメータおよびインポート・パラメータを、データ・ポンプ・エクスポートおよびデータ・ポンプ・インポートのコマンドラインで使用できるようになります。

- データ・ポンプ・ユーティリティのパフォーマンス
データ・ポンプ・エクスポート・ユーティリティおよびデータ・ポンプ・インポート・ユーティリティが、オリジナルのエクスポート・ユーティリティおよびインポート・ユーティリティよりもパフォーマンスに優れている理由、およびエクスポートおよびインポート操作のパフォーマンスを向上できる特定の手順について説明します。

- データ・ポンプAPI
データ・ポンプAPIのDBMS_DATAPUMPについて説明します。

1 Oracle Data Pumpの概要

Oracle Data Pumpテクノロジを使用すると、データおよびメタデータをデータベース間で非常に高速に移動できます。

次の項目を理解することは、Oracle Data Pumpを最大限に活用するために役立ちます。

- データ・ポンプのコンポーネント

- データ・ポンプによるデータの移動方法

- CDBでのデータ・ポンプの使用

- データ・ポンプ・エクスポートおよびデータ・ポンプ・インポートの操作に必要なロール

- データ・ポンプ・ジョブ実行中に行われる処理

- ジョブの状態の監視

- ファイルの割当て

- 異なるデータベース・リリース間のエクスポートとインポート

- SecureFiles LOBに関する考慮点

- データ・ポンプの終了コード

- データ・ポンプ・ジョブの監査

- データ・ポンプによるタイムスタンプ・データの処理方法

- キャラクタ・セットおよびグローバリゼーション・サポートに関する考慮点

データ・ポンプのコンポーネント

Oracle Data Pumpは、次の3つの要素で構成されています。

- コマンドライン・クライアントexpdpおよびimpdp

- PL/SQLパッケージDBMS_DATAPUMP(データ・ポンプAPIとも呼ばれます)

- PL/SQLパッケージDBMS_METADATA(メタデータAPIとも呼ばれます)

データ・ポンプ・クライアントであるexpdpおよびimpdpは、それぞれデータ・ポンプ・エクスポート・ユーティリティおよびデータ・ポンプ・インポート・ユーティリティを起動します。

expdpクライアントおよびimpdpクライアントでは、コマンドラインで入力されたパラメータを使用してエクスポートおよびインポートを実行するために、PL/SQLパッケージDBMS_DATAPUMPで提供されているプロシージャを使用します。これらのパラメータは、完全なデータベースまたはデータベースのサブセットに対するデータおよびメタデータをエクスポートおよびインポート可能にします。

メタデータを移動する場合、データ・ポンプでは、PL/SQLパッケージDBMS_METADATAで提供される機能が使用されます。DBMS_METADATAパッケージは、ディクショナリのメタデータの抽出、操作および再作成に関する集中的な機能を提供します。

DBMS_DATAPUMPおよびDBMS_METADATAの2つのPL/SQLパッケージは、データ・ポンプ・クライアントとは別に使用できます。

注意:

ダンプ・ファイルの読取りおよび書込みを含むすべてのデータ・ポンプ・エクスポートおよびデータ・ポンプ・インポートの処理は、指定したデータベース接続文字列によって選択されるシステム(サーバー)上で実行されます。つまり、ユーザーに権限がない場合は、データベース管理者(DBA)が、そのサーバーのファイル・システムで読取りおよび書込みが実行されるデータ・ポンプ・ファイル用のディレクトリ・オブジェクトを作成する必要があります。(セキュリティ上の理由から、承認されたユーザーのみが、ディレクトリ・オブジェクトにアクセスできるようにする必要があります。)特権ユーザーは、デフォルトのディレクトリ・オブジェクトを使用できます。ディレクトリ・オブジェクトの詳細は、「ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置」を参照してください。

関連項目:

- DBMS_DATAPUMPパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- DBMS_METADATAパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- ディレクトリ・オブジェクトの作成時に考慮するガイドラインの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

データ・ポンプによるデータの移動方法

データ・ポンプを使用してデータベースの中からまたはデータベースの中へデータを移動する方法、およびそれぞれの方法を使用する場合の詳細は、次の項目を参照してください。

- データ・ファイル・コピーを使用したデータ移動

- ダイレクト・パスを使用したデータ移動

- 外部表を使用したデータ移動

- 従来型パスを使用したデータ移動

- ネットワーク・リンク・インポートを使用したデータ移動

注意:

データ・ポンプでは、無効な一意索引を持つ表は、ロードされません。データを表にロードするには、その索引を削除するかまたは再度有効にする必要があります。

データ・ファイル・コピーを使用したデータ移動

最も高速なデータ移動の方法は、データベースのデータ・ファイルを、データの解析や変更を行わずに、ターゲット・データベースにコピーすることです。この方法では、データ・ポンプ・エクスポートを使用して、構造的な情報(メタデータ)のみをダンプ・ファイルにアンロードします。この方法は、次のような場合に使用します。

- トランスポータブル表領域のエクスポートの指定に、TRANSPORT_TABLESPACESパラメータが使用されている場合。指定した表領域のメタデータのみがエクスポートされます。

- 表モード・エクスポート(TABLESパラメータで指定)、全体モード・エクスポート(FULLパラメータで指定)、または全体モード・ネットワーク・インポート(FULLおよびNETWORK_LINKパラメータで指定)でTRANSPORTABLE=ALWAYSパラメータが指定されている場合。

エクスポート操作でデータ・ファイル・コピーが使用されている場合、対応するインポート・ジョブでも常にデータ・ファイル・コピーが使用されます。その後のインポート操作時に、データ・ファイルとエクスポート・ダンプ・ファイルの両方をロードする必要があります。

注意:

トランスポータブル・インポート中、表領域を一時的に読取り/書込み可能にしてから、読取り専用に戻します。これは、パフォーマンスを向上させるためにOracle Database 12cリリース1 (12.1.0.2)で導入された新しい動作です。ただし、この動作によって、インポート・ジョブのデータ・ファイルのSCNが変更されることを認識しておく必要があります。これによって、今後、これらのファイルのトランスポータブル・インポート中に問題が発生する可能性があります。

たとえば、表領域を読取りまたは書き込み可能にした後に、トランスポータブル表領域インポートが失敗した場合(読取り専用に戻した場合でも)、データ・ファイルは破損します。これらはリカバリできません。

トランスポータブル・ジョブは再起動できないので、失敗したジョブは最初から再起動する必要があります。破損したデータ・ファイルを削除し、破損していないバージョンをターゲットにコピーする必要があります。

トランスポータブル・ジョブを実行する場合、ベスト・プラクティスは、インポート・ジョブがターゲット・システムで正常に完了するまで、ソース・システムにデータ・ファイルのコピーを保持することです。インポート・ジョブがなんらかの理由で失敗しても、破損していないデータ・ファイルのコピーが残ります。

データ・ファイル・コピーを使用してデータを移動する場合、ソース・データベースとターゲット・データベース間のキャラクタ・セットの互換性に関する制限があります。詳細は、『Oracle Database管理者ガイド』を参照してください。

ソース・プラットフォームとターゲット・プラットフォームのエンディアンが異なる場合、転送するデータを変換してターゲット・プラットフォームの形式にする必要があります。DBMS_FILE_TRANSFER PL/SQLパッケージまたはRMAN CONVERTコマンドを使用してデータを変換できます。

関連項目:

- RMAN CONVERTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- データベース間で行う表領域の転送の詳細および例(データの変換方法を含む)は、『Oracle Database管理者ガイド』を参照してください。

ダイレクト・パスを使用したデータ移動

ダイレクト・パスは、データ・ファイル・コピーの次に高速なデータ移動方法です。この方法では、データベースのSQLレイヤーはバイパスされ、最小限の解析のみで行の移動がダンプ・ファイル間で行われます。データ・ポンプでは、データをロードおよびアンロードするために、表の構造上可能なかぎり、自動的にダイレクト・パスによる方法が使用されます。たとえば、表にBFILE型の列が含まれる場合は、ダイレクト・パスを使用して表をロードできないため、かわりに外部表が使用されます。

次の項では、ロードおよびアンロードに、ダイレクト・パスを使用できない場合について説明します。

- ダイレクト・パス・ロードが使用されない場合

- ダイレクト・パス・アンロードが使用されない場合

ダイレクト・パス・ロードが使用されない場合

表が次に示すいずれかの条件に該当する場合、データ・ポンプでは、その表へのデータのロードにダイレクト・パスではなく外部表が使用されます。

- CONTEXTタイプの索引ではないドメイン索引がLOB列に存在する。

- 単一パーティションのロード中に、複数パーティション表のグローバル索引が存在する。これには、パーティション化されたオブジェクト表も含まれる。

- クラスタ内に表が存在する。

- 既存の表にアクティブなトリガーが存在する。

- 既存の表で、ファイングレイン・アクセス・コントロールが挿入モードで有効である。

- 表にBFILE列または不透明な型の列が存在する。

- 既存の表に参照整合性制約が存在する。

- 表に不透明な型が埋め込まれたVARRAY列が存在する。

- 表に暗号化された列がある。

- データのインポート先が既存の表であり、次に示す1つ以上の条件に該当する。

- アクティブなトリガーが存在する。

- 表がパーティション化されている。

- ファイングレイン・アクセス・コントロールが挿入モードである。

- 参照整合性制約が存在する。

- 一意索引が存在する。

- サプリメンタル・ロギングが有効で、表に1つ以上のLOB列がある。

- 指定した表のデータ・ポンプ・コマンドが、QUERY、SAMPLEまたはREMAP_DATAパラメータを使用している。

- 表にTIMESTAMP WITH TIME ZONEデータ型を持つ列(VARRAY列を含む)が含まれていて、タイムゾーン・データ・ファイルのバージョンがエクスポート・システムとインポート・システム間で異なる。

ダイレクト・パス・アンロードが使用されない場合

表が次に示すいずれかの条件に該当する場合、データ・ポンプでは、その表へのデータのアンロードにダイレクト・パスではなく外部表が使用されます。

- SELECTに対するファイングレイン・アクセス・コントロールが有効である。

- 表は、キュー表である。

- 表に1つまたは複数のBFILE型または不透明な型の列、あるいは不透明な列を含むオブジェクト型が存在する。

- 表に暗号化された列がある。

- 表にアップグレードが必要な進化した型の列がある。

- 表に最新ではないLONG型またはLONG RAW型の列がある。

- 指定した表のデータ・ポンプ・コマンドが、QUERY、SAMPLEまたはREMAP_DATAパラメータを使用している。

- アンロード操作の前に、NOT NULLかつ指定されたデフォルト値を持つ列を含むように表が変更されている。

外部表を使用したデータ移動

データ・ファイル・コピーが選択されず、ダイレクト・パスでデータを移動できない場合、外部表によるメカニズムが使用されます。外部表によるメカニズムでは、データベース表のダンプ・ファイル・データにマップする外部表が作成されます。その後、SQLエンジンを使用してデータが移動されます。可能な場合は、インポート時にAPPENDヒントが使用されて、データベースへのデータのコピーが高速化されます。ダイレクト・パス・データと外部表データは、ダンプ・ファイル内で同様に表示されます。したがって、データ・ポンプでは、エクスポート時にはダイレクト・パスによるメカニズムが使用されても、ターゲット・データベースへのデータのインポート時には外部表が使用される場合があります。同様に、データ・ポンプでは、エクスポートに外部表、インポートにダイレクト・パスが使用される場合もあります。

特に、データ・ポンプでは、次のような場合に外部表が使用されます。

- パラレルSQL機能の使用がメリットとなる状況において、非常に大きい表およびパーティションをロードおよびアンロードする場合

- グローバル索引またはドメイン索引が定義されている表(パーティション・オブジェクト表など)をロードする場合

- トリガーがアクティブになっている表またはクラスタ表をロードする場合

- 暗号化された列が含まれている表をロードおよびアンロードする場合

- ファイングレイン・アクセス・コントロールでの挿入が使用可能な表をロードする場合

- ロード時およびアンロード時に別の方法でパーティション化される表をロードする場合

- インポート操作以外で作成された表をロードする場合(インポートを開始する前から表が存在する)

注意:

データ・ポンプがデータ・アクセスに外部表を使用する場合は、ORACLE_DATAPUMPアクセス・ドライバが使用されます。ただし、外部表を使用する際にデータ・ポンプで作成されるファイルは、ユーザーがSQL CREATE TABLE ... ORGANIZATION EXTERNAL文を使用して外部表を手動で作成する際に作成されるファイルとは互換性がないことに注意してください。

関連項目:

- ORACLE_DATAPUMPアクセス・ドライバ

- APPENDヒントの使用方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

従来型パスを使用したデータ移動

表属性の競合が存在する場合、データ・ポンプは、ダイレクト・パスと外部表のいずれの方法でも表にデータをロードできません。このような場合は従来型パスが使用されますが、パフォーマンスに影響する可能性があります。

ネットワーク・リンク・インポートを使用したデータ移動

インポート操作のネットワーク・リンクの指定にNETWORK_LINKインポート・パラメータが使用されている場合、SQLが使用され、INSERT SELECT文によりデータが移動されます。SELECT句は、ネットワーク・リンク上のリモート・データベースからデータを取得します。INSERT句はSQLを使用してデータをターゲット・データベースに挿入します。ダンプ・ファイルは含まれません。

エクスポート操作のネットワーク・リンクの指定にNETWORK_LINKエクスポート・パラメータが使用されている場合、リモート・データベースのデータがターゲット・データベースのダンプ・ファイルに書き込まれます。(読取り専用のデータベースからのエクスポートには、NETWORK_LINKパラメータが必要です。)

リンクとは、ネットワーク接続されたリモートのデータベースを示すため、データベース・リンクおよびネットワーク・リンクという用語は、同じ意味で使用されます。

サポートされているリンク・タイプ

データ・ポンプ・エクスポートおよびデータ・ポンプ・インポートでは、次のタイプのデータベース・リンクの使用がサポートされています。

- パブリック固定ユーザー

- パブリック接続ユーザー

- パブリック共有ユーザー(リンク所有者が使用する場合のみ)

- プライベート共有ユーザー(リンク所有者が使用する場合のみ)

- プライベート固定ユーザー(リンク所有者が使用する場合のみ)

サポートされていないリンク・タイプ

データ・ポンプ・エクスポートおよびデータ・ポンプ・インポートでは、次のタイプのデータベース・リンクの使用はサポートされません。

- プライベート接続ユーザー

- 現行ユーザー

関連項目:

- データベース・リンクを介したエクスポートの実行の詳細は、エクスポートの「NETWORK_LINK」パラメータを参照してください。

- データベース・リンクを介したインポートの実行の詳細は、インポートの「NETWORK_LINK」パラメータを参照してください。

- データベース・リンクおよび異なるタイプのリンクを作成する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

CDBでのデータ・ポンプの使用

マルチテナント・コンテナ・データベース(CDB)は、0、1または多数のユーザー作成のプラガブル・データベース(PDB)を含むOracleのデータベースです。PDBは、スキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトのポータブル・セットで、Oracle Netクライアントからは、非CDBとして表示されます。非CDBとは、CDBではないOracle Databaseです。

データ・ポンプを使用すると、データベースの全部または一部の非CDBからPDBへの移行、同じかまたは異なるCDB内のPDB間での移行、PDBから非CDBへの移行が可能です。一般的に、PDBでデータ・ポンプを使用することは、非CDBでデータ・ポンプを使用することと同じです。

注意:

Oracle Database 12cリリース1 (12.1)のデータ・ポンプでは、CDB全体の操作はサポートされません。CDBのルートまたはシード・データベースに接続すると、データ・ポンプによって次の警告が発行されます。

ORA-39357: WARNING: Oracle Data Pump operations are not typically needed when connected to the root or seed of a container database.

データ・ポンプを使用したCDBへのデータベースの移動

CDBに空のPDBを作成した後、Oracle Data Pumpの全体モード・エクスポートおよびインポート操作を使用して、データをPDBに移動できます。このジョブは、トランスポータブル・オプションを指定しても指定しなくても実行できます。トランスポータブル・オプションを全体モード・エクスポートまたはインポートで使用する場合、全体トランスポータブル・エクスポート/インポートと呼ばれます。

トランスポータブル・オプションが使用される場合、エクスポートおよびインポートでは、トランスポータブル表領域のデータ移動と従来のデータ移動の両方を使用しますが、後者はSYSTEMやSYSAUXなどの非トランスポータブル表領域に存在する表が対象です。トランスポータブル・オプションを使用すると、表データをアンロードおよび再ロードする必要と、ユーザー表領域の索引構造を再作成する必要がなくなるため、エクスポート時間と(特に)インポート時間を短縮できます。

エクスポート/インポート操作に対して特定のPDBを指定する場合、データ・ポンプ・コマンドラインで、データ・ポンプの開始時に接続文字列に接続識別子を指定します。たとえば、pdb1というPDBにデータをインポートするには、データ・ポンプ・コマンドラインで次のように入力します。

impdp hr@pdb1 DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp TABLES=employees

データ・ポンプを使用してCDBにデータを移動する場合、次の要件に注意してください。

- マルチテナント環境を管理するには、CDB_DBAロールを持っている必要があります。

- Oracle Database 11.2.0.2以前からの全体データベース・エクスポートは、Oracle Database 12c (CDBまたは非CDB)にインポートされる場合があります。ただし、登録したオプションおよびコンポーネントの情報がエクスポートに含まれるように、まずソース・データベースをOracle Databasegリリース2 (11.2.0.3以上)にアップグレードすることをお薦めします。

- 全体データベース・エクスポートまたは全体トランスポータブル・データベース・エクスポートのいずれかを使用して、Oracle Database 11gリリース2 (11.2.0.3以上)をCDB(または非CDB)に移行する場合、Oracle Database 12cにインポートできるダンプ・ファイルを生成するためにデータ・ポンプ・エクスポート・パラメータVERSION=12を設定する必要があります。VERSION=12を設定しない場合、生成したエクスポート・ファイルには、登録したデータベース・オプションおよびコンポーネントの完全な情報は含まれません。

- ネットワーク・ベースの全体トランスポータブル・インポートでは、FULL=YES、TRANSPORTABLE=ALWAYSおよびTRANSPORT_DATAFILES=datafile_nameパラメータを使用する必要があります。ソース・データベースがOracle Database 11gリリース11.2.0.3以上で、Oracle Database 12cリリース1 (12.1)より前の場合、VERSION=12パラメータも必要です。

- ファイル・ベースの全体トランスポータブル・インポートでは、TRANSPORT_DATAFILES=datafile_nameパラメータのみを使用する必要があります。データ・ポンプ・インポートでは、TRANSPORTABLE=ALWAYSおよびFULL=YESパラメータが使用されるはずです。

- デフォルトのデータ・ポンプ・ディレクトリ・オブジェクトのDATA_PUMP_DIRは、PDBでは使用できません。エクスポートまたはインポートするPDB内に明示的なディレクトリ・オブジェクトを定義する必要があります。

データ・ポンプの使用によるCDB内または間のPDBの移動

PDBに対するデータ・ポンプ・エクスポートおよびインポート操作は、共通ユーザーの処理方法を除き、非CDBに対する操作と同じです。CDBで共通ユーザーを作成した場合、CDBのPDB内からそのユーザーの全データベースまたは特権スキーマをエクスポートすると、標準のCREATE USER C##common name DDL文がインポート時に実行されます。ユーザー名の共通ユーザー接頭辞C##が原因で、文は失敗します。次のエラー・メッセージが返されます。

ORA-65094:invalid local user or role name

エクスポート対象のPDBで、そのユーザーのスキーマにローカル・オブジェクトを作成してそれらをインポートする場合、同じ名前の共通ユーザーがすでにターゲットCDBインスタンスに存在することを確認するか、次のようにimpdpコマンドでデータ・ポンプ・インポートのREMAP_SCHEMAパラメータを使用します。

REMAP_SCHEMA=C##common name:local user name

関連項目:

- CDBの詳細は、『Oracle Database概要』を参照してください。

- データ・ポンプを使用して非CDBをCDBに移動する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CDBおよびPDBの権限およびロールの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- 「全体モード・エクスポート時のトランスポータブル・オプションの使用」

- 「全体モード・インポート時のトランスポータブル・オプションの使用」

- コマンドラインで接続識別子を指定する方法の詳細は、「ネットワークに関する考慮点」を参照してください

データ・ポンプ・エクスポートおよびデータ・ポンプ・インポートの操作に必要なロール

データ・ポンプの多くのエクスポートおよびインポート操作では、DATAPUMP_EXP_FULL_DATABASEロールまたはDATAPUMP_IMP_FULL_DATABASEロール(あるいはその両方)をユーザーが持っている必要があります。 これらのロールは、データベース作成の一環として標準スクリプトを実行すると、自動的にOracle Database用に定義されます。(これらのロールの名前にはFULLという語が含まれますが、これらのロールは、実際には全体モードのみではなく、任意のエクスポートまたはインポート・モードのすべての特権操作に適用されることに注意してください。)

DATAPUMP_EXP_FULL_DATABASEロールはエクスポート操作にのみ影響します。DATAPUMP_IMP_FULL_DATABASEロールは、インポート操作と、SQLFILEインポート・パラメータを使用する操作に影響します。これらのロールによって、ユーザーは次の処理を行うエクスポートおよびインポート操作を実行できます。

- 自分のスキーマ・スコープ以外での操作の実行

- 他のユーザーが開始したジョブの監視

- 権限のないユーザーが参照できないオブジェクトのエクスポート(表領域定義など)とインポート(ディレクトリ定義など)

これらは強力なロールです。これらのロールをユーザーに付与する際は、十分に注意する必要があります。

SYSスキーマには、これらのいずれのロールも割り当てられていません。ただし、データ・ポンプが実行するセキュリティ・チェックの中でこれらのロールを必要とするものについては、SYSスキーマにアクセス権が付与されます。

注意:

ORA-39181: Only Partial Data Exported Due to Fine Grain Access Controlというエラー・メッセージが表示される場合は、http://support.oracle.comで、My Oracle Supportノート422480.1の有効ファイングレイン・アクセス・コントロール・ポリシーを持つ表データのエクスポート時のセキュリティに関する情報を参照してください。

関連項目:

Oracle Databaseのインストールで事前定義されるロールの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

データ・ポンプ・ジョブ実行中に行われる処理

データ・ポンプ・ジョブでは、マスター表、マスター・プロセス、ワーカー・プロセスを使用して、処理が実行され、進捗状況が追跡されます。

ジョブの調整

すべてのデータ・ポンプ・エクスポート・ジョブおよびデータ・ポンプ・インポート・ジョブに対して、マスター・プロセスが作成されます。マスター・プロセスによって、ジョブ全体(クライアントとの通信、ワーカー・プロセス・プールの作成および制御、ロギング操作の実行など)が制御されます。

ジョブ内での進捗状況の追跡

データおよびメタデータの転送中、ジョブ内の進捗状況の追跡にマスター表が使用されます。マスター表は、ユーザー表としてデータベース内に実装されます。また、エクスポート・ジョブおよびインポート・ジョブ用のマスター表固有の機能は、次のとおりです。

- エクスポート・ジョブの場合、マスター表には、ダンプ・ファイル・セット内のデータベース・オブジェクトの位置が記録されます。エクスポート・ユーティリティでは、ジョブの継続中に、マスター表の作成およびメンテナンスが行われます。エクスポート・ジョブ終了時に、マスター表の内容がダンプ・ファイル・セット内のファイルに書き込まれます。

- インポート・ジョブの場合、マスター表は、ダンプ・ファイル・セットからロードされ、ターゲット・データベースにインポートする必要があるオブジェクトの位置を特定する操作の順序の制御に使用されます。

マスター表は、エクスポートまたはインポート操作を実行している現在のユーザーのスキーマ内に作成されます。そのため、このユーザーには、CREATE TABLEシステム権限およびマスター表を作成するための十分な表領域の割当て制限が必要です。マスター表の名前は、その表を作成したジョブと同じ名前になります。したがって、データ・ポンプ・ジョブに、既存の表またはビューと同じ名前を明示的には指定できません。

すべての操作で、ジョブの再起動にマスター表の情報が使用されます。(トランスポータブル・ジョブは再開できないことに注意してください。)

マスター表は、状況に応じて、次のとおり保持または削除されます。

- ジョブが正常に終了すると、マスター表は削除されます。これを上書きするには、ジョブに対してデータ・ポンプのKEEP_MASTER=YESパラメータを設定します。

- ジョブが正常に完了しなかった場合、マスター表は自動的に保持されます。

- 対話方式コマンドSTOP_JOBを使用してジョブを停止すると、ジョブの再起動に使用できるようにマスター表は保持されます。

- 対話方式コマンドKILL_JOBを使用してジョブを中断すると、マスター表は削除され、ジョブを再起動できません。

- ジョブが突然終了した場合でも、マスター表は保持されます。このジョブを再起動しない場合、マスター表を削除できます。

- ジョブが実行を開始する前(つまり、データベース・オブジェクトがコピーされる前)に停止すると、マスター表は削除されます。

関連項目:

ジョブ名の形式の詳細は、「JOB_NAME」を参照してください

ジョブ実行中のデータおよびメタデータのフィルタ処理

マスター表内では、名前や自分のスキーマなどの属性が特定のオブジェクトに割り当てられます。オブジェクトは、オブジェクトのクラス(TABLE、INDEX、DIRECTORYなど)にも属します。オブジェクトのクラスは、オブジェクトのオブジェクト型と呼ばれます。EXCLUDEおよびINCLUDEパラメータを使用して、エクスポートまたはインポートされるオブジェクト型を制限できます。オブジェクトの名前またはオブジェクトを自分のスキーマの名前に基づいて、制限するオブジェクトを指定できます。データ固有のフィルタを指定して、エクスポートおよびインポートする行を制限することもできます。

関連項目:

- 「エクスポート操作中のフィルタ処理」

- 「インポート操作中のフィルタ処理」

ジョブ実行中のメタデータの変換

データベース間でデータを移動する場合は、表領域間で記憶域を再マップしたり、特定のオブジェクトの所有者を再定義するために、メタデータの変換を実行すると有効です。これは、データ・ポンプ・インポート・パラメータのREMAP_DATAFILE、REMAP_SCHEMA、REMAP_TABLE、REMAP_TABLESPACE、TRANSFORMおよびPARTITION_OPTIONSを使用して実行されます。

ジョブ・パフォーマンスの最大化

データ・ポンプでは、複数のワーカー・プロセスを採用し、それらをパラレルに実行して、ジョブのパフォーマンスを向上させることができます。PARALLELパラメータを使用して、現状の環境で最大限の効果を得る並列度を設定します。たとえば、本番システムへのジョブの影響を制限する場合、データベース管理者(DBA)は並列度を制限する必要があります。並列度は、ジョブの実行中いつでも再設定できます。たとえば、運用時間中は特定のジョブの並列度が2に制限されるようにPARALLELを2に設定し、非運用時間中は8に再設定することができます。並列度の設定は、マスター・プロセスによって施行され、マスター・プロセスによって、1回の操作でデータおよびメタデータの処理を実行するワーカー・プロセスに、実行対象の処理が割り当てられます。これらのワーカー・プロセスは、パラレルで動作します。並列度を設定する場合の推奨事項は、エクスポートのPARALLELおよびインポートのPARALLELパラメータの説明を参照してください。

注意:

並列度を調整する機能は、Oracle DatabaseのEnterprise Editionでのみ使用可能です。

関連項目:

- 「Oracle RAC環境でのエクスポートにおけるPARALLELの使用」

- 「Oracle RAC環境でのインポートにおけるPARALLELの使用」

データのロードおよびアンロード

ワーカー・プロセスによって、メタデータおよび表データがアンロードおよびロードされます。また、インポート中には、これらによって索引が再作成されます。これらの操作の一部(表データのアンロードおよびロード、索引の再作成およびパッケージ本体のロード)は、パラレルに実行できます。他のすべての操作は逐次実行されます。ワーカー・プロセスは、コマンドライン・パラメータPARALLELに指定した値と同数になるまで必要に応じて作成されます。アクティブなワーカー・プロセスの数は、ジョブの存続期間中いつでも再設定できます。ワーカー・プロセスは、Oracle Real Application Clusters(Oracle RAC)環境内の様々なノードで起動できます。

注意:

Oracle DatabaseのStandard Editionでは、PARALLELの値は1に制限されています。

非常に大きい表またはパーティションをロードまたはアンロードするタスクがワーカー・プロセスに割り当てられた場合、パラレル実行を最大限に利用できるように、外部表によるアクセス方法が使用されることがあります。その場合、ワーカー・プロセスはパラレル実行コーディネータになります。実際のロードおよびアンロード処理は、Oracle RAC環境内の使用可能なプロセスのプールから割り当てられたパラレルI/Oの実行プロセス(スレーブとも呼ばれる)間で分割されます。

関連項目:

- エクスポートの「PARALLEL」パラメータ

- インポートの「PARALLEL」パラメータ

ジョブの状態の監視

データ・ポンプ・エクスポートおよびインポート・クライアント・ユーティリティでは、ロギング・モードまたは対話方式コマンド・モードのいずれでも、ジョブに接続できます。

ロギング・モードでは、ジョブの実行中に、そのジョブの詳細な状態がリアルタイムで自動的に表示されます。表示される情報には、ジョブおよびパラメータの説明、処理されるデータ量の推定、現在の操作または処理中のアイテムの説明、ジョブで使用されるファイル、発生したエラーおよび最終的なジョブの状態(停止または完了)があります。

対話方式コマンド・モードでは、ジョブの状態をリクエストに表示できます。表示される情報には、ジョブの説明および状態、現在の操作または処理中のアイテムの説明、書込み中のファイルおよび累積的な状態があります。

オプションで、ジョブの実行中にログ・ファイルの書込みを行うこともできます。ログ・ファイルには、ジョブの進捗状況のサマリーが記録され、ジョブの実行中に発生したエラーがリストされます。また、ジョブの完了状態も記録されます。

ジョブの状態を判断したり、データ・ポンプ・ジョブについての情報を表示するには、DBA_DATAPUMP_JOBSビュー、USER_DATAPUMP_JOBSビューまたはDBA_DATAPUMP_SESSIONSビューを問い合せる方法もあります。これらのビューの説明は、『Oracle Databaseリファレンス』を参照してください。

関連項目:

- コマンドライン・エクスポートでの状態表示の頻度を変更する方法については、エクスポートの「STATUS」パラメータを参照してください。

- コマンドライン・インポートでの状態表示の頻度を変更する方法については、インポートの「STATUS」パラメータを参照してください。

- 対話方式の「STATUS」エクスポート・コマンド

- 対話方式のインポートの「STATUS」コマンド

- エクスポート・ログ・ファイルのファイル指定を設定する方法については、エクスポートの「LOGFILE」パラメータを参照してください。

- インポート・ログ・ファイルのファイル指定を設定する方法については、インポートの「LOGFILE」パラメータを参照してください。

ジョブの実行状況の監視

表データの転送を行うデータ・ポンプ操作(エクスポートおよびインポート)では、ジョブの進捗状況(単位は、転送された表データのメガバイト数)を示す動的パフォーマンス・ビューV$SESSION_LONGOPSのエントリが保持されます。このエントリは、転送の推定サイズを含み、実際に転送されたデータの量が反映されるように定期的に更新されます。

パラメータCOMPRESSION、ENCRYPTION、ENCRYPTION_ALGORITHM、ENCRYPTION_MODE、ENCRYPTION_PASSWORD、QUERYおよびREMAP_DATAを使用しても、推定値の決定には反映されません。

エクスポート操作の推定値が有効かどうかは、操作開始時に要求された推定のタイプによって異なります。この値は、実際の転送量を超えた場合に必要に応じて更新されます。インポート操作の推定値は、厳密な値です。

データ・ポンプ・ジョブに関連するV$SESSION_LONGOPS列は、次のとおりです。

- USERNAME: ジョブの所有者

- OPNAME: ジョブ名

- TARGET_DESC: ジョブ操作

- SOFAR: ジョブ実行中に転送されたメガバイト数

- TOTALWORK: ジョブ内の推定メガバイト数

- UNITS: メガバイト(MB)

- MESSAGE: 状態メッセージ。次の形式で表示されます。

'job_name: operation_name : nnn out of mmm MB done'

ファイルの割当て

データ・ポンプ・ジョブは、次のタイプのファイルを管理します。

- 移動中のデータおよびメタデータを格納するダンプ・ファイル。

- 操作に関連したメッセージを記録するログ・ファイル。

- SQLFILE操作の出力を記録するSQLファイル。SQLFILE操作は、データ・ポンプ・インポートのSQLFILEパラメータを使用して起動され、他のパラメータに基づいてImportが実行されるSQL DDLとして、SQLファイルに書き込まれます。

- トランスポータブル・インポート中にDATA_FILESパラメータにより指定されるファイル

データ・ポンプでのこれらのファイルの割当て方法および処理方法を理解すると、エクスポート・ユーティリティおよびインポート・ユーティリティを最大限に利用できます。

注意:

データ・ポンプ・ジョブによってネットワーク・ファイル・ストレージ(NFS)関連のエラーが生成される場合、使用しているプラットフォームのインストレーション・ガイドを参照して適切なNFSマウント設定を決定してください。

ファイルの指定およびダンプ・ファイルの追加

エクスポート操作の場合、ダンプ・ファイルは、ジョブの定義時およびエクスポート操作の後の段階で指定できます。たとえば、エクスポート操作中に領域が不足した場合は、データ・ポンプ・エクスポート・ユーティリティのADD_FILEコマンドを対話方式モードで使用して、追加ダンプ・ファイルを追加できます。

インポート操作の場合、ジョブの定義時にすべてのダンプ・ファイルを指定する必要があります。

既存のファイルは、ログ・ファイルおよびSQLファイルによって上書きされます。ダンプ・ファイルの場合は、REUSE_DUMPFILESエクスポート・パラメータを使用して、既存のダンプ・ファイルを上書きするかどうかを指定できます。

ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置

データ・ポンプは、クライアント・ベースではなく、サーバー・ベースであるため、ダンプ・ファイル、ログ・ファイルおよびSQLファイルには、サーバー・ベースのディレクトリ・パスを基準としてアクセスします。データ・ポンプでは、ディレクトリ・パスをディレクトリ・オブジェクトとして指定する必要があります。ディレクトリ・オブジェクトは、ファイル・システムのディレクトリ・パスに名前をマップします。DBAは、承認されたユーザーのみが、ディレクトリ・パスに関連付けられたディレクトリ・オブジェクトにアクセスできるようにする必要があります。

次の例は、/usr/apps/datafilesにあるディレクトリにマップされるdpump_dir1というディレクトリ・オブジェクトを作成するSQL文を示しています。

SQL> CREATE DIRECTORY dpump_dir1 AS '/usr/apps/datafiles';

ディレクトリ・オブジェクトは、データのセキュリティおよび整合性を確保するために必要です。次に例を示します。

- 入力ファイルのディレクトリ・パスの位置を指定する権限を付与された場合、ユーザーは、サーバーにはアクセス権があるが、ユーザー自身はアクセス権を持たないデータの読取りを実行できる場合があります。

- 出力ファイルのディレクトリ・パスの位置を指定する権限を付与された場合、通常、ユーザーが削除権限を持たないファイルが、サーバーによって上書きされる場合があります。

UNIXおよびWindowsオペレーティング・システムの場合、デフォルトのディレクトリ・オブジェクトDATA_PUMP_DIRは、データベースが作成されるとき、またはデータベース・ディレクトリがアップグレードされるたびに作成されます。デフォルトでは、特権ユーザーのみが使用できます。(ユーザーSYSTEMは、デフォルトでDATA_PUMP_DIRディレクトリへの読取りおよび書込みアクセス権を持っています。)

権限のないユーザーの場合、データ・ポンプ・エクスポートまたはデータ・ポンプ・インポートを実行できるようにするには、データベース管理者(DBA)またはCREATE ANY DIRECTORY権限を持つユーザーがディレクトリ・オブジェクトを作成する必要があります。

ディレクトリの作成後、ディレクトリ・オブジェクトを作成するユーザーは、そのディレクトリに対するREAD権限またはWRITE権限を他のユーザーに付与する必要があります。たとえば、dpump_dir1で指定されたディレクトリのユーザーhrのかわりに、Oracle Databaseがファイルを読取りまたは書込みできるようにするには、DBAが次のコマンドを実行する必要があります。

SQL> GRANT READ, WRITE ON DIRECTORY dpump_dir1 TO hr;

ディレクトリ・オブジェクトに対するREAD権限またはWRITE権限は、Oracle Databaseによって対応するディレクトリにあるファイルの読取りまたは書込みのみを実行できることを意味します。適切なオペレーティング・システム権限がないかぎり、Oracle Databaseの外部にあるファイルには直接アクセスできません。同様に、Oracle Databaseには、ディレクトリのファイルに対して読取りおよび書込みを行うオペレーティング・システム権限が必要です。

データ・ポンプ・エクスポートおよびインポート・ユーティリティでは、次の順序でファイルの位置が判断されます。

1. ディレクトリ・オブジェクトがファイル指定の一部として指定されている場合は、そのディレクトリ・オブジェクトで指定された位置が使用されます。(ディレクトリ・オブジェクトとファイル名は、コロンで区切る必要があります。)

2. ディレクトリ・オブジェクトがファイル指定の一部として指定されていない場合は、DIRECTORYパラメータで指定されたディレクトリ・オブジェクトが使用されます。

3. ディレクトリ・オブジェクトがファイル指定の一部として指定されていない場合、およびDIRECTORYパラメータでディレクトリ・オブジェクトが指定されていない場合は、環境変数DATA_PUMP_DIRの値が使用されます。この環境変数は、データ・ポンプ・エクスポートおよびインポート・ユーティリティが実行されるクライアント・システムで、オペレーティング・システム・コマンドを使用して定義されます。このクライアント・ベースの環境変数には、DBAがサーバー・システムで最初に作成するサーバー・ベースのディレクトリ・オブジェクトの名前を割り当てる必要があります。たとえば、次のSQL文では、サーバー・システムにディレクトリ・オブジェクトが作成されます。このディレクトリ・オブジェクトの名前はDUMP_FILES1で、位置は '/usr/apps/dumpfiles1'です。

SQL> CREATE DIRECTORY DUMP_FILES1 AS '/usr/apps/dumpfiles1';

cshを使用しているUNIXベースのクライアント・システムのユーザーは、環境変数DATA_PUMP_DIRに、値DUMP_FILES1を割り当てることができます。コマンドラインでは、DIRECTORYパラメータは省略できます。ダンプ・ファイルemployees.dmpおよびログ・ファイル export.logは、'/usr/apps/dumpfiles1'に書き込まれます。

%setenv DATA_PUMP_DIR DUMP_FILES1
%expdp hr TABLES=employees DUMPFILE=employees.dmp

4. 前述の3つの条件では、ディレクトリ・オブジェクトの位置を判断できない場合、特権ユーザーであれば、データ・ポンプはデフォルトのサーバー・ベースのディレクトリ・オブジェクトDATA_PUMP_DIRの値を試行します。このディレクトリ・オブジェクトは、データベースが作成されるとき、またはデータベース・ディレクトリがアップグレードされるたびに自動的に作成されます。DATA_PUMP_DIRのパス定義は、次のSQL問合せを使用して確認できます。

SQL> SELECT directory_name, directory_path FROM dba_directories
2 WHERE directory_name='DATA_PUMP_DIR';

特権ユーザーでない場合は、DATA_PUMP_DIRディレクトリ・オブジェクトへのアクセス権限が、DBAによって事前に付与されている必要があります。

デフォルトのDATA_PUMP_DIRディレクトリ・オブジェクトと、同じ名前のクライアント・ベースの環境変数とを混同しないでください。

Oracle RACに関する考慮点

Oracle RAC環境で操作を実行する場合は、次の考慮点に注意してください。

- Oracle RAC構成でデータ・ポンプまたは外部表を使用するには、ディレクトリ・オブジェクトのパスがクラスタ・ファイル・システム上に存在するようにする必要があります。
ディレクトリ・オブジェクトは、データ・ポンプまたは外部表プロセス(あるいはその両方)を実行できるすべてのインスタンスから参照およびアクセス可能な共有物理記憶域を指している必要があります。

- デフォルトのデータ・ポンプの動作では、Oracle RAC構成内の任意のインスタンスでワーカー・プロセスを実行できます。したがって、このようなOracle RACインスタンス上のワーカーは、ディレクトリ・オブジェクトによって定義された場所(共有ストレージ・メディアなど)に物理的にアクセスできる必要があります。この目的で使用できる共有ストレージが構成内にない場合にも並列処理が必要であれば、CLUSTER=NOパラメータを使用して、すべてのワーカー・プロセスを、データ・ポンプ・ジョブが開始されたインスタンスのみに置くことができます。

- データ・ポンプは、パラレル問合せスレーブを使用して、データのロードおよびアンロードを実行する場合があります。Oracle RAC環境では、データ・ポンプはこれらのスレーブの実行場所を制御しません。また、データ・ポンプ・ジョブのCLUSTERおよびSERVICE_NAMEに指定された内容に関係なく、Oracle RAC内の他のインスタンスでスレーブが実行される場合があります。パラレル問合せ操作の制御は、データ・ポンプとは無関係です。パラレル問合せスレーブがデータ・ポンプ・ジョブの一部として他のインスタンスで実行される場合は、ダンプ・ファイル・セットの物理記憶域へのアクセスも必要になります。

Oracle Automatic Storage Managementを使用可能にした場合のディレクトリ・オブジェクトの使用方法

Oracle Automatic Storage Management (Oracle ASM)を使用可能にしてデータ・ポンプ・エクスポート・ユーティリティまたはインポート・ユーティリティを使用する場合は、オペレーティング・システムのディレクトリ・パスではなくOracle ASMディスク・グループ名が使用されるように、ダンプ・ファイルで使用されるディレクトリ・オブジェクトを定義する必要があります。オペレーティング・システムのディレクトリ・パスを示す、別のディレクトリ・オブジェクトがログ・ファイルに使用される必要があります。たとえば、Oracle ASMダンプ・ファイルのディレクトリ・オブジェクトは、次のように作成します。

SQL> CREATE or REPLACE DIRECTORY dpump_dir as '+DATAFILES/';

ログ・ファイル用の個別のディレクトリ・オブジェクトは、次のように作成します。

SQL> CREATE or REPLACE DIRECTORY dpump_log as '/homedir/user1/';

ユーザーhrに、これらのディレクトリ・オブジェクトに対するアクセス権を付与する場合は、次に示すように、必要な権限を割り当てます。

SQL> GRANT READ, WRITE ON DIRECTORY dpump_dir TO hr;
SQL> GRANT READ, WRITE ON DIRECTORY dpump_log TO hr;

この後に、次のデータ・ポンプ・エクスポート・ユーティリティのコマンドを使用します(パスワードを入力するように要求されます)。

> expdp hr DIRECTORY=dpump_dir DUMPFILE=hr.dmp LOGFILE=dpump_log:hr.log

注意:

データ・ポンプのダンプ・ファイルをASMとディスク・ディレクトリの間で単にコピーする場合には、DBMS_FILE_TRANSFER PL/SQLパッケージを使用できます。

関連項目:

- エクスポートの「DIRECTORY」パラメータ

- インポートの「DIRECTORY」パラメータ

- CREATE DIRECTORYコマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください

- Oracle ASMの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照

- DBMS_FILE_TRANSFER PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

DATA_PUMP_DIRディレクトリ・オブジェクトおよびプラガブル・データベース

デフォルトのデータ・ポンプ・ディレクトリ・オブジェクトのDATA_PUMP_DIRは、プラガブル・データベース(PDB)では使用できません。データ・ポンプを使用してエクスポートまたはインポートを行うPDB内に、明示的なディレクトリ・オブジェクトを定義する必要があります。

置換変数の使用

エクスポート操作で、特定のファイル名を指定するかわりに、または指定した上で、ファイル名に置換変数(%U)を使用してDUMPFILEパラメータで複数のダンプ・ファイルを指定できます。これは、ダンプ・ファイル・テンプレートと呼ばれます。新しいダンプ・ファイルは、01(%Uに対応)から02、03の順で、必要に応じて作成されます。PARALLELパラメータの現行の設定で指定されたすべてのプロセスをアクティブにできるように、十分な数のダンプ・ファイルが作成されます。FILESIZEパラメータで指定した最大サイズに達したためにダンプ・ファイルが一杯になると、ダンプ・ファイルはクローズされ、新しく生成された名前を持つ新しいダンプ・ファイルが、それにかわるファイルとして作成されます。

複数のダンプ・ファイル・テンプレートが提供されている場合、これらのテンプレートは、ラウンドロビン法によるダンプ・ファイルの生成に使用されます。たとえば、並列度6のジョブに、expa%U、expb%Uおよびexpc%Uがすべて指定された場合、expa01.dmp、expb01.dmp、expc01.dmp、expa02.dmp、expb02.dmpおよびexpc02.dmpが初期ダンプ・ファイルとして作成されます。

インポートおよびSQLFILE操作では、ダンプ・ファイル指定expa%U、expb%Uおよびexpc%Uを指定した場合、ダンプ・ファイルexpa01.dmp、expb01.dmpおよびexpc01.dmpをオープンすると操作が開始されます。マスター表は複数のダンプ・ファイルにまたがることができます。したがって、マスター表のすべての部分が検出されるまで、ダンプ・ファイルは、置換変数の増加および新しいファイル名(expa02.dmp、expb02.dmp、expc02.dmpなど)の検索を行うことによって、オープン状態を継続します。ダンプ・ファイルが存在しない場合は、エラーとなったダンプ・ファイル指定の置換変数の増加が中止されます。たとえば、expb01.dmpおよびexpb02.dmpは検出され、expb03.dmpは検出されなかった場合、expb%U指定を使用したファイルの検索は中止されます。マスター表全体が検出されると、その表を使用して、ダンプ・ファイル・セット内のすべてのダンプ・ファイルの位置が特定されているかどうかを確認できます。

異なるデータベース・リリース間のエクスポートとインポート

データ・ポンプを使用して、異なるリリースのデータベース・ソフトウェア間で全データベースまたは一部を移行できます。データ・ポンプ・エクスポートのVERSIONパラメータは、通常、この作業のために使用します。これにより、指定したバージョンと互換性のあるデータ・ポンプのダンプ・ファイル・セットが生成されます。

VERSIONのデフォルト値はCOMPATIBLEで、これは、エクスポートされたデータベース・オブジェクト定義がCOMPATIBLE初期化パラメータで指定されたリリースと互換性があることを示します。

アップグレードで、データ・ポンプ・ベースの移行のターゲット・リリースがソースより新しい場合、ソース・データベースのすべてのオブジェクトがターゲット・リリースと互換性があるため、通常は、VERSIONパラメータを指定する必要はありません。例外は、Oracle Database 11g (リリース11.2.0.3以降)全体をOracle Database 12cリリース1 (12.1.0.1)以降にインポートするための準備としてエクスポートする場合です。この場合、VERSION=12とFULL=YESを明示的に指定して、Oracle内部のコンポーネント・パラメータの完全セットを含めます。

ダウングレードで、データ・ポンプ・ベースの移行のターゲット・リリースがソースより古い場合、VERSIONパラメータを明示的に指定して、ターゲットと同じバージョンにする必要があります。例外として、ターゲット・リリース・バージョンがソース・システムのCOMPATIBLE初期化パラメータの値と同じである場合、VERSIONを指定する必要はありません。ただし、通常は、VERSIONパラメータが明示的に指定されていなければ、データ・ポンプ・インポートでは、現在のリリースよりも新しいOracleリリースで作成されたダンプ・ファイル・セットを読み取ることができません。

異なるデータベース・リリース間のエクスポートとインポートを行う場合、次の点を考慮する必要があります。

- データ・ポンプのエクスポートで、現在のデータベース・バージョンより古いデータベース・バージョンを指定すると、その古いバージョンのデータベースにインポート可能なダンプ・ファイル・セットが作成されます。たとえば、Oracle Database 12cリリース1 (12.1.0.2)を実行していて、エクスポートでVERSION=11.2を指定する場合、作成されるダンプ・ファイル・セットはOracle 11.2のデータベースにインポートできます。

注意:

Oracle Database 12cリリース1 (12.1.0.2)以降のみで有効なデータベース権限(たとえば、表、ビュー、マテリアライズド・ビューおよびシノニムに対するREAD権限)はOracle Database 12cリリース1 (12.1.0.1)以降にインポートできません。これを実行しようとすると、エラーとして報告され、インポート操作が続行されます。

- 現在のデータベース・バージョンより古いデータベース・バージョンを指定する場合は、特定の機能を使用できないことがあります。たとえば、VERSION=10.1を指定した場合に、ジョブに対してデータ圧縮も指定してあるとエラーが発生します。これは、Oracle Database 10gリリース1(10.1)では圧縮がサポートされていないためです。

- データ・ポンプ・インポートは、常に、古いリリースのデータベースで作成されたデータ・ポンプのダンプ・ファイル・セットを読み込むことができます。

- データ・ポンプ操作がネットワーク・リンクを介して行われる場合、ソース・データベースとターゲット・データベースのバージョンの差違が2バージョン以下である必要があります。たとえば、一方のデータベースがOracle Database 12cの場合、他方のデータベースは12c、11gまたは10gである必要があります。データ・ポンプがチェックするのはメジャー・バージョン番号のみ(10g、11g、12cなど)で、具体的なリリース番号(12.1、10.1、10.2、11.1、11.2など)ではありません。

関連項目:

- エクスポートの「VERSION」パラメータ

- インポートの「VERSION」パラメータ

- READおよびREAD ANY TABLE権限の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください

SecureFiles LOBに関する考慮点

データ・ポンプ・エクスポートを使用してSecureFiles LOBをエクスポートした場合の結果の動作は、エクスポートのVERSIONパラメータの値、ContentTypeが存在するかどうか、LOBがアーカイブされてデータがキャッシュされるかどうかなどの条件によって異なります。次の例に、これらの変数の様々な組合せを示します。

- 表に、ContentTypeが存在するSecureFiles LOBが含まれていて、エクスポート・ユーティリティのVERSIONパラメータが11.2.0.0.0未満の値に設定されていると、ContentTypeはエクスポートされません。

- 表に、ContentTypeが存在するSecureFiles LOBが含まれていて、エクスポート・ユーティリティのVERSIONパラメータが11.2.0.0.0以上の値に設定されていると、ContentTypeがエクスポートされて、その後のインポートでリストアされます。

- 表に、現在アーカイブされているSecureFiles LOBが含まれていて、データがキャッシュされ、エクスポート・ユーティリティのVERSIONパラメータが11.2.0.0.0未満の値に設定されていると、SecureFiles LOBデータがエクスポートされて、アーカイブ・メタデータが削除されます。この例では、VERSIONが11.1以上に設定されていると、SecureFiles LOBは、標準のSecureFiles LOBになります。ただし、VERSIONが11.1未満の値に設定されていると、SecureFiles LOBはBasicFiles LOBになります。

- 表に、現在アーカイブされているSecureFiles LOBが含まれていて、データがキャッシュされず、エクスポート・ユーティリティのVERSIONパラメータが11.2.0.0.0未満の値に設定されていると、ORA-45001エラーが返されます。

- 表に、現在アーカイブされているSecureFiles LOBが含まれていて、データがキャッシュされ、エクスポート・ユーティリティのVERSIONパラメータが11.2.0.0.0以上の値に設定されていると、キャッシュされたデータとアーカイブ・メタデータの両方がエクスポートされます。

関連項目:

SecureFilesの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

データ・ポンプの終了コード

Oracle Data Pumpでは、完了してすぐにエクスポートおよびインポート操作の結果が提供されます。データ・ポンプでは、結果をログ・ファイルに記録するだけでなく、プロセス終了コードで結果をレポートすることもできます。これによって、コマンドラインやスクリプトからのデータ・ポンプ・ジョブの結果を確認できます。

表1-1に、Linux、UNIXおよびWindowsオペレーティング・システムに対応するデータ・ポンプの終了コードを示します。

表 1-1 データ・ポンプの終了コード

終了コード

意味

EX_SUCC 0

エクスポートおよびインポート・ジョブが、正常に完了しました。エラーは出力デバイスに表示されず、ログ・ファイル(ある場合)にも記録されません。

EX_SUCC_ERR 5

エクスポートまたはインポート・ジョブは正常に完了しましたが、ジョブ実行中にエラーが検出されました。エラーは出力デバイスに表示され、ログ・ファイル(ある場合)に記録されます。

EX_FAIL 1

エクスポートまたはインポート・ジョブで、次を含む1つ以上の致命的エラーが検出されました。

- コマンドラインまたはコマンド構文のエラー

- エクスポートまたはインポートがリカバリできないOracle Databaseのエラー

- オペレーティング・システムのエラー(mallocなど)

- ジョブの開始を妨げる無効なパラメータ値(たとえばDIRECTORYパラメータで指定された無効なディレクトリ・オブジェクト)

致命的エラーは出力デバイスに表示されますが、ログ・ファイルには記録されない場合があります。これがログ・ファイルに記録されるかどうかは、次のようないくつかの要因によります。

- ログ・ファイルをジョブの開始時に指定したか。

- ログ・ファイルを開くのに十分なほどジョブの処理が進行していたか。

データ・ポンプ・ジョブの監査

選択したユーザー・データベース・アクションを監視および記録するため、データ・ポンプ・ジョブの監査を実行できます。データ・ポンプでは、すべての監査レコードが1つの場所に一元化される統合監査を使用します。

統合監査を設定するには、統合監査ポリシーを作成するか、既存のポリシーを変更します。監査ポリシーは、データベースにおけるユーザー動作の特定の部分を監査できる監査設定の名前付きグループです。ポリシーを作成するには、SQL CREATE AUDIT POLICY文を使用します。

監査ポリシーを作成したら、AUDITおよびNOAUDIT SQL文を使用してポリシーをそれぞれ有効化および無効化します。

関連項目:

- SQL CREATE AUDIT POLICY、ALTER AUDIT POLICY、AUDITおよびNOAUDIT文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- Oracle Databaseで監査を使用する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

データ・ポンプによるタイムスタンプ・データの処理方法

注意:

この項の情報は、Oracle Database 12c以上で実行されているOracle Data Pumpにのみ適用されます。

この項では、タイムスタンプ・データ型のTIMESTAMP WITH TIMEZONEおよびTIMESTAMP WITH LOCAL TIMEZONEを含むエクスポートおよびインポート・ジョブの正常な完了に影響する可能性のある要因について説明します。

TIMESTAMP WITH TIME ZONEの制限事項

TIMESTAMP with TIME ZONEデータを含むエクスポートおよびインポート・ジョブでは、ジョブが正常に完了するかどうかは次の要因に依存します。

- ソース・データベースとターゲット・データベースのOracle Databaseタイムゾーン・ファイルのバージョン。「ソースおよびターゲットのタイムゾーン・ファイルのバージョン」を参照してください。

- エクスポート/インポート・モードと、使用しているデータ・ポンプのバージョンでTIMESTAMP WITH TIME ZONEデータがサポートされるかどうか。(Data Pump 11.2.0.1以上では、TIMESTAMP WITH TIME ZONEデータがサポートされます。)「データ・ポンプによるTIMESTAMP WITH TIME ZONEデータのサポート」を参照してください。

データベースのタイムゾーン・ファイルのバージョンを識別するには、次のSQL文を実行します。

SQL> SELECT VERSION FROM V$TIMEZONE_FILE;

関連項目:

- タイムゾーン・ファイルの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

ソースおよびターゲットのタイムゾーン・ファイルのバージョン

ジョブが正常に完了するかどうかは、ソースとターゲットのタイムゾーン・ファイルのバージョンが一致しているかどうかによります。

- Oracle Databaseのタイムゾーン・ファイルのバージョンがソース・データベースとターゲット・データベースで同じである場合、TIMESTAMP WITH TIME ZONEデータの変換は不要です。エクスポート/インポート・ジョブは正常に完了します。
この例外は、データ・ポンプの11.2.0.1より前のリリースを使用して実行されるトランスポータブル表領域またはトランスポータブル表のエクスポートです。この場合、TIMESTAMP WITH TIME ZONE列を含むダンプ・ファイルの表は、タイムゾーン・ファイルのバージョンがソースとターゲットで同じであっても、インポート時に作成されません。

- ターゲット・データベースでソースのタイムゾーン・ファイルのバージョンを使用できない場合、ジョブは失敗します。ソースのタイムゾーン・ファイルが新しいバージョンに更新されていても、ターゲットでは更新されていないことがあるため、ソースのタイムゾーン・ファイルのバージョンはターゲットで使用できない可能性があります。たとえば、タイムゾーン・ファイルのバージョンが17のOracle Database 11gリリース2 (11.2.0.2)でエクスポートを実行し、使用できるタイムゾーン・ファイルのバージョンが16のみの11.2.0.2でインポートを実行すると、ジョブは失敗します。

データ・ポンプによるTIMESTAMP WITH TIME ZONEデータのサポート

この項では、Oracle Databaseのタイムゾーン・ファイルのバージョンがソース・データベースとターゲット・データベースで異なる場合における、異なるエクスポートおよびインポート・モードでのデータ・ポンプによるTIMESTAMP WITH TIME ZONEデータのサポートについて説明します。

非トランスポータブル・モード

- TIMESTAMP WITH TIME ZONEデータをサポートするデータ・ポンプのバージョン(11.2.0.1以上)でダンプ・ファイルを作成すると、エクスポート・システムのタイムゾーン・ファイルのバージョンがダンプ・ファイルに記録されます。データ・ポンプでは、この情報を使用してデータ変換が必要であるかどうかを決定します。ターゲット・データベースでソースのタイムゾーンのバージョンについて認識しているが、実際には新しいバージョンを使用している場合、データは新しいバージョンに変換されます。TIMESTAMP WITH TIME ZONEデータはダウングレードできないため、ソースで使用しているものより古いバージョンのタイムゾーン・ファイルを使用しているターゲットにインポートを試みると、インポートは失敗します。

- Oracle Database 11gリリース2 (11.2.0.1)より前のデータ・ポンプのバージョンでダンプ・ファイルを作成する場合、TIMESTAMP WITH TIME ZONEデータはサポートされないため、変換が実行されずに破損する可能性があります。

トランスポータブル表領域モードおよびトランスポータブル表モード

- トランスポータブル表領域モードおよびトランスポータブル表モードでは、ソースとターゲットのタイムゾーン・ファイルのバージョンが異なる場合、TIMESTAMP WITH TIME ZONE列を含む表は作成されません。ジョブの開始時に、ソースとターゲットのデータベース・タイムゾーン・ファイルのバージョンを示す警告が表示されます。また、作成されなかった表ごとにメッセージが表示されます。このことは、ダンプ・ファイルを作成するために使用したデータ・ポンプのバージョンでTIMESTAMP WITH TIME ZONEデータがサポートされる場合でも同様です。(リリース11.2.0.1以上ではTIMESTAMP WITH TIMEZONEデータがサポートされます。)

- ソースがOracle Database 11gリリース2 (11.2.0.1)よりも前の場合、トランスポータブル・セットがTIMESTAMP WITH TIME ZONE列を使用するかどうかに関係なく、タイムゾーン・ファイルのバージョンはすべてのトランスポータブル・ジョブのソースおよびターゲット・データベースで同じである必要があります。

全体トランスポータブル・モード

全体トランスポータブル・エクスポートおよびインポートがサポートされるのは、ソース・データベースがOracle Database 11gリリース2 (11.2.0.3)以上で、ターゲットがOracle Database 12cリリース1 (12.1)以上の場合です。

Data Pump 11.2.0.1以上では、TIMESTAMP WITH TIME ZONEデータがサポートされます。したがって、全体トランスポータブル操作では、TIMESTAMP WITH TIME ZONE列を含む表が作成されます。ソース・データベースとターゲット・データベースのタイムゾーン・ファイルのバージョンが異なる場合、ソースのTIMESTAMP WITH TIME ZONE列は、ターゲットのタイムゾーン・ファイルのバージョンに変換されます。

関連項目:

- トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 全体トランスポータブル・エクスポートの詳細は、「全体モード・エクスポート時のトランスポータブル・オプションの使用」を参照してください

- 全体トランスポータブル・インポートの詳細は、「全体モード・インポート時のトランスポータブル・オプションの使用」を参照してください

TIMESTAMP WITH LOCAL TIME ZONEの制限事項

表がトランスポータブル・モード(トランスポータブル表、トランスポータブル表領域または全体トランスポータブル)を使用して移動され、次の条件が存在する場合、警告が発行されて表は作成されません。

- ソース・データベースとターゲット・データベースのデータベース・タイムゾーンが異なる場合

- 表にTIMESTAMP WITH LOCAL TIME ZONEデータ型が含まれる場合

これらの条件が原因で作成されなかった表を正常に移動するには、トランスポータブルではないエクスポートおよびインポート・モードを使用してください。

キャラクタ・セットおよびグローバリゼーション・サポートに関する考慮点

この項では、ユーザー・データおよびデータ定義言語(DDL)のキャラクタ・セット変換に関連するデータ・ポンプ・エクスポートおよびインポートのグローバリゼーション・サポートの動作について説明します。

ユーザー・データ

エクスポート・ユーティリティは、常に、エクスポート・システムのキャラクタ・セットでUnicodeデータを含むユーザー・データをエクスポートします。(キャラクタ・セットは、データベース作成時に指定されます。)ソース・データベースのキャラクタ・セットが、インポート・データベースのキャラクタ・セットと異なる場合、自動的にデータをインポート・システムのキャラクタ・セットに変換するための単一の変換が実行されます。

変換によるキャラクタ・セットのソート順への影響

エクスポート・キャラクタ・セットのソート順が、インポート・キャラクタ・セットと異なる場合、キャラクタ列をパーティション化した表では、結果が保証されません。たとえば、次のようなASCIIキャラクタ・セットのデータベースの表定義について考えてみます。

CREATE TABLE partlist ( part VARCHAR2(10),
partno NUMBER(2)
)
PARTITION BY RANGE (part)
(
PARTITION part_low VALUES LESS THAN ('Z')
TABLESPACE tbs_1,
PARTITION part_mid VALUES LESS THAN ('z')
TABLESPACE tbs_2,
PARTITION part_high VALUES LESS THAN (MAXVALUE)
TABLESPACE tbs_3
);

ASCIIキャラクタ・セットでは、Zの後にzがあるため、このパーティション・スキームには意味があります。

この表がEBCDICキャラクタ・セット・ベースのデータベースにインポートされると、EBCDICキャラクタ・セットでは、zがZの前にあるため、part_midパーティションのすべての行が、part_lowパーティションに移行します。希望する結果を得るには、partlist表の所有者は、インポート後に表を再パーティション化する必要があります。

DDL

エクスポート・ユーティリティは、エクスポート・システムのデータベース・キャラクタ・セットを使用してダンプ・ファイルを書き込みます。

インポート・システムのデータベース・キャラクタ・セットがエクスポート・システムのデータベース・キャラクタ・セットと異なる場合にのみ、ダンプ・ファイルのインポート時にDDLのためにキャラクタ・セット変換が必要です。

キャラクタ・セット変換によるデータの損失を最小限にするには、インポートのデータベース・キャラクタ・セットがエクスポートのデータベース・キャラクタ・セットのスーパーセットであることを確認します。

シングルバイト・キャラクタ・セットとエクスポートおよびインポート

インポートが実行されるシステムで7ビット・キャラクタ・セットを使用し、8ビット・キャラクタ・セットのダンプ・ファイルをインポートすると、一部の8ビット・キャラクタは同等の7ビットに変換されることがあります。これが発生した場合の目印として、アクセント記号が付いている文字からアクセントが消去されます。

この不要な変換を回避するため、エクスポート・データベースとインポート・データベースで同じキャラクタ・セットを使用していることを確認してください。

マルチバイト・キャラクタ・セットとエクスポートおよびインポート

インポート・データベースのキャラクタ・セットに同等の文字がないエクスポート・ファイル中の文字は、変換時にデフォルトの文字に置換されます。インポート・データベースのキャラクタ・セットは、デフォルトの文字を定義します。

DDLの変換中にインポート・システムで置換文字を使用する必要がある場合、警告メッセージが表示され、システムは変換されたDDLをロードしようと試みます。

ユーザー・データの変換中にインポート・システムで置換文字を使用する必要がある場合、デフォルトの動作として、変換されたデータがロードされます。ただし、置換文字を使用して変換されたユーザー・データの行を拒否するようにインポート・システムに指示することが可能です。詳細は、インポートの「DATA_OPTIONS」パラメータを参照してください。

100%完全に変換されるためには、インポート・データベースのキャラクタ・セットは、エクスポート・ファイルを生成するために使用されるキャラクタ・セットのスーパーセットであるか、それと同等である必要があります。

注意:

エクスポート・システムのデータベース・キャラクタ・セットがインポート・システムのものと異なる場合、ジョブの開始時に、データベース・キャラクタ・セットの内容を示す情報メッセージがインポート・システムに表示されます。

インポート・データベースのキャラクタ・セットがエクスポート・ファイルを生成するために使用されたキャラクタ・セットのスーパーセットではない場合、キャラクタ・セット変換によってデータ損失が発生する可能性があることを示す警告がインポート・システムに表示されます。

2 データ・ポンプ・エクスポート

Oracle Data Pump Exportユーティリティは、ダンプ・ファイル・セットと呼ばれる一連のオペレーティング・システム・ファイルに、データおよびメタデータをアンロードする場合に使用します。

ここでは、次の項目について説明します。

- データ・ポンプ・エクスポート・ユーティリティとは

- データ・ポンプ・エクスポートの起動

- エクスポート操作中のフィルタ処理

- エクスポート・ユーティリティのコマンドライン・モードで使用可能なパラメータ

- エクスポート・ユーティリティの対話方式コマンド・モードで使用可能なコマンド

- データ・ポンプ・エクスポートの使用例

- データ・ポンプ・エクスポートの構文図

データ・ポンプ・エクスポート・ユーティリティとは

データ・ポンプ・エクスポート(以降、エクスポート・ユーティリティと呼びます)は、ダンプ・ファイル・セットと呼ばれる一連のオペレーティング・システム・ファイルにデータおよびメタデータをアンロードするためのユーティリティです。ダンプ・ファイル・セットは、データ・ポンプ・インポート・ユーティリティによってのみインポートできます。ダンプ・ファイル・セットは、同一システムでインポートするか、または別のシステムへ移動してそのシステムにロードできます。

ダンプ・ファイル・セットは、表データ、データベース・オブジェクトのメタデータ、制御情報を含む1つ以上のディスク・ファイルで構成されています。これらのファイルは独自のバイナリ形式で書き込まれています。データ・ポンプ・インポート・ユーティリティは、インポート操作中、これらのファイルを使用してダンプ・ファイル・セット内の各データベース・オブジェクトの位置を特定します。

ダンプ・ファイルは、クライアントではなくサーバーによって書き込まれるため、データベース管理者(DBA)は、ファイルが書き込まれるサーバーの場所を定義するディレクトリ・オブジェクトを作成する必要があります。ディレクトリ・オブジェクトの詳細は、「ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置」を参照してください。

データ・ポンプ・エクスポート・ユーティリティでは、データおよびメタデータのサブセットが、エクスポート・モードで設定されているとおりにジョブによって移動されるように指定できます。この指定には、エクスポート・パラメータで指定するデータ・フィルタおよびメタデータ・フィルタが使用されます。詳細は、「エクスポート操作中のフィルタ処理」を参照してください。

データ・ポンプ・エクスポートを使用できる様々な方法の例については、「データ・ポンプ・エクスポートの使用例」を参照してください。

データ・ポンプ・エクスポートの起動

データ・ポンプ・エクスポート・ユーティリティは、expdpコマンドを使用して起動します。エクスポート操作の特性は、指定するエクスポート・パラメータによって決定されます。これらのパラメータは、コマンドラインまたはパラメータ・ファイルのいずれかで指定できます。

注意:

エクスポート・ユーティリティは、Oracleサポート・サービスから要求された場合以外、SYSDBAとして起動しないでください。SYSDBAは内部的に使用され、一般ユーザーとは異なる特別な機能を持ちます。

エクスポート・ユーティリティの起動の詳細は、次の項を参照してください。

- 「データ・ポンプ・エクスポートのインタフェース」

- 「データ・ポンプ・エクスポートのモード」

- 「ネットワークに関する考慮点」

データ・ポンプ・エクスポートのインタフェース

データ・ポンプ・エクスポートとは、コマンドライン、パラメータ・ファイルまたは対話方式コマンド・モードを使用して対話できます。

- コマンドライン・インタフェース: ほとんどのエクスポート・パラメータを直接コマンドラインで指定できます。コマンドライン・インタフェースで使用可能なパラメータの詳細は、「エクスポート・ユーティリティのコマンドライン・モードで使用可能なパラメータ」を参照してください。

- パラメータ・ファイル・インタフェース: パラメータ・ファイルでコマンドラインのパラメータを指定できます。パラメータ・ファイルはネストできないため、PARFILEパラメータのみが例外となります。値の指定に引用符が必要なパラメータを指定する場合は、パラメータ・ファイルを使用することをお薦めします。詳細は、「データ・ポンプ・コマンドラインでの引用符の使用」を参照してください。

- 対話方式コマンド・インタフェース: 端末へのロギングを中止してエクスポート・ユーティリティのプロンプトを表示します。このプロンプトで、対話方式コマンド・モード固有のコマンドも含めて、様々なコマンドを入力できます。このモードは、コマンドライン・インタフェースまたはパラメータ・ファイル・インタフェースで開始されたエクスポート操作中に[Ctrl]キーを押しながら[C]キーを押すと使用可能になります。対話方式コマンド・モードは、実行中のジョブまたは停止されたジョブに接続した場合も使用可能になります。
対話方式コマンド・モードで使用可能なコマンドの詳細は、「エクスポート・ユーティリティの対話方式コマンド・モードで使用可能なコマンド」を参照してください。

データ・ポンプ・エクスポートのモード

エクスポート・ユーティリティには、データベースの様々な部分をアンロードするための様々なモードがあります。モードは、適切なパラメータを使用してコマンドラインで指定します。使用可能なモードについては、次の項で説明します。

- 「全体モード」

- 「スキーマ・モード」

- 「表モード」

- 「表領域モード」

- 「トランスポータブル表領域モード」

注意:

一部のシステム・スキーマは、ユーザー・スキーマではないため、エクスポートできません。システム・スキーマには、Oracleが管理するデータおよびメタデータが含まれています。エクスポートされないシステム・スキーマの例としては、SYS、ORDSYS、MDSYSなどがあります。

関連項目:

「データ・ポンプ・エクスポートの使用例」

「全体モード」

全データベース・エクスポートは、FULLパラメータを使用して指定します。全データベース・エクスポートでは、データベース全体がアンロードされます。このモードには、DATAPUMP_EXP_FULL_DATABASEロールが必要です。

全体モード・エクスポート時のトランスポータブル・オプションの使用

FULLパラメータをTRANSPORTABLE=ALWAYSパラメータとともに指定すると、データ・ポンプによって全体トランスポータブル・エクスポートが実行されます。全体トランスポータブル・エクスポートでは、データベースの完全なコピーを作成するために必要なすべてのオブジェクトおよびデータがエクスポートされます。次のデータ移動方法の組合せが使用されます。

- トランスポータブル表領域に存在するオブジェクトは、そのメタデータのみがダンプ・ファイル・セットにアンロードされ、データ自体はデータ・ファイルをターゲット・データベースにコピーしたときに移動されます。コピーする必要のあるデータ・ファイルは、エクスポート操作のログ・ファイルの最後に表示されます。

- 非トランスポータブル表領域に存在するオブジェクト(SYSTEMやSYSAUXなど)は、ダイレクト・パス・アンロードおよび外部表を使用して、そのメタデータとデータの両方がダンプ・ファイル・セットにアンロードされます。

全体トランスポータブル・エクスポートの実行には、次の制限があります。

- 全体トランスポータブル・エクスポートを実行するユーザーには、DATAPUMP_EXP_FULL_DATABASE権限が必要です。

- エクスポートを実行するユーザーのデフォルトの表領域を、転送対象となっている表領域のいずれかに設定することはできません。

- エクスポートされるデータベースに、暗号化された表領域または暗号化された列(透過的データ暗号化(TDE)列またはSecureFiles LOB列)のある表が含まれる場合、ENCRYPTION_PASSWORDパラメータも指定する必要があります。

- ソース・データベースとターゲット・データベースは、ソース・データベースに暗号化された表領域がある場合、同じエンディアンのプラットフォーム上に存在する必要があります。

- ソース・プラットフォームとターゲット・プラットフォームのエンディアンが異なる場合、転送するデータを変換してターゲット・プラットフォームの形式にする必要があります。DBMS_FILE_TRANSFERパッケージまたはRMAN CONVERTコマンドを使用してデータを変換できます。これらのオプションの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 全体トランスポータブル・エクスポートは再開できません。

- エクスポートのために選択された記憶域を持つすべてのオブジェクトでは、そのすべての記憶域セグメントが、管理対象の非トランスポータブル表領域(SYSTEM / SYSAUX)内に全体として存在するか、ユーザー定義のトランスポータブル表領域内に全体として存在する必要があります。シングル・オブジェクトの記憶域は、2種類の表領域にまたがることはできません。

- 全体トランスポータブル・エクスポートを使用してネットワークを介してデータベースを転送する場合、管理表領域(SYSTEMやSYSAUXなど)に存在するLONGまたはLONG RAW列を含む表は、サポートされません。

- 全体トランスポータブル・エクスポートを使用してネットワークを介してデータベースを転送する場合、監査証跡情報自体がユーザー定義の表領域に格納されていると、管理表領域(SYSTEMやSYSAUXなど)に格納された表に対して監査を有効にすることはできません。

- ソース・データベースとターゲット・データベースの両方でOracle Database 12cリリース1 (12.1)を実行している場合、全体トランスポータブル・エクスポートを実行するには、データ・ポンプのVERSIONパラメータを12.0以上に設定するか、COMPATIBLEデータベース初期化パラメータを12.0以上に設定する必要があります。

全体トランスポータブル・エクスポートは、リリース11.2.0.3を実行しているソース・データベースでサポートされます。これを行うには、次の例に示すとおり、データ・ポンプのVERSIONパラメータを12.0以上に設定します。

> expdp user_name FULL=y DUMPFILE=expdat.dmp DIRECTORY=data_pump_dir
TRANSPORTABLE=always VERSION=12.0 LOGFILE=export.log

関連項目:

- RMAN CONVERTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- 全体トランスポータブル・エクスポートの例は、『Oracle Database管理者ガイド』を参照してください。

- エクスポートの「FULL」パラメータ

- エクスポートの「TRANSPORTABLE」パラメータ

スキーマ・モード

スキーマ・エクスポートは、SCHEMASパラメータを使用して指定します。これがデフォルトのエクスポート・モードです。DATAPUMP_EXP_FULL_DATABASEロールを所有している場合は、スキーマのリストを指定し、オプションでスキーマ定義およびこれらのスキーマに対するシステム権限を指定することができます。DATAPUMP_EXP_FULL_DATABASEロールを所有していない場合は、自分のスキーマのみをエクスポートできます。

SYSスキーマは、エクスポート・ジョブのソース・スキーマとして使用できません。

相互スキーマ参照は、参照されるスキーマがエクスポート対象のスキーマのリストにも指定されないかぎり、エクスポートされません。たとえば、指定されたいずれかのスキーマ内の表にトリガーが定義されていても、そのトリガーが、明示的に指定されていないスキーマ内に常駐している場合はエクスポートされません。これは、指定されたスキーマ内の表に影響を及ぼす外部型定義についても同様です。この場合は、インポート時に、型定義がターゲット・インスタンスにすでに存在している必要があります。

関連項目:

エクスポート・ユーティリティのSCHEMASパラメータの詳細は、「SCHEMAS」を参照してください

表モード

表モード・エクスポートは、TABLESパラメータを使用して指定します。表モードでは、指定した表、パーティションおよびそれらの依存オブジェクトのみがアンロードされます。所有するスキーマや列のタイプなど、表の作成に必要なすべてのオブジェクトがすでに存在している必要があります。

TRANSPORTABLE=ALWAYSパラメータとTABLESパラメータを組み合せて指定すると、オブジェクト・メタデータのみがアンロードされます。実際のデータを移動するには、データ・ファイルをターゲット・データベースにコピーします。これにより、エクスポート時間が短縮されます。異なるリリースまたはプラットフォーム間でデータ・ファイルを移動する場合は、データ・ファイルをOracle Recovery Manager(RMAN)で処理することが必要な場合があります。

自分のスキーマに存在しない表を指定するには、DATAPUMP_EXP_FULL_DATABASEロールが必要です。列の型定義は、表モードではエクスポートされません。この場合は、インポート時に、型定義がターゲット・インスタンスにすでに存在している必要があります。また、スキーマ・エクスポートの場合と同様に、相互スキーマ参照もエクスポートされません。

表および表パーティションをリカバリするには、RMANバックアップおよびRMAN RECOVER TABLEコマンドも使用できます。このプロセス中に、RMANによって、リカバリされたオブジェクトを含むデータ・ポンプ・エクスポートのダンプ・ファイルが作成(およびオプションでインポート)されます。このトピックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

関連項目:

- エクスポート・ユーティリティのTABLESパラメータの詳細は、「TABLES」を参照してください

- エクスポート・ユーティリティのTRANSPORTABLEパラメータの詳細は、「TRANSPORTABLE」を参照してください

- プラットフォーム間のデータの移動の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

表領域モード

表領域エクスポートは、TABLESPACESパラメータを使用して指定します。表領域モードでは、指定した表領域内に存在する表のみがアンロードされます。表がアンロードされると、その表の依存オブジェクトもアンロードされます。オブジェクトのメタデータとデータは、両方ともアンロードされます。表領域モードでは、指定した表領域内に表の一部が存在する場合、その表とその表のすべての依存オブジェクトがエクスポートされます。特権ユーザーは、すべての表を取得します。権限のないユーザーは、自分のスキーマ内の表のみを取得します。

関連項目:

- エクスポート・ユーティリティのTABLESPACESパラメータの詳細は、「TABLESPACES」を参照してください

トランスポータブル表領域モード

トランスポータブル表領域エクスポートは、TRANSPORT_TABLESPACESパラメータを使用して指定します。トランスポータブル表領域モードでは、指定した表領域セット内にある表のメタデータ(およびその表の依存オブジェクト)のみがエクスポートされます。表領域データ・ファイルは別の操作でコピーされます。次に、トランスポータブル表領域インポートが実行され、メタデータを含むダンプ・ファイルのインポートと、使用するデータ・ファイルの指定が行われます。

トランスポータブル表領域モードでは、指定した表がすべてその表領域に含まれている必要があります。つまり、表領域セット内に定義されているすべての表(およびその索引)のすべての記憶域セグメントも、セット内に含まれている必要があります。表領域セット内に違反が含まれている場合は、エクスポート・ユーティリティが実際にエクスポートを実行することなくすべての問題を識別します。

トランスポータブル表領域エクスポートは、停止すると再開できません。また、トランスポータブル表領域エクスポートには、1を超える並列度は指定できません。

暗号化された列は、トランスポータブル表領域モードではサポートされていません。

注意:

トランスポータブル表領域をエクスポートした後、それよりも古いリリース・レベルのデータベースにインポートすることはできません。ターゲット・データベースのリリース・レベルは、ソース・データベース以上である必要があります。

関連項目:

- トランスポータブル表領域モードを使用する場合のタイムスタンプ・データに関する特別な考慮事項の詳細は、「データ・ポンプによるタイムスタンプ・データの処理方法」を参照してください

ネットワークに関する考慮点

データ・ポンプ・エクスポート・ユーティリティの起動時、接続文字列には接続識別子を指定できます。この識別子では、現行のOracleシステム識別子(SID)によって指定した現行のインスタンスとは別のデータベース・インスタンスを指定できます。接続識別子には、Oracle*Net接続記述子または接続記述子にマップするネット・サービス名(通常、tnsnames.oraファイルで定義される)を指定できます。接続識別子を使用するには、Oracle Net Listenerが実行中であることが必要です(デフォルト・リスナーを起動するには、lsnrctl startと入力します)。次に、inst1が接続識別子である場合のこのタイプの接続の例を示します。

expdp hr@inst1 DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp TABLES=employees

エクスポートによってパスワードの入力を要求されます。

Password: password

ローカル・エクスポート・クライアントは接続識別子inst1(ネット・サービス名)によって定義されるデータベース・インスタンスに接続し、inst1からデータを取得し、データをinst1のダンプ・ファイルhr.dmpに書き込みます。

エクスポート・ユーティリティの起動時に接続識別子を指定することと、NETWORK_LINKパラメータを使用してエクスポート操作を実行することは異なります。エクスポート操作を開始して接続識別子を指定すると、接続識別子によって識別されたデータベース・インスタンスにローカルのエクスポート・クライアントが接続され、データベース・インスタンスのデータが取得され、そのデータベース・インスタンスのダンプ・ファイル・セットにデータが書き込まれます。一方、NETWORK_LINKパラメータを使用してエクスポートを実行すると、エクスポートはデータベース・リンクを使用して実行されます。(データベース・リンクとは2つの物理データベース・サーバー間の接続で、データベース・リンクによってクライアントは2つの物理データベース・サーバーに1つの論理データベースとしてアクセスできます。)

関連項目:

- 「NETWORK_LINK」

- データベース・リンクの詳細は、Oracle Database管理者ガイドを参照してください。

- 接続識別子およびOracle Net Listenerの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

エクスポート操作中のフィルタ処理

データ・ポンプ・エクスポート・ユーティリティでは、データとメタデータのフィルタ処理機能を使用して、エクスポートする情報の種類を効果的に制限できます。

データ・フィルタ

データ固有のフィルタ処理は、QUERYおよびSAMPLEパラメータによって実装されます。このパラメータは、表のエクスポートされる行に対する制限を指定します。

メタデータのフィルタ処理のため、間接的にデータのフィルタ処理が実行される場合もあります。この処理では、表オブジェクトおよび関連付けられた行データを含めたり、除外することができます。

各データ・フィルタは、表ごとにジョブ内で1回指定できます。同じ名前を使用する異なるフィルタが特定の表とジョブ全体の両方に適用された場合は、特定の表に対して提供されたフィルタ・パラメータが優先されます。

メタデータのフィルタ

メタデータのフィルタ処理は、EXCLUDEおよびINCLUDEパラメータによって実装されます。EXCLUDEおよびINCLUDEは、相互に排他的なパラメータです。

メタデータ・フィルタは、オブジェクトを、エクスポートまたはインポート操作に含めるか除外するかを識別します。たとえば、パッケージ仕様またはパッケージ本体を含まない全体エクスポートを要求できます。

フィルタを正しく使用して必要な結果を得た場合は、識別されたオブジェクトの依存オブジェクトも、識別されたオブジェクトとともに処理されます。たとえば、索引を操作に含めるようにフィルタで指定すると、その索引の統計も含まれます。同様に、フィルタで表を除外すると、その表に対する索引、制約、権限およびトリガーも除外されます。

1つのオブジェクト型に対して複数のフィルタが指定されている場合は、それらのフィルタに対して暗黙的なAND処理が適用されます。つまり、ジョブに関連するオブジェクトは、オブジェクト型に適用されるすべてのフィルタで処理される必要があります。

同じメタデータ・フィルタ名を、1つのジョブ内で複数回指定できます。

DATABASE_EXPORT_OBJECTS(全体モードの場合)、SCHEMA_EXPORT_OBJECTS(スキーマ・モードの場合)、TABLE_EXPORT_OBJECTS(表および表領域モードの場合)ビューを問い合せて、有効なオブジェクト・タイプ値の一覧を表示できます。OBJECT_PATH列にリストされる値が有効なオブジェクト・タイプです。たとえば、次の問合せを実行できます。

SQL> SELECT OBJECT_PATH, COMMENTS FROM SCHEMA_EXPORT_OBJECTS
2  WHERE OBJECT_PATH LIKE '%GRANT' AND OBJECT_PATH NOT LIKE '%/%';

次に、この問合せの出力結果の例を示します。

OBJECT_PATH
--------------------------------------------------------------------------------
COMMENTS
--------------------------------------------------------------------------------
GRANT
Object grants on the selected tables

OBJECT_GRANT
Object grants on the selected tables

PROCDEPOBJ_GRANT
Grants on instance procedural objects

PROCOBJ_GRANT
Schema procedural object grants in the selected schemas

ROLE_GRANT
Role grants to users associated with the selected schemas

SYSTEM_GRANT
System privileges granted to users associated with the selected schemas

関連項目:

「EXCLUDE」および「INCLUDE」

エクスポート・ユーティリティのコマンドライン・モードで使用可能なパラメータ

この項では、データ・ポンプ・エクスポート・ユーティリティのコマンドライン・モードで使用可能なパラメータについて説明します。エクスポート・パラメータを使用する前に、必ず次の項を読んでください。

- 「エクスポート・パラメータの指定」

- 「データ・ポンプ・コマンドラインでの引用符の使用」

パラメータの説明では、多くの場合パラメータの使用例を含みます。使用例を実行するために必要な環境の設定の詳細は、次の項を参照してください。

- 「エクスポート・パラメータの使用例」

エクスポート・パラメータの指定

値を複数個指定できるパラメータでは、カンマまたは空白で値を区切ることができます。たとえば、TABLES=employees,jobsまたはTABLES=employees jobsのように指定できます。

入力するパラメータごとに、等号(=)と値を入力する必要があります。それ以外の方法では、1つ前のパラメータ指定がどこで完了し、新しいパラメータ指定がどこから始まるかをデータ・ポンプに伝えることができません。たとえば、次のコマンドラインの場合、NOLOGFILEは有効なパラメータですが、DUMPFILEパラメータに対するダンプ・ファイル名がもう1つあると解釈されます。

expdp DIRECTORY=dpumpdir DUMPFILE=test.dmp NOLOGFILE TABLES=employees

その結果、test.dmpおよびnologfile.dmpという2つのダンプ・ファイルが作成されることになります。

これを回避するには、NOLOGFILE=YESまたはNOLOGFILE=NOのいずれかを指定します。

パラメータ値を指定する場合の大/小文字の区別

パラメータ値として入力される表領域名、スキーマ名、表名などについて、Oracle Data Pumpは、小文字または大/小文字混在で入力された値をデフォルトで大文字に変更します。たとえば、TABLE=hr.employeesと入力すると、それはTABLE=HR.EMPLOYEESに変更されます。大/小文字を維持するには、引用符で値を囲む必要があります。たとえば、TABLE="hr.employees"とすると、表名がすべて小文字のまま維持されます。入力する名前は、データベースに格納されている名前と完全に一致する必要があります。

データ・ポンプ・コマンドラインでの引用符の使用

一部のオペレーティング・システムでは引用符が特殊文字として処理されるため、バックスラッシュ(\)などのエスケープ文字を前に付けないと、アプリケーションに正しく渡されません。これは、コマンドラインとパラメータ・ファイル内の両方に当てはまります。また、オペレーティング・システムによっては、コマンドラインで、特殊文字を含むパラメータ値全体を一重引用符または二重引用符で囲む必要があります。

次の例では、これらの概念を説明します。特定のオペレーティング・システムに該当しない場合があること、および各ユーザーに固有の運用環境は想定していないことに注意してください。

次のように、パラメータ・ファイルでTABLESパラメータを指定するとします。

TABLES = \"MixedCaseTableName\"

これをコマンドラインで指定するとき、一部のオペレーティング・システムでは、次のように一重引用符で囲む必要があります。

TABLES = '\"MixedCaseTableName\"'

コマンドラインで追加の引用符を指定せずに手順を続行するには、パラメータ・ファイルを使用することをお薦めします。また、パラメータ・ファイルを使用し、指定するパラメータ値の文字列の最初の文字に引用符を使用しない場合(たとえば、TABLES=scott."EmP")は、エスケープ文字の使用が不要になるシステムがあることに注意してください。

エクスポート・パラメータの使用例

各項に示す例を試行する場合は、次の内容に注意してください。

- 例に示すようにユーザー名およびパラメータを入力した後、エクスポート・ユーティリティが起動され、パスワードの入力を求められます。データベース接続が行われる前に、パスワードを入力する必要があります。

- ここに示す例の多くは、Oracle Databaseのインストール時にデフォルトでインストールされるシード・データベースのサンプル・スキーマを使用しています。特に、人事管理(hr)スキーマを頻繁に使用します。

- この例では、ディレクトリ・オブジェクトdpump_dir1およびdpump_dir2がすでに存在し、これらのディレクトリ・オブジェクトについてのREAD権限およびWRITE権限が、hrユーザーに付与されているものとします。ディレクトリ・オブジェクトの作成および権限の割当ての詳細は、「ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置」を参照してください。

- 一部の例では、DATAPUMP_EXP_FULL_DATABASEロールおよびDATAPUMP_IMP_FULL_DATABASEロールが必要です。その例では、hrユーザーにこれらのロールが付与されているものとします。

必要に応じて、これらのディレクトリ・オブジェクトの作成と、必要な権限やロールの割当てをDBAに依頼します。

これらのパラメータの構文図は、「データ・ポンプ・エクスポートの構文図」を参照してください。

特に指定がないかぎり、これらのパラメータはパラメータ・ファイルでも指定できます。

関連項目:

- エクスポート・ユーティリティの「PARFILE」パラメータ

- デフォルト・ディレクトリ・オブジェクトの作成の詳細は、「ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置」を参照してください

- 「データ・ポンプ・エクスポートの使用例」

- 『Oracle Databaseサンプル・スキーマ』

- システムでの特殊文字および予約文字の処理方法の詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

ABORT_STEP

デフォルト: NULL

用途

ジョブの初期化後に、そのジョブを停止する場合に使用します。これによって、データのエクスポート前にマスター表の問合せが可能になります。

構文および説明

ABORT_STEP=[n | -1]

指定可能な値は、マスター表内のプロセス・オーダー番号と対応しています。各番号の使用結果は次のとおりです。

- n: 値が0以上の場合は、エクスポート操作が開始され、対応するプロセス・オーダー番号を持つ、マスター表に格納されているオブジェクトでジョブが中断されます。

- -1: 値が負の1(-1)の場合は、ジョブの設定後(ただし、オブジェクトまたはデータのエクスポート前)に、ジョブが中断されます。

制限事項

- 「なし」

例

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=expdat.dmp SCHEMAS=hr ABORT_STEP=-1

ACCESS_METHOD

デフォルト: AUTOMATIC

用途

エクスポート・ユーティリティで特定のメソッドを使用してデータをアンロードするように指定します。

構文および説明

ACCESS_METHOD=[AUTOMATIC | DIRECT_PATH | EXTERNAL_TABLE]

デフォルトのメソッドがなんらかの理由で動作しない場合に別のネイティブ・メソッドを試行できるように、ACCESS_METHODパラメータが提供されます。できるだけデフォルトのオプション(AUTOMATIC)を使用することをお薦めします(このオプションによって、データ・ポンプは最も効果的なメソッドを自動的に選択できるようになります)。

制限事項

- NETWORK_LINKパラメータも指定する場合、ダイレクト・パス・モードはサポートされません。

- データ・ポンプ・エクスポートのACCESS_METHODパラメータは、トランスポータブル表領域のジョブに対して有効ではありません。

例

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=expdat.dmp SCHEMAS=hr
ACCESS_METHOD=EXTERNAL_TABLE

ATTACH

デフォルト: ユーザーのスキーマで現在実行されているジョブ(存在する場合)

用途

クライアント・セッションを既存のエクスポート・ジョブに接続し、自動的に対話方式コマンド・インタフェースを有効にします。接続先のジョブの説明およびエクスポート・プロンプトが表示されます。

構文および説明

ATTACH [=[schema_name.]job_name]

schema_nameは、オプションです。自分のスキーマ以外のスキーマを指定するには、DATAPUMP_EXP_FULL_DATABASEロールが必要です。

job_nameは、スキーマに対応するエクスポート・ジョブが1つのみで、そのジョブがアクティブの場合はオプションです。停止しているジョブに接続する場合は、このジョブ名を指定する必要があります。DBA_DATAPUMP_JOBSビューまたはUSER_DATAPUMP_JOBSビューを問い合せて、データ・ポンプ・ジョブ名の一覧を表示できます。

ジョブに接続している場合、エクスポート・ユーティリティでは、ジョブの説明が表示され、次にエクスポート・プロンプトが表示されます。

制限事項

- ATTACHパラメータを指定する場合、コマンドラインで他に指定できるデータ・ポンプ・パラメータは、ENCRYPTION_PASSWORDのみです。

- 接続するジョブが最初に暗号化パスワードを使用して起動している場合、そのジョブへの接続時に、コマンドライン上のENCRYPTION_PASSWORDパラメータを再入力してそのパスワードを再指定する必要があります。唯一の例外は、ジョブが最初にENCRYPTION=ENCRYPTED_COLUMNS_ONLYパラメータを使用して開始されている場合です。この場合、ジョブへの接続時に暗号化パスワードは必要ありません。

- そのジョブが実行中でなければ、別のスキーマのジョブに接続することはできません。

- ジョブのダンプ・ファイル・セットまたはマスター表が削除されている場合、接続操作は失敗します。

- マスター表を変更すると、それがどのような変更であっても、予期しない結果になります。

例

次に、ATTACHパラメータの使用例を示します。ジョブhr.export_jobがすでに存在するものとします。

> expdp hr ATTACH=hr.export_job

関連項目:

「エクスポート・ユーティリティの対話方式コマンド・モードで使用可能なコマンド」

CLUSTER

デフォルト: YES

用途

データ・ポンプでOracle Real Application Clusters(Oracle RAC)リソースを使用できるかどうかと、ワーカーを他のOracle RACインスタンス上で開始できるかどうかを決定します。

構文および説明

CLUSTER=[YES | NO]

データ・ポンプ・エクスポートで、ジョブが開始されたインスタンスのみを使用し、Oracle Database 11g リリース2(11.2)より前の動作と同じにするには、CLUSTER=NOを指定します。

特定の既存サービスを指定しワーカー・プロセスを制約して、そのサービスに対して定義されたインスタンス上のみでこれらを実行できるようにするには、CLUSTER=YESパラメータとSERVICE_NAMEパラメータを組み合せて使用します。

CLUSTERパラメータを使用すると、エクスポート・ジョブをOracle RACインスタンス全体に分散させるための追加のオーバーヘッドが発生するため、パフォーマンスに影響する場合があります。ジョブが小さいときは、CLUSTER=NOを指定して、ジョブが開始されたインスタンス上のみでジョブを実行した方がよい場合もあります。CLUSTERパラメータを使用してジョブのパフォーマンスが最もよくなるのは、ジョブのデータ量が多い場合です。

例

次に、CLUSTERパラメータの使用例を示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_clus%U.dmp CLUSTER=NO PARALLEL=3

この例では、hrスキーマのスキーマ・モード・エクスポート(デフォルト)を実行します。CLUSTER=NOが指定されているため、ジョブでは起動時のインスタンスのみが使用されます。(CLUSTERパラメータが指定されていない場合は、デフォルト値のYが使用され、必要に応じて、Oracle RACの他のインスタンス上で動作が開始されます。)ダンプ・ファイルは、dpump_dir1ディレクトリ・オブジェクトに指定された場所に書き込まれます。ジョブでは、パラレル処理を最大3つまで実行できます。

関連項目:

- 「SERVICE_NAME」

- 「Oracle RACに関する考慮点」

COMPRESSION

デフォルト: METADATA_ONLY

用途

ダンプ・ファイル・セットに書き込む前に圧縮するデータを指定します。

構文および説明

COMPRESSION=[ALL | DATA_ONLY | METADATA_ONLY | NONE]

- ALLを指定すると、エクスポート操作全体について圧縮が有効になります。ALLオプションでは、Oracle Advanced Compressionオプションを有効にする必要があります。

- DATA_ONLYを指定すると、すべてのデータが圧縮形式でダンプ・ファイルに書き込まれます。DATA_ONLYオプションでは、Oracle Advanced Compressionオプションを有効にする必要があります。

- METADATA_ONLYを指定すると、すべてのメタデータが圧縮形式でダンプ・ファイルに書き込まれます。これはデフォルトです。

- NONEを指定すると、エクスポート操作全体について圧縮が無効になります。

制限事項

- これらすべての圧縮オプションを使用するには、COMPATIBLE初期化パラメータを11.0.0以上に設定する必要があります。

- METADATA_ONLYオプションは、たとえCOMPATIBLE初期化パラメータが10.2に設定されていても使用できます。

- ALLまたはDATA_ONLYを使用したデータ圧縮は、Oracle Database 11g以上のEnterprise Editionでのみ有効で、Oracle Advanced Compressionオプションを有効にする必要があります。

例

次に、COMPRESSIONパラメータの使用例を示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_comp.dmp COMPRESSION=METADATA_ONLY

このコマンドは、スキーマ・モードのエクスポートを実行し、すべてのメタデータを圧縮してからダンプ・ファイルhr_comp.dmpに書き出します。エクスポート・モードが指定されていないため、デフォルトでスキーマ・モードのエクスポートになります。

関連項目:

Oracle Advanced Compressionオプションのライセンス要件の詳細は、『Oracle Databaseライセンス情報』を参照してください。

COMPRESSION_ALGORITHM

デフォルト: BASIC

用途

ダンプ・ファイル・データを圧縮する場合に使用する圧縮アルゴリズムを指定します。

構文および説明

COMPRESSION_ALGORITHM = {BASIC | LOW | MEDIUM | HIGH}

パラメータ・オプションの定義は次のとおりです。

- BASIC: 圧縮率と速度の適度な組合せが実現し、使用されるアルゴリズムはOracle Data Pumpの以前のバージョンと同じです。

- LOW: エクスポート・スループットへの影響を最小限に抑えるため、CPUリソースが限定要因となっている環境に適しています。

- MEDIUM: ほとんどの環境に適しています。このオプションはBASICオプションと同様、圧縮率と処理速度を加味したよい組合せですが、BASICとは異なるアルゴリズムが使用されています。

- HIGH: ネットワーク速度が限定要因となっている、速度が遅いネットワークでダンプ・ファイルがコピーされる状況に最適です。

圧縮アルゴリズムのパフォーマンスは、そのCPU使用量および圧縮率(非圧縮の入力に対する割合としての圧縮済の出力のサイズ)によって特徴付けられます。これらの測定値は、使用される圧縮アルゴリズムの速度に加え、入力のサイズおよびタイプに応じて変化します。基本的に圧縮率はLOWからHIGHへと高くなります。ただし、圧縮率の上昇に応じて、消費されるCPUリソースが多くなります。

ご使用の環境で、データに対して様々な圧縮レベルをテストすることをお薦めします。エクスポートされるダンプ・ファイル・セットの圧縮レベルがパフォーマンスおよび記憶域要件を満たすようにするには、環境、ワークロードの特性、およびデータのサイズとタイプに基づいて圧縮レベルを選択します。

制限事項

- この機能を使用するには、データベース互換性を12.0.0以上に設定する必要があります。

- この機能では、Oracle Advanced Compressionオプションを有効にする必要があります。

例1

この例では、HRスキーマのスキーマ・モード・アンロードを実行し、低い圧縮レベルの圧縮アルゴリズムを使用して表データのみを圧縮します。これにより、最適な圧縮率を得ることはできませんが、使用されるCPUリソースの数を抑えることができます。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp COMPRESSION=DATA_ONLY
COMPRESSION_ALGORITHM=LOW

例2

この例では、HRスキーマのスキーマ・モード・アンロードを実行し、基本の圧縮レベルを使用してメタデータと表データの両方を圧縮します。COMPRESSION_ALGORITHMパラメータを完全に省略することは、値としてBASICを指定することと同じです。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp COMPRESSION=ALL COMPRESSION_ALGORITHM=BASIC

CONTENT

デフォルト: ALL

用途

エクスポート・ユーティリティでアンロードする内容を、データのみ、メタデータのみ(あるいはその両方)でフィルタ処理できます。

構文および説明

CONTENT=[ALL | DATA_ONLY | METADATA_ONLY]

- ALLを指定すると、データとメタデータの両方がアンロードされます。これはデフォルトです。

- DATA_ONLYを指定すると、表の行データのみがアンロードされます。データベース・オブジェクト定義はアンロードされません。

- METADATA_ONLYを指定すると、データベース・オブジェクト定義のみがアンロードされ、表の行データはアンロードされません。CONTENT=METADATA_ONLYを指定した場合、ダンプ・ファイルが後でインポートされるときに、ダンプ・ファイルからインポートされる索引または表の統計はインポート後にロックされることに注意してください。

制限事項

- CONTENT=METADATA_ONLYパラメータは、TRANSPORT_TABLESPACES(トランスポータブル表領域モード)パラメータまたはQUERYパラメータと組み合せて使用することはできません。

例

次に、CONTENTパラメータの使用例を示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp CONTENT=METADATA_ONLY

このコマンドでは、hrのスキーマに関連付けられたメタデータのみをアンロードするスキーマ・モード・エクスポートが実行されます。エクスポート・モードが指定されていない場合は、デフォルトでhrのスキーマのスキーマ・モード・エクスポートになります。

DATA_OPTIONS

デフォルト: デフォルト値は設定されていません。このパラメータが使用されていない場合、このパラメータが提供する特別なデータ処理オプションは無効になります。

用途

DATA_OPTIONSパラメータは、エクスポート操作時に特定のタイプのデータをどのように処理するかを指定します。

構文および説明

DATA_OPTIONS=XML_CLOBS

XML_CLOBSオプションを指定すると、XMLType列は、列に対して定義されているXMLTypeの格納形式に関係なく非圧縮のCLOB形式でエクスポートされます。

注意:

CLOBとして格納されるXMLTypeは、Oracle Database 12cリリース1 (12.1)からは非推奨になりました。XMLType表および列は、現在はバイナリXMLとして格納されます。

表にCLOB形式で格納されているXMLType列しかない場合は、データ・ポンプにより自動的にこれらの列がCLOB形式でエクスポートされるため、XML_CLOBSオプションを指定する必要はありません。表にオブジェクト・リレーショナル(スキーマベース)、バイナリまたはCLOB形式の組合せで格納されているXMLType列がある場合、デフォルトで、これらの列はデータ・ポンプにより圧縮形式でエクスポートされます。この方法を使用することをお薦めします。ただし、データを非圧縮のCLOB形式でエクスポートする必要がある場合は、XML_CLOBSオプションを使用してデフォルトの設定を上書きできます。

制限事項

- XML_CLOBSオプションを使用するには、エクスポート時とインポート時の両方で同じXMLスキーマを使用する必要があります。

- エクスポート・ユーティリティのDATA_OPTIONSパラメータを使用する場合は、ジョブ・バージョンを11.0.0以上に設定する必要があります。「VERSION」を参照してください。

例

この例では、hr.xdb_tab1表のXMLType列を、列に対して定義されているXMLTypeの格納形式に関係なく、非圧縮のCLOB形式でエクスポートするエクスポート操作を示します。

> expdp hr TABLES=hr.xdb_tab1 DIRECTORY=dpump_dir1 DUMPFILE=hr_xml.dmp
VERSION=11.2 DATA_OPTIONS=XML_CLOBS

関連項目:

XMLType表のエクスポートおよびインポートに固有の情報については、『Oracle XML DB開発者ガイド』を参照してください。

DIRECTORY

デフォルト: DATA_PUMP_DIR

用途

エクスポート・ユーティリティによるダンプ・ファイル・セットおよびログ・ファイルのデフォルトの書込み先を指定します。

構文および説明

DIRECTORY=directory_object

directory_objectは、データベースのディレクトリ・オブジェクトの名前です(実際のディレクトリのファイル・パスではありません)。インストール時に、特権ユーザーにDATA_PUMP_DIRという名前のデフォルトのディレクトリ・オブジェクトへのアクセス権が付与されます。デフォルトのDATA_PUMP_DIRディレクトリ・オブジェクトにアクセス可能なユーザーは、DIRECTORYパラメータを使用する必要はまったくありません。

DUMPFILEパラメータやLOGFILEパラメータで指定したディレクトリ・オブジェクトは、DIRECTORYパラメータに指定したディレクトリ・オブジェクトよりも優先されます。

例

次に、DIRECTORYパラメータの使用例を示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=employees.dmp CONTENT=METADATA_ONLY

ダンプ・ファイルemployees.dmpは、ディレクトリ・オブジェクトdpump_dir1に対応付けられたパスに書き込まれます。

関連項目:

- デフォルトのディレクトリ・オブジェクト、およびデータ・ポンプがファイルの位置を判断するために使用する優先順位の詳細は、「ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置」を参照してください

- 「Oracle RACに関する考慮点」

- CREATE DIRECTORYコマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

DUMPFILE

デフォルト: expdat.dmp

用途

名前を指定します。オプションで、エクスポート・ジョブに対するダンプ・ファイルのディレクトリ・オブジェクトを指定します。

構文および説明

DUMPFILE=[directory_object:]file_name [, ...]

DIRECTORYパラメータで指定されている場合、directory_objectはオプションです。ここで値を指定する場合は、すでに存在しアクセス権があるディレクトリ・オブジェクトを指定します。DUMPFILEパラメータの一部に指定されるデータベース・ディレクトリ・オブジェクトは、DIRECTORYパラメータによって指定された値またはデフォルトのディレクトリ・オブジェクトよりも優先されます。

カンマで区切ったリストまたは個別のDUMPFILEパラメータ指定で、複数のfile_name指定を定義できます。ファイル拡張子を指定しない場合は、デフォルトのファイル拡張子.dmpが使用されます。ファイル名には、複数のファイルを生成できることを示す置換変数(%U)を含めることができます。生成されるファイル名では、置換変数が、01から99まで増加する固定幅の2桁の整数に変換されます。ファイル指定に2つの置換変数が含まれている場合は、両方の変数が同時に増加します。たとえば、exp%Uaa%U.dmpは、exp01aa01.dmp、exp02aa02.dmpというように変換されます。

FILESIZEパラメータを指定すると、各ダンプ・ファイルがそのサイズを上限とするため、拡張できなくなります。置換変数(%U)を持つテンプレートを指定していて、ダンプ・ファイル・セットに必要な領域が不足し、デバイスに余裕がある場合は、FILESIZEパラメータで指定したサイズの新しいダンプ・ファイルが自動的に作成されます。

置換変数が含まれているファイル指定またはファイル・テンプレートは、定義されているとおり、完全修飾されたファイル名としてインスタンス化され、エクスポート・ユーティリティによって作成されます。ファイル指定は、指定した順序で処理されます。ファイル・サイズが上限に達したか、またはパラレル処理をアクティブなままにするためにジョブにファイルを追加する必要がある場合、置換変数を持つファイル・テンプレートが指定されていれば、追加のファイルが作成されます。

DUMPFILEパラメータで複数のファイルを指定することもできますが、エクスポート・ジョブでエクスポート・データを保持するために必要となるのは、それらのファイルのサブセットのみの場合もあります。エクスポート・ジョブの最後に表示されるダンプ・ファイル・セットには、実際に使用されたファイルが示されます。このダンプ・ファイル・セットを使用するインポート操作には、このファイル・リストが必要になります。使用されなかったファイルは無視してかまいません。

制限事項

- 作成されるダンプ・ファイルの名前がすでに存在しているダンプ・ファイルの名前と一致するとエラーが生成されます。既存のダンプ・ファイルが上書きされることはありません。この動作を上書きするには、エクスポート・ユーティリティのパラメータREUSE_DUMPFILES=YESを指定します。

- データ・ポンプのパラメータVERSION=12を使用してOracle Database 11gリリースで作成したダンプ・ファイルは、Oracle Database 12cリリース1 (12.1)以上でのみインポートできます。

例

次に、DUMPFILEパラメータの使用例を示します。

> expdp hr SCHEMAS=hr DIRECTORY=dpump_dir1 DUMPFILE=dpump_dir2:exp1.dmp,
exp2%U.dmp PARALLEL=3

ダンプ・ファイルexp1.dmpは、ディレクトリ・オブジェクトdpump_dir2に対応するパスに書き込まれます。これは、dpump_dir2が、ダンプ・ファイル名の一部として指定されたことによって、DIRECTORYパラメータで指定されたディレクトリ・オブジェクトよりも優先されるためです。3つのパラレル処理のすべてに、このジョブの間に実行する作業が与えられるため、指定した置換変数exp2%U.dmpに基づいて、exp201.dmpおよびexp202.dmpという名前のダンプ・ファイルが作成されます。ディレクトリが指定されていないため、作成されたファイルは、DIRECTORYパラメータで指定されたディレクトリ・オブジェクトdpump_dir1に関連付けられたパスに書き込まれます。

関連項目:

- ダンプ・ファイル名に置換変数を指定する場合の置換変数の処理方法の詳細は、「置換変数の使用」を参照してください

ENCRYPTION

デフォルト: デフォルト値は、使用される暗号化関連のパラメータの組合せによって決まります。暗号化を有効にするには、ENCRYPTIONまたはENCRYPTION_PASSWORDパラメータ、あるいは両方を指定する必要があります。

ENCRYPTION_PASSWORDパラメータのみが指定されている場合は、デフォルトでENCRYPTIONパラメータがALLに設定されます。

ENCRYPTIONパラメータのみが指定され、Oracle暗号化ウォレットがオープン状態の場合、デフォルト・モードはTRANSPARENTになります。ENCRYPTIONパラメータのみが指定され、ウォレットが閉じられている場合は、エラーが返されます。

ENCRYPTIONとENCRYPTION_PASSWORDのいずれも指定しない場合、ENCRYPTIONのデフォルト値はNONEとなります。

用途

ダンプ・ファイル・セットに書き込む前にデータを暗号化するかどうかを指定します。

構文および説明

ENCRYPTION = [ALL | DATA_ONLY | ENCRYPTED_COLUMNS_ONLY | METADATA_ONLY | NONE]

- ALLを指定すると、エクスポート操作ですべてのデータおよびメタデータについて暗号化が有効になります。

- DATA_ONLYを指定すると、データのみが暗号化形式でダンプ・ファイル・セットに書き込まれます。

- ENCRYPTED_COLUMNS_ONLYを指定すると、暗号化された列のみが暗号化形式でダンプ・ファイル・セットに書き込まれます。列にはすでに割り当てられた暗号化形式があり、定義によって列が保持できる暗号化形式は1つのみであるため、このオプションをENCRYPTION_ALGORITHMパラメータと組み合せて使用することはできません。
ENCRYPTED_COLUMNS_ONLYオプションを指定する場合、ENCRYPTION_PASSWORDで指定される暗号化パスワードに許可される最大長は、30バイトです。

ALL、DATA_ONLYまたはMETADATA_ONLYオプションを指定する場合、またはデフォルトを使用する場合、暗号化パスワードに許可される最大長は、128バイトです。

ENCRYPTED_COLUMNS_ONLYオプションを使用するには、Oracle Advanced Securityのデータの透過的な暗号化(TDE)を有効にする必要があります。TDEの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

- METADATA_ONLYを指定すると、メタデータのみが暗号化形式でダンプ・ファイル・セットに書き込まれます。

- NONEを指定すると、データは暗号化形式でダンプ・ファイル・セットに書き込まれません。

暗号化に関するSecureFilesの考慮点

エクスポート対象のデータに暗号化の必要なSecureFilesが含まれている場合は、ENCRYPTION=ALLを指定してダンプ・ファイル・セット全体を暗号化する必要があります。ダンプ・ファイル・セット全体の暗号化は、データ・ポンプ・エクスポート操作中にSecureFilesの暗号化セキュリティを実現する唯一の方法です。SecureFilesの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

暗号化に関するOracle Database Vaultの考慮点

エクスポート操作が起動されると、データ・ポンプによって、Oracle Database Vaultが有効であるかどうかが確認されます。それが有効であり、ダンプ・ファイルの暗号化がジョブに指定されていない場合、セキュアなデータがセキュアではない方法(クリア・テキスト)でダンプ・ファイル・セットに書き込まれていることを示す警告メッセージが返されます。

ORA-39327: Oracle Database Vault data is being stored unencrypted in dump file set

現在のエクスポート操作を中断し、出力ダンプ・ファイル・セットを暗号化するように指定して新しい操作を開始できます。

制限事項

- ALL、DATA_ONLYまたはMETADATA_ONLYの各オプションを指定するには、COMPATIBLE初期化パラメータを11.0.0以上に設定する必要があります。

- このパラメータは、Oracle Database 11g以上のEnterprise Editionでのみ有効です。

- データ・ポンプの暗号化機能を使用するには、Oracle Advanced Securityオプションが有効である必要があります。Oracle Advanced Securityオプションのライセンス要件の詳細は、『Oracle Databaseライセンス情報』を参照してください。

例

次の例では、ダンプ・ファイルでデータのみが暗号化されるエクスポート操作を実行します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_enc.dmp JOB_NAME=enc1
ENCRYPTION=data_only ENCRYPTION_PASSWORD=foobar

ENCRYPTION_ALGORITHM

デフォルト: AES128

用途

暗号化の実行に使用する必要のある暗号化アルゴリズムを指定します。

構文および説明

ENCRYPTION_ALGORITHM = [AES128 | AES192 | AES256]

暗号化アルゴリズムの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

制限事項

- この暗号化機能を使用するには、COMPATIBLE初期化パラメータを11.0.0以上に設定する必要があります。

- ENCRYPTION_ALGORITHMパラメータを使用する場合は、ENCRYPTIONまたはENCRYPTION_PASSWORDパラメータも指定する必要があります。指定しないと、エラーが返されます。

- すでに暗号化されている列に追加の暗号化形式を割り当てることはできないため、ENCRYPTION_ALGORITHMパラメータをENCRYPTION=ENCRYPTED_COLUMNS_ONLYと組み合せて使用することはできません。

- このパラメータは、Oracle Database 11g以上のEnterprise Editionでのみ有効です。

- データ・ポンプの暗号化機能を使用するには、Oracle Advanced Securityオプションが有効である必要があります。Oracle Advanced Securityオプションのライセンス要件の詳細は、『Oracle Databaseライセンス情報』を参照してください。

例

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_enc3.dmp
ENCRYPTION_PASSWORD=foobar ENCRYPTION_ALGORITHM=AES128

ENCRYPTION_MODE

デフォルト: デフォルト・モードは、他に使用される暗号化関連のパラメータによって決まります。ENCRYPTIONパラメータのみが指定され、Oracle暗号化ウォレットがオープン状態の場合、デフォルト・モードはTRANSPARENTになります。ENCRYPTIONパラメータのみが指定され、ウォレットが閉じられている場合は、エラーが返されます。

ENCRYPTION_PASSWORDパラメータが指定され、ウォレットがオープン状態の場合、デフォルト設定はDUALになります。ENCRYPTION_PASSWORDパラメータが指定され、ウォレットが閉じられている場合、デフォルト設定はPASSWORDになります。

用途

暗号化および復号化を実行する際に使用するセキュリティ・タイプを指定します。

構文および説明

ENCRYPTION_MODE = [DUAL | PASSWORD | TRANSPARENT]

DUALモードでは、後から透過的にインポートしたり、デュアルモードで暗号化されたダンプ・ファイル・セットの作成時に使用したパスワードを指定してインポートすることができるダンプ・ファイル・セットを作成します。DUALモードで作成されたダンプ・ファイル・セットを後からインポートするときは、ウォレットまたはENCRYPTION_PASSWORDパラメータで指定されたパスワードのいずれかを使用できます。DUALモードは、ウォレットを使用する場合にはダンプ・ファイル・セットのインポートをオンサイトで行い、ウォレットが使用できない場合にはオフサイトでインポートを行う必要もある場合に最適です。

PASSWORDモードでは、暗号化されたダンプ・ファイル・セットの作成時にパスワードを指定する必要があります。ダンプ・ファイル・セットをインポートするときは同じパスワードを指定する必要があります。PASSWORDモードでは、ENCRYPTION_PASSWORDパラメータを指定する必要もあります。PASSWORDモードは、ダンプ・ファイル・セットが別のデータベースやリモート・データベースにインポートされるときに、転送中もセキュリティで保護する必要がある場合に最適です。

TRANSPARENTモードでは、必要なウォレットを使用できる場合、暗号化されるダンプ・ファイル・セットをデータベース管理者(DBA)の介入なしで作成することができます。したがって、ENCRYPTION_PASSWORDパラメータは必要なく、実際には、TRANSPARENTモードで使用するとエラーの原因となります。この暗号化モードは、ダンプ・ファイル・セットをエクスポート元と同じデータベースにインポートする場合に最適です。

制限事項

- DUALまたはTRANSPARENTモードを使用するには、COMPATIBLE初期化パラメータを11.0.0以上に設定する必要があります。

- ENCRYPTION_MODEパラメータを使用する場合は、ENCRYPTIONまたはENCRYPTION_PASSWORDパラメータのいずれかを使用する必要もあります。そうでない場合は、エラーが戻されます。

- ENCRYPTION=ENCRYPTED_COLUMNS_ONLYを使用する場合は、ENCRYPTION_MODEパラメータを使用できません。そうでない場合は、エラーが戻されます。

- このパラメータは、Oracle Database 11g以上のEnterprise Editionでのみ有効です。

- データ・ポンプの暗号化機能を使用するには、Oracle Advanced Securityオプションが有効である必要があります。Oracle Advanced Securityオプションのライセンス要件の詳細は、『Oracle Databaseライセンス情報』を参照してください。

例

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_enc4.dmp
ENCRYPTION=all ENCRYPTION_PASSWORD=secretwords
ENCRYPTION_ALGORITHM=AES256 ENCRYPTION_MODE=DUAL

ENCRYPTION_PASSWORD

デフォルト: デフォルト値は設定されていません。ユーザーが値を指定します。

用途

エクスポート・ダンプ・ファイル内の暗号化列のデータ、メタデータまたは表データを暗号化するためのパスワードを指定します。これにより、暗号化されたダンプ・ファイル・セットへの不正なアクセスを防ぎます。

注意:

データ・ポンプの暗号化機能は、Oracle Database 11gリリース1(11.1)で変更されています。リリース11.1より前は、ENCRYPTION_PASSWORDパラメータが適用されるのは暗号化列のみでした。しかし、リリース11.1では、新しいENCRYPTIONパラメータが他のタイプのデータを暗号化するためのオプションを提供するようになりました。つまり、ENCRYPTIONと固有のオプションを指定せずにENCRYPTION_PASSWORDを指定すると、ダンプ・ファイルに書き込まれるすべてのデータが暗号化されるようになりました(ENCRYPTION=ALLを指定した場合と同じ)。暗号化列のみを再暗号化する場合は、ENCRYPTION_PASSWORDに加えてENCRYPTION=ENCRYPTED_COLUMNS_ONLYを指定する必要があります。

構文および説明

ENCRYPTION_PASSWORD = password

指定するpassword値は、暗号化された表の列、メタデータまたは表データをダンプ・ファイル・セットにクリア・テキストとして書き込まないように、再度暗号化するキーを指定します。エクスポート操作に暗号化された表の列が含まれていて、暗号化パスワードが指定されていない場合、暗号化された列はダンプ・ファイル・セットにクリア・テキストで書き込まれ、警告が発行されます。

入力したパスワードは画面に表示されます。パスワードを入力時に画面に表示しない場合、ENCRYPTION_PWD_PROMPTパラメータを使用します。

暗号化パスワードに許可される最大長は、ENCRYPTIONパラメータに指定されたオプションに応じて異なります。ENCRYPTION=ENCRYPTED_COLUMNS_ONLYが指定されている場合、暗号化パスワードの最大長は、30バイトです。ENCRYPTIONパラメータがALL、DATA_ONLYまたはMETADATA_ONLYとして指定されている場合、またはデフォルトが使用されている場合、暗号化パスワードの最大長は、128バイトです。

エクスポート操作については、ENCRYPTION_MODEパラメータがPASSWORDまたはDUALに設定されている場合に、このパラメータが必要になります。

注意:

データ・ポンプのENCRYPTION_PASSWORDパラメータで指定されるキーと、暗号化された列が含まれる表が最初に作成されるときにENCRYPTキーワードで指定されるキーとの間には、関連性も依存性もありません。たとえば、次のように、キーがxyzの暗号化列を持つ表を作成するとします。

CREATE TABLE emp (col1 VARCHAR2(256) ENCRYPT IDENTIFIED BY "xyz");

emp表をエクスポートするときは、ENCRYPTION_PASSWORDに任意の値を指定できます。xyzである必要はありません。

制限事項

- このパラメータは、Oracle Database 11g以上のEnterprise Editionでのみ有効です。

- 全体トランスポータブル・エクスポートで、暗号化された表領域および暗号化された列が存在する表を含む表領域を転送する場合、ENCRYPTION_PASSWORDパラメータが必要です。

- データ・ポンプの暗号化機能を使用するには、Oracle Advanced Securityオプションが有効である必要があります。Oracle Advanced Securityオプションのライセンス要件の詳細は、『Oracle Databaseライセンス情報』を参照してください。

- ENCRYPTION_PASSWORDを指定して、ENCRYPTION_MODEを指定しない場合は、ENCRYPTION_MODEのデフォルトがPASSWORDになるため、Oracle Advanced Securityのデータの透過的な暗号化を有効にする必要はありません。

- ENCRYPTION_PASSWORDパラメータは、指定した暗号化モードがTRANSPARENTの場合は有効になりません。

- ENCRYPTION_MODEをDUALに設定した場合にENCRYPTION_PASSWORDパラメータを使用するには、Oracle Advanced Securityのデータの透過的な暗号化(TDE)を有効にする必要があります。TDEの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

- ネットワーク・エクスポートの場合、ENCRYPTION_PASSWORDパラメータとENCRYPTION=ENCRYPTED_COLUMNS_ONLYの併用は、暗号化された列を含むユーザー定義の外部表ではサポートされていません。そのような表はスキップされ、エラー・メッセージが表示されますが、ジョブは続行されます。

- すべての列に対する暗号化属性は、エクスポートされた表の定義とターゲット表で一致している必要があります。たとえば、EMP表にEMPNOという列があるとします。次のいずれの場合も、ソース表のEMP列の暗号化属性が、ターゲット表のEMP列の暗号化属性と一致していないためエラーになります。

- EMPNO列を暗号化してEMP表をエクスポートし、表をインポートする前にEMPNO列から暗号化属性を削除する。

- EMPNO列を暗号化せずにEMP表をエクスポートし、表をインポートする前にEMPNO列の暗号化を有効にする。

例

次の例では、暗号化パスワード123456がダンプ・ファイルdpcd2be1.dmpに割り当てられています。

> expdp hr TABLES=employee_s_encrypt DIRECTORY=dpump_dir1
DUMPFILE=dpcd2be1.dmp ENCRYPTION=ENCRYPTED_COLUMNS_ONLY
ENCRYPTION_PASSWORD=123456

employee_s_encrypt表の暗号化列は、dpcd2be1.dmpダンプ・ファイルにクリア・テキストとして書き込まれません。この例で作成されたdpcd2be1.dmpファイルを後でインポートするには、同じ暗号化パスワードを指定する必要があることに注意してください。

ENCRYPTION_PWD_PROMPT

デフォルト: NO

用途

データ・ポンプによって暗号化パスワードの入力を要求するかどうかを指定します。

構文および説明

ENCRYPTION_PWD_PROMPT=[YES | NO]

コマンドラインでENCRYPTION_PWD_PROMPT=YESと指定すると、ENCRYPTION_PASSWORDパラメータを使用してコマンドラインでパスワードを入力するかわりに、データ・ポンプによって暗号化パスワードの入力を要求されます。この方法のメリットは、プロンプトで入力すると、暗号化パスワードが画面に表示されないことです。これに対し、ENCRYPTION_PASSWORDパラメータを使用してコマンドラインで入力すると、それがプレーン・テキストで表示されます。

プロンプトで入力する暗号化パスワードは、ENCRYPTION_PASSWORDパラメータで説明されているものと同じ基準に従います。

エクスポート操作で暗号化パスワードを指定した場合、インポート操作でもそれを指定する必要があります。

制限事項

- ENCRYPTION_PWD_PROMPTパラメータとENCRYPTION_PASSWORDパラメータの同時使用は禁止されています。

例

次の例では、データ・ポンプによって最初にユーザー・パスワードが要求され、次に暗号化パスワードが要求されます。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp ENCRYPTION_PWD_PROMPT=YES
.
.
.
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

Password:

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit
Production
With the Partitioning, Advanced Analytics and Real Application Testing options

Encryption Password:

Starting "HR"."SYS_EXPORT_SCHEMA_01":  hr/******** directory=dpump_dir1 dumpfile=hr.dmp encryption_pwd_prompt=Y
.
.
.

ESTIMATE

デフォルト: BLOCKS

用途

エクスポート・ジョブ内の各表で使用されるディスク領域(バイト単位)を見積もる場合にエクスポートで使用される方法を指定します。見積りはログ・ファイルに出力され、クライアントの標準出力デバイスに表示されます。見積りの対象は、表の行データのみです。メタデータは含まれません。

構文および説明

ESTIMATE=[BLOCKS | STATISTICS]

- BLOCKS: 見積りは、ソース・オブジェクトで使用されるデータベース・ブロックの数に、適切なブロック・サイズを掛けて計算されます。

- STATISTICS: 見積りは、表別の統計を使用して計算されます。この方法による見積りをできるかぎり正確にするには、すべての表を新しく分析しておく必要があります。(表の分析は、SQL ANALYZE文またはDBMS_STATS PL/SQLパッケージのいずれかで実行可能です。)

制限事項

- ESTIMATE=BLOCKSが使用されている場合、圧縮された表がデータ・ポンプのエクスポート・ジョブに含まれていると、その圧縮表に対するデフォルトのサイズ見積りは不正確になります。これは、データが圧縮形式で保存されていたことが、サイズの見積りに反映されないためです。圧縮された表に対するサイズ見積りをより正確に行うには、ESTIMATE=STATISTICSを使用してください。

- また、QUERYまたはREMAP_DATAパラメータのいずれかが使用されている場合に、見積りが不正確になることがあります。

例

次の例に、ESTIMATEパラメータの使用例を示します。ここでは、employees表に対する統計を使用して見積りが計算されます。

> expdp hr TABLES=employees ESTIMATE=STATISTICS DIRECTORY=dpump_dir1
DUMPFILE=estimate_stat.dmp

ESTIMATE_ONLY

デフォルト: NO

用途

エクスポート・ユーティリティで、ジョブが消費する領域を実際のエクスポート操作を行わずに見積もります。

構文および説明

ESTIMATE_ONLY=[YES | NO]

ESTIMATE_ONLY=YESの場合、エクスポート・ユーティリティは、使用される領域の見積りを行いますが、実際にエクスポート操作は実行せずに終了します。

制限事項

- ESTIMATE_ONLYパラメータは、QUERYパラメータと組み合せて使用することはできません。

例

次に、ESTIMATE_ONLYパラメータを使用して、HRスキーマが使用するエクスポート領域の大きさを判断する場合の例を示します。

> expdp hr ESTIMATE_ONLY=YES NOLOGFILE=YES SCHEMAS=HR

EXCLUDE

デフォルト: デフォルト値は設定されていません。

用途

エクスポート操作から除外するオブジェクトおよびオブジェクト型を指定して、エクスポートの対象となるメタデータをフィルタ処理できます。

構文および説明

EXCLUDE=object_type[:name_clause] [, ...]

object_typeは除外するオブジェクトのタイプを指定します。DATABASE_EXPORT_OBJECTS(全体モードの場合)、SCHEMA_EXPORT_OBJECTS(スキーマ・モードの場合)、TABLE_EXPORT_OBJECTS(表および表領域モードの場合)ビューを問い合せて、object_typeの有効な値の一覧を表示できます。OBJECT_PATH列にリストされる値が有効なオブジェクト・タイプです。(このような問合せの実行方法の例は、「メタデータのフィルタ」を参照してください。)

EXCLUDE文に指定したオブジェクト型を除き、実行されるエクスポート・モードに対応するすべてのオブジェクト型が、エクスポート操作の対象になります。オブジェクトが除外されると、そのオブジェクトのすべての依存オブジェクトも除外されます。たとえば、表を除外すると、その表のすべての索引およびトリガーも除外されます。

name_clauseは、オプションです。このオプションを使用すると、あるオブジェクト型のうち、特定のオブジェクトを選択できます。このオプションは、その型のオブジェクト名に対するフィルタとして使用されるSQL式です。SQL演算子および指定した型のオブジェクト名の比較対象となる値で構成されています。このname_clauseは、名前付きのインスタンスを持つオブジェクト型にのみ適用されます(たとえば、TABLEには適用されますが、GRANTには適用されません)。それは、コロンでオブジェクト型と区切り、二重引用符(一重引用符は名前文字列を区切るために必要なため)で囲む必要があります。たとえば、EXCLUDE=INDEX:"LIKE 'EMP%'"と設定した場合、EMPで始まる名前を持つすべての索引を除外できます。

name_clauseに指定する名前は、データベース内の既存のオブジェクトに、大文字と小文字も含めて完全に一致させる必要があります。たとえば、指定するname_clauseがEMPLOYEESという表に対するものだった場合は、すべてが大文字のEMPLOYEESという表が存在する必要があります。name_clauseに対してEmployees、employeesなどを指定した場合、表は検出されません。

name_clauseを指定しない場合、指定した型のすべてのオブジェクトが除外されます。

2つ以上のEXCLUDE文を指定できます。

オペレーティング・システムによっては、このパラメータの値を指定するときに引用符とともにエスケープ文字を使用する必要があります。このパラメータはパラメータ・ファイルで指定することをお薦めします。パラメータ・ファイルを使用すると、コマンドラインでは必要なエスケープ文字の数を減らすことができます。

object_typeにCONSTRAINT、GRANTまたはUSERを指定する場合、次に説明する影響があることに注意してください。

制約の除外

次の制約は明示的に除外できません。

- 表の作成とロードを正常に行うために必要な制約。たとえば、索引構成表の主キー制約、REF列を持つ表のREF SCOPEおよびWITH ROWID制約など

次に、EXCLUDE文の例およびその解釈を示します。

- EXCLUDE=CONSTRAINTでは、表の正常な作成およびロードに必要な制約を除く、すべての制約を除外します。

- EXCLUDE=REF_CONSTRAINTは、参照整合性(外部キー)制約を除外します。

権限とユーザーの除外

EXCLUDE=GRANTを指定すると、すべてのオブジェクト型に対するオブジェクト権限およびシステム権限が除外されます。

EXCLUDE=USERを指定すると、ユーザーの定義のみが除外され、そのユーザーのスキーマ内のオブジェクトは除外されません。

特定のユーザーとそのユーザーのすべてのオブジェクトを除外するには、次のコマンドを指定します(hrは除外するユーザーのスキーマ名です)。

expdp FULL=YES DUMPFILE=expfull.dmp EXCLUDE=SCHEMA:"='HR'"

ここで、エクスポート・モードがFULLに指定されていることに注意してください。モードを指定しなかった場合は、デフォルト・モードのSCHEMASが使用されます。その場合は、スキーマをエクスポートすると同時に除外するようコマンドが指示することになるため、エラーが発生します。

EXCLUDE=USER:"='HR'"のような文を使用してユーザーを除外しようとすると、CREATE USER hr DDL文内で使用される情報のみが除外され、期待した結果が得られない場合があります。

制限事項

- EXCLUDEおよびINCLUDEは、相互に排他的なパラメータです。

例

次に、EXCLUDE文の使用例を示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_exclude.dmp EXCLUDE=VIEW,
PACKAGE, FUNCTION

これによって、hrスキーマ全体がエクスポートされるスキーマ・モード・エクスポート(デフォルトのエクスポート・モード)が実行されます。ただし、このスキーマのビュー、パッケージおよびファンクションは除外されます。

関連項目:

- EXCLUDEパラメータを使用した場合の効果の詳細は、「エクスポート操作中のフィルタ処理」を参照してください

- パラメータ・ファイルの使用例は、「INCLUDE」を参照してください

- 「データ・ポンプ・コマンドラインでの引用符の使用」

FILESIZE

デフォルト: 0(最大サイズの16TBと同じ)

用途

各ダンプ・ファイルの最大サイズを指定します。ダンプ・ファイル・セット内にあるダンプ・ファイルが最大サイズになると、そのファイルはクローズされ、ファイル指定に置換変数が含まれている場合または追加ダンプ・ファイルがジョブに追加されている場合は、新しいファイルが作成されます。

構文および説明

FILESIZE=integer[B | KB | MB | GB | TB]

integerの後に(スペースを挿入しない)、B、KB、MB、GBまたはTB(それぞれバイト、キロバイト、メガバイト、ギガバイト、テラバイトを示す)を指定できます。デフォルトは、B(バイト)です。作成されるファイルの実際のサイズは、ダンプ・ファイル内で使用されている内部ブロックのサイズと一致するように切り捨てられる場合があります。

制限事項

- ファイルの最小サイズは、デフォルトのデータ・ポンプ・ブロック・サイズの10倍、つまり4KBです。

- ファイルの最大サイズは16TBです。

例

次に、サイズが3MBのダンプ・ファイルを設定する例を示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_3m.dmp FILESIZE=3MB

3MBでもすべてのエクスポート・データを保持するのに十分でなかった場合、次のエラーが表示され、ジョブは中止されます。

ORA-39095: Dump file space has been exhausted: Unable to allocate 217088 bytes

割り当てることができなかった実際のバイト数は、場合によって異なります。また、この数字は、エクスポート操作全体を完了するために必要な容量を表しているわけではありません。この値は、ダンプ・ファイル領域がなくなった時点でエクスポート中だったオブジェクトのサイズのみを示しています。この状況は、中止されたジョブに接続し、ADD_FILEコマンドを使用してファイルを1つ以上追加し、操作をやり直すことで解消できます。

FLASHBACK_SCN

デフォルト: デフォルト値は設定されていません。

用途

エクスポートで使用されるシステム変更番号(SCN)を指定して、フラッシュバック問合せユーティリティを使用可能にします。

構文および説明

FLASHBACK_SCN=scn_value

エクスポート操作は、指定したSCNまでの一貫性のあるデータを使用して実行されます。NETWORK_LINKパラメータが指定されている場合、SCNはソース・データベースのSCNを示します。

制限事項

- FLASHBACK_SCNおよびFLASHBACK_TIMEは、相互に排他的なパラメータです。

- FLASHBACK_SCNパラメータは、Oracle Databaseのフラッシュバック問合せ機能にのみ関係します。フラッシュバック・データベース、フラッシュバック削除およびフラッシュバック・データ・アーカイブには適用できません。

例

次の例では、384632 というSCN値が存在するとします。この例では、hrスキーマをSCN 384632までエクスポートします。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_scn.dmp FLASHBACK_SCN=384632

注意:

ロジカル・スタンバイ・システムにおいてロジカル・スタンバイのプライマリへのアクセスにネットワーク・リンクを使用する場合は、ロジカル・スタンバイによってSCNが選択されるため、FLASHBACK_SCNパラメータは無視されます。ロジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。

FLASHBACK_TIME

デフォルト: デフォルト値は設定されていません。

用途

指定された時刻に最も近いSCNを検出し、このSCNを使用してフラッシュバック・ユーティリティを使用可能にします。エクスポート操作は、このSCNまでの一貫性のあるデータを使用して実行されます。

構文および説明

FLASHBACK_TIME="TO_TIMESTAMP(time-value)"

TO_TIMESTAMPの値は引用符で囲まれるため、パラメータ・ファイルに記述することをお薦めします。詳細は、「データ・ポンプ・コマンドラインでの引用符の使用」を参照してください。

制限事項

- FLASHBACK_TIMEおよびFLASHBACK_SCNは、相互に排他的なパラメータです。

- FLASHBACK_TIMEパラメータは、Oracle Databaseのフラッシュバック問合せ機能にのみ関係します。フラッシュバック・データベース、フラッシュバック削除およびフラッシュバック・データ・アーカイブには適用できません。

例

DBMS_FLASHBACK.ENABLE_AT_TIMEプロシージャで使用可能な形式で時刻を指定できます。たとえば、次の内容のパラメータ・ファイルflashback.parを作成したとします。

DIRECTORY=dpump_dir1
DUMPFILE=hr_time.dmp
FLASHBACK_TIME="TO_TIMESTAMP('27-10-2012 13:16:00', 'DD-MM-YYYY HH24:MI:SS')"

次のコマンドを発行します。

> expdp hr PARFILE=flashback.par

エクスポート操作は、指定した時間に最も近いSCNと整合性のあるデータで実行されます。

注意:

ロジカル・スタンバイ・システムにおいてロジカル・スタンバイのプライマリへのアクセスにネットワーク・リンクを使用する場合は、ロジカル・スタンバイによってSCNが選択されるため、FLASHBACK_SCNパラメータは無視されます。ロジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。

関連項目:

フラッシュバック問合せの使用方法の詳細は、『Oracle Database開発ガイド』を参照してください。

FULL

デフォルト: NO

用途

全体データベース・モード・エクスポートの実行を指定します。

構文および説明

FULL=[YES | NO]

FULL=YESと指定すると、すべてのデータおよびメタデータがエクスポートされます。全体エクスポートを実行するには、DATAPUMP_EXP_FULL_DATABASEロールが必要です。

このエクスポート・モードを使用したエクスポート対象を、フィルタ処理によって制限できます。詳細は、「エクスポート操作中のフィルタ処理」を参照してください。

トランスポータブル・オプション(TRANSPORTABLE=ALWAYS)を使用して全体モード・エクスポートを実行できます。これは、全体トランスポータブル・エクスポートと呼ばれ、データベースの完全なコピーを作成するために必要なすべてのオブジェクトおよびデータがエクスポートされます。「全体モード・エクスポート時のトランスポータブル・オプションの使用」を参照してください。

注意:

全体モード・エクスポートによって作成されたダンプ・ファイルを後でインポートする場合、インポート操作はSYSアカウントのパスワードをソース・データベースからコピーしようとすることに注意してください。これは、失敗する場合があります(パスワードが共有パスワード・ファイル内にある場合など)。失敗した場合は、インポートの完了後に、ターゲット・データベース上のSYSアカウントのパスワードを任意のパスワードに設定する必要があります。

制限事項

- FULLパラメータをTRANSPORTABLE (全体トランスポータブル・エクスポート)と組み合せて使用するには、データ・ポンプのVERSIONパラメータを12.0以上に設定するか、COMPATIBLEデータベース初期化パラメータを12.0以上に設定する必要があります。

- 全体エクスポートでは、Oracleが管理するデータおよびメタデータを含むシステム・スキーマがデフォルトでエクスポートされません。デフォルトでエクスポートされないシステム・スキーマの例としては、SYS、ORDSYS、MDSYSなどがあります。

- SYSスキーマが所有しているオブジェクトに対する権限はエクスポートされません。

- 全体エクスポート操作では、1つのデータベース・エディションのみからオブジェクトがエクスポートされ、デフォルトでは現在のエディションがエクスポートされますが、エクスポートのSOURCE_EDITIONパラメータを使用して別のエディションを指定することもできます。

- レルムにより保護されているデータをエクスポートする場合は、そのレルムに対する権限が必要です。

- 自動ワークロード・リポジトリ(AWR)は、全データベースのエクスポートおよびインポート操作では移動されません。(データ・ポンプを使用してAWRスナップショットを移動する方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。)

- XDBリポジトリは、全データベースのエクスポートおよびインポート操作では移動されません。ユーザーが作成したXMLスキーマは移動されます。

例

次に、FULLパラメータの使用例を示します。ダンプ・ファイルexpfull.dmpは、dpump_dir2ディレクトリに書き込まれます。

> expdp hr DIRECTORY=dpump_dir2 DUMPFILE=expfull.dmp FULL=YES NOLOGFILE=YES

関連項目:

- 全体トランスポータブル・エクスポートの実行方法の詳細な例は、『Oracle Database管理者ガイド』を参照してください。

- レルムの構成の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

HELP

デフォルト: NO

用途

エクスポート・ユーティリティのオンライン・ヘルプを表示します。

構文および説明

HELP = [YES | NO]

HELP=YESが指定されている場合は、エクスポート・ユーティリティによって、そのすべてのコマンドライン・パラメータと対話方式コマンドの要約が表示されます。

例

> expdp HELP = YES

この例では、すべてのエクスポート・パラメータおよびコマンドの簡単な説明が表示されます。

INCLUDE

デフォルト: デフォルト値は設定されていません。

用途

現行のエクスポート・モードにオブジェクトとオブジェクト型を指定して、エクスポート対象のメタデータをフィルタ処理できます。指定したオブジェクトおよびこれらのオブジェクトのすべての依存オブジェクトがエクスポートされます。これらのオブジェクトに対する権限もエクスポートされます。

構文および説明

INCLUDE = object_type[:name_clause] [, ...]

object_typeは含めるオブジェクトのタイプを指定します。DATABASE_EXPORT_OBJECTS(全体モードの場合)、SCHEMA_EXPORT_OBJECTS(スキーマ・モードの場合)、TABLE_EXPORT_OBJECTS(表および表領域モードの場合)ビューを問い合せて、object_typeの有効な値の一覧を表示できます。OBJECT_PATH列にリストされる値が有効なオブジェクト・タイプです。(このような問合せの実行方法の例は、「メタデータのフィルタ」を参照してください。)

INCLUDE文で明示的に指定されたオブジェクト型とその依存オブジェクトのみがエクスポートされます。他のオブジェクト型(通常、DATAPUMP_EXP_FULL_DATABASEロールを所有している場合にスキーマ・モード・エクスポートの一部となるスキーマ定義情報など)はエクスポートされません。

name_clauseは、オプションです。これを使用すると、あるオブジェクト型のうち、特定のオブジェクトをファイングレイン選択できます。その型のオブジェクト名に対するフィルタとして使用されるSQL式です。SQL演算子および指定した型のオブジェクト名の比較対象となる値で構成されています。このname_clauseは、名前付きのインスタンスを持つオブジェクト型にのみ適用されます(たとえば、TABLEには適用されますが、GRANTには適用されません)。それは、コロンでオブジェクト型と区切り、二重引用符(一重引用符は名前文字列を区切るために必要なため)で囲む必要があります。

name_clauseに指定する名前は、データベース内の既存のオブジェクトに、大文字と小文字も含めて完全に一致させる必要があります。たとえば、指定するname_clauseがEMPLOYEESという表に対するものだった場合は、すべてが大文字のEMPLOYEESという表が存在する必要があります。name_clauseに対してEmployees、employeesなどを指定した場合、表は検出されません。

オペレーティング・システムによっては、このパラメータの値を指定するときに引用符とともにエスケープ文字を使用する必要があります。このパラメータはパラメータ・ファイルで指定することをお薦めします。パラメータ・ファイルを使用すると、コマンドラインでは必要なエスケープ文字の数を減らすことができます。詳細は、「データ・ポンプ・コマンドラインでの引用符の使用」を参照してください。

たとえば、次の内容のパラメータ・ファイルhr.parを作成したとします。

SCHEMAS=HR
DUMPFILE=expinclude.dmp
DIRECTORY=dpump_dir1
LOGFILE=expinclude.log
INCLUDE=TABLE:"IN ('EMPLOYEES', 'DEPARTMENTS')"
INCLUDE=PROCEDURE
INCLUDE=INDEX:"LIKE 'EMP%'"

この場合、コマンドラインで他のパラメータを入力しなくても、hr.parファイルを使用してエクスポート操作を開始できます。EMPLOYEESとDEPARTMENTS表、すべてのプロシージャおよびEMP接頭辞を持つすべての索引名が、エクスポートに含まれます。

> expdp hr PARFILE=hr.par

制約の追加

指定したobject_typeがCONSTRAINTである場合は、次に説明する影響があることに注意してください。

次の制約を明示的に含めることはできません。

- NOT NULL制約

- 表の作成とロードを正常に行うために必要な制約。たとえば、索引構成表の主キー制約、REF列を持つ表のREF SCOPEおよびWITH ROWID制約など

次に、INCLUDE文の例およびその解釈を示します。

- INCLUDE=CONSTRAINTは、NOT NULL制約および表の正常な作成およびロードに必要な制約を除き、すべての制約(非参照)を含めます。

- INCLUDE=REF_CONSTRAINTは、参照整合性(外部キー)制約を含めます。

制限事項

- INCLUDEおよびEXCLUDEは、相互に排他的なパラメータです。

- SYSスキーマが所有しているオブジェクトに対する権限はエクスポートされません。

例

次の例では、hrスキーマのすべての表(およびその依存オブジェクト)をエクスポートします。

> expdp hr INCLUDE=TABLE DUMPFILE=dpump_dir1:exp_inc.dmp NOLOGFILE=YES

JOB_NAME

デフォルト: SYS_EXPORT_<mode>_NNという書式のシステム生成による名前

用途

ジョブへの接続にATTACHパラメータを使用したり、DBA_DATAPUMP_JOBSまたはUSER_DATAPUMP_JOBSビューを使用してジョブを指定する場合など、後続処理でエクスポート・ジョブを指定するために使用されます。

構文および説明

JOB_NAME=jobname_string

jobname_stringには、このエクスポート・ジョブの名前を、30バイト以内で指定します。これらのバイトは印字可能文字と空白を表します。空白を含む場合は、一重引用符で囲みます(たとえば、'Thursday Export'とします)。ジョブ名は、エクスポート操作を実行しているユーザーのスキーマによって暗黙的に修飾されます。ジョブ名は、マスター表の名前として使用されます(マスター表はエクスポート・ジョブを制御します)。

デフォルトのジョブ名はSYS_EXPORT_<mode>_NNという形式で、システムによって生成されます。NNは、01から始めて増加する2桁の整数です。デフォルト名は、'SYS_EXPORT_TABLESPACE_02'などです。

例

次に、ジョブ名exp_jobを割り当てるエクスポート操作の例を示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=exp_job.dmp JOB_NAME=exp_job
NOLOGFILE=YES

KEEP_MASTER

デフォルト: NO

用途

正常に完了したデータ・ポンプ・ジョブの最後に、マスター表を削除するか、または保持するかを示します。ジョブが正常に完了しなかった場合、マスター表は自動的に保持されます。

構文および説明

KEEP_MASTER=[YES | NO]

制限事項

- 「なし」

例

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=expdat.dmp SCHEMAS=hr KEEP_MASTER=YES

LOGFILE

デフォルト: export.log

用途

エクスポート・ジョブのログ・ファイルの名前を指定します。また、オプションで、そのログ・ファイルを格納するディレクトリを指定します。

構文および説明

LOGFILE=[directory_object:]file_name

directory_objectには、DBAによって作成済であるデータベースのディレクトリ・オブジェクトを指定できます(そのオブジェクトへのアクセス権がある場合)。この指定は、DIRECTORYパラメータに指定されたディレクトリ・オブジェクトよりも優先されます。

file_nameには、ログ・ファイル名を指定します。デフォルトでは、DIRECTORYパラメータで指定されたディレクトリ・オブジェクトが示すディレクトリに、export.logというファイルが作成されます。

処理中の作業、完了した作業および発生したエラーに関するすべてのメッセージがログ・ファイルに書き込まれます。(ジョブのリアルタイムの状態を把握するには、対話方式モードでSTATUSコマンドを使用します。)

NOLOGFILEパラメータを指定しないかぎり、エクスポート・ジョブには、常にログ・ファイルが作成されます。ダンプ・ファイル・セットと同様に、ログ・ファイルの基準となるのは、クライアントではなく、サーバーです。

このファイル名と一致する既存のファイルは上書きされます。

制限事項

- Oracle Automatic Storage Management (Oracle ASM)を使用してデータ・ポンプ・エクスポートを実行する場合、LOGFILEパラメータは、Oracle ASMの+表記法を使用せずにディレクトリ・オブジェクトを指定する必要があります。つまり、ログ・ファイルはディスク・ファイルに書き込まれ、Oracle ASMの記憶域には書き込まれません。かわりに、NOLOGFILE=YESを指定することもできます。ただし、この場合はログ・ファイルの書込みは行われません。

例

次の例に、デフォルトの名前を使用しない場合に、ログ・ファイル名を指定する方法を示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp LOGFILE=hr_export.log

注意:

データ・ポンプ・エクスポート・ユーティリティは、データベースのキャラクタ・セットを使用してログ・ファイルに書込みを行います。クライアントのNLS_LANG環境設定がデータベースのキャラクタ・セットと異なるキャラクタ・セットの場合は、ログ・ファイル内の表の名前が、クライアントの出力画面に表示される名前と異なることがあります。

関連項目:

- 「STATUS」

- Oracle Automatic Storage Managementおよびディレクトリ・オブジェクトの詳細は、「Oracle Automatic Storage Managementを使用可能にした場合のディレクトリ・オブジェクトの使用方法」を参照してください

LOGTIME

デフォルト: タイムスタンプは記録されません。

用途

エクスポート操作中に表示されるメッセージにタイムスタンプを付けるように指定します。 タイムスタンプを使用して、データ・ポンプ操作の異なるフェーズ間の経過時間を計算できます。この情報は、パフォーマンス問題を診断する場合や、将来の同じような操作の時間を見積もる場合に役立ちます。

構文および説明

LOGTIME=[NONE | STATUS | LOGFILE | ALL]

使用可能なオプションの定義は次のとおりです。

- NONE: ステータス・メッセージまたはログ・ファイル・メッセージにタイムスタンプを付けません(デフォルトと同じ)。

- STATUS: ステータス・メッセージにのみタイムスタンプを付けます。

- LOGFILE: ログ・ファイル・メッセージにのみタイムスタンプを付けます。

- ALL: ステータス・メッセージとログ・ファイル・メッセージの両方にタイムスタンプを付けます。

制限事項

- 「なし」

例

次の例では、エクスポート操作中に表示されるすべてのステータス・メッセージとログ・ファイル・メッセージにタイムスタンプを記録します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=expdat.dmp SCHEMAS=hr LOGTIME=ALL

出力は、次のようになります。

10-JUL-12 10:12:22.300: Starting "HR"."SYS_EXPORT_SCHEMA_01":  hr/******** directory=dpump_dir1 dumpfile=expdat.dmp schemas=hr logtime=all
10-JUL-12 10:12:22.915: Estimate in progress using BLOCKS method...
10-JUL-12 10:12:24.422: Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
10-JUL-12 10:12:24.498: Total estimation using BLOCKS method: 128 KB
10-JUL-12 10:12:24.822: Processing object type SCHEMA_EXPORT/USER
10-JUL-12 10:12:24.902: Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
10-JUL-12 10:12:24.926: Processing object type SCHEMA_EXPORT/ROLE_GRANT
10-JUL-12 10:12:24.948: Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
10-JUL-12 10:12:24.967: Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
10-JUL-12 10:12:25.747: Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
10-JUL-12 10:12:32.762: Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
10-JUL-12 10:12:46.631: Processing object type SCHEMA_EXPORT/TABLE/TABLE
10-JUL-12 10:12:58.007: Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
10-JUL-12 10:12:58.106: Processing object type SCHEMA_EXPORT/TABLE/COMMENT
10-JUL-12 10:12:58.516: Processing object type SCHEMA_EXPORT/PROCEDURE/PROCEDURE
10-JUL-12 10:12:58.630: Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
10-JUL-12 10:12:59.365: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
10-JUL-12 10:13:01.066: Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
10-JUL-12 10:13:01.143: Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
10-JUL-12 10:13:02.503: Processing object type SCHEMA_EXPORT/VIEW/VIEW
10-JUL-12 10:13:03.288: Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
10-JUL-12 10:13:04.067: Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
10-JUL-12 10:13:05.251: Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
10-JUL-12 10:13:06.172: . . exported "HR"."EMPLOYEES"                            17.05 KB     107 rows
10-JUL-12 10:13:06.658: . . exported "HR"."COUNTRIES"                            6.429 KB      25 rows
10-JUL-12 10:13:06.691: . . exported "HR"."DEPARTMENTS"                          7.093 KB      27 rows
10-JUL-12 10:13:06.723: . . exported "HR"."JOBS"                                 7.078 KB      19 rows
10-JUL-12 10:13:06.758: . . exported "HR"."JOB_HISTORY"                          7.164 KB      10 rows
10-JUL-12 10:13:06.794: . . exported "HR"."LOCATIONS"                            8.398 KB      23 rows
10-JUL-12 10:13:06.824: . . exported "HR"."REGIONS"                              5.515 KB       4 rows
10-JUL-12 10:13:07.500: Master table "HR"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
10-JUL-12 10:13:07.503: ******************************************************************************

METRICS

デフォルト: NO

用途

ジョブに関する詳細情報をデータ・ポンプ・ログ・ファイルに記録するかどうかを示します。

構文および説明

METRICS=[YES | NO]

METRICS=YESを使用すると、オブジェクト数および経過時間がデータ・ポンプ・ログ・ファイルに記録されます。

制限事項

- 「なし」

例

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=expdat.dmp SCHEMAS=hr METRICS=YES

NETWORK_LINK

デフォルト: デフォルト値は設定されていません。

用途

有効なデータベース・リンクによって指定される(ソース)データベースからのエクスポートを使用可能にします。ソース・データベース・インスタンスのデータは、接続されたデータベース・インスタンスのダンプ・ファイル・セットに書き込まれます。

構文および説明

NETWORK_LINK=source_database_link

NETWORK_LINKパラメータは、データベース・リンクを使用してエクスポートを開始します。つまり、expdpクライアントの接続先となるシステムから、source_database_linkで指定されたソース・データベースに接続し、そこからデータを取り出して、接続されたシステムのダンプ・ファイルに書き込みます。

source_database_linkには、使用可能なデータベースへのデータベース・リンク名を指定する必要があります。対象インスタンスのデータベースにデータベース・リンクが指定されていない場合、ユーザーまたはDBAが、SQL CREATE DATABASE LINK文を使用してデータベース・リンクを作成する必要があります。

ソース・データベースが読取り専用の場合、ソース・データベースのユーザーは、デフォルト一時表領域として割り当てられたローカル管理一時表領域を持つ必要があります。それ以外の場合、ジョブは失敗します。

データ・ポンプ・エクスポートでは、次のタイプのデータベース・リンクの使用がサポートされています。

- パブリック固定ユーザー

- パブリック接続ユーザー

- パブリック共有ユーザー(リンク所有者が使用する場合のみ)

- プライベート共有ユーザー(リンク所有者が使用する場合のみ)

- プライベート固定ユーザー(リンク所有者が使用する場合のみ)

注意:

暗号化されていないネットワーク・リンクを介してエクスポート操作が行われる場合、すべてのデータはクリア・テキストとしてエクスポートされます。これは、データがデータベースで暗号化されている場合でも同様です。ネットワーク・セキュリティの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

制限事項

- データ・ポンプ・エクスポートでは、次のタイプのデータベース・リンクの使用はサポートされません。

- プライベート接続ユーザー

- 現行ユーザー

- ネットワーク・エクスポートでは、LONG列がサポートされていません。

- 全体トランスポータブル・エクスポートを使用してネットワークを介してデータベースを転送する場合、管理表領域(SYSTEMやSYSAUXなど)に存在するLONGまたはLONG RAW列を含む表は、サポートされません。

- 全体トランスポータブル・エクスポートを使用してネットワークを介してデータベースを転送する場合、監査証跡情報自体がユーザー定義の表領域に格納されていると、管理表領域(SYSTEMやSYSAUXなど)に格納された表に対して監査を有効にすることはできません。

- データ・ポンプ操作がネットワーク・リンクを介して行われる場合、ソース・データベースとターゲット・データベースのバージョンの差違が2バージョン以下である必要があります。たとえば、一方のデータベースがOracle Database 12cの場合、他方のデータベースは12c、11gまたは10gである必要があります。データ・ポンプがチェックするのはメジャー・バージョン番号のみ(10g、11g、12cなど)で、具体的なリリース番号(12.1、10.1、10.2、11.1、11.2など)ではありません。

例

次に、NETWORK_LINKパラメータの使用例を示します。source_database_linkには、すでに存在する有効なデータベース・リンク名を指定します。

> expdp hr DIRECTORY=dpump_dir1 NETWORK_LINK=source_database_link
DUMPFILE=network_export.dmp LOGFILE=network_export.log

関連項目:

- データベース・リンクの詳細は、Oracle Database管理者ガイドを参照してください。

- CREATE DATABASE LINK文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- ローカル管理表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

NOLOGFILE

デフォルト: NO

用途

ログ・ファイルを作成するかどうかを指定します。

構文および説明

NOLOGFILE=[YES | NO]

デフォルトでログ・ファイルを作成しないようにするには、NOLOGFILE=YESを指定します。ただし、進捗とエラーに関する情報は、接続されているいずれかのクライアント(元のエクスポート操作を開始したクライアントを含む)の標準出力デバイスに書き込まれます。実行中のジョブに接続されているクライアントが存在しないときにNOLOGFILE=YESを指定すると、重要な進捗情報およびエラー情報が失われる危険性があります。

例

次に、NOLOGFILEパラメータの使用例を示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp NOLOGFILE=YES

このコマンドによって、ログ・ファイルの書込みを行わないスキーマ・モード・エクスポート(デフォルト)が実行されます。

PARALLEL

デフォルト: 1

用途

エクスポート・ジョブのために動作するアクティブな実行プロセスの最大数を指定します。この実行セットはワーカー・プロセスおよびパラレルI/Oサーバーの処理の組合せで構成されています。パラレル問合せ操作で問合せコーディネータとして動作するマスター制御プロセスおよびワーカー・プロセスは、この合計数には加算されません。

このパラメータを使用して、リソース消費と経過時間のバランスをとることができます。

構文および説明

PARALLEL=integer

integerに指定する値は、ダンプ・ファイル・セット内のファイル数以下にする必要があります(または、ダンプ・ファイル指定に置換変数を指定する必要があります)。アクティブなワーカー・プロセスまたはI/Oサーバー・プロセスは、1つのファイルに対してそれぞれが同時に排他的に書込みを行うため、ファイル数が不足していると、逆効果になります。ファイルの待機中に、一部のワーカー・プロセスがアイドル状態になるため、そのジョブの全体的なパフォーマンスが低下します。また、パラレルI/Oサーバー・プロセスを共有で実行しているメンバーが出力用ファイルを取得できない場合は、ORA-39095エラーを返してエクスポート操作が停止します。いずれの場合も、データ・ポンプ・エクスポート・ユーティリティを使用してジョブに接続することによって、問題を解決できます。接続後、対話方式モードで、ADD_FILEコマンドを使用してファイルを追加し、ジョブが停止した場合は、ジョブを再開します。

ジョブの実行中にPARALLELの値を増減するには、対話方式コマンド・モードを使用します。並列度を下げても、ジョブに関連付けられたワーカー・プロセスは減少しません。任意の時点で実行されるワーカー・プロセスの数が減少します。また、プロセス数が減少する前に、継続中の処理が適正な完了ポイントに到達する必要があります。そのため、値を小さくした効果の確認に時間がかかる場合があります。アイドル状態のワーカーは、ジョブが終了するまで削除されません。

パラレル実行できる処理が存在する場合、並列度の増加はすぐに反映されます。

Oracle RAC環境でのエクスポートにおけるPARALLELの使用

Oracle Real Application Clusters(Oracle RAC)環境内でPARALLEL=1としてエクスポート操作を実行すると、すべてのデータ・ポンプ・プロセスは、ジョブが開始されたインスタンス上に配置されます。そのため、ディレクトリ・オブジェクトは、そのインスタンスのローカル記憶域を示すことができます。

PARALLELを1より大きな値に設定してエクスポート操作を実行する場合は、ジョブが開始されたインスタンス以外のインスタンスにもデータ・ポンプ・プロセスを置くことができます。そのため、ディレクトリ・オブジェクトは、Oracle RACのすべてのインスタンスからアクセス可能な共有記憶域を示す必要があります。

制限事項

- このパラメータは、Oracle Database 11g以上のEnterprise Editionでのみ有効です。

- 表および表パーティションを、パラレルで(PQスレーブを使用して)エクスポートするには、DATAPUMP_EXP_FULL_DATABASEロールが必要です。

例

次に、PARALLELパラメータの使用例を示します。

> expdp hr DIRECTORY=dpump_dir1 LOGFILE=parallel_export.log
JOB_NAME=par4_job DUMPFILE=par_exp%u.dmp PARALLEL=4

この例では、hrスキーマのスキーマ・モード・エクスポート(デフォルトのモード)が実行され、ディレクトリ・オブジェクトdpump_dir1に指定されたパスに、最大で4つのファイルが作成されます。

関連項目:

- 「リソース消費の制御」

- 「DUMPFILE」

- 「エクスポート・ユーティリティの対話方式コマンド・モードで使用可能なコマンド」

- 「パラレル全データベース・エクスポートの実行」

PARFILE

デフォルト: デフォルト値は設定されていません。

用途

エクスポート・パラメータ・ファイルの名前を指定します。

構文および説明

PARFILE=[directory_path]file_name

パラメータ・ファイルでは、ファイル内にデータ・ポンプ・パラメータを指定して、すべてのコマンドを個別に入力するかわりにそのファイルをコマンドラインに指定できます。これは、同じパラメータの組合せを何度も使用する場合に便利です。値の指定に引用符が必要なパラメータを使用する場合も、パラメータ・ファイルを使用することをお薦めします。

サーバーによって作成されて書き込まれるダンプ・ファイル、ログ・ファイルおよびSQLファイルとは異なり、パラメータ・ファイルはexpdpクライアントによって開かれて読み取られるため、パラメータ・ファイルにディレクトリ・オブジェクトは指定されません。パラメータ・ファイルのデフォルトの場所は、ユーザーのカレント・ディレクトリです。

パラメータ・ファイル内では、カンマはすべての改行文字に暗黙的に含まれるため、各行の最後にカンマを入力する必要はありません。長い表名など、折返しを含む長い行がある場合、現在の行の最後にバックスラッシュ継続文字(\)を入力して次の行に継続します。

制限事項

- PARFILEパラメータは、パラメータ・ファイル内には指定できません。

例

パラメータ・ファイルhr.parの内容は、次のとおりです。

SCHEMAS=HR
DUMPFILE=exp.dmp
DIRECTORY=dpump_dir1
LOGFILE=exp.log

このパラメータ・ファイルを指定するには、次のExportコマンドを実行します。

> expdp hr PARFILE=hr.par

関連項目:

「データ・ポンプ・コマンドラインでの引用符の使用」

QUERY

デフォルト: デフォルト値は設定されていません。

用途

エクスポート対象となるデータをフィルタ処理するために使用する問合せ句を指定できます。

構文および説明

QUERY = [schema.][table_name:] query_clause

通常、query_clauseでは、ファイングレイン行選択のためのSQL WHERE句を使用しますが、任意のSQL句を使用できます。たとえば、ORDER BY句を使用すると、ヒープ構成表から索引構成表への移行を高速化できます。スキーマおよび表名を指定しなかった場合は、エクスポート・ジョブ内のすべての表に問合せが適用されます(この場合、問合せは、これらのすべての表に対して有効である必要があります)。表固有の問合せは、すべての表に適用される問合せより優先されます。

特定の表に問合せを適用する場合は、表名と問合せ句をコロンで区切る必要があります。表固有の問合せは複数指定できますが、1つの表に指定できるのは1つの問合せのみです。

QUERYパラメータと一緒にNETWORK_LINKパラメータを指定する場合、リモート(ソース)ノード上にあるquery_clauseで指定されるすべてのオブジェクトは、NETWORK_LINK値で明示的に修飾する必要があります。それ以外の場合、データ・ポンプではオブジェクトがローカル(ターゲット)ノード上に存在することを前提とし、存在しない場合はエラーが返され、リモート(ソース)システムからの表のインポートは失敗します。

たとえば、NETWORK_LINK=dblink1と指定した場合、QUERYパラメータのquery_clauseは、次の例に示すようにそのリンクを指定する必要があります。

QUERY=(hr.employees:"WHERE last_name IN(SELECT last_name
FROM hr.employees@dblink1)")

オペレーティング・システムによっては、このパラメータの値を指定するときに引用符とともにエスケープ文字を使用する必要があります。このパラメータはパラメータ・ファイルで指定することをお薦めします。パラメータ・ファイルを使用すると、コマンドラインでは必要なエスケープ文字の数を減らすことができます。詳細は、「データ・ポンプ・コマンドラインでの引用符の使用」を参照してください。

表固有の問合せで自分のスキーマ以外のスキーマを指定するには、その特定の表に対するアクセス権限が付与されている必要があります。

制限事項

- QUERYパラメータは次のパラメータとは併用できません。

- CONTENT=METADATA_ONLY

- ESTIMATE_ONLY

- TRANSPORT_TABLESPACES

- 表にQUERYパラメータが指定されている場合、データ・ポンプは外部表を使用してターゲット表をアンロードします。外部表は、SQL CREATE TABLE AS SELECT文を使用します。QUERYパラメータの値は、CREATE TABLE文のSELECT部分にあるWHERE句です。QUERYパラメータにアンロードする表と一致する名前の列がある他の表への参照が含まれていて、これらの列が問合せで使用される場合は、表別名を使用して、アンロードする表内の列と、SELECT文内の同じ名前を持つ列を区別する必要があります。アンロードする表に対してデータ・ポンプで使用される表別名は、KU$です。
たとえば、sh.customers表にある顧客のクレジットの上限に基づいてsh.sales表のサブセットをエクスポートするとします。次の例では、KU$を使用して、sh.salesをアンロードするためにQUERYパラメータ内のcust_idフィールドを修飾します。この結果、データ・ポンプによって、クレジットの上限が$10,000を超える顧客の行のみがエクスポートされます。

QUERY='sales:"WHERE EXISTS (SELECT cust_id FROM customers c
WHERE cust_credit_limit > 10000 AND ku$.cust_id = c.cust_id)"'

次の問合せのように、表別名としてKU$を使用しないと、すべての行がアンロードされることになります。

QUERY='sales:"WHERE EXISTS (SELECT cust_id FROM customers c
WHERE cust_credit_limit > 10000 AND cust_id = c.cust_id)"'

- QUERYに使用できる文字列の最大長は、引用符を含めて4000バイトです。つまり、許容される実際の最大長は3998バイトです。

例

次に、QUERYパラメータの使用例を示します。

> expdp hr PARFILE=emp_query.par

emp_query.parファイルの内容は次のとおりです。

QUERY=employees:"WHERE department_id > 10 AND salary > 10000"
NOLOGFILE=YES
DIRECTORY=dpump_dir1
DUMPFILE=exp1.dmp

この例では、hrスキーマのすべての表がアンロードされます。ただし、アンロードされるのは、問合せ式に適合する行のみです。この場合、hrスキーマ内のすべての表(employeesを除く)のすべての行がアンロードされます。employees表に対しては、問合せ基準を満たす行のみがアンロードされます。

REMAP_DATA

デフォルト: デフォルト値は設定されていません。

用途

REMAP_DATAパラメータを使用すると再マップ・ファンクションを指定できます。これにより、指定した列の元の値をソースとして再マップした値を返し、ダンプ・ファイル内の元の値をこの値に置き換えます。このオプションは、一般的に、本番システムからテスト・システムへ移動するときにデータをマスクするために使用されます。たとえば、クレジット・カード番号などの顧客の機密データの列を、REMAP_DATAファンクションで生成された番号に置き換えることができます。これにより、権限のないユーザーに個人データを公開することなく、データで必要な書式と処理特性を保持できます。

同じファンクションを、ダンプされる複数の列に適用できます。これは、参照制約で子と親両方の列を再マップするときに整合性を保つ必要がある場合に役立ちます。

構文および説明

REMAP_DATA=[schema.]tablename.column_name:[schema.]pkg.function

次に、各構文要素の説明を構文で出現する順に示します。

schema: 再マップされる表を含むスキーマ。デフォルトでは、これはエクスポートを実行するユーザーのスキーマです。

tablename: 列の再マップが行われる表。

column_name: データの再マップが行われる列。

schema: 再マップ・ファンクションを含むユーザー作成のPL/SQLパッケージを含むスキーマ。デフォルトでは、これはエクスポートを実行するユーザーのスキーマです。

pkg: 再マップ・ファンクションを含むユーザー作成のPL/SQLパッケージの名前。

function: 指定した表の各行で、列表を再マップする場合にコールされるPL/SQL内のファンクションの名前。

制限事項

- ソース引数および戻り値のデータ型はともに、表内の指定した列のデータ型と一致している必要があります。

- 再マップ・ファンクションでは、自律型トランザクション以外のコミットまたはロール・バックを実行できません。

- REMAP_DATAパラメータの値としてのシノニムの使用はサポートされていません。たとえば、hrスキーマ内のregions表にregnのシノニムがある場合は、regnをREMPA_DATA仕様の一部として指定した場合にエラーが返されます。

- リモート表のLOB列データの再マップはサポートされていません。

- 型がユーザー定義型、ユーザー定義型の属性、LONG、REF、VARRAY、ネストした表、BFILEおよびXMLtypeの列は、REMAP_DATAでサポートされません。

例

次の例では、minus10およびplusxという名前のファンクションを格納するremapという名前のパッケージが作成されており、これらのファンクションはemployees表内のemployee_idおよびfirst_nameの値を変更すると想定しています。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=remap1.dmp TABLES=employees
REMAP_DATA=hr.employees.employee_id:hr.remap.minus10
REMAP_DATA=hr.employees.first_name:hr.remap.plusx

REUSE_DUMPFILES

デフォルト: NO

用途

すでに存在しているダンプ・ファイルを上書きするかどうかを指定します。

構文および説明

REUSE_DUMPFILES=[YES | NO]

通常、データ・ポンプ・エクスポートは、すでに存在するダンプ・ファイル名を指定するとエラーを返します。REUSE_DUMPFILESパラメータを使用すると、動作を変更してダンプ・ファイル名を再利用できます。たとえば、エクスポートを実行してDUMPFILE=hr.dmpおよびREUSE_DUMPFILES=YESを指定した場合、hr.dmpがすでに存在するときは、このファイルが上書きされます。このファイルの前の内容は消去され、かわりに現行のエクスポートのデータが格納されます。

例

次のエクスポート操作では、enc1.dmpという名前のダンプ・ファイルが作成されます。これは、この名前の付いたダンプ・ファイルがすでに存在する場合でも同様です。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=enc1.dmp
TABLES=employees REUSE_DUMPFILES=YES

SAMPLE

デフォルト: デフォルト値は設定されていません。

用途

サンプリングしてソース・データベースからアンロードするデータ行の割合を指定できます。

構文および説明

SAMPLE=[[schema_name.]table_name:]sample_percent

このパラメータを使用すると、サンプリングしてエクスポートするデータの割合を指定し、データのサブセットをエクスポートできます。sample_percentは、行がサンプルの一部として選択される可能性を示します。ただし、指定した正確な行数が表から取り出されるわけではありません。sample_percentには、0.000001から100未満の任意の数を指定できます。

sample_percentは特定の表に適用することができます。次の例では、HR.EMPLOYEES表の50%がエクスポートされます。

SAMPLE="HR"."EMPLOYEES":50

スキーマを指定する場合は、表も指定する必要があります。ただし、スキーマを指定せずに表を指定することはできます(その場合は、現在のユーザーが使用されます)。表の指定がない場合は、エクスポート・ジョブ全体にsample_percent値が適用されます。

このパラメータとデータ・ポンプ・インポートのPCTSPACE変換を組み合せて使用すると、記憶域の割当てサイズをサンプリングされたデータ・サブセットに合わせることができます。(詳細は、インポートの「TRANSFORM」パラメータを参照してください。)

制限事項

- SAMPLEパラメータは、ネットワークのエクスポートに対して無効です。

例

次の例では、表の名前が指定されていないため、全体のエクスポート・ジョブにSAMPLE値70が適用されます。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=sample.dmp SAMPLE=70

SCHEMAS

デフォルト: 現在のユーザーのスキーマ

用途

スキーマ・モード・エクスポートの実行を指定します。これは、エクスポートのデフォルトのモードです。

構文および説明

SCHEMAS=schema_name [, ...]

DATAPUMP_EXP_FULL_DATABASEロールがある場合、自分のスキーマ以外の単一のスキーマまたはスキーマ名のリストを指定できます。DATAPUMP_EXP_FULL_DATABASEロールでは、インポート時にスキーマを再作成できるように、指定した各スキーマのスキーマ・オブジェクト以外の補足情報をエクスポートすることもできます。この補足情報には、ユーザー定義、関連するすべてのシステムおよびロールの権限、ユーザー・パスワードの履歴などが含まれます。スキーマ・モードを使用したエクスポート対象を、フィルタ処理によってより詳細に制限できます(詳細は、「エクスポート操作中のフィルタ処理」を参照してください)。

制限事項

- DATAPUMP_EXP_FULL_DATABASEロールを持っていない場合は、自分のスキーマのみ指定できます。

- SYSスキーマは、エクスポート・ジョブのソース・スキーマとして使用できません。

例

次に、SCHEMASパラメータの使用例を示します。前述の例でDATAPUMP_EXP_FULL_DATABASEロールがすでに割り当てられているため、ユーザーhrが複数のスキーマを指定できることに注意してください。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=expdat.dmp SCHEMAS=hr,sh,oe

このコマンドで、スキーマ・モード・エクスポートが実行され、dpump_dir1ディレクトリにあるexpdat.dmpダンプ・ファイルに、スキーマhr、shおよびoeが書き込まれます。

SERVICE_NAME

デフォルト: デフォルト値は設定されていません。

用途

CLUSTERパラメータと組み合せて使用するサービス名を指定するために使用します。

構文および説明

SERVICE_NAME=name

SERVICE_NAMEパラメータをCLUSTER=YESパラメータとともに使用して、リソース・グループに属しているOracle Real Application Clusters(Oracle RAC)インスタンス群(通常は全Oracle RACインスタンスのサブセット)を定義するリソース・グループに関連付けられている、既存のサービスを指定できます。

サービス名は、リソース・グループおよびそのリソース・グループに対して定義されたインスタンスを決定する目的でのみ使用されます。ジョブが開始されたインスタンスは、そのインスタンスがリソース・グループに含まれているかどうかとは関係なく、常に使用されます。

SERVICE_NAMEパラメータは、CLUSTER=NOと同時に指定されると、無視されます。

インスタンスA、B、CおよびDを含むOracle RAC構成があります。インスタンスA、BおよびCのみで構成されるリソース・グループを持つmy_serviceというサービスが存在するとします。そのような場合は、次の内容が成立します。

- データ・ポンプ・ジョブをインスタンスAで開始し、CLUSTER=YESを指定し(またはデフォルトのYをそのまま使用し)、SERVICE_NAMEパラメータを指定しなかった場合、データ・ポンプは、指定されている並列度に応じて、すべてのインスタンス(A、B、CおよびD)にワーカーを作成します。

- データ・ポンプ・ジョブをインスタンスAで開始し、CLUSTER=YESおよびSERVICE_NAME=my_serviceを指定した場合、ワーカーは、インスタンスA、BおよびCのみで開始可能です。

- データ・ポンプ・ジョブをインスタンスDで開始し、CLUSTER=YESおよびSERVICE_NAME=my_serviceを指定した場合、ワーカーは、インスタンスA、B、CおよびDのみで開始可能です。インスタンスDはmy_serviceに存在しませんが、インスタンスDはジョブが開始されたインスタンスであるため含まれています。

- データ・ポンプ・ジョブをインスタンスAで開始し、CLUSTER=NOを指定した場合、SERVICE_NAMEパラメータを指定しても無視され、すべてのプロセスがインスタンスAで開始されます。

例

次に、SERVICE_NAMEパラメータの使用例を示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_svname2.dmp SERVICE_NAME=sales

この例では、hrスキーマのスキーマ・モード・エクスポート(デフォルト・モード)を実行します。コマンドラインではCLUSTER=YESは指定されていませんが、それはデフォルトの動作なので、ジョブではサービス名salesに関連付けられたリソース・グループのすべてのインスタンスが使用されます。hr_svname2.dmpという名前のダンプ・ファイルが、dpump_dir1ディレクトリ・オブジェクトによって指定された場所に書き込まれます。

関連項目:

「CLUSTER」

SOURCE_EDITION

デフォルト: システム上のデフォルトのデータベース・エディション

用途

オブジェクトのエクスポート元のデータベース・エディションを指定します。

構文および説明

SOURCE_EDITION=edition_name

SOURCE_EDITION=edition_nameを指定すると、そのエディションのオブジェクトがエクスポートされます。データ・ポンプは、変更されずに継承されているすべてのオブジェクトと、変更されているすべての実際のオブジェクトを選択します。

このパラメータが指定されていない場合は、デフォルトのエディションが使用されます。指定されたエディションが存在しない場合や使用できない場合は、エラー・メッセージが返されます。

制限事項

- このパラメータは、バージョニング可能な同じオブジェクトのバージョンがデータベース内に2つ以上ある場合にのみ有効です。

- ジョブ・バージョンは、11.2以上である必要があります。「VERSION」を参照してください。

例

次に、SOURCE_EDITIONパラメータの使用例を示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=exp_dat.dmp SOURCE_EDITION=exp_edition EXCLUDE=USER

この例は、オブジェクトのエクスポート元となるexp_editionというエディションがシステム上に存在することを前提としています。エクスポート・モードは指定されていないため、デフォルトのスキーマ・モードが使用されます。EXCLUDE=userパラメータは、ユーザーの定義のみを除外します。ユーザーのスキーマに含まれるオブジェクトは除外されません。

関連項目:

- エディションの作成方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- エディション機能(継承されたオブジェクトと実際のオブジェクトも含む)の詳細は、『Oracle Database開発ガイド』を参照してください。

STATUS

デフォルト: 0

用途

ジョブ状態の表示が更新される頻度を指定します。

構文および説明

STATUS=[integer]

integerに値を入力すると、ロギング・モードでジョブの状態を表示する頻度を秒単位で指定できます。値を入力しなかった場合またはデフォルト値の0を使用した場合、各オブジェクト型、表またはパーティションの完了に関する情報のみ表示されます。

この状態情報は、標準出力デバイスのみに書き込まれ、ログ・ファイルには(使用可能な場合でも)書き込まれません。

例

次に、STATUSパラメータの使用例を示します。

> expdp hr DIRECTORY=dpump_dir1 SCHEMAS=hr,sh STATUS=300

この例では、hrおよびshスキーマをエクスポートし、エクスポート状態を5分ごと(60秒×5=300秒)に表示します。

TABLES

デフォルト: デフォルト値は設定されていません。

用途

表モード・エクスポートの実行を指定します。

構文および説明

TABLES=[schema_name.]table_name[:partition_name] [, ...]

このモードを使用したエクスポート対象を、フィルタ処理によってより詳細に制限できます(詳細は、「エクスポート操作中のフィルタ処理」を参照してください)。表およびパーティションまたはサブパーティションをカンマで区切ったリストを指定して、エクスポート対象のデータおよびメタデータをフィルタ処理できます。パーティションの名前を指定する場合は、関連表にあるパーティションまたはサブパーティションの名前にする必要があります。指定した表、パーティションおよびそれらの依存オブジェクトのみがアンロードされます。

パーティション表全体をエクスポートすると、パーティション表として全体的にインポートされます。これが当てはまらないのは、インポート時にPARTITION_OPTIONS=DEPARTITIONが指定されている場合のみです。

指定する表名の先頭にスキーマ名を修飾できます。デフォルトのスキーマは、現在のユーザーのスキーマです。自分のスキーマ以外のスキーマを指定するには、DATAPUMP_EXP_FULL_DATABASEロールが必要です。

ワイルドカード文字%を使用して、表名およびパーティション名を指定できます。

表名には次の制限があります。

- デフォルトでは、表名は大文字でデータベースに格納されます。表名が大文字と小文字または小文字のみで表記され、大/小文字を区別する場合、名前を引用符で囲む必要があります。したがって、表名は、データベースに格納されている表名と完全に一致するように指定する必要があります。
ただし、オペレーティング・システムによっては、コマンドラインの引用符自体をエスケープする必要がある場合があります。次に、異なるエクスポート・モードで大/小文字の区別を保持する方法を示します。

- コマンドライン・モード

TABLES='\"Emp\"'

- パラメータ・ファイル・モード

TABLES='"Emp"'

- 表名を引用符で囲まないかぎり、コマンドラインで指定する表名にシャープ(#)記号は使用できません。同様に、パラメータ・ファイルでは、表名が引用符で囲まれていないかぎり、表名にシャープ(#)記号を使用すると、エクスポート・ユーティリティではシャープ(#)記号より右側の文字がコメントとして解釈されます。
たとえば、パラメータ・ファイルに次のコマンドラインが記述されている場合、エクスポート・ユーティリティではemp#の右側がすべてコメントとして解釈されるため、表deptおよびmydataはエクスポートされません。

TABLES=(emp#, dept, mydata)

ただし、パラメータ・ファイルに次の行が含まれる場合は、emp#が引用符で囲まれているため、エクスポート・ユーティリティは3つの表をすべてエクスポートします。

TABLES=('"emp#"', dept, mydata)

注意:

オペレーティング・システムによっては、一重引用符を使用する必要がある場合と、二重引用符を使用する必要がある場合があります。ご使用のオペレーティング・システム固有のドキュメントで確認してください。表のネーミング方法に制限があるオペレーティング・システムもあります。

たとえば、UNIXのCシェルではドル記号($)やシャープ(#)(またはその他の特殊文字)には特別な意味があります。これらの文字をシェルを介してエクスポートするには、エスケープ文字を使用する必要があります。

表モード・エクスポート中のトランスポータブル・オプションの使用

表モード・エクスポート中にトランスポータブル・オプションを使用するには、TRANSPORTABLE=ALWAYSパラメータとTABLESパラメータを組み合せて指定します。指定した表、パーティションまたはサブパーティションのメタデータはダンプ・ファイルにエクスポートされます。実際のデータを移動するには、データ・ファイルをターゲット・データベースにコピーします。

表のパーティションの一部のみをエクスポートし、TRANSPORTABLE=ALWAYSパラメータを使用すると、インポート時にそれぞれのパーティションが非パーティション表になります。

制限事項

- 相互スキーマ参照はエクスポートされません。たとえば、指定されたいずれかのスキーマ内の表にトリガーが定義されていても、そのトリガーが、明示的に指定されていないスキーマ内に常駐している場合はエクスポートされません。

- 表で使用される型は、表モードではエクスポートされません。後でダンプ・ファイルをインポートするときにインポート先のデータベースに型が存在しない場合、表の作成は正常に実行されません。

- TABLESパラメータの値としてのシノニムの使用はサポートされていません。たとえば、hrスキーマのregions表にregnのシノニムが存在する場合、TABLES=regnを使用すると無効になります。この場合、エラーが返されます。

- 表名にワイルド・カード文字%を含む表のエクスポートは、表がパーティションの場合はサポートされません。

- TABLESパラメータに指定する表名のリストの長さは、最大4MBに制限されます。ただし、NETWORK_LINKパラメータで10.2.0.3以前のOracle Databaseまたは読取り専用のデータベースが設定されている場合は異なります。この場合の上限は4KBです。

- エクスポートに対してTRANSPORTABLE=ALWAYSも設定されている場合、1つの表からのパーティションのみを指定できます。

例

次の例に、hrスキーマにある3つ表employees、jobsおよびdepartmentsをエクスポートするためにTABLESパラメータを使用する簡単な例を示します。ユーザーhrは、hrスキーマ内の表をエクスポートしているため、表名の前にスキーマ名を指定する必要はありません。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=tables.dmp
TABLES=employees,jobs,departments

次の例では、ユーザーhrにDATAPUMP_EXP_FULL_DATABASEロールが付与されていることを前提としています。ここでは、TABLESパラメータを使用したパーティションのエクスポートを示します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=tables_part.dmp
TABLES=sh.sales:sales_Q1_2012,sh.sales:sales_Q2_2012

この例では、shスキーマのsales表から、パーティションsales_Q1_2012およびsales_Q2_2012をエクスポートします。

関連項目:

- 「TRANSPORTABLE」

- インポートの「REMAP_TABLE」コマンド

- 「データ・ファイル・コピーを使用したデータ移動」

TABLESPACES

デフォルト: デフォルト値は設定されていません。

用途

表領域モードでエクスポートされる表領域名のリストを指定します。

構文および説明

TABLESPACES=tablespace_name [, ...]

表領域モードでは、指定した表領域内に存在する表のみがアンロードされます。表がアンロードされると、その表の依存オブジェクトもアンロードされます。オブジェクトのメタデータとデータは、両方ともアンロードされます。指定した表領域内に表の一部が存在する場合、その表とその表のすべての依存オブジェクトがエクスポートされます。特権ユーザーは、すべての表を取得します。権限のないユーザーは、自分のスキーマ内の表のみを取得します。

このモードを使用したエクスポート対象を、フィルタ処理によってより詳細に制限できます(詳細は、「エクスポート操作中のフィルタ処理」を参照してください)。

制限事項

- TABLESPACESパラメータに指定する表領域名のリストの長さは、最大4MBに制限されます。ただし、NETWORK_LINKで10.2.0.3以前のOracle Databaseまたは読取り専用のデータベースが設定されている場合は異なります。この場合の上限は4KBです。

例

次に、TABLESPACESパラメータの使用例を示します。この例では、表領域tbs_4、tbs_5およびtbs_6がすでに存在するとします。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=tbs.dmp
TABLESPACES=tbs_4, tbs_5, tbs_6

このコマンドによって、表領域エクスポートが実行され、指定した表領域(tbs_4、tbs_5およびtbs_6)から表(および表の依存オブジェクト)がアンロードされます。

TRANSPORT_FULL_CHECK

デフォルト: NO

用途

トランスポータブル・セット内部のオブジェクトと外部のオブジェクト間の依存性をチェックするかどうかを指定します。このパラメータは、トランスポータブル表領域モード・エクスポートでのみ使用可能です。

構文および説明

TRANSPORT_FULL_CHECK=[YES | NO]

TRANSPORT_FULL_CHECK=YESを指定すると、エクスポート・ユーティリティによって、トランスポータブル・セット内のオブジェクトとトランスポータブル・セット外のオブジェクトの間に依存性が存在しないことが確認されます。ここでは、双方向の依存性がチェックされます。たとえば、トランスポータブル・セット内に表は存在するが、その表の索引は存在しない場合は、エラーが返され、エクスポート操作が終了します。同様に、トランスポータブル・セット内に索引は存在するが表は存在しない場合も、エラーが返されます。

TRANSPORT_FULL_CHECK=NOを指定すると、エクスポート・ユーティリティによって、トランスポータブル・セット外のオブジェクトに依存するオブジェクトが、トランスポータブル・セット内に存在しないことのみ確認されます。ここでは、一方向の依存性がチェックされます。たとえば、表は索引に依存しませんが、索引は表に依存します。これは、索引は表なしでは意味を持たないためです。そのため、トランスポータブル・セット内に表は存在するが、表の索引は存在しない場合、このチェックは正常に終了します。ただし、トランスポータブル・セット内に索引は存在するが表は存在しない場合は、エクスポート操作が終了します。

他のチェックも実行されます。たとえば、エクスポートでは、常に、TRANSPORT_TABLESPACESで指定された表領域セット内に定義されているすべての表(およびその索引)のすべての記憶域セグメントが、表領域セット内に実際に含まれていることが確認されます。

例

次に、TRANSPORT_FULL_CHECKパラメータの使用例を示します。ここでは、表領域tbs_1が存在するとします。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=tts.dmp
TRANSPORT_TABLESPACES=tbs_1 TRANSPORT_FULL_CHECK=YES LOGFILE=tts.log

TRANSPORT_TABLESPACES

デフォルト: デフォルト値は設定されていません。

用途

トランスポータブル表領域モードでのエクスポート実行を指定します。

構文および説明

TRANSPORT_TABLESPACES=tablespace_name [, ...]

TRANSPORT_TABLESPACESパラメータは、ソース・データベースからターゲット・データベースにオブジェクト・メタデータがエクスポートされる表領域名のリストを指定するために使用します。

エクスポートのログ・ファイルには、トランスポータブル・セットで使用されているデータ・ファイル、ダンプ・ファイルおよび制約違反が一覧表示されます。

TRANSPORT_TABLESPACESパラメータを使用すると、指定した表領域内のすべてのオブジェクトのメタデータがエクスポートされます。特定の表、パーティションまたはサブパーティションのみのトランスポータブル・エクスポートを実行する場合は、TABLESパラメータとTRANSPORTABLE=ALWAYSパラメータを併用する必要があります。

注意:

トランスポータブル表領域をエクスポートした後、それよりも古いリリース・レベルのデータベースにインポートすることはできません。ターゲット・データベースのリリース・レベルは、ソース・データベース以上である必要があります。

制限事項

- トランスポータブル表領域モードは、暗号化された列をサポートしていません。

- トランスポータブル表領域ジョブは、再開できません。

- トランスポータブル表領域ジョブは、並列度1に制限されます。

- トランスポータブル表領域モードでは、DATAPUMP_EXP_FULL_DATABASEロールが必要です。

- エクスポートを実行するユーザーのデフォルトの表領域を、転送対象となっている表領域のいずれかに設定することはできません。

- SYSTEMおよびSYSAUX表領域は、トランスポータブル表領域モードで転送できません。

- トランスポータブル・セット内のすべての表領域は、読取り専用に設定する必要があります。

- データ・ポンプ・エクスポートのVERSIONパラメータとTRANSPORT_TABLESPACESパラメータと一緒に指定する場合、バージョンはOracle Database COMPATIBLE初期化パラメータ以上である必要があります。

- TRANSPORT_TABLESPACESパラメータは、QUERYパラメータと組み合せて使用することはできません。

- トランスポータブル表領域のジョブでは、データ・ポンプ・エクスポートのACCESS_METHODパラメータはサポートされません。

例

次に、TRANSPORT_TABLESPACESパラメータを(ネットワークベースではなく)ファイル・ベースのジョブに使用した例を示します。表領域tbs_1は、移動する表領域です。この例では、表領域tbs_1がすでに存在し、読取り専用に設定されていると仮定しています。また、この例では、このエクスポート・コマンドの実行前にデフォルトの表領域が変更されていると仮定しています。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=tts.dmp
TRANSPORT_TABLESPACES=tbs_1 TRANSPORT_FULL_CHECK=YES LOGFILE=tts.log

関連項目:

- 「トランスポータブル表領域モード」

- 「データ・ファイル・コピーを使用したデータ移動」

- 「データ・ポンプによるタイムスタンプ・データの処理方法」

- データベース間の表領域の転送の詳細は、『Oracle Database管理者ガイド』を参照してください。

TRANSPORTABLE

デフォルト: NEVER

用途

表モード・エクスポート(TABLESパラメータで指定)または全体モード・エクスポート(FULLパラメータで指定)中にトランスポータブル・オプションを使用する必要があるかどうかを指定します。

構文および説明

TRANSPORTABLE = [ALWAYS | NEVER]

使用可能な値の定義は、次のとおりです。

ALWAYS - エクスポート・ジョブでトランスポータブル・オプションを使用するように指定します。トランスポータブルが使用できない場合、ジョブは失敗します。

表モード・エクスポートでトランスポータブル・オプションを使用すると、指定した表、パーティションまたはサブパーティションのメタデータのみがエクスポートされるトランスポータブル表領域エクスポートになります。

全体モード・エクスポートでトランスポータブル・オプションを使用すると、データベースの完全なコピーを作成するために必要なすべてのオブジェクトおよびデータがエクスポートされる全体トランスポータブル・エクスポートになります。

NEVER: エクスポート・ジョブでトランスポータブル・オプションではなくダイレクト・パスまたは外部表による方法を使用してデータをアンロードするように指定します。これはデフォルトです。

注意:

トランスポータブル・モードで表領域全体をエクスポートする場合は、TRANSPORT_TABLESPACESパラメータを使用します。

- 表のパーティションの一部のみをエクスポートし、TRANSPORTABLE=ALWAYSパラメータを使用すると、インポート時にそれぞれのパーティションが非パーティション表になります。

- 表のパーティションのサブセットのみをエクスポートし、TRANSPORTABLEパラメータを使用しない場合、またはそのパラメータがNEVERに設定されている場合(デフォルト)は、インポート時に次のようになります。

- PARTITION_OPTIONS=DEPARTITIONを使用している場合は、ダンプ・ファイル・セットに含まれるそれぞれのパーティションが、非パーティション表として作成されます。

- PARTITION_OPTIONSを使用していない場合は、完全な表が作成されます。つまり、完全な表内のすべてのメタデータが、ソース上での表定義と同じになるようにターゲット・システム上に存在します。ただし、指定されたパーティション用にエクスポートされたデータのみが表に挿入されます。

制限事項

- TRANSPORTABLEパラメータは、表モード・エクスポートおよび全体モード・エクスポートでのみ有効です。

- TRANSPORTABLEパラメータを使用するには、COMPATIBLE初期化パラメータを11.0.0以上に設定する必要があります。

- FULLパラメータをTRANSPORTABLE (全体トランスポータブル・エクスポートの実行)と組み合せて使用するには、データ・ポンプのVERSIONパラメータを12.0以上に設定する必要があります。VERSIONパラメータを指定しない場合、COMPATIBLEデータベース初期化パラメータを12.0以上に設定する必要があります。

- トランスポータブル・エクスポートを実行するユーザーには、DATAPUMP_EXP_FULL_DATABASE権限が必要です。

- 表、パーティションおよびサブパーティションに関連付けられている表領域は読取り専用である必要があります。

- 全体トランスポータブル・エクスポートでは、データ移動方法の組合せが使用されます。トランスポータブル表領域に存在するオブジェクトは、そのメタデータのみがアンロードされ、データはデータ・ファイルがソース・システムからターゲット・システムにコピーされるときにコピーされます。コピーする必要のあるデータ・ファイルは、エクスポート操作のログ・ファイルの最後に表示されます。非トランスポータブル表領域に存在するオブジェクト(SYSTEMやSYSAUXなど)は、そのメタデータとデータの両方がダンプ・ファイル・セットにアンロードされます。(全体トランスポータブル・エクスポートの実行の詳細は、『Oracle Database管理者ガイド』を参照してください。)

- エクスポートを実行するユーザーのデフォルトの表領域を、転送対象となっている表領域のいずれかに設定することはできません。

例

次の例では、shユーザーがDATAPUMP_EXP_FULL_DATABASEロールを持ち、表sales2がパーティション化されて表領域tbs2内に格納されているとします。(tbs2表領域はソース・データベースで読取り専用に設定する必要があります。)

> expdp sh DIRECTORY=dpump_dir1 DUMPFILE=tto1.dmp
TABLES=sh.sales2 TRANSPORTABLE=ALWAYS

エクスポートが正常に完了した後は、データ・ファイルをターゲット・データベース領域にコピーする必要があります。次に、PARTITION_OPTIONSとREMAP_SCHEMAの各パラメータを使用してインポート操作を実行し、sales2の各パーティションを固有の表にします。

> impdp system PARTITION_OPTIONS=DEPARTITION
TRANSPORT_DATAFILES=oracle/dbs/tbs2 DIRECTORY=dpump_dir1
DUMPFILE=tto1.dmp REMAP_SCHEMA=sh:dp

関連項目:

- 「全体モード・エクスポート時のトランスポータブル・オプションの使用」

- 「データ・ファイル・コピーを使用したデータ移動」

VERSION

デフォルト: COMPATIBLE

用途

エクスポートするデータベース・オブジェクトのバージョンを指定します。指定したリリースと互換性のあるデータベース・オブジェクトおよび属性のみがエクスポートされます。このパラメータは、以前のリリースのOracle Databaseと互換性のあるダンプ・ファイル・セットの作成に使用できます。このことは、データ・ポンプ・エクスポートがOracle Database 10gリリース1(10.1)以前のOracle Databaseと一緒に使用できるという意味ではありません。データ・ポンプ・エクスポートは、Oracle Database 10gリリース1(10.1)以降でのみ動作します。VERSIONパラメータを使用して可能になるのは、エクスポートするオブジェクトのバージョンの識別のみです。

Oracle Database 11gリリース2 (11.2.0.3)以上では、VERSIONパラメータをVERSION=12とし、FULL=Yと組み合せて指定することで、Oracle Database 12cにインポートできる全体エクスポートのダンプ・ファイルを生成できます。このエクスポートには、登録したデータベース・オプションおよびコンポーネントの情報が含まれます。(このダンプ・ファイル・セットをインポートできるのは、Oracle Database 12cリリース1 (12.1.0.1)以降のみです。)VERSION=12とFULL=Yの組合せに、TRANSPORTABLE=ALWAYSも指定すると、Oracle Database 12cにインポートできる全体トランスポータブル・エクスポート・ダンプ・ファイルが生成されます。(「全体モード・エクスポート時のトランスポータブル・オプションの使用」を参照してください。)

構文および説明

VERSION=[COMPATIBLE | LATEST | version_string]

VERSIONパラメータで使用可能な値は、次のとおりです。

- COMPATIBLE - デフォルト値。メタデータのバージョンは、COMPATIBLE初期化パラメータで指定したデータベース互換性レベルに対応します。 データベースの互換性は、9.2以上に設定する必要があります。

- LATEST - メタデータおよび生成されるSQL DDLのバージョンは、互換性レベルに関係なく、データベース・リリースに対応します。

- version_string: 特定のデータベース・リリース(11.2.0など)。Oracle Database 11gの場合、9.2未満の値は指定できません。

VERSIONで指定したリリースと互換性のないデータベース・オブジェクトまたは属性は、エクスポートされません。たとえば、指定したリリースではサポートされていない新しいデータ型を含む表はエクスポートされません。

制限事項

- アーカイブされたLOBがある表を、リリース11.2よりも前のデータベースにエクスポートすることはできません。

- データ・ポンプ・エクスポートのVERSIONパラメータをTRANSPORT_TABLESPACESパラメータと一緒に指定した場合、値はOracle Database COMPATIBLE初期化パラメータ以上である必要があります。

- データ・ポンプのVERSIONパラメータを12.1より前の任意の値に指定すると、4000バイトを超える長さのVARCHAR2またはNVARCHAR2列と、2000バイトを超える長さのRAW列を含む表は、データ・ポンプのダンプ・ファイルから除外されます。

- データ・ポンプのパラメータVERSION=12を使用してOracle Database 11gリリースで作成したダンプ・ファイルは、Oracle Database 12cリリース1 (12.1)以上でのみインポートできます。

例

次の例は、メタデータのバージョンがデータベースのリリースに対応している場合のエクスポートの例を示します。

> expdp hr TABLES=hr.employees VERSION=LATEST DIRECTORY=dpump_dir1
DUMPFILE=emp.dmp NOLOGFILE=YES

関連項目:

「異なるデータベース・リリース間のエクスポートとインポート」

VIEWS_AS_TABLES

デフォルト: デフォルト値は設定されていません。

注意:

VIEWS_AS_TABLESパラメータによって、暗号化されていない形式のビュー・データはアンロードされ、暗号化されていない表が作成されます。機密データをアンロードする場合、エクスポート操作で暗号化を有効にし、必ず暗号化された表領域に表を作成することをお薦めします。REMAP_TABLESPACEパラメータを使用して、このような表領域に表を移動できます。

用途

1つ以上のビューを表としてエクスポートするように指定します。

構文および説明

VIEWS_AS_TABLES=[schema_name.]view_name[:table_name], ...

データ・ポンプによって、ビューと同じ列を持ち、ビューからフェッチされた行データを持つ表がエクスポートされます。データ・ポンプでは、ビューに依存する権限や制約などのオブジェクトもエクスポートされます。表に適用されない依存オブジェクト(UNDERオブジェクト権限の付与など)は、エクスポートされません。VIEWS_AS_TABLESパラメータは、単独で使用するか、TABLESパラメータと組み合せて使用します。どちらを使用しても、データ・ポンプでは表モード・エクスポートが実行されます。

構文要素の定義は次のとおりです。

schema_name: ビューが存在するスキーマの名前。スキーマ名を指定しない場合、デフォルトで、エクスポートを実行するユーザーになります。

view_name: 表としてエクスポートするビューの名前。ビューは存在し、LOB以外のスカラー列のみを含むリレーショナル・ビューである必要があります。無効なビューや存在しないビューを指定すると、そのビューはスキップされてエラー・メッセージが返されます。

table_name: エクスポートされるビューのメタデータのソースとなる表の名前。デフォルトでは、データ・ポンプによって、ビューと同じ列およびデータ型を持つ、行の含まれない一時的なテンプレート表が自動的に作成されます。データベースが読取り専用の場合、このテンプレート表のデフォルトの作成には失敗します。この場合、表名を指定できます。表は、ビューと同じスキーマに属している必要があります。これは、ヒープ構成のパーティション化されていないリレーショナル表である必要があります。ネストした表にすることはできません。

テンプレート表が明示的に指定された複数のビューがエクスポート・ジョブに含まれる場合、それらのテンプレート表はすべて異なっている必要があります。たとえば、2つのビューで同じテンプレート表を使用している次のジョブでは、ビューの1つがスキップされます。

expdp scott/tiger directory=dpump_dir dumpfile=a.dmp views_as_tables=v1:emp,v2:emp

オブジェクトの省略をレポートするエラー・メッセージが返されます。

テンプレート表は、エクスポート操作の完了後に自動的に削除されます。それらが存在している間は、次の問合せを実行してその名前を表示できます(名前はすべてKU$VATで始まります)。

SQL> SELECT * FROM user_tab_comments WHERE table_name LIKE 'KU$VAT%';
TABLE_NAME                     TABLE_TYPE
------------------------------ -----------
COMMENTS
-----------------------------------------------------
KU$VAT_63629                   TABLE
Data Pump metadata template table for view SCOTT.EMPV

制限事項

- VIEWS_AS_TABLESパラメータは、TRANSPORTABLE=ALWAYSパラメータと組み合せて使用することはできません。

- VIEWS_AS_TABLESパラメータを使用して作成された表には、指定したビューの一部であった非表示列は含まれません。

- VIEWS_AS_TABLESパラメータでは、LONGのデータ型の列のある表をサポートしていません。

例

次の例では、ビューscott.view1の内容をscott1.dmpというダンプ・ファイルにエクスポートします。

> expdp scott/tiger views_as_tables=view1 directory=data_pump_dir dumpfile=scott1.dmp

ダンプ・ファイルには、ビューからフェッチされた行を持つview1という表が含まれます。

エクスポート・ユーティリティの対話方式コマンド・モードで使用可能なコマンド

対話方式コマンド・モードでは、現行のジョブは継続して続行されますが、端末へのロギングは一時停止され、エクスポート・プロンプト(Export>)が表示されます。

対話方式コマンド・モードを開始するには、次のいずれかの方法を使用します。

- 接続されたクライアントから、[Ctrl]を押しながら[C]を押します。

- ジョブを実行している端末以外の端末から、expdpコマンドでATTACHパラメータを指定してジョブに接続します。この機能は、ある場所で開始したジョブを、後で別の場所から確認する場合に有効です。

表2-1に、現行のジョブに対して対話方式コマンド・モードでデータ・ポンプ・エクスポート・プロンプトから実行できる操作を示します。

表2-1 データ・ポンプ・エクスポートの対話方式コマンド・モードでサポートされているコマンド

アクティビティ

使用するコマンド

追加ダンプ・ファイルを追加する。

ADD_FILE

対話方式モードを終了し、ロギング・モードに切り替える。

CONTINUE_CLIENT

ジョブは続行したままエクスポート・クライアント・セッションを停止する。

EXIT_CLIENT

ダンプ・ファイルのデフォルト・サイズを再定義して、その後のすべてのダンプ・ファイルに適用する。

FILESIZE

使用可能なコマンドの概要を表示する。

HELP

現在接続中のすべてのクライアント・セッションを切断し、現行のジョブを停止する。

KILL_JOB

現行のジョブに対するアクティブなワーカー・プロセスの数を増減する。このコマンドは、Oracle Database 11g以上のEnterprise Editionでのみ有効。

PARALLEL

接続している停止ジョブを再開する。

START_JOB

現行のジョブの詳細な状態を表示したり、状態の表示周期を設定する。

STATUS

後で再開するために、現行のジョブを停止する。

STOP_JOB

ADD_FILE

用途

エクスポート・ダンプ・ファイル・セットに、追加ファイルまたは置換変数を追加します。

構文および説明

ADD_FILE=[directory_object:]file_name [,...]

各ファイル名に、異なるディレクトリ・オブジェクトを指定できます。ディレクトリ・オブジェクトを指定しない場合は、デフォルトが使用されます。

file_nameに、ディレクトリ・パスの情報を含めないでください。ただし、置換変数(%U)を含めることはできます。この置換変数は、指定されたファイル名をテンプレートとして使用し、複数のファイルが生成できることを示します。

追加されるファイルのサイズは、FILESIZEパラメータの設定によって決定されます。

例

次の例では、2つのダンプ・ファイルをダンプ・ファイル・セットに追加します。ダンプ・ファイルhr2.dmpに、ディレクトリ・オブジェクトが指定されていないため、ジョブに対するデフォルトのディレクトリ・オブジェクトを使用するとします。別のディレクトリ・オブジェクトdpump_dir2が、ダンプ・ファイルhr3.dmpに指定されています。

Export> ADD_FILE=hr2.dmp, dpump_dir2:hr3.dmp

関連項目:

置換変数を指定した場合の効果の詳細は、「ファイルの割当て」を参照してください

CONTINUE_CLIENT

用途

エクスポート・モードを、対話方式コマンド・モードからロギング・モードに変更します。

構文および説明

CONTINUE_CLIENT

ロギング・モードでは、状態が端末に継続的に出力されます。ジョブが現在停止している場合、CONTINUE_CLIENTを指定すると、クライアントがジョブの開始を試みます。

例

Export> CONTINUE_CLIENT

EXIT_CLIENT

用途

エクスポート・クライアント・セッションを停止し、エクスポート・ユーティリティを終了して、端末へのロギングを中断します。ただし、現行のジョブの実行は続行します。

構文および説明

EXIT_CLIENT

EXIT_CLIENTでは、ジョブが実行されたままになるため、後でこのジョブに接続できます。ジョブの状態を確認するには、ジョブのログ・ファイルを監視するか、USER_DATAPUMP_JOBSビューまたはV$SESSION_LONGOPSビューを問い合せることができます。

例

Export> EXIT_CLIENT

FILESIZE

用途

後のダンプ・ファイルの最大サイズを再定義します。ダンプ・ファイル・セット内にあるダンプ・ファイルが最大サイズになると、そのファイルはクローズされ、ファイル指定に置換変数が含まれている場合または追加ダンプ・ファイルがジョブに追加されている場合は、新しいファイルが作成されます。

構文および説明

FILESIZE=integer[B | KB | MB | GB | TB]

integerの後に(スペースを挿入しない)、B、KB、MB、GBまたはTB(それぞれバイト、キロバイト、メガバイト、ギガバイト、テラバイトを示す)を指定できます。デフォルトは、B(バイト)です。作成されるファイルの実際のサイズは、ダンプ・ファイル内で使用されている内部ブロックのサイズと一致するように切り捨てられる場合があります。

ファイル・サイズ0は最大ファイル・サイズの16TBと同じです。

制限事項

- ファイルの最小サイズは、デフォルトのデータ・ポンプ・ブロック・サイズの10倍、つまり4KBです。

- ファイルの最大サイズは16TBです。

例

Export> FILESIZE=100MB

HELP

用途

対話方式コマンド・モードで使用可能なデータ・ポンプ・エクスポート・コマンドの情報を表示します。

構文および説明

HELP

対話方式コマンド・モードで使用可能なコマンドの情報を表示します。

例

Export> HELP

KILL_JOB

用途

現在接続中のすべてのクライアント・セッションを切断してから、現行のジョブを停止します。エクスポート・ユーティリティを終了し、端末プロンプトに戻します。

構文および説明

KILL_JOB

KILL_JOBを使用して中断されたジョブは、再開できません。接続中のすべてのクライアント(KILL_JOBコマンドを発行しているクライアントを含む)は、現在のユーザーがジョブを停止しているという警告を受け取った後、切断されます。すべてのクライアントが切断されると、ジョブのプロセス構造が即時に停止し、マスター表およびダンプ・ファイルが削除されます。ログ・ファイルは、削除されません。

例

Export> KILL_JOB

PARALLEL

用途

現行のジョブに対してアクティブなプロセス(ワーカーおよびパラレル・スレーブ)の数を増減できます。

構文および説明

PARALLEL=integer

PARALLELは、コマンドライン・パラメータおよび対話方式コマンド・モードのパラメータとして使用可能です。必要な数のパラレル・プロセス(ワーカーおよびパラレル・スレーブ)を設定できます。増加処理は、ファイルとリソースが十分にある場合は即時に実行されます。減少処理は、既存のプロセスが現行のタスクを終了してから実行されます。値を小さくすると、ワーカーはアイドル状態になりますが、ジョブが終了するまで削除はされません。

制限事項

- このパラメータは、Oracle Database 11g以上のEnterprise Editionでのみ有効です。

例

Export> PARALLEL=10

関連項目:

並列度の詳細は、「PARALLEL」を参照してください

START_JOB

用途

接続している現行のジョブを開始します。

構文および説明

START_JOB

START_JOBコマンドは、ジョブが現在実行中の場合を除き、接続している現行のジョブを開始します。ダンプ・ファイル・セットおよびマスター表が元のまま変更されていない場合は、予期しない障害またはSTOP_JOBコマンドの発行後に、データの損失や破損なしにジョブが再開されます。

トランスポータブル表領域モードで実行されたエクスポートは、再開できません。

例

Export> START_JOB

STATUS

用途

ジョブの累積的な状態、現行の操作の説明および推定完了率を表示します。ロギング・モードの状態を表示する間隔を再設定することもできます。

構文および説明

STATUS[=integer]

ロギング・モードでのこの状態の表示頻度を秒単位で指定できるオプションがあります。値を入力しなかった場合またはデフォルト値の0を使用した場合は、状態の定期表示はオフになり、状態は1回のみ表示されます。

この状態情報は、標準出力デバイスのみに書き込まれ、ログ・ファイルには(使用可能な場合でも)書き込まれません。

例

次に、現行のジョブの状態を表示し、ロギング・モードの表示間隔を5分(300秒)に変更する例を示します。

Export> STATUS=300

STOP_JOB

用途

現行のジョブを即時にまたは手順に従って停止し、エクスポート・ユーティリティを終了します。

構文および説明

STOP_JOB[=IMMEDIATE]

STOP_JOBコマンド発行時または発行後にマスター表およびダンプ・ファイル・セットに障害が発生していない場合は、そのジョブに接続し、START_JOBコマンドを使用して再開できます。

手順に従って停止する場合は、関連する値を指定しないでSTOP_JOBを使用します。確認を要求する警告が発行されます。手順に従った停止では、ワーカー・プロセスで現行のタスクが終了した後、ジョブが停止されます。

即時に停止するには、STOP_JOB=IMMEDIATEを指定します。確認を要求する警告が発行されます。接続中のすべてのクライアント(STOP_JOBコマンドを発行しているクライアントを含む)は、現在のユーザーがジョブを停止および切断中であるという警告を受け取ります。すべてのクライアントが切断されると、ジョブのプロセス構造が即時に停止されます。マスター・プロセスは、ワーカー・プロセスで現行のタスクが終了するまで待機はしません。STOP_JOB=IMMEDIATEを指定した場合、データ破損やデータ損失の危険性はありません。ただし、停止時に完了しなかった一部のタスクは、再開時に再実行する必要があります。

例

Export> STOP_JOB=IMMEDIATE

データ・ポンプ・エクスポートの使用例

この項では、データ・ポンプ・エクスポートの使用例を示します。

- 表モード・エクスポートの実行

- 選択した表および行のデータのみのアンロード

- 表モード・エクスポートに必要なディスク領域の見積り

- スキーマ・モード・エクスポートの実行

- パラレル全データベース・エクスポートの実行

- 対話方式モードを使用したジョブの停止および再接続

これらの例を正しく使用するために役立つ情報については、「エクスポート・パラメータの使用例」を参照してください。

表モード・エクスポートの実行

例2-1に、TABLESパラメータを使用して、表モード・エクスポートを指定する例を示します。人事管理(hr)スキーマから、表employeesおよびjobsの表エクスポートを実行するには、次のデータ・ポンプ・エクスポート・コマンドを発行します。

ユーザーhrは、自分のスキーマ内の表をエクスポートしているため、表名の前にスキーマ名を指定する必要はありません。NOLOGFILE=YESパラメータは、その操作のエクスポート・ログ・ファイルが生成されないことを示します。

例2-1 表モード・エクスポートの実行

expdp hr TABLES=employees,jobs DUMPFILE=dpump_dir1:table.dmp NOLOGFILE=YES

選択した表および行のデータのみのアンロード

例2-2に、人事管理(hr)スキーマから、表countriesおよびregionsを除くすべての表のデータのみをアンロードするために使用するパラメータ・ファイル(exp.par)の内容を示します。employees表から、department_idが50以外の行がアンロードされます。行は、employee_id順にソートされます。

次のコマンドを使用して、exp.parパラメータ・ファイルを実行できます。

> expdp hr PARFILE=exp.par

スキーマ・モード・エクスポート(デフォルト・モード)が実行されますが、CONTENTパラメータによって、エクスポートが表のデータのみのアンロードに効果的に制限されます。ディレクトリ・オブジェクトdpump_dir1は、DBAによってすでに作成されています。このオブジェクトは、エクスポート・ダンプ・ファイルに対する読取りおよび書込み権限がユーザーhrに付与されているサーバー上のディレクトリを示しています。ダンプ・ファイルdataonly.dmpは、dpump_dir1に作成されます。

例2-2 選択した表および行のデータのみのアンロード

DIRECTORY=dpump_dir1
DUMPFILE=dataonly.dmp
CONTENT=DATA_ONLY
EXCLUDE=TABLE:"IN ('COUNTRIES', 'REGIONS')"
QUERY=employees:"WHERE department_id !=50 ORDER BY employee_id"

表モード・エクスポートに必要なディスク領域の見積り

例2-3に、表モード・エクスポートで使用される領域を、ESTIMATE_ONLYパラメータを使用して、実際のエクスポート操作を実行しないで見積もる場合の例を示します。次のコマンドを実行し、BLOCKSメソッドを使用して、人事管理(hr)スキーマの3つの表employees、departmentsおよびlocationsのデータのエクスポートに必要なバイト数を見積もります。

見積りはログ・ファイルに出力され、クライアントの標準出力デバイスに表示されます。見積りの対象は、表の行データのみです。メタデータは含まれません。

例2-3 表モード・エクスポートに必要なディスク領域の見積り

> expdp hr DIRECTORY=dpump_dir1 ESTIMATE_ONLY=YES TABLES=employees,
departments, locations LOGFILE=estimate.log

スキーマ・モード・エクスポートの実行

例2-4に、hrスキーマのスキーマ・モード・エクスポートを示します。スキーマ・モード・エクスポートでは、対応するスキーマに属するオブジェクトのみがアンロードされます。スキーマ・モードは、デフォルトのモードであるため、複数のスキーマや自分のスキーマ以外を指定する場合以外、コマンドラインでSCHEMASパラメータを指定する必要はありません。

例2-4 スキーマ・モード・エクスポートの実行

> expdp hr DUMPFILE=dpump_dir1:expschema.dmp LOGFILE=dpump_dir1:expschema.log

パラレル全データベース・エクスポートの実行

例2-5に、最大3つのパラレル・プロセス(ワーカーまたはPQスレーブ)を持つ全データベース・エクスポートを示します。

例2-5 パラレル全体エクスポート

> expdp hr FULL=YES DUMPFILE=dpump_dir1:full1%U.dmp, dpump_dir2:full2%U.dmp
FILESIZE=2G PARALLEL=3 LOGFILE=dpump_dir1:expfull.log JOB_NAME=expfull

これは、全データベース・エクスポートであるため、データベースのすべてのデータおよびメタデータがエクスポートされます。full101.dmp、full201.dmp、full102.dmpなどのダンプ・ファイルが、dpump_dir1およびdpump_dir2ディレクトリ・オブジェクトで示されたディレクトリに、ラウンドロビン法で作成されます。最適なパフォーマンスを得るには、これらのファイルを個別のI/Oチャネルに配置する必要があります。各ファイルのサイズは、必要に応じて2GBまで拡張されます。最初に、最大3つのファイルが作成されます。必要に応じて、追加のファイルが作成されます。ジョブおよびマスター表は、expfullという名前になります。ログ・ファイルは、dpump_dir1ディレクトリのexpfull.logに書き込まれます。

対話方式モードを使用したジョブの停止および再接続

この例を試す前に、例2-5のパラレル全体エクスポートを再実行します。エクスポートの実行中、[Ctrl]を押しながら[C]を押します。これによって、データ・ポンプ・エクスポートの対話方式コマンド・インタフェースを起動します。対話方式インタフェースでは、端末へのロギングは停止され、データ・ポンプ・エクスポートのプロンプトが表示されます。

ジョブの状態が表示された後、CONTINUE_CLIENT コマンドを実行して、ロギング・モードを再開し、expfullジョブを再起動できます。

Export> CONTINUE_CLIENT

ジョブが再オープンされたことを示すメッセージが表示され、処理の状態がクライアントに出力されます。

例2-6 ジョブの停止と再接続

エクスポート・プロンプトで、次のコマンドを実行してジョブを停止します。

Export> STOP_JOB=IMMEDIATE
Are you sure you wish to stop this job ([y]/n): y

このジョブは停止状態でクライアントを終了します。

停止したジョブに再接続するには、次のコマンドを入力します。

> expdp hr ATTACH=EXPFULL

データ・ポンプ・エクスポートの構文図

この項では、データ・ポンプ・エクスポートの構文図を示します。これらの構文図では、標準SQL構文の表記法を使用します。SQL構文の表記法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ExpInit

ExpStart

ExpModes

ExpOpts

ExpCompression

ExpEncrypt

ExpFilter

ExpRacOpt

ExpRemap

ExpVersion

ExpFileOpts

ExpDynOpts

ExpDiagnostics

3 データ・ポンプ・インポート

エクスポート・ダンプ・ファイル・セットをターゲット・データベースにロードするために使用するOracle Data Pump Importユーティリティについて説明します。また、これを使用して、ファイルを介さずにソース・データベースから直接ターゲット・データベースにロードする、ネットワーク・インポートを実行することもできます。

ここでは、次の項目について説明します。

- データ・ポンプ・インポート・ユーティリティとは

- データ・ポンプ・インポートの起動

- インポート操作中のフィルタ処理

- インポート・ユーティリティのコマンドライン・モードで使用可能なパラメータ

- インポート・ユーティリティの対話方式コマンド・モードで使用可能なコマンド

- データ・ポンプ・インポートの使用例

- データ・ポンプ・インポートの構文図

データ・ポンプ・インポート・ユーティリティとは

データ・ポンプ・インポート(以降、インポート・ユーティリティと呼びます)は、エクスポート・ダンプ・ファイル・セットをターゲット・システムにロードするためのユーティリティです。ダンプ・ファイル・セットは、表データ、データベース・オブジェクトのメタデータ、制御情報を含む1つ以上のディスク・ファイルで構成されています。これらのファイルは独自のバイナリ形式で書き込まれています。データ・ポンプ・インポート・ユーティリティは、インポート操作中、これらのファイルを使用してダンプ・ファイル・セット内の各データベース・オブジェクトの位置を特定します。

また、ダンプ・ファイルを介さずに、ソース・データベースから直接ターゲット・データベースをロードするために使用することもできます。これはネットワーク・インポートと呼ばれます。

データ・ポンプ・インポート・ユーティリティでは、インポート・モードで設定されているとおりにジョブによって、データおよびメタデータのサブセットが、ダンプ・ファイル・セットまたはソース・データベース(ネットワーク・インポートの場合)から移動されるように指定できます。この指定は、インポート・ユーティリティのコマンドによって実装されるデータ・フィルタおよびメタデータ・フィルタを使用して行います。詳細は、「インポート操作中のフィルタ処理」を参照してください。

インポートを使用できる様々な方法の例については、「データ・ポンプ・インポートの使用例」を参照してください。

データ・ポンプ・インポートの起動

データ・ポンプ・インポート・ユーティリティは、impdpコマンドを使用して起動します。インポート操作の特性は、指定するインポート・パラメータによって決定されます。これらのパラメータは、コマンドラインまたはパラメータ・ファイルのいずれかで指定できます。

注意:

インポート・ユーティリティは、Oracleサポート・サービスから要求された場合以外、SYSDBAとして起動しないでください。SYSDBAは内部的に使用され、一般ユーザーとは異なる特別な機能を持ちます。

注意:

NOLOGGING句を有効にして作成された表または表領域に対してデータ・ポンプ・インポートを実行する場合でも、REDOログ・ファイルが生成される場合があることに注意してください。このような場合に生成されるREDOは、通常、マスター表のメンテナンスを目的としているか、または基礎となる再帰的領域トランザクション、データ・ディクショナリの変更、およびロギングを必要とする表の索引メンテナンスに関係しています。

インポート・ユーティリティの起動の詳細は、次の項を参照してください。

- 「データ・ポンプ・インポートのインタフェース」

- 「データ・ポンプ・インポートのモード」

- 「ネットワークに関する考慮点」

データ・ポンプ・インポートのインタフェース

データ・ポンプ・インポートは、コマンドライン、パラメータ・ファイルまたは対話方式コマンド・モードを使用して実行できます。

- コマンドライン・インタフェース: 直接コマンドラインでインポートのパラメータを指定できます。コマンドライン・インタフェースで使用可能なパラメータの詳細は、「インポート・ユーティリティのコマンドライン・モードで使用可能なパラメータ」を参照してください。

- パラメータ・ファイル・インタフェース: パラメータ・ファイルでコマンドラインのパラメータを指定できます。パラメータ・ファイルはネストできないため、PARFILEパラメータのみが例外となります。値の指定に引用符が必要なパラメータを指定する場合は、パラメータ・ファイルを使用することをお薦めします。詳細は、「データ・ポンプ・コマンドラインでの引用符の使用」を参照してください。

- 対話方式コマンド・インタフェース: 端末へのロギングを中止してインポート・ユーティリティのプロンプトを表示します。対話方式コマンド・モード固有のコマンドも含めて、様々なコマンドが入力できます。このモードは、コマンドライン・インタフェースまたはパラメータ・ファイル・インタフェースで開始されたインポート操作中に[Ctrl]キーを押しながら[C]キーを押すと使用可能になります。対話方式コマンド・モードは、実行中のジョブまたは停止されたジョブに接続した場合も使用可能になります。
対話方式コマンド・モードで使用可能なコマンドの詳細は、「インポート・ユーティリティの対話方式コマンド・モードで使用可能なコマンド」を参照してください。

データ・ポンプ・インポートのモード

インポート・モードで、何をインポートするかを決定します。指定したモードは、操作のソース(ダンプ・ファイル・セットまたはNETWORK_LINKパラメータが指定されている場合は別のデータベース)に適用されます。

インポート操作のソースがダンプ・ファイル・セットの場合、モードの指定はオプションです。モードを指定していない場合、インポート・ユーティリティは、エクスポート操作実行時のモードでダンプ・ファイル・セット全体をロードしようとします。

モードは、適切なパラメータを使用してコマンドラインで指定します。使用可能なモードについては、次の項で説明します。

- 「全体インポート・モード」

- 「スキーマ・モード」

- 「表モード」

- 「表領域モード」

- 「トランスポータブル表領域モード」

注意:

全体モード・エクスポートによって作成されたダンプ・ファイルをインポートする場合、インポート操作はSYSアカウントのパスワードをソース・データベースからコピーしようとします。これは、失敗する場合があります(パスワードが共有パスワード・ファイル内にある場合など)。失敗した場合は、インポートの完了後に、ターゲット・データベース上のSYSアカウントのパスワードを任意のパスワードに設定する必要があります。

全体インポート・モード

全体インポートは、FULLパラメータを使用して指定します。全体インポート・モードでは、ソース(ダンプ・ファイル・セットまたは別のデータベース)の全内容がターゲット・データベースにロードされます。これは、ファイル・ベース・インポートのデフォルトです。ソースが、自分のスキーマ以外のスキーマを含む別のデータベースである場合、DATAPUMP_IMP_FULL_DATABASEロールを持っている必要があります。

権限のないユーザーの場合、相互スキーマ参照はインポートされません。たとえば、インポートを実行するユーザーのスキーマ内の表にトリガーが定義されていても、そのトリガーが別のユーザーのスキーマに存在している場合はインポートされません。

NETWORK_LINKパラメータを完全インポートに使用する場合は、ターゲット・データベースではDATAPUMP_IMP_FULL_DATABASEロールが必要で、ソース・データベースではDATAPUMP_EXP_FULL_DATABASEロールが必要です。

全体モード・インポート時のトランスポータブル・オプションの使用

全体モード・インポート時にトランスポータブル・オプションを使用して、全体トランスポータブル・インポートを実行できます。

ネットワーク・ベースの全体トランスポータブル・インポートでは、FULL=YES、TRANSPORTABLE=ALWAYSおよびTRANSPORT_DATAFILES=datafile_nameパラメータを使用する必要があります。

ファイル・ベースの全体トランスポータブル・インポートでは、TRANSPORT_DATAFILES=datafile_nameパラメータのみを使用する必要があります。データ・ポンプ・インポートでは、TRANSPORTABLE=ALWAYSおよびFULL=Yパラメータの存在が推測されます。

全体トランスポータブル・インポートを実行する場合、次のようないくつかの要件があります。

- 同時にNETWORK_LINKパラメータを指定するか、エクスポート中にインポート対象のダンプ・ファイル・セットがトランスポータブル・オプションを使用して作成されている必要があります。

- ネットワーク・リンクを使用する場合、NETWORK_LINKパラメータで指定されているデータベースはOracle Database 11gリリース2 (11.2.0.3)以上であり、データ・ポンプのVERSIONパラメータは12以上に設定されている必要があります。(ネットワーク・インポート以外では、ダンプ・ファイルから暗黙的にVERSION=12が決定されます。)

- ソース・プラットフォームとターゲット・プラットフォームのエンディアンが異なる場合、転送するデータを変換してターゲット・プラットフォームの形式にする必要があります。DBMS_FILE_TRANSFERパッケージまたはRMAN CONVERTコマンドを使用してデータを変換できます。これらのオプションの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- ソース・プラットフォームとターゲット・プラットフォームのエンディアンが同じではない場合、暗号化された表領域の全体トランスポータブル・インポートは、ネットワーク・モードまたはダンプ・ファイル・モードでサポートされません。

- 全体トランスポータブル・インポートを使用してネットワークを介してデータベースを転送する場合、管理表領域(SYSTEMやSYSAUXなど)に存在するLONGまたはLONG RAW列を含む表は、サポートされません。

- 全体トランスポータブル・インポートを使用してネットワークを介してデータベースを転送する場合、監査証跡情報自体がユーザー定義の表領域に格納されていると、管理表領域(SYSTEMやSYSAUXなど)に格納された表に対して監査を有効にすることはできません。

関連項目:

- 全体トランスポータブル・インポートの詳細な例は、『Oracle Database管理者ガイド』を参照してください。

- インポートの「FULL」パラメータ

- インポートの「TRANSPORTABLE」パラメータ

スキーマ・モード

スキーマ・インポートは、SCHEMASパラメータを使用して指定します。スキーマ・インポートでは、指定されたスキーマが所有しているオブジェクトのみがロードされます。ソースは、全体インポート・モード、表モード、表領域モードまたはスキーマ・モードのエクスポート・ダンプ・ファイル・セット、または別のデータベースです。DATAPUMP_IMP_FULL_DATABASEロールを所有している場合は、スキーマ・リストを指定できます。これにより、スキーマ内のオブジェクトに加えてスキーマ自体(システム権限を含む)もデータベース内に作成されます。

相互スキーマ参照は、残りのスキーマが現行のスキーマに再マップされないかぎり、権限のないユーザーに対してインポートされません。たとえば、インポートを実行するユーザーのスキーマ内の表にトリガーが定義されていても、そのトリガーが別のユーザーのスキーマに存在している場合はインポートされません。

関連項目:

「SCHEMAS」

表モード

表モード・インポートは、TABLESパラメータを使用して指定します。表モードでは、指定した表、パーティションおよびそれらの依存オブジェクトのみがロードされます。ソースは、全体インポート・モード、スキーマ・モード、表領域モードまたは表モードのエクスポート・ダンプ・ファイル・セット、または別のデータベースです。自分のスキーマに存在しない表を指定するには、DATAPUMP_IMP_FULL_DATABASEロールが必要です。

TRANPORTABLE=ALWAYSパラメータをTABLESパラメータと組み合せて指定することで、表モードのインポート中にトランスポータブル・オプションを使用できます。これには、NETWORK_LINKパラメータも使用する必要があることに注意してください。

表および表パーティションをリカバリするには、RMANバックアップおよびRMAN RECOVER TABLEコマンドも使用できます。このプロセス中に、RMANによって、リカバリされたオブジェクトを含むデータ・ポンプ・エクスポートのダンプ・ファイルが作成(およびオプションでインポート)されます。このトピックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

関連項目:

- 「TABLES」

- 「TRANSPORTABLE」

- 「データ・ファイル・コピーを使用したデータ移動」

表領域モード

表領域モードのインポートは、TABLESPACESパラメータを使用して指定します。表領域モードでは、指定した表領域内のすべてのオブジェクトが、依存オブジェクトとともにロードされます。ソースは、全体インポート・モード、スキーマ・モード、表領域モードまたは表モードのエクスポート・ダンプ・ファイル・セット、または別のデータベースです。権限のないユーザーの場合、現行のスキーマに再マッピングされていないオブジェクトは処理されません。

関連項目:

「TABLESPACES」

トランスポータブル表領域モード

トランスポータブル表領域インポートは、TRANSPORT_TABLESPACESパラメータを使用して指定します。トランスポータブル表領域モードでは、(NETWORK_LINKパラメータで指定された)データベース・リンクを使用するか、メタデータを含むダンプ・ファイルを指定することで、別のデータベースからメタデータがロードされます。TRANSPORT_DATAFILESパラメータで指定した実際のデータ・ファイルは、ターゲット・データベースで使用するために、通常は、データ・ファイルをターゲット・システムにコピーすることによって、ソース・システムで使用可能にする必要があります。

トランスポータブル・ジョブを実行する場合、ベスト・プラクティスは、インポート・ジョブがターゲット・システムで正常に完了するまで、ソース・システムにデータ・ファイルのコピーを保持することです。インポート・ジョブがなんらかの理由で失敗しても、破損していないデータ・ファイルのコピーが残ります。詳細は、「データ・ファイル・コピーを使用したデータ移動」を参照してください。

トランスポータブル表領域モードでは、暗号化された列も暗号化された表領域もサポートされません。

このモードには、DATAPUMP_IMP_FULL_DATABASEロールが必要です。

注意:

トランスポータブル表領域をエクスポートした後、それよりも古いリリース・レベルのデータベースにインポートすることはできません。ターゲット・データベースのリリース・レベルは、ソース・データベース以上である必要があります。

関連項目:

- トランスポータブル表領域モードを使用する場合のタイムスタンプ・データに関する特別な考慮事項の詳細は、「データ・ポンプによるタイムスタンプ・データの処理方法」を参照してください

ネットワークに関する考慮点

データ・ポンプ・インポート・ユーティリティの起動時、接続文字列には接続識別子を指定できます。接続識別子では、現行のOracleシステム識別子(SID)によって指定した現行のインスタンスとは別のデータベース・インスタンスを指定できます。接続識別子には、Oracle*Net接続記述子または接続記述子にマップするネット・サービス名(通常、tnsnames.oraファイルで定義される)を指定できます。接続識別子を使用するには、Oracle Net Listenerが実行中であることが必要です(デフォルト・リスナーを起動するには、lsnrctl startと入力します)。次に、inst1が接続識別子である場合のこのタイプの接続の例を示します。

impdp hr@inst1 DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp TABLES=employees

インポートによってパスワードの入力を要求されます。

Password: password

ローカル・インポート・クライアントは接続識別子inst1(ネット・サービス名)によって識別されるデータベース・インスタンスに接続し、ダンプ・ファイルhr.dmpからinst1にデータをインポートします。

インポート・ユーティリティの起動時に接続識別子を指定することと、NETWORK_LINKパラメータを使用してインポート操作を実行することは異なります。インポート操作を開始して接続識別子を指定すると、接続識別子によって識別されるデータベース・インスタンスにローカルのインポート・クライアントが接続され、コマンドラインで指定されるダンプ・ファイルからそのデータベース・インスタンスにデータがインポートされます。

一方、NETWORK_LINKパラメータを使用してインポートを実行すると、インポートはデータベース・リンクを使用して実行され、ダンプ・ファイルは含まれません。(データベース・リンクとは2つの物理データベース・サーバー間の接続で、データベース・リンクによってクライアントは2つの物理データベース・サーバーに1つの論理データベースとしてアクセスできます。)

関連項目:

- 「NETWORK_LINK」

- データベース・リンクの詳細は、Oracle Database管理者ガイドを参照してください。

- 接続識別子およびOracle Net Listenerの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

インポート操作中のフィルタ処理

データ・ポンプ・インポート・ユーティリティでは、データとメタデータのフィルタ処理機能を使用して、インポートする情報の種類を効果的に制限できます。

データ・フィルタ

データ固有のフィルタ処理は、QUERYおよびSAMPLEパラメータによって実装されます。このパラメータは、表のインポートされる行に対する制限を指定します。メタデータのフィルタ処理のため、間接的にデータのフィルタ処理が実行される場合もあります。この処理では、表オブジェクトおよび関連付けられた行データを含めたり、除外することができます。

各データ・フィルタは、表およびジョブごとにそれぞれ1回指定できます。同じ名前を使用する異なるフィルタが特定の表とジョブ全体の両方に適用された場合は、特定の表に対して提供されたフィルタ・パラメータが優先されます。

メタデータのフィルタ

データ・ポンプ・インポート・ユーティリティで提供されるメタデータのフィルタ処理機能は、オリジナルのインポート・ユーティリティと比較すると大幅に拡張されています。メタデータのフィルタ処理は、EXCLUDEおよびINCLUDEパラメータによって実装されます。EXCLUDEおよびINCLUDEは、相互に排他的なパラメータです。

メタデータ・フィルタは、データ・ポンプ操作に含めるか、データ・ポンプ操作から除外するオブジェクトの集合を特定します。たとえば、パッケージ仕様またはパッケージ本体を含まない全体インポートを要求できます。

フィルタを正しく使用して必要な結果を得た場合は、識別されたオブジェクトの依存オブジェクトも、識別されたオブジェクトとともに処理されます。たとえば、パッケージを操作に含めるようにフィルタで指定すると、そのパッケージに対する権限も含まれます。同様に、フィルタで表を除外すると、その表に対する索引、制約、権限およびトリガーも除外されます。

1つのオブジェクト型に対して複数のフィルタが指定されている場合は、それらのフィルタに対して暗黙的なAND処理が適用されます。つまり、ジョブに関連するオブジェクトは、オブジェクト型に適用されるすべてのフィルタで処理される必要があります。

1つのジョブ内には、同じフィルタ名を複数回指定できます。

DATABASE_EXPORT_OBJECTS(全体モードの場合)、SCHEMA_EXPORT_OBJECTS(スキーマ・モードの場合)、TABLE_EXPORT_OBJECTS(表および表領域モードの場合)ビューを問い合せて、有効なオブジェクト・タイプ値の一覧を表示できます。OBJECT_PATH列にリストされる値が有効なオブジェクト・タイプです。完全なオブジェクト・パス名は、インポート・モードでなくエクスポート・モードによって決定されます。

関連項目:

- フィルタ処理の使用例は、「メタデータのフィルタ」を参照してください

- インポートの「EXCLUDE」パラメータ

- インポートの「INCLUDE」パラメータ

インポート・ユーティリティのコマンドライン・モードで使用可能なパラメータ

この項では、データ・ポンプ・インポート・ユーティリティのコマンドライン・モードで使用可能なパラメータについて説明します。インポート・パラメータを使用する前に、必ず次の項を読んでください。

- インポート・パラメータの指定

- データ・ポンプ・コマンドラインでの引用符の使用

ここで説明する内容の多くは、パラメータの使用例を含みます。使用例を実行するために必要な環境の設定の詳細は、次の項を参照してください。

- インポート・パラメータの使用例

インポート・パラメータの指定

値を複数個指定できるパラメータでは、カンマまたは空白で値を区切ることができます。たとえば、TABLES=employees,jobsまたはTABLES=employees jobsのように指定できます。

入力するパラメータごとに、等号(=)と値を入力する必要があります。それ以外の方法では、1つ前のパラメータ指定がどこで完了し、新しいパラメータ指定がどこから始まるかをデータ・ポンプに伝えることができません。たとえば、次のコマンドラインの場合、NOLOGFILEは有効なパラメータですが、DUMPFILEパラメータに対するダンプ・ファイル名がもう1つあると解釈されます。

impdp DIRECTORY=dpumpdir DUMPFILE=test.dmp NOLOGFILE TABLES=employees

その結果、test.dmpおよびnologfile.dmpという2つのダンプ・ファイルが作成されることになります。

これを回避するには、NOLOGFILE=YESまたはNOLOGFILE=NOのいずれかを指定します。

パラメータ値を指定する場合の大/小文字の区別

パラメータ値として入力される表領域名、スキーマ名、表名などについて、Oracle Data Pumpは、小文字または大/小文字混在で入力された値をデフォルトで大文字に変更します。たとえば、TABLE=hr.employeesと入力すると、それはTABLE=HR.EMPLOYEESに変更されます。大/小文字を維持するには、引用符で値を囲む必要があります。たとえば、TABLE="hr.employees"とすると、表名がすべて小文字のまま維持されます。入力する名前は、データベースに格納されている名前と完全に一致する必要があります。

データ・ポンプ・コマンドラインでの引用符の使用

一部のオペレーティング・システムでは引用符が特殊文字として処理されるため、バックスラッシュ(\)などのエスケープ文字を前に付けないと、アプリケーションに正しく渡されません。これは、コマンドラインとパラメータ・ファイル内の両方に当てはまります。また、オペレーティング・システムによっては、コマンドラインで、特殊文字を含むパラメータ値全体を一重引用符または二重引用符で囲む必要があります。

次の例では、これらの概念を説明します。特定のオペレーティング・システムに該当しない場合があること、および各ユーザーに固有の運用環境は想定していないことに注意してください。

次のように、パラメータ・ファイルでTABLESパラメータを指定するとします。

TABLES = \"MixedCaseTableName\"

これをコマンドラインで指定するとき、一部のオペレーティング・システムでは、次のように一重引用符で囲む必要があります。

TABLES = '\"MixedCaseTableName\"'

コマンドラインで追加の引用符を指定せずに手順を続行するには、パラメータ・ファイルを使用することをお薦めします。また、パラメータ・ファイルを使用し、指定するパラメータ値の文字列の最初の文字に引用符を使用しない場合(たとえば、TABLES=scott."EmP")は、エスケープ文字の使用が不要になるシステムがあることに注意してください。

インポート・パラメータの使用例

各項に示す例を試行する場合は、次の内容に注意してください。

- 例に示すようにユーザー名およびパラメータを入力した後、インポート・ユーティリティが起動され、パスワードの入力が要求されます。データベース接続が行われる前に、パスワードを入力する必要があります。

- ここに示す例の多くは、Oracle Databaseのインストール時にデフォルトでインストールされるシード・データベースのサンプル・スキーマを使用しています。特に、人事管理(hr)スキーマを頻繁に使用します。

- インポートするダンプ・ファイルを指定する例では、そのダンプ・ファイルが存在するものとします。可能なかぎり、「データ・ポンプ・エクスポート」のエクスポートの例を実行して生成されるダンプ・ファイルを使用します。

- この例では、ディレクトリ・オブジェクトdpump_dir1およびdpump_dir2がすでに存在し、これらのディレクトリ・オブジェクトについてのREAD権限およびWRITE権限が、hrユーザーに付与されているものとします。ディレクトリ・オブジェクトの作成および権限の割当ての詳細は、「ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置」を参照してください。

- 一部の例では、DATAPUMP_EXP_FULL_DATABASEロールおよびDATAPUMP_IMP_FULL_DATABASEロールが必要です。その例では、hrユーザーにこれらのロールが付与されているものとします。

必要に応じて、これらのディレクトリ・オブジェクトの作成と、必要な権限やロールの割当てをDBAに依頼します。

これらのパラメータの構文図は、「データ・ポンプ・インポートの構文図」を参照してください。

特に指定がないかぎり、これらのパラメータはパラメータ・ファイルでも指定できます。

関連項目:

- インポートの「PARFILE」パラメータ

- デフォルト・ディレクトリ・オブジェクトの作成の詳細は、「ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置」を参照してください

- 「データ・ポンプ・エクスポートの使用例」

- 『Oracle Databaseサンプル・スキーマ』

- システムでの特殊文字および予約文字の処理方法の詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

ABORT_STEP

デフォルト: NULL

用途

ジョブの初期化後に、そのジョブを停止する場合に使用します。これによって、データがインポートされる前に、マスター表への問合せが可能となります。

構文および説明

ABORT_STEP=[n | -1]

指定可能な値は、マスター表内のプロセス・オーダー番号と対応しています。各番号の使用結果は次のとおりです。

- n: 値が0以上の場合は、インポート操作が開始され、対応するプロセス・オーダー番号を持つ、マスター表に格納されているオブジェクトでジョブが中断されます。

- -1およびジョブがNETWORK_LINKを使用するインポートの場合: ジョブの設定後(ただし、いずれかのオブジェクトのインポート前)に中断します。

- -1およびジョブがNETWORK_LINKを使用しないインポートの場合: マスター表をロードしてフィルタを適用した後に、ジョブを中断します。

制限事項

- 「なし」

例

> impdp hr SCHEMAS=hr DIRECTORY=dpump_dir1 LOGFILE=schemas.log
DUMPFILE=expdat.dmp ABORT_STEP=-1

ACCESS_METHOD

デフォルト: AUTOMATIC

用途

インポート・ユーティリティで特定のメソッドを使用してデータをロードするように指定します。

構文および説明

ACCESS_METHOD=[AUTOMATIC | DIRECT_PATH | EXTERNAL_TABLE | CONVENTIONAL]

デフォルトのメソッドがなんらかの理由で動作しない場合に別のネイティブ・メソッドを試行できるように、ACCESS_METHODパラメータが提供されます。できるだけデフォルトのオプション(AUTOMATIC)を使用することをお薦めします(このオプションによって、データ・ポンプは最も効果的なメソッドを自動的に選択できるようになります)。

制限事項

- NETWORK_LINKパラメータも指定した場合、ACCESS_METHODパラメータは無視されます。

- データ・ポンプ・インポートのACCESS_METHODパラメータは、トランスポータブル表領域のジョブに対して有効ではありません。

例

> impdp hr SCHEMAS=hr DIRECTORY=dpump_dir1 LOGFILE=schemas.log
DUMPFILE=expdat.dmp ACCESS_METHOD=CONVENTIONAL

ATTACH

デフォルト: ユーザーのスキーマで現在実行されているジョブ(実行中のジョブが1つのみの場合)

用途

クライアント・セッションを既存のインポート・ジョブに接続し、自動的に対話方式コマンド・モードにします。

構文および説明

ATTACH [=[schema_name.]job_name]

schema_nameは、接続しているスキーマが、自分のスキーマにない場合に指定します。このパラメータを指定するには、DATAPUMP_IMP_FULL_DATABASEロールが必要です。

job_nameは、スキーマに対応する実行中ジョブが1つのみで、そのジョブがアクティブな場合、指定する必要はありません。停止しているジョブに接続する場合は、このジョブ名を指定する必要があります。DBA_DATAPUMP_JOBSビューまたはUSER_DATAPUMP_JOBSビューを問い合せて、データ・ポンプ・ジョブ名の一覧を表示できます。

ジョブに接続している場合、インポート・ユーティリティでは、ジョブの説明が表示され、次にインポート・プロンプトが表示されます。

制限事項

- ATTACHパラメータを指定する場合、コマンドラインで他に指定できるデータ・ポンプ・パラメータは、ENCRYPTION_PASSWORDのみです。

- 接続するジョブが最初に暗号化パスワードを使用して起動している場合、そのジョブへの接続時に、コマンドライン上のENCRYPTION_PASSWORDパラメータを再入力してそのパスワードを再指定する必要があります。

- そのジョブが実行中でなければ、別のスキーマのジョブに接続することはできません。

- ジョブのダンプ・ファイル・セットまたはマスター表が削除されている場合、接続操作は失敗します。

- マスター表を変更すると、それがどのような変更であっても、予期しない結果になる場合があります。

例

次に、ATTACHパラメータの使用例を示します。

> impdp hr ATTACH=import_job

この例では、import_jobというジョブがhrスキーマに存在すると仮定しています。

関連項目:

「インポート・ユーティリティの対話方式コマンド・モードで使用可能なコマンド」

CLUSTER

デフォルト: YES

用途

データ・ポンプでOracle Real Application Clusters(Oracle RAC)リソースを使用できるかどうかと、ワーカーを他のOracle RACインスタンス上で開始できるかどうかを決定します。

構文および説明

CLUSTER=[YES | NO]

データ・ポンプ・インポートで、ジョブが開始されたインスタンスのみを使用し、Oracle Database 11g リリース2(11.2)より前の動作と同じにするには、CLUSTER=NOを指定します。

特定の既存サービスを指定し、そのサービスに定義されたインスタンスでのみ実行されるようにワーカー・プロセスを制限するには、SERVICE_NAMEパラメータとCLUSTER=YESパラメータとともに使用します。

CLUSTERパラメータを使用すると、インポート・ジョブをOracle RACインスタンス全体に分散させるための追加のオーバーヘッドが発生するため、パフォーマンスに影響する場合があります。ジョブが小さいときは、CLUSTER=NOを指定して、ジョブが開始されたインスタンス上のみでジョブを実行した方がよい場合もあります。CLUSTERパラメータを使用してジョブのパフォーマンスが最もよくなるのは、ジョブのデータ量が多い場合です。

例

> impdp hr DIRECTORY=dpump_dir1 SCHEMAS=hr CLUSTER=NO PARALLEL=3 NETWORK_LINK=dbs1

この例では、hrスキーマのスキーマ・モード・インポートを実行します。CLUSTER=NOが使用されているため、ジョブでは起動時のインスタンスのみが使用されます。最大3つまでのパラレル処理を使用できます。dbs1のNETWORK_LINK値は、データのインポート元であるソース・データベース名に置き換えます。(これはネットワーク・インポートであるため、ダンプ・ファイルは生成されません。)

NETWORK_LINKパラメータは、単にこの例の一部として使用されています。CLUSTERパラメータの使用時は必須ではありません。

関連項目:

- 「SERVICE_NAME」

- 「Oracle RACに関する考慮点」

CONTENT

デフォルト: ALL

用途

インポート操作でロードする内容をフィルタ処理できます。

構文および説明

CONTENT=[ALL | DATA_ONLY | METADATA_ONLY]

- ALLを指定すると、ソースに含まれているすべてのデータおよびメタデータがロードされます。これはデフォルトです。

- DATA_ONLYを指定すると、表の行データのみが既存の表にロードされます。データベース・オブジェクトは作成されません。

- METADATA_ONLYを指定すると、データベース・オブジェクト定義のみがロードされ、表の行データはロードされません。CONTENT=METADATA_ONLYを指定した場合、ダンプ・ファイルからインポートされる任意の索引または表の統計は、インポート操作の完了後にロックされることに注意してください。

制限事項

- CONTENT=METADATA_ONLYパラメータおよび値は、TRANSPORT_TABLESPACES(トランスポータブル表領域モード)パラメータまたはQUERYパラメータと組み合せて使用することはできません。

- CONTENT=ALLおよびCONTENT=DATA_ONLYパラメータおよび値は、SQLFILEパラメータと組み合せて使用することはできません。

例

次に、CONTENTパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp CONTENT=METADATA_ONLY

このコマンドは、expfull.dmpダンプ・ファイルのメタデータのみをロードする全体インポートを実行します。全体インポートが実行されるのは、インポート・モードを指定しないファイル・ベースのインポートでは、全体インポートがデフォルトであるためです。

DATA_OPTIONS

デフォルト: デフォルト値は設定されていません。このパラメータが使用されていない場合、このパラメータが提供する特別なデータ処理オプションは無効になります。

用途

DATA_OPTIONSパラメータは、インポート操作時に特定のタイプのデータをどのように処理するかを指定します。

構文および説明

DATA_OPTIONS = [DISABLE_APPEND_HINT | SKIP_CONSTRAINT_ERRORS | REJECT_ROWS_WITH_REPL_CHAR]

- DISABLE_APPEND_HINT: インポート操作で、データ・オブジェクトのロード時にAPPENDヒントを使用しないことを指定します。ロードするデータ・オブジェクトの一部がすでにデータベースに存在し、1つ以上のデータ・オブジェクトに対して他のアプリケーションから同時にアクセスされる可能性がある場合は、APPENDヒントを無効にしたほうが効果的な場合があります。
DISABLE_APPEND_HINTを設定しない場合は、デフォルトの動作によりデータ・オブジェクトのロード中にAPPENDヒントが使用されます。

- SKIP_CONSTRAINT_ERRORS: データ・オブジェクト(表、パーティションまたはサブパーティション)をロードする際の、非遅延制約違反の処理方法に適用されます。遅延制約違反が発生しても、ロードへの影響はありません。遅延制約違反は常に、ロード全体のロール・バックの原因となります。
SKIP_CONSTRAINT_ERRORSオプションでは、非遅延の制約違反が発生した場合もインポート操作を続行することを指定します。非遅延の制約違反の原因となっているすべての行はログに記録されますが、違反が発生しているデータ・オブジェクトのロードは停止されません。

SKIP_CONSTRAINT_ERRORSが設定されていない場合のデフォルトの動作では、非遅延の制約違反が発生しているデータ・オブジェクトのロード全体がロール・バックされます。

- REJECT_ROWS_WITH_REPL_CHAR: キャラクタ・セットの変換中にデフォルトの置換文字が使用されていたためにデータ損失が発生したすべての行をインポート操作で拒否するように指定します。
REJECT_ROWS_WITH_REPL_CHARが設定されていない場合、デフォルトの動作では、置換文字で変換された行がロードされます。

制限事項

- DISABLE_APPEND_HINTを使用すると、データ・オブジェクトのロードにかかる時間が長くなる場合があります。

- SKIP_CONSTRAINT_ERRORSが使用され、データ・オブジェクトがロード時にそのデータ・オブジェクトに対して定義された一意の索引または制約を持つ場合、そのデータ・オブジェクトのロードにAPPENDヒントは使用されません。したがって、SKIP_CONSTRAINT_ERRORSオプションを使用した場合、このようなデータ・オブジェクトのロードにはより時間がかかります。

- データ・オブジェクトが外部表によるアクセス方法を使用せずにロードされている場合、SKIP_CONSTRAINT_ERRORSは、たとえ指定されていても使用されません。

例

この例では、SKIP_CONSTRAINT_ERRORSが有効化されているデータのみの表モード・インポートを示します。

> impdp hr TABLES=employees CONTENT=DATA_ONLY
DUMPFILE=dpump_dir1:table.dmp DATA_OPTIONS=skip_constraint_errors

このインポート操作中に非遅延の制約違反が発生した場合、それはログに記録されますが、インポートは完了するまで続行されます。

DIRECTORY

デフォルト: DATA_PUMP_DIR

用途

インポート・ジョブがダンプ・ファイル・セットを検出し、ログ・ファイルおよびSQLファイルが作成されるデフォルトの位置を指定します。

構文および説明

DIRECTORY=directory_object

directory_objectは、データベースのディレクトリ・オブジェクトの名前です(実際のディレクトリのファイル・パスではありません)。インストール時に、特権ユーザーにDATA_PUMP_DIRという名前のデフォルトのディレクトリ・オブジェクトへのアクセス権が付与されます。デフォルトのDATA_PUMP_DIRディレクトリ・オブジェクトにアクセス可能なユーザーは、DIRECTORYパラメータを使用する必要はまったくありません。

DUMPFILEパラメータ、LOGFILEパラメータまたはSQLFILEパラメータで指定したディレクトリ・オブジェクトは、DIRECTORYパラメータに指定したディレクトリ・オブジェクトよりも優先されます。ダンプ・ファイル・セット用に使用するディレクトリに対する読取り権限と、ログ・ファイルおよびSQLファイルの作成に使用するディレクトリに対する書込み権限が必要です。

例

次に、DIRECTORYパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp
LOGFILE=dpump_dir2:expfull.log

このコマンドによって、インポート・ジョブが、dpump_dir1ディレクトリ・オブジェクトに示されたディレクトリのexpfull.dmpダンプ・ファイルを検索します。LOGFILEパラメータに指定したdpump_dir2ディレクトリ・オブジェクトは、DIRECTORYパラメータよりも優先されるため、ログ・ファイルは、dpump_dir2に書き込まれます。

関連項目:

- デフォルトのディレクトリ・オブジェクト、およびデータ・ポンプがファイルの位置を判断するために使用する優先順位の詳細は、「ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置」を参照してください

- 「Oracle RACに関する考慮点」

- CREATE DIRECTORYコマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください

DUMPFILE

デフォルト: expdat.dmp

用途

Exportによって作成されたダンプ・ファイル・セットの名前を指定します。オプションで、これらのディレクトリ・オブジェクトを指定します。

構文および説明

DUMPFILE=[directory_object:]file_name [, ...]

DIRECTORYパラメータで指定されている場合、directory_objectはオプションです。ここで値を指定する場合は、すでに存在しアクセス権があるディレクトリ・オブジェクトを指定します。DUMPFILEパラメータの一部に指定されるデータベース・ディレクトリ・オブジェクトは、DIRECTORYパラメータで指定された値よりも優先されます。

file_nameには、ダンプ・ファイル・セット内のファイルの名前を指定します。ファイル名には、置換変数%Uを含むテンプレートを指定することもできます。%Uを使用した場合、インポート・ユーティリティは、テンプレートと一致する各ファイルを一致するファイルが検出されなくなるまで調べ、ダンプ・ファイル・セットの一部となるすべてのファイルの位置を特定します。%Uは、01から始まる2桁の整数に変換されます。

DUMPFILEパラメータでのファイル指定にセット全体が含まれている場合は、インポート・ユーティリティでセット全体の位置を特定するための十分な情報がファイルに含まれます。ファイルの名前、位置または順序は、エクスポート時と同じである必要はありません。

制限事項

- データ・ポンプのパラメータVERSION=12を使用してOracle Database 11gリリースで作成したダンプ・ファイルは、Oracle Database 12cリリース1 (12.1)以上でのみインポートできます。

例

次に、インポートのDUMPFILEパラメータの使用例を示します。この例では、ExportのDUMPFILEパラメータで示した例を実行して、ダンプ・ファイルを作成できます。「DUMPFILE」を参照してください。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=dpump_dir2:exp1.dmp, exp2%U.dmp

exp1.dmpダンプ・ファイルに、ディレクトリ・オブジェクト(dpump_dir2)が指定されているため、インポート・ジョブは、そのファイルを検索します。また、dpump_dir1にある、exp2nn.dmpの形式のダンプ・ファイルも検索します。ログ・ファイルは、dpump_dir1に書き込まれます。

関連項目:

- 「ファイルの割当て」

- 「データのみ表モード・インポートの実行」

ENCRYPTION_PASSWORD

デフォルト: デフォルト値は設定されていません。ユーザーが値を指定します。

用途

ダンプ・ファイル・セット内の暗号化列のデータにアクセスするためのパスワードを指定します。これにより、暗号化されたダンプ・ファイル・セットへの不正なアクセスを防ぎます。

これは、全体トランスポータブル・エクスポートまたはインポート操作中に、暗号化された表領域および暗号化された列を含む表に関連するキーを転送する場合にも必要です。

入力したパスワードは画面に表示されます。パスワードを入力時に画面に表示しない場合、ENCRYPTION_PWD_PROMPTパラメータを使用します。

構文および説明

ENCRYPTION_PASSWORD = password

このパラメータは、エクスポート操作で暗号化パスワードが指定された場合に、インポート操作で必要になります。このパスワードは、エクスポート操作で指定されたものと同じものを指定する必要があります。

制限事項

- このパラメータは、Oracle Database 11g以上のEnterprise Editionでのみ有効です。

- データ・ポンプの暗号化機能を使用するには、Oracle Advanced Securityオプションが有効である必要があります。Oracle Advanced Securityオプションのライセンス要件の詳細は、『Oracle Databaseライセンス情報』を参照してください。

- ダンプ・ファイル・セットが暗号化の透過モードを使用して作成されている場合、ENCRYPTION_PASSWORDパラメータは無効です。

- ENCRYPTION_PASSWORDパラメータは、暗号化された表領域または暗号化された列を含む表がソース・データベースに存在するネットワーク・ベースの全体トランスポータブル・インポートでは必須です。

- すべての列に対する暗号化属性は、エクスポートされた表の定義とターゲット表で一致している必要があります。たとえば、EMP表にEMPNOという列があるとします。次のいずれの場合も、ソース表のEMP列の暗号化属性が、ターゲット表のEMP列の暗号化属性と一致していないためエラーになります。

- EMPNO列を暗号化してEMP表をエクスポートし、表をインポートする前にEMPNO列から暗号化属性を削除する。

- EMPNO列を暗号化せずにEMP表をエクスポートし、表をインポートする前にEMPNO列の暗号化を有効にする。

例

次の例では、暗号化パスワード123456を指定する必要があります。これは、ダンプ・ファイルdpcd2be1.dmpの作成時に、そのパスワードが指定されたためです(「ENCRYPTION_PASSWORD」を参照)。

> impdp hr TABLES=employee_s_encrypt DIRECTORY=dpump_dir
DUMPFILE=dpcd2be1.dmp ENCRYPTION_PASSWORD=123456

インポート操作時、エクスポート操作時に暗号化されたemployee_s_encrypt表のすべての列は、複合化されてからインポートされます。

ENCRYPTION_PWD_PROMPT

デフォルト: NO

用途

データ・ポンプによって暗号化パスワードの入力を要求するかどうかを指定します。

構文および説明

ENCRYPTION_PWD_PROMPT=[YES | NO]

コマンドラインでENCRYPTION_PWD_PROMPT=YESと指定すると、ENCRYPTION_PASSWORDパラメータを使用してコマンドラインでパスワードを入力するかわりに、データ・ポンプによって暗号化パスワードの入力を要求されます。この方法のメリットは、プロンプトで入力すると、暗号化パスワードが画面に表示されないことです。これに対し、ENCRYPTION_PASSWORDパラメータを使用してコマンドラインで入力すると、それがプレーン・テキストで表示されます。

プロンプトで入力する暗号化パスワードは、ENCRYPTION_PASSWORDパラメータで説明されているものと同じ基準に従います。

エクスポート操作で暗号化パスワードを指定した場合、インポート操作でもそれを指定する必要があります。

制限事項

- ENCRYPTION_PWD_PROMPTパラメータとENCRYPTION_PASSWORDパラメータの同時使用は禁止されています。

例

次の例では、データ・ポンプによって最初にユーザー・パスワードが要求され、次に暗号化パスワードが要求されます。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp ENCRYPTION_PWD_PROMPT=YES
.
.
.
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

Password:

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit
Production
With the Partitioning, Advanced Analytics and Real Application Testing options

Encryption Password:

Master table "HR"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "HR"."SYS_IMPORT_FULL_01":  hr/******** directory=dpump_dir1 dumpfile=hr.dmp encryption_pwd_prompt=Y
.
.
.

ESTIMATE

デフォルト: BLOCKS

用途

このパラメータによって、ネットワーク・インポート操作のソース・システムで、データの生成量が見積もられます。

構文および説明

ESTIMATE=[BLOCKS | STATISTICS]

ESTIMATEパラメータでは、次の値を選択できます。

- BLOCKS: 見積りは、ソース・オブジェクトで使用されるデータベース・ブロックの数に、適切なブロック・サイズを掛けて計算されます。

- STATISTICS: 見積りは、表別の統計を使用して計算されます。この方法による見積りをできるかぎり正確にするには、すべての表を新しく分析しておく必要があります。(表の分析は、SQL ANALYZE文またはDBMS_STATS PL/SQLパッケージのいずれかで実行可能です。)

生成される見積りは、インポート・ジョブの完了率の確認に使用されます。

制限事項

- インポートのESTIMATEパラメータは、NETWORK_LINKパラメータも指定されている場合のみ有効です。

- インポート・ソースがダンプ・ファイル・セットの場合、ロードされるデータの量がすでにわかっているため、完了率は自動的に計算されます。

- QUERYまたはREMAP_DATAパラメータのいずれかを使用している場合は、見積りが不正確になることがあります。

例

次の例では、source_database_linkにソース・データベースに対する有効なリンク名を指定します。

> impdp hr TABLES=job_history NETWORK_LINK=source_database_link
DIRECTORY=dpump_dir1 ESTIMATE=STATISTICS

hrスキーマのjob_history表が、ソース・データベースからインポートされます。デフォルトでログ・ファイルが作成され、dpump_dir1ディレクトリ・オブジェクトで示されたディレクトリに書き込まれます。ジョブが開始すると、表の統計に基づいて、そのジョブの見積りが計算されます。

EXCLUDE

デフォルト: デフォルト値は設定されていません。

用途

インポート・ジョブから除外するオブジェクトおよびオブジェクト型を指定して、インポートの対象となるメタデータをフィルタ処理できます。

構文および説明

EXCLUDE=object_type[:name_clause] [, ...]

object_typeは除外するオブジェクトのタイプを指定します。DATABASE_EXPORT_OBJECTS(全体モードの場合)、SCHEMA_EXPORT_OBJECTS(スキーマ・モードの場合)、TABLE_EXPORT_OBJECTS(表および表領域モードの場合)ビューを問い合せて、object_typeの有効な値の一覧を表示できます。OBJECT_PATH列にリストされる値が有効なオブジェクト・タイプです。(このような問合せの実行方法の例は、「メタデータのフィルタ」を参照してください。)

指定したインポート・モードでは、EXCLUDE文に指定されたオブジェクト型を除き、ソースに含まれるすべてのオブジェクト型およびその依存オブジェクトが含まれます。オブジェクトが除外されると、そのオブジェクトのすべての依存オブジェクトも除外されます。たとえば、表を除外すると、その表のすべての索引およびトリガーも除外されます。

name_clauseは、オプションです。これを使用すると、あるオブジェクト型のうち、特定のオブジェクトをファイングレイン選択できます。その型のオブジェクト名に対するフィルタとして使用されるSQL式です。SQL演算子および指定した型のオブジェクト名の比較対象となる値で構成されています。name_clauseは、名前付きのインスタンスを持つオブジェクト型にのみ適用されます(たとえば、TABLEおよびVIEWには適用されますが、GRANTには適用されません)。それは、コロンでオブジェクト型と区切り、二重引用符(一重引用符は名前文字列を区切るために必要なため)で囲む必要があります。たとえば、EXCLUDE=INDEX:"LIKE 'DEPT%'"と設定した場合、deptで始まる名前を持つすべての索引を除外できます。

name_clauseに指定する名前は、データベース内の既存のオブジェクトに、大文字と小文字も含めて完全に一致させる必要があります。たとえば、指定するname_clauseがEMPLOYEESという表に対するものだった場合は、すべてが大文字のEMPLOYEESという表が存在する必要があります。name_clauseに対してEmployees、employeesなどを指定した場合、表は検出されません。

2つ以上のEXCLUDE文を指定できます。

オペレーティング・システムによっては、このパラメータの値を指定するときに引用符とともにエスケープ文字を使用する必要があります。このパラメータはパラメータ・ファイルで指定することをお薦めします。パラメータ・ファイルを使用すると、コマンドラインでは必要なエスケープ文字の数を減らすことができます。

次の項で説明するとおり、特定のオブジェクト(特にCONSTRAINT、GRANTおよびUSER)を除外対象として指定した場合の効果を認識しておく必要があります。

制約の除外

次の制約は除外できません。

- 表の作成とロードを正常に行うために必要な制約。たとえば、索引構成表の主キー制約、REF列を持つ表のREF SCOPEおよびWITH ROWID制約など。

次に、EXCLUDE文の例およびその解釈を示します。

- EXCLUDE=CONSTRAINTでは、表の正常な作成およびロードに必要な制約を除く、すべての制約を除外します。

- EXCLUDE=REF_CONSTRAINTは、参照整合性(外部キー)制約を除外します。

権限とユーザーの除外

EXCLUDE=GRANTを指定すると、すべてのオブジェクト型に対するオブジェクト権限およびシステム権限が除外されます。

EXCLUDE=USERを指定すると、ユーザーの定義のみが除外され、そのユーザーのスキーマ内のオブジェクトは除外されません。

特定のユーザーとそのユーザーのすべてのオブジェクトを除外するには、次のコマンドを指定します(hrは除外するユーザーのスキーマ名です)。

impdp FULL=YES DUMPFILE=expfull.dmp EXCLUDE=SCHEMA:"='HR'"

ここで、インポート・モードがFULLに指定されていることに注意してください。モードを指定しなかった場合は、デフォルト・モードのSCHEMASが使用されます。その場合は、スキーマをインポートすると同時に除外するようコマンドが指示することになるため、エラーが発生します。

EXCLUDE=USER:"= 'HR'"などの文を使用してユーザーを除外しようとすると、DDL文CREATE USER hr のみが除外され、期待した結果が得られない場合があります。

制限事項

- EXCLUDEおよびINCLUDEは、相互に排他的なパラメータです。

例

DBAまたはDATAPUMP_IMP_FULL_DATABASEロールを持つ他のユーザーが、パラメータ・ファイルexclude.parで次のように実行するとします。(例を実行するには、まずこのファイルを作成する必要があります。)

EXCLUDE=FUNCTION
EXCLUDE=PROCEDURE
EXCLUDE=PACKAGE
EXCLUDE=INDEX:"LIKE 'EMP%' "

次のコマンドを発行します。このコマンドでは、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp system DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp PARFILE=exclude.par

expfull.dmpダンプ・ファイルから、empで始まる名前を持つファンクション、プロシージャ、パッケージおよび索引を除くすべてのデータがロードされます。

関連項目:

EXCLUDEパラメータを使用した場合の効果の詳細は、「インポート操作中のフィルタ処理」を参照してください

「データ・ポンプ・コマンドラインでの引用符の使用」

FLASHBACK_SCN

デフォルト: デフォルト値は設定されていません。

用途

インポートで使用されるシステム変更番号(SCN)を指定して、フラッシュバック・ユーティリティを使用可能にします。

構文および説明

FLASHBACK_SCN=scn_number

インポート操作は、指定したscn_numberまでの一貫性のあるデータを使用して実行されます。

注意:

ロジカル・スタンバイ・システムでは、ロジカル・スタンバイによってSCNが選択されるため、FLASHBACK_SCNパラメータは無視されます。ロジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。

制限事項

- FLASHBACK_SCNパラメータは、NETWORK_LINKパラメータも指定されている場合のみ有効です。

- FLASHBACK_SCNパラメータは、Oracle Databaseのフラッシュバック問合せ機能にのみ関係します。フラッシュバック・データベース、フラッシュバック削除およびフラッシュバック・データ・アーカイブには適用できません。

- FLASHBACK_SCNおよびFLASHBACK_TIMEは、相互に排他的なパラメータです。

例

次に、FLASHBACK_SCNパラメータの使用例を示します。

> impdp hr DIRECTORY=dpump_dir1 FLASHBACK_SCN=123456
NETWORK_LINK=source_database_link

この例のsource_database_linkには、データのインポート元であるソース・データベース名を指定します。

FLASHBACK_TIME

デフォルト: デフォルト値は設定されていません。

用途

インポートで使用されるシステム変更番号(SCN)を指定して、フラッシュバック・ユーティリティを使用可能にします。

構文および説明

FLASHBACK_TIME="TO_TIMESTAMP()"

指定された時刻に最も近いSCNを検出し、このSCNを使用してフラッシュバック・ユーティリティを使用可能にします。インポート操作は、このSCNまでの一貫性のあるデータを使用して実行されます。TO_TIMESTAMPの値は引用符で囲まれるため、パラメータ・ファイルに記述することをお薦めします。詳細は、「データ・ポンプ・コマンドラインでの引用符の使用」を参照してください。

注意:

ロジカル・スタンバイ・システムでは、ロジカル・スタンバイによってSCNが選択されるため、FLASHBACK_TIMEパラメータは無視されます。ロジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。

制限事項

- このパラメータは、NETWORK_LINKパラメータも指定されている場合にのみ有効です。

- FLASHBACK_TIMEパラメータは、Oracle Databaseのフラッシュバック問合せ機能にのみ関係します。フラッシュバック・データベース、フラッシュバック削除およびフラッシュバック・データ・アーカイブには適用できません。

- FLASHBACK_TIMEおよびFLASHBACK_SCNは、相互に排他的なパラメータです。

例

DBMS_FLASHBACK.ENABLE_AT_TIMEプロシージャで使用可能な形式で時刻を指定できます。たとえば、次の内容のパラメータ・ファイルflashback_imp.parを作成したとします。

FLASHBACK_TIME="TO_TIMESTAMP('27-10-2012 13:40:00', 'DD-MM-YYYY HH24:MI:SS')"

次のコマンドを発行します。

> impdp hr DIRECTORY=dpump_dir1 PARFILE=flashback_imp.par NETWORK_LINK=source_database_link

インポート操作は、指定した時間に最も近いSCNと整合性のあるデータで実行されます。

関連項目:

フラッシュバックの使用方法の詳細は、『Oracle Database開発ガイド』を参照してください。

FULL

デフォルト: YES

用途

全データベース・インポートの実行を指定します。

構文および説明

FULL=YES

FULL=YESの値は、ソースからのすべてのデータおよびメタデータがインポートされることを示します。ソースは、ダンプ・ファイル・セットにするか(ファイル・ベース・インポートの場合)、NETWORK_LINKパラメータで指定された別のデータベースにすることができます(ネットワーク・インポートの場合)。

ファイルからインポートする際に、DATAPUMP_IMP_FULL_DATABASEロールを持っていない場合、自分のスキーマにマップするスキーマのみインポートされます。

NETWORK_LINKパラメータが使用され、インポート・ジョブを実行するユーザーがターゲット・データベースのDATAPUMP_IMP_FULL_DATABASEロールを持っている場合、そのユーザーは、ソース・データベースのDATAPUMP_EXP_FULL_DATABASEロールも持っている必要があります。

このモードを使用したインポート対象を、フィルタ処理によってより詳細に制限できます(詳細は、「インポート操作中のフィルタ処理」を参照してください)。

FULLはデフォルトのモードで、ファイル・ベースのインポートを実行している場合、コマンドラインで指定する必要はありませんが、ネットワーク・ベースの全体インポートを実行している場合は、コマンドラインでFULL=Yを指定する必要があります。

全体モード・インポート時にトランスポータブル・オプションを使用して、全体トランスポータブル・インポートを実行できます。「全体モード・インポート時のトランスポータブル・オプションの使用」を参照してください。

制限事項

- 自動ワークロード・リポジトリ(AWR)は、全データベースのエクスポートおよびインポート操作では移動されません。(データ・ポンプを使用してAWRスナップショットを移動する方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。)

- XDBリポジトリは、全データベースのエクスポートおよびインポート操作では移動されません。ユーザーが作成したXMLスキーマは移動されます。

- ターゲットがOracle Database 12cリリース1 (12.1.0.1)以降で、ソースがOracle Database 11gリリース2 (11.2.0.3)以降である場合、ネットワーク・リンクで実行される全体インポートでは、VERSION=12を設定する必要があります。

例

次に、FULLパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr DUMPFILE=dpump_dir1:expfull.dmp FULL=YES
LOGFILE=dpump_dir2:full_imp.log

この例では、expfull.dmpダンプ・ファイルのすべての内容をインポートします。ここでは、DIRECTORYパラメータは指定されていません。そのため、DUMPFILEパラメータおよびLOGFILEパラメータの両方にディレクトリ・オブジェクトを指定する必要があります。例に示すとおり、ディレクトリ・オブジェクトは、別のものを指定することができます。

HELP

デフォルト: NO

用途

インポート・ユーティリティのオンライン・ヘルプを表示します。

構文および説明

HELP=YES

HELP=YESが指定されている場合は、インポート・ユーティリティのすべてのコマンドライン・パラメータと対話方式コマンドの要約が表示されます。

例

> impdp HELP = YES

この例では、すべてのインポート・パラメータおよびコマンドの簡単な説明が表示されます。

INCLUDE

デフォルト: デフォルト値は設定されていません。

用途

現行のインポート・モードにオブジェクトとオブジェクト型を指定して、インポート対象のメタデータをフィルタ処理できます。

構文および説明

INCLUDE = object_type[:name_clause] [, ...]

object_typeは含めるオブジェクトのタイプを指定します。DATABASE_EXPORT_OBJECTS(全体モードの場合)、SCHEMA_EXPORT_OBJECTS(スキーマ・モードの場合)、TABLE_EXPORT_OBJECTS(表および表領域モードの場合)ビューを問い合せて、object_typeの有効な値の一覧を表示できます。OBJECT_PATH列にリストされる値が有効なオブジェクト・タイプです。(このような問合せの実行方法の例は、「メタデータのフィルタ」を参照してください。)

INCLUDE文に明示的に指定した、ソース内のオブジェクト型とその依存オブジェクトのみがインポートされます。

name_clauseは、オプションです。これを使用すると、あるオブジェクト型のうち、特定のオブジェクトをファイングレイン選択できます。その型のオブジェクト名に対するフィルタとして使用されるSQL式です。SQL演算子および指定した型のオブジェクト名の比較対象となる値で構成されています。このname_clauseは、名前付きのインスタンスを持つオブジェクト型にのみ適用されます(たとえば、TABLEには適用されますが、GRANTには適用されません)。それは、コロンでオブジェクト型と区切り、二重引用符(一重引用符は名前文字列を区切るために必要なため)で囲む必要があります。

name_clauseに指定する名前は、データベース内の既存のオブジェクトに、大文字と小文字も含めて完全に一致させる必要があります。たとえば、指定するname_clauseがEMPLOYEESという表に対するものだった場合は、すべてが大文字のEMPLOYEESという表が存在する必要があります。name_clauseに対してEmployees、employeesなどを指定した場合、表は検出されません。

2つ以上のINCLUDE文を指定できます。

オペレーティング・システムによっては、このパラメータの値を指定するときに引用符とともにエスケープ文字を使用する必要があります。このパラメータはパラメータ・ファイルで指定することをお薦めします。パラメータ・ファイルを使用すると、コマンドラインでは必要なエスケープ文字の数を減らすことができます。詳細は、「データ・ポンプ・コマンドラインでの引用符の使用」を参照してください。

DATABASE_EXPORT_OBJECTS(全体モードの場合)、SCHEMA_EXPORT_OBJECTS(スキーマ・モードの場合)、TABLE_EXPORT_OBJECTS(表および表領域モードの場合)ビューを問い合せて、INCLUDEパラメータで使用する有効なパスの一覧を表示できます。

制限事項

- INCLUDEおよびEXCLUDEは、相互に排他的なパラメータです。

例

DBAまたはDATAPUMP_IMP_FULL_DATABASEロールを持つ他のユーザーが、パラメータ・ファイルimp_include.parで次のように実行するとします。

INCLUDE=FUNCTION
INCLUDE=PROCEDURE
INCLUDE=PACKAGE
INCLUDE=INDEX:"LIKE 'EMP%' "

次のコマンドを発行します。

> impdp system SCHEMAS=hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp
PARFILE=imp_include.par

この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

このインポートでは、hrスキーマのファンクション、プロシージャ、パッケージ、および名前がEMPで始まる索引のみロードされます。これは特権モードのインポート(ユーザーにDATAPUMP_IMP_FULL_DATABASEロールがある)ですが、USERオブジェクト型がINCLUDE文に指定されていないため、スキーマ定義はインポートされません。

JOB_NAME

デフォルト: SYS_<IMPORTまたはSQLFILE>_<mode>_NNという書式のシステム生成による名前

用途

ジョブ名は、ジョブへの接続にATTACHパラメータを使用したり、DBA_DATAPUMP_JOBSまたはUSER_DATAPUMP_JOBSビューを使用してジョブを指定する場合など、後続処理でインポート・ジョブを指定するために使用されます。

構文および説明

JOB_NAME=jobname_string

jobname_stringには、このインポート・ジョブの名前を、30バイト以内で指定します。これらのバイトは印字可能文字と空白を表します。空白を含む場合は、一重引用符で囲みます(たとえば、'Thursday Import'とします)。ジョブ名は、インポート操作を実行しているユーザーのスキーマによって暗黙的に修飾されます。ジョブ名は、マスター表の名前として使用されます(マスター表はエクスポート・ジョブを制御します)。

デフォルトのジョブ名はSYS_IMPORT_mode_NNまたはSYS_SQLFILE_mode_NNという形式で、システムによって生成されます。NNは、01から始めて増加する2桁の整数です。デフォルト名は、'SYS_IMPORT_TABLESPACE_02'などです。

例

次に、JOB_NAMEパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp JOB_NAME=impjob01

KEEP_MASTER

デフォルト: NO

用途

正常に完了したデータ・ポンプ・ジョブの最後に、マスター表を削除するか、または保持するかを示します。ジョブが正常に完了しなかった場合、マスター表は自動的に保持されます。

構文および説明

KEEP_MASTER=[YES | NO]

制限事項

- 「なし」

例

> impdp hr SCHEMAS=hr DIRECTORY=dpump_dir1 LOGFILE=schemas.log
DUMPFILE=expdat.dmp KEEP_MASTER=YES

LOGFILE

デフォルト: import.log

用途

インポート・ジョブのログ・ファイルの名前を指定します。オプションで、そのログ・ファイルのディレクトリ・オブジェクトを指定します。

構文および説明

LOGFILE=[directory_object:]file_name

directory_objectには、DBAによって作成済で、自分にアクセス権があるディレクトリ・オブジェクトを指定する必要があります。この指定は、DIRECTORYパラメータに指定されたディレクトリ・オブジェクトよりも優先されます。デフォルトでは、DIRECTORYパラメータに指定されているディレクトリ・オブジェクトによって参照されるディレクトリ内に、import.logが作成されます。

file_nameに指定したファイルがすでに存在する場合、そのファイルは上書きされます。

処理中の作業、完了した作業および発生したエラーに関するすべてのメッセージがログ・ファイルに書き込まれます。(ジョブのリアルタイムの状態を把握するには、対話方式モードでSTATUSコマンドを使用します。)

NOLOGFILEパラメータが指定されていないかぎり、常に、ログ・ファイルは作成されます。ダンプ・ファイル・セットと同様に、ログ・ファイルの基準となるのは、クライアントではなく、サーバーです。

注意:

データ・ポンプ・インポート・ユーティリティは、データベースのキャラクタ・セットを使用してログ・ファイルに書込みを行います。クライアントのNLS_LANG環境にデータベースのキャラクタ・セットと異なるキャラクタ・セットを設定した場合は、ログ・ファイル内の表の名前が、クライアントの出力画面に表示される名前と異なることがあります。

制限事項

- Oracle Automatic Storage Management (Oracle ASM)を使用してデータ・ポンプ・インポートを実行する場合、LOGFILEパラメータは、Oracle ASMの+表記法を使用せずにディレクトリ・オブジェクトを指定する必要があります。つまり、ログ・ファイルはディスク・ファイルに書き込まれ、Oracle ASMの記憶域には書き込まれません。かわりに、NOLOGFILE=YESを指定することもできます。ただし、この場合はログ・ファイルの書込みは行われません。

例

次に、LOGFILEパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr SCHEMAS=HR DIRECTORY=dpump_dir2 LOGFILE=imp.log
DUMPFILE=dpump_dir1:expfull.dmp

LOGFILEパラメータにはディレクトリ・オブジェクトが指定されていないため、ログ・ファイルは、DIRECTORYパラメータに指定したディレクトリ・オブジェクトに書き込まれます。

関連項目:

- 「STATUS」

- Oracle Automatic Storage Managementおよびディレクトリ・オブジェクトの詳細は、「Oracle Automatic Storage Managementを使用可能にした場合のディレクトリ・オブジェクトの使用方法」を参照してください

LOGTIME

デフォルト: タイムスタンプは記録されません。

用途

インポート操作中に表示されるメッセージにタイムスタンプを付けるように指定します。タイムスタンプを使用して、データ・ポンプ操作の異なるフェーズ間の経過時間を計算できます。この情報は、パフォーマンス問題を診断する場合や、将来の同じような操作の時間を見積もる場合に役立ちます。

構文および説明

LOGTIME=[NONE | STATUS | LOGFILE | ALL]

使用可能なオプションの定義は次のとおりです。

- NONE: ステータス・メッセージまたはログ・ファイル・メッセージにタイムスタンプを付けません(デフォルトと同じ)。

- STATUS: ステータス・メッセージにのみタイムスタンプを付けます。

- LOGFILE: ログ・ファイル・メッセージにのみタイムスタンプを付けます。

- ALL: ステータス・メッセージとログ・ファイル・メッセージの両方にタイムスタンプを付けます。

制限事項

- 「なし」

例

次の例では、インポート操作中に表示されるすべてのステータス・メッセージとログ・ファイル・メッセージにタイムスタンプを記録します。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expdat.dmp SCHEMAS=hr LOGTIME=ALL TABLE_EXISTS_ACTION=REPLACE

LOGTIMEの出力例は、エクスポートの「LOGTIME」パラメータを参照してください。

MASTER_ONLY

デフォルト: NO

用途

マスター表の内容を確認できるように、マスター表のみをインポートしてジョブを停止するかどうかを示します。

構文および説明

MASTER_ONLY=[YES | NO]

制限事項

- NETWORK_LINKパラメータも指定する場合、MASTER_ONLY=YESはサポートされません。

例

> impdp hr SCHEMAS=hr DIRECTORY=dpump_dir1 LOGFILE=schemas.log
DUMPFILE=expdat.dmp MASTER_ONLY=YES

METRICS

デフォルト: NO

用途

ジョブに関する詳細情報をデータ・ポンプ・ログ・ファイルに記録するかどうかを示します。

構文および説明

METRICS=[YES | NO]

METRICS=YESを使用すると、オブジェクト数および経過時間がデータ・ポンプ・ログ・ファイルに記録されます。

制限事項

- 「なし」

例

> impdp hr SCHEMAS=hr DIRECTORY=dpump_dir1 LOGFILE=schemas.log
DUMPFILE=expdat.dmp METRICS=YES

NETWORK_LINK

デフォルト: デフォルト値は設定されていません。

用途

有効なデータベース・リンクによって指定される(ソース)データベースからのインポートを使用可能にします。ソース・データベース・インスタンスのデータは、接続されたデータベース・インスタンスに直接書き込まれます。

構文および説明

NETWORK_LINK=source_database_link

NETWORK_LINKパラメータは、データベース・リンクを使用してインポートを開始します。つまり、impdpクライアントの接続先となるシステムから、source_database_linkで指定されたソース・データベースに接続し、そこからデータを取り出して、接続されたインスタンスのデータベースに直接書き込みます。ダンプ・ファイルは含まれません。

source_database_linkには、使用可能なデータベースへのデータベース・リンク名を指定する必要があります。対象インスタンスのデータベースにデータベース・リンクが指定されていない場合、ユーザーまたはDBAが、SQL CREATE DATABASE LINK文を使用してデータベース・リンクを作成する必要があります。

トランスポータブル・メソッドを使用してネットワーク・インポートを実行する場合は、インポートを開始する前に、ソース・データ・ファイルをターゲット・データベースにコピーする必要があります。

ソース・データベースが読取り専用の場合、接続されたユーザーは、デフォルト一時表領域として割り当てられたローカル管理一時表領域をソース・データベース上に持つ必要があります。それ以外の場合、ジョブは失敗します。

このパラメータは、FLASHBACK_SCN、FLASHBACK_TIME、ESTIMATE、TRANSPORT_TABLESPACESまたはTRANSPORTABLEのいずれかのパラメータを指定する場合に必要です。

データ・ポンプ・インポートでは、次のタイプのデータベース・リンクの使用がサポートされています。

- パブリック固定ユーザー

- パブリック接続ユーザー

- パブリック共有ユーザー(リンク所有者が使用する場合のみ)

- プライベート共有ユーザー(リンク所有者が使用する場合のみ)

- プライベート固定ユーザー(リンク所有者が使用する場合のみ)

注意:

暗号化されていないネットワーク・リンクを介してインポート操作が行われる場合、すべてのデータはクリア・テキストとしてインポートされます。これは、データがデータベースで暗号化されている場合でも同様です。ネットワーク・セキュリティの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

制限事項

- データ・ポンプ・インポートでは、次のタイプのデータベース・リンクの使用はサポートされません。

- プライベート接続ユーザー

- 現行ユーザー

- ContentTypeセットがあるSecureFiles、または現在Oracle Database File System Linksを介してSecureFilesセグメントの外に格納されているSecureFilesが表に含まれている場合、インポートのNETWORK_LINKパラメータはサポートされません。

- ネットワーク・インポートは進化した型の使用をサポートしません。

- ネットワーク・インポートはLONG列をサポートしません。

- データ・ポンプ操作がネットワーク・リンクを介して行われる場合、ソース・データベースとターゲット・データベースのバージョンの差違が2バージョン以下である必要があります。たとえば、一方のデータベースがOracle Database 12cの場合、他方のデータベースは12c、11gまたは10gである必要があります。データ・ポンプがチェックするのはメジャー・バージョン番号のみ(10g、11g、12cなど)で、具体的なリリース番号(12.1、10.1、10.2、11.1、11.2など)ではありません。

- インポート・ジョブを実行するUSERIDがターゲット・データベースのDATAPUMP_IMP_FULL_DATABASEロールを持っている場合、そのユーザーは、ソース・データベースのDATAPUMP_EXP_FULL_DATABASEロールも持っている必要があります。

- ネットワーク・モード・インポートではパラレル問合せ(PQ)スレーブは使用されません。「ネットワーク・モード・インポートにおけるPARALLELの使用」を参照してください。

- 全体トランスポータブル・インポートを使用してネットワークを介してデータベースを転送する場合、管理表領域(SYSTEMやSYSAUXなど)に存在するLONGまたはLONG RAW列を含む表は、サポートされません。

- 全体トランスポータブル・インポートを使用してネットワークを介してデータベースを転送する場合、監査証跡情報自体がユーザー定義の表領域に格納されていると、管理表領域(SYSTEMやSYSAUXなど)に格納された表に対して監査を有効にすることはできません。

例

次の例では、source_database_linkを有効なデータベース・リンクの名前に置き換えます。

> impdp hr TABLES=employees DIRECTORY=dpump_dir1
NETWORK_LINK=source_database_link EXCLUDE=CONSTRAINT

この例では、ソース・データベースからemployees 表(制約を除く)がインポートされます。ログ・ファイルは、DIRECTORYパラメータに指定したdpump_dir1に書き込まれます。

関連項目:

- データベース・リンクの詳細は、Oracle Database管理者ガイドを参照してください。

- CREATE DATABASE LINK文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- ローカル管理表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

NOLOGFILE

デフォルト: NO

用途

デフォルトでログ・ファイルを作成するかどうかを指定します。

構文および説明

NOLOGFILE=[YES | NO]

NOLOGFILE=YESを指定すると、ログ・ファイルは作成されません。ただし、進捗とエラーに関する情報が、接続されているいずれかのクライアント(オリジナルのエクスポート操作を開始したクライアントを含む)の標準出力デバイスに書き込まれます。実行中のジョブに接続されているクライアントが存在しないときにNOLOGFILE=YESを指定すると、重要な進捗情報およびエラー情報が失われる危険性があります。

例

次に、NOLOGFILEパラメータの使用例を示します。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp NOLOGFILE=YES

このコマンドを実行すると、expfull.dmpダンプ・ファイルの全体インポート・モード(ファイル・ベース・インポートのデフォルト)が実行されます。NOLOGFILEにYESが設定されているため、ログ・ファイルは書き込まれません。

PARALLEL

デフォルト: 1

用途

インポート・ジョブのために動作するアクティブな実行プロセスの最大数を指定します。

構文および説明

PARALLEL=integer

integerに指定する値によって、インポート・ジョブのために動作するアクティブな実行プロセスの最大数が指定されます。この実行セットはワーカー・プロセスおよびパラレルI/Oサーバーの処理の組合せで構成されています。パラレルI/O操作でパラレル実行コーディネータとして動作するマスター制御プロセス、アイドル状態のワーカーおよびワーカー・プロセスは、この合計数には加算されません。このパラメータを使用して、リソース消費と経過時間のバランスをとることができます。

インポートのソースがファイルで構成されるダンプ・ファイル・セットの場合、同じファイルから複数のプロセスが読取り可能ですが、パフォーマンスは、I/O競合によって制限されます。

ジョブの実行中にPARALLELの値を増減するには、対話方式コマンド・モードを使用します。

並列度は、ユーザー・データおよびパッケージ本体のロード、索引の作成に使用します。

ネットワーク・モード・インポートにおけるPARALLELの使用

ネットワーク・モード・インポート中、PARALLELパラメータによって、ジョブに割り当てることができるワーカー・プロセスの最大数が定義されます。ネットワーク・モード・インポート中のPARALLELパラメータの影響を理解するには、データ・ポンプによって定義されるtable_dataオブジェクトの概念を理解することが重要です。データ・ポンプでは、データを移動するとき、次の項目を個々のtable_dataオブジェクトとみなします。

- 完全な表(パーティションまたはサブパーティションされていないもの)

- パーティション(表がパーティション化されているがサブパーティション化されていない場合)

- サブパーティション(表がサブパーティション化されている場合)

次に例を示します。

- 非パーティション表scott.non_part_tableには次の1つのtable_dataオブジェクトがあります。
scott.non_part_table

- パーティション表scott.part_table(パーティションp1とパーティションp2を持つ)には次の2つのtable_dataオブジェクトがあります。
scott.part_table:p1

scott.part_table:p2

- サブパーティション表scott.sub_part_table(パーティションp1とp2、およびサブパーティションp1s1、p1s2、p2s1およびp2s2を持つ)には次の4つのtable_dataオブジェクトがあります。
scott.sub_part_table:p1s1

scott.sub_part_table:p1s2

scott.sub_part_table:p2s1

scott.sub_part_table:p2s2

ネットワーク・モード・インポート中、各table_dataオブジェクトには、PARALLELパラメータに指定された値までの独自のワーカー・プロセスが割り当てられます。ネットワーク・モード・インポートではパラレル問合せ(PQ)スレーブを使用しないため、パラレル問合せ(PQ)スレーブは割り当てられません。複数のtable_dataオブジェクトを同時にアンロードすることは可能ですが、各table_dataオブジェクトはシングル・プロセスを使用してアンロードされます。

Oracle RAC環境でのインポートにおけるPARALLELの使用

Oracle Real Application Clusters(Oracle RAC)環境でPARALLEL=1としてインポート操作を実行すると、すべてのデータ・ポンプ・プロセスは、ジョブが開始されたインスタンス上に配置されます。そのため、ディレクトリ・オブジェクトは、そのインスタンスのローカル記憶域を示すことができます。

PARALLELを1より大きな値に設定してインポート操作を実行する場合は、ジョブが開始されたインスタンス以外のインスタンスにもデータ・ポンプ・プロセスを置くことができます。そのため、ディレクトリ・オブジェクトは、Oracle RACのすべてのインスタンスからアクセス可能な共有記憶域を示す必要があります。

制限事項

- このパラメータは、Oracle Database 11g以上のEnterprise Editionでのみ有効です。

- 表および表パーティションをパラレルで(PQスレーブを使用して)インポートするには、DATAPUMP_IMP_FULL_DATABASEロールが必要です。

例

次に、PARALLELパラメータの使用例を示します。

> impdp hr DIRECTORY=dpump_dir1 LOGFILE=parallel_import.log
JOB_NAME=imp_par3 DUMPFILE=par_exp%U.dmp PARALLEL=3

このコマンドは、ExportのPARALLELパラメータの例を実行した場合に作成されるダンプ・ファイル・セットをインポートします。(「PARALLEL」を参照してください。)ダンプ・ファイル名は、par_exp01.dmp、par_exp02.dmpおよびpar_exp03.dmpです。

関連項目:

「リソース消費の制御」

PARFILE

デフォルト: デフォルト値は設定されていません。

用途

インポート・パラメータ・ファイルの名前を指定します。

構文および説明

PARFILE=[directory_path]file_name

パラメータ・ファイルでは、ファイル内にデータ・ポンプ・パラメータを指定して、すべてのコマンドを個別に入力するかわりにそのファイルをコマンドラインに指定できます。これは、同じパラメータの組合せを何度も使用する場合に便利です。値の指定に引用符が必要なパラメータを使用する場合も、パラメータ・ファイルを使用することをお薦めします。

サーバーによって作成されて書き込まれるダンプ・ファイル、ログ・ファイルおよびSQLファイルとは異なり、パラメータ・ファイルはimpdpクライアントによって開かれて読み取られるため、パラメータ・ファイルにディレクトリ・オブジェクトは指定されません。パラメータ・ファイルのデフォルトの場所は、ユーザーのカレント・ディレクトリです。

パラメータ・ファイル内では、カンマはすべての改行文字に暗黙的に含まれるため、各行の最後にカンマを入力する必要はありません。長い表名など、折返しを含む長い行がある場合、現在の行の最後にバックスラッシュ継続文字(\)を入力して次の行に継続します。

制限事項

- PARFILEパラメータは、パラメータ・ファイル内には指定できません。

例

パラメータ・ファイルhr_imp.parの内容は、次のとおりです。

TABLES= countries, locations, regions
DUMPFILE=dpump_dir2:exp1.dmp,exp2%U.dmp
DIRECTORY=dpump_dir1
PARALLEL=3

このパラメータ・ファイルを指定するには、次のコマンドを実行します。

> impdp hr PARFILE=hr_imp.par

表countries、locationsおよびregionsは、ExportのDUMPFILEパラメータの例を実行した場合に作成されるダンプ・ファイル・セットからインポートされます。(「DUMPFILE」を参照してください。)インポート・ジョブは、dpump_dir2で示される位置にあるexp1.dmpファイルを検索します。また、dpump_dir1によって示される位置にあるexp2nn.dmpの形式のすべてのダンプ・ファイルも検索します。そのジョブのログ・ファイルも、dpump_dir1に書き込まれます。

関連項目:

「データ・ポンプ・コマンドラインでの引用符の使用」

PARTITION_OPTIONS

デフォルト: パーティション名がTABLESパラメータで指定され、TRANPORTABLE=ALWAYSが(インポート操作時またはエクスポート中に)設定されている場合、デフォルトはdepartitionです。それ以外の場合、デフォルトはnoneとなります。

用途

インポート操作中に表パーティションをどのように作成するかを指定します。

構文および説明

PARTITION_OPTIONS=[NONE | DEPARTITION | MERGE]

noneの値を指定した場合、エクスポート操作が実行されたシステム上に存在していたのと同様に表が作成されます。エクスポートがパーティションまたはサブパーティション・フィルタとともにトランスポータブル・メソッドを使用して実行されている場合、noneオプションまたはmergeオプションは使用できません。そのような場合は、departitionオプションを使用する必要があります。

departitionの値を指定した場合、各パーティションまたはサブパーティションは、新しい個々の表に昇格します。新規表のデフォルト名は、表とパーティションの名前、または表とサブパーティションの名前を適切に組み合せたものとなります。

mergeの値を設定した場合、すべてのパーティションおよびサブパーティションは1つの表に統合されます。

パーティション表のインポート中の並列処理では次のような影響があります。

- パーティション表が既存のパーティション表にインポートされた場合、データ・ポンプはPARALLELパラメータで指定される値にかかわらず、一度に1つのパーティションまたはサブパーティションのみを処理します。

- インポート先の表がまだ存在しておらず、データ・ポンプでそれを作成する必要がある場合、インポートは、インポートが開始されたときにPARALLELパラメータで指定された並列化まで並列して実行します。

制限事項

- ダンプ・ファイルを作成したエクスポート操作がトランスポータブル・メソッドにより実行されており、パーティションまたはサブパーティションが指定されている場合、インポート操作ではdepartitionオプションを使用する必要があります。

- ダンプ・ファイルを作成したエクスポート操作がトランスポータブル・メソッドにより実行されている場合、インポート操作でPARTITION_OPTIONS=MERGEは使用できません。

- 非パーティション化されているオブジェクトに対する権限が存在する場合、エラー・メッセージが生成され、オブジェクトはロードされません。

例

次の例は、sh.sales表がsales.dmpという名前のダンプ・ファイルにエクスポートされていることを前提としています。ここでは、mergeオプションを使用して、sh.sales内のすべてのパーティションをscottスキーマ内の非パーティション表にマージします。

> impdp system TABLES=sh.sales PARTITION_OPTIONS=MERGE
DIRECTORY=dpump_dir1 DUMPFILE=sales.dmp REMAP_SCHEMA=sh:scott

関連項目:

PARTITION_OPTIONS=DEPARTITIONを使用したインポート操作の実行例は、「TRANSPORTABLE」を参照してください

QUERY

デフォルト: デフォルト値は設定されていません。

用途

インポート対象となるデータをフィルタ処理する問合せ句を指定できます。

構文および説明

QUERY=[[schema_name.]table_name:]query_clause

通常、query_clauseでは、ファイングレイン行選択のためのSQL WHERE句を使用しますが、任意のSQL句を使用できます。たとえば、ORDER BY句を使用すると、ヒープ構成表から索引構成表への移行を高速化できます。スキーマおよび表名を指定しなかった場合は、ソース・ダンプ・ファイル・セットまたはデータベース内のすべての表に問合せが適用されます(この場合、問合せは、これらのすべての表に対して有効である必要があります)。表固有の問合せは、すべての表に適用される問合せより優先されます。

特定の表に問合せを適用する場合は、表名と問合せ句をコロン(:)で区切る必要があります。表固有の問合せは複数指定できますが、1つの表に指定できるのは1つの問合せのみです。

QUERYパラメータと一緒にNETWORK_LINKパラメータを指定する場合、リモート(ソース)ノード上にあるquery_clauseで指定されるすべてのオブジェクトは、NETWORK_LINK値で明示的に修飾する必要があります。それ以外の場合、データ・ポンプではオブジェクトがローカル(ターゲット)ノード上に存在することを前提とし、存在しない場合はエラーが返され、リモート(ソース)システムからの表のインポートは失敗します。

たとえば、NETWORK_LINK=dblink1と指定した場合、QUERYパラメータのquery_clauseは、次の例に示すようにそのリンクを指定する必要があります。

QUERY=(hr.employees:"WHERE last_name IN(SELECT last_name
FROM hr.employees@dblink1)")

オペレーティング・システムによっては、このパラメータの値を指定するときに引用符とともにエスケープ文字を使用する必要があります。このパラメータはパラメータ・ファイルで指定することをお薦めします。パラメータ・ファイルを使用すると、コマンドラインでは必要なエスケープ文字の数を減らすことができます。詳細は、「データ・ポンプ・コマンドラインでの引用符の使用」を参照してください。

QUERYパラメータを使用すると、外部表による方法(ダイレクト・パスによる方法ではなく)でデータベース・アクセスが実行されます。

表固有の問合せで自分のスキーマ以外のスキーマを指定するには、その特定の表に対するアクセス権限が付与されている必要があります。

制限事項

- QUERYパラメータは次のパラメータとは併用できません。

- CONTENT=METADATA_ONLY

- SQLFILE

- TRANSPORT_DATAFILES

- 表にQUERYパラメータが指定されている場合、データ・ポンプは外部表を使用してターゲット表をロードします。外部表は、SQLのINSERT文をSELECT句とともに使用します。QUERYパラメータの値は、INSERT文のSELECT部分にあるWHERE句に含まれています。QUERYパラメータにロードする表と一致する名前の列がある他の表への参照が含まれていて、これらの列が問合せで使用される場合は、表別名を使用して、ロードする表内の列と、SELECT文内の同じ名前を持つ列を区別する必要があります。ロードする表に対してデータ・ポンプで使用される表別名は、KU$です。
たとえば、sh.customers表にある顧客のクレジットの上限に基づいてsh.sales表のサブセットをインポートするとします。次の例では、KU$を使用して、sh.salesをロードするためにQUERYパラメータ内のcust_idフィールドを修飾します。この結果、データ・ポンプによって、クレジットの上限が$10,000を超える顧客の行のみがインポートされます。

QUERY='sales:"WHERE EXISTS (SELECT cust_id FROM customers c
WHERE cust_credit_limit > 10000 AND ku$.cust_id = c.cust_id)"'

表別名としてKU$を使用しないと、すべての行がロードされます。

QUERY='sales:"WHERE EXISTS (SELECT cust_id FROM customers c
WHERE cust_credit_limit > 10000 AND cust_id = c.cust_id)"'

- QUERYに使用できる文字列の最大長は、引用符を含めて4000バイトです。つまり、許容される実際の最大長は3998バイトです。

例

次に、QUERYパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。QUERY値には引用符を使用するため、パラメータ・ファイルを使用することをお薦めします。

次の内容のパラメータ・ファイルquery_imp.parを作成したとします。

QUERY=departments:"WHERE department_id < 120"

次のコマンドを入力します。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp
PARFILE=query_imp.par NOLOGFILE=YES

expfull.dmp内のすべての表はインポートされますが、departments表については、QUERYパラメータに指定した基準を満たすデータのみがインポートされます。

REMAP_DATA

デフォルト: デフォルト値は設定されていません。

用途

REMAP_DATAパラメータを使用すると、新規データベースへの挿入時に、データを再マップできます。一般的には、プライマリ・キーを再生成して、ターゲット・データベース上の既存の表に表をインポートする場合の競合を回避するために使用されます。

ダンプ・ファイルまたはリモート・データベースのいずれかから、指定した列の値をソースとして取得するには、再マップ・ファンクションを指定します。再マップ・ファンクションを指定すると、ターゲット・データベースの元の値を置き換える再マップした値が返されます。

同じファンクションを、ダンプされる複数の列に適用できます。これは、参照制約で子と親両方の列を再マップするときに整合性を保つ必要がある場合に役立ちます。

構文および説明

REMAP_DATA=[schema.]tablename.column_name:[schema.]pkg.function

次に、各構文要素の説明を構文で出現する順に示します。

schema: 再マップされる表を含むスキーマ。デフォルトでは、これはインポートを実行するユーザーのスキーマです。

tablename: 列の再マップが行われる表。

column_name: データの再マップが行われる列。

schema: 再マップ・ファンクションを含むユーザー作成のPL/SQLパッケージを含むスキーマ。デフォルトでは、これはインポートを実行するユーザーのスキーマです。

pkg: 再マップ・ファンクションを含むユーザー作成のPL/SQLパッケージの名前。

function: 指定した表の各行で、列表を再マップする場合にコールされるPL/SQL内のファンクションの名前。

制限事項

- ソース引数および戻り値のデータ型はともに、表内の指定した列のデータ型と一致している必要があります。

- 再マップ・ファンクションでは、自律型トランザクション以外のコミットまたはロール・バックを実行できません。

- REMAP_DATAパラメータの値としてのシノニムの使用はサポートされていません。たとえば、hrスキーマ内のregions表にregnのシノニムがある場合は、regnをREMPA_DATA仕様の一部として指定した場合にエラーが返されます。

- リモート表のLOB列データの再マップはサポートされていません。

- 型がユーザー定義型、ユーザー定義型の属性、LONG、REF、VARRAY、ネストした表、BFILEおよびXMLtypeの列は、REMAP_DATAでサポートされません。

例

次の例では、plusxという名前のファンクションを格納するremapという名前のパッケージが作成されており、このファンクションはemployees表内のfirst_nameの値を変更すると想定しています。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expschema.dmp
TABLES=hr.employees REMAP_DATA=hr.employees.first_name:hr.remap.plusx

REMAP_DATAFILE

デフォルト: デフォルト値は設定されていません。

用途

ソース・データ・ファイルが参照されるすべてのSQL文(CREATE TABLESPACE、CREATE LIBRARYおよびCREATE DIRECTORY)で、ソース・データ・ファイルの名前をターゲット・データ・ファイル名に変更します。

構文および説明

REMAP_DATAFILE=source_datafile:target_datafile

データ・ファイルの再マップは、ファイル名のネーミング規則が異なるプラットフォーム間でデータベースを移動する場合に有効です。source_datafileとtarget_datafileの名前は、SQL文で指定するとおりのものである必要があります。コロンが有効なファイル指定文字として使用されるプラットフォームでの曖昧さを排除するために、データ・ファイル名は引用符で囲むことをお薦めします。

オペレーティング・システムによっては、このパラメータの値を指定するときに引用符とともにエスケープ文字を使用する必要があります。このパラメータはパラメータ・ファイルで指定することをお薦めします。パラメータ・ファイルを使用すると、コマンドラインでは必要なエスケープ文字の数を減らすことができます。

このパラメータを指定するには、DATAPUMP_IMP_FULL_DATABASEロールが必要です。

例

次の内容のパラメータ・ファイルpayroll.parを作成したとします。

DIRECTORY=dpump_dir1
FULL=YES
DUMPFILE=db_full.dmp
REMAP_DATAFILE="'DB1$:[HRDATA.PAYROLL]tbs6.dbf':'/db1/hrdata/payroll/tbs6.dbf'"

次のコマンドを発行します。

> impdp hr PARFILE=payroll.par

この例では、インポート時に、すべてのSQL DDL文に対するVMSファイル指定(DR1$:[HRDATA.PAYROLL]tbs6.dbf)をUNIXファイル指定(/db1/hrdata/payroll/tbs6.dbf)に再マップします。ダンプ・ファイルdb_full.dmpは、ディレクトリ・オブジェクトdpump_dir1によって位置が示されます。

関連項目:

「データ・ポンプ・コマンドラインでの引用符の使用」

REMAP_SCHEMA

デフォルト: デフォルト値は設定されていません。

用途

ソース・スキーマにあるすべてのオブジェクトをターゲット・スキーマにロードします。

構文および説明

REMAP_SCHEMA=source_schema:target_schema

複数のREMAP_SCHEMA行を指定できますが、ソース・スキーマは行ごとに異なっている必要があります。ただし、異なるソース・スキーマを同じターゲット・スキーマにマップすることはできます。マッピングは完全ではない場合があります(詳細は、次の「制限事項」を参照してください)。

再マッピング先のスキーマが存在しない場合は、インポート操作によってそのスキーマが作成されます。ただし、ソース・スキーマに必要なCREATE USERメタデータがダンプ・ファイル・セットに含まれており、ユーザーが必要な権限を所有してインポートを実行していることが条件となります。たとえば、次のExportコマンドの場合、ユーザーSYSTEMには必要な権限があるため、スキーマの作成に必要なメタデータを含むダンプ・ファイル・セットが作成されます。

> expdp system SCHEMAS=hr
Password: password

> expdp system FULL=YES
Password: password

スキーマの作成に必要なメタデータがダンプ・ファイル・セットに含まれていない場合や、ユーザーに必要な権限がない場合は、インポート操作を実行する前にターゲット・スキーマを作成しておく必要があります。これは、権限が付与されていないダンプ・ファイルには、インポート操作でスキーマを自動作成するための情報が含まれないためです。

インポート操作によってスキーマが作成された場合は、インポートの完了後、そのスキーマに有効なパスワードを割り当てて、接続できるようにする必要があります。パスワードを割り当てるSQL文(権限が必要)は、次のとおりです。

SQL> ALTER USER schema_name IDENTIFIED BY new_password

制限事項

- 権限のないユーザーは、自分のスキーマが再マップのターゲット・スキーマの場合にのみ、スキーマの再マップを実行できます。(特権ユーザーがスキーマの再マップを実行する場合は、制限がありません。)たとえば、SCOTTは、自分のBLAKEのオブジェクトをSCOTTに再マップできますが、SCOTTは、SCOTTのオブジェクトをBLAKEに再マップすることはできません。

- インポートで検出できない一部のスキーマ参照があるため、マッピングは完全ではない場合があります。たとえば、インポートでは、型定義、ビュー、プロシージャおよびパッケージの本体に埋め込まれたスキーマ参照は検出されません。

- トリガーの場合、REMAP_SCHEMAはトリガーの所有者のみに影響します。

- 再マップするスキーマ内の表にユーザー定義のオブジェクト型が含まれており、その表が、エクスポートされる時刻とインポートしようとする時刻の間に変更される場合、その表のインポートは失敗します。ただし、インポート操作自体は続行されます。

- デフォルトでは、ソース・データベースのスキーマ・オブジェクトにオブジェクト識別子(OID)がある場合、それらと同じOIDを持つターゲット・データベースにインポートされます。オブジェクトがエクスポート元と同じデータベースであって異なるスキーマにインポートされた場合、新しい(インポートされた)オブジェクトのOIDは、既存のオブジェクトと同じものになり、インポートは失敗します。インポートを成功させるには、インポート時にTRANSFORM=OID:Nパラメータも指定する必要があります。変換OID:Nにより新しいオブジェクトに対して新しいOIDが作成され、インポートが成功します。

例

ユーザーSYSTEMとして、次のエクスポートおよびインポート・コマンドを実行して、hrスキーマをscottスキーマに再マップするとします。

> expdp system SCHEMAS=hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp

> impdp system DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp REMAP_SCHEMA=hr:scott

この例では、インポート前にユーザーscottが存在する場合、インポートのREMAP_SCHEMAコマンドによって、hrスキーマにあるオブジェクトが既存のscottスキーマに追加されます。インポート後、scottスキーマに既存のパスワードで(パスワードの再設定なしで)接続できます。

インポート操作の実行前にユーザーscottが存在しない場合は、インポートによって、このユーザーがパスワードなしで自動作成されます。これは、ダンプ・ファイルhr.dmpが、スキーマの作成に必要なメタデータを含むダンプ・ファイルを作成する権限を所有するSYSTEMによって作成されたためです。ただし、インポート完了後に、ターゲット・データベース上のscottのパスワードを再設定しないかぎり、インポートの完了時にscottには接続できません。

REMAP_TABLE

デフォルト: デフォルト値は設定されていません。

用途

インポート操作中に、表の名前を変更できます。

構文および説明

次のいずれかの構文を使用できます(下記の「使用上の注意」を参照)。

REMAP_TABLE=[schema.]old_tablename[.partition]:new_tablename

または

REMAP_TABLE=[schema.]old_tablename[:partition]:new_tablename

REMAP_TABLEパラメータを使用して表全体の名前を変更するか、表を非パーティションする場合の表のパーティションを変更できます。(「PARTITION_OPTIONS」を参照してください。)

これを使用して、エクスポートした表パーティションの自動ネーミングを上書きすることもできます。

使用上の注意

最初の構文では、REMAP_TABLE=A.B:Cを指定すると、インポートによってAはスキーマ名、Bは古い表名、Cは新しい表名とみなされることに注意してください。最初の構文を使用して、非パーティション表にするパーティションの名前を変更するには、スキーマ名を指定する必要があります。

2番目の構文を使用して、非パーティション表にするパーティションの名前を変更するには、古い表名で指定します。スキーマ名は必要ありません。

制限事項

- インポートによって作成されたオブジェクトのみ、再マップされます。既存の表は再マップされないことに注意してください。

- 再マップする表が同じスキーマ内に名前付きの制約を持っていて、表の作成時に制約を作成する必要がある場合、REMAP_TABLEパラメータは機能しません。

例

次の例では、REMAP_TABLEパラメータを使用して、employees表をempsという新しい名前に変更します。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expschema.dmp
TABLES=hr.employees REMAP_TABLE=hr.employees:emps

REMAP_TABLESPACE

デフォルト: デフォルト値は設定されていません。

用途

ターゲット表領域に作成するソース表領域内の永続データを使用して、インポート用に選択されたすべてのオブジェクトを再マップします。

構文および説明

REMAP_TABLESPACE=source_tablespace:target_tablespace

複数のREMAP_TABLESPACEパラメータを指定できますが、ソース表領域はパラメータごとに1つのみです。ターゲット・スキーマのターゲット表領域には、十分な割当て制限が必要です。

データ・ポンプ・インポートで表領域を再マップする唯一の方法は、REMAP_TABLESPACEパラメータを使用することです。これは、オリジナルのインポート・ユーティリティの機能よりも簡単で正確な方法です。その方法には、表領域の副次句の数など多くの制限事項があり、一部のDDLコマンドを正常に実行できない場合がありました。

これに対し、REMAP_TABLESPACEパラメータを使用するデータ・ポンプ・インポートの方法は、ユーザーを含むすべてのオブジェクトに対して、DDL文に含まれる表領域副次句の数にかかわりなく有効に使用できます。

制限事項

- データ・ポンプ・インポートで再マップ可能なトランスポータブル・インポートの表領域は、互換性レベルが10.1以降に設定されているデータベースにあるもののみです。

- インポートによって作成されたオブジェクトのみ、再マップされます。特に、既存の表の表領域は、TABLE_EXISTS_ACTIONがSKIP、TRUNCATEまたはAPPENDに設定されている場合は、再マップされません。

例

次に、REMAP_TABLESPACEパラメータの使用例を示します。

> impdp hr REMAP_TABLESPACE=tbs_1:tbs_6 DIRECTORY=dpump_dir1
DUMPFILE=employees.dmp

REUSE_DATAFILES

デフォルト: NO

用途

インポート・ジョブで、表領域の作成に既存のデータ・ファイルを再利用するかどうかを指定します。

構文および説明

REUSE_DATAFILES=[YES | NO]

デフォルト(n)が使用され、CREATE TABLESPACE文で指定されているデータ・ファイルがすでに存在する場合は、CREATE TABLESPACE文の失敗によるエラー・メッセージが発行されますが、インポート・ジョブは続行されます。

このパラメータにYを指定すると、既存のデータ・ファイルが再度初期化されます。

注意:

REUSE_DATAFILES=YESを指定すると、データが失われる場合があります。

例

次に、REUSE_DATAFILESパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp LOGFILE=reuse.log
REUSE_DATAFILES=YES

この例では、expfull.dmpファイルのCREATE TABLESPACE文で指定されたデータ・ファイルを再度初期化します。

SCHEMAS

デフォルト: デフォルト値は設定されていません。

用途

スキーマ・モード・インポートの実行を指定します。

構文および説明

SCHEMAS=schema_name [,...]

DATAPUMP_IMP_FULL_DATABASEロールがある場合は、インポートするスキーマのリストをこのパラメータで指定して、スキーマ・モードのインポートを実行できます。まず、システムおよびロールの権限、パスワード履歴などを含むユーザー定義がインポートされます(存在しない場合)。次に、スキーマ内のすべてのオブジェクトがインポートされます。権限のないユーザーは、自分のスキーマか、自分のスキーマに再マップされるスキーマのみを指定できます。この場合、スキーマ定義についての情報はインポートされず、その定義内に含まれているオブジェクトのみがインポートされます。

このインポート・モードを使用したインポート対象を、フィルタ処理によって制限できます。詳細は、「インポート操作中のフィルタ処理」を参照してください。

スキーマ・モードは、ネットワーク・ベース・インポートを実行する際のデフォルト・モードです。

例

次に、SCHEMASパラメータの使用例を示します。この例では、ExportのSCHEMASパラメータで示した例を実行して、expdat.dmpファイルを作成できます。「SCHEMAS」を参照してください。

> impdp hr SCHEMAS=hr DIRECTORY=dpump_dir1 LOGFILE=schemas.log
DUMPFILE=expdat.dmp

hrスキーマは、expdat.dmpファイルからインポートされます。ログ・ファイルschemas.logは、dpump_dir1に書き込まれます。

SERVICE_NAME

デフォルト: デフォルト値は設定されていません。

用途

CLUSTERパラメータと組み合せて使用するサービス名を指定するために使用します。

構文および説明

SERVICE_NAME=name

SERVICE_NAMEパラメータをCLUSTER=YESパラメータとともに使用して、リソース・グループに属しているOracle Real Application Clusters(Oracle RAC)インスタンス群(通常は全Oracle RACインスタンスのサブセット)を定義するリソース・グループに関連付けられている、既存のサービスを指定できます。

サービス名は、リソース・グループおよびそのリソース・グループに対して定義されたインスタンスを決定する目的でのみ使用されます。ジョブが開始されたインスタンスは、そのインスタンスがリソース・グループに含まれているかどうかとは関係なく、常に使用されます。

SERVICE_NAMEパラメータは、CLUSTER=NOと同時に指定されると、無視されます。

インスタンスA、B、CおよびDを含むOracle RAC構成があります。インスタンスA、BおよびCのみで構成されるリソース・グループを持つmy_serviceというサービスが存在するとします。そのような場合は、次の内容が成立します。

- データ・ポンプ・ジョブをインスタンスAで開始し、CLUSTER=YESを指定し(またはデフォルトのYESをそのまま使用し)、SERVICE_NAMEパラメータを指定しない場合、データ・ポンプは指定の並列度に応じてすべてのインスタンス(A、B、CおよびD)にワーカーを作成します。

- データ・ポンプ・ジョブをインスタンスAで開始し、CLUSTER=YESおよびSERVICE_NAME=my_serviceを指定した場合、ワーカーは、インスタンスA、BおよびCのみで開始可能です。

- データ・ポンプ・ジョブをインスタンスDで開始し、CLUSTER=YESおよびSERVICE_NAME=my_serviceを指定した場合、ワーカーは、インスタンスA、B、CおよびDのみで開始可能です。インスタンスDはmy_serviceに存在しませんが、インスタンスDはジョブが開始されたインスタンスであるため含まれています。

- データ・ポンプ・ジョブをインスタンスAで開始し、CLUSTER=NOを指定した場合、SERVICE_NAMEパラメータを指定しても無視され、すべてのプロセスがインスタンスAで開始されます。

例

> impdp system DIRECTORY=dpump_dir1 SCHEMAS=hr
SERVICE_NAME=sales NETWORK_LINK=dbs1

この例では、hrスキーマのスキーマ・モード・ネットワーク・インポートを開始します。コマンドラインではCLUSTER=YESは指定されていませんが、それはデフォルトの動作なので、ジョブではサービス名salesに関連付けられたリソース・グループのすべてのインスタンスが使用されます。dbs1のNETWORK_LINK値は、データのインポート元であるソース・データベース名に置き換えます。(これはネットワーク・インポートであるため、ダンプ・ファイルは生成されません。)

NETWORK_LINKパラメータは、単にこの例の一部として使用されています。SERVICE_NAMEパラメータの使用時は必須ではありません。

関連項目:

「CLUSTER」

SKIP_UNUSABLE_INDEXES

デフォルト: Oracle Databaseの構成パラメータSKIP_UNUSABLE_INDEXESの値

用途

インポートで、(システムまたはユーザーのいずれかによって)索引使用禁止に設定されている索引を持つ表をロードするかどうかを指定します。

構文および説明

SKIP_UNUSABLE_INDEXES=[YES | NO]

SKIP_UNUSABLE_INDEXESがYESに設定されているときに、索引が使用禁止の状態になっている表またはパーティションが検出された場合、その表やパーティションは、使用禁止の索引が存在しない場合と同様にロードされます。

SKIP_UNUSABLE_INDEXESがNOに設定されているときに、索引が使用禁止の表またはパーティションが検出された場合、その表やパーティションはロードされません。索引が使用禁止に設定されていない他の表に対しては、行の挿入時に更新が行われます。

SKIP_UNUSABLE_INDEXESパラメータが指定されていない場合は、Oracle Databaseの構成パラメータSKIP_UNUSABLE_INDEXESの設定値(デフォルト値はy)が参照され、使用禁止の索引の処理が決定されます。

制約の施行に使用される索引に使用禁止のマークが付けられている場合、その表にデータはインポートされません。

注意:

このパラメータは、データを既存の表にインポートする場合にのみ有効です。インポート処理の一環として表が作成される場合は、表と索引が新規に作成され、使用禁止のマークは付けられないため、このパラメータによる実質的な効果はありません。

例

次に、SKIP_UNUSABLE_INDEXESパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp LOGFILE=skip.log
SKIP_UNUSABLE_INDEXES=YES

SOURCE_EDITION

デフォルト: オブジェクトがフェッチされるリモート・ノード上のデフォルトのデータベース・エディション

用途

オブジェクトがフェッチされるリモート・ノード上のデータベース・エディションを指定します。

構文および説明

SOURCE_EDITION=edition_name

SOURCE_EDITION=edition_nameを指定すると、そのエディションのオブジェクトがインポートされます。データ・ポンプは、変更されずに継承されているすべてのオブジェクトと、変更されているすべての実際のオブジェクトを選択します。

このパラメータが指定されていない場合は、デフォルトのエディションが使用されます。指定されたエディションが存在しない場合や使用できない場合は、エラー・メッセージが返されます。

制限事項

- SOURCE_EDITIONパラメータがインポート操作で有効なのは、NETWORK_LINKパラメータも指定されている場合のみです。「NETWORK_LINK」を参照してください。

- このパラメータは、バージョニング可能な同じオブジェクトのバージョンがデータベース内に2つ以上ある場合にのみ有効です。

- ジョブ・バージョンは、11.2以上に設定する必要があります。「VERSION」を参照してください。

例

次に、インポートのSOURCE_EDITIONパラメータの使用例を示します。

> impdp hr DIRECTORY=dpump_dir1 SOURCE_EDITION=exp_edition
NETWORK_LINK=source_database_link EXCLUDE=USER

この例は、オブジェクトのインポート元となるexp_editionというエディションがシステム上に存在することを前提としています。インポート・モードは指定されていないため、デフォルトのスキーマ・モードが使用されます。source_database_linkは、データのインポート元であるソース・データベース名に置き換えます。EXCLUDE=USERパラメータは、ユーザーの定義のみを除外し、ユーザーのスキーマに含まれるオブジェクトは除外しません。(これはネットワーク・インポートであるため、ダンプ・ファイルは生成されません。)

関連項目:

- エディションの作成方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- エディション機能(継承されたオブジェクトと実際のオブジェクトも含む)の詳細は、『Oracle Database開発ガイド』を参照してください。

SQLFILE

デフォルト: デフォルト値は設定されていません。

用途

インポートが他のパラメータに基づいて実行するすべてのSQL DDLの書込み先のファイルを指定します。

構文および説明

SQLFILE=[directory_object:]file_name

file_nameには、インポート・ジョブが、ジョブで実行するDDLを書き込むファイル名を指定します。そのSQLは、実際には実行されず、ターゲット・システムも変更されません。ファイルは、他のdirectory_objectが明示的に指定されないかぎり、DIRECTORYパラメータに指定されたディレクトリ・オブジェクトに書き込まれます。このパラメータで指定した名前と一致する名前を持つ既存のファイルはすべて上書きされます。

パスワードは、SQLファイルに含まれないことに注意してください。たとえば、実行したDDLにCONNECT文が含まれている場合、この文はコメントで置き換えられ、スキーマ名のみが表示されます。次の例では、ダッシュ(--)の後に続くのがコメントです。また、hrというスキーマ名は表示されていますが、パスワードは表示されていません。

-- CONNECT hr

したがって、SQLファイルは、実行する前に、コメントを示すダッシュを削除し、hrスキーマのパスワードを追加して編集する必要があります。

StreamsなどのOracle Databaseオプションでは、無名PL/SQLブロックがSQLFILE出力に出現することがあります。これらは、直接実行しないでください。

制限事項

- SQLFILEが指定されている場合、CONTENTパラメータは、ALLまたはDATA_ONLYのいずれかに設定されていると無視されます。

- Oracle Automatic Storage Management (Oracle ASM)を使用してSQLファイルへのデータ・ポンプ・インポートを実行する場合、SQLFILEパラメータでは、Oracle ASMの+表記法を使用せずにディレクトリ・オブジェクトを指定する必要があります。つまり、SQLファイルはディスク・ファイルに書き込まれ、Oracle ASMの記憶域には書き込まれません。

- SQLFILEパラメータは、QUERYパラメータと組み合せて使用することはできません。

例

次に、SQLFILEパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp
SQLFILE=dpump_dir2:expfull.sql

SQLファイルexpfull.sqlは、dpump_dir2に書き込まれます。

STATUS

デフォルト: 0

用途

ジョブ状態が表示される頻度を指定します。

構文および説明

STATUS[=integer]

integerに値を入力すると、ロギング・モードでジョブの状態を表示する頻度を秒単位で指定できます。値を入力しなかった場合またはデフォルト値の0を使用した場合、各オブジェクト型、表またはパーティションの完了に関する情報のみ表示されます。

この状態情報は、標準出力デバイスのみに書き込まれ、ログ・ファイルには(使用可能な場合でも)書き込まれません。

例

次に、STATUSパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr NOLOGFILE=YES STATUS=120 DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp

この例では、状態が2分(120秒)ごとに表示されます。

STREAMS_CONFIGURATION

デフォルト: YES

用途

エクスポート・ダンプ・ファイル内に存在するStreamsメタデータをインポートするかどうかを指定します。

構文および説明

STREAMS_CONFIGURATION=[YES | NO]

例

次に、STREAMS_CONFIGURATIONパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp STREAMS_CONFIGURATION=NO

関連項目:

『Oracle Streamsレプリケーション管理者ガイド』

TABLE_EXISTS_ACTION

デフォルト: SKIP(CONTENT=DATA_ONLYが指定されている場合、デフォルトはSKIPではなく、APPENDです。)

用途

インポート・ユーティリティに対して、作成しようとしている表がすでに存在する場合に行う操作を指定します。

構文および説明

TABLE_EXISTS_ACTION=[SKIP | APPEND | TRUNCATE | REPLACE]

次の値を指定できます。

- SKIP: 表はそのままにして、次のオブジェクトに移動します。CONTENTパラメータがDATA_ONLYに設定されている場合、このオプションは無効です。

- APPEND: ソースから行をロードし、既存の行は変更しません。

- TRUNCATE: 既存の行を削除した後、ソースから行をロードします。

- REPLACE: 既存の表を削除した後、ソースから表を作成およびロードします。CONTENTパラメータがDATA_ONLYに設定されている場合、このオプションは無効です。

これらのオプションを使用する場合に考慮する事項は次のとおりです。

- TRUNCATEまたはREPLACEを使用する場合は、影響を受ける表の行が参照制約のターゲットではないことを確認してください。

- SKIP、APPENDまたはTRUNCATEを使用する場合、索引、権限、トリガー、制約など、ソースの既存の表依存オブジェクトは変更されません。REPLACEを使用すると、依存オブジェクトが明示的または暗黙的に除外(EXCLUDEを使用して)され、それらがソースのダンプ・ファイルまたはシステムに存在する場合、依存オブジェクトは削除され、ソースから再作成されます。

- APPENDまたはTRUNCATEを使用する場合は、操作を実行する前に、ソースにある行が既存の表に適合するかどうかがチェックされます。
既存の表にアクティブな制約およびトリガーがある場合は、外部表によるアクセス方法を使用してロードされます。アクティブな制約に違反する行がある場合、ロードは失敗し、データはロードされません。この動作を変更するには、インポート・ユーティリティのコマンドラインでDATA_OPTIONS=SKIP_CONSTRAINT_ERRORSを指定します。

制約違反の可能性があるデータをロードする必要がある場合は、制約を無効にし、データをロードした後、制約を再度有効にする前に問題のある行を削除する方法を検討してください。

- APPENDを使用すると、常に、データは新しい領域にロードされます。既存の領域は、使用可能な場合でも再利用されません。そのため、ロード後にデータを圧縮することもできます。

- 既存のターゲット表の有無によりパーティション表の並列処理がどのように影響を受けるかの詳細は、インポートのPARTITION_OPTIONSパラメータの説明も参照してください。

注意:

データ・ポンプは、ソース表とターゲット表の不一致(2つの表の列数が同じでないか、ソース表にない列名がターゲット表にある)を検出すると、2つの表間で列名を比較します。これらの表に共通の列が少なくとも1つあると、(データ型に互換性があるとみなされる)共通する列のデータが表にインポートされます。次の制限があります。

- この動作はネットワーク・インポートではサポートされません。

- 次の型の列は削除できません。オブジェクト列、オブジェクト属性、ネストされた表の列、主キーに基づくREF列。

制限事項

- TRUNCATEは、クラスタ化された表では使用できません。

例

次に、TABLE_EXISTS_ACTIONパラメータの使用例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr TABLES=employees DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp
TABLE_EXISTS_ACTION=REPLACE

TABLES

デフォルト: デフォルト値は設定されていません。

用途

表モード・インポートの実行を指定します。

構文および説明

TABLES=[schema_name.]table_name[:partition_name]

表モード・インポートでは、表およびパーティションまたはサブパーティションをカンマで区切ったリストを指定して、ソースからインポートするデータをフィルタ処理できます。

schema_nameを指定しなかった場合は、デフォルトで現在のユーザーのスキーマ名になります。自分のスキーマ以外のスキーマを指定するには、DATAPUMP_IMP_FULL_DATABASEロールを持っているか、またはスキーマを現在のユーザーに再マップする必要があります。

このインポート・モードを使用したインポート対象を、フィルタ処理によって制限できます。詳細は、「インポート操作中のフィルタ処理」を参照してください。

partition_nameを指定する場合は、関連表にあるパーティションまたはサブパーティションの名前にする必要があります。

ワイルドカード文字%を使用して、表名およびパーティション名を指定できます。

表名には次の制限があります。

- デフォルトでは、表名は大文字でデータベースに格納されます。表名が大文字と小文字または小文字のみで表記され、大/小文字を区別する場合、名前を引用符で囲む必要があります。したがって、表名は、データベースに格納されている表名と完全に一致するように指定する必要があります。
ただし、オペレーティング・システムによっては、コマンドラインの引用符自体をエスケープする必要がある場合があります。次に、異なるインポート・モードで大/小文字の区別を保持する方法を示します。

- コマンドライン・モード

TABLES='\"Emp\"'

- パラメータ・ファイル・モード

TABLES='"Emp"'

- 表名を引用符で囲まないかぎり、コマンドラインで指定する表名にシャープ(#)記号は使用できません。同様に、パラメータ・ファイルでは、表名が引用符で囲まれていないかぎり、表名にシャープ(#)記号を使用すると、インポート・ユーティリティではシャープ(#)記号より右側の文字がコメントとして解釈されます。
たとえば、パラメータ・ファイルに次のコマンドラインが記述されている場合、インポート・ユーティリティではemp#の右側がすべてコメントとして解釈されるため、表deptおよびmydataはインポートされません。

TABLES=(emp#, dept, mydata)

ただし、パラメータ・ファイルに次の行が含まれる場合は、emp#が引用符で囲まれているため、インポート・ユーティリティは3つの表をすべてインポートします。

TABLES=('"emp#"', dept, mydata)

注意:

オペレーティング・システムによっては、一重引用符を使用する必要がある場合と、二重引用符を使用する必要がある場合があります。ご使用のオペレーティング・システム固有のドキュメントで確認してください。表のネーミング方法に制限があるオペレーティング・システムもあります。

たとえば、UNIXのCシェルではドル記号($)やシャープ(#)(またはその他の特殊文字)には特別な意味があります。これらの文字をシェルを介してインポートするには、エスケープ文字を使用する必要があります。

制限事項

- TABLESパラメータの値としてのシノニムの使用はサポートされていません。たとえば、hrスキーマのregions表にregnのシノニムが存在する場合、TABLES=regnを使用すると無効になります。この場合、エラーが返されます。

- インポートに対してPARTITION_OPTIONS=DEPARTITION も指定されている場合、1つの表からのパーティションのみを指定できます。

- TRANSPORTABLE=ALWAYSを指定する場合は、TABLESパラメータで指定されるすべてのパーティションが同じ表内に存在する必要があります。

- TABLESパラメータに指定する表名のリストの長さは、最大4MBに制限されます。ただし、NETWORK_LINKパラメータで10.2.0.3以前のOracle Databaseまたは読取り専用のデータベースが設定されている場合は異なります。この場合の上限は4KBです。

例

次に、TABLESパラメータを使用して、expfull.dmpファイルからemployeesおよびjobs表のみをインポートする簡単な例を示します。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp TABLES=employees,jobs

次に、 TABLESパラメータを使用したパーティションのインポート例を示します。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expdat.dmp
TABLES=sh.sales:sales_Q1_2012,sh.sales:sales_Q2_2012

この例では、shスキーマのsales表のパーティションsales_Q1_2012およびsales_Q2_2012をインポートします。

TABLESPACES

デフォルト: デフォルト値は設定されていません。

用途

表領域モード・インポートの実行を指定します。

構文および説明

TABLESPACES=tablespace_name [, ...]

TABLESPACESを使用して、表と依存オブジェクトがソース(全体インポート・モード、スキーマ・モード、表領域モードまたは表モードのエクスポート・ダンプ・ファイル・セット、あるいは別のデータベース)からインポートされる表領域名のリストを指定します。

インポートの次の状況では、データ・ポンプによりデータのインポート先に自動的に表領域が作成されます。

- インポートがFULLモードまたはTRANSPORT_TABLESPACESモードで実行されている場合

- インポートがTRANSPORTABLE=ALWAYSを含む表モードで実行されている場合

その他のすべての場合では、選択したオブジェクトの表領域がインポート先のデータベースにすでに存在している必要があります。REMAP_TABLESPACEインポート・パラメータを使用して、インポート先のデータベースにある表領域に表領域名をマッピングすることもできます。

このインポート・モードを使用したインポート対象を、フィルタ処理によって制限できます。詳細は、「インポート操作中のフィルタ処理」を参照してください。

制限事項

- TABLESPACESパラメータに指定する表領域名のリストの長さは、最大4MBに制限されます。ただし、NETWORK_LINKパラメータで10.2.0.3以前のデータベースまたは読取り専用のデータベースが設定されている場合は異なります。この場合の上限は4KBです。

例

次に、TABLESPACESパラメータの使用例を示します。表領域はすでに存在するものとします。この例では、ExportのFULLパラメータで示した例を実行して、expfull.dmpダンプ・ファイルを作成できます。「FULL」を参照してください。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp TABLESPACES=tbs_1,tbs_2,tbs_3,tbs_4

この例では、表領域tbs_1、tbs_2、tbs_3およびtbs_4にデータがある表がすべてインポートされます。

TARGET_EDITION

デフォルト: システム上のデフォルトのデータベース・エディション

用途

オブジェクトのインポート先のデータベース・エディションを指定します。

構文および説明

TARGET_EDITION=name

TARGET_EDITION=nameが指定されている場合、データ・ポンプ・インポートは、ダンプ・ファイル内にあるすべてのオブジェクトを作成します。エディション化可能でないオブジェクトは、すべてのエディションで作成されます。たとえば、表はエディション化可能でないため、ダンプ・ファイル内に表があると、その表が作成されてすべてのエディションから参照できます。ダンプ・ファイル内のオブジェクトでエディション化可能なもの(プロシージャなど)は、指定されたターゲット・エディションのみに作成されます。

このパラメータが指定されていない場合は、エクスポート・ジョブでエディションが指定されていた場合でも、ターゲット・データベースのデフォルトのエディションが使用されます。指定されたエディションが存在しない場合や使用できない場合は、エラー・メッセージが返されます。

制限事項

- このパラメータは、バージョニング可能な同じオブジェクトのバージョンがデータベース内に2つ以上ある場合にのみ有効です。

- ジョブ・バージョンは、11.2以上である必要があります。「VERSION」を参照してください。

例

次に、TARGET_EDITIONパラメータの使用例を示します。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=exp_dat.dmp TARGET_EDITION=exp_edition

この例は、オブジェクトのインポート先となるexp_editionというエディションがシステム上に存在することを前提としています。インポート・モードは指定されていないため、デフォルトのスキーマ・モードが使用されます。

関連項目:

- エディションの作成方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- エディション機能の詳細は、『Oracle Database開発ガイド』を参照してください。

TRANSFORM

デフォルト: デフォルト値は設定されていません。

用途

インポート中のオブジェクトに対するオブジェクト作成DDLを変更できます。

構文および説明

TRANSFORM = transform_name:value[:object_type]

transform_nameには、変換の名前を指定します。使用可能なオプションは、次のとおりです(アルファベット順に記載)。

- DISABLE_ARCHIVE_LOGGING:[Y | N]
Yに設定すると、データがインポートされる前に、指定したオブジェクト型(TABLEまたはINDEX、あるいはその両方)のロギング属性が無効になります。Nに設定すると(デフォルト)、アーカイブ・ロギングはインポート中に無効になりません。データがロードされた後に、オブジェクトのロギング属性は元の設定に戻されます。オブジェクト型を指定しない場合、DISABLE_ARCHIVE_LOGGINGの動作は、TABLEとINDEXの両方のオブジェクト型に適用されます。この変換は、ファイル・モード・インポートとネットワーク・モード・インポートの両方で動作します。これは、トランスポータブル表領域インポートには適用されません。

注意:

データベースがFORCE LOGGINGモードである場合、索引および表の作成時にDISABLE_ARCHIVE_LOGGINGオプションではロギングは無効になりません。

- INMEMORY:[Y | N]
INMEMORY変換は、インメモリー列ストア(IM列ストア)に関連があります。IM列ストアは、表、表パーティションおよびその他のデータベース・オブジェクトのコピーを格納するSystem Global Area(SGA)のオプションの部分です。IM列ストアはSGAの一部であるため、データは行ではなく、列によって移入されます。データは高速スキャンで最適化されます。IM列ストアでは、バッファ・キャッシュは置換しませんが、両方のメモリー領域において同じデータを異なる形式で格納するための補足としての役割を果たします。IM列ストアは、Oracle Databaseインメモリー・オプションに含まれています。

インポートでY (デフォルト値)が指定されている場合、データ・ポンプは、IM列ストア句を含むすべてのオブジェクトに対してIM列ストア句を保持します。これらのオブジェクトがインポート時に再作成されると、データ・ポンプは、エクスポート時にこれらのオブジェクトの設定と一致するIM列ストア句を生成します。

インポートでNが指定されている場合、データ・ポンプは、IM列ストア句を含むすべてのオブジェクトからIM列ストア句を削除します。表領域に格納されているオブジェクトにIM列ストア句がない場合、オブジェクトは表領域からIM列ストア句を継承します。したがって、データベースを移行していて、IM列ストア機能を使用する新しいデータベースが必要な場合、適切なIM列ストア句を持つ表領域を事前に作成できます。その後、インポート・コマンドでTRANSFORM=INMEMORY:Nを使用します。オブジェクトは、事前に作成済の新しい表領域からIM列ストア句を継承します。

INMEMORY変換を使用しない場合、すべてのオブジェクトを個別に変更して、適切なIM列ストア句を追加する必要があります。

注意:

INMEMORY変換は、Oracle Database 12cリリース1 (12.1.0.2)以降でのみ使用可能です。

関連項目:

- インメモリー列ストア(IM列ストア)の使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- INMEMORY_CLAUSE:"string with a valid in-memory parameter"
INMEMORY_CLAUSE変換は、インメモリー列ストア(IM列ストア)に関連があります。IM列ストアは、表、表パーティションおよびその他のデータベース・オブジェクトのコピーを格納するSystem Global Area(SGA)のオプションの部分です。IM列ストアはSGAの一部であるため、データは行ではなく、列によって移入されます。データは高速スキャンで最適化されます。IM列ストアでは、バッファ・キャッシュは置換しませんが、両方のメモリー領域において同じデータを異なる形式で格納するための補足としての役割を果たします。IM列ストアは、Oracle Databaseインメモリー・オプションに含まれています。

この変換を指定すると、データ・ポンプは、DDL内にIM列ストア句が含まれる、インポート対象のすべてのオブジェクトに対して、文字列の内容をINMEMORY_CLAUSEとして使用します。この変換は、ダンプ・ファイルのオブジェクトに対してIM列ストア句を優先させる必要がある場合に有効です。

注意:

INMEMORY_CLAUSE変換は、Oracle Database 12cリリース1 (12.1.0.2)以降でのみ使用可能です。

関連項目:

- インメモリー列ストア(IM列ストア)の使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- IM列ストア句で指定できるパラメータのリストおよび詳細は、『Oracle Databaseリファレンス』を参照してください。

- LOB_STORAGE:[SECUREFILE | BASICFILE | DEFAULT | NO_CHANGE]
指定した記憶域(SECUREFILEまたはBASICFILE)で、LOBセグメントが作成されます。値がNO_CHANGE (デフォルト)の場合、LOBセグメントは、ソース・データベースに存在するものと同じ記憶域に作成されます。値がDEFAULTの場合、キーワード(SECUREFILEまたはBASICFILE)は省略され、LOBセグメントはデフォルト記憶域に作成されます。

この変換を指定すると、マテリアライズド・ビューに記憶域を提供する表を含め、ジョブのすべての表のLOB記憶域が変更されます。

LOB_STORAGEの変換は、トランスポータブル・インポート・ジョブでは無効です。

- OID:[Y | N]
インポート時にY(デフォルト値)を指定した場合、エクスポートされたOIDが、新しいオブジェクト表およびオブジェクト型に割り当てられます。データ・ポンプでは、ターゲット・データベース上で、一致する既存の型を検出する際にOIDの確認も行います。

インポート時にNを指定した場合、次が実行されます。

- エクスポートされたOIDは、新しいオブジェクト表とオブジェクト型の作成で割り当てられません。かわりに、新しいOIDが割り当てられます。これは、スキーマのクローニングに有効ですが、参照オブジェクトには影響しません。

- 型に関連付けされた表にデータをロードする前に、データ・ポンプで、ターゲット・データベース上に既存の一致する型を検出する際、標準の型のOIDチェックをスキップします。型のハッシュ・コード、バージョン番号、型名によるその他のチェックは実行されます。

- PCTSPACE:some_number_greater_than_zero
この変換の値には、0より大きい数字を指定する必要があります。この値は、エクステントの割当てとデータ・ファイル・サイズの変更に使用する、割合の乗数を表します。

なお、このPCTSPACE変換とデータ・ポンプ・エクスポートのSAMPLEパラメータを組み合せて使用すると、記憶域の割当てサイズを、サンプリングされたデータ・サブセットに合わせることができます。(「SAMPLE」を参照してください。)

- SEGMENT_ATTRIBUTES:[Y | N]
値をYに指定すると、適切なDDLにセグメント属性(物理属性、記憶域属性、表領域およびロギング)が指定されます。デフォルトはYです。

- SEGMENT_CREATION:[Y | N]
Y (デフォルト)に設定した場合、この変換によってSQL SEGMENT CREATION句がCREATE TABLE文に追加されます。つまり、CREATE TABLE文でSEGMENT CREATION DEFERREDかSEGMENT CREATION IMMEDIATEのいずれかが明示的に表現されます。値がNの場合、SEGMENT CREATION句はCREATE TABLE文から省略されます。ロードされる表に対してデフォルトのセグメント作成属性を使用するには、このパラメータをNに設定します。(この機能はOracle Database 11gリリース2(11.2.0.2)から使用できます。)

- STORAGE:[Y | N]
値をYに指定すると、適切なDDLにSTORAGE句が指定されます。デフォルトはYです。SEGMENT_ATTRIBUTES=Nの場合、このパラメータは無視されます。

- TABLE_COMPRESSION_CLAUSE:[NONE | compression_clause]
NONEを指定すると、表圧縮句は省略されます(その表の表領域にはデフォルトの圧縮が使用されます)。それ以外の場合、その値が有効な表圧縮句です(NOCOMPRESS、COMPRESS BASICなど)。指定した圧縮を使用して表が作成されます。有効な表圧縮構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表圧縮句が複数の語の場合、一重引用符または二重引用符で囲む必要があります。

表圧縮句が複数の語の場合、一重引用符または二重引用符で囲む必要があります。さらに、ご使用のオペレーティング・システムの要件によっては、句をエスケープ文字(バックスラッシュ文字など)で囲む必要がある場合があります。次に例を示します。

TRANSFORM=TABLE_COMPRESSION_CLAUSE:\"COLUMN STORE COMPRESS FOR QUERY HIGH\"

この変換を指定すると、マテリアライズド・ビューに記憶域を提供する表を含め、ジョブのすべての表の圧縮タイプが変更されます。

object_typeの指定はオプションです。このオプションで、変換が適用されるオブジェクト型を指定します。オブジェクト型を指定しなかった場合、変換はすべての有効なオブジェクト型に適用されます。表3-1に、変換ごとの有効なオブジェクト型を示します。

表3-1 データ・ポンプ・インポートのTRANSFORMパラメータの有効なオブジェクト型

-

CLUSTER

CONSTRAINT

INC_TYPE

INDEX

ROLLBACK_SEGMENT

TABLE

TABLESPACE

TYPE

DISABLE_ARCHIVE_LOGGING

なし

なし

なし

あり

なし

あり

なし

なし

INMEMORY_

なし

なし

なし

なし

なし

あり

あり

なし

INMEMORY_CLAUSE

なし

なし

なし

なし

なし

あり

あり

なし

LOB_STORAGE

なし

なし

なし

なし

なし

あり

なし

なし

OID

なし

なし

あり

なし

なし

あり

なし

あり

PCTSPACE

あり

あり

なし

あり

あり

あり

あり

なし

SEGMENT_ATTRIBUTES

あり

あり

なし

あり

あり

あり

あり

なし

SEGMENT_CREATION

なし

なし

なし

なし

なし

あり

なし

なし

STORAGE

あり

あり

なし

あり

あり

あり

なし

なし

TABLE_COMPRESSION_CLAUSE

なし

なし

なし

なし

なし

あり

なし

なし

例

次の例では、hrスキーマのemployees表をエクスポートしたとします。表をインポートした結果返されるSQL CREATE TABLE文は、次のようになります。

CREATE TABLE "HR"."EMPLOYEES"
( "EMPLOYEE_ID" NUMBER(6,0),
"FIRST_NAME" VARCHAR2(20),
"LAST_NAME" VARCHAR2(25) CONSTRAINT "EMP_LAST_NAME_NN" NOT NULL ENABLE,
"EMAIL" VARCHAR2(25) CONSTRAINT "EMP_EMAIL_NN" NOT NULL ENABLE,
"PHONE_NUMBER" VARCHAR2(20),
"HIRE_DATE" DATE CONSTRAINT "EMP_HIRE_DATE_NN" NOT NULL ENABLE,
"JOB_ID" VARCHAR2(10) CONSTRAINT "EMP_JOB_NN" NOT NULL ENABLE,
"SALARY" NUMBER(8,2),
"COMMISSION_PCT" NUMBER(2,2),
"MANAGER_ID" NUMBER(6,0),
"DEPARTMENT_ID" NUMBER(4,0)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 10240 NEXT 16384 MINEXTENTS 1 MAXEXTENTS 121
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM" ;

STORAGE句またはTABLESPACE句は、保持しない場合、インポート・ユーティリティのTRANSFORMパラメータを使用してCREATE STATEMENTから削除できます。SEGMENT_ATTRIBUTESの値をNに指定します。これによって、セグメント属性(記憶域と表領域の両方)が表から除外されます。

> impdp hr TABLES=hr.employees DIRECTORY=dpump_dir1 DUMPFILE=hr_emp.dmp
TRANSFORM=SEGMENT_ATTRIBUTES:N:table

この結果返される、employees表のCREATE TABLE文は次のようになります。STORAGEまたはTABLESPACE句は含まれていません。かわりに、HRスキーマのデフォルト表領域が使用されます。

CREATE TABLE "HR"."EMPLOYEES"
( "EMPLOYEE_ID" NUMBER(6,0),
"FIRST_NAME" VARCHAR2(20),
"LAST_NAME" VARCHAR2(25) CONSTRAINT "EMP_LAST_NAME_NN" NOT NULL ENABLE,
"EMAIL" VARCHAR2(25) CONSTRAINT "EMP_EMAIL_NN" NOT NULL ENABLE,
"PHONE_NUMBER" VARCHAR2(20),
"HIRE_DATE" DATE CONSTRAINT "EMP_HIRE_DATE_NN" NOT NULL ENABLE,
"JOB_ID" VARCHAR2(10) CONSTRAINT "EMP_JOB_NN" NOT NULL ENABLE,
"SALARY" NUMBER(8,2),
"COMMISSION_PCT" NUMBER(2,2),
"MANAGER_ID" NUMBER(6,0),
"DEPARTMENT_ID" NUMBER(4,0)
);

前述の例で示したとおり、SEGMENT_ATTRIBUTES変換は、記憶域と表領域の両方の属性に適用されます。STORAGE句のみを省略して、TABLESPACE句を保持する場合は、STORAGE変換を次のように使用できます。

> impdp hr TABLES=hr.employees DIRECTORY=dpump_dir1 DUMPFILE=hr_emp.dmp
TRANSFORM=STORAGE:N:table

SEGMENT_ATTRIBUTESおよびSTORAGE変換は、次のコマンドに示すとおり、TRANSFORMパラメータにオブジェクト型を指定しないことによって、すべての適用可能な表オブジェクトおよび索引オブジェクトに適用できます。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp SCHEMAS=hr TRANSFORM=SEGMENT_ATTRIBUTES:N

TRANSPORT_DATAFILES

デフォルト: デフォルト値は設定されていません。

用途

トランスポータブル表領域モード・インポートか、エクスポート時にTRANSPORTABLE=ALWAYSが設定された場合は表モード・インポートまたは全体モード・インポートによって、ターゲット・データベースにインポートされるデータ・ファイルの一覧を指定します。データ・ファイルはターゲット・データベース・システム上にすでに存在する必要があります。

構文および説明

TRANSPORT_DATAFILES=datafile_name

datafile_nameには、ディレクトリ・オブジェクト名ではなく、ターゲット・データベースが存在するシステムで有効な絶対ディレクトリ・パスを指定する必要があります。

インポート操作前の任意の時点で、ソース・システムからターゲット・システムにデータ・ファイルをコピーしておく必要があります。この処理は、オペレーティング・システムでサポートされている任意のコピー方法で実行できます。必要に応じて、ターゲット・システムにコピーするときに、ファイルの名前を変更できます(例2を参照)。

トランスポータブル表領域モード・エクスポートによって生成されたダンプ・ファイル・セットがすでにある場合、(メタデータを含んでいる)ダンプ・ファイルおよびTRANSPORT_DATAFILESパラメータを指定することで、そのダンプ・ファイルのトランスポータブル・モード・インポートを実行できます。TRANSPORT_DATAFILESパラメータが存在することで、これがトランスポータブル・モード・インポートであることと、実際のデータを取得する場所がインポートに通知されます。

オペレーティング・システムによっては、このパラメータの値を指定するときに引用符とともにエスケープ文字を使用する必要があります。このパラメータはパラメータ・ファイルで指定することをお薦めします。パラメータ・ファイルを使用すると、コマンドラインでは必要なエスケープ文字の数を減らすことができます。

制限事項

- TRANSPORT_DATAFILESパラメータは、QUERYパラメータと組み合せて使用することはできません。

- トランスポータブル・インポート・ジョブは、再開できません。

例1

次に、TRANSPORT_DATAFILESパラメータの使用例を示します。次の内容のパラメータ・ファイルtrans_datafiles.parを作成したとします。

DIRECTORY=dpump_dir1
DUMPFILE=tts.dmp
TRANSPORT_DATAFILES='/user01/data/tbs1.dbf'

次のコマンドを発行します。

> impdp hr PARFILE=trans_datafiles.par

例2

この例は、トランスポータブル表領域のエクスポートおよびインポート操作の一環として、データ・ファイルの名前を変更する操作を示しています。ソース・システムにemployees.datというデータ・ファイルがあることを前提としています。

1. オペレーティング・システムでサポートされている方法で、ソース・システムからターゲット・データベースがあるシステムに、employees.datというデータ・ファイルを手動でコピーします。コピー操作の一環として、ファイル名をworkers.datに変更します。

2. 表領域tbs_1について、トランスポータブル表領域のエクスポートを実行します。

> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=tts.dmp TRANSPORT_TABLESPACES=tbs_1

tbs_1のメタデータのみ(データなし)がtts.dmpというダンプ・ファイルにエクスポートされます。実際のデータは、手順1でターゲット・データベースにコピーされています。

3. workers.datというデータ・ファイルの絶対ディレクトリ・パスを指定して、トランスポータブル表領域のインポートを実行します。

> impdp hr DIRECTORY=dpump_dir1 DUMPFILE=tts.dmp
TRANSPORT_DATAFILES='/user01/data/workers.dat'

tts.dmpに含まれているメタデータがインポートされ、workers.datファイル内の情報がデータ・ポンプによってデータベースの正しい場所に割り当てられます。

関連項目:

「データ・ポンプ・コマンドラインでの引用符の使用」

TRANSPORT_FULL_CHECK

デフォルト: NO

用途

指定したトランスポータブル表領域セットが他の表領域内のオブジェクトによって参照されていることを確認するかどうかを指定します。

構文および説明

TRANSPORT_FULL_CHECK=[YES | NO]

TRANSPORT_FULL_CHECK=YESを指定すると、インポート・ユーティリティによって、トランスポータブル・セット内のオブジェクトとトランスポータブル・セット外のオブジェクトの間に依存性が存在しないことが確認されます。ここでは、双方向の依存性がチェックされます。たとえば、トランスポータブル・セット内に表は存在するが、その表の索引は存在しない場合は、エラーが返され、インポート操作が終了します。同様に、トランスポータブル・セット内に索引は存在するが表は存在しない場合も、エラーが返されます。

TRANSPORT_FULL_CHECK=NOを指定すると、インポート・ユーティリティによって、トランスポータブル・セット外のオブジェクトに依存するオブジェクトが、トランスポータブル・セット内に存在しないことのみ確認されます。ここでは、一方向の依存性がチェックされます。たとえば、表は索引に依存しませんが、索引は表に依存します。これは、索引は表なしでは意味を持たないためです。そのため、トランスポータブル・セット内に表は存在するが、表の索引は存在しない場合、このチェックは正常に終了します。ただし、トランスポータブル・セット内に索引は存在するが表は存在しない場合は、インポート操作が終了します。

このチェックに加えて、インポートでは、常に、TRANSPORT_TABLESPACESで指定された表領域セット内に定義されているすべての表(およびその索引)のすべての記憶域セグメントが、表領域セット内に実際に含まれていることが確認されます。

制限事項

- このパラメータは、NETWORK_LINKパラメータを指定した場合にのみトランスポータブル・モード(またはTRANSPORTABLE=ALWAYSがエクスポート時に指定されていた場合は表モードまたは全体モード)に対して有効です。

例

次の例では、source_database_linkを有効なデータベース・リンクの名前に置き換えます。また、この例では、tbs6.dbfというデータ・ファイルがすでに存在するものとします。

次の内容のパラメータ・ファイルfull_check.parを作成したとします。

DIRECTORY=dpump_dir1
TRANSPORT_TABLESPACES=tbs_6
NETWORK_LINK=source_database_link
TRANSPORT_FULL_CHECK=YES
TRANSPORT_DATAFILES='/wkdir/data/tbs6.dbf'

次のコマンドを発行します。

> impdp hr PARFILE=full_check.par

TRANSPORT_TABLESPACES

デフォルト: デフォルト値は設定されていません。

用途

データベース・リンク(NETWORK_LINKパラメータで指定)経由でトランスポータブル表領域モードのインポートの実行を指定します。

構文および説明

TRANSPORT_TABLESPACES=tablespace_name [, ...]

TRANSPORT_TABLESPACESパラメータは、ソース・データベースからターゲット・データベースにオブジェクト・メタデータがインポートされる表領域の名前のリストを指定するために使用します。

これはトランスポータブル・モード・インポートであるため、データのインポート先の表領域は、データ・ポンプによって自動的に作成されます。事前に表領域を作成しておく必要はありません。ただし、インポートを開始する前に、データ・ファイルをターゲット・データベースにコピーする必要があります。

インポート・コマンドラインでTRANSPORT_TABLESPACESを指定する場合は、データベース・リンクを指定するためにNETWORK_LINKパラメータも使用する必要があります。データベース・リンクは2つの物理データベース・サーバー間の接続であり、データベース・リンクを使用すると、クライアントから1つの論理データベースとしてこれらのサーバーにアクセスできます。オブジェクト・メタデータはデータベース・リンクを使用してソース(NETWORK_LINKによって指定されるデータベース)からエクスポートされ、ターゲット(impdpコマンドが発行されるデータベース)に直接インポートされるため、NETWORK_LINKパラメータが必要となります。この処理にはダンプ・ファイルは関連しません。また、実際のデータがある場所をインポートが認識できるように、TRANSPORT_DATAFILESパラメータも指定する必要があります(実際のデータは、他の手段を使用した別の操作でターゲットにコピーされます)。

注意:

トランスポータブル表領域モード・エクスポートによって生成されたダンプ・ファイル・セットがすでにある場合、そのダンプ・ファイルのトランスポータブル・モード・インポートを実行できますが、この場合TRANSPORT_TABLESPACESまたはNETWORK_LINKを指定しません。指定するとエラーが発生します。かわりに、(メタデータを含んでいる)ダンプ・ファイルとTRANSPORT_DATAFILESパラメータを指定します。TRANSPORT_DATAFILESパラメータが存在することで、これがトランスポータブル・モード・インポートであることと、実際のデータを取得する場所がインポートに通知されます。

トランスポータブル・ジョブを実行する場合、ベスト・プラクティスは、インポート・ジョブがターゲット・システムで正常に完了するまで、ソース・システムにデータ・ファイルのコピーを保持することです。インポート・ジョブがなんらかの理由で失敗しても、破損していないデータ・ファイルのコピーが残ります。

制限事項

- トランスポータブル表領域をエクスポートした後、それよりも古いリリース・レベルのデータベースにインポートすることはできません。インポート先のターゲット・データベースのリリース・レベルは、ソース・データベース以上である必要があります。

- TRANSPORT_TABLESPACESパラメータは、NETWORK_LINKパラメータも指定されている場合のみ有効です。

- トランスポータブル・モードは、暗号化された列をサポートしていません。

- TRANSPORT_TABLESPACESパラメータを使用してトランスポータブル表領域インポートを実行するには、COMPATIBLE初期化パラメータを11.0.0以上に設定する必要があります。

- オペレーティング・システムによっては、このパラメータの値を指定するときに引用符とともにエスケープ文字を使用する必要があります。このパラメータはパラメータ・ファイルで指定することをお薦めします。パラメータ・ファイルを使用すると、コマンドラインでは必要なエスケープ文字の数を減らすことができます。

- トランスポータブル表領域のジョブでは、データ・ポンプ・インポートのACCESS_METHODパラメータはサポートされません。

例

次の例では、source_database_linkを有効なデータベース・リンクの名前に置き換えます。また、この例では、tbs6.dbfというデータ・ファイルが、ソース・データベースからローカル・システムにすでにコピーされているものとします。次の内容のパラメータ・ファイルtablespaces.parを作成したとします。

DIRECTORY=dpump_dir1
NETWORK_LINK=source_database_link
TRANSPORT_TABLESPACES=tbs_6
TRANSPORT_FULL_CHECK=NO
TRANSPORT_DATAFILES='user01/data/tbs6.dbf'

次のコマンドを発行します。

> impdp hr PARFILE=tablespaces.par

関連項目:

- データベース・リンクの詳細は、Oracle Database管理者ガイドを参照してください。

- ソース・システムにデータ・ファイルのコピーを保持することがベスト・プラクティスである理由の詳細は、「データ・ファイル・コピーを使用したデータ移動」を参照してください

- 「データ・ポンプによるタイムスタンプ・データの処理方法」

- 「データ・ポンプ・コマンドラインでの引用符の使用」

TRANSPORTABLE

デフォルト: NEVER

用途

表モード・インポート(TABLESパラメータで指定)または全体モード・インポート(FULLパラメータで指定)中にトランスポータブル・オプションを使用する必要があるかどうかを指定します。

構文および説明

TRANSPORTABLE = [ALWAYS | NEVER]

使用可能な値の定義は、次のとおりです。

ALWAYS: インポート・ジョブでトランスポータブル・オプションを使用するように指定します。トランスポータブルが使用できない場合、ジョブは失敗します。

表モード・インポートでトランスポータブル・オプションを使用すると、指定した表、パーティションまたはサブパーティションのメタデータのみがインポートされるトランスポータブル表領域インポートになります。

全体モード・インポートでトランスポータブル・オプションを使用すると、指定したデータベースのすべてのオブジェクトのメタデータがインポートされる全体トランスポータブル・インポートになります。

どちらの場合も、別々の操作でターゲット・データベースに実際のデータ・ファイルをコピー(および通常は変換)する必要があります。

トランスポータブル・ジョブを実行する場合、ベスト・プラクティスは、インポート・ジョブがターゲット・システムで正常に完了するまで、ソース・システムにデータ・ファイルのコピーを保持することです。インポート・ジョブがなんらかの理由で失敗しても、破損していないデータ・ファイルのコピーが残ります。

NEVER: インポート・ジョブでトランスポータブル・オプションではなくダイレクト・パスまたは外部表による方法を使用してデータをロードするように指示します。これはデフォルトです。

表のパーティションのサブセットのみをインポートし、TRANSPORTABLE=ALWAYSパラメータを使用すると、それぞれのパーティションが非パーティション表になります。

表のパーティションのサブセットのみをインポートし、TRANSPORTABLEパラメータを使用しない場合、またはそのパラメータが NEVERに設定されている場合(デフォルト)は、次のようになります。

- PARTITION_OPTIONS=DEPARTITIONを使用している場合は、それぞれのパーティションが、非パーティション表として作成されます。

- PARTITION_OPTIONSを使用していない場合は、完全な表が作成されます。つまり、完全な表内のすべてのメタデータが、ソース上での表定義と同じになるようにターゲット・システム上に存在します。ただし、指定されたパーティション用のデータのみが表に挿入されます。

制限事項

- インポートのTRANSPORTABLEパラメータは、NETWORK_LINKパラメータも指定されている場合のみ有効です。

- TRANSPORTABLEパラメータは、表モード・インポートおよび全体モード・インポートでのみ有効です。

- トランスポータブル・インポートを実行するユーザーでは、ソース・データベースでDATAPUMP_EXP_FULL_DATABASEロール、ターゲット・データベースでDATAPUMP_IMP_FULL_DATABASEロールが必要になります。

- ネットワーク・インポートのために選択された記憶域を持つすべてのオブジェクトでは、ソース・システム上のすべての記憶域セグメントが、管理対象の非トランスポータブル表領域(SYSTEM / SYSAUX)内に全体として存在するか、ユーザー定義のトランスポータブル表領域内に全体として存在する必要があります。シングル・オブジェクトの記憶域は、2種類の表領域にまたがることはできません。

- ソース・データベースがリリース11.2.0.3の場合にTRANSPORTABLEパラメータを使用してネットワーク・ベースの全体トランスポータブル・インポートを実行するには、データ・ポンプのVERSIONパラメータを12.0以上に設定する必要があります。ソース・データベースがリリース12.1以上の場合、VERSIONパラメータは不要ですが、COMPATIBLEデータベース初期化パラメータを12.0.0以上に設定する必要があります。

例1

次に、ネットワーク・リンク・インポート中にTRANSPORTABLEパラメータを使用した例を示します。

> impdp system TABLES=hr.sales TRANSPORTABLE=ALWAYS
DIRECTORY=dpump_dir1 NETWORK_LINK=dbs1 PARTITION_OPTIONS=DEPARTITION
TRANSPORT_DATAFILES=datafile_name

例2

次に、NETWORK_LINKが、暗号化された表領域および暗号化された列を含む表が存在するOracle Database 11gリリース2 (11.2.0.3)を示している全体トランスポータブル・インポートを実行する場合にTRANSPORTABLEパラメータを使用した例を示します。

> impdp import_admin FULL=Y TRANSPORTABLE=ALWAYS VERSION=12 NETWORK_LINK=dbs1
ENCRYPTION_PASSWORD=password TRANSPORT_DATAFILES=<datafile_name>
LOGFILE=dpump_dir1:fullnet.log

関連項目:

- 「全体モード・インポート時のトランスポータブル・オプションの使用」

- ソース・システムにデータ・ファイルのコピーを保持することがベスト・プラクティスである理由の詳細は、「データ・ファイル・コピーを使用したデータ移動」を参照してください

VERSION

デフォルト: インポート操作でVERSIONパラメータを指定する必要はありません。データ・ポンプは次のうちの古い方を使用します。

- ネットワーク・インポートの場合、ダンプ・ファイルまたはソース・データベースに関連付けられているバージョン

- ターゲット・データベースのCOMPATIBLE初期化パラメータで指定されたバージョン

用途

インポートするデータベース・オブジェクトのバージョンを指定します(つまり、指定されたリリースと互換性のあるデータベース・オブジェクトおよび属性のみがインポートされます)。なお、これは、10.1より前のリリースのOracle Databaseでデータ・ポンプ・インポートが使用可能ということではありません。データ・ポンプ・インポートは、Oracle Database 10gリリース1(10.1)以降でのみ動作します。VERSIONパラメータを使用して可能になるのは、インポートするオブジェクトのバージョンの識別のみです。

構文および説明

VERSION=[COMPATIBLE | LATEST | version_string]

このパラメータは、ソース・システムのリリースより古い互換リリースのOracle Databaseが稼働しているターゲット・システムのロードに使用できます。指定したリリースと互換性のないソース・システム上のデータベース・オブジェクトまたは属性はターゲットに移動されません。たとえば、指定したリリースではサポートされていない新しいデータ型を含む表はインポートされません。このパラメータの有効な値は次のとおりです。

- COMPATIBLE - デフォルト値。メタデータのバージョンは、データベースの互換性レベルに対応します。データベースの互換性は、9.2.0以上に設定する必要があります。

- LATEST: メタデータのバージョンは、データベースのリリースに対応します。ターゲット・データベースの実際のバージョンがCOMPATIBLE初期化パラメータで指定されたバージョンより新しいである場合、インポート・ジョブでVERSION=LATESTを指定しても影響がありません。

- version_string: 特定のデータベース・リリース(11.2.0など)。

制限事項

- データ・ポンプのVERSIONパラメータを12.1より前の任意の値に指定すると、4000バイトを超える長さのVARCHAR2またはNVARCHAR2列と、2000バイトを超える長さのRAW列を含む表は、データ・ポンプのダンプ・ファイルから除外されます。

- ターゲットがOracle Database 12cリリース1 (12.1.0.1)以降で、ソースがOracle Database 11gリリース2 (11.2.0.3)以降である場合、ネットワーク・リンクで実行される全体インポートでは、VERSION=12を設定する必要があります。

- データ・ポンプのパラメータVERSION=12を使用してOracle Database 11gリリースで作成したダンプ・ファイルは、Oracle Database 12cリリース1 (12.1)以上でのみインポートできます。

例

次の例では、ターゲット・データベースをOracle Database 12cリリース1 (12.1.0.1)、ソース・データベースをOracle Database 11gリリース2 (11.2.0.3)と想定しています。ここでは、ネットワーク・ベース・インポートにVERSION=12を設定する必要があります。また、NETWORK_LINKパラメータを使用している場合、デフォルト・インポート・モードが全体モードであっても、コマンドラインでこれを指定する必要があります。

> impdp hr FULL=Y DIRECTORY=dpump_dir1
NETWORK_LINK=source_database_link VERSION=12

関連項目:

「異なるデータベース・リリース間のエクスポートとインポート」

VIEWS_AS_TABLES (ネットワーク・インポート)

デフォルト: デフォルト値は設定されていません。

注意:

このVIEWS_AS_TABLESの説明は、ネットワーク・インポート時に適用されます(データ・ポンプ・インポートのNETWORK_LINKパラメータの値を指定する場合)。ネットワーク・インポートではないインポートを実行する場合、「VIEWS_AS_TABLES (非ネットワーク・インポート)」を参照してください。

用途

1つ以上のビューを表としてインポートするように指定します。

構文および説明

VIEWS_AS_TABLES=[schema_name.]view_name[:table_name], ...

データ・ポンプによって、ビューと同じ列を持ち、ビューからフェッチされた行データを持つ表がインポートされます。データ・ポンプでは、ビューに依存する権限や制約などのオブジェクトもインポートされます。表に適用されない依存オブジェクト(UNDERオブジェクト権限の付与など)は、インポートされません。VIEWS_AS_TABLESパラメータは、単独で使用するか、TABLESパラメータと組み合せて使用します。どちらを使用しても、データ・ポンプでは表モード・インポートが実行されます。

構文要素の定義は次のとおりです。

schema_name: ビューが存在するスキーマの名前。スキーマ名を指定しない場合、デフォルトで、インポートを実行するユーザーになります。

view_name: 表としてインポートするビューの名前。ビューは存在し、LOB以外のスカラー列のみを含むリレーショナル・ビューである必要があります。無効なビューや存在しないビューを指定すると、そのビューはスキップされてエラー・メッセージが返されます。

table_name: インポートされるビューのメタデータのソースとなる表の名前。デフォルトでは、データ・ポンプによって、ビューと同じ列およびデータ型を持つ、行の含まれない一時的なテンプレート表が自動的に作成されます。データベースが読取り専用の場合、このテンプレート表のデフォルトの作成には失敗します。この場合、表名を指定できます。表は、ビューと同じスキーマに属している必要があります。これは、ヒープ構成のパーティション化されていないリレーショナル表である必要があります。ネストした表にすることはできません。

テンプレート表が明示的に指定された複数のビューがインポート・ジョブに含まれる場合、それらのテンプレート表はすべて異なっている必要があります。たとえば、2つのビューで同じテンプレート表を使用している次のジョブでは、ビューの1つがスキップされます。

impdp hr DIRECTORY=dpump_dir NETWORK_LINK=dblink1 VIEWS_AS_TABLES=v1:employees,v2:employees

オブジェクトの省略をレポートするエラー・メッセージが返されます。

テンプレート表は、インポート操作の完了後に自動的に削除されます。それらが存在している間は、次の問合せを実行してその名前を表示できます(名前はすべてKU$VATで始まります)。

SQL> SELECT * FROM user_tab_comments WHERE table_name LIKE 'KU$VAT%';
TABLE_NAME                     TABLE_TYPE
------------------------------ -----------
COMMENTS
-----------------------------------------------------
KU$VAT_63629                   TABLE
Data Pump metadata template table for view HR.EMPLOYEESV

制限事項

- VIEWS_AS_TABLESパラメータは、TRANSPORTABLE=ALWAYSパラメータと組み合せて使用することはできません。

- VIEWS_AS_TABLESパラメータを使用して作成された表には、指定したビューの一部であった非表示列は含まれません。

- VIEWS_AS_TABLESパラメータでは、LONGのデータ型の列のある表をサポートしていません。

例

次の例では、ネットワーク・インポートを実行して、読取り専用データベースからビューhr.v1のコンテンツをインポートします。ソース・データベースのhrスキーマには、ビューview1と同じジオメトリを持つテンプレート表が含まれる必要があります(この表はview1_tabと呼ばれます)。VIEWS_AS_TABLESパラメータには、ビュー名と表名をコロンで区切ってリストします。

> impdp hr VIEWS_AS_TABLES=view1:view1_tab NETWORK_LINK=dblink1

ビューは、ビューからフェッチされた行を持つview1という表としてインポートされます。表のメタデータは、テンプレート表のview1_tabからコピーされます。

VIEWS_AS_TABLES (非ネットワーク・インポート)

デフォルト: デフォルト値は設定されていません。

用途

ビューとしてエクスポートされたダンプ・ファイルの1つ以上の表をインポートするように指定します。

構文および説明

VIEWS_AS_TABLES=[schema_name.]view_name,...

VIEWS_AS_TABLESパラメータは、単独で使用するか、TABLESパラメータと組み合せて使用します。どちらを使用しても、データ・ポンプでは表モード・インポートが実行されます。

構文要素の定義は次のとおりです。

schema_name: ビューが存在するスキーマの名前。スキーマ名を指定しない場合、デフォルトで、インポートを実行するユーザーになります。

view_name: 表としてインポートするビューの名前。

制限事項

- VIEWS_AS_TABLESパラメータは、TRANSPORTABLE=ALWAYSパラメータと組み合せて使用することはできません。

- VIEWS_AS_TABLESパラメータを使用して作成された表には、指定したビューの一部であった非表示列は含まれません。

- VIEWS_AS_TABLESパラメータでは、LONGのデータ型の列のある表をサポートしていません。

例

次の例では、view1としてエクスポートされたscott1.dmpダンプ・ファイルの表をインポートします。

> impdp scott/tiger views_as_tables=view1 directory=data_pump_dir dumpfile=scott1.dmp

インポート・ユーティリティの対話方式コマンド・モードで使用可能なコマンド

対話方式コマンド・モードでは、現行のジョブは継続して続行されますが、端末へのロギングは一時停止され、インポート・プロンプト(Import>)が表示されます。

対話方式コマンド・モードを開始するには、次のいずれかの方法を使用します。

- 接続されたクライアントから、[Ctrl]を押しながら[C]を押します。

- ジョブを実行している端末以外の端末から、ATTACHパラメータを使用してジョブに接続します。この機能は、ある場所で開始したジョブを、後で別の場所から確認する場合に有効です。

表3-2に、現行のジョブに対して対話方式コマンド・モードでデータ・ポンプ・インポート・プロンプトから実行できる操作を示します。

表3-2 データ・ポンプ・インポートの対話方式コマンド・モードでサポートされているコマンド

アクティビティ

使用するコマンド

対話方式コマンド・モードを終了する。

CONTINUE_CLIENT

現行のジョブは続行したままインポート・クライアント・セッションを停止する。

EXIT_CLIENT

使用可能なコマンドの概要を表示する。

HELP

現在接続中のすべてのクライアント・セッションを切断し、現行のジョブを停止する。

KILL_JOB

現行のジョブに対するアクティブなワーカー・プロセスの数を増減する。このコマンドは、Oracle Database Enterprise Editionでのみ使用可能です。

PARALLEL

接続している停止ジョブを再開する。

START_JOB

現行のジョブの詳細な状態を表示する。

STATUS

現行のジョブを停止する。

STOP_JOB

CONTINUE_CLIENT

用途

モードを、対話方式コマンド・モードからロギング・モードに変更します。

構文および説明

CONTINUE_CLIENT

ロギング・モードでは、ジョブの状態が端末に継続的に出力されます。ジョブが現在停止している場合、CONTINUE_CLIENTを指定すると、クライアントがジョブの開始を試みます。

例

Import> CONTINUE_CLIENT

EXIT_CLIENT

用途

インポート・クライアント・セッションを停止し、インポート・ユーティリティを終了して、端末へのロギングを中断します。ただし、現行のジョブの実行は続行します。

構文および説明

EXIT_CLIENT

EXIT_CLIENTでは、ジョブが実行されたままになるため、ジョブがまだ「実行中」または「停止」状態になっている場合は、後でこのジョブに接続できます。ジョブの状態を確認するには、ジョブのログ・ファイルを監視するか、USER_DATAPUMP_JOBSビューまたはV$SESSION_LONGOPSビューを問い合せることができます。

例

Import> EXIT_CLIENT

HELP

用途

対話方式コマンド・モードで使用可能なデータ・ポンプ・インポート・コマンドの情報を表示します。

構文および説明

HELP

対話方式コマンド・モードで使用可能なコマンドの情報を表示します。

例

Import> HELP

KILL_JOB

用途

現在接続中のすべてのクライアント・セッションを切断してから、現行のジョブを停止します。インポート・ユーティリティを終了し、端末プロンプトに戻します。

構文および説明

KILL_JOB

KILL_JOBを使用して中断されたジョブは、再開できません。接続中のすべてのクライアント(KILL_JOBコマンドを発行しているクライアントを含む)は、現在のユーザーがジョブを停止しているという警告を受け取った後、切断されます。すべてのクライアントが切断されると、ジョブのプロセス構造が即時に停止し、マスター表およびダンプ・ファイルが削除されます。ログ・ファイルは、削除されません。

例

Import> KILL_JOB

PARALLEL

用途

現行のジョブに対してアクティブなワーカー・プロセスまたはPQスレーブ(あるいはその両方)の数を増減できます。

構文および説明

PARALLEL=integer

PARALLELは、コマンドライン・パラメータおよび対話方式モードのパラメータとして使用可能です。必要な数のパラレル処理を設定できます。増加処理は、リソースが十分にありパラレル化を必要とする作業量が十分にある場合は、即時に実行されます。減少処理は、既存のプロセスが現行のタスクを終了してから実行されます。整数値を小さくすると、ワーカーはアイドル状態になりますが、ジョブが終了するまで削除はされません。

制限事項

- このパラメータは、Oracle Database 11g以上のEnterprise Editionでのみ有効です。

例

Import> PARALLEL=10

関連項目:

並列度の詳細は、「PARALLEL」を参照してください

START_JOB

用途

接続している現行のジョブを開始します。

構文および説明

START_JOB[=SKIP_CURRENT=YES]

START_JOBコマンドは、(現在実行できない)接続中のジョブを再開します。ダンプ・ファイル・セットおよびマスター表が元のまま保持されている場合は、予期しない障害またはSTOP_JOBコマンドの発行後にデータの損失や破損なしにジョブが再開されます。

SKIP_CURRENTオプションでは、以前失敗したジョブ、または特定のオブジェクトでハングしたか、実行が遅いジョブを再開できます。失敗する文または現在処理されているオブジェクトはスキップされ、ジョブは次の項目から再開されます。パラレル・ジョブの場合は、このオプションが原因で、各ワーカーでの現在の処理がスキップされ、再開時に次の項目に移動されます。

SQLFILEジョブもトランスポータブル表領域モードでのインポートも再開できません。

例

Import> START_JOB

STATUS

用途

ジョブの累積的な状態、現行の操作の説明および推定完了率を表示します。ロギング・モードの状態を表示する間隔を再設定することもできます。

構文および説明

STATUS[=integer]

ロギング・モードでのこの状態の表示頻度を秒単位で指定できるオプションがあります。値を入力しなかった場合またはデフォルト値の0を使用した場合は、状態の定期表示はオフになり、状態は1回のみ表示されます。

この状態情報は、標準出力デバイスのみに書き込まれ、ログ・ファイルには(使用可能な場合でも)書き込まれません。

例

次に、現行のジョブの状態を表示し、ロギング・モードの表示間隔を2分(120秒)に変更する例を示します。

Import> STATUS=120

STOP_JOB

用途

現行のジョブを即時にまたは手順に従って停止し、インポート・ユーティリティを終了します。

構文および説明

STOP_JOB[=IMMEDIATE]

STOP_JOBコマンド発行時または発行後にマスター表およびダンプ・ファイル・セットに障害が発生していない場合は、そのジョブに接続し、START_JOBコマンドを使用して再開できます。

手順に従って停止する場合は、関連する値を指定しないでSTOP_JOBを使用します。確認を要求する警告が発行されます。手順に従った停止では、ワーカー・プロセスで現行のタスクが終了した後、ジョブが停止されます。

即時に停止するには、STOP_JOB=IMMEDIATEを指定します。確認を要求する警告が発行されます。接続中のすべてのクライアント(STOP_JOBコマンドを発行しているクライアントを含む)は、現在のユーザーがジョブを停止および切断中であるという警告を受け取ります。すべてのクライアントが切断されると、ジョブのプロセス構造が即時に停止されます。マスター・プロセスは、ワーカー・プロセスで現行のタスクが終了するまで待機はしません。STOP_JOB=IMMEDIATEを指定した場合、データ破損やデータ損失の危険性はありません。ただし、停止時に完了しなかった一部のタスクは、再開時に再実行する必要があります。

例

Import> STOP_JOB=IMMEDIATE

データ・ポンプ・インポートの使用例

この項では、データ・ポンプ・インポートの使用例を示します。

- 例3-1

- 例3-2

- ネットワーク・モード・インポートの実行

これらの例を正しく使用するために役立つ情報については、「インポート・パラメータの使用例」を参照してください。

データのみ表モード・インポートの実行

例3-1に、employees表のデータのみ表モード・インポートの実行方法を示します。例2-1で作成されたダンプ・ファイルを使用します。

CONTENT=DATA_ONLYパラメータは、すべてのデータベース・オブジェクト定義(メタデータ)をフィルタから除外します。表の行データのみロードされます。

例3-1 データのみ表モード・インポートの実行

> impdp hr TABLES=employees CONTENT=DATA_ONLY DUMPFILE=dpump_dir1:table.dmp
NOLOGFILE=YES

スキーマ・モード・インポートの実行

例3-2に、例2-4で作成したダンプ・ファイル・セットのスキーマ・モード・インポートを示します。

例3-2 スキーマ・モード・インポートの実行

> impdp hr SCHEMAS=hr DIRECTORY=dpump_dir1 DUMPFILE=expschema.dmp
EXCLUDE=CONSTRAINT,REF_CONSTRAINT,INDEX TABLE_EXISTS_ACTION=REPLACE

EXCLUDEパラメータは、インポートしたメタデータをフィルタします。指定したインポート・モードでは、EXCLUDE文に指定されたオブジェクトを除き、ソースに含まれるすべてのオブジェクトおよびその依存オブジェクトが含まれます。オブジェクトが除外されると、そのオブジェクトのすべての依存オブジェクトも除外されます。TABLE_EXISTS_ACTION=REPLACEパラメータでは、表がすでに存在する場合は削除し、ダンプ・ファイルの内容でその表を再作成してロードするように指定します。

ネットワーク・モード・インポートの実行

例3-3では、ソースが、NETWORK_LINKパラメータで指定されたデータベースであるネットワーク・モード・インポートを実行します。

関連項目:

データベース・リンクの詳細は、「NETWORK_LINK」を参照してください

例3-3 スキーマのネットワーク・モード・インポート

> impdp hr TABLES=employees REMAP_SCHEMA=hr:scott DIRECTORY=dpump_dir1
NETWORK_LINK=dblink

この例では、hrスキーマからscottスキーマへemployees表をインポートします。dblinkは、ターゲット・データベースとは異なるソース・データベースを示します。

スキーマを再マップするには、ユーザーhrに、ローカル・データベースのDATAPUMP_IMP_FULL_DATABASEロールおよびソース・データベースのDATAPUMP_EXP_FULL_DATABASEロールが必要です。

REMAP_SCHEMAは、ソース・スキーマにあるすべてのオブジェクトをターゲット・スキーマにロードします。

データ・ポンプ・インポートの構文図

この項では、データ・ポンプ・インポートの構文図を示します。これらの構文図では、標準SQL構文の表記法を使用します。SQL構文の表記法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ImpInit

ImpStart

ImpModes

ImpOpts

ImpContent

ImpEncrypt

ImpFilter

ImpPartitioning

ImpRacOpt

ImpRemap

ImpFileOpts

ImpNetworkOpts

ImpDynOpts

ImpTransforms

ImpVersion

ImpDiagnostics

4 データ・ポンプのレガシー・モード

オリジナルのエクスポート(exp)およびインポート(imp)を使用している場合は、長年使用してきたスクリプトが存在することがあります。データ・ポンプでは、データ・ポンプで既存のスクリプトを引き続き使用できるレガシー・モードが提供されるようになりました。

コマンドラインまたはスクリプトのいずれかにオリジナルのエクスポートまたはインポートに特有のパラメータが存在するとデータ・ポンプで判断されると、データ・ポンプはレガシー・モードに入ります。そのパラメータがデータ・ポンプで処理されると、データ・ポンプ・エクスポートまたはデータ・ポンプ・インポートと同等のパラメータが表示されます。新しい構文を確認し、時間があるときにスクリプトを変更することをお薦めします。

注意:

データ・ポンプ・エクスポートおよびデータ・ポンプ・インポート・ユーティリティでは、データ・ポンプ形式のダンプ・ファイルとログ・ファイルのみ、作成および読取りが実行されます。オリジナルのエクスポートやインポートと互換性のあるダンプ・ファイルが作成されたり、読み込まれることはありません。オリジナルのエクスポートで作成されたダンプ・ファイルがある場合は、オリジナルのインポートを使用してデータベースにデータをインポートする必要があります。

データ・ポンプのレガシー・モードを使用する前に、次の項目について理解する必要があります。

- パラメータのマッピング

- データ・ポンプ・レガシー・モードでのファイルの場所の管理

- データ・ポンプのログ・ファイルとエラーに対する既存のスクリプトの調整

パラメータのマッピング

この項では、オリジナルのエクスポートおよびインポートのパラメータと、同様の機能を持つデータ・ポンプ・エクスポートおよびデータ・ポンプ・インポートのパラメータとのマッピング関係について説明します。

関連項目:

- データ・ポンプ・エクスポート

- データ・ポンプ・インポート

- オリジナルのエクスポート

- オリジナルのインポート

データ・ポンプでのオリジナルのエクスポート・パラメータの使用

対応するデータ・ポンプ・パラメータにマップするオリジナルのエクスポート・パラメータがある場合は、そのエクスポート・パラメータをデータ・ポンプ・エクスポートで使用できます。表4-1に、オリジナルのエクスポート・パラメータがデータ・ポンプ・エクスポートでどのように解釈されるかを示します。オリジナルのエクスポートとデータ・ポンプのエクスポートで名前と機能が同じパラメータは、この表に含まれていません。

表4-1 データ・ポンプ・エクスポートでのオリジナルのエクスポート・パラメータの扱い

オリジナルのエクスポート・パラメータ

データ・ポンプ・エクスポート・パラメータでの処理

BUFFER

このパラメータは無視されます。

COMPRESS

このパラメータは無視されます。オリジナルのエクスポートの場合、COMPRESSパラメータは初期エクステントの管理方法に影響していました。オリジナルのエクスポートでは、COMPRESS=nに設定すると、初期エクステントと第2エクステントに対して現行の記憶域パラメータが使用されていました。

データ・ポンプ・エクスポートのCOMPRESSIONパラメータは、ダンプ・ファイルのデータ圧縮方法を指定するために使用されます。オリジナルのエクスポートのCOMPRESSパラメータとは関連がありません。

CONSISTENT

データ・ポンプ・エクスポートは現在の時刻を確認して、FLASHBACK_TIMEを使用します。

CONSTRAINTS

オリジナルのエクスポートでCONSTRAINTS=nを使用していた場合、データ・ポンプ・エクスポートはEXCLUDE=CONSTRAINTSを使用します。

デフォルトの動作では、制約がエクスポートに含まれます。

DIRECT

このパラメータは無視されます。データ・ポンプ・エクスポートでは、最適なエクスポート方法が自動的に選択されます。

FEEDBACK

データ・ポンプ・エクスポートのSTATUS=30コマンドが使用されます。STATUSコマンドでは、処理されている行に加えてエクスポート・ジョブの状態も返されるため、これは直接のマッピングではありません。

オリジナルのエクスポートでは、一定の行数(FEEDBACKコマンドで指定)の後にフィードバックが表示されていました。データ・ポンプ・エクスポートでは、STATUSで指定された秒数ごとに状態が表示されます。

FILE

データ・ポンプ・エクスポートは、FILEパラメータに対する指定パスまたはデフォルト・パスを確認します。また、スキーマに書込みアクセス権があるディレクトリ・オブジェクトが存在するかどうかも確認します。

データ・ポンプでのオリジナルのエクスポートのFILEパラメータの処理方法の詳細は、「データ・ポンプ・レガシー・モードでのファイルの場所の管理」を参照してください。

GRANTS

オリジナルのエクスポートでGRANTS=nを使用していた場合、データ・ポンプ・エクスポートはEXCLUDE=GRANTを使用します。

オリジナルのエクスポートでGRANTS=yを使用していた場合、そのパラメータは無視されます。その指定はデータ・ポンプ・エクスポートのデフォルトの動作であるため、再マップする必要はありません。

INDEXES

オリジナルのエクスポートでINDEXES=nを使用していた場合、データ・ポンプ・エクスポートはEXCLUDE=INDEXパラメータを使用します。

オリジナルのエクスポートでINDEXES=yを使用していた場合、そのパラメータは無視されます。その指定はデータ・ポンプ・エクスポートのデフォルトの動作であるため、再マップする必要はありません。

LOG

データ・ポンプ・エクスポートは、LOGパラメータに対する指定パスまたはデフォルト・パスを確認します。また、スキーマに書込みアクセス権があるディレクトリ・オブジェクトが存在するかどうかも確認します。

データ・ポンプでのオリジナルのエクスポートのLOGパラメータの処理方法の詳細は、「データ・ポンプ・レガシー・モードでのファイルの場所の管理」を参照してください。

ログ・ファイルの内容は、データ・ポンプ・エクスポート操作の内容になります。ログ・ファイルの場所と内容については、「ログ・ファイル」を参照してください。

OBJECT_CONSISTENT

このパラメータは無視されます。データ・ポンプ・エクスポートの処理では、エクスポートされる各オブジェクトの状態に一貫性があることが保証されています。

OWNER

データ・ポンプのSCHEMASパラメータが使用されます。

RECORDLENGTH

このパラメータは無視されます。データ・ポンプ・エクスポートでは、バッファ・サイズは自動的に調整されます。

RESUMABLE

このパラメータは無視されます。データ・ポンプ・エクスポートの場合、この機能はEXP_FULL_DATABASEロールを付与されているユーザーに自動的に提供されます。

RESUMABLE_NAME

このパラメータは無視されます。データ・ポンプ・エクスポートの場合、この機能はEXP_FULL_DATABASEロールを付与されているユーザーに自動的に提供されます。

RESUMABLE_TIMEOUT

このパラメータは無視されます。データ・ポンプ・エクスポートの場合、この機能はEXP_FULL_DATABASEロールを付与されているユーザーに自動的に提供されます。

ROWS

オリジナルのエクスポートでROWS=yを使用していた場合、データ・ポンプ・エクスポートはCONTENT=ALLパラメータを使用します。

オリジナルのエクスポートでROWS=nを使用していた場合、データ・ポンプ・エクスポートはCONTENT=METADATA_ONLYパラメータを使用します。

STATISTICS

このパラメータは無視されます。統計は、データ・ポンプ・エクスポート操作の一環として、表に対して常に保存されます。

TABLESPACES

オリジナルのエクスポートでTRANSPORT_TABLESPACE=nも指定していた場合、データ・ポンプ・エクスポートはTABLESPACESパラメータを無視します。

オリジナルのエクスポートでTRANSPORT_TABLESPACE=yも指定していた場合、データ・ポンプ・エクスポートは、TABLESPACESパラメータに対して指定されていた名前を、データ・ポンプ・エクスポートのTRANSPORT_TABLESPACESパラメータに対して使用します。

TRANSPORT_TABLESPACE

オリジナルのエクスポートでTRANSPORT_TABLESPACE=n(デフォルト)を使用していた場合、データ・ポンプ・エクスポートはTABLESPACESパラメータを使用します。

オリジナルのエクスポートでTRANSPORT_TABLESPACE=yを使用していた場合、データ・ポンプ・エクスポートはTRANSPORT_TABLESPACESパラメータを使用し、メタデータのみがエクスポートされます。

TRIGGERS

オリジナルのエクスポートでTRIGGERS=nを使用していた場合、データ・ポンプ・エクスポートはEXCLUDE=TRIGGERパラメータを使用します。

オリジナルのエクスポートでTRIGGERS=yを使用していた場合、そのパラメータは無視されます。その指定はデータ・ポンプ・エクスポートのデフォルトの動作であるため、再マップする必要はありません。

TTS_FULL_CHECK

オリジナルのエクスポートでTTS_FULL_CHECK=yを使用していた場合、データ・ポンプ・エクスポートはTRANSPORT_FULL_CHECKパラメータを使用します。

オリジナルのエクスポートでTTS_FULL_CHECK=yを使用していた場合、そのパラメータは無視されます。その指定はデータ・ポンプ・エクスポートのデフォルトの動作であるため、再マップする必要はありません。

VOLSIZE

オリジナルのエクスポートでVOLSIZEパラメータが使用されている場合、それはダンプ・ファイルの指定場所がテープ・デバイスであることを意味します。テープ・デバイスは、データ・ポンプ・エクスポートのダンプ・ファイル形式でサポートされていません。したがって、この操作はエラーが発生して終了します。

データ・ポンプでのオリジナルのインポート・パラメータの使用

データ・ポンプ・パラメータにマップするオリジナルのインポート・パラメータがある場合は、そのインポート・パラメータをデータ・ポンプ・インポートで使用できます。表4-2に、オリジナルのインポート・パラメータがデータ・ポンプ・インポートでどのように解釈されるかを示します。オリジナルのインポートとデータ・ポンプのインポートで名前と機能が同じパラメータは、この表に含まれていません。

表4-2 データ・ポンプ・インポートでのオリジナルのインポート・パラメータの扱い

オリジナルのインポート・パラメータ

データ・ポンプ・インポート・パラメータでの処理

BUFFER

このパラメータは無視されます。

CHARSET

このパラメータは、数リリース前からサポートされなくなりました。今後は使用しないでください。このパラメータは、データ・ポンプ・インポート操作が中断される原因になります。

COMMIT

このパラメータは無視されます。データ・ポンプ・インポートでは、表の処理が終了するたびにコミットが自動的に実行されます。

COMPILE

このパラメータは無視されます。データ・ポンプ・インポートでは、プロシージャの作成後にコンパイルが実行されます。依存性の理由で必要な場合は、再コンパイルを実行できます。

CONSTRAINTS

オリジナルのインポートでCONSTRAINTS=nを使用していた場合、データ・ポンプ・インポートはEXCLUDE=CONSTRAINTパラメータを使用します。

オリジナルのインポートでCONSTRAINTS=yを使用していた場合、そのパラメータは無視されます。その指定はデータ・ポンプ・インポートのデフォルトの動作であるため、再マップする必要はありません。

DATAFILES

データ・ポンプ・インポートのTRANSPORT_DATAFILESパラメータが使用されます。

DESTROY

オリジナルのインポートでDESTROY=yを使用していた場合、データ・ポンプ・インポートはREUSE_DATAFILES=yパラメータを使用します。

オリジナルのインポートでDESTROY=nを使用していた場合、そのパラメータは無視されます。その指定はデータ・ポンプ・インポートのデフォルトの動作であるため、再マップする必要はありません。

FEEDBACK

データ・ポンプ・インポートのSTATUS=30コマンドが使用されます。STATUSコマンドでは、処理されている行に加えてインポート・ジョブの状態も返されるため、これは直接のマッピングではありません。

オリジナルのインポートでは、一定の行数(FEEDBACKコマンドで指定)の後にフィードバックが表示されていました。データ・ポンプ・インポートでは、STATUSで指定された秒数ごとに状態が表示されます。

FILE

データ・ポンプ・インポートは、FILEパラメータに対する指定パスまたはデフォルト・パスを確認します。また、スキーマに書込みアクセス権があるディレクトリ・オブジェクトが存在するかどうかも確認します。

データ・ポンプでのオリジナルのインポートのFILEパラメータの処理方法の詳細は、「データ・ポンプ・レガシー・モードでのファイルの場所の管理」を参照してください。

FILESIZE

このパラメータは無視されます。この情報はデータ・ポンプのダンプ・ファイル・セットにすでに含まれています。

FROMUSER

データ・ポンプ・インポートのSCHEMASパラメータが使用されます。TOUSERを使用せずにFROMUSERが使用されていた場合は、IMP_FULL_DATABASEロールを持つインポート・スキーマによって、データ・ポンプ・インポートでスキーマが作成され、そのスキーマのオブジェクトがインポートされます。IMP_FULL_DATABASEロールを持っていないインポート・スキーマは、ダンプ・ファイル・セットから自分のスキーマのみをインポートできます。

GRANTS

オリジナルのインポートでGRANTS=nを使用していた場合、データ・ポンプ・インポートはEXCLUDE=OBJECT_GRANTパラメータを使用します。

オリジナルのインポートでGRANTS=yを使用していた場合、そのパラメータは無視されます。その指定はデータ・ポンプ・インポートのデフォルトの動作であるため、再マップする必要はありません。

IGNORE

オリジナルのインポートでIGNORE=yを使用していた場合、データ・ポンプ・インポートはTABLE_EXISTS_ACTION=APPENDパラメータを使用します。これにより、表データの処理が続行されます。

オリジナルのインポートでIGNORE=nを使用していた場合、そのパラメータは無視されます。その指定はデータ・ポンプ・インポートのデフォルトの動作であるため、再マップする必要はありません。

INDEXES

オリジナルのインポートでINDEXES=nを使用していた場合、データ・ポンプ・インポートはEXCLUDE=INDEXパラメータを使用します。

オリジナルのインポートでINDEXES=yを使用していた場合、そのパラメータは無視されます。その指定はデータ・ポンプ・インポートのデフォルトの動作であるため、再マップする必要はありません。

INDEXFILE

データ・ポンプ・インポートのSQLFILE={directory-object:}filenameおよびINCLUDE=INDEXパラメータが使用されます。

FILEパラメータに対してディレクトリ・オブジェクトを検索する場合の方法と手順が、INDEXFILEパラメータに対しても同様に適用されます。

オリジナルのインポートでディレクトリ・オブジェクトが指定されていなかった場合は、DIRECTORYパラメータで指定されたディレクトリ・オブジェクトがデータ・ポンプ・インポートで使用されます。

LOG

データ・ポンプ・インポートは、LOGパラメータに対する指定パスまたはデフォルト・パスを確認します。また、スキーマに書込みアクセス権があるディレクトリ・オブジェクトが存在するかどうかも確認します。

データ・ポンプでのオリジナルのインポートのLOGパラメータの処理方法の詳細は、「データ・ポンプ・レガシー・モードでのファイルの場所の管理」を参照してください。

ログ・ファイルの内容は、データ・ポンプ・インポート操作の内容になります。ログ・ファイルの場所と内容については、「ログ・ファイル」を参照してください。

RECORDLENGTH

このパラメータは無視されます。データ・ポンプの場合、レコード長に関する問題は内部で処理されます。

RESUMABLE

このパラメータは無視されます。この機能はIMP_FULL_DATABASEロールを付与されているユーザーに対して自動的に提供されます。

RESUMABLE_NAME

このパラメータは無視されます。この機能はIMP_FULL_DATABASEロールを付与されているユーザーに対して自動的に提供されます。

RESUMABLE_TIMEOUT

このパラメータは無視されます。この機能はIMP_FULL_DATABASEロールを付与されているユーザーに対して自動的に提供されます。

ROWS=N

オリジナルのインポートでROWS=nを使用していた場合、データ・ポンプ・インポートはCONTENT=METADATA_ONLYパラメータを使用します。

オリジナルのインポートでROWS=yを使用していた場合、データ・ポンプ・インポートはCONTENT=ALLパラメータを使用します。

SHOW

SHOW=yが指定されている場合、データ・ポンプ・インポートのSQLFILE=[directory_object:]file_nameパラメータを使用して、インポート操作のDDLがファイルに書き込まれます。指定ファイルには、(ダンプ・ファイルの全体の内容ではなく)DDLのみが書き込まれます。(これは、オリジナルのインポートなので、画面に出力は表示されません。)

DUMPFILEパラメータ(またはDUMPFILEに再マップされる、オリジナルのインポートのFILEパラメータ)で指定された名前がファイルの名前になります。指定されているダンプ・ファイル名が複数ある場合は、最初に指定されているファイル名が使用されます。ファイルは、DIRECTORYパラメータで指定されたディレクトリ・オブジェクトの場所か、DUMPFILEパラメータに含まれるディレクトリ・オブジェクトに配置されます。(DUMPFILEパラメータで指定されたディレクトリ・オブジェクトが優先されます。)

STATISTICS

このパラメータは無視されます。統計は、データ・ポンプ・インポート操作の一環として、表に対して常に保存されます。

STREAMS_CONFIGURATION

このパラメータは無視されます。この値はデータ・ポンプ・インポートによって自動的に決定されるため、指定する必要はありません。

STREAMS_INSTANTIATION

このパラメータは無視されます。この値はデータ・ポンプ・インポートによって自動的に決定されるため、指定する必要はありません。

TABLESPACES

オリジナルのインポートでTRANSPORT_TABLESPACE=n(デフォルト)も指定されていた場合、データ・ポンプ・インポートはTABLESPACESパラメータを無視します。

オリジナルのインポートでTRANSPORT_TABLESPACE=yも指定していた場合、データ・ポンプ・インポートは、このTABLESPACESパラメータに対して指定されていた名前を、データ・ポンプ・インポートのTRANSPORT_TABLESPACESパラメータに適用します。

TOID_NOVALIDATE

このパラメータは無視されます。型比較に、OIDは使用されなくなりました。

TOUSER

データ・ポンプ・インポートのREMAP_SCHEMAパラメータが使用されます。オリジナルのインポートより多くのオブジェクトをインポートできます。また、ターゲットのスキーマがまだ存在していない場合は、データ・ポンプ・インポートで作成することもできます。

オリジナルのインポートでFROMUSERパラメータも指定されている必要があります。指定されていない場合は、操作が失敗します。

TRANSPORT_TABLESPACE

TRANSPORT_TABLESPACEパラメータは無視されますが、DATAFILESパラメータも指定した場合、インポート・ジョブはメタデータのロードを続行します。DATAFILESパラメータを指定しない場合、ORA-39002:invalid operationエラー・メッセージが返されます。

TTS_OWNERS

このパラメータは無視されます。この情報はデータ・ポンプのダンプ・ファイル・セットに自動的に保存されます。

VOLSIZE

オリジナルのインポートでVOLSIZEパラメータが使用されている場合、それはダンプ・ファイルの指定場所がテープ・デバイスであることを意味します。テープ・デバイスは、データ・ポンプ・インポートのダンプ・ファイル形式でサポートされていません。したがって、この操作はエラーが発生して終了します。

データ・ポンプ・レガシー・モードでのファイルの場所の管理

オリジナルのバージョンはクライアントベース、データ・ポンプはサーバーベースであるため、オリジナルのエクスポートとインポート、およびデータ・ポンプ・エクスポートとデータ・ポンプ・インポートは、ダンプ・ファイルとログ・ファイルの書込み/読取りを行える場所によって異なります。

オリジナルのエクスポートおよびインポートでは、FILEパラメータとLOGパラメータを使用して、それぞれダンプ・ファイル名とログ・ファイル名を指定します。これらのファイル名は常にクライアント・システムに対してローカルなファイルを参照し、パスの指定を含めることもできます。

データ・ポンプ・エクスポートおよびデータ・ポンプ・インポートでは、DUMPFILEパラメータとLOGFILEパラメータを使用して、それぞれダンプ・ファイル名とログ・ファイル名を指定します。これらのファイル名は常にサーバー・システムに対してローカルなファイルを参照し、パス情報を含めることはできません。かわりに、ディレクトリ・オブジェクトを使用して、パス情報を間接的に指定します。ディレクトリ・オブジェクトによって定義されるパス値は、サーバーからアクセスできる必要があります。ディレクトリ・オブジェクトは、データ・ポンプ・ジョブ用にDIRECTORYパラメータを使用して指定されます。DUMPFILEパラメータおよびLOGFILEパラメータに渡されるファイル名にディレクトリ・オブジェクトを付加することもできます。データ・ポンプを使用する特権ユーザーは、ディレクトリ・オブジェクトがコマンドラインで指定されていない場合に、デフォルト・ディレクトリ・オブジェクトを使用できます。このデフォルトのディレクトリ・オブジェクトDATA_PUMP_DIRは、インストール時に設定されます。

データ・ポンプのレガシー・モードを有効にし、オリジナルのエクスポートのFILE=filespecパラメータまたはLOG=filespecパラメータ(あるいはその両方)をコマンドラインに指定すると、次の優先順位ルールで、ファイルの場所が決まります。

注意:

コマンドラインにFILEパラメータとLOGパラメータの両方を指定した場合は、優先順位ルールがそれぞれのパラメータに個別に適用されます。

また、オリジナルのエクスポートおよびインポートとデータ・ポンプ・エクスポート、データ・ポンプ・インポートのパラメータが混在する場合は、個別のルールがそれぞれ適用されます。たとえば、次のコマンドを指定したとします。

expdp system FILE=/user/disk/foo.dmp LOGFILE=foo.log DIRECTORY=dpump_dir

この項で説明したとおり、データ・ポンプのレガシー・モードによるファイル管理ルールが、FILEパラメータに適用されます。通常の(レガシー・モードではない)データ・ポンプのファイル管理ルールは、「ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置」で説明されているとおりに、LOGFILEパラメータに適用されます。

1. パスの位置がファイル指定の一部として指定されると、データ・ポンプはエクスポート・ジョブを実行するスキーマからアクセスでき、そのパスの位置がファイル指定でのパスの位置に一致するディレクトリ・オブジェクトの検索を試行します。そのようなディレクトリ・オブジェクトが見つからないと、エラーが返されます。たとえば、USER_DUMP_FILESという名前のサーバーベースのディレクトリ・オブジェクトが'/disk1/user1/dumpfiles/'のパス値とともに定義されていて、このディレクトリ・オブジェクトへの読取り/書込みアクセス権限がhrスキーマに付与されているとします。次のコマンドを実行すると、データ・ポンプはそのパス値に'/disk1/user1/dumpfiles/'が含まれ、そのhrスキーマに読取り/書込みアクセス権限が付与されているサーバーベースのディレクトリ・オブジェクトを探します。

expdp hr FILE=/disk1/user1/dumpfiles/hrdata.dmp

その場合、データ・ポンプはディレクトリ・オブジェクトUSER_DUMP_FILESを使用します。この例で使用されているパス値'/disk1/user1/dumpfiles/'は、Oracle Databaseからアクセスできるサーバー・システム上のパスを参照している必要があります。

パスの位置がファイル指定の一部として指定されている場合は、DIRECTORYパラメータで指定されたディレクトリ・オブジェクトが無視されます。たとえば、次のコマンドを実行すると、データ・ポンプはファイル・パラメータのDPUMP_DIRディレクトリ・オブジェクトを使用せず、かわりにそのパス値に'/disk1/user1/dumpfiles/'が含まれ、そのhrスキーマに読取り/書込みアクセス権限が付与されているサーバーベースのディレクトリ・オブジェクトを探します。

expdp hr FILE=/disk1/user1/dumpfiles/hrdata.dmp DIRECTORY=dpump_dir

2. パスの位置がファイル指定の一部として指定されない場合は、DIRECTORYパラメータに指定されたディレクトリ・オブジェクトが使用されます。たとえば、次のコマンドを実行すると、データ・ポンプはDPUMP_DIRディレクトリ・オブジェクト用に定義されたパスの位置をhrdata.dmpファイルに適用します。

expdp hr FILE=hrdata.dmp DIRECTORY=dpump_dir

3. パスの位置がファイル指定の一部として指定されず、DIRECTORYパラメータにディレクトリ・オブジェクトが指定されていない場合は、データ・ポンプによって次のように動作が順次実行されます。

a. データ・ポンプはDATA_PUMP_DIR_schema_nameという形式のディレクトリ・オブジェクトを探します。ここでのschema_nameは、データ・ポンプ・ジョブを実行するスキーマです。たとえば、次のコマンドを実行すると、データ・ポンプはDATA_PUMP_DIR_HRという名前のサーバーベースのディレクトリ・オブジェクトを探します。

expdp hr FILE=hrdata.dmp

また、hrスキーマには、このディレクトリ・オブジェクトへの読取り/書込みアクセス権限が付与されている必要があります。そのようなディレクトリ・オブジェクトが存在しないとき、処理は手順bに進みます。

b. データ・ポンプは、クライアントベースの環境変数DATA_PUMP_DIRを探します。たとえば、DUMP_FILES1という名前のサーバーベースのディレクトリ・オブジェクトが定義されていて、hrスキーマにそのオブジェクトへの読取り/書込みアクセス権限が付与されているとします。その場合は、クライアント・システムで、次のようにDUMP_FILES1を指すように環境変数DATA_PUMP_DIRを設定します。

setenv DATA_PUMP_DIR DUMP_FILES1
expdp hr FILE=hrdata.dmp

データ・ポンプは、次にサーバーベースのディレクトリ・オブジェクトDUMP_FILES1をhrdata.dmpファイルに対して使用します。

クライアントベースの環境変数DATA_PUMP_DIRが存在しないとき、処理は手順cに進みます。

c. データ・ポンプ・ジョブを実行するスキーマにDBA権限があると、デフォルトのデータ・ポンプ・ディレクトリ・オブジェクトDATA_PUMP_DIRが使用されます。このデフォルトのディレクトリ・オブジェクトは、インストール時に設定されます。たとえば、次のコマンドを実行すると、データ・ポンプはシステムにDBA権限があるとみなし、デフォルトのDATA_PUMP_DIRディレクトリ・オブジェクトを使用しようとします。

expdp system FILE=hrdata.dmp

関連項目:

通常モードのデータ・ポンプ(レガシー・モードではない)でのデータ・ポンプのファイル管理優先順位ルールの詳細は、「ダンプ・ファイル、ログ・ファイルおよびSQLファイルのデフォルトの位置」を参照してください

データ・ポンプのログ・ファイルとエラーに対する既存のスクリプトの調整

データ・ポンプのレガシー・モードを使用する場合は、オリジナルのエクスポートおよびインポート用に作成された既存のスクリプトを確認して更新する必要があります。これは、ファイルの形式およびエラーのレポート処理が異なるためです。

ログ・ファイル

データ・ポンプのエクスポートおよびインポートで作成されるログ・ファイルは、オリジナルのエクスポートおよびインポートとは形式が異なります。オリジナルのエクスポートおよびインポートの出力を解析するスクリプトがある場合は、データ・ポンプのエクスポートおよびインポートで使用されるログ・ファイル形式を扱えるように更新する必要があります。たとえば、「Successfully Terminated」というメッセージは、データ・ポンプのログ・ファイルには表示されません。

エラー

データ・ポンプのエクスポートおよびインポートと、オリジナルのエクスポートおよびインポートとでは、生成されるエラーが異なる場合があります。たとえば、データ・ポンプ・エクスポートで無視されるパラメータが、オリジナルのエクスポートで範囲外の値である場合、ログ・ファイルに書き込まれるのは、パラメータは無視されるという情報メッセージです。値のチェックは実行されないため、エラー・メッセージは生成されません。

終了ステータス

データ・ポンプ・エクスポートおよびデータ・ポンプ・インポートには、エクスポート・ジョブとインポート・ジョブの成功または失敗をスクリプトでより適切に判定できるようにするための、拡張された終了状態の値があります。終了状態を参照するスクリプトは、必要に応じて確認および更新する必要があります。

5 データ・ポンプ・ユーティリティのパフォーマンス

データ・ポンプ・エクスポートおよびデータ・ポンプ・インポート・ユーティリティは、大規模データベースを対象に設計されています。大量のデータおよびメタデータがある場合は、オリジナルのエクスポート・ユーティリティおよびインポート・ユーティリティと比較して、データのパフォーマンスが向上します。(データ・ポンプ・エクスポート・ユーティリティおよびデータ・ポンプ・インポート・ユーティリティでのメタデータ抽出およびデータベース・オブジェクト作成のパフォーマンスは、基本的にはオリジナルのエクスポート・ユーティリティおよびインポート・ユーティリティのパフォーマンスと同様です。)

次に示す項目は、データ・ポンプのパフォーマンスが向上する理由の理解に役立ち、また、データ・ポンプのエクスポートおよびインポート操作のパフォーマンスを向上させるための具体的な手順を提案するものです。

- データ・ポンプ・エクスポート・ユーティリティおよびデータ・ポンプ・インポート・ユーティリティのデータ・パフォーマンスの改善点

- パフォーマンスのチューニング

- データ・ポンプ・ユーティリティのパフォーマンスに影響する初期化パラメータ

データ・ポンプ・エクスポート・ユーティリティおよびデータ・ポンプ・インポート・ユーティリティのデータ・パフォーマンスの改善点

次に、データ・ポンプ・エクスポートおよびインポート・ユーティリティでのパフォーマンス向上の要因を示します。

- 複数のワーカー・プロセスで、表間およびパーティション間のパラレル処理を実行して、複数のパラレル・ダイレクト・パス・ストリームで表をロードおよびアンロードできます。

- 非常に大きい表およびパーティションの場合は、単一のワーカー・プロセスで、外部表による方法を使用してデータにアクセスすると、複数のパラレル問合せおよびパラレルDML I/Oサーバー・プロセスを介してパーティション間のパラレル処理を選択できます。

- データ・ポンプでは、索引の作成およびパッケージ本体のロードにパラレル処理を使用します。

- ダンプ・ファイルは、直接サーバーで読取りおよび書込みが行われるため、データをクライアントに移動する必要はありません。

- ダンプ・ファイルの格納形式は、ダイレクト・パスAPIの内部ストリーム形式です。これは、表領域内部のOracle Databaseのデータ・ファイルに格納されている形式と同様の形式です。したがって、クライアント側ではINSERT文バインド変数への変換は実行されません。

- サポートされているデータ・アクセス方法(ダイレクト・パスおよび外部表による方法)は従来のSQLより高速です。ダイレクト・パスAPIを使用すると、単一ストリームでの最大のパフォーマンスが実現します。外部表機能を使用すると、Oracle Databaseのパラレル問合せおよびパラレルDML機能を効率的に使用できます。

- エクスポート時に、メタデータとデータの抽出を同時に実行できます。

パフォーマンスのチューニング

データ・ポンプでは、すべての使用可能なリソースを最大限に使用して、スループットの最大化およびジョブ経過時間の最小化が行われるように設計されています。これを実現するには、システムでCPU、メモリー、I/O間でバランスがとられている必要があります。また、パフォーマンス・チューニングの標準原理が適用されます。たとえば、ダンプ・ファイル・セット内のダンプ・ファイルの書込みおよび読取りはパラレルで行われるため、最大のパフォーマンスを得るにはそれらのダンプ・ファイルを個別のディスクに常駐させる必要があります。また、それらのダンプ・ファイルは、ソースまたはターゲットの表領域が常駐するディスクとは別のディスクに常駐させる必要があります。

パフォーマンス・チューニングを行う場合は、パフォーマンスとリソース消費のバランスをとることが必要です。

この項の内容は、次のとおりです。

- リソース消費の制御

- 圧縮および暗号化によるパフォーマンスへの影響

- 統計のエクスポートおよびインポートにおけるメモリーの考慮事項

リソース消費の制御

データ・ポンプ・エクスポートおよびインポート・ユーティリティを使用すると、ジョブごとのリソース消費量を動的に増減できます。これを実行するには、データ・ポンプのPARALLELパラメータを使用してそのジョブの並列度を指定します。最大のスループットを得るには、PARALLELをCPU数の2倍(CPUごとに2つのワーカー)以下に設定してください。

並列度を増加すると、CPU使用量、メモリー使用量およびI/O帯域幅使用も増大します。これらのリソースの使用可能な量が適切であることを確認してください。必要に応じて、異なるディスク・デバイスまたはチャネル間にファイルを分散して、必要なI/O帯域幅を確保できます。

並列度を最大にするには、並列度ごとに少なくとも1つのファイルを提供する必要があります。これを簡単に行うには、たとえばfile%u.dmpのように、ファイル名に置換変数を使用します。ただし、ディスク設定によっては(たとえば、単純な非ストライプ・ディスクなどの場合)、すべてのダンプ・ファイルを1つのデバイスに配置しない場合があります。その場合は、置換変数を使用して複数のファイル名を指定し、それぞれのファイルを別々のディレクトリ(別々のディスク)に配置します。高速CPUと高速ディスクを使用する場合でも、CPUとディスク間のパスは、持続可能な並列度の量を制約する要因になることがあります。

データ・ポンプのPARALLELパラメータは、Oracle Database 11g以上のEnterprise Editionでのみ有効です。

圧縮および暗号化によるパフォーマンスへの影響

圧縮および暗号化に関連するデータ・ポンプ・パラメータを使用すると、特にネットワーク・モードで実行されるジョブの場合にパフォーマンスが向上する可能性があります。ただし、RAWデータの変換を実行するために必要な追加のCPUリソースが原因で、パフォーマンスが低下する場合もあることに注意してください。両者はトレードオフの関係にあります。

統計のエクスポートおよびインポートにおけるメモリーの考慮事項

12.1より前のリリースで作成され、統計データが大量に含まれるデータ・ポンプ・エクスポート・ダンプ・ファイルでは、インポート操作で大量のメモリーを消費する場合があります。インポート操作時のメモリーの不足を回避するには、インポートの開始前に十分にメモリーを割り当てる必要があります。必要とされるメモリーの正確な量は、インポートするデータの量、使用しているプラットフォーム、または使用する構成に固有の要素によって異なります。

この問題にまとめて対処するには、エクスポートまたはインポート操作のいずれかの際にデータ・ポンプのEXCLUDE=STATISTICSパラメータを設定します。DBMS_STATS PL/SQLパッケージを使用すると、インポートが完了した後にターゲット・データベースで統計を再生成することができます。

関連項目:

- DBMS_STATS PL/SQLパッケージを使用して手動で統計を収集する場合の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。

- DBMS_STATS PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- データ・ポンプ・エクスポートのEXCLUDEパラメータ

- データ・ポンプ・インポートのEXCLUDEパラメータ

データ・ポンプ・ユーティリティのパフォーマンスに影響する初期化パラメータ

特定のOracle Database初期化パラメータの設定が、データ・ポンプ・エクスポートおよびデータ・ポンプ・インポートのパフォーマンスに影響する場合があります。特に、次の設定を使用してパフォーマンスを改善できます。ただし、プラットフォームによっては同様の効果を得られない場合もあります。

- DISK_ASYNCH_IO=TRUE

- DB_BLOCK_CHECKING=FALSE

- DB_BLOCK_CHECKSUM=FALSE

次の初期化パラメータには、並列度が最大になる値を指定する必要があります。

- PROCESSES

- SESSIONS

- PARALLEL_MAX_SERVERS

さらに、初期化パラメータSHARED_POOL_SIZEとUNDO_TABLESPACEは、余裕のある大きさにする必要があります。具体的な値は、データベースのサイズによって異なります。

Streams環境でのバッファ・キャッシュ・サイズの設定

Oracle Data Pumpは、Streams機能を使用してプロセス間の通信を行います。SGA_TARGET初期化パラメータが設定されていると、STREAMS_POOL_SIZE初期化パラメータは自動的に合理的な値に設定されます。

SGA_TARGET初期化パラメータが設定されていない状態で、STREAMS_POOL_SIZE初期化パラメータも定義されていない場合は、ストリーム・プールのサイズは自動的に共有プール・サイズの10%(デフォルト)になります。

ストリーム・プールが作成されると、バッファ・キャッシュに割り当てられたメモリーから必要なSGAメモリーが確保されるため、キャッシュのサイズは、DB_CACHE_SIZE初期化パラメータで指定したサイズよりも少なくなります。つまり、バッファ・キャッシュが必要最小限のSGAで構成されていた場合、データ・ポンプ操作は正しく動作しません。データ・ポンプ操作を正常に実行するために、STREAMS_POOL_SIZEの値は、最小サイズの10MBにすることをお薦めします。

関連項目:

『Oracle Streams概要および管理』

6 データ・ポンプAPI

データ・ポンプAPI(DBMS_DATAPUMP)は、あるサイトのデータおよびメタデータのすべてまたは一部をデータベース間で移動するための高速なメカニズムを提供します。データ・ポンプ・エクスポートおよびデータ・ポンプ・インポート・ユーティリティはデータ・ポンプAPIに基づいています。

ここでは、次の項目について説明します。

- データ・ポンプAPIのクライアント・インタフェースの動作

- データ・ポンプAPIを使用する場合の基本手順

- データ・ポンプAPIの使用例

関連項目:

- DBMS_DATAPUMPパッケージで使用可能なプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- データ・ポンプの概要の詳細は、「Oracle Data Pumpの概要」を参照してください

データ・ポンプAPIのクライアント・インタフェースの動作

クライアント・インタフェースで使用されている主な構造体はジョブ・ハンドルで、コール元に対しては整数として表示されます。ハンドルは、DBMS_DATAPUMP.OPENファンクションまたはDBMS_DATAPUMP.ATTACHファンクションを使用して作成します。他のセッションをジョブに接続してその進捗状況を監視および制御できます。この機能によって、DBAは帰宅前にジョブを開始して、自宅でその進捗状況を確認できます。ハンドルはセッション固有です。同じジョブによって、セッションごとに異なるハンドルを作成できます。

ジョブの状態

次に、各フェーズに関連付けられたジョブの状態を示します。

- 未定義: ハンドル作成前

- 定義中: ハンドルの最初の作成時

- 実行中: DBMS_DATAPUMP.START_JOBプロシージャの実行時

- 完了中: ジョブがその作業を終了し、データ・ポンプ・プロセスを終了中

- 完了: ジョブの完了時

- 停止保留: 手順に従ったジョブの停止が要求された場合

- 停止処理中: ジョブの停止処理を実行中

- アイドル: 停止しているジョブに接続するためにDBMS_DATAPUMP.ATTACHが実行されてから、そのジョブを再開するためにDBMS_DATAPUMP.START_JOBが実行されるまでの期間

- 未実行: 実行されていない(関連付けられたデータ・ポンプ・プロセスが存在しない)ジョブに対してマスター表が存在する状態

「アイドル」状態のジョブに対してDBMS_DATAPUMP.START_JOBを実行すると、「実行中」状態に戻ります。

すべてのユーザーがDBMS_DATAPUMP.DETACHを実行して「定義中」状態のジョブとの接続を切断すると、そのジョブはデータベースから完全に削除されます。

ジョブが異常終了した場合またはジョブを実行しているインスタンスが停止した場合、「実行中」または「アイドル」状態のジョブは「未実行」状態になります。ユーザーは、その状態からジョブを再開できます。

マスター制御プロセスは、「定義中」、「アイドル」、「実行中」、「停止処理中」、「停止保留」、「完了処理中」の状態でアクティブです。また、一時的に「停止」および「完了」の状態にもなります。ジョブのマスター表は、「未定義」状態を除いてすべての状態で存在します。ワーカー・プロセスは「実行中」および「停止保留」状態、つまりインポート・ジョブに対する「定義中」状態でのみアクティブです。

ジョブの状態が「実行中」の場合に接続を切断しても、そのジョブは停止しません。実行中のジョブにはいつでも再接続して、ジョブに関する状態情報を再度取得できます。

DBMS_DATAPUMP.DETACHプロシージャが実行されると、明示的に切断されることがあります。または、データ・ポンプAPIセッションが停止した場合や、データ・ポンプAPIがデータ・ポンプ・ジョブと通信できない場合、もしくはDBMS_DATAPUMP.STOP_JOBプロシージャが実行された場合は、暗黙的に切断されることがあります。

「未実行」状態は、実行中のジョブのコンテキストの外部にマスター表が存在することを示します。この状態は、(後で再開するために)ジョブが停止された場合またはジョブが異常終了した場合に発生します。また、この状態は、ジョブの開始時に行われるジョブの状態の移行中、およびマスター表を削除する前に行うジョブの終了時に、一時的に発生する場合があります。「未実行」状態は、DBA_DATAPUMP_JOBSビューおよびUSER_DATAPUMP_JOBSビューでのみ表示されます。GET_STATUSプロシージャから返されることはありません。

表6-1に、DBMS_DATAPUMPプロシージャを実行できる有効なジョブの状態を示します。この表に示す状態は、特に指定がないかぎり、エクスポートとインポートの両方で有効です。

表6-1 DBMS_DATAPUMPプロシージャを実行できる有効なジョブの状態

プロシージャ名

有効な状態

説明

ADD_FILE

定義中(エクスポート・ジョブとインポート・ジョブの両方で有効)

実行中、アイドル(エクスポート・ジョブでダンプ・ファイルを指定する場合にのみ有効)

ダンプ・ファイル・セット、ログ・ファイルまたはSQLFILEの出力用のファイルを指定する。

ATTACH

定義中、実行中、アイドル、停止、完了、完了処理中、未実行

ユーザー・セッションで、ジョブの監視または停止したジョブの再開を可能にする。ジョブのダンプ・ファイル・セットまたはマスター表が削除または変更されている場合、接続操作は失敗します。

DATA_FILTER

定義中

ジョブが処理するデータを制限する。

DETACH

すべて

ユーザー・セッションをジョブから切断する。

GET_DUMPFILE_INFO

すべて

ダンプ・ファイルのヘッダー情報を取得する。

GET_STATUS

完了、未実行、停止および未定義を除くすべての状態

ジョブの状態を取得する。

LOG_ENTRY

定義中、実行中、アイドル、停止保留、完了処理中

ログ・ファイルにエントリを追加する。

METADATA_FILTER

定義中

ジョブが処理するメタデータを制限する。

METADATA_REMAP

定義中

ジョブが処理するメタデータを再マップする。

METADATA_TRANSFORM

定義中

ジョブが処理するメタデータを変更する。

OPEN

未定義

新しいジョブを作成する。

SET_PARALLEL

定義中、実行中、アイドル

ジョブの並列度を指定する。

SET_PARAMETER

定義中脚注1

ジョブのデフォルトの処理を変更する。

START_JOB

定義中、アイドル

ジョブを開始または再開する。

STOP_JOB

定義中、実行中、アイドル、停止保留

ジョブの停止を開始する。

WAIT_FOR_JOB

完了、未実行、停止および未定義を除くすべての状態

ジョブの終了を待機する。

脚注1

ENCRYPTION_PASSWORDパラメータは、アイドル状態および定義中状態のときに入力できます。

データ・ポンプAPIを使用する場合の基本手順

データ・ポンプAPIを使用するには、DBMS_DATAPUMPパッケージで提供されるプロシージャを使用します。次の手順では、データ・ポンプAPIの使用に関連する基本操作を示します。通常操作を行う順序でこれらの手順を示します。

1. DBMS_DATAPUMP.OPENプロシージャを実行して、データ・ポンプ・ジョブとのそのインフラストラクチャを作成します。

2. ジョブで使用するパラメータを定義します。

3. ジョブを開始します。

4. オプションで、ジョブを完了まで監視できます。

5. オプションで、ジョブとの接続を切断し、後で再接続します。

6. オプションで、ジョブを停止します。

7. オプションで、ジョブを再開します。

これらの手順の概要は、次の項で示す使用例で説明します。

関連項目:

DBMS_DATAPUMPパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

データ・ポンプAPIの使用例

この項では、データ・ポンプAPIの使用方法を理解するために有効な例を示します。

- 例6-1

- 例6-2

- 例6-3

- 例6-4

これらの例は、PL/SQLスクリプトの形式で記述します。これらのスクリプトをコピーして実行するには、まず、SQL*Plusを使用して次の操作を実行する必要があります。

- ディレクトリ・オブジェクトを作成し、そのオブジェクトへのREADおよびWRITE権限を付与します。たとえば、権限を持つdmpdirというディレクトリ・オブジェクトを作成するには、次のように行います。userは、ユーザー名に置き換えます。

SQL> CREATE DIRECTORY dmpdir AS '/rdbms/work';
SQL> GRANT READ, WRITE ON DIRECTORY dmpdir TO user;

- EXP_FULL_DATABASEロールおよびIMP_FULL_DATABASEロールを所有していることを確認します。セキュリティ・ドメイン内でユーザー自身に割り当てられているすべてのロールのリストを表示するには、次のように行います。

SQL> SELECT * FROM SESSION_ROLES;

必要なロールが割り当てられていない場合は、システム管理者に連絡してください。

- サーバーの出力がオンになっていない場合はオンにします。次のように行います。

SQL> SET SERVEROUTPUT ON

これを行わなかった場合は、画面に出力が表示されません。この操作は、例を実行するセッションと同じセッションで行う必要があります。この設定は、SQL*Plusを終了すると失われるため、新しいセッションの開始時に再設定する必要があります。(別のユーザー名に接続する場合も、再設定する必要があります。)

例6-1 簡単なスキーマ・エクスポートの実行

次の例のPL/SQLスクリプトは、データ・ポンプAPIを使用してHRスキーマのスキーマ・エクスポートを簡単に実行する方法を示しています。ジョブの作成、開始、監視の方法を示しています。この例の詳細は、スクリプト内のコメントを参照してください。例を簡単にしておくために、APIのコールでの例外は検出されません。ただし、本番環境でエラーが発生した場合は、例外ハンドラを定義してGET_STATUSをコールし、エラー情報の詳細を取得することをお薦めします。

このスクリプトを使用するには、ユーザーSYSTEMとして接続します。

DECLARE
ind NUMBER;              -- Loop index
h1 NUMBER;               -- Data Pump job handle
percent_done NUMBER;     -- Percentage of job complete
job_state VARCHAR2(30);  -- To keep track of job state
le ku$_LogEntry;         -- For WIP and error messages
js ku$_JobStatus;        -- The job status from get_status
jd ku$_JobDesc;          -- The job description from get_status
sts ku$_Status;          -- The status object returned by get_status
BEGIN

-- Create a (user-named) Data Pump job to do a schema export.

h1 := DBMS_DATAPUMP.OPEN('EXPORT','SCHEMA',NULL,'EXAMPLE1','LATEST');

-- Specify a single dump file for the job (using the handle just returned)
-- and a directory object, which must already be defined and accessible
-- to the user running this procedure.

DBMS_DATAPUMP.ADD_FILE(h1,'example1.dmp','DMPDIR');

-- A metadata filter is used to specify the schema that will be exported.

DBMS_DATAPUMP.METADATA_FILTER(h1,'SCHEMA_EXPR','IN (''HR'')');

-- Start the job. An exception will be generated if something is not set up
-- properly.

DBMS_DATAPUMP.START_JOB(h1);

-- The export job should now be running. In the following loop, the job
-- is monitored until it completes. In the meantime, progress information is
-- displayed.

percent_done := 0;
job_state := 'UNDEFINED';
while (job_state != 'COMPLETED') and (job_state != 'STOPPED') loop
dbms_datapump.get_status(h1,
dbms_datapump.ku$_status_job_error +
dbms_datapump.ku$_status_job_status +
dbms_datapump.ku$_status_wip,-1,job_state,sts);
js := sts.job_status;

-- If the percentage done changed, display the new value.

if js.percent_done != percent_done
then
dbms_output.put_line('*** Job percent done = ' ||
to_char(js.percent_done));
percent_done := js.percent_done;
end if;

-- If any work-in-progress (WIP) or error messages were received for the job,
-- display them.

if (bitand(sts.mask,dbms_datapump.ku$_status_wip) != 0)
then
le := sts.wip;
else
if (bitand(sts.mask,dbms_datapump.ku$_status_job_error) != 0)
then
le := sts.error;
else
le := null;
end if;
end if;
if le is not null
then
ind := le.FIRST;
while ind is not null loop
dbms_output.put_line(le(ind).LogText);
ind := le.NEXT(ind);
end loop;
end if;
end loop;

-- Indicate that the job finished and detach from it.

dbms_output.put_line('Job has completed');
dbms_output.put_line('Final job state = ' || job_state);
dbms_datapump.detach(h1);
END;
/

例6-2 ダンプ・ファイルのインポートおよびすべてのスキーマ・オブジェクトの再マップ

この例のスクリプトでは、例6-1(hrスキーマのエクスポート)で作成したダンプ・ファイルをインポートします。すべてのスキーマ・オブジェクトがhrスキーマからblakeスキーマに再マップされます。例を簡単にしておくために、APIのコールでの例外は検出されません。ただし、本番環境でエラーが発生した場合は、例外ハンドラを定義してGET_STATUSをコールし、エラー情報の詳細を取得することをお薦めします。

このスクリプトを使用するには、ユーザーSYSTEMとして接続します。

DECLARE
ind NUMBER;              -- Loop index
h1 NUMBER;               -- Data Pump job handle
percent_done NUMBER;     -- Percentage of job complete
job_state VARCHAR2(30);  -- To keep track of job state
le ku$_LogEntry;         -- For WIP and error messages
js ku$_JobStatus;        -- The job status from get_status
jd ku$_JobDesc;          -- The job description from get_status
sts ku$_Status;          -- The status object returned by get_status
BEGIN

-- Create a (user-named) Data Pump job to do a "full" import (everything
-- in the dump file without filtering).

h1 := DBMS_DATAPUMP.OPEN('IMPORT','FULL',NULL,'EXAMPLE2');

-- Specify the single dump file for the job (using the handle just returned)
-- and directory object, which must already be defined and accessible
-- to the user running this procedure. This is the dump file created by
-- the export operation in the first example.

DBMS_DATAPUMP.ADD_FILE(h1,'example1.dmp','DMPDIR');

-- A metadata remap will map all schema objects from HR to BLAKE.

DBMS_DATAPUMP.METADATA_REMAP(h1,'REMAP_SCHEMA','HR','BLAKE');

-- If a table already exists in the destination schema, skip it (leave
-- the preexisting table alone). This is the default, but it does not hurt
-- to specify it explicitly.

DBMS_DATAPUMP.SET_PARAMETER(h1,'TABLE_EXISTS_ACTION','SKIP');

-- Start the job. An exception is returned if something is not set up properly.

DBMS_DATAPUMP.START_JOB(h1);

-- The import job should now be running. In the following loop, the job is
-- monitored until it completes. In the meantime, progress information is
-- displayed. Note: this is identical to the export example.

percent_done := 0;
job_state := 'UNDEFINED';
while (job_state != 'COMPLETED') and (job_state != 'STOPPED') loop
dbms_datapump.get_status(h1,
dbms_datapump.ku$_status_job_error +
dbms_datapump.ku$_status_job_status +
dbms_datapump.ku$_status_wip,-1,job_state,sts);
js := sts.job_status;

-- If the percentage done changed, display the new value.

if js.percent_done != percent_done
then
dbms_output.put_line('*** Job percent done = ' ||
to_char(js.percent_done));
percent_done := js.percent_done;
end if;

-- If any work-in-progress (WIP) or Error messages were received for the job,
-- display them.

if (bitand(sts.mask,dbms_datapump.ku$_status_wip) != 0)
then
le := sts.wip;
else
if (bitand(sts.mask,dbms_datapump.ku$_status_job_error) != 0)
then
le := sts.error;
else
le := null;
end if;
end if;
if le is not null
then
ind := le.FIRST;
while ind is not null loop
dbms_output.put_line(le(ind).LogText);
ind := le.NEXT(ind);
end loop;
end if;
end loop;

-- Indicate that the job finished and gracefully detach from it.

dbms_output.put_line('Job has completed');
dbms_output.put_line('Final job state = ' || job_state);
dbms_datapump.detach(h1);
END;
/

例6-3 簡単なスキーマ・エクスポート実行中の例外処理機能の使用方法

この例のスクリプトでは、データ・ポンプAPIを使用した簡単なスキーマ・エクスポートを示します。例6-1の延長で、例外処理機能を使用してSUCCESS_WITH_INFOケースを捕捉する方法およびGET_STATUSプロシージャを使用したエラーの詳細を取得する方法を示します。DBMS_DATAPUMP.OPENまたはDBMS_DATAPUMP.ATTACHエラーの例外情報を取得する場合は、DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR情報マスクとNULLジョブ・ハンドルを使用してDBMS_DATAPUMP.GET_STATUSをコールし、エラー情報の詳細を取得できます。

この例を使用するには、ユーザーSYSTEMとして接続します。

DECLARE
ind NUMBER;              -- Loop index
spos NUMBER;             -- String starting position
slen NUMBER;             -- String length for output
h1 NUMBER;               -- Data Pump job handle
percent_done NUMBER;     -- Percentage of job complete
job_state VARCHAR2(30);  -- To keep track of job state
le ku$_LogEntry;         -- For WIP and error messages
js ku$_JobStatus;        -- The job status from get_status
jd ku$_JobDesc;          -- The job description from get_status
sts ku$_Status;          -- The status object returned by get_status
BEGIN

-- Create a (user-named) Data Pump job to do a schema export.

h1 := dbms_datapump.open('EXPORT','SCHEMA',NULL,'EXAMPLE3','LATEST');

-- Specify a single dump file for the job (using the handle just returned)
-- and a directory object, which must already be defined and accessible
-- to the user running this procedure.

dbms_datapump.add_file(h1,'example3.dmp','DMPDIR');

-- A metadata filter is used to specify the schema that will be exported.

dbms_datapump.metadata_filter(h1,'SCHEMA_EXPR','IN (''HR'')');

-- Start the job. An exception will be returned if something is not set up
-- properly.One possible exception that will be handled differently is the
-- success_with_info exception. success_with_info means the job started
-- successfully, but more information is available through get_status about
-- conditions around the start_job that the user might want to be aware of.

begin
dbms_datapump.start_job(h1);
dbms_output.put_line('Data Pump job started successfully');
exception
when others then
if sqlcode = dbms_datapump.success_with_info_num
then
dbms_output.put_line('Data Pump job started with info available:');
dbms_datapump.get_status(h1,
dbms_datapump.ku$_status_job_error,0,
job_state,sts);
if (bitand(sts.mask,dbms_datapump.ku$_status_job_error) != 0)
then
le := sts.error;
if le is not null
then
ind := le.FIRST;
while ind is not null loop
dbms_output.put_line(le(ind).LogText);
ind := le.NEXT(ind);
end loop;
end if;
end if;
else
raise;
end if;
end;

-- The export job should now be running. In the following loop,
-- the job is monitored until it completes. In the meantime, progress information -- is displayed.

percent_done := 0;
job_state := 'UNDEFINED';
while (job_state != 'COMPLETED') and (job_state != 'STOPPED') loop
dbms_datapump.get_status(h1,
dbms_datapump.ku$_status_job_error +
dbms_datapump.ku$_status_job_status +
dbms_datapump.ku$_status_wip,-1,job_state,sts);
js := sts.job_status;

-- If the percentage done changed, display the new value.

if js.percent_done != percent_done
then
dbms_output.put_line('*** Job percent done = ' ||
to_char(js.percent_done));
percent_done := js.percent_done;
end if;

-- Display any work-in-progress (WIP) or error messages that were received for
-- the job.

if (bitand(sts.mask,dbms_datapump.ku$_status_wip) != 0)
then
le := sts.wip;
else
if (bitand(sts.mask,dbms_datapump.ku$_status_job_error) != 0)
then
le := sts.error;
else
le := null;
end if;
end if;
if le is not null
then
ind := le.FIRST;
while ind is not null loop
dbms_output.put_line(le(ind).LogText);
ind := le.NEXT(ind);
end loop;
end if;
end loop;

-- Indicate that the job finished and detach from it.

dbms_output.put_line('Job has completed');
dbms_output.put_line('Final job state = ' || job_state);
dbms_datapump.detach(h1);

-- Any exceptions that propagated to this point will be captured. The
-- details will be retrieved from get_status and displayed.

exception
when others then
dbms_output.put_line('Exception in Data Pump job');
dbms_datapump.get_status(h1,dbms_datapump.ku$_status_job_error,0,
job_state,sts);
if (bitand(sts.mask,dbms_datapump.ku$_status_job_error) != 0)
then
le := sts.error;
if le is not null
then
ind := le.FIRST;
while ind is not null loop
spos := 1;
slen := length(le(ind).LogText);
if slen > 255
then
slen := 255;
end if;
while slen > 0 loop
dbms_output.put_line(substr(le(ind).LogText,spos,slen));
spos := spos + 255;
slen := length(le(ind).LogText) + 1 - spos;
end loop;
ind := le.NEXT(ind);
end loop;
end if;
end if;
END;
/

例6-4 ダンプ・ファイルの情報の表示

この例のPL/SQLスクリプトは、データ・ポンプAPIプロシージャDBMS_DATAPUMP.GET_DUMPFILE_INFOを使用して、データ・ポンプ・ジョブのコンテキストの外部でデータ・ポンプ・ダンプ・ファイルに関する情報を表示する方法を示しています。この例では、例6-1のサンプルPL/SQLスクリプトで作成されたexample1.dmpダンプ・ファイルに含まれる情報を表示しています。

このPL/SQLスクリプトを使用して、オリジナルのエクスポート(expユーティリティ)およびORACLE_DATAPUMP外部表アクセス・ドライバで作成されたダンプ・ファイルの情報を表示することもできます。

このスクリプトを使用するには、ユーザーSYSTEMとして接続します。

SET VERIFY OFF
SET FEEDBACK OFF

DECLARE
ind        NUMBER;
fileType   NUMBER;
value      VARCHAR2(2048);
infoTab    KU$_DUMPFILE_INFO := KU$_DUMPFILE_INFO();

BEGIN
--
-- Get the information about the dump file into the infoTab.
--
BEGIN
DBMS_DATAPUMP.GET_DUMPFILE_INFO('example1.dmp','DMPDIR',infoTab,fileType);
DBMS_OUTPUT.PUT_LINE('---------------------------------------------');
DBMS_OUTPUT.PUT_LINE('Information for file: example1.dmp');

--
-- Determine what type of file is being looked at.
--
CASE fileType
WHEN 1 THEN
DBMS_OUTPUT.PUT_LINE('example1.dmp is a Data Pump dump file');
WHEN 2 THEN
DBMS_OUTPUT.PUT_LINE('example1.dmp is an Original Export dump file');
WHEN 3 THEN
DBMS_OUTPUT.PUT_LINE('example1.dmp is an External Table dump file');
ELSE
DBMS_OUTPUT.PUT_LINE('example1.dmp is not a dump file');
DBMS_OUTPUT.PUT_LINE('---------------------------------------------');
END CASE;

EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('---------------------------------------------');
DBMS_OUTPUT.PUT_LINE('Error retrieving information for file: ' ||
'example1.dmp');
DBMS_OUTPUT.PUT_LINE(SQLERRM);
DBMS_OUTPUT.PUT_LINE('---------------------------------------------');
fileType := 0;
END;

--
-- If a valid file type was returned, then loop through the infoTab and
-- display each item code and value returned.
--
IF fileType > 0
THEN
DBMS_OUTPUT.PUT_LINE('The information table has ' ||
TO_CHAR(infoTab.COUNT) || ' entries');
DBMS_OUTPUT.PUT_LINE('---------------------------------------------');

ind := infoTab.FIRST;
WHILE ind IS NOT NULL
LOOP
--
-- The following item codes return boolean values in the form
-- of a '1' or a '0'. Display them as 'Yes' or 'No'.
--
value := NVL(infoTab(ind).value, 'NULL');
IF infoTab(ind).item_code IN
(DBMS_DATAPUMP.KU$_DFHDR_MASTER_PRESENT,
DBMS_DATAPUMP.KU$_DFHDR_DIRPATH,
DBMS_DATAPUMP.KU$_DFHDR_METADATA_COMPRESSED,
DBMS_DATAPUMP.KU$_DFHDR_DATA_COMPRESSED,
DBMS_DATAPUMP.KU$_DFHDR_METADATA_ENCRYPTED,
DBMS_DATAPUMP.KU$_DFHDR_DATA_ENCRYPTED,
DBMS_DATAPUMP.KU$_DFHDR_COLUMNS_ENCRYPTED)
THEN
CASE value
WHEN '1' THEN value := 'Yes';
WHEN '0' THEN value := 'No';
END CASE;
END IF;

--
-- Display each item code with an appropriate name followed by
-- its value.
--
CASE infoTab(ind).item_code
--
-- The following item codes have been available since Oracle
-- Database 10g, Release 10.2.
--
WHEN DBMS_DATAPUMP.KU$_DFHDR_FILE_VERSION   THEN
DBMS_OUTPUT.PUT_LINE('Dump File Version:         ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_MASTER_PRESENT THEN
DBMS_OUTPUT.PUT_LINE('Master Table Present:      ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_GUID THEN
DBMS_OUTPUT.PUT_LINE('Job Guid:                  ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_FILE_NUMBER THEN
DBMS_OUTPUT.PUT_LINE('Dump File Number:          ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_CHARSET_ID  THEN
DBMS_OUTPUT.PUT_LINE('Character Set ID:          ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_CREATION_DATE THEN
DBMS_OUTPUT.PUT_LINE('Creation Date:             ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_FLAGS THEN
DBMS_OUTPUT.PUT_LINE('Internal Dump Flags:       ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_JOB_NAME THEN
DBMS_OUTPUT.PUT_LINE('Job Name:                  ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_PLATFORM THEN
DBMS_OUTPUT.PUT_LINE('Platform Name:             ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_INSTANCE THEN
DBMS_OUTPUT.PUT_LINE('Instance Name:             ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_LANGUAGE THEN
DBMS_OUTPUT.PUT_LINE('Language Name:             ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_BLOCKSIZE THEN
DBMS_OUTPUT.PUT_LINE('Dump File Block Size:      ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_DIRPATH THEN
DBMS_OUTPUT.PUT_LINE('Direct Path Mode:          ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_METADATA_COMPRESSED THEN
DBMS_OUTPUT.PUT_LINE('Metadata Compressed:       ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_DB_VERSION THEN
DBMS_OUTPUT.PUT_LINE('Database Version:          ' || value);

--
-- The following item codes were introduced in Oracle Database 11g
-- Release 11.1
--

WHEN DBMS_DATAPUMP.KU$_DFHDR_MASTER_PIECE_COUNT THEN
DBMS_OUTPUT.PUT_LINE('Master Table Piece Count:  ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_MASTER_PIECE_NUMBER THEN
DBMS_OUTPUT.PUT_LINE('Master Table Piece Number: ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_DATA_COMPRESSED THEN
DBMS_OUTPUT.PUT_LINE('Table Data Compressed:     ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_METADATA_ENCRYPTED THEN
DBMS_OUTPUT.PUT_LINE('Metadata Encrypted:        ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_DATA_ENCRYPTED THEN
DBMS_OUTPUT.PUT_LINE('Table Data Encrypted:      ' || value);
WHEN DBMS_DATAPUMP.KU$_DFHDR_COLUMNS_ENCRYPTED THEN
DBMS_OUTPUT.PUT_LINE('TDE Columns Encrypted:     ' || value);

--
-- For the DBMS_DATAPUMP.KU$_DFHDR_ENCRYPTION_MODE item code a
-- numeric value is returned. So examine that numeric value
-- and display an appropriate name value for it.
--
WHEN DBMS_DATAPUMP.KU$_DFHDR_ENCRYPTION_MODE THEN
CASE TO_NUMBER(value)
WHEN DBMS_DATAPUMP.KU$_DFHDR_ENCMODE_NONE THEN
DBMS_OUTPUT.PUT_LINE('Encryption Mode:           None');
WHEN DBMS_DATAPUMP.KU$_DFHDR_ENCMODE_PASSWORD THEN
DBMS_OUTPUT.PUT_LINE('Encryption Mode:           Password');
WHEN DBMS_DATAPUMP.KU$_DFHDR_ENCMODE_DUAL THEN
DBMS_OUTPUT.PUT_LINE('Encryption Mode:           Dual');
WHEN DBMS_DATAPUMP.KU$_DFHDR_ENCMODE_TRANS THEN
DBMS_OUTPUT.PUT_LINE('Encryption Mode:           Transparent');
END CASE;

--
-- The following item codes were introduced in Oracle Database 12c
-- Release 12.1
--

--
-- For the DBMS_DATAPUMP.KU$_DFHDR_COMPRESSION_ALG item code a
-- numeric value is returned. So examine that numeric value and
-- display an appropriate name value for it.
--
WHEN DBMS_DATAPUMP.KU$_DFHDR_COMPRESSION_ALG THEN
CASE TO_NUMBER(value)
WHEN DBMS_DATAPUMP.KU$_DFHDR_CMPALG_NONE THEN
DBMS_OUTPUT.PUT_LINE('Compression Algorithm:     None');
WHEN DBMS_DATAPUMP.KU$_DFHDR_CMPALG_BASIC THEN
DBMS_OUTPUT.PUT_LINE('Compression Algorithm:     Basic');
WHEN DBMS_DATAPUMP.KU$_DFHDR_CMPALG_LOW THEN
DBMS_OUTPUT.PUT_LINE('Compression Algorithm:     Low');
WHEN DBMS_DATAPUMP.KU$_DFHDR_CMPALG_MEDIUM THEN
DBMS_OUTPUT.PUT_LINE('Compression Algorithm:     Medium');
WHEN DBMS_DATAPUMP.KU$_DFHDR_CMPALG_HIGH THEN
DBMS_OUTPUT.PUT_LINE('Compression Algorithm:     High');
END CASE;
ELSE NULL;  -- Ignore other, unrecognized dump file attributes.
END CASE;
ind := infoTab.NEXT(ind);
END LOOP;
END IF;
END;
/

第II部 SQL*Loader

次の項目では、SQL*Loaderユーティリティについて説明します。

SQL*Loaderの概念

ここでは、SQL*Loaderおよびその機能の説明に加え、データ・ロードの概念についても説明します(オブジェクト・サポートも含む)。さらに、SQL*Loaderへの入力、データベースの事前準備およびSQL*Loaderからの出力についても説明します。

SQL*Loaderコマンドライン・リファレンス

ここでは、SQL*Loaderで使用するコマンドラインの構文について説明します。コマンドライン引数、SQL*Loaderのメッセージを抑制する方法、バインド配列のサイズ指定などについて説明します。

SQL*Loader制御ファイル・リファレンス

ここでは、SQL*Loaderの設定に使用する制御ファイルの構文、およびデータをOracleの形式にマップする方法をSQL*Loaderに記述する方法について説明します。詳細な構文図を示すとともに、データ・ファイル、表と列、データの位置、ロードするデータの型と形式などの指定に関する情報についても説明します。

SQL*Loaderフィールド・リスト・リファレンス

ここでは、SQL*Loader制御ファイルのフィールド・リストのセクションについて説明します。フィールド・リストには、位置、データ型、条件、デリミタなど、ロードするフィールドの情報が提供されます。

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

ここでは、様々な形式での列オブジェクトのロード方法について説明します。オブジェクト表、REF列、LOBおよびコレクションのロード方法についても説明します。

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

ここでは、従来型パス・ロードとダイレクト・パス・ロードの違いを説明します。ダイレクト・パス・ロードは、大量のデータを従来より高速にロードするための高パフォーマンス・オプションです。

SQL*Loaderエクスプレス

ここでは、単純なデータ型を迅速かつ簡単にロードできるSQL*Loaderエクスプレス・モードについて説明します。

7 SQL*Loaderの概念

SQL*Loaderを使用してOracleデータベースにデータをロードする前に、次の基本概念を理解する必要があります。

- SQL*Loaderの機能

- SQL*Loaderのパラメータ

- SQL*Loader制御ファイル

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

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

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

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

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

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

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

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

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

- SQL*Loaderの事例

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、ログ・ファイル、不良ファイル(拒否されたレコードが存在する場合)で、廃棄ファイルに出力される場合もあります。

図7-1に、制御ファイルを使用する標準的なSQL*Loaderセッションのフローの例を示します。

図7-1 SQL*Loaderの概要

SQL*Loaderのパラメータ

SQL*Loaderは、sqlldrコマンドを指定すると起動しますが、オプションで、ロード操作の様々な特性を確立するパラメータを指定した場合も起動します。

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

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

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

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

関連項目:

- SQL*Loaderのパラメータの詳細は、「SQL*Loaderコマンドライン・リファレンス」を参照してください

- 「PARFILE」

- 「OPTIONS句」

SQL*Loader制御ファイル

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

通常、制御ファイルには、次の3つの項目が次の順序で含まれます。

- セッション全体の情報

- 表およびフィールド・リストの情報

- 入力データ(オプションの項目)

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

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

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

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

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

関連項目:

制御ファイルの構文およびセマンティクスの詳細は、「SQL*Loader制御ファイル・リファレンス」を参照してください

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

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

注意:

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

固定レコード形式

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

INFILE datafile_name "fix n"

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

例7-1に、固定レコード形式で解釈されるデータ・ファイル(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,.

可変レコード形式

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

INFILE "datafile_name" "var n"

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

例7-2に、データ・ファイル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,
012..68773,ben,

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

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

例7-3に、terminator_stringが文字列'|\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,|

論理レコード

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

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

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

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

関連項目:

- 「物理レコードからの論理レコードの作成」

- 「事例4: 結合された物理レコードのロード」(事例の使用方法については、「SQL*Loaderの事例」を参照)

データ・フィールド

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

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

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

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

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

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

関連項目:

- 「データ・フィールドの位置指定」

- 「デリミタの指定」

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フィールドを指定します。

関連項目:

- 「LOBFILEからのLOBデータのロード」

- 「セカンダリ・データ・ファイル(SDF)」

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

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

1. SQL*Loaderで、制御ファイルにあるフィールド指定を使用してデータ・ファイルの形式を解釈し、次に、入力データを解析します。そのデータを使用してSQL INSERT文に対応するバインド配列を移入します。バインド配列は、SQL*Loaderがロード対象のデータを格納するメモリー内の領域です。バインド配列が一杯の場合、データはデータベースに転送されます。バインド配列のサイズは、SQL*LoaderのBINDSIZEおよびREADSIZEパラメータによって制御されます。

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

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

関連項目:

- 「BINDSIZE」

- 「READSIZE」

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

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

不良ファイル

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

SQL*Loaderによって拒否されたレコード

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

SQL*Loaderの操作中にOracle Databaseによって拒否されたレコード

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

関連項目:

- 「不良ファイルの指定」

- 「事例4: 結合された物理レコードのロード」(事例の使用方法については、「SQL*Loaderの事例」を参照)

廃棄ファイル

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

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

関連項目:

- 「事例4: 結合された物理レコードのロード」(事例の使用方法については、「SQL*Loaderの事例」を参照)

- 「廃棄ファイルの指定」

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

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ファンクションを使用することによってロードされるデータを変更できます。

注意:

Windowsオペレーティング・システムでの名前付きパイプを使用した外部表ロードは、サポートされません。

関連項目:

- ORACLE_LOADERアクセス・ドライバ

- ORACLE_DATAPUMPアクセス・ドライバ

- 外部表の作成と管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

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

外部表とSQL*Loaderのレコード解析は類似しているため、通常、同じレコード形式での大幅なパフォーマンスの違いはありません。ただし、外部表と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)の使用

バイト順マーク(BOM)

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

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

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

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

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

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

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

TERMINATED BY ',' ENCLOSED BY "'"

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

オブジェクト、コレクションおよびLOBをバルク・ロードするためにSQL*Loaderを使用できます。

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

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

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

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

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

- 非パーティション表

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

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

SQL*Loaderの事例

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

注意:

事例に使用するファイルは、$ORACLE_HOME/rdbms/demoディレクトリにあります。これらのファイルは、Oracle Database 12c 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 12c 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表の各行の内容が表示されます。

8 SQL*Loaderコマンドライン・リファレンス

次の項目で説明するように、コマンドライン・パラメータを使用してSQL*Loaderを起動します。

- SQL*Loaderの起動

- SQL*Loaderのコマンドライン・パラメータ

- 終了コードによる結果の検査と表示

注意:

通常のSQL*LoaderとSQL*Loaderエクスプレス・モードでは、同じパラメータをいくつか共有していますが、その動作は異なる場合があります。この章のパラメータの説明は、通常のSQL*Loaderを対象としています。SQL*Loaderエクスプレス・モードのパラメータは、「SQL*Loaderエクスプレス」を参照してください。

SQL*Loaderの起動

この項では、SQL*Loaderの起動方法とパラメータの指定方法について説明します。内容は次のとおりです。

- コマンドラインでのパラメータの指定

- SQL*Loaderのパラメータ指定の代替方法

- ネットワークを介してデータをロードするためのSQL*Loaderの使用

SQL*Loaderのすべてのパラメータと、簡単な説明およびそれぞれのデフォルト値をリストしたヘルプ画面を表示するには、プロンプトでsqlldrと入力して[Enter]を押します。

コマンドラインでのパラメータの指定

SQL*Loaderを起動する際に、ロード操作の様々な特性を確立するためにパラメータを指定します。パラメータはカンマで区切ることができます。

> sqlldr CONTROL=ulcase1.ctl
Username: scott
Password: password

位置で指定するとは、パラメータ名は入力せずに、値を入力するということです。次の例では、ユーザー名scottが指定され、その後にulcase1.ctlという制御ファイルの名前が指定されています。パスワードを入力するように要求されます。

> sqlldr scott ulcase1.ctl
Password: password

パラメータ名を一度使用したら、後続のすべての指定でパラメータ名を入力する必要があります。位置で指定することはできなくなります。たとえば、次のコマンドでは、CONTROLパラメータを使用して制御ファイル名を指定していますが、ログ・ファイル名はLOGパラメータなしで指定しています。この場合、ulcase1.logの位置が正しくても、エラーが発生します。

> sqlldr scott CONTROL=ulcase1.ctl ulcase1.log

かわりに、次のように入力する必要があります。

> sqlldr scott CONTROL=ulcase1.ctl LOG=ulcase1.log

関連項目:

すべてのコマンドライン・パラメータの詳細は、「SQL*Loaderのコマンドライン・パラメータ」を参照してください

SQL*Loaderのパラメータ指定の代替方法

コマンドラインの長さが、システムの行の最大サイズを超える場合は、OPTIONS句を使用して、一部のコマンドライン・パラメータを制御ファイルに格納できます。

また、パラメータをパラメータ・ファイルとしてグループ化することもできます。このファイルの名前は、SQL*Loaderの起動時に、PARFILEパラメータを使用してコマンドラインで指定できます。

パラメータ指定のこれらの代替方法は、同じパラメータを同じ値で繰り返し使用する場合に有効です。

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

関連項目:

- 「OPTIONS句」

- 「PARFILE」

ネットワークを介してデータをロードするためのSQL*Loaderの使用

ネットワーク接続を介してデータをロードするためにSQL*Loaderを使用するには、SQL*Loaderユーティリティの起動時に、接続文字列に接続識別子を指定します。この識別子では、現在のユーザーのORACLE_SID環境変数の設定によって指定した現行のインスタンスとは別のデータベース・インスタンスを指定できます。接続識別子には、Oracle Net接続記述子または接続記述子にマップするネット・サービス名(通常、tnsnames.oraファイルで定義される)を指定できます。接続識別子を使用するには、Oracle Net Listenerが実行中であることが必要です(デフォルト・リスナーを起動するには、lsnrctl startと入力します)。次に、ユーザーscottがinst1という接続識別子を使用してSQL*Loaderを起動する例を示します。

> sqlldr CONTROL=ulcase1.ctl
Username: scott@inst1
Password: password

ローカルSQL*Loaderクライアントは接続識別子inst1(ネット・サービス名)によって定義されるデータベース・インスタンスに接続し、ulcase1.ctl制御ファイルの指定に従ってデータをロードします。

注意:

プラガブル・データベース(PDB)にデータをロードするには、SQL*Loaderの起動時に、単純に接続文字列に接続識別子を指定します。

関連項目:

- 接続識別子およびOracle Net Listenerの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- PDBの詳細は、『Oracle Database概要』を参照してください。

SQL*Loaderのコマンドライン・パラメータ

この項では、SQL*Loaderの各コマンドライン・パラメータについて説明します。ここで使用されているコマンドライン・パラメータのデフォルト値および最大値は、UNIXベースのシステムでの値です。これらの値はオペレーティング・システムによって異なります。詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

BAD

デフォルト: .bad拡張子が付いたデータ・ファイルの名前

用途

最初のデータ・ファイルの指定に関連する不良ファイルの名前または場所(あるいはその両方)を指定します。

構文および説明

BAD=[directory/][filename]

不良ファイルには、挿入時にエラーの原因になったレコードや、不適切に書式化されたレコードが格納されます。BADパラメータを指定する場合、ディレクトリまたはファイル名(あるいはその両方)を指定する必要があります。拒否されたレコードがあり、不良ファイルに名前を指定しなかった場合は、デフォルトで、データ・ファイル名に拡張子(またはファイル・タイプ).badを付けたものがファイル名になります。

directoryパラメータには、不良ファイルの書込み先となるディレクトリを指定します。指定には、デバイスまたはネットワーク・ノードの名前を含めることができます。directoryの値は、次のように決定されます。

- BADパラメータが指定されておらず、不良ファイルが必要な場合、デフォルト・ディレクトリは、SQL*Loaderの制御ファイルが存在するディレクトリになります。

- BADパラメータでファイル名が指定されているが、ディレクトリがない場合、ディレクトリはデフォルトでカレント・ディレクトリになります。

- BADパラメータでディレクトリが指定されているが、ファイル名がない場合、指定されたディレクトリが使用され、不良ファイルの名前と拡張子にはデフォルトが使用されます。

filenameパラメータには、プラットフォームで有効とみなされるファイル名を指定します。名前(および.bad以外のものを使用する場合は拡張子)のみを指定する必要があります。ファイル名に空白やその他の句読点文字が含まれている場合は、一重引用符で囲む必要があります。

コマンドラインで指定された不良ファイルは、制御ファイルの最初のINFILE文(存在する場合)に関連する不良ファイルとなります。不良ファイルの名前は、BADFILE句を使用して、SQL*Loaderの制御ファイル内に指定することもできます。不良ファイル名をコマンドラインと制御ファイルに指定した場合は、コマンドラインの値が使用されます。生成される不良ファイルと同じ名前のファイルがすでに存在する場合は、使用するオペレーティング・システムに応じて、既存ファイルが上書きされるか、新しいバージョンのファイルが生成されます。

関連項目:

不良ファイルの形式の詳細は、「不良ファイルの指定」を参照してください

例

次の指定では、カレント・ディレクトリにemp1.badという不良ファイルを作成します。

BAD=emp1

BINDSIZE

デフォルト: 256000

用途

BINDSIZEパラメータでは、バインド配列の最大サイズ(バイト単位)を指定します。

構文および説明

BINDSIZE=n

バインド配列は、SQL*Loaderがロード対象のデータを格納するメモリー内の領域です。バインド配列が一杯の場合、データはデータベースに転送されます。バインド配列のサイズは、BINDSIZEおよびREADSIZEパラメータによって制御されます。

BINDSIZEで指定されたバインド配列サイズは、デフォルト・サイズ(システムによって異なる)およびROWSに基づいて計算されたサイズよりも優先されます。

関連項目:

- 「バインド配列および従来型パス・ロード」

- 「READSIZE」

- 「ROWS」

制限事項

- BINDSIZEパラメータは、従来型パス・ロードでのみ使用します。

例

次のBINDSIZEの指定では、バインド配列の最大サイズを356,000バイトに制限します。

BINDSIZE=356000

COLUMNARRAYROWS

デフォルト: 5000

用途

COLUMNARRAYROWSパラメータでは、行数を指定してダイレクト・パス列配列に割り当てます。

関連項目:

- 「CONCATENATEを使用した論理レコードの作成」

- 「列配列の行数およびストリーム・バッファ・サイズの指定」

構文および説明

COLUMNARRARYROWS=n

このパラメータの値は、SQL*Loaderでは計算されません。値を指定するか、またはデフォルトを使用する必要があります。

例

次の例では、ダイレクト・パス列配列に1000行を割り当てるように指定します。

COLUMNARRAYROWS=1000

CONTROL

デフォルト: デフォルト値は設定されていません。

用途

CONTROLパラメータは、データのロード方法を記述するSQL*Loader制御ファイルの名前を指定します。

構文および説明

CONTROL=control_file_name

ファイルの拡張子またはファイル・タイプを指定していない場合は、デフォルトで.ctlになります。CONTROLパラメータを指定しない場合、SQL*Loaderによってその入力を要求されます。

SQL*Loader制御ファイル名に特殊文字が含まれている場合、オペレーティング・システムによっては、その文字をエスケープする必要があります。また、オペレーティング・システム上でファイル・システム・パスの中にバックスラッシュが使用されている場合は、複数のエスケープ文字を使用するか、または引用符でパスを囲む必要があります。詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

関連項目:

SQL*Loader制御ファイルの詳細は、「SQL*Loader制御ファイル・リファレンス」を参照してください

例

次の例では、emp1という制御ファイルを指定します。これには、自動的にデフォルトの拡張子である.ctlが付けられます。

CONTROL=emp1

DATA

デフォルト: 制御ファイルと同じ名前ですが、拡張子は.datになります。

用途

DATAパラメータでは、ロードするデータが含まれるデータ・ファイルの名前を指定します。

構文および説明

DATA=data_file_name

ファイル拡張子を指定しない場合、デフォルトで.datになります。

ファイルの指定にはワイルド・カード(ファイル名およびファイル拡張子にのみ可能で、デバイスまたはディレクトリ名には不可)を含めることができます。アスタリスク(*)は複数文字を表し、疑問符(?)は1文字を表します。次に例を示します。

DATA='emp*.dat'

DATA='m?emp.dat'

複数のデータ・ファイルの指定(それぞれにワイルド・カードを含めることが可能)をリストするには、ファイル名をカンマで区切る必要があります。

ファイル名に任意の特殊文字(空白、*、?など)が含まれる場合、名前全体を一重引用符で囲む必要があります。

次に、DATAパラメータの有効な3つの使用例を示します(ファイル名に特殊文字が含まれる場合のみ、一重引用符が必要です)。

DATA='file1','file2','file3','file4','file5','file6'

DATA='file1','file2'
DATA='file3,'file4','file5'
DATA='file6'

DATA='file1'
DATA='file2'
DATA='file3'
DATA='file4'
DATA='file5'
DATA='file6'

注意:

複数のデータ・ファイルがロードされる状況でBADパラメータも指定する場合、ファイル名ではなく、不良ファイルのディレクトリのみを指定することをお薦めします。指定した名前を持つファイルがすでに存在する場合、使用しているオペレーティング・システムに応じて、既存ファイルが上書きされるか、新しいバージョンのファイルが生成されます。

コマンドラインでDATAパラメータを使用してデータ・ファイルを指定し、同時に制御ファイルでINFILE句を使用してデータ・ファイルを指定すると、制御ファイルの最初のINFILEの指定は無視されます。コマンドラインと制御ファイル内で指定された他のすべてのデータ・ファイルは処理されます。

DATAパラメータと一緒にファイル処理オプションを指定すると、制御ファイルからのデータのロード時に、警告メッセージが発行されます。

例

次の例では、employees.datというデータ・ファイルをロードするように指定します。拡張子が指定されていないため、.dat拡張子がデフォルトとみなされます。

DATA=employees

DATA_CACHE

デフォルト: 使用可能(1000要素)。データ・キャッシュ機能を完全に使用禁止にするには、0(ゼロ)に設定します。

用途

DATA_CACHEパラメータは、データ・キャッシュ・サイズ(エントリ数)を指定します。データ・キャッシュは、テキスト文字列から内部の日付書式への変換結果を格納するために使用されます。このキャッシュが有効なのは、テキスト形式から日付書式に変換する場合と比べて、日付の検索コストが非常に低くなるためです。日付ファイルに同じ日付が繰り返して存在する場合は、データ・キャッシュを使用することで、ダイレクト・パス・ロードの速度を向上できます。

構文および説明

DATA_CACHE=n

必要に応じて、すべての表に固有のデータ・キャッシュが作成されます。データ・キャッシュは、表への格納のためにデータ型変換が必要な日付値またはタイムスタンプ値が1つ以上ロードされた場合にのみ作成されます。

データ・キャッシュ機能は、デフォルトで使用可能です。デフォルトのデータ・キャッシュ・サイズは1000要素です。デフォルトのサイズを使用し、1000を超える一意の入力値をロードすると、データ・キャッシュ機能は、この表に対して自動的に使用禁止となります。ただし、デフォルトを変更して0以外のデータ・キャッシュ・サイズを指定し、キャッシュ量がこのサイズを超えた場合、キャッシュは使用禁止になりません。

ログ・ファイルに含まれているデータ・キャッシュ統計(エントリ数、ヒット数、ミス数)を使用して、将来、同様のロードを行うときのためにキャッシュのサイズを調整できます。

関連項目:

「データ・キャッシュの値の指定」

制限事項

- データ・キャッシュ機能は、ダイレクト・パス・ロードと外部表ロードでのみ使用できます。

例

次の指定では、データ・キャッシュ機能を完全に使用禁止にします。

DATA_CACHE=0

DEGREE_OF_PARALLELISM

デフォルト: NONE

用途

DEGREE_OF_PARALLELISMパラメータでは、ロード操作中に使用する並列度を指定します。

構文および説明

DEGREE_OF_PARALLELISM=[degree-num|DEFAULT|AUTO|NONE]

degree-numを指定する場合、1からnの整数値にする必要があります。

DEFAULTを指定すると、(AUTOのデフォルト・パラメータ値ではなく)データベースのデフォルトの並列度が使用されます。

AUTOを使用すると、Oracle Databaseによってロードの並列度が自動的に設定されます。

NONEを指定すると、ロードはパラレルに実行されません。

関連項目:

- パラレル実行の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

制限事項

- DEGREE_OF_PARALLELISMパラメータは、外部表ロード方法が使用される場合にのみ有効です。

例

次の例では、ロードの並列度を3に設定します。

DEGREE_OF_PARALLELISM=3

DIRECT

デフォルト: FALSE

用途

DIRECTパラメータでは、従来型パスまたはダイレクト・パスのどちらのロード方法を使用するかを指定します。

構文および説明

DIRECT=[TRUE | FALSE]

TRUE値はダイレクト・パス・ロードを指定します。FALSE値は従来型パス・ロードを指定します。

関連項目:

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

例

次の例では、従来型パス・モードを使用してロードを実行するように指定します。

DIRECT=FALSE

DISCARD

デフォルト: データ・ファイルと同じファイル名ですが、拡張子は.dscになります。

用途

DISCARDパラメータでは、表に挿入されず、拒否もされないレコードを格納するための廃棄ファイルをオプションで指定できます。これらは不良レコードではなく、制御ファイル内で指定されているWHEN句などのレコード選択基準に単純に一致しなかったレコードです。

構文および説明

DISCARD=[directory/][filename]

DISCARDパラメータを指定する場合、ディレクトリまたはファイル名(あるいはその両方)を指定する必要があります。

directoryパラメータには、廃棄ファイルの書込み先となるディレクトリを指定します。指定には、デバイスまたはネットワーク・ノードの名前を含めることができます。directoryの値は、次のように決定されます。

- DISCARDパラメータが指定されていないが、DISCARDMAXパラメータは指定されている場合、デフォルト・ディレクトリは、SQL*Loaderの制御ファイルが存在するディレクトリになります。

- DISCARDパラメータでファイル名が指定されているが、ディレクトリがない場合、ディレクトリはデフォルトでカレント・ディレクトリになります。

- DISCARDパラメータでディレクトリが指定されているが、ファイル名がない場合、指定されたディレクトリが使用され、名前と拡張子にはデフォルトが使用されます。

filenameパラメータには、プラットフォームで有効とみなされるファイル名を指定します。名前(および.dsc以外のものを使用する場合は拡張子)のみを指定する必要があります。ファイル名に空白やその他の句読点文字が含まれている場合は、一重引用符で囲む必要があります。

DISCARDパラメータもDISCARDMAXパラメータも指定しない場合、廃棄レコードがあっても廃棄ファイルは作成されません。

DISCARDパラメータが指定されていないが、DISCARDMAXパラメータは指定されている場合に廃棄レコードが存在すると、デフォルト名を使用して廃棄ファイルが作成され、ファイルはSQL*Loaderの制御ファイルが存在する場所と同じディレクトリに書き込まれます。

注意:

複数のデータ・ファイルがロードされる状況でDISCARDパラメータも指定する場合、ファイル名ではなく、廃棄ファイルのディレクトリのみを指定することをお薦めします。指定した名前を持つファイルがすでに存在する場合、使用しているオペレーティング・システムに応じて、既存ファイルが上書きされるか、新しいバージョンのファイルが生成されます。

コマンドラインで指定された廃棄ファイルは、制御ファイルの最初のINFILE文(存在する場合)に関連する廃棄ファイルとなります。つまり、制御ファイル中で指定する廃棄ファイル名よりも、コマンドラインで指定した廃棄ファイル名の方が優先されます。生成される廃棄ファイルと同じ名前のファイルがすでに存在する場合は、既存ファイルが上書きされるか、新しいバージョンのファイルが生成されます。どちらの処理が行われるかは、使用するオペレーティング・システムによって異なります。

関連項目:

廃棄ファイルの形式の詳細は、「廃棄レコードおよび拒否レコード」を参照してください

例

employees.datというデータ・ファイルをロードすることを前提としています。次の例では、ディレクトリ名のみを指定しているため、廃棄ファイルの名前はemployees.dscになり、mydirディレクトリに作成されます。

DISCARD=mydir/

DISCARDMAX

デフォルト: ALL

用途

DISCARDMAXパラメータは、データ・ロードが終了する前に、許可する廃棄レコードの数を指定します。

構文および説明

DISCARDMAX=n

最初の廃棄レコードで停止するには、値0を指定します。

DISCARDMAXが指定されているが、DISCARDパラメータは指定されていない場合、廃棄ファイルの名前は、拡張子.dscが付けられたデータ・ファイルの名前になります。

例

次の例では、ロードが終了するまでに25個の破棄レコードが許可されます。

DISCARDMAX=25

DNFS_ENABLE

デフォルト: TRUE

用途

DNFS_ENABLEパラメータでは、SQL*Loader操作中の入力データ・ファイルに対するDirect NFSクライアントの使用を有効化および無効化できます。

構文および説明

DNFS_ENABLE=[TRUE|FALSE]

Direct NFSクライアントは、Oracle Databaseがファイル・サーバー上のファイルにアクセスする際のパフォーマンスを向上するために、ファイル・サーバーで実装できるAPIです。

SQL*Loaderでは、1GBを超えるデータ・ファイルを読み取る場合にデフォルトでDirect NFSクライアント・インタフェースが使用されます。よりサイズの小さいファイルでは、オペレーティング・システムのI/Oインタフェースが使用されます。すべての入力データ・ファイルでDirect NFSクライアントを使用するには、DNFS_ENABLE=TRUEを使用します。

すべてのデータ・ファイルでDirect NFSクライアントの使用を無効にするには、DNFS_ENABLE=FALSEを指定します。

DNFS_READBUFFERSパラメータは、Direct NFSクライアントによって使用される読取りバッファの数(デフォルトは4)を指定するために使用できます。

関連項目:

- Direct NFSクライアントの有効化の詳細は、使用しているプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

例

次の例では、ロード中の入力データ・ファイルでのDirect NFSクライアントの使用を無効にします。

DNFS_ENABLE=FALSE

DNFS_READBUFFERS

デフォルト: 4

用途

DNFS_READBUFFERSパラメータでは、Direct NFSクライアントによって使用される読取りバッファの数を制御できます。Direct NFSクライアントは、Oracle Databaseがファイル・サーバー上のファイルにアクセスする際のパフォーマンスを向上するために、ファイル・サーバーで実装できるAPIです。

構文および説明

DNFS_READBUFFERS=n

より大きい値を使用すると、Direct NFSクライアント・ファイル・サーバーからの一貫性のないI/Oに対処できますが、メモリー使用量が増大する可能性があります。

関連項目:

- Direct NFSクライアントの有効化の詳細は、使用しているプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

制限事項

- DNFS_ENABLEパラメータを同時に指定せずにこのパラメータを使用するには、入力ファイルが1GBを超えている必要があります。

例

次の例では、Direct NFSクライアントによって使用される読取りバッファの数を10に指定します。

DNFS_READBUFFERS=10

ERRORS

デフォルト値: 50

用途

ERRORSパラメータでは、許可する挿入エラーの最大数を指定します。

構文および説明

ERRORS=n

発生したエラーの数がERRORSに指定された値を超えると、SQL*Loaderによりロードが中止されます。その前までに挿入されたデータはコミットされます。

エラーを許容しない場合は、ERRORS=0を設定します。エラーを無制限に許容する場合は、非常に大きい値を指定します。

SQL*Loaderでは、すべての表の間でレコードの整合性を保つように処理されます。つまり、複数の表をロードする場合は、エラーの数がこの上限を超えても、すぐにはロード処理が中止されません。SQL*Loaderでは、複数の表のロードに対して許容最大数のエラーが検出されても、行のロードは続行され、すでに表にロードされた有効な行は確実にすべての表にロードされます。また、拒否された行はすべての表から削除されます。

どのような場合でも、SQL*Loaderでは、エラーになったレコードが不良ファイルに書き込まれます。

例

次の例では、ロードの挿入エラーの最大数を25に指定します。それを超えると、ロードは終了します。

ERRORS=25

EXTERNAL_TABLE

デフォルト: NOT_USED

用途

EXTERNAL_TABLEパラメータは、外部表オプションを使用してデータをロードするかどうかをSQL*Loaderに指定します。

構文および説明

EXTERNAL_TABLE=[NOT_USED | GENERATE_ONLY | EXECUTE]

指定可能な値は次のとおりです。

- NOT_USED: デフォルト値。従来型パス・モードまたはダイレクト・パス・モードのいずれかを使用して、ロードを行います。

- GENERATE_ONLY: 制御ファイルに記述されているとおり、SQL*Loaderログ・ファイル内の外部表を使用してロードを行うために必要なすべてのSQL文を書き込みます。これらのSQL文は、編集およびカスタマイズできます。実際のロードは、SQL*Loaderを使用せずに、SQL*Plusでこれらの文を実行して、後で行うことができます。

- EXECUTE: 外部表を使用してロードを行うために必要なSQL文を実行します。ただし、SQL文からエラーが返されると、ロードは停止します。SQL文は、実行されたとおりログ・ファイルに書き込まれます。つまり、SQL文からエラーが返されると、ロードに必要な残りのSQL文はログ・ファイルには書き込まれません。
SQL*Loader制御ファイルでEXTERNAL_TABLE=EXECUTEパラメータとSEQUENCEパラメータの両方を使用すると、SQL*Loaderは、データベースの順序を作成し、その順序に従って表をロードした後、その順序を削除します。この方法でロードを実行すると、従来型またはダイレクト・パスによる方法でロードした場合とは異なる結果になります。(順序の作成方法の詳細は、『Oracle Database SQL言語リファレンス』のCREATE SEQUENCEに関する項を参照してください。)

注意:

EXTERNAL_TABLEパラメータを指定すると、SQL*Loader制御ファイル内の日時データ型(TIMESTAMPなど)は自動的にCHARデータ型に変換されて、外部表のdate_format_spec句が使用されます。詳細は、「date_format_spec」を参照してください。

外部表オプションで、データベース内のディレクトリ・オブジェクトを使用して、すべての入力データ・ファイルがどこに格納されるか、および出力ファイル(不良ファイルや廃棄ファイルなど)がどこで作成されるかを指定します。データ・ファイルを含むディレクトリ・オブジェクトには、READアクセスが、出力ファイルが作成されるディレクトリ・オブジェクトには、WRITEアクセスが必要です。データ・ファイルまたは出力ファイル格納用の既存のディレクトリ・オブジェクトがない場合は、SQL*LoaderでSQL文を生成して作成します。したがって、EXECUTEオプションを指定する場合は、CREATE ANY DIRECTORY権限が必要です。ロード処理の最後にディレクトリ・オブジェクトを削除する場合は、DROP ANY DIRECTORY権限も必要です。

注意:

SQL*LoaderでEXTERNAL_TABLE=EXECUTE修飾子を指定すると、データのロードに使用可能な外部表が作成された後、INSERT文が実行され、データがロードされます。外部表のすべてのファイルがディレクトリ・オブジェクト内に存在すると識別される必要があります。SQL*Loaderは、ユーザーがアクセス権限を所有している既存のディレクトリ・オブジェクトを使用します。ただし、SQL*Loaderにより一致するディレクトリ・オブジェクトが検出されない場合は、一時ディレクトリ・オブジェクトの作成が試行されます。新しいディレクトリ・オブジェクトを作成する権限を所有していない場合、この操作は正常に実行されません。

この問題を解決するには、EXTERNAL_TABLE=GENERATE_ONLYを使用して、SQL*Loaderで実行が試行されるSQL文を作成します。これらのSQL文を抽出し、参照するディレクトリ・オブジェクトを、アクセス権限を所有しているディレクトリ・オブジェクトに変更します。その後、これらのSQL文を実行します。

複数表のロードを行う場合は、SQL*Loaderで次の手順を実行します。

1. 任意の表にロードされる入力データ・ファイルのすべてのフィールドを記述する表を、データベースに作成します。

2. INSERT文を作成して、データの外部表記述からこの表をロードします。

3. 制御ファイルのすべての表にINSERT文を実行します。

実行例については、事例5にEXTERNAL_TABLE=GENERATE_ONLYパラメータを追加して実行します。外部表に一意の名前を保証するため、SQL*Loaderではすべてのフィールド用に生成された名前を使用します。これは、フィールド名が制御ファイル内の異なる表の間で一意でないことがあるためです。

関連項目:

- 事例の使用方法の詳細は、「SQL*Loaderの事例」を参照してください

- 外部表の概要

- ORACLE_LOADERアクセス・ドライバ

制限事項

- SQL*Loaderを介して外部表からデータベース表にデータを挿入する場合、ユリウス日は使用できません。この問題を解決するには、次の例に示すとおり、TO_DATEおよびTO_CHARを使用してユリウス日書式を変換します。

TO_CHAR(TO_DATE(:COL1, 'MM-DD-YYYY'), 'J')

- 外部表からデータベース表にデータを挿入する場合、オブジェクト要素には組込み関数およびSQL文字列は使用できません。

例

EXTERNAL_TABLE=EXECUTE

FILE

デフォルト: デフォルト値は設定されていません。

用途

FILEパラメータでは、エクステントの割当て元となるデータベース・ファイルを指定します。

関連項目:

「パラレル・データ・ロード・モデル」

構文および説明

FILE=tablespace_file

SQL*Loaderの異なるプロセスに対するFILEパラメータの値を変えることによって、データがシステムにロードされるときのディスクの競合を最小限に抑えることができます。

制限事項

- FILEパラメータは、ダイレクト・パスのパラレル・ロードでのみ使用します。

LOAD

デフォルト: すべてのレコードがロードされます。

用途

LOADパラメータでは、ロード対象の最大レコード数を指定します。

構文および説明

LOAD=n

ロードに指定したすべてのパラメータが正しく設定されているかどうかをテストする場合、LOADパラメータを使用して、すべてのレコードをロードするかわりに、かぎられた数のレコードを指定できます。実際のレコード件数が指定された最大数より少ない場合、エラーは発生しません。

例

次の例では、最大10個のレコードをロードするように指定します。

LOAD=10

外部表の方法によるロードでは、ロードに成功したレコードのみが合計に加算されます。そのため、入力データ・ファイルに15個のレコードがあり、レコード2および4が不良の場合、レコード1、3、5、6、7、8、9、10、11および12が合計10個のレコードとして表にロードされます。

従来型パス・ロードとダイレクト・パス・ロードでは、成功と失敗の両方のロード試行が合計に加算されます。そのため、入力データ・ファイルに15個のレコードがあり、レコード2および4が不良の場合、レコード1、3、5、6、7、8、9および10の8個のみが実際に表にロードされます。

LOG

デフォルト: 拡張子が.logの制御ファイル名

用途

LOGパラメータでは、ロード・プロセスに関するログ情報を格納するためにSQL*Loaderが使用するログ・ファイルのディレクトリ・パスまたはファイル名(あるいはその両方)を指定します。

構文および説明

LOG=[[directory/][log_file_name]]

LOGパラメータを指定する場合、ディレクトリ名またはファイル名(あるいはその両方)を指定する必要があります。

ディレクトリ名を指定しない場合、デフォルトでカレント・ディレクトリが使用されます。

ファイル名なしでディレクトリ名を指定した場合、デフォルトのログ・ファイル名が使用されます。

例

次の例では、カレント・ディレクトリにemp1.logというログ・ファイルを作成します。拡張子を指定しない場合でも、デフォルトの.logが使用されます。

LOG=emp1

MULTITHREADING

デフォルト: 複数CPUシステムではTRUEで、単一CPUシステムではFALSE。

用途

サーバー・システムでのストリームのロードと並行して、クライアント・システムでストリームを作成できます。

構文および説明

MULTITHREADING=[TRUE | FALSE]

デフォルトでは、マルチスレッド・オプションは常にTRUEに設定され、複数CPUシステム上で使用可能です。この場合の複数CPUシステムの定義は、2つ以上のCPUを持つ単一システムです。

単一CPUシステムでは、マルチスレッドはデフォルトでFALSEに設定されています。2つの単一CPUシステム間でマルチスレッドを使用するには、マルチスレッドを使用可能にする必要があります。デフォルトでは、使用可能になっていません。

関連項目:

「複数CPUシステムのダイレクト・パス・ロードの最適化」

制限事項

- MULTITHREADINGパラメータは、ダイレクト・パス・ロードでのみ使用できます。

- マルチスレッド機能は、オペレーティング・システムに依存します。すべてのオペレーティング・システムがマルチスレッドをサポートしているわけではありません。

例

次の例では、単一CPUシステムでマルチスレッドを使用可能にします。複数CPUシステムでは、デフォルトで使用可能です。

MULTITHREADING=TRUE

NO_INDEX_ERRORS

デフォルト: FALSE

用途

NO_INDEX_ERRORSパラメータでは、ダイレクト・パス・ロード中に索引付けエラーを許容するかどうかを指定します。

構文および説明

NO_INDEX_ERRORS=[TRUE | FALSE]

NO_INDEX_ERRORS=FALSEの設定では、ダイレクト・パス・ロードの結果として索引が使用できなくなった場合、行がロードされ、索引は使用禁止状態のまま残されます。これはデフォルトの動作です。

NO_INDEX_ERRORS=TRUEの設定では、ダイレクト・パス・ロードの結果として索引付けエラーが発生すると、ロードは中断されます。どの行もロードされず、索引はそのままの状態で残されます。

制限事項

- NO_INDEX_ERRORSパラメータは、ダイレクト・パス・ロードでのみ有効です。従来型パス・ロードで指定した場合、このパラメータは無視されます。

例

NO_INDEX_ERRORS=TRUE

PARALLEL

デフォルト: FALSE

用途

PARALLELパラメータは、ダイレクト・パスまたは外部表を使用するロードによって、複数の同時セッションで同じ表にデータをロードできるかどうかを指定します。

構文および説明

PARALLEL=[TRUE | FALSE]

関連項目:

「パラレル・データ・ロード・モデル」

制限事項

- PARALLELパラメータは、従来型パス・ロードでは無効です。

例

次の例では、パラレルにロードを実行するように指定します。

PARALLEL=TRUE

PARFILE

デフォルト: デフォルト値は設定されていません。

用途

PARFILEパラメータは、コマンドラインで頻繁に使用するパラメータを記述したファイルを指定します。

構文および説明

PARFILE=file_name

コマンドラインで各パラメータを指定するかわりに、単にパラメータ・ファイルの名前を指定できます。たとえば、daily_report.parというパラメータ・ファイルの内容が、次のとおりだとします。

USERID=scott
CONTROL=daily_report.ctl
ERRORS=9999
LOG=daily_report.log

セキュリティ上の理由から、パラメータ・ファイルにはUSERIDのパスワードを含めないでください。コマンドラインでパラメータ・ファイルを指定した後、SQL*Loaderによってパスワードを入力するように要求されます。次に例を示します。

sqlldr PARFILE=daily_report.par
Password: password

制限事項

- 通常は問題ありませんが、システムによっては、パラメータ指定の中で等号(=)の前後に空白を挿入できないものもあります。

例

「構文および説明」の例を参照してください。

PARTITION_MEMORY

デフォルト: デフォルト値は0 (ゼロ)です。PGA_AGGREGATE_TARGET初期化パラメータの値に基づいてメモリーの使用が制限されます。メモリーの使用がこの値に達すると、一部のパーティションのロードが遅延します。

用途

PARTITION_MEMORYパラメータを使用すると、多数のパーティションをロードしている際に使用するメモリーの量を制限できます。このパラメータは、ロードしているパーティションの数が大量のメモリーを消費し、使用可能なメモリーを超える可能性がある場合に有効です(これは、特にデータが圧縮されている場合に起こることがあります)。

指定した制限に達すると、メモリーの使用が制限値を下回るまで、一部のパーティション行のロードが遅延します。

構文および説明

PARTITION_MEMORY=n

パラメータ値nの単位は、KBです。

nが0 (デフォルト)に設定されている場合、SQL*Loaderでは、PGA_AGGREGATE_TARGET初期化パラメータの機能である値が使用されます。

nが-1 (マイナス1)に設定されている場合、SQL*Loaderでは、多数のパーティションをロードする際のメモリーの消費は少なくなりません。

制限事項

- このパラメータは、ダイレクト・パス・ロードでのみ有効です。

- このパラメータは、Oracle Database 12cリリース1 (12.1.0.2)以降でのみ使用可能です。

例

次の例では、メモリーの使用を1GBに制限しています。

> sqlldr hr CONTROL=t.ctl DIRECT=true PARTITION_MEMORY=1000000

READSIZE

デフォルト:1048576

用途

デフォルトを使用しない場合は、READSIZEパラメータを使用して読取りバッファのサイズ(バイト単位)を指定できます。

構文および説明

READSIZE=n

従来型パス・ロードの方法では、バインド配列は、読取りバッファのサイズによって制限されます。そのため、読取りバッファを大きくすると、コミット操作を実行する前に、より多くのデータを読み取ることができるというメリットがあります。

たとえば、READSIZEに1000000を設定すると、コミットを実行する前に、SQL*Loaderによって、データ・ファイルから1,000,000バイト単位で読取りを実行できます。

注意:

READSIZEにBINDSIZEより小さい値を指定した場合、READSIZEの値は増加します。

「BINDSIZE」を参照してください。

制限事項

- READSIZEパラメータは、データ・ファイルからデータを読み込む場合にのみ使用されます。制御ファイルからレコードを読み込む場合は、常に64KBという値がREADSIZEとして使用されます。

- READSIZEパラメータは、LOBに影響しません。LOB読取りバッファのサイズは、64KBに固定されています。

- 許容最大サイズは、プラットフォームによって異なります。

例

次の例では、読取りバッファのサイズを500,000バイトに設定します(この設定では、デフォルト値またはデフォルトを超える値が使用されている場合より多くのコミット操作が必要になります)。

READSIZE=500000

RESUMABLE

デフォルト: FALSE

用途

RESUMABLEパラメータを使用して、再開可能な領域割当てを有効または無効にします。

構文および説明

RESUMABLE=[TRUE | FALSE]

関連項目:

- 再開可能な領域割当ての詳細は、『Oracle Database管理者ガイド』を参照してください。

制限事項

- このパラメータはデフォルトでは無効なため、関連するRESUMABLE_NAMEパラメータおよびRESUMABLE_TIMEOUTパラメータを使用するには、RESUMABLE=TRUEを設定する必要があります。

例

次の例では、再開可能な領域割当てを有効にします。

RESUMABLE=TRUE

RESUMABLE_NAME

デフォルト: 'User USERNAME(USERID), Session SESSIONID, Instance INSTANCEID'

用途

RESUMABLE_NAMEパラメータでは、再開可能な文を指定します。

構文および説明

RESUMABLE_NAME='text_string'

この値はユーザー定義のテキスト文字列で、USER_RESUMABLEまたはDBA_RESUMABLEビューに挿入して、一時停止されている特定の再開可能な文を識別できます。

制限事項

- RESUMABLEパラメータをTRUEに設定して、再開可能な領域割当てを有効にしないかぎり、このパラメータは無視されます。

例

RESUMABLE_NAME='my resumable sql'

RESUMABLE_TIMEOUT

デフォルト: 7200秒(2時間)

用途

RESUMABLE_TIMEOUTパラメータでは、エラー修正に必要な時間を秒単位で指定します。

構文および説明

RESUMABLE_TIMEOUT=n

タイムアウト時間内にエラーを修正できない場合は、文の実行が途中で終了します。

制限事項

- RESUMABLEパラメータをTRUEに設定して、再開可能な領域割当てを有効にしないかぎり、このパラメータは無視されます。

例

次の例では、10分(600秒)以内にエラーを修正する必要があることを指定します。

RESUMABLE_TIMEOUT=600

ROWS

デフォルト: 従来型パスのデフォルトは64です。ダイレクト・パスのデフォルトはすべての行です。

用途

従来型パス・ロードでは、ROWSパラメータでバインド配列の行数を指定します。ダイレクト・パス・ロードでは、ROWSパラメータでデータの保存前にデータ・ファイルから読み取る行数を指定します。

構文および説明

ROWS=n

従来型パス・ロードの場合のみ: ROWSパラメータでバインド配列の行数を指定します。行の最大数は65534です。詳細は、「バインド配列および従来型パス・ロード」を参照してください。

ダイレクト・パス・ロードの場合のみ: ROWSパラメータでデータ・ファイルからデータのセーブ前に読み込む行数を指定します。デフォルトでは、ロード終了時に、すべての行の読取りおよびデータ・セーブが1回実行されます。詳細は、「データ・セーブを使用したデータ損失の防止」を参照してください。1回のセーブで実際に表にロードされる行のおよその数は、ROWSの値から、最後のセーブ以降に廃棄および拒否されたレコードの数を引いた数です。

注意:

ROWSに低い値を指定し、表圧縮を使用してデータを圧縮しようとすると、通常は圧縮比が低下します。データの圧縮には、高い値を指定するかデフォルト値を使用することをお薦めします。

制限事項

- 索引構成表(IOT)にデータがロードされる場合、あるいはVARRAY、XML列またはLOBが含まれる表にデータがロードされる場合、ROWSパラメータはダイレクト・パス・ロードで無視されます。これは、ロードはそのまま実行されますが、セーブポイントは処理されないことを意味します。

例

従来型パス・ロードでは、指定した値が許容可能な最大行数の65534を超えているため、次の例はエラーになります。

ROWS=65900

SILENT

デフォルト: デフォルト値は設定されていません。

用途

SILENTパラメータは、SQL*Loaderの操作中に画面に書き込まれる内容の一部を抑止します。

構文および説明

SILENT=[HEADER | FEEDBACK | ERRORS | DISCARDS | PARTITIONS | ALL]

適切な値を使用して、次の1つ以上の内容を抑止します(複数のオプションを指定する場合、カンマで区切る必要があります)。

- HEADER: 画面に通常表示されるSQL*Loaderのヘッダー・メッセージを非表示にします。ただし、ヘッダー・メッセージはログ・ファイルに出力されます。

- FEEDBACK: ロードで画面に通常表示される「commit point reached」メッセージとステータス・メッセージを非表示にします。

- ERRORS: レコードにOracleエラーが発生したためそのレコードが不良ファイルに書き込まれた場合、データ・エラー・メッセージがログ・ファイルに出力されないようにします。ただし、拒否レコード件数は出力されます。

- DISCARDS: レコードが廃棄ファイルに書き込まれた場合に、そのことを示すメッセージがログ・ファイルに出力されないようにします。

- PARTITIONS: パーティション表のダイレクト・ロード中、ログ・ファイルに対するパーティションごとの統計情報の書込みを使用禁止にします。

- ALL: すべての抑止値(HEADER、FEEDBACK、ERRORS、DISCARDSおよびPARTITIONSパラメータ)を実装します。

例

たとえば、画面に通常表示されるヘッダーとフィードバック・メッセージが表示されないようにするには、コマンドラインの引数で次のように指定します。

SILENT=HEADER, FEEDBACK

SKIP

デフォルト: 0 (レコードは1件もスキップされません。)

用途

SKIPパラメータは、ファイルの先頭から何件の論理レコードをロード対象外とするかを指定します。これによって、すでに処理されているレコードをロードすることなく、なんらかの理由で中断されたロードを継続できます。

構文および説明

SKIP=n

SKIPパラメータは、すべての従来型ロード、単一表のダイレクト・パス・ロード、各表にロードされるレコード数が同一の場合の複数表のダイレクト・パス・ロードに使用されます。各表にロードされるレコード数が異なる場合、複数表のダイレクト・パス・ロードには使用できません。

WHEN句を使用し、セカンダリ・データもロード対象となる場合、そのセカンダリ・データは、プライマリ・データ・ファイルのレコードに対してWHEN句が正常に実行された場合にのみスキップされます。

関連項目:

「中断されたロード」

制限事項

- SKIPパラメータは、外部表のロードには使用できません。

例

次の例では、ロードを続行する前にデータ・ファイル内の最初の500件の論理レコードをスキップします。

SKIP=500

SKIP_INDEX_MAINTENANCE

デフォルト: FALSE

用途

SKIP_INDEX_MAINTENANCEパラメータでは、ダイレクト・パス・ロードの索引メンテナンスを停止するかどうかを指定します。

構文および説明

SKIP_INDEX_MAINTENANCE=[TRUE | FALSE]

このパラメータをTRUEに設定すると、索引パーティションには、索引キーが追加されるかわりに索引使用禁止が設定されます(索引セグメントと、その索引が付けられているデータとの整合性がとれないため)。ロードの影響を受けない索引セグメントについては、ロード前の状態が保持されます。

SKIP_INDEX_MAINTENANCEパラメータ:

- ローカル索引とグローバル索引の両方に適用できます。

- 索引を持つオブジェクトのパラレル・ロードを実行できます(PARALLELパラメータとともに指定)。

- グローバル索引を持つ表に単一パーティションをロードできます(INTO TABLE句でPARTITIONパラメータを指定)。

- ロードによって索引使用禁止状態に設定された索引や索引パーティションのリストを(SQL*Loaderログ・ファイルに)作成します。

制限事項

- SKIP_INDEX_MAINTENANCEパラメータは、従来型パス・ロードには適用されません。

- 一意で使用禁止状態の索引に対しては、索引メンテナンスをスキップできません。この原則は、DML操作の場合にも、ダイレクト・パスでDMLと整合性を持つロードを行う場合にも適用されます。

例

次の例では、ダイレクト・パス・ロードの操作中に索引メンテナンスが発生しないようにします。

SKIP_INDEX_MAINTENANCE=TRUE

SKIP_UNUSABLE_INDEXES

デフォルト: 初期化パラメータ・ファイルで指定した、Oracle Databaseの構成パラメータSKIP_UNUSABLE_INDEXESの値。デフォルトのデータベースの設定は、TRUEです。

用途

SKIP_UNUSABLE_INDEXESパラメータでは、索引使用禁止状態で出現した索引をスキップし、ロード操作を続行するかどうかを指定します。

構文および説明

SKIP_UNUSABLE_INDEXES=[TRUE | FALSE]

SKIP_UNUSABLE_INDEXESの値としてTRUEを指定すると、索引使用禁止状態の索引が検出された場合、使用禁止状態の索引はスキップされ、ロード処理は続行されます。これによってロード開始前の状態が使用禁止の索引を含む表をロードできます。ロード時に使用禁止状態でない索引は、SQL*Loaderによってメンテナンスされます。ロード時に使用禁止状態の索引はメンテナンスされず、ロード完了時も使用禁止状態のままです。

SKIP_UNUSABLE_INDEXESパラメータは、SQL*LoaderとOracle Databaseの両方によって提供されます。SQL*LoaderのSKIP_UNUSABLE_INDEXESパラメータは、SQL*Loaderコマンドラインで指定します。Oracle DatabaseのSKIP_UNUSABLE_INDEXESパラメータは、初期化パラメータ・ファイルの構成パラメータとして指定します。相互に与える影響を理解しておく必要があります。

SQL*LoaderコマンドラインでSKIP_UNUSABLE_INDEXESの値を指定すると、SQL*Loaderは、初期化パラメータ・ファイルに指定されているSKIP_UNUSABLE_INDEXES構成パラメータの値を上書きします。

SQL*LoaderコマンドラインでSKIP_UNUSABLE_INDEXESの値を指定しない場合、SQL*Loaderは、初期化パラメータ・ファイルに指定されているSKIP_UNUSABLE_INDEXES構成パラメータのOracle Database設定を使用します。初期化パラメータ・ファイルでSKIP_UNUSABLE_INDEXESの設定を指定しない場合、デフォルトの設定はTRUEになります。

SKIP_UNUSABLE_INDEXESパラメータは、従来型パス・ロードおよびダイレクト・パス・ロードの両方に適用できます。

制限事項

- 一意で使用禁止状態の索引に対しては、索引メンテナンスをスキップできません。この原則は、DML操作の場合にも、ダイレクト・パスでDMLと整合性を持つロードを行う場合にも適用されます。

例

Oracle Databaseの初期化パラメータの値がSKIP_UNUSABLE_INDEXES=FALSEであっても、SQL*Loaderコマンドラインの次のパラメータが優先します。したがって、索引使用禁止状態の索引が出現すると、それはスキップされてロード操作が続行されます。

SKIP_UNUSABLE_INDEXES=TRUE

STREAMSIZE

デフォルト: 256000

用途

STREAMSIZEパラメータで、クライアントからサーバーへ送ったデータのストリーム・サイズ(バイト単位)を指定します。

構文および説明

STREAMSIZE=n

STREAMSIZEパラメータでは、ダイレクト・パス・ストリーム・バッファのサイズを指定します。列配列の行数(COLUMNARRAYROWSパラメータで指定)によって、ストリーム・バッファが作成される前にロードされた行数を判断します。これらのパラメータの最適値は、使用されるシステム、入力データ型およびOracleの列データ型に応じて異なります。独自の構成用に最適な値を使用することで、SQL*Loaderのログ・ファイルでの経過時間が少なくなります。

関連項目:

「列配列の行数およびストリーム・バッファ・サイズの指定」

制限事項

- STREAMSIZEパラメータは、ダイレクト・パス・ロードにのみ適用されます。

- STREAMSIZEの最小値は65536です。65536未満の値が指定された場合、かわりに65536が使用されます。

例

次の例では、ダイレクト・パス・ストリーム・バッファのサイズを300,000バイトに指定します。

STREAMSIZE=300000

TRIM

デフォルト: LDRTRIM

用途

TRIMパラメータでは、テキスト・フィールドの先頭またはテキスト・フィールドの末尾(あるいはその両方)から空白を切り捨てることを指定します。空白には、空白文字およびその他の印字されない文字(タブ、LF、改行など)が含まれます。

構文および説明

TRIM=[LRTRIM | NOTRIM | LTRIM | RTRIM | LDRTRIM]

TRIMパラメータの有効な値は次のとおりです。

フィールドから文字を切り捨てない場合は、NOTRIMを使用します。この設定では、通常、最高のパフォーマンスを得ることができます。

フィールドから文字を切り捨てる場合は、LRTRIM、LTRIMおよびRTRIMを使用します。LRTRIMを使用すると、先頭と後続の空白の両方が切り捨てられます。先頭の空白を切り捨てるには、LTRIMを使用します。後続の空白を切り捨てるには、RTRIMを使用します。

LDRTRIMは、次の場合を除いて、NOTRIMと同様です。

- フィールドがデリミタ付きのフィールドではない場合、空白は右から切り捨てられる。

- フィールドがOPTIONALLY ENCLOSED BYで指定されたデリミタ付きフィールドで、オプションの囲みが特定のインスタンスで欠落している場合、空白は左から切り捨てられる。

すべてが空白のフィールドに対して切捨てを指定する場合、そのフィールドはNULLに設定されます。

制限事項

- TRIMパラメータは、外部表ロード方法が使用される場合にのみ有効です。

例

次の例では、どのフィールドからも文字が切り捨てられないロード操作が実行されます。

TRIM=NOTRIM

USERID

デフォルト: 省略すると、システムから入力を要求されます。スラッシュのみを入力すると、デフォルトとしてオペレーティング・システムのログイン名がUSERIDに適用されます。

用途

USERIDパラメータを使用して、Oracleユーザー名およびパスワードを指定します。

構文および説明

USERID=[username | / | SYS]

ユーザー名を指定します。セキュリティ上の理由から、コマンドラインにはユーザー名のみを指定することをお薦めします。SQL*Loaderによってパスワードの入力を要求されます。

USERIDパラメータを指定しない場合、その入力を求められます。スラッシュのみを入力すると、デフォルトとしてオペレーティング・システムのログイン名がUSERIDに適用されます。

ユーザーSYSとして接続する場合は、接続文字列にAS SYSDBAも指定する必要があります。

制限事項

- 文字列AS SYSDBAには空白が含まれるため、一部のオペレーティング・システムでは、接続文字列全体を一重引用符で囲むか、なんらかの方法でリテラルとしてマークする必要があります。また、オペレーティング・システムによっては、コマンドラインの引用符を、バックスラッシュなどでエスケープする必要がある場合もあります。
システムの特殊文字および予約文字の詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

例

次の例では、ユーザー名のhrを指定します。SQL*Loaderによってパスワードの入力を要求されます。これが指定する最初で唯一のパラメータであるため、パラメータ名のUSERIDを含める必要はありません。

> sqlldr hr
Password:

関連項目:

- 「コマンドラインでのパラメータの指定」

終了コードによる結果の検査と表示

Oracle SQL*Loaderでは、SQL*Loaderの完了後、すぐに実行結果を確認できます。SQL*Loaderでは、実行結果をログ・ファイルに記録するのみでなく、プロセス終了コードでレポートすることもできます。。このOracle SQL*Loaderの機能によって、コマンドラインやスクリプトからSQL*Loaderを起動したときにもその結果を確認できます。表8-1に、様々な結果の終了コードを示します。

表8-1 SQL*Loaderの終了コード

結果

終了コード

すべての列が正常にロードされた

EX_SUCC

すべての行または一部の行が拒否された

EX_WARN

すべての行または一部の行が廃棄された

EX_WARN

ロードが中断された

EX_WARN

コマンドラインまたは構文エラー

EX_FAIL

SQL*Loaderに対してリカバリ不能なOracleエラー

EX_FAIL

OS関連エラー(ファイルのオープン/クローズ、mallocなど)

EX_FTL

LinuxおよびUNIXオペレーティング・システムでは、終了コードは次のとおりです。

EX_SUCC 0
EX_FAIL 1
EX_WARN 2
EX_FTL  3

Windowsオペレーティング・システムでは、終了コードは次のとおりです。

EX_SUCC 0
EX_FAIL 1
EX_WARN 2
EX_FTL  4

SQL*Loaderが0(ゼロ)以外の終了コードを返した場合、システム・ログ・ファイルおよびSQL*Loaderログ・ファイルで、詳細な診断情報を確認してください。

UNIXでは、シェルの終了コードを調べてロード結果を確認できます。

9 SQL*Loader制御ファイル・リファレンス

SQL*Loader制御ファイルは、SQL*Loaderジョブ用のデータ定義言語(DDL)命令を含むテキスト・ファイルです。SQL*Loader制御ファイルを正しく使用するには、次の項目を理解することが必要です。

- 制御ファイルの内容

- 制御ファイル中でのコマンドライン・パラメータの指定

- ファイル名およびオブジェクト名の指定

- XMLType表の識別

- フィールド順序の指定

- データ・ファイルの指定

- CSV形式のファイルの指定

- BEGINDATAによる制御ファイルのデータの識別

- データ・ファイル形式およびバッファリングの指定

- 不良ファイルの指定

- 廃棄ファイルの指定

- 表レベルでのNULLIF句の指定

- 表レベルでの日時書式の指定

- 異なる文字コード体系の処理

- 中断されたロード

- 物理レコードからの論理レコードの作成

- 表への論理レコードのロード

- 索引オプション

- 複数のINTO TABLE句を使用するメリット

- バインド配列および従来型パス・ロード

注意:

SQL*Loaderは制御ファイルなしで使用することもできます(これはSQL*Loaderエクスプレス・モードと呼ばれます)。詳細は、「SQL*Loaderエクスプレス」を参照してください。

制御ファイルの内容

SQL*Loader制御ファイルは、DDL命令を含むテキスト・ファイルです。DDLを使用して、SQL*Loaderセッションの次の項目を制御します。

- SQL*Loaderによってロードされるデータの位置

- SQL*Loaderによるデータ書式設定の方法

- データのロード時のSQL*Loaderの設定(メモリー管理、拒否レコード、ロード処理の中断など)

- SQL*Loaderによるロード中のデータの処理方法

SQL*LoaderのDDL構文図の詳細は、「SQL*Loaderの構文図」を参照してください。

SQL*Loader制御ファイルを作成するには、viやxemacsなどのテキスト・エディタを使用します。

通常、制御ファイルには、次の3つの項目が次の順序で含まれます。

- セッション全体の情報

- 表およびフィールド・リストの情報

- 入力データ(オプションの項目)

例9-1に、サンプル制御ファイルを示します。

例9-1 サンプル制御ファイル

1    -- This is a sample control file
2    LOAD DATA
3    INFILE 'sample.dat'
4    BADFILE 'sample.bad'
5    DISCARDFILE 'sample.dsc'
6    APPEND
7    INTO TABLE emp
8    WHEN (57) = '.'
9    TRAILING NULLCOLS
10  (hiredate SYSDATE,
deptno POSITION(1:2)  INTEGER EXTERNAL(2)
NULLIF deptno=BLANKS,
job    POSITION(7:14)  CHAR  TERMINATED BY WHITESPACE
NULLIF job=BLANKS  "UPPER(:job)",
mgr    POSITION(28:31) INTEGER EXTERNAL
TERMINATED BY WHITESPACE, NULLIF mgr=BLANKS,
ename  POSITION(34:41) CHAR
TERMINATED BY WHITESPACE  "UPPER(:ename)",
empno  POSITION(45) INTEGER EXTERNAL
TERMINATED BY WHITESPACE,
sal    POSITION(51) CHAR  TERMINATED BY WHITESPACE
"TO_NUMBER(:sal,'$99,999.99')",
comm   INTEGER EXTERNAL  ENCLOSED BY '(' AND '%'
":comm * 100"
)

このサンプル制御ファイルの左側の数字は、実際の制御ファイルでは表示されません。これらの数字は、次の説明の番号に対応しています。

1. 制御ファイルにコメントを入力します。詳細は、「制御ファイルのコメント」を参照してください。

2. LOAD DATA文によって、SQL*Loaderで新しくデータ・ロードが開始されます。構文の詳細は、「SQL*Loaderの構文図」を参照してください。

3. INFILE句には、ロードするデータが入っているデータ・ファイルの名前を指定します。詳細は、「データ・ファイルの指定」を参照してください。

4. BADFILE句には、拒否レコードが書き込まれるファイルの名前を指定します。詳細は、「不良ファイルの指定」を参照してください。

5. DISCARDFILE句には、廃棄レコードが書き込まれるファイルの名前を指定します。詳細は、「廃棄ファイルの指定」を参照してください。

6. APPEND句は、空ではない表にデータをロードする場合に使用できるオプションの1つです。詳細は、「空でない表へのデータのロード」を参照してください。
空の表にデータをロードするには、INSERT句を使用します。詳細は、「空の表へのデータのロード」を参照してください。

7. INTO TABLE句を使用して、表、フィールドおよびデータ型を識別できます。この句で、データ・ファイル中のレコードとデータベース中の表の関係を定義します。詳細は、「表名の指定」を参照してください。

8. WHEN句には、1つ以上のフィールド条件を指定します。SQL*Loaderで、この条件に基づいてデータをロードするかどうかを判断します。詳細は、「条件に基づいたレコードのロード」を参照してください。

9. TRAILING NULLCOLS句を使用すると、相対位置に指定した列がレコード中に存在しない場合、その列の値はNULLとして処理されます。詳細は、「データが欠落しているショート・レコードの処理」を参照してください。

10. 制御ファイルの残りの部分には、ロード中の表の列形式の詳細を参照できるフィールド・リストが含まれます。制御ファイルのセクションの詳細は、「SQL*Loaderフィールド・リスト・リファレンス」を参照してください。

制御ファイルのコメント

コメントはファイル中のパラメータ部分のどこにでも記述できますが、データの部分には記述できません。コメントの前にハイフンを2つ続けて記述します。次に例を示します。

--This is a comment

二重ハイフンの右側のすべてのテキストは行末まで無視されます。

制御ファイル中でのコマンドライン・パラメータの指定

SQL*Loader制御ファイルでは、OPTIONS句を使用してコマンドライン・パラメータを指定できます。これは、同じオプションの組合せで何度も制御ファイルを使用する場合に役立ちます。OPTIONS句は、LOAD DATA文の前に置きます。

OPTIONS句

OPTIONS句では、次のコマンドライン・パラメータを指定できます。これらのパラメータの説明は、「SQL*Loaderコマンドライン・リファレンス」を参照してください。

BINDSIZE = n
COLUMNARRAYROWS = n
DATA_CACHE = n
DEGREE_OF_PARALLELISM= {degree-num|DEFAULT|AUTO|NONE}
DIRECT = {TRUE | FALSE}
ERRORS = n
EXTERNAL_TABLE = {NOT_USED | GENERATE_ONLY | EXECUTE}
FILE = tablespace file
LOAD = n
MULTITHREADING = {TRUE | FALSE}
PARALLEL = {TRUE | FALSE}
READSIZE = n
RESUMABLE = {TRUE | FALSE}
RESUMABLE_NAME = 'text string'
RESUMABLE_TIMEOUT = n
ROWS = n
SILENT = {HEADER | FEEDBACK | ERRORS | DISCARDS | PARTITIONS | ALL}
SKIP = n
SKIP_INDEX_MAINTENANCE = {TRUE | FALSE}
SKIP_UNUSABLE_INDEXES = {TRUE | FALSE}
STREAMSIZE = n
TRIM= {LRTRIM|NOTRIM|LTRIM|RTRIM|LDRTRIM}

次に、SQL*Loader制御ファイルで使用できるOPTIONS句の使用例を示します。

OPTIONS (BINDSIZE=100000, SILENT=(ERRORS, FEEDBACK) )

注意:

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

ファイル名およびオブジェクト名の指定

通常、オブジェクト名(表名や列名など)の指定に関して、SQL*LoaderはSQL標準規則に準拠しています。この項では、次の項目について説明します。

- SQLおよびSQL*Loaderの予約語と競合するファイル名

- SQL文字列の指定

- オペレーティング・システムに関する考慮点

SQLおよびSQL*Loaderの予約語と競合するファイル名

SQLおよびSQL*Loaderの予約語は、二重引用符で囲みます。SQL*Loaderの予約語はCONSTANTのみです。

二重引用符は、オブジェクト名にSQLが認識可能な文字($、#、_)以外の特殊文字が含まれている場合、またはオブジェクト名に大/小文字の区別が必要な場合に使用する必要があります。

関連項目:

『Oracle Database SQL言語リファレンス』

SQL文字列の指定

SQL文字列を指定する場合は、二重引用符で囲みます。SQL文字列を使用すると、SQL演算子をデータ・フィールドに適用できます。

関連項目:

「フィールドへのSQL演算子の適用」

オペレーティング・システムの考慮事項

次の項では、ご使用のオペレーティング・システムによって異なる仕様について説明します。

完全パスの指定

完全パス名を指定すると、問題が発生する場合があります。これは、特殊文字の使用が原因でオペレーティング・システム依存の非互換が発生するためです。多くの場合、パス名を一重引用符で囲んで指定すると、このエラーは回避できます。

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

DDL構文では、(ご使用のオペレーティング・システムでエスケープ文字の使用が許可されている場合)二重引用符の前にバックスラッシュ・エスケープ文字(\)を付けて、二重引用符で区切られた文字列の中で二重引用符を使用できます。一重引用符で区切られた文字列中で一重引用符を使用する場合も、その前にバックスラッシュを付けます。

たとえば、homedir\data"norm\mydataという文字列には、二重引用符が含まれています。二重引用符の直前にバックスラッシュを付けることによって、二重引用符を文字列として使用できます。

INFILE 'homedir\data\"norm\mydata'

また、バックスラッシュを2回続けて書くことによって、バックスラッシュ自体を文字列中に表示できます。

次に例を示します。

"so'\"far"     or  'so\'"far'     is parsed as   so'"far
"'so\\far'"    or  '\'so\\far\''  is parsed as  'so\far'
"so\\\\far"    or  'so\\\\far'    is parsed as   so\\far

注意:

先頭位置の二重引用符はエスケープできません。そのため、先頭に引用符の付く文字列は作成しないでください。

移植不能文字列

SQL*Loader制御ファイルには、オペレーティング・システム間で移植不能な、2種類の文字列があります(filename文字列およびfile processing option文字列)。別のオペレーティング・システム用に変換した場合、これらの文字列を修正する必要があります。SQL*Loader制御ファイルのこれ以外の文字列はすべて、異なるオペレーティング・システム間で移植可能です。

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

オペレーティング・システムで、パス名のディレクトリを区切る文字としてバックスラッシュが使用されている場合、およびオペレーティング・システムで実行しているOracle Databaseのリリースで、ファイル名およびその他の移植不能文字列に対してバックスラッシュをエスケープ文字として使用可能な場合は、パス名のディレクトリ間の区切りにバックスラッシュを2つ続けて指定して、パス名全体を一重引用符で囲みます。

エスケープ文字が使用できない場合

現在オペレーティング・システム上で実行中のOracle Databaseのリリースでは、移植不能文字列に対してエスケープ文字を使用できない場合があります。エスケープ文字が禁止されている場合、バックスラッシュは、エスケープ文字ではなく通常の文字として処理されます(ただし、移植不能文字列以外の文字列では使用可能)。この場合、次のようなパス名を指定できます。

INFILE 'topdir\mydir\myfile'

バックスラッシュを2つ続ける必要はありません。

バックスラッシュはエスケープ文字として認識されないため、一重引用符で囲まれた文字列の中に、一重引用符で囲まれた別の文字列を埋め込むことはできません。これは、二重引用符についても同様です。二重引用符で囲まれた文字列は、二重引用符で区切られた他の文字列の中に埋め込むことはできません。

XMLType表の識別

Oracle Database 10gでは、SQL*Loader制御ファイルでXMLTYPE句を使用できます。形式は、XMLTYPE(フィールド名)です。正しいSQL文を構築するために、この句を使用してXMLType表を識別します。例9-2では、スキーマベースのXMLType表にデータをロードするために、SQL*Loaderの制御ファイルでXMLTYPE句を使用する方法を示します。

関連項目:

SQL*Loaderを使用したXMLデータのロードの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

例9-2 SQL*Loader制御ファイルでのXMLType表の識別

XMLスキーマ定義は次のとおりです。XMLスキーマxdb_user.xsdがOracle XML DBに登録され、表xdb_tab5が作成されます。

begin dbms_xmlschema.registerSchema('xdb_user.xsd',
'<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xdb="http://xmlns.oracle.com/xdb">
<xs:element name = "Employee"
xdb:defaultTable="EMP31B_TAB">
<xs:complexType>
<xs:sequence>
<xs:element name = "EmployeeId" type = "xs:positiveInteger"/>
<xs:element name = "Name" type = "xs:string"/>
<xs:element name = "Salary" type = "xs:positiveInteger"/>
<xs:element name = "DeptId" type = "xs:positiveInteger"
xdb:SQLName="DEPTID"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>',
TRUE, TRUE, FALSE); end;
/

表を定義する方法は、次のとおりです。

CREATE TABLE xdb_tab5 OF XMLTYPE XMLSCHEMA "xdb_user.xsd" ELEMENT "Employee";

データを表xdb_tab5にロードするために使用する制御ファイルは、次のようになります。登録されたXMLスキーマxdb_user.xsdを使用して、XMLTypeデータがロードされます。XMLTYPE句を使用して、この表をXMLType表として識別します。ダイレクト・パスまたは従来型モードのいずれかを使用して、表にデータをロードできます。

LOAD DATA
INFILE *
INTO TABLE xdb_tab5 TRUNCATE
xmltype(xmldata)
(
xmldata   char(4000)
)
BEGINDATA
<Employee>  <EmployeeId>111</EmployeeId>  <Name>Ravi</Name>  <Salary>100000</Sal
ary>  <DeptId>12</DeptId></Employee>
<Employee>  <EmployeeId>112</EmployeeId>  <Name>John</Name>  <Salary>150000</Sal
ary>  <DeptId>12</DeptId></Employee>
<Employee>  <EmployeeId>113</EmployeeId>  <Name>Michael</Name>  <Salary>75000</S
alary>  <DeptId>12</DeptId></Employee>
<Employee>  <EmployeeId>114</EmployeeId>  <Name>Mark</Name>  <Salary>125000</Sal
ary>  <DeptId>16</DeptId></Employee>
<Employee>  <EmployeeId>115</EmployeeId>  <Name>Aaron</Name>  <Salary>600000</Sa
lary>  <DeptId>16</DeptId></Employee>

フィールド順序の指定

SQL*Loader制御ファイルでFIELD NAMES句を使用して、フィールド順序を指定できます。構文は次のとおりです:

FIELD NAMES {FIRST FILE|FIRST FILE IGNORE|ALL FILES|ALL FILES IGNORE|NONE}

FIELD NAMESのオプションは次のとおりです。

- FIRST FILE: 最初のデータ・ファイルに、最初のレコードのデータに対応するフィールド名のリストが含まれることを示します。このリストでは、データ・ファイルのデータと同じデリミタが使用されます。レコードは、データ・ファイルのフィールドとターゲット表の列とのマッピングを設定するために読み取られます。レコードは、データが処理されるとスキップされます。これは、データ・ファイルのフィールドの順序が表の列の順序と異なる場合や、データ・ファイルのフィールドの数がターゲット表の列の数と異なる場合に役立ちます。

- FIRST FILE IGNORE: 最初のデータ・ファイルに、最初のレコードのデータに対応するフィールド名のリストが含まれるが、その情報は無視する必要があることを示します。レコードは、データが処理されるとスキップされますが、フィールドの設定には使用されません。

- ALL FILES: すべてのデータ・ファイルに、最初のレコードのデータに対応するフィールド名のリストが含まれることを示します。各データ・ファイルの最初のレコードは、データが処理されるとスキップされます。フィールドは、データ・ファイルごとに異なる順序で配置できます。SQL*Loaderは、各データ・ファイルのフィールドの順序に基づいてロードを設定します。

- ALL FILES IGNORE: すべてのデータ・ファイルに、最初のレコードのデータに対応するフィールド名のリストが含まれるが、その情報は無視する必要があることを示します。レコードは、すべてのデータ・ファイルでデータが処理されるとスキップされますが、フィールドの設定には使用されません。

- NONE: データ・ファイルに、最初のレコードの通常のデータが含まれることを示します。これはデフォルトです。

FIELD NAMES句は、列オブジェクト、ネストした表、VARRAYなどの複合列型では使用できません。

データ・ファイルの指定

ロードするデータを含むデータ・ファイルを指定するには、INFILEキーワードにファイル名を続け、必要な場合はファイル処理オプション文字列を続けます。指定する単一ファイルが複数ある場合は、INFILEキーワードを複数使用できます。ファイル名にワイルドカードを使用することもできます(アスタリスク(*)は複数文字を、疑問符(?)は1文字を表します)。

注意:

コマンドラインからデータ・ファイルを指定する場合は、「SQL*Loaderのコマンドライン・パラメータ」で説明しているDATAパラメータを使用します。コマンドラインでファイル名を指定すると、制御ファイルの最初のINFILE句が上書きされます。

ファイル名が指定されない場合は、制御ファイル名の拡張子(ファイルのタイプ)を.datにしたファイル名がデフォルトで採用されます。

ロードするデータを制御ファイル内にも記述した場合は、ファイル名にアスタリスク(*)を指定してください。この指定の詳細は、「BEGINDATAによる制御ファイルのデータの識別」を参照してください。

注意:

ここで説明する内容は、プライマリ・データ・ファイルのみに適用されます。LOBFILEまたはSDFには適用されません。

LOBFILEの詳細は、「LOBFILEからのLOBデータのロード」を参照してください。

SDFの詳細は、「セカンダリ・データ・ファイル(SDF)」を参照してください。

INFILEの構文は次のとおりです。

表9-1では、INFILEキーワードのパラメータについて説明します。

表9-1 INFILEキーワードのパラメータ

パラメータ

説明

INFILE

データ・ファイル指定が続くことを示します。

input_filename

データが入っているファイルの名前。ファイル名にはワイルドカードを使用できます。アスタリスク(*)は複数文字を表し、疑問符(?)は1文字を表します。次に例を示します。

INFILE 'emp*.dat'
INFILE 'm?emp.dat'

ファイル名に空白やその他の句読点文字が含まれている場合は、一重引用符で囲む必要があります。詳細は、「ファイル名およびオブジェクト名の指定」を参照してください。

*

データが制御ファイル中にある場合は、ファイル名のかわりにアスタリスク(*)を指定します。制御ファイルおよびデータ・ファイルにデータがある場合は、読み込むデータをまずアスタリスクで指定する必要があります。

os_file_proc_clause

ファイル処理オプション文字列。データ・ファイルの形式を指定します。また、この指定によってデータ・ファイルの読取りを最適化できます。この文字列の構文は、ご使用のオペレーティング・システムに依存します。詳細は、「データ・ファイル形式およびバッファリングの指定」を参照してください。

INFILE構文の例

次に、INFILE構文を指定する様々な方法を示します。

- 制御ファイルにデータがある場合

INFILE  *

- デフォルトの拡張子.datを持つファイルsampleにデータがある場合

INFILE  sample

- フルパスに指定されたファイルdatafile.datにデータがある場合

INFILE 'c:/topdir/subdir/datafile.dat'

注意:

ファイル名に空白やその他の句読点文字が含まれている場合は、ファイル名を一重引用符で囲む必要があります。

- 名前がempで始まる.datタイプの任意のファイルにデータがある場合

INFILE 'emp*.dat'

- 名前がmで始まり、その後に他の任意の1文字が続き、empで終わる.datタイプの任意のファイルにデータがある場合。たとえば、myemp.datという名前のファイルが次の指定に含まれます。

INFILE 'm?emp.dat'

複数のデータ・ファイルの指定

1回のSQL*Loaderの実行で複数のデータ・ファイルのデータをロードする場合は、各データ・ファイルに対してINFILE句を指定します。このとき、レコードのレイアウトは同じである必要がありますが、データ・ファイルに同じファイル処理オプションは必要ありません。たとえば、最初と2番目のファイルが異なるファイル処理オプション文字列で指定されていても、3番目のファイルが制御ファイル中のデータで構成されていても実行することができます。

各データ・ファイルに、個別の不良ファイルおよび廃棄ファイルを指定することもできます。このような場合、個別の不良ファイルおよび廃棄ファイルは、各データ・ファイル名の直後に宣言する必要があります。次に、4つのデータ・ファイルを個別の不良ファイルおよび廃棄ファイルとともに指定している制御ファイルの例を示します。

INFILE  mydat1.dat  BADFILE  mydat1.bad  DISCARDFILE mydat1.dis
INFILE  mydat2.dat
INFILE  mydat3.dat  DISCARDFILE  mydat3.dis
INFILE  mydat4.dat  DISCARDMAX  10 0

- mydat1.datでは、不良ファイルと廃棄ファイルの両方が明示的に指定されています。したがって、必要に応じて両方のファイルが作成されます。

- mydat2.datでは、不良ファイルも廃棄ファイルも指定されていません。そのため、不良ファイルのみが必要に応じて作成されます。不良ファイルが作成された場合、デフォルトのファイル名および拡張子mydat2.badが使用されます。一方、廃棄ファイルについては、行が廃棄されても廃棄ファイルは作成されません。

- mydat3.datでは、必要に応じてデフォルトの不良ファイルが作成されます。また、必要に応じて、指定された名前の廃棄ファイル(mydat3.dis)も作成されます。

- mydat4.datでは、必要に応じてデフォルトの不良ファイルが作成されます。DISCARDMAXオプションが指定されているため、SQL*Loaderによって廃棄ファイルが使用されることを前提として、廃棄ファイルがデフォルト名(mydat4.dsc)で作成されます。

CSV形式のファイルの指定

SQL*Loaderでカンマ区切り値形式のファイルであるデータ・ファイルにアクセスするには、CSV句を使用します。これによって、ファイルは、通常の改行文字列(たとえば、UNIXまたはLinuxオペレーティング・システムの場合は\n、Windowsオペレーティング・システムの場合は\nまたは\r\n)を含むストリーム・レコード形式のファイルであるとみなされます。データ値にはレコード終了記号含める(埋め込む)ことができます。CSV句の構文は次のとおりです。

FIELDS CSV [WITH EMBEDDED|WITHOUT EMBEDDED] [FIELDS TERMINATED BY ','] [OPTIONALLY ENCLOSED BY '"']

FIELDS CSV句の主なポイントは次のとおりです。

- SQL*Loaderのデフォルトでは、FIELDS CSV句を使用しません。

- WITH EMBEDDEDおよびWITHOUT EMBEDDEDオプションでは、データのフィールド内にレコード終了記号が含まれている(埋め込まれている)かどうかを指定します。

- WITH EMBEDDEDを使用する場合、埋込みのレコード終了記号は囲む必要があり、データ・ファイル内の並列度は外部表ロードでは無効になります。

- TERMINATED BY ','およびOPTIONALLY ENCLOSED BY '"'オプションはデフォルトのため、指定する必要はありません。これらは別の終了記号や囲み文字で上書きできます。

- CSV句を使用する場合、区切ることが可能なデータ型のみが制御ファイルのフィールドとして許可されます。区切ることが可能なデータ型には、CHAR、日時、期間および数値型EXTERNALが含まれます。

- CSV句を指定する場合、TERMINATED BYおよびENCLOSED BY句は、フィールド・レベルでは使用できません。

- CSV句を指定すると、通常のSQL*Loaderの空白の切捨てがデフォルトで実行されます。PRESERVE BLANKSを指定すると、空白の切捨てを回避できます。または、フィールド指定でSQL関数のLTRIMおよびRTRIMを使用すると、左側または右側(あるいはその両方)の空白を削除できます。

- CSV句を指定する場合、INFILE *句は使用できません。つまり、SQL*Loader制御ファイルに含まれているデータは使用できません。

次のサンプルSQL*Loader制御ファイルでは、デフォルトのデリミタでFIELDS CSV句を使用しています。

LOAD DATA
INFILE "mydata.dat"
TRUNCATE
INTO TABLE mytable
FIELDS CSV WITH EMBEDDED
TRAILING NULLCOLS
(
c0 char,
c1 char,
c2 char,
)

BEGINDATAによる制御ファイルのデータの識別

データが制御ファイルにある場合、ファイル名ではなくアスタリスクがINFILE句の後に続きます。実際のデータは、ロード構成の指定後、制御ファイルに書き込まれます。

最初のデータ・レコードの前に、BEGINDATA文を指定します。構文は次のとおりです。

BEGINDATA
first_data_record

BEGINDATA文を使用する場合は、次のことに注意してください。

- 制御ファイルにデータが含まれているにもかかわらず、BEGINDATA文を省略すると、SQL*Loaderでデータが制御情報として解釈されるため、エラー・メッセージが発行されます。データが個別ファイルにある場合は、BEGINDATA文は使用できません。

- BEGINDATAを含む行がデータの先頭行として解釈されてしまうため、BEGINDATA文と同じ行には、空白またはその他の文字を入力しないでください。

- コメントもデータとして解釈されてしまうため、BEGINDATAの後に続けて記述しないでください。

関連項目:

- INFILEの使用例については、「データ・ファイルの指定」を参照してください

- 「事例1: 可変長データのロード」(事例の使用方法については、「SQL*Loaderの事例」を参照)

データ・ファイル形式およびバッファリングの指定

SQL*Loaderの設定時、制御ファイルの形式およびバッファリングの指定に対して、オペレーティング・システムに依存したファイル処理オプション文字列(os_file_proc_clause)を制御ファイルに指定できます。

たとえば、ご使用のオペレーティング・システムに、次のようなオプション文字列の構文があるとします。

この構文では、RECSIZEは固定長レコードのサイズ、BUFFERSは非同期I/Oを行うためのバッファ数です。

mydata.datというファイルを80バイトのレコードを含むファイルとして宣言し、SQL*LoaderのI/O処理で使用されるバッファ数を8とする場合は、次の制御ファイルのエントリを使用します。

INFILE 'mydata.dat' "RECSIZE 80 BUFFERS 8"

注意:

この例では、ファイル名に一重引用符を使用し、その他の指定には二重引用符を使用しています。

関連項目:

Windowsシステムでのos_file_proc_clauseの使用方法については、『Oracle Databaseプラットフォーム・ガイド for Microsoft Windows』を参照してください。

不良ファイルの指定

SQL*Loaderを実行すると、不良ファイルまたは拒否ファイルと呼ばれるファイルが生成されることがあります。これらのファイルには、書式エラーまたはOracleエラーが発生したためにロードを拒否されたレコードが格納されます。不良ファイルが作成されるように指定した場合は、次の規則に従って作成されます。

- レコードが1つ以上拒否された場合、不良ファイルが作成され、拒否レコードがログに記録されます。

- レコードが1つも拒否されない場合、不良ファイルは作成されません。

- 不良ファイルが作成される場合、同じ名前の既存のファイルは上書きされます。そのため、残しておきたいファイルが上書きされないようにする必要があります。

注意:

一部のシステムでは、同じ名前のファイルがすでに存在する場合でも、新しいバージョンのファイルが作成される場合があります。

不良ファイルの名前を指定する場合は、BADFILE句を使用します。コマンドラインから不良ファイルを指定する場合は、「SQL*Loaderのコマンドライン・パラメータ」で説明しているBADパラメータを使用します。

コマンドラインから指定した不良ファイル名は、制御ファイル中の最初に記述されるINFILE句に対して指定されたものとみなされます。この場合、前述の句の中で不良ファイル名が指定されていても、コマンドラインから指定した不良ファイル名が優先されます。

生成される不良ファイルのファイル形式やレコード形式は、データ・ファイルと同じです。したがって、データを修正した後そのまま再ロードすることができます。ストリーム・レコード形式のデータ・ファイルに関しては、データ・ファイルにあるレコード終了記号が不良ファイル内でも使用されます。

BADFILE句の構文は次のとおりです。

BADFILE句は、その後に不良ファイルのディレクトリ・パスまたはファイル名(あるいはその両方)が続くことを指定します。BADFILEを指定した場合、ディレクトリ・パス、ファイル名またはこの両方を指定する必要があります。

directoryパラメータには、不良ファイルの書込み先となるディレクトリ・パスを指定します。

filenameパラメータには、使用するプラットフォームに有効なファイル名を指定します。ファイル名に空白やその他の句読点文字が含まれている場合は、一重引用符で囲む必要があります。不良ファイルの名前を指定しなかった場合は、デフォルトで、データ・ファイル名に拡張子(またはファイル・タイプ).badを付けたものがファイル名になります。

不良ファイル名指定の例

ファイル名sampleおよびデフォルトのファイル拡張子(またはファイル・タイプ) .badで不良ファイルを指定するには、制御ファイルで次のように入力します。

BADFILE sample

ディレクトリ名のみを指定するには、制御ファイルで次のように入力します。

BADFILE '/mydisk/bad_dir/'

ファイル名bad0001およびファイル拡張子(またはファイル・タイプ) .rejで不良ファイルを指定するには、制御ファイルで次のいずれかの行を入力します。

BADFILE bad0001.rej
BADFILE '/REJECT_DIR/bad0001.rej'

LOBFILEおよびSDFを使用した不良ファイルの処理方法

LOBFILEおよびSDFのデータは、拒否された行がある場合、不良ファイルには書き込まれません。LOBのロード中にエラーが発生した場合、その行は拒否されません。この場合、LOB列は、空のまま(NULLではなく長さが0(ゼロ)バイト)になります。ただし、LOBFILEを使用してXML列をロードし、このLOBデータのロード中にエラーが発生した場合、XML列はNULLになります。

拒否レコードの条件

レコードは、次の理由で拒否されます。

1. レコードの挿入時に、指定されたデータ型と実際のデータが適合しないなどのOracleエラーが発生する場合。

2. レコードが不適切にフォーマットされて、SQL*Loaderがフィールドの境界を検索できない場合。

3. レコードが制約に違反するか、または一意の索引を非一意にしようとする場合。

デリミタの指定が不適切であっても、WHEN句の指定条件に基づいてデータを評価できる場合は、条件判断が行われ、データが挿入または拒否されます。

前述のリストの2番目の理由でロードが拒否された場合、従来型パス・ロードでもダイレクト・パス・ロードでも表に行は書込みできません。

前述のリストの1番目または3番目の理由でいずれかの表に違反がある場合、従来型パス・ロードでは、表に行は書込みできません。行はその表に対して拒否され、拒否ファイルに書き込まれます。

従来型パス・ロードでは、データ・ファイルのレコードが複数の表にロードされているときに1つ以上の表から拒否されると、そのレコードはいずれの表にもロードされません。

ログ・ファイルには、拒否レコードそれぞれについてのOracleエラー情報が記録されます。拒否レコードの例の詳細は、事例4を参照してください。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

廃棄ファイルの指定

ロード条件を満たさないレコードがある場合、SQL*Loaderを実行すると、廃棄ファイルが生成されることがあります。このファイルに出力されたレコードは廃棄レコードと呼ばれます。廃棄レコードは、制御ファイル中のWHEN句の指定を満たすことができなかったものです。これらのレコードは、拒否レコードとは異なります。廃棄レコードに必ず不良データがあるとはかぎりません。また、廃棄レコードに対して、挿入は行われません。

廃棄ファイルは次の規則に従って生成されます。

- 廃棄ファイル名を指定し、1つ以上のレコードが制御ファイルに指定したすべてのWHEN句の条件に満たない場合に生成されます。(廃棄ファイルが生成されると、同じ名前の既存のファイルは上書きされることに注意してください。)

- 廃棄レコードがない場合、廃棄ファイルは生成されません。

制御ファイル内で廃棄ファイルを指定するには、そのディレクトリまたは名前(またはその両方)を指定するか、廃棄の最大数を指定します。次のいずれかの句により、廃棄ファイルが必要に応じて作成されます。

- DISCARDFILE=[[directory/][filename]]

- DISCARDS

- DISCARDMAX

生成される廃棄ファイルのファイル形式やレコード形式は、データ・ファイルと同じです。ストリーム・レコード形式のデータ・ファイルに関しては、データ・ファイルにあるレコード終了記号が廃棄ファイル内でも使用されます。

DISCARDパラメータまたはDISCARDMAXパラメータを指定することで、コマンドラインから廃棄ファイルを作成することもできます。詳細は、「SQL*Loaderコマンドライン・リファレンス」を参照してください。

制御ファイルまたはコマンドラインにDISCARD句がない場合、廃棄レコード(つまり、制御ファイルのWHEN句で指定の事項を満たしていないもの)がある場合でも廃棄ファイルは作成されません。

制御ファイルでの廃棄ファイルの指定

ファイルの名前を指定するには、DISCARDFILE句にディレクトリ・パスまたはファイル名(あるいはその両方)を続けます。

DISCARDFILE句は、その後に廃棄ディレクトリ・パスまたはファイル名(あるいはその両方)が続くことを指定します。directory_pathもfilenameも必須ではありません。ただし、少なくとも1つを指定する必要があります。

directoryパラメータには、廃棄ファイルの書込み先となるディレクトリを指定します。

filenameパラメータには、使用するプラットフォームに有効なファイル名を指定します。ファイル名に空白やその他の句読点文字が含まれている場合は、一重引用符で囲む必要があります。

デフォルトのファイル名は、データ・ファイル名にデフォルトのファイル拡張子(またはファイル・タイプ).dscを付けたものが採用されます。廃棄ファイル名をコマンドラインから指定した場合は、制御ファイル中で指定されたファイル名よりも、コマンドラインからの指定ファイル名が優先されます。生成される廃棄ファイルと同じ名前のファイルがすでに存在する場合は、既存ファイルが上書きされるか、新しいバージョンのファイルが生成されます。どちらの処理が行われるかは、使用するオペレーティング・システムによって異なります。

廃棄レコード数の上限付け

DISCARDSまたはDISCARDMAXキーワードにintegerを指定して、各データ・ファイルに対して廃棄されるレコード数を制限できます。

データ・ファイルごとに異なる数の上限を設定できます。ただし、1回のみ廃棄数を指定した場合は、指定した廃棄上限値はすべてのファイルに適用されます。

廃棄の上限に達すると、データ・ファイルの処理が中止され、引き続き、次のデータ・ファイル(存在する場合)の処理が実行されます。

廃棄数の上限値が指定されていて、廃棄ファイル名の指定がない場合、SQL*Loaderによってデフォルトのファイル名とファイル拡張子(またはファイル・タイプ)で廃棄ファイルが作成されます。

廃棄ファイル名指定の例

次に、制御ファイル内から廃棄ファイルの名前を指定する様々な方法を示します。

- ファイル名circularおよびデフォルトのファイル拡張子(またはファイル・タイプ).dscで廃棄ファイルを指定するには、次のとおり入力します。

DISCARDFILE  circular

- ファイル名notapplおよびファイル拡張子(またはファイル・タイプ).mayで廃棄ファイルを指定するには、次のとおり入力します。

DISCARDFILE notappl.may

- 廃棄ファイルforget.meにフルパスを指定するには、次のとおり入力します。

DISCARDFILE  '/discard_dir/forget.me'

廃棄レコードの条件

レコードに対してINTO TABLE句が指定されていない場合、そのレコードは廃棄されます。レコードの廃棄は、SQL*Loader制御ファイル中に記述されたすべてのINTO TABLE句がWHEN句を持っていて、レコードがそれらのどの条件にも該当しない場合、またはすべてのフィールドがNULLである場合に発生します。

INTO TABLE句がWHEN句なしで指定されている場合、レコードは廃棄されません。すべてのレコードに関して、指定の表への挿入が試みられます。このとき、レコードが拒否されることはありますが、廃棄されることはありません。

「事例7: 書式化されたレポートからのデータの抽出」に廃棄ファイルの使用例があります。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

LOBFILEおよびSDFを使用した廃棄ファイルの処理方法

LOBFILEおよびSDFのデータは、廃棄された行がある場合も、廃棄ファイルには書き込まれません。

コマンドラインからの廃棄ファイルの指定

コマンドラインから廃棄ファイルを指定する方法の詳細は、「DISCARD」を参照してください。

コマンドラインで指定したファイル名で、制御ファイルに指定した廃棄ファイルが上書きされます。

表レベルでのNULLIF句の指定

表レベルでNULLIF句を指定できます。構文は次のとおりです:

NULLIF {=|!=}{"char_string"|x'hex_string'|BLANKS}

char_stringおよびhex_stringの値は、一重引用符または二重引用符で囲む必要があります。

この指定は、NULLIF句がフィールド・レベルで指定されていないかぎり、マップされた文字フィールドごとに使用されます。フィールド・レベルで指定されたNULLIF句は、表レベルで指定されたNULLIF句に優先します。

SQL*Loaderは、レコードのフィールドの値に基づいて、指定された値を確認します。等号または不等号の指定を使用して一致した場合、フィールドはその行でNULLに設定されます。空白の切捨て後に長さが0になったフィールドも、すべてNULLに設定されます。

デフォルトのNULLIFまたは他の任意のNULLIF句をフィールドに適用しない場合、フィールド・レベルでNO NULLIFを指定できます。

関連項目:

- フィールド・レベルでNULLIF句を指定する方法の詳細は、「WHEN、NULLIFおよびDEFAULTIF句の使用」を参照してください

表レベルでの日時書式の指定

SQL*Loader制御ファイルにおいて、表レベルで特定の日時書式を指定できます。各構文は次のとおりです。

DATE FORMAT mask
TIMESTAMP FORMAT mask
TIMESTAMP WITH TIME ZONE mask
TIMESTAMP WITH LOCAL TIME ZONE mask

この指定は、異なるマスクがフィールド・レベルで指定されていないかぎり、日付またはタイムスタンプ・フィールドごとに使用されます。フィールド・レベルで指定されたマスクは、表レベルで指定されたマスクに優先します。

次に、SQL*Loader制御ファイルでのDATE FORMAT句の使用例を示します。DATE FORMAT句は、hiredateおよびentrydateフィールドのフィールド・レベルのDATEによって上書きされます。

LOAD DATA
INFILE myfile.dat
APPEND
INTO TABLE EMP
FIELDS TERMINATED BY ","
DATE FORMAT "DD-Month-YYYY"
(empno,
ename,
job,
mgr,
hiredate DATE,
sal,
comm,
deptno,
entrydate DATE)

関連項目:

- フィールド・レベルで日時データ型を指定する方法の詳細は、「日時および間隔のデータ型」を参照してください

異なる文字コード体系の処理

SQL*Loaderでは、(キャラクタ・セットまたはコード・ページと呼ばれる)異なる文字コード体系がサポートされます。SQL*Loaderでは、Oracleグローバリゼーション・サポート・テクノロジの機能を使用して、様々な文字コード体系(シングルバイトおよびマルチバイト)を扱うことができます。

関連項目:

『Oracle Databaseグローバリゼーション・サポート・ガイド』

次の項では、サポートしている文字コード体系について簡単に説明します。

マルチバイト(アジア系言語)・キャラクタ・セット

マルチバイト・キャラクタ・セットは、アジア系言語をサポートするために使用されます。データをマルチバイト形式でロードしたり、データベース・オブジェクト名(フィールド、表など)をマルチバイト文字で指定することもできます。制御ファイルでは、コメントおよびオブジェクト名にもマルチバイト文字を使用できます。

Unicodeキャラクタ・セット

SQL*Loaderでは、Unicodeキャラクタ・セットのデータのロードがサポートされています。

Unicodeは、エンコーディングされたユニバーサル・キャラクタ・セットであり、単一のキャラクタ・セットでほとんどの言語による情報の格納をサポートします。Unicodeでは、プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が指定されます。Unicodeには、2つの異なるエンコーディング(UTF-16およびUTF-8)が存在します。

注意:

このマニュアルでは、UTF-16およびUTF16の両方の用語が使用されています。UTF-16という用語は、一般的にUnicodeのUTF-16エンコーディングを意味します。UTF16(ハイフンなし)という用語は、キャラクタ・セットの固有の名前で、UTF-16エンコーディングの使用時にCHARACTERSETパラメータに指定する必要のある用語です。UTF-8およびUTF8の場合も同様です。

UnicodeのUTF-16エンコーディングは、固定幅マルチバイト・エンコーディングで、文字コード0x0000から0x007fは、シングルバイトASCIIコードの0x00から0x7fと同じ意味です。

UnicodeのUTF-8エンコーディングは、可変幅マルチバイト・エンコーディングで、文字コード0x00から0x7fがASCIIと同じ意味です。UTF-8の文字は1バイト、2バイトまたは3バイトの長さになります。

関連項目:

- 「事例11: Unicodeキャラクタ・セットのデータのロード」(事例の使用方法については、「SQL*Loaderの事例」を参照)

- Unicodeのエンコーディングの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

データベース・キャラクタ・セット

Oracle Databaseでは、SQLのCHARデータ型(CHAR、VARCHAR2、CLOBおよびLONG)に格納されたデータ、表名などの識別子、SQL文およびPL/SQLソース・コードに対して、データベース・キャラクタ・セットが使用されます。シングルバイト・キャラクタ・セットおよびASCII文字またはEBCDIC文字のいずれかを含む可変幅キャラクタ・セットのみがデータベース・キャラクタ・セットとしてサポートされます。マルチバイト固定幅キャラクタ・セット(たとえば、AL16UTF16)は、データベース・キャラクタ・セットとしてサポートされません。

SQLのNCHARデータ型(NCHAR、NVARCHAR2およびNCLOB)に格納されたデータ用のデータベースでは、代替キャラクタ・セットを使用できます。代替キャラクタ・セットは、データベース各国語キャラクタ・セットと呼ばれます。Unicodeキャラクタ・セットのみが、データベース各国語キャラクタ・セットとしてサポートされます。

データ・ファイル・キャラクタ・セット

デフォルトでは、データ・ファイルには、NLS_LANGパラメータで定義されているキャラクタ・セットが使用されます。NLS_LANGでサポートされているデータ・ファイル・キャラクタ・セットは、データベース・キャラクタ・セットとしてサポートされているものと同じです。SQL*Loaderでは、データ・ファイル内のOracleでサポートされているすべてのキャラクタ・セットがサポートされます(データベース・キャラクタ・セットとしてサポートされていないものもサポートされます)。

たとえば、SQL*Loaderでは、データ・ファイル内のマルチバイト固定幅キャラクタ・セット(AL16UTF16、JA16EUCFIXEDなど)がサポートされます。また、SQL*Loaderでは、リトル・エンディアン・バイト順序によるUTF-16エンコーディングもサポートされます。ただし、Oracle Databaseでは、ビッグ・エンディアン・バイト順序によるUTF-16エンコーディング(AL16UTF16)のみが、データベース・キャラクタ・セットとしてではなく、データベースの各国語キャラクタ・セットとしてのみサポートされます。

データ・ファイルのキャラクタ・セットは、NLS_LANGパラメータ、またはSQL*LoaderのCHARACTERSETパラメータを使用して設定できます。

入力文字の変換

CHARACTERSETパラメータが指定されていない場合、すべてのデータ・ファイルに対するデフォルトのキャラクタ・セットは、NLS_LANGパラメータで定義されたセッション・キャラクタ・セットです。入力データ・ファイルで使用されるキャラクタ・セットは、CHARACTERSETパラメータで指定できます。

SQL*Loaderでは、データ・ファイル・キャラクタ・セット、データベース・キャラクタ・セットおよびデータベース各国語キャラクタ・セットが異なる場合、データ・ファイルのデータをデータベース・キャラクタ・セットまたはデータベース各国語キャラクタ・セットに自動的に変換できます。

データのキャラクタ・セット変換が必要な場合、ターゲットのキャラクタ・セットは、ソースのデータ・ファイル・キャラクタ・セットのスーパーセットである必要があります。そうでない場合、ターゲット・キャラクタ・セットに同じ文字がない文字は、置換文字(通常、疑問符(?)などのデフォルトの文字)に変換されます。これによって、データが失われます。

データベース・キャラクタ・タイプCHARおよびVARCHAR2のサイズは、バイト単位(バイト長セマンティクス)または文字単位(文字長セマンティクス)で指定できます。バイト単位で指定され、データ・キャラクタ・セットの変換が必要な場合、変換される文字のソース・キャラクタ・セットより多くのバイトがターゲット・キャラクタ・セットで使用されると、変換後の値はソースの値より大きくなることがあります。これによって、ターゲットの大きい値がデータベースの列のサイズを超える場合、次のエラー・メッセージがレポートされます。

ORA-01401: inserted value too large for column

データベースの列サイズを文字単位で指定するか、または制御ファイルの文字サイズを使用してデータを記述することによっても、この問題を回避できます。また、最大列サイズがバイト単位で、変換後の値を保持できる大きさであることを確認する方法もあります。

関連項目:

- 「文字長セマンティクス」

- 『Oracle Databaseグローバリゼーション・サポート・ガイド』

VARRAYまたは主キー・ベースREFへのデータ・ロード時の考慮事項

SQL*Loaderの従来型パスまたはOracle Call Interface(OCI)を使用して、VARRAYまたは主キー・ベースREFに、データベース・キャラクタ・セットとは異なるキャラクタ・セットのデータをロードする場合は、次のような問題が発生する可能性があります。

- データベースの列に対してフィールドが大きすぎるという理由で、実際には大きすぎない場合でも、行が拒否される可能性があります。

- 大きすぎるフィールドのみが拒否されるロード処理で、1行もロードされないまま異常終了する可能性があります。

- 主キー・ベースREF列をSQL*Plusで選択した場合、それらの列が空白として返されるにもかかわらず、行が正しくロードされたようにレポートされる可能性があります。

これらの問題を回避するには、データをロードする前にNLS_LANG環境変数を使用して、クライアントのキャラクタ・セットをデータベース・キャラクタ・セットに設定します。

CHARACTERSETパラメータ

CHARACTERSETパラメータを指定して、SQL*Loaderに入力データ・ファイルのキャラクタ・セットを示します。CHARACTERSETパラメータが指定されていない場合、すべてのデータ・ファイルに対するデフォルトのキャラクタ・セットは、NLS_LANGパラメータで定義されたセッション・キャラクタ・セットです。文字データ(SQL*Loaderデータ型のCHAR、VARCHAR、VARCHARC、数値型EXTERNALおよび日時データ型と期間データ型のフィールド)のみが、データ・ファイルのキャラクタ・セットに影響されます。

CHARACTERSETの構文は次のとおりです。

CHARACTERSET char_set_name

char_set_name変数で、キャラクタ・セット名を指定します。通常、指定された名前はOracleがサポートしているキャラクタ・セットの名前である必要があります。

UnicodeのUTF-16エンコーディングの場合は、名前はAL16UTF16でなくUTF16を使用します。AL16UTF16(UTF-16エンコードされたデータに対してサポートされるOracleキャラクタ・セット名)は、ビッグ・エンディアンのバイト順序のUTF-16データにのみ使用されます。ただし、データ・ファイルを作成したシステムのバイト順序を使用してデータを設定することが許可されているため、データ・ファイル内のデータはビッグ・エンディアンまたはリトル・エンディアンのいずれかにできます。このため、異なるキャラクタ・セット名(UTF16)が使用されます。また、キャラクタ・セット名AL16UTF16もサポートされています。ただし、リトル・エンディアンのバイト順序のデータ・ファイルにAL16UTF16を指定すると、SQL*Loaderによって警告メッセージが発行され、データ・ファイルはリトル・エンディアンとして処理されます。

CHARACTERSETパラメータは、LOBFILEおよびSDFのみでなくプライマリ・データ・ファイルに対しても指定できます。すべてのプライマリ・データ・ファイルは同じキャラクタ・セットとみなされます。INFILEパラメータの前に指定されるCHARACTERSETパラメータは、プライマリ・データ・ファイルのリスト全体に適用されます。CHARACTERSETパラメータがプライマリ・データ・ファイルに対して指定される場合、指定された値は、LOBFILEおよびSDFのデフォルトとしても使用されます。LOBFILEまたはSDF仕様でCHARACTERSETパラメータを指定すると、デフォルト設定は上書きされます。

CHARACTERSETパラメータで指定されたキャラクタ・セットは、制御ファイルのINFILE句で指定されたデータには適用されません。制御ファイルは、常に、NLS_LANGパラメータで指定されているセッション・キャラクタ・セットを使用して処理されます。したがって、NLS_LANGパラメータで指定されているセッション・キャラクタ・セット以外のキャラクタ・セットでデータをロードするには、そのデータを別のデータ・ファイルに置く必要があります。

関連項目:

- 「バイト順序」

- サポートされているキャラクタ・セット名の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください

- 「制御ファイル・キャラクタ・セット」

- リトル・エンディアンのUTF-16でエンコーディングされたデータを含むデータ・ファイルをロードする例については、「事例11: Unicodeキャラクタ・セットのデータのロード」を参照してください。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

制御ファイル・キャラクタ・セット

SQL*Loader制御ファイル自体のキャラクタ・セットは、NLS_LANGパラメータで指定されているセッション・キャラクタ・セットであることが前提です。制御ファイル・キャラクタ・セットがデータ・ファイル・キャラクタ・セットと異なる場合は、次のことに注意してください。SQL*Loader制御ファイルで文字列として指定されたデリミタおよび比較句の値は、比較が行われる前に、制御ファイル・キャラクタ・セットからデータ・ファイル・キャラクタ・セットに変換されます。正しく指定するには、文字列値ではなく16進文字列を指定してください。

16進文字列がUnicodeのUTF-16エンコーディングのデータ・ファイルで使用される場合、ビッグ・エンディアンのシステムとリトル・エンディアンのシステムでバイト順序が異なります。たとえば、ビッグ・エンディアンのシステムでは、UTF-16の「,」(カンマ)はX'002c'です。リトル・エンディアンのシステムではX'2c00'です。SQL*Loaderでは、常に、ビッグ・エンディアン形式で16進文字列を指定する必要があります。必要に応じて、比較が行われる前に、SQL*Loaderによってバイトが交換されます。これによって、ビッグ・エンディアンおよびリトル・エンディアンの両システム上の制御ファイルで同じ構文を使用することができます。

UnicodeのUTF-16エンコーディングのストリーム形式のデータ・ファイルで使用されるレコード終了記号のデフォルトは、UTF-16では「\n」(ビッグ・エンディアンのシステムでは0x000Aで、リトル・エンディアンのシステムでは0x0A00)です。INFILE行上の"STR 'char_str'"指定または "STR x'hex_str'"指定を使用して、これらのデフォルト設定を上書きできます。たとえば、次のいずれかの行を使用して、'\n'のかわりに'ab'をレコード終了記号として使用できます。

INFILE myfile.dat "STR 'ab'"

INFILE myfile.dat "STR x'00410042'"

BEGINDATA文の後に指定するデータも、NLS_LANGパラメータで指定されたセッション・キャラクタ・セットであることが前提です。

SQL*Loaderのデータ型(CHAR、VARCHAR、VARCHARC、DATEおよび数値型EXTERNAL)に関して、SQL*Loaderでは、バイト単位(バイト長セマンティクス)または文字単位(文字長セマンティクス)のいずれかで指定される文字フィールドの長さがサポートされます。たとえば、制御ファイルでのCHAR(10)指定は、10バイトまたは10文字を意味します。データ・ファイルでシングルバイト・キャラクタ・セットが使用されている場合、これらは同じです。ただし、データ・ファイルでマルチバイト・キャラクタ・セットが使用されている場合、異なることもあります。

キャラクタ・セット変換中に文字列の拡張によって発生する挿入エラーを回避するには、データ・ファイルおよびターゲット・データベースの列の両方で文字長セマンティクスを使用します。

文字長セマンティクス

バイト長セマンティクスは、UTF16キャラクタ・セット(デフォルトで文字長セマンティクスを使用します)を使用するデータ・ファイル以外のすべてのデータ・ファイルのデフォルトです。デフォルトに上書きするには、次の構文で示すとおり、CHARまたはCHARACTERを指定します。

LENGTHパラメータは、SQL*Loader制御ファイルのCHARACTERSETパラメータの後に置かれます。LENGTHパラメータは、プライマリ・データ・ファイルに関する構文の指定のみではなく、LOBFILEデータ・ファイルおよびセカンダリ・データ・ファイル(SDF)にも適用されます。INFILEパラメータの前のLENGTH指定は、プライマリ・データ・ファイルのリスト全体に適用されます。プライマリ・データ・ファイルに対するLENGTH指定は、LOBFILEおよびSDFに対するデフォルトとして使用されます。LOBFILEおよびSDF仕様でLENGTHを指定することによって、デフォルトを上書きできます。CHARACTERSETパラメータとは異なり、LENGTHパラメータは、制御ファイル内に含まれるデータ(INFILE *構文)に適用されます。

LENGTHパラメータに対しては、CHARのかわりにCHARACTERを指定できます。

文字長セマンティクスがSQL*Loaderのデータ・ファイルに対して使用されている場合は、次のSQL*Loaderデータ型で文字長セマンティクスが使用されます。

- CHAR

- VARCHAR

- VARCHARC

- DATE

- 数値型EXTERNAL(INTEGER、FLOAT、DECIMALおよびZONED)

VARCHARデータ型では、長さサブフィールドはバイナリのSMALLINT長さサブフィールドです。ただし、その値は文字単位の文字列の長さを示します。

次のデータ型では、データ・ファイルで文字長セマンティクスが使用されていてもバイト長セマンティクスを使用します。これは、データがバイナリであるか、またはZONEDおよびDECIMALの場合は、特別にバイナリにエンコーディングされた形式であるためです。

- INTEGER

- SMALLINT

- FLOAT

- DOUBLE

- BYTEINT

- ZONED

- DECIMAL

- RAW

- VARRAW

- VARRAWC

- GRAPHIC

- GRAPHIC EXTERNAL

- VARGRAPHIC

POSITIONパラメータの開始引数および終了引数は、文字長セマンティクスがデータ・ファイルで使用されていても、バイト単位で解釈されます。これは、異なるデータ型のデータが混在するデータ・ファイル(一部では文字長セマンティクスを使用し、一部ではバイト長セマンティクスを使用する)を処理する場合に必要です。SMALLINT長さフィールドおよび文字データを含むVARCHARデータ型で位置を処理する場合にも必要です。SMALLINT長さフィールドは、システムによって一定のバイト数(通常、2バイト)を必要とします。ただし、その値は、文字列の長さを文字単位で示します。

データ・ファイルの文字長セマンティクスは、データベースの列で文字長セマンティクスが使用されているかどうかに関係なく使用できます。したがって、データ・ファイルおよびデータベースの列で、同じまたは異なる長さのセマンティクスを使用できます。

シフト・センシティブ文字データ

通常、シフト・センシティブ文字データのロードは、ASCIIデータまたはEBCDICデータのロードに比べて非常に遅くなります。シフト・センシティブ文字データを最速でロードするには、デリミタのない固定位置フィールドを使用します。パフォーマンスを向上させるには、次の点に注意してください。

- フィールド・データに、同数のシフトアウト/シフトイン・バイトが含まれる必要があります。

- フィールドは、シングルバイト・モードで開始および終了する必要があります。

- 最初のバイトをシフトアウト、最後のバイトをシフトインにできます。

- 最初と最後の文字は、マルチバイトにできません。

- 空白が保存され、マルチバイトの空白を確認する必要がある場合、より遅いパスが使用されます。これは、シングルバイトの空白の削除が実行された後、シフトイン・バイトがフィールドの最後のバイトとなる場合に、発生する可能性があります。

中断されたロード

ロードは様々な理由で中断されます。主な理由は領域エラーで、SQL*Loaderで使用されるデータ行および索引エントリ用の領域の不足によって発生します。エラーの最大数を超えた場合、サーバーからSQL*Loaderに予期しないエラーが返された場合、レコードがデータ・ファイルに対して長すぎた場合、または[Ctrl]キーを押しながら[C]キーを押した場合にも、ロードが中断されます。

ロードが中断された場合のSQL*Loaderの動作は、ロードのモードが従来型パス・ロードかダイレクト・パス・ロードか、およびロードが中断された理由によって異なります。また、中断されたロードを継続する場合、SKIPパラメータを使用するかどうか、およびこのパラメータに指定する値は、状況によって異なります。次の項に例を示します。

関連項目:

「SKIP」

中断された従来型パス・ロード

従来型パス・ロードでは、バインド配列のすべてのデータがすべての表にロードされた後で、データがコミットされます。ロードが中断された場合は、直前のコミット操作の時点までに処理された行のみがロードされます。データの部分コミットは行われません。

中断されたダイレクト・パス・ロード

ダイレクト・パス・ロードでは、中断されたロードの動作は、ロードが中断された理由によって異なります。

- 領域エラーによって中断されたロード

- エラーが最大数を超えたことによって中断されたロード

- 致命的エラーによって中断されたロード

- [Ctrl]キーを押しながら[C]キーを押すことによって中断されたロード

領域エラーによって中断されたロード

領域エラーが原因でロードが中断されたときのSQL*Loaderの動作は、データを複数のサブパーティションにロード中だったかどうかで異なります。

- データを複数のサブパーティションにロードしているとき(パーティション表、コンポジット・パーティション表、またはコンポジット・パーティション表の1つのパーティションにロードしているとき)に領域エラーが発生した場合
複数のサブパーティションへのロード中に領域エラーが発生した場合、ロードは中断され、ROWSが指定されていなければデータは保存されません(この場合、コミット済のデータはすべて保存されます)。このような動作は、行が順不同にロードされる可能性を考慮したためです。順不同になるのは、それぞれの行が順序を考慮せずにパーティションに割り当てられ、そのパーティションが別々にロードされることが原因です。パーティションに割り当てられているすべての行がロードされる前にロードが中断されると、レコード番号nの行はロードされていても、レコード番号n-1の行がロードされていない可能性があります。したがって、単純にSKIP=Nを使用するだけではロードを続行できません。

- 非パーティション表、パーティション表の1つのパーティション、またはコンポジット・パーティション表の1つのサブパーティションにデータをロードしているときに、領域エラーが発生した場合
制御ファイルに記述されているINTO TABLE文が1つの場合、SQL*Loaderは、エラーが発生する前にロードされていた行と同じ数の行をコミットします。

制御ファイルにINTO TABLE文が複数ある場合、SQL*Loaderは、データ・ファイルから他の表に読取り済のデータをロードし、そのデータをコミットします。

いずれの場合も、この動作は、ROWSパラメータが指定されていたかどうかに関係なく実行されます。ロードを継続する場合は、SKIPパラメータを使用して、ロード済の行をスキップできます。INTO TABLE文が複数あった場合は、それぞれの表に異なる数の行がロードされている可能性があります。したがって、ロードを継続するには、表ごとに異なるSKIPパラメータの値を指定することが必要な場合があります。SKIPパラメータの値がすべての表で同じ場合にのみ、SQL*Loaderによってその値が報告されます。

エラーが最大数を超えたことによって中断されたロード

エラーが最大数を超えると、SQL*Loaderによって、すべての表へのレコードのロードが停止され、その時点までに終了している処理がコミットされます。ロードを継続する場合、SKIPパラメータに指定する値は表によって異なります。SKIPパラメータの値がすべての表で同じ場合にのみ、SQL*Loaderによってその値が報告されます。

致命的エラーによって中断されたロード

致命的エラーが発生した場合は、ロードが停止されます。ロードの開始時にROWSが指定されていないかぎり、データは保存されません。指定されている場合、コミット済のすべてのデータが保存されます。SKIPパラメータの値がすべての表で同じ場合にのみ、SQL*Loaderによってその値が報告されます。

[Ctrl]キーを押しながら[C]キーを押すことによって中断されたロード

SQL*Loaderによるデータの保存中に[Ctrl]キーを押しながら[C]キーを押すと、データの保存は継続され、保存の完了後にロードが停止されます。データを保存中でない場合は、コミットされていない処理をコミットせずにロードが停止されます。つまり、SKIPパラメータの値は、すべての表で同じになります。

ロードの中断後の表および索引の状態

ロードが中断されると、すでにロードされたデータはそのまま表に残り、その表は有効な状態のままとなります。従来型パスを使用した場合、すべての索引は有効な状態のままとなります。

ダイレクト・パス・ロード方法を使用した場合は、表の索引はすべて使用禁止状態のままになります。このような索引は、継続処理をする前、またはロードが再開されすべて終了した後に、再構築または再作成できます。

これ以外の索引は、他にエラーが発生していないかぎり有効です。索引が使用禁止状態のままになるその他の理由については、「使用禁止状態(Index Unusable)のままの索引」を参照してください。

ログ・ファイルを使用したロード状態の確認

SQL*Loaderのログ・ファイルには、表や索引の状態、および入力データ・ファイルから読み込まれた論理レコード数の情報が記録されます。これらの情報は、中断されたロードを再開する場合に利用できます。

単一表へのロードの継続

ダイレクト・パス・ロードまたは従来型パス・ロードを、終了前にSQL*Loaderで中断する必要がある場合は、すでにコミットされているか、またはセーブポイントが付けられている行が存在しています。中断されたロードを継続するには、SKIPパラメータを使用して、前回のロードによってすでに処理されている論理レコードの数を指定します。ロードの中断時に、次のようなメッセージ形式でログ・ファイルにSKIPの値が書き込まれます。

Specify SKIP=1001 when continuing the load.

SKIPパラメータの値を指定するこのメッセージの前には、ロードが中断された理由を示すメッセージが書き込まれています。

複数表へのロードの場合は、SKIPパラメータの値がすべての表で同じ場合にのみ、値が表示されます。

関連項目:

「SKIP」

物理レコードからの論理レコードの作成

複数の物理レコードを1つの論理レコードに結合するには、対象とするデータによって、次の句のうちの1つを指定します。

- CONCATENATE

- CONTINUEIF

CONCATENATEを使用した論理レコードの作成

常に一定の数の物理レコードを結合して1つの論理レコードを構成する場合、CONCATENATEを使用します。次の例では、integerによって結合する物理レコードの数を指定します。

CONCATENATE  integer

CONCATENATEに指定された整数値によって、SQL*Loaderで列配列の各行に割り当てられる物理レコード構造の数が決まります。ダイレクト・パス・ロードでは、COLUMNARRAYROWSのデフォルト値が大きいため、CONCATENATEにも大きい値を指定すると、メモリーの過剰割当てが発生する可能性があります。この場合は、COLUMNARRAYROWSパラメータの値を小さくして列配列の行の数を減らすことによって、パフォーマンスを向上できます。

関連項目:

- 「COLUMNARRAYROWS」

- 「列配列の行数およびストリーム・バッファ・サイズの指定」

CONTINUEIFを使用した論理レコードの作成

CONTINUEIFは、結合する物理レコードの数が異なる場合に使用します。CONTINUEIF句を使用する場合は、後に条件を指定します。この条件は、各物理レコードが読み込まれるたびに評価されます。たとえば、2つのレコードがあって、その最初のレコードの80バイト目にシャープ記号(#)がある場合、2つのレコードは結合されます。この場合、指定の位置に他の文字があると、2番目のレコードは最初のレコードに結合されません。

次に、CONTINUEIFの完全な構文を示します。この構文で、さらに柔軟な処理を実行できます。

表9-2では、CONTINUEIF句のパラメータについて説明します。

表9-2 CONTINUEIF句のパラメータ

パラメータ

説明

THIS

現在のレコードについて条件が真のとき、次の物理レコードを読み込んで現在のレコードに連結します。この処理は、条件が偽になるまで繰り返されます。条件が偽になると、現在の物理レコードが現在の論理レコードを構成する最後の物理レコードになります。THISはデフォルトです。

NEXT

次のレコードで条件が真になると、現在の物理レコードを現在の論理レコードに連結します。この処理は、条件が偽になるまで繰り返されます。

operator

サポートされているのは等号演算子(=)と不等号演算子(!= または<>)です。

等号演算子を指定すると、フィールドと比較文字列が完全に一致したときに、条件が真となります。不等号演算子を指定した場合は、どの文字が異なっていても、条件は真となります。

LAST

レコードの最後の文字(空白以外)に対して、THISと同様の条件判断を行います。現在の物理レコードの最後の文字(空白以外)が条件を満たしていると、次の物理レコードが読み込まれ、現在の物理レコードに連結されます。この処理は、条件が偽になるまで繰り返されます。現在のレコードに関して条件が偽になると、現在の物理レコードが現在の論理レコードを構成する最後の物理レコードになります。

LASTには、単一の文字継続フィールドのみを使用できます(これに対し、THISおよびNEXTには、複数の文字継続フィールドを使用できます)。

pos_spec

物理レコード中の列の開始番号と終了番号です。

列番号は1から始まります。ハイフンまたはコロンを使用することもできます(start-endまたはstart:end)。

endを省略すると、継続フィールドの長さには、指定されたバイト列または文字列の長さが取られます。endが指定されていて、それによって決まる継続フィールドの長さが指定されたバイト列または文字列の長さと異なる場合は、短い方に不足分を埋めるための文字が追加されます。文字列の場合は空白が追加され、16進数のバイト列の場合は0(ゼロ)が追加されます。

str

startとendで定義された継続フィールドと比較する文字列です。比較演算の内容は、operatorで指定された演算子によって異なります。文字列は一重引用符または二重引用符で囲みます。文字列は1文字ずつ比較され、必要があれば、空白埋め文字が右側に追加されます。

X'hex-str'

16進形式で指定された文字列で、使用方法はstrと同じです。たとえば、X'1FB033'と表記した場合は、1F、B0、33の値を持つ3バイトの16進文字列を意味します。

PRESERVE

論理レコードには'char_string'またはX'hex_string'が含まれます。デフォルトでは、これらは排除されます。

CONTINUEIF句の中で指定する位置は、各物理レコード中の位置を示します。物理レコード中の位置が参照されるのは、この場合のみです。これ以外の場合、参照先は論理レコードとなります。

CONTINUEIF THISおよびCONTINUEIF LASTでは、PRESERVEパラメータを指定しない場合、論理レコードの作成時にすべての物理レコードから継続フィールドが削除されます。継続フィールドが読み込まれるまでは、データは同じ論理レコードに連結します。たとえば、CONTINUEIF THIS(3:5)='***'を指定すると、3から5までの位置がすべてのレコードから削除されます。つまり、レコードの3から5までの位置にある継続文字が削除されます。また、3から5までの位置にある文字は、継続文字が3から5までの位置にない場合でもレコードから削除されます。

CONTINUEIF THISおよびCONTINUEIF LASTでは、PRESERVEパラメータを使用した場合、論理レコードの作成時にすべての物理レコードに継続フィールドが保持されます。

CONTINUEIF LASTは、CONTINUEIF THISおよびCONTINUEIF NEXTとは異なります。CONTINUEIF LASTでは、継続フィールドの位置がレコードごとに異なり、PRESERVEが指定されていない場合でも、継続フィールドは削除されません。

例9-3から例9-6に、PRESERVEパラメータの有無にかかわらず、CONTINUEIF THISおよびCONTINUEIF NEXTの使用例を示します。

例9-3 PRESERVEパラメータを使用しないCONTINUEIF THIS

ここで、物理レコードは次のような14バイトのレコードとします。また、ピリオドは空白を表します。

%%aaaaaaaa....
%%bbbbbbbb....
..cccccccc....
%%dddddddddd..
%%eeeeeeeeee..
..ffffffffff..

次の例では、CONTINUEIF THIS句にPRESERVEパラメータは使用されていません。

CONTINUEIF THIS (1:2) = '%%'

したがって、論理レコードは次のように作成されます。

aaaaaaaa....bbbbbbbb....cccccccc....
dddddddddd..eeeeeeeeee..ffffffffff..

列1および列2(たとえば、物理レコード1の%%)は、論理レコード作成時に物理レコードから削除されることに注意してください。

例9-4 PRESERVEパラメータを使用するCONTINUEIF THIS

例9-3の物理レコードと同じ物理レコードがあるとします。

次の例では、CONTINUEIF THIS句にPRESERVEパラメータが使用されています。

CONTINUEIF THIS PRESERVE (1:2) = '%%'

したがって、論理レコードは次のように作成されます。

%%aaaaaaaa....%%bbbbbbbb......cccccccc....
%%dddddddddd..%%eeeeeeeeee....ffffffffff..

列1および列2は、論理レコード作成時に物理レコードから削除されないことに注意してください。

例9-5 PRESERVEパラメータを使用しないCONTINUEIF NEXT

ここで、物理レコードは次のような14バイトのレコードとします。また、ピリオドは空白を表します。

..aaaaaaaa....
%%bbbbbbbb....
%%cccccccc....
..dddddddddd..
%%eeeeeeeeee..
%%ffffffffff..

次の例では、CONTINUEIF NEXT句にPRESERVEパラメータは使用されていません。

CONTINUEIF NEXT (1:2) = '%%'

したがって、論理レコードは次のように作成されます(例9-3と同じ結果)。

aaaaaaaa....bbbbbbbb....cccccccc....
dddddddddd..eeeeeeeeee..ffffffffff..

例9-6 PRESERVEパラメータを使用するCONTINUEIF NEXT

例9-5の物理レコードと同じ物理レコードがあるとします。

次の例では、CONTINUEIF NEXT句にPRESERVEパラメータが使用されています。

CONTINUEIF NEXT PRESERVE (1:2) = '%%'

したがって、論理レコードは次のように作成されます。

..aaaaaaaa....%%bbbbbbbb....%%cccccccc....
..dddddddddd..%%eeeeeeeeee..%%ffffffffff..

関連項目:

CONTINUEIF句の例は、「事例4: 結合された物理レコードのロード」を参照してください。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

表への論理レコードのロード

この項では、次の内容について説明します。

- ロードする表の指定方法

- 表にロードするレコードの指定方法

- レコードに対するデフォルトのデータ・デリミタ

- データが欠落しているショート・レコードの処理方法

表名の指定

LOAD DATA文のINTO TABLE句を使用して、表、フィールドおよびデータ型を識別できます。この句で、データ・ファイル中のレコードとデータベース中の表の関係を定義します。フィールドやデータ型の指定については後述します。

INTO TABLE句

INTO TABLE句が持つ様々な機能の1つに、データのロード先となる表を指定する機能があります。複数の表にロードするには、それぞれの表に対してINTO TABLE句を指定する必要があります。

INTO TABLE句を記述する場合、キーワードINTO TABLEの次に、データを受け取るOracleの表名を指定します。

構文は次のとおりです:

表名には、すでに存在する表を指定してください。表名がSQLやSQL*Loaderの予約済キーワードと同じ場合、表名に特殊文字が含まれる場合、または表名の中の大/小文字を区別する必要がある場合は、表名を二重引用符で囲みます。

INTO TABLE scott."CONSTANT"
INTO TABLE scott."Constant"
INTO TABLE scott."-CONSTANT"

ユーザーが表をロードするには、INSERT権限が必要です。表がユーザーのスキーマにない場合、ユーザーはシノニムを使用して表を参照するか、またはスキーマ名を表名の一部として含める必要があります(たとえば、scott.empはscottスキーマの表empを参照します)。

注意:

SQL*Loaderでは、データベースへの接続処理を完了した後の現行のスキーマが、デフォルト・スキーマであるとみなされます。したがって、データベースへの接続中に実行されるログオン・トリガーが存在する場合は、接続文字列で指定されたスキーマがデフォルト・スキーマになるとはかぎりません。

特定のデータベースに接続した時点で現行のスキーマを別のスキーマに変更するログオン・トリガーが存在する場合は、その新しいスキーマがデフォルトとして使用されます。

表固有のロード方法

表のロード時に、INTO TABLE句を使用して、表固有のロード方法(INSERT、APPEND、REPLACEまたはTRUNCATE)を指定できます。指定したロード方法は、その表のみに適用されます。表固有のロード方法は、グローバルな表のロード方法よりも優先されます。INTO TABLE句の前にロード方法が特に指定されていない場合、グローバルな表のロード方法は、デフォルトでINSERTとなります。次の項では、これらのオプションを使用して空および空でない表へデータをロードする方法について説明します。

空の表へのデータのロード

ロード先の表が空の場合は、INSERTオプションを使用します。

INSERT

これは、SQL*Loaderのデフォルトの方法です。ロードする前に表を空にする必要があります。表に行が存在する場合はエラーが返され、ロードが終了します。「事例1: 可変長データのロード」に例があります。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

空でない表へのデータのロード

ロード先の表にすでにデータが存在する場合は、次の3つのオプションがあります。

- APPEND

- REPLACE

- TRUNCATE

注意:

REPLACEまたはTRUNCATEを指定すると、個々の行ではなく表全体が置き換えられます。行の削除が成功した後、COMMITが実行されます。ロード前に表にあったデータは、事前にエクスポートまたはそれに相当するユーティリティで保存しておかないかぎり、リカバリできません。

APPEND

表にデータがすでに存在する場合、SQL*Loaderで新しい行が表に追加されます。データが存在しない場合には、単に新しい行がロードされます。APPENDオプションを使用するには、SELECT権限が必要です。「事例3: 自由区分形式ファイルのロード」に例があります。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

REPLACE

REPLACEオプションを使用すると、SQLのDELETE FROM TABLE文が実行されます。表の既存の行はすべて削除され、新しくデータがロードされます。この場合、その表がロード実行者のスキーマ内に存在するか、ロード実行者がその表に対してDELETE権限を持っている必要があります。「事例4: 結合された物理レコードのロード」に例があります。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

行削除によって、その表に定義された削除トリガーが起動します。DELETE CASCADEが表に指定されている場合、カスケード化された削除が同様に実行されます。カスケード化された削除の詳細は、『Oracle Database概要』を参照してください。

既存の行の更新

REPLACEは、個々の行ではなく表を置換する方法です。既存レコードにNULL列があっても、そのレコードは更新されません。既存の行を更新するには、次の手順を実行してください。

1. データを作業表にロードします。

2. 相関副問合せを指定した、SQLのUPDATE文を使用します。

3. 作業表を削除します。

TRUNCATE

TRUNCATEオプションを使用すると、SQLのTRUNCATE TABLE table_name REUSE STORAGE文が実行され、表のエクステントが再利用されます。TRUNCATEオプションにより、表またはクラスタからすべての行が短時間で効率的に削除されるため、最大限の処理パフォーマンスを実現できます。TRUNCATE文を実行する前に、表の参照整合性制約を使用禁止にします。参照整合性制約が使用禁止でない場合、SQL*Loaderによってエラーが返されます。

整合性制約が使用禁止になると、その表に対してはDELETE CASCADEは定義されません。DELETE CASCADE機能が必要な場合は、ロードを開始する前に、表の内容を手動で削除する必要があります。

この場合、表がロード実行者のスキーマにあるか、ロード実行者がDROP ANY TABLE権限を所有している必要があります。

表固有のOPTIONSパラメータ

パラレル・ロードでは、個々の表に対してOPTIONSパラメータを指定できます(このパラメータは、パラレル・ロードの場合のみ有効です)。

OPTIONSパラメータの構文は次のとおりです。

関連項目:

「パラレル・ダイレクト・パス・ロードのパラメータ」

条件に基づいたレコードのロード

WHEN句を使用して論理レコード中の条件をテストし、その論理レコードをロードするか廃棄するかを選択できます。

WHEN句を表名の後に記述し、その後にフィールド条件を1つ以上指定します。field_conditionの構文は、次のとおりです。

たとえば、次のように指定すると、第5列の値がqであるレコードがすべてロードされます。

WHEN (5) = 'q'

WHEN句では各条件の前にANDを使用して、複数の条件を設定できます。小カッコの指定は任意ですが、ANDによって複数の条件を設定している場合は、あいまいさを避けるために必ず使用してください。次に例を示します。

WHEN (deptno = '10') AND (job = 'SALES')

関連項目:

- SQL*LoaderによるNULLIFおよびDEFAULTIF句に対するWHEN句の評価方法の詳細は、「WHEN、NULLIFおよびDEFAULTIF句の使用」を参照してください

- WHEN句の使用例は、「事例5: 複数表へのデータのロード」(事例の使用方法については、「SQL*Loaderの事例」)を参照してください

LOBFILEおよびSDFでのWHEN句の使用

LOBFILEまたはSDFのレコードが廃棄されると、SQL*LoaderによってそのLOBFILEまたはSDF内の対応するデータがスキップされます。

デフォルトのデータ・デリミタ(区切り記号)の指定

データ・ファイル中のデータ・フィールドがすべて同じ文字で終了している場合、FIELDS句を使用してデフォルトの終了デリミタおよび囲みデリミタを指定することができます。構文は次のとおりです:

fields_spec

関連項目:

- csv_clauseの詳細は、「CSV形式のファイルの指定」を参照してください

termination_spec

注意:

終了記号の文字列には、1つ以上の文字が含まれます。また、TERMINATED BY EOFは、LOBFILEからのLOBのロードにのみ適用されます。

enclosure_spec

注意:

囲み文字列には、1つ以上の文字が含まれます。

特定の列に対してデリミタを上書きする場合は、その列名の後に適用するデリミタを指定します。「事例3: 自由区分形式ファイルのロード」に例があります。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

関連項目:

- 構文の詳細は、「デリミタの指定」を参照してください

- 「LOBFILEからのLOBデータのロード」

データが欠落しているショート・レコードの処理

制御ファイルの定義で指定したフィールドの数が、実際にレコード中に存在するフィールドより多い場合、残りの(指定された余分の)列にNULL値を設定するか、またはエラーを出力するかがSQL*Loaderによって判断されます。

制御ファイルの定義でフィールドの開始位置として論理レコードの終了位置よりも後の位置が明示的に指定されている場合、SQL*Loaderによって、このフィールドにNULL値が設定されます。フィールドが(次に示す例の中のdnameおよびlocのように)相対位置に定義されていて、そのフィールドが現れる前にレコードのデータが終わった場合は、SQL*LoaderによってこのフィールドにNULL値が設定されるか、またはエラーが出力されます。SQL*Loaderによる処理は、TRAILING NULLCOLS句(次の構文図を参照)を指定しているかどうかによって決まります。

TRAILING NULLCOLS句

TRAILING NULLCOLS句を使用すると、相対位置で指定した列がレコード中に存在しない場合、その列の値はNULLとして処理されます。

たとえば、次のようなデータについて考えます。

10 Accounting

このデータが次の制御ファイルで読み込まれ、そのレコードはdnameの後で終了するとします。

INTO TABLE dept
TRAILING NULLCOLS
( deptno CHAR TERMINATED BY " ",
dname  CHAR TERMINATED BY WHITESPACE,
loc    CHAR TERMINATED BY WHITESPACE
)

この場合、その後のlocフィールドにはNULL値が設定されています。この例でTRAILING NULLCOLS句を指定しなかった場合は、データ欠落のためエラーとなります。

関連項目:

TRAILING NULLCOLSの使用例は、「事例7: 書式化されたレポートからのデータの抽出」(事例の使用方法については、「SQL*Loaderの事例」)を参照してください

索引オプション

この項では、索引エントリの作成方法を制御する次のSQL*Loaderオプションについて説明します。

- SORTED INDEXES

- SINGLEROW

SORTED INDEXES句

SORTED INDEXES句はダイレクト・パス・ロードに適用できます。このオプションを指定すると、入力データはロード前に指定の索引でソートされていることがSQL*Loaderで認識されるため、ロード時にはSQL*Loaderのパフォーマンスが最適化されます。

関連項目:

「SORTED INDEXES句」

SINGLEROWオプション

SINGLEROWオプションは、APPENDオプションを使用してかぎられたメモリーでダイレクト・パス・ロードを実行する場合、または少数のレコードを大規模な表にロードする場合に使用します。このオプションを使用すると、各索引エントリが、一度に1レコードずつ直接索引に挿入されます。

表に行を追加(APPEND)する場合、デフォルトではSINGLEROWは使用されません。この場合、索引エントリは個別の一時記憶域に置かれ、ロード終了時に元の索引とマージされます。この方法では、パフォーマンスが向上して最適な索引が作成されますが、記憶域も余分に必要となります。マージ処理が実行されている間は、元の索引、新しい索引、および新しいエントリのための領域が同時に記憶域を占有します。

SINGLEROWオプションの場合、新しい索引エントリや新しい索引のための記憶域は必要ありません。結果としてできる索引は、新しくソートされたものほど最適化されていない可能性がありますが、作成するための記憶域は少なくて済みます。ただし、各索引が挿入されるたびにUNDO情報が追加で作成されるため、時間がかかります。このオプションは、次の場合に使用してください。

- 使用可能な記憶域がかぎられている場合。

- ロードされる行数が表のサイズに比べて小さい場合(比率が1:20以下かどうかが目安になります)。

複数のINTO TABLE句を使用するメリット

複数のINTO TABLE句を指定すると、次の処理が可能になります。

- 異なる表へのデータのロード

- 1つの入力レコードからの複数の論理レコードの抽出

- 異なる入力レコード形式の区別

- 異なる入力行オブジェクト・サブタイプの区別

ここでは、まず、複数のINTO TABLE句で同じ表を参照するという最も一般的な使用方法を示します。この項では、複数のINTO TABLE句の様々な指定方法を説明します。また、POSITIONパラメータの指定方法についても説明します。

注意:

INTO TABLE句を複数指定した場合、次のINTO TABLE句の処理に移ったときのフィールド・スキャンは、前回フィールド・スキャンを停止した位置から続行されます。この項の残りの部分では、このような動作を利用する重要な方法について詳しく説明します。また、固定フィールド位置やPOSITIONパラメータを使用した別の手順についても説明します。

複数の論理レコードの抽出

データ記憶域および転送メディアには、物理レコードが固定長のものがあります。データ・レコードが比較的短い場合、メディアを効率的に使用するために複数の論理レコードをまとめて1つの物理レコードに記録できます。

ここでは、入力ファイルの1件の物理レコードを2件の論理レコードとみなし、INTO TABLE句を2回指定してemp表にデータをロードする方法について説明します。たとえば、次のようなデータの例を考えます。

1119 Smith      1120 Yvonne
1121 Albert     1130 Thomas

次の制御ファイルを使用して論理レコードを抽出します。

INTO TABLE emp
(empno POSITION(1:4)  INTEGER EXTERNAL,
ename POSITION(6:15) CHAR)
INTO TABLE emp
(empno POSITION(17:20) INTEGER EXTERNAL,
ename POSITION(21:30) CHAR)

デリミタに基づく相対的な位置指定

同じレコードを、別の指定方法でロードできます。次の制御ファイルでは、絶対的位置を指定するかわりに相対的な位置を指定しています。ここでは、各フィールドが空白(" ")1文字、またはいくつかの空白やタブ(WHITESPACE)で区切られていることを示しています。

INTO TABLE emp
(empno INTEGER EXTERNAL TERMINATED BY " ",
ename CHAR             TERMINATED BY WHITESPACE)
INTO TABLE emp
(empno INTEGER EXTERNAL TERMINATED BY " ",
ename CHAR)            TERMINATED BY WHITESPACE)

この例では、2番目のempnoフィールドは、別のINTO TABLE句に指定されていますが、1番目のenameの直後に指定されていることに注意してください。新しいINTO TABLE句に対して、レコードの先頭からのフィールド・スキャンが実行されるわけではありません。かわりに、前回スキャンが停止した位置から続行されます。

レコードのスキャンを特定の位置から強制的に開始するには、POSITIONパラメータを使用します。詳細は、「異なる入力レコード形式の区別」および「複数表へのデータのロード」を参照してください。

異なる入力レコード形式の区別

通常、データ・ファイルには様々な形式のレコードが含まれています。ここでは、次のようなデータについて考えます。この例では、emp表およびdept表のレコードが、データ中に混在しています。

1 50   Manufacturing       — DEPT record
2 1119 Smith      50       — EMP record
2 1120 Snyder     50
1 60   Shipping
2 1121 Stevens    60

これら2つの形式は、レコードIDフィールドで区別されます。部門レコードの最初の列は1、従業員レコードの最初の列は2になります。このデータをロードするため、次の制御ファイルではフィールドの正確な位置を指定しています。

INTO TABLE dept
WHEN recid = 1
(recid  FILLER POSITION(1:1)  INTEGER EXTERNAL,
deptno POSITION(3:4)  INTEGER EXTERNAL,
dname  POSITION(8:21) CHAR)
INTO TABLE emp
WHEN recid <> 1
(recid  FILLER POSITION(1:1)   INTEGER EXTERNAL,
empno  POSITION(3:6)   INTEGER EXTERNAL,
ename  POSITION(8:17)  CHAR,
deptno POSITION(19:20) INTEGER EXTERNAL)

POSITIONパラメータに基づく相対的な位置指定

前述の例のレコードは、デリミタ付きのデータとしてもロードできます。ただし、その場合はPOSITIONパラメータを使用する必要があります。次の制御ファイルを使用します。

INTO TABLE dept
WHEN recid = 1
(recid  FILLER INTEGER EXTERNAL TERMINATED BY WHITESPACE,
deptno INTEGER EXTERNAL TERMINATED BY WHITESPACE,
dname  CHAR TERMINATED BY WHITESPACE)
INTO TABLE emp
WHEN recid <> 1
(recid  FILLER POSITION(1) INTEGER EXTERNAL TERMINATED BY ' ',
empno  INTEGER EXTERNAL TERMINATED BY ' '
ename  CHAR TERMINATED BY WHITESPACE,
deptno INTEGER EXTERNAL TERMINATED BY ' ')

2番目のINTO TABLE句のPOSITIONパラメータは、このデータを正しくロードするために必要です。このように指定すると、2つ目の書式に一致するデータを確認するときのフィールド・スキャンは、列1から開始されます。この指定がない場合、SQL*Loaderでは、recidフィールドがdnameフィールドの後にあるものとしてスキャンされます。

異なる入力行オブジェクトのサブタイプの区別

通常、データ・ファイルには、同じ行オブジェクト型から継承された行オブジェクトで構成される単一のレコードが含まれています。たとえば、次のような単純なオブジェクト型およびオブジェクト表の定義について考えてみます。ここでは、NOT FINALのベース・オブジェクト型が、ベース型から行オブジェクトを継承する2つのオブジェクト・サブタイプとともに定義されています。

CREATE TYPE person_t AS OBJECT
(name    VARCHAR2(30),
age     NUMBER(3)) not final;

CREATE TYPE employee_t UNDER person_t
(empid   NUMBER(5),
deptno  NUMBER(4),
dept    VARCHAR2(30)) not final;

CREATE TYPE student_t UNDER person_t
(stdid   NUMBER(5),
major   VARCHAR2(20)) not final;

CREATE TABLE persons OF person_t;

次の入力データ・ファイルには、これらの行オブジェクト・サブタイプが混在しています。型IDフィールドは、3つのサブタイプで区別されます。person_tオブジェクトでは、最初の列にPがあり、employee_tオブジェクトではE、student_tオブジェクトではSがあります。

P,James,31,
P,Thomas,22,
E,Pat,38,93645,1122,Engineering,
P,Bill,19,
P,Scott,55,
S,Judy,45,27316,English,
S,Karen,34,80356,History,
E,Karen,61,90056,1323,Manufacturing,
S,Pat,29,98625,Spanish,
S,Cody,22,99743,Math,
P,Ted,43,
E,Judy,44,87616,1544,Accounting,
E,Bob,50,63421,1314,Shipping,
S,Bob,32,67420,Psychology,
E,Cody,33,25143,1002,Human Resources,

次の制御ファイルでは、POSITIONパラメータに基づく相対的な位置指定によって、このデータをロードします。固有のオブジェクト型名を持つTREAT AS句の使用方法に注意してください。これによって、オブジェクト表のすべての入力行オブジェクトが名前付きオブジェクト型の定義に準拠することが、SQL*Loaderで認識されます。

注意:

複数のサブタイプを同じINTO TABLE文ではロードできません。複数のINTO TABLE文を使用し、それぞれの文で異なるサブタイプをロードする必要があります。

INTO TABLE persons
REPLACE
WHEN typid = 'P' TREAT AS person_t
FIELDS TERMINATED BY ","
(typid   FILLER  POSITION(1) CHAR,
name            CHAR,
age             CHAR)

INTO TABLE persons
REPLACE
WHEN typid = 'E' TREAT AS employee_t
FIELDS TERMINATED BY ","
(typid   FILLER  POSITION(1) CHAR,
name            CHAR,
age             CHAR,
empid           CHAR,
deptno          CHAR,
dept            CHAR)

INTO TABLE persons
REPLACE
WHEN typid = 'S' TREAT AS student_t
FIELDS TERMINATED BY ","
(typid   FILLER  POSITION(1) CHAR,
name            CHAR,
age             CHAR,
stdid           CHAR,
major           CHAR)

関連項目:

オブジェクト型のロードの詳細は、「列オブジェクトのロード」を参照してください

複数表へのデータのロード

複数のINTO TABLE句でPOSITIONパラメータを指定すると、1件のレコードのデータを正規化された複数の表にロードできます。例については、「事例5: 複数表へのデータのロード」を参照してください。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

複数のINTO TABLE句使用のサマリー

複数のINTO TABLE句を指定すると、1件の入力レコードから複数の論理レコードを抽出できます。また、同一ファイル中の異なる形式のレコードを区別できます。

デリミタ付きデータの場合、期待する結果を得るには、POSITIONパラメータを正しく指定する必要があります。

複数のINTO TABLE句でPOSITIONパラメータを指定しない場合、1件の(デリミタ付きデータ)入力レコードの異なる部分が処理されます。これによって、1件のレコードから複数の表へのデータ・ロードが可能になります。複数のINTO TABLE句でPOSITIONパラメータを指定すると、同一のレコードを異なる方法で処理できます。つまり、1つの入力ファイルで複数の形式を識別できます。

バインド配列および従来型パス・ロード

SQL*Loaderでは、データのデータベースへの転送時にSQL配列インタフェース・オプションが使用されます。まず、一度に複数の行が読み込まれてバインド配列に格納されます。SQL*LoaderからOracle DatabaseにINSERTコマンドが送られると、配列全体が一度に挿入されます。バインド配列内の行が挿入された後、COMMIT文が発行されます。

バインド配列サイズを決定する必要があるのは、SQL*Loaderの従来型パス・オプションを使用する場合のみです。通常、これはダイレクト・パス・ロードによる方法では、使用されません。ダイレクト・パス・ロードでは、ダイレクト・パスAPIが使用されるためです。ただし、データ変換を必要とする特殊なダイレクト・パス・ロードの場合にはバインド配列を使用することができます。

関連項目:

ダイレクト・パス・ロードの概要は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください

バインド配列のサイズ要件

バインド配列には、1行以上が入る領域を確保してください。行の最大長が、BINDSIZEパラメータで指定されたバインド配列のサイズを超えると、SQL*Loaderからエラーが出力されます。通常、バインド配列内に入る範囲の行が格納されます。この場合の読取り行数の上限は、ROWSパラメータで指定された行数となります。(従来型パス・ロードでのROWSの最大値は65534です。)

バインド配列全体が連続するメモリーを占有する必要はありませんが、バインド配列内の各フィールドを格納するバッファには連続するメモリーが必要です。オペレーティング・システムで、フィールド格納用として連続する十分なメモリーを確保できないと、SQL*Loaderからエラーが出力されます。

関連項目:

- 「BINDSIZE」

- 「ROWS」

バインド配列のパフォーマンスに関する考慮点

バインド配列を大きくすると、Oracle Databaseへのコール数を最小に、またパフォーマンスを最大にできます。一般に、バインド配列サイズを大きくする場合、100行まではサイズの増加に比例してパフォーマンスが大幅に向上します。ただし、100行を超えるバインド配列サイズを設定しても、パフォーマンスはそれほど向上しません。したがって、一般に配列サイズ(バイト単位)は100行が目安となります。

一般に、サイズが適切であれば、SQL*Loaderで効果的に処理できます。通常は、この項で説明するような細かい計算をする必要はありません。この項は、パフォーマンスを最大にする場合、またはメモリー使用量を確認する場合に参照してください。

行数およびバインド配列サイズの指定

バインド配列サイズを指定する場合に、コマンドライン・パラメータBINDSIZEまたは制御ファイル中のOPTIONS句を使用すると、バインド配列の上限値が設定されます。バインド配列は、この上限値を超えることはありません。

初期化の段階で、SQL*Loaderでは単一行のロードに必要なサイズがバイト単位で決定されます。このサイズが指定された最大値を超える場合は、エラーが返され、ロードが終了します。

次にSQL*Loaderでは、このサイズとロードする行数が乗算されます。このとき、ロードする行数は、コマンドライン・パラメータROWSで指定されていても、制御ファイル中のOPTIONS句で指定されていてもかまいません。

このサイズがバインド配列の最大値を超えないかぎり、ロードは継続されます。SQL*Loaderでは、バインド配列の最大サイズの限界まで行数は拡張されません。行数とバインド配列の最大サイズの両方が指定された場合、SQL*Loaderでは、これらの値の小さい方がバインド配列に適用されます。

バインド配列の最大サイズが小さく、指定の行数を格納できない場合は、その最大サイズに収まる分の行数が採用されます。

バインド配列サイズを確認するための計算

バインド配列サイズは、配列内の行数に各行の最大長を掛け合せた値となります。行の最大長は、次のように、フィールドの最大長の合計にオーバーヘッドを加えた値となります。

bind array size =
(number of rows) * (  SUM(fixed field lengths)
+ SUM(maximum varying field lengths)
+ ( (number of varying length fields)
* (size of length indicator) )
)

ほとんどのフィールドのサイズは、固定長です。このような固定長フィールドの場合、ロードされる各行のサイズは同じです。固定長フィールドについては、「SQL*Loaderのデータ型」で説明するとおり、フィールド・サイズがフィールドの最大長(バイト)となります。そのため、オーバーヘッドは発生しません。

行によってサイズが変化するフィールドには、次のようなものがあります。

- CHAR

- DATE

- INTERVAL DAY TO SECOND

- INTERVAL DAY TO YEAR

- LONG VARRAW

- 数値型EXTERNAL

- TIME

- TIMESTAMP

- TIME WITH TIME ZONE

- TIME WITH TIME ZONE

- VARCHAR

- VARCHARC

- VARGRAPHIC

- VARRAW

- VARRAWC

これらのデータ型の最大長の詳細は、「SQL*Loaderのデータ型」を参照してください。ここでの最大長とは、入力データ・レコードの中でフィールドが占有できる長さを、バイト数で表したものです。この最大長は、バインド配列の中で各フィールドが占有する格納領域のサイズも表しています。バインド配列には、サイズが変化するこれらのフィールドについてのオーバーヘッドも含まれます。

文字データ型(CHAR、DATEおよび数値型EXTERNAL)がデリミタ付きで指定された場合は、これらのフィールドに対して指定されたフィールド長が最大長となります。逆に、デリミタなしでこれらのデータ型が指定された場合は、レコードのサイズは固定ですが、挿入時にフィールド中の空白文字が切り捨てられるため、フィールド長は変化します。したがって、これらのデータ型は、たとえ固定長フィールドであっても内部的には可変長フィールドとして扱われます。

長さインジケータは、バインド配列内のそれぞれのフィールドに格納されています。バインド配列におけるフィールドの領域として、そのフィールドの可能最大長のデータを格納できるだけのサイズが確保されています。一方、実際のフィールド長は、行ごとに長さインジケータで示されます。

注意:

従来型パス・ロードでは、バインド配列のサイズの割当て時にLOBFILEは含まれません。

長さインジケータのサイズの決定

ほとんどのシステムでは、長さインジケータのサイズは2バイトです。まれに3バイトのシステムもあります。長さインジケータのサイズを調べるには、次の制御ファイルを作成して実行します。

OPTIONS (ROWS=1)
LOAD DATA
INFILE *
APPEND
INTO TABLE DEPT
(deptno POSITION(1:1) CHAR(1))
BEGINDATA
a

この制御ファイルは、1行のバインド配列を使用して、1バイトのCHARをロードします。この例では、実際にデータはロードされません。これは、aを数値型の列(deptno)にロードすると、変換エラーが発生するためです。このときのログ・ファイルに示されたバインド配列サイズから、(文字フィールドの長さである)1を引いた値が、フィールド長のインジケータのサイズとなります。

注意:

これと同様の方法で、計算しないでバインド配列サイズを求めることもできます。制御ファイルにデータを記述せず、ROWS=1と指定して実行すると、1行のデータに必要なメモリーのサイズがわかります。このサイズとバインド配列に格納する行数を掛け合せれば、バインド配列サイズを判断できます。

フィールド・バッファ・サイズの計算

表9-3から表9-6の表に、各データ型のメモリー要件を示します。「L」は制御ファイルで指定したデータ長です。「P」は精度です。「S」はフィールド長インジケータのサイズです。これらの値の詳細は、「SQL*Loaderのデータ型」を参照してください。

表9-3 固定長フィールド

データ型

バイト単位のサイズ(オペレーティング・システムによって異なる)

INTEGER

C言語のINTデータ型に相当するサイズ

INTEGER(N)

Nバイト

SMALLINT

C言語のSHORT INTデータ型に相当するサイズ

FLOAT

C言語のFLOATデータ型に相当するサイズ

DOUBLE

C言語のDOUBLEデータ型に相当するサイズ

BYTEINT

C言語のUNSIGNED CHARデータ型に相当するサイズ

VARRAW

UNSIGNED SHORTに4096バイトまたはmax_lengthに指定した値をプラスしたサイズ

LONG VARRAW

UNSIGNED INTに4096バイトまたはmax_lengthに指定した値をプラスしたサイズ

VARCHARC

2つの数値で構成されます。最初に長さを指定し、次に(オプションで)max_length(デフォルトは4096バイト)を指定します。

VARRAWC

このデータ型はRAWデータ用です。2つの数値で構成されます。最初に長さを指定し、次に(オプションで)max_length(デフォルトは4096バイト)を指定します。

表9-4 非グラフィック・フィールド

データ型

デフォルト・サイズ

指定するサイズ

(パック)DECIMAL

「なし」

(N+1)/2切上げ

ZONED

「なし」

P

RAW

「なし」

L

CHAR型(デリミタなし)

1

L + S

日時データ型および期間データ型(デリミタなし)

「なし」

L + S

数値型EXTERNAL 型(デリミタなし)

「なし」

L + S

表9-5 グラフィック・フィールド

データ型

デフォルト・サイズ

POSITIONでの長さの指定

DATA TYPEでの長さの指定

GRAPHIC

「なし」

L

2×L

GRAPHIC EXTERNAL

「なし」

L-2

2×(L-2)

VARGRAPHIC

4KB×2

L+S

(2×L)+S

表9-6 可変長フィールド

データ型

デフォルト・サイズ

最大長の指定(L)

VARCHAR

4KB

L+S

CHAR型(デリミタ付き)

255

L+S

日時データ型および期間データ型(デリミタ付き)

255

L+S

数値型EXTERNAL型(デリミタ付き)

255

L+S

バインド配列用のメモリー所要量の最小化

VARCHAR型、VARGRAPHIC型フィールド、およびデリミタ付きのCHAR型、DATE型、数値型EXTERNAL型フィールドの場合、そのデータ型に割り当てられているデフォルト・サイズに特に注意してください。このデフォルト・サイズによっては、メモリーを大量に使用することがあります。特に、デフォルト・サイズにバインド配列の行数を掛け合せると、使用するメモリーは非常に大きくなります。これらのフィールドに対しては、最大長としてできるだけ小さな値を指定してください。次に例を示します。

CHAR(10) TERMINATED BY ","

バイト長セマンティクスを使用する場合、次の例では、バインド配列で(10+2)×64=768バイトのメモリーを使用します(ここでは、長さインジケータを2バイトで一度に64行ロードするとして計算しています)。

同じ例で文字長セマンティクスを使用する場合、バインド配列では((10 * s) + 2) * 64バイトのメモリーを使用します(ここでは、「s」はデータ・ファイル・キャラクタ・セットにおける1文字のバイト単位での最大サイズです)。

ここで、次の例について考えてみます。

CHAR TERMINATED BY ","

バイト長セマンティクスまたは文字長セマンティクスを使用しているかどうかにかかわらず、この例では、(255+2)×64=16,448バイトが必要になります。これは、デリミタ付きフィールドのデフォルト最大長が255バイトであるためです。この指定によって、バインド配列に入る行数が大きく違ってきます。

複数のINTO TABLE句に対するバインド配列サイズの計算

制御ファイルに複数のINTO TABLE句が指定されている場合のバインド配列サイズの計算は、複数のINTO TABLE句が指定されていない場合と同様に行います。いい換えると、制御ファイルに指定されているフィールド全体を1つの長いデータ構造体、つまりバインド配列の中の1行のデータ構造体であると考えます。

データ・レコード中の同じフィールドを複数のINTO TABLE句が参照する場合は、そのフィールドが参照されると、常に、バインド配列に追加の領域が必要となります。このようなフィールドについては、特にバッファの割当てを最小限に抑える必要があります。

注意:

CONSTANT、EXPRESSION、RECNUM、SYSDATEおよび SEQUENCEの各関数を指定すると、SQL*Loaderによってデータが生成されます。このようにして生成されたデータは、バインド配列の領域を必要としません。

10 SQL*Loaderフィールド・リスト・リファレンス

SQL*Loader制御ファイルのフィールド・リストには、位置、データ型、条件、デリミタなど、ロードするフィールドの情報が提供されます。これに関するSQL*Loader制御ファイルの詳細は、次の項目を参照してください。

- フィールド・リストの内容

- データ・フィールドの位置指定

- 列およびフィールドの指定

- SQL*Loaderのデータ型

- フィールド条件の指定

- WHEN、NULLIFおよびDEFAULTIF句の使用

- 異なるプラットフォーム間でのデータのロード

- バイト順序

- すべてが空白のフィールドのロード

- 空白の切捨て

- 空白の切捨てに対するPRESERVE BLANKSオプションの影響

- フィールドへのSQL演算子の適用

- SQL*Loaderを使用した入力データの生成

フィールド・リストの内容

SQL*Loader制御ファイルのフィールド・リストには、位置、データ型、条件、デリミタなど、ロードするフィールドの情報が提供されます。

例10-1に、「SQL*Loader制御ファイル・リファレンス」で説明したサンプル制御ファイルのフィールド・リスト・セクションを示します。

例10-1 サンプル制御ファイルのフィールド・リスト・セクション

.
.
.
1  (hiredate  SYSDATE,
2     deptno  POSITION(1:2)  INTEGER EXTERNAL(2)
NULLIF deptno=BLANKS,
3       job   POSITION(7:14)  CHAR  TERMINATED BY WHITESPACE
NULLIF job=BLANKS  "UPPER(:job)",
mgr    POSITION(28:31) INTEGER EXTERNAL
TERMINATED BY WHITESPACE, NULLIF mgr=BLANKS,
ename  POSITION(34:41) CHAR
TERMINATED BY WHITESPACE  "UPPER(:ename)",
empno  POSITION(45) INTEGER EXTERNAL
TERMINATED BY WHITESPACE,
sal    POSITION(51) CHAR  TERMINATED BY WHITESPACE
"TO_NUMBER(:sal,'$99,999.99')",
4      comm   INTEGER EXTERNAL  ENCLOSED BY '(' AND '%'
":comm * 100"
)

このサンプル制御ファイルの左側の数字は、実際の制御ファイルでは表示されません。これらの数字は、次の説明の番号に対応しています。

1. SYSDATEに、列を現在のシステム日付に設定します。詳細は、「列への現在の日付の設定」を参照してください。

2. POSITIONに、データ・フィールドの位置を指定します。詳細は、「データ・フィールドの位置指定」を参照してください。
INTEGER EXTERNALは、フィールドのデータ型です。詳細は、「データ・フィールドのデータ型の指定」および「数値型EXTERNAL」を参照してください。

NULLIF句は、フィールド条件の指定に使用する句の1つです。詳細は、「WHEN、NULLIFおよびDEFAULTIF句の使用」を参照してください。

このサンプルでは、BLANKSパラメータを使用して、フィールドを空白と比較しています。詳細は、「フィールドとBLANKSの比較」を参照してください。

3. TERMINATED BY WHITESPACE句は、フィールドを指定できるデリミタの1つです。詳細は、「デリミタの指定」を参照してください。

4. ENCLOSED BY句は、もう1つの使用可能なフィールド・デリミタです。詳細は、「デリミタの指定」を参照してください。

データ・フィールドの位置指定

データ・ファイルからデータをロードする場合は、フィールドの位置と長さをSQL*Loaderに対して明示する必要があります。論理レコード中のフィールド位置は、列指定の中でPOSITION句を使用して指定します。このときフィールド位置は、明示的に指定することも、前のフィールドからの相対位置で指定することもできます。POSITIONに対する引数は、カッコで囲む必要があります。文字長セマンティクスをデータ・ファイルに使用しても、start、endおよびintegerは、常にバイト単位です。

位置指定(pos_spec)句の構文は次のとおりです。

「データ・フィールドの位置指定」」では、位置指定句のパラメータについて説明します。

表10-1 位置指定句のパラメータ

パラメータ

説明

start

論理レコード中のデータ・フィールドの開始位置です。論理レコードの先頭バイト位置は1となります。

end

論理レコード中のデータ・フィールドの終了位置です。start-endと表記することも、start:endと表記することもできます。endを省略した場合、フィールド長は、データ・ファイル中のデータ型から導出されます。CHAR型では、startまたはendを省略し、長さ指定(CHAR(n))をしない場合、データ長が1として扱われます。データ型から長さを導出できない場合は、エラー・メッセージが出力されます。

*

対象となるデータ・フィールドが前のフィールドの直後にあることを示します。制御ファイル中の最初のデータ・フィールドに対して*を指定した場合、そのフィールドは論理レコードの先頭であると判断されます。位置指定に*を使用した場合、フィールド長はデータ型から導出されます。

+integer

+integerを指定してオフセットを使用すると、前フィールドの終了位置直後の位置から現行のフィールドをオフセットできます。この場合、現行のフィールドの値は、+integerで指定されたバイト数分スキップした後で読み込まれます。

POSITIONを完全に省略することも可能です。省略した場合のデータ・フィールドの位置指定は、POSITION(*)と指定した場合と同じです。

タブを含むデータでのPOSITIONの使用

フィールド位置の指定で、データ・ファイル中にタブが含まれている場合は注意が必要です。SQL*Loaderの拡張SQL文字列機能を使用して、書式化されたレポートのデータをロードするとします。最初に、レポートの印刷出力を見て、すべての文字位置を正確に調べ、制御ファイルを作成します。このような状況でデータをロードしようとすると、無効な数字および欠落フィールドによる多数のエラーが発生し、ロードが失敗する場合があります。

これらの種類のエラーはデータにタブが含まれる場合に発生します。用紙上では、各タブは複数の列に分かれて印刷されます。一方、データ・ファイル内では各タブは単なる1文字です。この結果、データ・ファイルがSQL*Loaderによって読み取られるとき、POSITION指定が正しくなくなります。

この問題を解決するには、データ・ファイル中のタブを探して該当箇所のPOSITION指定を調整するか、フィールドをデリミタで区切ります。

関連項目:

「デリミタの指定」

複数表のロードでのPOSITIONの使用

複数表のロードでは、複数のINTO TABLE句を指定します。このとき最初の表の最初の列に対してPOSITION(*)を使用すると、論理レコードの先頭から相対的に位置が計算されます。2番目以降の表の最初の列に対してPOSITION(*)が使用された場合は、その時点で最後にロードされた表の最終列から相対的に位置が計算されます。

したがって、2番目以降のINTO TABLE句の処理開始時に、位置が自動的に論理レコードの先頭に設定されるわけではありません。このため、複数のINTO TABLE句を指定して、同一物理レコード中の異なる箇所を処理できます。例については、「複数の論理レコードの抽出」を参照してください。

論理レコード中のデータには、2つの表の両方ではなく、片方の表のみにロードするデータもあります。その場合は、POSITIONを設定しなおす必要があります。このとき、位置指定を省略するか、またはINTO TABLE句で先頭フィールドに対するPOSITION(*+n)を指定するかわりに、POSITION(1)またはPOSITION(n)を指定します。

POSITIONを使用した例

siteid  POSITION (*) SMALLINT
siteloc POSITION (*) INTEGER

これらが最初の2つの列を指している場合、siteidは1列目から始まり、sitelocがその次の列から始まります。

ename  POSITION (1:20)  CHAR
empno  POSITION (22-26) INTEGER EXTERNAL
allow  POSITION (*+2)   INTEGER EXTERNAL TERMINATED BY "/"

列enameは、位置1から20までを占める文字データで、その次の列empnoは、位置22から26までを占める数値型データです。列allowは、empnoの終了直後の位置(27)から+2の位置、つまり列29から、スラッシュが検出されるまでのデータとなります。

列およびフィールドの指定

表の列はいくつでもロードできます。データベース中に定義されていて制御ファイル中で指定されていない列には、NULL値が割り当てられます。

列指定には、列名とその列に入る値の指定を記述します。これらの列指定はカンマで区切って、全体を小カッコで囲みます。

(columnspec,columnspec, ...)

(FILLERのマークが付けられていない)それぞれの列名は、INTO TABLE句で指定した表中の列名に対応させてください。列名にSQLやSQL*Loaderの予約語または特殊文字が含まれているか、大/小文字の区別がある場合は、列名を引用符で囲みます。

列の値をSQL*Loaderで生成する場合は、列指定の中でRECNUMパラメータ、SEQUENCEパラメータまたはCONSTANTパラメータを指定します。詳細は、「SQL*Loaderを使用した入力データの生成」を参照してください。

データ・ファイルから列の値を読み込む場合は、列の値に対応するデータ・フィールドを指定します。このとき、列指定には、データベース表中の列を示す列名(column name)およびデータ・レコード中のフィールドを示すフィールド指定(field specification)を指定します。フィールド指定には、フィールドの位置、データ型、NULL値の制限およびデフォルト値を指定します。

列オブジェクトのロード時に、必ずしもすべての属性を指定する必要はありません。指定しなかった属性には、NULLが設定されます。

FILLERフィールドの指定

BOUNDFILLERまたはFILLERで指定されたFILLERフィールドは、データ・ファイルをマップしたフィールドで、データベースの列とは対応しません。FILLERフィールドは、データ・ファイルがマップされているデータ・フィールドから割り当てられた値です。

FILLERフィールドに関しては次のことに注意してください。

- FILLERフィールドの構文は、フィールド名の後にFILLERを付けること以外は、列ベースのフィールドと同じです。

- FILLERフィールドには名前がありますが、表にはロードされません。

- FILLERフィールドは、引数としてinit_specs(たとえば、NULLIFおよびDEFAULTIF)に使用できます。

- FILLERフィールドは、引数として指示句(たとえば、SID、OID、REFおよびBFILE)に使用できます。
FillerフィールドがBFILEなどの指示句で参照され、列オブジェクト内の制御ファイルで宣言されている場合にあいまいな指定を行わないようにするために、フィールド名にオブジェクトの名前を修飾する必要があります。これは次の例で説明します。

LOAD DATA
INFILE *
INTO TABLE BFILE1O_TBL REPLACE
FIELDS TERMINATED BY ','
(
emp_number char,
emp_info_b column object
(
bfile_name FILLER char(12),
emp_b BFILE(constant "SQLOP_DIR", emp_info_b.bfile_name) NULLIF
emp_info_b.bfile_name = 'NULL'
)
)
BEGINDATA
00001,bfile1.dat,
00002,bfile2.dat,
00003,bfile3.dat,

- FILLERフィールドは、NULLIF句、DEFAULTIF句およびWHEN句のフィールド条件指定で使用できます。ただし、SQL文字列では使用できません。

- FILLERフィールドの指定に、NULLIF句またはDEFAULTIF句を含めることはできません。

- FILLERフィールドは、TRAILING NULLCOLSが指定されて適用可能な場合、NULLで初期化されます。他のフィールドが、無効なFILLERフィールドを参照している場合は、エラーになります。

- FILLERフィールドは、オブジェクトのフィールド・リスト内部またはVARRAYの定義の内部を含む、データ・ファイルのどこにでも指定できます。

- バイナリ配列のFILLERには領域が割り当てられていないため、SQL文字列をFILLERフィールドの一部としては指定できません。

注意:

この項で説明する内容は、BOUNDFILLERを使用したバウンドFILLERの指定にも適用されます。唯一の例外として、バイナリ配列のバウンドFILLERには領域が割り当てられているため、このバウンドFILLERを使用して、SQL文字列をフィールドの一部として指定できます。

FILLERフィールド指定の例を次に示します。

field_1_count FILLER char,
field_1 varray count(field_1_count)
(
filler_field1  char(2),
field_1  column object
(
attr1 char(2),
filler_field2  char(2),
attr2 char(2),
)
filler_field3  char(3),
)
filler_field4 char(6)

データ・フィールドのデータ型の指定

フィールドのデータ型を指定することによって、SQL*Loaderでフィールドのデータが処理される方法が決まります。たとえば、INTEGERデータ型を指定するとバイナリ・データとして処理され、INTEGER EXTERNALを指定すると数字を表す文字データとして処理されます。CHARを指定したフィールドには、すべての文字データを含むことができます。

各フィールドに指定できるデータ型は1つのみで、データ型が指定されていない場合、CHARであるとみなされます。

「SQL*Loaderのデータ型」 では、SQL*Loaderデータ型をOracleデータ型に変換する方法と、各SQL*Loaderデータ型の詳細を説明しています。

データ型を指定する前に、フィールドの位置を指定する必要があります。

SQL*Loaderのデータ型

SQL*Loaderのデータ型は、移植可能なデータ型と移植不能なデータ型にグループ化できます。これら2つの各グループ内で、データ型はさらにVALUEデータ型とLENGTH-VALUEデータ型にグループ化されます。

移植可能なデータ型および移植不能なデータ型は、データ型のプラットフォーム依存性によって分類されます。プラットフォーム依存性は、異なるプラットフォームのバイト順序スキーム(ビッグ・エンディアンとリトル・エンディアン)の違い、プラットフォームのビット数(16ビット、32ビット、64ビット)の違い、符号付き数表現のスキーマの違い(2の補数と1の補数)などの様々な理由から存在します。バイト順序スキーム、プラットフォームのワード長などの場合は、SQL*Loaderで、プラットフォーム依存性を解決するメカニズムが提供されます。これらのメカニズムの詳細は、該当するデータ型の説明を参照してください。

移植可能なデータ型および移植不能なデータ型の両方ともVALUEまたはLENGTH-VALUEをとることができます。VALUEデータ型のデータ・フィールド部分は単一であるとします。LENGTH-VALUEデータ型では、データ・フィールドが2つのサブフィールド(lengthサブフィールドがvalueサブフィールドの長さを指定)で構成される必要があります。

注意:

Oracle Database 12cリリース1 (12.1)から、Oracle DatabaseのVARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズが32KBに増加しました(COMPATIBLE初期化パラメータが12.0以上に設定され、MAX_STRING_SIZE初期化パラメータがEXTENDEDに設定されている場合)。SQL*Loaderでは、この新しい最大サイズがサポートされます。

移植不能なデータ型

移植不能なデータ型は、VALUEデータ型とLENGTH-VALUEデータ型にグループ化されます。移植不能なVALUEデータ型は次のとおりです。

- INTEGER(n)

- SMALLINT

- FLOAT

- DOUBLE

- BYTEINT

- ZONED

- (パック)DECIMAL

移植不能なLENGTH-VALUEデータ型は次のとおりです。

- VARGRAPHIC

- VARCHAR

- VARRAW

- LONG VARRAW

移植不能なデータ型の構文の詳細は、「datatype_spec」の構文図を参照してください。

INTEGER(n)

データは、フルワード2進整数(nは、1、2、4または8から選択して指定した長さ)です。長さが指定されていない場合、その長さはバイト単位で、ご使用のプラットフォームのCプログラミング言語におけるLONG INTのサイズに基づいて決まります。

INTEGERは、バイト・サイズ、バイト順序および符号付きの値の表現がシステム間で異なるため、移植不能です。ただし、符号付きの値の表現がシステム間で同じ場合は、SQL*Loaderを使用して、正しい結果でINTEGERデータにアクセスできます。長さ指定(n)でINTEGERを指定し、必要に応じて適切な方法でデータのバイト順序を指定すると、SQL*Loaderを使用してシステム間で正しい結果でデータにアクセスできます。長さ指定なしにINTEGERを指定すると、C言語のLONG INTの長さが両方のシステムで同じバイト数である場合のみ、SQL*Loaderを使用して正しい結果でデータにアクセスできます。その場合も、必要に応じて、適切な方法でデータのバイト順序を指定する必要があります。

2進整数の長さを明示的に指定すると、ワード長がSQL*Loaderで使用されているものとは異なるプラットフォーム上で入力データを作成する場合に有効です。たとえば、2進整数を含む入力データは、64ビットのプラットフォームで作成され、32ビットのプラットフォーム上のSQL*Loaderを使用しているデータベースにロードされます。この場合、INTEGER(8)を指定して、SQL*Loaderによってその整数を4バイトの量ではなく、8バイトの量として処理します。

デフォルトでは、INTEGERはSIGNED量として処理されます。SQL*Loaderで、符号なしの量として処理する場合は、UNSIGNEDを指定します。デフォルトの動作に戻すには、SIGNEDを指定します。

関連項目:

「異なるプラットフォーム間でのデータのロード」

SMALLINT

データはハーフワードの2進整数で表現されます。このフィールド長には、使用しているシステムのハーフワード整数の長さが取られます。デフォルトでは、SIGNED量として処理されます。SQL*Loaderで、符号なしの量として処理する場合は、UNSIGNEDを指定します。デフォルトの動作に戻すには、SIGNEDを指定します。

SMALLINTは、SHORT INTの長さが同じバイト数のシステム間のみで、正しい結果でロードできます。バイト順序がシステム間で異なる場合は、適切な方法でデータのバイト順序を指定します。詳細は、「バイト順序」を参照してください。

注意:

これは、Cプログラミング言語のSHORT INTデータ型です。フィールド長を決定する1つの方法は、データを入れずに小さい制御ファイルを作成し、その結果のログ・ファイルを調べることです。このデータ型のサイズは、制御ファイルを使用しては変更できません。

FLOAT

データは単精度浮動小数点2進数で表現されます。POSITION句でendを指定するとendは無視されます。このフィールド長には、システムの単精度浮動小数点2進数の長さが取られます。(データ型はC言語のFLOATです。)このデータ型のサイズは、制御ファイルを使用しては変更できません。

FLOATは、FLOATの表現に互換性があり、長さが同じのシステム間のみで、正しい結果でロードできます。バイト順序が2つのシステム間で異なる場合は、適切な方法でデータのバイト順序を指定します。詳細は、「バイト順序」を参照してください。

DOUBLE

データは倍精度浮動小数点2進数で表現されます。POSITION句でendを指定するとendは無視されます。このフィールド長には、システムの倍精度浮動小数点2進数の長さが取られます。(データ型はC言語のDOUBLEまたはLONG FLOATです。)このデータ型のサイズは、制御ファイルを使用しては変更できません。

DOUBLEは、DOUBLEの表現に互換性があり、長さが同じのシステム間のみで、正しい結果でロードできます。バイト順序が2つのシステム間で異なる場合は、適切な方法でデータのバイト順序を指定します。詳細は、「バイト順序」を参照してください。

BYTEINT

2進数で表されている1バイト分のデータを10進数に直した値がロードされます。たとえば、入力文字x"1C"は28としてロードされます。BYTEINTフィールドの長さは、常に1バイトになります。POSITION(start:end)を指定すると、endは無視されます。(データ型はC言語のUNSIGNED CHARです。)

このデータ型の構文例は次のとおりです。

(column1 position(1) BYTEINT,
column2 BYTEINT,
...
)

ZONED

ZONED型のデータは、ZONED型の10進数形式で表現されます。つまり、10進数の各1桁が1バイトで表され、最終バイトに符号が入ります。(COBOLのSIGN TRAILINGフィールドに相当)このフィールド長には、精度(桁数)として指定された長さが取られます。

ZONEDデータ型の構文は次のとおりです。

ここでのprecisionは数字の桁数です。scale(指定されている場合)は(暗黙の)小数点の右側の桁数です。次の例では、位置32から始まる8桁の整数を表します。

sal  POSITION(32)  ZONED(8),

Oracle Databaseでは、ZONED型のデータがASCIIベースのプラットフォームで生成される場合、VAX/VMS ZONED型10進数形式を使用します。EBCDICベースのプラットフォームで生成されるZONED型10進データのロードも可能です。この場合、Oracleでは、ESA/390 Principles of Operationsバージョン8.1マニュアルで指定されているIBM形式を使用します。使用される形式は、入力データ・ファイルのキャラクタ・セット・エンコーディングによって異なります。詳細は、「CHARACTERSETパラメータ」を参照してください。

DECIMAL

DECIMAL型のデータは、PACKED型の10進数形式で記述されます。つまり、10進数の各2桁が1バイトで表され、最終バイトに1桁と符号が入ります。DECIMALフィールドでは暗黙の小数点位置を指定できるため、分数の値を表すこともできます。

DECIMALデータ型の構文は次のとおりです。

precisionパラメータは、数値の桁数です。DECIMALフィールドのバイト長は、桁数から計算します。(N+1)/2を求め、その小数点以下を切り上げた値がバイト長となります。

scaleパラメータは、小数点の右側にくる桁数のことで、スケール変更係数と呼びます。デフォルト値は0(ゼロ)です(整数となります)。全体の桁数より大きい数は指定できますが、負数は指定できません。

次に例を示します。

sal DECIMAL (7,2)

この例では、+12345.67の形式の数値がロードされます。このフィールドは、データ・レコード中で4バイトを占有します。(DECIMALフィールドのバイト長は、(N+1)/2の小数点以下を切り上げた値になります。ここで、Nは数値の桁数です。また、1は符号用として追加されています。)

VARGRAPHIC

このデータは、可変長のダブルバイト・キャラクタ・セット(DBCS)です。lengthサブフィールドおよびダブルバイト文字の文字列で構成されます。ダブルバイト・キャラクタ・セットは、Oracle Databaseではサポートされていないため、SQL*Loaderを使用してシングルバイトとして読み込み、RAWデータとしてロードします。RAWデータ型と同様、VARGRAPHICフィールドは変更されずに指定の列に格納されます。

注意:

lengthサブフィールドのサイズには、システム上のSQL*LoaderのSMALLINTデータ型の長さ(C言語のSHORT INT型に相当する長さ)が取られます。詳細は、「SMALLINT」を参照してください。

VARGRAPHICデータは、SHORT INTの長さが同じバイト数のシステム間でのみ、正しい結果でロードできます。バイト順序がシステム間で異なる場合は、適切な方法でlengthサブフィールドのバイト順序を指定します。詳細は、「バイト順序」を参照してください。

VARGRAPHICデータ型の構文は次のとおりです。

現行のフィールドの長さは、先頭の2バイトで示されます。VARGRAPHICデータ型に指定する最大長には、lengthサブフィールドの長さは含まれません。この最大長には、グラフィック(ダブルバイト)文字の文字数を指定します。フィールドのバイト単位の最大長を決定するには、このmaximum_lengthの値を2倍します。

フィールド最大長のデフォルトは、グラフィック文字で2KB、つまり4KB(2×2KB)です。必要なメモリーを最小限にするには、このような可変フィールドに対して、できるだけ最大長を指定します。

VARGRAPHIC文の前に(pos_specを使用して)位置指定が指定されている場合、グラフィック文字の1文字目ではなく、lengthサブフィールドの位置がわかります。pos_spec(start:end)を指定すると、endの位置によってそのフィールドの最大長が決まります。ここでのstartやendは、そのファイルにおける1バイト単位の文字位置を示します。したがって、(end+1)からstartの値を引くと、フィールドの実際のバイト長が求められます。最大長を指定した場合は、その最大長の方が、位置指定から計算された最大長より優先されます。

VARGRAPHICフィールドのフィールド長全体が、読み込まれる前に論理レコードの終わりで切り捨てられた場合、警告が出力されます。VARGRAPHIC型のフィールド長は、そのフィールドの各入力データ中に埋め込まれているため、そのフィールド長の方が正確であるとみなされます。

VARGRAPHICデータに対してはデリミタを使用できません。

VARCHAR

VARCHARフィールドは、LENGTH-VALUEデータ型です。バイナリのlengthサブフィールドおよびその長さを持つ文字列で構成されます。データ・ファイルに文字長セマンティクスが使用されないかぎり、長さはバイト単位です。文字長セマンティクスが使用される場合は、文字単位になります。詳細は、「文字長セマンティクス」を参照してください。

VARCHARフィールドは、SHORTデータ・フィールドのINTの長さが同じバイト数のシステム間でのみ、正しくロードできます。バイト順序がシステム間で異なる場合、またはVARCHARフィールドにUTF16キャラクタ・セットのデータが含まれている場合は、適切な方法でlengthサブフィールドおよびデータのバイト順序を指定します。データのバイト順序は、UTF16キャラクタ・セットに対してのみ問題となります。詳細は、「バイト順序」を参照してください。

注意:

lengthサブフィールドのサイズには、システム上のSQL*LoaderのSMALLINTデータ型の長さ(C言語のSHORT INT型に相当する長さ)が取られます。詳細は、「SMALLINT」を参照してください。

VARCHARデータ型の構文は次のとおりです。

制御ファイルに指定する最大長には、lengthサブフィールドのサイズを含むことはできません。VARCHARデータ型にオプションで最大長を指定すると、そのサイズ分のバッファがこのフィールドに対してバイト単位で割り当てられます。ただし、文字長セマンティクスがデータ・ファイルに使用される場合、バイト単位のバッファ・サイズは、キャラクタ・セット内の最大限の文字のバイト単位のサイズのmax_length倍となります。詳細は、「文字長セマンティクス」を参照してください。

デフォルトの最大サイズは4KBです。データのロードに必要な最小限の値を最大値として指定することによって、SQL*Loaderで使用されるメモリーを最小限に抑えることができます。特に、VARCHARフィールドを多数使用する場合有効です。

POSITION句を使用する場合、指定する位置は、テキスト文字の先頭ではなく、lengthサブフィールドのバイト単位の位置になります。POSITION(start:end)と指定すると、endの位置によってそのフィールドの最大長が決まります。したがって、(end+1)からstartの値を引くと、フィールドの実際のバイト長が求められます。最大長を指定した場合は、その最大長の方がPOSITION句から計算された長さよりも優先されます。

VARCHARフィールドのフィールド長全体が、読み込まれる前に論理レコードの終わりで切り捨てられた場合、警告が出力されます。VARCHAR型のフィールド長は、そのフィールドの各入力データ中に埋め込まれているため、そのフィールド長の方が正確であるとみなされます。

VARCHARデータに対してはデリミタを使用できません。

VARRAW

VARRAWは、2バイトのバイナリのlengthサブフィールドおよびその後に続くRAW文字列のVALUEサブフィールドで構成されています。

デフォルトでは、VARRAWは、lengthサブフィールドが2バイトで、最大サイズが4KBのVARRAWになります。VARRAW(65000)は、lengthサブフィールドが2バイトで、最大サイズが65000バイトのVARRAWになります。

VARRAWフィールドは、適切な方法でlengthサブフィールドのバイト順序を指定すると、異なるバイト順序のシステム間でロードできます。詳細は、「バイト順序」を参照してください。

LONG VARRAW

LONG VARRAWは、2バイトのlengthサブフィールドではなく、4バイトのlengthサブフィールドを持つVARRAWです。

デフォルトでは、LONG VARRAWは、lengthサブフィールドが4バイトで、最大サイズが4KBのVARRAWになります。LONG VARRAW(300000)は、lengthサブフィールドが4バイトで、最大サイズが300000バイトのVARRAWになります。

LONG VARRAWフィールドは、適切な方法でlengthサブフィールドのバイト順序を指定すると、異なるバイト順序のシステム間でロードできます。詳細は、「バイト順序」を参照してください。

移植可能なデータ型

移植可能なデータ型は、VALUEデータ型とLENGTH-VALUEデータ型にグループ化されます。移植可能なVALUEデータ型は次のとおりです。

- CHAR

- 日時データ型および期間データ型

- GRAPHIC

- GRAPHIC EXTERNAL

- 数値型EXTERNAL(INTEGER、FLOAT、DECIMALおよびZONED)

- RAW

移植可能なLENGTH-VALUEデータ型は次のとおりです。

- VARCHARC

- VARRAWC

これらのデータ型の構文の詳細は、「datatype_spec」の構文図を参照してください。

文字データ型は、CHAR、DATEおよび数値型EXTERNALデータ型です。これらのフィールドにはデリミタを使用できます。また、制御ファイルにフィールド長(または最大長)を指定することができます。

CHAR

このデータ・フィールドには、文字データが入ります。データ長には最大長を指定します(オプション)。長さに関して、次のことに注意してください。

- データ長が指定されていない場合、データ長はPOSITION句の指定から導出されます。

- データ長が指定されている場合は、POSITION句で指定したデータ長より優先されます。

- データ長もPOSITION句による位置も指定されていない場合、フィールドが区切られていないかぎり、CHARのデータ長は1文字とみなされます。

- デリミタ付きCHARフィールドでは、長さが指定されている場合、その長さが最大長として使用されます。

- 長さが指定されていないデリミタ付きCHARフィールドでは、デフォルトの255バイトが使用されます。

- デリミタ付きで255バイトを超えるCHARフィールドには、最大長を指定する必要があります。指定しない場合は、データ・ファイルのフィールドが最大長を超えているというエラーを受信します。

CHARデータ型の構文は次のとおりです。

関連項目:

「デリミタの指定」

日時および間隔のデータ型

日時および期間の両方ともフィールドで構成されています。これらのフィールドの値は、データ型の値によって決まります。

日時データ型は、次のとおりです。

- DATE

- TIME

- TIMEWITHTIMEZONE

- TIMESTAMP

- TIMESTAMPWITHTIMEZONE

- TIMESTAMPWITHLOCALTIMEZONE

日時データ型の値は、「日時」とも呼ばれます。次に説明する日時データ型(DATEを除く)では、オプションでfractional_second_precisionの値を指定できます。fractional_second_precisionには、SECOND日時フィールドの小数部分に格納する桁数を指定します。このデータ型の列を作成する場合、値は0から9までの範囲内の数に設定できます。デフォルトは6です。

期間データ型は次のとおりです。

- INTERVALYEARTOMONTH

- INTERVALDAYTOSECOND

期間データ型の値は、「期間」とも呼ばれます。INTERVAL YEAR TO MONTHデータ型では、オプションでyear_precisionの値を指定できます。year_precisionには、YEAR日時フィールドの桁数を指定します。デフォルト値は2です。

INTERVAL DAY TO SECONDデータ型では、オプションでday_precisionおよびfractional_second_precisionの値を指定できます。day_precisionには、DAY日時フィールドの桁数を指定します。0から9までの値を使用できます。デフォルトは2です。fractional_second_precisionには、SECOND日時フィールドの小数部分に格納する桁数を指定します。このデータ型の列を作成する場合、値は0から9までの範囲内の数に設定できます。デフォルトは6です。

関連項目:

- SQL*Loader制御ファイルにおいて表レベルで日時データ型を指定する方法の詳細は、「表レベルでの日時書式の指定」を参照してください

- fractional_second_precision、year_precisionおよびday_precisionを使用する、日時データ型と期間データ型の指定の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

DATE

DATEフィールドには文字データが入り、その文字データは、指定された日付マスクを使用してOracleの日付に変換されます。DATEフィールドの構文は次のとおりです。

次に例を示します。

LOAD DATA
INTO TABLE dates (col_a POSITION (1:15) DATE "DD-Mon-YYYY")
BEGINDATA
1-Jan-2012
1-Apr-2012 28-Feb-2012

デリミタがない場合、空白は無視され、日付は左から右に構文解析されます(DATEフィールドのデータがすべて空白の場合、NULLフィールドとしてロードされます)。

可変長の日付マスクを指定していない場合、データ長の指定はオプションになります。データ・ファイルに文字長セマンティクスが使用されないかぎり、長さはバイト単位です。文字長セマンティクスが使用される場合は、文字単位になります。詳細は、「文字長セマンティクス」を参照してください。

前述の例では、日付マスク"DD-Mon-YYYY"は、バイト長セマンティクスで11バイトあります。そのため、SQL*Loaderによってこのフィールドの最大文字数が11文字とみなされ、前述の指定は正しく処理されます。ただし、次のように指定される場合は注意が必要です。

DATE "Month dd, YYYY"

この場合、日付マスクは14バイトです。September 30, 2012などのように14バイトを超える長さの値が指定されている場合は、長さを指定する必要があります。

同様に、ユリウス日(日付マスク「J」)の場合も長さを指定する必要があります。日付文字列の長さがマスクの長さ(マスク内のバイト数)を超える可能性がある場合は、必ずフィールド長を指定してください。

長さを明示的に指定していない場合は、POSITION句から長さが求められます。マスクを使用するときは、データ長がマスクの長さ以下であることが確実でないかぎり、常に長さを指定してください。

長さを明示的に指定した場合、この長さは、POSITION句で指定された長さよりも優先されます。これらはいずれも、マスクから求められる長さより優先されます。マスクについては、Oracle日付マスクとして有効なものを指定します。マスクの指定を省略すると、デフォルトのOracle日付マスク「dd-mon-yy」が使用されます。

データ長は小カッコで囲み、マスクは引用符で囲む必要があります。

DATEデータ型のフィールドでは、デリミタも使用できます。詳細は、「デリミタの指定」を参照してください。

時間

TIMEデータ型には、時、分、秒の値が格納されます。次のように指定します。

TIME [(fractional_second_precision)]

TIMEWITHTIMEZONE

TIME WITH TIME ZONEデータ型は、タイムゾーンの置換えを含むTIMEデータ型の変形です。タイムゾーンの置換えは、ローカル時刻とUTCの差(時および分)です。次のように指定します。

TIME [(fractional_second_precision)] WITH [LOCAL] TIME ZONE

LOCALオプションが指定されている場合、データベースに格納されているデータはデータベース・タイムゾーンに指定されます。データが取得されると、ユーザーのローカル・セッション・タイムゾーンに返されます。

TIMESTAMP

TIMESTAMPデータ型は、DATEデータ型の拡張機能です。DATEデータ型の年、月および日に加えて、TIMEデータ型の時、分および秒の値を格納します。次のように指定します。

TIMESTAMP [(fractional_second_precision)]

日付値を指定する場合、時間構成要素を指定しないと、デフォルト時間の12:00:00 AM(真夜中)が採用されます。

TIMESTAMPWITHTIMEZONE

TIMESTAMP WITH TIME ZONEデータ型は、タイムゾーンの置換えを含むTIMESTAMPデータ型の変形です。タイムゾーンの置換えは、ローカル時刻とUTCの差(時および分)です。次のように指定します。

TIMESTAMP [(fractional_second_precision)] WITH TIME ZONE

TIMESTAMPWITHLOCALTIMEZONE

TIMESTAMP WITH LOCAL TIME ZONEデータ型は、タイムゾーンのオフセットを含むTIMESTAMPデータ型の変形です。データベースに格納されているデータは、データベース・タイムゾーンに指定されます。データが取得されると、ユーザーのローカル・セッション・タイムゾーンに返されます。次のように指定します。

TIMESTAMP [(fractional_second_precision)] WITH LOCAL TIME ZONE

INTERVALYEARTOMONTH

INTERVAL YEAR TO MONTHデータ型は、YEARおよびMONTH日時フィールドを使用して一定期間を格納します。次のように指定します。

INTERVAL YEAR [(year_precision)] TO MONTH

INTERVALDAYTOSECOND

INTERVAL DAY TO SECONDデータ型は、DAYおよびSECOND日時フィールドを使用して一定期間を格納します。次のように指定します。

INTERVAL DAY [(day_precision)] TO SECOND [(fractional_second_precision)]

GRAPHIC

このデータは、ダブルバイト・キャラクタ・セット(DBCS)形式の文字列データです。ダブルバイト・キャラクタ・セットはOracle Databaseではサポートされていないため、SQL*Loaderを使用してシングルバイトとして読み込みます。RAWデータ型と同様、GRAPHICフィールドは変更されずに指定の列に格納されます。

GRAPHICデータ型の構文は次のとおりです。

GRAPHIC型およびGRAPHIC EXTERNAL型では、POSITION(start:end)を指定すると、論理レコードにおけるフィールドの正確な位置が決まります。

ただし、GRAPHIC (EXTERNAL)データ型にデータ長を指定する場合は、ダブルバイト・グラフィック文字の文字数を指定します。この値を2倍してフィールドのバイト長が求められます。グラフィック文字の長さを指定した場合は、POSITION句から求められたデータ長は無視されます。GRAPHICデータ型の指定では、データ・フィールドの区切りの指定はできません。

GRAPHIC EXTERNAL

DBCSフィールドがシフトイン/シフトアウト文字で囲まれている場合は、GRAPHIC EXTERNAL型を使用します。このデータ型は、データの先頭と最後の文字(シフトイン/シフトアウト文字)がロードされないことを除き、GRAPHIC型とほぼ同じです。

GRAPHIC EXTERNALデータ型の構文は次のとおりです。

GRAPHICは、ダブルバイト文字のデータであることを示します。EXTERNALは、先頭と最後の文字が無視されることを示します。graphic_char_lengthの値は、DBCSのデータ長を指定します(「GRAPHIC」を参照)。

たとえば、[ ]をシフトイン/シフトアウト文字とし、#を任意のダブルバイト文字とします。

[####]を表現する場合は、POSITION(1:4) GRAPHICまたはPOSITION(1) GRAPHIC(2)と指定します。

[####]を表現する場合は、POSITION(1:6) GRAPHIC EXTERNALまたはPOSITION(1) GRAPHIC EXTERNAL(2)と指定します。

数値型EXTERNAL

数値型EXTERNALデータ型は、オプション指定の長さおよびデリミタ付きの、EXTERNALとして指定された数値データ型(INTEGER、FLOAT、DECIMALおよびZONED)です。データ・ファイルに文字長セマンティクスが使用されないかぎり、長さはバイト単位です。文字長セマンティクスが使用される場合は、文字単位になります。詳細は、「文字長セマンティクス」を参照してください。

このデータ型は、判読可能な文字形式の数値データです。長さ、位置およびデリミタについては、CHARデータと同じ規則が数値型EXTERNALにも適用されます。これらの規則の詳細は、「CHAR」を参照してください。

数値型EXTERNALデータ型の構文は、「datatype_spec」を参照してください。

注意:

このデータは、バイナリ表現ではなく、文字形式の数字になります。したがって、これらのデータ型の処理方法は、DEFAULTIFを使用する場合を除き、CHARと同じです。デフォルトをNULLにする場合はCHARを使用します。デフォルトを0(ゼロ)にする場合はEXTERNALを使用します。詳細は、「WHEN、NULLIFおよびDEFAULTIF句の使用」を参照してください。

FLOAT EXTERNALデータは科学表記法または通常表記法のどちらででも指定できます。「5.33」と「533E-2」は両方とも同じ値の正しい表現です。

RAW

RAW型のバイナリ・データが無条件でRAW型のデータベース列にロードされた場合、Oracle Databaseによるデータ変換は行われません。CHAR列にロードした場合は、Oracle Databaseによって、16進数にデータ変換されます。DATE型や数値型の列にはロードできません。

RAWデータ型の構文は次のとおりです。

このフィールドのlengthは、制御ファイルに指定されたバイト数です。この長さは、データベース中のターゲット列の長さとメモリー・リソースによってのみ制限されます。データ・ファイルに文字長セマンティクスが使用される場合でも、長さは常にバイト単位です。RAWデータ・フィールドに対してはデリミタは使用できません。

VARCHARC

VARCHARCデータ型は、文字のlengthサブフィールドおよびその後に続く文字列値のサブフィールドで構成されます。

VARCHARCに対する宣言には、lengthサブフィールドの長さが含まれます。また、オプションで文字列の最大サイズがその後に続く場合もあります。データ・ファイルにバイト長セマンティクスが使用される場合、長さおよび最大サイズはともにバイト単位です。データ・ファイルに文字長セマンティクスが使用される場合、長さおよび最大サイズはともに文字単位です。最大サイズが指定されていない場合、バイト長セマンティクスまたは文字長セマンティクスのいずれが使用されていても、デフォルトは4KBです。

次に例を示します。

- 少なくとも長さサブフィールドに値を指定する必要があるため、VARCHARCはエラーになります。

- データ・ファイルにバイト長セマンティクスが使用されている場合、VARCHARC(7)は、lengthサブフィールドが7バイトで、最大サイズが4KB(デフォルト)のVARCHARCになります。文字長セマンティクスが使用されている場合は、lengthサブフィールドが7文字で、最大サイズが4KB(デフォルト)のVARCHARCになります。最大サイズが指定されていない場合、バイト長セマンティクスまたは文字長セマンティクスのいずれが使用されていても、常にデフォルトの4KBが使用されることに注意してください。

- データ・ファイルにバイト長セマンティクスが使用されている場合、VARCHARC(3,500)は、lengthサブフィールドが3バイトで、最大サイズが500バイトのVARCHARCになります。文字長セマンティクスが使用されている場合は、lengthサブフィールドが3文字で、最大サイズが500文字のVARCHARCになります。

詳細は、「文字長セマンティクス」を参照してください。

VARRAWC

VARRAWCデータ型は、RAW文字列値のサブフィールドで構成されています。

次に例を示します。

- VARRAWCはエラーになります。

- VARRAWC(7)は、lengthサブフィールドが7バイトで、最大サイズが4KB(デフォルト)のVARRAWCになります。

- VARRAWC(3,500)は、lengthサブフィールドが3バイトで、最大サイズが500バイトのVARRAWCになります。

システム固有のデータ型フィールド長の競合

フィールド長を指定する方法は数通りあります。それぞれの指定方法で異なる値を指定して、値が競合する場合は、そのうちの1つの値が優先されます。競合が発生した時点で警告が出されます。どのフィールド長を採用するかは、次の規則に基づいて決定されます。

1. POSITION句で指定されたバイト数に関係なく、SMALLINT、FLOATおよびDOUBLEのデータ・サイズは固定長です。

2. DECIMAL、INTEGER、ZONED、GRAPHIC、GRAPHIC EXTERNALまたはRAWで指定されたフィールド長(または精度)が、POSITION(start:end)から計算されたサイズと異なる場合は、指定されたフィールド長(または精度)を採用します。

3. 文字フィールドまたはVARGRAPHICフィールドにおいて指定された最大長が、POSITION(start:end)から計算されたフィールド長と異なる場合は、指定された最大長を採用します。

たとえば、システム固有のデータ型INTEGERが4バイトであるときに、次のようなフィールドが指定されたとします。

column1 POSITION(1:6) INTEGER

この場合、警告が出力され、正しいフィールド長である4バイトが採用されます。実際に使用されたフィールド長は、ログ・ファイル内の列表の「Len」という見出しの箇所に記録されます。

Column Name             Position   Len  Term Encl Data Type
----------------------- --------- ----- ---- ---- ---------
COLUMN1                       1:6     4             INTEGER

LENGTH-VALUEデータ型のフィールド長

制御ファイルで、LENGTH-VALUEデータ型の最大長(VARCHAR、VARCHARC、VARGRAPHIC、VARRAWおよびVARRAWC)を指定できます。指定される最大長は、フィールドにバイト長セマンティクスが使用される場合はバイト単位で、文字長セマンティクスが使用される場合は文字単位です。最大長が指定されていない場合は、デフォルトで4096バイトとなります。フィールド長が最大長を超える場合、レコードは拒否され、次のエラーが表示されます。

Variable length field exceed maximum length

データ型の変換

制御ファイルに指定したデータ型で、データ・ファイル中のデータをどのように解釈するかを、SQL*Loaderに対して指定します。一方、サーバーでは、これとは別にデータベース中の列に対してデータ型を定義します。これらの2つのデータ型を対応付ける手がかりとなるのが、制御ファイル中に指定している列名です。

SQL*Loaderでは、入力ファイル中のフィールドからデータが抽出されます。抽出処理は、制御ファイルに指定したデータ型に基づいて行われます。次にSQL*Loaderでは、そのフィールドがサーバーに送信されます。送信されたフィールドは、該当する列に(行挿入配列の一部として)格納されます。

SQL*Loaderまたはサーバーでは、変換の必要なデータに対してデータ変換が行われ、適切な内部形式でデータが格納されます。これには、データ・ファイルのキャラクタ・セットとデータベースのキャラクタ・セットが異なる場合に、データ・ファイルのデータをデータベース用に変換する機能も含まれます。

注意:

SQL*Loaderの従来型パスを使用して、データ・ファイルの文字データをLONG RAW列にロードする場合、その文字データはHEX文字列として解釈されます。SQLは、HEX文字列をバイナリ表現に変換します。ここで、4000バイトより長い文字列は、SQL HEXTORAW変換演算子のバイト制限を超えていることに注意してください。エラーが返されます。SQL*Loaderはその行を拒否してロードを続行します。

ファイルのデータのデータ型は、Oracle表の列のデータ型と同じである必要はありません。データ型が一致していない場合、Oracle Databaseサーバーで自動的に変換が行われます。ただし、変換が正常に実行されたか、エラーは発生していないかについては実行後に確認する必要があります。たとえば、CHARデータ型のデータ・ファイル・フィールドをNUMBERデータ型のデータベース列にロードする場合、文字フィールドの内容が有効な数値を表していることを確認する必要があります。

注意:

SQL*Loaderには、NUMBERまたはVARCHAR2などのOracle内部データ型に関するデータ型指定は定義されていません。SQL*Loaderのデータ型として扱えるのはテキスト・エディタで作成できるデータ(文字データ型)、および標準プログラミング言語で作成できるデータ(システム固有のデータ型)のみです。ただし、NUMBERおよびVARCHAR2のようなデータ型は、SQL*Loaderでは認識されませんが、これらのデータ型またはその他のデータ型のデータベース列に、Oracle Databaseで変換可能なデータをロードすることはできます。

日時データ型および期間データ型のデータ型変換

表10-2に、Oracle Databaseデータ型と、SQL*Loader制御ファイルの日時データ型および期間データ型の間で変換がサポートされるかどうかを示します。

この表で使用されているOracle Databaseデータ型の略称は次のとおりです。

N = NUMBER

C: CHARまたはVARCHAR2

D = DATE

T = TIMEおよびTIME WITH TIME ZONE

TS = TIMESTAMPおよびTIMESTAMP WITH TIME ZONE

YM: INTERVAL YEAR TO MONTH

DS: INTERVAL DAY TO SECOND

SQL*Loaderデータ型でも、D、T、TS、YMおよびDSに関しては、表の略称の定義は同じです。ただし、前述のとおり、SQL*Loaderには、NUMBER、CHAR、VARCHAR2などのOracle内部データ型に関するデータ型指定は定義されていません。ただし、Oracle Databaseで変換可能なデータは、これらのデータ型やその他のデータ型のデータベース列にロードできます。

この表の読み方の例を、SQL*Loaderデータ型DATE (略称D)の行で示します。行を右に読み進めると、データ型変換がサポートされるOracle Databaseデータ型は、CHAR、VARCHAR2、DATE、TIMESTAMPおよびTIMESTAMP WITH TIME ZONEデータ型であることがわかります。ただし、Oracle Databaseデータ型のNUMBER、TIME、TIME WITH TIME ZONE、INTERVAL YEAR TO MONTHまたはINTERVAL DAY TO SECONDデータ型の変換はサポートされません。

表10-2 日時データ型および期間データ型のデータ型変換

SQL*Loaderデータ型

Oracle Databaseデータ型(変換のサポート)

N

N(可)、C(可)、D(不可)、T(不可)、TS(不可)、YM(不可)、DS(不可)

C

N(可)、C(可)、D(可)、T(可)、TS(可)、YM(可)、DS(可)

D

N(不可)、C(可)、D(可)、T(不可)、TS(可)、YM(不可)、DS(不可)

T

N(不可)、C(可)、D(不可)、T(可)、TS(可)、YM(不可)、DS(不可)

TS

N(不可)、C(可)、D(可)、T(可)、TS(可)、YM(不可)、DS(不可)

YM

N(不可)、C(可)、D(不可)、T(不可)、TS(不可)、YM(可)、DS(不可)

DS

N(不可)、C(可)、D(不可)、T(不可)、TS(不可)、YM(不可)、DS(可)

デリミタの指定

CHAR、日時、期間または数値型EXTERNAL型のフィールドの境界は、デリミタ文字を使用して、入力データ・レコード中に指定することもできます。デリミタ文字は、TERMINATED BY、ENCLOSED BYおよびOPTIONALLY ENCLOSED BY句を様々に組み合せて指定できます(ただし、TERMINATED BY句を使用する場合は、最初に指定する必要があります)。デリミタは、データ型の指定の後で指定します。

デリミタ句を様々に組み合せて使用した場合にデータがどのように処理されるかについては、「デリミタ付きデータの処理方法」を参照してください。

注意:

RAWデータ型でもデリミタを使用できます。ただし、RAWデータ型が入力LOBFILEにある場合、およびデリミタがTERMINATED BY EOF (ファイルの終わり)の場合のみです。

終了および囲みの指定に関する構文

次の図に、termination_specおよびenclosure_specの構文を示します。

表10-3では、デリミタの指定に使用する、終了および囲みの指定に関する構文について説明します。

表10-3 デリミタの指定に使用するパラメータ

パラメータ

説明

TERMINATED

データは、最初にデリミタが現れるまで読み込まれます。

BY

可読性を向上させるために使用されるオプションのワードです。

WHITESPACE

デリミタには、スペース、タブ、空白、LF、改ページ、改行などの任意の空白文字を使用できます。(TERMINATEDの場合のみ使用できます。ENCLOSEDでは使用できません。)

OPTIONALLY

指定する文字でデータを囲むこともできます。SQL*Loaderでは、この指定文字が最初に現れたところから、次に同じ文字が現れたところまでのデータ値が読み込まれます。データが囲まれていない場合は、終了デリミタ付きのフィールドとして読み込まれます。オプションで囲みデリミタを指定する場合は、必ずTERMINATED BY句を指定してください。その場合、フィールド定義の一部としてローカルに指定しても、FIELDS句の中でグローバルに指定してもかまいません。

ENCLOSED

データは2つのデリミタで囲まれます。

string

デリミタは文字列です。

X'hexstr'

デリミタは、文字コード体系におけるX'hexstr'によって指定される値を持つ文字で、X'1F'(10進数の31)などのように指定します。「X」は大文字でも小文字でも使用できます。

AND

後続の囲みデリミタを指定する場合に使用します。後続の囲みデリミタには、先頭の囲みデリミタとは異なる文字を指定できます。AND句を指定しないと、先頭の囲みデリミタと後続の囲みデリミタは同じ文字とみなされます。

EOF

ファイル全体がLOBにロードされたことを示します。これは、LOBファイルからデータがロードされる場合のみ有効です。EOFによって終了するフィールドは囲むことができません。

各指定方法によるデリミタの指定例およびそれぞれの場合の実際のデータの例を示します。

TERMINATED BY ','                      a data string,
ENCLOSED BY '"'                        "a data string"
TERMINATED BY ',' ENCLOSED BY '"'      "a data string",
ENCLOSED BY '(' AND ')'                (a data string)

データ中のデリミタ記号

デリミタとして定義した句読点を、データの中でも使用する必要があります。このような場合、デリミタ文字を2つ続けて記述すると、この文字は1文字のみ指定されたものと解釈され、データの一部として組み込まれます。たとえば、データベースに次の文字列を格納するとします。

(The delimiters are left parentheses, (, and right parentheses, )).)

フィールド指定は次のようにします。

ENCLOSED BY "(" AND ")"

この場合、データベースには次の文字列が格納されます。

The delimiters are left parentheses, (, and right parentheses, ).

このため、隣接するフィールドが同じデリミタを使用すると、問題が発生します。たとえば、次のように指定されている場合、

field1 TERMINATED BY "/"
field2 ENCLOSED by "/"

次のデータは正しく解釈されます。

This is the first string/      /This is the second string/

ただし、field1およびfield2が次のように隣接している場合、誤った処理が行われます。

This is the first string//This is the second string/

この場合、このデータ全体が、中央に1つの「/」のみを持つ単一の文字列とみなされ、field1に属するものと解釈されてしまいます。

デリミタ付きデータの最大長

デリミタ付きデータの最大長のデフォルトは、255バイトです。したがって、デリミタ付きフィールドでは、バインド配列に対して記憶域が大量に使用される場合があります。フィールドが255バイトより短い場合、最大長にはできるだけ小さい値を指定してください。フィールドが255バイトより長い場合は、フィールド長指定子またはPOSITION句を使用して、フィールドに最大長を指定する必要があります。

たとえば、文字列リテラルが255バイトより長い場合は、SUBSTR()およびCHAR()を使用して、フィールドのすべてのレコードの中で最も長い文字列を指定します。たとえば、field1のすべてのレコードの中で最も長い文字列が600バイトの場合は、次のようになります。

field1 CHAR(600) SUBSTR(:field, 1, 240)

デリミタを使用した後続の空白のロード

後続の空白は、PRESERVE BLANKSを指定しないかぎり、デリミタなしのデータ型ではロードされません。たとえば、データ・フィールド長が9文字で、DANIELbbbという値のデータがあるとします。ここでのbbbは3つの空白を示します。このとき、CHAR(9)と宣言されていると、Oracle Databaseには「DANIEL」がロードされます。

この例で後続の空白も必要な場合は、CHAR(9) TERMINATED BY ':'と宣言し、さらにデータ・ファイルにコロンを追加してフィールドをDANIELbbb:とします。このフィールドは、後続の空白とともに、「DANIEL」としてロードされます。TERMINATED BY句を使用しないでPRESERVE BLANKSを指定し、同じ結果を得ることもできます。

関連項目:

- 「空白の切捨て」

- 「空白の切捨てに対するPRESERVE BLANKSオプションの影響」

デリミタ付きデータの処理方法

デリミタは、TERMINATED BY、ENCLOSED BYおよび OPTIONALLY ENCLOSED BY句の様々な組合せをフィールド定義で使用して定義できます。次の項では、それぞれの場合に行われる処理について説明します。

- TERMINATED BYのみを使用するフィールド

- TERMINATED BYなしでENCLOSED BYを使用するフィールド

- TERMINATED BYとともにENCLOSED BYを使用するフィールド

- TERMINATED BYとともにOPTIONALLY ENCLOSED BYを使用するフィールド

TERMINATED BYのみを使用するフィールド

フィールドに対してTERMINATED BYが指定され、ENCLOSED BYは指定されていない場合、フィールドの開始位置から最初のTERMINATED BYデリミタまでがフィールドのデータとして読み込まれます(デリミタ自体は読み込まれません)。終了デリミタがフィールドの最初の列位置にある場合、そのフィールドはNULLとなります。TERMINATED BYデリミタが検出される前にレコードの終わりが検出された場合は、レコードの末尾までのすべてのデータがフィールドの要素とみなされます。

TERMINATED BY WHITESPACEを指定すると、最初に空白文字(スペース、タブ、空白、LF、改ページまたは改行)が現れるまでデータが読み込まれます。空白文字が現れると、隣接する空白文字が検出されなくなるまで現在の位置が進められます。したがって、フィールド値の間に入る空白は、いくつあってもかまいません。ただし、フィールドの最初の列位置が既知であり、空白の終端文字がそこにある場合は、空白以外の終端文字のときとは異なり、フィールドがNULLとして扱われないため、レコードが拒否されたり、フィールドが誤った列にロードされる可能性があります。

TERMINATED BYなしでENCLOSED BYを使用するフィールド

TERMINATED BY句を使用せずにENCLOSED BY句を使用するフィールドの場合は、次の処理が行われます。

1. フィールドの先頭に空白がある場合は、その空白がすべてスキップされます。

2. 最初に検出される空白以外の文字は、最初のENCLOSED BYデリミタに一致する文字列の先頭である必要があります。そうでない場合、行は拒否されます。

3. 最初のENCLOSED BYデリミタが検出された場合は、2番目のENCLOSED BYデリミタの検索が開始されます。

4. 2番目のENCLOSED BYデリミタが最初のデリミタと隣合せで検出された場合は、1つのデリミタが記述されていると解釈した上で、フィールドのデータ要素に含まれます。引き続き、2番目のENCLOSED BYデリミタが検索されます。

5. 2番目のENCLOSED BYデリミタが検出される前にレコードの終わりが検出された場合、その行は拒否されます。

TERMINATED BYとともにENCLOSED BYを使用するフィールド

ENCLOSED BY句を使用し、TERMINATED BY句も使用するフィールドの場合は、次の処理が行われます。

1. フィールドの先頭に空白がある場合は、その空白がすべてスキップされます。

2. 最初に検出される空白以外の文字は、最初のENCLOSED BYデリミタに一致する文字列の先頭である必要があります。そうでない場合、行は拒否されます。

3. 最初のENCLOSED BYデリミタが検出された場合は、2番目のENCLOSED BYデリミタの検索が開始されます。

4. 2番目のENCLOSED BYデリミタが最初のデリミタと隣合せで検出された場合は、1つのデリミタが記述されていると解釈した上で、フィールドのデータ要素に含まれます。引き続き、次にある2番目のENCLOSED BYデリミタが検索されます。

5. 2番目のENCLOSED BYデリミタが検出される前にレコードの終わりが検出された場合、その行は拒否されます。

6. 2番目のENCLOSED BYデリミタが検出された場合は、パーサーによりTERMINATED BYデリミタが検索されます。TERMINATED BYデリミタがWHITESPACE以外の場合、2番目のENCLOSED BYデリミタの最後とTERMINATED BYデリミタの間にある空白はスキップされます。

注意:

2番目のENCLOSED BYデリミタとTERMINATED BYデリミタの間に使用できるのは、WHITESPACEのみです。それ以外の文字があると、エラーが発生します。

7. TERMINATED BYデリミタが検出される前にレコードの終わりが検出された場合でも、行は拒否されません。

TERMINATED BYとともにOPTIONALLY ENCLOSED BYを使用するフィールド

OPTIONALLY ENCLOSED BY句およびTERMINATED BY句を使用するフィールドの場合は、次の処理が行われます。

1. フィールドの先頭に空白がある場合は、その空白がすべてスキップされます。

2. 最初に検出された空白以外の文字が、最初のOPTIONALLY ENCLOSED BYデリミタに一致する文字列の先頭であるかどうかがパーサーによって確認されます。そうでない場合に、OPTIONALLY ENCLOSED BYデリミタがデータ内に存在しないと、フィールドの現在の位置から最初のTERMINATED BYデリミタまでがフィールドのデータとして読み込まれます(デリミタ自体は読み込まれません)。TERMINATED BYデリミタが最初の列位置にある場合、そのフィールドはNULLとなります。TERMINATED BYデリミタが検出される前にレコードの終わりが検出された場合は、レコードの末尾までのすべてのデータがフィールドの要素とみなされます。

3. 最初のOPTIONALLY ENCLOSED BYデリミタが検出された場合は、2番目のOPTIONALLY ENCLOSED BYデリミタの検索が開始されます。

4. 2番目のOPTIONALLY ENCLOSED BYデリミタが2つ隣合せで検出された場合は、1つのデリミタが記述されていると解釈した上で、フィールドのデータ要素に含まれます。引き続き、2番目のOPTIONALLY ENCLOSED BYデリミタが検索されます。

5. 2番目のOPTIONALLY ENCLOSED BYデリミタが検出される前にレコードの終わりが検出された場合、その行は拒否されます。

6. OPTIONALLY ENCLOSED BYデリミタがデータ内に存在する場合は、パーサーによりTERMINATED BYデリミタが検索されます。TERMINATED BYデリミタがWHITESPACE以外の場合、2番目のOPTIONALLY ENCLOSED BYデリミタの最後とTERMINATED BYデリミタの間にある空白はスキップされます。

7. TERMINATED BYデリミタが検出される前にレコードの終わりが検出された場合でも、行は拒否されません。

注意:

空白文字をTERMINATED BYデリミタとして指定し、OPTIONALLY ENCLOSED BYも使用する場合は注意が必要です。SQL*Loaderでは、OPTIONALLY ENCLOSED BYデリミタを検索するときに、先頭の空白が取り除かれます。2つのTERMINATED BYデリミタがレコードの途中に隣り合って含まれている場合(通常は、レコードのフィールドをNULLに設定する目的でこのように記述します)、最初のTERMINATED BYデリミタの空白を使用してフィールドが終了されますが、残りの空白は、次のフィールドの先頭の空白とみなされ、次のフィールドのTERMINATED BYデリミタとはみなされません。NULL値をロードする場合は、データ内にENCLOSED BYデリミタを含める必要があります。

文字データ型フィールド長の競合

CHAR型、DATE型および数値型EXTERNAL型の文字データ・フィールドの場合は、そのフィールド長を制御ファイルに複数指定できます。複数指定したときの長さが異なり、値が競合する場合は、そのうちの1つが優先されます。競合が発生すると、警告が出力されます。 この項では、指定された長さのうちのどれが優先されるかについて説明します。

事前にサイズが決まっているフィールド

前述のデータ型のフィールドに対して開始位置と終了位置を指定すると、そのフィールド長は指定された開始/終了位置から求められます。データ型指定の中で長さを指定し、終了位置は指定しない場合、データ型指定の中で指定された長さがそのフィールド長になります。開始位置、終了位置および長さがすべて指定されていて、その長さが異なる場合は、次のように、データ型指定の中で指定されている長さがフィールド長として使用されます。

POSITION(1:10) CHAR(15)

この場合、このフィールド長は15になります。

デリミタ付きフィールド

デリミタ付きフィールドに長さを指定した場合、または開始位置と終了位置から長さを計算できる場合は、その長さがフィールドの最大長となります。指定される最大長は、フィールドにバイト長セマンティクスが使用される場合はバイト単位で、文字長セマンティクスが使用される場合は文字単位です。長さが指定されていない場合、または開始位置と終了位置から長さが計算できない場合は、最大長のデフォルトは255バイトです。実際の長さはデリミタの位置によって変わりますが、長さの上限はこの最大長の値となります。

フィールドにデリミタのみでなく、開始位置および終了位置が指定されている場合は、位置指定のみが影響します。囲みデリミタまたは終了デリミタは無視されます。

デリミタが見つからない場合は、レコードの終わりがフィールドの終端となります。TRAILING NULLCOLSが指定されている場合は、残りのフィールドにはNULL値が設定されます。デリミタまたはレコードの終端で区切った結果、フィールド長が最大長よりも大きくなる場合は、SQL*Loaderによってレコードが拒否され、エラーが返されます。

日付フィールド・マスク

マスクを指定した場合、日付フィールド長は、使用するマスクによって異なります。指定されたマスクによって形式が決定され、SQL*Loaderではその形式に基づいてレコード中のデータが解釈されます。たとえば、次のようなマスクを指定したとします。

"Month dd, yyyy"

この場合、May 3, 2012はレコード(バイト長セマンティクスを含む)中で11バイトを占有し、January 31, 2012は16バイトを占有することになります。

ただし、開始位置および終了位置を指定すると、この位置指定から計算されるフィールド長は、マスクから求められるフィールド長よりも優先されます。DATE(12)のようにフィールド長が指定された場合は、このフィールド長が最優先となります。日付フィールドが、終了デリミタまたは囲みデリミタでも区切られている場合は、制御ファイル中で指定された長さがそのフィールドの最大長と解釈されます。

関連項目:

DATEフィールドの詳細は、「日時および間隔のデータ型」を参照してください

フィールド条件の指定

フィールド条件とは、論理レコード中のフィールドに関して、それが真か偽かを評価する条件を記述したものです。フィールド条件は、WHEN句、NULLIF句およびDEFAULTIF句で使用します。

注意:

句の評価に使用するフィールドにNULL値が含まれている場合、常に、その句はFALSEと評価されます。この機能については、「WHEN、NULLIFおよびDEFAULTIF句の使用例」で説明しています。

フィールド条件は、CONTINUEIF句の中で指定する条件と同様ですが、次の2つの点で異なります。第1に、フィールド条件で指定する位置は、物理レコードではなく論理レコードの位置を示します。第2に、論理レコード内の位置またはデータ・ファイル内のフィールド名(FILLERフィールドを含む)のいずれかを指定できます。

注意:

フィールド条件は、セカンダリ・データ・ファイル(SDF)のフィールドに基づくことができません。

field_condition句の構文は次のとおりです。

pos_spec句の構文は次のとおりです。

「フィールド条件の指定」では、フィールド条件句のパラメータについて説明します。位置指定パラメータの詳細は、「データ・フィールドの位置指定」を参照してください。

表10-4 フィールド条件句のパラメータ

パラメータ

説明

pos_spec

論理レコード中の比較対象フィールドの開始および終了位置です。それらの位置は小カッコで囲んでください。start-endと表記することも、start:endと表記することもできます。

開始位置の指定は、列番号、*(次の列)または*+n(次の列にオフセット分を加算)の形式で指定できます。

終了位置を省略した場合、フィールド長は、比較文字列の長さから判断されます。対象フィールドと比較文字列の長さが異なるときは、短い方を埋めるために文字列が追加されます。文字列の場合は空白が追加され、16進数のバイト列の場合は0(ゼロ)が追加されます。

start

論理レコード中の比較対象フィールドの開始位置です。

end

論理レコード中の比較対象フィールドの終了位置です。

full_fieldname

full_fieldnameには、ドット表記法を使用してフィールドのフルネームを指定します。フィールドcol2が列オブジェクトcol1の属性の場合、指示句の中でcol2 を参照するときは、col1.col2と表記してください。同じエンティティを参照または命名している列名およびフィールド名があっても、列名には、エンティティのフルネームを指定できない(ドット表記法がない)ため、別のものとして認識されます。

operator

比較演算子として、等価または不等価を示す記号を指定します。

char_string

比較フィールドとの比較に使用する文字列で、一重引用符または二重引用符で囲んで指定します。比較の結果が真の場合は、現在のレコードが表に挿入されます。

X'hex_string'

16進数の文字列で、16進数2桁がフィールドの1バイトに相当します。一重引用符または二重引用符で囲まれます。比較の結果が真の場合は、現在のレコードが表に挿入されます。

BLANKS

フィールドが完全に空白かどうかをテストできます。BLANKSの指定は、デリミタ付きデータのロード時にフィールド長が予測できない場合、または空白が複数あるマルチバイト・キャラクタ・セットを使用する場合に必要となります。

フィールドとBLANKSの比較

BLANKSパラメータを使用すると、長さが不明なフィールドのデータが空白かどうかを知ることができます。

次の指定を実行すると、空白のフィールドにNULL値を設定できます。

full_fieldname ... NULLIF column_name=BLANKS

BLANKSパラメータが認識できるのは空白のみです。タブは認識できません。これは、どのようなフィールド比較の場合でも、比較文字列のかわりに指定できます。列の値がすべて空白のときにのみ条件が真となります。

BLANKSは、固定長フィールドに対しても指定できます。その場合は、対象フィールドに合った長さの空白文字列を指定したのと同じことになります。たとえば、次の指定はどちらも同じことを意味します。

fixed_field CHAR(2) NULLIF fixed_field=BLANKS
fixed_field CHAR(2) NULLIF fixed_field="  "

マルチバイト・キャラクタ・セットには複数の空白が存在することもあります。このようなキャラクタ・セットには、空白文字列を指定するかわりにBLANKSを使用します。

文字列は特定の空白文字の組合せのみに一致しますが、BLANKSパラメータは様々な空白文字の組合せに一致します。マルチバイト・キャラクタ・セットの詳細は、「マルチバイト(アジア系言語)キャラクタ・セット」を参照してください。

フィールドと文字列の比較

データ・フィールドが、それより短い比較文字列と比較された場合は、その文字列が埋め込まれます。文字データ型の文字列には、次のように空白が埋め込まれます。

NULLIF (1:4)=" "

この例では、位置1:4にあるデータが4つの空白と比較されます。位置1:4のデータが空白4つであれば、この句は真となります。

次の句のように、16進文字列には16進数のゼロが埋め込まれます。

NULLIF (1:4)=X'FF'

この句で、データ位置1:4を16進数のバイト列'FF000000'と比較します。

WHEN、NULLIFおよびDEFAULTIF句の使用

次の説明は、スカラー・フィールドに適用されます。非スカラー・フィールド(列オブジェクト、LOBおよびコレクション)はより複雑なため、WHEN、NULLIFおよびDEFAULTIF句は異なる方法で処理されます。

WHEN、NULLIFまたはDEFAULTIF句は、フィールド名を指定するか、フィールド位置を指定するかによって、結果が異なります。

- WHEN、NULLIFまたはDEFAULTIF句でフィールド名を指定すると、これらの句は、SQL*Loaderによってフィールドの評価値と比較されます。評価値には、切り捨てられた空白文字が考慮されます。空白およびタブの切捨ての詳細は、「空白の切捨て」を参照してください。

- WHEN、NULLIFまたはDEFAULTIF句で位置を指定すると、これらの句は、SQL*Loaderによってデータ・ファイル内の元の論理レコードと比較されます。この場合、論理レコードでは空白の切捨ては行われません。

フィールドに切り捨てられた空白がある場合、あるいはWHEN、NULLIFまたはDEFAULTIF句に空白およびタブが含まれているか、BLANKSパラメータが使用されている場合は、異なる結果が得られます。名前で指定されているフィールドおよび位置で指定されているフィールドに対して同じ結果が必要な場合は、PRESERVE BLANKSオプションを使用します。PRESERVE BLANKSオプションによって、フィールド値の評価時にSQL*Loaderによって空白文字が切り捨てられないようにします。

WHEN、NULLIFまたはDEFAULTIF句は、SQL*Loaderの処理手順によっても結果に影響します。SQL*Loaderは次の手順を順番に実行します。ただし、すべての手順を実行するわけではありません。フィールドが設定されると、設定作業の残りの手順は無視されます。たとえば、手順5でフィールドが設定された場合、SQL*Loaderは手順6には進みません。

1. SQL*Loaderで、入力レコードの各フィールドの値が評価され、空白およびタブの切り捨てに関する既存のガイドラインに従って、切り捨てる必要のある空白が切り捨てられます。

2. 各レコードに対して、SQL*Loaderで表のWHEN句が評価されます。

3. レコードが表のWHEN句を満たす場合、またはWHENが指定されていない場合は、SQL*Loaderで、NULLIF句の各フィールドが確認されます。

4. NULLIF句が存在する場合は、SQL*Loaderで評価されます。

5. NULLIF句が満たされている場合は、SQL*LoaderではフィールドがNULLに設定されます。

6. NULLIF句が満たされていない場合、またはNULLIF句がない場合は、SQL*Loaderのフィールド評価によってフィールド長が確認されます。フィールドがフィールド評価の結果、0の長さを持っている場合(たとえば、NULLフィールドまたは結果としてNULLフィールドとなる空白の切捨て)は、SQL*LoaderでフィールドがNULLに設定されます。この場合、フィールドに指定されたDEFAULTIF句は評価されません。

7. 指定されたNULLIF句が偽の場合、またはNULLIF句がない場合、およびフィールドがフィールド評価の結果、0の長さを持たない場合は、SQL*Loaderで、DEFAULTIF句に対するフィールドが確認されます。

8. DEFAULTIF句が存在する場合は、SQL*Loaderで評価されます。

9. DEFAULTIF句が満たされていて、データ・ファイルのフィールドが数値フィールドの場合、フィールドは0に設定されます。フィールドが数値フィールドではない場合、NULLに設定されます。次のフィールドは数値フィールドで、DEFAULTIF句を満たす場合は、0に設定されます。

- BYTEINT

- SMALLINT

- INTEGER

- FLOAT

- DOUBLE

- ZONED

- (パック)DECIMAL

- 数値型 EXTERNAL(INTEGER、FLOAT、DECIMALおよびZONED)

10. DEFAULTIF句が満たされていない場合、またはDEFAULTIF句がない場合は、SQL*Loaderによって、手順1の評価値でフィールドが設定されます。

SQL*Loaderの操作順序が原因で、予期しない結果となる場合があります。たとえば、DEFAULTIF句は、数値フィールドを0ではなくNULLに設定しているように見える場合があります。

注意:

これらの手順に示したとおり、NULLIFおよびDEFAULTIF句を使用した場合は、SQL*Loaderによる処理が増えます。そのためパフォーマンスに影響する可能性があります。手順1では、0と評価されたフィールドは、SQL*LoaderによってNULL値に設定されます。パフォーマンスを向上させるには、この機能を利用するためにデータを変更できるかどうかを検討してください。手順1でのNULL値の検出は、NULLIF句またはDEFAULTIF句の処理よりはるかに迅速に行われます。

たとえば、CHAR(5)は、論理レコードの終わりまでに格納されない場合、またはすべての空白が含まれ、空白の切捨てが有効になっている場合は、データ長が0になります。デリミタで区切られたフィールドは、フィールドの開始と終了記号の間に文字がない場合、データ長が0になります。

また、文字フィールドの場合は、通常、NULLIFの方がDEFAULTIFより迅速に処理されます(文字フィールドのデフォルト値はNULLです)。

関連項目:

- 「表レベルでのNULLIF句の指定」

WHEN、NULLIFおよびDEFAULTIF句の使用例

例10-2から例10-5に、異なる条件でWHEN句、NULLIF句およびDEFAULTIF句を使用した場合の結果を示します。これらの例では、空白またはスペースはピリオド(.)で示されています。col1およびcol2は、データベースのVARCHAR2(5)列です。

例10-2 DEFAULTIF句の無評価

制御ファイルが次のように指定されています。

(col1 POSITION (1:5),
col2 POSITION (6:8) CHAR INTEGER EXTERNAL DEFAULTIF col1 = 'aname')

データ・ファイルには次の情報が格納されています。

aname...

例10-2では、行のcol1がanameと評価され、col2が長さが0(「...」ですが、後続の空白は位置フィールドでは切り捨てられます)であるNULLと評価されます。

SQL*Loaderでcol2にロードされた最終値が確認される場合、WHEN句およびNULLIF句は評価されません。フィールド長(フィールド評価の結果、0と評価された長さ)が確認されます。したがって、SQL*Loaderでは、col2の最終値にNULLが設定されます。DEFAULTIF句は評価されず、行はcol1の場合はaname、col2の場合はNULLとしてロードされます。

例10-3 DEFAULTIF句の評価

制御ファイルが次のように指定されています。

.
.
.
PRESERVE BLANKS
.
.
.
(col1 POSITION (1:5),
col2 POSITION (6:8) INTEGER EXTERNAL DEFAULTIF col1 = 'aname'

データ・ファイルには次の情報が格納されています。

aname...

例10-3では、行のcol1が再度anameと評価されます。col2は、PRESERVE BLANKSが指定された場合、後続の空白が切り捨てられないため、「...」と評価されます。

SQL*Loaderでcol2にロードされた最終値が確認される場合、WHEN句およびNULLIF句は評価されません。0でなく3と評価されたフィールド評価からフィールド長が確認されます。

次に、SQL*LoaderではDEFAULTIF句が評価されます。col1がanameでanameと同じであるため、真と評価されます。

col2は数値フィールドであるため、SQL*Loaderではcol2の最終値に0が設定されます。行は、col1の場合は「aname」、col2の場合は0としてロードされます。

例10-4 DEFAULTIF句を使用した位置の指定

制御ファイルが次のように指定されています。

(col1 POSITION (1:5),
col2 POSITION (6:8) INTEGER EXTERNAL DEFAULTIF (1:5) = BLANKS)

データ・ファイルには次の情報が格納されています。

.....123

例10-4では、行のcol1が長さが0(...ですが、後続の空白は切り捨てられます)であるNULLと評価されます。col2は、123と評価されます。

SQL*Loaderでcol2にロードされる最終値が設定される場合、WHEN句およびNULLIF句は評価されません。0でなく3と評価されたフィールド評価からフィールド長が確認されます。

次に、SQL*LoaderではDEFAULTIF句が評価されます。.....である(1:5)を、真と評価されているBLANKSと比較されます。したがって、col2が数値フィールド(integer EXTERNALは数値)のため、SQL*Loaderではcol2の最終値に「0」が設定されます。行は、col1の場合はNULL、col2の場合は0としてロードされます。

例10-5 DEFAULTIF句を使用したフィールド名の指定

制御ファイルが次のように指定されています。

(col1 POSITION (1:5),
col2 POSITION(6:8) INTEGER EXTERNAL DEFAULTIF col1 = BLANKS)

データ・ファイルには次の情報が格納されています。

.....123

例10-5では、行のcol1が長さが0(...ですが、後続の空白は切り捨てられます)であるNULLと評価されます。col2は、123と評価されます。

SQL*Loaderでcol2の最終値が確認される場合、WHEN句およびNULLIF句は評価されません。0でなく3と評価されたフィールド評価からフィールド長が確認されます。

次に、SQL*LoaderではDEFAULTIF句が評価されます。評価の一部として、col1のフィールド評価がNULLであることが確認されます。NULLのため、DEFAULTIF句は偽と評価されます。したがって、SQL*Loaderではcol2の最終値に、フィールド評価の元の値である123が設定されます。行は、col1の場合はNULL、col2の場合は123としてロードされます。

異なるプラットフォーム間でのデータのロード

データ・ファイルを作成するプラットフォームと、そのデータ・ファイルのロード先となるプラットフォームが異なる場合は、ターゲット・システムが読取り可能な形式でデータを作成する必要があります。たとえば、ソース・システムではシステム固有の浮動小数点の内部表現に16バイトを使用し、ターゲット・システムでは浮動小数点を12バイトで表現しているとします。この場合、ソース・システムで生成されたデータを、ターゲット・システムに直接読み込ませることはできません。

この問題を解決する方法として、Oracle Netデータベース・リンクを使用してデータをロードし、データ型の自動変換機能を利用する方法があります。前述のような問題が発生した場合は、できるだけこの方法を使用してください。この場合、SQL*Loaderはソース・システムで実行する必要があります。

プラットフォーム間のロードに関する問題は、通常、システム固有のデータ型に関連して発生します。フィールドに0(ゼロ)を追加してフィールド長を長くするか、またはフィールドの一部分のみを読み込んでフィールド長を短くする(4バイト整数を使用しているシステム上に8バイト整数を読み込む場合、またはその逆のパターンがこれに相当)ことによって、問題を回避できる場合もあります。ただし、データ型の実装に互換性がない場合は、この方法で問題の解決はできません。

Oracle Netデータベース・リンクが使用できず、ターゲット・システム上で実行しているSQL*Loaderを使用してデータ・ファイルにアクセスする必要がある場合は、移植可能なSQL*Loaderデータ型(たとえば、CHAR、DATE、VARCHARC、数値型EXTERNAL)のみを使用してください。これらのデータ型を使用して書き込まれたデータ・ファイルは、システム固有のデータ型を使用して書き込まれたデータ・ファイルより大きくなる可能性があります。そのため、ロードに時間がかかりますが、異なるプラットフォームに直接転送することができます。

バイト順序スキームまたはシステム固有の整数の長さが、入力データが作成されるプラットフォームとSQL*Loaderを実行するプラットフォームの間で異なることが事前にわかっている場合は、適切な方法で、データのバイト順序またはシステム固有の整数の長さを指定します。バイト順序を指定する方法には、BYTEORDERパラメータを使用する方法、またはファイルにバイト順序マーク(BOM)を設定する方法があります。この2つの方法の詳細は、「バイト順序」を参照してください。これらの方法を実行すると、非互換性を排除し、プラットフォーム間での正常なデータ・ロードを実現できます。バイト順序がSQL*Loaderのデフォルトと異なる場合は、バイト順序を指定する必要があります。

バイト順序

注意:

この項の説明は、SQL*Loaderを実行するシステムとは異なるバイト順序スキームを持つシステム上で入力データを作成する場合のみに適用されます。それ以外の場合は、次の項に進んでください。

SQL*Loaderを使用して、SQL*Loaderが実行されているシステムとはバイト順序が異なるシステム上で作成されたデータ・ファイルから、(データ・ファイルに移植不能な特定のデータ型が含まれている場合であっても)データをロードできます。

デフォルトでは、すべてのデータ・ファイルに対するバイト順序として実行されているシステムのバイト順序が、SQL*Loaderで使用されます。たとえば、Sun Solarisシステム上では、SQL*Loaderでビッグ・エンディアン・バイト順序が使用されます。IntelまたはIntelと互換性のあるPC上では、SQL*Loaderでリトル・エンディアン・バイト順序が使用されます。

バイト順序は、データが一度に偶数バイト(通常、2バイト、4バイトまたは8バイト)書き込まれる場合、および読み込まれる場合の結果に影響します。次に例をいくつか示します。

- 2バイト整数値の1は、ビッグ・エンディアン・システムでは0x0001、リトル・エンディアン・システムでは0x0100として書き込まれます。

- 4バイト整数の66051は、ビッグ・エンディアン・システムでは0x00010203、リトル・エンディアン・システムでは0x03020100として書き込まれます。

バイト順序は、UTF16キャラクタ・セットの文字データが2バイトのエントリとして書き込まれる場合、および読み込まれる場合の結果にも影響します。たとえば、文字「a」(ASCIIでは0x61)は、ビッグ・エンディアン・システムでは0x0061、リトル・エンディアン・システムでは0x6100として書き込まれます。

Oracleでサポートされるすべてのキャラクタ・セットでは、UTF16を除いて、一度に1バイト書き込まれます。そのため、UTF8などのマルチバイト・キャラクタ・セットの場合も、文字の書込み、読取りには、システムのバイト順序に関係なく、すべてのシステムで同じ方法が使用されます。したがって、UTF16キャラクタ・セットのデータは、バイト順序依存のため移植不能です。Oracleでサポートされる他のすべてのキャラクタ・セットのデータは移植可能です。

データ・ファイルのバイト順序が問題となるのは、バイト順序依存データを含むデータ・ファイルが、SQL*Loaderが実行されているシステムとは異なるバイト順序のシステムで作成される場合のみです。SQL*Loaderでデータのバイト順序を認識できる場合、必要に応じてバイトを入れ替えて、データが正常にターゲット・データベースにロードされることを確認します。バイト・スワップとは、ビッグ・エンディアン形式のデータをリトル・エンディアン形式に変換すること、またはその逆の変換を意味します。

SQL*Loaderにデータのバイト順序を指定するには、BYTEORDERパラメータを使用するか、またはそのファイルにバイト順序マーク(BOM)を設定します。この2つの方法のいずれも使用しない場合、SQL*Loaderではデータを正常にデータ・ファイルにロードできません。

関連項目:

SQL*Loaderでのバイト・スワップの処理例については、「事例11: Unicodeキャラクタ・セットのデータのロード」を参照してください。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

バイト順序の指定

入力データ・ファイルのデータのバイト順序を指定するには、SQL*Loader制御ファイルの次の構文を使用します。

BYTEORDERパラメータには、次の特長があります。

- BYTEORDERは、SQL*Loader制御ファイルのLENGTHパラメータの後に置かれます。

- 異なるデータ・ファイルに異なるバイト順序を指定できます。ただし、INFILEパラメータの前のBYTEORDER指定が、プライマリ・データ・ファイルのすべてのリストに適用されます。

- プライマリ・データ・ファイルに対するBYTEORDER指定は、LOBFILEおよびSDFに対するデフォルトとしても使用されます。このデフォルトを上書きするには、LOBFILEまたはSDF指定を使用してBYTEORDERを指定します。

- BYTEORDERパラメータは、制御ファイル内のデータには適用されません。

- BYTEORDERパラメータは次のものに適用されます。

- 2進INTEGERデータおよびSMALLINTデータ

- 可変長フィールドのバイナリ長(VARCHAR、VARGRAPHIC、VARRAWおよびLONG VARRAWデータ型用)

- UTF16キャラクタ・セットのデータ・ファイルの文字データ

- FLOATおよびDOUBLEデータ型(データが書き込まれたシステムに、SQL*Loaderが実行されているシステム上のデータと互換性のある浮動小数点の表現がある場合)

- BYTEORDERパラメータは、次のものには適用されません。

- RAWデータ型(RAW、VARRAWまたはVARRAWC)

- 図形データ型(GRAPHIC、VARGRAPHICまたはGRAPHIC EXTERNAL)

- UTF16以外のキャラクタ・セットのデータ・ファイルの文字データ

- ZONEDまたは(PACKED) DECIMALデータ型

バイト順序マーク(BOM)の使用

Unicodeエンコーディング(UTF-16またはUTF-8)が使用されているデータ・ファイルには、ファイルの最初の数バイトにバイト順序マーク(BOM)が含まれている場合があります。キャラクタ・セットUTF-16が使用されているデータ・ファイルでは、ファイルの最初の2バイトの値{0xFE,0xFF}は、ファイルがビッグ・エンディアンのデータを含んでいることを示すBOMです。{0xFF,0xFE}という値は、ファイルにリトル・エンディアンのデータが含まれていることを示すBOMです。

第1プライマリ・データ・ファイルでUTF16キャラクタ・セットが使用され、BOMで開始されている場合は、SQL*Loaderでそのマークを読み込んで解釈し、すべてのプライマリ・データ・ファイルのバイト順序を決定します。SQL*Loaderで、BOMを読み込んで解釈し、スキップして、BOMの直後のバイトからデータを処理し始めます。BOM設定は、第1プライマリ・データ・ファイルに対するBYTEORDER指定より優先されます。第1プライマリ・データ・ファイル以外のデータ・ファイルのBOMは、バイト順序競合の確認のみに使用されます。データ・ファイルの処理中にSQL*Loaderで使用されるバイト順序の設定は変更されません。

つまり、第1プライマリ・データ・ファイルに対するバイト順序インジケータの優先順位は次のようになります。

- 第1プライマリ・データ・ファイルのBOM(データ・ファイルでバイト順序に依存したUnicodeキャラクタ・セット(UTF16)を使用し、BOMが存在する場合)

- BYTEORDERパラメータの値(INFILEパラメータの前に指定された場合)

- SQL*Loaderが実行されているシステムのバイト順序

UTF8キャラクタ・セットが使用されているデータ・ファイルでは、最初の3バイトの{0xEF,0xBB,0xBF}というBOMによって、ファイルにUTF8データが含まれていることが示されます。UTF8のデータはバイト順序依存ではないため、BOMではデータのバイト順序を指定しません。UTF8のBOMが検出された場合は、SQL*LoaderでBOMをスキップしますが、データ・ファイルの処理のためのバイト順序の設定変更は実行しません。

SQL*Loaderによって、まず、定義済の優先順位を使用して第1プライマリ・データ・ファイルのバイト順序設定を確立します。このバイト順位設定は、すべてのプライマリ・データ・ファイルに使用されます。別のプライマリ・データ・ファイルでキャラクタ・セットUTF16が使用され、BOMも含まれている場合、そのBOMの値は、第1プライマリ・データ・ファイルで確立されたバイト順序設定と比較されます。BOMの値が第1プライマリ・データ・ファイルのバイト順序設定と一致する場合は、SQL*LoaderでそのBOMをスキップし、そのバイト順序設定を使用して、BOMの直後のバイトからデータを処理し始めます。BOMの値が、第1プライマリ・データ・ファイルで確立されたバイト順序設定と一致しない場合は、SQL*Loaderでエラー・メッセージを発行し、処理を停止します。

LOBFILEまたはセカンダリ・データ・ファイル(SDF)が制御ファイルで指定される場合、ファイルを処理する準備が整うと、SQL*Loaderで各LOBFILEおよびSDFのバイト順序設定を確立します。LOBFILEおよびSDFのデフォルトのバイト順序設定は、第1プライマリ・データ・ファイルで確立されたバイト順序設定です。これは、BYTEORDERパラメータがLOBFILEまたはSDFで指定される場合は、上書きされます。いずれの場合も、LOBFILEまたはSDFでUTF16キャラクタ・セットが使用され、BOMが含まれている場合、BOMの値はファイルのバイト順序と比較されます。BOMの値がファイルのバイト順序設定と一致する場合は、SQL*LoaderでそのBOMをスキップし、そのバイト順序設定を使用して、BOMの直後のバイトからデータを処理し始めます。BOMの値が一致しない場合、SQL*Loaderからエラーが発行され、処理が停止します。

つまり、LOBFILEおよびSDFに対するバイト順序インジケータの優先順位は次のようになります。

- LOBFILEまたはSDFで指定されたBYTEORDERパラメータ値

- 第1プライマリ・データ・ファイルで確立されたバイト順序設定

注意:

データ・ファイルのキャラクタ・セットがUnicodeキャラクタ・セットで、ファイルの最初の数バイトにバイト順序マークが設定されている場合、SKIPパラメータは使用しないでください。使用した場合、バイト順序マークは読み込まれず、バイト順序マークとして解釈されません。

BOMの確認の抑止

Unicodeキャラクタ・セットのデータ・ファイルには、ファイルの最初のバイトにBOMと一致するバイナリ・データが含まれています。たとえば、integer(2)型の値0xFEFF = 65279小数点は、UTF16のビッグ・エンディアンBOMと一致します。この場合、SQL*Loaderを使用してデータ・ファイルの最初のバイトをデータとして読み込むことができます。また、値NOCHECKでBYTEORDERMARKパラメータを指定して、SQL*LoaderによってBOMを確認しないようにできます。BYTEORDERMARKパラメータの構文は次のとおりです。

BYTEORDERMARK NOCHECKを指定すると、SQL*LoaderではBOMが確認されず、データ・ファイルのすべてのデータがデータとして読み込まれます。

BYTEORDERMARK CHECKを指定すると、BOMを確認するようSQL*Loaderに指示します。これはUnicodeキャラクタ・セットのデータ・ファイルについてのデフォルト動作です。ただし、この指定は明確化の目的で制御ファイル内で使用されることがあります。Unicode以外のキャラクタ・セットを使用するデータ・ファイルについてBYTEORDERMARK CHECKを指定すると、エラーとなります。

BYTEORDERMARKパラメータには、次の特長があります。

- SQL*Loader制御ファイル内のオプションのBYTEORDERパラメータの後に置かれます。

- プライマリ・データ・ファイルの構文指定に適用される以外に、LOBFILEとセカンダリ・データ・ファイル(SDF)にも適用されます。

- 異なるデータ・ファイルに異なるBYTEORDERMARK値を指定できます。ただし、INFILEパラメータの前のBYTEORDERMARK指定が、プライマリ・データ・ファイルのリスト全体に適用されます。

- プライマリ・データ・ファイルに対するBYTEORDERMARK指定は、LOBFILEおよびSDFに対するデフォルトとしても使用されます。ただし、LOBFILEまたはSDFでUnicode以外のキャラクタ・セットが使用されている場合は、値CHECKは無視されます。LOBFILEおよびセカンダリ・データ・ファイルに対するこのデフォルト設定は、LOBFILEまたはSDF指定にBYTEORDERMARKを指定することによって上書きできます。

すべてが空白のフィールドのロード

フィールドが完全に空白のレコードは拒否されます。これらのフィールドのいずれかをNULLとしてロードするには、BLANKSパラメータを持つNULLIF句を使用します。

空白のフィールドがCHAR型で、囲みデリミタによって囲まれている場合は、囲みデリミタで囲まれている空白部分がロードされます。囲みデリミタで囲まれていない場合は、そのフィールドはNULLとしてロードされます。

DATEフィールドまたは数値フィールドのデータがすべて空白の場合は、NULLフィールドとしてロードされます。

関連項目:

- NULLIF句を使用して、すべてが空白のフィールドをNULLとしてロードする方法の例については、「事例6: ダイレクト・パス・ロード方式を使用したデータのロード」を参照してください。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

- 「空白の切捨て」

- 「空白の切捨てに対するPRESERVE BLANKSオプションの影響」

空白の切捨て

空白、タブおよびその他の印字されない文字(改行、LFなど)が空白を構成します。先頭の空白は、フィールドの開始位置にあります。後続の空白は、フィールドの終了位置にあります。フィールドの指定方法にもよりますが、空白は、フィールドのデータベースへの挿入時に、データの一部として含めることも切り捨てることもできます。これについて、図10-1に示します。この図では、2つのCHARフィールドがデータ・レコードに定義されています。

フィールド指定は制御ファイルに含まれています。制御ファイルのCHAR指定は、データベースのCHAR指定と同じではありません。制御ファイル内でCHARとして定義されたデータ・フィールドは、SQL*Loaderに行挿入の作成方法を指定するのみです。Oracle Databaseで必要な変換が行われ、データベースのCHAR、VARCHAR2、NCHAR、NVARCHAR2、NUMBERまたはDATE列にデータを挿入できるようになります。

デフォルトでは、SQL*Loaderを使用してCHARデータから後続の空白を削除した後、このデータをデータベースに渡します。その後、図10-1に示すとおり、フィールド1とフィールド2は3バイトのフィールドとしてデータベースに渡されます。ただし、データを表に挿入する場合は処理が異なります。

図10-1 フィールド変換の例

列1は、データベース内で長さ5の固定長CHAR列として定義されます。そのため、データ(aaa)は5バイトの幅を保持したまま、その列で左揃えにされます。余った右側の部分は空白で埋められます。一方、列2は、最大長5バイトの可変長フィールドとして定義されています。その列(bbb)のデータも左揃えにされますが、長さは3バイトのままです。

表10-5に、PRESERVE BLANKSが指定されていない場合に空白が入力データ・フィールドから切り捨てられるケースおよびその処理方法を示します。空白の切捨てを回避する方法については、「空白の切捨てに対するPRESERVE BLANKSオプションの影響」を参照してください。

表10-5 空白の切捨てに関する動作のサマリー

指定

データ

結果

先頭の空白の存在(1)

後続の空白の存在1

サイズ指定あり

__aa__

__aa

あり

なし

終了デリミタ

__aa__,

__aa__

あり

あり脚注2

囲みデリミタ

"__aa__"

__aa__

あり

あり

終了と囲み

"__aa__",

__aa__

あり

あり

オプションの囲み(あり)

"__aa__",

__aa__

あり

あり

オプションの囲み(なし)

__aa__,

aa__

なし

あり

前のフィールドが空白で区切られている場合

__aa__

aa脚注3

なし

脚注参照 3

脚注 1 空白のみのフィールドが切り捨てられた場合、その値はNULLになります。

脚注2

空白で終了するフィールドを除きます。

脚注3

後続の空白があるかどうかは、表中の他の項目に示すとおり、現行のフィールドの指定によって異なります。

この項の残りの部分では、空白の切捨てに関する次の項目について説明します。

- 空白の切捨てが可能なデータ型

- 空白の切捨てが可能なデータ型に対するフィールド長指定

- フィールドの相対的な位置指定

- 先頭の空白

- 後続の空白の切捨て

- 囲まれたフィールドの切捨て

空白の切捨てが可能なデータ型

次の説明は、データ型が文字データ型であるフィールドにのみ適用できます。

- CHARデータ型

- 日時および期間データ型

- 数値型EXTERNALデータ型:

- INTEGER EXTERNAL

- FLOAT EXTERNAL

- (パック)DECIMAL EXTERNAL

- ZONED(10進)EXTERNAL

注意:

VARCHAR型およびVARCHARC型フィールドも文字データを含みますが、フィールド中の空白は切り捨てられません。これらのフィールドは、データ・ファイルのフィールド中の空白文字をすべて含みます。

空白の切捨てが可能なデータ型に対するフィールド長指定

フィールド長の指定には2通りの方法があります。制御ファイルで位置指定またはデータ型および長さについてフィールド長の定数を定義した場合、そのフィールドは、事前にサイズが決まっていることになります。一方、フィールド長を事前に指定しないでレコード中のインジケータでフィールド長を決める場合は、そのフィールドを囲みデリミタまたは終了デリミタのいずれかを使用して区切ります。

開始値および終了値での位置指定は、囲みデリミタまたは終了デリミタが定義されるフィールドに対して定義されます。囲みデリミタまたは終了デリミタは無視されます。

事前にサイズが決まっているフィールド

フィールドのサイズを事前に決定するには、フィールドの開始位置と終了位置を指定するか、フィールド長を指定します。それぞれの指定例を示します。

loc POSITION(19:31)
loc CHAR(14)

2番目の例では、フィールド位置は指定されていませんが、フィールド長は事前に指定されています。

デリミタ付きフィールド

デリミタとは、フィールドの境界を指定する文字のことです。

囲みデリミタは、次の例("__"が空白またはタブを表す)中の引用符のように、フィールドを囲みます。

"__aa__"

一方、終了デリミタは、フィールドの終わりを示します。次の例中のカンマがこれに相当します。

__aa__,

デリミタに使用する文字は、制御句TERMINATED BYおよびENCLOSED BYを使用して指定します。次に指定例を示します。

loc TERMINATED BY "." OPTIONALLY ENCLOSED BY '|'

フィールドの相対的な位置指定

この項では、次の条件でSQL*Loaderを使用してフィールドの開始位置を決定する方法について説明します。

- フィールドの開始位置が指定されていない場合

- 前のフィールドの終端がデリミタで指定されている場合

- 前のフィールドに囲みデリミタおよび終了デリミタの両方が含まれる場合

フィールドの開始位置が指定されていない場合

フィールドの開始位置が指定されていない場合は、前のフィールドの終了位置の直後の位置が、そのフィールドの開始位置となります。図10-2に、前のフィールド(フィールド1)のサイズが事前に決定されている場合の例を示します。

図10-2 固定長フィールドの後の相対的な位置指定

前のフィールドの終端がデリミタで指定されている場合

前のフィールド(フィールド1)の終端がデリミタで指定されている場合、次のフィールドはそのデリミタの直後から開始します。この例を図10-3に示します。

図10-3 デリミタ付きフィールドの後の相対的な位置指定

前のフィールドに囲みデリミタおよび終了デリミタの両方が含まれる場合

フィールドが囲みデリミタと終了デリミタの両方で指定された場合、その次のフィールドは終了デリミタの直後の位置から開始します。この例を図10-4に示します。囲みデリミタから終了デリミタまでの間に空白以外の文字がある場合は、エラーが出力されます。

図10-4 囲みデリミタの後の相対的な位置指定

先頭の空白

図10-4の例では、2つのフィールドはともに先頭の空白が付いた状態で格納されます。ただし、次のような場合、先頭の空白はフィールドのデータに含まれません。

- 前のフィールドが空白で区切られて(終了して)いて、現行のフィールドの開始位置が指定されていない場合。

- フィールドに対してオプションの囲みデリミタが指定されているにもかかわらず、その囲みデリミタが使用されていない場合。

これらの事例については、次の項で例示します。

前のフィールドが空白で区切られている場合

前のフィールドがTERMINATED BY WHITESPACEで区切られていると、そのフィールドの後に続く空白はすべてデリミタとみなされます。この場合、次のフィールドは、次に空白以外の文字が現れた位置から開始します。この例を図10-5に示します。

図10-5 空白で区切られたフィールド

このようなケースは、前述の例のとおり前のフィールドがTERMINATED BY WHITESPACE句で明示的に指定された場合に発生します。グローバルにFIELDS TERMINATED BY WHITESPACE句が指定された場合も、このケースに相当します。

オプションの囲みデリミタ

オプションの囲みデリミタが指定されているにもかかわらず、それが使用されていない場合も、先頭の空白は切り捨てられます。

オプションの囲みデリミタが指定されると、SQL*Loaderによって前方スキャンが実行され、最初の囲みデリミタが検索されます。囲みデリミタがない場合は、空白がスキップされ、フィールドから削除されます。最初に見つかった空白以外の文字がフィールドの開始と判断されます。この例を図10-6のフィールド2に示します。(フィールド1では、SQL*Loaderによってフィールドの囲みデリミタが検出されたため空白が含まれます)。

図10-6 オプションの囲みデリミタ付きフィールド

前のフィールドがTERMINATED BY WHITESPACEで区切られた場合と異なり、前述のように指定された場合は、現行のフィールドの開始位置が指定されていても先頭の空白は切り捨てられます。

注意:

囲みデリミタが存在する場合は、最初の囲みデリミタの後の先頭の空白はそのままデータとして保持されますが、この囲みデリミタの前にある空白は切り捨てられます。図10-6のフィールド1の最初の引用符がこのケースに相当します。

後続の空白の切捨て

後続の空白は、フィールドが文字データ型で事前にフィールド・サイズが決まっている場合、常に切り捨てられます。後続の空白が常に切り捨てられるのは、これらのフィールドのみです。

囲まれたフィールドの切捨て

フィールドが囲みデリミタで囲まれている場合、または、図10-6の最初のフィールドのように終了デリミタと囲みデリミタの両方で区切られている場合、囲みデリミタの外側にある空白は、フィールドの一部とはみなされません。囲みデリミタの内側に空白があれば、それが先頭の空白または後続の空白のいずれであっても、フィールドの一部とみなされます。

空白の切捨てに対するPRESERVE BLANKSオプションの影響

すべてのCHARフィールド、DATEフィールド、および数値型EXTERNALフィールドで空白が切り捨てられないようにするには、制御ファイル内のLOAD文でPRESERVE BLANKSを指定します。ただし、すべてのCHAR、DATEまたは数値型EXTERNALフィールドに空白を残す必要がない場合があります。その場合は、SQL*Loaderを使用して、PRESERVE BLANKSを、LOAD文でグローバルに指定するのではなく、個々のフィールドのデータ型指定で指定することもできます。

次の例では、PRESERVE BLANKSがLOAD文で指定されていない場合に、空白を含むc1フィールドをデフォルトでゼロにします。これは、個々のフィールドに対してPRESERVE BLANKSを指定することで実現できます。指定したフィールドのみで空白が切り捨てられ、その他のフィールドでは空白はそのまま残されます。

c1 INTEGER EXTERNAL(10) PRESERVE BLANKS DEFAULTIF c1=BLANKS

この例では、PRESERVE BLANKSがフィールドに対して指定されていない場合、そのフィールドがNULL(0ではなく)として誤ってロードされます。

LOAD文に対するオプションとしてPRESERVE BLANKSを指定して、ほとんどのCHAR、DATEおよび数値型EXTERNALフィールドに適用する必要がある場合があります。このオプションの指定は、個々のフィールドのデータ型指定でNO PRESERVE BLANKSを指定して上書きできます。次に例を示します。

c1 INTEGER EXTERNAL(10) NO PRESERVE BLANKS

[NO] PRESERVE BLANKSとデリミタ句の併用

デリミタ句が指定されていると、PRESERVE BLANKSオプションに次のような影響があります。

- オプションの囲みデリミタがない場合、先頭の空白はそのまま残ります。

- 事前にフィールド・サイズが指定された場合にも、後続の空白を残します。

たとえば、次のフィールドについて考えてみます。ここでは、アンダースコアは空白を表します。

__aa__,

このフィールドが次のデリミタ句でロードされるとします。

TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'

この場合、PRESERVE BLANKSを指定すると、先頭の空白および後続の空白がともに保存されます。PRESERVE BLANKSを指定しない場合は、先行する空白は切り捨てられます。

次に、このフィールドが次の句でロードされるとします。

TERMINATED BY WHITESPACE

この場合、PRESERVE BLANKSを指定すると、次のフィールドの先頭の空白は、このフィールドが空白を含むPOSITION句で指定されていないかぎり保存されません。このような指定がない場合は、SQL*Loaderによって前のフィールドの終わりにあるすべての空白を読み込まずにスキャンが実行され、次に空白以外の文字またはタブ以外の文字が現れた位置が次のフィールドの開始位置と認識されます。

関連項目:

「空白の切捨て」

フィールドへのSQL演算子の適用

SQL文字列を使用することによって、様々なSQL演算子をフィールド・データに適用できます。SQL文字列には、任意に組み合せたSQL式を組み込むことができます。ただし、このSQL式は、Oracle DatabaseによってINSERT文中のVALUES句に対して有効であると認識されたものにかぎります。通常、ターゲット列のデータ型と互換性のある単一の値を返すSQL関数を使用できます。SQL文字列は、列オブジェクトおよびコレクションなどのユーザー定義の複合型に加えて、単純なスカラー列型にも適用できます。

列名とSQL文字列のバインド変数における列名は、SQL識別子のルールによる解釈の結果、同じ列に対応している必要があります。ただし、次の例に示すとおり、2つの名前を完全に同じ記述にする必要はありません。

LOAD DATA
INFILE *
APPEND INTO TABLE XXX
( "Last"   position(1:7)     char   "UPPER(:\"Last\")"
first   position(8:15)    char   "UPPER(:first || :FIRST || :\"FIRST\")"
)
BEGINDATA
Grant  Phil
Taylor Jason

前述の例では、次のことに注意してください。

- 表の作成時、(前述の"Last"という列のように)列識別子に小文字または特殊文字(あるいはその両方)が含まれているために二重引用符を使用して宣言されている場合、バインド変数の列名は、CREATE TABLE文で使用される列名と完全に一致する必要があります。

- 表の作成時、(前述のfirstという列のように)列識別子が二重引用符を使用しないで宣言されている場合は、first、FIRSTおよび"FIRST"のすべてが大文字として処理され、FIRSTに解決されるため、SQL文字列のバインド変数では、これらのいずれの書式も使用できます。

SQL文字列を使用する場合は、次のことに注意してください。

- SQL文字列の実行は、フィールド設定の一部としてみなされません。SQL文字列を実行する場合、フィールド設定およびNULLIFやDEFAULTIF句の結果が使用されます。したがって、評価の順序は次のとおりです(手順1と2は「WHEN、NULLIFおよびDEFAULTIF句の使用」で説明されている手順の要約です)。

1. フィールド設定が実行されます。

2. NULLIFまたはDEFAULTIF句が適用されます(これにより、このような句が含まれるフィールドのフィールド設定の結果が変更されることがあります)。NULLIFおよびDEFAULTIF句をSQL式で使用すると、FINAL型の列の結果ではなく、フィールド設定の結果に影響があります。

3. SQL式は、手順1と2の終了後に得られたフィールドの結果を使用して評価されます。結果は、SQL式を含む列に従って割り当てられます。(SQL式が存在しない場合、手順1と2から得られた結果が列に割り当てられます。)

- 関連付けられたSQL文字列を含む文字入力が制御ファイルによって指定されている場合、SQL*Loaderによるデータ変更は試行されません。これは、SQL*Loaderでは、SQL演算子を使用して変更した文字入力データは、データベースの挿入に対し正しい結果を生成すると仮定されているためです。

- SQL文字列を指定する位置は、その列に関するその他の指定がすべて記述された後になります。

- SQL文字列は、二重引用符で囲んで記述します。

- SQL文字列内の列名を引用符で囲むには、エスケープ文字を使用する必要があります。
前述の例では、Lastを二重引用符で囲んで大文字および小文字の組合せを保持しています。また、二重引用符を使用すると、バックスラッシュ(エスケープ)文字も使用する必要があります。

- SQL文字列に列オブジェクト属性を参照する列名が含まれている場合は、バインド変数にオブジェクト属性をフルネームで指定する必要があります。フルネームの各属性名は、個々の識別子です。各識別子は、SQL識別子の引用符ルールに従い、フルネームの他の識別子からは独立しています。たとえば、"HEIGHT_%TILE"という名前の属性を持つCHILDという列オブジェクトがあるとします。(その属性名は、二重引用符で囲まれています。)バインド変数にオブジェクト属性をフルネームで指定するには、次のいずれかの書式を使用します。

- :CHILD.\"HEIGHT_%TILE\"

- :child.\"HEIGHT_%TILE\"

フルネームを引用符で囲む(:\"CHILD.HEIGHT_%TILE\")と、バインド変数で使用されるオブジェクト属性名の引用符ルールは変更されたという警告メッセージが生成されます。この警告は、バインド変数を正確に指定するように求めるためのものであり、ロードが異常終了することはありません。名前を引用符で囲むと、SQLでは、名前が複数の識別子で構成される列オブジェクト属性フルネームとしてではなく、1つの識別子として解釈されるため、引用符ルールは変更されました。

- SQL文字列の評価は、NULLIF句またはDEFAULTIF句の後、日時マスクよりも前に行われます。

- Oracle Databaseで文字列を認識できない場合は、エラーが発生してロードは終了します。文字列が認識されても、データベース・エラーが発生すると、エラーの発生した行は拒否されます。

- フィールド指定でEXPRESSIONパラメータを使用する場合は、SQL文字列が必要です。

- SQL文字列では、OID、SID、REFまたはBFILEを使用してロードしたフィールドは参照できません。また、FILLERフィールドやSQL文字列を使用する他のフィールドも参照できません。

- ダイレクト・パス・モードでは、SQL文字列でのVARRAY、ネストした表またはLOB列の参照はできません。これには、列オブジェクトの属性であるVARRAY、ネストした表またはLOB列も含まれます。

- SQL文字列は、RECNUM、SEQUENCE、CONSTANTまたはSYSDATEフィールドでは使用できません。

- SQL文字列は、LOB、BFILE、XML列またはコレクションの要素であるファイルでは使用できません。

- ダイレクト・パス・モードでは、SQL文字列の式の評価後に返される最後の結果はスカラー・データ型である必要があります。つまり、ダイレクト・パス・ロードの実行時、式によってはオブジェクトまたはコレクション・データ型を返さない場合があります。

フィールドの参照

レコード中のフィールドを参照する場合は、フィールド名の前にコロン(:)を付けます。このように指定すると、現在のレコードのフィールド値が代入されます。SQL文字列で、前にコロン(:)が付いたフィールド名もバインド変数として参照されます。一重引用符で囲まれたバインド変数は、バインド変数としてではなくテキスト・リテラルとして扱われることに注意してください。

次の例では、制御ファイルの現行のフィールドおよび他のフィールドの参照方法を示します。また、バインド変数を一重引用符で囲むことにより、テキスト・リテラルとして扱われることを示しています。示されている概念を十分に理解するために、次の例の説明も参照してください。

LOAD DATA
INFILE *
APPEND INTO TABLE YYY
(
field1  POSITION(1:6) CHAR "LOWER(:field1)"
field2  CHAR TERMINATED BY ','
NULLIF ((1) = 'a') DEFAULTIF ((1)= 'b')
"RTRIM(:field2)",
field3  CHAR(7) "TRANSLATE(:field3, ':field1', ':1')",
field4  COLUMN OBJECT
(
attr1  CHAR(3) NULLIF field4.attr2='ZZ' "UPPER(:field4.attr3)",
attr2  CHAR(2),
attr3  CHAR(3)  ":field4.attr1 + 1"
),
field5  EXPRESSION "MYFUNC(:FIELD4, SYSDATE)"
)
BEGINDATA
ABCDEF1234511  ,:field1500YYabc
abcDEF67890    ,:field2600ZZghl

この例に関する注意事項:

- 次の行では、:field1は一重引用符で囲まれていないため、バインド変数として解釈されます。
field1 POSITION(1:6) CHAR "LOWER(:field1)"

- 次の行では、':field1'と':1'は一重引用符で囲まれているため、テキスト・リテラルとして解釈され、変更されずにTRANSLATE関数に渡されます。
field3 CHAR(7) "TRANSLATE(:field3, ':field1', ':1')"

引用符で囲まれた文字列中で引用符を使用する方法の詳細は、「ファイル名およびオブジェクト名の指定」を参照してください。

- 各入力データ読取りでは、バインド変数で参照されたフィールドの値はバインド変数に置き換えられます。たとえば、最初のレコードの値ABCDEFは、最初のフィールド:field1にマップされます。この値は、引数としてLOWER関数に渡されます。

- SQL文字列のバインド変数によって現行のフィールドを参照する必要はありません。前述の例では、フィールドfield4.attr1に対するSQL文字列のバインド変数によって、フィールドfield4.attr3を参照しています。field4.attr1フィールドは、入力レコードの値500およびNULL (2番目のレコードのNULLIF field4.attr2='ZZ'句がTRUEであるため)にマップされます。ただし、対応する列に格納された最終値はABCおよびGHLです。
field4.attr3フィールドは、入力レコードの値ABCおよびGHLにマップされます。ただし、SQL式がfield4.attr1を参照しているため、対応する列に格納された最終値は500 + 1 = 501およびGHLです。(NULLフィールドに1を足しても、結果はNULLフィールドになります。)

- field5フィールドは、入力レコードのどのフィールドにもマップされません。ターゲット列に格納されている値は、2つの引数をとるPL/SQL関数MYFUNCの実行結果です。EXPRESSIONパラメータの使用には、入力データがフィールドにマップされないため、SQL文字列を使用して列の最終値を計算する必要があります。

フィールド指定でのSQL演算子の共通使用

次のタスクでは、共通してSQL演算子が使用されています。

- 暗黙の小数点が付いているEXTERNALデータをロードするには、次のように指定します。

field1 POSITION(1:9) DECIMAL EXTERNAL(8) ":field1/1000"

- また、長すぎるフィールドを切り捨てるには、次のように指定します。

field1 CHAR TERMINATED BY "," "SUBSTR(:field1, 1, 10)"

SQL演算子の組合せ

複数の演算子を次の例のように組み合せることができます。

field1 POSITION(*+3) INTEGER EXTERNAL
"TRUNC(RPAD(:field1,6,'0'), -2)"
field1 POSITION(1:8) INTEGER EXTERNAL
"TRANSLATE(RTRIM(:field1),'N/A', '0')"
field1 CHAR(10)
"NVL( LTRIM(RTRIM(:field1)), 'unknown' )"

日付マスク付きのSQL文字列の使用

日付マスクと併用する場合、日付マスクはSQL文字列の後で評価されます。次のように指定されるフィールドがあるとします。

field1 DATE "dd-mon-yy" "RTRIM(:field1)"

SQL*Loaderの内部で次の文が生成され、挿入されます。

TO_DATE(RTRIM(<field1_value>), 'dd-mon-yyyy')

SQL文字列でDATEフィールド・データ型を使用する場合、日付マスクが必要です。これは、SQL*Loaderで、DATEパラメータの後の最初の引用符付き文字列が日付マスクであるとみなされるためです。たとえば、次のフィールド指定では、エラー(ORA-01821: 日付書式コードが無効です)が発生します。

field1 DATE "RTRIM(TO_DATE(:field1, 'dd-mon-yyyy'))"

この場合の簡単な解決策は、CHARデータ型を使用することです。

書式化されたフィールドの解析

TO_CHAR演算子を使用して、書式化された日付および数値を格納できます。次に例を示します。

field1 ... "TO_CHAR(:field1, '$09999.99')"

この例では、数値型の入力データを、書式化された形式で格納することができます。この場合、field1はデータベース中ではキャラクタ列です。この指定にある書式化文字(ドル記号やピリオドなど)は、データとともにそのままフィールドに格納されます。

ただし、このような値を数量や日付として格納すると、より柔軟な処理を行うことができます。この場合、データベース内の値に算術関数を指定しても、書式化された値を選択してレポートを作成することができます。

SQL文字列を使用して、書式化されたレポートからデータをロードする例は、「事例7: 書式化されたレポートからのデータの抽出」にあります。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

SQL文字列を使用したANYDATAデータベース型へのロード

ANYDATAデータベース型には、異なる型のデータを格納できます。SQL*loaderを使用してANYDATA型をロードするには、ファンクション・コールによって明示的に構築する必要があります。ファンクションは、この項で説明したとおり、SQL文字列のサポートを使用してコールします。

たとえば、ANYDATA型のmiscellaneousという名前の列を含む表があるとします。この列は、次のようにしてロードできます。この場合、番号を含むANYDATA型が作成されます。

LOAD DATA
INFILE *
APPEND INTO TABLE  ORDERS
(
miscellaneous CHAR "SYS.ANYDATA.CONVERTNUMBER(:miscellaneous)"
)
BEGINDATA
4

レコード内の値によっては、さらに複雑な条件で、異なる型を含むANYDATA型を作成する場合もあります。そのためには、レコード内の値に基づいて、ANYDATA型にする型を決定する独自のファンクションを記述し、適切なANYDATA.Convert*()ファンクションをコールしてその型を作成する必要があります。

関連項目:

- ANYDATAデータベース型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- PL/SQLでのANYDATAの使用方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

SQL*Loaderを使用した入力データの生成

この項では、データ・ファイルからデータを読み込むのではなく、SQL*Loaderでデータを生成してデータベース・レコードに格納するパラメータについて説明します。ここで説明するパラメータは次のとおりです。

- CONSTANTパラメータ

- EXPRESSIONパラメータ

- RECNUMパラメータ

- SYSDATEパラメータ

- SEQUENCEパラメータ

ファイルを使用しないデータのロード

フィールドの指定として順序、レコード番号、システム日付、定数およびSQL文字列式のみを指定してSQL*Loaderでデータを生成できます。

SQL*Loaderを使用して、LOAD文で指定された数のレコードを挿入します。この場合、SKIPパラメータは指定できません。

SQL*Loaderは、このような場合用に最適化されています。生成された指定のみが使用されていることを検出すると、SQL*Loaderでは、常に、指定されたすべてのデータ・ファイルが無視されます。I/Oの読取りは実行されません。

バインド配列用のメモリーも不要です。制御ファイル中にWHEN句が指定されている場合は、SQL*Loaderでデータの評価が必要であると判断され、入力レコードが読み込まれます。

列への定数値の設定

これは、生成するデータとしては最も単純な形式です。ロード中であっても、何回ロードしても、このデータは変わりません。

CONSTANTパラメータ

列に定数値を設定するには、CONSTANTを指定して、その後に値を指定します。

CONSTANT  value

CONSTANTデータは、SQL*Loaderでは、文字入力として認識されます。このデータは、必要に応じてデータベース列のデータ型に変換されます。

値を引用符で囲むこともできます。特に、指定する値に空白や予約語が含まれている場合は、必ず引用符で囲んでください。また、ターゲット列に対して必ず有効な値を指定してください。指定した値が無効な場合は、すべてのレコードが拒否されてしまいます。

2の32乗-1(4,294,967,295)より大きい数値は引用符で囲んでください。

注意:

CONSTANTパラメータを使用して列にNULLを設定することはできません。列をNULLに設定する場合は、その列については何も指定しないでください。これによって、Oracleでレコードをロードするときに、その列に自動的にNULLが設定されます。CONSTANTおよび値の組合せを指定すると、列指定は完結します。

列への式の値の設定

列名の後にEXPRESSIONパラメータを使用して、SQL演算子または特別に書き込まれたPL/SQL関数によって返された値に、その列を設定します。EXPRESSIONパラメータの後に続くSQL文字列に、演算子または関数が指定されます。演算子または関数に必要なパラメータが適切に指定され、その演算子または関数によって返された結果が、ロード中の列のデータ型と互換性がある場合、任意の式を使用できます。

EXPRESSIONパラメータ

列名、EXPRESSIONパラメータおよびSQL文字列の組合せは、完全なフィールド指定です。

column_name EXPRESSION "SQL string"

従来型パス・モードおよびダイレクト・パス・モードの両方で、EXPRESSIONパラメータを使用して、デフォルト値をcolumn_nameにロードできます。

column_name EXPRESSION "DEFAULT"

DEFAULTを使用し、モードがダイレクト・パスの場合、順序をデフォルトとして使用しても機能しません。

データファイル・レコード番号への1列の設定

RECNUMパラメータを列名の後に指定すると、レコードのロード元である論理レコードの番号が、その列に設定されます。レコードの番号は、最初のデータ・ファイルの先頭をレコード1として、順番にカウントされます。RECNUMは、各論理レコードが構成されるたびに増えていきます。廃棄、スキップ、拒否またはロードされたレコードもカウントされます。SKIP=10と指定した場合、最初にロードされるレコードのRECNUMの値は11になります。

RECNUMパラメータ

列名およびRECNUMの組合せを指定すると、列指定は完結します。

column_name RECNUM

列への現在の日付の設定

SYSDATEを使用して列を指定すると、SQL言語のSYSDATEパラメータで定義されているとおりに現在のシステム日付が取得されます。詳細は、『Oracle Database SQL言語リファレンス』のDATEデータ型に関する項を参照してください。

SYSDATEパラメータ

列名とSYSDATEパラメータの組合せを指定すると、列指定は完結します。

column_name SYSDATE

データベースの列のデータ型は、CHARまたはDATE型にしてください。列がCHAR型の場合、日付は'dd-mon-yy'の書式でロードされます。ロード後は、この書式でのみ日付のロードができます。システム日付をDATE列にロードすると、そのシステム日付は、時間と日付を含む様々な書式でロードできます。

新しいシステム日付/時間は、従来型パス・ロードで挿入されたレコードの各配列や、ダイレクト・パス・ロード中にロードされた各レコード・ブロックで使用されます。

列への一意の順序番号の設定

SEQUENCEパラメータは、特定の列に対して一意の値を設定します。SEQUENCEの値は、ロードされたレコードまたは拒否されたレコードが発生するたびに増加します。廃棄またはスキップされたレコードに対しては、値は増加しません。

SEQUENCEパラメータ

列名とSEQUENCEパラメータの組合せを指定すると、列指定は完結します。

表10-6では、列指定に使用されるパラメータについて説明します。

表10-6 列指定に使用されるパラメータ

パラメータ

説明

column_name

データベース内の、順序を割り当てる列の名前。

SEQUENCE

列の値を指定するには、このSEQUENCEを使用します。

COUNT

順序番号は表中にすでにあるレコード数で始まり、以降は増分値を加えた値が設定されます。

MAX

順序番号は列の現在の最大値で始まり、以降は増分値を加えた値が設定されます。

integer

先頭となる特定の順序番号を指定します。

incr

レコードがロードまたは拒否された後の順序番号の増分値。これはオプションです。デフォルトは1です。

レコードが拒否された場合(書式エラーがあるか、またはOracleエラーが発生した場合)でも、その欠落を埋めるために生成された順序番号が変更されることはありません。たとえば、ある列に関して、4つの行に順序番号10、12、14および16が割り当てられ、番号12の行が拒否されたとします。この場合、挿入された3つの行の番号は10、14および16であって、10、12および14ではありません。このような処理が行われることによって、データ・エラーが発生しても、挿入時の順番を保持できます。拒否されたデータを修正して再度挿入する場合は、列の順序番号に一致するようにデータを手動で設定できます。

「事例3: 自由区分形式ファイルのロード」に、SEQUENCEパラメータの使用例があります。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

複数の表に対する順序番号の生成

一意の順序番号は、各表への挿入時に生成されるのではなく、各論理入力レコードに対して生成されます。したがって、データを複数の表に挿入する場合、同じ順序番号を使用することができます。この仕様は、多くの場合に有効です。

ただし、INTO TABLE句ごとに別の順序番号を生成する場合もあります。たとえば、各入力レコード中に3つの論理レコードが定義された形式のデータについて考えます。この場合、INTO TABLE句を3つ使用して、レコードの3つの異なる部分を同じ表に挿入するように指定できます。SEQUENCE(MAX)を使用すると、各表の最大値が採用されるため、順序番号に一貫性がなくなります。

このレコードの順序番号を生成する場合は、挿入する3つの論理レコードそれぞれに対して、重複しない番号を生成する必要があります。1レコード当たりの表挿入の回数を順序番号の増分値として使用し、各挿入の順序番号をその続き番号で始めるようにします。

例: 挿入ごとの順序番号の生成

次に示す部門名をdept表にロードするとします。各入力レコードには部門名が3つ入っています。この部門番号を自動生成する方法について考えます。

Accounting     Personnel      Manufacturing
Shipping       Purchasing     Maintenance
...

部門番号を重複しないように生成するには、次のような制御ファイル・エントリを作成します。

INTO TABLE dept
(deptno  SEQUENCE(1, 3),
dname   POSITION(1:14) CHAR)
INTO TABLE dept
(deptno  SEQUENCE(2, 3),
dname   POSITION(16:29) CHAR)
INTO TABLE dept
(deptno  SEQUENCE(3, 3),
dname   POSITION(31:44) CHAR)

最初のINTO TABLE句で生成される部門番号は1で、2番目では2が、3番目では3が生成されます。これらすべてで増分値として3が使用されます(増分値は各レコードに含まれる部門名の数と一致します)。この制御ファイルでロードを実行すると、Accounting部門は部門番号1、Personnel部門は部門番号2、Manufacturing部門は部門番号3でロードされます。

また、次のレコードになると、順序番号は増分値分のみ増加するので、Shipping部門は部門番号4、Purchasing部門は部門番号5でロードされ、以降も同様にロードされます。

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

SQL*Loaderを使用して、様々な形式で列オブジェクトがロードでき、オブジェクト表、REF列、LOBおよびコレクションのロードができます。次のトピックを参照してください。

- 列オブジェクトのロード

- オブジェクト表のロード

- REF列のロード

- LOBのロード

- BFILE列のロード

- コレクション(ネストした表およびVARRAY)のロード

- 動的および静的SDF指定

- 親表を子表から分割してのロード

列オブジェクトのロード

制御ファイルの列オブジェクトは、その属性によって記述されています。列オブジェクトの基になるオブジェクト型がNOT FINALであると宣言されると、制御ファイルの列オブジェクトは、基になるオブジェクト型から導出されたサブタイプの(導出および宣言された)属性によって記述されます。データ・ファイルでは、列オブジェクトの各属性に対応するデータは、単純なリレーショナル列に対応するデータ・フィールドと同様の形式でデータ・ファイルに記述されています。

注意:

SQL*Loaderによる列オブジェクトなどの複合データ型のサポートによって、制御ファイル内に、2つの同じフィールド名が存在する可能性があります。1つは列に対応し、もう1つは列オブジェクトの属性に対応する場合です。制御ファイルに同名のフィールドが存在する場合、特定の句がフィールド(たとえば、WHEN、NULLIF、DEFAULTIF、SID、OID、REF、BFILEなど)を参照できるため、名前の重複が発生する場合があります。

したがって、フィールドを参照する句を使用する場合、フルネームを使用する必要があります。たとえば、フィールドfld1がCOLUMN OBJECTであると指定され、フィールドfld2を含む場合、NULLIFなどの句でfld2を指定するときは、完全なフィールド名fld1.fld2を使用する必要があります。

次に、列オブジェクトのロードに関する例を示します。

- ストリーム・レコード形式への列オブジェクトのロード

- 可変レコード形式への列オブジェクトのロード

- ネストした列オブジェクトのロード

- 導出サブタイプを使用した列オブジェクトのロード

- オブジェクトに対するNULL値の指定

- ユーザー定義コンストラクタを使用した列オブジェクトのロード

ストリーム・レコード形式への列オブジェクトのロード

例11-1に、事前にサイズが決まっているフィールドにデータがある例を示します。終了文字は、物理レコードの終わりを示します。オペレーティング・システムのファイル処理句(os_file_proc_clause)のカスタム・レコード・セパレータを使用して、物理レコードの終わりを示すこともできます。

例11-1 ストリーム・レコード形式への列オブジェクトのロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE departments
(dept_no     POSITION(01:03)    CHAR,
dept_name   POSITION(05:15)    CHAR,
1   dept_mgr    COLUMN OBJECT
(name     POSITION(17:33)    CHAR,
age      POSITION(35:37)    INTEGER EXTERNAL,
emp_id   POSITION(40:46)    INTEGER EXTERNAL) )

データ・ファイル(sample.dat)

101 Mathematics  Johny Quest       30   1024
237 Physics      Albert Einstein   65   0000

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. この列オブジェクトの型指定は、ネストした列オブジェクトの記述にも繰り返し使用できます。

可変レコード形式への列オブジェクトのロード

例11-2に、デリミタ付きフィールドにデータがある例を示します。

例11-2 可変レコード形式への列オブジェクトのロード

制御ファイルの内容

LOAD DATA
1 INFILE 'sample.dat' "var 6"
INTO TABLE departments
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
2  (dept_no
dept_name,
dept_mgr       COLUMN OBJECT
(name       CHAR(30),
age         INTEGER EXTERNAL(5),
emp_id      INTEGER EXTERNAL(5)) )

データ・ファイル(sample.dat)

3  000034101,Mathematics,Johny Q.,30,1024,
000039237,Physics,"Albert Einstein",65,0000,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. "var"文字列には、各レコードの先頭にある長さフィールドのバイト数(この例では6)が含まれます。値が指定されない場合、デフォルトは5バイトです。可変レコードの最大サイズは、2^32-1です。それ以上の値を指定するとエラーになります。

2. 位置を指定しなくても、一般構文では同じ結果(列オブジェクトの名前の後に、カッコで囲まれた属性のリストが続く)になります。また、省略された型指定については、デフォルトで長さが255のCHAR型になります。

3. 最初の6バイト(斜体で示した部分)に、次のレコードの長さを指定します。これらの長さ指定には、emp_idフィールドの後の終了記号のために無視される改行文字も含まれます。

ネストした列オブジェクトのロード

例11-3に、ネストした列オブジェクト(他の列オブジェクト内にネストした1つの列オブジェクト)の制御ファイルの記述方法を示します。

例11-3 ネストした列オブジェクトのロード

制御ファイルの内容

LOAD DATA
INFILE `sample.dat'
INTO TABLE departments_v2
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(dept_no      CHAR(5),
dept_name     CHAR(30),
dept_mgr      COLUMN OBJECT
(name      CHAR(30),
age        INTEGER EXTERNAL(3),
emp_id     INTEGER EXTERNAL(7),
1     em_contact COLUMN OBJECT
(name      CHAR(30),
phone_num  CHAR(20))))

データ・ファイル(sample.dat)

101,Mathematics,Johny Q.,30,1024,"Barbie",650-251-0010,
237,Physics,"Albert Einstein",65,0000,Wife Einstein,654-3210,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. このエントリでは、列オブジェクトにネストした列オブジェクトを指定します。

導出サブタイプを使用した列オブジェクトのロード

例11-4に、NOT FINALのベース・オブジェクト型を拡張して新しく導出されたサブタイプを作成する例を示します。表定義の列オブジェクトは、ベース・オブジェクト型であると宣言されますが、サブタイプがベース・オブジェクト型から導出される場合は、SQL*Loaderによってサブタイプを列オブジェクトにロードできます。

例11-4 サブタイプを使用した列オブジェクトのロード

オブジェクトの型定義

CREATE TYPE person_type AS OBJECT
(name     VARCHAR(30),
ssn      NUMBER(9)) not final;

CREATE TYPE employee_type UNDER person_type
(empid    NUMBER(5));

CREATE TABLE personnel
(deptno   NUMBER(3),
deptname VARCHAR(30),
person   person_type);

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE personnel
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(deptno        INTEGER EXTERNAL(3),
deptname      CHAR,
1   person        COLUMN OBJECT TREAT AS employee_type
(name       CHAR,
ssn        INTEGER EXTERNAL(9),
2      empid      INTEGER EXTERNAL(5)))

データ・ファイル(sample.dat)

101,Mathematics,Johny Q.,301189453,10249,
237,Physics,"Albert Einstein",128606590,10030,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. TREAT AS句で指定すると、SQL*Loaderでは、実際の宣言型がperson_typeである列オブジェクトpersonが、導出型employee_typeであると宣言されたかのように処理されます。

2. empid属性はemployee_typeの属性であるため、ここで使用できます。TREAT AS句が指定されていない場合、この属性は列の宣言型の属性ではないため、エラーが発生します。

オブジェクトに対するNULL値の指定

非スカラー・データ型に対するNULL値の指定は、スカラー・データ型に対する指定より多少複雑になります。オブジェクトは、その属性のサブセットをNULLにするか、すべての属性をNULL(NULLオブジェクトにかぎります)にするか、またはオブジェクト自身をNULL(アトミックNULLオブジェクト)にできます。

NULL属性の指定

列オブジェクトに対応するフィールドでは、NULLIF句を使用して、特殊属性をNULLに初期化するフィールド条件を指定できます。例11-5に、これを示します。

例11-5 NULLIF句を使用したNULL属性の指定

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE departments
(dept_no      POSITION(01:03)    CHAR,
dept_name     POSITION(05:15)    CHAR NULLIF dept_name=BLANKS,
dept_mgr      COLUMN OBJECT
1    ( name     POSITION(17:33)    CHAR NULLIF dept_mgr.name=BLANKS,
1    age        POSITION(35:37)    INTEGER EXTERNAL NULLIF dept_mgr.age=BLANKS,
1    emp_id     POSITION(40:46)    INTEGER EXTERNAL NULLIF dept_mgr.empid=BLANKS))

データ・ファイル(sample.dat)

2  101             Johny Quest            1024
237   Physics   Albert Einstein   65   0000

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. 各属性に対応するNULLIF句は、属性値をNULLにする条件を示します

2. dept_mgrのage属性の値はNULLです。dept_nameの値もNULLです。

アトミックNULLの指定

列オブジェクトがNULL値(アトミックNULL)を取る条件を制御ファイルで指定するには、NULLIF句で使用するオブジェクトの名前は、マップ・フィールドの論理的な組合せに基づいている必要があります(たとえば、例11-5では、指定されたマップ・フィールドは、dept_no、dept_name、name、ageおよびemp_idです。dept_mgrは、データ・ファイルのどのフィールドにも対応していない(マップされていない)ため、指定されたマップ・フィールドではありません)。

前述の方法は使用可能ですが、オブジェクトがNULL値を取るための条件がマップ・フィールドに依存していない場合は、理想的な方法ではありません。このような場合は、FILLERフィールドを使用できます。

FILLERフィールドをデータ・ファイルのフィールドにマップし(列オブジェクトがアトミックNULLかどうかを示す)、そのFILLERフィールドを列オブジェクトのNULLIF句のフィールド条件で使用できます。この例を例11-6に示します。

例11-6 FILLERフィールドを使用したデータのロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE departments_v2
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(dept_no         CHAR(5),
dept_name        CHAR(30),
1  is_null          FILLER CHAR,
2  dept_mgr         COLUMN OBJECT NULLIF is_null=BLANKS
(name         CHAR(30) NULLIF dept_mgr.name=BLANKS,
age           INTEGER EXTERNAL(3) NULLIF dept_mgr.age=BLANKS,
emp_id        INTEGER EXTERNAL(7)
NULLIF dept_mgr.emp_id=BLANKS,
em_contact    COLUMN OBJECT NULLIF is_null2=BLANKS
(name      CHAR(30)
NULLIF dept_mgr.em_contact.name=BLANKS,
phone_num  CHAR(20)
NULLIF dept_mgr.em_contact.phone_num=BLANKS)),
1  is_null2         FILLER CHAR)

データ・ファイル(sample.dat)

101,Mathematics,n,Johny Q.,,1024,"Barbie",608-251-0010,,
237,Physics,,"Albert Einstein",65,0000,,650-654-3210,n,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. FILLERフィールド(データ・ファイルがマップされており、対応する列がない)はCHAR型(デリミタ付きフィールドであるため、CHARのデフォルトはCHAR(255))のフィールドです。NULLIF句は、FILLERフィールド自体には使用できません

2. is_nullフィールドが空白の場合は、NULL(アトミックNULL)の値を取得します。

ユーザー定義コンストラクタを使用した列オブジェクトのロード

Oracle Databaseでは、すべてのオブジェクト型に対してデフォルトのコンストラクタが自動的に提供されます。このコンストラクタを使用するには、コンストラクタに対するコールで、その型のすべての属性を引数として指定する必要があります。オブジェクトの新しいインスタンスが作成されると、その属性は引数リスト内の対応する値を取ります。このコンストラクタは、属性値コンストラクタと呼ばれます。SQL*Loaderでは、列オブジェクトのロード時に、デフォルトで属性値コンストラクタが使用されます。

1つ以上のユーザー定義コンストラクタを作成することによって、属性値コンストラクタを上書きできます。ユーザー定義コンストラクタを作成する場合、オブジェクトの新しいインスタンスが作成されると、常に、ユーザー定義論理を実行する型本体を指定する必要があります。ユーザー定義コンストラクタの引数リストは、属性値コンストラクタと同じ場合もありますが、型本体で実装される論理は異なります。

ユーザー定義コンストラクタのファンクションの引数リストが属性値コンストラクタの引数リストと一致する場合、従来型パスとダイレクト・パスではSQL*Loaderの動作が異なります。従来型パス・モードでは、ユーザー定義コンストラクタがコールされます。ダイレクト・パス・モードでは、属性値コンストラクタがコールされます。例11-7に、この違いを示します。

例11-7 一致するコンストラクタを使用した列オブジェクトのロード

オブジェクトの型定義

CREATE TYPE person_type AS OBJECT
(name     VARCHAR(30),
ssn      NUMBER(9)) not final;

CREATE TYPE employee_type UNDER person_type
(empid    NUMBER(5),
-- User-defined constructor that looks like an attribute-value constructor
CONSTRUCTOR FUNCTION
employee_type (name VARCHAR2, ssn NUMBER, empid NUMBER)
RETURN SELF AS RESULT);

CREATE TYPE BODY employee_type AS
CONSTRUCTOR FUNCTION
employee_type (name VARCHAR2, ssn NUMBER, empid NUMBER)
RETURN SELF AS RESULT AS
--User-defined constructor makes sure that the name attribute is uppercase.
BEGIN
SELF.name  := UPPER(name);
SELF.ssn   := ssn;
SELF.empid := empid;
RETURN;
END;

CREATE TABLE personnel
(deptno   NUMBER(3),
deptname VARCHAR(30),
employee employee_type);

制御ファイルの内容

LOAD DATA
INFILE *
REPLACE
INTO TABLE personnel
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(deptno        INTEGER EXTERNAL(3),
deptname      CHAR,
employee      COLUMN OBJECT
(name       CHAR,
ssn        INTEGER EXTERNAL(9),
empid      INTEGER EXTERNAL(5)))

BEGINDATA
1  101,Mathematics,Johny Q.,301189453,10249,
237,Physics,"Albert Einstein",128606590,10030,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. この制御ファイルが従来型パス・モードで実行された場合、名前フィールドのJohny Q.およびAlbert Einsteinは、両方とも大文字でロードされます。これは、従来型パス・モードではユーザー定義コンストラクタがコールされるためです。これに対し、この制御ファイルがダイレクト・パス・モードで実行された場合、名前フィールドは入力データに表示されているとおりにロードされます。これは、ダイレクト・パス・モードでは属性値コンストラクタがコールされるためです。

引数リストが属性値コンストラクタと一致しないユーザー定義コンストラクタの作成もできます。この場合は、従来型パス・モードおよびダイレクト・パス・モードの両方で、属性値コンストラクタがコールされます。例11-8に示す定義について考えてみます。

例11-8 一致しないコンストラクタを使用した列オブジェクトのロード

オブジェクトの型定義

CREATE SEQUENCE employee_ids
START     WITH  1000
INCREMENT BY    1;

CREATE TYPE person_type AS OBJECT
(name     VARCHAR(30),
ssn      NUMBER(9)) not final;

CREATE TYPE employee_type UNDER person_type
(empid    NUMBER(5),
-- User-defined constructor that does not look like an attribute-value
-- constructor
CONSTRUCTOR FUNCTION
employee_type (name VARCHAR2, ssn NUMBER)
RETURN SELF AS RESULT);

CREATE TYPE BODY employee_type AS
CONSTRUCTOR FUNCTION
employee_type (name VARCHAR2, ssn NUMBER)
RETURN SELF AS RESULT AS
-- This user-defined constructor makes sure that the name attribute is in
-- lowercase and assigns the employee identifier based on a sequence.
nextid     NUMBER;
stmt       VARCHAR2(64);
BEGIN

stmt := 'SELECT employee_ids.nextval FROM DUAL';
EXECUTE IMMEDIATE stmt INTO nextid;

SELF.name  := LOWER(name);
SELF.ssn   := ssn;
SELF.empid := nextid;
RETURN;
END;

CREATE TABLE personnel
(deptno   NUMBER(3),
deptname VARCHAR(30),
employee employee_type);

例11-7で説明した制御ファイルがこれらの定義に従って使用された場合、名前フィールドは、入力データに表示されているとおりに(大文字と小文字の組合せで)ロードされます。これは、従来型パス・モードおよびダイレクト・パス・モードの両方で属性値コンストラクタがコールされるためです。

SQL式でユーザー定義コンストラクタを明示的に参照することによって、従来型パス・モードを使用してこの表をロードすることもできます。例11-9に、この方法を示します。

例11-9 コンストラクタが一致しない場合のSQLを使用した列オブジェクトのロード

制御ファイルの内容

LOAD DATA
INFILE *
REPLACE
INTO TABLE personnel
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(deptno        INTEGER EXTERNAL(3),
deptname      CHAR,
name          BOUNDFILLER CHAR,
ssn           BOUNDFILLER INTEGER EXTERNAL(9),
1      employee      EXPRESSION "employee_type(:NAME, :SSN)")

BEGINDATA
1  101,Mathematics,Johny Q.,301189453,
237,Physics,"Albert Einstein",128606590,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. この制御ファイルが従来型パス・モードで実行された場合、名前フィールドのJohny Q.およびAlbert Einsteinは、両方とも大文字でロードされます。これは、従来型パス・モードではユーザー定義コンストラクタがコールされるためです。これに対し、この制御ファイルがダイレクト・パス・モードで実行された場合、名前フィールドは入力データに表示されているとおりにロードされます。これは、ダイレクト・パス・モードでは属性値コンストラクタがコールされるためです。

例11-9に示した制御ファイルがダイレクト・パス・モードで使用された場合は、次のエラーが通知されます。

SQL*Loader-951: Error calling once/load initialization
ORA-26052: Unsupported type 121 for SQL expression on column EMPLOYEE.

オブジェクト表のロード

オブジェクト表のロードに必要な制御ファイルの構文は、典型的なリレーショナル表のロードの場合とほぼ同じです。例11-10に、主キーベースのオブジェクト識別子(OID)を使用したオブジェクト表のロード例を示します。

例11-10 主キーOIDを使用したオブジェクト表のロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
DISCARDFILE 'sample.dsc'
BADFILE 'sample.bad'
REPLACE
INTO TABLE employees
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(name    CHAR(30)                NULLIF name=BLANKS,
age      INTEGER EXTERNAL(3)     NULLIF age=BLANKS,
emp_id   INTEGER EXTERNAL(5))

データ・ファイル(sample.dat)

Johny Quest, 18, 007,
Speed Racer, 16, 000,

前述の制御ファイルを見ただけでは、ロードされる表がシステム生成OIDを持つオブジェクト表か、主キーOIDを持つオブジェクト表か、またはリレーショナル表かを判断できません。

すでにシステム生成OIDを含むデータをロードし、新しいOIDを生成するのではなく、データ・ファイル内の既存のOIDを使用するように指定する必要がある場合もあります。そのような場合は、INTO TABLE句に続けてOID句を使用します。

OID (fieldname)

この場合、fieldnameには、システム生成OIDを含むデータ・フィールドにマップされた、フィールド指定リストのフィールド名(通常はFILLERフィールド)を指定します。SQL*Loaderでは、その指定されたOIDが、正しい形式で、グローバルな独自性を保持したOIDであるとみなされます。そのため、OracleのOIDジェネレータを使用してOIDを生成し、ロードされたOIDの一意性を確保する必要があります。

また、そのOID句は、主キーOIDではなく、システム生成のOIDでのみ使用できます。

例11-11に、行オブジェクトを使用したシステム生成OIDのロード例を示します。

例11-11 OIDのロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE employees_v2
1  OID (s_oid)
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(name    CHAR(30)                NULLIF name=BLANKS,
age      INTEGER EXTERNAL(3)    NULLIF age=BLANKS,
emp_id   INTEGER EXTERNAL(5),
2     s_oid    FILLER CHAR(32))

データ・ファイル(sample.dat)

3  Johny Quest, 18, 007, 21E978406D3E41FCE03400400B403BC3,
Speed Racer, 16, 000, 21E978406D4441FCE03400400B403BC3,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. OID句には、s_oidのロード・フィールドがOIDを含むように指定します。カッコが必要です

2. s_oidに有効な16進数が含まれていない場合、そのレコードは拒否されます。

3. データ・ファイルのOIDは文字列で、32バイトの16進数として解釈されます。32バイトの16進数は、後で16バイトのRAWに変換されてオブジェクト表に格納されます。

サブタイプを使用したオブジェクト表のロード

オブジェクト表の列オブジェクトがNOT FINALに基づいている場合、SQL*Loaderによって導出サブタイプをオブジェクト表にロードできます。前述のとおり、オブジェクト表に導出サブタイプをロードする場合に必要な構文は、典型的なリレーショナル表のロードの場合とほぼ同じです。ただし、この場合、実際に使用するサブタイプがオブジェクト表で有効であるかどうかをSQL*Loaderで判断できるように、サブタイプに名前を指定する必要があります。この概念を例11-12に示します。

例11-12 サブタイプを使用したオブジェクト表のロード

オブジェクトの型定義

CREATE TYPE employees_type AS OBJECT
(name     VARCHAR2(30),
age      NUMBER(3),
emp_id   NUMBER(5)) not final;

CREATE TYPE hourly_emps_type UNDER employees_type
(hours    NUMBER(3));

CREATE TABLE employees_v3 of employees_type;

制御ファイルの内容

LOAD DATA

INFILE 'sample.dat'
INTO TABLE employees_v3
1  TREAT AS hourly_emps_type
FIELDS TERMINATED BY ','
(name     CHAR(30),
age      INTEGER EXTERNAL(3),
emp_id   INTEGER EXTERNAL(5),
2     hours    INTEGER EXTERNAL(2))

データ・ファイル(sample.dat)

Johny Quest, 18, 007, 32,
Speed Racer, 16, 000, 20,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. TREAT AS句で指定すると、SQL*Loaderでは、実際の宣言型がemployee_typeであるオブジェクト表が、hourly_emps_type型であると宣言されたかのように処理されます

2. hours属性はhourly_emps_typeの属性であるため、ここで使用できます。TREAT AS句が指定されていない場合、この属性はオブジェクト表の宣言型の属性ではないため、エラーが発生します。

REF列のロード

SQL*Loaderは、システム生成OIDのREF列、主キーベースのREF列および主キーを使用可能な有効範囲なしREF列をロードできます。これらの各列については、次の項で説明するとおり、表名を指定する方法が重要です。

REF句における表名の指定

注意:

この項で説明する内容は、SQL*LoaderおよびOracle Databaseのリリースがいずれも11gリリース1(11.1)以上の環境にのみ適用されます。SQL*Loader、Oracle Databaseまたはその両方が以前のリリースの環境には適用されません。

SQL*Loader制御ファイルでは、REF列に対応するフィールドの記述は、列名の後にREF句を記述することによって行います。REF句には、引数として表名とロードされるREF列の型に適用可能な属性を取ります。表名は、(FILLERフィールドを使用して)動的に、または定数として指定できます。また、表名は、スキーマ名の有無にかかわらず指定できます。

REF句で指定する表名が、定数として、またはFILLERフィールドを使用して指定されるかどうかにかかわらず、大/小文字を区別して認識されます。このため、次のような状況が発生します。

- ユーザーSCOTTが、小文字で表名を引用符で囲まずにtable2という名前の表を作成する場合、その表は次のいずれの方法でもREF句で使用できます。

- REF(constant 'TABLE2', ...)

- REF(constant '"TABLE2"', ...)

- REF(constant 'SCOTT.TABLE2', ...)

- ユーザーSCOTTが、大文字と小文字を組み合せた名前を引用符で囲んで"Table2"という名前の表を作成する場合、その表は次のいずれの方法でもREF句で使用できます。

- REF(constant 'Table2', ...)

- REF(constant '"Table2"', ...)

- REF(constant 'SCOTT.Table2', ...)

いずれの状況においても、constantがFILLERフィールドに置換された場合、同じ値がデータ・セクションに書き込まれると、例に示したとおり値が処理されます。

システム生成OID型のREF列

システム生成REF列をロードする場合、SQL*Loaderでは、REF列を構築する実OIDが残りのデータとともにデータ・ファイル内にあるとみなされます。REF列に対応するフィールドの記述は、列名の後にREF句を記述することによって行います。

REF句には、引数として表名とOIDを取ります。その引数は、定数として、または(FILLERフィールドを使用して)動的に指定できます。適切な構文については、「ref_spec」を参照してください。例11-13に、システム生成OID型のREF列のロード例を示します。

例11-13 システム生成REF列のロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE departments_alt_v2
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(dept_no      CHAR(5),
dept_name    CHAR(30),
1 dept_mgr     REF(t_name, s_oid),
s_oid        FILLER CHAR(32),
t_name       FILLER CHAR(30))

データ・ファイル(sample.dat)

22345, QuestWorld, 21E978406D3E41FCE03400400B403BC3, EMPLOYEES_V2,
23423, Geography, 21E978406D4441FCE03400400B403BC3, EMPLOYEES_V2,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. 指定した表が存在しない場合、レコードは拒否されます。また、dept_mgrフィールド自体には、データ・ファイルのフィールドはマップされません。

主キーREF列

主キーREF列をロードするには、SQL*Loader制御ファイルのフィールドで列名の後にREF句を記述する必要があります。REF句には、カンマで区切ったフィールド名および定数値のリストが引数として必要です。最初の引数は表名で、その後にロードするREF列の基になる主キーOIDを指定する引数を記述します。適切な構文については、「ref_spec」を参照してください。

SQL*Loaderでは、引数の順序は、参照されている表で主キーOIDを作成する列の相対順序に一致しているとみなされます。例11-14に、主キーREF列のロード例を示します。

例11-14 主キーREF列のロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE departments_alt
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(dept_no       CHAR(5),
dept_name      CHAR(30),
dept_mgr       REF(CONSTANT 'EMPLOYEES', emp_id),
emp_id         FILLER CHAR(32))

データ・ファイル(sample.dat)

22345, QuestWorld, 007,
23423, Geography, 000,

主キーが使用可能な有効範囲なしREF列

主キーが使用可能な有効範囲なしREF列によって、システム生成および主キーの両方の型のREFを参照できます。このようなREF列をロードするための構文は、システム生成OID型のREF列または主キーREF列にロードする場合と同じです。例11-13および例11-14を参照してください。

主キーが使用可能な有効範囲なしREF列をロードする場合は、次の制限が適用されます。

- 単一表へのロード中は、この列からシステム生成または主キーのいずれかの型のREFのみを参照できます。両方は参照できません。両方の型の参照を試行すると、データ行が拒否され、参照表名が無効であることを示すエラー・メッセージが表示されます。

- この列に有効範囲なし主キーREFをロードする場合、単一表へのロード中は、1つのオブジェクト表のみ参照できます。複数の有効範囲なし主キーREF(いくつかのREFはオブジェクト表Xを指し、別のREFはオブジェクト表Yを指す)をロードする場合、次のいずれかの操作を実行する必要があります。

- 単一表へのロードを2回実行します。

- 有効範囲なし主キーREFのオブジェクト表名など、WHEN句によってデータのいくつかの要素が指定されている複数のINTO TABLE句を使用して、ロードを1回実行します。次に例を示します。

LOAD DATA
INFILE 'data.dat'

INTO TABLE orders_apk
APPEND
when CUST_TBL = "CUSTOMERS_PK"
fields terminated by ","
(
order_no   position(1)  char,
cust_tbl FILLER     char,
cust_no  FILLER     char,
cust   REF (cust_tbl, cust_no) NULLIF order_no='0'
)

INTO TABLE orders_apk
APPEND
when CUST_TBL = "CUSTOMERS_PK2"
fields terminated by ","
(
order_no  position(1)  char,
cust_tbl FILLER     char,
cust_no  FILLER     char,
cust   REF (cust_tbl, cust_no) NULLIF order_no='0'
)

これらの方法のいずれも使用しない場合、データ行が拒否され、参照されている表の名前が無効であることを示すエラー・メッセージが表示されます。

- コレクション内の有効範囲なし主キーREFは、SQL*Loaderではサポートされていません。

- このREF列にシステム生成のREFをロードする場合は、「システム生成OID型のREF列」で説明されている制限も適用されます。

- このREF列に主キーREFをロードする場合は、「主キーREF列」で説明されている制限も適用されます。

注意:

主キーが使用可能な有効範囲なしREF列の場合、SQL*Loaderでは、(REFディレクティブまたはデータ行のいずれかから)最初の有効な解析済オブジェクト表が取得され、オブジェクト表のOID型を使用してその単一表へのロードで参照可能なREF型が決定されます。

LOBのロード

LOBは、ラージ・オブジェクト型です。SQL*Loaderでは、次のLOB型がサポートされています。

- BLOB: 非構造化バイナリ・データを含む内部LOB。

- CLOB: 文字データを含む内部LOB。

- NCLOB: 各国語キャラクタ・セットの文字を含む内部LOB。

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

LOBは、列のデータ型にすることができ、NCLOB以外はオブジェクトの属性のデータ型にすることもできます。LOBは実際の値を持ち、その値はNULLでも「値なし(空)」でもかまいません。LOBに格納される長さ0のフィールドがある場合は、SQL*Loaderによって空のLOBが作成されます。(他のデータ型の場合は、このデータ型とは異なり、長さ0の文字列に対して、列はSQL*LoaderによってNULLに設定されます。)つまり、NULL値をLOB列にロードする方法は、NULLIF句を使用する方法のみです。

XML列は、SYS.XMLTYPE型であると宣言された列です。SQL*Loaderは、XML列をCLOBと同様に処理します。次の項で説明するプライマリ・データ・ファイルまたはLOBFILEからのLOBデータのロード方法は、XML列のロードに適用できます。

注意:

LOBフィールドにはSQL文字列を指定できません。これは、LOBFILE_specを指定する場合も同じです。

LOBは非常に大きくなくことがあるため、次の項で説明するように、SQL*LoaderはLOBデータをプライマリ・データ・ファイルから(他のデータと一緒に)ロードするか、またはLOBFILEからロードすることができます。

- プライマリ・データ・ファイルからのLOBデータのロード

- LOBFILEからのLOBデータのロード

関連項目:

ラージ・オブジェクト(LOB)データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

プライマリ・データ・ファイルからのLOBデータのロード

プライマリ・データ・ファイルから内部LOB(BLOB、CLOBおよびNCLOB)またはXML列をロードするには、次の標準SQL*Loader形式を使用できます。

- 事前にサイズが決まっているフィールド

- デリミタ付きフィールド

- Length-Value Pairフィールド

これらの各形式については、次の項で説明します。

事前に決められたサイズのフィールドのLOBデータ

例11-15に示すように、これはLOBデータをロードする場合、最も高速で、概念的に単純な形式です。

注意:

ロードするLOBデータは、サイズが均等ではないため、サイズが小さいデータ・フィールドに空白を埋め込み、全LOBデータが同じサイズになるようにできます。

この形式でLOBをロードするには、ロード時のデータ型としてCHARまたはRAWを使用する必要があります。

例11-15 事前に決められたサイズのフィールドのLOBデータ

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat' "fix 501"
INTO TABLE person_table
(name       POSITION(01:21)       CHAR,
1  "RESUME"    POSITION(23:500)      CHAR   DEFAULTIF "RESUME"=BLANKS)

データ・ファイル(sample.dat)

Julia Nayer      Julia Nayer
500 Example Parkway
jnayer@us.example.com ...

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. DEFAULTIF句が使用されているため、RESUMEが含まれているデータ・フィールドが空の場合、NULLのLOBではなく、空のLOBになります。ただし、DEFAULTIFではなくNULLIF句が使用されている場合は、空のデータ・フィールドではなくNULLになります。
また、ロード時に、CHAR以外にもSQL*Loaderのデータ型を使用できます。たとえば、BLOBのロード時、RAWデータ型を使用する場合があります。

デリミタ付きフィールドのLOBデータ

この形式で、同じ列(データ・ファイルのフィールド)で異なるサイズのLOBを、問題なく処理できます。ただし、このような柔軟性によって、SQL*Loaderで区切り文字列を探してデータをスキャンする必要があるため、パフォーマンスに影響します。

単一キャラクタのデリミタで、文字列のデリミタを指定する場合は、データ・ファイルのキャラクタ・セットに注意してください。データ・ファイルのキャラクタ・セットが制御ファイルのキャラクタ・セットと異なる場合は、デリミタを16進数の表記法で指定できます(X'hexadecimal string')。デリミタを実際に16進数の表記法で指定する場合は、入力データ・ファイルのキャラクタ・セット中の有効な文字で指定する必要があります。一方、16進数の表記法で指定しない場合、デリミタは、クライアント(制御ファイル)のキャラクタ・セットで指定してください。この場合、デリミタは、SQL*Loaderによってデータ・ファイル内で検索される前に、データ・ファイルのキャラクタ・セットに変換されます。

次の点に注意してください。

- 文字列デリミタを使用した区切り構文がサポートされます(囲みデリミタを区切りとします)。

- マルチ・キャラクタの囲みデリミタの前に空白は入れられません。

- フィールドがWHITESPACEで終わる場合、先頭の空白は切り捨てられます。

注意:

SQL*LoaderによるCLOBデータ移動時のフィールドのデフォルト最大長は255バイトですが、最大2GBまでの値を指定できます。デリミタ付きフィールドでは、長さが指定されている場合、その長さが最大長として使用されます。値が指定されない場合、デフォルトは255バイトです。デリミタ付きで255バイトを超えるCHARフィールドの場合、最大長を指定する必要があります。CHARデータ型の詳細は、「CHAR」を参照してください。

例11-16にデリミタ付きフィールドへのLOBデータのロードの例を示します。

例11-16 デリミタ付きフィールドのLOBデータのロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat' "str '|'"
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name        CHAR(25),
1  "RESUME"     CHAR(507) ENCLOSED BY '<startlob>' AND '<endlob>')

データ・ファイル(sample.dat)

Julia Nayer,<startlob>        Julia Nayer
500 Example Parkway
jnayer@us.example.com ...   <endlob>
2  |Bruce Ernst, .......

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. <startlob>および<endlob>は、囲み文字列です。デフォルトのバイト長セマンティクスでは、CHAR(507)を使用して読み込むことができるLOBの最大長は507バイトです。文字長セマンティクスが使用された場合、最大長は507文字になります。詳細は、「文字長セマンティクス」を参照してください

2. レコード・セパレータ'|'は、<endlob>のすぐ後にあり、その後に改行文字が続く場合、改行は、次のレコードの一部として解釈されます。代替方法は、レコード・セパレータに改行部分を作成することです(たとえば'|\n'、または16進ではX'7C0A')。

Length-Value PairフィールドのLOBデータ

VARCHAR、VARCHARCまたはVARRAWデータ型を使用して、Length-Value Pairフィールドで編成されたLOBデータをロードできます。このロード方法を使用すると、デリミタ付きフィールドを使用するよりも高いパフォーマンスを得ることができます。ただし、柔軟性は損なわれる場合があります(たとえば、各LOBのロード前に、LOBの長さの確認が必要です)。例11-17に、Length-Value PairフィールドのLOBデータのロード例を示します。

例11-17 Length-Value PairフィールドへのLOBデータのロード

制御ファイルの内容

LOAD DATA
1 INFILE 'sample.dat' "str '<endrec>\n'"
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name       CHAR(25),
2    "RESUME"    VARCHARC(3,500))

データ・ファイル(sample.dat)

Julia Nayer,479                Julia Nayer
500 Example Parkway
jnayer@us.example.com
... <endrec>
3    Bruce Ernst,000<endrec>

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. バックスラッシュ・エスケープ文字がサポートされていない場合、例の中でレコード・セパレータとして使用されている文字列は、16進数の表記法で表現されます。

2. "RESUME"は、CLOB列に対応するフィールドです。制御ファイルでは、VARCHARCがそのフィールドで、フィールド長は3バイト、最大サイズは500バイト(バイト長セマンティクスで)です。文字長セマンティクスが使用された場合、長さは3文字で最大サイズは500文字です。詳細は、「文字長セマンティクス」を参照してください。

3. VARCHARCのlengthサブフィールドは、0(サブフィールドの値が空)です。このため、LOBインスタンスは、空に初期化されます。

LOBFILEからのLOBデータのロード

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

LOBFILEからロードしたLOBをメモリーに合わせる必要はありません。SQL*Loaderでは、64KB単位でLOBFILEが読み込まれます。

LOBFILEのデータ・フィールドは、次のいずれかの型です。

- ファイルの内容全体を読み込む単一のLOBフィールド

- サイズが決められたフィールド(固定長フィールド)

- デリミタ付きフィールド(TERMINATED BYまたはENCLOSED BY)
PRESERVE BLANKS句は、LOBFILEから読み込むフィールドには使用できません。

- Length-Value Pairフィールド(可変長フィールド)
この型のフィールドからデータをロードするには、VARRAW、VARCHARまたはVARCHARC SQL*Loaderデータ型を使用します。

これらの各フィールド型の使用例については、「LOBFILEからのLOBデータのロードの例」を参照してください。前述のすべてのフィールド型は、XML列のロードに使用できます。

LOBFILE構文については、「lobfile_spec」を参照してください。

動的および静的LOBFILE指定

LOBFILEを静的に指定(制御ファイルにファイル名を指定)するか、または動的に指定(FILLERフィールドをファイル名のソースとして使用)できます。いずれの場合も、LOBFILEがEOFで終了しない場合は、LOBFILEの終わりに到達するとファイルがクローズされ、そのファイルからさらにデータを読み込む場合は、空のフィールドからデータを読み込むことになります。

ただし、LOBFILEをEOFで終了する場合は、ファイルからデータを読み込むと、常に、ファイル全体が戻されます。

同じLOBFILEを、2つの異なるフィールドのソースとして指定しないでください。指定すると、通常、2つのフィールドは、データを別々に読み取ります。

LOBFILEからのLOBデータのロードの例

この項では、LOBFILEの異なるフィールド型からデータをロードする例を示します。

ファイル当たり1つのLOB

例11-18では、各LOBFILEは、それぞれ1つのLOBのソースです。この方法で編成されたLOBデータをロードするには、列名またはフィールド名の後にLOBFILEデータ型を指定します。

例11-18 LOBFILE当たり1つのLOBを使用したLOBデータのロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name      CHAR(20),
1  ext_fname    FILLER CHAR(40),
2  "RESUME"     LOBFILE(ext_fname) TERMINATED BY EOF)

データ・ファイル(sample.dat)

Johny Quest,jqresume.txt,
Speed Racer,'/private/sracer/srresume.txt',

セカンダリ・データ・ファイル(jqresume.txt)

Johny Quest
500 Oracle Parkway
...

セカンダリ・データ・ファイル(srresume.txt)

Speed Racer
400 Oracle Parkway
...

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. FILLERフィールドは、SQL*LoaderのCHARデータ型を使用して読み込まれる、40バイトのデータ・フィールドにマップされています。ここでは、デフォルトのバイト長セマンティクスの使用を想定しています。文字長セマンティクスが使用された場合、フィールドは40文字データ・フィールドにマップされます

2. SQL*Loaderでは、FILLERフィールドext_fnameのLOBFILE名が使用されます。(CHARデータ型を使用する) LOBFILEの最初のバイトからEOF文字までのデータがロードされます。既存のLOBFILEが指定されていない場合、RESUMEフィールドは空に初期化されます。

事前に決められたサイズのLOB

例11-19では、制御ファイルの特定の列にロードするLOBのサイズを指定します。ロード時、列にロードしたLOBデータは、指定したサイズとみなされます。事前に決められたサイズのフィールドでは、データ解析機能を最適に実行できます。ただし、すべてのLOBデータが必ずしも同じサイズであるとはかぎりません。

例11-19 事前に決められたサイズのLOBを使用したLOBデータのロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name     CHAR(20),
1  "RESUME"    LOBFILE(CONSTANT '/usr/private/jquest/jqresume.txt')
CHAR(2000))

データ・ファイル(sample.dat)

Johny Quest,
Speed Racer,

セカンダリ・データ・ファイル(jqresume.txt)

Johny Quest
500 Oracle Parkway
...
Speed Racer
400 Oracle Parkway
...

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. このエントリでは、現行のロード・セッション中、最後にロードされたバイト位置に続けてロードを開始し、CHARデータ型を使用して、jqresume.txt LOBFILEから2000バイトのデータをロードするように指定しています。ここでは、デフォルトのバイト長セマンティクスの使用を想定しています。文字長セマンティクスが使用された場合、SQL*Loaderでは、最後にロードされた文字の直後の文字から順番に、2000文字のデータがロードされます。詳細は、「文字長セマンティクス」を参照してください。

デリミタ付きフィールドのLOB

例11-20では、LOBFILEがデリミタ付きフィールドである場合の、LOBデータの例を示します。この形式では、サイズの異なるLOBを同じ列にロードしても、問題は発生しません。ただし、このような柔軟性によって、SQL*Loaderで区切り文字列を探してデータをスキャンする必要があるため、パフォーマンスに影響します。

例11-20 デリミタ付きLOBを使用したLOBデータのロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name     CHAR(20),
1  "RESUME"    LOBFILE( CONSTANT 'jqresume') CHAR(2000)
TERMINATED BY "<endlob>\n")

データ・ファイル(sample.dat)

Johny Quest,
Speed Racer,

セカンダリ・データ・ファイル(jqresume.txt)

Johny Quest
500 Oracle Parkway
... <endlob>
Speed Racer
400 Oracle Parkway
... <endlob>

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. CHARの最大長に2000が指定されているため、SQL*Loaderで、フィールドの最大長を推測でき、メモリーの使用量を最適化できます。最大長を指定する場合、小さすぎる値は指定しないように注意してください。TERMINATED BY句は、LOBを終了する文字列を指定します。かわりに、ENCLOSED BY句も使用できます。ENCLOSED BY句を使用すると、LOBFILE内でのLOBの相対的な位置指定に関して、多少柔軟に対応できます(LOBFILE内のLOBには順序が不要)。

Length-Value Pairで指定したLOB

例11-21では、LOBFILEの各LOBの先頭でデータ長が定義されています。VARCHAR、VARCHARCまたはVARRAWデータ型を使用して、この方法で編成されたLOBデータをロードできます。

このロード方法を使用すると、デリミタ付きフィールドを使用するより高いパフォーマンスを得ることができます。ただし、柔軟性は損なわれます(たとえば、各LOBのロード前に、LOBの長さの確認が必要です)。

例11-21 Length-Value Pairを指定したLOBを使用したLOBデータのロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE person_table
FIELDS TERMINATED BY ','
(name          CHAR(20),
1  "RESUME"       LOBFILE(CONSTANT 'jqresume') VARCHARC(4,2000))

データ・ファイル(sample.dat)

Johny Quest,
Speed Racer,

セカンダリ・データ・ファイル(jqresume.txt)

2      0501Johny Quest
500 Oracle Parkway
...
3      0000

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. VARCHARC(4,2000)のエントリによって、LOBFILEのLOBがLength-Value Pair形式であり、最初の4バイトが長さを示すことをSQL*Loaderに指定します。この2000という値は、フィールドの最大サイズが2000であることを示します。ここでは、デフォルトのバイト長セマンティクスの使用を想定しています。文字長セマンティクスが使用された場合、最初の4文字は文字単位の長さとして解釈されます。フィールドの最大サイズは2000文字です。詳細は、「文字長セマンティクス」を参照してください。

2. Johny Questの前の0501は、次の501文字がLOBのデータであることを示します。

3. このエントリは、LOBが空である(NULLではない)ことを示します。

LOBFILEからLOBをロードする場合の考慮点

LOBFILEからデータをロードする場合は、次のことに注意してください。

- LOBおよびXML列のみがLOBFILEからロードできます。

- 特定のLOBのロードが失敗した場合、そのLOBを含むレコードは拒否されません。かわりに、そのレコードのLOBは、空のLOBになります。XML列の場合、LOBのロード中に失敗するとNULL値が挿入されます。

- LOB列に対応するフィールドの最大長を指定する必要はありません。最大長を指定すると、SQL*Loaderでは最大長をメモリー使用量の最適化のヒントに使用します。そのため、最大長の指定では、実際の最大長よりも小さい値を指定しないでください。

- LOBFILEからデータをロード中、位置指定(pos_spec)はできません。

- NULLIFまたはDEFAULTIFのフィールド条件は、LOBFILEから読み込まれたフィールドに基づくことはできません。

- 存在しないLOBFILEをフィールドのデータ・ソースに指定すると、そのフィールドは初期化されて空になります。そのフィールドを空にできない場合は、NULLに初期化されます。

- 表レベル・デリミタは、LOBFILEから読み込まれるフィールドには指定できません。

- 従来型パス・モードでSQL式を使用してXML列をロードするか、LOB列を参照する場合は、SQL*LoaderでLOBデータを一時LOBとして処理する必要があります。このような場合のロード・パフォーマンスを最適化するには、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』の一時LOBのパフォーマンスに関するガイドラインを参照してください。

BFILE列のロード

BFILEデータ型には、データベースの外側にあるオペレーティング・システム・ファイルの非構造化バイナリ・データが格納されます。BFILE列または属性には、データを含む外部ファイルを示すロケータが格納されます。BFILEとしてロードされるファイルは、ロード時に存在している必要はなく、後で作成できます。SQL*Loaderでは、必要なオブジェクト(サーバーのファイル・システム上の物理ディレクトリに対する論理的な別名)がすでに作成されていると想定しています。詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

BFILE列に対応する制御ファイルのフィールドの記述は、列名の後にBFILE句を記述して行います。BFILE句には、引数としてディレクトリ・オブジェクト(server_directoryの別名)名の後にBFILE名が必要です。いずれの引数も文字列定数として指定するか、他のフィールドを介して動的にロードできます。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

次の2つのBFILEのロード例を示します。例11-22では、1つのファイル名のみを動的に指定する方法を、例11-23では、BFILEとディレクトリ・オブジェクトの両方を動的に指定する方法を示します。

例11-22 BFILEを使用したデータのロード: ファイル名のみを動的に指定

制御ファイルの内容

LOAD DATA
INFILE sample.dat
INTO TABLE planets
FIELDS TERMINATED BY ','
(pl_id    CHAR(3),
pl_name   CHAR(20),
fname     FILLER CHAR(30),
1  pl_pict   BFILE(CONSTANT "scott_dir1", fname))

データ・ファイル(sample.dat)

1,Mercury,mercury.jpeg,
2,Venus,venus.jpeg,
3,Earth,earth.jpeg,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. ディレクトリ名は引用符に囲まれており、そのまま使用されるため、文字列は大文字にせずそのまま指定します。

例11-23 BFILEを使用したデータのロード: ファイル名およびディレクトリを動的に指定

制御ファイルの内容

LOAD DATA
INFILE sample.dat
INTO TABLE planets
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(pl_id    NUMBER(4),
pl_name   CHAR(20),
fname     FILLER CHAR(30),
1  dname     FILLER CHAR(20),
pl_pict   BFILE(dname, fname) )

データ・ファイル(sample.dat)

1, Mercury, mercury.jpeg, scott_dir1,
2, Venus, venus.jpeg, scott_dir1,
3, Earth, earth.jpeg, scott_dir2,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. dnameは、ロードしたファイルに対応するディレクトリ名を含む、データ・ファイルのフィールドにマップされています。

コレクション(ネストした表およびVARRAY)のロード

LOBと同様、コレクションも、プライマリ・データ・ファイル(データ・インライン)またはSDF(データ・アウトライン)のいずれかからロードできます。SDFの詳細は、「セカンダリ・データ・ファイル(SDF)」を参照してください。

コレクション・データをロードする場合、コレクションに属するデータのインスタンスが終了したことをSQL*Loaderに伝える機能が必要です。これには、2つの方法があります。

- それぞれのネストした表またはVARRAYインスタンスにロードされる行または要素の数を指定するには、DDL構文のCOUNT関数を使用します。COUNTに指定する値は、数字または数字を含む文字列のいずれかで、制御ファイルでCOUNT句よりも先に記述する必要があります。この位置の依存性は、COUNT句に固有です。COUNT(0)またはCOUNT(cnt_field)を指定して、カレント行のcnt_fieldが0の場合は、NULLIF句によって上書きされないかぎり、空のコレクション(NULLではない)になります。詳細は、「count_spec」を参照してください。
制御ファイルでCOUNT句によってフィールドが指定され、そのフィールドがカレント行でNULLに設定されている場合、そのカウントを使用するコレクションは、カレント行でも空に設定されます。

- TERMINATED BYおよびENCLOSED BY句を使用して、一意のコレクション・デリミタを指定します。SDF句が使用されている場合、この方法は使用できません。

制御ファイルでは、コレクションは、列オブジェクトと同様に記述します。詳細は、「列オブジェクトのロード」を参照してください。一部、次のような相違点があります。

- コレクションの記述には、前述の2つの機能を使用します。

- コレクションの記述には、セカンダリ・データ・ファイル(SDF)を指定できます。

- 同じSDFのフィールド上にないかぎり、NULLIFまたはDEFAULTIF句ではSDFのフィールドを参照できません。

- フィールド名を引数として使用する句には、同じコレクションのフィールドに対するDDL指定でないかぎり、コレクション内のフィールド名を使用できません。

- フィールド・リストには、非FILLERフィールドが1つと、複数のFILLERフィールドが含まれている必要があります。VARRAYが列オブジェクトのVARRAYの場合、列オブジェクトの属性は、ネストしたフィールド・リストに記述されます。

ネストした表およびVARRAYでの制限事項

ネストした表およびVARRAYには次の制限事項があります。

- field_listには、collection_fld_specを含めることはできません。

- VARRAY内にネストしたcol_obj_specには、collection_fld_specを含めることはできません。

- field_listの一部として指定したcolumn_nameは、VARRAYパラメータを前に付けたcolumn_nameと同一である必要があります。

また、ネストした表を含む表にロードする場合、複数のロードへの細分化およびSIDの生成は自動的に行われないため注意してください。

例11-24に、VARRAYおよびネストした表のロード例を示します。

例11-24 VARRAYおよびネストした表のロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat' "str '\n' "
INTO TABLE dept
REPLACE
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(
dept_no       CHAR(3),
dname         CHAR(25) NULLIF dname=BLANKS,
1    emps          VARRAY TERMINATED BY ':'
(
emps        COLUMN OBJECT
(
name      CHAR(30),
age       INTEGER EXTERNAL(3),
2        emp_id    CHAR(7) NULLIF emps.emps.emp_id=BLANKS
)
),
3   proj_cnt      FILLER CHAR(3),
4   projects      NESTED TABLE SDF (CONSTANT "pr.txt" "fix 57") COUNT (proj_cnt)
(
projects    COLUMN OBJECT
(
project_id        POSITION (1:5) INTEGER EXTERNAL(5),
project_name      POSITION (7:30) CHAR
NULLIF projects.projects.project_name = BLANKS
)
)
)

データ・ファイル(sample.dat)

101,MATH,"Napier",28,2828,"Euclid", 123,9999:0
210,"Topological Transforms",:2

セカンダリ・データ・ファイル(SDF)(pr.txt)

21034 Topological Transforms
77777 Impossible Proof

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. TERMINATED BY句では、VARRAYのインスタンス終了記号(COUNT句は使用されていないことに注意)を指定します。

2. このFILLERフィールドの存在によって発生するフィールド名の競合は、フルネームによるフィールド参照(ドット表記法を使用)によって解決されます。

3. proj_cntは、COUNT句に対する引数として使用するFILLERフィールドです。

4. このエントリでは、次の内容が指定されます。

- pr.txtと呼ばれるSDFをデータのソースとして指定します。また、SDF内で固定レコード形式を指定します。

- COUNT句が0の場合、コレクションは空に初期化されます。コレクションを空に初期化するもう1つの方法は、DEFAULTIF句を使用する方法です。ネストした表のフィールドの記述に対応するメイン・フィールド名は、そのネストした非FILLERフィールドのフィールド名、特に、列オブジェクトのフィールド名の記述と同じです。

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

セカンダリ・データ・ファイル(SDF)とプライマリ・データ・ファイルの概念は類似しています。プライマリ・データ・ファイルと同様に、SDFはレコードの集まりで、各レコードはフィールドで構成されています。SDFは、制御ファイルのフィールドごとに指定されます。これは、大きいネストした表およびVARRAYをロードする場合に有効です。

注意:

SDFをデータ・ソースとして命名できるのは、collection_fld_specのみです。

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

プライマリ・データ・ファイルの場合、各SDFについて次を指定できます。

- レコード形式(固定、ストリームまたは可変)の指定。また、ストリーム・レコード形式が使用される場合、レコード・セパレータを指定できます。

- レコード・サイズの指定。

- CHARACTERSET句を使用した、SDFのキャラクタ・セットの指定(「異なる文字コード体系の処理」を参照)。

- 特にSDF指定(SDF指定を含むコレクションのすべてのメンバー・フィールドまたは属性で、LOBFILEフィールドを含むフィールドを除く)のあるフィールドに対するデフォルトのデリミタの指定(デリミタ指定を使用)

SDFについては、次のことにも注意してください。

- 存在しないSDFをフィールドのデータ・ソースに指定すると、そのフィールドは初期化されて空になります。そのフィールドを空にできない場合は、NULLに初期化されます。

- 表レベル・デリミタは、SDFから読み込まれるフィールドには指定できません。

- 64KBを超えるSDFをロードするには、READSIZEパラメータを使用してより大きな物理レコード・サイズを指定できます。コマンドラインからでも、OPTIONS句の一部としてでもREADSIZEパラメータを指定できます。

関連項目:

- 「READSIZE」

- 「OPTIONS句」

- 「sdf_spec」

動的および静的SDF指定

SDFを静的に指定(実際のファイル名を指定)するか、または動的に指定(FILLERフィールドをファイル名のソースとして使用)できます。いずれの場合も、SDFのEOFに到達するとファイルはクローズされ、そのファイルからさらにデータを読み込む場合は、空のフィールドからデータを読み込むことになります。

動的セカンダリ・ファイル指定では、動作は多少異なります。参照ファイルの指定が変更されると、常に、古いファイルはクローズされ、データは新しい参照先ファイルの最初から読み込まれます。

このようなデータ・ソース・ファイルの動的な切替えは、リセットの効果があります。たとえば、SQL*Loaderを使用して、現行のファイルから前回オープンしていたファイルに切り替える場合、前回オープンしていたファイルを再オープンし、そのファイルの最初からデータが読み込まれます。

同じSDFを、2つの異なるフィールドのソースとして指定しないでください。指定すると、通常、2つのフィールドは、データを別々に読み取ります。

親表を子表から分割してのロード

ネストした表の列を含む表をロードする場合、親表を子表から分割してロードする場合があります。SID(システム生成またはユーザー定義)がロード時にわかっている場合(SIDがデータとともにデータ・ファイルにある場合)、親表と子表を別々にロードできます。

次の例は、ユーザー定義SIDを持つ親および子表をロードする方法を示しています。

例11-25 ユーザー定義SIDを使用した親表のロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat' "str '|\n' "
INTO TABLE dept
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
( dept_no   CHAR(3),
dname       CHAR(20) NULLIF dname=BLANKS ,
mysid       FILLER CHAR(32),
1  projects    SID(mysid))

データ・ファイル(sample.dat)

101,Math,21E978407D4441FCE03400400B403BC3,|
210,"Topology",21E978408D4441FCE03400400B403BC3,|

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. mysidは、実際のSIDを含むデータ・ファイルのフィールドにマップされているFILLERフィールドで、SID句に対する引数として指定できます。

例11-26 ユーザー定義SIDを使用した子表のロード

制御ファイルの内容

LOAD DATA
INFILE 'sample.dat'
INTO TABLE dept
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
1  SID(sidsrc)
(project_id     INTEGER EXTERNAL(5),
project_name   CHAR(20) NULLIF project_name=BLANKS,
sidsrc FILLER  CHAR(32))

データ・ファイル(sample.dat)

21034, "Topological Transforms", 21E978407D4441FCE03400400B403BC3,
77777, "Impossible Proof", 21E978408D4441FCE03400400B403BC3,

注意:

例の左に付けた太字の数字は、次の注意事項と対応しています。

1. 表レベルのSID句を指定すると、SQL*Loaderによって、ネストした表の記憶表がロードされます。sidsrcは、実際のSIDのソースである、FILLERフィールド名です。

VARRAY列ロード時のメモリーの問題

次に、VARRAY列をロードする場合の注意事項を示します。

- VARRAYは、データベースにロードされる前にクライアント・メモリーに作成されます。VARRAYの各要素には、データベースにロードする前に、4バイトのクライアント・メモリーが必要です。そのため、1000個の要素を持つVARRAYをロードする場合は、VARRAYをデータベースにロードする前に、それぞれのVARRAYインスタンスに、4000バイト以上のクライアント・メモリーが必要です。多くの場合、SQL*Loaderでは、VARRAYの構築やロードに、2倍から3倍のメモリー量を必要とします。

- BINDSIZEパラメータを使用して、SQL*Loaderでレコードのロードに割り当てるメモリーの量を指定します。BINDSIZEに指定された値に応じて、SQL*Loaderで、ロード中の各フィールドのサイズを考慮し、1回のトランザクションでロードできる行数を判断します。行数が多ければトランザクションは少なくなり、パフォーマンスは向上します。ただし、システムのメモリー量に制限がある場合、パフォーマンスを優先せず、SQL*Loaderで算出した値より低い値をROWSに指定できます。

- 非常に大きいVARRAYまたは多数の小さいVARRAYが原因で、ロード中にメモリーが不足する場合があります。この場合は、BINDSIZEまたはROWSにより小さい値を指定し、再ロードします。

12 従来型パス・ロードおよびダイレクト・パス・ロード

SQL*Loaderでは、従来型パス・ロード方式およびダイレクト・パス・ロード方式が提供されます。それぞれの方法の詳細は、次の項目を参照してください。

- データのロード方法

- 従来型パス・ロード

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

- ダイレクト・パス・ロードの使用

- ダイレクト・パス・ロードのパフォーマンスの最適化

- 複数CPUシステムのダイレクト・パス・ロードの最適化

- 索引メンテナンスの回避

- ダイレクト・パス・ロード、整合性制約およびトリガー

- パラレル・データ・ロード・モデル

- 一般的なパフォーマンス改善のヒント

ダイレクト・パス・ロードを使用した例は、「事例6: ダイレクト・パス・ロード方式を使用したデータのロード」を参照してください。その他の事例では、従来型パス・ロードを使用しています。(事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

データのロード方法

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

- 従来型パス・ロード

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

従来型パス・ロードでは、Oracle Databaseの表に対して(1つ以上の)SQL INSERT文が実行されます。ダイレクト・パス・ロードでは、Oracleデータ・ブロックをフォーマットし、データ・ブロックを直接データ・ファイルに書き込むため、Oracle Databaseのオーバーヘッドが大幅に削減されます。ダイレクト・パス・ロードでは、データベース・リソースに対して他のユーザーとの競合が発生しないため、ディスク速度に近い速度でデータをロードできます。

データをロードする表はデータベース中に存在している必要があります。SQL*Loaderでは、表は作成されません。すでにデータが含まれているか、または空である既存の表にロードされます。

ロードを実行するには、次の権限が必要です。

- ロードする表についてのINSERT権限。

- ロードする表にすでにデータが存在するために、REPLACEオプションまたはTRUNCATEオプションを使用して古いデータを削除してから新しくデータをロードする場合には、その表についてのDELETE権限。

ROWID列のロード

従来型パス・ロードおよびダイレクト・パス・ロードの両方において、ROWID列のテキスト値を指定できます。(これは、SELECT ROWID FROM table_nameの処理の実行時に取得するテキストと同じです。)ROWIDの文字列解釈は、表内の列に対してはROWID型に変換されます。

従来型パス・ロード

従来型パス・ロード(デフォルト)では、SQL INSERT文とバインド配列バッファを使用して、データをデータベース表にロードします。

SQL*Loaderで従来型パス・ロードを実行する場合、バッファ・リソースに関して他のすべてのプロセスと同等の処理が行われるため、競合が発生します。このため、ロードにかなりの時間がかかります。また、SQL文が生成され、Oracle Databaseに渡されてから実行されるため、さらにオーバーヘッドが発生します。

挿入が発生すると、常に、Oracle Databaseで空き領域のあるブロック(ディスク内に散在して、部分的に書込み可能なブロック)が検索され、そこにデータが書き込まれます。通常のデータベース使用の場合はそれほどでもありませんが、このアクションは大量データのロード速度を大幅に低下させることがあります。

関連項目:

「中断された従来型パス・ロード」

単一パーティションの従来型パス・ロード

従来型パス・ロードでは、SQL INSERT文を使用します。ただし、従来型パスで単一パーティションに対してロードする場合は、SQL*Loaderで次のような形式のINSERT文のパーティション拡張構文を使用します。

INSERT INTO TABLE T PARTITION (P) VALUES ...

OracleカーネルのSQLレイヤーでは、挿入される行が指定のパーティションに対応するかどうかを判断します。行が指定のパーティションに対応しない場合、その行は拒否され、そのことを示すエラー・メッセージがSQL*Loaderログ・ファイルに記録されます。

従来型パスを使用する場合

ロードを高速にするには、従来型パス・ロードよりダイレクト・ パス・ロードを使用します。ただし、ダイレクト・パス・ロードにはいくつかの制限があるため、従来型パス・ロードを使用する必要がある場合もあります。次のような場合には、従来型パス・ロードを使用します。

- ロードと並行して索引付き表にアクセスする場合、またはロードと並行して索引なしの表に挿入または更新を行う場合。
ダイレクト・パス・ロード(パラレル・ロードは除く)を使用するには、SQL*Loaderに、表への排他的書込み権限と、すべての索引への排他的読取り権限および書込み権限が必要です。

- データをクラスタ表にロードする場合。
ダイレクト・パス・ロードでは、クラスタ表に対するロードはサポートされていません。

- 比較的少数の行を索引付きの大きな表にロードする場合。
ダイレクト・パス・ロードでは、既存の索引を新しい索引キーとマージするために、既存の索引をコピーします。既存の索引が非常に大きく、新しいキーの数が非常に少ない場合は、索引をコピーする時間が、ダイレクト・パス・ロードで節約できる時間を相殺してしまうことがあります。

- 参照整合性制約および列チェック整合性制約のある大きな表に、比較的少数の行をロードする場合。
これらの制約は、ダイレクト・パスでロードした行には適用できないため、ロードが継続している間は使用禁止になります。そして、ロードが完了した時点で表全体に適用されます。表が非常に大きく、新しい行の数が少ない場合は、この処理にかかる時間が節約した時間より多くなる可能性があります。

- レコードのロード時に、次のような状況でレコードが拒否されることを確認する場合。

- レコードの挿入でOracleエラーが発生した場合。

- レコードが間違ってフォーマットされたため、SQL*Loaderでフィールドの境界を見つけられない場合。

- レコードが制約に違反した場合、または一意の索引を非一意にしようとした場合。

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

バインド配列バッファに書き込むかわりに、SQL INSERT文を使用して、バインド配列をOracle Databaseに渡します。ダイレクト・パス・ロードは、ダイレクト・パスAPIを使用して、ロードされるデータをサーバーのロード・エンジンに渡します。ロード・エンジンは、渡されたデータから列配列構造体を作成します。

ダイレクト・パス・ロード・エンジンは、列配列構造体を使用してOracleデータ・ブロックをフォーマットし、索引キーを作成します。新しくフォーマットされたデータベース・ブロックが直接データベースに書き込まれます(ホスト・プラットフォームが非同期I/Oをサポートしている場合、非同期書込みを使用して1つのI/O要求に対して複数のブロックを書き込むことができます)。

内部的には、フォーマットされたブロック用に複数のバッファが使用されます。ホスト・プラットフォームで非同期I/Oが可能な場合は、あるバッファに書き込んでいる間に1つ以上のバッファへの書込みが行われます。この場合、I/Oを伴う処理がオーバーラップするため、ロード・パフォーマンスが向上します。

関連項目:

「中断されたダイレクト・パス・ロード」

ダイレクト・パス・ロード時のデータ変換

ダイレクト・パス・ロード時には、サーバー側ではなくクライアント側でデータ変換が発生します。初期化パラメータ・ファイルのNLSパラメータ(サーバー側の言語ハンドル)は使用されません。この動作を変更するには、SQL*Loaderの制御ファイルに書式マスクを指定する(初期化パラメータ・ファイルにNLSパラメータを設定することと同じ)か、または適切な環境変数を設定します。たとえば、フィールドに日付書式を指定するには、例12-1に示すとおりSQL*Loaderの制御ファイルに日付書式を設定するか、または例12-2に示すとおり環境変数NLS_DATE_FORMATを設定します。

例12-1 SQL*Loaderの制御ファイルに対する日付書式の設定

LOAD DATA
INFILE 'data.dat'
INSERT INTO TABLE emp
FIELDS TERMINATED BY "|"
(
EMPNO NUMBER(4) NOT NULL,
ENAME CHAR(10),
JOB CHAR(9),
MGR NUMBER(4),
HIREDATE DATE 'YYYYMMDD',
SAL NUMBER(7,2),
COMM NUMBER(7,2),
DEPTNO NUMBER(2)
)

例12-2 環境変数NLS_DATE_FORMATの設定

UNIXのBourneまたはKornシェルの場合:

% NLS_DATE_FORMAT='YYYYMMDD'
% export NLS_DATE_FORMAT

UNIXのcshの場合:

%setenv NLS_DATE_FORMAT='YYYYMMDD'

パーティション表またはサブパーティション表のダイレクト・パス・ロード

パーティション表またはサブパーティション表へロードする場合は、SQL*Loaderによって、行がパーティション化され、索引(索引もパーティション化できます)がメンテナンスされます。パーティション表またはサブパーティション表のダイレクト・パス・ロードは、パーティションまたはサブパーティションの多い表の場合、非常に多くのリソースを使用することに注意してください。

注意:

複数のパーティションに対してダイレクト・パス・ロードを実行する場合に領域エラーが発生すると、ロードは直前のコミット・ポイントにロールバックされます。コミット・ポイントが存在しない場合、ロード全体がロールバックされます。これによって、領域エラー後に検出されたデータが異なるパーティションに書き込まれることがなくなります。

ROWSパラメータを使用して、コミット・ポイントの頻度を指定できます。ROWSパラメータが指定されていない場合、ロード全体がロールバックされます。

単一パーティションまたはサブパーティションのダイレクト・パス・ロード

パーティション表の単一パーティションまたはサブパーティションをロードするとき、SQL*Loaderによって、行がパーティション化され、SQL*Loader制御ファイルに指定されたパーティションまたはサブパーティションにマップできない行はすべて拒否されます。ロードされるデータのパーティションまたはサブパーティションに対応するローカル索引パーティションは、SQL*Loaderによってメンテナンスされます。単一パーティションまたはサブパーティションのダイレクト・パス・ロードでは、グローバル索引はメンテナンスされません。ただし、ダイレクト・パスで単一パーティションに対してロードする場合、SQL*Loaderでは次のような形式のLOAD文のパーティション拡張構文を使用します。

LOAD INTO TABLE T PARTITION (P) VALUES ...

LOAD INTO TABLE T SUBPARTITION (P) VALUES ...

パーティション表またはサブパーティション表の1つのパーティションをロードしている間も、その表の他のパーティションに対してはDML操作やダイレクト・パス・ロードを行うことができます。

ダイレクト・パス・ロードでは、データベース処理は最小限に抑えられますが、ロードの開始時と終了時に、それぞれロードの初期化と終了処理のためにOracle Databaseに対するコールが数回実行されます。また、ロードの初期化中に必要なDMLロックがかけられ、ロード終了時に解除されます。ロード中には、索引キーが作成されてソートに使用されたり、必要に応じて新しいエクステントを取得するために領域管理ルーチンを使用することによって、データ・セーブポイントの上限(最高水位標)を調整するなどの動作も発生します。上限の調整の詳細は、「データ・セーブを使用したデータ損失の防止」を参照してください。

ダイレクト・パス・ロードのメリット

ダイレクト・パス・ロードは、従来型パス・ロードよりも処理が高速です。その理由は次のとおりです。

- 一部使用中の部分ブロックを使用しないため、空きブロックを検索するための読取り処理が不要で、書込みも少なくなります。

- SQL*LoaderはSQL INSERT文を実行しないため、Oracle Databaseの処理負荷が減ります。

- 表と索引をロード開始時にロックするようにOracleに要求し、ロード完了時にロック解除を要求します。これに対し、従来型パス・ロードでは、行配列ごとにOracleを1回コールして、SQL INSERT文を処理します。

- マルチ・ブロックの非同期I/Oを使用してデータベース・ファイルに書き込みます。

- ダイレクト・パス・ロードを使用するプロセスは、Oracleのバッファ・キャッシュを使用するのではなく、そのプロセス独自の書込みI/Oを実行します。これによって、他のOracleユーザーとの競合を最少にします。

- SORTED INDEXESオプションを指定すると、使用システムまたはインストール環境に固有の高性能ソート・ルーチンを使用して、データを事前にソートしておくことができます。

- ロードする表が空の場合、事前ソート・オプションを使用すると索引作成のソート段階とマージ段階を省略できます。索引は、データの挿入時に作成されます。

- インスタンス障害からのリストアに、REDOログ・ファイル・エントリは必要ありません。したがって、次の場合は、ロード時のログを記録する時間は不要です。

- Oracle Databaseで、SQL NOARCHIVELOGパラメータが使用可能な場合

- SQL*LoaderのUNRECOVERABLE句が使用可能な場合

- ロードするオブジェクトのSQL NOLOGGINGパラメータが設定されている場合

詳細は、「インスタンス・リカバリおよびダイレクト・パス・ロード」を参照してください。

ダイレクト・パス・ロード使用上の制限

ダイレクト・パス・ロードを使用するには、次の条件を満たしている必要があります。

- ロードする表はクラスタ化できません。

- ロードする表は、INSERTでアクティブなOracle Virtual Private Database (VPD)ポリシー含むことができません。

- ロードするセグメントに未処理のアクティブ・トランザクションを含むことはできません。
この条件が満たされているかどうかを確認するには、MONITOR TABLEというOracle Enterprise Managerコマンドを使用して、ロードする表のオブジェクトIDを検索します。次に、MONITOR LOCKコマンドを使用して、表にロックがかけられているかどうか調べます。

- Oracle9iより前のリリースのデータベースでは、クライアントとサーバーが同じリリースである場合のみ、SQL*Loaderのダイレクト・パス・ロードを実行できます。また、Oracle9iのデータのダイレクト・パス・ロードは、以前のリリースのデータベースに対しては実行できません。たとえば、ダイレクト・パス・ロードを使用して、リリース9.0.1のデータベースからリリース8.1.7のデータベースにデータをロードすることはできません。
Oracle9i以上では、クライアントとサーバーのリリースが異なる場合にも、SQL*Loaderのダイレクト・パス・ロードを実行できます。ただし、両方がリリース9.0.1以上で、クライアントのリリースは、サーバーのリリース以下である必要があります。たとえば、リリース9.0.1のデータベースからリリース9.2のデータベースへのダイレクト・パス・ロードを実行できます。ただし、リリース10.0.0のデータベースからリリース9.2のデータベースへのデータのロードに、ダイレクト・パス・ロードを使用することはできません。

次の機能は、ダイレクト・パス・ロードでは使用できません。

- BFILE列のロード

- ロード時のCREATE SEQUENCEの使用。これは、ダイレクト・パスではINSERT文が生成されないため、ダイレクト・パス・ロードでは、次の値をフェッチするSQLが生成されないことが理由です。

単一パーティションのダイレクト・パス・ロードでの制限

前述の制限に加え、単一のパーティションをロードするときには次の制限があります。

- パーティションのある表に、グローバル索引が定義されていないこと。

- パーティションのある表に対して、参照制約およびCHECK制約が使用禁止であること。

- トリガーが使用禁止であること。

ダイレクト・パスを使用する場合

前述の制限のいずれにも該当しない場合は、次のようなときにダイレクト・パス・ロードを使用してください。

- 短時間で大量のデータをロードする必要がある場合。ダイレクト・パス・ロードによって、大量のデータを高速ロードし、索引付けできます。表が空であるかどうかにかかわらず、データをロードできます。

- 最大のパフォーマンスを得るため、データをパラレルでロードする場合。詳細は、「パラレル・データ・ロード・モデル」を参照してください。

整合性制約

ダイレクト・パス・ロード時には、すべての整合性制約が適用されます。ただし、すべての制約が同時に適用されるとはかぎりません。ロード中にはNOT NULL制約が施行されます。これらの制約に従っていないレコードは拒否されます。

ロード中およびロード後に、UNIQUE制約が施行されます。UNIQUE制約に違反するレコードは拒否されます(制約違反が検出されると、そのレコードはメモリー内で使用不可になります)。

他の行または表に依存する整合性制約(参照制約など)は、ダイレクト・パス・ロード実行前に使用禁止になります。そのため、ロード後に再び使用可能にする必要があります。REENABLEを指定すると、SQL*Loaderにより、これらの制約はロード終了時に自動的に使用可能に戻されます。制約が再び使用可能になった時点で、表全体(すべての行)に対してチェックが行われます。このチェックでエラーが見つかった行は、指定されたエラー・ログに書き込まれます。詳細は、「ダイレクト・パス・ロード、整合性制約およびトリガー」を参照してください。

ダイレクト・パスのフィールド・デフォルト

ダイレクト・パス・ロードを使用する場合、データベースに定義されているデフォルトの列指定は使用できません。デフォルト値を設定するフィールドに対しては、DEFAULTIF句を使用して指定する必要があります。DEFAULTIF句が指定されておらず、フィールドがNULLである場合は、NULL値がデータベースに挿入されます。

シノニムへのロード

ダイレクト・パス・ロードでは、表のシノニムにデータをロードできます。ただし、そのためには、そのシノニムが表または単純表のビューを直接指している必要があります。以下の制限に注意してください。

- ユーザー定義の型またはXMLデータを持つ表にビューが存在する場合、ダイレクト・パス・モードは使用できません。

- ダイレクト・パス・モードでは、SQL式を含むSQL*Loader制御ファイルを使用してビューをロードすることはできません。

ダイレクト・パス・ロードの使用

この項では、SQL*Loaderのダイレクト・パス・ロードの使用方法を説明します。内容は次のとおりです。

- ダイレクト・パス・ロードのセットアップ

- ダイレクト・パス・ロードの指定

- 索引の作成

- 使用禁止状態(Index Unusable)のままの索引

- データ・セーブを使用したデータ損失の防止

- ダイレクト・パス・ロード時のデータ・リカバリ

- LONG型データ・フィールドのロード

- ダイレクト・パス・モードを使用するSQL*Loader操作の監査

ダイレクト・パス・ロードのセットアップ

ダイレクト・パス・ロード用にデータベースを準備するには、セットアップ・スクリプトのcatldr.sqlを実行し、必要なビューを作成します。このスクリプトは、ダイレクト・ロードを行う予定のデータベースそれぞれに対して1回のみ実行します。データベースのインストール時に、ダイレクト・ロードを実行することがわかっている場合は、データベースのインストール中にこのスクリプトを実行することもできます。

ダイレクト・パス・ロードの指定

SQL*Loaderをダイレクト・パス・ロード・モードで起動するには、次の形式で、コマンドラインまたはパラメータ・ファイル(使用している場合)のDIRECTパラメータにTRUEを設定します。

DIRECT=TRUE

関連項目:

- ダイレクト・パス・ロードのパフォーマンスの最適化に使用可能なパラメータの詳細は、「ダイレクト・パス・ロード・パフォーマンスの最適化」を参照してください

- 複数CPUシステムまたは分散システムでダイレクト・パス・ロードを使用する場合は、「複数CPUシステムのダイレクト・パス・ロードの最適化」を参照してください

索引の作成

一時記憶域を使用すると、ダイレクト・パス・ロードのパフォーマンスが向上します。各ブロックがフォーマットされた後、新しい索引キーがソート(一時)セグメントに挿入されます。ロードが終了すると、古い索引と新しいキーがマージされ、新しい索引が作成されます。古い索引、ソート(一時)セグメント、新しい索引セグメントでは、すべてのマージが完了するまで記憶域が必要です。最後に、古い索引と一時セグメントが削除されます。

従来型パス・ロードでは、行が挿入されるたびに索引が更新されます。この方法では一時記憶域は不要ですが、処理に時間がかかります。

パフォーマンスの向上

メモリーに制限があるシステムでパフォーマンスを向上するには、SINGLEROWパラメータを使用します。詳細は、「SINGLEROWオプション」を参照してください。

注意:

ダイレクト・ロード時にデータの事前ソートを指定してあり、既存の索引が空である場合、一時セグメントは不要で、マージも行われません。この場合は、索引にキーが直接付加されます。詳細は、「ダイレクト・パス・ロードのパフォーマンスの最適化」を参照してください。

複数の索引が作成されると、古い索引の他に、各索引に対応する一時セグメントが同時に存在するようになります。次に、新しいキーは一度に1索引ずつ古い索引とマージされます。新しい各索引が作成されると、古い索引とそれに対応する一時セグメントは削除されます。

関連項目:

索引のサイズを計算する方法および記憶域パラメータを設定する方法の詳細は、『Oracle Database管理者ガイド』を参照してください

一時セグメント記憶域要件

新しい索引キーの格納に必要な一時セグメント領域の大きさ(バイト単位)を計算するには、次の式を使用します。

1.3 * key_storage

この式では、キー記憶域が次のように定義されます。

key_storage = (number_of_rows) *
( 10 + sum_of_column_sizes + number_of_columns )

この式における列(column)とは、索引の列を意味します。ここでは、1列につき1バイトを使用しています。さらに、ROWIDやその他のオーバーヘッドとして1行につき10バイトを計算に入れています。

定数1.3は、ソートに必要な追加領域の平均的な大きさを反映しています。この値は、データの順序がきわめてランダムな場合に有効です。データが逆の順序に並んでいると、ソートには2倍のキー記憶域が必要となるため、そのときは定数値を2.0とします。ただし、これは最悪の場合です。

データが完全にソートされている場合は、索引エントリを格納できる領域のみが必要なため、そのときの定数の値は1.0に下がります。詳細は、「高速索引付けのためのデータの事前ソート」を参照してください。

使用禁止状態(Index Unusable)のままの索引

ロードされているデータ・セグメントが、その索引の索引セグメントより新しいものになると、SQL*Loaderによって索引が索引使用禁止状態になります。

SQL文が索引使用禁止状態の索引を参照しようとすると、エラーが発生します。ダイレクト・パス・ロードの実行時に、次のような状況が発生すると、索引またはパーティション索引のパーティションは索引使用禁止状態になります。

- SQL*Loaderで索引のための領域が少なくなり、索引が更新できない場合。

- データがSORTED INDEXES句で指定した順序になっていない場合。

- インスタンス障害が発生したか、または索引作成中にOracleシャドウ・プロセスが失敗した場合。

- 一意の索引内に重複キーがある場合。

- データ・セーブポイントを使用中、データ・セーブポイント発生後にロードが正常に実行されないか、またはキーボードからの中断によって終了された場合。

ある索引が索引使用禁止状態かどうかを調べるには、次に示す簡単な問合せを実行します。

SELECT INDEX_NAME, STATUS
FROM USER_INDEXES
WHERE TABLE_NAME = 'tablename';

表の所有者でない場合は、USER_INDEXESのかわりに、ALL_INDEXESまたはDBA_INDEXESを検索してください。

ある索引パーティションが使用禁止状態かどうかを調べるには、次に示す問合せを実行します。

SELECT INDEX_NAME,
PARTITION_NAME,
STATUS FROM USER_IND_PARTITIONS
WHERE STATUS != 'VALID';

表の所有者でない場合は、USER_IND_PARTITIONSのかわりに、ALL_IND_PARTITIONSおよびDBA_IND_PARTITIONSを検索します。

データ・セーブを使用したデータ損失の防止

データ・セーブを使用して、インスタンス障害によるデータ損失を回避できます。最後のセーブポイントにロードされたすべてのデータが、インスタンス障害から保護されます。インスタンス障害後にロードを続行する場合は、障害発生前に入力ファイルから何行処理されたか判別し、SKIPパラメータを使用して、処理済の行をスキップします。

表に索引がある場合には、まず索引を削除してからロードを続行します。ロードの終了後、索引を再作成してください。メディア障害およびインスタンス・リカバリの詳細は、「ダイレクト・パス・ロード時のデータ・リカバリ」を参照してください。

注意:

SQL*Loaderではデータのロードが完了するまで索引が作成されないため、索引はデータ・セーブでは保護されません(事前ソートされたデータを空の表にロードする場合にかぎり、ロード中に索引が作成されますが、その場合も索引は保護されません。)

ROWSパラメータの使用

ROWSパラメータには、ダイレクト・パス・ロードでデータ・セーブを行う間隔を設定します。ROWSに指定する値は、データベースへの挿入を保存する前に、SQL*Loaderによって入力ファイルから読み込まれる行数です。

データ・セーブは負荷の高い操作です。データ・セーブの間隔が15分以上になるように、ROWSを十分高い値に設定してください。これによって、長時間のダイレクト・パス・ロードの実行中にインスタンス障害が発生したときに、損失する作業量の上限(最高水位標)を指定できます。ROWSに小さい値を設定すると、パフォーマンスおよびデータ・ブロック領域使用率が低下します。

データ・セーブとコミット

従来型ロードでは、ROWSはコミット操作の前に読み込む行数を意味します。ダイレクト・ロードにおけるデータ・セーブは、従来型ロードにおけるコミットと同様ですが、異なる部分もあります。

類似点は次のとおりです。

- データ・セーブを行うと他のユーザーもその行を参照できます。

- データ・セーブ後は、行をロールバックできません。

一方、従来型との主な相違点は、ダイレクト・パス・ロードのデータ・セーブではロードが完了するまで索引が使用できない(索引使用禁止状態)ということです。

ダイレクト・パス・ロード時のデータ・リカバリ

ダイレクト・パス・ロード方法を指定すると、SQL*Loaderのデータ・リカバリ機能が完全にサポートされます。リカバリには大きく分けて2種類あります。

- メディア・リカバリは、損失したデータベース・ファイルをリカバリします。データベース・ファイルを損失した場合に、それをリカバリできるようにするには、ARCHIVELOGモードで実行する必要があります。

- インスタンス・リカバリは、障害が発生する前にインメモリー・データが変更されたが、ディスクに書き込まれる前に障害のため失われてしまったというシステム障害をリカバリします。Oracle Databaseでは、REDOログ・ファイルがアーカイブされていない場合も、インスタンス障害をリカバリできます。

メディア・リカバリおよびダイレクト・パス・ロード

REDOログ・ファイル・アーカイブ機能が使用可能になっている( ARCHIVELOGモードで実行している)場合、ダイレクト・パスでロードしたデータは、SQL*Loaderによってログに記録されます。それによって、メディア・リカバリが可能になります。REDOログ・ファイル・アーカイブの機能が使用可能になっていない(NOARCHIVELOGモードで実行している)場合、メディア・リカバリはできません。

ロード中に失われたデータベース・ファイルをリカバリするには、従来型パスでロードしたデータをリカバリするときと同じ方法を使用してください。

1. 影響を受けたデータベース・ファイルの最新のバックアップをリストアします。

2. RMAN RECOVERコマンドを使用して、表領域をリカバリします。

関連項目:

RMANを使用して表領域をリカバリする方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

インスタンス・リカバリおよびダイレクト・パス・ロード

データベース・ファイルは、SQL*Loaderによって直接書き込まれます。そのため、インスタンスを再起動すると、最後にデータをセーブした時点までに挿入したすべての行が、自動的にデータベース・ファイルに存在します。変更がREDOログ・ファイルに記録されていなくても、インスタンス・リカバリは可能です。

インスタンス障害が発生すると、作成中の索引は索引使用禁止状態のままになります。使用禁止状態の索引は、表またはパーティションを使用する前に再構築する必要があります。索引が索引使用禁止状態のままであるかどうかを調べる方法については、「使用禁止状態(Index Unusable)のままの索引」を参照してください。

LONG型データ・フィールドのロード

SQL*Loaderの最大バッファ・サイズよりも長いデータをダイレクト・パスでロードするには、LOBを使用します。LOBに大きいSTREAMSIZE値を使用すると、パフォーマンスが向上します。

関連項目:

- 「LOBのロード」

- 「列配列の行数およびストリーム・バッファ・サイズの指定」

次の項で説明するように、PIECEDパラメータを使用すると、最大バッファ・サイズより長いデータもロードできますが、LOBを使用することをお薦めします。

PIECEDとしてのデータのロード

データが論理レコードの最終列である場合、PIECEDパラメータを使用すると、データをセクションごとにロードできます。

列をPIECEDと宣言することによって、LONGフィールドを複数の物理レコード(ピース)に分割することが、ダイレクト・パス・ローダーに通知されます。この場合、SQL*Loaderでは、LONGフィールドの各ピースが物理レコード内で検索された順序で処理されます。レコードが処理される前に、フィールドのすべてのピースが読み込まれます。SQL*Loaderでは、格納前のLONGフィールドは具体化されません。ただし、レコードが処理される前に、フィールドのすべての部分が読み込まれます。

列をPIECEDと宣言する場合、次の制約が適用されます。

- このオプションはダイレクト・パスでのみ有効です。

- 1つの表につき1フィールドのみをPIECEDにできます。

- PIECEDフィールドは論理レコードの最終フィールドである必要があります。

- WHEN句、NULLIF句またはDEFAULTIF句では、PIECEDフィールドを使用できません。

- 論理レコード内のPIECEDフィールドの領域は、他のフィールドの領域と重複してはいけません。

- PIECEDに対応するデータベースの列を索引に含めることはできません。

- 拒否されたレコードにPIECEDフィールドが含まれている場合は、不良ファイルからそのレコードをロードできません。
たとえば、1つのPIECEDフィールドが3つのレコードにまたがっているとします。SQL*Loaderでは、最初のレコードからPIECEDフィールドの第一分割がロードされ、次に同じバッファを使用して2番目のレコードから第二分割がロードされます。その後、同じバッファを使用して同様に3番目のレコードがロードされます。ここでエラーが検出されると、最初の2つのレコードはすでにバッファには存在しないため、3番目のレコードのみが不良ファイルに書き込まれます。その結果、不良ファイルにあるレコードが無効となります。

ダイレクト・パス・モードを使用するSQL*Loader操作の監査

選択したユーザー・データベース・アクションを監視および記録するため、SQL*Loaderのダイレクト・パス・ロードの監査を実行できます。SQL*Loaderでは、すべての監査レコードが1つの場所に一元化される統合監査を使用します。

統合監査を設定するには、統合監査ポリシーを作成するか、既存のポリシーを変更します。監査ポリシーは、データベースにおけるユーザー動作の特定の部分を監査できる監査設定の名前付きグループです。ポリシーを作成するには、SQL CREATE AUDIT POLICY文を使用します。

監査ポリシーを作成したら、AUDITおよびNOAUDIT SQL文を使用してポリシーをそれぞれ有効化および無効化します。

関連項目:

- SQL CREATE AUDIT POLICY、ALTER AUDIT POLICY、AUDITおよびNOAUDIT文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- Oracle Databaseで監査を使用する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

ダイレクト・パス・ロードのパフォーマンスの最適化

ダイレクト・パス・ロードでは、使用する時間と一時記憶域を制御できます。

時間を最小化するには、次の方法があります。

- 記憶域の事前割当て

- データの事前ソート

- データ・セーブの回数の削減

- REDOログの最小限の使用

- 配列行の列数およびストリーム・バッファのサイズを指定

- 日付キャッシュの値の指定

- DB_UNRECOVERABLE_SCN_TRACKING=FALSEと設定します。リカバリ不能な(nologging)ダイレクト書込みは、SCNと最終ダイレクト書込みの時間を定期的に格納することによって、制御ファイル内で追跡されます。制御ファイルへのこれらの更新がパフォーマンスに悪影響を及ぼす場合は、DB_UNRECOVERABLE_SCN_TRACKINGパラメータをFALSEに設定すると、パフォーマンスが向上することがあります。

領域を最小化するには、次の方法があります。

- ロード前のデータのソート時に、最も多くの一時記憶域を必要とする索引でデータをソートします。

- ロード中の索引メンテナンスを回避します。

高速ロードのための記憶域の事前割当て

SQL*Loaderでは、必要に応じて自動的に表にエクステントが追加されますが、これには時間がかかります。新しい表へ高速にロードするには、表の作成に必要なエクステントを事前に割り当ててください。

表に必要な領域を計算するには、『Oracle Database管理者ガイド』のデータベース・ファイルの管理の説明を参照してください。必要な領域を割り当てるには、SQL CREATE TABLE文でINITIALまたはMINEXTENTS句を使用します。

別の方法として、エクステントの割当て回数が減るようにエクステントのサイズを十分に大きくする方法もあります。

高速索引付けのためのデータの事前ソート

索引付き列を基準にしてデータを事前ソートすると、ダイレクト・パス・ロードのパフォーマンスを改善できます。事前ソートを行うと、ロード時の一時記憶要件を最小限に抑えることができます。また、事前ソートでは、ご使用のオペレーティング・システムまたはアプリケーション用に最適化された高性能ソート・ルーチンを利用できます。

データが事前ソートされていて既存の索引が空でない場合は、事前ソートによって、新しいキーに必要な一時セグメント領域の大きさを最小にできます。ソート・ルーチンは、新しい各キーをキー・リストに追加します。

ソート用の追加領域は必要なく、キーのための領域のみが必要となります。必要な記憶域の大きさを計算するには、ソート係数として1.3ではなく1.0を使用してください。必要な記憶域要件の見積りについては、「一時セグメント記憶域要件」を参照してください。

事前ソートを指定していて既存の索引が空である場合は、最大効率が実現します。新しいキーが索引に挿入されるのみです。一時セグメントと新しい索引が古い空の索引と同時に存在するのではなく、新しい索引のみが存在します。したがって、一時記憶域は不要であり、時間も短縮できます。

SORTED INDEXES句

SORTED INDEXESは、データを事前ソートしている索引を指定します。この句は、ダイレクト・パス・ロードでのみ使用できます。例については、「事例6: ダイレクト・パス・ロード方式を使用したデータのロード」を参照してください。 (事例の使用方法については、「SQL*Loaderの事例」を参照してください。)

一般に、SORTED INDEXES句では1つの索引のみを指定します。通常、これは、ある索引でソートされたデータは、別の索引にとって正しい順序とはかぎらないためです。ただし、複数の索引のデータの順序が同じである場合は、索引すべてを同時に指定できます。

SORTED INDEXES句で指定した索引はすべて、ダイレクト・パス・ロードを開始する前に作成する必要があります。

未ソートのデータ

SORTED INDEXES句で索引を指定しても、データがその索引でソートされていない場合は、ロード終了時に索引は索引使用禁止状態のままになります。データは存在していますが、索引を使用しようとするとエラーになります。索引使用禁止状態の索引がある場合は、ロード後に再構築してください。

複数列索引

SORTED INDEXES句で複数列の索引を指定する場合は、まず索引の最初の列で順序付けが行われ、次に2番目の列で順序付けが行われるように、データをソートしてください。

たとえば、索引の最初の列に都市名があり、2番目の列に名前の名字がある場合、次のリストのように都市別順で、同じ都市の中では名字順に並ぶようにデータをソートします。

Albuquerque      Adams
Albuquerque      Hartstein
Albuquerque      Klein
...         ...
Boston           Andrews
Boston           Bobrowski
Boston           Heigham
...              ...

最適ソート順序の選択方法

ダイレクト・パス・ロードのパフォーマンスを最大限に引き出すには、最も大きな一時セグメント領域を必要とする索引に基づいて、データを事前ソートしてください。たとえば、主キーが1つの数値列で、2次キーが3つのテキスト列で構成される場合、2次キーで事前ソートすることによって、ソート時間と記憶要件の両方を最小にできます。

最も大きな記憶域を必要とする索引がどれであるかを知るには、次の手順に従ってください。

1. 各索引について、その索引のすべての列の幅を加算します。

2. 単一表へのロードの場合は、最大幅を持つ索引を選択します。

3. 複数表へのロードの場合は、各表に対して最大幅を持つ索引を調べます。各表にロードされる行数が同じ場合は、最大幅を持つ索引を選択します。通常は、各表にロードされる行数は同じです。

4. 複数表へのロードにおいて、索引付きの表にロードされる行数が表によって異なる場合は、手順3で確認した各索引の幅と、その索引にロードされる行数を掛け合せます。結果が最も大きい値の索引を選択します。

データ・セーブの回数の削減

ROWS値が小さいことが原因でデータ・セーブが頻繁に発生する場合、ダイレクト・パス・ロードのパフォーマンスは低下します。ROWS値が小さい場合、セーブ後に最後のデータ・ブロックには書込みが行われないため、データ・ブロック領域が無駄になります。

ダイレクト・パス・ロードは従来型ロードより何倍も高速なため、ダイレクト・ロードの場合には、ROWSの値は従来型ロードの場合よりかなり大きくする必要があります。

データ・セーブ時には、SQL*Loaderのすべてのバッファへの書込みが正常に終了するまで、ロードは停止します。ROWSの値は、安全性を確保できる範囲で、できるだけ大きくしてください。数千行をロードしてみて、1行当たりの平均ロード時間を計ってみることをお薦めします。その値から、ROWSに設定する値が求められます。

たとえば、1分当たり20,000行がロードされるとします。この場合、処理途中に実行するセーブの間隔を10分以内にするには、ROWSを200,000(20,000行/分×10分間)に設定してください。

REDOログの最小限の使用

ダイレクト・ロードを大幅に高速化する1つの方法は、REDOログの使用を最小限に抑えることです。それには3通りの方法があります。アーカイブを使用禁止にする方法、ロードをリカバリ不可能に指定する方法、ロードされるオブジェクトに対してSQLのNOLOGGINGパラメータを設定する方法です。この項では、すべての方法を説明します。

アーカイブの使用禁止

アーカイブが使用禁止の場合、ダイレクト・パス・ロードでは全体イメージのREDOログは生成されません。SQLのARCHIVELOGおよびNOARCHIVELOGパラメータを使用して、アーカイブ・モードを設定します。アーカイブの詳細は、『Oracle Database管理者ガイド』を参照してください。

SQL*LoaderのUNRECOVERABLE句の指定

時間およびREDOログ・ファイルの領域を節約するには、データのロード時に制御ファイルでSQL*LoaderのUNRECOVERABLE句を使用します。リカバリ不可能を指定したロードの場合は、ロードされたデータはREDOログ・ファイルに記録されません。かわりに、操作を無効にするために必要なREDOログ(無効REDOログ)が生成されます。

UNRECOVERABLE句は、ロード・セッション中にロードされたすべてのオブジェクト(データ・セグメントおよび索引セグメントの両方)に適用されます。このため、ロードされた表についてはメディア・リカバリはできません。ただし、他のユーザーが行ったデータベース変更のログは、引き続き記録されます。

注意:

データ・ロードは記録されないため、必要な場合はロード後にデータのバックアップを取ってください。

UNRECOVERABLE句を指定してロードしたデータについてメディア・リカバリが必要になった場合、ロードしたデータ・ブロックには、論理的に破損したというマークが付けられます。

データをリカバリするには、データを削除して再作成します。データがリカバリ不能にならないように、データのロード後、すぐにバックアップを取ってください。

デフォルトでは、ダイレクト・パス・ロードはRECOVERABLEです。

次に、制御ファイルのUNRECOVERABLE句の指定例を示します。

UNRECOVERABLE
LOAD DATA
INFILE 'sample.dat'
INTO TABLE emp
(ename VARCHAR2(10), empno NUMBER(4));

SQL NOLOGGINGパラメータの設定

データまたは索引のセグメントにSQLのNOLOGGINGパラメータが設定されていると、そのセグメントに対する全体イメージのREDOログは使用できません(無効REDOログが生成されます)。NOLOGGINGパラメータを使用すると、ログが記録されないオブジェクトに対しより優れた制御が可能です。

列配列の行数およびストリーム・バッファ・サイズの指定

列配列の行数によって、ストリーム・バッファが作成される前にロードされた行数を判断します。STREAMSIZEパラメータで、クライアントからサーバーへ送ったデータのストリーム・サイズ(バイト単位)を指定します。

列配列の行数の値を指定するには、COLUMNARRAYROWSパラメータを使用します。 ダイレクト・パスを使用してVARRAYをロードすると、COLUMNARRAYROWSパラメータはデフォルトで100に設定され、クライアント・オブジェクトのキャッシュ・スラッシングを回避します。

ダイレクト・パス・ストリーム・バッファのサイズを指定するには、STREAMSIZEパラメータを使用します。

これらのパラメータの最適値は、使用されるシステム、入力データ型およびOracleの列データ型に応じて異なります。独自の構成用に最適な値を使用することで、SQL*Loaderのログ・ファイルでの経過時間が少なくなります。

注意:

ページングが過剰に発生すると、パフォーマンスが大幅に低下するため、ページング・アクティビティのプロセスを監視する必要があります。過剰なページングを回避するには、READSIZE、STREAMSIZEおよびCOLUMNARRAYROWSの値を小さくする必要があります。

複数CPUシステムでダイレクト・パス・ロードを実行する場合、列配列の行数およびストリーム・バッファのサイズを指定すると、特に有効です。

関連項目:

- 「複数CPUシステムのダイレクト・パス・ロードの最適化」

- 「COLUMNARRAYROWS」

- 「STREAMSIZE」

データ・キャッシュの値の指定

同じ日付値またはタイムスタンプ値のロードが何度も行われるダイレクト・パス・ロードを実行する場合、総ロード時間の大部分が日付およびタイムスタンプのデータの変換に使用される可能性があります。特に、複数の日付列がロードされる場合にこのような状況が発生します。この場合、SQL*Loaderのデータ・キャッシュを使用することによってパフォーマンスを向上できます。

データ・キャッシュを使用すると、入力データ内に多数の重複する日付値が存在する場合、日付変換が実行される回数が減ります。この機能を使用すると、ロード中に予測される一意の日付の数を指定できます。

データ・キャッシュは、デフォルトで使用可能です。データ・キャッシュを完全に使用禁止にするには、0(ゼロ)に設定します。

デフォルトのデータ・キャッシュ・サイズは1000要素です。デフォルトのサイズを使用し、1000を超える一意の入力値がロードされると、データ・キャッシュはこの表に対して自動的に使用禁止となります。これによって、過剰および不要なルックアップ時間によって、パフォーマンスが低下する可能性がなくなります。ただし、デフォルトを使用するかわりに0(ゼロ)以外の値をデータ・キャッシュに指定し、キャッシュ量がこの値を超えた場合、データ・キャッシュは使用禁止になりません。最大値を超えた入力データは、適切な変換ルーチンによって明示的に変換されます。

データ・キャッシュは、1つの表のみに対応付けできます。複数の表でデータ・キャッシュの共有はできません。次のすべての条件を満たす場合にのみ、表に対してデータ・キャッシュが作成されます。

- DATA_CACHEパラメータが0(ゼロ)以外に設定されている

- 表への格納のためにデータ型変換が必要な、1つ以上の日付値またはタイムスタンプ値(あるいはその両方)がロードされている

- ダイレクト・パス・ロードでロードされている

データ・キャッシュの統計はログ・ファイルに書き込まれます。これらの統計を使用して、次のとおりダイレクト・パス・ロードのパフォーマンスを向上できます。

- キャッシュ・エントリの数がキャッシュ・サイズより小さく、キャッシュ・ミスがない場合は、キャッシュ・サイズをより小さい値に設定できます。

- キャッシュ・ヒット(重複値が存在するエントリ)の数が小さく、キャッシュ・ミスの数が大きい場合は、キャッシュ・サイズを大きくする必要があります。キャッシュ・サイズを大きくしすぎると、過剰なページング、過度のメモリー使用量などの他の問題が発生する場合があります。

- ほぼすべての入力日付値が一意の場合、データ・キャッシュを使用してもパフォーマンスは向上しないため、使用する必要はありません。

注意:

データ・キャッシュがデフォルトで使用可能な場合、最大値を超えたため使用禁止になると、日付キャッシュの統計はSQL*Loaderのログ・ファイルに書き込まれません。

キャッシュ・サイズを大きくしてもパフォーマンスが向上しない場合は、デフォルトの動作に戻すか、またはキャッシュ・サイズを0(ゼロ)に設定します。パフォーマンス全体の向上は、ロードされる他の列のデータ型によっても異なります。ロードされる日付列の総数がロードされる他のデータ型より大きい場合、パフォーマンスは大幅に向上します。

関連項目:

DATA_CACHE

複数CPUシステムのダイレクト・パス・ロードの最適化

複数CPUシステムでダイレクト・パス・ロードを実行する場合、SQL*Loaderではデフォルトでマルチスレッドが使用されます。この場合の複数CPUシステムは、2つ以上のCPUを持つ単一のシステムとして定義されます。

マルチスレッド・ロードとは、可能な場合、列配列をストリーム・バッファに変換し、ストリーム・バッファ・ロードがパラレルで実行されることを表します。この最適化は、次の場合に最も効果的です。

- 列配列が、ロード用に複数のダイレクト・パス・ストリーム・バッファを生成できる十分な大きさの場合。

- 入力フィールドのデータ型からOracleの列データ型へのデータ変換が必要な場合。
変換は、ストリーム・バッファのロード時にパラレルで実行されます。

この処理の状態は、次の例に示すとおり、SQL*Loaderのログ・ファイルに記録されます。

Total stream buffers loaded by SQL*Loader main thread:         47
Total stream buffers loaded by SQL*Loader load thread:        180
Column array rows:                                           1000
Stream buffer bytes:                                       256000

この例では、SQL*Loaderのロード・スレッドがメイン・スレッドをオフロードしています。これによって、ロード・スレッドがサーバーで現行のストリームをロードする一方で、メイン・スレッドは、次のストリーム・バッファを作成できます。

ロード・スレッドを使用して、できるだけ多くのストリーム・バッファ・ロードを実行することが目的です。これによって、列配列の行数の増加、またはストリーム・バッファのサイズの削減(あるいはその両方)を実現できます。SQL*Loaderのログ・ファイルの経過時間を監視することで、変更による効果を確認できます。詳細は、「列配列の行数およびストリーム・バッファ・サイズの指定」を参照してください。

単一CPUシステム上では、最適化はデフォルトで無効になります。サーバーが他のシステム上にある場合は、マルチスレッドを手動で有効にするとパフォーマンスが向上します。

マルチスレッド・オプションを有効または無効にするには、SQL*LoaderのコマンドラインでMULTITHREADINGパラメータを使用するか、またはSQL*Loaderの制御ファイルにMULTITHREADINGパラメータを指定します。

関連項目:

ダイレクト・パス・ロードの概要は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください

索引メンテナンスの回避

従来型パスとダイレクト・パスの両方について、SQL*Loaderでは表のすべての既存の索引がメンテナンスされます。

索引のメンテナンスを回避するには、次のいずれかの方法を使用します。

- ロードを始める前に索引を削除します。

- ロードを始める前に、選択した索引または索引パーティションを索引使用禁止状態に設定し、SKIP_UNUSABLE_INDEXESパラメータを使用します。

- SKIP_INDEX_MAINTENANCEパラメータを使用します(ダイレクト・パスの場合に限定されるため、注意して使用してください)。

索引のメンテナンスを回避すると、ダイレクト・パス・ロード中に必要な領域を最小限にできます。その方法は次のとおりです。

- 一度に索引を作成できるため、各索引を別々に作成する場合に必要なソート用の(一時)セグメント領域を削減できます。

- 索引の作成時に、索引セグメントは1つのみ存在します(これに対し、新しいキーを古いキーにマージして新しい索引を作成するときには、一時的に3つのセグメントが存在します)。

表の全行数に対してロードする行数が多い場合、索引のメンテナンスを避けることは合理的です。ただし、比較的少数の行を大きな表に追加する場合は、索引の再ソートに非常に時間がかかることがあります。そのような場合は、従来型パス・ロードを使用するか、SQL*LoaderのSINGLEROWパラメータを使用します。詳細は、「SINGLEROWオプション」を参照してください。

ダイレクト・パス・ロード、整合性制約およびトリガー

従来型パス・ロードでは、行配列の挿入には標準SQL INSERT文を使用します。このとき、整合性制約および挿入トリガーは自動的に適用されます。ただし、ダイレクト・パスでデータをロードする場合は、SQL*Loaderでは一部の整合性制約およびすべてのデータベース・トリガーが使用禁止になります。このセクションでは、これらの機能に関するダイレクト・パス・ロードの使用について説明します。

整合性制約

整合性制約には、ダイレクト・パス・ロード時に自動的に使用禁止になるものがあります。また、使用禁止にならないものもあります。制約の詳細は、『Oracle Database開発ガイド』の制約によるデータ整合性のメンテナンスを参照してください。

使用可能な制約

ダイレクト・パス・ロード時でも使用可能な制約は、次のとおりです。

- NOT NULL

- UNIQUE

- 主キー制約(NOT NULL列における一意制約)

NOT NULL制約は列配列の作成時にチェックされます。NOT NULL制約に違反する行はすべて拒否されます。

ダイレクト・パス・ロード時にUNIQUE制約が使用可能であっても、その制約に違反する行もロードされます。(これは、そのような行が拒否される従来型パスとは異なります。)UNIQUE制約は、ダイレクト・パス・ロードの最後で索引が再作成されるときに検証されます。違反が検出されると、索引は索引使用禁止状態のままになります。詳細は、「使用禁止状態(Index Unusable)のままの索引」を参照してください。

使用禁止の制約

次の制約は、ダイレクト・パス・ロード時にデフォルトで自動的に使用禁止になります。

- CHECK制約

- 参照制約(外部キー)

EVALUATE CHECK_CONSTRAINTS句を指定すると、CHECK制約の自動的な使用禁止を変更できます。SQL*Loaderでは、ダイレクト・パス・ロード中にCHECK制約が評価されます。CHECK制約に違反する行はすべて拒否されます。次の例に、SQL*Loader制御ファイルでのEVALUATE CHECK_CONSTRAINTS句の使用方法を示します。

LOAD DATA
INFILE *
APPEND
INTO TABLE emp
EVALUATE CHECK_CONSTRAINTS
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(c1 CHAR(10) ,c2)
BEGINDATA
Jones,10
Smith,20
Brown,30
Taylor,40

制約を使用可能に戻す方法

REENABLE句を指定しておくと、ロードの完了時に、整合性制約が自動的に使用可能に戻されます。REENABLE句の構文は次のとおりです。

DISABLED_CONSTRAINTSパラメータはオプションで、読みやすくするために使用します。EXCEPTIONS句を使用する場合は、指定する表がすでに存在していて、その表への挿入が可能である必要があります。ここで指定する表には、整合性制約のいずれかに違反したすべての行のROWIDが格納されます。また、違反があった制約名も格納されます。この例外表の作成方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

SQL*Loaderログ・ファイルには、使用禁止となっていた制約、および使用可能に戻された制約が記録され、エラーが原因で制約を使用可能に戻せなかった場合または検査できなかった場合はそのエラーが記録されます。さらに、ロードした表のそれぞれに指定された例外表の名前もログ・ファイルに書き込まれます。

REENABLE句を使用しない場合は、表のすべての行が検査されるときに制約を手動で使用可能に戻す必要があります。ここで新しいデータにエラーが見つかると、エラー・メッセージが生成されます。例外表を指定した場合は、違反のあった制約名と不良データのROWIDが、その表に書き込まれます。

REENABLE句を使用すると、制約を自動的に使用可能に戻し、新しい行すべてを検証できます。新しいデータにエラーが見つからなかった場合は、検証された制約に自動的にマークを付けられます。新しいデータにエラーが見つかった場合は、ログ・ファイルにエラー・メッセージが書き込まれ、SQL*Loaderによって制約の状態にENABLE NOVALIDATEというマークが付けられます。例外表を指定した場合は、違反のあった制約名と不良データのROWIDが、その表に書き込まれます。

注意:

通常、表制約がENABLE NOVALIDATEの状態のままになっている場合、新しいデータは表へ挿入されますが、新しい無効なデータは挿入されません。ただし、SQL*Loaderのダイレクト・パス・ロードでは、この規則は施行されません。したがって、次のダイレクト・パス・ロードが無効なデータで実行される場合、無効なデータは挿入されますが、前述されたのと同じエラー・レポートおよび例外表の処理が実行されます。この例では、各ロードの前に外部表がクリーン・アウトされていない場合、その表には、重複するエントリが含まれます。重複するエントリは、次のような問合せを実行することによって、簡単に削除できます。

SELECT UNIQUE * FROM exceptions_table;

注意:

参照整合性の再検証は、表全体に対して実行する必要があります。そのため、少数の行を非常に大きい表にロードするときは、ダイレクト・パスではなく従来型パスを使用した方がパフォーマンスが向上することがあります。

データベース挿入トリガー

ダイレクト・パス・ロードが始まると、表挿入トリガーも使用禁止になります。行のロードおよび索引の再作成が完了すると、使用禁止になっていたトリガーはすべて使用可能に戻されます。ログ・ファイルには、ロード時に使用禁止になっていたすべてのトリガーのリストが示されます。トリガーを使用可能に戻すときに1つでもエラーがあると、使用可能にできません。

整合性制約と異なり、挿入トリガーは、使用可能に戻っても表全体に対して再び適用されません。つまり、ダイレクト・パスでロードされた行に対しては、挿入トリガーは起動しません。ダイレクト・パスでロードした場合は、新しい行への挿入トリガーに相当する処理はすべて、アプリケーション側で実行する必要があります。

挿入トリガーの整合性制約への置換

アプリケーションは整合性制約を実行する場合、通常は挿入トリガーを使用します。アプリケーションが使用する挿入トリガーのほとんどは単純なため、Oracleの自動整合性制約に置き換えることができます。

自動制約が使用できない場合

挿入トリガーは、Oracleの自動整合性制約に置き換えられない場合があります。たとえば、挿入トリガーの中で表のルックアップ関数を使用して整合性チェックを行っている場合、自動制約は使用できません。これは、自動制約はカレント行における定数および列以外は参照できないためです。このようなトリガーと同じ処理を実現する方法が2つあります。この項ではその方法について説明します。

準備

いずれの方法の場合も、表に対して事前に行うべき作業があります。次に示す一般的なガイドラインに従って、表を準備してください。

1. ロードの前に、表に1バイトまたは1文字分の列を追加します。この列は、各行が「旧データ」か「新データ」かを示すためのものです。

2. この列の値がNULLの場合は「旧データ」を示すことにします。これは、NULL列であれば領域を使用せずに済むためです。

3. ロード時にSQL*LoaderのCONSTANTパラメータを使用して、ロードしたすべての行に「新データ」を示すフラグを付けます。

この手順に従って準備すると、新しくロードした行が識別できるため、古い行に影響を与えずに新しいデータを操作できます。

更新トリガーの使用

一般に、挿入トリガーと同じ処理を実現する場合は、データベース更新トリガーを使用します。これは最も単純な方法です。例外を呼び出さない挿入トリガーの場合は、常にこの方法を使用できます。

1. 挿入トリガーと同じ処理を行う更新トリガーを作成します。

トリガーをコピーします。「new.column_name」というすべての箇所を「old.column_name」に変更してください。

2. 現行の更新トリガーがある場合は、それを新しい更新トリガーに置き換えます。

3. 「新データ」のフラグをNULLに変更して、表を更新します。これによって、更新トリガーが起動します。

4. 元の更新トリガーがある場合は、それをリストアします。

トリガーの動作によっては、この操作中に表に対する排他的更新アクセスが必要となる場合もあります。排他的更新アクセスを実行すると、他のユーザーが修正する行に、誤ってこのトリガーが適用されることはありません。

例外処理と同じ処理の実現

挿入トリガーの中で例外を呼び出している場合、それと同じ処理を行うには、さらに作業が必要です。例外を呼び出すということは、表にその行を挿入しないということです。この処理を更新トリガーで実現するには、ロードした行に削除フラグを付けておく必要があります。

この場合、「新データ」列を削除フラグに使用することはできません。更新トリガーでは、その起動元である列を修正できないためです。したがって、表にもう1列追加する必要があります。ここで追加する列は、削除する行を示すためのものです。NULL値の場合は、行が有効であることを示します。挿入トリガーで例外を呼び出すと、常に、更新トリガーによって追加列にフラグが設定されます。これによって、その行が無効であることが示されます。

要約すると、挿入トリガーで例外を呼び出している場合は、次の条件を満たすと、同じ処理を更新トリガーで実現できます。

- 表に列を2つ追加する(通常はNULL)。

- 表を排他的に更新できる(必要な場合)。

ストアド・プロシージャの使用

次に示すプロシージャは、どのような場合でも使用できますが、その実装はより複雑になります。このプロシージャは、挿入トリガーで例外を呼び出すときに使用できます。そのとき、2番目の列を追加する必要はありません。また、更新トリガーとは処理が異なるため、表に対する排他的アクセス権限がなくても使用できます。

1. 次のようにして、挿入トリガーと同じ処理を行うストアド・プロシージャを作成します。

a. 表から新しい行をすべて選択するように、カーソルを宣言します。

b. 処理ループの中でカーソルをオープンし、1回に1行ずつフェッチします。

c. 挿入トリガーでの操作を実行します。

d. 操作が正常に終了した場合は、「新データ」のフラグをNULLに変更します。

e. 操作が失敗した場合は、「新データ」のフラグを「不良データ」に変更します。

2. SQL*Plusなどの管理ツールを使用して、このストアド・プロシージャを実行します。

3. プロシージャの実行後、表の中に「不良データ」フラグの付いた行がないかどうかを調べます。

4. 不良の行を更新または削除します。

5. 挿入トリガーを使用可能に戻します。

永続的に使用禁止のトリガーおよび制約

SQL*Loaderでは、トリガーおよび制約を使用禁止にするために、ロードされる表にいくつかのロックを獲得する必要があります。競合するプロセスが表のトリガーまたは制約を使用可能にしているときに、SQL*Loaderでその表のトリガーまたは制約を使用禁止にしようとした場合、SQL*Loaderではその表に関して排他的アクセス権を獲得することはできません。

この場合、SQL*Loaderでは、できるかぎり問題のないように処理が実行されます。ロード終了前に、使用禁止のトリガーおよび制約を使用可能に戻そうとします。ただし、表ロックが原因でSQL*Loaderの処理を継続できなくなった場合は、SQL*Loaderでトリガーや制約を使用可能にする処理も実行されないことがあります。この場合、トリガーおよび制約は、手動で使用可能にするまで永続的に使用できない状態になります。

このような状況はまれですが、発生する可能性はあります。このような状況を回避するには、ダイレクト・ロードの処理中は、表のトリガーまたは制約を使用可能にするアプリケーションを実行しないことをお薦めします。

適切なロックの獲得に失敗したことによってダイレクト・ロードが終了した場合は、ログを確認してください。ログには、使用禁止のすべてのトリガーおよび制約と、それらを使用可能に戻すための各試行が示されます。SQL*Loaderによって使用可能に戻されなかったすべてのトリガーおよび制約は、『Oracle Database SQL言語リファレンス』で説明するALTER TABLE文のENABLE句を使用して、手動で使用可能にする必要があります。

従来型パスの同時ロードによるパフォーマンスの向上

トリガーまたは整合性制約の問題があっても、より高速なロードを実現する場合は、従来型パスによる同時ロードの使用を考えてください。つまり、複数CPUシステムで同時に複数のセッションでロードを実行します。入力データ・ファイルを論理レコードの境界で別々のファイルに分割し、それらの各入力データ・ファイルを従来型パス・ロード・セッションでロードします。このロードには、次のような特長があります。

- 複数CPUシステムでの単一従来型パス・ロードよりは速くなりますが、ダイレクト・ロードほど速くはありません。

- トリガーが起動されて整合性制約がロードされた行に適用され、標準DML実行ロジックによって索引がメンテナンスされます。

パラレル・データ・ロード・モデル

この項では、データのロードに必要な所要時間を最小限にするために使用される、同時処理の3つの基本モデルについて説明します。

- 従来型パスによる同時ロード

- ダイレクト・パス・ロードによるセグメント間同時処理

- ダイレクト・パス・ロードによるセグメント内同時処理

従来型パスによる同時ロード

同時に複数の従来型パス・ロード・セッションを実行する方法の詳細は、「従来型パスの同時ロードによるパフォーマンスの向上」を参照してください。同一または異なるオブジェクトを制限なしで同時にロードする場合に、この方法を使用できます。

ダイレクト・パスによるセグメント間同時処理

セグメント間同時処理は、異なるオブジェクトを同時にロードする場合に使用できます。この方法は、異なる表の同時ダイレクト・パス・ロード、または同じ表の異なるパーティションの同時ダイレクト・パス・ロードに適用できます。

1つのパーティションのダイレクト・パス・ロードを行う場合は、次のことを考慮します。

- ローカル索引は、ロードによってメンテナンスされます。

- グローバル索引は、ロードではメンテナンスできません。

- 参照整合性およびCHECK制約は使用禁止にする必要があります。

- トリガーは使用禁止にする必要があります。

- 入力データは事前にパーティション化する必要があります(パーティション化しない場合、多くのレコードが拒否され、パフォーマンスが低下します。)

ダイレクト・パスによるセグメント内同時処理

SQL*Loaderでは、複数のセッションを同時に実行して、同一の表またはパーティション表の同一パーティションに対してダイレクト・パス・ロードを実行できます。複数のSQL*Loaderセッションを実行すると、システムで使用可能なリソースを与えられればダイレクト・パス・ロードのパフォーマンスが向上します。

このデータ・ロード方法は、DIRECTおよびPARALLELパラメータにTRUEを設定することによって使用でき、「パラレル・ダイレクト・パス・ロード」とも呼ばれます。

並列化はユーザーによって管理されるものだということを理解しておいてください。PARALLELパラメータにTRUEを設定した場合、複数の同時ダイレクト・パス・ロード・セッションのみが可能になります。

パラレル・ダイレクト・パス・ロードの制限

パラレル・ダイレクト・パス・ロードには次の制限があります。

- ローカル索引もグローバル索引もロードによってメンテナンスできません。

- 行は追加(APPEND)のみできます。REPLACE、TRUNCATEおよびINSERTは使用できません(これは、個別のロードの間には整合性がないためです)。パラレル・ロードの前に表を切り捨てる必要がある場合は、手動で行ってください。

さらに、パラレル・ダイレクト・パス・ロードでは次のオブジェクトを使用禁止にする必要があります。これらを使用禁止にするための操作は不要です。SQL*Loaderではロードの開始前にこれらを使用禁止にし、ロードの完了後にこれらを使用可能に戻します。

- 参照整合性制約

- トリガー

- CHECK制約(ENABLE_CHECK_CONSTRAINTS制御ファイル・オプションが使用される場合を除く)

1つのパーティションのパラレル・ダイレクト・パス・ロードを行う場合は、まず、データをパーティション化してください(そうしない場合は、パーティション不一致によるレコード拒否のオーバーへッドのため、ロード速度が遅くなります)。

複数のSQL*Loaderセッションの初期化

入力元となるデータ・ファイルは、SQL*Loaderセッションごとに異なります。同じ表にダイレクト・ロードを実行するセッションすべてに対して、PARALLEL句にTRUEを設定する必要があります。構文は次のとおりです。

PARALLELは、コマンドラインまたはパラメータ・ファイルに指定できます。また、OPTIONS句を使用して制御ファイルに指定することもできます。

たとえば、1つの表について3つのSQL*Loaderダイレクト・パス・ロード・セッションを開始するには、オペレーティング・システムのプロンプトで、次の各コマンドを実行します。コマンドをそれぞれ入力した後に、パスワードを入力するように要求されます。

sqlldr USERID=scott CONTROL=load1.ctl DIRECT=TRUE PARALLEL=TRUE
sqlldr USERID=scott CONTROL=load2.ctl DIRECT=TRUE PARALLEL=TRUE
sqlldr USERID=scott CONTROL=load3.ctl DIRECT=TRUE PARALLEL=TRUE

このコマンドは、別々のセッションで実行するか、またはオペレーティング・システムがサポートしている場合には別々のバックグラウンド・ジョブとして実行してください。複数の制御ファイルを使用していることに注意してください。そうすることによって、ダイレクト・パス・ロードで使用するファイルをより柔軟に指定できます。

注意:

パラレル・ロード時には、索引はメンテナンスされません。ロード完了後に、索引をすべて手動で(再)作成または再構築する必要があります。パラレル・ロード後に大きな索引を構築する場合、パラレル索引作成機能またはパラレル索引再構築機能を使用すると処理を高速化できます。

PARALLEL句を使用してロードを実行すると、SQL*Loaderによって同時実行セッションごとに一時セグメントが作成されます。それらの一時セグメントは、ロード完了時に マージされます。マージによって作成されたセグメントは、セグメントの最高水位標より上にあるデータベースの既存のセグメントに追加されます。各ローダー・セッションの各セグメントで使用された最後のエクステントは、空き領域をすべて切り捨ててから、SQL*Loaderセッションの他のエクステントと組み合せることができます。

パラレル・ダイレクト・パス・ロードのパラメータ

パラレル・ダイレクト・パス・ロードを実行する場合、ローダーによって割り当てられる一時セグメントの属性を指定してできるオプションがあります。これらのオプションは、FILEおよびSTORAGEパラメータを使用して指定します。これらのパラメータはパラレル・ロードに対してのみ有効です。

FILEパラメータを使用した一時セグメントの指定

最大の入出力スループットを得るために、同時実行のダイレクト・パス・ロード・セッションで、各ファイルを別のディスクに置いて使用することをお薦めします。SQL*Loader制御ファイルでは、ロードされるオブジェクト(表またはパーティション)の表領域にある有効なデータ・ファイルであれば、OPTIONS句のFILEパラメータを使用してファイル名を指定できます。

次に例を示します。

LOAD DATA
INFILE 'load1.dat'
INSERT INTO TABLE emp
OPTIONS(FILE='/dat/data1.dat')
(empno POSITION(01:04) INTEGER EXTERNAL NULLIF empno=BLANKS
...

同時実行する各SQL*Loaderセッションのコマンドラインでも、FILEパラメータを指定できます。ただし、その指定は、そのセッションでロードされるすべてのオブジェクトにグローバルに適用されます。

FILEパラメータの使用

パラレル・ダイレクト・パス・ロードでは、Oracle DatabaseのFILEパラメータに次の制限があります。

- 非パーティション表の場合: 指定されたファイルは、ロードする表と同じ表領域に存在する必要があります。

- パーティション表の1つのパーティションをロードする場合: 指定したファイルは、ロードするパーティションの表領域に存在する必要があります。

- パーティション表の表全体をロードする場合: 指定されたファイルは、ロードするすべてのパーティションと同じ表領域に存在する必要があります。つまり、すべてのパーティションは同じ表領域に存在する必要があります。

STORAGEパラメータの使用方法

STORAGEパラメータを使用して、パラレル・ダイレクト・パス・ロード用に割り当てられる一時セグメントの記憶域属性を指定できます。STORAGEパラメータが使用されない場合は、ロードされるオブジェクト(表、パーティション)が存在するセグメントの記憶域属性が使用されます。また、STORAGEパラメータが指定されてない場合は、SQL*LoaderでEXTENTS用にデフォルトの2KBが使用されます。

たとえば、STORAGEパラメータを指定するためには、次のOPTIONS句が使用されます。

OPTIONS (STORAGE=(INITIAL 100M NEXT 100M PCTINCREASE 0))

STORAGEパラメータを使用できるのは、SQL*Loader制御ファイル内のみでコマンドラインでは使用できません。STORAGEパラメータは、PCTINCREASEを0(ゼロ)に設定する、INITIALまたはNEXT値を設定する以外には、使用しないでください。暗黙的に無視される可能性があります。

パラレル・ダイレクト・パス・ロード後の制約の使用可能化

すべてのデータのロード完了後に、制約およびトリガーを手動で使用可能にしてください。

それぞれのSQL*Loaderセッションで、ダイレクト・パス・ロードの後に表の制約が使用可能に戻されることがあるため、あるセッションで、他のセッションがデータのロードを終える前に、制約が使用可能に戻される可能性があります。この場合、ロードを完了する最初のセッションでは、残りのセッションで表のロックが共有されているため、制約を使用可能にできなくなります。

ダイレクト・パス・ロードの後、一部の制約が使用可能に戻っていない可能性があるため、ロードの完了後、制約の状態を調べ、制約が使用可能になったことを確認する必要があります。

主キー制約および一意制約

PRIMARY KEY制約およびUNIQUE KEY制約が有効である場合、表に索引が作成されます。表が非常に大きい場合は、ダイレクト・パス・ロード後に索引を使用可能にするまでに非常に長い時間がかかる可能性があります。ロード後に、これらの制約を手動で有効にしてください(また、自動で有効にする機能を指定しないでください)。これによって、必要な索引をパラレルに手動で作成し、制約を有効にするまでの時間を節約できます。

一般的なパフォーマンス改善のヒント

ロードするデータの形式について制御が可能な場合は、次に示すヒントを利用してロード・パフォーマンスを改善できます。

- 論理レコードの処理を効率化します。

- 物理レコードと論理レコードの1対1のマップを使用します(CONTINUEIFおよびCONCATENATEを使用しない)。

- ソフトウェアで物理レコードの境界を簡単に判断できるようにします。ファイル処理オプション文字列「FIX nnn」または「VAR」を使用します。ほとんどのプラットフォーム(UNIX、NTなど)では、デフォルト(ストリーム・モード)を使用する場合、ローダーで各物理レコードをスキャンしてレコード終了記号(改行文字)を探す必要があります。

- フィールド設定を効率化します。フィールド設定とは、データ・ファイルのフィールドを、ロードされる表の対応する列にマップする処理です。マップ機能は、制御ファイルのフィールド記述によって制御されます。フィールド設定は(データ変換とともに)、ほとんどのロードでCPUサイクルを最も使用する処理です。

- デリミタ付きのフィールドを使用しないようにします。固定位置のフィールドを使用します。デリミタ付きフィールドを使用すると、ローダーで入力データをスキャンしてデリミタを見つけなければなりません。固定位置フィールドを使用すると、フィールド設定は単純なポインタの算出によって(非常に速く)行われます。

- (PRESERVE BLANKSを使用する)必要がない場合は、空白を切り捨てないでください。

- 変換を効率化します。SQL*Loaderでは、キャラクタ・セット変換、データ型変換などのいくつかの変換が行われます。このような変換が行われない場合、処理は最も速くなります。

- 可能な場合は、シングルバイト・キャラクタ・セットを使用します。

- キャラクタ・セット変換はできるだけ行わないようにします。SQL*Loaderでは、次の4つのキャラクタ・セットがサポートされています。

- クライアント・キャラクタ・セット(クライアントsqlldrプロセスのNLS_LANG)

- データ・ファイル・キャラクタ・セット(通常、クライアント・キャラクタ・セットと同じ)

- データベース・キャラクタ・セット

- データベース・キャラクタ・セット

すべてのキャラクタ・セットが同じ場合、パフォーマンスは最適化されます。ダイレクト・パスでは、データ・ファイル・キャラクタ・セットとデータベース・サーバー・キャラクタ・セットが同じである場合、最適なパフォーマンスが得られます。キャラクタ・セットが同じ場合、キャラクタ・セット変換用バッファは割り当てられません。

- ダイレクト・パス・ロードを使用します。

- SORTED INDEXS句を使用します。

- NULLIF句およびDEFAULTIF句は必要な場合以外は使用しないようにします。これらの句は、関連する句を持つ各列にロードされるすべての行について、評価される必要があります。

- 可能な場合は、パラレル・ダイレクト・パス・ロードおよびパラレル索引作成を使用します。

- CONCATENATE句およびCOLUMNARRAYROWS句の両方に大きい値を指定する場合は、パフォーマンスへの影響に注意します。詳細は、「CONCATENATEを使用した論理レコードの作成」を参照してください。

13 SQL*Loaderエクスプレス

SQL*Loaderエクスプレス・モードでは、SQL*Loaderを使用して単純なデータ型を迅速かつ簡単にロードできます。

ここでは、次の項目について説明します。

- SQL*Loaderエクスプレス・モードとは

- SQL*Loaderエクスプレス・モードの使用方法

- SQL*Loaderエクスプレス・モードのパラメータ・リファレンス

- SQL*Loaderエクスプレス・モードの構文図

SQL*Loaderエクスプレス・モードとは

SQL*Loaderエクスプレス・モードでは、表の列がすべて文字、数値または日時データ型で、入力データ・ファイルにデリミタ付き文字データのみが含まれる場合、表名のみを指定することで迅速にロードを実行できます。

エクスプレス・モードでは、SQL*Loader制御ファイルは使用されません。かわりに、SQL*Loaderでは、ALL_TAB_COLUMNSビューにある表の列定義を使用して入力フィールドの順序とデータ型を判別します。他のほとんどの設定については、デフォルト値が想定されますが、これはコマンドライン・パラメータで上書きできます。

注意:

SQL*Loaderエクスプレス・モードで使用できる有効なパラメータは、この章で説明しているパラメータのみです。他の任意のパラメータは、無視されるか、状況によってはエラーの原因となります。

SQL*Loaderエクスプレス・モードの使用方法

SQL*Loaderエクスプレス・モードをアクティブ化するには、ユーザー名と表名を指定するだけです。次のように、SQL*Loaderによってパスワードの入力を要求されます。

> sqlldr username TABLE=employees
Password:
.
.
.

SQL*Loader: Release 12.1.0.1.0 - Production on Thu Jan 3 12:57:05 2013

Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

Express Mode Load, Table: EMPLOYEES
.
.
.

TABLEパラメータのみを指定してSQL*Loaderエクスプレス・モードをアクティブ化すると、他の複数のパラメータにはデフォルト設定が使用されます。ほとんどのデフォルト値は、コマンドラインで追加パラメータを指定して上書きできます。

SQL*Loaderエクスプレス・モードでは、SQL*Loader制御ファイルを含むログ・ファイルが生成されます。ログ・ファイルには、外部表を作成し、SQL INSERT AS SELECT文を使用してロードを実行するためのSQLスクリプトも含まれます。制御ファイルもSQLスクリプトもSQL*Loaderエクスプレス・モードでは使用されません。これらは、通常のSQL*Loaderまたはスタンドアロンの外部表を使用して操作を実行する場合の開始ポイントとして使用できます(制御ファイルはSQL*Loaderで使用し、SQLスクリプトはスタンドアロンの外部表の操作で使用します)。

関連項目:

- 「SQL*Loaderエクスプレス・モードのパラメータ・リファレンス」

- 制御ファイルの詳細は、「SQL*Loader制御ファイル・リファレンス」を参照してください

SQL*Loaderエクスプレス・モードで使用されるデフォルト値

デフォルトでは、特に指定しないかぎり、SQL*Loaderエクスプレス・モードを使用して実行されるロードでは次のように想定されます。

- データ・ファイルを指定しない場合、カレント・ディレクトリでtable-name.datというファイルが検索されます。

- 外部表はロード方法です。一部のエラーでは、SQL*Loaderエクスプレス・モードによって、デフォルトの外部表のロード方法からダイレクト・パス・ロードに自動的に切り替えられます。これが発生する可能性のある例として、権限違反が原因でCREATE DIRECTORY SQLコマンドが失敗した場合があげられます。

- フィールドは次の要素を使用して設定されます。

- 表の列名に基づく名前(フィールドの順序は表の列の順序に一致)

- 表の列型に基づく型

- 改行(レコード・デリミタとして)

- カンマ(フィールド・デリミタとして)

- 囲みなし

- 左右切捨て

- DEGREE_OF_PARALLELISMパラメータはAUTOに設定されます。

- 日付およびタイムスタンプの書式ではNLS設定が使用されます。

- NLSクライアント・キャラクタ・セットが使用されます。

- 表にデータがすでに含まれる場合、新しいデータは表に追加されます。

- データ・ファイルが指定されていない場合、データ・ファイル、ログ・ファイルおよび不良ファイルのデフォルト名は次のようになります。(%pは、Oracle Databaseスレーブ・プロセスのプロセスIDで置き換えられます。)

- table-name.dat (データ・ファイル)

- table-name.log (SQL*Loaderログ・ファイル)

- table-name_%p.log_xt (Oracle Databaseログ・ファイル。emp_17228.log_xtなど)

- table-name_%p.bad (不良ファイル)

- 1つ以上のデータ・ファイルが(DATAパラメータを使用して)指定されている場合、ログ・ファイルと不良ファイルのデフォルト名は次のようになります。(%pは、サーバー・スレーブ・プロセスのプロセスIDで置き換えられます。)

- table-name.log (SQL*Loaderログ・ファイル)

- table-name_%p.log_xt (Oracle Databaseログ・ファイル)

- first-data-file_%p.bad (不良ファイル)

関連項目:

- 「DATA」パラメータ

SQL*Loaderエクスプレス・モードによるバイト順序の処理方法

一般的に、SQL*Loaderエクスプレス・モードでは、SQL*Loader制御ファイルを使用して実行されるロードと同じ方法でバイト順序マークが処理されます。 まとめると、次のようになります。

- Unicodeキャラクタ・セットを含むデータ・ファイルでは、SQL*Loaderエクスプレス・モードによってファイルの先頭にあるバイト順序マークが確認されます。

- UTF16データ・ファイルでは、バイト順序マークが見つかると、バイト順序マークによってデータ・ファイルのバイト順序が設定されます。バイト順序マークが見つからない場合、SQL*Loaderが実行されているシステムのバイト順序がデータ・ファイルで使用されます。

- UTF16データ・ファイルは、バイト順序(エンディアン)が、SQL*Loaderエクスプレスが実行されているシステムと同じバイト順序であるかどうかにかかわらず、ロードできます。

- UTF8データ・ファイルでは、どのバイト順序マークが見つかってもスキップされます。

- 複数のデータ・ファイルが関与し、それらが異なるバイト順序を使用している場合、ロードは中断されます。

関連項目:

- SQL*Loaderがデータ・ファイルでバイト順序を処理する方法の詳細は、「バイト順序」を参照してください

SQL*Loaderエクスプレス・モードのパラメータ・リファレンス

この項では、SQL*Loaderエクスプレス・モードで使用できるパラメータについて説明します。一部のパラメータの名前は通常のSQL*Loaderで使用されるパラメータと同じですが、動作が異なる場合があります。説明をよく読んで、想定される動作を確認してください。

注意:

パラメータ値に引用符が含まれる場合、それらはパラメータ・ファイルで指定することをお薦めします。SQL*Loaderエクスプレス・モードにも関係する問題が説明されているため、「データ・ポンプ・コマンドラインでの引用符の使用」を参照してください。

BAD

デフォルト: デフォルトは、(DATAパラメータを使用して)データ・ファイルが指定されているかどうかによって異なります。詳細は、「SQL*Loaderエクスプレス・モードで使用されるデフォルト値」を参照してください。

用途

BADパラメータでは、不良ファイルの場所と名前を指定します。

構文および説明

BAD=[directory/][filename]

不良ファイルには、挿入時にエラーの原因になったレコードや、不適切に書式化されたレコードが格納されます。BADパラメータを指定する場合、ディレクトリまたはファイル名(あるいはその両方)を指定する必要があります。BADパラメータを指定しない場合に、拒否レコードが存在すると、デフォルトのファイル名が使用されます。

directory変数には、不良ファイルの書込み先となるディレクトリを指定します。指定には、デバイスまたはネットワーク・ノードの名前を含めることができます。

filename変数には、プラットフォームで有効とみなされるファイル名を指定します。名前(および.bad以外のものを使用する場合は拡張子)のみを指定する必要があります。ファイル名に空白やその他の句読点文字が含まれている場合は、一重引用符で囲む必要があります。

directoryおよびfilenameの値は、次のように決定されます。

- BADパラメータでファイル名が指定されているが、ディレクトリがない場合、ディレクトリはデフォルトでカレント・ディレクトリになります。

- BADパラメータでディレクトリが指定されているが、ファイル名がない場合、指定されたディレクトリが使用され、ファイル名と拡張子にはデフォルトが使用されます。

BADパラメータは、指定されているDATAパラメータ(指定がある場合)に一致するすべてのファイルに適用されます。DATAパラメータが指定されていない場合、1つのデータ・ファイル(table-name.dat)に適用されます。

制限事項

注意:

- (デフォルトまたは指定した名前の)ファイルがすでに存在する場合、使用しているオペレーティング・システムに応じて、既存ファイルが上書きされるか、新しいバージョンのファイルが生成されます。

- 複数のデータ・ファイルがロードされる状況では、BADパラメータを指定しないか、または不良ファイルのディレクトリのみを指定することをお薦めします。

例

次の指定では、カレント・ディレクトリにemp1.badという不良ファイルを作成します。

> sqlldr hr TABLE=employees BAD=emp1

CHARACTERSET

デフォルト: 環境変数NLS_LANGで指定されたNLSクライアント・キャラクタ・セット

用途

CHARACTERSETパラメータでは、ロードに使用するデフォルト以外のキャラクタ・セットを指定します。

構文および説明

CHARACTERSET=character_set_name

CHARACTERSETパラメータでは、SQL*Loaderの入力データ・ファイルのキャラクタ・セットを指定します。CHARACTERSETパラメータが指定されていない場合、すべてのデータ・ファイルに対するデフォルトのキャラクタ・セットは、環境変数NLS_LANGで定義されたセッション・キャラクタ・セットです。文字データ(SQL*Loaderデータ型のCHAR、VARCHAR、VARCHARC、数値型EXTERNALおよび日時データ型と期間データ型のフィールド)のみが、データ・ファイルのキャラクタ・セットに影響されます。

character_set_name変数で、キャラクタ・セット名を指定します。通常、指定された名前は、Oracle Databaseがサポートしているキャラクタ・セットの名前である必要があります。

UnicodeのUTF-16エンコーディングの場合は、名前はAL16UTF16でなくUTF16を使用します。AL16UTF16 (UTF-16エンコードされたデータに対してサポートされるキャラクタ・セット名)は、ビッグ・エンディアンのバイト順序のUTF-16データにのみ使用されます。ただし、データ・ファイルを作成したシステムのバイト順序を使用してデータを設定することが許可されているため、データ・ファイル内のデータはビッグ・エンディアンまたはリトル・エンディアンのいずれかにできます。このため、異なるキャラクタ・セット名(UTF16)が使用されます。また、キャラクタ・セット名AL16UTF16もサポートされています。ただし、リトル・エンディアンのバイト順序のデータ・ファイルにAL16UTF16を指定すると、SQL*Loaderによって警告メッセージが発行され、データ・ファイルはリトル・エンディアンとして処理されます。

CHARACTERSETパラメータ値は、すべてのデータ・ファイルで同じであるとみなされます。

注意:

UTF-16という用語は、一般的にUnicodeのUTF-16エンコーディングを意味します。UTF16(ハイフンなし)という用語は、キャラクタ・セットの固有の名前で、UTF-16エンコーディングの使用時にCHARACTERSETパラメータに指定する必要のある用語です。UTF-8およびUTF8の場合も同様です。

制限事項

- 「なし」

例

次の例では、UTF-8のキャラクタ・セットを指定します。

> sqlldr hr TABLE=employees CHARACTERSETNAME=utf8

CSV

デフォルト: コマンドラインでCSVパラメータを指定しない場合、SQL*Loaderエクスプレスでは、ロードされるCSVファイルに埋込み文字や囲み文字を含まないデータが存在するものと想定されます。

コマンドラインでCSV=WITHOUT_EMBEDDEDを指定する場合、SQL*Loaderエクスプレスでは、ロードされるCSVファイルに埋込み文字を含まないデータと、オプションで「"」に囲まれたデータが存在するものと想定されます。

用途

CSVパラメータによって、ロードされるカンマ区切り値(CSV)形式のファイルにレコード終了記号の埋込みフィールドが含まれるかどうかを指定するオプションが提供されます。

構文および説明

CSV=[WITH_EMBEDDED | WITHOUT_EMBEDDED]

このパラメータの有効なオプションは次のとおりです。

- WITH_EMBEDDED: このオプションは、レコードのフィールドにレコード終了記号が含まれる(埋め込まれている)場合があることを示します。レコード終了記号は改行です。デフォルトのデリミタは、TERMINTATED BY ","およびOPTIONALLY_ENCLOSED_BY '"'です。埋込みのレコード終了記号は囲む必要があります。
CSVファイルに埋込みのレコード終了記号が多く含まれると、パフォーマンスが低下する可能性があります。

- WITHOUT_EMBEDDED: このオプションは、レコードのフィールドにレコード終了記号が含まれない(埋め込まれていない)ことを示します。レコード終了記号は改行です。デフォルトのデリミタは、TERMINTATED BY ","およびOPTIONALLY_ENCLOSED_BY ' " 'です。

制限事項

- 通常、ファイルはパラレルに処理できます(同時に複数の実行サーバーによって分割および処理されます)。ただし、埋込みのレコード終了記号を含むCSV形式のファイルの場合、そのファイルはただ1つの実行サーバーによって処理される必要があります。したがって、データ・ファイル内のパラレル処理は、CSV=WITH_EMBEDDEDの場合は無効になります。

例

次の例では、埋込みのレコード終了記号を含むCSV形式のファイルとしてデータ・ファイルを処理します。

> sqlldr hr TABLE=employees CSV=WITH_EMBEDDED

DATA

デフォルト: 表名と同じ名前ですが、拡張子は.datになります。

用途

DATAパラメータでは、ロードするデータが含まれるデータ・ファイルの名前を指定します。

構文および説明

DATA=data-file-name

ファイル拡張子を指定しない場合、デフォルトで.datになります。

ファイルの指定にはワイルド・カード(ファイル名およびファイル拡張子にのみ可能で、デバイスまたはディレクトリ名には不可)を含めることができます。アスタリスク(*)は複数文字を表し、疑問符(?)は1文字を表します。次に例を示します。

DATA='emp*.dat'

DATA='m?emp.dat'

複数のデータ・ファイルの指定(それぞれにワイルド・カードを含めることが可能)をリストするには、ファイル名をカンマで区切る必要があります。

ファイル名に任意の特殊文字(空白、*、?など)が含まれる場合、名前全体を一重引用符で囲む必要があります。

次に、DATAパラメータの有効な3つの使用例を示します(ファイル名に特殊文字が含まれる場合のみ、一重引用符が必要です)。

DATA='file1','file2','file3','file4','file5','file6'

DATA='file1','file2'
DATA='file3,'file4','file5'
DATA='file6'

DATA='file1'
DATA='file2'
DATA='file3'
DATA='file4'
DATA='file5'
DATA='file6'

制限事項

注意:

複数のデータ・ファイルがロードされる状況でBADパラメータも指定する場合、ファイル名ではなく、不良ファイルのディレクトリのみを指定することをお薦めします。指定した名前を持つファイルがすでに存在する場合、使用しているオペレーティング・システムに応じて、既存ファイルが上書きされるか、新しいバージョンのファイルが生成されます。

例

カレント・ディレクトリにemp1.dat、emp2.dat、m1emp.datおよびm2emp.datという名前のデータ・ファイルが含まれている状態で、次のコマンドを発行するとします。

> sqlldr hr TABLE=employees DATA='emp*','m1emp'

コマンドによって、ファイルemp1.dat、emp2.datおよびm1emp.datがロードされます。ファイルm2emp.datは、どのワイルドカード基準にも一致しないため、ロードされません。

DATE_FORMAT

デフォルト: DATE_FORMATパラメータが指定されていない場合、環境変数NLS_DATE_FORMAT、NLS_LANGUAGEまたはNLS_DATE_LANGUAGEの設定が使用されます(SQL*Loaderセッションに対して定義されている場合)。NLS_DATE_FORMATが定義されていない場合、日付は、NLS_TERRITORYの設定によって定義されるデフォルト書式であるとみなされます。

用途

DATE_FORMATパラメータでは、すべての日付フィールドのデフォルト値に優先する日付書式を指定します。

構文および説明

DATE_FORMAT=mask

maskは、通常は二重引用符で囲まれる日付書式マスクです。

制限事項

- 「なし」

例

データ・ファイルの日付が17-March-2012である場合、日付書式は次のように指定します。

> sqlldr hr TABLE=employees DATE_FORMAT="DD-Month-YYYY"

DEGREE_OF_PARALLELISM

デフォルト: AUTO

用途

DEGREE_OF_PARALLELISMパラメータでは、ロードで使用する並列度を指定します。

構文および説明

DEGREE_OF_PARALLELISM=[degree-num|DEFAULT|AUTO|NONE]

degree-numを指定する場合、1からnの整数値にする必要があります。

DEFAULTを指定すると、(AUTOのデフォルト・パラメータ値ではなく)データベースのデフォルトの並列度が使用されます。

AUTOを使用すると、Oracle Databaseによってロードの並列度が自動的に設定されます。DEGREE_OF_PARALLELISMパラメータが指定されていない場合、これがデフォルトになります。

NONEを指定すると、ロードはパラレルに実行されません。値NONEは、値1と同じです。

関連項目:

- パラレル実行の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

制限事項

- DEGREE_OF_PARALLELISMパラメータは、従来型パスまたはダイレクト・パスのロード方法を強制的に実行する場合は無視されます(NONEオプションが使用されます)。どの値でDEGREE_OF_PARALLELISMパラメータを指定しても、常にこの内容を示すメッセージが表示されます。

- ロードがデフォルトの外部表ロードで、SQL*Loaderエクスプレス・モードでかわりにダイレクト・パス・ロードを使用することになるエラーが発生した場合、並列度を指定したり、AUTOで外部表のデフォルトを受け入れていても、ジョブはパラレルに実行されません。この変更を示すアラート・メッセージが表示されます。

例

次の例では、並列度を使用せずにデータをロードします。

> sqlldr hr TABLE=employees DEGREE_OF_PARALLELISM=NONE

DIRECT

デフォルト: FALSE

用途

DIRECTパラメータでは、従来型パスまたはダイレクト・パスのどちらのロード方法を使用するかを指定します。

構文および説明

DIRECT=[TRUE|FALSE]

TRUE値はダイレクト・パス・ロードを指定します。FALSE値は従来型パス・ロードを指定します。

このパラメータは、SQL*Loaderエクスプレス・モードによって使用される外部表のデフォルトのロード方法に優先します。

一部のエラーでは、SQL*Loaderエクスプレス・モードによって、デフォルトの外部表のロード方法からダイレクト・パス・ロードに自動的に切り替えられます。これが発生する可能性のある例として、権限違反が原因でCREATE DIRECTORY SQLコマンドが失敗した場合があげられます。

DIRECTパラメータを使用し、従来型パス・ロードまたはダイレクト・パス・ロードを指定する場合、次の標準のSQL*Loaderパラメータをエクスプレス・モードで使用できます。

- BINDSIZE

- COLUMNARRAYROWS (ダイレクト・パス・ロードのみ)

- DATA_CACHE

- ERRORS

- MULTITHREADING (ダイレクト・パス・ロードのみ)

- NO_INDEX_ERRORS (ダイレクト・パス・ロードのみ)

- RESUMABLE

- RESUMABLE_NAME

- RESUMABLE_TIMEOUT

- ROWS

- SKIP

- STREAMSIZE

制限事項

- 「なし」

例

次の例では、SQL*Loaderは、ロードで外部表のかわりにダイレクト・パス・ロード方法を使用します。

> sqlldr hr TABLE=employees DIRECT=TRUE

DNFS_ENABLE

デフォルト: TRUE

用途

DNFS_ENABLEパラメータでは、SQL*Loader操作中の入力データ・ファイルに対するDirect NFSクライアントの使用を有効化および無効化できます。

Direct NFSクライアントは、Oracleがファイル・サーバー上のファイルにアクセスする際のパフォーマンスを向上するために、ファイル・サーバーで実装できるAPIです。

構文および説明

構文は次のとおりです:

DNFS_ENABLE=[TRUE|FALSE]

SQL*Loaderでは、1GBを超えるデータ・ファイルを読み取る場合にデフォルトでDirect NFSクライアント・インタフェースが使用されます。よりサイズの小さいファイルでは、オペレーティング・システムのI/Oインタフェースが使用されます。すべての入力データ・ファイルでDirect NFSクライアントを使用するには、DNFS_ENABLE=TRUEを使用します。

すべてのデータ・ファイルでDirect NFSクライアントの使用を無効にするには、DNFS_ENABLE=FALSEを指定します。

DNFS_ENABLEパラメータをDNFS_READBUFFERSパラメータと組み合せて使用すると、Direct NFSクライアントによって使用される読取りバッファの数を指定できます。

関連項目:

- NFSでDirect NFSクライアントのOracle Disk Manager Controlを有効化する方法の詳細は、使用しているプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

DNFS_READBUFFERS

デフォルト: 4

用途

DNFS_READBUFFERSパラメータでは、Direct NFSクライアントによって使用される読取りバッファの数を制御できます。Direct NFSクライアントは、Oracleがファイル・サーバー上のファイルにアクセスする際のパフォーマンスを向上するために、ファイル・サーバーで実装できるAPIです。

構文および説明

構文は次のとおりです:

DNFS_READBUFFERS = n

デフォルトより大きい値を使用すると、Direct NFSクライアント・ファイル・サーバーからの一貫性のないI/Oに対処できますが、メモリー使用量が増大する可能性があります。

DNFS_ENABLEパラメータを同時に指定せずにこのパラメータを使用するには、入力ファイルが1GBを超えている必要があります。

関連項目:

- NFSでDirect NFSクライアントのOracle Disk Manager Controlを有効化する方法の詳細は、使用しているプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

ENCLOSED_BY

デフォルト: デフォルトは、囲み文字なしです。

用途

ENCLOSED_BYパラメータでは、フィールドの囲み文字を指定します。

構文および説明

ENCLOSED_BY=['char'|x'hex-char']

囲み文字は単一の文字である必要があります。これには、16進表記を使用できます。

制限事項

- 同じ文字を使用して囲み文字の最初と最後の両方を示す必要があります。

例

次の例では、フィールド・データは「/」文字(フォワード・スラッシュ)で囲まれます。

> sqlldr hr TABLE=employees ENCLOSED_BY='/'

EXTERNAL_TABLE

デフォルト: EXECUTE

用途

EXTERNAL_TABLEパラメータは、外部表オプションを使用してデータをロードするかどうかをSQL*Loaderに指定します。

構文および説明

EXTERNAL_TABLE=[NOT_USED | GENERATE_ONLY | EXECUTE]

次の3つの値を指定できます。

- NOT_USED: デフォルト値。従来型パス・モードまたはダイレクト・パス・モードのいずれかを使用して、ロードを行います。

- GENERATE_ONLY: SQL*Loaderログ・ファイル内の外部表を使用してロードを行うために必要なすべてのSQL文を書き込みます。これらのSQL文は、編集およびカスタマイズできます。実際のロードは、SQL*Loaderを使用せずに、SQL*Plusでこれらの文を実行して、後で行うことができます。

- EXECUTE: 外部表を使用してロードを行うために必要なSQL文を実行します。ただし、SQL文からエラーが返されると、ロードは停止します。SQL文は、実行されたとおりログ・ファイルに書き込まれます。つまり、SQL文からエラーが返されると、ロードに必要な残りのSQL文はログ・ファイルには書き込まれません。

外部表オプションで、データベース内のディレクトリ・オブジェクトを使用して、すべてのデータ・ファイルがどこに格納されるか、および出力ファイル(不良ファイルや廃棄ファイルなど)がどこで作成されるかを指定します。データ・ファイルを含むディレクトリ・オブジェクトには、READアクセスが、出力ファイルが作成されるディレクトリ・オブジェクトには、WRITEアクセスが必要です。データ・ファイルまたは出力ファイル格納用の既存のディレクトリ・オブジェクトがない場合は、SQL*LoaderでSQL文を生成して作成します。したがって、EXECUTEオプションを指定する場合は、CREATE ANY DIRECTORY権限が必要です。ロード処理の最後にディレクトリ・オブジェクトを削除する場合は、DROP ANY DIRECTORY権限も必要です。

注意:

SQL*LoaderでEXTERNAL_TABLE=EXECUTE修飾子を指定すると、データのロードに使用可能な外部表が作成された後、INSERT文が実行され、データがロードされます。外部表のすべてのファイルがディレクトリ・オブジェクト内に存在すると識別される必要があります。SQL*Loaderは、ユーザーがアクセス権限を所有している既存のディレクトリ・オブジェクトを使用します。ただし、SQL*Loaderにより一致するディレクトリ・オブジェクトが検出されない場合は、一時ディレクトリ・オブジェクトの作成が試行されます。新しいディレクトリ・オブジェクトを作成する権限を所有していない場合、この操作は正常に実行されません。

この問題を解決するには、EXTERNAL_TABLE=GENERATE_ONLYを使用して、SQL*Loaderで実行が試行されるSQL文を作成します。これらのSQL文を抽出し、参照するディレクトリ・オブジェクトを、アクセス権限を所有しているディレクトリ・オブジェクトに変更します。その後、これらのSQL文を実行します。

制限事項

- 「なし」

例

sqlldr hr TABLE=employees EXTERNAL_TABLE=NOT_USED

FIELD_NAMES

デフォルト: NONE

用途

FIELD_NAMESパラメータを使用して、データベース表の列の順序に従っているフィールドを上書きします。(デフォルトで、SQL*Loaderでは、ALL_TAB_COLUMNSビューにある表の列定義を使用して入力フィールドの順序とデータ型を判別します。)

このパラメータが役に立つ場合の例は、入力ファイルのデータが表の列と同じ順序になっていない場合です。このような場合、データ・ファイルに(表の列ヘッダー行のように)フィールド名のレコードを含め、FIELD_NAMESパラメータを使用して、最初のレコードのフィールド名を処理してフィールドの順序を決定するようにSQL*Loaderに指示できます。

構文および説明

FIELD_NAMES=[ALL | ALL_IGNORE | FIRST | FIRST_IGNORE | NONE]

このパラメータの有効なオプションは次のとおりです。

- ALL: すべてのデータ・ファイルでフィールド名レコードが処理されます。

- ALL_IGNORE: すべてのデータ・ファイルで最初の(フィールド名)レコードを無視し、通常どおりデータ・レコードを処理します。

- FIRST: 最初のデータ・ファイルで最初の(フィールド名)レコードを処理します。他のすべてのデータ・ファイルでは、フィールド名レコードがないため、データ・ファイルは通常どおり処理されます。

- FIRST_IGNORE: 最初のデータ・ファイルで最初の(フィールド名)レコードを無視し、フィールド順序として表の列順序を使用します。

- NONE: どのデータ・ファイルにもフィールド名レコードが存在しないため、データ・ファイルは通常どおり処理されます。これはデフォルトです。

制限事項

- フィールド名に大文字と小文字が混在する場合、または空白などの特殊文字が含まれる場合、OPTIONALLY_ENCLOSED_BYパラメータまたはENCLOSED_BYパラメータを使用して、大/小文字を保持することと、特殊文字をフィールド名の一部として含めることを指定します。

例

列ヘッダーを含むCSVファイルを表にロードする際に、入力ファイルの各行のフィールドが表の列と同じ順序である場合、次のようにします。

> sqlldr hr TABLE=employees CSV=WITHOUT_EMBEDDED FIELD_NAMES=FIRST_IGNORE

LOAD

デフォルト: すべてのレコードがロードされます。

用途

LOADパラメータでは、ロード対象のレコード数を指定します。

構文および説明

LOAD=n

ロードに指定したすべてのパラメータが正しく設定されているかどうかをテストする場合、LOADパラメータを使用して、すべてのレコードをロードするかわりに、かぎられた数のレコードを指定できます。実際のレコード件数が指定された最大数より少ない場合、エラーは発生しません。

制限事項

- 「なし」

例

次の例では、最大10個のレコードをロードするように指定します。

> sqlldr hr TABLE=employees LOAD=10

外部表の方法によるロード(エクスプレス・モードのデフォルトのロード方法)では、ロードに成功したレコードのみが合計に加算されます。そのため、ファイルに15個のレコードがあり、レコード2および4が不良の場合、レコード1、3、5、6、7、8、9、10、11および12が合計10個のレコードとして表にロードされます。

従来型パス・ロードとダイレクト・パス・ロードでは、成功と失敗の両方のロード試行が合計に加算されます。そのため、ファイルに15個のレコードがあり、レコード2および4が不良の場合、レコード1、3、5、6、7、8、9および10の8個のみが実際に表にロードされます。

NULLIF

デフォルト: デフォルトでは、NULLIFの確認は行われません。

用途

NULLIFパラメータでは、フィールドをNULL列としてロードするかどうかを決定するために使用する値を指定します。

構文および説明

NULLIF = "string"

または

NULLIF != "string"

SQL*Loaderは、レコードのフィールドの値に基づいて、指定された値を確認します。等号(=)または不等号(!=)の指定を使用して一致した場合、フィールドはその行でNULLに設定されます。空白の切捨て後に長さが0になったフィールドも、すべてNULLに設定されます。

制限事項

- 「なし」

例

次の例では、ピリオドの値が含まれるフィールドが存在する場合、各行でそれらのフィールドをNULLに設定します。

> sqlldr hr TABLE=employees NULLIF="."

OPTIONALLY_ENCLOSED_BY

デフォルト: デフォルトでは、オプションのフィールド囲み文字はありません。

用途

OPTIONALLY_ENCLOSED_BYパラメータでは、オプションのフィールド囲み文字を指定します。

構文および説明

OPTIONALLY_ENCLOSED_BY=['char'| x'hex-char']

囲み文字は単一の文字である必要があります。これには、16進表記を使用できます。

制限事項

- 同じ文字を使用して囲み文字の最初と最後の両方を示す必要があります。

例

次の例では、オプションの囲み文字として二重引用符(")を指定します。パラメータをコマンドラインではなく、パラメータ・ファイルで指定する場合、エスケープ文字のバックスラッシュ(\)は必要ありません。

> sqlldr hr TABLE=employees OPTIONALLY_ENCLOSED_BY='\"'

次の例では、16進形式でオプションの囲み文字を指定します。パラメータをコマンドラインではなく、パラメータ・ファイルで指定する場合、二重引用符は必要ありません。

> sqlldr hr TABLE=employees OPTIONALLY_ENCLOSED_BY="x'22'"

PARFILE

デフォルト: デフォルト値は設定されていません。

用途

PARFILEパラメータは、コマンドラインで頻繁に使用するパラメータを記述したファイルを指定します。

構文および説明

PARFILE=parameter_file_name

パラメータ値に引用符が含まれる場合は、パラメータ・ファイルを使用することをお薦めします。

注意:

通常は問題ありませんが、システムによっては、パラメータ指定の中で等号(=)の前後に空白を挿入できないものもあります。

制限事項

- セキュリティ上の理由から、パラメータ・ファイルにはUSERIDのパスワードを含めないでください。コマンドラインでパラメータ・ファイルを指定した後、SQL*Loaderによってパスワードを入力するように要求されます。次に例を示します。

> sqlldr hr TABLE=employees PARFILE=daily_report.par
Password:

例

次のパラメータ・ファイルtest.parを作成したとします。

table=employees
data='mydata*.dat'
enclosed_by='"'

次のコマンドを実行すると、mydata*.datに一致するデータ・ファイルの二重引用符で囲まれたすべてのフィールドがemployees表にロードされます。

> sqlldr hr PARFILE=test.par
Password:

SILENT

デフォルト: このパラメータが指定されていない場合、内容は抑止されません。

用途

SILENTパラメータは、SQL*Loaderの操作中に画面に書き込まれる内容の一部を抑止します。

構文および説明

構文は次のとおりです:

SILENT={HEADER | FEEDBACK | ERRORS | DISCARDS | PARTITIONS | ALL}

適切な値を使用して、次の1つ以上の内容を抑止します(複数のオプションを指定する場合、カンマで区切る必要があります)。

- HEADER: 画面に通常表示されるSQL*Loaderのヘッダー・メッセージを非表示にします。ただし、ヘッダー・メッセージはログ・ファイルに出力されます。

- FEEDBACK: ロードで画面に通常表示される「commit point reached」メッセージとステータス・メッセージを非表示にします。

- ERRORS: レコードにOracleエラーが発生したためそのレコードが不良ファイルに書き込まれた場合、データ・エラー・メッセージがログ・ファイルに出力されないようにします。ただし、拒否レコード件数は出力されます。

- DISCARDS: レコードが廃棄ファイルに書き込まれた場合に、そのことを示すメッセージがログ・ファイルに出力されないようにします。このオプションは、エクスプレス・モードでは無視されます。

- PARTITIONS: パーティション表のダイレクト・ロード中、ログ・ファイルに対するパーティションごとの統計情報の書込みを使用禁止にします。このオプションは、強制ダイレクト・パス操作でのみ有効です。

- ALL: すべての抑止オプションを実装します。

例

たとえば、画面に通常表示されるヘッダーとフィードバック・メッセージが表示されないようにするには、コマンドラインの引数で次のように指定します。

> sqlldr hr TABLE=employees SILENT=HEADER, FEEDBACK

TABLE

デフォルト: デフォルト値は設定されていません。

用途

TABLEパラメータでは、SQL*Loaderエクスプレス・モードをアクティブ化します。

構文および説明

TABLE=[schema-name.]table-name

スキーマ名または表名に小文字、空白または他の特殊文字が含まれる場合、名前を二重引用符で囲み、その文字列全体を一重引用符で囲む必要があります。次に例を示します。

TABLE='"hr.Employees"'

制限事項

- TABLEパラメータは、SQL*Loaderエクスプレス・モードでのみ有効です。

例

次の例では、エクスプレス・モードでemployees表をロードします。

> sqlldr hr TABLE=employees

TERMINATED_BY

デフォルト: カンマ

用途

TERMINATED_BYパラメータでは、デフォルトに優先するフィールド終端文字を指定します。

構文および説明

TERMINATED_BY=['char'| x'hex-char' | WHITESPACE]

フィールド終端文字は単一の文字である必要があります。これには、16進表記を使用できます。また、空白にすることもできます。TERMINATED_BY=WHITESPACEを指定すると、最初に空白文字(スペース、タブ、空白、LF、改ページまたは改行)が現れるまでデータが読み込まれます。空白文字が現れると、隣接する空白文字が検出されなくなるまで現在の位置が進められます。したがって、フィールド値の間に入る空白は、いくつあってもかまいません。

TERMINATED_BY=WHITESPACEを使用する場合、NULLフィールドに空白または空白文字のみを含めることはできません(空白または空白文字はスキップされ、エラーがレポートされる可能性があるため)。つまり、データにNULLフィールドが含まれる場合、必要に応じて別の文字列を使用してNULLフィールドを示し、NULLIFパラメータを使用してNULLIF文字列を示す必要があります。たとえば、文字列"NoData"を使用してNULLフィールドを示し、データに文字列"NoData"を挿入してNULLフィールドを示すことができます。NULLIF="NoData"を指定して、SQL*Loaderに対し、文字列"NoData"を含むフィールドをNULLに設定するように指示します。

制限事項

- 「なし」

例

次の例では、フィールドが「|」文字で終了します。

> sqlldr hr TABLE=employees TERMINATED_BY="|"

TIMESTAMP_FORMAT

デフォルト: デフォルトは、環境変数NLS_TIMESTAMP_FORMATの値から取得されます。NLS_TIMESTAMP_FORMATが設定されていない場合、タイムスタンプでは、6桁の小数点精度を持つ環境変数NLS_TERRITORYで定義されたデフォルト書式を使用します。

用途

TIMESTAMP_FORMATパラメータでは、ロードで使用するタイムスタンプ書式を指定します。

構文および説明

TIMESTAMP_FORMAT="timestamp_format"

制限事項

- 「なし」

例

次の例では、タイムスタンプ書式を指定します。

> sqlldr hr TABLE=employees TIMESTAMP_FORMAT="MON-DD-YYYY HH:MI:SSXFF AM"

TRIM

デフォルト: 従来型パス・ロードとダイレクト・パス・ロードのデフォルトはLDRTRIMです。外部表ロードのデフォルトはLRTRIMです。

用途

TRIMパラメータでは、ロード中に使用する切捨てタイプを指定します。

構文および説明

TRIM=[LRTRIM | NOTRIM | LTRIM | RTRIM |LDRTRIM]

TRIMパラメータを使用して、空白をテキスト・フィールドの始めから切り捨てるか、終わりから切り捨てるか、またはその両方から切り捨てるかを指定します。空白には、空白文字およびその他の印字されない文字(タブ、LF、改行など)が含まれます。

フィールドから文字を切り捨てない場合は、NOTRIMを使用します。この設定では、通常、最高のパフォーマンスを得ることができます。

フィールドから文字を切り捨てる場合は、LRTRIM、LTRIMおよびRTRIMを使用します。LRTRIMを使用すると、先頭と後続の空白の両方が切り捨てられます。先頭の空白を切り捨てるには、LTRIMを使用します。後続の空白を切り捨てるには、RTRIMを使用します。

LDRTRIMは、次の場合を除いて、NOTRIMと同様です。

- フィールドがOPTIONALLY_ENCLOSED BYで指定されたデリミタ付きフィールドで、オプションの囲みが特定のインスタンスで欠落している場合、空白は左から切り捨てられます。

すべてが空白のフィールドに対して切捨てを指定する場合、そのフィールドはNULLに設定されます。

制限事項

- 強制従来型パス・ロードおよび強制ダイレクト・パス・ロードでは、LDRTRIMのみがサポートされます。どの値でTRIMパラメータを指定しても、常にこの内容を示すメッセージが表示されます。

- ロードがデフォルトの外部表ロードで、SQL*Loaderエクスプレス・モードでかわりにダイレクト・パス・ロードを使用することになるエラーが発生した場合、別の方法を指定したり、LRTRIMで外部表のデフォルトを受け入れていても、LDRTRMが切捨て方法として使用されます。この変更を示すアラート・メッセージが表示されます。
NOTRIMを使用する場合、PRESERVE BLANKS句を含む制御ファイルを使用できます。

例

次の例では、右側のすべての空白(後続の空白)を切り捨ててフィールドを読み取ります。

> sqlldr hr TABLE=employees TRIM=RTRIM

USERID

デフォルト: none

用途

USERIDパラメータを使用して、Oracleユーザー名およびパスワードを指定します。

構文および説明

USERID = [username | / | SYS]

USERIDパラメータを指定しない場合、その入力を求められます。スラッシュのみを入力すると、デフォルトとしてオペレーティング・システムのログイン名がUSERIDに適用されます。

ユーザーSYSとして接続する場合は、接続文字列にAS SYSDBAも指定する必要があります。

制限事項

- 文字列AS SYSDBAには空白が含まれるため、一部のオペレーティング・システムでは、接続文字列全体を一重引用符で囲むか、なんらかの方法でリテラルとしてマークする必要があります。また、オペレーティング・システムによっては、コマンドラインの引用符を、バックスラッシュなどでエスケープする必要がある場合もあります。
システムの特殊文字および予約文字の詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

例

次の例では、ユーザーhrのジョブを開始します。

> sqlldr USERID=hr TABLE=employees
Password:

SQL*Loaderエクスプレス・モードの構文図

この項では、SQL*Loaderエクスプレス・モードの構文を図形式(線路図またはDDL構文図ともいいます)で示します。ここで使用している構文の表記法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

express_init

次の構文図は、前の構文図のexpress_optionsに含まれるパラメータを示します。次の構文図に示されているSQL*Loaderエクスプレス・モードのパラメータは、すべてオプションで、SQL*Loaderコマンドラインに任意の順序で指定できます。そのため、これらは単純なアルファベット順で示します。

express_options

express_options_cont

第III部 外部表

外部表を正しく使用するには、次のことをよく理解しておく必要があります。

外部表の概要

外部表の基本概念について説明します。

ORACLE_LOADERアクセス・ドライバ

ORACLE_LOADERアクセス・ドライバについて説明します。

ORACLE_DATAPUMPアクセス・ドライバ

ORACLE_DATAPUMPアクセス・ドライバのパラメータ、サポートされるデータ型のロードおよびアンロードに関する情報などについて説明します。

14 外部表の概要

外部表機能は、既存のSQL*Loader機能を補足する機能です。この機能によって、データベースに表がある場合と同様に、外部ソースのデータにアクセスできます。

データ・ロード時にステージング表の追加の索引付けが必要な場合、SQL*Loaderを使用する方が有効です。SQL*Loaderと外部表との処理内容の違いについては、「SQL*Loaderと外部表との処理内容の違い」を参照してください。

次のトピックを参照してください。

- 外部表の作成方法

- 外部表の使用時のデータ型の変換

関連項目:

外部表の作成と管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

外部表の作成方法

外部表は、SQLのCREATE TABLE...ORGANIZATION EXTERNAL文を使用して作成されます。外部表の作成時に、次の属性を指定します。

- TYPE: 外部表の型を指定します。ORACLE_LOADER型およびORACLE_DATAPUMP型の2種類の型が選択可能です。外部表の各型は、固有のアクセス・ドライバによってサポートされます。

- ORACLE_LOADERアクセス・ドライバがデフォルトです。これによって、外部表から内部表にデータがロードされます。データはテキスト・データ・ファイルからのものである必要があります。(ORACLE_LOADERアクセス・ドライバは、アンロードを実行できないため、内部表から外部表にデータを移動することはできません。)

- ORACLE_DATAPUMPアクセス・ドライバでは、ロードおよびアンロードを実行できます。データは、バイナリのダンプ・ファイルからロードする必要があります。内部表から外部表へのロードは、バイナリのダンプ・ファイルからフェッチすることによって実行されます。内部表から外部表へのアンロードは、外部表のバイナリのダンプ・ファイルを移入することによって実行されます。ORACLE_DATAPUMPアクセス・ドライバは、SQLのCREATE TABLE AS SELECT文を使用した外部表の作成の一環としてのみダンプ・ファイルにデータを書き込むことができます。作成されたダンプ・ファイルは、何回でも読み取ることができますが、変更はできません(つまり、DML操作は実行できません)。

- DEFAULT DIRECTORY: 明示的にディレクトリ・オブジェクトに名前を付けないすべての入出力ファイルに対して、使用するデフォルトのディレクトリを指定します。位置はディレクトリ・パスではなく、ディレクトリ・オブジェクトで指定されます。外部表を作成する前にディレクトリ・オブジェクトを作成しておく必要があります(これを行わない場合はエラーが生成されます)。詳細は、「データ・ファイルおよび出力ファイルの位置」を参照してください。

- ACCESS PARAMETERS: 外部データ・ソースを記述し、指定された外部表の型を実装します。各外部表の型には、その外部表の型に固有のアクセス・パラメータを提供する専用のアクセス・ドライバがあります。アクセス・パラメータはオプションです。詳細は、「アクセス・パラメータ」を参照してください。

- LOCATION: 外部表のデータ・ファイルを指定します。ファイル名は、directory:fileという書式です。directoryの部分はオプションです。この部分を指定しないと、デフォルトのディレクトリがファイルのディレクトリとして使用されます。ORACLE_LOADERアクセス・ドライバを使用している場合には、ファイル名にはワイルドカードを使用でき、アスタリスク(*)は複数文字を、疑問符(?)は1文字を表します。

次の例では、これらの各属性の使用を示します(デフォルト・ディレクトリdef_dir1がすでに存在するものとします)。

SQL> CREATE TABLE emp_load
2    (employee_number      CHAR(5),
3     employee_dob         CHAR(20),
4     employee_last_name   CHAR(20),
5     employee_first_name  CHAR(15),
6     employee_middle_name CHAR(15),
7     employee_hire_date   DATE)
8  ORGANIZATION EXTERNAL
9    (TYPE ORACLE_LOADER
10     DEFAULT DIRECTORY def_dir1
11     ACCESS PARAMETERS
12       (RECORDS DELIMITED BY NEWLINE
13        FIELDS (employee_number      CHAR(2),
14                employee_dob         CHAR(20),
15                employee_last_name   CHAR(18),
16                employee_first_name  CHAR(11),
17                employee_middle_name CHAR(11),
18                employee_hire_date   CHAR(10) date_format DATE mask "mm/dd/yyyy"
19               )
20       )
21     LOCATION ('info.dat')
22    );

Table created.

アクセス・ドライバで指定する情報により、データ・ソースのデータが、外部表の定義と一致するように処理されます。CREATE TABLE emp_loadの後にリストされるフィールドが、実際にinfo.datソース・ファイル内のデータのメタデータを定義します。

データ・ファイルおよび出力ファイルの位置

アクセス・ドライバは、データベース・サーバー内で実行されます。これは、SQL*Loaderが、ロードするデータをサーバーに送信するクライアント・プログラムであるという点で、SQL*Loaderとは異なります。この違いは、次のことを意味しています。

- サーバーでは、アクセス・ドライバによってロードされるファイルにアクセスする必要があります。

- サーバーでは、アクセス・ドライバによって作成された出力ファイル(ログ・ファイル、不良ファイルおよび廃棄ファイル)、およびORACLE_DATAPUMPアクセス・ドライバによって作成されたダンプ・ファイルの作成と書込みを行う必要があります。

アクセス・ドライバでは、ディレクトリ・オブジェクトを使用して、ファイルの読取りおよび書込みを行う位置を指定する必要があります。ディレクトリ・オブジェクトは、ファイル・システムのディレクトリ名に名前をマップします。たとえば、次の文は/usr/apps/datafilesにあるディレクトリにマップされる、ext_tab_dirという名前のディレクトリ・オブジェクトを作成します。

CREATE DIRECTORY ext_tab_dir AS '/usr/apps/datafiles';

ディレクトリ・オブジェクトは、DBAまたはCREATE ANY DIRECTORY権限を持つすべてのユーザーが作成できます。

注意:

Oracle Real Applications Cluster(Oracle RAC)構成で外部表を使用するには、ディレクトリ・オブジェクトのパスがクラスタ・ファイル・システム上に存在するようにする必要があります。

ディレクトリの作成後、ディレクトリ・オブジェクトを作成するユーザーは、そのディレクトリのREAD権限およびWRITE権限を他のユーザーに付与する必要があります。これらの権限は、ロールを使用して割り当てるのではなく、明示的に付与する必要があります。たとえば、ext_tab_dirで指定されたディレクトリのユーザーscottのかわりに、サーバーがファイルを読み込むことができるようにするには、ディレクトリ・オブジェクトを作成したユーザーが、次のコマンドを実行する必要があります。

GRANT READ ON DIRECTORY ext_tab_dir TO scott;

SYSユーザーのみがディレクトリ・オブジェクトを所有できます。ただし、SYSユーザーは、ディレクトリ・オブジェクトを作成する権限を他のユーザーに付与できます。ディレクトリ・オブジェクトへのREAD 権限またはWRITE権限は、Oracle Databaseによるファイルの読取りまたは書込みのみを意味します。適切なオペレーティング・システム権限がないかぎり、Oracle Databaseの外部にあるファイルには直接アクセスできません。同様に、Oracle Databaseには、ディレクトリのファイルに対して読取りおよび書込みを行うオペレーティング・システム権限が必要です。

アクセス・パラメータ

特定の型の外部表を作成する場合、アクセス・パラメータを指定して、アクセス・ドライバのデフォルトの動作を変更できます。各アクセス・ドライバには、アクセス・パラメータ用の固有の構文があります。外部表に使用する、ORACLE_LOADER、ORACLE_DATAPUMPの2つのアクセス・ドライバが提供されています。

注意:

これらのアクセス・パラメータは、SQL文のCREATE TABLE...ORGANIZATION EXTERNALのopaque_format_specとしてまとめて参照されます。

関連項目:

- ORACLE_LOADERアクセス・ドライバ

- ORACLE_DATAPUMPアクセス・ドライバ

- SQL CREATE TABLE文を使用するときにopaque_format_specを指定する方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

外部表の使用時のデータ型の変換

データを外部表から、または外部表に移動すると、次の3つの場所にある同一の列が、異なるデータ型を持つ可能性があります。

- データベース: データが外部表にアンロードされる際のソースであり、データが外部表からロードされるときのロード先です。

- 外部表: データが外部表にアンロードされると、外部表内の列のデータ型と一致するよう、データベースからのデータは必要に応じて変換されます。また、SQL演算子をソース・データに適用して、データを外部表に移動する前にデータ型を変更できます。同様に、外部表からデータベースにロードすると、外部表からのデータはデータベース内の列のデータ型と一致するよう自動的に変換されます。さらに、外部表から選択しているSQL文内のSQL演算子を使用して、他の変換も実行できます。より高いパフォーマンスを得るには、外部表のデータ型を、データベースのデータ型と一致させます。

- データ・ファイル: データを外部表にアンロードすると、データ・ファイルのフィールドのデータ型は外部表のフィールドのデータ型と完全に一致します。ただし、外部表からデータをロードすると、データ・ファイルのデータ型が外部表のデータ型と一致しない場合があります。その場合、データ・ファイルからのデータは、外部表のデータ型と一致するよう変換されます。列の変換時にエラーが発生した場合、その列を含むレコードはロードされません。より高いパフォーマンスを得るには、データ・ファイルのデータ型を、外部表のデータ型と一致させます。

データ・ファイルと外部表の間で変換エラーが発生すると、エラーの発生した行は無視されます。変換エラーおよび制約違反を含む、外部表とデータベース内の列でエラーが発生すると、操作全体が正常に完了されないまま終了します。

データが外部表にアンロードされる際に、ソース表内の列のデータ型が外部表の列のデータ型と一致していない場合、データが変換されます。変換エラーが発生した場合、その時点までに処理されたすべての行がデータ・ファイルに含まれず、データ・ファイルの読取りができなくなる場合があります。変換エラーによって操作が失敗する問題を回避するには、外部表の列のデータ型をデータベースの列のデータ型と一致させます。ただし、外部表はすべてのデータ型をサポートするわけではないため、必ず成功するとはかぎりません。そのような場合、ソース表でサポートされていないデータ型を、外部表でサポートするデータ型に変換する必要があります。たとえば、LONG_TABという名前のソース表にLONG列がある場合、作成される外部表LONG_TAB_XTの対応する列はCLOBである必要があり、外部表を移入するために使用したSELECT副問合せは、列をロードするためにTO_LOB演算子を使用する必要があります。

CREATE TABLE LONG_TAB_XT (LONG_COL CLOB) ORGANIZATION EXTERNAL...SELECT TO_LOB(LONG_COL) FROM LONG_TAB;

注意:

Oracle Database 12cリリース1 (12.1)から、Oracle DatabaseのVARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズが32KBに増加しました(COMPATIBLE初期化パラメータが12.0以上に設定され、MAX_STRING_SIZE初期化パラメータがEXTENDEDに設定されている場合)。外部表機能では、この新しい最大サイズがサポートされます。

15 ORACLE_LOADERアクセス・ドライバ

ORACLE_LOADERアクセス・ドライバは、ORACLE_LOADER型の外部表に固有のアクセス・パラメータのセットを提供します。アクセス・ドライバのデフォルトの動作を変更するためにアクセス・パラメータを使用できます。アクセス・ドライバで指定する情報により、データ・ソースのデータが、外部表の定義と一致するように処理されます。

詳細は次のトピックを参照してください。

- access_parameters句

- record_format_info句

- field_definitions句

- column_transforms句

- ORACLE_LOADERアクセス・ドライバのパラレル・ロードに関する考慮点

- ORACLE_LOADERアクセス・ドライバを使用する際のパフォーマンスのヒント

- ORACLE_LOADERアクセス・ドライバ使用時の制限事項

- ORACLE_LOADERアクセス・ドライバの予約語

これらの項目内の情報を正しく使用するには、使用するプラットフォームのデータ・ファイルのファイル形式およびレコード形式(キャラクタ・セット、フィールドのデータ型など)についての知識が必要です。また、外部表を作成し、その外部表に問合せを実行するためのSQLの知識も必要です。

SQL*LoaderでEXTERNAL_TABLE=GENERATE_ONLYパラメータを使用すると、任意のSQL*Loader制御ファイルに適正なアクセス・パラメータを取得できます。GENERATE_ONLYを指定すると、制御ファイルに記述されているとおり、SQL*Loaderログ・ファイル内の外部表を使用してロードを行うために必要なすべてのSQL文が書き込まれます。これらのSQL文は、編集およびカスタマイズできます。実際のロードは、SQL*Loaderを使用せずに、SQL*Plusでこれらの文を実行して、後で行うことができます。

関連項目:

- 「EXTERNAL_TABLE」

- 外部表の作成と管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

注意:

- 章の後半で説明されているその他の構文を使用しなければ、わかりにくい場合があります。構文によって行われる処理が明確でない場合は、先に進み、その説明を参照してください。

- ここで示す例は、外部表の場合のデータ・ファイル内容のサンプルを伴うCREATE TABLE...ORGANIZATION EXTERNAL文の例で、その内容は、CREATE TABLE文の一部ではなく、完全な例です。

- 外部表アクセス・パラメータにおいて列名や表名などの識別子が指定される場合、特定の値はアクセス・パラメータ・パーサーによって予約語とみなされます。予約語を識別子として使用するには、二重引用符で囲む必要があります。詳細は、「ORACLE_LOADERアクセス・ドライバの予約語」を参照してください。

access_parameters句

access_parameters句には、コメント、レコード形式およびフィールド形式の情報が含まれています。

データ・ソースのデータの記述は外部表の定義とは別です。これは、次のことを意味します。

- ソース・ファイルに含まれるフィールドの数は、外部表の列数と異なる場合があります。

- データ・ソースのフィールドのデータ型は、外部表の列のデータ型と異なる場合があります。

アクセス・ドライバによって、データ・ソースのデータが、外部表の定義と一致するように処理されます。

access_parameters句の構文は次のとおりです。

注意:

これらのアクセス・パラメータは、SQL文のCREATE TABLE...ORGANIZATION EXTERNALのopaque_format_specとしてまとめて参照されます。

関連項目:

- SQL CREATE TABLE...ORGANIZATION EXTERNAL文を使用するときにopaque_format_specを指定する方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

コメント

コメントは、2つのハイフンで始まり、その後にテキストが続く行です。コメントは、次の例のように、アクセス・パラメータより前に位置する必要があります。

--This is a comment.
--This is another comment.
RECORDS DELIMITED BY NEWLINE

二重ハイフンの右側のすべてのテキストは行末まで無視されます。

record_format_info

record_format_info句はオプションであり、レコード(形式など)、データのキャラクタ・セット、およびレコードをロードの対象外とする規則についての情報が含まれます。構文の詳細は、「record_format_info句」を参照してください。

field_definitions

field_definitions句を使用して、データ・ファイルのフィールドを指定します。データ・ファイルのフィールドが外部表の列と同じ名前の場合、フィールドのデータはその列に使用されます。構文の詳細は、「field_definitions句」を参照してください。

column_transforms

column_transforms句はオプションであり、データ・ファイルの列に直接マップされない外部表の列のロード方法を記述するために使用します。NULL、CONSTANT、CONCATおよびLOBFILE変換を使用して行います。構文の詳細は、「column_transforms句」を参照してください。

record_format_info句

record_format_info句には、レコード(形式など)、データのキャラクタ・セットおよびレコードをロード対象とする規則についての情報が含まれます。また、PREPROCESSOR句も使用すると、ユーザーが用意したプログラムの名前を指定し、そのプログラムを実行して、ORACLE_LOADERアクセス・ドライバで解析できるようにデータ・ファイルの内容を変更することもできます。

record_format_info句はオプションです。デフォルト値は、句が指定されているかどうかにかかわらず、RECORDS DELIMITED BY NEWLINEです。record_format_info句の構文は次のとおりです。

et_record_spec_options句を使用すると、追加の書式情報をオプションで指定できます。書式オプションは必要な数だけ任意の順序で指定できます。オプションの構文は次のとおりです。

次のet_output_filesの図に、不良ファイル、廃棄ファイルおよびログ・ファイルを指定するオプションを示します。これらの句ごとに、ディレクトリ・オブジェクト名またはファイル名(あるいはその両方)を指定する必要があります。

FIXED長

FIXED句を使用して、すべてのレコードをバイト単位の固定長として識別します。FIXEDレコードに対して指定したサイズには、改行などのレコード終了文字を含める必要があります。他のレコード型と比較して、固定長レコードの固定長フィールドは、アクセス・ドライバを最も簡単に処理できるフィールドおよびレコード形式です。

次に、FIXEDレコードが使用されている例を示します。データ・ファイルの各レコードの末尾に1バイトの改行文字があるとします。その後に、ロードが可能なデータ・ファイルのサンプルを示します。

CREATE TABLE emp_load (first_name CHAR(15), last_name CHAR(20), year_of_birth CHAR(4))
ORGANIZATION EXTERNAL (TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS (RECORDS FIXED 20 FIELDS (first_name CHAR(7),
last_name CHAR(8),
year_of_birth CHAR(4)))
LOCATION ('info.dat'));

Alvin  Tolliver1976
KennethBaer    1963
Mary   Dube    1973

VARIABLEサイズ

VARIABLE句を使用して、レコードを可変長として識別します。各レコードの先頭に、レコードのバイト数を示す文字列が付きます。カウント・フィールドを含む文字列の長さは、VARIABLEパラメータの後に続くサイズ引数となります。サイズは、文字数ではなく、バイト数で表されることに注意してください。レコードの先頭の数値にレコード終了文字の分が含まれる必要があります。ただし、カウント・フィールド自身のサイズは含まれません。レコード終了文字のバイト数は、ファイルの作成方法および作成時のプラットフォームによって異なります。

次に、VARIABLEレコードが使用されている例を示します。データ・ファイルの各レコードの末尾に1バイトの改行文字があるとします。その後に、ロードが可能なデータ・ファイルのサンプルを示します。

CREATE TABLE emp_load (first_name CHAR(15), last_name CHAR(20), year_of_birth CHAR(4))
ORGANIZATION EXTERNAL (TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS (RECORDS VARIABLE 2 FIELDS TERMINATED BY ','
(first_name CHAR(7),
last_name CHAR(8),
year_of_birth CHAR(4)))
LOCATION ('info.dat'));

21Alvin,Tolliver,1976,
19Kenneth,Baer,1963,
16Mary,Dube,1973,

DELIMITED BY

DELIMITED BY句を使用して、レコードの終わりを識別する文字を指定します。

DELIMITED BY NEWLINEを指定する場合、実際に使用される値はプラットフォームに依存します。UNIXプラットフォームでは、NEWLINEは「\n」です。Windowsオペレーティング・システムでは、NEWLINEは「\r\n」とみなされます。

DELIMITED BY stringを指定する場合、stringは、テキストまたは一連の16進数のいずれかになります。16進数の場合は、OXまたはXで開始して引用符で囲みます。テキストの場合は、データ・ファイルのキャラクタ・セットに変換され、その結果がレコードの境界の識別に使用されます。詳細は、「string」を参照してください。

次の条件を満たす場合は、デリミタの識別には16進数字を使用する必要があります。

- アクセス・パラメータのキャラクタ・セットがデータ・ファイルのキャラクタ・セットとは異なる場合。

- 区切り文字列中にデータ・ファイルのキャラクタ・セットに変換できない文字がある場合。

16進数字はバイトに変換されます。16進文字列ではキャラクタ・セットの変換は実行されません。

ファイルの終わりがレコード終了記号の前で検出された場合、アクセス・ドライバは、終了記号が検出された場合と同様に、ファイルの終わりまでの処理されていないすべてのデータをレコードの部分とみなします。

注意:

デリミタ付きのレコードには、VARCHARおよびVARRAWのバイナリ数値を含むバイナリ・データを含めないでください。バイナリ・データを含めると、そのバイナリ・データがデリミタの検索中に文字として解釈されるため、エラーまたは破損が発生します。

次に、DELIMITED BYレコードの使用例を示します。

CREATE TABLE emp_load (first_name CHAR(15), last_name CHAR(20), year_of_birth CHAR(4))
ORGANIZATION EXTERNAL (TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS (RECORDS DELIMITED BY '|' FIELDS TERMINATED BY ','
(first_name CHAR(7),
last_name CHAR(8),
year_of_birth CHAR(4)))
LOCATION ('info.dat'));

Alvin,Tolliver,1976|Kenneth,Baer,1963|Mary,Dube,1973

CHARACTERSET

CHARACTERSET string句を使用して、データ・ファイルのキャラクタ・セットを識別します。キャラクタ・セットを指定しない場合、データベースのデフォルトのキャラクタ・セットが使用されます。詳細は、「string」を参照してください。

注意:

クライアントのNLS環境変数設定は、データベースに使用されるキャラクタ・セットに影響しません。

関連項目:

Oracleでサポートされるキャラクタ・セットのリストは、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

EXTERNAL VARIABLE DATA

注意:

EXTERNAL VARIABLE DATA句がOracle SQL Connector for Hadoop Distributed File System (HDFS)とともに使用する場合にのみ、有効です。Oracle SQL Connector for HDFSの詳細は、『Oracle Big Data Connectorsユーザーズ・ガイド』を参照してください。

EXTERNAL VARIABLE DATA句を指定し、ORACLE_LOADERアクセス・ドライバを使用してORACLE_DATAPUMPアクセス・ドライバで生成されたダンプ・ファイルをロードします。構文は次のとおりです:

EXTERNAL VARIABLE DATAを使用する場合は、セキュリティ上の理由から、DISABLE_DIRECTORY_LINK_CHECKアクセス・パラメータが必要です。

EXTERNAL VARIABLE DATA句で使用できるその他のアクセス・パラメータは、次のとおりです。

- LOGFILE | NOLOGFILE

- READSIZE

- PREPROCESSOR

次の例では、EXTERNAL VARIABLE DATA句を使用しています。この例では、deptxt1.dmpダンプ・ファイルが事前にORACLE_DATAPUMPアクセス・ドライバで生成されていることを想定しています。PREPROCESSORパラメータで指定されたtkexcatプログラムは、入力データを処理するためにユーザーが用意したプログラムです。

CREATE TABLE deptxt1
(
deptno  number(2),
dname   varchar2(14),
loc     varchar2(13)
)
ORGANIZATION EXTERNAL
(
TYPE ORACLE_LOADER
DEFAULT DIRECTORY dpump_dir
ACCESS PARAMETERS
(
EXTERNAL VARIABLE DATA
DISABLE_DIRECTORY_LINK_CHECK
LOGFILE 'deptxt1.log'
READSIZE=10000
PREPROCESSOR tkexcat
)
LOCATION ('deptxt1.dmp')
)
REJECT LIMIT UNLIMITED
;

PREPROCESSOR

注意:

PREPROCESSOR句を使用する場合は、セキュリティ上の影響を考慮する必要があります。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

ロードするファイルにORACLE_LOADERアクセス・ドライバでサポートしていない形式のデータ・レコードが含まれる場合は、PREPROCESSOR句を使用して、ユーザーが用意するプリプロセッサ・プログラムを指定し、そのプログラムをすべてのデータ・ファイルに対して実行します。引数を使用する場合は、そのプログラムの指定をシェル・スクリプトに入れる必要があります(「file_spec」の説明を参照)。

プリプロセッサ・プログラムは、アクセス・ドライバがサポートするレコード形式にデータを変換し、変換したレコード・データを標準出力(stdout)に書き出します。アクセス・ドライバはそのデータを入力として読み取ることになります。PREPROCESSOR句の構文は次のとおりです。

directory_spec

各データ・ファイルに対して実行するプリプロセッサ・プログラムの名前が含まれるディレクトリ・オブジェクトを指定します。外部表にアクセスするユーザーには、使用されるディレクトリ・オブジェクトのEXECUTE権限が必要です。directory_specを省略した場合は、外部表に対して指定されたデフォルトのディレクトリが使用されます。

注意:

セキュリティ上の理由から、プリプロセッサ・プログラムは、デフォルト・ディレクトリでなく別のディレクトリを使用して格納することをお薦めします。プリプロセッサ・プログラムが格納されているディレクトリには別のファイルを保管しないでください。

プリプロセッサ・プログラムは、ディレクトリ・オブジェクト内に存在する必要があります。これは、セキュリティ上の理由から、プログラムへのアクセスを制御できるようにするためです。OSシステム管理者は、そのディレクトリ・オブジェクトに対応するディレクトリを作成し、OSユーザーORACLEがそのディレクトリへのアクセス権を持っていることを確認する必要があります。DBAは、承認されたユーザーのみが、ディレクトリ・パスに関連付けられたディレクトリ・オブジェクトにアクセスできるようにする必要があります。ディレクトリ・オブジェクトのアクセス権は、複数のデータベース・ユーザーに付与できますが、そのディレクトリ内のプリプロセッサを実行できるのはEXECUTE権限を持つユーザーのみです。ディレクトリ・オブジェクトへの読取り/書込み権限を持つ既存データベース・ユーザーでは、前処理の機能を使用できません。DBAがディレクトリ・オブジェクトのEXECUTE権限をどのユーザーにも付与しなければ、プリプロセッサの使用を禁止できます。

関連項目:

EXECUTE権限を付与する方法については、『Oracle Database SQL言語リファレンス』を参照してください。

file_spec

プリプロセッサ・プログラムの名前です。この名前は、使用されているディレクトリ・オブジェクト(directory_specまたは外部表のデフォルト・ディレクトリのいずれか)に関連付けられたパス名の後ろに追加されます。file_specに絶対ディレクトリ・パスや相対ディレクトリ・パスを含めることはできません。

プリプロセッサ・プログラムに引数(gunzip -cなど)が必要な場合は、プログラム名とその引数を実行可能シェル・スクリプト(Windowsオペレーティング・システムではバッチ(.bat)・ファイル)で指定する必要があります。シェル・スクリプトおよびバッチ・ファイルには、次の項で説明する特定の要件があります。

オペレーティング・システム・ディレクトリに正しいバージョンのプリプロセッサ・プログラムがあることを必ず確認してください。

次に、シェルまたはバッチ・ファイルを使用せずにPREPROCESSOR句を指定する例を示します。

SQL> CREATE TABLE xtab (recno varchar2(2000))
2    ORGANIZATION EXTERNAL (
3    TYPE ORACLE_LOADER
4    DEFAULT DIRECTORY data_dir
5    ACCESS PARAMETERS (
6    RECORDS DELIMITED BY NEWLINE
7    PREPROCESSOR execdir:'zcat'
8    FIELDS (recno char(2000)))
9    LOCATION ('foo.dat.gz'))
10    REJECT LIMIT UNLIMITED;
Table created.

Linuxオペレーティング・システムにおけるPREPROCESSOR句でのシェル・スクリプトの使用

- シェル・スクリプトは、directory_specに存在する必要があります。

- gunzipなどのシステム・コマンドのフルパス名を指定する必要があります。

- プリプロセッサのシェル・スクリプトには、EXECUTE権限が必要です。

- 外部表のLOCATION句にリストされているデータ・ファイルは、$1で参照する必要があります。

次の例は、外部表作成時のPREPROCESSOR句でのシェル・スクリプトの指定方法を示しています。

SQL> CREATE TABLE xtab (recno varchar2(2000))
2    ORGANIZATION EXTERNAL (
3    TYPE ORACLE_LOADER
4    DEFAULT DIRECTORY data_dir
5    ACCESS PARAMETERS (
6    RECORDS DELIMITED BY NEWLINE
7    PREPROCESSOR execdir:'uncompress.sh'
8    FIELDS (recno char(2000)))
9    LOCATION ('foo.dat.gz'))
10    REJECT LIMIT UNLIMITED;
Table created.

Windowsオペレーティング・システムにおけるPREPROCESSOR句でのバッチ・ファイルの使用

- バッチ・ファイルは、directory_specに存在する必要があります。

- gunzipなどのシステム・コマンドのフルパス名を指定する必要があります。

- プリプロセッサのバッチ・ファイルには、EXECUTE権限が必要です。

- バッチ・ファイルの最初の行には@echo offを含める必要があります。この要件は、バッチ・ファイルの実行時にはデフォルトで実行中のコマンドが表示され、表示されたコマンドが外部表アクセス・ドライバへの入力として扱われるという意図しない副次的な影響があるために設けられています。

- LOCATION句からの入力を表すには、%1を使用する必要があります。(これは、LOCATION句が$1によって参照されるLinuxスタイルのシェル・スクリプトとは異なることに注意してください。)

- バッチ・ファイル内の実行可能ファイルにはすべてフルパスを指定する必要があります(次の例ではsed.exe)。すべてのWindowsインストールにMKSツールキットが存在するわけではないため、sed.exeなどのコマンドが使用できない場合があることにも注意してください。
Windowsで使用するバッチ・ファイルには、.batまたは.cmd拡張子が必要です。これらがない場合(たとえば、プリプロセッサ・スクリプトをsed.shと指定しようとした場合)、次のエラーが発生します。

SQL> select * from foo ;
select * from foo
*
ERROR at line 1:

ORA-29913: error in executing ODCIEXTTABLEFETCH callout
ORA-29400: data cartridge error
KUP-04095: preprocessor command
C:/Temp\sed.sh encountered error
"CreateProcess Failure for Preprocessor:
C:/Temp\sed.sh, errorcode: 193

次に、Windowsで外部表PREPROCESSORオプションを指定したバッチ・ファイルを使用する単純な例を示します。この例では、バッチ・ファイルはストリーム・エディタ(sed.exe)ユーティリティを使用して、入力データの単純な変換を実行します。

create table deptxt
(
deptno char(2),
dname char(14),
loc char(13)
)
organization external
(
type ORACLE_LOADER
default directory def_dir1
access parameters
(
records delimited by newline
badfile 'deptxt.bad'
logfile 'deptxt.log'
preprocessor exec_dir:'sed.bat'
fields terminated by ','
missing field values are null
)
location ('deptxt.dat')
)
reject limit unlimited ;

select * from deptxt ;

Where deptxt.dat contains:

10,ACCOUNTING,NEW YORK
20,RESEARCH,DALLAS
30,SALES,CHICAGO
40,OPERATIONS,BOSTON

プリプロセッサ・プログラムsed.batの内容は次のとおりです。

@echo off
c:/mksnt/mksnt/sed.exe -e 's/BOSTON/CALIFORNIA/' %1

PREPROCESSORオプションにより、入力データ(deptxt.dat)がsed.batに渡されます。その後、deptxt表から選択すると、以前はBOSTONだった最後の行のLOC列がCALIFORNIAになったことが結果に表示されます。

SQL> select * from deptxt ;

DE DNAME          LOC
-- -------------- -------------
1a ACCOUNTING     NEW YORK
20 RESEARCH       DALLAS
30 SALES          CHICAGO
40 OPERATIONS     CALIFORNIA

4 rows selected.

PREPROCESSOR句によるパラレル処理の使用

外部表では、LOCATION句で指定された各データ・ファイルが単一グラニュルとして扱われます。PREPROCESSOR句によるパラレル処理を最大限に活用するには、ロードされるデータを複数ファイル(グラニュル)に分割する必要があります。これは、外部表における並列度が、存在するデータ・ファイル数までに制限されるためです。たとえば、並列度を16に指定し、データ・ファイルが10個のみ存在する場合には、10個のスレーブ・プロセスがビジーとなり、6個がアイドル状態になるため、実際の並列度は10となります。アイドル状態のスレーブ・プロセスがないことが最適な状態です。したがって、並列度を指定する場合、すべてのスレーブ・プロセスがビジーになるように、並列度がデータ・ファイル数を超えないことが理想的です。

関連項目:

- 並列度のグラニュルの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

PREPROCESSOR句を使用する際の制限事項

- Oracle Database Vault機能を使用するデータベースでは、PREPROCESSOR句を使用できません。

- PREPROCESSOR句は、COLUMN TRANSFORMS句とともには使用できません。

LANGUAGE

LANGUAGE句を使用すると、データのロケール依存情報を得るための言語名(FRENCHなど)を指定できます。次に、言語名から得られる情報のタイプの例を示します。

- 月と日の名前およびその略称

- A.M.、P.M.、A.D.およびB.C.と同じ内容を表す記号

- SQL句ORDER BYが指定されたときの、文字データのデフォルトのソート順序

- 筆記方向(右から左、左から右)

- 肯定応答および否定応答の文字列(YES、NOなど)

関連項目:

Oracleでサポートされる言語のリストは、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

TERRITORY

TERRITORY句を使用すると、地域名を指定して、入力データの特性をより詳細に指定することができます。たとえば、カンマではなく小数点(531,298のかわりに531.298など)が数字に使用される国もあります。

関連項目:

Oracleでサポートされる地域のリストは、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

DATA IS...ENDIAN

DATA IS...ENDIAN句を使用して、データ・ファイルを生成したプラットフォームによってバイト順序が異なるデータのエンディアンを指定します。次の型のフィールドは、この句の影響を受けます。

- INTEGER

- UNSIGNED INTEGER

- FLOAT

- BINARY_FLOAT

- DOUBLE

- BINARY_DOUBLE

- VARCHAR(数値のみ)

- VARRAW(数値のみ)

- UTF16キャラクタ・セットの任意の文字データ型

- RECORDS DELIMITED BY stringによって指定するUTF16キャラクタ・セット文字列

Windowsベースのプラットフォームではリトル・エンディアン・データが生成されます。ビッグ・エンディアン・プラットフォームには、Sun SolarisおよびIBM MVSがあります。DATA IS...ENDIAN句を指定しない場合、データは、アクセス・ドライバが実行されているプラットフォームと同じエンディアンになります。UTF-16データ・ファイルには、ファイルの先頭にデータのエンディアンを示すマークがあります。このマークは、DATA IS...ENDIAN句に優先します。

BYTEORDERMARK(CHECK | NOCHECK)

BYTEORDERMARK句を使用して、データ・ファイルにバイト順序マーク(BOM)があるかを確認するかどうかを指定します。この句は、キャラクタ・セットがUnicodeの場合にのみ有効です。

BYTEORDERMARK NOCHECKを指定すると、データ・ファイルにBOMが存在するかどうかが確認されず、データ・ファイルのすべてのデータがデータとして読み込まれます。

BYTEORDERMARK CHECKを指定すると、データ・ファイルにBOMがあるかどうかを確認します。これはUnicodeキャラクタ・セットのデータ・ファイルについてのデフォルト動作です。

次に、使用例をいくつか示します。

- データをリトル・エンディアンまたはビッグ・エンディアンとして指定し、CHECKを指定したときにそのエンディアンがデータ・ファイルと一致していないと判断された場合は、エラーが返されます。たとえば、次のパラメータを指定したとします。

DATA IS LITTLE ENDIAN
BYTEORDERMARK CHECK

Unicodeデータ・ファイル内にBOMが存在するかどうかが確認され、そのデータが実際にはビッグ・エンディアンであった場合は、リトル・エンディアンを指定していたため、エラーが返されます。

- BOMが存在せず、DATA IS...ENDIANパラメータを使用してエンディアンを指定しない場合は、プラットフォームのエンディアンが使用されます。

- BYTEORDERMARK NOCHECKを指定し、DATA IS...ENDIANパラメータを使用してエンディアンを指定した場合は、その値が使用されます。それ以外の場合は、プラットフォームのエンディアンが使用されます。

関連項目:

「バイト順序」

STRING SIZES ARE IN

STRING SIZES ARE IN句を使用して、文字列の長さがバイト単位であるか、または文字単位であるかを指定します。この句を指定しない場合、アクセス・ドライバは、データベースが使用するモードを使用します。長さが埋め込まれた文字型(VARCHARなど)も、この句の影響を受けます。この句を指定すると、埋め込まれた長さは、バイト数ではなく、文字数となります。UTF16などのマルチバイト・キャラクタ・セットのロード時には、STRING SIZES ARE IN CHARACTERSを指定する必要があります。

LOAD WHEN

LOAD WHEN condition_spec句を使用して、データベースに渡すレコードを識別します。評価の方法は様々です。

- condition_spec句がレコードのフィールドを参照する場合、この句は、すべてのフィールドがレコードから解析された後で、NULLIF句またはDEFAULTIF句の評価が行われる前にのみ評価されます。

- 条件指定が範囲のみを参照する(フィールド名は参照しない)場合、フィールドが解析される前に句が評価されます。これは、ファイル中のロードできないレコードを、エラーなしで現行のレコード定義に解析できない場合に有効です。

詳細は、「condition_spec」を参照してください。

次に、LOAD WHENの使用例を示します。

LOAD WHEN (empid != BLANKS)
LOAD WHEN ((dept_id = "SPORTING GOODS" OR dept_id = "SHOES") AND total_sales != 0)

BADFILE | NOBADFILE

BADFILE句を使用して、エラーのためにロードできない場合にレコードが書き込まれるファイルを指定します。たとえば、データ・ファイルのフィールドを外部表の列のデータ型に変換できなかった場合、不良ファイルにレコードが書き込まれます。不良ファイルの目的は、すべての拒否されたデータを調査および修正して、ファイルをロードできるようにすることです。不良レコードがあってもデータを修正しない場合は、NOBADFILEオプションを使用して不良ファイルの作成を回避できます。

BADFILE句を指定する場合、ディレクトリ・オブジェクト名またはファイル名(あるいはその両方)を指定する必要があります。詳細は、「[directory object name:] [filename]」を参照してください。

BADFILEまたはNOBADFILEのいずれも指定しない場合、デフォルトでは1つ以上のレコードが拒否されると、不良ファイルが作成されます。このファイルの名前は、表名の後に_%pが付いたものになり、拡張子.badが付けられます。

LOAD WHEN句が正常に実行されない場合、レコードは不良ファイルには書き込まれず、かわりに、廃棄ファイルに書き込まれます。また、外部表のレコードを使用中にエラーが発生する場合は(外部表に対してINSERT INTO...AS SELECT...を使用した場合の制約違反など)、レコードは不良ファイルに書き込まれません。

DISCARDFILE | NODISCARDFILE

DISCARDFILE句を使用して、レコードがLOAD WHEN句の条件を満たすことができないことが書き込まれるファイルを指定します。この廃棄ファイルは、廃棄される最初のレコードが検出されると作成されます。同じ外部表が複数回アクセスされる場合、廃棄ファイルはそのたびに再度書き込まれます。廃棄レコードを個別のファイルに保存する必要がない場合、NODISCARDFILEを使用します。

DISCARDFILEを指定する場合、ディレクトリ・オブジェクト名またはファイル名(あるいはその両方)を指定する必要があります。詳細は、「[directory object name:] [filename]」を参照してください。

DISCARDFILE またはNODISCARDFILEのいずれも指定しない場合、デフォルトでは1つ以上のレコードでLOAD WHEN句が失敗すると、廃棄ファイルが作成されます。このファイルの名前は、表名の後に_%pが付いたものになり、拡張子.dscが付けられます。

LOGFILE | NOLOGFILE

LOGFILE句を使用して、データ・ファイルのデータへのアクセス中に外部表のユーティリティによって生成されたメッセージを含むファイルを指定します。ログ・ファイルがすでに同じ名前で存在する場合は、アクセス・ドライバによってそのログ・ファイルが再びオープンされ、新しいログ情報がファイルの終わりに追加されます。この点では、既存のファイルを上書きする不良ファイルおよび廃棄ファイルとは異なります。NOLOGFILE句を使用してログ・ファイルの作成を回避できます。

LOGFILEを指定する場合、ディレクトリ・オブジェクト名またはファイル名(あるいはその両方)を指定する必要があります。詳細は、「[directory object name:] [filename]」を参照してください。

LOGFILEまたはNOLOGFILEのいずれも指定しない場合、デフォルトではログ・ファイルが作成されます。このファイルの名前は、表名の後に_%pが付いたものになり、拡張子.logが付けられます。

SKIP

SKIPパラメータは、ロードの前に、データ・ファイルに含まれる指定した件数のレコードをスキップします。データにパラレルにアクセスしない場合にのみ指定できます。同一の表の同じ場所に1つ以上のデータ・ファイルがある場合、SKIPパラメータは、最初のデータ・ファイルに含まれる指定した件数のレコードのみをスキップします。

FIELD NAMES

FIELD NAMES句を使用してフィールド順序を指定できます。構文は次のとおりです:

FIELD NAMES {FIRST | FIRST IGNORE | ALL | ALL IGNORE| NONE}

FIELD NAMESのオプションは次のとおりです。

- FIRST: 最初のデータ・ファイルに、最初のレコードのデータに対応するフィールド名のリストが含まれることを示します。このリストでは、データ・ファイルのデータと同じデリミタが使用されます。このレコードは、データ・ファイルのフィールドとターゲット表の列とのマッピングを設定するために読み取られ、使用されます。このレコードは、データが処理されるとスキップされます。これは、データ・ファイルのフィールドの順序が表の列の順序と異なる場合や、データ・ファイルのフィールドの数がターゲット表の列の数と異なる場合に役立ちます。

- FIRST IGNORE: 最初のデータ・ファイルに、最初のレコードのデータに対応するフィールド名のリストが含まれるが、その情報は無視する必要があることを示します。このレコードは、データが処理されるとスキップされますが、フィールドの設定には使用されません。

- ALL: すべてのデータ・ファイルに、最初のレコードのデータに対応する列名のリストが含まれることを示します。各データ・ファイルの最初のレコードは、データが処理されるとスキップされます。リストは、各データ・ファイルで同じであるとみなされます。そうではない場合、データ・ファイルで不一致が検出されたときにロードは終了します。

- ALL IGNORE: すべてのデータ・ファイルに、最初のレコードのデータに対応するフィールド名のリストが含まれるが、その情報は無視する必要があることを示します。このレコードは、すべてのデータ・ファイルでデータが処理されるとスキップされますが、フィールドの設定には使用されません。

- NONE: データ・ファイルに、最初のレコードの通常のデータが含まれることを示します。このオプションがデフォルトです。

READSIZE

READSIZEパラメータは、レコードの処理に使用する読取りバッファのサイズを指定します。読取りバッファのサイズは、アクセス・ドライバで処理する最大入力レコードのサイズ以上にする必要があります。サイズは、整数のバイト数で指定します。デフォルト値は512KB(524288バイト)です。データ・ファイル内に512KBより大きいレコードがある場合は、デフォルト値より大きい値を指定する必要があります。READSIZEのサイズに上限はありませんが、アクセス・ドライバで割当て可能なメモリーの最大量が事実上の上限となります。

追加のバッファが割り当てられる場合もあるため、割当てに使用可能なメモリーの量によっても制限されます。追加のバッファは、(データ内、デリミタ、またはマルチ・キャラクタ/バイトのデリミタが使用されている場合はそのデリミタのいずれかで)分割された可能性のあるレコードの処理を正常に完了するために使用されます。

DISABLE_DIRECTORY_LINK_CHECK

デフォルトでは、ORACLE_LOADERアクセス・ドライバは、データやログ・ファイルを開く前にチェックを行い、使用するディレクトリがシンボリック・リンクでないことを確認します。DISABLE_DIRECTORY_LINK_CHECKパラメータ(引数なし)を指定して、このチェックを回避するようにアクセス・ドライバに指示すると、親ディレクトリがシンボリック・リンクの可能性があるファイルも使用できます。

注意:

シンボリック・リンクは外部表のロード操作での入力や出力をリダイレクトするために使用される可能性もあるため、このパラメータの使用にはセキュリティのリスクが伴います。

DATA_CACHE

デフォルトでは、(1000要素に対して)データ・キャッシュ機能が使用できます。データ・キャッシュ機能を完全に使用禁止にするには、0(ゼロ)に設定します。

DATA_CACHEは、データ・キャッシュ・サイズ(エントリ数)を指定します。たとえば、DATA_CACHE=5000を指定すると、作成されたデータ・キャッシュごとに最大5000の一意の日付エントリが含まれます。必要に応じて、すべての表に固有のデータ・キャッシュが作成されます。データ・キャッシュは、表への格納のためにデータ型変換が必要な日付値またはタイムスタンプ値が1つ以上ロードされた場合にのみ作成されます。

データ・キャッシュ機能は、デフォルトで使用可能です。デフォルトのデータ・キャッシュ・サイズは1000要素です。デフォルトのサイズを使用し、1000を超える一意の入力値をロードすると、データ・キャッシュ機能は、この表に対して自動的に使用禁止となります。ただし、デフォルトを変更して0以外のデータ・キャッシュ・サイズを指定し、キャッシュ量がこのサイズを超えた場合、キャッシュは使用禁止になりません。

ログ・ファイルに含まれているデータ・キャッシュ統計(エントリ数、ヒット数、ミス数)を使用して、将来、同様のロードを行うときのためにキャッシュのサイズを調整できます。

関連項目:

「データ・キャッシュの値の指定」

string

stringは、引用符で囲まれた一連の文字または16進数字です。一連の文字の場合、これらの文字はデータ・ファイルのキャラクタ・セットに変換されます。また、16進数字の場合には、偶数にする必要があります。16進数字は、バイナリに翻訳されたものに変換され、その翻訳結果はデータ・ファイルのキャラクタ・セット内の文字列として処理されます。これは、16進数字がバイナリに翻訳されたものに変換された後では、他のキャラクタ・セットの翻訳が実行されないことを意味します。 stringの構文は次のとおりです。

condition_spec

condition_specは、真または偽のいずれかに評価される式です。ブール演算子によって結合される1つ以上の条件を指定します。条件およびブール演算子は、左から右へと評価されます。(ブール演算子は、条件が評価された後に適用されます。)カッコを使用して、ブール演算子を評価するデフォルトの順序を変更できます。condition_spec句の評価にはより多くのレコード処理時間が必要であるため、多くの句を使用しないようにする必要があります。condition_specの構文は次のとおりです。

条件指定にフィールド名を参照する条件が含まれている場合、条件指定は、すべてのフィールドがレコードで検出され、空白の切捨てが行われた後のみに評価されます。空白がフィールドから切り捨てられている場合、フィールドとBLANKSの比較は有効ではありません。

次に、condition_specの使用例を示します。

empid = BLANKS OR last_name = BLANKS
(dept_id = SPORTING GOODS OR dept_id = SHOES) AND total_sales != 0

関連項目:

「condition」

[directory object name:] [filename]

この句を使用して、出力ファイル(BADFILE、DISCARDFILEまたはLOGFILE)の名前を指定します。ディレクトリ・オブジェクト名またはファイル名(あるいはその両方)を指定する必要があります。そのディレクトリ・オブジェクト名は、外部表にアクセスしているユーザーが書込み権限を所有しているディレクトリ・オブジェクトの名前です。このディレクトリ・オブジェクト名を指定しない場合、CREATE TABLE...ORGANIZATION EXTERNAL文のDEFAULT DIRECTORY句に対して指定した値が使用されます。

filenameパラメータは、ディレクトリ・オブジェクト内に作成するファイルの名前です。パラレル・ロードでファイル名を一意にするには、アクセス・ドライバで記号置換を行います。UNIXおよびWindowsオペレーティング・システムでサポートされる記号置換は、次のとおりです(その他のプラットフォームでは、別の記号が使用される場合があります)。

- %pは、現行のプロセスのプロセスIDに置換されます。たとえば、アクセス・ドライバのプロセスIDが12345の場合、exttab_%p.logは、exttab_12345.log.となります。

- %aは、現行のプロセスのエージェント番号に置換されます。エージェント番号は、外部表にアクセスしている各パラレル・プロセスに割り当てられた一意の番号です。この番号には、3文字になるように、左側に0が埋められます。たとえば、3番目のパラレル・エージェントがファイルを作成する場合、bad_data_%a.badをファイル名として指定した場合、エージェントはbad_data_003.badというファイルを作成します。

- %%は、%に置換されます。ファイル名にパーセント符号が必要な場合、この記号置換が使用されます。

%文字が検出され、前述の文字以外の文字がその後に続く場合、エラーが返されます。

%pまたは%aを使用しないで出力ファイルに対して一意のファイル名を作成し、外部表にパラレルでアクセス中の場合、出力ファイルが破損するか、エージェントがファイルに書込みをできないという問題が発生する場合があります。

BADFILE (またはDISCARDFILEかLOGFILE)を指定しない場合、アクセス・ドライバでは、表の名前に_%pを付けたものがファイル名として使用されます。ファイルに対して拡張子がない場合は、デフォルトの拡張子が使用されます。デフォルトの拡張子は、不良ファイルでは.bad、廃棄ファイルでは.dsc、ログ・ファイルでは.log となります。

condition

conditionを使用して、定数文字列とレコードのバイト範囲またはフィールドを比較します。比較のソースは、レコードのフィールドまたはレコードのバイト範囲のいずれかです。比較はバイト単位で実行されます。文字列を比較のターゲットとして指定すると、データ・ファイルのキャラクタ・セットに変換されます。フィールドに文字以外のデータ型が含まれる場合、フィールド値または文字列のどちらでもデータ型変換は実行されません。conditionの構文は次のとおりです。

range start : range end

この句を使用してレコードのバイト範囲または文字範囲を記述して条件を指定します。STRING SIZES ARE句に使用する値で、rangeがバイトを示すか、文字を示すかを決定します。range startおよびrange endは、レコードへのバイト・オフセットまたは文字オフセットです。range startは、range end以下である必要があります。文字範囲の検索は、可変幅キャラクタ・セットのデータに対してより固定幅キャラクタ・セットのデータに対しての方が速く処理されます。範囲が、存在しないレコードの一部を指す場合、その範囲を参照しようとするとレコードは拒否されます。range start:range endは、カッコで囲む必要があります。たとえば、(10:13)となります。

注意:

データ・ファイルには、バイナリ・データ(VARCHARなどのバイナリ・カウントのあるデータ型を含む)および文字データ(可変幅キャラクタ・セットが使用されているか、または文字幅が1バイトより大きいデータ)が混在しないようにする必要があります。この場合、アクセス・ドライバは、開始位置の検索時にバイナリ・データを文字データとして処理するため、フィールドの適切な開始位置を検索できない場合があります。

次に、conditionの使用例を示します。

LOAD WHEN empid != BLANKS
LOAD WHEN (10:13) = 0x'00000830'
LOAD WHEN PRODUCT_COUNT = "MISSING"

IO_OPTIONS句

IO_OPTIONS句によって、オペレーティング・システムがデータ・ファイルを読み取るために使用するI/Oオプションを指定できます。

指定可能なオプションはDIRECTIO (デフォルト)とNODIRECTIOのみです。

DIRECTIOオプションはデフォルトで使用され、直接I/Oを使用してデータ・ファイルのオープンおよび読取りが試行されます。試行が成功した場合、オペレーティング・システムとNFSサーバー(ファイルがNFSサーバー上にあるとき)では、ファイルから読み取ったデータをキャッシュしません。これにより、特にファイルが大きい場合に、データ・ファイルの読取りパフォーマンスが向上します。読取り対象のデータ・ファイルについて直接I/Oがサポートされない場合、ファイルは開かれて読み取られますがDIRECTIOオプションは無視されます。

IO_OPTIONS句にNODIRECTIOオプションが指定されている場合は、データ・ファイルの読取りに直接I/Oは使用されません。

IO_OPTIONS句が指定されていない場合は、デフォルトのDIRECTIOオプションが使用されます。

DNFS_DISABLE | DNFS_ENABLE

これらのパラメータを使用して、外部表操作中の入力データ・ファイルに対するDirect NFSクライアントの使用を有効化および無効化できます。

Direct NFSクライアントは、Oracleがファイル・サーバー上のファイルにアクセスする際のパフォーマンスを向上するために、ファイル・サーバーで実装できるAPIです。

外部表では、1GBを超えるデータ・ファイルを読み取る場合にデフォルトでDirect NFSクライアント・インタフェースが使用されます。よりサイズの小さいファイルでは、オペレーティング・システムのI/Oインタフェースが使用されます。すべての入力データ・ファイルでDirect NFSクライアントを使用するには、DNFS_ENABLEを使用します。

すべてのデータ・ファイルでDirect NFSクライアントの使用を無効にするには、DNFS_DISABLEを指定します。

関連項目:

- NFSでDirect NFSクライアントのOracle Disk Manager Controlを有効化する方法の詳細は、『Oracle Grid Infrastructureインストレーション・ガイドfor Linux』を参照してください。

DNFS_READBUFFERS

DNFS_READBUFFERSを使用して、Direct NFSクライアントによって使用される読取りバッファの数を制御できます。Direct NFSクライアントは、Oracleがファイル・サーバー上のファイルにアクセスする際のパフォーマンスを向上するために、ファイル・サーバーで実装できるAPIです。

DNFS_READBUFFERSのデフォルト値は4です。

より大きい値を使用すると、Direct NFSクライアント・ファイル・サーバーからの一貫性のないI/Oに対処できますが、メモリー使用量が増大する可能性があります。

関連項目:

- NFSでDirect NFSクライアントのOracle Disk Manager Controlを有効化する方法の詳細は、『Oracle Grid Infrastructureインストレーション・ガイドfor Linux』を参照してください。

field_definitions句

field_definitions句では、FIELDSパラメータを使用してデータ・ファイルのフィールドに名前を付け、それらのレコード内での検索方法を指定します。

field_definitions句が省略された場合、次のことが想定されます。

- フィールドは「,」で区切られる

- フィールドのデータ型はCHARである

- フィールドの最大長は255である

- データ・ファイルのフィールドの順序は、外部表で定義されたフィールドの順序となる

- 空白はフィールドから切り捨てられない。

次に、アクセス・パラメータを含まずに作成する外部表の例を示します。その後に、外部表をロードするために使用できるデータ・ファイルのサンプルinfo.datを示します。

CREATE TABLE emp_load (first_name CHAR(15), last_name CHAR(20), year_of_birth CHAR(4))
ORGANIZATION EXTERNAL (TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tab_dir LOCATION ('info.dat'));

Alvin,Tolliver,1976
Kenneth,Baer,1963

field_definitions句の構文は次のとおりです。

IGNORE_CHARS_AFTER_EOR

オプションのこのパラメータは、最後のエンドオブレコードの後、かつエンドオブファイルより前に、レコードの定義に一致しない不要な文字が見つかった場合、その文字を無視するように指定します。

次の4つの条件がすべて当てはまると、エラー・メッセージが外部表のログ・ファイルに書き込まれます。

- IGNORE_CHARS_AFTER_EORパラメータが設定されているか、フィールドが自由書式可能になっている(自由書式可能とは、フィールドが可変長であるか、フィールドがデリミタまたは囲み文字で指定されていて可変長であるかのいずれかです)。

- 文字がファイル内の最後のエンドオブレコードの後にある。

- アクセス・パラメータMISSING FIELD VALUES ARE NULLが設定されていない。

- フィールドに絶対位置が設定されていない。

外部表のログ・ファイルに書き込まれるエラー・メッセージは次のとおりです。

KUP-04021: field formatting error for field Col1
KUP-04023: field start is after end of record
KUP-04101: record 2 rejected in file /home/oracle/datafiles/example.dat

CSV

外部表でカンマ区切り値形式のファイルであるデータ・ファイルにアクセスするには、FIELDS CSV句を使用します。これによって、ファイルは、通常の改行文字列(たとえば、UNIXまたはLinuxオペレーティング・システムの場合は\n、Windowsオペレーティング・システムの場合は\nまたは\r\n)を含むストリーム・レコード形式のファイルであるとみなされます。データ値にはレコード終了記号含める(埋め込む)ことができます。FIELDS CSV句の構文は次のとおりです。

FIELDS CSV [WITH EMBEDDED | WITHOUT EMBEDDED] [TERMINATED BY ','] [OPTIONALLY ENCLOSED BY '"']

FIELDS CSV句の主なポイントは次のとおりです。

- デフォルトでは、FIELDS CSV句を使用しません。

- WITH EMBEDDEDおよびWITHOUT EMBEDDEDオプションでは、データにレコード終了記号が含まれている(埋め込まれている)かどうかを指定します。WITH EMBEDDEDオプションがデフォルトです。

- WITH EMBEDDEDを使用する場合、埋込みのレコード終了記号は囲む必要があり、データ・ファイル内の並列度は外部表ロードでは無効になります。

- TERMINATED BY ','およびOPTIONALLY ENCLOSED BY '"'オプションはデフォルトのため、指定する必要はありません。これらは別の終了記号や囲み文字で上書きできます。

- CSV句を使用する場合、フィールド・レベルでのデリミタ指定は許可されず、区切ることが可能なデータ型のみ許可されます。区切ることが可能なデータ型には、CHAR、日時、期間および数値型EXTERNALが含まれます。

- CSV句を指定する場合、TERMINATED BYおよびENCLOSED BY句は、フィールド・レベルでは使用できません。

- CSV句を指定する場合、デフォルトの切捨て動作はLDRTRIMです。これを上書きするには、外部表の他の切捨てオプション(NOTRIM、LRTRIM、LTRIMまたはRTRIM)のいずれかを指定します。

- CSV句は、IGNORE_CHARS_AFTER_EOR句の後で、delim_spec句の前に指定する必要があります。

delim_spec句

delim_spec句を使用して、レコード内のすべてのフィールドの終了位置を識別します。すべてのフィールドに指定されるdelim_specは、特定のフィールドに対してfield_list句の一部として上書きできます。構文の詳細は、「delim_spec」を参照してください。

trim_spec句

trim_spec句を使用して、すべての文字フィールドでデフォルトとして実行される空白の切捨てタイプを指定します。すべてのフィールドに指定されるtrim_spec句は、個々のフィールドに対してtrim_spec句を指定して上書きできます。構文の詳細は、「trim_spec」を参照してください。

ALL FIELDS OVERRIDE

ALL FIELDS OVERRIDE句では、アクセス・ドライバに対し、すべてのフィールドが存在し、それらが外部表の列と同じ順序であることを示します。特殊な定義が含まれるフィールドを指定するだけで済みます。この句は、オプションのtrim_spec句の後で、オプションのMISSING FIELD VALUES ARE NULL句の前に指定する必要があります。

次に、ALL FIELDS OVERRIDE句の使用例を示します。指定する必要のあるフィールドはHIREDATEのみで、これは日付書式マスクを必要とします。他のすべてのフィールドはデフォルト値を使用します。

FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY '"' LDRTRIM
ALL FIELDS OVERRIDE
REJECT ROWS WITH ALL NULL FIELDS
(
HIREDATE CHAR(20) DATE_FORMAT DATE MASK "DD-Month-YYYY"
)

MISSING FIELD VALUES ARE NULL

MISSING FIELD VALUES ARE NULLは、位置が明示的に示されておらず、入力するのに十分なデータがないフィールドをNULLに設定します。詳細は、「MISSING FIELD VALUES ARE NULL」を参照してください。

REJECT ROWS WITH ALL NULL FIELDS

REJECT ROWS WITH ALL NULL FIELDSは、行内で参照されるすべてのフィールドがNULLの場合、その行が外部表にロードされないことを示します。このパラメータを指定しない場合、デフォルト値が使用され、すべてのフィールドがNULLの行が外部表にロードされます。このパラメータの設定は、「reject rows with all null fields」または「rows with all null fields are accepted」としてログ・ファイルに書き込まれます。

DATE_FORMAT

DATE_FORMAT句では、フィールド・レベルで日時書式マスクを一度指定することで、指定された独自のマスクのないそのタイプのすべてのフィールドにそれを適用できます。日時書式マスクは、オプションのREJECT ROWS WITH ALL NULL FIELDS句の後で、fields_list句の前に指定する必要があります。

DATE_FORMATは、日時データ型のDATE、TIME、TIME WITH TIME ZONE、TIMESTAMPおよびTIMESTAMP WITH TIME ZONEで指定できます。

次に、任意のDATE型フィールドにDD-Month-YYYYの日付マスクを適用するDATE_FORMAT句の使用例を示します。

FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY '"' LDRTRIM
REJECT ROWS WITH ALL NULL FIELDS
DATE_FORMAT DATE MASK "DD-Month-YYYY"

(
EMPNO,
ENAME,
JOB,
MGR,
HIREDATE CHAR(20),
SAL,
COMM,
DEPTNO,
PROJNO,
ENTRYDATE CHAR(20)
)

NULLIF | NO NULLIF

NULLIF句は、すべての文字フィールド(CHAR、VARCHAR、VARCHARC、外部NUMBER、日時など)に適用されます。

構文は次のとおりです:

NULLIF {=|!=}{"char_string"|x'hex_string'|BLANKS}

フィールドに対する等号または不等号の指定を使用して一致した場合、フィールドはその行でNULLに設定されます。

char_stringおよびhex_stringは、一重引用符または二重引用符で囲む必要があります。

NULLIFは、フィールド・レベルで指定されると、このNULLIF句に優先します。

NULLIF句を適用しないフィールドがある場合、フィールド・レベルでNO NULLIFを指定できます(次の例を参照)。

NULLIF句は、オプションのREJECT ROWS WITH ALL NULL FIELDS句の後で、fields_list句の前に指定する必要があります。

次に、NULLIF句の使用例を示します。MGRフィールドは、NULLIF="NONE"句をそのフィールドに適用しないようにするNO NULLIFに設定されます。

FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY '"' LDRTRIM
REJECT ROWS WITH ALL NULL FIELDS
NULLIF = "NONE"
(
EMPNO,
ENAME,
JOB,
MGR
)

field_list句

field_list句を使用して、データ・ファイルのフィールドおよびそのデータ型を識別します。構文の詳細は、「field_list」を参照してください。

delim_spec

delim_spec句を使用して、フィールドの終了位置(ENCLOSED BYを指定する場合は、開始位置)を検索します。構文は次のとおりです。

ENCLOSED BYを指定すると、アクセス・ドライバで、レコードの現在の位置から最初のデリミタまでの間のすべての空白がスキップされます。現在の位置と最初のデリミタの間のすべての空白が無視されます。次に、アクセス・ドライバでは、2番目の囲みデリミタが検索されます(または、2番目のデリミタが指定されていない場合は、最初のデリミタがもう1度検索されます)。これら2つのデリミタの間にあるすべての文字がフィールド部分とみなされます。

TERMINATED BY stringをENCLOSED BY句で指定する場合、終了記号文字列は、2番目の囲みデリミタの直後に置く必要があります。2番目の囲みデリミタと終了デリミタの間の空白はスキップされます。2つのデリミタの間で空白以外の文字が検索される場合、正しく書式化されていないため行が拒否されます。

ENCLOSED BY句を使用せずにTERMINATED BYを指定する場合、レコードの現在の位置と次に検索される終了記号文字列の間にあるすべての文字がフィールド部分とみなされます。

OPTIONALLYを指定する場合は、TERMINATED BYも指定する必要があります。OPTIONALLYパラメータによって、ENCLOSED BYデリミタは、両方存在するかまたは両方存在しないかのいずれかであることが示されます。終了デリミタは、ENCLOSED BYデリミタの有無にかかわらず存在する必要があります。OPTIONALLYを指定する場合、アクセス・ドライバは、最初の空白以外の文字までのすべての空白をスキップします。最初の空白以外の文字が検索されると、アクセス・ドライバは、現在の位置に最初の囲みデリミタが含まれているかどうかを確認します。含まれている場合は、アクセス・ドライバによって2番目の囲み文字列が検索され、最初の囲みデリミタと2番目の囲みデリミタの間のすべての文字がフィールド部分とみなされます。終了デリミタは、2番目の囲みデリミタの直後に置く必要があります(2番目の囲みデリミタと終了デリミタの間にオプションで空白を置くことも可能)。最初の空白以外の文字が最初の囲み文字列ではない場合、アクセス・ドライバは終了デリミタを検索します。この場合、先頭の空白は切り捨てられます。

関連項目:

アクセス・ドライバのデフォルトの切捨て動作の詳細は、表10-5を参照してください。LTRIMおよびRTRIMを使用すると、この動作を変更できます。

デリミタが検出された後、レコードの現在の位置は、フィールドの最後のデリミタの後に設定されます。TERMINATED BY WHITESPACEを指定した場合、レコードの現在の位置は、フィールドの後に続くすべての空白の後に設定されます。

レコードの最後のフィールドで終了記号が欠落している場合は、エラーではありません。アクセス・ドライバは、終了記号が検出された場合と同様に処理を行います。2番目の囲みデリミタが欠落している場合は、エラーとなります。

2番目の囲みに使用される文字列は、2番目の囲みを2回続けることによって、データ・フィールドに含むことができます。たとえば、フィールドが一重引用符で囲まれる場合、次の例のdon'tという単語で示すような方法で一重引用符を2つ並べて指定することによって、フィールドに一重引用符を含むことができます。

'I don''t like green eggs and ham'

囲みデリミタを使用せずに、データ・フィールドの終了文字列を引用符で囲む方法はありません。フィールドに終了デリミタを含むことができるのは、フィールド・パーサーが囲みデリミタを検出するまで終了デリミタを検索しないためです。

通常、1文字の文字列は、複数文字の文字列より速く指定できます。また、固定幅キャラクタ・セットのデータは、可変幅のキャラクタ・セットよりも速く検索できます。

注意:

外部表では、文字列内のバックスラッシュ(\)の使用はサポートされていません。

例: 終了デリミタを含む外部表

次に、終了デリミタが使用されている外部表の例を示します。その後に、ロードが可能なデータ・ファイルのサンプルを示します。

CREATE TABLE emp_load (first_name CHAR(15), last_name CHAR(20), year_of_birth CHAR(4))
ORGANIZATION EXTERNAL (TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS (FIELDS TERMINATED BY WHITESPACE)
LOCATION ('info.dat'));

Alvin Tolliver 1976
Kenneth Baer 1963
Mary Dube 1973

例: 囲みデリミタおよび終了デリミタを含む外部表

次に、囲みデリミタと終了デリミタの両方を使用する外部表の例を示します。2番目の囲みデリミタと終了記号の間のすべての空白が無視されるのと同様に、終了文字列と最初の囲み文字列の間のすべての空白も無視されます。この例の後に、ロードが可能なデータ・ファイルのサンプルを示します。

CREATE TABLE emp_load (first_name CHAR(15), last_name CHAR(20), year_of_birth CHAR(4))
ORGANIZATION EXTERNAL (TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS (FIELDS TERMINATED BY "," ENCLOSED BY "("  AND ")")
LOCATION ('info.dat'));

(Alvin) ,   (Tolliver),(1976)
(Kenneth),  (Baer) ,(1963)
(Mary),(Dube) ,   (1973)

例: オプションの囲みデリミタを含む外部表

次に、オプションの囲みデリミタを使用する外部表の例を示します。フィールドの先頭および後続の空白を切り捨てるために、LRTRIMを使用していることに注意してください。この例の後に、ロードが可能なデータ・ファイルのサンプルを示します。

CREATE TABLE emp_load (first_name CHAR(15), last_name CHAR(20), year_of_birth CHAR(4))
ORGANIZATION EXTERNAL (TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS (FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '(' and ')'
LRTRIM)
LOCATION ('info.dat'));

Alvin ,   Tolliver , 1976
(Kenneth),  (Baer), (1963)
( Mary ), Dube ,    (1973)

trim_spec

trim_spec句を使用して、空白をテキスト・フィールドの始めから切り捨てるか、終わりから切り捨てるか、またはその両方から切り捨てるかを指定します。空白には、空白文字およびその他の印字されない文字(タブ、LF、改行など)が含まれます。 trim_spec句の構文は次のとおりです。

フィールドから文字を切り捨てない場合は、NOTRIMを使用します。

フィールドから文字を切り捨てる場合は、LRTRIM、LTRIMおよびRTRIMを使用します。LRTRIMを使用すると、先頭と後続の空白の両方が切り捨てられます。先頭の空白を切り捨てるには、LTRIMを使用します。後続の空白を切り捨てるには、RTRIMを使用します。

SQL*Loaderの切捨て機能との互換性を保つには、LDRTRIMを使用します。次の場合を除いて、NOTRIMと同様です。

- フィールドがデリミタ付きのフィールドではない場合、空白は右から切り捨てられる。

- フィールドがOPTIONALLY ENCLOSED BYで指定されたデリミタ付きフィールドで、オプションの囲みが特定のインスタンスで欠落している場合、空白は左から切り捨てられる。

デフォルトは、LDRTRIMです。NOTRIMを指定すると、パフォーマンスが向上します。

trim_spec句をフィールド・リストの前に指定して、デフォルトの切捨てをすべてのフィールドに設定できます。trim_specがフィールド・リストの前で指定されない場合、LDRTRIMが、デフォルトの切捨て設定となります。デフォルトの切捨ては、個々のフィールドに対してdatatype_specの一部として上書きできます。

すべてが空白のフィールドに対して切捨てを指定する場合、そのフィールドはNULLに設定されます。

次の例では、すべてのデータが固定長です。ただし、先頭に空白がある文字データはロードできません。この例の後に、ロードが可能なデータ・ファイルのサンプルを示します。

CREATE TABLE emp_load (first_name CHAR(15), last_name CHAR(20),
year_of_birth CHAR(4))
ORGANIZATION EXTERNAL (TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS (FIELDS LTRIM)
LOCATION ('info.dat'));

Alvin,           Tolliver,1976
Kenneth,         Baer,    1963
Mary,            Dube,    1973

MISSINGFIELDVALUESARENULL

MISSING FIELD VALUES ARE NULLの影響は、POSITIONがフィールド位置を明示的に示すために使用されているかどうかによって、次のように異なります。

- デフォルトの動作では、フィールド位置が明示的に示されておらず、レコードのすべてのフィールドに十分なデータがない場合、レコードは拒否されます。この動作を変更するには、MISSING FIELD VALUES ARE NULLを使用して、使用可能なデータがないフィールドをNULLとして定義します。

- フィールド位置が明示的に示されている場合、MISSING FIELD VALUES ARE NULLが使用されているかどうかにかかわらず、常に、値のないフィールドはNULLとして定義されます。

次の例で、2番目のレコードは、生まれた年のデータがデータ・ファイルから欠落していても、year_of_birth 列に対しNULLに設定されて格納されます。MISSING FIELD VALUES ARE NULL句をアクセス・パラメータで指定しない場合、year_of_birth列の値が含まれていない2番目のレコードが拒否されます。この例の後に、ロードが可能なデータ・ファイルのサンプルを示します。

CREATE TABLE emp_load (first_name CHAR(15), last_name CHAR(20), year_of_birth INT)
ORGANIZATION EXTERNAL (TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS (FIELDS TERMINATED BY ","
MISSING FIELD VALUES ARE NULL)
LOCATION ('info.dat'));

Alvin,Tolliver,1976
Baer,Kenneth
Mary,Dube,1973

field_list

field_list句を使用して、データ・ファイルのフィールドおよびそのデータ型を識別します。field_list句では、次のように評価します。

- フィールドにいずれのデータ型も指定されない場合、データ型は、デリミタなしフィールドではCHAR(1)、デリミタ付きフィールドではCHAR(255)である。

- いずれのフィールド・リストも指定されない場合、データ・ファイルのフィールドは外部表と同じ順序である。データベースの列がCHARまたはVARCHARではない場合、すべてのフィールドのデータ型は、CHAR(255)となる。データベースの列がCHARまたはVARCHARの場合、フィールドのデータ型はCHARのままであるが、その長さは255か列の長さでいずれか長い方の値となる。

- いずれのフィールド・リストも指定されず、delim_spec句も指定されない場合、データ・ファイルのフィールドは外部表のフィールドと同じ順序である。すべてのフィールドは、CHAR(255)であり、カンマで終了する。

次の例では、field_listおよびdelim_specを含まない外部表の定義を示します。その後に、ロードが可能なデータ・ファイルのサンプルを示します。

CREATE TABLE emp_load (first_name CHAR(15), last_name CHAR(20), year_of_birth INT)
ORGANIZATION EXTERNAL (TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS (FIELDS TERMINATED BY "|")
LOCATION ('info.dat'));

Alvin|Tolliver|1976
Kenneth|Baer|1963
Mary|Dube|1973

field_list句の構文は次のとおりです。

field_name

field_nameは、データ・ファイルのフィールド名を識別する文字列です。文字列が引用符内にない場合、フィールド名は外部表の列名に一致され、大文字になります。

field_nameが問合せで参照される外部表の列名と一致する場合は、このフィールド値が外部表列の値に使用されます。名前が外部表で参照されたいずれの名前にも一致しない場合、フィールドはロードされません。ただし、このフィールドは句の評価(たとえば、WHENまたはNULLIF)には使用できます。

pos_spec

pos_spec句を使用して、レコード内の列の位置を指定します。構文の詳細は、「pos_spec句」を参照してください。

datatype_spec

datatype_spec句を使用して、フィールドのデータ型を指定します。datatype_specが指定されない場合、アクセス・ドライバは、データ型はCHAR(255)であると想定します。構文の詳細は、「datatype_spec句」を参照してください。

init_spec

init_spec句を使用して、フィールドがNULLになる、またはデフォルトの値を設定されるタイミングを指定します。構文の詳細は、「init_spec句」を参照してください。

pos_spec句

pos_spec句を使用して、レコード内の列の位置を指定します。STRING SIZES ARE IN句を設定して、pos_specがバイト位置と文字位置のどちらを参照するかを決定します。可変幅キャラクタ・セットで文字位置を使用すると、固定幅キャラクタ・セットで文字位置を使用するより大幅に時間がかかります。pos_specが文字位置に使用されると、バイナリ文字データとマルチバイト文字データは、同じデータ・ファイルには指定できません。指定した場合の結果は保証されません。pos_spec句の構文は次のとおりです。

開始

startパラメータは、レコードの開始位置からフィールドの開始位置までのバイト数または文字数です。前のフィールド位置からの相対ではなく、レコードの絶対位置でフィールドの開始位置を設定します。

*

*パラメータで、フィールドが前のフィールドの直後のバイトまたは文字から始まることを指定します。これは、可変長フィールドの後に固定長フィールドが続く場合に有効です。このオプションは、レコードの最初のフィールドには使用できません。

increment

incrementパラメータを使用して、フィールドの開始位置を前のフィールドの終了位置からの固定のバイト数または固定の文字数で設定します。*-incrementを使用して、フィールドの開始位置をレコードの現在の位置の前に指定します。*+incrementを使用して、開始位置を現在の位置の後に移動します。

end

endパラメータを使用して、フィールドの終了バイトをレコード内の絶対バイトまたは絶対文字オフセットで指定します。startをendとともに指定する場合、endは、startより小さくできません。*またはincrementをendとともに指定し、startが特定のレコードのendより大きいオフセットと評価された場合、レコードは拒否されます。

length

lengthパラメータで、フィールドの終了位置を開始位置からの固定のバイト数または文字数で指定します。開始位置を*で指定すると、固定長フィールドに有効です。

次に、pos_specの使用例を示します。その後に、ロードが可能なデータ・ファイルのサンプルを示します。

CREATE TABLE emp_load (first_name CHAR(15),
last_name CHAR(20),
year_of_birth INT,
phone CHAR(12),
area_code CHAR(3),
exchange CHAR(3),
extension CHAR(4))
ORGANIZATION EXTERNAL
(TYPE ORACLE_LOADER
DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS
(FIELDS RTRIM
(first_name (1:15) CHAR(15),
last_name (*:+20),
year_of_birth (36:39),
phone (40:52),
area_code (*-12: +3),
exchange (*+1: +3),
extension (*+1: +4)))
LOCATION ('info.dat'));

Alvin          Tolliver            1976415-922-1982
Kenneth        Baer                1963212-341-7912
Mary           Dube                1973309-672-2341

datatype_spec句

datatype_spec句を使用して、データ型がデフォルトと異なる場合にデータ・ファイルのフィールドのデータ型を記述します。フィールドのデータ型は、外部表の対応する列のデータ型とは異なる場合があります。アクセス・ドライバで必要な変更が行われます。datatype_spec句の構文は次のとおりです。

フィールドのバイト数または文字数が0の場合、フィールドはNULLであると想定されます。オプションのDEFAULTIF句を使用して、フィールドをデフォルトの値に設定するタイミングを指定します。また、オプションのNULLIF句で、フィールドに対応付けられた列をNULLに設定するタイミングに関するその他の条件を指定します。DEFAULTIF句またはNULLIF句がTRUEの場合、これらの句を使用すると、データ・ファイルから読み込まれるすべての値が上書きされます。

関連項目:

- NULLIFおよびDEFAULTIFの詳細は、「init_spec句」を参照してください

- データ・タイプの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

[UNSIGNED] INTEGER [EXTERNAL] [(len)]

この句を使用して、フィールドを整数として定義します。EXTERNALを指定する場合、数値は文字列で指定します。EXTERNALを指定しない場合、数値はバイナリ・フィールドです。2進整数フィールドのlenに対する有効な値は、1、2、4および8です。lenが2進整数で指定されていない場合、デフォルトの値は、アクセス・ドライバが実行されているプラットフォーム上のsizeof(int)の値です。DATA IS {BIG | LITTLE} ENDIAN句を使用すると、データは格納される前にバイト・スワップされます。

EXTERNALを指定する場合、lenの値は、(STRING SIZES ARE IN BYTES句またはCHARACTERS句の設定に応じて)バイト数または文字数を数値で指定します。長さを指定しない場合、デフォルト値は255になります。

[UNSIGNED] INTEGER [EXTERNAL] [(len)]データ型のデフォルト値は、次のように決定されます。

- 長さを指定しない場合、デフォルトの長さは1になります。

- 長さを指定せず、フィールドがDELIMITED BY NEWLINE句で区切られている場合、デフォルトの長さは1になります。

- 長さを指定せず、フィールドがDELIMITED BY句で区切られている場合、デフォルトの長さは255になります(ただし、前述のとおりデリミタがNEWLINEでない場合)。

DECIMAL [EXTERNAL]およびZONED [EXTERNAL]

DECIMAL句を使用して、フィールドがPACKED型の10進数であることを指定します。ZONED句を使用して、フィールドがZONED型の10進数であることを指定します。precisionフィールドで、数値の桁数を指定します。scaleフィールドで、数値の小数点の位置を指定します。つまり、小数点の右側にくる桁数を指定します。scaleを指定しない場合、値は0となります。

使用中のキャラクタ・セットがEBCDICベースかASCIIベースかによって、ZONED型の10進数には異なるエンコーディング形式があることに注意してください。ソース・データの言語がEBCDICの場合、そのファイルのZONED型の10進数は、EBCDICエンコーディングと一致する必要があります。言語がASCIIベースの場合、その数値はASCIIエンコーディングと一致する必要があります。

EXTERNALパラメータを指定する場合、データ・フィールドは、その長さがフィールドの精度と一致する文字列です。

ORACLE_DATE

ORACLE_DATEは、Oracleバイナリ日付フォーマットの日付を含むフィールドであることを指定します。これは、Oracle Call Interface (OCI)プログラムでは、DTYDATデータ型として使用される形式です。固定長7のフィールドです。

ORACLE_NUMBER

ORACLE_NUMBERは、Oracle数値書式の数値を含むフィールドであることを指定します。COUNTEDを指定しないかぎり、フィールドは固定長(Oracle数値フィールドの最大サイズ)です。その場合、フィールドの最初のバイトには残りのフィールドのバイト数が含まれます。

ORACLE_NUMBERは、固定長22バイトのフィールドです。ORACLE_NUMBER COUNTEDフィールドの長さは、カウント・バイト用の1バイトに、カウント・バイトで指定されたバイト数を加えた長さです。

浮動小数点数

DOUBLE、FLOAT、BINARY_DOUBLEおよびBINARY_FLOATのデータ型は、浮動小数点数です。

DOUBLEおよびFLOATは、プラットフォームで固有に使用される浮動小数点形式です。これらは、そのプラットフォームのCプログラムのDOUBLEおよびFLOATデータ型でデフォルトで使用されるものと同じデータ型です。BINARY_FLOATおよびBINARY_DOUBLEは浮動小数点数であり、実質的にInstitute for Electrical and Electronics Engineers (IEEE) Standard for Binary Floating-Point Arithmetic、IEEE規格754-1985に準拠しています。ほとんどのプラットフォームでは、固有の浮動小数点形式としてIEEE規格を使用しているため、FLOATとBINARY_FLOATは、プラットフォーム上では同様となります。また、DOUBLEとBINARY_DOUBLEも同様となります。

注意:

浮動小数点数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

DOUBLE

DOUBLE句を使用して、フィールドが、アクセス・ドライバが実行されているプラットフォーム上のC言語のDOUBLEデータ型と同じ形式であることを指定します。DATA IS {BIG | LITTLE} ENDIAN句を使用すると、データは格納される前にバイト・スワップされます。このデータ型は特定のプラットフォーム間では移植できません。

FLOAT [EXTERNAL]

FLOAT句を使用して、フィールドが、アクセス・ドライバが実行されているプラットフォーム上のC言語のFLOATデータ型と同じ形式であることを指定します。DATA IS {BIG | LITTLE} ENDIAN句を使用すると、データは格納される前にバイト・スワップされます。このデータ型は特定のプラットフォーム間では移植できません。

EXTERNALパラメータを指定する場合、フィールドは、最大長255の文字列です。

BINARY_DOUBLE

BINARY_DOUBLEは、64ビットの倍精度浮動小数点数データ型です。各BINARY_DOUBLE値では、長さを示すバイトを含め9バイトを必要とします。浮動小数点数の詳細は、FLOATデータ型の注意に関する情報を参照してください。

BINARY_FLOAT

BINARY_FLOATは、32ビットの単精度浮動小数点数データ型です。各BINARY_FLOAT値では、長さを示すバイトを含め5バイトを必要とします。浮動小数点数の詳細は、FLOATデータ型の注意に関する情報を参照してください。

RAW

RAW句を使用して、ソース・データがバイナリ・データであることを指定します。RAWフィールドに対するlenは常にバイト単位です。RAWフィールドがキャラクタ列にロードされると、列に書き込まれるデータは、RAWフィールドのバイトの16進表現となります。

CHAR

CHAR句を使用して、フィールドが文字データ型であることを指定します。CHARフィールドの長さ(len)で、フィールドの最大バイト数または最大文字数を指定します。lenは、STRING SIZES ARE IN句の設定に応じて、バイト単位または文字単位になります。

CHARデータ型のフィールドに長さを指定しない場合、フィールドが区切られていないかぎり、フィールド・サイズは1になります。

- デリミタ付きCHARフィールドでは、長さが指定されている場合、その長さが最大長として使用されます。

- 長さが指定されていないデリミタ付きCHARフィールドでは、デフォルトの255バイトが使用されます。

- デリミタ付きで255バイトを超えるCHARフィールドには、最大長を指定する必要があります。指定しない場合は、データ・ファイルのフィールドが最大長を超えているというエラーを受信します。

次に、CHAR句の使用例を示します。

SQL> CREATE TABLE emp_load
2    (employee_number      CHAR(5),
3     employee_dob         CHAR(20),
4     employee_last_name   CHAR(20),
5     employee_first_name  CHAR(15),
6     employee_middle_name CHAR(15),
7     employee_hire_date   DATE)
8  ORGANIZATION EXTERNAL
9    (TYPE ORACLE_LOADER
10     DEFAULT DIRECTORY def_dir1
11     ACCESS PARAMETERS
12       (RECORDS DELIMITED BY NEWLINE
13        FIELDS (employee_number      CHAR(2),
14                employee_dob         CHAR(20),
15                employee_last_name   CHAR(18),
16                employee_first_name  CHAR(11),
17                employee_middle_name CHAR(11),
18                employee_hire_date   CHAR(10) date_format DATE mask "mm/dd/yyyy"
19               )
20       )
21     LOCATION ('info.dat')
22    );

Table created.

date_format_spec

date_format_spec句を使用して、特定の形式の日付データまたは時刻データ(またはその両方)が文字列フィールドに含まれることを指定します。この情報は、文字フィールドが日付データ型または時刻データ型に変換される場合、および文字列フィールドが日付列にマップされる場合のみに使用されます。

日付と時刻の書式を正しく指定する方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

date_format_spec句の構文は次のとおりです。

DATE

DATE句を使用して、文字列に日付が含まれることを指定します。

MASK

MASK句を使用して、データ型に対するデフォルトのグローバリゼーション書式マスクを上書きします。日付マスクを指定しない場合は、データ型に対する適切なグローバリゼーション・パラメータのデータベースのNLSパラメータ設定(セッションの設定ではない)が使用されます。NLS_DATABASE_PARAMETERSビューに、これらの設定が表示されます。

- NLS_DATE_FORMAT (DATEデータ型)

- NLS_TIMESTAMP_FORMAT (TIMESTAMPデータ型)

- NLS_TIMESTAMP_TZ_FORMAT (TIMESTAMP WITH TIME ZONEデータ型)

以下の点に注意する必要があります。

- NLS_NUMERIC_CHARACTERS初期化パラメータのデータベース設定(NLS_DATABASE_PARAMETERSビューの設定)によって、文字データ型から数値データ型への暗黙的な変換に使用される小数点区切りが制御されます。

- デフォルトの書式では、桁区切りは使用できません。

TIMESTAMP

TIMESTAMP句を使用して、書式化されたタイムスタンプがフィールドに含まれることを指定します。

INTERVAL

INTERVAL句を使用して、フィールドに書式化された期間が含まれることを指定します。期間の型は、YEAR TO MONTHまたはDAY TO SECONDのいずれかです。

次に、複雑なDATE文字列とTIMESTAMP文字列の使用例を示します。その後に、ロードが可能なデータ・ファイルのサンプルを示します。

SQL> CREATE TABLE emp_load
2    (employee_number      CHAR(5),
3     employee_dob         CHAR(20),
4     employee_last_name   CHAR(20),
5     employee_first_name  CHAR(15),
6     employee_middle_name CHAR(15),
7     employee_hire_date   DATE,
8     rec_creation_date    TIMESTAMP WITH TIME ZONE)
9  ORGANIZATION EXTERNAL
10    (TYPE ORACLE_LOADER
11     DEFAULT DIRECTORY def_dir1
12     ACCESS PARAMETERS
13       (RECORDS DELIMITED BY NEWLINE
14        FIELDS (employee_number      CHAR(2),
15                employee_dob         CHAR(20),
16                employee_last_name   CHAR(18),
17                employee_first_name  CHAR(11),
18                employee_middle_name CHAR(11),
19                employee_hire_date   CHAR(22) date_format DATE mask "mm/dd/yyyy hh:mi:ss AM",
20                rec_creation_date    CHAR(35) date_format TIMESTAMP WITH TIME ZONE mask "DD-MON-RR HH.MI.SSXFF AM TZH:TZM"
21               )
22       )
23     LOCATION ('infoc.dat')
24    );

Table created.

SQL> SELECT * FROM emp_load;

EMPLO EMPLOYEE_DOB         EMPLOYEE_LAST_NAME   EMPLOYEE_FIRST_ EMPLOYEE_MIDDLE
----- -------------------- -------------------- --------------- ---------------
EMPLOYEE_
---------
REC_CREATION_DATE
---------------------------------------------------------------------------
56    november, 15, 1980   baker                mary            alice
01-SEP-04
01-DEC-04 11.22.03.034567 AM -08:00

87    december, 20, 1970   roper                lisa            marie
01-JAN-02
01-DEC-02 02.03.00.678573 AM -08:00

2 rows selected.

info.dat ファイルの内容は、次のようになります。これは、2つの長いレコードです。日付フィールド(09/01/2004、01/01/2002)とそれに続く時刻フィールドの間には、空白が1つあります。

56november, 15, 1980  baker             mary       alice      09/01/2004 08:23:01 AM01-DEC-04 11.22.03.034567 AM -08:00
87december, 20, 1970  roper             lisa       marie      01/01/2002 02:44:55 PM01-DEC-02 02.03.00.678573 AM -08:00

VARCHARおよびVARRAW

VARCHARデータ型には、文字データが後に続くバイナリ・カウント・フィールドが含まれます。バイナリ・カウント・フィールドの値は、フィールドのバイト数または文字数のいずれかです。数値が、文字数とバイト数のどちらで解釈されるかを指定する方法の詳細は、「STRING SIZES ARE IN」を参照してください。

VARRAWデータ型には、バイナリ・データが後に続くバイナリ・カウント・フィールドが含まれます。バイナリ・カウント・フィールドの値は、バイナリ・データのバイト数です。VARRAWフィールドのデータは、DATA IS…ENDIAN句の影響を受けません。

ACCESS PARAMETERS句の中のVARIABLE 2句は、長さを含むバイナリ・フィールドのサイズを規定します。

オプションのlength_of_lengthフィールドは、カウント・フィールドのバイト数です。VARCHARに対するlength_of_lengthの有効な値は、1、2、4および8です。length_of_lengthを指定しない場合、値に2が使用されます。カウント・フィールドは、DATA IS…ENDIAN句で指定されたとおりの同じエンディアンを持ちます。

max_lenフィールドを使用して、データ・ファイルのフィールドのインスタンスの最大サイズを指定します。VARRAWフィールドでは、max_lenはバイト数です。VARCHARフィールドでは、max_lenは、STRING SIZES ARE IN句の設定に応じて、文字数またはバイト数のいずれかになります。

次に、VARCHARおよびVARRAWの使用例を示します。例の後に、データ・ファイルinfo.datの内容を示します。

CREATE TABLE emp_load
(first_name CHAR(15),
last_name CHAR(20),
resume CHAR(2000),
picture RAW(2000))
ORGANIZATION EXTERNAL
(TYPE ORACLE_LOADER
DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS
(RECORDS
VARIABLE 2
DATA IS BIG ENDIAN
CHARACTERSET US7ASCII
FIELDS (first_name VARCHAR(2,12),
last_name VARCHAR(2,20),
resume VARCHAR(4,10000),
picture VARRAW(4,100000)))
LOCATION ('info.dat'));

info.datデータ・ファイルの内容

この例で使用するデータ・ファイルの内容は次のとおりです。

0005Alvin0008Tolliver0000001DAlvin Tolliver's Resume etc. 0000001013f4690a30bc29d7e40023ab4599ffff

わかりやすくするため、カウント・バイトのバイナリ値およびRAWデータの値は、1バイナリ・バイトをイタリック体の2文字で表示していることに注意してください。実際のデータ・ファイルでは、ASCII形式ではなくバイナリ形式の値になります。したがって、この例をカット・アンド・ペーストで使用すると、エラーが返されます。

VARCHARCおよびVARRAWC

VARCHARCデータ型には、文字データが後に続く文字カウント・フィールドが含まれます。カウント・フィールドの値は、フィールドのバイト数または文字数のいずれかです。数値が、文字数とバイト数のどちらで解釈されるかを指定する方法の詳細は、「STRING SIZES ARE IN」を参照してください。オプションのlength_of_lengthは、長さが文字とバイトのどちらで解釈されるかに応じて、VARCHARCに対するカウント・フィールドのバイト数または文字数のいずれかになります。

VARCHARCに対するlength_of_lengthsの最大値は、文字列のサイズが文字単位の場合は10で、文字列のサイズがバイト単位の場合は20です。length_of_lengthのデフォルトの値は5です。

VARRAWCデータ型には、バイナリ・データが後に続く文字カウント・フィールドが含まれます。カウント・フィールドの値は、バイナリ・データのバイト数です。length_of_lengthは、カウント・フィールドのバイト数です。

max_lenフィールドを使用して、データ・ファイルのフィールドのインスタンスの最大サイズを指定します。VARRAWCフィールドでは、max_lenはバイト数です。VARCHARCフィールドでは、max_lenは、STRING SIZES ARE IN句の設定に応じて、文字数またはバイト数のいずれかになります。

次に、VARCHARCおよびVARRAWCの使用例を示します。pictureフィールドの長さは0です。これは、このフィールドがNULLに設定されていることを意味します。

CREATE TABLE emp_load
(first_name CHAR(15),
last_name CHAR(20),
resume CHAR(2000),
picture RAW (2000))
ORGANIZATION EXTERNAL
(TYPE ORACLE_LOADER
DEFAULT DIRECTORY ext_tab_dir
ACCESS PARAMETERS
(FIELDS (first_name VARCHARC(5,12),
last_name VARCHARC(2,20),
resume VARCHARC(4,10000),
picture VARRAWC(4,100000)))
LOCATION ('info.dat'));

00007William05Ricca0035Resume for William Ricca is missing0000

init_spec句

init_spec句を使用して、フィールドをNULLまたはデフォルト値に設定するタイミングを指定します。init_spec句の構文は次のとおりです。

NULLIF句およびDEFAULTIF句は、フィールドに各1回のみ指定できます。これらの句を使用して、次の処理を実行できます。

- NULLIF condition_specを指定し、TRUEと評価された場合、フィールドはNULLに設定されます。

- DEFAULTIF condition_specを指定し、TRUEと評価された場合、フィールドの値はデフォルトの値に設定されます。デフォルトの値は、フィールドのデータ型によって次のように異なります。

- 文字データ型の場合は、デフォルトの値は空の文字列

- 数値データ型の場合は、デフォルトの値は0

- 日付データ型の場合は、デフォルトの値はNULL

- NULLIF句とDEFAULTIF句の両方をフィールドに指定する場合、まずNULLIF句が評価され、DEFAULTIF句は、NULLIF句がFALSEと評価された場合のみに評価されます。

column_transforms句

オプションのCOLUMN TRANSFORMS句を使用した変換では、データ・ファイルの列に直接マップされない外部表の列をロードする方法を指定できます。column_transforms句の構文は次のようになります。

注意:

COLUMN TRANSFORMS句とPREPROCESSOR句を同時に使用することはできません。

transform

transform句で指定された各変換では、外部表の列を識別し、次に列の値の計算方法を指定します。構文は次のとおりです:

NULL変換は、外部表の列を各行でNULLに設定します。CONSTANT変換は、外部表の列をすべての行で同じ値に設定するために使用されます。CONCAT変換は、外部表の列をデータ・ファイルからの現在のレコード内の定数文字列またはフィールド(あるいはその両方)の連結に設定するために使用されます。LOBFILE変換は、別のデータ・ファイルからのレコードのフィールドにデータをロードするために使用されます。これらの各変換については、次の項で詳しく説明します。

column_name FROM

column_nameは、ロードする外部表の列を一意に識別します。transform句で列名が参照される場合、その名前は、データ・ファイルのフィールドとしてFIELDS句で指定することはできません。

NULL

NULL変換が指定された場合、フィールドのすべての値は各レコードに対してNULLに設定されます。

CONSTANT

CONSTANT変換では、レコードの列の値として指定された文字列の値が使用されます。外部表の列が文字列型でない場合、定数文字列は列のデータ型に変換されます。この変換は各行に対して行われます。

データ型変換で使用される文字列のキャラクタ・セットは、データベースのキャラクタ・セットです。

CONCAT

CONCAT変換は、データ・ファイルの定数文字列とフィールドを連結して1つの文字列にします。連結の一部として使用できるフィールドは、文字データ型でfields句にリストされているフィールドのみです。他の列変換は、連結の一部として指定できません。

LOBFILE

LOBFILE変換は、外部表の列の値として内容を使用するファイルを識別します。すべてのLOBFILEは、directory object:filename形式のオプションのディレクトリ・オブジェクトおよびファイル名で識別されます。LOBFILE変換には次の規則が適用されます。

- ディレクトリ・オブジェクトおよびファイル名は、定数文字列またはフィールド句のフィールド名のいずれかです。

- 定数文字列が指定された場合、その文字列を使用して表の各行のLOBFILEを検索します。

- フィールド名が指定された場合、データ・ファイル内のそのフィールドの値を使用してLOBFILEを検索します。

- ディレクトリ・オブジェクトまたはファイル名のいずれかに対してフィールド名が指定され、そのフィールドの値がNULLの場合、LOBFILEによってロードされる列もNULLに設定されます。

- ディレクトリ・オブジェクトが指定されない場合、外部表に対して指定されたデフォルトのディレクトリが使用されます。

- ディレクトリ・オブジェクトに対してフィールド名が指定された場合、FROM句も指定する必要があります。

ファイル全体がLOB列の値として使用されます。複数の行で同じファイルが参照されると、各列を移入するためにファイルが再びオープンし、再び読み込まれます。

lobfile_attr_list

lobfile_attr_listは、LOBFILEの追加属性をリストします。構文は次のとおりです:

FROM句は、LOBFILEで使用されるすべてのディレクトリ・オブジェクトの名前をリストします。LOBFILEの名前のディレクトリ・オブジェクトに対して、フィールド名が指定された場合にのみ使用します。FROM句の目的は、初期化時に名前付きのディレクトリ・オブジェクトに許可されたアクセス権の種類を識別することにあります。フィールドの値に指定されたディレクトリ・オブジェクトが、リスト内のディレクトリ・オブジェクトではない場合、行は拒否されます。

CLOB属性は、LOBFILE内のデータがRAWデータではなく、文字データであることを示します。場合によって文字データは、データベース内にLOBを格納するために使用されるキャラクタ・セットに変換する必要があります。

CHARACTERSET属性は、LOBFILE内のデータのキャラクタ・セット名を含みます。

BLOB属性は、LOBFILE内のデータが生データであることを示します。

CLOBまたはBLOBのいずれも指定されない場合、CLOBであるとみなされます。文字LOBFILEに対してキャラクタ・セットが指定されない場合、データ・ファイルのキャラクタ・セットであるとみなされます。

STARTOF source_field (長さ)

STARTOFキーワードを使用すると、列がソース・フィールドのデータの部分文字列になることが可能な外部表を作成できます。

長さは、部分文字列の先頭からの長さです。長さとはバイト数のことであり、変換される外部表の列は文字長セマンティクスではなく、バイト長セマンティクスを使用するとみなされます。(文字長セマンティクスを使用すると、予期しない結果になる可能性があります。)

完全な文字コードのみが移動され、文字は分割されません。したがって、部分文字列がマルチバイト・キャラクタの途中で終わると、結果の文字列は短くなります。たとえば、長さに10を指定し、10番目のバイトがマルチバイト・キャラクタの最初のバイトである場合、最初の9バイトのみが返されます。

次の例では、部署名(dname)フィールドの最初の4バイトのみが必要となる場合の、STARTOFキーワードの使用方法を示しています。

SQL> CREATE TABLE dept (deptno  NUMBER(2),
2                    dname   VARCHAR2(14),
3                    loc     VARCHAR2(13)
4                         )
5  ORGANIZATION EXTERNAL
6  (
7    DEFAULT DIRECTORY def_dir1
8    ACCESS PARAMETERS
9    (
10      RECORDS DELIMITED BY NEWLINE
11      FIELDS TERMINATED BY ','
12      (
13        deptno           CHAR(2),
14        dname_source     CHAR(14),
15        loc              CHAR(13)
16      )
17      column transforms
18      (
19         dname FROM STARTOF dname_source (4)
20      )
21    )
22    LOCATION ('dept.dat')
23  );

Table created.

dept表からSELECT操作を実行する場合、dnameフィールドの最初の4バイトが返されます。

SQL> SELECT * FROM dept;

DEPTNO DNAME          LOC
---------- -------------- -------------
10 ACCO           NEW YORK
20 RESE           DALLAS
30 SALE           CHICAGO
40 OPER           BOSTON

4 rows selected.

ORACLE_LOADERアクセス・ドライバのパラレル・ロードに関する考慮点

ORACLE_LOADERアクセス・ドライバでは、大きいデータ・ファイルを、個別に処理できるチャンクに分割します。

次のファイル、レコードおよびデータ特性によって、ファイルのパラレル処理が禁止されます。

- 順次データ・ソース(テープ・ドライブ、パイプなど)

- 文字の境界が文字列中の任意のバイトで始まり、境界を判断できないマルチバイト・キャラクタ・セットのデータ
この制限事項は、1レコード当たりのバイト数が固定のデータ・ファイルには適用されません。

- VAR形式のレコード

PARALLEL句の指定は、大量のデータを扱う場合にのみ有効です。

ORACLE_LOADERアクセス・ドライバを使用する際のパフォーマンスのヒント

パフォーマンスを監視する場合、最も重要なことは、ロードの経過時間の測定です。また、CPU使用量、メモリー使用量およびI/O率の測定も重要です。

並列度を増減することによって、パフォーマンスを変更できます。並列度は、データ・ファイルの処理に起動できるアクセス・ドライバの数を示します。並列度によって、リソース使用率を低くした遅いロードと、すべてのリソースを使用した速いロードを選択できます。アクセス・ドライバは、アクセス・ドライバ専用に使用するリソース量を判断できないため、自動的にはチューニングされません。

さらに考慮する必要があるのは、アクセス・ドライバで大きなI/Oバッファを使用すると、パフォーマンスが向上するという点です(バッファのサイズは、READSIZE句をアクセス・パラメータで使用して指定できます)。共有サーバーを使用するデータベースでは、アクセス・ドライバが使用するすべてのメモリーはSystem Global Area(SGA)から割り当てられます。そのため、共有サーバー上の外部表を使用する際には注意が必要です。

また、パフォーマンスは、データ・キャッシュ機能を使用して向上できる場合もあります。データ・キャッシュを使用して、ロード中に予測される一意の日付の数を指定する、入力データ内に多数の重複する日付またはタイムスタンプ値が存在する場合と、日付変換が実行される回数を減らすことができます。外部表で提供されるデータ・キャッシュ機能は、SQL*Loaderで提供されるものと同じです。詳細は、「DATA_CACHE」を参照してください。

パフォーマンスを向上させるには、並列度の変更およびデータ・キャッシュの使用に加えて、次のことを考慮してください。

- 固定長レコードは、文字列で終了しているレコードより速く処理される。

- 固定長フィールドは、デリミタ付きフィールドより速く処理される。

- シングルバイト・キャラクタ・セットは、最も速く処理される。

- 固定幅キャラクタ・セットは、可変幅キャラクタ・セットより速く処理される。

- 可変幅キャラクタ・セットのバイト長セマンティクスは、文字長セマンティクスより早く処理される。

- 1文字のレコード終了デリミタおよびフィールド・デリミタは、複数文字のデリミタより速く処理される。

- キャラクタ・セットを変換するより、データ・ファイルのキャラクタ・セットをデータベースのキャラクタ・セットに一致させる方が速く処理される。

- データ型を変換するより、データ・ファイルのデータ型をデータベースのデータ型に一致させる方が速く処理される。

- 拒否された行を拒否ファイルに書き込まない場合は、オーバーヘッドが削減されるため、処理速度が速くなる。

- 条件句(WHEN、NULLIFおよびDEFAULTIFを含む)を使用すると、処理速度が遅くなる。

- アクセス・ドライバは、マルチスレッドを使用して作業をできるだけ簡素化します。

ORACLE_LOADERアクセス・ドライバ使用時の制限事項

この項では、ORACLE_LOADERアクセス・ドライバを使用する際に認識しておく必要がある制限事項について説明します。

- 暗号化された列がある外部表のエクスポートとインポートは、サポートされていません。

- 列処理: デフォルトでは、外部表の機能は、外部表に定義されたすべての列をフェッチします。これによって、すべての問合せに対し、一貫した結果が保証されます。ただし、パフォーマンスを考慮して、外部表内で参照される列だけを処理することができます。これによって、データ変換の量および問合せの実行で必要なデータ処理の量を最小限にします。この場合、データ型変換エラーが発生した列を含んでいたために拒否された行も、その列が参照されないかぎり、別の問合せでは拒否されません。ALTER TABLEコマンドを使用すると、この列処理動作を変更できます。

- 外部表は、LONG列にデータをロードできません。

- ORACLE_LOADERアクセス・ドライバのアクセス・パラメータにSQL文字列を指定できません。解決策として、外部表を読み取る文のSELECT句にDECODE句を使用できます。また、DECODE句を使用する外部表のビューを作成して、外部表ではなくそのビューから選択することもできます。

- 外部表では、文字列内のバックスラッシュ(\)の使用はサポートされていません。詳細は、「バックスラッシュ・エスケープ文字の使用」を参照してください。

- 外部表アクセス・パラメータにおいて列名や表名などの識別子が指定される場合、特定の値はアクセス・パラメータ・パーサーによって予約語とみなされます。予約語を識別子として使用するには、二重引用符で囲む必要があります。

ORACLE_LOADERアクセス・ドライバの予約語

外部表アクセス・パラメータにおいて列名や表名などの識別子が指定される場合、特定の値はアクセス・パラメータ・パーサーによって予約語とみなされます。予約語を識別子として使用するには、二重引用符で囲む必要があります。ORACLE_LOADERアクセス・ドライバの予約語は、次のとおりです。

- ALL

- AND

- ARE

- ASTERISK

- AT

- ATSIGN

- BADFILE

- BADFILENAME

- BACKSLASH

- BENDIAN

- BIG

- BLANKS

- BY

- BYTES

- BYTESTR

- CHAR

- CHARACTERS

- CHARACTERSET

- CHARSET

- CHARSTR

- CHECK

- CLOB

- COLLENGTH

- COLON

- COLUMN

- COMMA

- CONCAT

- CONSTANT

- COUNTED

- DATA

- DATE

- DATA_CACHE

- DATE_FORMAT

- DATEMASK

- DAY

- DEBUG

- DECIMAL

- DEFAULTIF

- DELIMITBY

- DELIMITED

- DISCARDFILE

- DNFS_ENABLE

- DNFS_DISABLE

- DNFS_READBUFFERS

- DOT

- DOUBLE

- DOUBLETYPE

- DQSTRING

- DQUOTE

- DSCFILENAME

- ENCLOSED

- ENDIAN

- ENDPOS

- EOF

- EQUAL

- EXIT

- EXTENDED_IO_PARAMETERS

- EXTERNAL

- EXTERNALKW

- EXTPARM

- FIELD

- FIELDS

- FILE

- FILEDIR

- FILENAME

- FIXED

- FLOAT

- FLOATTYPE

- FOR

- FROM

- HASH

- HEXPREFIX

- IN

- INTEGER

- INTERVAL

- LANGUAGE

- IS

- LEFTCB

- LEFTTXTDELIM

- LEFTP

- LENDIAN

- LDRTRIM

- LITTLE

- LOAD

- LOBFILE

- LOBPC

- LOBPCCONST

- LOCAL

- LOCALTZONE

- LOGFILE

- LOGFILENAME

- LRTRIM

- LTRIM

- MAKE_REF

- MASK

- MINUSSIGN

- MISSING

- MISSINGFLD

- MONTH

- NEWLINE

- NO

- NOCHECK

- NOT

- NOBADFILE

- NODISCARDFILE

- NOLOGFILE

- NOTEQUAL

- NOTERMBY

- NOTRIM

- NULL

- NULLIF

- OID

- OPTENCLOSE

- OPTIONALLY

- OPTIONS

- OR

- ORACLE_DATE

- ORACLE_NUMBER

- PLUSSIGN

- POSITION

- PROCESSING

- QUOTE

- RAW

- READSIZE

- RECNUM

- RECORDS

- REJECT

- RIGHTCB

- RIGHTTXTDELIM

- RIGHTP

- ROW

- ROWS

- RTRIM

- SCALE

- SECOND

- SEMI

- SETID

- SIGN

- SIZES

- SKIP

- STRING

- TERMBY

- TERMEOF

- TERMINATED

- TERMWS

- TERRITORY

- 時間

- TIMESTAMP

- TIMEZONE

- TO

- TRANSFORMS

- UNDERSCORE

- UINTEGER

- UNSIGNED

- VALUES

- VARCHAR

- VARCHARC

- VARIABLE

- VARRAW

- VARRAWC

- VLENELN

- VMAXLEN

- WHEN

- WHITESPACE

- WITH

- YEAR

- ZONED

16 ORACLE_DATAPUMPアクセス・ドライバ

ORACLE_DATAPUMP型の外部表に固有のアクセス・パラメータのセットを提供するORACLE_DATAPUMPアクセス・ドライバについて説明します。アクセス・ドライバのデフォルトの動作を変更するためにアクセス・パラメータを使用できます。アクセス・ドライバで指定する情報により、データ・ソースのデータが、外部表の定義と一致するように処理されます。

詳細は次のトピックを参照してください。

- access_parameters句

- ORACLE_DATAPUMPアクセス・ドライバを使用したデータのアンロードとロード

- サポートされるデータ型

- サポートされないデータ型

- ORACLE_DATAPUMPアクセス・ドライバを使用する際のパフォーマンスのヒント

- ORACLE_DATAPUMPアクセス・ドライバ使用時の制限事項

- ORACLE_DATAPUMPアクセス・ドライバの予約語

ORACLE_DATAPUMPアクセス・ドライバを正しく使用するには、使用するプラットフォームのデータ・ファイルのファイル形式およびレコード形式(キャラクタ・セット、フィールドのデータ型など)についての知識が必要です。また、外部表を作成し、その外部表に問合せを実行するためのSQLの知識も必要です。

注意:

- 章の後半で説明されているその他の構文を使用しなければ、わかりにくい場合があります。構文によって行われる処理が明確でない場合は、先に進み、その説明を参照してください。

- 外部表アクセス・パラメータにおいて列名や表名などの識別子が指定される場合、特定の値はアクセス・パラメータ・パーサーによって予約語とみなされます。予約語を識別子として使用するには、二重引用符で囲む必要があります。詳細は、「ORACLE_DATAPUMPアクセス・ドライバの予約語」を参照してください。

access_parameters句

外部表の作成時に、access_parameters句内の特定のパラメータを指定できます。この句およびその個別のパラメータはオプションです。たとえば、LOGFILEを指定し、VERSIONは指定しない、またはその逆も可能です。access_parameters句の構文は次のとおりです。

注意:

これらのアクセス・パラメータは、SQL文のCREATE TABLE...ORGANIZATION EXTERNALのopaque_format_specとしてまとめて参照されます。

関連項目:

- SQL CREATE TABLE...ORGANIZATION EXTERNAL文を使用するときにopaque_format_specを指定する方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

コメント

コメントは、2つのハイフンで始まり、その後にテキストが続く行です。コメントは、次の例のように、アクセス・パラメータより前に位置する必要があります。

--This is a comment.
--This is another comment.
NOLOG

二重ハイフンの右側のすべてのテキストは行末まで無視されます。

COMPRESSION

デフォルト: DISABLED

用途

データをダンプ・ファイル・セットに書き込む前にデータを圧縮するかどうかと、使用する圧縮アルゴリズム(オプション)を指定します。

構文および説明

COMPRESSION [ENABLED {BASIC | LOW| MEDIUM | HIGH} | DISABLED]

- ENABLEDを指定すると、アンロード操作全体ですべてのデータが圧縮されます。追加で次の圧縮オプションのいずれかを指定できます。

- BASIC: 圧縮率と速度の適度な組合せが実現し、使用されるアルゴリズムはOracle Data Pumpの以前のバージョンと同じです。

- LOW: アンロード・スループットへの影響を最小限に抑えます。CPUリソースが限定要因となっている環境に適しています。

- MEDIUM: ほとんどの環境に適しています。このオプションはBASICオプションと同様、圧縮率と処理速度を加味したよい組合せですが、BASICとは異なるアルゴリズムが使用されています。

- HIGH: ネットワーク速度が限定要因となっている、速度が遅いネットワークを使用するアンロードに最適です。

注意:

これらの圧縮アルゴリズムを使用するには、COMPATIBLE初期化パラメータを12.0.0以上に設定する必要があります。この機能では、Oracle Advanced Compressionオプションを有効にする必要があります。

圧縮アルゴリズムのパフォーマンスは、そのCPU使用量および圧縮率(非圧縮の入力に対する割合としての圧縮済の出力のサイズ)によって特徴付けられます。これらの測定値は、使用される圧縮アルゴリズムの速度に加え、入力のサイズおよびタイプに応じて変化します。基本的に圧縮率はLOWからHIGHへと高くなります。ただし、圧縮率の上昇に応じて、消費されるCPUリソースが多くなります。

ご使用の環境で、データに対して様々な圧縮レベルをテストすることをお薦めします。エクスポートされるダンプ・ファイル・セットの圧縮レベルがパフォーマンスおよび記憶域要件を満たすようにするには、環境、ワークロードの特性、およびデータのサイズとタイプに基づいて圧縮レベルを選択します。

- DISABLEDを指定すると、アップロード操作でデータは圧縮されません。

例

次の例では、COMPRESSIONパラメータがENABLEDに設定されています。したがって、dept.dmpダンプ・ファイルに書き込まれるすべてのデータは圧縮形式になります。

CREATE TABLE deptXTec3
ORGANIZATION EXTERNAL (TYPE ORACLE_DATAPUMP DEFAULT DIRECTORY def_dir1
ACCESS PARAMETERS (COMPRESSION ENABLED) LOCATION ('dept.dmp'));

ENCRYPTION

デフォルト: DISABLED

用途

ダンプ・ファイル・セットに書き込む前にデータを暗号化するかどうかを指定します。

構文および説明

ENCRYPTION [ENABLED | DISABLED]

ENABLEDを指定すると、すべてのデータが暗号化形式でダンプ・ファイル・セットに書き込まれます。

DISABLEDを指定すると、データは暗号化形式でダンプ・ファイル・セットに書き込まれません。

制限事項

このパラメータは、エクスポート操作でのみ使用します。

例

次の例では、ENCRYPTIONパラメータがENABLEDに設定されています。したがって、dept.dmpファイルに書き込まれるすべてのデータは暗号化形式になります。

CREATE TABLE deptXTec3
ORGANIZATION EXTERNAL (TYPE ORACLE_DATAPUMP DEFAULT DIRECTORY def_dir1
ACCESS PARAMETERS (ENCRYPTION ENABLED) LOCATION ('dept.dmp'));

LOGFILE | NOLOGFILE

デフォルト: LOGFILEが指定されない場合、デフォルトのディレクトリにログ・ファイルが作成され、ログ・ファイルの名前は、表名および.logの拡張子を持つプロセスIDから生成されます。ログ・ファイルがすでに同じ名前で存在する場合は、アクセス・ドライバによってそのログ・ファイルが再びオープンされ、新しいログ情報がファイルの終わりに追加されます。

用途

LOGFILEは、ダンプ・ファイルのアクセス中に生成されたすべてのメッセージを含むログ・ファイルの名前を指定します。NOLOGFILEを使用してログ・ファイルの作成を回避できます。

構文および説明

NOLOGFILE

または

LOGFILE [directory_object:]logfile_name

ログ・ファイル名の一部としてディレクトリ・オブジェクトを指定しない場合、DEFAULT DIRECTORY属性で指定されたディレクトリ・オブジェクトが使用されます。ディレクトリ・オブジェクトが指定されず、デフォルトのディレクトリも指定されない場合は、エラーが返されます。置換変数を使用してパラレル・ロードおよびパラレル・アンロード中に一意のファイル名を作成する方法については、「LOGFILEのファイル名」を参照してください。

例

次の例では、ダンプ・ファイルdept_dmpは、ディレクトリ・オブジェクトload_dirで識別されるディレクトリ内にありますが、ログ・ファイルdeptxt.logは、ディレクトリ・オブジェクトlog_dirで識別されるディレクトリ内にあります。

CREATE TABLE dept_xt (dept_no INT, dept_name CHAR(20), location CHAR(20))
ORGANIZATION EXTERNAL (TYPE ORACLE_DATAPUMP DEFAULT DIRECTORY load_dir
ACCESS PARAMETERS (LOGFILE log_dir:deptxt) LOCATION ('dept_dmp'));

LOGFILEのファイル名

パラレル・ロードでファイル名を一意にするには、アクセス・ドライバで記号置換を行います。サポートされている記号置換は次のとおりです。

- %pは、現行のプロセスのプロセスIDに置換されます。たとえば、アクセス・ドライバのプロセスIDが12345の場合、exttab_%p.logは、exttab_12345.logとなります。

- %aは、現行のプロセスのエージェント番号に置換されます。エージェント番号は、外部表にアクセスしている各パラレル・プロセスに割り当てられた一意の番号です。この番号には、3文字になるように、左側に0が埋められます。たとえば、3番目のパラレル・エージェントがファイルを作成する際に、exttab_%a.logがファイル名として指定されている場合、エージェントはexttab_003.logというファイルを作成します。

- %%は、%に置換されます。ファイル名にパーセント符号が必要な場合、この記号置換を使用する必要があります。

%文字に前述のリスト内の文字以外の文字が続く場合、エラーが返されます。

%pまたは%aを使用しないで出力ファイルに対して一意のファイル名を作成し、外部表にパラレルでアクセス中の場合、出力ファイルが破損するか、エージェントがファイルに書込みをできないという問題が発生する場合があります。

ファイルに対して拡張子が指定されていない場合は、デフォルトの拡張子である.logが使用されます。生成された名前が有効なファイル名ではない場合、エラーが返され、データのロードまたはアンロードは行われません。

VERSION句

VERSION句は、ダンプ・ファイルを読み取るOracle Databaseの最低のリリースを指定するために使用されます。たとえば、11.1と指定すると、Oracle Database 11gリリース11.1および11.2データベースの両方でダンプ・ファイルを読み取ることができます。11.2と指定すると、Oracle Database 11gリリース2(11.2)データベースのみがダンプ・ファイルを読み取ることができます。

デフォルト値はCOMPATIBLEです。

SQL ENCRYPT句の使用による影響

外部表の作成時にSQL ENCRYPT句を指定する場合は、次の点に注意してください。

- ENCRYPT句を指定した列は、暗号化されてからダンプ・ファイルに書き込まれます。

- ダンプ・ファイルを別のデータベースに移動する場合は、ダンプ・ファイルの暗号化列とダンプ・ファイルの読込みに使用する外部表の両方で、同じ暗号化パスワードを使用する必要があります。

- 2つ目のデータベースの外部表で暗号化されている正しい列に対してパスワードを指定しなかった場合は、エラーが発生します。指定したパスワードが正しくない場合は、ダンプ・ファイルのデータが無効になります。

- 作成するダンプ・ファイルのリリースは10.2以上にする必要があります。そうでない場合は、エラーが戻されます。

関連項目:

CREATE TABLE文でのENCRYPT句の使用方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ORACLE_DATAPUMPアクセス・ドライバを使用したデータのアンロードとロード

ORACLE_DATAPUMPアクセス・ドライバは、SQLのCREATE TABLE AS SELECT文を使用した外部表の作成の一環として、ダンプ・ファイルにデータを書き込むことができます。ファイル内のデータは、バイナリ形式で記述され、ORACLE_DATAPUMPアクセス・ドライバによってのみ読取りが可能です。作成されたダンプ・ファイルは変更できません(つまり、ダンプ・ファイルに対してデータ操作言語(DML)操作は実行できません)。ただし、このファイルは何回でも読み取ることができ、別の外部表のダンプ・ファイルとして同じデータベースまたは異なるデータベースで使用できます。

次の手順ではサンプル・スキーマoeを使用して、ORACLE_DATAPUMPアクセス・ドライバを使用したデータのアンロード方法およびロード方法の例を示します。(例では、ディレクトリ・オブジェクトdef_dir1がすでに存在し、ユーザーoeにはそれに対する読取りおよび書込み権限が付与されているとします。)

1. 外部表は、AS SELECT句を使用した外部表の作成の一環としてのみファイルにデータを移入します。次の例では、inventories_xtという名前の外部表を作成し、外部表のダンプ・ファイルにoeスキーマ内のinventories表のデータを移入します。

SQL> CREATE TABLE inventories_xt
2  ORGANIZATION EXTERNAL
3  (
4    TYPE ORACLE_DATAPUMP
5    DEFAULT DIRECTORY def_dir1
6    LOCATION ('inv_xt.dmp')
7  )
8  AS SELECT * FROM inventories;

Table created.

2. inventoriesおよび新しい外部表の両方を、次のとおり記述します。その両方は一致している必要があります。

SQL> DESCRIBE inventories
Name                                      Null?    Type
---------------------------------------- --------- ----------------
PRODUCT_ID                                NOT NULL NUMBER(6)
WAREHOUSE_ID                              NOT NULL NUMBER(3)
QUANTITY_ON_HAND                          NOT NULL NUMBER(8)

SQL> DESCRIBE inventories_xt
Name                                      Null?    Type
----------------------------------------- -------- -----------------
PRODUCT_ID                                NOT NULL NUMBER(6)
WAREHOUSE_ID                              NOT NULL NUMBER(3)
QUANTITY_ON_HAND                          NOT NULL NUMBER(8)

3. 作成された外部表は、他の表と同様に問合せを行うことができます。たとえば、次のように外部表のレコード数を選択します。

SQL> SELECT COUNT(*) FROM inventories_xt;

COUNT(*)
----------
1112

4. 外部表のデータをinventoriesのデータと比較します。違いがないことを確認します。

SQL> SELECT * FROM inventories MINUS SELECT * FROM inventories_xt;

no rows selected

5. 外部表が作成され、CREATE TABLE AS SELECT文によりダンプ・ファイルが移入された後では、外部表に対する行の追加、更新または削除は実行できません。外部表のデータの変更を試みると、エラーが発生します。

次の例では、既存の外部表へのデータ操作言語(DML)の使用を試みます。次のエラーが返されます。

SQL> DELETE FROM inventories_xt WHERE warehouse_id = 5;
DELETE FROM inventories_xt WHERE warehouse_id = 5
*
ERROR at line 1:
ORA-30657: operation not supported on external organized table

6. 外部表に対して作成されたダンプ・ファイルは移動できるようになり、同じデータベースまたは異なるデータベース内の別の外部表のダンプ・ファイルとして使用できます。既存のファイルを使用する外部表を作成した場合、CREATE TABLE文のAS SELECT句は存在しません。

SQL> CREATE TABLE inventories_xt2
2  (
3    product_id          NUMBER(6),
4    warehouse_id        NUMBER(3),
5    quantity_on_hand    NUMBER(8)
6  )
7  ORGANIZATION EXTERNAL
8  (
9    TYPE ORACLE_DATAPUMP
10    DEFAULT DIRECTORY def_dir1
11    LOCATION ('inv_xt.dmp')
12  );

Table created.

7. 新しい外部表のデータをinventories表のデータと比較します。比較する前に、product_idフィールドは互換性のあるデータ型に変換されます。違いがないことを確認します。

SQL> SELECT * FROM inventories MINUS SELECT * FROM inventories_xt2;

no rows selected

8. 3つのダンプ・ファイルおよび3の並列度の外部表を作成します。

SQL> CREATE TABLE inventories_xt3
2  ORGANIZATION EXTERNAL
3  (
4    TYPE ORACLE_DATAPUMP
5    DEFAULT DIRECTORY def_dir1
6    LOCATION ('inv_xt1.dmp', 'inv_xt2.dmp', 'inv_xt3.dmp')
7  )
8  PARALLEL 3
9  AS SELECT * FROM inventories;

Table created.

9. アンロードされたデータとinventoriesを比較します。違いがないことを確認します。

SQL> SELECT * FROM inventories MINUS SELECT * FROM inventories_xt3;

no rows selected

10. inventories表の数行を含む外部表を作成します。

SQL> CREATE TABLE inv_part_xt
2  ORGANIZATION EXTERNAL
3  (
4  TYPE ORACLE_DATAPUMP
5  DEFAULT DIRECTORY def_dir1
6  LOCATION ('inv_p1_xt.dmp')
7  )
8  AS SELECT * FROM inventories WHERE warehouse_id < 5;

Table created.

11. inventoriesの残りの行を含む別の外部表を作成します。

SQL> drop table inv_part_xt;

Table dropped.

SQL>
SQL> CREATE TABLE inv_part_xt
2  ORGANIZATION EXTERNAL
3  (
4  TYPE ORACLE_DATAPUMP
5  DEFAULT DIRECTORY def_dir1
6  LOCATION ('inv_p2_xt.dmp')
7  )
8  AS SELECT * FROM inventories WHERE warehouse_id >= 5;

Table created.

12. 手順10および手順11で作成した2つのダンプ・ファイルを使用する外部表を作成します。

SQL> CREATE TABLE inv_part_all_xt
2  (
3  product_id NUMBER(6),
4  warehouse_id NUMBER(3),
5  quantity_on_hand NUMBER(8)
6  )
7  ORGANIZATION EXTERNAL
8  (
9  TYPE ORACLE_DATAPUMP
10  DEFAULT DIRECTORY def_dir1
11  LOCATION ('inv_p1_xt.dmp','inv_p2_xt.dmp')
12  );

Table created.

13. 新しい外部表とinventories表を比較します。違いがないことを確認します。これは、外部表の作成で使用された2つのダンプ・ファイルに同じメタデータ(同じ表名inv_part_xt、同じ列情報など)があるためです。

SQL> SELECT * FROM inventories MINUS SELECT * FROM inv_part_all_xt;

no rows selected

パラレル・ロードおよびパラレル・アンロード

ダンプ・ファイルは、記述されるすべてのデータを保持できるサイズのディスクに格納する必要があります。すべてのデータを保持できない容量の場合、CREATE TABLE AS SELECT文に対してエラーが返されます。この問題を軽減するには、CREATE TABLE AS SELECT文の実行時に複数のディレクトリ・オブジェクトを作成するという方法があります。ただし、これらのディレクトリは、異なるディスクに存在する必要があります。LOCATION句でdirectory:file形式を使用して複数の位置を指定し、PARALLEL句を指定することで複数のファイルを作成できます。外部表を移入するために作成された各パラレルI/Oサーバー・プロセスでは、固有のファイルに書込みを実行します。各I/Oサーバー・プロセスには固有のファイルが必要であるため、LOCATION句のファイル数と並列度が一致している必要があります。余分なファイルを指定した場合は、すべて無視されます。指定された並列度に対して必要数のファイルが存在しない場合、LOCATION句のファイル数と一致するよう並列度が下げられます。

inventories表の3つのファイルへのアンロードの例を次に示します。

SQL> CREATE TABLE inventories_XT_3
2  ORGANIZATION EXTERNAL
3  (
4    TYPE ORACLE_DATAPUMP
5    DEFAULT DIRECTORY def_dir1
6    LOCATION ('inv_xt1.dmp', 'inv_xt2.dmp', 'inv_xt3.dmp')
7  )
8  PARALLEL 3
9  AS SELECT * FROM oe.inventories;

Table created.

ORACLE_DATAPUMPアクセス・ドライバを使用してデータをロードする場合は、パラレル処理で、複数のダンプ・ファイルや同じダンプ・ファイルのチャンクも同時に読み取ることができます。したがって、ファイルが複数のファイル・オフセットを含むことができる大きさであれば、ダンプ・ファイルが1つであっても、データをパラレルでロードできます。ORACLE_DATAPUMP外部表から読み込む場合、並列度はLOCATION句のファイル数に関連付けられません。

ダンプ・ファイルの結合

異なる外部表から移入されたすべてのダンプ・ファイルは、別の外部表のLOCATION句で指定できます。たとえば、異なる本番データベースのデータを個別のファイルにアンロードし、次にそれらのファイルをデータ・ウェアハウスで定義された外部表に含めることができます。これにより、複数のソースから容易にデータを集計できます。唯一の制限は、すべての外部表のメタデータが完全に同じでなければいけない必要がある点です。つまり、キャラクタ・セット、タイムゾーン、スキーマ名、表名および列名がすべて一致する必要があります。また、列は同じ順序で定義され、そのデータ型も完全に同一である必要があります。1つ目の外部表を作成した後で、2つ目の外部表に同じ表名を使用できるようにするには、1つ目の外部表を削除する必要があります。こうすることで、2つのダンプ・ファイルにリストされたメタデータは同じ状態になり、これらのダンプ・ファイルを同時に使用して同じ外部表を作成できます。

SQL> CREATE TABLE inv_part_1_xt
2  ORGANIZATION EXTERNAL
3  (
4    TYPE ORACLE_DATAPUMP
5    DEFAULT DIRECTORY def_dir1
6    LOCATION ('inv_p1_xt.dmp')
7  )
8  AS SELECT * FROM oe.inventories WHERE warehouse_id < 5;

Table created.

SQL> DROP TABLE inv_part_1_xt;

SQL> CREATE TABLE inv_part_1_xt
2  ORGANIZATION EXTERNAL
3  (
4    TYPE ORACLE_DATAPUMP
5    DEFAULT directory def_dir1
6    LOCATION ('inv_p2_xt.dmp')
7  )
8  AS SELECT * FROM oe.inventories WHERE warehouse_id >= 5;

Table created.

SQL> CREATE TABLE inv_part_all_xt
2  (
3    PRODUCT_ID          NUMBER(6),
4    WAREHOUSE_ID        NUMBER(3),
5    QUANTITY_ON_HAND    NUMBER(8)
6  )
7  ORGANIZATION EXTERNAL
8  (
9    TYPE ORACLE_DATAPUMP
10    DEFAULT DIRECTORY def_dir1
11    LOCATION ('inv_p1_xt.dmp','inv_p2_xt.dmp')
12  );

Table created.

SQL> SELECT * FROM inv_part_all_xt MINUS SELECT * FROM oe.inventories;

no rows selected

サポートされるデータ型

外部表を使用してデータベース間でデータを移動する際には、次のような問題があります。

- 2つのプラットフォーム間で、データベースのキャラクタ・セットとデータベースの各国語キャラクタ・セットが異なる場合があります。

- 2つのデータベースで、プラットフォームのエンディアンが異なる場合があります。

ORACLE_DATAPUMPアクセス・ドライバは、これらの状況の一部を自動的に解消します。

次のデータ型は、ロード時およびアンロード時に自動的に変換されます。

- 文字(CHAR、NCHAR、VARCHAR2、NVARCHAR2)

- RAW

- NUMBER

- 日付/時刻

- BLOB

- CLOBおよびNCLOB

- ROWIDおよびUROWID

外部表でサポートされていないデータ型を使用するとエラーが返されます。サポートされていないデータ型であるLONGを使用した例を次に示します。

SQL> CREATE TABLE bad_datatype_xt
2  (
3    product_id             NUMBER(6),
4    language_id            VARCHAR2(3),
5    translated_name        NVARCHAR2(50),
6    translated_description LONG
7  )
8  ORGANIZATION EXTERNAL
9  (
10    TYPE ORACLE_DATAPUMP
11    DEFAULT DIRECTORY def_dir1
12    LOCATION ('proddesc.dmp')
13  );
translated_description LONG
*
ERROR at line 6:
ORA-30656: column type not supported on external organized table

関連項目:

「サポートされていないデータ型」

サポートされていないデータ型

外部表は、列に対して有効なすべてのデータ型のサブセットをサポートしています。特に、文字データ型(LONGを除く)、RAWデータ型、すべての数値データ型、およびすべての日付、タイムスタンプ、期間データ型をサポートしています。

この項では、ORACLE_DATAPUMPアクセス・ドライバを使用して、サポートされていないデータ型のデータをアンロードおよび再ロードする方法を説明します。サポートされないデータ型の一部を次に示します。

- BFILE

- LONGおよびLONG RAW

- FINALオブジェクト型

- FINALオブジェクト型の表

BFILEデータ型のアンロードおよびロード

BFILEデータ型には、ファイルのディレクトリ・オブジェクトとディレクトリ・オブジェクト内のファイル名という2つの情報が格納されます。

ORACLE_DATAPUMPアクセス・ドライバを使用して、ディレクトリ・オブジェクト名およびファイル名を外部表の2つの列に格納することにより、BFILE列をアンロードできます。DBMS_LOB.FILEGETNAMEプロシージャは両方の名前を返します。ただし、これはプロシージャであるため、SELECT文では使用できません。かわりに、2つのファンクションを使用します。最初のファンクションは、ディレクトリ・オブジェクト名を返し、2つ目のファンクションはファイル名を返します。

次の手順では、BFILEデータ型のアンロードおよびロードの例を示します。

1. BFILE 列のディレクトリ・オブジェクトを抽出するファンクションを作成します。列がNULLの場合は、NULLが返されます。

SQL> CREATE FUNCTION get_dir_name (bf BFILE) RETURN VARCHAR2 IS
2  DIR_ALIAS VARCHAR2(255);
3  FILE_NAME VARCHAR2(255);
4  BEGIN
5    IF bf is NULL
6    THEN
7      RETURN NULL;
8    ELSE
9      DBMS_LOB.FILEGETNAME (bf, dir_alias, file_name);
10      RETURN dir_alias;
11    END IF;
12  END;
13  /

Function created.

2. BFILE列のファイル名を抽出するファンクションを作成します。

SQL> CREATE FUNCTION get_file_name (bf BFILE) RETURN VARCHAR2 is
2  dir_alias VARCHAR2(255);
3  file_name VARCHAR2(255);
4  BEGIN
5    IF bf is NULL
6    THEN
7      RETURN NULL;
8    ELSE
9      DBMS_LOB.FILEGETNAME (bf, dir_alias, file_name);
10      RETURN file_name;
11    END IF;
12  END;
13  /

Function created.

3. 次のように、BFILE列にNULL値を持つ行を追加できます。

SQL> INSERT INTO PRINT_MEDIA (product_id, ad_id, ad_graphic)
2  VALUES (3515, 12001, NULL);

1 row created.

新しく作成したファンクションを使用して外部表を移入できます。BFILE列がNULLの場合、ファンクションはad_graphic_dir列およびad_graphic_file列をNULLに設定します。

4. print_media表からのデータを含める外部表を作成します。get_dir_nameおよびget_file_nameファンクションを使用して、BFILE列の構成要素を取得します。

SQL> CREATE TABLE print_media_xt
2  ORGANIZATION EXTERNAL
3  (
4    TYPE oracle_datapump
5    DEFAULT DIRECTORY def_dir1
6    LOCATION ('pm_xt.dmp')
7  ) AS
8  SELECT product_id, ad_id,
9         get_dir_name (ad_graphic) ad_graphic_dir,
10         get_file_name(ad_graphic) ad_graphic_file
11  FROM print_media;

Table created.

5. 外部表内のデータからBFILE列をロードするファンクションを作成します。外部表のad_graphic_dir列がNULLの場合、ファンクションはNULLを返します。

SQL> CREATE FUNCTION get_bfile (dir VARCHAR2, file VARCHAR2) RETURN
BFILE is
2  bf BFILE;
3  BEGIN
4    IF dir IS NULL
5    THEN
6      RETURN NULL;
7    ELSE
8      RETURN BFILENAME(dir,file);
9    END IF;
10  END;
11  /

Function created.

6. get_bfileファンクションを使用してBFILE列を含む新しい表を移入できます。

SQL> CREATE TABLE print_media_int AS
2  SELECT product_id, ad_id,
3         get_bfile (ad_graphic_dir, ad_graphic_file) ad_graphic
4  FROM print_media_xt;

Table created.

7. 新しくロードされた表の列にあるデータと、print_media表の列のデータは一致している必要があります。

SQL> SELECT product_id, ad_id,
2         get_dir_name(ad_graphic),
3         get_file_name(ad_graphic)
4  FROM print_media_int
5  MINUS
6  SELECT product_id, ad_id,
7         get_dir_name(ad_graphic),
8         get_file_name(ad_graphic)
9  FROM print_media;

no rows selected

LONGおよびLONG RAWデータ型のアンロード

ORACLE_DATAPUMPアクセス・ドライバは、LONG列およびLONG RAW列のアンロードに使用できますが、データはLOBフィールドにのみ再ロードできます。次の手順は、LONGおよびLONG RAWデータ型のアンロードの例を示します。

1. アンロードする表にLONG列またはLONG RAW列が含まれる場合、外部表の対応する列を、LONG列に対してはCLOBを、LONG RAW列に対してはBLOBを定義します。

SQL> CREATE TABLE long_tab
2  (
3    key                   SMALLINT,
4    description           LONG
5  );

Table created.

SQL> INSERT INTO long_tab VALUES (1, 'Description Text');

1 row created.

2. これで、LONG列からのデータを含めたCLOB列を含む外部表を作成できます。外部表をロードするときには、LONG列をCLOBに変換するためにTO_LOB演算子が使用されます。

SQL> CREATE TABLE long_tab_xt
2  ORGANIZATION EXTERNAL
3  (
4    TYPE ORACLE_DATAPUMP
5    DEFAULT DIRECTORY def_dir1
6    LOCATION ('long_tab_xt.dmp')
7  )
8  AS SELECT key, TO_LOB(description) description FROM long_tab;

Table created.

3. 外部表のデータを使用して、アンロードされている表と同じ表を別に作成できますが、作成した表にはLONG列のかわりにLOB列が含まれます。

SQL> CREATE TABLE lob_tab
2  AS SELECT * from long_tab_xt;

Table created.

4. 表が正しく作成されたことを確認します。

SQL> SELECT * FROM lob_tab;

KEY  DESCRIPTION
----------------------------------------------------------------------------
1  Description Text

FINALオブジェクト型を含む列のアンロードおよびロード

FINAL型の列のオブジェクトは、オブジェクト型の各属性を外部表の列に移動することで移入されます。また、外部表には、列オブジェクトがアトミックNULLであるかどうかを追跡するための、新規の列が必要です。次の手順では、FINALオブジェクト型を含む列のアンロードおよびロードの方法を示します。

1. 次の例では、ソース表のwarehouse列がアトミックNULLであるかを追跡するために外部表のwarehouse列を使用します。

SQL> CREATE TABLE inventories_obj_xt
2  ORGANIZATION EXTERNAL
3  (
4    TYPE ORACLE_DATAPUMP
5    DEFAULT DIRECTORY def_dir1
6    LOCATION ('inv_obj_xt.dmp')
7  )
8  AS
9  SELECT oi.product_id,
10         DECODE (oi.warehouse, NULL, 0, 1) warehouse,
11         oi.warehouse.location_id location_id,
12         oi.warehouse.warehouse_id warehouse_id,
13         oi.warehouse.warehouse_name warehouse_name,
14         oi.quantity_on_hand
15  FROM oc_inventories oi;

Table created.

これで、オブジェクト型の属性を含む外部表の列を、その型の列をロードする際の型コンストラクタのファンクションの引数として使用できます。外部表のwarehouse列は、オブジェクトのコンストラクタ・ファンクションをコールするか、列をNULLに設定するかを判断するために使用されます。

2. oc_inventoriesビューと同様の新規の内部表をロードします。(WHERE 1=0句を使用すると、古い表と同様の表を作成しますが、データは古い表から新しい表にはコピーされません。)

SQL> CREATE TABLE oc_inventories_2 AS SELECT * FROM oc_inventories
WHERE 1 = 0;

Table created.

SQL> INSERT INTO oc_inventories_2
2  SELECT product_id,
3         DECODE (warehouse, 0, NULL,
4                 warehouse_typ(warehouse_id, warehouse_name,
5                 location_id)), quantity_on_hand
6  FROM inventories_obj_xt;

1112 rows created.

FINALオブジェクト型の表

オブジェクト表には、表のすべての行を一意に識別するオブジェクト識別子があります。そのため次のような問題があります。

- オブジェクト識別子をアンロードおよび再ロードする必要がない場合、外部表にはオブジェクト表に対する型の属性のフィールドのみを含める必要があります。

- オブジェクト識別子(OID)をアンロードおよび再ロードする必要があり、表のOIDが表の1つ以上のフィールドである場合(主キー・ベースOIDとも呼ばれる)、外部表には表の型のすべての属性に対して1つの列が存在します。

- OIDをアンロードする必要があり、表のOIDがシステム生成である場合、手順はより複雑になります。システム生成OIDを保持するには、型の属性の他に別の列を作成する必要があります。

次の手順は、前述の最後の状況の例を示します。

1. システム生成OIDを持つ型の表を作成します。

SQL> CREATE TYPE person AS OBJECT (name varchar2(20)) NOT FINAL
2  /

Type created.

SQL> CREATE TABLE people OF person;

Table created.

SQL> INSERT INTO people VALUES ('Euclid');

1 row created.

2. システム生成OIDを含む列を保持するために、OID列を使用する外部表を作成します。

SQL> CREATE TABLE people_xt
2  ORGANIZATION EXTERNAL
3  (
4    TYPE ORACLE_DATAPUMP
5    DEFAULT DIRECTORY def_dir1
6    LOCATION ('people.dmp')
7  )
8  AS SELECT SYS_NC_OID$ oid, name FROM people;

Table created.

3. システム生成OIDを持つ同じ型の別の表を作成します。次にINSERT文を実行して、新しい表に古い表からアンロードされたデータをロードします。

SQL> CREATE TABLE people2 OF person;

Table created.

SQL>
SQL> INSERT INTO people2 (SYS_NC_OID$, SYS_NC_ROWINFO$)
2  SELECT oid, person(name) FROM people_xt;

1 row created.

SQL>
SQL> SELECT SYS_NC_OID$, name FROM people
2  MINUS
3  SELECT SYS_NC_OID$, name FROM people2;

no rows selected

ORACLE_DATAPUMPアクセス・ドライバを使用する際のパフォーマンスのヒント

パフォーマンスを監視する場合、最も重要なことは、ロードの経過時間の測定です。また、CPU使用量、メモリー使用量およびI/O率の測定も重要です。

並列度を増減することによって、パフォーマンスを変更できます。並列度は、データ・ファイルの処理に起動できるアクセス・ドライバの数を示します。並列度によって、リソース使用率を低くした遅いロードと、すべてのリソースを使用した速いロードを選択できます。アクセス・ドライバは、アクセス・ドライバ専用に使用するリソース量を判断できないため、自動的にはチューニングされません。

アクセス・ドライバは、パフォーマンスを向上させるために大きなI/Oバッファを使用します。共有サーバーを使用するデータベースでは、アクセス・ドライバが使用するすべてのメモリーはSystem Global Area(SGA)から割り当てられます。そのため、共有サーバー上の外部表を使用する際には注意が必要です。

ORACLE_DATAPUMPアクセス・ドライバ使用時の制限事項

ORACLE_DATAPUMPアクセス・ドライバには、次の制限事項があります。

- 暗号化された列がある外部表のエクスポートとインポートは、サポートされていません。

- 列処理: デフォルトでは、外部表の機能は、外部表に定義されたすべての列をフェッチします。これによって、すべての問合せに対し、一貫した結果が保証されます。ただし、パフォーマンスを考慮して、外部表内で参照される列だけを処理することができます。これによって、データ変換の量および問合せの実行で必要なデータ処理の量を最小限にします。この場合、データ型変換エラーが発生した列を含んでいたために拒否された行も、その列が参照されないかぎり、別の問合せでは拒否されません。ALTER TABLEコマンドを使用すると、この列処理動作を変更できます。

- 外部表は、LONG列にデータをロードできません。

- ロード時におけるバイト順序マークの処理。データ・ファイル・キャラクタ・セットがUTF8またはUTF16の外部表ロードでは、バイト順序マークの確認は抑止できません。バイト順序マークの確認は、データ・ファイルの先頭にバイト順序マークのエンコーディングと一致するバイナリ・データが含まれている場合にのみ抑止する必要があります。(SQL*Loaderを使用したロードでは、バイト順序マークの確認を抑止できます。)バイト順序マークを確認するということは、バイト順序マークがデータ・ファイル内に存在する必要があるという意味ではないことに注意してください。バイト順序マークがない場合は、サーバー・プラットフォームのバイト順序が使用されます。

- 外部表機能では、文字列内のバックスラッシュ(\)エスケープ文字の使用をサポートしません。詳細は、「バックスラッシュ・エスケープ文字の使用」を参照してください。

- 外部表アクセス・パラメータにおいて列名や表名などの識別子が指定される場合、特定の値はアクセス・パラメータ・パーサーによって予約語とみなされます。予約語を識別子として使用するには、二重引用符で囲む必要があります。

ORACLE_DATAPUMPアクセス・ドライバの予約語

外部表アクセス・パラメータにおいて列名や表名などの識別子が指定される場合、特定の値はアクセス・パラメータ・パーサーによって予約語とみなされます。予約語を識別子として使用するには、二重引用符で囲む必要があります。ORACLE_DATAPUMPアクセス・ドライバの予約語は、次のとおりです。

- BADFILE

- COMPATIBLE

- COMPRESSION

- DATAPUMP

- DEBUG

- ENCRYPTION

- INTERNAL

- JOB

- LATEST

- LOGFILE

- NOBADFILE

- NOLOGFILE

- PARALLEL

- TABLE

- VERSION

- WORKERID

第IV部 その他のユーティリティ

ADRCI: ADRコマンド・インタプリタ

ここでは、自動診断リポジトリ・コマンド・インタプリタ(ADRCI)について説明します。これは、Oracle Database診断データの管理に使用するコマンドライン・ツールです。

DBVERIFY: オフライン・データベース検査ユーティリティ

ここでは、オフライン・データベース検査ユーティリティであるDBVERIFYの使用方法について説明します。

DBNEWIDユーティリティ

ここでは、DBNEWIDユーティリティを使用してデータベースの名前またはID(あるいはその両方)を変更する方法について説明します。

REDOログ・ファイル分析のためのLogMinerの使用

ここでは、SQLインタフェース経由でのREDOログの問合せが可能なOracle LogMinerユーティリティについて説明します。

メタデータAPIの使用

ここでは、データベース・オブジェクトに対するメタデータの完全な表現の抽出および処理が可能なメタデータAPIについて説明します。

オリジナルのエクスポート

ここでは、オリジナルのエクスポート・ユーティリティを使用して、オリジナルのインポート・ユーティリティで使用できるようにOracle Databaseのデータをダンプ・ファイルに書き込む方法を説明します。

オリジナルのインポート

ここでは、オリジナルのエクスポート・ユーティリティを使用して作成されたダンプ・ファイルを、オリジナルのインポート・ユーティリティを使用してインポートする方法を説明します。

17 ADRCI: ADRコマンド・インタプリタ

自動診断リポジトリ・コマンド・インタプリタ(ADRCI)ユーティリティは、Oracle Database診断データの管理に使用するコマンドライン・ツールです。

次のトピックを参照してください。

- ADRコマンド・インタプリタ(ADRCI)ユーティリティ

- 定義

- ADRCIの起動とヘルプの利用

- ADRCIコマンドを使用する前のADRCIホームパスの設定

- アラート・ログの表示

- トレース・ファイルの検索

- インシデントの表示

- インシデントのパッケージ化

- ADRCIコマンド・リファレンス

- ADRCIのトラブルシューティング

関連項目:

診断データの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

ADRコマンド・インタプリタ(ADRCI)ユーティリティ

ADRCIは、Oracle Database 11gに導入された故障診断機能インフラストラクチャに使用されるコマンドライン・ツールです。ADRCIでは、次の操作を実行できます。

- 自動診断リポジトリ(ADR)内の診断データを表示します。

- 状態モニターのレポートを表示します。

- Oracleサポート・サービスへ送信するために、インシデントや問題の情報をZIPファイルにパッケージ化します。

診断データには、インシデントおよび問題についての説明、トレース・ファイル、ダンプ、状態モニターのレポート、アラート・ログ・エントリなどが含まれます。

ADRデータは、ADRディレクトリのオペレーティング・システム権限により保護されているため、ADRCIにログインする必要はありません。

ADRCIには豊富なコマンド・セットがあり、対話型モードまたはスクリプト内で使用できます。

注意:

診断データを管理する場合の簡単で推奨される方法は、Oracle Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)を使用する方法です。ADRCIでは、サポート・ワークベンチの機能の大部分にかわるコマンドライン機能が備わり、トレース・ファイルのリスト表示や問合せなどの機能が追加されています。

サポート・ワークベンチの詳細は、『Oracle Database管理者ガイド』を参照してください。

定義

次に、ADRCIおよびOracle Databaseの故障診断機能インフラストラクチャで使用される用語の定義を示します。

自動診断リポジトリ(ADR)

自動診断リポジトリ(ADR)は、データベース診断データ(トレース、ダンプ、アラート・ログ、状態モニターのレポートなど)のファイルベース・リポジトリです。複数のインスタンスや製品にまたがる一元化されたディレクトリ構造を持っています。リリース11g以上では、データベース、Oracle Automatic Storage Management (Oracle ASM)およびその他のオラクル社の製品やコンポーネントは、すべての診断データをADRに格納します。各製品のインスタンスはそれぞれ、診断データを独自のADRホーム・ディレクトリの下に配置します(「ADRホーム」を参照)。たとえば、共有記憶域とASMを使用するOracle Real Application Clusters(Oracle RAC)環境では、各データベース・インスタンスおよび各Oracle ASMインスタンスがADR内にホーム・ディレクトリを持ちます。ADRの統一されたディレクトリ構造を使用することで、ユーザーおよびOracleサポート・サービスによる、複数のインスタンスおよび複数の製品間での診断データを関連付けた分析が可能になります。

問題点

問題とは、データベースで発生するクリティカル・エラーのことです。クリティカル・エラーには、ORA-00600などの内部エラーや、ORA-07445(オペレーティング・システムの例外)、ORA-04031(共有プールのメモリー不足)などのその他の重大なエラーが含まれます。問題はADRで追跡されます。各問題には、問題キーと一意の問題IDが割り当てられます(「問題キー」を参照。)

インシデント

インシデントは、問題が1回発生したことを表します。問題が複数回発生した場合は、発生ごとにインシデントが作成されます。インシデントはADR内で追跡されます。各インシデントは、数値型のインシデントIDによって識別されます。このIDはADR内で一意です。インシデントが発生すると、データベースによりアラート・ログ内にエントリが作成され、Oracle Enterprise Managerにインシデント・アラートが送信されます。次に、インシデントに関する診断データがダンプ・ファイルの形式(インシデント・ダンプ)で収集され、インシデントIDを使用してインシデント・ダンプにタグが付けられ、インシデント・ダンプがそのインシデント用に作成されたADRサブディレクトリに格納されます。

通常、クリティカル・エラーの診断と解決は、インシデント・アラートから開始されます。ADR内のすべてのインシデントのリストは、ADRCIコマンドを使用して取得できます。各インシデントは1つの問題にのみマップされます。

インシデントはフラッド制御されているため、1つの問題が生成するインシデントやインシデント・ダンプが多すぎることはありません。インシデント・フラッド制御の詳細は、『Oracle Database管理者ガイド』を参照してください。

問題キー

すべての問題には問題キーが割り当てられています。問題キーはエラー・コード(ORA 600など)を含むテキスト文字列で、1つ以上のエラー・パラメータを含むことがあります。2つのインシデントは、その2つの問題キーが一致した場合に発生原因が同じとみなされます。

インシデント・パッケージ

インシデント・パッケージ(パッケージ)は、1つ以上の問題に対するインシデント・データの集合です。Oracleサポート・サービスにインシデント・データを送信する前に、インシデント・パッケージング・サービス(IPS)を使用してパッケージにデータを収集する必要があります。パッケージを作成した後は、パッケージに外部ファイルを追加したり、パッケージ内からファイルを選択して削除することや、パッケージ内で選択したファイルを修正(編集)して機密データを削除することも可能です。

パッケージは、パッケージの内容から物理ファイルを作成するまでは論理構成のみです。つまり、インシデント・パッケージは、ADR内のメタデータの集合として開始されます。パッケージの内容を追加および削除する場合は、メタデータのみが変更されます。Oracleサポート・サービスへデータをアップロードする準備ができたら、データをZIPファイルに保存するADRCIを使用して物理パッケージを作成します。次に、ZIPファイルをOracleサポートにアップロードできます。

ファイナライズ

ADRCIで論理パッケージから物理パッケージを生成する前に、パッケージをファイナライズする必要があります。これにより、他のコンポーネントが呼び出され、相関診断データ・ファイルがこのパッケージにすでに存在するインシデントに追加されます。また、ファイナライズすることで、最新のトレース・ファイル、アラート・ログ・エントリ、状態モニター・レポート、SQLテスト・ケースおよび構成情報も追加されます。この手順は、物理パッケージが生成されると自動的に実行されますが、ADRCIユーティリティを使用して手動で実行することもできます。パッケージを手動でファイナライズした後、追加されたファイルを確認し、機密情報を含むファイルを削除または編集することができまます。

関連項目:

相関診断データの詳細は、『Oracle Database管理者ガイド』を参照してください。

ADRホーム

ADRホームは、特定のオラクル社の製品またはコンポーネントの特定のインスタンスに対するすべての診断データ(トレース、ダンプ、アラート・ログなど)のルート・ディレクトリです。たとえば、Oracle ASMを使用するOracle RAC環境では、各データベース・インスタンスと各Oracle ASMインスタンスにADRホームがあります。すべてのADRホームは、同じ階層ディレクトリ構造を共有します。各ADRホームの標準的なサブディレクトリには、アラート(アラート・ログ)、トレース(トレース・ファイル)およびインシデント(インシデント情報)を含むものもあります。すべてのADRホームはADRベース・ディレクトリ内に配置されます。(詳細は、「ADRベース」を参照してください。)

一部のADRCIコマンドは、同時に複数のADRホームでの動作が可能です。カレントADRCIホームパスにより、ADRCIコマンドの発行時に診断データを検索するADRホームが決定されます。詳細は、「ホームパス」を参照してください。

ADRベース

複数のADRホーム間で診断データの相関付けを行うことができるようにするために、ADRホームはADRベースと呼ばれる同じルート・ディレクトリ下でグループ化されます。たとえば、Oracle RAC環境では、ADRベースが共有ディスク上に存在し、各Oracle RACインスタンスのADRホームがこのADRベース下に配置される場合があります。

データベース・インスタンスのADRベースの場所は、DIAGNOSTIC_DEST初期化パラメータによって設定されます。このパラメータが指定されない場合またはNULLである場合は、データベースではこのパラメータがデフォルト値に設定されます。詳細は、『Oracle Database管理者ガイド』を参照してください。

複数のデータベース・インスタンスがOracleホームを共有しているときは、これらのインスタンスが複数の単一インスタンスであるかOracle RACデータベースの複数のインスタンスであるかどうかに関係なく、1つ以上のこれらのインスタンスがADRベースを異なる場所に設定している場合、最後に起動するインスタンスがADRCIのデフォルトADRベースを決定します。

ホームパス

すべてのADRCIコマンドは、カレントADRホーム内の診断データに対して動作します。常に複数のADRホームをカレントにできます。一部のADRCIコマンド(SHOW INCIDENTなど)は、すべてのカレントADRホームから診断データを検索して表示します。その他のコマンドは、1つのADRホームをとカレントとし、カレントADRホームが複数存在している場合はエラー・メッセージを表示します。

ADRCIホームパスにより、カレントであるADRホームが決定されます。これは、ADRベース階層内のディレクトリを指定することによって決定されます。1つのADRホーム・ディレクトリが指定されている場合、そのADRホームが唯一のカレントADRホームとなります。ホームパスが階層内のADRホーム・ディレクトリ・レベルより上位のディレクトリを示している場合は、そのディレクトリより下位のすべてのADRホームがカレントになります。

デフォルトでは、ADRCI起動時のホームパスはNULLです。つまり、ADRベース下のADRホームはすべてカレントになります。

SHOW HOMEおよびSHOW HOMEPATHの各コマンドは、カレントであるADRホームのリストを表示し、SET HOMEPATHコマンドはホームパスを設定します。

関連項目:

- ADRとそのディレクトリの構造および場所の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 「ADRCIコマンドを使用する前のADRCIホームパスの設定」

- 「SET HOMEPATH」

- 「SHOW HOMES」

ADRCIの起動とヘルプの利用

ADRCIは対話方式モードまたはバッチ・モードで使用できます。詳細は次の項を参照してください。

- 対話方式モードでのADRCIの使用方法

- ヘルプの利用

- バッチ・モードでのADRCIの使用方法

対話方式モードでのADRCIの使用方法

対話方式モードでは、個々のコマンドを1つずつ入力するように要求されます。

対話方式モードでADRCIを使用するには、次の手順に従います。

1. ORACLE_HOMEおよびPATH環境変数が適切に設定されていることを確認します。

Windowsプラットフォームの場合、これらの環境変数はインストール時に自動的にWindowsレジストリに設定されます。その他のプラットフォームの場合は、オペレーティング・システムのコマンドを使用して環境変数を設定および確認する必要があります。

PATH環境変数には、ORACLE_HOME/binが含まれている必要があります。

2. オペレーティング・システムのコマンド・プロンプトで、次のコマンドを入力します。

ADRCI

ユーティリティが起動し、次のプロンプトが表示されます。

adrci>

3. ADRCIコマンドを入力します。各コマンドの入力後に[Enter]キーを押します。

4. 次のコマンドのいずれかを入力して、ADRCIを終了します。

EXIT
QUIT

ヘルプの参照

ADRCIヘルプ・システムを使用すると、次の項目を実行できます。

- ADRコマンドのリストの表示

- 個々のコマンドのヘルプの表示

- ADRCIコマンドライン・オプションのリストの表示

ADRCIコマンドのリストを表示するには、次の手順に従います。

1. 対話方式モードでADRCIを起動します。
詳細は、「対話方式モードでのADRCIの使用方法」を参照してください。

2. ADRCIプロンプトで、次のコマンドを入力します。

HELP

特定のADRCIコマンドのヘルプを利用するには、次の手順に従います。

1. 対話方式モードでADRCIを起動します。

詳細は、「対話方式モードでのADRCIの使用方法」を参照してください。

2. ADRCIプロンプトで、次のコマンドを入力します。

HELP command

たとえば、SHOW TRACEFILEコマンドに関するヘルプを利用するには、次のように入力します。

HELP SHOW TRACEFILE

コマンドライン・オプションのリストを表示するには、次の手順に従います。

- オペレーティング・システムのコマンド・プロンプトで、次のコマンドを入力します。

ADRCI -HELP

ユーティリティによって、次のような出力が示されます。

Syntax:
adrci [-help] [script=script_filename] [exec="command [;command;...]"]

Options      Description                     (Default)
-----------------------------------------------------------------
script       script file name                (None)
help         help on the command options     (None)
exec         exec a set of commands          (None)
-----------------------------------------------------------------

バッチ・モードでのADRCIの使用方法

バッチ・モードを使用すると、入力を求めるプロンプトが表示されることなく、一連のADRCIコマンドを一度に実行できます。バッチ・モードを使用するには、ADRCIの起動時にADRCIコマンドにコマンドライン・パラメータを追加します。バッチ・モードでは、シェル・スクリプトまたはWindowsバッチ・ファイルにADRCIコマンドを含めることができます。対話方式モードと同様、ADRCIを起動する前に、ORACLE_HOMEおよびPATH環境変数を設定する必要があります。

次のコマンドライン・パラメータは、バッチ操作に使用できます。

表17-1 バッチ操作用のADRCIのコマンドライン・パラメータ

パラメータ

説明

EXEC

ADRCIを起動するオペレーティング・システム・コマンドラインで、1つ以上のADRCIコマンドを発行できます。コマンドが複数ある場合は、セミコロン(;)で区切ります。

SCRIPT

ADRCIコマンドを含むスクリプトを実行できます。

コマンドラインでADRCIコマンドを発行するには、次の手順に従います。

- オペレーティング・システムのコマンド・プロンプトで、次のコマンドを入力します。

ADRCI EXEC="COMMAND[; COMMAND]..."

たとえば、SHOW HOMESコマンドをバッチ・モードで実行するには、オペレーティング・システムのコマンド・プロンプトで次のコマンドを入力します。

ADRCI EXEC="SHOW HOMES"

SHOW HOMESコマンドを実行してから、SHOW INCIDENTコマンドを実行するには、次のように入力します。

ADRCI EXEC="SHOW HOMES; SHOW INCIDENT"

ADRCIスクリプトを実行するには、次の手順に従います。

- オペレーティング・システムのコマンド・プロンプトで、次のコマンドを入力します。

- ADRCI SCRIPT=SCRIPT_FILE_NAME

たとえば、adrci_script.txtというスクリプト・ファイルを実行するには、オペレーティング・システムのコマンド・プロンプトで次のコマンドを入力します。

ADRCI SCRIPT=adrci_script.txt

スクリプト・ファイルには、次のようにセミコロン(;)または改行で区切られた一連のコマンドが含まれています。

- SET HOMEPATH diag/rdbms/orcl/orcl; SHOW ALERT -term

ADRCIコマンドを使用する前のADRCIホームパスの設定

問題を診断するときは、複数のデータベース・インスタンスまたはコンポーネントからの診断データを使用する場合や、1つのインスタンスまたはコンポーネントからの診断データを対象とする場合があります。複数のインスタンスまたはコンポーネントからの診断データを使用するには、これらのインスタンスまたはコンポーネントすべてのADRホームがカレントであることを確認する必要があります。1つのインスタンスまたはコンポーネントからの診断データを使用するには、そのインスタンスまたはコンポーネントのADRホームのみがカレントであることを確認する必要があります。ADRCIホームパスを設定してカレントのADRホームを制御します。

複数のホームがカレントになっている場合は、ADRディレクトリ構造におけるホームパスは、直下に複数のADRホーム・ディレクトリを含むディレクトリを示しています。1つのADRホームを対象とするには、ホームパスをディレクトリ階層の下部にある1つのADRホーム・ディレクトリを示すように設定する必要があります。

たとえば、orclbiという名前のOracle RACデータベースが、SID orclbi1とorclbi2が指定された2つのインスタンスを持ち、Oracle RACが共有Oracleホームを使用している場合は、次の2つのADRホームが存在します。

/diag/rdbms/orclbi/orclbi1/
/diag/rdbms/orclbi/orclbi2/

すべてのADRCIコマンドおよび出力では、ADRホーム・ディレクトリ・パス(ADRホーム)は常にADRベースに対して相対的に示されます。したがって、ADRベースが現在/u01/app/oracleである場合、これら2つのADRホームの絶対パスは次のようになります。

/u01/app/oracle/diag/rdbms/orclbi/orclbi1/
/u01/app/oracle/diag/rdbms/orclbi/orclbi2/

SET HOMEPATHコマンドを使用して、1つ以上のADRホームをカレントに設定します。ADRベースが/u01/app/oracleである場合に、ホームパスを/u01/app/oracle/diag/rdbms/orclbi/orclbi2/に設定するには、このコマンドを次のように使用します。

adrci> set homepath diag/rdbms/orclbi/orclbi2

ADRCIの起動時には、ホームパスはデフォルトでNULLになります。つまり、ADRベース下のすべてのADRホームがカレントとなります。前述の例では、両方のOracle RACインスタンスのADRホームがカレントになります。

adrci> show homes
ADR Homes:
diag/rdbms/orclbi/orclbi1
diag/rdbms/orclbi/orclbi2

この場合、実行するADRCIコマンドはいずれも、複数のカレントADRホームをコマンドがサポートしていると想定して、両方のADRホームからの診断データを処理します。ホームパスを/diag/rdbms/orclbi/orclbi2に設定すると、orclbi2のSIDを持つインスタンスのADRホームのみがカレントになります。

adrci> set homepath diag/rdbms/orclbi/orclbi2
adrci> show homes
ADR Homes:
diag/rdbms/orclbi/orclbi2

この場合、実行するADRCIコマンドはいずれも、この1つのADRホームからの診断データのみを使用します。

関連項目:

- ADRホームの構造の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 「ADRベース」

- 「ADRホーム」

- 「ホームパス」

- 「SET HOMEPATH」

- 「SHOW HOMES」

アラート・ログの表示

Oracle Database 11g以上では、アラート・ログがXML形式のファイルおよびテキスト・ファイルの両方で書き込まれます。任意のテキスト・エディタでいずれかの形式のファイルを表示するか、ADRCIコマンドを実行してXMLタグを省略したXML形式のアラート・ログを表示することができます。デフォルトでは、ADRCIはデフォルトのエディタにアラート・ログを表示します。SET EDITORコマンドを使用すると、デフォルトのエディタを変更できます。

ADRCIでアラート・ログを表示するには、次の手順に従います。

1. 対話方式モードでADRCIを起動します。

詳細は、「ADRCIの起動とヘルプの利用」を参照してください。

2. (オプション)SET HOMEPATHコマンドを使用して、ADRホームを1つ選択します(カレントにします)。

最初にSHOW HOMESコマンドを使用すると、カレントのADRホームのリストを表示できます。詳細は、「ホームパス」および「ADRCIコマンドを使用する前のADRCIホームパスの設定」を参照してください。

3. ADRCIプロンプトで、次のコマンドを入力します。

SHOW ALERT

複数のADRホームがカレントの場合は、リストから1つのADRホームを選択するように要求されます。デフォルトのエディタに、XMLタグを省略したアラート・ログが表示されます。

4. エディタを終了し、ADRCIコマンド・プロンプトに戻ります。

SHOW ALERTコマンドのバリエーションを次に示します。

SHOW ALERT -TAIL

これは、ターミナル・セッションでのアラート・ログの最後の部分(最後の10エントリ)を表示します。

SHOW ALERT -TAIL 50

これは、ターミナル・セッションでのアラート・ログの最後の50エントリを表示します。

SHOW ALERT -TAIL -F

これは、アラート・ログの最後の10エントリを表示した後、アラート・ログに到着する追加メッセージを待機します。各メッセージは、到着時に表示に追加されます。このコマンドにより、アラート・ログのライブ監視を実行できます。待機を停止してADRCIプロンプトに戻るには、[Ctrl]を押しながら[C]を押します。

SPOOL /home/steve/MYALERT.LOG
SHOW ALERT -TERM
SPOOL OFF

これは、XMLタグのないアラート・ログを/home/steve/MYALERT.LOGファイルに出力します。

SHOW ALERT -P "MESSAGE_TEXT LIKE '%ORA-600%'"

これは、文字列ORA-600を含むアラート・ログ・メッセージのみを表示します。出力は次のようになります。

ADR Home = /u01/app/oracle/product/11.1.0/db_1/log/diag/rdbms/orclbi/orclbi:
******************************************************************************
01-SEP-06 09.17.44.849000000 PM -07:00
AlertMsg1: ORA-600 dbgris01, addr=0xa9876541

関連項目:

- 「SHOW ALERT」

- 「SET EDITOR」

- Oracle Enterprise Managerまたはテキスト・エディタを使用してアラート・ログを表示する方法については、『Oracle Database管理者ガイド』を参照してください。

トレース・ファイルの検索

ADRCIにより、現在自動診断リポジトリ(ADR)に存在するトレース・ファイルの名前が表示できます。ADR内に存在するすべてのトレース・ファイルの名前を表示することも、フィルタを適用して名前のサブセットを表示することもできます。たとえば、ADRCIのコマンドで、次の操作を行うことができます。

- ファイル名が検索文字列と一致するトレース・ファイルのリストの取得

- 特定のディレクトリ内に存在するトレース・ファイルのリストの取得

- 特定のインシデントに関連するトレース・ファイルのリストの取得

適切なコマンドライン・パラメータを使用して、フィルタ処理機能を組み合せることができます。

SHOW TRACEFILEコマンドは、カレントADRホーム下のトレース・ディレクトリおよびインシデント・ディレクトリに存在するトレース・ファイルのリストを表示します。複数のADRホームがカレントの場合、すべてのADRホームからのトレース・ファイル・リストが順次出力されます。

次の文は、フィルタ処理を行わずに、カレントADRホームに存在するすべてのトレース・ファイルの名前を表示します。

SHOW TRACEFILE

次の文は、ファイル名に文字列mmonが含まれるすべてのトレース・ファイルの名前を表示します。パーセント符号(%)はワイルドカード文字として使用されます。また、検索文字列では大/小文字が区別されます。

SHOW TRACEFILE %mmon%

この文は、/home/steve/tempディレクトリ内でファイル名に文字列mmonを含むすべてのトレース・ファイルの名前を表示します。

SHOW TRACEFILE %mmon% -PATH /home/steve/temp

この文は、トレース・ファイルの名前を、最終変更時間を逆にたどる順序でリストします。つまり、最近変更されたトレース・ファイルがリストの最初に示されます。

SHOW TRACEFILE -RT

この文は、インシデント番号1681に関連付けられているすべてのトレース・ファイルの名前を表示します。

SHOW TRACEFILE -I 1681

関連項目:

- 「SHOW TRACEFILE」

- ADRのディレクトリ構造の詳細は、『Oracle Database管理者ガイド』を参照してください。

インシデントの表示

ADRCIのSHOW INCIDENTコマンドでは、未解決のインシデントに関する情報が表示されます。インシデントごとに、インシデントID、問題キーおよびインシデント作成時間が表示されます。複数のカレントADRホームが存在するようにADRCIホームパスが設定されている場合、レポートにはすべてのカレントADRホームからのインシデントが含まれます。

すべての未解決のインシデントに関するレポートを表示するには、次の手順に従います。

1. ADRCIを対話方式モードで開始し、ホームパスがADRベース・ディレクトリ階層内で正確なディレクトリを示していることを確認します。

詳細は、「ADRCIの起動とヘルプの利用」および「ホームパス」を参照してください。

2. ADRCIプロンプトで、次のコマンドを入力します。

SHOW INCIDENT

ADRCIによって、次のような出力が生成されます。

ADR Home = /u01/app/oracle/product/11.1.0/db_1/log/diag/rdbms/orclbi/orclbi:
*****************************************************************************
INCIDENT_ID       PROBLEM_KEY               CREATE_TIME
----------------- ------------------------- ---------------------------------
3808              ORA 603                   2010-06-18 21:35:49.322161 -07:00
3807              ORA 600 [4137]            2010-06-18 21:35:47.862114 -07:00
3805              ORA 600 [4136]            2010-06-18 21:35:25.012579 -07:00
3804              ORA 1578                  2010-06-18 21:35:08.483156 -07:00
4 rows fetched

SHOW INCIDENTコマンドのバリエーションを次に示します。

SHOW INCIDENT -MODE BRIEF
SHOW INCIDENT -MODE DETAIL

これらのコマンドは、インシデント・レポートの詳細バージョンを生成します。

SHOW INCIDENT -MODE DETAIL -P "INCIDENT_ID=1681"

これは、インシデント1681のみを対象とする詳細なインシデント・レポートを表示します。

関連項目:

ADRCIコマンド・リファレンス

インシデントのパッケージ化

Oracleサポート・サービスに送信して分析を依頼するために、ADRCIコマンドを使用して1つ以上のインシデントをパッケージ化できます。詳細は、次の項目を参照してください。

- インシデントのパッケージ化

- インシデント・パッケージの作成

インシデントのパッケージ化

インシデントのパッケージ化プロセスは次の3つの手順で構成されています。

手順1: 論理インシデント・パッケージの作成

インシデント・パッケージ(パッケージ)は、自動診断リポジトリ(ADR)内のメタデータとしてのみ存在するため、論理パッケージとして示されます。インシデント・パッケージは、論理パッケージから物理パッケージを生成するまではコンテンツが含まれません。論理パッケージにはパッケージ番号が割り当てられますので、以降のコマンドではこの番号を使用してパッケージを参照します。

論理パッケージは空のパッケージとして作成することも、インシデント番号、問題番号、問題キーまたは時間間隔に基づいたパッケージとして作成することもできます。パッケージを空のパッケージとして作成する場合は、手順2でパッケージに診断情報を追加できます。

インシデントに基づいてパッケージを作成する場合は、そのインシデントの診断データ(ダンプ、状態モニターのレポートなど)が含まれます。問題番号または問題キーに基づいてパッケージを作成する場合は、パッケージにその問題番号または問題キーを参照するインシデントの診断データが含まれます。時間間隔に基づいてパッケージを作成する場合は、その時間間隔内で発生したインシデントに関する診断データが含まれます。

手順2: インシデント・パッケージへの診断情報の追加

インシデント番号、問題番号、問題キーまたは時間間隔に基づいて論理パッケージを作成した場合、この手順はオプションとなります。パッケージにインシデントを追加したり、ADR内のファイルをパッケージに追加することができます。空のパッケージを作成した場合は、ADRCIコマンドを使用してパッケージにインシデントまたはファイルを追加する必要があります。

手順3: 物理インシデント・パッケージの生成

コマンドを送信して物理パッケージを生成するときに、ADRCIは必要なすべての診断ファイルを収集して、指定したディレクトリ内のZIPファイルに追加します。完全なZIPファイルまたは増分ZIPファイルを生成できます。増分ファイルには、同じ論理パッケージに対してZIPファイルが最後に作成されて以降に追加または変更された診断ファイルすべてが含まれます。増分ファイルは完全ファイルを作成した後にのみ作成でき、必要な数だけ作成できます。各ZIPファイルには順序番号が割り当てられるため、ファイルを正しい順序で分析できます。

ZIPファイルの名前は次の形式に従って指定されます。

packageName_mode_sequence.zip

説明:

- packageNameは、問題キーの一部とその後のタイムスタンプで構成されます。

- modeは、COM(完全)またはINC(増分)のいずれかです

- sequenceは、整数です。

たとえば、2006年9月6日午後4時53分に作成した論理パッケージの完全なZIPファイルを生成してから、同じ論理パッケージに対して増分ZIPファイルを生成する場合、次のような名前のファイルを作成します。

ORA603_20060906165316_COM_1.zip
ORA603_20060906165316_INC_2.zip

インシデント・パッケージの作成

次の各項では、論理インシデント・パッケージ(パッケージ)の作成および物理パッケージの生成に使用するADRCIコマンドについて説明します。

- 論理インシデント・パッケージの作成

- 論理インシデント・パッケージへの診断情報の追加

- 物理インシデント・パッケージの生成

関連項目:

「インシデントのパッケージ化」

論理インシデント・パッケージの作成

IPS CREATE PACKAGEコマンドの変形を使用して、論理パッケージ(パッケージ)を作成します。

インシデントに基づいてパッケージを作成するには、次の手順に従います。

1. ADRCIを対話方式モードで開始し、ホームパスがADRベース・ディレクトリ階層内で正確なディレクトリを示していることを確認します。

詳細は、「ADRCIの起動とヘルプの利用」および「ホームパス」を参照してください。

2. ADRCIプロンプトで、次のコマンドを入力します。

IPS CREATE PACKAGE INCIDENT incident_number

たとえば、次のコマンドはインシデント3に基づいてパッケージを作成します。

IPS CREATE PACKAGE INCIDENT 3

ADRCIによって、次のような出力が生成されます。

Created package 10 based on incident id 3, correlation level typical

この論理パッケージに割り当てられたパッケージ番号は10です。

IPS CREATE PACKAGEコマンドのバリエーションを次に示します。

IPS CREATE PACKAGE

これは空のパッケージを作成します。IPS ADD INCIDENTまたはIPS ADD FILEの各コマンドを使用して、生成する前にパッケージに診断データを追加する必要があります。

IPS CREATE PACKAGE PROBLEM problem_ID

これは、パッケージを作成して、指定した問題ID(問題IDは整数)を参照するインシデントの診断情報を含めます。(問題IDは整数です。)表示されているレポートからインシデントの問題IDを取得するには、SHOW INCIDENT -MODE BRIEFコマンドを使用します。同じ問題IDを割り当てられたインシデントが数多く存在する場合もあるため、ADRCIは、90日を超えるインシデントを除き、この問題IDを持つインシデントで最初に発生した3つのインシデント(早期インシデント)と最後に発生した3つのインシデント(最新インシデント)の診断情報をパッケージに追加します。

注意:

早期インシデントと最新インシデントの数と90日の経過日数制限はデフォルト値であり、変更が可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

また、ADRCIによって、すでに追加されているインシデントに時間その他の基準で密接に相関付けられている他のインシデントが追加される場合もあります。

IPS CREATE PACKAGE PROBLEMKEY "problem_key"

これは、パッケージを作成し、指定した問題キーを参照するインシデントの診断情報を含めます。表示されているレポートから問題キーを取得するには、SHOW INCIDENTコマンドを使用します。同じ問題キーを割り当てられたインシデントが数多く存在する場合もあるため、ADRCIは、90日を超えるインシデントを除き、この問題キーを持つインシデントで最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントの診断情報のみをパッケージに追加します。

注意:

早期インシデントと最新インシデントの数と90日の経過日数制限はデフォルト値であり、変更が可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

また、ADRCIによって、すでに追加されているインシデントに時間その他の基準で密接に相関付けられている他のインシデントが追加される場合もあります。

問題キーに空白や引用符が含まれている場合、問題キーを一重引用符(')または二重引用符(")で囲む必要があります。

IPS CREATE PACKAGE SECONDS sec

これは、パッケージを作成し、sec秒前から現在までに発生したすべてのインシデントの診断情報を含みます。secは整数である必要があります。

IPS CREATE PACKAGE TIME 'start_time' TO 'end_time'

これは、パッケージを作成し、指定した時間範囲内で発生したすべてのインシデントの診断情報を含めます。start_timeおよびend_timeは、YYYY-MM-DD HH24:MI:SS.FF TZR書式で指定する必要があります。これは、NLS_TIMESTAMP_TZ_FORMAT初期化パラメータに対して有効なフォーマット文字列です。時間の小数(FF)部分はオプションで、HH24:MI:SSのデリミタにはコロンまたはピリオドを使用できます。

たとえば、次のコマンドは、2010年7月24日から7月30日に発生したインシデントを含むパッケージを作成します。

IPS CREATE PACKAGE TIME '2010-07-24 00:00:00 -07:00' to '2010-07-30 23.59.59 -07:00'

関連項目:

「IPS CREATE PACKAGE」

論理インシデント・パッケージへの診断情報の追加

既存の論理パッケージ(パッケージ)に次の診断情報を追加できます。

- 特定のインシデントに関するすべての診断情報

- ADR内の名前付きファイル

既存のパッケージにインシデントを追加するには、次の手順に従います。

1. ADRCIを対話方式モードで開始し、ホームパスがADRベース・ディレクトリ階層内で正確なディレクトリを示していることを確認します。

詳細は、「ADRCIの起動とヘルプの利用」および「ホームパス」を参照してください。

2. ADRCIプロンプトで、次のコマンドを入力します。

IPS ADD INCIDENT incident_number PACKAGE package_number

既存のパッケージにADR内のファイルを追加するには、次の手順に従います。

- ADRCIプロンプトで、次のコマンドを入力します。

IPS ADD FILE filespec PACKAGE package_number

filespecは、(パスを含む)完全修飾ファイル名である必要があります。ADRベース・ディレクトリ階層内に存在するファイルのみを追加できます。

関連項目:

ADRCIコマンド・リファレンス

物理インシデント・パッケージの生成

パッケージを生成するときは、既存の論理パッケージに対して物理パッケージ(ZIPファイル)を作成します。

物理インシデント・パッケージを生成するには、次の手順に従います。

1. ADRCIを対話方式モードで開始し、ホームパスがADRベース・ディレクトリ階層内で正確なディレクトリを示していることを確認します。

詳細は、「ADRCIの起動とヘルプの利用」および「ホームパス」を参照してください。

2. ADRCIプロンプトで、次のコマンドを入力します。

IPS GENERATE PACKAGE package_number IN path

これは、指定したパスに完全な物理パッケージ(ZIPファイル)を生成します。たとえば、次のコマンドは、ディレクトリ/home/steve/diagnosticsに論理パッケージ番号2から完全な物理パッケージを作成します。

IPS GENERATE PACKAGE 2 IN /home/steve/diagnostics

また、最後にパッケージを生成して以降に発生したインシデントのみを含む増分パッケージも生成できます。

増分物理インシデント・パッケージを生成するには、次の手順に従います。

- ADRCIプロンプトで、次のコマンドを入力します。

IPS GENERATE PACKAGE package_number IN path INCREMENTAL

関連項目:

- ADRCIコマンド・リファレンス

- 「インシデントのパッケージ化」

ADRCIコマンド・リファレンス

ADRCIには次の4種類のコマンドが用意されています。

- 1つ以上のカレントADRホームで動作するコマンド

- 1つのカレントADRホームのみで動作し、複数のカレントADRホームが存在する場合にはエラー・メッセージを発行するコマンド

- 複数のカレントADRホームが存在するときに、1つのADRホームを選択するように要求するコマンド

- カレントADRホームを必要としないコマンド

すべてのADRCIコマンドは、1つのカレントADRホームが存在する場合をサポートしています。

表17-2では、ADRCIコマンド・セットを一覧表示します。

表17-2 ADRCIコマンドのリスト

コマンド

説明

CREATE REPORT

指定したレポート・タイプおよびIDのレポートを作成します。

ECHO

入力文字列をエコー処理します。

EXIT

カレントのADRCIセッションを終了します。

HOST

ADRCIからオペレーティング・システムのコマンドを実行します。

IPS

IPSユーティリティを起動します。ADRCI内で使用可能なIPSコマンドについては、表17-3を参照してください。

PURGE

現在の削除ポリシーに従って、カレントADRホーム内の診断データを削除します。

QUIT

カレントのADRCIセッションを終了します。

RUN

ADRCIスクリプトを実行します。

SELECT

指定されたインシデントまたは問題から、修飾されたレコードを取得します。

SET BASE

カレントADRCIセッションのADRベースを設定します。

SET BROWSER

将来の使用のために予約されています。

SET CONTROL

ADRの内容の削除ポリシーを設定します。

SET ECHO

コマンド出力を切り替えます。

SET EDITOR

トレース・ログおよびアラート・ログの内容を表示するデフォルトのエディタを設定します。

SET HOMEPATH

1つ以上のADRホームをカレントにします。

SET TERMOUT

ターミナル出力を切り替えます。

SHOW ALERT

アラート・ログ・メッセージを表示します。

SHOW BASE

カレントADRベースを示します。

SHOW CONTROL

カレントの削除ポリシーを含むADR情報を表示します。

SHOW HM_RUN

状態モニターの実行情報を表示します。

SHOW HOMEPATH

カレントのホームパスを表示します。

SHOW HOMES

カレントのADRホームを表示します。

SHOW INCDIR

指定したインシデントに対して作成されたトレース・ファイルを表示します。

SHOW INCIDENT

インシデントのリストを出力します。

SHOW LOG

診断ログ・メッセージを表示します。

SHOW PROBLEM

問題のリストを出力します。

SHOW REPORT

指定したレポート・タイプおよびIDのレポートを表示します。

SHOW TRACEFILE

修飾されたトレース・ファイル名を表示します。

SPOOL

出力をファイルへ送信します。

注意:

特に指定されないかぎり、すべてのコマンドは複数のカレントADRホームで動作します。

CREATE REPORT

用途

指定したレポート・タイプと実行IDのレポートを作成し、そのレポートをADRに格納します。現在は、hm_run(状態モニター)レポート・タイプのみがサポートされています。

注意:

状態モニターの実行の結果は、内部形式でADRに格納されます。これらの結果を表示するには、結果から状態モニター・レポートを作成した後に、このレポートを表示する必要があります。レポートは1回のみ作成する必要があります。その後は、このレポートを複数回表示できます。

構文および説明

create report report_type run_name

report_typeはhm_runである必要があります。run_nameは状態モニターの実行名です。SHOW HM_RUNコマンドを使用して実行名を取得します。

すでにレポートが存在する場合は、そのレポートが上書きされます。レポートを表示するにはSHOW REPORTコマンドを使用します。

このコマンドは、複数のADRホームをサポートしていません。

例

この例では、実行名hm_run_1421を使用した状態モニターの実行に対するレポートを作成します。

create report hm_run hm_run_1421

注意:

CREATE REPORTは、複数のADRホームが設定されている場合には機能しません。1つのADRホームの設定については、「ADRCIコマンドを使用する前のADRCIホームパスの設定」を参照してください。

ECHO

用途

入力文字列を出力します。このコマンドを使用すると、ADRCIスクリプトからカスタム・テキストを出力できます。

構文および説明

echo quoted_string

文字列は、一重引用符または二重引用符で囲んで記述します。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

次の例は、文字列Hello, world!を出力します。

echo "Hello, world!"

echo 'Hello, world!'

EXIT

用途

ADRCIユーティリティを終了します。

構文および説明

exit

EXITは、QUITコマンドのシノニムです。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

HOST

用途

ADRCIを終了しないでオペレーティング・システムのコマンドを実行します。

構文および説明

host ["host_command_string"]

hostのみを使用すると、オペレーティング・システムのシェルに入り、複数のオペレーティング・システムのコマンドを入力できるようになります。シェルを終了してADRCIに戻るにはEXITを入力します。

同じ行でコマンド(host_command_string)を二重引用符で囲んで指定することもできます。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

host

host "ls -l *.pl"

IPS

用途

インシデント・パッケージング・サービス(IPS)を呼び出します。IPSコマンドは、論理インシデント・パッケージ(パッケージ)の作成、パッケージへの診断データの追加、およびOracleサポート・サービスへ送信する物理パッケージの生成を行うためのオプションを提供します。

関連項目:

パッケージ化の詳細は、「インシデントのパッケージ化」を参照してください

IPSのコマンド・セットには次のコマンドが含まれます。

表17-3 IPSのコマンド・セット

コマンド

説明

IPS ADD

インシデント、問題または問題キーをパッケージに追加します。

IPS ADD FILE

ファイルをパッケージに追加します。

IPS ADD NEW INCIDENTS

指定したパッケージ内の問題に対する新しいインシデントを検索して追加します。

IPS COPY IN FILE

外部ファイル・システムからADRへファイルをコピーします。

IPS COPY OUT FILE

ADRから外部ファイル・システムへファイルをコピーします。

IPS CREATE PACKAGE

新しい(論理)パッケージを作成します。

IPS DELETE PACKAGE

ADRからパッケージおよびその内容を削除します。

IPS FINALIZE

アップロードする前にパッケージをファイナライズします。

IPS GENERATE PACKAGE

指定したパッケージの内容のZIPファイルをターゲット・ディレクトリに生成します。

IPS GET MANIFEST

パッケージのZIPファイルからマニフェストを取得して表示します。

IPS GET METADATA

パッケージのZIPファイルからメタデータを抽出して表示します。

IPS PACK

インシデント、問題または問題キーから直接物理パッケージ(ZIPファイル)を作成します。

IPS REMOVE

既存のパッケージからインシデントを削除します。

IPS REMOVE FILE

既存のパッケージからファイルを削除します。

IPS SET CONFIGURATION

IPS構成パラメータの値を変更します。

IPS SHOW CONFIGURATION

IPS構成パラメータの値を表示します。

IPS SHOW FILES

パッケージ内のファイルを一覧表示します。

IPS SHOW INCIDENTS

パッケージ内のインシデントを一覧表示します。

IPS SHOW PACKAGE

指定したパッケージに関する情報を表示します。

IPS UNPACK FILE

パッケージのZIPファイルを指定したパスに解凍します。

注意:

IPSコマンドは、複数のADRホームが設定されている場合には機能しません。1つのADRホームの設定については、「ADRCIコマンドを使用する前のADRCIホームパスの設定」を参照してください。

IPSコマンドでの<ADR_HOME>および<ADR_BASE>変数の使用

IPSのコマンド・セットは、カレントADRホームおよびADRベースのディレクトリを参照するためのショートカットを提供します。カレントADRホームのディレクトリにアクセスするには、<ADR_HOME>変数を次のように使用します。

ips add file <ADR_HOME>/trace/orcl_ora_13579.trc package 12

ADRベース・ディレクトリにアクセスするには、<ADR_BASE>変数を次のように使用します。

ips add file <ADR_BASE>/diag/rdbms/orcl/orcl/trace/orcl_ora_13579.trc package 12

注意:

山カッコ(< >)は、ここに示すとおりに入力します。

IPS ADD

用途

インシデントをパッケージに追加します。

構文および説明

ips add {incident first [n] | incident inc_id | incident last [n] |
problem first [n] | problem prob_id | problem last [n] |
problemkey pr_key | seconds secs | time start_time to end_time}
package package_id

表17-4に、IPS ADDの引数を示します。

表17-4 IPS ADDコマンドの引数

引数

説明

incident first [n]

最初に発生したnつのインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最初に発生した5つのインシデントが追加されます。nを省略すると、デフォルトの1となり、最初に発生したインシデントが追加されます。

incident inc_id

IDがinc_idのインシデントをパッケージに追加します。

incident last [n]

最後に発生したnつのインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最後に発生した5つのインシデントが追加されます。nを省略すると、デフォルトの1となり、最後に発生したインシデントが追加されます。

problem first [n]

最初に発生したnつの問題のインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最初に発生した5つの問題のインシデントが追加されます。nを省略すると、デフォルトの1となり、最初に発生した問題のインシデントが追加されます。

90日を超えるインシデントを除き、各問題について、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

problem prob_id

問題IDがprob_idのインシデントをすべてパッケージに追加します。90日を超えるインシデントを除き、その問題について、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

problem last [n]

最後に発生したnつの問題のインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最後に発生した5つの問題のインシデントが追加されます。nが省略されると、デフォルトの1となり、最後に発生した問題のインシデントが追加されます。

90日を超えるインシデントを除き、各問題について、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

problemkey pr_key

問題キーがpr_keyのインシデントをパッケージに追加します。90日を超えるインシデントを除き、その問題キーについて、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。)

seconds secs

現時点で過去secs秒以内に発生したすべてのインシデントを追加します。

time start_time to end_time

start_timeとend_timeの間のすべてのインシデントをパッケージに追加します。時刻の書式はYYYY-MM-YY HH24:MI:SS.FF TZRです。小数部分(FF)はオプションです。

package package_id

インシデントの追加先となるパッケージを指定します。

例

この例では、インシデント22をパッケージ12に追加します。

ips add incident 22 package 12

この例では、90日を超えるインシデントを除き、問題IDが6の最初に発生した3つの早期インシデントおよび最後に発生した3つの最新インシデントをパッケージ2に追加します。

ips add problem 6 package 2

この例では、過去1分間に発生したすべてのインシデントをパッケージ5に追加します。

ips add seconds 60 package 5

この例では、2010年5月1日の午前10時から午後11時の間に発生したすべてのインシデントを追加します。

ips add  time '2010-05-01 10:00:00.00 -07:00' to '2010-05-01 23:00:00.00 -07:00'

IPS ADD FILE

用途

ファイルを既存のパッケージに追加します。

構文および説明

ips add file file_name package package_id

file_nameは、ファイルのフルパス名です。必要に応じて、<ADR_HOME>および<ADR_BASE>変数を使用できます。ファイルは、パッケージと同じADRベース下に存在する必要があります。

package_idはパッケージのIDです。

例

この例では、トレース・ファイルをパッケージ12に追加します。

ips add file <ADR_HOME>/trace/orcl_ora_13579.trc package 12

関連項目:

<ADR_HOME>ディレクトリ構文の詳細は、「IPSコマンドでの<ADR_HOME>および<ADR_BASE>変数の使用」を参照してください

IPS ADD NEW INCIDENTS

用途

指定したパッケージ内の問題すべてに対して新しいインシデントを検索して追加します。

構文および説明

ips add new incidents package package_id

package_idは更新するパッケージのIDです。パッケージ内の問題の新しいインシデントのみが追加されます。

例

この例では、パッケージ12内の問題について新しい最新インシデントを3つまで追加します。

ips add new incidents package 12

注意:

追加される最新インシデントの数はデフォルト値であり、変更が可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

IPS COPY IN FILE

用途

外部ファイル・システムからADRへファイルをコピーします。

パッケージ内のファイルを編集するには、ファイルを指定したディレクトリにコピーし、そのファイルを編集してから、コピーして元のパッケージに戻す必要があります。この作業は、パッケージをOracleサポート・サービスに送信する前にファイル内の機密データを削除するために行うことがあります。

構文および説明

ips copy in file filename [to new_name][overwrite] package package_id
[incident incid]

外部ファイルfilename(フルパス名で指定)をADRにコピーし、その際に既存のパッケージpackage_idおよびオプションでインシデントincidと関連付けます。ADR内でコピーされたファイルに新しいファイル名を付ける場合は、to new_nameオプションを使用します。すでに存在するファイルを上書きする場合は、overwriteオプションを使用します。

例

この例では、トレース・ファイルをファイル・システムからADRにコピーします。ファイルはパッケージ2およびインシデント4に関連付けます。

ips copy in file /home/nick/trace/orcl_ora_13579.trc to <ADR_HOME>/trace/orcl_ora_13579.trc package 2 incident 4

関連項目:

- <ADR_HOME>変数の詳細は、「IPSコマンドでの<ADR_HOME>および<ADR_BASE>変数の使用」を参照してください

- パッケージ内のファイルの一覧表示については、「IPS SHOW FILES」を参照してください

IPS COPY OUT FILE

用途

ADRから外部ファイル・システムへファイルをコピーします。

パッケージ内のファイルを編集するには、ファイルを指定したディレクトリにコピーし、そのファイルを編集してから、コピーして元のパッケージに戻す必要があります。この作業は、パッケージをOracleサポート・サービスに送信する前にファイル内の機密データを削除するために行うことがあります。

構文および説明

ips copy out file source to target [overwrite]

ファイルsourceをADRの外の場所target(フルパス名で指定)にコピーします。すでに存在するファイルを上書きする場合は、overwriteオプションを使用します。

例

この例では、カレントのADRホームのトレース・サブディレクトリ内のファイルorcl_ora_13579.trcをローカル・フォルダにコピーします。

ips copy out file <ADR_HOME>/trace/orcl_ora_13579.trc to /home/nick/trace/orcl_ora_13579.trc

関連項目:

- <ADR_HOME>ディレクトリ構文の詳細は、「IPSコマンドでの<ADR_HOME>および<ADR_BASE>変数の使用」を参照してください

- パッケージ内のファイルの一覧表示については、「IPS SHOW FILES」を参照してください

IPS CREATE PACKAGE

用途

新しいパッケージを作成します。ADRCIにより、新しいパッケージに対してパッケージ番号が自動的に割り当てられます。

構文および説明

ips create package {incident first [n] | incident inc_id |
incident last [n] | problem first [n] | problem prob_id |
problem last [n] | problemkey prob_key | seconds secs |
time start_time to end_time} [correlate {basic |typical | all}]

また、指定されたオプションを使用しても、インシデントを新しいパッケージに追加できます。

表17-5に、IPS CREATE PACKAGEの引数を示します。

表17-5 IPS CREATE PACKAGEコマンドの引数

引数

説明

incident first [n]

最初に発生したnつのインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最初に発生した5つのインシデントが追加されます。nを省略すると、デフォルトの1となり、最初に発生したインシデントが追加されます。

incident inc_id

IDがinc_idのインシデントをパッケージに追加します。

incident last [n]

最後に発生したnつのインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最後に発生した5つのインシデントが追加されます。nを省略すると、デフォルトの1となり、最後に発生したインシデントが追加されます。

problem first [n]

最初に発生したnつの問題のインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最初に発生した5つの問題のインシデントが追加されます。nを省略すると、デフォルトの1となり、最初に発生した問題のインシデントが追加されます。

90日を超えるインシデントを除き、各問題について、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

problem prob_id

問題IDがprob_idのインシデントをすべてパッケージに追加します。90日を超えるインシデントを除き、その問題について、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

problem last [n]

最後に発生したnつの問題のインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最後に発生した5つの問題のインシデントが追加されます。nが省略されると、デフォルトの1となり、最後に発生した問題のインシデントが追加されます。

90日を超えるインシデントを除き、各問題について、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

problemkey pr_key

問題キーがpr_keyのインシデントをすべてパッケージに追加します。90日を超えるインシデントを除き、その問題キーについて、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。)

seconds secs

現時点で過去secs秒以内に発生したすべてのインシデントを追加します。

time start_time to end_time

start_timeとend_timeの間に発生したすべてのインシデントをパッケージに追加します。時刻の書式はYYYY-MM-YY HH24:MI:SS.FF TZRです。小数部分(FF)はオプションです。

correlate {basic |typical | all}

パッケージに相関インシデントを指定する方法を選択します。この引数には3つのオプションがあります。

- correlate basicを選択すると、インシデント・ダンプおよびインシデント・プロセスのトレース・ファイルが指定されます。

- correlate typicalを選択すると、各インシデントのインシデント・ダンプ、および5分以内に変更されたトレース・ファイルが指定されます。時間間隔を変更するには、INCIDENT_TIME_WINDOW構成パラメータを変更します。

- correlate allを選択すると、インシデント・ダンプ、およびインシデントが最初に選択された時刻と最後に選択された時刻の間に変更されたすべてのトレース・ファイルが指定されます。

デフォルト値はcorrelate typicalです。

例

この例では、インシデントを含まないパッケージを作成します。

ips create package

出力例:

Created package 5 without any contents, correlation level typical

この例では、指定された日の午前10時から午後11時の間に発生したすべてのインシデントを含むパッケージを作成します。

ips create package time '2010-05-01 10:00:00.00 -07:00' to '2010-05-01 23:00:00.00 -07:00'

出力例:

Created package 6 based on time range 2010-05-01 10:00:00.00 -07:00 to 2010-05-01 23:00:00.00 -07:00, correlation level typical

この例では、パッケージを作成し、90日を超えるインシデントを除いて、問題IDが3の最初に発生した3つの早期インシデントおよび最後に発生した3つの最新インシデントを追加します。

ips create package problem 3

出力例:

Created package 7 based on problem id 3, correlation level typical

注意:

追加される早期インシデントと最新インシデントの数と90日の経過日数制限はデフォルト値であり、変更が可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

関連項目:

インシデント・パッケージの作成

IPS DELETE PACKAGE

用途

ADRからパッケージおよびその内容を削除します。

構文および説明

ips delete package package_id

package_idは削除するパッケージです。

例

ips delete package 12

IPS FINALIZE

用途

アップロードする前にパッケージをファイナライズします。

構文および説明

ips finalize package package_id

package_idはファイナライズするパッケージのIDです。

例

ips finalize package 12

関連項目:

パッケージのファイナライズの詳細は、『Oracle Database管理者ガイド』を参照してください。

IPS GENERATE PACKAGE

用途

ターゲット・ディレクトリに物理パッケージ(ZIPファイル)を作成します。

構文および説明

ips generate package package_id [in path] [complete | incremental]

package_idは生成するパッケージのIDです。オプションで、ディレクトリpathにファイルを保存できます。このオプションを指定しない場合、パッケージは現在の作業ディレクトリに生成されます。

completeオプションを指定すると、ADRCIにより、すべてのパッケージ・ファイルがパッケージに強制的に含まれるようになります。これはデフォルトの動作です。

incrementalオプションを選択すると、このパッケージが最後に生成された後に追加または変更されたファイルのみが指定されます。したがって、incrementalオプションでのコマンドの動作はより短い時間で終了します。

例

この例では、パス/home/steveに物理パッケージ・ファイルを生成します。

ips generate package 12 in /home/steve

この例では、物理パッケージが最後に生成された後に追加または変更されたファイルからパッケージを生成します。

ips generate package 14 incremental

関連項目:

「物理インシデント・パッケージの生成」

IPS GET MANIFEST

用途

パッケージのZIPファイルからマニフェストを抽出して表示します。

構文および説明

ips get manifest from file filename

filenameは、パッケージのZIPファイルです。マニフェストは、パッケージ・ファイルのXML形式のメタデータのセットで、ADR構成、相関ファイル、インシデントおよびパッケージが生成された方法に関する情報を含みます。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

ips get manifest from file /home/steve/ORA603_20060906165316_COM_1.zip

IPS GET METADATA

用途

パッケージ・ファイルからADR関連のメタデータを抽出して表示します。

構文および説明

ips get metadata {from file filename | from adr}

filenameは、パッケージのZIPファイルです。(metadata.xmlに格納されている)パッケージ・ファイルのメタデータには、ADRホーム、ADRベースおよび製品に関する情報が含まれています。

IPS UNPACKを使用してADRホームに解凍されたパッケージZIPファイルからメタデータを取得するには、from adrオプションを使用します。

from adrオプションを使用する場合は、ADRホームを設定する必要があります。

例

この例では、パッケージ・ファイルからメタデータを表示します。

ips get metadata from file /home/steve/ORA603_20060906165316_COM_1.zip

次の例では、ディレクトリ/scratch/oracle/package1に解凍したパッケージ・ファイルからメタデータを表示します。

set base /scratch/oracle/package1
ips get metadata from adr

前述の例でADRCIは、SET BASEコマンドを受け取ると、IPS UNPACK FILEコマンドで/scratch/oracle/package1に作成されたADRホームをホームパスに自動的に追加します。

関連項目:

パッケージ・ファイルの解凍の詳細は、「IPS UNPACK FILE」を参照してください

IPS PACK

用途

すぐにパッケージを作成して、物理パッケージを生成します。

構文および説明

ips pack [incident first [n] | incident inc_id | incident last [n] |
problem first [n] | problem prob_id | problem last [n] |
problemkey prob_key | seconds secs | time start_time to end_time]
[correlate {basic |typical | all}] [in path]

ADRCIにより、自動的に新しいパッケージに対してパッケージ番号が生成されます。パッケージの内容が指定されない場合、IPS PACKは空のパッケージを作成します。

表17-6に、IPS PACKの引数を示します。

表17-6 IPS PACKコマンドの引数

引数

説明

incident first [n]

最初に発生したnつのインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最初に発生した5つのインシデントが追加されます。nを省略すると、デフォルトの1となり、最初に発生したインシデントが追加されます。

incident inc_id

IDがinc_idのインシデントをパッケージに追加します。

incident last [n]

最後に発生したnつのインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最後に発生した5つのインシデントが追加されます。nを省略すると、デフォルトの1となり、最後に発生したインシデントが追加されます。

problem first [n]

最初に発生したnつの問題のインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最初に発生した5つの問題のインシデントが追加されます。nを省略すると、デフォルトの1となり、最初に発生した問題のインシデントが追加されます。

90日を超えるインシデントを除き、各問題について、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

problem prob_id

問題IDがprob_idのインシデントをすべてパッケージに追加します。90日を超えるインシデントを除き、その問題について、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

problem last [n]

最後に発生したnつの問題のインシデントをパッケージに追加します(nは正の整数)。たとえばnに5を設定すると、最後に発生した5つの問題のインシデントが追加されます。nが省略されると、デフォルトの1となり、最後に発生した問題のインシデントが追加されます。

90日を超えるインシデントを除き、各問題について、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。詳細は、「IPS SET CONFIGURATION」を参照してください。

problemkey pr_key

問題キーがpr_keyのインシデントをパッケージに追加します。90日を超えるインシデントを除き、その問題キーについて、最初に発生した3つの早期インシデントと最後に発生した3つの最新インシデントのみを追加します。(注意: これらの制限はデフォルト値であり、変更可能です。)

seconds secs

現時点で過去secs秒以内に発生したすべてのインシデントを追加します。

time start_time to end_time

start_timeとend_timeの間に発生したすべてのインシデントをパッケージに追加します。時刻の書式はYYYY-MM-YY HH24:MI:SS.FF TZRです。小数部分(FF)はオプションです。

correlate {basic |typical | all}

パッケージに相関インシデントを指定する方法を選択します。この引数には3つのオプションがあります。

- correlate basicを選択すると、インシデント・ダンプおよびインシデント・プロセスのトレース・ファイルが指定されます。

- correlate typicalを選択すると、各インシデントのインシデント・ダンプ、および5分以内に変更されたトレース・ファイルが指定されます。時間間隔を変更するには、INCIDENT_TIME_WINDOW構成パラメータを変更します。

- correlate allを選択すると、インシデント・ダンプ、およびインシデントが最初に選択された時刻と最後に選択された時刻の間に変更されたすべてのトレース・ファイルが指定されます。

デフォルト値はcorrelate typicalです。

in path

物理パッケージをディレクトリpathへ保存します。

例

この例では、空のパッケージを作成します。

ips pack

この例では、インシデント861に関するすべての情報を含む物理パッケージを作成します。

ips pack incident 861

次の例では、過去1分間のすべてのインシデントを完全な相関状態で含む物理パッケージを作成します。

ips pack seconds 60 correlate all

関連項目:

構成パラメータの設定の詳細は、「IPS SET CONFIGURATION」を参照してください。

IPS REMOVE

用途

既存のパッケージからインシデントを削除します。

構文および説明

ips remove {incident inc_id | problem prob_id | problemkey prob_key}
package package_id

パッケージからインシデントを削除した後も、これらのインシデントは引き続きパッケージのメタデータ内で追跡され、(ADD NEW INCIDENTSなどを使用したときに)ADRCIが後から自動的にこれらのインシデントを追加してしまうのを防ぎます。

表17-7では、IPS REMOVEの引数を示します。

表17-7 IPS REMOVEコマンドの引数

引数

説明

incident inc_id

IDがinc_idのインシデントをパッケージから削除します。

problem prob_id

問題IDがprob_idのインシデントをすべてパッケージから削除します。

problemkey pr_key

問題キーがpr_keyのインシデントをすべてパッケージから削除します。

package package_id

IDがpackage_idのパッケージからインシデントを削除します。

例

この例では、パッケージ12からインシデント22を削除します。

ips remove incident 22 package 12

関連項目:

パッケージのメタデータの詳細は、「IPS GET MANIFEST」を参照してください

IPS REMOVE FILE

用途

既存のパッケージからファイルを削除します。

構文および説明

ips remove file file_name package package_id

file_nameはパッケージpackage_idから削除するファイルです。ファイルの完全パスを指定する必要があります。(必要に応じて、<ADR_HOME>および<ADR_BASE>変数を使用できます。)

削除後も、このファイルは引き続きパッケージのメタデータ内で追跡され、(ADD NEW INCIDENTSなどを使用したときに)ADRCIが後から自動的にこのファイルを追加してしまうのを防ぎます。したがって、ファイルを削除しても、そのファイルのEXCLUDEフラグがExplicitly excludedに設定されるだけです。

例

この例では、パッケージ12からトレース・ファイルを削除します。

ips remove file <ADR_HOME>/trace/orcl_ora_13579.trc package 12
Removed file <ADR_HOME>/trace/orcl_ora_13579.trc from package 12
ips show files package 12

.
.
.
FILE_ID                4
FILE_LOCATION          <ADR_HOME>/trace
FILE_NAME              orcl_ora_13579.trc
LAST_SEQUENCE          0
EXCLUDE                Explicitly excluded
.
.
.

関連項目:

- パッケージのメタデータの詳細は、「IPS GET MANIFEST」を参照してください

- <ADR_BASE>ディレクトリ構文の詳細は、「IPSコマンドでの<ADR_HOME>および<ADR_BASE>変数の使用」を参照してください

- 「IPS SHOW FILES」

IPS SET CONFIGURATION

用途

IPS構成パラメータの値を変更します。

構文および説明

ips set configuration {parameter_id | parameter_name} value

parameter_idは変更するパラメータのIDでparameter_nameは、変更するパラメータの名前です。valueは新規の値です。構成パラメータおよびそのIDのリストに対しては、「IPS SHOW CONFIGURATION」を使用します。

例

ips set configuration 3 10

IPS SHOW CONFIGURATION

用途

IPS構成パラメータおよびその値のリストを表示します。これらのパラメータは、タイムアウトおよびインシデント追加間隔など、IPSデータの各種しきい値を制御します。

構文および説明

ips show configuration {parameter_id | parameter_name}]

IPS SHOW CONFIGURATIONは、構成パラメータごとに次の情報を表示します。

- パラメータID

- 名前

- 説明

- パラメータを使用する単位(日数や時間数など)

- 値

- デフォルト値

- 最小値

- 最大値

- フラグ

オプションで、parameter_idまたはparameter_nameを指定して特定のパラメータに関する情報を取得できます。

例

次のコマンドは、すべてのIPS構成パラメータを示します。

ips show configuration

出力例:

PARAMETER INFORMATION:
PARAMETER_ID           1
NAME                   CUTOFF_TIME
DESCRIPTION            Maximum age for an incident to be considered for
inclusion
UNIT                   Days
VALUE                  90
DEFAULT_VALUE          90
MINIMUM                1
MAXIMUM                4294967295
FLAGS                  0

PARAMETER INFORMATION:
PARAMETER_ID           2
NAME                   NUM_EARLY_INCIDENTS
DESCRIPTION            How many incidents to get in the early part of the range
UNIT                   Number
VALUE                  3
DEFAULT_VALUE          3
MINIMUM                1
MAXIMUM                4294967295
FLAGS                  0

PARAMETER INFORMATION:
PARAMETER_ID           3
NAME                   NUM_LATE_INCIDENTS
DESCRIPTION            How many incidents to get in the late part of the range
UNIT                   Number
VALUE                  3
DEFAULT_VALUE          3
MINIMUM                1
MAXIMUM                4294967295
FLAGS                  0

PARAMETER INFORMATION:
PARAMETER_ID           4
NAME                   INCIDENT_TIME_WINDOW
DESCRIPTION            Incidents this close to each other are considered
correlated
UNIT                   Minutes
VALUE                  5
DEFAULT_VALUE          5
MINIMUM                1
MAXIMUM                4294967295
FLAGS                  0

PARAMETER INFORMATION:
PARAMETER_ID           5
NAME                   PACKAGE_TIME_WINDOW
DESCRIPTION            Time window for content inclusion is from x hours
before first included incident to x hours after last
incident
UNIT                   Hours
VALUE                  24
DEFAULT_VALUE          24
MINIMUM                1
MAXIMUM                4294967295
FLAGS                  0

PARAMETER INFORMATION:
PARAMETER_ID           6
NAME                   DEFAULT_CORRELATION_LEVEL
DESCRIPTION            Default correlation level for packages
UNIT                   Number
VALUE                  2
DEFAULT_VALUE          2
MINIMUM                1
MAXIMUM                4
FLAGS                  0

例

このコマンドは、構成パラメータNUM_EARLY_INCIDENTSを示します。

ips show configuration num_early_incidents

このコマンドは、構成パラメータ3を示します。

ips show configuration 3

構成パラメータの説明

表17-8に、IPS構成パラメータの詳細を示します。

表17-8 IPS構成パラメータ

パラメータ

ID

説明

CUTOFF_TIME

1

インシデントが追加対象とみなされる最長期間(日単位)。

NUM_EARLY_INCIDENTS

2

問題に基づいてパッケージを作成するときに、前半部分に含めるインシデントの数。デフォルトでは、ADRCIは最初の3つのインシデントと最新の3つのインシデントをパッケージに追加します。

NUM_LATE_INCIDENTS

3

問題に基づいてパッケージを作成するときに、後半部分に含めるインシデントの数。デフォルトでは、ADRCIは最初の3つのインシデントと最新の3つのインシデントをパッケージに追加します。

INCIDENT_TIME_WINDOW

4

2つのインシデントが相関とみなされるためのインシデント発生の間隔(分数)。

PACKAGE_TIME_WINDOW

5

インシデントをパッケージに追加するための時間ウィンドウとして使用時間数。たとえば、値が5の場合、パッケージ内でインシデントが最初に発生した5時間前、およびパッケージ内の最新のインシデントの発生から5時間後のインシデントを含めます。

DEFAULT_CORRELATION_LEVEL

6

パッケージ内のインシデントを相関付けるために使用するデフォルトの相関レベル。相関レベルは次のとおりです。

- 1(basic): インシデント・ダンプおよびインシデント・プロセスのトレース・ファイルが含まれます。

- 2(typical): インシデント・ダンプおよびINCIDENT_TIME_WINDOW(前述の内容を参照)で指定された時間ウィンドウ内で変更されたトレース・ファイルが含まれます。

- 4(all): インシデント・ダンプ、および最初に選択されたインシデントと最後に選択されたインシデント間で変更されたすべてのトレース・ファイルが含まれます。同じ時間範囲内で追加インシデントが発生した場合は、これらのインシデントを自動的に含めることができます。

関連項目:

「IPS SET CONFIGURATION」

IPS SHOW FILES

用途

指定したパッケージ内に含まれているファイルを表示します。

構文および説明

ips show files package package_id

package_idは表示するパッケージのIDです。

例

この例では、パッケージ1に関連付けられているすべてのファイルを示します。

ips show files package 1

出力例:

FILE_ID                1
FILE_LOCATION          <ADR_HOME>/alert
FILE_NAME              log.xml
LAST_SEQUENCE          1
EXCLUDE                Included

FILE_ID                2
FILE_LOCATION          <ADR_HOME>/trace
FILE_NAME              alert_adcdb.log
LAST_SEQUENCE          1
EXCLUDE                Included

FILE_ID                27
FILE_LOCATION          <ADR_HOME>/incident/incdir_4937
FILE_NAME              adcdb_ora_692_i4937.trm
LAST_SEQUENCE          1
EXCLUDE                Included

FILE_ID                28
FILE_LOCATION          <ADR_HOME>/incident/incdir_4937
FILE_NAME              adcdb_ora_692_i4937.trc
LAST_SEQUENCE          1
EXCLUDE                Included

FILE_ID                29
FILE_LOCATION          <ADR_HOME>/trace
FILE_NAME              adcdb_ora_692.trc
LAST_SEQUENCE          1
EXCLUDE                Included

FILE_ID                30
FILE_LOCATION          <ADR_HOME>/trace
FILE_NAME              adcdb_ora_692.trm
LAST_SEQUENCE          1
EXCLUDE                Included
.
.
.

IPS SHOW INCIDENTS

用途

指定したパッケージ内に含まれているインシデントを表示します。

構文および説明

ips show incidents package package_id

package_idは表示するパッケージのIDです。

例

この例では、パッケージ1のインシデントを表示します。

ips show incidents package 1

出力例:

MAIN INCIDENTS FOR PACKAGE 1:
INCIDENT_ID            4985
PROBLEM_ID             1
EXCLUDE                Included

CORRELATED INCIDENTS FOR PACKAGE 1:

IPS SHOW PACKAGE

用途

指定したパッケージに関する情報を表示します。

構文および説明

ips show package package_id {basic | brief | detail}

package_idは表示するパッケージのIDです。

basicオプションを使用して、最小限の情報を表示します。これは、package_idが指定されていない場合のデフォルトです。

briefオプションを使用して、basicオプションよりも詳細なパッケージ情報を表示します。これは、package_idが指定されている場合のデフォルトです。

detailオプションを使用して、briefオプションで表示される情報に加えて、パッケージ履歴および含まれているインシデントやファイルの情報を表示します。

例

ips show package 12

ips show package 12 brief

IPS UNPACK FILE

用途

物理パッケージ・ファイルを指定したパスに解凍します。

構文および説明

ips unpack file file_name [into path]

file_nameは、解凍する物理パッケージ(ZIPファイル)のフルパス名です。オプションで、ファイルをディレクトリpathに解凍することもできます。このディレクトリは、すでに存在していて書込み可能である必要があります。パスを省略すると、現在の作業ディレクトリが使用されます。解凍先のディレクトリはADRベースとして処理され、有効なADRホームが含まれるADRベースのディレクトリ階層が完全に作成されます。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

ips unpack file /tmp/ORA603_20060906165316_COM_1.zip into /tmp/newadr

PURGE

用途

現在の削除ポリシーに従って、カレントADRホーム内の診断データを削除します。削除が予定されているADRの内容のみが削除されます。

ADR内の診断データにはデフォルトのライフサイクルが設定されています。たとえば、インシデントおよび問題に関する情報は1年後に削除されますが、関連するダンプ・ファイル(ダンプ)はわずか30日後に削除されます。

Oracle Databaseなどの一部のオラクル社の製品では、ライフ・サイクルの終了時に診断データが自動的に削除されます。その他の製品やコンポーネントでは、このコマンドを使用して診断データを手動で削除する必要があります。また、このコマンドで、自動削除される予定のデータも削除できます。

SHOW CONTROLコマンドでは、存続期間が短いADRの内容と存続期間が長いADRの内容に対して、デフォルトの削除ポリシーが表示されます。

構文および説明

purge [-i {id | start_id end_id} |
-age mins [-type {ALERT|INCIDENT|TRACE|CDUMP|HM|UTSCDMP}]]

表17-9に、PURGEのフラグを示します。

表17-9 PURGEコマンドのフラグ

フラグ

説明

-i {id1 | start_id end_id}

特定のインシデントID(id)またはインシデントIDの範囲(start_idおよびend_id)を削除します。

-age mins

mins分以上経過したデータのみを削除します。

-type {ALERT|INCIDENT|TRACE|CDUMP|HM|UTSCDMP}

削除する診断データのタイプを指定します。-age句とともに使用します。

次のタイプを指定できます。

- ALERT: アラート・ログ

- INCIDENT: インシデント・データ

- TRACE: トレース・ファイル(ダンプを含む)

- CDUMP: コア・ダンプ・ファイル

- HM: 状態モニターの実行データおよびレポート

- UTSCDMP: 各セッションのインメモリー・トレースのダンプ
UTSCDMPデータは、トレース・ディレクトリの下のディレクトリに格納されます。これらのディレクトリの名前は、cdmp_timestampです。バックグラウンド・プロセスは、クリティカル・エラー(ORA-600またはORA-7445エラーなど)が発生すると、このようなディレクトリを作成し、各セッションのインメモリー・トレース・データをトレース・ファイルに書き込みます。このデータは、エラーが発生する前に実行されていたインスタンスを特定するのに役立ちます。

例

この例では、デフォルトの削除ポリシーに基づいて、カレントADRホーム内のすべての診断データを削除します。

purge

この例では、123から456の間のすべてのインシデントについて、診断データをすべて削除します。

purge -i 123 456

この例では、過去1時間より前のすべてのインシデント・データを削除します。

purge -age 60 -type incident

注意:

PURGEは、複数のADRホームが設定されている場合には機能しません。1つのADRホームの設定については、「ADRCIコマンドを使用する前のADRCIホームパスの設定」を参照してください。

QUIT

「EXIT」を参照してください。

RUN

用途

ADRCIスクリプトを実行します。

構文および説明

run script_name

@ script_name

@@ script_name

script_nameは、実行するADRCIコマンドを含むファイルです。フルパス名が指定されていないかぎり、ADRCIはカレント・ディレクトリでスクリプトを検索します。ファイル拡張子のないファイル名が指定されている場合、ADRCIはデフォルトの拡張子.adiを使用します。

runおよび@コマンドはシノニムです。@@コマンドは、runや@と似ていますが、スクリプト内で使用される場合に、@@はカレント・ディレクトリではなくコール側スクリプトのパスを使用してscript_nameを検索する点が異なります。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

run my_script

@my_script

SELECT

用途

指定されたインシデントまたは問題に関して、修飾されたレコードを取得します。

構文および説明

select {*|[field1, [field2, ...]} FROM {incident|problem}
[WHERE predicate_string]
[ORDER BY field1 [, field2, ...] [ASC|DSC|DESC]]
[GROUP BY field1 [, field2, ...]]
[HAVING having_predicate_string]

表17-10 SELECTコマンドのフラグ

フラグ

説明

field1, field2, ...

取得するフィールドをリストします。*を指定すると、すべてのフィールドが取得されます。

incident|problem

インシデントまたは問題を問い合せるかどうかを示します。

WHERE "predicate_string"

SQLに類似した述語文字列を使用して、述語がtrueであるインシデントまたは問題のみを表示します。述語文字列は、二重引用符で囲む必要があります。

表17-16に、インシデントの述語文字列で使用できるフィールドを表示します。

表17-20に、問題の述語文字列で使用できるフィールドを表示します。

ORDER BY field1, field2, ... [ASC|DSC|DESC]

フィールドを指定順序、昇順(ASC)および降順(DSCまたはDESC)でソートして、結果を表示します。ORDER BY句を指定すると、結果はデフォルトの昇順で表示されます。

GROUP BY field1, field2, ...

指定したフィールドごとにグループ化された結果が表示されます。

GROUP BYフラグは行をグループ化しますが、結果セットの順序は保証しません。グループ化の順序付けを行うには、ORDER BYフラグを使用します。

HAVING "having_predicate_string"

返される行のグループを、HAVINGの述語がtrueであるグループに制限します。HAVINGフラグは、GROUP BYフラグと一緒に使用する必要があります。

注意:

WHERE、ORDER BY、GROUP BYおよびHAVINGフラグは、SELECT SQL文の同名の句に似ています。SELECT SQL文における句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドを使用する際は、次の制限事項があります。

- 結合できる表は、2つまでです。

- 表の別名は使用できません。

- 使用できる関数は、この項に示す一部の関数に限定されます。

- 表を結合するとき、またはGROUP BY句を使用するときに、ワイルドカード(*)は使用できません。

- 文を1つの行に収める必要があります。

- 文に副問合せを含めることはできません。

- 文にWITH句を含めることはできません。

- 一部の疑似列のみ、使用可能です。たとえば、ROWNUMは使用できますが、ROWIDは使用できません。

例

この例では、1を超えるincident_idを持つインシデントの、incident_idおよびcreate_timeを取得します。

select incident_id, create_time from incident where incident_id > 1

この問合せの出力例を次に示します。

INCIDENT_ID          CREATE_TIME
-------------------- ----------------------------------------
4801                 2011-05-27 10:10:26.541656 -07:00
4802                 2011-05-27 10:11:02.456066 -07:00
4803                 2011-05-27 10:11:04.759654 -07:00

この例では、problem_keyに600が含まれる各問題の、problem_idおよびfirst_incidentを取得します。

select problem_id, first_incident from problem where problem_key like '%600%'

この問合せの出力例を次に示します。

PROBLEM_ID           FIRST_INCIDENT
-------------------- --------------------
1                    4801
2                    4802
3                    4803

関数

このセクションでは、SELECTコマンドと一緒に使用できる関数について説明します。

これらの関数の目的および構文は、対応するSQL関数に似ていますが、一部において異なっています。この項では、ADRCIユーティリティで使用される関数とおよびSQL関数の間の相違点について説明します。

すべての関数に次の制限事項が適用されます。

- 式は、単純式である必要があります。単純式については、『Oracle Database SQL言語リファレンス』を参照してください。

- 複数の関数コールを組み合せることはできません。たとえば、次の関数コールの組合せはサポートされません。

sum(length(column_name))

- 関数はオーバーロードされません。

- すべての関数の引数は必須です。

- 関数は、他のADRCIユーティリティ・コマンドと一緒に使用できません。

表17-11 SELECTコマンドのADRCIユーティリティ関数

関数

説明

AVG

式の平均値を返します。

CONCAT

2つの文字列を連結して返します。

COUNT

問合せによって返された行数を返します。

DECODE

1つの式を各検索値と1つずつ比較します。

LENGTH

入力キャラクタ・セットによる定義を使用して、文字列の長さを返します。

MAX

式の最大値を返します。

MIN

式の最小値を返します。

NVL

問合せの結果において、null(空白として返される)を文字データに置換します。

REGEXP_LIKE

指定した正規表現の指定パターンに一致する行を返します。

SUBSTR

文字データの一部を返します。

SUM

式の値の合計を返します。

TIMESTAMP_TO_CHAR

TIMESTAMPデータ型の値を、VARCHAR2データ型の値に、指定した書式で変換します。

TOLOWER

すべての文字を小文字にして、文字データを返します。

TOUPPER

すべての文字を大文字にして、文字データを返します。

AVG

式の平均値を返します。

構文

『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドでAVG関数を使用する場合は、次の制限事項が適用されます。

- 式は、数値型の列または正の数値定数である必要があります。

- この関数は、DISTINCTまたはALLキーワードをサポートしていません。

- この関数は、OVER句をサポートしていません。

CONCAT

2つの文字列を連結して返します。データ型がCHARおよびVARCHAR2の文字データを使用できます。戻り値は、文字データと同じデータ型です。

構文

『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドでCONCAT関数を使用する場合は、次の制限事項が適用されます。

- この関数は、BLOB、CLOB、NCLOB、BFILEデータ型などのLOBデータ型をサポートしていません。

- この関数は、NCHAR、NVARCHAR2、NCLOBデータ型などの各国語キャラクタ・セットのデータ型をサポートしていません。

COUNT

問合せによって返された行数を返します。

構文

『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドでCOUNT関数を使用する場合は、次の制限事項が適用されます。

- この式は、列、数値定数または文字列定数である必要があります。

- この関数は、DISTINCTまたはALLキーワードをサポートしていません。

- この関数は、OVER句をサポートしていません。

- この関数は、通常、重複およびNULLを含めて問合せのすべての行をカウントします。

例

この例では、flood_controlledが0(ゼロ)のインシデントの数を返します。

select count(*) from incident where flood_controlled = 0;

この例では、problem_keyにORA-600が含まれる問題の数を返します。

select count(*) from problem where problem_key like '%ORA-600%';

DECODE

1つの式を各検索値と1つずつ比較します。式が検索値に等しい場合、Oracle Databaseは対応する結果を返します。一致するものがない場合、Oracleは指定されたデフォルト値を返します。

構文

『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドでDECODE関数を使用する場合は、次の制限事項が適用されます。

- 検索引数は、文字データである必要があります。

- デフォルト値を指定する必要があります。

例

次の例では、各incident_idと、インシデントがフラッド制御されているかどうかを示します。この例では、DECODE関数を使用して、flood_controlledフィールドの数値のかわりにテキストを表示します。

select incident_id, decode(flood_controlled, 0, \
"Not flood-controlled", "Flood-controlled") from incident;

LENGTH

入力キャラクタ・セットによる定義を使用して、文字列の長さを返します。

この文字列のデータ型には、CHAR、VARCHAR2、NCHAR、NVARCHAR2、CLOB、NCLOBのいずれかを使用できます。戻り値のデータ型はNUMBERです。文字列のデータ型がCHARの場合、長さにはすべての後続の空白が含まれます。文字列がNULLの場合、この関数は0(ゼロ)を返します。

注意:

文字列がNULLの場合、SQL関数はNULLを戻します。

構文

『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドは、関数LENGTHB、LENGTHC、LENGTH2およびLENGTH4をサポートしていません。

例

この例では、各問題のproblem_idおよびproblem_keyの長さを示します。

select problem_id, length(problem_key) from problem;

MAX

式の最大値を返します。

構文

『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドでMAX関数を使用する場合は、次の制限事項が適用されます。

- この関数は、DISTINCTまたはALLキーワードをサポートしていません。

- この関数は、OVER句をサポートしていません。

例

この例では、すべての記録された問題の最大のlast_incident値を示します。

select max(last_incident) from problem;

MIN

式の最小値を返します。

構文

『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドでMIN関数を使用する場合は、次の制限事項が適用されます。

- この関数は、DISTINCTまたはALLキーワードをサポートしていません。

- この関数は、OVER句をサポートしていません。

例

この例では、すべての記録された問題に関する最小のfirst_incident値を示します。

select min(first_incident) from problem;

NVL

問合せの結果において、null(空白として返される)を文字データに置換します。指定した最初の式がNULLの場合、NVLは指定した2番目の式を返します。指定した最初の式がNULLでない場合、NVLは最初の式の値を返します。

構文

『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドでNVL関数を使用する場合は、次の制限事項が適用されます。

- 置換する値(2番目の式)は、文字データとして指定する必要があります。

- この関数は、データ変換をサポートしません。

例

この例では、singalling_componentの出力のNULLをテキスト"No component"に置換します。

select nvl(signalling_component, 'No component') from incident;

REGEXP_LIKE

指定した正規表現の指定パターンに一致する行を返します。

注意:

SQLでは、REGEXP_LIKEは関数ではなく条件です。

構文

『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドでREGEXP_LIKE関数を使用する場合は、次の制限事項が適用されます。

- パターン一致では、常に大/小文字が区別されます。

- この関数は、match_param引数をサポートしていません。

例

この例では、problem_keyが数値で終了するすべての問題のproblem_idおよびproblem_keyを表示します。

select problem_id, problem_key from problem \
where regexp_like(problem_key, '[0-9]$') = true

SUBSTR

文字データの一部を返します。返されるデータ部分は、指定した部分から始まる、指定した文字長の部分文字列となります。SUBSTRは、入力キャラクタ・セットによって定義された文字を使用して、長さを計算します。

構文

『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドでSUBSTR関数を使用する場合は、次の制限事項が適用されます。

- この関数は、正の整数のみをサポートします。負の値または浮動小数点数については、サポートしていません。

- SELECTコマンドは、SUBSTRB、SUBSTRC、SUBSTR2およびSUBSTR4関数をサポートしていません。

例

この例では、各problem_keyの5文字目以降を表示します。

select substr(problem_key, 5) from problem;

SUM

式の値の合計を返します。

構文

『Oracle Database SQL言語リファレンス』を参照してください。

制限事項

SELECTコマンドでSUM関数を使用する場合は、次の制限事項が適用されます。

- この式は、数値型の列または数値定数である必要があります。

- この関数は、DISTINCTまたはALLキーワードをサポートしていません。

- この関数は、OVER句をサポートしていません。

TIMESTAMP_TO_CHAR

TIMESTAMPデータ型の値を、VARCHAR2データ型の値に、指定した書式で変換します。形式を指定しない場合、値が関数によってデフォルトのタイムスタンプ形式に変換されます。

構文

『Oracle Database SQL言語リファレンス』でTO_CHAR関数の構文を参照してください。

制限事項

SELECTコマンドでTIMESTAMP_TO_CHAR関数を使用する場合は、次の制限事項が適用されます。

- この関数は、TIMESTAMPデータ型のみを変換します。TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONEなどデータ型はサポートされていません。

- この関数は、nlsparm引数をサポートしていません。この関数は、セッションのデフォルト言語を使用します。

例

この例では、各インシデントのcreate_timeを、TIMESTAMPデータ型からVARCHAR2データ型にDD-MON-YYYY形式で変換します。

select timestamp_to_char(create_time, 'DD-MON-YYYY') from incident;

TOLOWER

すべての文字を小文字にして、文字データを返します。データ型がCHARおよびVARCHAR2の文字データを使用できます。戻り値は、文字データと同じデータ型です。データベースは、基礎となるキャラクタ・セットに対して定義されているバイナリ・マッピングに基づいて文字の大/小文字を設定します。

構文

『Oracle Database SQL言語リファレンス』でLOWER関数の構文を参照してください。

制限事項

SELECTコマンドでTOLOWER関数を使用する場合は、次の制限事項が適用されます。

- この関数は、BLOB、CLOB、NCLOB、BFILEデータ型などのLOBデータ型をサポートしていません。

- この関数は、NCHAR、NVARCHAR2、NCLOBデータ型などの各国語キャラクタ・セットのデータ型をサポートしていません。

例

この例では、各problem_keyをすべて小文字で表示します。

select tolower(problem_key) from problem;

TOUPPER

すべての文字を大文字にして、文字データを返します。データ型がCHARおよびVARCHAR2の文字データを使用できます。戻り値は、文字データと同じデータ型です。データベースは、基礎となるキャラクタ・セットに対して定義されているバイナリ・マッピングに基づいて文字の大/小文字を設定します。

構文

『Oracle Database SQL言語リファレンス』でUPPER関数の構文を参照してください。

制限事項

SELECTコマンドでTOUPPER関数を使用する場合は、次の制限事項が適用されます。

- この関数は、BLOB、CLOB、NCLOB、BFILEデータ型などのLOBデータ型をサポートしていません。

- この関数は、NCHAR、NVARCHAR2、NCLOBデータ型などの各国語キャラクタ・セットのデータ型をサポートしていません。

例

この例では、各problem_keyをすべて大文字で表示します。

select toupper(problem_key) from problem;

SET BASE

用途

カレントADRCIセッションで使用するADRベースを設定します。

構文および説明

set base base_str

base_strは、ディレクトリへのフルパスです。base_strの形式は、オペレーティング・システムによって異なります。ベース・ディレクトリ下に有効なADRホームが存在する場合、これらのホームはカレントADRCIセッションのホームパスに追加されます。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

set base /u01/app/oracle

関連項目:

「ADRベース」

SET BROWSER

用途

レポートを表示するデフォルトのブラウザを設定します。

注意:

このコマンドは今後使用する目的で確保されています。現時点では、ADRCIはブラウザでHTML形式のレポートをサポートしていません。

構文および説明

set browser browser_program

browser_programは、ブラウザのプログラム名です(ブラウザはカレントのADR作業ディレクトリから起動可能であると想定されています)。ブラウザが設定されていない場合、ADRCIはレポートを端末またはスプール・ファイルに表示します。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

set browser mozilla

関連項目:

- レポート表示の詳細は、「SHOW REPORT」を参照してください

- スプールの詳細は、「SPOOL」を参照してください

SET CONTROL

用途

ADRの内容の削除ポリシーを設定します。

構文および説明

set control (purge_policy = value, ...)

purge_policyは、SHORTP_POLICYまたはLONGP_POLICYのいずれかです。詳細は、「SHOW CONTROL」を参照してください。

valueは、ADRの内容が削除可能になるまでの時間数です。

SHORTP_POLICYおよびLONGP_POLICYは相互に排他的ではありません。各ポリシーは、異なるタイプの内容を制御します。

このコマンドは、1つのADRホームでのみ機能します。

例

set control (SHORTP_POLICY = 360)

SET ECHO

用途

コマンド出力をオンまたはオフにします。このコマンドは、スクリプトに表示される出力またはスプール・モードを使用する出力のみに影響します。

構文および説明

set echo on|off

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

set echo off

関連項目:

スプールの詳細は、「SPOOL」を参照してください

SET EDITOR

用途

アラート・ログおよびトレース・ファイルの内容を表示するためのエディタを設定します。

構文および説明

set editor editor_program

editor_programは、エディタのプログラム名です。エディタが設定されていない場合、ADRCIはオペレーティング・システムの環境変数EDITORで指定されているエディタを使用します。EDITORが設定されていない場合、ADRCIはデフォルトのエディタとしてviを使用します。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

set editor xemacs

SET HOMEPATH

用途

1つ以上のADRホームをカレントにします。多くのADRコマンドが、カレントADRホームでのみ動作します。

構文および説明

set homepath homepath_str1 homepath_str2 ...

homepath_strn文字列は、カレントADRベースに対して相対的なADRホームのパスです。ディレクトリ名diagはパスから省略可能です。指定したパスに複数のADRホームが含まれている場合は、すべてのホームがホームパスに追加されます。

目的とする新しいADRホームがカレントADRベース内に存在しない場合は、SET BASEを使用して新しいADRベースを設定してから、SET HOMEPATHを使用します。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

set homepath diag/rdbms/orcldw/orcldw1  diag/rdbms/orcldw/orcldw2

次のコマンドにより、前述の例と同一のホームパスを設定できます。

set homepath rdbms/orcldw/orcldw1  rdbms/orcldw/orcldw2

関連項目:

「ホームパス」

SET TERMOUT

用途

端末への出力をオンまたはオフにします。

構文および説明

set termout on|off

この設定はスプールとは関係なく使用できます。つまり、出力は端末とファイル両方に同時に送信できます。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

関連項目:

スプールの詳細は、「SPOOL」を参照してください

例

set termout on

SHOW ALERT

用途

デフォルトのエディタにアラート・ログの内容を表示します。

構文および説明

show alert [-p "predicate_string"] [-tail [num] [-f]] [-term]
[-file alert_file_name]

-termフラグを使用している場合を除き、このコマンドは1つのカレントADRホームでのみ動作します。複数のADRホームが設定されている場合、ADRCIによって、使用するADRホームを選択するように要求されます。

表17-12 SHOW ALERTコマンドのフラグ

フラグ

説明

-p "predicate_string"

SQLに類似した述語文字列を使用して、述語がtrueであるアラート・ログのエントリのみを表示します。述語文字列は、二重引用符で囲む必要があります。

表17-13に、述語文字列で使用できるフィールドを表示します。

-tail [num] [-f]

アラート・ログの最新のエントリを表示します。

numオプションを使用して、アラート・ログで最新のnum個のエントリを表示します。numが省略されている場合は、最新の10個のエントリが表示されます。

-fオプションが指定されている場合は、要求されたメッセージを表示した後に、コマンドが戻りません。かわりに、コマンドがアクティブのまま残り、アラート・ログに新しいエントリが到着すると、引き続きそのエントリを端末に表示します。このコマンドを使用すると、アラート・ログのライブ監視を実行できます。このコマンドを終了するには、[Ctrl]を押しながら[C]を押します。

-term

結果を端末に送信します。すべてのカレントADRホームからアラート・ログ全体を順次出力します。このオプションが指定されていない場合、結果はデフォルトのエディタに表示されます。

-file alert_file_name

ADRの外のアラート・ファイルを指定できます。alert_file_nameは、フルパス名で指定する必要があります。このオプションは、-tailオプションとともに使用できません。

表17-13 SHOW ALERTのアラート・フィールド

フィールド

タイプ

ORIGINATING_TIMESTAMP

timestamp

NORMALIZED_TIMESTAMP

timestamp

ORGANIZATION_ID

text(65)

COMPONENT_ID

text(65)

HOST_ID

text(65)

HOST_ADDRESS

text(17)

MESSAGE_TYPE

number

MESSAGE_LEVEL

number

MESSAGE_ID

text(65)

MESSAGE_GROUP

text(65)

CLIENT_ID

text(65)

MODULE_ID

text(65)

PROCESS_ID

text(33)

THREAD_ID

text(65)

USER_ID

text(65)

INSTANCE_ID

text(65)

DETAILED_LOCATION

text(161)

UPSTREAM_COMP_ID

text(101)

DOWNSTREAM_COMP_ID

text(101)

EXECUTION_CONTEXT_ID

text(101)

EXECUTION_CONTEXT_SEQUENCE

number

ERROR_INSTANCE_ID

number

ERROR_INSTANCE_SEQUENCE

number

MESSAGE_TEXT

text(2049)

MESSAGE_ARGUMENTS

text(129)

SUPPLEMENTAL_ATTRIBUTES

text(129)

SUPPLEMENTAL_DETAILS

text(4000)

PROBLEM_KEY

text(65)

例

この例では、カレントADRホームのすべてのアラート・メッセージをデフォルトのエディタに表示します。

show alert

この例では、カレントADRホームのすべてのアラート・メッセージを表示し、デフォルトのエディタではなく端末に出力を送信します。

show alert -term

この例では、カレントADRホームのすべてのアラート・メッセージを、インシデントを示すメッセージ・テキストとともに表示します。

show alert -p "message_text like '%incident%'"

この例では、最新の20個のアラート・メッセージを表示してから、アラート・ログをオープンしたままにし、新しいアラート・ログのエントリが到着すると、それらのエントリを表示します。

show alert -tail 20 -f

この例では、複数のADRホームが設定されているときに、1つのカレントADRホームのすべてのアラート・メッセージをデフォルトのエディタに表示します。

show alert

Choose the alert log from the following homes to view:

1: diag/tnslsnr/dbhost1/listener
2: diag/asm/+asm/+ASM
3: diag/rdbms/orcl/orcl
4: diag/clients/user_oracle/host_9999999999_11
Q: to quit

Please select option:
3

関連項目:

「SET EDITOR」

SHOW BASE

用途

カレントADRベースを示します。

構文および説明

show base [-product product_name]

特定の製品では、オプションで、製品のADRベースの場所を表示できます。現在サポートされている製品は、CLIENTとADRCIです。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

次の例では、カレントADRベースを示します。

show base

出力例:

ADR base is "/u01/app/oracle"

次の例では、Oracle DatabaseクライアントのカレントADRベースを示します。

show base -product client

SHOW CONTROL

用途

削除ポリシー属性を含む、ADRについての情報を示します。

構文および説明

show control

次の削除ポリシー属性を含む、ADRの各種属性を示します。

属性名

説明

SHORTP_POLICY

存続期間の短いADRの内容が削除可能になるまでの時間数。デフォルト値は720(30日)です。

0(ゼロ)を設定すると、存続期間の短い内容をすべて削除できます。設定の最大値は、35791394です。35791394を超える値を指定すると、この属性は0(ゼロ)に設定されます。

存続期間の短いADRの内容を次に示します。

- cdmp_timestampサブディレクトリに格納済のこれらのファイルを含む、トレース・ファイル

- コア・ダンプ・ファイル

- パッケージ化の情報

LONGP_POLICY

存続期間の長いADRの内容が削除可能になるまでの時間数。デフォルト値は8760(365日)です。

0(ゼロ)を設定すると、存続期間の長い内容をすべて削除できます。設定の最大値は、35791394です。35791394を超える値を指定すると、この属性は0(ゼロ)に設定されます。

存続期間の長いADRの内容を次に示します。

- インシデント情報

- インシデント・ダンプ

- アラート・ログ

注意:

SHORTP_POLICYおよびLONGP_POLICY属性は相互に排他的ではありません。各ポリシーは、異なるタイプの内容を制御します。

SHOW HM_RUN

用途

状態モニターの実行に関するすべての情報を表示します。

構文および説明

show hm_run [-p "predicate_string"]

predicate_stringは、選択するフィールド名を指定するSQLに類似した述語です。表17-14に、使用可能なフィールド名のリストを示します。

表17-14 状態モニターの実行に使用するフィールド

フィールド

タイプ

RUN_ID

number

RUN_NAME

text(31)

CHECK_NAME

text(31)

NAME_ID

number

MODE

number

START_TIME

timestamp

RESUME_TIME

timestamp

END_TIME

timestamp

MODIFIED_TIME

timestamp

TIMEOUT

number

FLAGS

number

STATUS

number

SRC_INCIDENT_ID

number

NUM_INCIDENTS

number

ERR_NUMBER

number

REPORT_FILE

bfile

例

次の例では、すべての状態モニターの実行に関するデータを示します。

show hm_run

次の例では、123のIDを持つ状態モニターの実行に関するデータを示します。

show hm_run -p "run_id=123"

関連項目:

状態モニターの詳細は、『Oracle Database管理者ガイド』を参照してください。

SHOW HOMEPATH

用途

SHOW HOMESコマンドと同じです。

構文および説明

show homepath | show homes | show home

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

show homepath

出力例:

ADR Homes:
diag/tnslsnr/dbhost1/listener
diag/asm/+asm/+ASM
diag/rdbms/orcl/orcl
diag/clients/user_oracle/host_9999999999_11

関連項目:

ホームパスの設定方法の詳細は、「SET HOMEPATH」を参照してください

SHOW HOMES

用途

カレントADRCIセッションのADRホームを表示します。

構文および説明

show homes | show home | show homepath

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

show homes

出力例:

ADR Homes:
diag/tnslsnr/dbhost1/listener
diag/asm/+asm/+ASM
diag/rdbms/orcl/orcl
diag/clients/user_oracle/host_9999999999_11

SHOW INCDIR

用途

指定したインシデントのトレース・ファイルを表示します。

構文および説明

show incdir [id | id_low id_high]

1つのインシデントID(id)またはインシデントの範囲(id_lowからid_high)を指定できます。インシデントIDが指定されていない場合は、すべてのインシデントのトレース・ファイルが表示されます。

例

この例では、すべてのインシデントのすべてのトレース・ファイルを表示します。

show incdir

出力例:

ADR Home = /u01/app/oracle/log/diag/rdbms/emdb/emdb:
*************************************************************************
diag/rdbms/emdb/emdb/incident/incdir_3801/emdb_ora_23604_i3801.trc
diag/rdbms/emdb/emdb/incident/incdir_3801/emdb_m000_23649_i3801_a.trc
diag/rdbms/emdb/emdb/incident/incdir_3802/emdb_ora_23604_i3802.trc
diag/rdbms/emdb/emdb/incident/incdir_3803/emdb_ora_23604_i3803.trc
diag/rdbms/emdb/emdb/incident/incdir_3804/emdb_ora_23604_i3804.trc
diag/rdbms/emdb/emdb/incident/incdir_3805/emdb_ora_23716_i3805.trc
diag/rdbms/emdb/emdb/incident/incdir_3805/emdb_m000_23767_i3805_a.trc
diag/rdbms/emdb/emdb/incident/incdir_3806/emdb_ora_23716_i3806.trc
diag/rdbms/emdb/emdb/incident/incdir_3633/emdb_pmon_28970_i3633.trc
diag/rdbms/emdb/emdb/incident/incdir_3633/emdb_m000_23778_i3633_a.trc
diag/rdbms/emdb/emdb/incident/incdir_3713/emdb_smon_28994_i3713.trc
diag/rdbms/emdb/emdb/incident/incdir_3713/emdb_m000_23797_i3713_a.trc
diag/rdbms/emdb/emdb/incident/incdir_3807/emdb_ora_23783_i3807.trc
diag/rdbms/emdb/emdb/incident/incdir_3807/emdb_m000_23803_i3807_a.trc
diag/rdbms/emdb/emdb/incident/incdir_3808/emdb_ora_23783_i3808.trc

この例では、インシデント3713のすべてのトレース・ファイルを表示します。

show incdir 3713

出力例:

ADR Home = /u01/app/oracle/log/diag/rdbms/emdb/emdb:
*************************************************************************
diag/rdbms/emdb/emdb/incident/incdir_3713/emdb_smon_28994_i3713.trc
diag/rdbms/emdb/emdb/incident/incdir_3713/emdb_m000_23797_i3713_a.trc

次の例では、3801から3804の間のインシデントのすべてのトレース・ファイルを表示します。

show incdir 3801 3804

出力例:

ADR Home = /u01/app/oracle/log/diag/rdbms/emdb/emdb:
*************************************************************************
diag/rdbms/emdb/emdb/incident/incdir_3801/emdb_ora_23604_i3801.trc
diag/rdbms/emdb/emdb/incident/incdir_3801/emdb_m000_23649_i3801_a.trc
diag/rdbms/emdb/emdb/incident/incdir_3802/emdb_ora_23604_i3802.trc
diag/rdbms/emdb/emdb/incident/incdir_3803/emdb_ora_23604_i3803.trc
diag/rdbms/emdb/emdb/incident/incdir_3804/emdb_ora_23604_i3804.trc

SHOW INCIDENT

用途

カレントADRホームに関連付けられているすべてのインシデントを表示します。未解決のインシデントとクローズしたインシデントの両方を含めます。

構文および説明

show incident [-p "predicate_string"] [-mode {BASIC|BRIEF|DETAIL}]          [-orderby field1, field2, ... [ASC|DSC]]

表17-15に、SHOW INCIDENTのフラグを示します。

表17-15 SHOW INCIDENTコマンドのフラグ

フラグ

説明

-p "predicate_string"

述語文字列を使用して、述語がtrueであるインシデントのみを示します。述語文字列は、二重引用符で囲む必要があります。

表17-16に、述語文字列で使用できるフィールドを表示します。

-mode {BASIC|BRIEF|DETAIL}

インシデントの出力モードを選択します。BASICはデフォルトです。

- BASICは、基本的なインシデント情報(INCIDENT_ID、PROBLEM_IDおよびCREATE_TIMEの各フィールド)のみを表示します。フラッド制御されているインシデントは表示されません。

- BRIEFは、表17-16で説明されているフィールドの指定に従って、インシデントに関連するすべての情報を表示します。フラッド制御されているインシデントも含みます。

- DETAILは、(BRIEFモードを使用した場合と同じ)インシデントに関連するすべての情報と、インシデント・ダンプに関する情報を表示します。フラッド制御されているインシデントも含みます。

-orderby field1, field2, ... [ASC|DSC]

結果を指定した順序のフィールドでソートするだけでなく、昇順(ASC)および降順(DSC)でソートして表示します。デフォルトでは、結果は昇順で表示されます。

表17-16 SHOW INCIDENTのインシデント・フィールド

フィールド

タイプ

説明

INCIDENT_ID

number

インシデントのID

PROBLEM_ID

number

インシデントが属する問題のID

CREATE_TIME

timestamp

インシデントが作成された時間

CLOSE_TIME

timestamp

インシデントがクローズされた時間

STATUS

number

このインシデントの状態

FLAGS

number

内部使用のフラグ

FLOOD_CONTROLLED

number(ADRCIによりテキスト・ステータスにデコードされる)

インシデントのフラッド制御の状態をエンコード

ERROR_FACILITY

text(10)

インシデントの原因となったエラーのエラー機能

ERROR_NUMBER

number

インシデントの原因となったエラーのエラー番号

ERROR_ARG1

text(64)

インシデントの原因となったエラーに関する最初の引数

エラーの引数では、エラーを発行したコードの位置など、エラーの追加情報が提供されます。

ERROR_ARG2

text(64)

インシデントの原因となったエラーに関する2番目の引数

ERROR_ARG3

text(64)

インシデントの原因となったエラーに関する3番目の引数

ERROR_ARG4

text(64)

インシデントの原因となったエラーに関する4番目の引数

ERROR_ARG5

text(64)

インシデントの原因となったエラーに関する5番目の引数

ERROR_ARG6

text(64)

インシデントの原因となったエラーに関する6番目の引数

ERROR_ARG7

text(64)

インシデントの原因となったエラーに関する7番目の引数

ERROR_ARG8

text(64)

インシデントの原因となったエラーに関する8番目の引数

SIGNALLING_COMPONENT

text(64)

インシデントの原因となったエラー信号を出したコンポーネント

SIGNALLING_SUBCOMPONENT

text(64)

インシデントの原因となったエラー信号を出したサブコンポーネント

SUSPECT_COMPONENT

text(64)

インシデントの原因の可能性があると自動的に識別されたコンポーネント

SUSPECT_SUBCOMPONENT

text(64)

インシデントの原因の可能性があると自動的に識別されたサブコンポーネント

ECID

text(64)

実行コンテキストID

IMPACT

number

インシデントの影響のエンコード化

ERROR_ARG9

text(64)

インシデントの原因となったエラーに関する9番目の引数

ERROR_ARG10

text(64)

インシデントの原因となったエラーに関する10番目の引数

ERROR_ARG11

text(64)

インシデントの原因となったエラーに関する11番目の引数

ERROR_ARG12

text(64)

インシデントの原因となったエラーに関する12番目の引数

例

次の例では、このADRホームのすべてのインシデントを示します。

show incident

出力例:

ADR Home = /u01/app/oracle/log/diag/rdbms/emdb/emdb:
*************************************************************************
INCIDENT_ID          PROBLEM_KEY                                  CREATE_TIME
-------------------- -------------------------------------------- ----------------------------
3808                 ORA 603                                      2010-06-18 21:35:49.322161 -07:00
3807                 ORA 600 [4137]                               2010-06-18 21:35:47.862114 -07:00
3806                 ORA 603                                      2010-06-18 21:35:26.666485 -07:00
3805                 ORA 600 [4136]                               2010-06-18 21:35:25.012579 -07:00
3804                 ORA 1578                                     2010-06-18 21:35:08.483156 -07:00
3713                 ORA 600 [4136]                               2010-06-18 21:35:44.754442 -07:00
3633                 ORA 600 [4136]                               2010-06-18 21:35:35.776151 -07:00
7 rows fetched

次の例では、インシデント3805の詳細を示します。

adrci> show incident -mode DETAIL -p "incident_id=3805"

出力例:

ADR Home = /u01/app/oracle/log/diag/rdbms/emdb/emdb:
*************************************************************************

**********************************************************
INCIDENT INFO RECORD 1
**********************************************************
INCIDENT_ID                   3805
STATUS                        closed
CREATE_TIME                   2010-06-18 21:35:25.012579 -07:00
PROBLEM_ID                    2
CLOSE_TIME                    2010-06-18 22:26:54.143537 -07:00
FLOOD_CONTROLLED              none
ERROR_FACILITY                ORA
ERROR_NUMBER                  600
ERROR_ARG1                    4136
ERROR_ARG2                    2
ERROR_ARG3                    18.0.628
ERROR_ARG4                    <NULL>
ERROR_ARG5                    <NULL>
ERROR_ARG6                    <NULL>
ERROR_ARG7                    <NULL>
ERROR_ARG8                    <NULL>
SIGNALLING_COMPONENT          <NULL>
SIGNALLING_SUBCOMPONENT       <NULL>
SUSPECT_COMPONENT             <NULL>
SUSPECT_SUBCOMPONENT          <NULL>
ECID                          <NULL>
IMPACTS                       0
PROBLEM_KEY                   ORA 600 [4136]
FIRST_INCIDENT                3805
FIRSTINC_TIME                 2010-06-18 21:35:25.012579 -07:00
LAST_INCIDENT                 3713
LASTINC_TIME                  2010-06-18 21:35:44.754442 -07:00
IMPACT1                       0
IMPACT2                       0
IMPACT3                       0
IMPACT4                       0
KEY_NAME                      Client ProcId
KEY_VALUE                     oracle@dbhost1 (TNS V1-V3).23716_3083142848
KEY_NAME                      SID
KEY_VALUE                     127.52237
KEY_NAME                      ProcId
KEY_VALUE                     23.90
KEY_NAME                      PQ
KEY_VALUE                     (0, 1182227717)
OWNER_ID                      1
INCIDENT_FILE                 /.../emdb/emdb/incident/incdir_3805/emdb_ora_23716_i3805.trc
OWNER_ID                      1
INCIDENT_FILE                 /.../emdb/emdb/trace/emdb_ora_23716.trc
OWNER_ID                      1
INCIDENT_FILE                 /.../emdb/emdb/incident/incdir_3805/emdb_m000_23767_i3805_a.trc
1 rows fetched

SHOW LOG

用途

診断ログ・メッセージを表示します。

構文および説明

show log [-l log_name] [-p "predicate_string"] [-term] [ [-tail [num] [-f]] ]

表17-17に、SHOW LOGのフラグを示します。

表17-17 SHOW LOGコマンドのフラグ

フラグ

説明

-l log_name

表示するログの名前。

ログ名を指定しない場合、このコマンドによって、カレントADRホーム以下のすべての診断ログに含まれるすべてのメッセージが表示されます。

-p "predicate_string"

SQLに類似した述語文字列を使用して、述語がtrueであるログのエントリのみを表示します。述語文字列は、二重引用符で囲む必要があります。

表17-18に、述語文字列で使用できるフィールドを表示します。

-term

結果を端末に送信します。

このオプションを指定しない場合、このコマンドによってエディタに結果が表示されます。デフォルトでは、結果はEmacsに表示されますが、SET EDITORコマンドを使用して別のエディタに結果を表示することもできます。

-tail [num] [-f]

ログの最新のエントリを表示します。

numオプションを使用して、ログで最新のnum個のエントリを表示します。numが省略されている場合は、最新の10個のエントリが表示されます。

-fオプションが指定されている場合は、要求されたメッセージを表示した後に、コマンドが戻りません。かわりに、コマンドがアクティブのまま残り、ログに新しいエントリが到着すると、引き続きそのエントリを端末に表示します。このコマンドを使用すると、ログのライブ監視を実行できます。このコマンドを終了するには、[Ctrl]を押しながら[C]を押します。

表17-18 SHOW LOGのログ・フィールド

フィールド

タイプ

ORIGINATING_TIMESTAMP

timestamp

NORMALIZED_TIMESTAMP

timestamp

ORGANIZATION_ID

text(65)

COMPONENT_ID

text(65)

HOST_ID

text(65)

HOST_ADDRESS

text(17)

MESSAGE_TYPE

number

MESSAGE_LEVEL

number

MESSAGE_ID

text(65)

MESSAGE_GROUP

text(65)

CLIENT_ID

text(65)

MODULE_ID

text(65)

PROCESS_ID

text(33)

THREAD_ID

text(65)

USER_ID

text(65)

INSTANCE_ID

text(65)

DETAILED_LOCATION

text(161)

UPSTREAM_COMP_ID

text(101)

DOWNSTREAM_COMP_ID

text(101)

EXECUTION_CONTEXT_ID

text(101)

EXECUTION_CONTEXT_SEQUENCE

number

ERROR_INSTANCE_ID

number

ERROR_INSTANCE_SEQUENCE

number

MESSAGE_TEXT

text(2049)

MESSAGE_ARGUMENTS

text(129)

SUPPLEMENTAL_ATTRIBUTES

text(129)

SUPPLEMENTAL_DETAILS

text(4000)

PROBLEM_KEY

text(65)

SHOW PROBLEM

用途

カレントADRホームの問題情報を示します。

構文および説明

show problem [-p "predicate_string"] [-last num | -all]
[-orderby field1, field2, ... [ASC|DSC]]

表17-19に、SHOW PROBLEMのフラグを示します。

表17-19 SHOW PROBLEMコマンドのフラグ

フラグ

説明

-p "predicate_string"

SQLに類似した述語文字列を使用して、述語がtrueであるインシデントのみを示します。述語文字列は、二重引用符で囲む必要があります。

表17-20に、述語文字列で使用できるフィールドを表示します。

-last num | -all

最新のnum個の問題を示すか、またはすべての問題を示します。デフォルトでは、SHOW PROBLEMは最新の50個の問題を示します。

-orderby field1, field2, ... [ASC|DSC]

結果を指定した順序のフィールド(field1、field2、...)でソートするだけでなく、昇順(ASC)および降順(DSC)でソートして表示します。デフォルトでは、結果は昇順で表示されます。

表17-20 SHOW PROBLEMの問題フィールド

フィールド

タイプ

説明

PROBLEM_ID

number

問題のID

PROBLEM_KEY

text(550)

問題の問題キー

FIRST_INCIDENT

number

問題の最初のインシデントのインシデントID

FIRSTINC_TIME

timestamp

問題の最初のインシデントの作成時間

LAST_INCIDENT

number

問題の最後のインシデントのインシデントID

LASTINC_TIME

timestamp

問題の最後のインシデントの作成時間

IMPACT1

number

この問題の影響のエンコード化

IMPACT2

number

この問題の影響のエンコード化

IMPACT3

number

この問題の影響のエンコード化

IMPACT4

number

この問題の影響のエンコード化

SERVICE_REQUEST

text(64)

問題のサービス・リクエスト(サポート・ワークベンチで入力)

BUG_NUMBER

text(64)

問題のバグ番号(サポート・ワークベンチで入力)

例

次の例では、カレントADRホームのすべての問題を表示します。

show problem -all

次の例では、IDが4の問題を示します。

show problem -p "problem_id=4"

SHOW REPORT

用途

指定したレポート・タイプおよび実行名のレポートを表示します。現在は、hm_run(状態モニター)レポート・タイプのみが、XML形式のみでサポートされています。HTML形式の状態モニター・レポートを表示するには、Oracle Enterprise ManagerまたはDBMS_HM PL/SQLパッケージを使用します。詳細は、『Oracle Database管理者ガイド』を参照してください。

構文および説明

SHOW REPORT report_type run_name

report_typeはhm_runである必要があります。run_nameは、レポートの作成元となる状態モニターの実行名です。CREATE REPORTコマンドを使用して、最初にレポートを作成する必要があります。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

show report hm_run hm_run_1421

関連項目:

- 「CREATE REPORT」

- 「SHOW HM_RUN」

SHOW TRACEFILE

用途

トレース・ファイルを表示します。

構文および説明

show tracefile [file1 file2 ...] [-rt | -t]
[-i inc1 inc2 ...] [-path path1 path2 ...]

このコマンドは、-iまたは-pathフラグが指定されていないかぎり、カレントADRホームのトレース・ディレクトリおよびすべてのインシデント・ディレクトリ下で1つ以上のファイルを検索します。

このコマンドの使用時に-iオプションを指定しないかぎり、ADRホームを設定しておく必要はありません。

表17-21に、SHOW TRACEFILEの引数を示します。

表17-21 SHOW TRACEFILEコマンドの引数

引数

説明

file1 file2 ...

ファイル名で結果をフィルタ処理します。%記号はワイルドカード文字です。

表17-22 SHOW TRACEFILEコマンドのフラグ

フラグ

説明

-rt | -t

トレース・ファイル名をタイムスタンプに従って並べ替えます。-tを指定すると、ファイル名がタイムスタンプの昇順でソートされ、-rtを指定すると、ファイル名がその逆の順序でソートされます。ファイル名の並べ替えは、ファイルのディレクトリを基準としてのみ行われます。トレース・ファイルの複数のディレクトリを表示すると、各ディレクトリに個別に順序付けが行われます。

このオプションを使用すると、タイムスタンプが各ファイル名の横に表示されます。

-i inc1 inc2 ...

指定したインシデントIDに対して作成されたトレース・ファイルのみを選択します。

-path path1 path2 ...

指定したパス名下のトレース・ファイルのみを問い合せます。

例

次の例では、カレントADRホーム下のすべてのトレース・ファイルを示します。

show tracefile

次の例では、すべてのmmonトレース・ファイルを、タイムスタンプに従って降順で表示します。

show tracefile %mmon% -rt

次の例では、/home/steve/temp下にある、インシデント1および4に対するすべてのトレース・ファイルを示します。

show tracefile -i 1 4 -path /home/steve/temp

SPOOL

用途

ADRCI出力をファイルへ送信します。

構文および説明

SPOOL filename [[APPEND] | [OFF]]

filenameは、出力が送信されるファイル名です。フルパス名が指定されていない場合、ファイルはカレントADRCI作業ディレクトリに作成されます。ファイル拡張子が指定されていない場合、デフォルトの拡張子.adoが使用されます。APPENDを指定すると、出力がファイルの末尾に追加されます。指定されていない場合は、ファイルが上書きされます。スプールをオフにするにはOFFを使用します。

このコマンドを使用する前に、ADRホームを設定しておく必要はありません。

例

spool myfile

spool myfile.ado append

spool off

spool

ADRCIのトラブルシューティング

一般的なADRCIエラー・メッセージの一部と、その考えられる原因および回避策を次に示します。

ADRベースが設定されていません

原因: ORACLE_HOME環境変数にNULLまたは無効な変数を指定してADRCIを起動した可能性があります。

処理: ADRCIを終了し、ORACLE_HOME環境変数を設定してからADRCIを再起動します。詳細は、「ADRベース」を参照してください。

DIA-48323: 指定されたパス名[string]は現行ADRホームの内部に存在する必要があります

原因: ADRホームの外のファイルは、このコマンドではインシデント・ファイルとして使用できません。

処理: ADRホーム内のインシデント・ファイルを使用して再試行します。

DIA-48400: ADRCIの初期化に失敗しました

原因: ADRベース・ディレクトリが存在しません。

処理: DIAGNOSTIC_DEST初期化パラメータの値をチェックし、1つ以上のADRホームを含むADRベース・ディレクトリを示していることを確認します。DIAGNOSTIC_DESTが欠落している場合やNULLである場合は、ORACLE_HOME/logで有効なADRベース・ディレクトリ階層を確認します。

DIA-48431: ADRホーム・パスを1つ以上指定する必要があります

原因: そのコマンドで、1つ以上のADRホームをカレントにする必要があります。

処理: SET HOMEPATHコマンドを使用して、1つ以上のADRホームをカレントにします。

DIA-48432: ADRホーム・パス[string]が無効です

原因: 指定されたADRホームが有効ではありません。パスが存在していない可能性があります。

処理: 指定されたADRホームパスが存在していることを確認します。

DIA-48447: 入力パス[path]にADRホームが含まれていません

原因: SET HOMEPATHを使用してADRホームを設定する場合、カレントADRベースに対して相対的なパスを指定する必要があります。

処理: 目的とする新しいADRホームがカレントADRベースに存在しない場合は、まずSET BASEを使用してADRベースを設定し、その後でSHOW HOMESを使用して新しいADRベースの下でADRホームを確認します。次に、必要に応じて、SET HOMEPATHを使用して新しいADRホームを設定します。

DIA-48448: このコマンドは、複数のADRホームをサポートしていません

原因: カレントADRCIセッションに複数のカレントADRホームが存在します。

処理: SET HOMEPATHコマンドを使用して、1つのADRホームをカレントにします。

18 DBVERIFY: オフライン・データベース検査ユーティリティ

DBVERIFYは外部コマンドライン・ユーティリティで、物理データ構造に対する整合性チェックを実行します。

DBVERIFYは、オフラインまたはオンライン・データベースおよびバックアップ・ファイル上で使用できます。DBVERIFYを使用するのは、バックアップ・データベース(またはデータ・ファイル)をリストアする前にそれが有効であることを確認する場合です。また、データ破損の問題が発生した場合に診断機能としても使用します。DBVERIFYはオフライン・データベースに対して実行できるため、整合性チェックが非常に高速に行えます。

DBVERIFYによるチェックは、キャッシュ管理(データ・ブロック)ブロックのみに制限されています。DBVERIFYは、データ・ファイルでのみ使用します。制御ファイルまたはREDOログに対しては機能しません。

DBVERIFYには、2つのコマンドライン・インタフェースがあります。最初のインタフェースでは、確認の対象として単一データ・ファイルのディスク・ブロックを指定します。次のインタフェースでは、確認の対象としてセグメントを指定します。いずれのインタフェースでも、最初にdbvコマンドを記述します。次の項では、これらのインタフェースの記述について説明します。

- DBVERIFYを使用した単一データ・ファイルのディスク・ブロックの検査

- DBVERIFYを使用したセグメントの検査

DBVERIFYを使用した単一データ・ファイルのディスク・ブロックの検査

このモードでは、DBVERIFYによって、単一データ・ファイルの1つ以上のディスク・ブロックがスキャンされ、ページのチェックが実行されます。

注意:

検査するファイルが、Oracle Automatic Storage Management (Oracle ASM)ファイルである場合、USERIDを指定する必要があります。DBVERIFYでOracle ASMファイルにアクセスするには、Oracleインスタンスに接続する必要があるためです。

単一ファイルのブロックを検査する際のDBVERIFY構文

単一データ・ファイルのディスク・ブロックを検査するときに使用するDBVERIFYの構文は次のとおりです。

単一ファイルのブロックを検査する際のDBVERIFYパラメータ

単一ファイルのブロックを検査するために使用するDBVERIFYパラメータを次に説明します。

パラメータ

説明

USERID

ユーザー名およびパスワードを指定します。このパラメータは、検査するファイルがOracle ASMファイルである場合にのみ必要です。

FILE

検査するデータベース・ファイル名。

START

検査する最初のブロック・アドレス。ブロック・アドレスは、Oracleブロックで指定します(オペレーティング・システム・ブロックではありません)。STARTを指定しないと、ファイル内の最初のブロックがDBVERIFYによってデフォルト設定されます。

END

検査する最後のブロック。ENDを指定しないと、ファイル内の最後のブロックがDBVERIFYによってデフォルト設定されます。

BLOCKSIZE

BLOCKSIZEは、検査するファイルのブロック・サイズが2KBでない場合にのみ指定します。ファイルのブロック・サイズが2KBでない場合、BLOCKSIZEを指定しないとDBV-00103のエラーが発生します。

HIGH_SCN

HIGH_SCNの値が指定されていると、DBVERIFYはそのブロック・レベルのSCNが指定された値を超えているブロックごとに診断メッセージを書き込みます。

このパラメータはオプションです。デフォルトはありません。

LOGFILE

ログ情報を書き込むファイルを指定します。デフォルトでは、端末画面への出力となります。

FEEDBACK

DBVERIFYによって進捗画面が端末に表示され、DBVERIFYの実行中に検証されたページ数nが1つのピリオド(.)で示されます。n = 0と設定すると、進捗画面は表示されません。

HELP

オンライン・ヘルプを表示します。

PARFILE

使用するパラメータ・ファイルの名前を指定します。DBVERIFYパラメータの様々な値をフラット・ファイルに格納できます。これにより、パラメータ・ファイルをカスタマイズして様々なタイプのデータ・ファイルを処理したり、特定のタイプの整合性チェックをデータ・ファイルに対して実行できます。

単一データ・ファイルに対するDBVERIFYの出力例

次に、ファイルt_db1.dbfの検査の例を示します。フィードバック・パラメータに100が指定されているため、100ページの処理が行われるたびにピリオドが1つ表示されます。出力結果の一部も示します。

% dbv FILE=t_db1.dbf FEEDBACK=100
.
.
.
DBVERIFY - Verification starting : FILE = t_db1.dbf

................................................................................

DBVERIFY - Verification complete

Total Pages Examined         : 9216
Total Pages Processed (Data) : 2044
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 733
Total Pages Failing   (Index): 0
Total Pages Empty            : 5686
Total Pages Marked Corrupt   : 0

Total Pages Influx           : 0

注意:

- Pages = ブロック

- Total Pages Examined =ファイルのブロック数。

- Total Pages Processed = 検査されたブロック数(書式化されたブロック)。

- Total Pages Failing (Data) = データ・ブロック・チェック・ルーチンで違反したブロック数。

- Total Pages Failing (Index) = 索引ブロック・チェック・ルーチンで違反したブロック数。

- Total Pages Marked Corrupt = キャッシュ・ヘッダーが無効で、DBVERIFYがブロック型を識別できないブロック数。

- Total Pages Influx = 読取りおよび書込みが同時に行われるブロック数。DBVERIFYの実行時にデータベースがオープンされている場合は、一貫性を維持したイメージの取得のためにDBVERIFYによってブロックが複数回読み込まれます。ただし、データベースがオープンされているため、読取りおよび書込みが同時に行われるブロックがあります(INFLUX)。DBVERIFYでは、絶え間なく変化するページの一貫性のあるイメージは取得できません。

DBVERIFYを使用したセグメントの検査

このモードでは、DBVERIFYを使用して表セグメントまたは索引セグメントの検査を指定できます。確認中のセグメントに行連鎖ポインタがあることを確認します。

このモードでは、検査するセグメント(データ・セグメントまたは索引セグメント)を指定する必要があります。また、セグメントについての情報をデータベースから取得するため、SYSDBA権限でデータベースにログインする必要があります。

このモードでは、セグメントはロックされます。1つの索引セグメントを指定する場合、親表はロックされます。IOTなど、一部の索引には親表はありません。

セグメントを検査する際のDBVERIFY構文

セグメントを検査するときのDBVERIFYの構文は次のとおりです。

単一のセグメントを検査する際のDBVERIFYパラメータ

単一のセグメントを検査するために使用するDBVERIFYパラメータを次に説明します。

パラメータ

説明

USERID

ユーザー名およびパスワードを指定します。

SEGMENT_ID

検査するセグメントを指定します。このパラメータは、表領域ID番号(tsn)、セグメント・ヘッダー・ファイル番号(segfile)およびセグメント・ヘッダー・ブロック番号(segblock)で構成されます。この情報は、SYS_USER_SEGSから得られます。関係がある列は、TABLESPACE_ID、HEADER_FILEおよびHEADER_BLOCKです。SYS_USER_SEGSを問い合せるには、SYSDBA権限が必要です。

HIGH_SCN

HIGH_SCNの値が指定されていると、DBVERIFYはそのブロック・レベルのSCNが指定された値を超えているブロックごとに診断メッセージを書き込みます。

このパラメータはオプションです。デフォルトはありません。

LOGFILE

ログ情報を書き込むファイルを指定します。デフォルトでは、端末画面への出力となります。

FEEDBACK

DBVERIFYによって進捗画面が端末に表示され、DBVERIFYの実行中に検証されたページ数nが1つのピリオド(.)で示されます。n = 0と設定すると、進捗画面は表示されません。

HELP

オンライン・ヘルプを表示します。

PARFILE

使用するパラメータ・ファイルの名前を指定します。DBVERIFYパラメータの様々な値をフラット・ファイルに格納できます。これにより、パラメータ・ファイルをカスタマイズして様々なタイプのデータ・ファイルを処理したり、特定のタイプの整合性チェックをデータ・ファイルに対して実行できます。

検査対象のセグメントに対するDBVERIFYの出力例

次の出力例は、SEGMENT_ID 1.2.67を検査するDBVERIFY操作で表示されるものです。

DBVERIFY - Verification starting : SEGMENT_ID = 1.2.67

DBVERIFY - Verification complete

Total Pages Examined         : 8
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 1
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 2
Total Pages Processed (Seg)  : 1
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 4
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 7358 (0.7358)

19 DBNEWIDユーティリティ

DBNEWIDは、オペレーショナル・データベースのDBIDおよびDBNAMEを変更できるデータベース・ユーティリティです。

次のトピックを参照してください。

- DBNEWIDユーティリティとは

- DBIDおよびDBNAMEの変更による影響

- データベースのDBIDおよびDBNAMEの変更

- DBNEWIDユーティリティの構文

DBNEWIDユーティリティとは

DBNEWIDユーティリティの導入以前は、データベースのコピーを手動で作成し、制御ファイルを再作成してデータベースに新しいデータベース名(DBNAME)を指定することができました。ただし、データベースに新しい識別子(DBID)を指定することはできません。DBIDは、データベース用の内部的な一意の識別子です。Recovery Manager(RMAN)ではDBIDによってデータベースが区別されるため、シード・データベースおよび手動でコピーされたデータベースは、同じRMANリポジトリに登録できません。DBNEWIDユーティリティを使用すると、次のいずれかを変更することによって、この問題を解決できます。

- データベースのDBIDのみ

- データベースのDBNAMEのみ

- データベースのDBNAMEおよびDBIDの両方

DBIDおよびDBNAMEの変更による影響

データベースのDBIDの変更は、重要な処理です。データベースのDBIDを変更すると、そのデータベースのすべての古いバックアップおよびアーカイブ・ログが使用できなくなります。これは、データがすでにデータ・ファイルに存在する以外は、データベースの作成と同様です。DBIDを変更すると、変更前に作成されたバックアップおよびアーカイブ・ログは、現行のDBIDに一致しない元のDBIDを保持しているため、使用できなくなります。オンラインREDOログを再作成してその順序を1にリセットするRESETLOGSオプションを使用してデータベースをオープンする必要があります。このため、DBIDの変更直後に、データベース全体のバックアップを取る必要があります。

DBIDを変更せずにDBNAMEを変更する場合は、RESETLOGSオプションを指定してデータベースをオープンする必要がないため、データベースのバックアップおよびアーカイブ・ログは無効になりません。ただし、DBNAMEを変更すると、これらが無効になります。データベース名の変更後、新しい名前を反映させるにはDB_NAME初期化パラメータを変更する必要があります。また、Oracleパスワード・ファイルの再作成が必要な場合もあります。制御ファイルの古い(データベース名を変更する前の)バックアップをリストアする場合、データベース名を変更する前の初期化パラメータ・ファイルおよびパスワード・ファイルを使用する必要があります。

注意:

取得プロセスを使用してデータベースへの変更を取得する場合は、データベースのDBIDまたはDBNAMEを変更しないでください。取得プロセスの詳細は、『Oracle Streams概要および管理』を参照してください。

グローバル・データベース名に関する考慮点

分散データベース・システム内のデータベースを使用している場合、各データベースには一意のグローバル・データベース名が必要です。DBNEWIDユーティリティは、グローバル・データベース名を変更しません。グローバル・データベース名の変更は、SQLのALTER DATABASE文を使用してのみ行えます。構文は次のとおりです。

ALTER DATABASE RENAME GLOBAL_NAME TO newname.domain;

グローバル・データベース名は、データベース名およびドメインで構成されます。これらはデータベースが最初に作成されたときにDB_NAMEおよびDB_DOMAIN初期化パラメータによって指定されます。

次の例では、ドメインus.example.comのデータベース名をsalesに変更します。

ALTER DATABASE RENAME GLOBAL_NAME TO sales.us.example.com

これは、DBNEWIDを使用してデータベース名の変更を完了した後に行います。

関連項目:

グローバル・データベース名の詳細は、『Oracle Database管理者ガイド』を参照してください

データベースのDBIDおよびDBNAMEの変更

この項の内容は次のとおりです。

- DBIDおよびデータベース名の変更

- データベースIDのみの変更

- データベース名のみの変更

- DBNEWIDのトラブルシューティング

DBIDおよびデータベース名の変更

次の手順では、データベースのDBIDを変更する方法について説明します。オプションで、データベース名も変更できます。

1. データベース全体のリカバリ可能なバックアップがあることを確認します。

2. ターゲット・データベースがマウント状態であること、またそのデータベースがマウント前に一貫性を維持した状態で停止されていることを確認します。次に例を示します。

SHUTDOWN IMMEDIATE
STARTUP MOUNT

3. コマンドラインで、SYSDBA権限を持つ有効なユーザー(TARGET)を指定してDBNEWIDユーティリティを起動します(パスワードの入力を求められます)。

% nid TARGET=SYS

DBIDの他にデータベース名を変更するには、コマンドラインでDBNAMEパラメータも指定します(パスワードの入力を求められます)。次の例は、データベース名をtest_dbに変更します。

% nid TARGET=SYS DBNAME=test_db

DBNEWIDユーティリティは、ファイルへの入出力を試行する前に、データ・ファイルと制御ファイルのヘッダーで妥当性チェックを実行します。妥当性チェックが正常に行われると、DBNEWIDでは、操作の確認を求め(ログ・ファイルを指定した場合は確認が求められません)、オフラインの通常のデータ・ファイルおよび読取り専用データ・ファイルを含む各データ・ファイルのDBIDを変更し(この例で示すように、DBNAMEが指定された場合は、DBNAMEも変更し)、データベースを停止し、その後、終了します。次に、この出力例を示します。

.
.
.
Connected to database PROD (DBID=86997811)
.
.
.
Control Files in database:
/oracle/TEST_DB/data/cf1.dbf
/oracle/TEST_DB/data/cf2.dbf

The following datafiles are offline clean:
/oracle/TEST_DB/data/tbs_61.dbf (23)
/oracle/TEST_DB/data/tbs_62.dbf (24)
/oracle/TEST_DB/data/temp3.dbf (3)
These files must be writable by this utility.

The following datafiles are read-only:
/oracle/TEST_DB/data/tbs_51.dbf (15)
/oracle/TEST_DB/data/tbs_52.dbf (16)
/oracle/TEST_DB/data/tbs_53.dbf (22)
These files must be writable by this utility.

Changing database ID from 86997811 to 1250654267
Changing database name from PROD to TEST_DB
Control File /oracle/TEST_DB/data/cf1.dbf - modified
Control File /oracle/TEST_DB/data/cf2.dbf - modified
Datafile /oracle/TEST_DB/data/tbs_01.dbf - dbid changed, wrote new name
Datafile /oracle/TEST_DB/data/tbs_ax1.dbf - dbid changed, wrote new name
Datafile /oracle/TEST_DB/data/tbs_02.dbf - dbid changed, wrote new name
Datafile /oracle/TEST_DB/data/tbs_11.dbf - dbid changed, wrote new name
Datafile /oracle/TEST_DB/data/tbs_12.dbf - dbid changed, wrote new name
Datafile /oracle/TEST_DB/data/temp1.dbf - dbid changed, wrote new name
Control File /oracle/TEST_DB/data/cf1.dbf - dbid changed, wrote new name
Control File /oracle/TEST_DB/data/cf2.dbf - dbid changed, wrote new name
Instance shut down

Database name changed to TEST_DB.
Modify parameter file and generate a new password file before restarting.
Database ID for database TEST_DB changed to 1250654267.
All previous backups and archived redo logs for this database are unusable.
Database has been shutdown, open database with RESETLOGS option.
Successfully changed database name and ID.
DBNEWID - Completed successfully.

妥当性チェックが正常に行われなかった場合、次に示す出力例のようにDBNEWIDユーティリティが終了し、ターゲット・データベースは変更されません。データベースをオープンし、エラーを修正した後で、DBNEWIDユーティリティの操作を再開するか、またはDBIDを変更せずに継続してデータベースを使用することができます。

.
.
.
Connected to database PROD (DBID=86997811)
.
.
.
Control Files in database:
/oracle/TEST_DB/data/cf1.dbf
/oracle/TEST_DB/data/cf2.dbf

The following datafiles are offline clean:
/oracle/TEST_DB/data/tbs_61.dbf (23)
/oracle/TEST_DB/data/tbs_62.dbf (24)
/oracle/TEST_DB/data/temp3.dbf (3)
These files must be writable by this utility.

The following datafiles are read-only:
/oracle/TEST_DB/data/tbs_51.dbf (15)
/oracle/TEST_DB/data/tbs_52.dbf (16)
/oracle/TEST_DB/data/tbs_53.dbf (22)
These files must be writable by this utility.

The following datafiles are offline immediate:
/oracle/TEST_DB/data/tbs_71.dbf (25)
/oracle/TEST_DB/data/tbs_72.dbf (26)

NID-00122: Database should have no offline immediate datafiles

Change of database name failed during validation - database is intact.
DBNEWID - Completed with validation errors.

4. データベースをマウントします。次に例を示します。

STARTUP MOUNT

5. RESETLOGSモードでデータベースをオープンし、通常の使用を再開します。次に例を示します。

ALTER DATABASE OPEN RESETLOGS;

データベースの新しいバックアップを取ります。オンラインREDOログをリセットしたため、現行のデータベースでは古いバックアップとアーカイブ・ログは使用できません。

データベースIDのみの変更

データベース名を変更せずに、データベースIDを変更するには、「DBIDおよびデータベース名の変更」の手順に従ってください。ただし、手順3では、オプションのデータベース名(DBNAME)を指定しません。次に、データベースIDのみを変更した場合に生成される出力例を示します。

.
.
.
Connected to database PROD (DBID=86997811)
.
.
.
Control Files in database:
/oracle/TEST_DB/data/cf1.dbf
/oracle/TEST_DB/data/cf2.dbf

The following datafiles are offline clean:
/oracle/TEST_DB/data/tbs_61.dbf (23)
/oracle/TEST_DB/data/tbs_62.dbf (24)
/oracle/TEST_DB/data/temp3.dbf (3)
These files must be writable by this utility.

The following datafiles are read-only:
/oracle/TEST_DB/data/tbs_51.dbf (15)
/oracle/TEST_DB/data/tbs_52.dbf (16)
/oracle/TEST_DB/data/tbs_53.dbf (22)
These files must be writable by this utility.

Changing database ID from 86997811 to 4004383693
Control File /oracle/TEST_DB/data/cf1.dbf - modified
Control File /oracle/TEST_DB/data/cf2.dbf - modified
Datafile /oracle/TEST_DB/data/tbs_01.dbf - dbid changed
Datafile /oracle/TEST_DB/data/tbs_ax1.dbf - dbid changed
Datafile /oracle/TEST_DB/data/tbs_02.dbf - dbid changed
Datafile /oracle/TEST_DB/data/tbs_11.dbf - dbid changed
Datafile /oracle/TEST_DB/data/tbs_12.dbf - dbid changed
Datafile /oracle/TEST_DB/data/temp1.dbf - dbid changed
Control File /oracle/TEST_DB/data/cf1.dbf - dbid changed
Control File /oracle/TEST_DB/data/cf2.dbf - dbid changed
Instance shut down

Database ID for database TEST_DB changed to 4004383693.
All previous backups and archived redo logs for this database are unusable.
Database has been shutdown, open database with RESETLOGS option.
Succesfully changed database ID.
DBNEWID - Completed succesfully.

データベース名のみの変更

次の手順では、DBIDを変更せずにデータベース名を変更する方法について説明します。

1. データベース全体のリカバリ可能なバックアップがあることを確認します。

2. ターゲット・データベースがマウント状態であること、またそのデータベースがマウント前に一貫性を維持した状態で停止されていることを確認します。次に例を示します。

SHUTDOWN IMMEDIATE
STARTUP MOUNT

3. コマンドラインでユーティリティを起動し、SYSDBA権限を持つ有効なユーザーを指定します(パスワードを入力するように要求されます)。DBNAMEパラメータとSETNAMEパラメータの両方を指定する必要があります。この例では、データベース名をtest_dbに変更します。

% nid TARGET=SYS DBNAME=test_db SETNAME=YES

DBNEWIDユーティリティを使用して、(データ・ファイルではなく)制御ファイルへの入出力を試行する前に、制御ファイルのヘッダーで妥当性チェックを実行します。妥当性チェックが正常に行われると、操作の確認が求められ、制御ファイル内のデータベース名が変更されます。これらの処理の完了後、データベースが停止され、DBNEWIDユーティリティが終了します。次に、この出力例を示します。

.
.
.
Control Files in database:
/oracle/TEST_DB/data/cf1.dbf
/oracle/TEST_DB/data/cf2.dbf

The following datafiles are offline clean:
/oracle/TEST_DB/data/tbs_61.dbf (23)
/oracle/TEST_DB/data/tbs_62.dbf (24)
/oracle/TEST_DB/data/temp3.dbf (3)
These files must be writable by this utility.

The following datafiles are read-only:
/oracle/TEST_DB/data/tbs_51.dbf (15)
/oracle/TEST_DB/data/tbs_52.dbf (16)
/oracle/TEST_DB/data/tbs_53.dbf (22)
These files must be writable by this utility.

Changing database name from PROD to TEST_DB
Control File /oracle/TEST_DB/data/cf1.dbf - modified
Control File /oracle/TEST_DB/data/cf2.dbf - modified
Datafile /oracle/TEST_DB/data/tbs_01.dbf - wrote new name
Datafile /oracle/TEST_DB/data/tbs_ax1.dbf - wrote new name
Datafile /oracle/TEST_DB/data/tbs_02.dbf - wrote new name
Datafile /oracle/TEST_DB/data/tbs_11.dbf - wrote new name
Datafile /oracle/TEST_DB/data/tbs_12.dbf - wrote new name
Datafile /oracle/TEST_DB/data/temp1.dbf - wrote new name
Control File /oracle/TEST_DB/data/cf1.dbf - wrote new name
Control File /oracle/TEST_DB/data/cf2.dbf - wrote new name
Instance shut down

Database name changed to TEST_DB.
Modify parameter file and generate a new password file before restarting.
Successfully changed database name.
DBNEWID - Completed successfully.

妥当性チェックが正常に行われなかった場合、DBNEWIDユーティリティは終了し、ターゲット・データベースは変更されません。データベースをオープンし、エラーを修正した後で、DBNEWIDユーティリティの操作を再開するか、またはデータベース名を変更せずに継続してデータベースを使用することができます。(妥当性チェックが正常に行われなかった場合の出力例は、「DBIDおよびデータベース名の変更」の手順3を参照してください。)

4. 初期化パラメータ・ファイル(PFILE)のDB_NAME初期化パラメータを新しいデータベース名に設定します。

注意:

DBNEWIDユーティリティは、サーバー・パラメータ・ファイル(SPFILE)を変更しません。したがって、SPFILEを使用して、Oracle Databaseを起動した場合は、サーバー・パラメータ・ファイルから初期化パラメータ・ファイルを再作成し、サーバー・パラメータ・ファイルを削除して、初期化パラメータ・ファイルのDB_NAMEを変更した後で、サーバー・パラメータ・ファイルを再作成する必要があります。

5. 新しいパスワード・ファイルを作成します。

6. データベースを起動し、通常の使用を再開します。次に例を示します。

STARTUP

データベースIDは変更せずに、データベース名のみを変更したため、データベースのオープン時にRESETLOGSオプションを使用する必要はありません。これまでのすべてのバックアップは使用可能です。

DBNEWIDのトラブルシューティング

DBNEWIDユーティリティによって妥当性チェックが正常に行われたが、要求された変更の実行中にエラーが検出された場合、DBNEWIDユーティリティは停止し、データベースは変更中のままになります。この場合、DBNEWIDユーティリティの操作を完了するか、または元に戻さないかぎり、データベースをオープンできません。DBNEWIDユーティリティによって操作の状態を示すメッセージが表示されます。

操作を続行するか元に戻す前に、エラーの原因を解決します。データベース全体を最新のバックアップからリストアして、DBNEWIDユーティリティの起動前の時点までリカバリを実行する以外に解決策がない場合もあります。そのため、DBNEWIDユーティリティの実行前に最新のバックアップを使用可能にしておくことが重要です。

変更を続行する場合は、元のコマンドを再実行します。DBNEWIDユーティリティが再開され、すべてのデータ・ファイルおよび制御ファイルに新しい値が指定されるまで変更操作が続行されます。この時点では、データベースは停止されます。RESETLOGSオプションを使用してデータベースをオープンする前に、マウントする必要があります。

DBNEWIDユーティリティの操作を元に戻した場合、DBNEWIDユーティリティによって実行されたすべての変更が元に戻され、データベースはマウントされた状態のままになります。

DBNEWIDがリリース10.1以上のOracle Databaseに対して実行された場合は、操作の要約がアラート・ファイルに記録されます。たとえば、データベース名およびデータベースIDの変更では、次のような内容が記録されます。

*** DBNEWID utility started ***
DBID will be changed from 86997811 to new DBID of 1250452230 for
database PROD
DBNAME will be changed from PROD to new DBNAME of TEST_DB
Starting datafile conversion
Setting recovery target incarnation to 1
Datafile conversion complete
Database name changed to TEST_DB.
Modify parameter file and generate a new password file before restarting.
Database ID for database TEST_DB changed to 1250452230.
All previous backups and archived redo logs for this database are unusable.
Database has been shutdown, open with RESETLOGS option.
Successfully changed database name and ID.
*** DBNEWID utility finished successfully ***

データベース名だけの変更では、次のような内容がアラート・ファイルに記録されます。

*** DBNEWID utility started ***
DBNAME will be changed from PROD to new DBNAME of TEST_DB
Starting datafile conversion
Datafile conversion complete
Database name changed to TEST_DB.
Modify parameter file and generate a new password file before restarting.
Successfully changed database name.
*** DBNEWID utility finished successfully ***

In case of failure during DBNEWID the alert will also log the failure:
*** DBNEWID utility started ***
DBID will be changed from 86997811 to new DBID of 86966847 for database
AV3
Change of database ID failed.
Must finish change or REVERT changes before attempting any database
operation.
*** DBNEWID utility finished with errors ***

DBNEWIDの構文

次の図に、DBNEWIDユーティリティの構文を示します。

DBNEWIDパラメータ

表19-1に、DBNEWIDユーティリティの構文のパラメータを示します。

表19-1 DBNEWIDユーティリティのパラメータ

パラメータ

説明

TARGET

データベースへの接続に使用するユーザー名およびパスワードを指定します。ユーザーには、SYSDBA権限が必要です。オペレーティング・システム認証を使用している場合、スラッシュ(/)を使用して続けることができます。環境変数$ORACLE_HOMEおよび$ORACLE_SIDが正しく設定されていない場合、ターゲット・データベースへの接続にセキュリティで保護されたサービス(IPCまたはBEQ)を指定できます。DBNEWIDユーティリティを起動する場合は、常にターゲット・データベースを指定する必要があります。

REVERT

YES(デフォルトはNO)を指定すると、失敗したDBIDの変更が元に戻ります。ターゲット・データベース上でDBIDの変更操作が進行していない場合は、ユーティリティによってエラーが出力されます。DBIDの変更が正常に完了した場合は、元に戻せません。REVERT=YESは、DBIDの変更が正常に行われなかった場合にのみ有効です。

DBNAME=new_db_name

データベース名を変更します。データベースのDBIDおよびDBNAMEは同時に変更できます。DBNAMEのみを変更するには、SETNAMEパラメータも指定します。

SETNAME

YES(デフォルトはNO)を指定すると、DBNEWIDユーティリティによってデータベースの名前のみが変更され、DBIDは変更されません。SETNAME=YESを指定すると、ユーティリティによってターゲット・データベースの制御ファイルのみに書き込まれます。

LOGFILE=logfile

DBNEWIDユーティリティによってメッセージが書き込まれるファイルを指定します。デフォルトでは、古いログに上書きされます。ログ・ファイルを指定すると、DBNEWIDユーティリティによって確認が求められません。

APPEND

YES(デフォルトはNO)を指定すると、既存のログ・ファイルにログの出力が追加されます。

HELP

YES(デフォルトはNO)を指定すると、DBNEWIDユーティリティの構文オプションのリストが出力されます。

制限と使用方法

DBNEWIDユーティリティには次の制限事項があります。

- データベースのDBIDを変更するには、データベースがマウントされており、マウント前に一貫性を維持した状態で停止されている必要があります。Oracle Real Application Clustersデータベースの場合は、データベースをNOPARALLELモードでマウントする必要があります。

- DBIDの変更後は、RESETLOGSオプションを使用してデータベースをオープンする必要があります。データベース名のみの変更後は、RESETLOGSオプションを使用してオープンする必要はありません。

- DBNEWIDユーティリティの実行中に、データベースに対して他のプロセスを実行することはできません。他のセッションがデータベースを停止して起動した場合、DBNEWIDユーティリティは異常終了します。

- すべてのオンライン・データ・ファイルは、リカバリが不要な、一貫性を維持した状態である必要があります。

- NORMALモードでオフラインにされたデータ・ファイルは、アクセスおよび書込みが可能である必要があります。そうでない場合は、DBNEWIDユーティリティを起動する前に、これらのファイルを削除する必要があります。

- すべての読取り専用表領域は、DBNEWIDユーティリティを起動する前に、オペレーティング・システム・レベルでアクセスおよび書込みが可能である必要があります。これらの表領域を書込み可能にできない場合(たとえば、表領域がCD-ROMにある場合)は、トランスポータブル表領域機能を使用して、DBNEWIDユーティリティを起動する前に、表領域を書込み可能な領域にトランスポートする必要があります。

- DBNEWIDユーティリティは、グローバル・データベース名を変更しません。詳細は、「グローバル・データベース名に関する考慮点」を参照してください。

Oracle Database 10gより前のリリースに対する制限事項

DBNEWIDユーティリティをリリース10.1より前のOracle Databaseに対し実行する場合は、次の制限事項がさらに適用されます。

- nid実行可能ファイルはデータ・ファイルおよび制御ファイルに直接アクセスする必要があるため、この実行可能ファイルはOracle所有者が所有し、実行する必要があります。他のユーザーがこのユーティリティを実行する場合は、そのユーザーIDをデータ・ファイルおよび制御ファイルの所有者に設定します。

- DBNEWIDユーティリティを使用するには、ローカル接続を介してデータベースのデータ・ファイルに直接アクセスする必要があります。DBNEWIDユーティリティでは、ネット・サービス名は指定できますが、非ローカル・データベースのDBIDは変更できません。

20 REDOログ・ファイル分析のためのLogMinerの使用

Oracle LogMinerは、Oracle Databaseの一部で、SQLインタフェースを介してREDOログ・ファイル(オンラインおよびアーカイブ)を問い合せることができます。REDOログ・ファイルには、データベースでのアクティビティの履歴情報が含まれています。

次のトピックを参照してください。

- LogMinerのメリット

- LogMinerの概要

- CDBのLogMinerの使用

- LogMinerディクショナリ・ファイルとREDOログ・ファイル

- LogMinerの起動

- 分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ

- V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定

- V$LOGMNR_CONTENTSに返されたDDL文の再適用

- DBMS_LOGMNR.START_LOGMNRの複数回のコール

- サプリメンタル・ロギング

- ビューでのLogMiner操作情報へのアクセス

- 一般的なLogMinerセッションの手順

- LogMinerの使用例

- サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン

LogMinerは、コマンドラインから使用するか、またはOracle LogMinerビューアのグラフィカル・ユーザー・インタフェースを介してアクセスできます。Oracle LogMinerビューアは、Oracle Enterprise Managerの一部です。Oracle LogMinerビューアの詳細は、Oracle Enterprise Managerオンライン・ヘルプを参照してください。

LogMinerのメリット

ユーザー・データやデータベース・ディクショナリに対するすべての変更は、Oracle REDOログ・ファイルに記録されます。これによってデータベース・リカバリ操作が実行できます。

LogMinerには、REDOログ・ファイルに対して適切に定義された使いやすい包括的なリレーショナル・インタフェースが用意されているため、強力なデータ監査ツールとしても、高度なデータ分析ツールとしても使用できます。次に、LogMinerの主要機能の一部を示します。

- アプリケーション・レベルで発生したエラーなど、データベースの論理的破損が発生した時期を特定します。WHERE句の値に誤りがあったために不適切な行を削除した、不適切な値で行を更新した、不適切な索引を消去したなどのエラーがこれに含まれます。たとえば、ユーザー・アプリケーションで、すべての社員の給与を10%増額するところを100%増額するように誤ってデータベースを更新してしまったり、データベース管理者(DBA)が誤って重要なシステム表を削除してしまったりすることがあります。エラーが発生した時期を正確に知ることは、時刻ベースまたは変更ベースのリカバリの開始時期の特定に役立ちます。この情報から、破損する直前の状態にデータベースをリストアできます。LogMinerを使用したこのような処理方法の詳細は、「列の値に基づいたV$LOGMNR_CONTENTSの問合せ」を参照してください。

- トランザクション・レベルでファイングレインなリカバリを行うために必要な処置を特定します。既存の依存性についての正しい理解と認識があれば、表固有のundo操作を実行し、表を元の状態に戻すことができます。そのために、LogMinerは、元のSQL文の発行順序を逆にたどる表固有の再構築されたSQL文を適用します。例については、「使用例1: LogMinerを使用した特定のユーザーによる変更の追跡」を参照してください。
通常は、表を以前の状態にリストアしてから、アーカイブされたREDOログ・ファイルを適用して、表をロールフォワードします。

- 傾向分析により、パフォーマンス・チューニングとキャパシティ・プランニングを実行します。どの表で更新や挿入が最も多いかを判断できます。その情報は、ディスク・アクセス統計に関する履歴的観点を提供するため、チューニングに使用できます。例については、「使用例2: LogMinerを使用した表アクセス統計の計算」を参照してください。

- 事後監査を実行します。LogMinerを使用して、データベースで実行されたデータ操作言語(DML)文およびデータ定義言語(DDL)文、これらの文が実行された順序、および文の実行者を追跡できます。(ただし、LogMinerをそのような目的に使用するには、そのイベントが発生した時期を知り、分析に適したログを指定できる必要があります。そうでない場合、多数のREDOログ・ファイルのマイニングが必要となり、時間がかかる場合があります。LogMinerの使用は、データベース使用の監査のための補助と考えてください。データベースの監査の詳細は、『Oracle Database管理者ガイド』を参照してください。

LogMinerの概要

次の各項では、LogMinerの概要を説明します。

- LogMinerの構成

- LogMiner操作の指定および分析するデータの取得

LogMinerの構成

LogMiner構成には、よく理解しておく必要がある次の4つの基本オブジェクトがあります。ソース・データベース、マイニング・データベース、LogMinerディクショナリ、分析対象のデータが含まれるREDOログ・ファイルです。

- ソース・データベースは、LogMinerで分析するすべてのREDOログ・ファイルを生成するデータベースです。

- マイニング・データベースは、分析実行時にLogMinerにより使用されるデータベースです。

- LogMinerディクショナリは、LogMinerがユーザーの要求したREDOログ・データを表すときに、内部オブジェクトIDではなく表名と列名を提供するために使用されます。
LogMinerでディクショナリを使用して、内部オブジェクト識別子およびデータ型を、オブジェクト名および外部データ・フォーマットに変換します。ディクショナリがない場合、LogMinerから内部オブジェクトIDが返され、データはバイナリ・データとして表されます。

たとえば、次のSQL文について検討します。

INSERT INTO HR.JOBS(JOB_ID, JOB_TITLE, MIN_SALARY, MAX_SALARY)  VALUES('IT_WT','Technical Writer', 4000, 11000);

ディクショナリがない場合、LogMinerは次のように表示します。

insert into "UNKNOWN"."OBJ# 45522"("COL 1","COL 2","COL 3","COL 4") values
(HEXTORAW('45465f4748'),HEXTORAW('546563686e6963616c20577269746572'),
HEXTORAW('c229'),HEXTORAW('c3020b'));

- REDOログ・ファイルには、データベースまたはデータベース・ディクショナリに対して行われた変更が含まれます。

LogMiner構成のサンプル

図20-1にサンプルLogMiner構成を示します。この図では、ボストンにあるソース・データベースでREDOログ・ファイルが生成され、アーカイブ後にサンフランシスコにあるデータベースに送られます。LogMinerディクショナリは、これらのREDOログ・ファイルに対して抽出されます。LogMinerが実際にREDOログ・ファイルを分析するマイニング・データベースは、サンフランシスコにあります。ボストンのデータベースでOracle Database 11gが実行され、サンフランシスコのデータベースでOracle Database 12cが実行されています。

図20-1 サンプルLogMinerデータベースの構成

図20-1は、有効なLogMiner構成の一例です。その他に有効な構成としては、ソース・データベースとマイニング・データベースの両方に同じデータベースを使用する構成、データ・ディクショナリを別の方法で提供する構成などがあります。他のデータ・ディクショナリ・オプションの詳細は、「LogMinerディクショナリ・オプション」を参照してください。

要件

次に、ソース・データベース、マイニング・データベース、データ・ディクショナリ、およびLogMinerがマイニングするREDOログ・ファイルの要件を示します。

- ソース・データベースおよびマイニング・データベース

- ソース・データベースおよびマイニング・データベースは、同一のハードウェア・プラットフォームで稼働している必要があります。

- マイニング・データベースは、ソース・データベースと同一でも、まったく別であってもかまいません。

- マイニング・データベースは、ソース・データベースと同じか上位のリリースのOracle Databaseを実行する必要があります。

- マイニング・データベースでは、ソース・データベースで使用するものと同じキャラクタ・セット(またはキャラクタ・セットのスーパーセット)を使用する必要があります。

- LogMinerディクショナリ

- ディクショナリは、LogMinerが分析するREDOログ・ファイルを生成するソース・データベースと同じデータベースにより生成される必要があります。

- すべてのREDOログ・ファイルに対する条件を次に示します。

- 同じソース・データベースで生成される必要があります。

- 同じデータベースRESETLOGS SCNと関連付けられている必要があります。

- リリース8.0以上のOracle Databaseである必要があります。ただし、リリース9.0.1で導入されたLogMiner機能の一部は、Oracle9i以上のデータベースで生成されたREDOログ・ファイルでのみ機能します。詳細は、「サポートされるデータベースとREDOログ・ファイルのバージョン」を参照してください。

LogMinerでは、異なるデータベースからのREDOログ・ファイルを混在させること、また分析対象のREDOログ・ファイルを生成したデータベース以外からのディクショナリを使用することはできません。

注意:

LogMinerで分析するログ・ファイルを生成するには、その前にサプリメンタル・ロギングを有効にする必要があります。

サプリメンタル・ロギングが有効な場合、REDOログ・ファイルの情報を役立てるために必要な補足情報がREDOストリームに記録されます。したがって、次のSQL文で示すように、少なくとも最小サプリメンタル・ロギングは有効にする必要があります。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

サプリメンタル・ロギングが有効であるかどうかを確認するには、次のSQL文で示すように、V$DATABASEビューを問い合せます。

SELECT SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;

問合せからYESまたはIMPLICITの値が返された場合、最小サプリメンタル・ロギングは有効です。サプリメンタル・ロギングの詳細は、「サプリメンタル・ロギング」を参照してください。

LogMiner操作の指定および分析するデータの取得

LogMiner操作の指定には DBMS_LOGMNRおよびDBMS_LOGMNR_DPL/SQLパッケージを、分析するデータの取得にはV$LOGMNR_CONTENTSビューを、それぞれ次のように使用します。

1. LogMinerディクショナリを指定します。

使用するディクショナリのタイプに応じて、DBMS_LOGMNR_D.BUILDプロシージャを使用するか、LogMiner起動時(手順3)にディクショナリを指定するか、その両方を実行します。

2. 分析するREDOログ・ファイルのリストを指定します。

DBMS_LOGMNR.ADD_LOGFILEプロシージャを使用するか、LogMiner起動時(手順3)に自動的に分析するログ・ファイルのリストをLogMinerが作成するよう指定します。

3. LogMinerを起動します。

DBMS_LOGMNR.START_LOGMNRプロシージャを使用します。

4. 分析するREDOデータを要求します。

V$LOGMNR_CONTENTSビューを問い合せます。

5. LogMinerセッションを終了します。

DBMS_LOGMNR.END_LOGMNRプロシージャを使用します。

V$LOGMNR_CONTENTSビューを問い合せて、LogMiner PL/SQLパッケージを使用するには、EXECUTE_CATALOG_ROLEロールおよびLOGMINING権限を持っている必要があります。

注意:

Oracle RACデータベースで生成されたアーカイブ・ログ内で、指定された分析する時間範囲またはSCN範囲のマイニングを行う場合、指定の時間範囲またはSCN範囲でアクティブであった、すべてのREDOスレッドのすべてのアーカイブ・ログが指定されていることを確認する必要があります。指定されていない場合、V$LOGMNR_CONTENTSという問合せによって、(DBMS_LOGMNR.ADD_LOGFILEプロシージャを使用してLogMinerに指定されたアーカイブ・ログに基づき)部分的な結果のみが返されます。この制限事項は、CONTINUOUS_MINEオプションを使用して、ソース・データベースでアーカイブ・ログをマイニングする場合にも適用されます。有効または無効なスレッドがない場合にのみ、Oracle RACデータベースでCONTINUOUS_MINEオプションを使用する必要があります。

関連項目:

LogMinerの使用例は、「一般的なLogMinerセッションの手順」を参照してください

CDBのLogMinerの使用

LogMinerはマルチテナント・コンテナ・データベース(CDB)で使用できますが、次の各項では、LogMinerをCDBで使用する場合と非CDBで使用する場合とで注意する必要のある相違点について説明します。

- CDBでのLogMiner V$ビューおよびDBAビュー

- CDBでのV$LOGMNR_CONTENTSビュー

- CDBでのサプリメンタル・ロギングの有効化

マルチテナント環境を管理するには、CDB_DBAロールを持っている必要があります。

関連項目:

- CDBの詳細は、『Oracle Database概要』を参照してください。

- ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- CDBおよびPDBの権限およびロールの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

CDBでのLogMiner V$ビューおよびDBAビュー

CDBでは、システムで実行されているLogMinerセッションの情報を表示するためにLogMinerによって使用されるビューに、CON_IDという追加の列が含まれます。この列によって、情報が表示されるセッションに関連付けられたコンテナIDを識別します。プラガブル・データベース(PDB)のビューを問い合せると、データベースに関連付けられた情報のみが表示されます。この新しい動作の影響を受けるビューは次のとおりです。

- V$LOGMNR_DICTIONARY_LOAD

- V$LOGMNR_LATCH

- V$LOGMNR_PROCESS

- V$LOGMNR_SESSION

- V$LOGMNR_STATS

注意:

CDBをサポートするため、V$LOGMNR_CONTENTSビューには、CON_ID以外にもいくつかの新しい列が含まれます。詳細は、「CDBでのV$LOGMNR_CONTENTSビュー」を参照してください。

次のDBAビューには、名前がCDBで始まる類似のCDBビューがあります。

DBAビュー

CDBビュー

DBA_LOGMNR_LOG

CDB_LOGMNR_LOG

DBA_LOGMNR_PURGED_LOG

CDB_LOGMNR_PURGED_LOG

DBA_LOGMNR_SESSION

CDB_LOGMNR_SESSION

DBAビューには、問合せが行われたコンテナで定義されているセッションに関連する情報のみが表示されます。

CDBビューには、特定の行が表すデータを含むコンテナを識別する追加のCON_ID列が含まれます。ルートからCDBビューを問い合せると、それらのビューを使用してすべてのコンテナに関する情報を参照できます。

CDBでのV$LOGMNR_CONTENTSビュー

CDBでは、V$LOGMNR_CONTENTSビューとその関連機能はルート・データベースに制限されています。V$LOGMNR_CONTENTSには、CDBを支援するいくつかの新しい列が存在します。

- CON_ID: 問合せの実行元のコンテナに関連付けられたIDが含まれます。V$LOGMNR_CONTENTSはルート・データベースに制限されるため、問合せがCDBで実行されると、この列は値1を返します。

- SRC_CON_NAME: PDBの名前。この情報は、マイニングがLogMinerディクショナリで実行される場合にのみ使用できます。

- SRC_CON_ID: REDOレコードを生成したPDBのコンテナID。この情報は、マイニングがLogMinerディクショナリで実行される場合にのみ使用できます。

- SRC_CON_DBID: PDBの識別子。この情報は、マイニングが現在のLogMinerディクショナリで実行される場合にのみ使用できます。

- SRC_CON_GUID: PDBに関連付けられたGUIDが含まれます。この情報は、マイニングが現在のLogMinerディクショナリで実行される場合にのみ使用できます。

情報が意味を持たない状況では、これらの列は値を返さないこともあります。マイニングが非CDBで実行されると、SRC_CON_xxx列はNULLになります。

CDBでのサプリメンタル・ロギングの有効化

CDBで、データベース全体のサプリメンタル・ロギングを有効化および無効化する構文は、非CDBと同じです。

ALTER DATABASE [ADD|DROP] SUPPLEMENTAL LOG DATA ...

ただし、次のことに注意してください。

- CDBでは、CDB$ROOTから有効化されたサプリメンタル・ロギング・レベルはCDB全体で有効になります。

- CDB$ROOTで最小限のサプリメンタル・ロギングが有効になっていれば、PDBレベルで追加のサプリメンタル・ロギング・レベルを有効にできます。

- CDB$ROOTからCDBレベルで有効化されたサプリメンタル・ロギング・レベルをPDBレベルで無効化することはできません。

- CDB$ROOTからすべてのサプリメンタル・ロギングを削除すると、以前のPDBレベル設定にかかわらず、CDBのすべてのサプリメンタル・ロギングが無効になります。

CREATE TABLEおよびALTER TABLE文で開始するサプリメンタル・ロギング操作は、ルート・データベースまたはPDBから実行可能で、適用先の表のみが影響を受けます。

CDBでのフラット・ファイル・ディクショナリの使用

単一のフラット・ファイルにCDB全体のディクショナリ・スナップショットを取得することはできません。個々のPDBに接続する必要があり、そのPDB専用のスナップショットをフラット・ファイルに取得できます。したがって、フラット・ファイル・ディクショナリを使用する場合、データ・ディクショナリがフラット・ファイル内に含まれるPDBに関連付けられた変更を対象とするREDOログのみをマイニングできます。

LogMinerディクショナリ・ファイルとREDOログ・ファイル

LogMinerを使用する前に、LogMinerがLogMinerディクショナリ・ファイルおよびREDOログ・ファイルとともにどのように動作するかを理解しておくことが重要です。これは、正確な結果の取得と、システム・リソースの使用計画の作成に役立ちます。

この項では、次の概念について説明します。

- LogMinerディクショナリ・オプション

- REDOログ・ファイル・オプション

LogMinerディクショナリ・オプション

LogMinerは、REDOデータをユーザーに返す際に、オブジェクトIDをオブジェクト名に変換するためにディクショナリを必要とします。LogMinerには、ディクショナリ提供方法として次の3つのオプションがあります。

- オンライン・カタログの使用
REDOログ・ファイルが作成されたソース・データベースにアクセスでき、分析する表の列定義に変更がないことが見込まれる場合には、このオプションの使用をお薦めします。このオプションは、最も効率的で簡単に使用できます。

- REDOログ・ファイルへのLogMinerディクショナリの抽出
REDOログ・ファイルが作成されたソース・データベースにアクセスできない場合、または分析する表の列定義が変更される可能性がある場合には、このオプションの使用をお薦めします。

- フラット・ファイルへのLogMinerディクショナリの抽出
このオプションは、以前のリリースとの下位互換性を保つものです。このオプションは、トランザクションの一貫性を保証しません。オンライン・カタログを使用するか、REDOログ・ファイルからディクショナリを抽出することをお薦めします。

図20-2に、状況に合わせたLogMinerディクショナリの選択方法を示します。

図20-2 LogMinerディクショナリの選択方法

次の項では、使用可能な各ディクショナリ・オプションの指定方法を説明します。

オンライン・カタログの使用

データベースで現在使用中のディクショナリを使用することをLogMinerに指定するには、次のように、LogMiner起動時にディクショナリ・ソースとしてオンライン・カタログを指定します。

EXECUTE DBMS_LOGMNR.START_LOGMNR(-
OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);

オンライン・カタログは、オンラインREDOログ・ファイルの分析に使用する他にも、アーカイブREDOログ・ファイルが同じシステム上で生成されている場合には、アーカイブREDOログ・ファイルの分析に使用できます。

オンライン・カタログにはデータベースに関する最新情報が含まれており、分析を開始するには最も速い方法です。重要な表を変更するDDL操作は頻繁に行われないため、通常、オンライン・カタログには分析に必要な情報が提供されています。

ただし、オンライン・カタログが再構成できるのは、表の最新バージョンに対して実行されるSQL文のみであることに注意してください。表が変更されると、オンライン・カタログは以前の表のバージョンを反映しなくなります。つまり、LogMinerは、以前の表のバージョンに対して実行されたSQL文を再構築することはできません。かわりに、LogMinerは、次に示すV$LOGMNR_CONTENTSビューのSQL_REDO列で実行不可SQL(バイナリ値のhextoraw書式を含む)を生成します。

insert into HR.EMPLOYEES(col#1, col#2) values (hextoraw('4a6f686e20446f65'),
hextoraw('c306'));"

オンライン・カタログ・オプションでは、データベースがオープンしている必要があります。

オンライン・カタログ・オプションは、DBMS_LOGMNR.START_LOGMNRのDDL_DICT_TRACKINGオプションに対し有効ではありません。

REDOログ・ファイルへのLogMinerディクショナリの抽出

REDOログ・ファイルにLogMinerディクショナリを抽出するには、データベースがオープンしていて、ARCHIVELOGモードの状態で、アーカイブが有効になっている必要があります。ディクショナリをREDOログ・ストリームに抽出している間は、DDL文を実行できません。したがって、REDOログ・ファイルに抽出されるディクショナリは、一貫性が保証されます(一方、フラット・ファイルに抽出されたディクショナリは一貫性が保証されません)。

ディクショナリ情報をREDOログ・ファイルに抽出するには、STORE_IN_REDO_LOGSオプションを指定してPL/SQL DBMS_LOGMNR_D.BUILDプロシージャを実行します。ファイル名や位置を指定しないでください。

EXECUTE DBMS_LOGMNR_D.BUILD( -
OPTIONS=> DBMS_LOGMNR_D.STORE_IN_REDO_LOGS);

関連項目:

- ARCHIVELOGモードの詳細は、『Oracle Database管理者ガイド』を参照してください。

- DBMS_LOGMNR_D.BUILDの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ディクショナリをREDOログ・ファイルに抽出するプロセスはデータベース・リソースを消費しますが、ピーク時間帯を外して抽出を実行することで問題を解決できます。また、フラット・ファイルに抽出するより高速になります。ディクショナリのサイズに応じて、複数のREDOログ・ファイルを含めることもできます。関係するREDOログ・ファイルがアーカイブされている場合、抽出されたディクショナリの先頭と終わりがどのREDOログ・ファイルにあるかを特定することができます。これを行うには、次のとおりV$ARCHIVED_LOGビューを問い合せます。

SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN='YES';
SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_END='YES';

LogMinerセッションの起動を準備するときに、ADD_LOGFILEプロシージャで、先頭と終わりのREDOログ・ファイル名を(必要であればその間の他のログも)指定してください。

定期的にREDOログ・ファイルのバックアップを取って情報を保存し、後で利用できるようにしておくことをお薦めします。データベースが適切に管理されている理想的な環境では、アーカイブされたREDOログ・ファイルのバックアップとリストアのためのプロセスがすでに整っているため、そのための特別な手順は必要ありません。バックアップ作業も時間がかかる作業のため、ピークを外した時間帯に実行することをお薦めします。

フラット・ファイルへのLogMinerディクショナリの抽出

LogMinerディクショナリがフラット・ファイルに存在する場合、REDOログ・ファイルに存在する場合よりもシステム・リソースの消費が少なくなります。古いREDOログ・ファイルを正しく分析できるように、定期的にディクショナリ抽出のバックアップを取ることをお薦めします。

データベース・ディクショナリ情報をフラット・ファイルに抽出するには、STORE_IN_FLAT_FILEオプションを指定してDBMS_LOGMNR_D.BUILDプロシージャを実行します。

ディクショナリの作成中にDDL操作が発生しないように注意してください。

ディクショナリをフラット・ファイルに抽出する手順は、次のとおりです。手順1と2は準備のための手順です。これらは、1回のみの実行で、以後は何回でもディクショナリをフラット・ファイルに抽出できます。

1. DBMS_LOGMNR_D.BUILDプロシージャは、ディクショナリ・ファイルが置かれたディレクトリにアクセスする必要があります。通常、PL/SQLプロシージャは、ユーザー・ディレクトリにアクセスしないため、DBMS_LOGMNR_D.BUILDプロシージャが使用するディレクトリを指定する必要があります。ディレクトリを指定しない場合、プロシージャの実行は失敗します。ディレクトリを指定するには、初期化パラメータ・ファイルでUTL_FILE_DIR初期化パラメータを設定します。

たとえば、ディクショナリ・ファイルを置くディレクトリとして/oracle/databaseを使用するようにUTL_FILE_DIRを設定するには、次の内容を初期化パラメータ・ファイルに記述します。

UTL_FILE_DIR = /oracle/database

初期化パラメータ・ファイルに対する変更を有効にするには、データベースの停止と再起動が必要であることに注意してください。

2. データベースがクローズされている場合、SQL*Plusを使用してマウントしてから、分析するREDOログ・ファイルが含まれるデータベースをオープンします。たとえば、SQL STARTUPコマンドを入力すると、データベースがマウントされ、オープンします。

STARTUP

3. DBMS_LOGMNR_D.BUILD PL/SQLプロシージャを実行します。ディクショナリのファイル名およびこのファイルのディレクトリ・パス名を指定します。このプロシージャにより、ディクショナリ・ファイルが作成されます。たとえば、/oracle/databaseでdictionary.oraファイルを作成するには、次のとおり入力します。

EXECUTE DBMS_LOGMNR_D.BUILD('dictionary.ora', -
'/oracle/database/', -
DBMS_LOGMNR_D.STORE_IN_FLAT_FILE);

STORE_IN_FLAT_FILEオプションを指定せずに、ファイル名と位置を指定することもできます。結果は同じになります。

REDOログ・ファイル・オプション

REDOログ・ファイルにあるデータをマイニングするには、LogMinerは、マイニングするREDOログ・ファイルの情報を必要とします。これらのREDOログ・ファイルで検出されたデータベースに対する変更は、V$LOGMNR_CONTENTSビューを介してユーザーに表示されます。

分析するREDOログ・ファイルのリストを自動的かつ動的に作成するようにLogMinerに対して指定したり、LogMinerが分析するREDOログ・ファイルのリストを明示的に指定することができます。その方法は次のとおりです。

- 自動
LogMinerをソース・データベースで使用する場合、LogMinerに対して、分析するREDOログ・ファイルを自動的に検出し、リストを作成するように指定できます。それには、DBMS_LOGMNR.START_LOGMNRプロシージャでLogMinerを起動するときに、CONTINUOUS_MINEオプションを使用し、時間範囲またはSCN範囲を指定します。この例では、オンライン・カタログからのディクショナリを指定していますが、任意のLogMinerディクショナリを使用できます。

注意:

CONTINUOUS_MINEオプションでは、データベースがマウントされ、アーカイブが使用可能である必要があります。

LogMinerは、データベース制御ファイルを使用して、指定された時間範囲またはSCN範囲を満たすREDOログ・ファイルを検出し、LogMiner REDOログ・ファイル・リストに追加します。次に例を示します。

ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';
EXECUTE DBMS_LOGMNR.START_LOGMNR( -
STARTTIME => '01-Jan-2012 08:30:00', -
ENDTIME => '01-Jan-2012 08:45:00', -
OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -
DBMS_LOGMNR.CONTINUOUS_MINE);

(この例では、DBMS_LOGMNR.START_LOGMNRプロシージャに対するPL/SQLコールで日付書式を指定する必要がないように、最初にSQL ALTER SESSION SET NLS_DATE_FORMAT文を使用しています。)

LogMiner起動時に、DBMS_LOGMNR.ADD_LOGFILEを使用して1つのREDOログ・ファイルのみを指定し、CONTINUOUS_MINEオプションを指定しても、分析するREDOログ・ファイルのリストをLogMinerに自動的に作成させることができます。ただし、最初に説明した方法がより一般的です。

- 手動
LogMinerを起動する前に手動でREDOログ・ファイルのリストを作成するには、DBMS_LOGMNR.ADD_LOGFILEプロシージャを使用します。最初のREDOログ・ファイルがこのリストに追加された後、それ以降に追加される各REDOログ・ファイルは、同じデータベースからのもので、同じデータベースのRESETLOGS SCNと関連付けられている必要があります。この方法を使用する場合、LogMinerはソース・データベースに接続されている必要はありません。

たとえば、REDOログ・ファイルの新規リストを開始するには、PL/SQLプロシージャDBMS_LOGMNR.ADD_LOGFILEのNEWオプションを指定し、新規リストの開始であることを指定します。たとえば、/oracle/logs/log1.fを指定するには、次のように入力します。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => '/oracle/logs/log1.f', -
OPTIONS => DBMS_LOGMNR.NEW);

必要に応じて、PL/SQL DBMS_LOGMNR.ADD_LOGFILEプロシージャのADDFILEオプションを指定し、さらにREDOログ・ファイルを追加します。たとえば、/oracle/logs/log2.fを追加するには、次のように入力します。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => '/oracle/logs/log2.f', -
OPTIONS => DBMS_LOGMNR.ADDFILE);

現在のLogMinerセッションでどのREDOログ・ファイルが分析されているかを確認するには、V$LOGMNR_LOGSビューを問い合せます。このビューでは、REDOログ・ファイルごとに1行で構成しています。

LogMinerの起動

LogMinerを起動するには、DBMS_LOGMNR.START_LOGMNRプロシージャをコールします。DBMS_LOGMNR.START_LOGMNRプロシージャで使用できるオプションは、V$LOGMNR_CONTENTSビューに対する出力を制御します。そのためV$LOGMNR_CONTENTSビューを問い合せる前に、DBMS_LOGMNR.START_LOGMNRをコールする必要があります。

LogMiner起動時には、次の項目を指定できます。

- LogMinerが返すデータをフィルタ処理する方法(たとえば、開始時刻と終了時刻、またはSCN値によるフィルタ処理)

- LogMinerにより返されるデータを書式設定するためのオプション

- 使用するLogMinerディクショナリ

次のリストに、DBMS_LOGMNR.START_LOGMNRに対してOPTIONSパラメータで指定できるLogMiner設定の要約と、詳細情報の参照先を示します。

- DICT_FROM_ONLINE_CATALOG - 「オンライン・カタログの使用」を参照してください

- DICT_FROM_REDO_LOGS - 「LogMinerの起動」を参照してください

- CONTINUOUS_MINE - 「REDOログ・ファイル・オプション」を参照してください

- COMMITTED_DATA_ONLY - 「コミット済トランザクションのみの表示」を参照してください

- SKIP_CORRUPTION - 「REDO破損のスキップ」を参照してください

- NO_SQL_DELIMITER - 「再実行のために再構築されたSQL文の書式設定」を参照してください

- PRINT_PRETTY_SQL - 「返されるデータの可読性向上のための表示方法の書式設定」を参照してください

- NO_ROWID_IN_STMT - 「再実行のために再構築されたSQL文の書式設定」を参照してください

- DDL_DICT_TRACKING - 「LogMinerディクショナリでのDDL文の追跡」を参照してください

DBMS_LOGMNR.START_LOGMNRプロシージャの実行時には、指定されたパラメータとオプションの組合せが有効かどうか、指定されたディクショナリとREDOログ・ファイルが使用可能かどうかがLogMinerによりチェックされます。ただし、V$LOGMNR_CONTENTSビューは、「V$LOGMNR_CONTENTSビューへの移入方法」で説明するとおり、このビューを問い合せるまで移入されません。

パラメータおよびオプションは、次回のDBMS_LOGMNR.START_LOGMNRへのコールでは保持されません。DBMS_LOGMNR.START_LOGMNRをコールするたびに、必要なパラメータおよびオプション(SCN範囲や時間範囲を含む)をすべて指定する必要があります。

分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ

分析するREDOデータにアクセスするには、V$LOGMNR_CONTENTSビューを問い合せます。(V$LOGMNR_CONTENTSを問い合せるには、SYSDBAまたはLOGMINING権限が必要なことに注意してください。)このビューは、データベースに対して行われた変更に関する次のような履歴情報を提供します(次に示す以外の情報もあります)。

- データベースに対して行われた変更のタイプ: INSERT、UPDATE、DELETEまたはDDL (OPERATION列)。

- 変更が行われたSCN(SCN列)。

- 変更がコミットされたSCN(COMMIT_SCN列)。

- 変更が属するトランザクション(XIDUSN列、XIDSLT列およびXIDSQN列)。

- 変更されたオブジェクトの表とスキーマの名前(SEG_NAME列およびSEG_OWNER列)。

- 変更を行うDDL文またはDML文を発行したユーザーの名前(USERNAME列)。

- SQL DML文による変更の場合では、REDOレコードを生成するために使用されたSQL DMLと等価のSQL DML(必ずしも同一ではない)を表すように再構築されたSQL文(SQL_REDO列)。

- パスワードがSQL_REDO列にある文に含まれる場合のパスワードの暗号化。DDL文に対応するSQL_REDO列の値は、REDOレコードを生成するために使用されるSQL DDLと常に同一です。

- SQL DML変更による変更の場合では、変更を元に戻すために必要なSQL DML文を示すように再構築されたSQL文(SQL_UNDO列)。
DDL文に対応するSQL_UNDO列は常にNULLです。一部のデータ型とロールバック操作についても、SQL_UNDO列はNULLです。

注意:

LogMinerは透過的データ暗号化(TDE)をサポートしているため、対象オブジェクト用のメタデータがLogMinerデータ・ディクショナリに含まれ、適切なマスター・キーがOracleウォレットにある場合は、暗号化された列(更新中の暗号化された列を含む)が含まれる表で実行されたDML操作がV$LOGMNR_CONTENTSに表示されます。ウォレットはオープンされている必要があります。オープンされていない場合は、V$LOGMNR_CONTENTSでは関連付けられたREDOレコードを解釈することができません。データベースがオープンされていない(読取り専用、または読取り/書込み可能のいずれかの)場合、TDEはサポートされません。TDEの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

V$LOGMNR_CONTENTSの問合せの例

たとえば、Ronという名前のユーザーがoe.orders表で行ったすべての削除操作を調べるとします。次のようなSQL問合せを発行します。

SELECT OPERATION, SQL_REDO, SQL_UNDO
FROM V$LOGMNR_CONTENTS
WHERE SEG_OWNER = 'OE' AND SEG_NAME = 'ORDERS' AND
OPERATION = 'DELETE' AND USERNAME = 'RON';

次の出力が生成されます。画面上での書式設定は、ここに示したものと異なる場合があります。

OPERATION   SQL_REDO                        SQL_UNDO

DELETE      delete from "OE"."ORDERS"       insert into "OE"."ORDERS"
where "ORDER_ID" = '2413'       ("ORDER_ID","ORDER_MODE",
and "ORDER_MODE" = 'direct'      "CUSTOMER_ID","ORDER_STATUS",
and "CUSTOMER_ID" = '101'        "ORDER_TOTAL","SALES_REP_ID",
and "ORDER_STATUS" = '5'         "PROMOTION_ID")
and "ORDER_TOTAL" = '48552'      values ('2413','direct','101',
and "SALES_REP_ID" = '161'       '5','48552','161',NULL);
and "PROMOTION_ID" IS NULL
and ROWID = 'AAAHTCAABAAAZAPAAN';

DELETE      delete from "OE"."ORDERS"        insert into "OE"."ORDERS"
where "ORDER_ID" = '2430'        ("ORDER_ID","ORDER_MODE",
and "ORDER_MODE" = 'direct'       "CUSTOMER_ID","ORDER_STATUS",
and "CUSTOMER_ID" = '101'         "ORDER_TOTAL","SALES_REP_ID",
and "ORDER_STATUS" = '8'          "PROMOTION_ID")
and "ORDER_TOTAL" = '29669.9'     values('2430','direct','101',
and "SALES_REP_ID" = '159'        '8','29669.9','159',NULL);
and "PROMOTION_ID" IS NULL
and ROWID = 'AAAHTCAABAAAZAPAAe';

この出力は、ユーザーRonがoe.orders表から2行を削除したことを示しています。再構築されたSQL文は、Ronが発行した実際の文と等価ですが、必ずしも同一とはかぎりません。その理由は、元のWHERE句の記録がREDOログ・ファイルになく、そのため、LogMinerは、削除(あるいは更新または挿入)された行のみを個別に表示するためです。

したがって、両方の行の削除に1つのDELETE文のみが関係している場合でも、V$LOGMNR_CONTENTSの出力にはそれが反映されません。そのため、実際のDELETE文は、DELETE FROM OE.ORDERS WHERE CUSTOMER_ID ='101'またはDELETE FROM OE.ORDERS WHERE PROMOTION_ID = NULLのいずれかです。

V$LOGMNR_CONTENTSビューへの移入方法

V$LOGMNR_CONTENTS固定ビューは、他のビューと異なり、表に格納されたデータの選択的表示ではありません。ユーザーがREDOログ・ファイルに対して要求したデータのリレーショナルな表示です。LogMinerがこのビューに移入するのは、このビューに対する問合せに応答する場合のみです。V$LOGMNR_CONTENTSを問い合せる前に、LogMinerを正常に起動しておく必要があります。

SQL選択操作がV$LOGMNR_CONTENTSビューに対して実行された場合、REDOログ・ファイルは順番に読み込まれます。REDOログ・ファイルから変換された情報が、V$LOGMNR_CONTENTSビューの行として返されます。これは、起動時に指定されたフィルタ基準を満たすまで、またはREDOログ・ファイルの終わりに達するまで繰り返されます。

V$LOGMNR_CONTENTSの特定の列が移入されない場合があります。次に例を示します。

- TABLE_SPACE列は、OPERATION列の値がDDLの行には移入されません。DDLは、複数の表領域で動作する可能性があるためです。たとえば、表は、複数の表領域にわたる複数のパーティションで作成される可能性があるため、列に正しく移入されません。

- LogMinerでは、一時表に対するSQLのREDOまたはSQLのUNDOは生成されません。SQL_REDO列には「/* No SQL_REDO for temporary tables */」、SQL_UNDO列には「/* No SQL_UNDO for temporary tables */」という文字列が表示されます。

LogMinerでは、COMMITTED_DATA_ONLYオプションを使用して、コミット済トランザクションのみを取得するように指定しないかぎり、すべての行がSCN順に返されます。SCN順は、メディア・リカバリで通常適用される順序です。

関連項目:

DBMS_LOGMNR.START_LOGMNRに対するCOMMITTED_DATA_ONLYオプションの詳細は、「コミット済トランザクションのみの表示」を参照してください

注意:

LogMinerは、問合せに応答する場合にのみV$LOGMNR_CONTENTSビューに移入し、要求したデータをデータベースに格納しないため、次の条件が適用されます。

- V$LOGMNR_CONTENTSを問い合せるたびに、LogMinerは、要求したデータのREDOログ・ファイルを分析します。

- 問合せで消費されるメモリー量は、問合せを満たすために返す必要がある行数によっては異なりません。

- 要求したデータを返すためにかかる時間は、そのデータを検出するためにマイニングする必要があるREDOログ・データの量および型によって異なります。

前述の理由から、さらに分析を行うためにデータを保持する必要がある場合、特に問合せによって返されるデータの量が、そのデータを提供するためにLogMinerによって分析されるREDOデータの量と比較して少ない場合は、V$LOGMNR_CONTENTSという問合せの結果を一時的に格納する表を作成することをお薦めします。

列の値に基づいたV$LOGMNR_CONTENTSの問合せ

LogMinerは、列の値に基づいた問合せを行うことができます。たとえば、hr.employees表に対して行われた、salaryを一定額より多く増額するすべての更新を示す問合せを実行できます。このようなデータは、システム動作の分析や監査タスクの実行に使用できます。

LogMinerによるREDOログ・ファイルからのデータ抽出は、DBMS_LOGMNR.MINE_VALUEおよびDBMS_LOGMNR.COLUMN_PRESENTという2つのマイニング関数を使用して実行されます。これらのマイニング関数に対するサポートは、V$LOGMNR_CONTENTSビューのREDO_VALUE列とUNDO_VALUE列によって提供されます。

次に、MINE_VALUE関数を使用して、hr.employees表に対して行われた、salary列を元の値の2倍より多く増額したすべての更新を選択する例を示します。

SELECT SQL_REDO FROM V$LOGMNR_CONTENTS
WHERE
SEG_NAME = 'EMPLOYEES' AND
SEG_OWNER = 'HR' AND
OPERATION = 'UPDATE' AND
DBMS_LOGMNR.MINE_VALUE(REDO_VALUE, 'HR.EMPLOYEES.SALARY') >
2*DBMS_LOGMNR.MINE_VALUE(UNDO_VALUE, 'HR.EMPLOYEES.SALARY');

この例で示したとおり、MINE_VALUE関数には2つの引数があります。

- 最初の引数は、データのREDO部分(REDO_VALUE)またはUNDO部分(UNDO_VALUE)のいずれをマイニングするかを指定します。データのREDO部分とは、挿入、更新または削除操作後に列に含まれるデータです。データのUNDO部分とは、挿入、更新または削除操作前に列に存在していたデータです。REDO_VALUEは新しい値、UNDO_VALUEは古い値と考えてください。

- 2番目の引数は、マイニングする列の完全修飾名を指定する文字列(この場合は、hr.employees.salary)です。MINE_VALUE関数からは、常に、元のデータ型に戻すことができる文字列が返されます。

MINE_VALUE関数によって返されるNULL値の意味

MINE_VALUE関数がNULL値を返した場合は、次のいずれかを意味します。

- 指定した列がデータのREDO部分またはUNDO部分に存在していない。

- 指定した列は存在するが、その値がNULL。

この2つの場合を区別するには、DBMS_LOGMNR.COLUMN_PRESENT関数を使用します。この関数では、列がデータのREDO部分またはUNDO部分に存在している場合は、1が返されます。存在していない場合には、0が返されます。たとえば、salary列の値の増額および対応するトランザクション識別子を検索するとします。次のSQL問合せを発行します。

SELECT
(XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID,
(DBMS_LOGMNR.MINE_VALUE(REDO_VALUE, 'HR.EMPLOYEES.SALARY') -
DBMS_LOGMNR.MINE_VALUE(UNDO_VALUE, 'HR.EMPLOYEES.SALARY')) AS INCR_SAL
FROM V$LOGMNR_CONTENTS
WHERE
OPERATION = 'UPDATE' AND
DBMS_LOGMNR.COLUMN_PRESENT(REDO_VALUE, 'HR.EMPLOYEES.SALARY') = 1 AND
DBMS_LOGMNR.COLUMN_PRESENT(UNDO_VALUE, 'HR.EMPLOYEES.SALARY') = 1;

MINE_VALUE関数およびCOLUMN_PRESENT関数の使用規則

MINE_VALUE関数およびCOLUMN_PRESENT関数には、次の使用規則が適用されます。

- LogMinerセッション内でのみ使用できます。

- V$LOGMNR_CONTENTSビューからの選択操作中に起動する必要があります。

- LONG、LONG RAW、CLOB、BLOB、NCLOB、ADTまたはCOLLECTIONデータ型はサポートされません。

MINE_VALUEファンクションを使用してNCHAR値を取得する際の制限事項

DBMS_LOGMNR.MINE_VALUEファンクションを使用してデータベース・キャラクタ・セットに存在しない文字を含むNCHAR値を取得する場合、それらの文字は、データベース・キャラクタ・セットの置換文字(逆向きの疑問符など)として返されます。

XMLType列およびXMLType表に基づいたV$LOGMNR_CONTENTSの問合せ

LogMinerでは、XMLType列に対して生成されるREDOがサポートされます。CLOBとして格納されるXMLTypeデータは、11.0.0.0以上の互換性設定で生成されたREDOに対してサポートされます。オブジェクト・リレーショナルおよびバイナリXMLとして格納されるXMLTypeデータは、11.2.0.3以上の互換性設定で生成されたREDOに対してサポートされます。

LogMinerでは、XMLTypeが何で保存されているかに応じて、V$LOGMNR_CONTENTS内のSQL_REDOを別の方法で示します。いずれの場合においても、STATUS列に加えSQL_REDO列の内容は、注意深く確認し、変更をREDOするためにSQLまたはPL/SQL文が生成される前に、通常は再アセンブリする必要があります。このような変更の構築に、SQL_REDOデータを使用できない場合があります。次の項の例では、XMLTypeは行を完全に変更するための再構築で最も単純なCLOBとして格納されています。

注意:

CLOBとして格納されるXMLTypeデータは、Oracle Database 12cリリース1 (12.1)からは非推奨になりました。

XMLType列を使用した表に対して行われた変更についてのV$LOGMNR_CONTENTSの問合せ

この項の例では、次の列を使用したXML_CLOB_COL_TABという表について説明します。

- f1 NUMBER

- f2 VARCHAR2(100)

- f3 XMLTYPE

- f4 XMLTYPE

- f5 VARCHAR2(10)

ログおよびCOMMITTED_DATA_ONLYオプションを使用して、LogMinerセッションを起動したとします。XML_CLOB_COL_TAB表に対して行われた変更について、V$LOGMNR_CONTENTSに対して次の問合せが実行されます。

SELECT OPERATION, STATUS, SQL_REDO FROM V$LOGMNR_CONTENTS
WHERE SEG_OWNER = 'SCOTT' AND TABLE_NAME = 'XML_CLOB_COL_TAB';

問合せの出力は、次のようになります。

OPERATION         STATUS  SQL_REDO

INSERT            0       insert into "SCOTT"."XML_CLOB_COL_TAB"("F1","F2","F5") values
('5010','Aho40431','PETER')

XML DOC BEGIN     5       update "SCOTT"."XML_CLOB_COL_TAB" a set a."F3" = XMLType(:1)
where a."F1" = '5010' and a."F2" = 'Aho40431' and a."F5" = 'PETER'

XML DOC WRITE     5       XML Data

XML DOC WRITE     5       XML Data

XML DOC WRITE     5       XML Data

XML DOC END       5

XML DOC WRITE操作のSQL_REDO列には、XML文書の実際のデータがあります。データは文字列'XML Data'ではありません。

XMLType列を使用した表に挿入するための一般的なモデルを示すこの出力は、次のようになります。

1. すべてのスカラー列を使用した最初の挿入

2. バインド変数を使用して、1つのXMLType列に値を設定する更新文を使用したXML DOC BEGIN操作。

3. XML文書のデータを使用した1回以上のXML DOC WRITE操作

4. XML文書のすべてのデータが送信されたことを示すXML DOC END操作

5. 表に複数のXMLType列がある場合は、元のDMLによって変更されるそれぞれのXMLType列に対して、手順2から4が繰り返されます。

XML文書が表外の列として格納されていない場合、その列に対してXML DOC BEGIN、XML DOC WRITEまたはXML DOC END操作は行われません。文書は、次のような更新文に含まれます。

OPERATION   STATUS         SQL_REDO

UPDATE      0              update "SCOTT"."XML_CLOB_COL_TAB" a
set a."F3" = XMLType('<?xml version="1.0"?>
<PO pono="1">
<PNAME>Po_99</PNAME>
<CUSTNAME>Dave Davids</CUSTNAME>
</PO>')
where a."F1" = '5006' and a."F2" = 'Janosik' and a."F5" = 'MMM'

XMLType表に対して行われた変更についてのV$LOGMNR_CONTENTSの問合せ

XMLType表に対するDMLは、XMLType列に対するDMLとは多少異なります。XML文書では、XMLType表の行に対する値を表します。XMLType列の場合とは異なり、最初の挿入に続いてXML文書を含む更新を行うことはできません。データを表に挿入する前に、文書全体を作成する必要があります。

XMLType表のもう1つの相違点は、OBJECT_ID列の存在です。オブジェクト識別子は、オブジェクト表の各オブジェクトを一意に識別するために使用されます。XMLType表については、表に行が挿入されると、Oracle Databaseによってこの値が生成されます。OBJECT_IDの値は、SQLを使用して表に直接挿入することはできません。したがって、LogMinerでは、この値を含む実行可能なSQL_REDOを生成できません。

V$LOGMNR_CONTENTSビューには、XMLType表に対して行われた変更に対して移入される新しいOBJECT_ID列があります。この値は、元の表のオブジェクト識別子です。ただし、この同じXML文書が同じXMLType表に挿入されても、新しいオブジェクト識別子が生成されます。XMLType表における更新や削除などの次のDMLのSQL_REDOには、WHERE句に元の表の行を一意に識別するためのオブジェクト識別子が含まれます。

XMLTypeデータを使用するLogMinerの使用上の制限

XMLTypeデータのマイニングは、DBMS_LOGMNR.COMMITTED_DATA_ONLYオプションを使用している場合にのみ行う必要があります。そうしないと、一部の行の変更が不足しているために、不完全な変更が表示されたり、XMLとして表示されるはずの変更がCLOBの変更として表示される可能性があります。このために、これらのSQL DML文に対するSQL_REDOが不完全かつ無効になってしまいます。

SQL_UNDO列は、XMLTypeデータへの変更に対して移入されません。

XMLTypeデータを作成するためのPL/SQLプロシージャの例

この項の例では、表外のXMLデータを含む表に対してXML REDOをマイニングおよび作成するのに使用可能なプロシージャについて説明します。この例では、一時LOBを使用してXMLデータを作成する方法を示します。XML文書を一度作成すると、その文書を有効に使用できます。この例では、EmployeeName要素に対して作成された文書を問い合せて、EMPLOYEE_XML_DOCS表の元のDMLに対して返された名前、XML文書およびSQL_REDOを格納します。

注意:

このプロシージャでは、簡単な例のみを示します。この例は、LogMinerを使用して、XMLTypeデータを含む表に対するDMLのマイニングおよび作成が可能であることの説明のみを目的としています。

このプロシージャをコールする前に、関連するすべてのログをLogMinerセッションに追加し、COMMITTED_DATA_ONLYオプションを使用して、DBMS_LOGMNR.START_LOGMNR()をコールする必要があります。その後、マイニング対象のXMLデータを含む表のスキーマ名と表名を使用して、MINE_AND_ASSEMBLE()プロシージャをコールすることができます。

-- table to store assembled XML documents
create table employee_xml_docs  (
employee_name         varchar2(100),
sql_stmt                     varchar2(4000),
xml_doc                     SYS.XMLType);

-- procedure to assemble the XML documents
create or replace procedure mine_and_assemble(
schemaname        in varchar2,
tablename         in varchar2)
AS
loc_c      CLOB;
row_op     VARCHAR2(100);
row_status NUMBER;
stmt       VARCHAR2(4000);
row_redo   VARCHAR2(4000);
xml_data   VARCHAR2(32767 CHAR);
data_len   NUMBER;
xml_lob    clob;
xml_doc    XMLType;
BEGIN

-- Look for the rows in V$LOGMNR_CONTENTS that are for the appropriate schema
-- and table name but limit it to those that are valid sql or that need assembly
-- because they are XML documents.

For item in ( SELECT operation, status, sql_redo  FROM v$logmnr_contents
where seg_owner = schemaname and table_name = tablename
and status IN (DBMS_LOGMNR.VALID_SQL, DBMS_LOGMNR.ASSEMBLY_REQUIRED_SQL))
LOOP
row_op := item.operation;
row_status := item.status;
row_redo := item.sql_redo;

CASE row_op

WHEN 'XML DOC BEGIN' THEN
BEGIN
-- save statement and begin assembling XML data
stmt := row_redo;
xml_data := '';
data_len := 0;
DBMS_LOB.CreateTemporary(xml_lob, TRUE);
END;

WHEN 'XML DOC WRITE' THEN
BEGIN
-- Continue to assemble XML data
xml_data := xml_data || row_redo;
data_len := data_len + length(row_redo);
DBMS_LOB.WriteAppend(xml_lob, length(row_redo), row_redo);
END;

WHEN 'XML DOC END' THEN
BEGIN
-- Now that assembly is complete, we can use the XML document
xml_doc := XMLType.createXML(xml_lob);
insert into employee_xml_docs values
(extractvalue(xml_doc, '/EMPLOYEE/NAME'), stmt, xml_doc);
commit;

-- reset
xml_data := '';
data_len := 0;
xml_lob := NULL;
END;

WHEN 'INSERT' THEN
BEGIN
stmt := row_redo;
END;

WHEN 'UPDATE' THEN
BEGIN
stmt := row_redo;
END;

WHEN 'INTERNAL' THEN
DBMS_OUTPUT.PUT_LINE('Skip rows marked INTERNAL');

ELSE
BEGIN
stmt := row_redo;
DBMS_OUTPUT.PUT_LINE('Other - ' || stmt);
IF row_status != DBMS_LOGMNR.VALID_SQL then
DBMS_OUTPUT.PUT_LINE('Skip rows marked non-executable');
ELSE
dbms_output.put_line('Status : ' || row_status);
END IF;
END;

END CASE;

End LOOP;

End;
/

show errors;

次に、このプロシージャをコールして、SCOTT.XML_DATA_TABへの変更をマイニングし、DMLを適用できます。

EXECUTE MINE_AND_ASSEMBLE ('SCOTT', 'XML_DATA_TAB');

このプロシージャの結果、EMPLOYEE_XML_DOCS表には、変更されたXMLの表外の列それぞれに対する行が含まれます。EMPLOYEE_NAME列には、XML文書から抽出された値が含まれ、SQL_STMT列とXML_DOC列には、元の行の変更が反映されます。

次に、従業員名とSQL文のみが表示される結果表への問合せの例を示します。

SELECT EMPLOYEE_NAME, SQL_STMT FROM EMPLOYEE_XML_DOCS;

EMPLOYEE_NAME          SQL_STMT

Scott Davis          update "SCOTT"."XML_DATA_TAB" a set a."F3" = XMLType(:1)
where a."F1" = '5000' and a."F2" = 'Chen' and a."F5" = 'JJJ'

Richard Harry        update "SCOTT"."XML_DATA_TAB" a set a."F4" = XMLType(:1)
where a."F1" = '5000' and a."F2" = 'Chen' and a."F5" = 'JJJ'

Margaret Sally       update "SCOTT"."XML_DATA_TAB" a set a."F4" = XMLType(:1)
where a."F1" = '5006' and a."F2" = 'Janosik' and a."F5" = 'MMM'

V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定

LogMinerは、大量の情報を処理できます。V$LOGMNR_CONTENTSビューに返される情報、および情報が返される速度を制限できます。次の項では、これらの制限を指定する方法、およびV$LOGMNR_CONTENTSを問い合せた場合に返されるデータへのその制限の影響を示します。

- コミット済トランザクションのみの表示

- REDO破損のスキップ

- 時刻によるデータのフィルタ処理

- SCNによるデータのフィルタ処理

また、LogMinerには、V$LOGMNR_CONTENTSに返されたデータを書式設定するための機能もあります。この機能については、次の項を参照してください。

- 再実行のために再構築されたSQL文の書式設定

- 返されるデータの可読性向上のための表示方法の書式設定

これらのフィルタ処理機能および書式設定機能は、DBMS_LOGMNR.START_LOGMNRプロシージャのパラメータまたはオプションを使用して要求します。

コミット済トランザクションのみの表示

DBMS_LOGMNR.START_LOGMNRに対してCOMMITTED_DATA_ONLYオプションを使用した場合、コミット済トランザクションに属する行のみがV$LOGMNR_CONTENTSビューに表示されます。このオプションを使用すると、ロールバックされたトランザクション、進行中のトランザクションおよび内部操作をフィルタ処理して除外できます。

このオプションを有効にするには、LogMiner起動時に次のように指定します。

EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => -
DBMS_LOGMNR.COMMITTED_DATA_ONLY);

COMMITTED_DATA_ONLYオプションを指定した場合、LogMinerは、同じトランザクションに属するすべてのDML操作をグループ化します。トランザクションはコミットされた順序で返されます。

注意:

COMMITTED_DATA_ONLYオプションを指定して問合せを発行した場合、LogMinerは、1つのトランザクションのコミット・レコードを検出するまで、そのトランザクション内のすべてのREDOレコードをメモリーにステージングします。したがって、メモリーを使い果たして、「メモリー不足」エラーが返される場合があります。このエラーが発生した場合は、COMMITTED_DATA_ONLYオプションを指定せずにLogMinerを再起動し、問合せを再発行する必要があります。

LogMinerのデフォルトでは、すべてのトランザクションに対応する行が表示され、その行がREDOログ・ファイルで検出された順序で返されます。

たとえば、COMMITTED_DATA_ONLYオプションを指定せずにLogMinerを起動し、次の問合せを実行したとします。

SELECT (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID,
USERNAME, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE USERNAME != 'SYS'
AND SEG_OWNER IS NULL OR SEG_OWNER NOT IN ('SYS', 'SYSTEM');

出力は次のようになります。コミット済トランザクションとコミットされていないトランザクションの両方が返され、異なるトランザクションからの行が混在しています。

XID         USERNAME  SQL_REDO

1.15.3045   RON       set transaction read write;
1.15.3045   RON       insert into "HR"."JOBS"("JOB_ID","JOB_TITLE",
"MIN_SALARY","MAX_SALARY") values ('9782',
'HR_ENTRY',NULL,NULL);
1.18.3046   JANE      set transaction read write;
1.18.3046   JANE      insert into "OE"."CUSTOMERS"("CUSTOMER_ID",
"CUST_FIRST_NAME","CUST_LAST_NAME",
"CUST_ADDRESS","PHONE_NUMBERS","NLS_LANGUAGE",
"NLS_TERRITORY","CREDIT_LIMIT","CUST_EMAIL",
"ACCOUNT_MGR_ID") values ('9839','Edgar',
'Cummings',NULL,NULL,NULL,NULL,
NULL,NULL,NULL);
1.9.3041    RAJIV      set transaction read write;
1.9.3041    RAJIV      insert into "OE"."CUSTOMERS"("CUSTOMER_ID",
"CUST_FIRST_NAME","CUST_LAST_NAME","CUST_ADDRESS",
"PHONE_NUMBERS","NLS_LANGUAGE","NLS_TERRITORY",
"CREDIT_LIMIT","CUST_EMAIL","ACCOUNT_MGR_ID")
values ('9499','Rodney','Emerson',NULL,NULL,NULL,NULL,
NULL,NULL,NULL);
1.15.3045    RON       commit;
1.8.3054     RON       set transaction read write;
1.8.3054     RON       insert into "HR"."JOBS"("JOB_ID","JOB_TITLE",
"MIN_SALARY","MAX_SALARY") values ('9566',
'FI_ENTRY',NULL,NULL);
1.18.3046    JANE      commit;
1.11.3047    JANE      set transaction read write;
1.11.3047    JANE      insert into "OE"."CUSTOMERS"("CUSTOMER_ID",
"CUST_FIRST_NAME","CUST_LAST_NAME",
"CUST_ADDRESS","PHONE_NUMBERS","NLS_LANGUAGE",
"NLS_TERRITORY","CREDIT_LIMIT","CUST_EMAIL",
"ACCOUNT_MGR_ID") values ('8933','Ronald',
'Frost',NULL,NULL,NULL,NULL,NULL,NULL,NULL);
1.11.3047    JANE      commit;
1.8.3054     RON       commit;

次に、COMMITTED_DATA_ONLYオプションを指定してLogMinerを起動したとします。前の例の問合せを再度実行すると、出力は次のようになります。

1.15.3045   RON       set transaction read write;
1.15.3045   RON       insert into "HR"."JOBS"("JOB_ID","JOB_TITLE",
"MIN_SALARY","MAX_SALARY") values ('9782',
'HR_ENTRY',NULL,NULL);
1.15.3045    RON       commit;
1.18.3046   JANE      set transaction read write;
1.18.3046   JANE      insert into "OE"."CUSTOMERS"("CUSTOMER_ID",
"CUST_FIRST_NAME","CUST_LAST_NAME",
"CUST_ADDRESS","PHONE_NUMBERS","NLS_LANGUAGE",
"NLS_TERRITORY","CREDIT_LIMIT","CUST_EMAIL",
"ACCOUNT_MGR_ID") values ('9839','Edgar',
'Cummings',NULL,NULL,NULL,NULL,
NULL,NULL,NULL);
1.18.3046    JANE      commit;
1.11.3047    JANE      set transaction read write;
1.11.3047    JANE      insert into "OE"."CUSTOMERS"("CUSTOMER_ID",
"CUST_FIRST_NAME","CUST_LAST_NAME",
"CUST_ADDRESS","PHONE_NUMBERS","NLS_LANGUAGE",
"NLS_TERRITORY","CREDIT_LIMIT","CUST_EMAIL",
"ACCOUNT_MGR_ID") values ('8933','Ronald',
'Frost',NULL,NULL,NULL,NULL,NULL,NULL,NULL);
1.11.3047    JANE      commit;
1.8.3054     RON       set transaction read write;
1.8.3054     RON       insert into "HR"."JOBS"("JOB_ID","JOB_TITLE",
"MIN_SALARY","MAX_SALARY") values ('9566',
'FI_ENTRY',NULL,NULL);
1.8.3054     RON       commit;

1.15.3045トランザクションのCOMMIT文は、1.18.3046トランザクションのCOMMIT文の前に発行されたため、1.15.3045トランザクション全体が先に返されます。これは、1.18.3046トランザクションが1.15.3045トランザクションの前に開始されていた場合でも同様です。1.9.3041トランザクションではCOMMIT文が発行されなかったため、このトランザクションは返されません。

関連項目:

COMMITTED_DATA_ONLYオプションの使用例の詳細は、「LogMinerの使用例」を参照してください

REDO破損のスキップ

DBMS_LOGMNR.START_LOGMNRに対してSKIP_CORRUPTIONオプションを使用した場合、V$LOGMNR_CONTENTSビューからの選択操作中、REDOログ・ファイル内の破損はすべてスキップされます。破損したREDOレコードが検出されるたびに、OPERATION列にCORRUPTED_BLOCKS、STATUS列に1343、INFO列にスキップしたブロック数の入った行が返されます。

スキップされたレコード内には、破損したブロックで進行中のトランザクションに対する変更が含まれる場合がありますが、そのような変更は、V$LOGMNR_CONTENTSビューから返されるデータには反映されません。

デフォルトでは、選択操作は、REDOログ・ファイルで最初に破損が検出された時点で終了します。

次のSQLの例で、このオプションの動作を示します。

-- Add redo log files of interest.
--
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(-
logfilename => '/usr/oracle/data/db1arch_1_16_482701534.log' -
options => DBMS_LOGMNR.NEW);

-- Start LogMiner
--
EXECUTE DBMS_LOGMNR.START_LOGMNR();

-- Select from the V$LOGMNR_CONTENTS view. This example shows corruptions are -- in the redo log files.
--
SELECT rbasqn, rbablk, rbabyte, operation, status, info
FROM V$LOGMNR_CONTENTS;

ERROR at line 3:
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 6 change 73528 time 11/06/2011 11:30:23
ORA-00334: archived log: /usr/oracle/data/dbarch1_16_482701534.log

-- Restart LogMiner. This time, specify the SKIP_CORRUPTION option.
--
EXECUTE DBMS_LOGMNR.START_LOGMNR(-
options => DBMS_LOGMNR.SKIP_CORRUPTION);

-- Select from the V$LOGMNR_CONTENTS view again. The output indicates that
-- corrupted blocks were skipped: CORRUPTED_BLOCKS is in the OPERATION
-- column, 1343 is in the STATUS column, and the number of corrupt blocks
-- skipped is in the INFO column.
--
SELECT rbasqn, rbablk, rbabyte, operation, status, info
FROM V$LOGMNR_CONTENTS;

RBASQN  RBABLK RBABYTE  OPERATION        STATUS  INFO
13      2        76     START              0
13      2        76     DELETE             0
13      3       100     INTERNAL           0
13      3       380     DELETE             0
13      0         0     CORRUPTED_BLOCKS   1343  corrupt blocks 4 to 19 skipped
13      20      116     UPDATE             0

時刻によるデータのフィルタ処理

データを時刻でフィルタ処理するには、DBMS_LOGMNR.START_LOGMNRプロシージャにSTARTTIMEパラメータおよびENDTIMEパラメータを設定します。

PL/SQL DBMS_LOGMNR.START_LOGMNRプロシージャへのコールで日付書式を指定する必要がないように、最初にSQL ALTER SESSION SET NLS_DATE_FORMAT文を使用します。次に例を示します。

ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';
EXECUTE DBMS_LOGMNR.START_LOGMNR( -
DICTFILENAME => '/oracle/database/dictionary.ora', -
STARTTIME => '01-Jan-2012 08:30:00', -
ENDTIME => '01-Jan-2012 08:45:00'-
OPTIONS => DBMS_LOGMNR.CONTINUOUS_MINE);

タイムスタンプは、REDOレコードの順序の推測には使用しないでください。REDOレコードの順序は、SCNを使用して推測できます。

関連項目:

- 時刻によるデータのフィルタ処理の例の詳細は、「LogMinerの使用例」を参照してください

- 開始時刻および終了時刻を指定し、その指定時刻がLogMiner REDOログ・ファイル・リストで検出されなかった場合に発生する状態、およびこれらのパラメータとCONTINUOUS_MINEオプションとの相互作用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

SCNによるデータのフィルタ処理

データをSCN(システム変更番号)でフィルタ処理するには、次の例に示すように、PL/SQL DBMS_LOGMNR.START_LOGMNRプロシージャに対してSTARTSCNパラメータおよびENDSCNパラメータを使用します。

EXECUTE DBMS_LOGMNR.START_LOGMNR(-
STARTSCN => 621047, -
ENDSCN   => 625695, -
OPTIONS  => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -
DBMS_LOGMNR.CONTINUOUS_MINE);

STARTSCNパラメータおよびENDSCNパラメータは、すべてのパラメータを指定した場合、STARTTIMEパラメータおよびENDTIMEパラメータより優先されます。

関連項目:

- SCNによるデータのフィルタ処理の例の詳細は、「LogMinerの使用例」を参照してください

- 開始値およびSCN値を指定し、その値がLogMiner REDOログ・ファイル・リストで検出されなかった場合に発生する状態、およびこれらのパラメータとCONTINUOUS_MINEオプションとの相互作用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

再実行のために再構築されたSQL文の書式設定

デフォルトでは、再構築されるSQL_REDO文およびSQL_UNDO文にはROWID句が含まれ、それらの文はセミコロンで終わります。

ただし、次のようにこのデフォルト設定を上書きできます。

- LogMiner起動時にNO_ROWID_IN_STMTオプションを指定します。
この指定によって、再構築される文からROWID句が除外されます。行IDはデータベース間で一貫性がないため、最初に実行したデータベースと異なるデータベースに対してSQL_REDO文またはSQL_UNDO文を再実行する場合は、LogMiner起動時にNO_ROWID_IN_STMTオプションを指定します。

- LogMiner起動時にNO_SQL_DELIMITERオプションを指定します。
この指定によって、再構築される文からセミコロンが削除されます。この指定は、カーソルでオープンしてから、再構築された文を実行するアプリケーションに有効です。

V$LOGMNR_CONTENTSビューSTATUSフィールドに値2(invalid sql)が含まれている場合、関連付けられたSQL文は実行できません。

返されるデータの可読性向上のための表示方法の書式設定

問合せの結果、再構築されたSQL文を含む列が多数返され、表示内容が繁雑になり読みにくくなる場合があります。LogMinerでは、この問題に対応するためにPRINT_PRETTY_SQLオプションが用意されています。DBMS_LOGMNR.START_LOGMNRプロシージャに対してPRINT_PRETTY_SQLオプションを指定すると、再構築されたSQL文が次のように書式設定され、読みやすくなります。

insert into "HR"."JOBS"
values
"JOB_ID" = '9782',
"JOB_TITLE" = 'HR_ENTRY',
"MIN_SALARY" IS NULL,
"MAX_SALARY" IS NULL;
update "HR"."JOBS"
set
"JOB_TITLE" = 'FI_ENTRY'
where
"JOB_TITLE" = 'HR_ENTRY' and
ROWID = 'AAAHSeAABAAAY+CAAX';

update "HR"."JOBS"
set
"JOB_TITLE" = 'FI_ENTRY'
where
"JOB_TITLE" = 'HR_ENTRY' and
ROWID = 'AAAHSeAABAAAY+CAAX';

delete from "HR"."JOBS"
where
"JOB_ID" = '9782' and
"JOB_TITLE" = 'FI_ENTRY' and
"MIN_SALARY" IS NULL and
"MAX_SALARY" IS NULL and
ROWID = 'AAAHSeAABAAAY+CAAX';

PRINT_PRETTY_SQLオプションが有効な状態で再構築されたSQL文は、標準SQL構文を使用していないため、実行されません。

関連項目:

PRINT_PRETTY_SQLオプションの使用例の詳細は、「LogMinerの使用例」を参照してください

V$LOGMNR_CONTENTSに返されたDDL文の再適用

ユーザーが発行した一部のDDL文によって、1つ以上の他のDDL文がOracleによって内部的に実行される場合があることに注意してください。V$LOGMNR_CONTENTSビューのSQL_REDO列またはSQL_UNDO列から、データベースに対して最初に適用したときと同様にSQL DDLを再適用する場合は、Oracleによって内部的に実行された文を実行しないでください。

注意:

Oracleによって内部的に実行されたDML文を実行すると、データベースが破損する場合があります。例については、「例4: REDOログ・ファイル内のLogMinerディクショナリの使用」の手順5を参照してください。

ユーザーによって発行されたDDL文と、Oracleによって内部的に発行されたDDL文を区別するには、V$LOGMNR_CONTENTSのINFO列を問い合せます。INFO列の値は、DDLがユーザーによって実行されたか、Oracleによって実行されたかを示します。

最初に適用したときと同様にSQL DDLを再適用する場合は、V$LOGMNR_CONTENTSのINFO列に値USER_DDLが含まれる場合にのみ、SQL_REDO列またはSQL_UNDO列に含まれるDDL SQLを再実行する必要があります。

DBMS_LOGMNR.START_LOGMNRの複数回のコール

DBMS_LOGMNR.START_LOGMNRのコールに成功し、V$LOGMNR_CONTENTSビューから選択した後でも、現在のLogMinerセッションを終了せずにDBMS_LOGMNR.START_LOGMNRを再度コールし、異なるオプションおよび時間範囲またはSCN範囲を指定できます。次の場合にコールを複数回行います。

- LogMinerが分析するREDOデータの量を制限する。

- 異なるオプションを指定する。たとえば、PRINT_PRETTY_SQLオプションを指定する場合、コミット済トランザクションのみを表示する場合(COMMITTED_DATA_ONLYオプションを指定)などがあります。

- 分析する時間範囲またはSCN範囲を変更する。

例: DBMS_LOGMNR.START_LOGMNRの複数回のコール

次に、どのような場合にDBMS_LOGMNR.START_LOGMNRを複数回コールすると役立つかの例を示します。

例1: REDOログ・ファイルのデータのサブセットのみのマイニング

LogMinerがマイニングするREDOログ・ファイルのリストに、1週間の間に生成されたログ・ファイルが含まれているとします。ただし、それぞれの日の12:00から1:00の間に生成されたログ・ファイルのみを分析します。これを最も効率的に行う方法は次のとおりです。

1. 月曜日に、この時間範囲を指定して、DBMS_LOGMNR.START_LOGMNRをコールします。

2. V$LOGMNR_CONTENTSビューから変更を選択します。

3. 一週間のそれぞれの日に対して、手順1と2を繰り返します。

この方法では、その週のREDOデータの合計量が多い場合、リスト内の各REDOログ・ファイルの小さなサブセットのみがLogMinerによって読み込まれるため、全体の分析が非常に速く行われます。

例2: 時間範囲またはSCN範囲の調整

REDOログ・ファイル・リストを指定し、LogMiner起動時に時間範囲(またはSCN範囲)を指定するとします。V$LOGMNR_CONTENTSビューを問い合せると、指定した時間範囲には、必要なデータの一部のみが含まれます。時間範囲を1時間拡張するために、またはSCN範囲を調整するためにDBMS_LOGMNR.START_LOGMNRを再度コールできます。

例3: リモート・データベースで受信された場合のREDOログ・ファイルの分析

変更を分析またはデータベース間で変更をレプリケートするためのアプリケーションを作成したとします。ソース・データベースは、そのREDOログ・ファイルをマイニング・データベースに送信し、オペレーティング・システム・ディレクトリに格納します。アプリケーションは、次の手順を実行します。

1. 現在ディレクトリにあるすべてのREDOログ・ファイルをREDOログ・ファイル・リストに追加します。

2. 適切な設定でDBMS_LOGMNR.START_LOGMNRをコールし、V$LOGMNR_CONTENTSビューから選択します。

3. ディレクトリに新しく受信されたREDOログ・ファイルを追加します。

4. 必要に応じて、手順2と3を繰り返します。

サプリメンタル・ロギング

一般に、REDOログ・ファイルは、インスタンス・リカバリおよびメディア・リカバリに使用されます。これらの操作に必要なデータは、REDOログ・ファイルに自動的に記録されます。ただし、REDOベースのアプリケーションでは、追加の列をREDOログ・ファイルに記録する必要がある場合があります。これらの追加の列を記録するプロセスは、サプリメンタル・ロギングと呼ばれます。

デフォルトでは、Oracle Databaseでサプリメンタル・ロギングは提供されません。つまり、デフォルトでは、LogMinerは使用できません。したがって、LogMinerで分析するログ・ファイルを生成する前に、少なくとも最小サプリメンタル・ロギングは有効にする必要があります。

次に、追加の列が必要な例を示します。

- 再構築されたSQL文を別のデータベースに適用するアプリケーションでは、行を一意に識別する列(主キーなど)で更新文を識別する必要があります。ROWIDはデータベースごとに異なり、他のデータベースでは意味を持たないため、V$LOGMNR_CONTENTSビューによって返される再構築されたSQLに示されるROWIDでは識別できません。

- アプリケーションは、行変更の追跡をより効率的にするために、変更された列のみでなく、行全体のビフォア・イメージを記録する必要がある場合があります。

サプリメンタル・ログ・グループは、サプリメンタル・ロギングが有効な場合に記録される追加の列です。サプリメンタル・ログ・グループは2種類あり、これらによって、ログ・グループの列を記録する時期が決定されます。

- 無条件のサプリメンタル・ログ・グループ: 指定した列に更新が影響したかどうかに関係なく、行が更新されるたびに指定した列のビフォア・イメージが記録されます。これは、ALWAYSログ・グループと呼ばれる場合もあります。

- 条件付きのサプリメンタル・ログ・グループ: ログ・グループの1つ以上の列が更新された場合にのみ、指定したすべての列のビフォア・イメージが記録されます。

サプリメンタル・ログ・グループは、システムで生成することも、ユーザーが定義することもできます。

次の項で説明するとおり、サプリメンタル・ロギングには、2つの種類に加えて2つのレベルがあります。

- データベース・レベルのサプリメンタル・ロギング

- 表レベルのサプリメンタル・ロギング

関連項目:

「サプリメンタル・ロギング設定に関するビューの問合せ」

データベース・レベルのサプリメンタル・ロギング

データベース・レベルのサプリメンタル・ロギングには、次の項で説明するとおり、最小サプリメンタル・ロギングと識別キー・ロギングがあります。最小サプリメンタル・ロギングでは、REDOログ・ファイルを生成するデータベースに大きなオーバーヘッドが発生しません。ただし、データベース全体の識別キー・ロギングを有効にすると、REDOログ・ファイルを生成するデータベースにオーバーヘッドが発生する場合があります。LogMinerに対しては、少なくとも最小サプリメンタル・ロギングを有効にすることをお薦めします。

最小サプリメンタル・ロギング

最小サプリメンタル・ロギングは、LogMinerでDML変更と関連付けられたREDO操作を識別、グループ化およびマージするために必要な最小限の情報を記録します。また、LogMiner(およびLogMinerテクノロジに基づいた他の製品)に、連鎖行や様々な記憶域構成(クラスタ表、索引構成表など)のサポートに十分な情報を確保します。最小サプリメンタル・ロギングを有効にするには、次のSQL文を実行します。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

データベース・レベルの識別キー・ロギング

識別キー・ロギングは、REDOログ・ファイルがソース・データベース・インスタンスでマイニングされない場合(REDOログ・ファイルがロジカル・スタンバイ・データベースでマイニングされる場合など)に必要です。

データベース識別キー・ロギングを使用すると、次のオプションの1つ以上をSQLのALTER DATABASE ADD SUPPLEMENTAL LOG文に指定して、すべての更新に対してデータベース全体のビフォア・イメージ・ロギングを有効にできます。

- ALL: システムによって生成される無条件のサプリメンタル・ログ・グループ
このオプションを指定すると、行が更新された場合、その行のすべての列(LOB、LONGS、ADTを除く)がREDOログ・ファイルに格納されます。

データベース・レベルで、すべての列ロギングを有効にするには、次の文を実行します。

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

- PRIMARY KEY: システムによって生成される無条件のサプリメンタル・ログ・グループ
このオプションを指定すると、主キーを含む行が更新された場合(主キーの値に変更がない場合も)、データベースによって行の主キーのすべての列がREDOログ・ファイルに格納されます。

表に主キーが存在せず、1つ以上の非NULLの一意索引キー制約または索引キーが存在する場合は、一意索引キーのいずれかが、更新された行を一意に識別する手段としてロギング用に選択されます。

表に主キーと非NULLの一意索引キーのいずれも存在しない場合は、LONGとLOBを除くすべての列が補助的に記録されます。これは、その行に対してALLサプリメンタル・ロギングを指定することと同様です。したがって、データベース・レベルの主キー・サプリメンタル・ロギングを使用する場合は、すべてまたはほとんどの表に主キーまたは一意索引キーが含まれるように定義しておくことをお薦めします。

データベース・レベルで主キー・ロギングを有効にするには、次の文を実行します。

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

- UNIQUE: システムによって生成される条件付きのサプリメンタル・ログ・グループ
このオプションを指定すると、コンポジット一意キーまたはビットマップ索引に属する列が変更された場合、データベースによって、行のコンポジット一意キーまたはビットマップ索引のすべての列がREDOログ・ファイルに格納されます。一意キーは、一意制約または一意索引による場合があります。

データベース・レベルで一意索引キーおよびビットマップ索引のロギングを有効にするには、次の文を実行します。

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;

- FOREIGN KEY: システムによって生成される条件付きのサプリメンタル・ログ・グループ
このオプションを指定すると、データベースによって、外部キーに属する列が変更された場合、行の外部キーのすべての列がREDOログ・ファイルに格納されます。

データベース・レベルで外部キー・ロギングを有効にするには、次のSQL文を実行します。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (FOREIGN KEY) COLUMNS;

注意:

識別キー・ロギングが有効であるかどうかに関係なく、常に、LogMinerによって返されるSQL文にはROWID句が含まれます。DBMS_LOGMNR.START_LOGMNRプロシージャ・コールに対してNO_ROWID_IN_STMTオプションを使用すると、フィルタ処理でROWID句を除外できます。詳細は、「再実行のために再構築されたSQL文の書式設定」を参照してください。

識別キー・ロギングを使用する場合は、次のことに注意してください。

- 識別キー・ロギングが有効な場合にデータベースがオープンしていると、カーソル・キャッシュ内のすべてのDMLカーソルが無効になります。したがって、カーソル・キャッシュに再移入を行うまで、パフォーマンスに影響する場合があります。

- データベース・レベルで識別キー・ロギングを有効にすると、最小サプリメンタル・ロギングが暗黙で有効になります。

- サプリメンタル・ロギング文は累積的に実行されます。次のSQL文を発行すると、主キー・サプリメンタル・ロギングと一意キー・サプリメンタル・ロギングの両方が有効になります。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;

データベース・レベルのサプリメンタル・ロギングの無効化

データベース・レベルのサプリメンタル・ロギングを無効にするには、DROP SUPPLEMENTAL LOGGING句を指定してSQL ALTER DATABASE文を使用します。サプリメンタル・ロギング属性は段階的に削除できます。たとえば、次のSQL文を次の順序で発行したとします。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;

この文には、次のような効果があります。

- 最初の文の後、主キー・サプリメンタル・ロギングが有効になります。

- 2番目の文の後、主キー・サプリメンタル・ロギングおよび一意キー・サプリメンタル・ロギングが有効になります。

- 3番目の文の後、一意キー・サプリメンタル・ロギングのみが有効になります。

- 4番目の文の後、すべてのサプリメンタル・ロギングが無効になりません。次に示すエラーが返されます。ORA-32589: 最小限のサプリメンタル・ロギングは削除できません

すべてのデータベース・サプリメンタル・ロギングを無効にするには、最初に、有効になっている識別キー・ロギングをすべて無効にしてから、最小サプリメンタル・ロギングを無効にする必要があります。次の例に、正しい順序を示します。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;

最小サプリメンタル・ログ・データは、データベース・レベルの他のサプリメンタル・ロギングが有効になっていない場合にのみ削除できます。

表レベルのサプリメンタル・ロギング

表レベルのサプリメンタル・ロギングでは、補助的に記録する列を表レベルで指定します。識別キー・ロギングまたはユーザー定義の条件付きのサプリメンタル・ログ・グループまたは無条件のサプリメンタル・ログ・グループを使用して、次の項で説明するとおり、補助情報を記録できます。

表レベルの識別キー・ロギング

表レベルでの識別キー・ロギングでは、データベース・レベルの場合と同じオプション(すべて、主キー、外部キー、一意キー)が提供されます。ただし、表レベルで識別キー・ロギングを指定すると、指定した表のみが影響を受けます。たとえば、次のSQL文(データベース・レベルのサプリメンタル・ロギングの指定)を入力すると、データベース表の列が変更された場合は常に、その列を含む行全体(LOB、LONG、ADTの列を除く)がREDOログ・ファイルに格納されます。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

ただし、次のSQL文(表レベルのサプリメンタル・ロギングの指定)を入力すると、employees表の列が変更された場合にのみ、行全体(LOB、LONG、ADTを除く)がREDOログ・ファイルに格納されます。departments表の列が変更されると、変更された列のみがREDOログ・ファイルに格納されます。

ALTER TABLE HR.EMPLOYEES ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

表レベルの識別キー・ロギングを使用する場合は、次のことに注意してください。

- 表で識別キー・ロギングが有効な場合にデータベースがオープンしていると、カーソル・キャッシュ内のその表のすべてのDMLカーソルが無効になります。したがって、カーソル・キャッシュに再移入を行うまで、パフォーマンスに影響する場合があります。

- サプリメンタル・ロギング文は累積的に実行されます。次のSQL文を発行すると、主キー・サプリメンタル・ロギングと一意索引キーの表レベルのサプリメンタル・ロギングの両方が有効になります。

ALTER TABLE HR.EMPLOYEES
ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER TABLE HR.EMPLOYEES
ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;

各識別キー・ロギング・オプションの詳細は、「データベース・レベルの識別キー・ロギング」を参照してください。

表レベルのユーザー定義サプリメンタル・ログ・グループ

表レベルの識別キー・ロギングによって、ユーザー定義のサプリメンタル・ログ・グループもサポートされています。ユーザー定義サプリメンタル・ログ・グループによって、補助的に記録する列を指定できます。条件付きログ・グループまたは無条件ログ・グループは、次のとおり指定できます。

- ユーザー定義の無条件ログ・グループ
ユーザー定義の無条件ログ・グループを使用するサプリメンタル・ロギングを有効にするには、次の例に示すとおり、ALWAYS句を使用します。

ALTER TABLE HR.EMPLOYEES
ADD SUPPLEMENTAL LOG GROUP emp_parttime (EMPLOYEE_ID, LAST_NAME,
DEPARTMENT_ID) ALWAYS;

この例では、hr.employees表でemp_parttimeという名前のログ・グループが作成されます。このグループは、employee_id列、last_name列、department_id列で構成されます。これらの列は、UPDATE文がhr.employees表で実行されるたびに、その更新がこれらの列に影響するかどうかに関係なく記録されます。(更新が行われるたびに行イメージ全体を記録する場合は、前述のとおり、表レベルのALL識別キー・ロギングを使用します。)

注意:

LOB列、LONG列およびADT列は補助的に記録できません。

- ユーザー定義の条件付きログ・グループ
ユーザー定義の条件付きログ・グループを使用するサプリメンタル・ロギングを有効にするには、次の例に示すとおり、SQL ALTER TABLE文からALWAYS句を削除します。

ALTER TABLE HR.EMPLOYEES
ADD SUPPLEMENTAL LOG GROUP emp_fulltime (EMPLOYEE_ID, LAST_NAME,
DEPARTMENT_ID);

この例では、表hr.employeesでemp_fulltimeという名前のログ・グループが作成されます。前述の例と同様に、このグループは、employee_id列、last_name列およびdepartment_id列で構成されます。ただし、ALWAYS句が省略されたため、列のビフォア・イメージは、1つ以上の列が更新された場合にのみ記録されます。

無条件および条件付きのいずれのユーザー定義サプリメンタル・ログ・グループでも、NO LOGオプションを指定して、ログ・グループ内の列をサプリメンタル・ロギングから除外することを明示的に指定できます。ログ・グループを指定し、NO LOGオプションを使用する場合は、次の例に示すとおり、NO LOGオプションが接続されていない列をログ・グループで1つ以上指定する必要があります。

ALTER TABLE HR.EMPLOYEES
ADD SUPPLEMENTAL LOG GROUP emp_parttime(
DEPARTMENT_ID NO LOG, EMPLOYEE_ID);

これによって、NO LOG列に変更を行うと、サプリメンタル・ログ・グループ内の他の列がREDOログ・ファイルに格納されるように、指定されたサプリメンタル・ログ・グループ内の他の列とこの列とを関連付けることができます。この方法は、たとえば、LONG列の変更時にグループの特定の列を記録する場合に有効です。LONG列自体は補助的に記録できませんが、この列に対して行った変更を使用して、同じ行の他の列のサプリメンタル・ロギングをトリガーすることはできます。

ユーザー定義のサプリメンタル・ログ・グループを使用する場合の注意事項

ユーザー定義のサプリメンタル・ログ・グループを指定する場合は、次の点に注意してください。

- 1つの列を複数のサプリメンタル・ログ・グループに含めることができます。ただし、その列のビフォア・イメージの記録は1回のみです。

- 条件付きと無条件の両方で同じ列を記録することを指定した場合、その列は無条件に記録されます。

LogMinerディクショナリでのDDL文の追跡

LogMinerでは、LogMiner起動時に指定したLogMinerディクショナリ(オンライン・カタログ、REDOログ・ファイルのディクショナリまたはフラット・ファイルのいずれか)から独自の内部ディクショナリが自動的に作成されます。このディクショナリでは、データベース・オブジェクトとその定義のスナップショットが提供されます。

LogMinerディクショナリがREDOログ・ファイルにある場合またはフラット・ファイルである場合は、PL/SQL DBMS_LOGMNR.START_LOGMNRプロシージャに対してDDL_DICT_TRACKINGオプションを使用して、LogMinerでデータ定義言語(DDL)文を追跡することができます。DDL追跡によって、LogMinerは、表での列の追加や削除など、データベース・オブジェクトに対して行われた構造上の変更を問題なく追跡できます。次に例を示します。

EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => -
DBMS_LOGMNR.DDL_DICT_TRACKING + DBMS_LOGMNR.DICT_FROM_REDO_LOGS);

例の詳細は、「例5: 内部ディクショナリでのDDL文の追跡」を参照してください。

このオプションが設定されている場合、LogMinerは、REDOログ・ファイルで検出されたDDL文をその内部ディクショナリに適用します。

注意:

サプリメンタル・ロギングおよびDDL追跡機能が有効でない場合にDDLイベントが発生すると、LogMinerによってREDOデータの一部がバイナリ・データとして返されるため、通常、これらの機能を有効にしておくことをお薦めします。また、メタデータ・バージョンの不一致が発生する可能性もあります。

DDL_DICT_TRACKINGを有効にすると、LogMinerディクショナリの抽出後に作成された表で実行されたデータ操作言語(DML)操作を正常に表示できます。

たとえば、employees表が、1回目の操作でgender列が追加され、次の操作でcommission_pct列が削除されるように、連続する2つのDDL操作で更新された場合、LogMinerによって、これらの変更のそれぞれに対するemployeesについての情報がバージョン化されます。つまり、これらのDDLの変更前と変更後のREDOログ・ファイルは、LogMinerによって正常にマイニングできるため、SQL_REDO列またはSQL_UNDO列にバイナリ・データは表示されません。

LogMinerは、データベース・メタデータに対して自動的にバージョンを割り当てるため、内部ディクショナリとREDOログ・ファイル内のディクショナリとの間で不一致を検出して通知します。LogMinerによって不一致が検出されると、V$LOGMNR_CONTENTSビューのSQL_REDO列でバイナリ・データが生成され、INFO列に「ディクショナリのバージョンの不一致」という文字列、STATUS列に値2が入力されます。

注意:

LogMiner内部ディクショナリが、フラット・ファイル、REDOログ・ファイルまたはオンライン・カタログに含まれているLogMinerディクショナリとは異なることを理解しておいてください。LogMinerは、LogMiner内部ディクショナリは更新しますが、フラット・ファイル、REDOログ・ファイルまたはオンライン・カタログに含まれているディクショナリは更新しません。

次に、DBMS_LOGMNR.START_LOGMNRプロシージャでDDL_DICT_TRACKINGオプションを指定するための要件を説明します。

- DDL_DICT_TRACKINGオプションは、DICT_FROM_ONLINE_CATALOGオプションとは併用できません。

- DDL_DICT_TRACKINGオプションでは、データベースがオープンしている必要があります。

- サプリメンタル・ロギングをデータベース全体で有効にするか、または対象となる表のログ・グループを作成しておく必要があります。

DDL_DICT_TRACKINGおよびサプリメンタル・ロギングの設定

ディクショナリ追跡とサプリメンタル・ロギングの各種設定を組み合せた場合に発生する次の相互作用に注意してください。

- DDL_DICT_TRACKINGが有効で、サプリメンタル・ロギングが有効でない場合は、次のようになります。

- REDOログ・ファイルでDDLトランザクションが検出された場合、V$LOGMNR_CONTENTSの問合せはORA-01347エラーを返して終了します。

- REDOログ・ファイルでDMLトランザクションが検出された場合、LogMinerディクショナリ内の表(そのDMLの基礎となる表)の現在のバージョンがLogMinerによって正しいとは認識されず、V$LOGMNR_CONTENTSの列が次のように設定されます。

- SQL_REDO列にバイナリ・データが含まれます。

- STATUS列に値2が含まれます(SQLが有効でないことを示します)。

- INFO列に「ディクショナリの不一致」という文字列が含まれます。

- DDL_DICT_TRACKINGおよびサプリメンタル・ロギングが有効ではない場合、DML操作で参照された列がLogMinerディクショナリ内の列と一致すると、LogMinerディクショナリの最新バージョンがLogMinerによって正しいと認識され、V$LOGMNR_CONTENTSの列が次のように設定されます。

- LogMinerは、LogMinerディクショナリ内のオブジェクトの定義を使用して、SQL_REDO列とSQL_UNDO列の値を生成します。

- STATUS列に値3が含まれます(SQLが正しいと保証できないことを示します)。

- INFO列には、「サプリメンタル・ログ・データが見つかりません」という文字列が含まれます。

- DDL_DICT_TRACKINGおよびサプリメンタル・ロギングが有効ではない場合に、表のLogMinerディクショナリ定義で定義された列より、表のREDOログ・ファイル内の変更された列の方が多いときは、次のようになります。

- SQL_REDO列とSQL_UNDO列に「ディクショナリのバージョンの不一致」という文字列が含まれます。

- STATUS列に値2が含まれます(SQLが有効でないことを示します)。

- INFO列に「ディクショナリの不一致」という文字列が含まれます。

また、列のディクショナリ定義で定義されている型とその列の実際の型が異なる場合は、予期しない動作が発生する可能性があります。

DDL_DICT_TRACKINGおよび指定された時間範囲またはSCN範囲

LogMinerは、LogMinerディクショナリの一貫性を維持するためにDDL文が必要なため、DDL_DICT_TRACKINGオプションが有効な場合、要求した開始時刻またはSCN(DBMS_LOGMNR.START_LOGMNRで指定)より前に、REDOログ・ファイルの読取りを開始する場合があります。LogMinerがREDOログ・ファイルの読取りを開始する実際の時刻またはSCNは、必須開始時刻または必須開始SCNと呼ばれます。

欠落REDOログ・ファイル(順序番号に基づく)は、必須開始時刻または必須開始SCNから読取りを開始できません。

LogMinerでは、REDOログ・データの読取りを開始する位置を次のとおり決定します。

- ディクショナリのロード後、DBMS_LOGMNR.START_LOGMNRを初めてコールする場合、LogMinerは、次のいずれかの値の早い方を基準に読取りを開始します。

- ユーザーが要求した開始時刻またはSCN値

- ディレクトリ・ダンプのコミットSCN

- DBMS_LOGMNR.START_LOGMNRに対するこれ以降のコールでは、LogMinerは、次のいずれかの値の最も早いものを基準に読取りを開始します。

- ユーザーが要求した開始時刻またはSCN値

- COMMIT文がLogMinerによって読み込まれていない最も早いDDLトランザクションの開始時

- LogMinerによって読み込まれた最高のSCN

次に、前述の内容の使用例を示します。

5つのREDOログ・ファイルを含むREDOログ・ファイル・リストを作成するとします。ディクショナリは、最初のREDOファイルに含まれ、確認対象として指定した変更(DBMS_LOGMNR.START_LOGMNRを使用)は、3番目のREDOログ・ファイルに記録されているとします。ここで、次の手順を実行します。

1. DBMS_LOGMNR.START_LOGMNRをコールします。LogMinerによって、次のログ・ファイルが読み込まれます。

a. ディクショナリをロードするための最初のログ・ファイル

b. その中に含まれている可能性があるDDLをすべて取得するための2番目のREDOログ・ファイル

c. 必要なデータを取得するための3番目のログ・ファイル

2. 同じ要求範囲で、再度DBMS_LOGMNR.START_LOGMNRをコールします。
LogMinerは、REDOログ・ファイル3から読取りを開始します。REDOログ・ファイル2に含まれているDDL文はすでに処理されているため、REDOログ・ファイル2を読み込む必要はありません。

3. DBMS_LOGMNR.START_LOGMNRを再度コールします。今回は、REDOログ・ファイル5からデータを読み込む必要があるパラメータを指定します。
LogMinerは、REDOログ・ファイル4から読取りを開始し、その中に含まれているすべてのDDL文を取得します。

LogMinerが実際に読取りを開始する位置を確認するには、V$LOGMNR_PARAMETERSビューのREQUIRED_START_DATE列またはREQUIRED_START_SCN列を問い合せます。LogMinerが読取りを開始する位置に関係なく、要求した範囲内の行のみがV$LOGMNR_CONTENTSビューから返されます。

ビューでのLogMiner操作情報へのアクセス

LogMiner操作情報(REDOデータではなく)は、次のビューに含まれています。他のビューと同様に、SQLを使用してこれらのビューを問い合せることができます。

- V$LOGMNR_DICTIONARY
DBMS_LOGMNR.START_LOGMNRに対してSTORE_IN_FLAT_FILEオプションを使用して作成されたLogMinerディクショナリ・ファイルに関する情報を表示します。LogMinerディクショナリ作成の基礎となったデータベースに関する情報などが表示されます。

- V$LOGMNR_LOGS
指定したREDOログ・ファイルに関する情報を表示します。詳細は、「V$LOGMNR_LOGSの問合せ」を参照してください。

- V$LOGMNR_PARAMETERS
オプションのLogMinerパラメータに関する情報を表示します。開始システム変更番号(SCN)と終了SCN、開始時刻と終了時刻などの情報が含まれます。

- V$DATABASE、DBA_LOG_GROUPS、ALL_LOG_GROUPS、USER_LOG_GROUPS、DBA_LOG_GROUP_COLUMNS、ALL_LOG_GROUP_COLUMNS、USER_LOG_GROUP_COLUMSNS
サプリメンタル・ロギングの現在の設定に関する情報を表示します。詳細は、「サプリメンタル・ロギング設定に関するビューの問合せ」を参照してください。

V$LOGMNR_LOGSの問合せ

V$LOGMNR_LOGSビューを問い合せて、LogMinerによる分析のためにREDOログ・ファイルのリストに手動または自動で追加されたREDOログ・ファイルを判別することができます。このビューでは、REDOログ・ファイルごとに1行が含まれます。各REDOログ・ファイルに関する重要な情報(ファイル名、順序番号、SCN範囲、時間範囲、LogMinerディクショナリのすべてを含むか一部を含むかなど)が提供されます。

DBMS_LOGMNR.START_LOGMNRに対するコールが成功すると、V$LOGMNR_LOGSビューのSTATUS列には、次のいずれかの値が含まれます。

- 0
REDOログ・ファイルが、V$LOGMNR_CONTENTSビューの問合せ中に処理されることを示します。

- 1
対象のREDOログ・ファイルが、V$LOGMNR_CONTENTSビューに対する選択操作中にLogMinerによって処理される、最初のREDOログ・ファイルとなることを示します。

- 2
REDOログ・ファイルが除外されたため、V$LOGMNR_CONTENTSビューの問合せ中にLogMinerによって処理されないことを示します。このファイルは、要求した時間範囲またはSCN範囲を満たすには不要なため、除外されました。

- 4
LogMiner REDOログ・ファイル・リストから、REDOログ・ファイル(順序番号に基づく)が欠落していることを示します。

V$LOGMNR_LOGSビューには、次のように、リストから欠落している各REDOログ・ファイルに対する行が1行含まれます。

- FILENAME列には、順序番号の連続する範囲とSCN範囲の差異の合計が含まれます。
例: スレッド番号1、順序番号100から102の欠落ログ・ファイル

- INFO列には、MISSING_LOGFILEという文字列が含まれます。

REDOログ・ファイル・リストから欠落しているファイルの情報は、次の場合に有効な場合があります。

- DBMS_LOGMNR.START_LOGMNRへのコール時に指定可能なDDL_DICT_TRACKINGオプションおよびCONTINUOUS_MINEオプションによって、要求した時間範囲またはSCN範囲に対するLogMiner REDOログ・ファイル・リストから、REDOログ・ファイルが欠落しなくなります。DBMS_LOGMNR.START_LOGMNRに対するコールが失敗した場合、V$LOGMNR_LOGSビューのSTATUS列を問い合せることによって、リストから欠落しているREDOログ・ファイルを判別できます。その後、欠落しているREDOログ・ファイルを検索して、手動で追加すると、再度DBMS_LOGMNR.START_LOGMNRをコールできます。

- DBMS_LOGMNR.START_LOGMNRへのコール時に指定可能なその他のオプションでは、LogMiner REDOログ・ファイル・リストからファイルが欠落する場合がありますが、ファイルの欠落は、可能なかぎり回避する必要があります。V$LOGMNR_CONTENTSビューを問い合せる前に、V$LOGMNR_LOGSビューを問い合せて、必要なすべてのファイルがリストにあることを確認できます。リストに欠落ファイルがある場合にV$LOGMNR_CONTENTSビューを問い合せると、次の列の値を持つ行がV$LOGMNR_CONTENTSに返されます。

- OPERATION列の値MISSING_SCN

- STATUS列の値1291

- INFO列の欠落しているSCN範囲を示す文字列(「欠落SCN 100から200」など)

サプリメンタル・ロギング設定に関するビューの問合せ

次のリストに示すように、複数のビューを問い合せてサプリメンタル・ロギングの現在の設定を確認できます。

- V$DATABASEビュー

- SUPPLEMENTAL_LOG_DATA_FK列
この列には次のいずれかの値が入ります。

- NO: FOREIGN KEYオプションを指定したデータベース・レベルの識別キー・ロギングが有効でない場合

- YES: FOREIGN KEYオプションを指定したデータベース・レベルの識別キー・ロギングが有効な場合

- SUPPLEMENTAL_LOG_DATA_ALL列
この列には次のいずれかの値が入ります。

- NO: ALLオプションを指定したデータベース・レベルの識別キー・ロギングが有効でない場合

- YES: ALLオプションを指定したデータベース・レベルの識別キー・ロギングが有効な場合

- SUPPLEMENTAL_LOG_DATA_UI列

- NO: UNIQUEオプションを指定したデータベース・レベルの識別キー・ロギングが有効でない場合

- YES: UNIQUEオプションを指定したデータベース・レベルの識別キー・ロギングが有効な場合

- SUPPLEMENTAL_LOG_DATA_MIN列
この列には次のいずれかの値が入ります。

- NO: データベース・レベルのサプリメンタル・ロギングが有効でない場合

- IMPLICIT: データベース・レベルの識別キー・ロギング・オプションが有効なため、最小サプリメンタル・ロギングが有効な場合

- YES: SQL ALTER DATABASE ADD SUPPLEMENTAL LOG DATA文が発行されているため、最小サプリメンタル・ロギングが有効な場合

- DBA_LOG_GROUPS、ALL_LOG_GROUPS、USER_LOG_GROUPSの各ビュー

- ALWAYS列
この列には次のいずれかの値が入ります。

- ALWAYS: このログ・グループの列は、関連付けられた行の列が更新された場合に補助的に記録されることを示します。

- CONDITIONAL :このグループの列は、ログ・グループの列が更新された場合にのみ補助的に記録されることを示します。

- GENERATED列
この列には次のいずれかの値が入ります。

- GENERATED NAME: LOG_GROUP名がシステムによって生成された場合です。

- USER NAME: LOG_GROUP名がユーザーによって定義された場合です。

- LOG_GROUP_TYPE列
この列には、次のいずれかの値が入り、このログ・グループで定義されたロギングの種類を示します。USER LOG GROUPは、ログ・グループがユーザー定義である(システム生成ではない)ことを示します。

- ALL COLUMN LOGGING

- FOREIGN KEY LOGGING

- PRIMARY KEY LOGGING

- UNIQUE KEY LOGGING

- USER LOG GROUP

- DBA_LOG_GROUP_COLUMNS、ALL_LOG_GROUP_COLUMNS、USER_LOG_GROUP_COLUMNSの各ビュー

- LOGGING_PROPERTY列
この列には次のいずれかの値が入ります。

- LOG: ログ・グループのこの列が補助的に記録されることを示します。

- NO LOG: ログ・グループのこの列が補助的に記録されないことを示します。

一般的なLogMinerセッションの手順

この項では、一般的LogMinerセッションの手順について説明します。各手順の詳細は、該当する後述の項を参照してください。

1. サプリメンタル・ロギングの有効化

2. LogMinerディクショナリの抽出(オンライン・カタログを使用する予定でない場合)

3. 分析するREDOログ・ファイルの指定

4. LogMinerの起動

5. V$LOGMNR_CONTENTSの問合せ

6. LogMinerセッションの終了

LogMinerを実行するには、DBMS_LOGMNR PL/SQLパッケージを使用します。また、オンライン・カタログを使用するのではなく、LogMinerディクショナリを抽出した場合は、DBMS_LOGMNR_Dパッケージも使用します。

DBMS_LOGMNRパッケージには、LogMinerの初期化および実行に使用するプロシージャ(REDOログ・ファイルの名前、フィルタ基準、セッション特性を指定するためのインタフェースなど)が含まれます。DBMS_LOGMNR_Dパッケージは、現在のデータベースのデータベース・ディクショナリ表を問い合せてLogMinerディクショナリ・ファイルを作成します。

LogMiner PL/SQLパッケージは、SYSスキーマが所有します。したがって、ユーザーSYSとして接続していない場合は、次の条件が必要になります。

- コールにSYSを含める必要があります。次に例を示します。

EXECUTE SYS.DBMS_LOGMNR.END_LOGMNR;

- EXECUTE_CATALOG_ROLEロールを付与されている必要があります。

関連項目:

- これらのLogMinerパッケージの構文およびパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- PL/SQLパッケージの詳細は、『Oracle Database開発ガイド』を参照してください。

一般的なLogMinerセッション・タスク1: サプリメンタル・ロギングの有効化

使用する種類のサプリメンタル・ロギングを有効にします。最低限、次のように最小サプリメンタル・ロギングを有効にする必要があります。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

詳細は、「サプリメンタル・ロギング」を参照してください。

一般的なLogMinerセッション・タスク2: LogMinerディクショナリの抽出

LogMinerを使用するには、次のいずれかの方法でディクショナリを含める必要があります。

- LogMiner起動時にDICT_FROM_ONLINE_CATALOGオプションでオンライン・カタログの使用を指定。詳細は、「オンライン・カタログの使用」を参照してください。

- REDOログ・ファイルにデータベース・ディクショナリ情報を抽出。詳細は、「REDOログ・ファイルへのLogMinerディクショナリの抽出」を参照してください。

- フラット・ファイルにデータベース・ディクショナリ情報を抽出。詳細は、「フラット・ファイルへのLogMinerディクショナリの抽出」を参照してください。

一般的なLogMinerセッション・タスク3: 分析用のREDOログ・ファイルの指定

LogMinerを起動する前に、分析するREDOログ・ファイルを指定する必要があります。この指定を行うには、次の手順で示すとおり、DBMS_LOGMNR.ADD_LOGFILEプロシージャを実行します。REDOログ・ファイルは、任意の順序で追加および削除できます。

注意:

REDOログ・ファイルを生成するデータベース・インスタンスでマイニングを行う場合は、LogMinerの起動時にCONTINUOUS_MINEオプションおよび次のいずれかのパラメータを指定する必要があります。

- STARTSCNパラメータ

- STARTTIMEパラメータ

詳細は、「REDOログ・ファイル・オプション」を参照してください。

1. データベースをマウントした状態またはマウントしていない状態で、SQL*Plusを使用してOracleインスタンスを起動します。たとえば、SQLプロンプトでSTARTUP文を入力します。

STARTUP

2. REDOログ・ファイルのリストを作成します。PL/SQLプロシージャDBMS_LOGMNR.ADD_LOGFILEのNEWオプションを指定して、新規リストの開始であることを指定します。たとえば、REDOログ・ファイル/oracle/logs/log1.fを指定するには、次のように入力します。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => '/oracle/logs/log1.f', -
OPTIONS => DBMS_LOGMNR.NEW);

3. 必要に応じて、PL/SQLプロシージャDBMS_LOGMNR.ADD_LOGFILEのADDFILEオプションを指定し、さらにREDOログ・ファイルを追加します。たとえば、REDOログ・ファイル/oracle/logs/log2.fを追加するには、次のように入力します。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => '/oracle/logs/log2.f', -
OPTIONS => DBMS_LOGMNR.ADDFILE);

REDOログ・ファイルを追加する場合、OPTIONSパラメータの指定はオプションです。たとえば、次のように入力できます。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME=>'/oracle/logs/log2.f');

4. 必要に応じて、PL/SQLプロシージャDBMS_LOGMNR.REMOVE_LOGFILEを使用してREDOログ・ファイルを削除します。たとえば、REDOログ・ファイル/oracle/logs/log2.fを削除するには、次のように入力します。

EXECUTE DBMS_LOGMNR.REMOVE_LOGFILE( -
LOGFILENAME => '/oracle/logs/log2.f');

一般的なLogMinerセッション・タスク4: LogMinerの起動

LogMinerディクショナリ・ファイルを作成し、分析するREDOログ・ファイルを指定した後、LogMinerを起動する必要があります。次の手順を実行します。

1. DBMS_LOGMNR.START_LOGMNRプロシージャを実行して、LogMinerを起動します。

LogMinerディクショナリ・オプションを指定することをお薦めします。このオプションを指定していない場合、LogMinerでは、内部オブジェクトの識別子とデータ型を、オブジェクト名と外部データ書式に変換できません。したがって、内部オブジェクトIDが返され、データはバイナリ・データとして提供されます。また、ディクショナリがない場合、MINE_VALUE機能およびCOLUMN_PRESENT機能は使用できません。

フラット・ファイルのLogMinerディクショナリの名前を指定する場合は、そのディクショナリ・ファイルに完全修飾されたファイル名を指定する必要があります。たとえば、/oracle/database/dictionary.oraを使用してLogMinerを起動するには、次の文を発行します。

EXECUTE DBMS_LOGMNR.START_LOGMNR( -
DICTFILENAME =>'/oracle/database/dictionary.ora');

フラット・ファイルのディクショナリ名を指定しない場合は、OPTIONSパラメータを使用して、DICT_FROM_REDO_LOGSオプションまたはDICT_FROM_ONLINE_CATALOGオプションのいずれかを指定します。

DICT_FROM_REDO_LOGSを指定した場合、LogMinerでは、DBMS_LOGMNR.ADD_LOGFILEプロシージャで指定したREDOログ・ファイルに、ディクショナリが含まれていると認識されます。ディクショナリが含まれているREDOログ・ファイルを判別するには、V$ARCHIVED_LOGビューを使用します。例については、「REDOログ・ファイルへのLogMinerディクショナリの抽出」を参照してください。

注意:

LogMinerの起動後にREDOログ・ファイルを追加した場合は、LogMinerを再起動する必要があります。LogMinerは、DBMS_LOGMNR.START_LOGMNRに対する前回のコールに含まれていたオプションを保持しないため、使用するオプションを再度指定する必要があります。ただし、DBMS_LOGMNR.START_LOGMNRに対する現在のコールでディクショナリを指定しない場合は、前回のコールで指定したディクショナリ仕様を保持します。

DICT_FROM_ONLINE_CATALOGオプションの詳細は、「オンライン・カタログの使用」を参照してください。

2. オプションで、時刻またはSCNによって問合せをフィルタ処理できます。詳細は、「時刻によるデータのフィルタ処理」または「SCNによるデータのフィルタ処理」を参照してください。

3. OPTIONSパラメータを使用して、LogMinerセッションの特性を追加指定することもできます。たとえば、オンライン・カタログをLogMinerディクショナリとして使用して、V$LOGMNR_CONTENTSビューにコミット済トランザクションのみを表示できます。次のように入力します。

EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => -
DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -
DBMS_LOGMNR.COMMITTED_DATA_ONLY);

DBMS_LOGMNR.START_LOGMNRオプションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

DBMS_LOGMNR.START_LOGMNRプロシージャは、毎回異なるオプションを指定して、複数回実行できます。この機能は、たとえば、V$LOGMNR_CONTENTSの問合せから必要な結果を取得できず、他のオプションを指定してLogMinerを再起動する場合に有効です。LogMinerディクショナリを再指定する必要がないかぎり、DBMS_LOGMNR.START_LOGMNRに対する前回のコールでREDOログ・ファイルがすでに追加されている場合は、再度追加する必要はありません。

一般的なLogMinerセッション・タスク5: V$LOGMNR_CONTENTSの問合せ

この時点で、LogMinerは起動され、V$LOGMNR_CONTENTSビューに対して問合せを実行できます。この例については、「V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定」を参照してください。

一般的なLogMinerセッション・タスク6: LogMinerセッションの終了

LogMinerセッションを正常に終了するには、次に示すとおり、PL/SQLプロシージャDBMS_LOGMNR.END_LOGMNRを使用します。

EXECUTE DBMS_LOGMNR.END_LOGMNR;

このプロシージャを実行すると、すべてのREDOログ・ファイルがクローズされ、LogMinerによって割り当てられたすべてのデータベースとシステム・リソースを解放できます。

このプロシージャを実行しない場合、LogMinerは、コールを実行したOracleセッションが終了するまで、割り当てられたすべてのリソースを保持します。DDL_DICT_TRACKINGオプションまたはDICT_FROM_REDO_LOGSオプションのいずれかを使用した場合は、LogMinerセッションの終了に、このプロシージャを使用する必要があります。

LogMinerの使用例

この項では、次の各一般的カテゴリでのLogMinerの使用例を示します。

- 分析するREDOログ・ファイルの明示的指定によるマイニングの例

- REDOログ・ファイルのリストを明示的に指定しないマイニングの例

- 使用例

注意:

この項のすべての例では、最小サプリメンタル・ロギングが次のように有効にされているとします。

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

詳細は、「サプリメンタル・ロギング」を参照してください。

「例2: 指定したSCN範囲でのREDOログ・ファイルのマイニング」と「シナリオの例」以外のすべての例では、NLS_DATE_FORMATパラメータが次のように設定されているとみなします。

SQL>  ALTER SESSION SET NLS_DATE_FORMAT = 'dd-mon-yyyy hh24:mi:ss';

LogMinerではユーザー・セッションに対してアクティブなNLS_DATE_FORMATパラメータの設定を使用して日付データが表示されるため、この手順はオプションです。ただし、このパラメータを明示的に設定すると、指定した日付書式が使用されます。

分析するREDOログ・ファイルの明示的指定によるマイニングの例

次の例では、分析対象データが存在するREDOログ・ファイルがわかっている場合のLogMinerの使用方法を示します。この項は、次に示す例で構成されています。それぞれの例は、前の例に基づいて作成されているため、順番に読み進むことをお薦めします。

- 例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索

- 例2: コミット済トランザクションへのDML文のグループ化

- 例3: 再構築されたSQLの書式設定

- 例4: REDOログ・ファイル内のLogMinerディクショナリの使用

- 例5: 内部ディクショナリでのDDL文の追跡

- 例6: 時間範囲による出力のフィルタ処理

SQL出力の画面上の書式設定は、この項で示す例とは異なる場合があります。

例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索

データベースの変更履歴を確認する最も簡単な方法は、ソース・データベースでマイニングし、オンライン・カタログを使用してREDOログ・ファイルを変換する方法です。この例では、LogMinerを使用して最も簡単に分析を行う方法を示します。

この例では、最後にアーカイブされたREDOログ・ファイルをマイニングするとします。これは、最後にアーカイブされたREDOログ(データベースで生成)に含まれているすべての変更を検索します(データベースは、Oracle Real Application Clusters (Oracle RAC)データベースでないものとします)。

1. 最後にアーカイブされたREDOログ・ファイルを判別します。

SELECT NAME FROM V$ARCHIVED_LOG
WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG);

NAME
-------------------------------------------
/usr/oracle/data/db1arch_1_16_482701534.dbf

2. 分析するREDOログ・ファイルのリストを指定します。この場合は、手順1の問合せで返されたREDOログ・ファイルです。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', -
OPTIONS => DBMS_LOGMNR.NEW);

3. LogMinerを起動し、使用するディクショナリを指定します。

EXECUTE DBMS_LOGMNR.START_LOGMNR( -
OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);

4. V$LOGMNR_CONTENTSビューを問い合せます。
4つのトランザクションがあることに注意してください(そのうちの2つは、分析するREDOログ・ファイル内でコミット済であり、2つはコミットされていません)。出力には、実行された順序でDML文が表示されるため、トランザクションは交互に配置されます。

SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' ||  XIDSQN) AS XID,
SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS WHERE username IN ('HR', 'OE');

USR    XID          SQL_REDO                        SQL_UNDO
----   ---------  ----------------------------------------------------
HR     1.11.1476  set transaction read write;

HR     1.11.1476  insert into "HR"."EMPLOYEES"(     delete from "HR"."EMPLOYEES"
"EMPLOYEE_ID","FIRST_NAME",       where "EMPLOYEE_ID" = '306'
"LAST_NAME","EMAIL",              and "FIRST_NAME" = 'Nandini'
"PHONE_NUMBER","HIRE_DATE",       and "LAST_NAME" = 'Shastry'
"JOB_ID","SALARY",                and "EMAIL" = 'NSHASTRY'
"COMMISSION_PCT","MANAGER_ID",    and "PHONE_NUMBER" = '1234567890'
"DEPARTMENT_ID") values           and "HIRE_DATE" = TO_DATE('10-JAN-2012
('306','Nandini','Shastry',       13:34:43', 'dd-mon-yyyy hh24:mi:ss')
'NSHASTRY', '1234567890',         and "JOB_ID" = 'HR_REP' and
TO_DATE('10-jan-2012 13:34:43',   "SALARY" = '120000' and
'dd-mon-yyyy hh24:mi:ss'),         "COMMISSION_PCT" = '.05' and
'HR_REP','120000', '.05',         "DEPARTMENT_ID" = '10' and
'105','10');                      ROWID = 'AAAHSkAABAAAY6rAAO';

OE     1.1.1484   set transaction read write;

OE     1.1.1484   update "OE"."PRODUCT_INFORMATION"  update "OE"."PRODUCT_INFORMATION"
set "WARRANTY_PERIOD" =            set "WARRANTY_PERIOD" =
TO_YMINTERVAL('+05-00') where      TO_YMINTERVAL('+01-00') where
"PRODUCT_ID" = '1799' and          "PRODUCT_ID" = '1799' and
"WARRANTY_PERIOD" =                "WARRANTY_PERIOD" =
TO_YMINTERVAL('+01-00') and        TO_YMINTERVAL('+05-00') and
ROWID = 'AAAHTKAABAAAY9mAAB';      ROWID = 'AAAHTKAABAAAY9mAAB';

OE     1.1.1484   update "OE"."PRODUCT_INFORMATION"  update "OE"."PRODUCT_INFORMATION"
set "WARRANTY_PERIOD" =            set "WARRANTY_PERIOD" =
TO_YMINTERVAL('+05-00') where      TO_YMINTERVAL('+01-00') where
"PRODUCT_ID" = '1801' and          "PRODUCT_ID" = '1801' and
"WARRANTY_PERIOD" =                "WARRANTY_PERIOD" =
TO_YMINTERVAL('+01-00') and        TO_YMINTERVAL('+05-00') and
ROWID = 'AAAHTKAABAAAY9mAAC';      ROWID ='AAAHTKAABAAAY9mAAC';

HR     1.11.1476  insert into "HR"."EMPLOYEES"(     delete from "HR"."EMPLOYEES"
"EMPLOYEE_ID","FIRST_NAME",       "EMPLOYEE_ID" = '307' and
"LAST_NAME","EMAIL",              "FIRST_NAME" = 'John' and
"PHONE_NUMBER","HIRE_DATE",       "LAST_NAME" = 'Silver' and
"JOB_ID","SALARY",                "EMAIL" = 'JSILVER' and
"COMMISSION_PCT","MANAGER_ID",    "PHONE_NUMBER" = '5551112222'
"DEPARTMENT_ID") values           and "HIRE_DATE" = TO_DATE('10-jan-2012
('307','John','Silver',           13:41:03', 'dd-mon-yyyy hh24:mi:ss')
'JSILVER', '5551112222',         and "JOB_ID" ='105' and "DEPARTMENT_ID"
TO_DATE('10-jan-2012 13:41:03',   = '50' and ROWID = 'AAAHSkAABAAAY6rAAP';
'dd-mon-yyyy hh24:mi:ss'),
'SH_CLERK','110000', '.05',
'105','50');

OE     1.1.1484   commit;

HR     1.15.1481   set transaction read write;

HR     1.15.1481  delete from "HR"."EMPLOYEES"      insert into "HR"."EMPLOYEES"(
where "EMPLOYEE_ID" = '205' and   "EMPLOYEE_ID","FIRST_NAME",
"FIRST_NAME" = 'Shelley' and      "LAST_NAME","EMAIL","PHONE_NUMBER",
"LAST_NAME" = 'Higgins' and       "HIRE_DATE", "JOB_ID","SALARY",
"EMAIL" = 'SHIGGINS' and          "COMMISSION_PCT","MANAGER_ID",
"PHONE_NUMBER" = '515.123.8080'   "DEPARTMENT_ID") values
and "HIRE_DATE" = TO_DATE(        ('205','Shelley','Higgins',
'07-jun-1994 10:05:01',           and     'SHIGGINS','515.123.8080',
'dd-mon-yyyy hh24:mi:ss')         TO_DATE('07-jun-1994 10:05:01',
and "JOB_ID" = 'AC_MGR'           'dd-mon-yyyy hh24:mi:ss'),
and "SALARY"= '12000'            'AC_MGR','12000',NULL,'101','110');
and "COMMISSION_PCT" IS NULL
and "MANAGER_ID"
= '101' and "DEPARTMENT_ID" =
'110' and ROWID =
'AAAHSkAABAAAY6rAAM';

OE     1.8.1484   set transaction read write;

OE     1.8.1484   update "OE"."PRODUCT_INFORMATION"  update "OE"."PRODUCT_INFORMATION"
set "WARRANTY_PERIOD" =            set "WARRANTY_PERIOD" =
TO_YMINTERVAL('+12-06') where      TO_YMINTERVAL('+20-00') where
"PRODUCT_ID" = '2350' and          "PRODUCT_ID" = '2350' and
"WARRANTY_PERIOD" =                "WARRANTY_PERIOD" =
TO_YMINTERVAL('+20-00') and        TO_YMINTERVAL('+20-00') and
ROWID = 'AAAHTKAABAAAY9tAAD';       ROWID ='AAAHTKAABAAAY9tAAD';

HR     1.11.1476  commit;

5. LogMinerセッションを終了します。

SQL> EXECUTE DBMS_LOGMNR.END_LOGMNR();

例2: コミット済トランザクションへのDML文のグループ化

最初の例(例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索)で示したとおり、LogMinerのデフォルト動作では、トランザクションがコミット済であるかどうかに関係なく、分析するREDOログ・ファイルで検出されたすべての変更が表示されます。また、LogMinerでは、実行された順序で変更が表示されます。同じトランザクションに属するDML文がグループにまとめられていないため、出力を目視で簡単に確認することはできません。SQLを使用してトランザクションをグループ化することもできますが、LogMinerでは、より簡単な方法が提供されています。この例では、最後にアーカイブされたREDOログ・ファイルを再度分析しますが、コミット済トランザクションのみが返されます。

1. データベースによって最後にアーカイブされたREDOログ・ファイルを判別します。

SELECT NAME FROM V$ARCHIVED_LOG
WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG);

NAME
-------------------------------------------
/usr/oracle/data/db1arch_1_16_482701534.dbf

2. 手順1の問合せで返されたREDOログ・ファイルを指定します。このリストは、1つのREDOログ・ファイルで構成されます。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', -
OPTIONS => DBMS_LOGMNR.NEW);

3. 使用するディクショナリとCOMMITTED_DATA_ONLYオプションを指定して、LogMinerを起動します。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', -
OPTIONS => DBMS_LOGMNR.NEW);

4. V$LOGMNR_CONTENTSビューを問い合せます。
「例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索」に示したとおり、トランザクション1.11.1476は1.1.1484より前に開始されていますが、トランザクション1.1.1484の後にコミットされました。したがって、この例では、トランザクション1.1.1484は、その全体がトランザクション1.11.1476より前に示されます。分析中のREDOログ・ファイル内の、コミットされなかった2つのトランザクションは返されません。

SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' ||  XIDSQN) AS XID, SQL_REDO,
SQL_UNDO FROM V$LOGMNR_CONTENTS WHERE username IN ('HR', 'OE');
;
USR    XID          SQL_REDO                        SQL_UNDO
----   ---------    ------------------------------- ---------------------------------

OE     1.1.1484   set transaction read write;

OE     1.1.1484   update "OE"."PRODUCT_INFORMATION"  update "OE"."PRODUCT_INFORMATION"
set "WARRANTY_PERIOD" =            set "WARRANTY_PERIOD" =
TO_YMINTERVAL('+05-00') where      TO_YMINTERVAL('+01-00') where
"PRODUCT_ID" = '1799' and          "PRODUCT_ID" = '1799' and
"WARRANTY_PERIOD" =                "WARRANTY_PERIOD" =
TO_YMINTERVAL('+01-00') and        TO_YMINTERVAL('+05-00') and
ROWID = 'AAAHTKAABAAAY9mAAB';      ROWID = 'AAAHTKAABAAAY9mAAB';

OE     1.1.1484   update "OE"."PRODUCT_INFORMATION"  update "OE"."PRODUCT_INFORMATION"
set "WARRANTY_PERIOD" =            set "WARRANTY_PERIOD" =
TO_YMINTERVAL('+05-00') where      TO_YMINTERVAL('+01-00') where
"PRODUCT_ID" = '1801' and          "PRODUCT_ID" = '1801' and
"WARRANTY_PERIOD" =                "WARRANTY_PERIOD" =
TO_YMINTERVAL('+01-00') and        TO_YMINTERVAL('+05-00') and
ROWID = 'AAAHTKAABAAAY9mAAC';      ROWID ='AAAHTKAABAAAY9mAAC';

OE     1.1.1484   commit;

HR     1.11.1476  set transaction read write;

HR     1.11.1476  insert into "HR"."EMPLOYEES"(     delete from "HR"."EMPLOYEES"
"EMPLOYEE_ID","FIRST_NAME",       where "EMPLOYEE_ID" = '306'
"LAST_NAME","EMAIL",              and "FIRST_NAME" = 'Nandini'
"PHONE_NUMBER","HIRE_DATE",       and "LAST_NAME" = 'Shastry'
"JOB_ID","SALARY",                and "EMAIL" = 'NSHASTRY'
"COMMISSION_PCT","MANAGER_ID",    and "PHONE_NUMBER" = '1234567890'
"DEPARTMENT_ID") values           and "HIRE_DATE" = TO_DATE('10-JAN-2012
('306','Nandini','Shastry',       13:34:43', 'dd-mon-yyyy hh24:mi:ss')
'NSHASTRY', '1234567890',         and "JOB_ID" = 'HR_REP' and
TO_DATE('10-jan-2012 13:34:43',   "SALARY" = '120000' and
'dd-mon-yyy hh24:mi:ss'),         "COMMISSION_PCT" = '.05' and
'HR_REP','120000', '.05',         "DEPARTMENT_ID" = '10' and
'105','10');                      ROWID = 'AAAHSkAABAAAY6rAAO';

HR     1.11.1476  insert into "HR"."EMPLOYEES"(     delete from "HR"."EMPLOYEES"
"EMPLOYEE_ID","FIRST_NAME",       "EMPLOYEE_ID" = '307' and
"LAST_NAME","EMAIL",              "FIRST_NAME" = 'John' and
"PHONE_NUMBER","HIRE_DATE",       "LAST_NAME" = 'Silver' and
"JOB_ID","SALARY",                "EMAIL" = 'JSILVER' and
"COMMISSION_PCT","MANAGER_ID",    "PHONE_NUMBER" = '5551112222'
"DEPARTMENT_ID") values           and "HIRE_DATE" = TO_DATE('10-jan-2012
('307','John','Silver',           13:41:03', 'dd-mon-yyyy hh24:mi:ss')
'JSILVER', '5551112222',         and "JOB_ID" ='105' and "DEPARTMENT_ID"
TO_DATE('10-jan-2012 13:41:03',   = '50' and ROWID = 'AAAHSkAABAAAY6rAAP';
'dd-mon-yyyy hh24:mi:ss'),
'SH_CLERK','110000', '.05',
'105','50');

HR     1.11.1476  commit;

5. LogMinerセッションを終了します。

EXECUTE DBMS_LOGMNR.END_LOGMNR();

例3: 再構築されたSQLの書式設定

「例2: コミット済トランザクションへのDML文のグループ化」で示したとおり、オンラインREDOログ・ファイルのディクショナリでCOMMITTED_DATA_ONLYオプションを使用する方法は、コミット済トランザクションのみを対象とするための簡単な方法です。ただし、目視で簡単に確認はできません。INSERT文内の列名とそれに対応する値との間の関連が明白でないためです。PRINT_PRETTY_SQLオプションを指定することで、この問題に対処できます。このオプションを指定すると、再構築されたSQL文の一部が実行不可能になることに注意してください。

1. 最後にアーカイブされたREDOログ・ファイルを判別します。

SELECT NAME FROM V$ARCHIVED_LOG
WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG);

NAME
-------------------------------------------
/usr/oracle/data/db1arch_1_16_482701534.dbf

2. 手順1の問合せで返されたREDOログ・ファイルを指定します。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', -
OPTIONS => DBMS_LOGMNR.NEW);

3. 使用するディクショナリおよびCOMMITTED_DATA_ONLYオプションとPRINT_PRETTY_SQLオプションを指定して、LogMinerを起動します。

EXECUTE DBMS_LOGMNR.START_LOGMNR(-
OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -
DBMS_LOGMNR.COMMITTED_DATA_ONLY + -
DBMS_LOGMNR.PRINT_PRETTY_SQL);

DBMS_LOGMNR.PRINT_PRETTY_SQLオプションは、再構築されたSQLの書式のみを変更するため、目視用のレポートを生成する場合に有効です。

4. SQL_REDO文についてV$LOGMNR_CONTENTSビューに問い合せます。

SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' ||  XIDSQN) AS XID, SQL_REDO
FROM V$LOGMNR_CONTENTS;

USR    XID          SQL_REDO
----   ---------  -----------------------------------------------------

OE     1.1.1484   set transaction read write;

OE     1.1.1484   update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00')
where
"PRODUCT_ID" = '1799' and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and
ROWID = 'AAAHTKAABAAAY9mAAB';

OE     1.1.1484   update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00')
where
"PRODUCT_ID" = '1801' and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and
ROWID = 'AAAHTKAABAAAY9mAAC';

OE     1.1.1484   commit;

HR     1.11.1476  set transaction read write;

HR     1.11.1476  insert into "HR"."EMPLOYEES"
values
"EMPLOYEE_ID" = 306,
"FIRST_NAME" = 'Nandini',
"LAST_NAME" = 'Shastry',
"EMAIL" = 'NSHASTRY',
"PHONE_NUMBER" = '1234567890',
"HIRE_DATE" = TO_DATE('10-jan-2012 13:34:43',
'dd-mon-yyyy hh24:mi:ss',
"JOB_ID" = 'HR_REP',
"SALARY" = 120000,
"COMMISSION_PCT" = .05,
"MANAGER_ID" = 105,
"DEPARTMENT_ID" = 10;

HR     1.11.1476   insert into "HR"."EMPLOYEES"
values
"EMPLOYEE_ID" = 307,
"FIRST_NAME" = 'John',
"LAST_NAME" = 'Silver',
"EMAIL" = 'JSILVER',
"PHONE_NUMBER" = '5551112222',
"HIRE_DATE" = TO_DATE('10-jan-2012 13:41:03',
'dd-mon-yyyy hh24:mi:ss'),
"JOB_ID" = 'SH_CLERK',
"SALARY" = 110000,
"COMMISSION_PCT" = .05,
"MANAGER_ID" = 105,
"DEPARTMENT_ID" = 50;
HR     1.11.1476    commit;

5. 再構築されたSQL_UNDO文についてV$LOGMNR_CONTENTSビューに問い合せます。

SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' ||  XIDSQN) AS XID, SQL_UNDO
FROM V$LOGMNR_CONTENTS;

USR   XID        SQL_UNDO
----   ---------  -----------------------------------------------------

OE     1.1.1484   set transaction read write;

OE     1.1.1484   update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00')
where
"PRODUCT_ID" = '1799' and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and
ROWID = 'AAAHTKAABAAAY9mAAB';

OE     1.1.1484   update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00')
where
"PRODUCT_ID" = '1801' and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and
ROWID = 'AAAHTKAABAAAY9mAAC';

OE     1.1.1484   commit;

HR     1.11.1476  set transaction read write;

HR     1.11.1476  delete from "HR"."EMPLOYEES"
where
"EMPLOYEE_ID" = 306 and
"FIRST_NAME" = 'Nandini' and
"LAST_NAME" = 'Shastry' and
"EMAIL" = 'NSHASTRY' and
"PHONE_NUMBER" = '1234567890' and
"HIRE_DATE" = TO_DATE('10-jan-2012 13:34:43',
'dd-mon-yyyy hh24:mi:ss') and
"JOB_ID" = 'HR_REP' and
"SALARY" = 120000 and
"COMMISSION_PCT" = .05 and
"MANAGER_ID" = 105 and
"DEPARTMENT_ID" = 10 and
ROWID = 'AAAHSkAABAAAY6rAAO';

HR     1.11.1476   delete from "HR"."EMPLOYEES"
where
"EMPLOYEE_ID" = 307 and
"FIRST_NAME" = 'John' and
"LAST_NAME" = 'Silver' and
"EMAIL" = 'JSILVER' and
"PHONE_NUMBER" = '555122122' and
"HIRE_DATE" = TO_DATE('10-jan-2012 13:41:03',
'dd-mon-yyyy hh24:mi:ss') and
"JOB_ID" = 'SH_CLERK' and
"SALARY" = 110000 and
"COMMISSION_PCT" = .05 and
"MANAGER_ID" = 105 and
"DEPARTMENT_ID" = 50 and
ROWID = 'AAAHSkAABAAAY6rAAP';
HR     1.11.1476    commit;

6. LogMinerセッションを終了します。

EXECUTE DBMS_LOGMNR.END_LOGMNR();

例4: REDOログ・ファイル内のLogMinerディクショナリの使用

この例では、REDOログ・ファイルに抽出されたディクショナリを使用する方法を示します。オンライン・カタログ内のディクショナリを使用する場合は、オンライン・カタログを生成したデータベースと同じデータベース内のREDOログ・ファイルをマイニングする必要があります。REDOログ・ファイルに含まれているディクショナリを使用すると、別のデータベース内のREDOログ・ファイルをマイニングできます。

1. データベースによって最後にアーカイブされたREDOログ・ファイルを判別します。

SELECT NAME, SEQUENCE# FROM V$ARCHIVED_LOG
WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG);

NAME                                           SEQUENCE#
--------------------------------------------   --------------
/usr/oracle/data/db1arch_1_210_482701534.dbf   210

2. ディクショナリは、複数のREDOログ・ファイルに含まれている場合があります。したがって、ディクショナリの先頭と終わりが含まれているREDOログ・ファイルを判別する必要があります。次の手順を実行して、V$ARCHIVED_LOGビューを問い合せます。

a. ディクショナリ抽出の終わりが含まれているREDOログ・ファイルを検索します。このREDOログ・ファイルは、分析するREDOログ・ファイルより前に作成されている必要がありますが、できるかぎり新しいものを使用します。

SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end
FROM V$ARCHIVED_LOG
WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG
WHERE DICTIONARY_END = 'YES' and SEQUENCE# <= 210);

NAME                                           SEQUENCE#    D_BEG  D_END
--------------------------------------------   ----------   -----  ------
/usr/oracle/data/db1arch_1_208_482701534.dbf   208          NO     YES

b. データ・ディクショナリ抽出の先頭(前の手順で検出されたディクショナリの終わりに対応)が含まれているREDOログ・ファイルを検索します。

SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end
FROM V$ARCHIVED_LOG
WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG
WHERE DICTIONARY_BEGIN = 'YES' and SEQUENCE# <= 208);

NAME                                           SEQUENCE#    D_BEG  D_END
--------------------------------------------   ----------   -----  ------
/usr/oracle/data/db1arch_1_207_482701534.dbf   207          YES     NO

c. 分析するREDOログ・ファイルのリストを指定します。ディクショナリの先頭と終わりが含まれているREDOログ・ファイル、および分析するREDOログ・ファイルを追加します。REDOログ・ファイルは任意の順序で追加できます。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE(-
LOGFILENAME => '/usr/oracle/data/db1arch_1_210_482701534.dbf', -
OPTIONS => DBMS_LOGMNR.NEW);
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(-
LOGFILENAME => '/usr/oracle/data/db1arch_1_208_482701534.dbf');
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(-
LOGFILENAME => '/usr/oracle/data/db1arch_1_207_482701534.dbf');

d. V$LOGMNR_LOGSビューを問い合せて、分析するREDOログ・ファイルのリストをタイムスタンプとともに表示します。
出力では、LogMinerによって欠落しているREDOログ・ファイルに指摘フラグが付けられています。正常に機能するために欠落しているREDOログ・ファイルが必要なオプションを指定していない場合は、LogMinerでマイニングを続行できます。

3. 使用するディクショナリおよびCOMMITTED_DATA_ONLYオプションとPRINT_PRETTY_SQLオプションを指定して、LogMinerを起動します。

EXECUTE DBMS_LOGMNR.START_LOGMNR(-
OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOGS + -
DBMS_LOGMNR.COMMITTED_DATA_ONLY + -
DBMS_LOGMNR.PRINT_PRETTY_SQL);

4. V$LOGMNR_CONTENTSビューを問い合せます。
問合せによって返される行数を減らすには、SYSスキーマまたはSYSTEMスキーマで実行されたすべてのDML文を問合せから除外します。(この問合せでは、ディクショナリ抽出に関連したトランザクションを除外するタイムスタンプを指定します。)

出力には3つのトランザクションが表示されます。2つのDDLトランザクションと1つのDMLトランザクションです。DDLトランザクション1.2.1594は表oe.product_trackingを作成し、1.18.1602は表oe.product_informationでトリガーを作成します。いずれのトランザクションでも、システム表(SYSによって所有される表)に対して実行されたDML文は、問合せ条件に基づいてフィルタ処理で除外されます。

DMLトランザクション1.9.1598は、oe.product_information表を更新します。このトランザクションの更新操作は完全に変換されます。ただし、問合せの出力には、変換されない再構築されたSQL文も含まれます。これらの文は、データ・ディクショナリがREDOログ・ファイルに抽出された後で作成されたoe.product_tracking表で実行された可能性があります。

(次に示す例は、すべてのSQL文が完全に変換されるように、DDL_DICT_TRACKINGを使用したLogMinerの実行例です。バイナリ・データは返されていません。)

SELECT USERNAME AS usr, SQL_REDO FROM V$LOGMNR_CONTENTS
WHERE SEG_OWNER IS NULL OR SEG_OWNER NOT IN ('SYS', 'SYSTEM') AND
TIMESTAMP > '10-jan-2012 15:59:53';

USR             XID         SQL_REDO
---             --------    -----------------------------------
SYS             1.2.1594    set transaction read write;
SYS             1.2.1594    create table oe.product_tracking (product_id number not null,
modified_time date,
old_list_price number(8,2),
old_warranty_period interval year(2) to month);
SYS             1.2.1594    commit;

SYS             1.18.1602   set transaction read write;
SYS             1.18.1602   create or replace trigger oe.product_tracking_trigger
before update on oe.product_information
for each row
when (new.list_price <> old.list_price or
new.warranty_period <> old.warranty_period)
declare
begin
insert into oe.product_tracking values
(:old.product_id, sysdate,
:old.list_price, :old.warranty_period);
end;
SYS             1.18.1602   commit;

OE              1.9.1598    update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'),
"LIST_PRICE" = 100
where
"PRODUCT_ID" = 1729 and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and
"LIST_PRICE" = 80 and
ROWID = 'AAAHTKAABAAAY9yAAA';

OE              1.9.1598    insert into "UNKNOWN"."OBJ# 33415"
values
"COL 1" = HEXTORAW('c2121e'),
"COL 2" = HEXTORAW('7867010d110804'),
"COL 3" = HEXTORAW('c151'),
"COL 4" = HEXTORAW('800000053c');

OE              1.9.1598    update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'),
"LIST_PRICE" = 92
where
"PRODUCT_ID" = 2340 and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and
"LIST_PRICE" = 72 and
ROWID = 'AAAHTKAABAAAY9zAAA';

OE              1.9.1598    insert into "UNKNOWN"."OBJ# 33415"
values
"COL 1" = HEXTORAW('c21829'),
"COL 2" = HEXTORAW('7867010d110808'),
"COL 3" = HEXTORAW('c149'),
"COL 4" = HEXTORAW('800000053c');

OE              1.9.1598     commit;

5. 必要に応じて、追加の問合せを発行します。
CREATE TABLE DDL文の一部として実行されたすべてのDML文を表示します。この中には、ユーザーによって実行された文、Oracleによって内部的に実行された文などが含まれます。

注意:

ここで示すような問合せによって、表示された文を再適用する場合は、DDL文のみを再適用します。Oracleによって内部的に実行されたDML文は再適用しないでください。データベースを破損する危険性があります。次の出力では、再適用操作で使用する文はCREATE TABLE OE.PRODUCT_TRACKING文のみです。

SELECT SQL_REDO FROM V$LOGMNR_CONTENTS
WHERE XIDUSN  = 1 and XIDSLT = 2 and XIDSQN = 1594;

SQL_REDO
--------------------------------------------------------------------------------
set transaction read write;

insert into "SYS"."OBJ$"
values
"OBJ#" = 33415,
"DATAOBJ#" = 33415,
"OWNER#" = 37,
"NAME" = 'PRODUCT_TRACKING',
"NAMESPACE" = 1,
"SUBNAME" IS NULL,
"TYPE#" = 2,
"CTIME" = TO_DATE('13-jan-2012 14:01:03', 'dd-mon-yyyy hh24:mi:ss'),
"MTIME" = TO_DATE('13-jan-2012 14:01:03', 'dd-mon-yyyy hh24:mi:ss'),
"STIME" = TO_DATE('13-jan-2012 14:01:03', 'dd-mon-yyyy hh24:mi:ss'),
"STATUS" = 1,
"REMOTEOWNER" IS NULL,
"LINKNAME" IS NULL,
"FLAGS" = 0,
"OID$" IS NULL,
"SPARE1" = 6,
"SPARE2" = 1,
"SPARE3" IS NULL,
"SPARE4" IS NULL,
"SPARE5" IS NULL,
"SPARE6" IS NULL;

insert into "SYS"."TAB$"
values
"OBJ#" = 33415,
"DATAOBJ#" = 33415,
"TS#" = 0,
"FILE#" = 1,
"BLOCK#" = 121034,
"BOBJ#" IS NULL,
"TAB#" IS NULL,
"COLS" = 5,
"CLUCOLS" IS NULL,
"PCTFREE$" = 10,
"PCTUSED$" = 40,
"INITRANS" = 1,
"MAXTRANS" = 255,
"FLAGS" = 1,
"AUDIT$" = '--------------------------------------',
"ROWCNT" IS NULL,
"BLKCNT" IS NULL,
"EMPCNT" IS NULL,
"AVGSPC" IS NULL,
"CHNCNT" IS NULL,
"AVGRLN" IS NULL,
"AVGSPC_FLB" IS NULL,
"FLBCNT" IS NULL,
"ANALYZETIME" IS NULL,
"SAMPLESIZE" IS NULL,
"DEGREE" IS NULL,
"INSTANCES" IS NULL,
"INTCOLS" = 5,
"KERNELCOLS" = 5,
"PROPERTY" = 536870912,
"TRIGFLAG" = 0,
"SPARE1" = 178,
"SPARE2" IS NULL,
"SPARE3" IS NULL,
"SPARE4" IS NULL,
"SPARE5" IS NULL,
"SPARE6" = TO_DATE('13-jan-2012 14:01:05', 'dd-mon-yyyy hh24:mi:ss'),

insert into "SYS"."COL$"
values
"OBJ#" = 33415,
"COL#" = 1,
"SEGCOL#" = 1,
"SEGCOLLENGTH" = 22,
"OFFSET" = 0,
"NAME" = 'PRODUCT_ID',
"TYPE#" = 2,
"LENGTH" = 22,
"FIXEDSTORAGE" = 0,
"PRECISION#" IS NULL,
"SCALE" IS NULL,
"NULL$" = 1,
"DEFLENGTH" IS NULL,
"SPARE6" IS NULL,
"INTCOL#" = 1,
"PROPERTY" = 0,
"CHARSETID" = 0,
"CHARSETFORM" = 0,
"SPARE1" = 0,
"SPARE2" = 0,
"SPARE3" = 0,
"SPARE4" IS NULL,
"SPARE5" IS NULL,
"DEFAULT$" IS NULL;

insert into "SYS"."COL$"
values
"OBJ#" = 33415,
"COL#" = 2,
"SEGCOL#" = 2,
"SEGCOLLENGTH" = 7,
"OFFSET" = 0,
"NAME" = 'MODIFIED_TIME',
"TYPE#" = 12,
"LENGTH" = 7,
"FIXEDSTORAGE" = 0,
"PRECISION#" IS NULL,
"SCALE" IS NULL,
"NULL$" = 0,
"DEFLENGTH" IS NULL,
"SPARE6" IS NULL,
"INTCOL#" = 2,
"PROPERTY" = 0,
"CHARSETID" = 0,
"CHARSETFORM" = 0,
"SPARE1" = 0,
"SPARE2" = 0,
"SPARE3" = 0,
"SPARE4" IS NULL,
"SPARE5" IS NULL,
"DEFAULT$" IS NULL;

insert into "SYS"."COL$"
values
"OBJ#" = 33415,
"COL#" = 3,
"SEGCOL#" = 3,
"SEGCOLLENGTH" = 22,
"OFFSET" = 0,
"NAME" = 'OLD_LIST_PRICE',
"TYPE#" = 2,
"LENGTH" = 22,
"FIXEDSTORAGE" = 0,
"PRECISION#" = 8,
"SCALE" = 2,
"NULL$" = 0,
"DEFLENGTH" IS NULL,
"SPARE6" IS NULL,
"INTCOL#" = 3,
"PROPERTY" = 0,
"CHARSETID" = 0,
"CHARSETFORM" = 0,
"SPARE1" = 0,
"SPARE2" = 0,
"SPARE3" = 0,
"SPARE4" IS NULL,
"SPARE5" IS NULL,
"DEFAULT$" IS NULL;

insert into "SYS"."COL$"
values
"OBJ#" = 33415,
"COL#" = 4,
"SEGCOL#" = 4,
"SEGCOLLENGTH" = 5,
"OFFSET" = 0,
"NAME" = 'OLD_WARRANTY_PERIOD',
"TYPE#" = 182,
"LENGTH" = 5,
"FIXEDSTORAGE" = 0,
"PRECISION#" = 2,
"SCALE" = 0,
"NULL$" = 0,
"DEFLENGTH" IS NULL,
"SPARE6" IS NULL,
"INTCOL#" = 4,
"PROPERTY" = 0,
"CHARSETID" = 0,
"CHARSETFORM" = 0,
"SPARE1" = 0,
"SPARE2" = 2,
"SPARE3" = 0,
"SPARE4" IS NULL,
"SPARE5" IS NULL,
"DEFAULT$" IS NULL;

insert into "SYS"."CCOL$"
values
"OBJ#" = 33415,
"CON#" = 2090,
"COL#" = 1,
"POS#" IS NULL,
"INTCOL#" = 1,
"SPARE1" = 0,
"SPARE2" IS NULL,
"SPARE3" IS NULL,
"SPARE4" IS NULL,
"SPARE5" IS NULL,
"SPARE6" IS NULL;

insert into "SYS"."CDEF$"
values
"OBJ#" = 33415,
"CON#" = 2090,
"COLS" = 1,
"TYPE#" = 7,
"ROBJ#" IS NULL,
"RCON#" IS NULL,
"RRULES" IS NULL,
"MATCH#" IS NULL,
"REFACT" IS NULL,
"ENABLED" = 1,
"CONDLENGTH" = 24,
"SPARE6" IS NULL,
"INTCOLS" = 1,
"MTIME" = TO_DATE('13-jan-2012 14:01:08', 'dd-mon-yyyy hh24:mi:ss'),
"DEFER" = 12,
"SPARE1" = 6,
"SPARE2" IS NULL,
"SPARE3" IS NULL,
"SPARE4" IS NULL,
"SPARE5" IS NULL,
"CONDITION" = '"PRODUCT_ID" IS NOT NULL';

create table oe.product_tracking (product_id number not null,
modified_time date,
old_product_description varchar2(2000),
old_list_price number(8,2),
old_warranty_period interval year(2) to month);

update "SYS"."SEG$"
set
"TYPE#" = 5,
"BLOCKS" = 5,
"EXTENTS" = 1,
"INIEXTS" = 5,
"MINEXTS" = 1,
"MAXEXTS" = 121,
"EXTSIZE" = 5,
"EXTPCT" = 50,
"USER#" = 37,
"LISTS" = 0,
"GROUPS" = 0,
"CACHEHINT" = 0,
"HWMINCR" = 33415,
"SPARE1" = 1024
where
"TS#" = 0 and
"FILE#" = 1 and
"BLOCK#" = 121034 and
"TYPE#" = 3 and
"BLOCKS" = 5 and
"EXTENTS" = 1 and
"INIEXTS" = 5 and
"MINEXTS" = 1 and
"MAXEXTS" = 121 and
"EXTSIZE" = 5 and
"EXTPCT" = 50 and
"USER#" = 37 and
"LISTS" = 0 and
"GROUPS" = 0 and
"BITMAPRANGES" = 0 and
"CACHEHINT" = 0 and
"SCANHINT" = 0 and
"HWMINCR" = 33415 and
"SPARE1" = 1024 and
"SPARE2" IS NULL and
ROWID = 'AAAAAIAABAAAdMOAAB';

insert into "SYS"."CON$"
values
"OWNER#" = 37,
"NAME" = 'SYS_C002090',
"CON#" = 2090,
"SPARE1" IS NULL,
"SPARE2" IS NULL,
"SPARE3" IS NULL,
"SPARE4" IS NULL,
"SPARE5" IS NULL,
"SPARE6" IS NULL;

commit;

6. LogMinerセッションを終了します。

EXECUTE DBMS_LOGMNR.END_LOGMNR();

例5: 内部ディクショナリでのDDL文の追跡

この例では、DBMS_LOGMNR.DDL_DICT_TRACKINGオプションを使用して、REDOログ・ファイル内で検出されたDDL文でLogMiner内部ディクショナリを更新する方法を示します。

1. データベースによって最後にアーカイブされたREDOログ・ファイルを判別します。

SELECT NAME, SEQUENCE# FROM V$ARCHIVED_LOG
WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG);

NAME                                           SEQUENCE#
--------------------------------------------   --------------
/usr/oracle/data/db1arch_1_210_482701534.dbf   210

2. ディクショナリは複数のREDOログ・ファイルに含まれている場合があるため、データ・ディクショナリの先頭と終わりが含まれているREDOログ・ファイルを判別する必要があります。次の手順を実行して、V$ARCHIVED_LOGビューを問い合せます。

a. データ・ディクショナリ抽出の終わりが含まれているREDOログを検索します。このREDOログ・ファイルは、分析するREDOログ・ファイルより前に作成されている必要がありますが、できるかぎり新しいものを使用します。

SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end
FROM V$ARCHIVED_LOG
WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG
WHERE DICTIONARY_END = 'YES' and SEQUENCE# < 210);

NAME                                           SEQUENCE#    D_BEG  D_END
--------------------------------------------   ----------   -----  ------
/usr/oracle/data/db1arch_1_208_482701534.dbf   208          NO     YES

b. データ・ディクショナリ抽出の先頭(前のSQL文で検出されたディクショナリの終わりに対応)が含まれている、REDOログ・ファイルを検索します。

SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end
FROM V$ARCHIVED_LOG
WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG
WHERE DICTIONARY_BEGIN = 'YES' and SEQUENCE# <= 208);

NAME                                           SEQUENCE#    D_BEG  D_END
--------------------------------------------   ----------   -----  ------
/usr/oracle/data/db1arch_1_208_482701534.dbf   207          YES     NO

3. REDOログ・ファイルの完全なリストがあることを確認します。
REDOログ・ファイルで検出されたDDL文を正しく適用するために、マイニングするREDOログ・ファイルのリストにすべてのファイルが含まれていることを確認します。順序番号209に対応する欠落ログ・ファイルが、このリストに含まれている必要があります。次の問合せを発行して、リストに追加する必要があるREDOログ・ファイルの名前を判別します。

SELECT NAME FROM V$ARCHIVED_LOG
WHERE SEQUENCE# >= 207 AND SEQUENCE# <= 210
ORDER BY SEQUENCE# ASC;

NAME
--------------------------------------------
/usr/oracle/data/db1arch_1_207_482701534.dbf
/usr/oracle/data/db1arch_1_208_482701534.dbf
/usr/oracle/data/db1arch_1_209_482701534.dbf
/usr/oracle/data/db1arch_1_210_482701534.dbf

4. 分析するREDOログ・ファイルのリストを指定します。
ディクショナリの先頭と終わりが含まれているREDOログ・ファイル、マイニングするREDOログ・ファイル、および差異のないリストを作成するために必要なすべてのREDOログ・ファイルを含めます。REDOログ・ファイルは任意の順序で追加できます。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE(-
LOGFILENAME => '/usr/oracle/data/db1arch_1_210_482701534.dbf', -

OPTIONS => DBMS_LOGMNR.NEW);

EXECUTE DBMS_LOGMNR.ADD_LOGFILE(-
LOGFILENAME => '/usr/oracle/data/db1arch_1_209_482701534.dbf');
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(-
LOGFILENAME => '/usr/oracle/data/db1arch_1_208_482701534.dbf');
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(-
LOGFILENAME => '/usr/oracle/data/db1arch_1_207_482701534.dbf');

5. 使用するディクショナリおよびDDL_DICT_TRACKING、COMMITTED_DATA_ONLY、PRINT_PRETTY_SQLの各オプションを指定して、LogMinerを起動します。

EXECUTE DBMS_LOGMNR.START_LOGMNR(-
OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOGS + -
DBMS_LOGMNR.DDL_DICT_TRACKING + -
DBMS_LOGMNR.COMMITTED_DATA_ONLY + -
DBMS_LOGMNR.PRINT_PRETTY_SQL);

6. V$LOGMNR_CONTENTSビューを問い合せます。
返される行数を減らすため、SYSスキーマまたはSYSTEMスキーマで実行されたすべてのDML文を問合せから除外します。(この問合せでは、ディクショナリ抽出に関連したトランザクションを除外するタイムスタンプを指定します。)

この問合せは、正常に変換されたすべての再構築SQL文、およびトリガーを実行したためoe.product_tracking表に対して実行されたすべての挿入操作を返します。

SELECT USERNAME AS usr,(XIDUSN || '.' || XIDSLT || '.' || XIDSQN) as XID, SQL_REDO FROM
V$LOGMNR_CONTENTS
WHERE SEG_OWNER IS NULL OR SEG_OWNER NOT IN ('SYS', 'SYSTEM') AND
TIMESTAMP > '10-jan-2012 15:59:53';

USR             XID         SQL_REDO
-----------     --------    -----------------------------------
SYS             1.2.1594    set transaction read write;
SYS             1.2.1594    create table oe.product_tracking (product_id number not null,
modified_time date,
old_list_price number(8,2),
old_warranty_period interval year(2) to month);
SYS             1.2.1594    commit;

SYS             1.18.1602   set transaction read write;
SYS             1.18.1602   create or replace trigger oe.product_tracking_trigger
before update on oe.product_information
for each row
when (new.list_price <> old.list_price or
new.warranty_period <> old.warranty_period)
declare
begin
insert into oe.product_tracking values
(:old.product_id, sysdate,
:old.list_price, :old.warranty_period);
end;
SYS             1.18.1602   commit;

OE              1.9.1598    update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'),
"LIST_PRICE" = 100
where
"PRODUCT_ID" = 1729 and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and
"LIST_PRICE" = 80 and
ROWID = 'AAAHTKAABAAAY9yAAA';
OE              1.9.1598    insert into "OE"."PRODUCT_TRACKING"
values
"PRODUCT_ID" = 1729,
"MODIFIED_TIME" = TO_DATE('13-jan-2012 16:07:03',
'dd-mon-yyyy hh24:mi:ss'),
"OLD_LIST_PRICE" = 80,
"OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00');

OE              1.9.1598    update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'),
"LIST_PRICE" = 92
where
"PRODUCT_ID" = 2340 and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and
"LIST_PRICE" = 72 and
ROWID = 'AAAHTKAABAAAY9zAAA';

OE              1.9.1598    insert into "OE"."PRODUCT_TRACKING"
values
"PRODUCT_ID" = 2340,
"MODIFIED_TIME" = TO_DATE('13-jan-2012 16:07:07',
'dd-mon-yyyy hh24:mi:ss'),
"OLD_LIST_PRICE" = 72,
"OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00');

OE              1.9.1598     commit;

7. LogMinerセッションを終了します。

EXECUTE DBMS_LOGMNR.END_LOGMNR();

例6: 時間範囲による出力のフィルタ処理

前の2つの例では、問合せにタイムスタンプ・ベースの条件(TIMESTAMP > '10-jan-2012 15:59:53')を指定して、行をフィルタ処理しました。ただし、タイムスタンプ値に基づいてREDOレコードを除外するには、この例で示すとおり、DBMS_LOGMNR.START_LOGMNRプロシージャ・コールで時間範囲を指定する方法がより効率的です。

1. マイニングするREDOログ・ファイルのリストを作成します。
指定した時刻以降に生成されたREDOログ・ファイルをマイニングするとします。次のプロシージャは、指定した時刻に基づいてREDOログ・ファイルのリストを作成します。その後のSQL EXECUTE文は、プロシージャをコールし、開始時刻を2012年1月13日の午後2時に指定します。

--
-- my_add_logfiles
-- Add all archived logs generated after a specified start_time.
--
CREATE OR REPLACE PROCEDURE my_add_logfiles (in_start_time  IN DATE) AS
CURSOR  c_log IS
SELECT NAME FROM V$ARCHIVED_LOG
WHERE FIRST_TIME >= in_start_time;

count      pls_integer := 0;
my_option  pls_integer := DBMS_LOGMNR.NEW;

BEGIN
FOR c_log_rec IN c_log
LOOP
DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => c_log_rec.name,
OPTIONS => my_option);
my_option := DBMS_LOGMNR.ADDFILE;
DBMS_OUTPUT.PUT_LINE('Added logfile ' || c_log_rec.name);
END LOOP;
END;
/

EXECUTE my_add_logfiles(in_start_time => '13-jan-2012 14:00:00');

2. V$LOGMNR_LOGSを問い合せて、REDOログ・ファイルのリストを確認します。
この例では、出力にREDOログ・ファイルのサイズを含めます。

SELECT FILENAME name, LOW_TIME start_time, FILESIZE bytes
FROM V$LOGMNR_LOGS;

NAME                                START_TIME            BYTES
----------------------------------- --------------------  ----------------
/usr/orcl/arch1_310_482932022.dbf    13-jan-2012 14:02:35  23683584
/usr/orcl/arch1_311_482932022.dbf    13-jan-2012 14:56:35  2564096
/usr/orcl/arch1_312_482932022.dbf    13-jan-2012 15:10:43  23683584
/usr/orcl/arch1_313_482932022.dbf    13-jan-2012 15:17:52  23683584
/usr/orcl/arch1_314_482932022.dbf    13-jan-2012 15:23:10  23683584
/usr/orcl/arch1_315_482932022.dbf    13-jan-2012 15:43:22  23683584
/usr/orcl/arch1_316_482932022.dbf    13-jan-2012 16:03:10  23683584
/usr/orcl/arch1_317_482932022.dbf    13-jan-2012 16:33:43  23683584
/usr/orcl/arch1_318_482932022.dbf    13-jan-2012 17:23:10  23683584

3. REDOログ・ファイルのリストを調整します。
午後3時から4時の間に生成されたREDOログ・ファイルのみをマイニングする必要があるとします。

問合せ条件(timestamp > '13-jan-2012 15:00:00' and timestamp < '13-jan-2012 16:00:00')を使用してこれを行います。ただし、問合せ条件はLogMinerによって返される各行で評価されるため、問合せ条件に基づく行のフィルタ処理は、内部マイニング・エンジンでは行われません。したがって、REDOログ・ファイルarch1_311_482932022.dbfからarch1_315_482932022.dbfまでの行のみを取得する場合でも、この問合せでは、LogMinerセッションに登録されたすべてのREDOログ・ファイルがマイニングされます。

また、問合せ条件を使用し、分析する時間範囲外のREDOログ・ファイルを手動で削除することもできますが、最も簡単な解決法は、DBMS_LOGMNR.START_LOGMNRプロシージャ・コールで分析する時間範囲を指定する方法です。

この方法では、REDOログ・ファイルのリストは変更されませんが、指定した時間範囲内のREDOログ・ファイルのみがLogMinerによってマイニングされます。

EXECUTE DBMS_LOGMNR.START_LOGMNR(-
STARTTIME => '13-jan-2012 15:00:00', -
ENDTIME   => '13-jan-2012 16:00:00', -
OPTIONS   => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -
DBMS_LOGMNR.COMMITTED_DATA_ONLY + -
DBMS_LOGMNR.PRINT_PRETTY_SQL);

4. V$LOGMNR_CONTENTSビューを問い合せます。

SELECT TIMESTAMP, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID,

SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER = 'OE';

TIMESTAMP              XID          SQL_REDO
---------------------  -----------  --------------------------------
13-jan-2012 15:29:31   1.17.2376    update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00')
where
"PRODUCT_ID" = 3399 and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00') and
ROWID = 'AAAHTKAABAAAY9TAAE';
13-jan-2012 15:29:34   1.17.2376      insert into "OE"."PRODUCT_TRACKING"
values
"PRODUCT_ID" = 3399,
"MODIFIED_TIME" = TO_DATE('13-jan-2012 15:29:34',
'dd-mon-yyyy hh24:mi:ss'),
"OLD_LIST_PRICE" = 815,
"OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00');

13-jan-2012 15:52:43   1.15.1756      update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00')
where
"PRODUCT_ID" = 1768 and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00') and
ROWID = 'AAAHTKAABAAAY9UAAB';

13-jan-2012 15:52:43   1.15.1756      insert into "OE"."PRODUCT_TRACKING"
values
"PRODUCT_ID" = 1768,
"MODIFIED_TIME" = TO_DATE('13-jan-2012 16:52:43',
'dd-mon-yyyy hh24:mi:ss'),
"OLD_LIST_PRICE" = 715,
"OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00');

5. LogMinerセッションを終了します。

EXECUTE DBMS_LOGMNR.END_LOGMNR();

REDOログ・ファイルのリストを明示的に指定しないマイニングの例

前述の例では、マイニングするREDOログ・ファイルを明示的に指定しました。この例では、REDOログ・ファイルを生成したデータベースと同じデータベースでマイニングする場合、分析する時間(またはSCN)範囲を指定するのみで適切なREDOログ・ファイルのリストをマイニングできる方法を示します。REDOログ・ファイルを明示的に指定せずにマイニングするには、DBMS_LOGMNR.START_LOGMNRプロシージャに対してDBMS_LOGMNR.CONTINUOUS_MINEオプションを使用し、分析する時間範囲またはSCN範囲のいずれかを指定します。

この項は、次の例で構成されています。それぞれの例は、前の例に基づいて作成されているため、順番に読み進むことをお薦めします。

- 例1: 指定した時間範囲でのREDOログ・ファイルのマイニング

- 例2: 指定したSCN範囲でのREDOログ・ファイルのマイニング

- 例3: 問合せに将来の値を含めるCONTINUOUS_MINEオプションの使用

SQL出力の画面上の書式設定は、この項で示す例とは異なる場合があります。

例1: 指定した時間範囲でのREDOログ・ファイルのマイニング

この例は、「例4: REDOログ・ファイル内のLogMinerディクショナリの使用」と同様ですが、REDOログ・ファイルを明示的に指定しない点が異なります。この例では、REDOログ・ファイルに対して抽出されたデータ・ディクショナリを使用するものとします。

1. データ・ディクショナリの先頭を含むREDOログ・ファイルのタイムスタンプを判別します。

SELECT NAME, FIRST_TIME FROM V$ARCHIVED_LOG

WHERE SEQUENCE# = (SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG
WHERE DICTIONARY_BEGIN = 'YES');

NAME                                          FIRST_TIME
--------------------------------------------  --------------------
/usr/oracle/data/db1arch_1_207_482701534.dbf  10-jan-2012 12:01:34

2. その時点までに生成されたすべてのREDOログ・ファイルを表示します。
この手順は必須ではありませんが、手順4に示すとおり、CONTINUOUS_MINEオプションが予期したとおりに機能することを示すために含めています。

SELECT FILENAME name FROM V$LOGMNR_LOGS
WHERE LOW_TIME > '10-jan-2012 12:01:34';

NAME
----------------------------------------------
/usr/oracle/data/db1arch_1_207_482701534.dbf
/usr/oracle/data/db1arch_1_208_482701534.dbf
/usr/oracle/data/db1arch_1_209_482701534.dbf
/usr/oracle/data/db1arch_1_210_482701534.dbf

3. 使用するディクショナリおよびCOMMITTED_DATA_ONLY、PRINT_PRETTY_SQL、CONTINUOUS_MINEの各オプションを指定して、LogMinerを起動します。

EXECUTE DBMS_LOGMNR.START_LOGMNR(-
STARTTIME => '10-jan-2012 12:01:34', -
ENDTIME => SYSDATE, -
OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOGS + -
DBMS_LOGMNR.COMMITTED_DATA_ONLY + -
DBMS_LOGMNR.PRINT_PRETTY_SQL + -
DBMS_LOGMNR.CONTINUOUS_MINE);

4. V$LOGMNR_LOGSビューを問い合せます。
この手順は、予期したとおりCONTINUOUS_MINEオプションを指定したDBMS_LOGMNR.START_LOGMNRプロシージャに、この時点までに生成されたすべてのREDOログ・ファイルが含まれることを示します。(この手順の出力を手順2の出力と比較してください。)

SELECT FILENAME name FROM V$LOGMNR_LOGS;

NAME
------------------------------------------------------
/usr/oracle/data/db1arch_1_207_482701534.dbf
/usr/oracle/data/db1arch_1_208_482701534.dbf
/usr/oracle/data/db1arch_1_209_482701534.dbf
/usr/oracle/data/db1arch_1_210_482701534.dbf

5. V$LOGMNR_CONTENTSビューを問い合せます。
問合せによって返される行数を減らすため、SYSスキーマまたはSYSTEMスキーマで実行されたすべてのDML文を除外します。(この問合せでは、ディクショナリ抽出に関連したトランザクションを除外するタイムスタンプを指定します。)

問合せで返される再構築SQL文は、すべて正しく変換されていることに注意してください。

SELECT USERNAME AS usr,(XIDUSN || '.' || XIDSLT || '.' || XIDSQN) as XID,
SQL_REDO FROM V$LOGMNR_CONTENTS
WHERE SEG_OWNER IS NULL OR SEG_OWNER NOT IN ('SYS', 'SYSTEM') AND
TIMESTAMP > '10-jan-2012 15:59:53';

USR             XID         SQL_REDO
-----------     --------    -----------------------------------
SYS             1.2.1594    set transaction read write;
SYS             1.2.1594    create table oe.product_tracking (product_id number not null,
modified_time date,
old_list_price number(8,2),
old_warranty_period interval year(2) to month);
SYS             1.2.1594    commit;

SYS             1.18.1602   set transaction read write;
SYS             1.18.1602   create or replace trigger oe.product_tracking_trigger
before update on oe.product_information
for each row
when (new.list_price <> old.list_price or
new.warranty_period <> old.warranty_period)
declare
begin
insert into oe.product_tracking values
(:old.product_id, sysdate,
:old.list_price, :old.warranty_period);
end;
SYS             1.18.1602   commit;

OE              1.9.1598    update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'),
"LIST_PRICE" = 100
where
"PRODUCT_ID" = 1729 and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and
"LIST_PRICE" = 80 and
ROWID = 'AAAHTKAABAAAY9yAAA';
OE              1.9.1598    insert into "OE"."PRODUCT_TRACKING"
values
"PRODUCT_ID" = 1729,
"MODIFIED_TIME" = TO_DATE('13-jan-2012 16:07:03',
'dd-mon-yyyy hh24:mi:ss'),
"OLD_LIST_PRICE" = 80,
"OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00');

OE              1.9.1598    update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'),
"LIST_PRICE" = 92
where
"PRODUCT_ID" = 2340 and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and
"LIST_PRICE" = 72 and
ROWID = 'AAAHTKAABAAAY9zAAA';

OE              1.9.1598    insert into "OE"."PRODUCT_TRACKING"
values
"PRODUCT_ID" = 2340,
"MODIFIED_TIME" = TO_DATE('13-jan-2012 16:07:07',
'dd-mon-yyyy hh24:mi:ss'),
"OLD_LIST_PRICE" = 72,
"OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00');

OE              1.9.1598     commit;

6. LogMinerセッションを終了します。

EXECUTE DBMS_LOGMNR.END_LOGMNR();

例2: 指定したSCN範囲でのREDOログ・ファイルのマイニング

この例では、分析するSCN範囲を指定する方法、およびその範囲を満たすREDOログ・ファイルをマイニングする方法を示します。LogMinerを使用して、データ・ファイルで影響がまだ永続的になっていないすべてのコミット済DML文を表示できます。

この例では(他の例と異なり)、NLS_DATE_FORMATパラメータを設定していないことに注意してください。

1. 最後のチェックポイントが実行されたSCNを判別します。

SELECT CHECKPOINT_CHANGE#, CURRENT_SCN FROM V$DATABASE;

CHECKPOINT_CHANGE#  CURRENT_SCN
------------------  ---------------
56453576         56454208

2. LogMinerを起動し、CONTINUOUS_MINEオプションを指定します。

EXECUTE DBMS_LOGMNR.START_LOGMNR(-

STARTSCN => 56453576, -
ENDSCN   => 56454208, -
OPTIONS  => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -
DBMS_LOGMNR.COMMITTED_DATA_ONLY + -
DBMS_LOGMNR.PRINT_PRETTY_SQL + -
DBMS_LOGMNR.CONTINUOUS_MINE);

3. LogMinerによって追加されたアーカイブ済REDOログ・ファイルのリストを表示します。

SELECT FILENAME name, LOW_SCN, NEXT_SCN FROM V$LOGMNR_LOGS;

NAME                                           LOW_SCN   NEXT_SCN
--------------------------------------------   --------  --------
/usr/oracle/data/db1arch_1_215_482701534.dbf   56316771  56453579

LogMinerによって追加されたREDOログ・ファイルには、SCN範囲全体が含まれないことに注意してください。CONTINUOUS_MINEオプションを指定した場合にDBMS_LOGMNR.START_LOGMNRプロシージャをコールすると、アーカイブ済REDOログ・ファイルのみがLogMinerによって追加されます。LogMinerは、問合せ実行中必要に応じて、オンラインREDOログ・ファイルに含まれている残りのSCN範囲を自動的に追加します。追加されたREDOログ・ファイルが生成された最新のアーカイブ済REDOログ・ファイルであるかどうかを確認するには、次の問合せを使用します。

SELECT NAME FROM V$ARCHIVED_LOG
WHERE SEQUENCE# = (SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG);

NAME
--------------------------------------------
/usr/oracle/data/db1arch_1_215_482701534.dbf

4. ユーザー表に対して行われた変更についてV$LOGMNR_CONTENTSビューに問い合せます。
次の問合せは、トランザクション1.6.1911と関連付けられたSET TRANSACTION READ WRITE文およびCOMMIT文は返しません。これらの文には、セグメント所有者(SEG_OWNER)が関連付けられていないためです。

デフォルトのNLS_DATE_FORMATであるDD-MON-RRが、DATE型のMODIFIED_TIME列の表示に使用されていることに注意してください。

SELECT SCN, (XIDUSN || '.' || XIDSLT || '.' ||  XIDSQN) as XID, SQL_REDO
FROM V$LOGMNR_CONTENTS
WHERE SEG_OWNER NOT IN ('SYS', 'SYSTEM');

SCN        XID        SQL_REDO
---------- ---------- -------------
56454198   1.6.1911   update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00')
where
"PRODUCT_ID" = 2430 and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00') and
ROWID = 'AAAHTKAABAAAY9AAAC';

56454199   1.6.1911   insert into "OE"."PRODUCT_TRACKING"
values
"PRODUCT_ID" = 2430,
"MODIFIED_TIME" = TO_DATE('17-JAN-03', 'DD-MON-RR'),
"OLD_LIST_PRICE" = 175,
"OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00');

56454204   1.6.1911    update "OE"."PRODUCT_INFORMATION"
set
"WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00')
where
"PRODUCT_ID" = 2302 and
"WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00') and
ROWID = 'AAAHTKAABAAAY9QAAA';
56454206   1.6.1911    insert into "OE"."PRODUCT_TRACKING"
values
"PRODUCT_ID" = 2302,
"MODIFIED_TIME" = TO_DATE('17-JAN-03', 'DD-MON-RR'),
"OLD_LIST_PRICE" = 150,
"OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00');

5. LogMinerセッションを終了します。

EXECUTE DBMS_LOGMNR.END_LOGMNR();

例3: 問合せに将来の値を含める連続マイニングの使用

所定の時刻になるまでまたはSCNに到達するまで問合せが終了しないように指定するには、DBMS_LOGMNR.START_LOGMNRプロシージャへのコールで、CONTINUOUS_MINEオプションを使用し、ENDTIMEオプションまたはENDSCNオプションのいずれかを、将来の時刻またはまだ到達していないSCN値に設定します。

この例では、現在から5時間後までの間に表hr.employeesに対して行われたすべての変更を監視するとします。また、オンライン・カタログ内のディクショナリを使用するとします。

1. LogMinerを起動します。

EXECUTE DBMS_LOGMNR.START_LOGMNR(-

STARTTIME => SYSDATE, -
ENDTIME   => SYSDATE + 5/24, -
OPTIONS   => DBMS_LOGMNR.CONTINUOUS_MINE  + -
DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);

2. V$LOGMNR_CONTENTSビューを問い合せます。
この選択操作は、分析する時間範囲(現在から5時間)後に生成される最初のREDOログ・ファイル・レコードが検出されるまで完了しません。[Ctrl]キーを押しながら[C]キーを押すと、完了前に選択操作を中止できます。

この例では、SET ARRAYSIZE文を指定して、行がREDOログ・ファイルに入力されたとおりに表示されるように設定しています。SET ARRAYSIZE文を指定していない場合、SQL内部バッファが一杯になるまで行は返されません。

SET ARRAYSIZE 1;
SELECT USERNAME AS usr, SQL_REDO FROM V$LOGMNR_CONTENTS
WHERE  SEG_OWNER = 'HR' AND TABLE_NAME = 'EMPLOYEES';

3. LogMinerセッションを終了します。

EXECUTE DBMS_LOGMNR.END_LOGMNR();

シナリオの例

この項では、LogMinerの一般的な使用例を示します。この項では、次の例を示します。

- 使用例1: LogMinerを使用した特定のユーザーによる変更の追跡

- 使用例2: LogMinerを使用した表アクセス統計の計算

使用例1: LogMinerを使用した特定のユーザーによる変更の追跡

この例では、joedevoというユーザーによって特定の時間範囲にデータベースに対して行われた変更をすべて表示する方法を示します。データベースに接続した後、次の手順を実行します。

1. LogMinerディクショナリ・ファイルを作成します。
LogMinerを使用してjoedevoのデータを分析するには、joedevoが使用する表に対して表定義の変更が行われる前にLogMinerディクショナリ・ファイルを作成するか、またはLogMiner起動時にオンライン・カタログを使用する必要があります。LogMinerディクショナリを作成する例は、「LogMinerディクショナリの抽出」を参照してください。この例では、REDOログ・ファイルに抽出されたLogMinerディクショナリを使用します。

2. REDOログ・ファイルを追加します。
joedevoがデータベースに対して変更を行ったとします。分析するREDOログ・ファイルの名前は、次のように指定できます。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => 'log1orc1.ora', -
OPTIONS => DBMS_LOGMNR.NEW);

必要に応じて、次のようにREDOログ・ファイルを追加します。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => 'log2orc1.ora', -
OPTIONS => DBMS_LOGMNR.ADDFILE);

3. LogMinerを起動し、検索を指定した時間範囲に制限します。

EXECUTE DBMS_LOGMNR.START_LOGMNR( -
DICTFILENAME => 'orcldict.ora', -
STARTTIME => TO_DATE('01-Jan-1998 08:30:00','DD-MON-YYYY HH:MI:SS'), -
ENDTIME => TO_DATE('01-Jan-1998 08:45:00', 'DD-MON-YYYY HH:MI:SS'));

4. V$LOGMNR_CONTENTSビューを問い合せます。
この時点で、V$LOGMNR_CONTENTSビューを問い合せることが可能です。ユーザーjoedevoがsalary表に対して行ったすべての変更を検索します。次のSELECT文を実行します。

SELECT SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS
WHERE USERNAME = 'joedevo' AND SEG_NAME = 'salary';

SQL_REDO列とSQL_UNDO列の両方に対して、2つの行が返されます(データ表示の書式は画面では異なる場合があります)。joedevoが2つの操作を要求したことがわかります。joedevoは、古い給与を削除した後、新しい昇給後の給与を挿入しました。これらは、この操作を元に戻すために必要なデータです。

SQL_REDO                              SQL_UNDO
--------                              --------
delete from SALARY                    insert into SALARY(NAME, EMPNO, SAL)
where EMPNO = 12345                    values ('JOEDEVO', 12345, 500)
and NAME='JOEDEVO'
and SAL=500;

insert into SALARY(NAME, EMPNO, SAL)  delete from SALARY
values('JOEDEVO',12345, 2500)         where EMPNO = 12345
and NAME = 'JOEDEVO'
2 rows selected                       and SAL = 2500;

5. LogMinerセッションを終了します。
LogMinerセッションを正常に終了するには、DBMS_LOGMNR.END_LOGMNRプロシージャを使用します。

DBMS_LOGMNR.END_LOGMNR( );

使用例2: LogMinerを使用した表アクセス統計の計算

この例では、ダイレクト・マーケティング・データベースを管理し、1月の2週間の収益でのカスタマ・コンタクトの有効性を確認するとします。すでにLogMinerディクショナリを作成済で、検索するREDOログ・ファイルを追加してあるとします(前述の例と同様)。次の手順を実行します。

1. LogMinerを起動し、時間範囲を指定します。

EXECUTE DBMS_LOGMNR.START_LOGMNR( -
STARTTIME => TO_DATE('07-Jan-2012 08:30:00','DD-MON-YYYY HH:MI:SS'), -
ENDTIME => TO_DATE('21-Jan-2012 08:45:00','DD-MON-YYYY HH:MI:SS'), -
DICTFILENAME => '/usr/local/dict.ora');

2. V$LOGMNR_CONTENTSビューを問い合せて、次の例に示すとおり、指定した時間範囲で変更された表を判別します。(この問合せでは、従来どおり名前に$を含むシステム表がフィルタ処理で除外されます。)

SELECT SEG_OWNER, SEG_NAME, COUNT(*) AS Hits FROM
V$LOGMNR_CONTENTS WHERE SEG_NAME NOT LIKE '%$' GROUP BY
SEG_OWNER, SEG_NAME ORDER BY Hits DESC;

3. 次のデータが表示されます。(画面の書式は異なる場合があります。)

SEG_OWNER          SEG_NAME          Hits
---------          --------          ----
CUST               ACCOUNT            384
UNIV               EXECDONOR          325
UNIV               DONOR              234
UNIV               MEGADONOR           32
HR                 EMPLOYEES           12
SYS                DONOR               12

Hits列の値は、問合せで指定した2週間の間に、指定した表に対して挿入、削除、更新の操作が行われた回数を示しています。この例では、指定した2週間の間にcust.account表が最も多く変更され、hr.employees表とsys.donor表は同じ期間の変更回数が最小でした。

4. LogMinerセッションを終了します。
LogMinerセッションを正常に終了するには、DBMS_LOGMNR.END_LOGMNRプロシージャを使用します。

DBMS_LOGMNR.END_LOGMNR( );

サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン

次の項では、データ型と記憶域属性のサポートに関する情報およびサポートされるデータベースとREDOログ・ファイルのリリースを示します。

- サポートされるデータ型と表記憶域属性

- サポートされないデータ型と表記憶域属性

- サポートされるデータベースとREDOログ・ファイルのバージョン

サポートされるデータ型と表記憶域属性

注意:

Oracle Database 12cリリース1 (12.1)から、VARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズが32KBに増加しました(COMPATIBLE初期化パラメータが12.0以上に設定され、MAX_STRING_SIZE初期化パラメータがEXTENDEDに設定されている場合)。

LogMinerでは、サプリメンタル・ロギングの目的で32KBの列がLOBとして扱われます。

32KBの列は、ALWAYSサプリメンタル・ロギング・グループの一部にはできません。

LogMinerは、次のデータ型と表記憶域属性をサポートします。「互換性要件」で説明するとおり、一部のデータ型は特定のリリースでのみサポートされます。

データ型

- BINARY_DOUBLE

- BINARY_FLOAT

- BLOB

- CHAR

- CLOBおよびNCLOB

- DATE

- INTERVALYEARTOMONTH

- INTERVALDAYTOSECOND

- SecureFilesとして格納されるLOB (11.2以上の互換性で動作するデータベースが必要)

- LONG

- LONG RAW

- NCHAR

- NUMBER

- NVARCHAR2

- VARRAYとして格納されるオブジェクト

- オブジェクト(コレクションなしの単純なネストされたADT)
(SDO_GEOMETRYやORDIMAGEなどオラクルで用意しているタイプを含む)オブジェクトのサポートでは、12.0.0.0以上のREDO互換性が設定されたOracle Database 12cリリース1 (12.1)が実行されている必要があります。XMLデータに関連する操作用のSQL_REDO列の内容は、有効なSQLまたはPL/SQLではありません。

- Oracle Text

- RAW

- TIMESTAMP

- TIMESTAMP WITH TIMEZONE

- TIMESTAMP WITH LOCAL TIMEZONE

- VARCHARおよびVARCHAR2

- XDB

- 次のプライマリ・データベース互換性要件を仮定した場合は、すべてのストレージ・モデルのXMLTypeデータ。

- CLOB形式として格納されるXMLTypeでは、11.0以上の互換性設定で動作するデータベースが必要です(Oracle Database 12cリリース1 (12.1)からはCLOBとして格納されるXMLTypeが非推奨になったため)。

- オブジェクト・リレーショナル形式またはバイナリXMLで格納されるXMLTypeには、11.2.0.3以上のREDO互換性が設定されたOracle Database 11gリリース2 (11.2.0.3)以上でデータベースを実行している必要があります。XMLデータに関連する操作用のSQL_REDO列の内容は、有効なSQLまたはPL/SQLではありません。

表記憶域タイプ

- クラスタ表(索引クラスタおよびヒープ・クラスタを含む)

- 索引構成表(IOT) (オーバーフロー・セグメントを含むパーティション化および非パーティション化)

- ヒープ構成表(パーティション化および非パーティション化)

- 高度な行圧縮および基本表圧縮。これらのオプションはいずれも、データベースの互換性設定が11.1.0以上である必要があります。

- SecureFilesとして格納されるLOB列を含む表(データベース互換性が11.2以上に設定されている場合)

- ハイブリッド列圧縮を使用する表(データベース互換性が11.2.0.2以上に設定されている場合)

関連項目:

- ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。

互換性要件

LogMinerによる一部のデータ型および表記憶域属性のサポートには、次のデータベース互換性要件があります。

- マルチバイトのCLOBサポートには、10.1以上の互換性で動作するデータベースが必要です。

- LOBおよびオーバーフローなしのIOTサポートには、10.1以上の互換性で動作するデータベースが必要です。

- LOBおよびオーバーフローありのIOTサポートには、10.2以上の互換性で動作するデータベースが必要です。

- TDEおよびTSEサポートには、11.1以上の互換性で動作するデータベースが必要です。

- 基本圧縮および高度な行圧縮では、11.1以上の互換性で動作するデータベースが必要です。

- ハイブリッド列圧縮のサポートは、基礎となるストレージ・システムに依存し、11.2以上の互換性で動作するデータベースが必要です。

関連項目:

- ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。

サポートされないデータ型と表記憶域属性

LogMinerは、次のデータ型と表記憶域属性をサポートしません。これらのサポートされていないデータ型のいずれかを使用する列が表に含まれる場合、表全体がLogMinerによって無視されます。

- BFILE

- コレクション(VARRAYおよびネストした表を含む)

- ネストした表およびREFのあるオブジェクト

サポートされるデータベースとREDOログ・ファイルのバージョン

LogMinerは、リリース8.1以上のデータベースでのみ実行されますが、リリース8.0のデータベースからのREDOログ・ファイルの分析に使用することができます。ただし、LogMinerでREDOログ・ファイルから取得することができる情報は、使用中のデータベースのリリースではなく、ログのバージョンに依存します。たとえば、サプリメンタル・ロギングが有効な場合は、Oracle9iのREDOログ・ファイルを拡張して追加情報を取得できます。これによって、LogMinerの機能を最大限使用できます。旧リリースのOracleで作成されたREDOログ・ファイルには、追加データが含まれていないため、LogMinerによってサポートされる操作およびデータ型が制限される場合があります。

関連項目:

「一般的なLogMinerセッションの手順」および「サプリメンタル・ロギング」

SecureFiles LOBに関する考慮点

SecureFiles LOBは、データベース互換性が11.2以上に設定されている場合にサポートされます。SecureFiles LOB列には、SQL_REDO列のみを入力できます。SQL_UNDO列は入力されません。

透過的データ暗号化(TDE)およびデータ圧縮は、プライマリ・データベースのSecureFiles LOB列で有効化できます。

SecureFiles LOB列の重複除外は完全にサポートされます。フラグメント操作はサポートされません。

LogMinerは、サポートされない操作によって生成されたREDOを検出すると、OPERATION列がUNSUPPORTEDに設定された行を生成します。これらのREDOレコードには、SQL_REDOまたはSQL_UNDOは生成されません。

21 メタデータAPIの使用

DBMS_METADATA APIを使用すると、次の操作を行うことができます。

- オブジェクトのメタデータのXMLとしての取得

- SQL DDLへの変換を含む様々な方法でのXMLの変換

- 取得で抽出したオブジェクトを再作成するためのXMLの送信

DBMS_METADATA_DIFF APIを使用すると、データベース間でオブジェクトを比較し、同じ型のオブジェクトのうち時間の経過によってメタデータが変化したものを識別できます。

次のトピックを参照してください。

- DBMS_METADATA APIを使用する理由

- DBMS_METADATA APIの概要

- オブジェクトのメタデータを取得するためのDBMS_METADATA APIの使用

- 取得したオブジェクトを再作成するためのDBMS_METADATA APIの使用

- 異なるオブジェクト型のコレクションを取得するためのDBMS_METADATA APIの使用

- オブジェクトのメタデータを比較するためのDBMS_METADATA_DIFF APIの使用

- DBMS_METADATA APIのプログラム・インタフェースに関するパフォーマンスのヒント

- DBMS_METADATA APIの使用例

- DBMS_METADATAプロシージャの要約

- DBMS_METADATA_DIFFプロシージャの要約

DBMS_METADATA APIを使用する理由

Oracle Databaseの長期の使用に伴い、ディレクトリからメタデータを抽出し、そのメタデータに対し列の追加やデータ型の変更などを行い、さらにDDLに変換して元のまたは異なるデータベースのオブジェクトを再作成するために、ユーザーが独自のコードを開発する機会が多くなりました。ディクショナリの新機能をサポートするよう、そのコードを更新された状態に保つことは困難です。

DBMS_METADATA APIを使用すると、メタデータを抽出するために独自のコードを記述して管理する必要がなくなります。ディクショナリ・メタデータの抽出、操作および再作成に関する集中的な機能が提供されます。また、すべてのディクショナリ・オブジェクトを最新のレベルでサポートしています。

DBMS_METADATA APIは、記述および管理するカスタム・コードの量を大幅に削減しますが、通常のデータベース手順の変更はありません。DBMS_METADATA APIは、データ・ディクショナリ・ビューと同様、データベースのインストール時にcatproc.sqlを実行し、SQLスクリプトを実行してインストールします。インストール後は、制限モードであっても、インスタンスが動作中はいつでも使用可能です。

DBMS_METADATA APIは、異なるOracleのリリース間で上位互換性があるため、データベースのリリースを変更しても、ソース・コードの変更は必要ありません。1つのリリースで取得したXML文書を、同じまたはそれ以上のリリースの送信インタフェースで処理できます。たとえば、Oracle9iデータベースで取得したXML文書は、Oracle Database 10gに送信できます。

DBMS_METADATA APIの概要

DBMS_METADATA APIにおいては、データベース内のすべてのエンティティは、オブジェクト型に属するオブジェクトとして形成されています。たとえば、scott.emp表はオブジェクトであり、オブジェクト型はTABLEです。オブジェクトのメタデータをフェッチする場合は、オブジェクト型を指定する必要があります。

オブジェクト型の特定のオブジェクトまたは一連のオブジェクトをフェッチするには、フィルタを指定します。各オブジェクト型に対して異なるフィルタが定義されます。たとえば、TABLEオブジェクト型に対して定義されている2つのフィルタはSCHEMAおよびNAMEです。これにより、たとえば、スキーマがscottで名前がempである表を必要としていることを表現できます。

DBMS_METADATA APIは、XML(Extensible Markup Language)およびXSLT(Extensible Stylesheet Language Transformation)を使用します。XMLは解析や変換が容易な汎用形式であるため、DBMS_METADATA APIは、オブジェクト・メタデータをXMLとして表現します。DBMS_METADATA APIは、XSLTを使用してXML文書を他のXML文書またはSQL DDLのいずれかに変換します。

DBMS_METADATA APIを使用して、メタデータをフェッチするとき(または再送信するとき)に、1つ以上の変換(XSLTスクリプト)をXMLに適用するよう指定できます。APIには、XML文書をSQL作成DDLに変換する名前付きDDL以外にも、いくつかの事前定義変換があります。

次に変換パラメータを使用して、変換の条件を指定できます。また、オブジェクトのメタデータの特定の属性にアクセスするために、オプションの解析項目も指定できます。これらのオプションの詳細と実装例については、次の項を参照してください。

- オブジェクトのメタデータを取得するためのDBMS_METADATA APIの使用

- 取得したオブジェクトを再作成するためのDBMS_METADATA APIの使用

- 異なるオブジェクト型のコレクションを取得するためのDBMS_METADATA APIの使用

オブジェクトのメタデータを取得するためのDBMS_METADATA APIの使用

DBMS_METADATA APIの取得インタフェースでは、取得するオブジェクトの種類を指定できます。種類は、特定のオブジェクト型(表、索引、プロシージャなど)または論理単位を形成する異なるオブジェクト型のコレクション(データベース・エクスポート、スキーマ・エクスポートなど)のいずれかです。デフォルトでは、フェッチされたメタデータがXML文書に返されます。

注意:

スキーマにないオブジェクトにアクセスするにはSELECT_CATALOG_ROLEロールが必要です。ただし、ロールは多くのPL/SQLオブジェクト(ストアド・プロシージャ、ファンクション、定義者権限API)内で無効とされます。そのため、他のスキーマのオブジェクト(一般的には、SELECT_CATALOG_ROLEロールを必要とするすべてのオブジェクト)内にアクセスするPL/SQLプログラムを記述する場合は、実行者権限APIにコードを入力する必要があります。

プログラム・インタフェースを使用して、簡単な参照を実行したり、アプリケーションを開発できます。システム・メタデータの非定型の問合せを行う場合は、ブラウザ・インタフェースを使用します。アプリケーションの一部として、ディクショナリ・メタデータを抽出する場合は、プログラム・インタフェースを使用します。その場合、同じことをするために現在使用しているSQLスクリプトおよびカスタマイズしたコードのかわりに、DBMS_METADATA APIで提供されているプロシージャを使用することもできます。

基本的なメタデータ取得の通常手順

メタデータを取得する場合は、DBMS_METADATA PL/SQL APIを使用します。次に、プログラム・インタフェースおよびブラウザ・インタフェースの例を示します。

関連項目:

- プログラム・インタフェースで使用するDBMS_METADATAプロシージャの詳細は、表21-1を参照してください。

- ブラウザ・インタフェースで使用するDBMS_METADATAプロシージャの詳細は、表21-2を参照してください。

- DBMS_METADATA APIの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

例21-1では、DBMS_METADATAプログラム・インタフェースを使用して1つの表のメタデータを取得する基本的な方法を説明します。この例では、get_table_mdというファンクションを作成するDBMS_METADATAプログラムを作成します。ファンクションは、1つの表のメタデータを返します。

例21-2に示すとおり、ブラウザ・インタフェースを使用しても同じ結果を得られます。

例21-1 データ取得のためのDBMS_METADATAプログラム・インタフェースの使用

1. hrスキーマ内の1つの表(timecards)のメタデータを返すファンクションget_table_mdを作成するDBMS_METADATAプログラムを作成します。プログラムの内容は次のようになります。(この例ではプログラムにmetadata_program.sqlという名前を付けます)。

CREATE OR REPLACE FUNCTION get_table_md RETURN CLOB IS
-- Define local variables.
h NUMBER; --handle returned by OPEN
th NUMBER; -- handle returned by ADD_TRANSFORM
doc CLOB;
BEGIN

-- Specify the object type.
h := DBMS_METADATA.OPEN('TABLE');

-- Use filters to specify the particular object desired.
DBMS_METADATA.SET_FILTER(h,'SCHEMA','HR');
DBMS_METADATA.SET_FILTER(h,'NAME','TIMECARDS');

-- Request that the metadata be transformed into creation DDL.
th := DBMS_METADATA.ADD_TRANSFORM(h,'DDL');

-- Fetch the object.
doc := DBMS_METADATA.FETCH_CLOB(h);

-- Release resources.
DBMS_METADATA.CLOSE(h);
RETURN doc;
END;
/

2. ユーザーhrとして接続します。

3. プログラムを実行してget_table_mdファンクションを作成します。
SQL> @metadata_program

4. 新しく作成したget_table_mdファンクションを選択操作で使用します。完全で中断のない出力を生成するには、問合せの実行前に、次のとおり、PAGESIZEを0(ゼロ)にし、またLONGを大きい数に設定します。

SQL> SET PAGESIZE 0
SQL> SET LONG 1000000
SQL> SELECT get_table_md FROM dual;

5. hrスキーマのtimecards表のメタデータを示す出力は、次のようになります。

CREATE TABLE "HR"."TIMECARDS"
(    "EMPLOYEE_ID" NUMBER(6,0),
"WEEK" NUMBER(2,0),
"JOB_ID" VARCHAR2(10),
"HOURS_WORKED" NUMBER(4,2),
FOREIGN KEY ("EMPLOYEE_ID")
REFERENCES "HR"."EMPLOYEES" ("EMPLOYEE_ID") ENABLE
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "EXAMPLE"

例21-2 データ取得のためのDBMS_METADATAブラウザ・インタフェースの使用

SQL> SET PAGESIZE 0
SQL> SET LONG 1000000
SQL> SELECT DBMS_METADATA.GET_DDL('TABLE','TIMECARDS','HR') FROM dual;

結果は、例21-1の手順5と同様になります。

複数のオブジェクトの取得

例21-1では、オブジェクトが1つしか存在しないことがわかっていたため、FETCH_CLOBプロシージャは1回のみコールされました。scottスキーマのすべての表などの複数のオブジェクトも取得できます。それを行うには、次の構成メンバーを使用する必要があります。

LOOP
doc := DBMS_METADATA.FETCH_CLOB(h);
--
-- When there are no more objects to be retrieved, FETCH_CLOB returns NULL.
--
EXIT WHEN doc IS NULL;
END LOOP;

例21-3に、構成メンバーの使用および複数のオブジェクトの取得を示します。この例では、ユーザーscottとして接続します。パスワードは、tigerです。

例21-3 複数のオブジェクトの取得

1. 次のように、my_metadataという名前の表と、get_tables_mdという名前のプロシージャを作成します。すべてのオブジェクトを返すことはできないため、それらを表に格納して最後に問合せを実行します。

DROP TABLE my_metadata;
CREATE TABLE my_metadata (md clob);
CREATE OR REPLACE PROCEDURE get_tables_md IS
-- Define local variables
h       NUMBER;         -- handle returned by 'OPEN'
th      NUMBER;         -- handle returned by 'ADD_TRANSFORM'
doc     CLOB;           -- metadata is returned in a CLOB
BEGIN

-- Specify the object type.
h := DBMS_METADATA.OPEN('TABLE');

-- Use filters to specify the schema.
DBMS_METADATA.SET_FILTER(h,'SCHEMA','SCOTT');

-- Request that the metadata be transformed into creation DDL.
th := DBMS_METADATA.ADD_TRANSFORM(h,'DDL');

-- Fetch the objects.
LOOP
doc := DBMS_METADATA.FETCH_CLOB(h);

-- When there are no more objects to be retrieved, FETCH_CLOB returns NULL.
EXIT WHEN doc IS NULL;

-- Store the metadata in a table.
INSERT INTO my_metadata(md) VALUES (doc);
COMMIT;
END LOOP;

-- Release resources.
DBMS_METADATA.CLOSE(h);
END;
/

2. 次のようにプロシージャを実行します。

EXECUTE get_tables_md;

3. my_metadata表を問い合せて、取得された内容を確認します。

SET LONG 9000000
SET PAGES 0
SELECT * FROM my_metadata;

変換の条件指定

変換パラメータを使用して、追加する変換の条件を指定できます。SET_TRANSFORM_PARAMプロシージャを使用します。たとえば、TABLEオブジェクトに対してDDL変換を追加した場合、SEGMENT_ATTRIBUTES変換パラメータを指定して、物理、ストレージ、ロギングなどのセグメント属性をDDLに表示しないようにすることができます。デフォルトでは、セグメント属性がDDLに表示されます。

例21-4に、SET_TRANSFORM_PARAMプロシージャの使用方法を示します。

例21-4 変換の条件指定

1. 次のように、get_table_mdという名前のファンクションを作成します。

CREATE OR REPLACE FUNCTION get_table_md RETURN CLOB IS
-- Define local variables.
h    NUMBER;   -- handle returned by 'OPEN'
th   NUMBER;   -- handle returned by 'ADD_TRANSFORM'
doc  CLOB;
BEGIN

-- Specify the object type.
h := DBMS_METADATA.OPEN('TABLE');

-- Use filters to specify the particular object desired.
DBMS_METADATA.SET_FILTER(h,'SCHEMA','HR');
DBMS_METADATA.SET_FILTER(h,'NAME','TIMECARDS');

-- Request that the metadata be transformed into creation DDL.
th := dbms_metadata.add_transform(h,'DDL');

-- Specify that segment attributes are not to be returned.
-- Note that this call uses the TRANSFORM handle, not the OPEN handle.
DBMS_METADATA.SET_TRANSFORM_PARAM(th,'SEGMENT_ATTRIBUTES',false);

-- Fetch the object.
doc := DBMS_METADATA.FETCH_CLOB(h);

-- Release resources.
DBMS_METADATA.CLOSE(h);

RETURN doc;
END;
/

2. 次の問合せを実行します。

SQL> SELECT get_table_md FROM dual;

出力は、次のようになります。

CREATE TABLE "HR"."TIMECARDS"
(    "EMPLOYEE_ID" NUMBER(6,0),
"WEEK" NUMBER(2,0),
"JOB_ID" VARCHAR2(10),
"HOURS_WORKED" NUMBER(4,2),
FOREIGN KEY ("EMPLOYEE_ID")
REFERENCES "HR"."EMPLOYEES" ("EMPLOYEE_ID") ENABLE
)

ここまでの例ではDDL変換という1つの変換を使用しました。DBMS_METADATA APIでは、最初の出力が2番目の入力になり、2番目の出力が3番目の入力になるというように、複数の変換を指定することもできます。

Oracleには、XML文書を変更するMODIFYと呼ばれる変換があります。スキーマ名や表領域名の変更などが行えます。これには、再マップ・パラメータおよびSET_REMAP_PARAMプロシージャを使用します。

例21-5に、SET_REMAP_PARAMプロシージャの使用例を示します。まずMODIFY変換を追加し、再マップ・パラメータを指定して、スキーマ名をhrからscottに変更します。次にDDL変換を追加します。MODIFY変換の出力は、DDL変換への入力となるXML文書です。最終的な結果は、timecards表の作成DDLであり、hrスキーマのすべてのインスタンスはscottに変更されます。

例21-5 XML文書の変更

1. 次のように、remap_schemaという名前のファンクションを作成します。

CREATE OR REPLACE FUNCTION remap_schema RETURN CLOB IS
-- Define local variables.
h NUMBER; --handle returned by OPEN
th NUMBER; -- handle returned by ADD_TRANSFORM
doc CLOB;
BEGIN

-- Specify the object type.
h := DBMS_METADATA.OPEN('TABLE');

-- Use filters to specify the particular object desired.
DBMS_METADATA.SET_FILTER(h,'SCHEMA','HR');
DBMS_METADATA.SET_FILTER(h,'NAME','TIMECARDS');

-- Request that the schema name be modified.
th := DBMS_METADATA.ADD_TRANSFORM(h,'MODIFY');
DBMS_METADATA.SET_REMAP_PARAM(th,'REMAP_SCHEMA','HR','SCOTT');

-- Request that the metadata be transformed into creation DDL.
th := DBMS_METADATA.ADD_TRANSFORM(h,'DDL');

-- Specify that segment attributes are not to be returned.
DBMS_METADATA.SET_TRANSFORM_PARAM(th,'SEGMENT_ATTRIBUTES',false);

-- Fetch the object.
doc := DBMS_METADATA.FETCH_CLOB(h);

-- Release resources.
DBMS_METADATA.CLOSE(h);
RETURN doc;
END;
/

2. 次の問合せを実行します。

SELECT remap_schema FROM dual;

出力は、次のようになります。

CREATE TABLE "SCOTT"."TIMECARDS"
(    "EMPLOYEE_ID" NUMBER(6,0),
"WEEK" NUMBER(2,0),
"JOB_ID" VARCHAR2(10),
"HOURS_WORKED" NUMBER(4,2),
FOREIGN KEY ("EMPLOYEE_ID")
REFERENCES "SCOTT"."EMPLOYEES" ("EMPLOYEE_ID") ENABLE
)

XSLTをよく理解しているユーザーであれば、独自の変換を追加してXMLを処理できます。

特定のメタデータ属性へのアクセス

名前やスキーマなどのオブジェクトのメタデータの特定の属性へアクセスすることが必要な場合もあります。属性の情報は返されたメタデータを解析して取得できますが、DBMS_METADATA APIには、別の機能もあります。メタデータから解析され、別のデータ構造に返される特定の属性を解析項目に指定できます。これを行うには、SET_PARSE_ITEMプロシージャを使用します。

例21-6では、スキーマ内のすべての表をフェッチします。各表では、名前を取得するために解析項目を使用します。次に表のすべての索引を取得するために名前を使用します。次の例に、sys.ku$_ddlsオブジェクトのメタデータを返すFETCH_DDLファンクションの使用を示します。

この例では、いくつかの表および索引を含むスキーマに接続していることとします。また、my_metadataという名前の表も作成します。

例21-6 特定のメタデータ属性にアクセスするための解析項目の使用

1. 次のように、my_metadataという名前の表と、get_tables_and_indexesという名前のプロシージャを作成します。

DROP TABLE my_metadata;
CREATE TABLE my_metadata (
object_type   VARCHAR2(30),
name          VARCHAR2(30),
md            CLOB);
CREATE OR REPLACE PROCEDURE get_tables_and_indexes IS
-- Define local variables.
h1      NUMBER;         -- handle returned by OPEN for tables
h2      NUMBER;         -- handle returned by OPEN for indexes
th1     NUMBER;         -- handle returned by ADD_TRANSFORM for tables
th2     NUMBER;         -- handle returned by ADD_TRANSFORM for indexes
doc     sys.ku$_ddls;   -- metadata is returned in sys.ku$_ddls,
--  a nested table of sys.ku$_ddl objects
ddl     CLOB;           -- creation DDL for an object
pi      sys.ku$_parsed_items;   -- parse items are returned in this object
-- which is contained in sys.ku$_ddl
objname VARCHAR2(30);   -- the parsed object name
idxddls sys.ku$_ddls;   -- metadata is returned in sys.ku$_ddls,
--  a nested table of sys.ku$_ddl objects
idxname VARCHAR2(30);   -- the parsed index name
BEGIN
-- This procedure has an outer loop that fetches tables,
-- and an inner loop that fetches indexes.

-- Specify the object type: TABLE.
h1 := DBMS_METADATA.OPEN('TABLE');

-- Request that the table name be returned as a parse item.
DBMS_METADATA.SET_PARSE_ITEM(h1,'NAME');

-- Request that the metadata be transformed into creation DDL.
th1 := DBMS_METADATA.ADD_TRANSFORM(h1,'DDL');

-- Specify that segment attributes are not to be returned.
DBMS_METADATA.SET_TRANSFORM_PARAM(th1,'SEGMENT_ATTRIBUTES',false);

-- Set up the outer loop: fetch the TABLE objects.
LOOP
doc := dbms_metadata.fetch_ddl(h1);

-- When there are no more objects to be retrieved, FETCH_DDL returns NULL.
EXIT WHEN doc IS NULL;

-- Loop through the rows of the ku$_ddls nested table.
FOR i IN doc.FIRST..doc.LAST LOOP
ddl := doc(i).ddlText;
pi := doc(i).parsedItems;
-- Loop through the returned parse items.
IF pi IS NOT NULL AND pi.COUNT > 0 THEN
FOR j IN pi.FIRST..pi.LAST LOOP
IF pi(j).item='NAME' THEN
objname := pi(j).value;
END IF;
END LOOP;
END IF;
-- Insert information about this object into our table.
INSERT INTO my_metadata(object_type, name, md)
VALUES ('TABLE',objname,ddl);
COMMIT;
END LOOP;

-- Now fetch indexes using the parsed table name as
--  a BASE_OBJECT_NAME filter.

-- Specify the object type.
h2 := DBMS_METADATA.OPEN('INDEX');

-- The base object is the table retrieved in the outer loop.
DBMS_METADATA.SET_FILTER(h2,'BASE_OBJECT_NAME',objname);

-- Exclude system-generated indexes.
DBMS_METADATA.SET_FILTER(h2,'SYSTEM_GENERATED',false);

-- Request that the index name be returned as a parse item.
DBMS_METADATA.SET_PARSE_ITEM(h2,'NAME');

-- Request that the metadata be transformed into creation DDL.
th2 := DBMS_METADATA.ADD_TRANSFORM(h2,'DDL');

-- Specify that segment attributes are not to be returned.
DBMS_METADATA.SET_TRANSFORM_PARAM(th2,'SEGMENT_ATTRIBUTES',false);

LOOP
idxddls := dbms_metadata.fetch_ddl(h2);

-- When there are no more objects to  be retrieved, FETCH_DDL returns NULL.
EXIT WHEN idxddls IS NULL;

FOR i in idxddls.FIRST..idxddls.LAST LOOP
ddl := idxddls(i).ddlText;
pi  := idxddls(i).parsedItems;
-- Loop through the returned parse items.
IF pi IS NOT NULL AND pi.COUNT > 0 THEN
FOR j IN pi.FIRST..pi.LAST LOOP
IF pi(j).item='NAME' THEN
idxname := pi(j).value;
END IF;
END LOOP;
END IF;

-- Store the metadata in our table.
INSERT INTO my_metadata(object_type, name, md)
VALUES ('INDEX',idxname,ddl);
COMMIT;
END LOOP;  -- for loop
END LOOP;
DBMS_METADATA.CLOSE(h2);
END LOOP;
DBMS_METADATA.CLOSE(h1);
END;
/

2. 次のようにプロシージャを実行します。

EXECUTE get_tables_and_indexes;

3. 次の問合せを実行して、取得された内容を確認します。

SET LONG 9000000
SET PAGES 0
SELECT * FROM my_metadata;

取得したオブジェクトを再作成するためのDBMS_METADATA APIの使用

オブジェクトに対しメタデータをフェッチする場合、そのメタデータを使用して、オブジェクトを異なるデータベースまたはスキーマで再作成することがあります。

メタデータをフェッチする際に、再マップの実行を決定していない場合もあります。また、この決定を先送りにしたい場合があります。再マップを先送りにするには、メタデータをXMLとしてフェッチし、ファイルまたは表に格納します。後で送信インタフェースを使用しオブジェクトを再作成します。

送信インタフェースは取得インタフェースに類似した構成です。送信インタフェースには、作成するオブジェクトのオブジェクト型を指定するOPENWプロシージャが存在します。変換の指定、パラメータの変換および項目の解析ができます。CONVERTファンクションをコールしてXMLからDDLに変換する、またはPUTファンクションをコールしてXMLをDDLに変換し、DDLを送信してオブジェクトを作成できます。

関連項目:

送信インタフェースで使用するDBMS_METADATAプロシージャおよびファンクションの詳細は、表21-3を参照してください。

例21-7は、1つのスキーマの表のXMLをフェッチし、次に送信インタフェースを使用して別のスキーマの表を再作成します。

例21-7 取得したオブジェクトを再作成するための送信インタフェースの使用

1. 次のように、権限を持つユーザーとして接続します。

CONNECT system
Enter password: password

2. 実行者権限パッケージを作成してプロシージャを保持します。これは、別のスキーマ内のオブジェクトにアクセスするには、SELECT_CATALOG_ROLEロールが必要なためです。定義者権限PL/SQLオブジェクト(プロシージャ、ファンクションなど)では、ロールは使用できません。

CREATE OR REPLACE PACKAGE example_pkg AUTHID current_user IS
PROCEDURE move_table(
table_name  in VARCHAR2,
from_schema in VARCHAR2,
to_schema   in VARCHAR2 );
END example_pkg;
/
CREATE OR REPLACE PACKAGE BODY example_pkg IS
PROCEDURE move_table(
table_name  in VARCHAR2,
from_schema in VARCHAR2,
to_schema   in VARCHAR2 ) IS

-- Define local variables.
h1      NUMBER;         -- handle returned by OPEN
h2      NUMBER;         -- handle returned by OPENW
th1     NUMBER;         -- handle returned by ADD_TRANSFORM for MODIFY
th2     NUMBER;         -- handle returned by ADD_TRANSFORM for DDL
xml     CLOB;           -- XML document
errs    sys.ku$_SubmitResults := sys.ku$_SubmitResults();
err     sys.ku$_SubmitResult;
result  BOOLEAN;
BEGIN

-- Specify the object type.
h1 := DBMS_METADATA.OPEN('TABLE');

-- Use filters to specify the name and schema of the table.
DBMS_METADATA.SET_FILTER(h1,'NAME',table_name);
DBMS_METADATA.SET_FILTER(h1,'SCHEMA',from_schema);

-- Fetch the XML.
xml := DBMS_METADATA.FETCH_CLOB(h1);
IF xml IS NULL THEN
DBMS_OUTPUT.PUT_LINE('Table ' || from_schema || '.' || table_name
|| ' not found');
RETURN;
END IF;

-- Release resources.
DBMS_METADATA.CLOSE(h1);

-- Use the submit interface to re-create the object in another schema.

-- Specify the object type using OPENW (instead of OPEN).
h2 := DBMS_METADATA.OPENW('TABLE');

-- First, add the MODIFY transform.
th1 := DBMS_METADATA.ADD_TRANSFORM(h2,'MODIFY');

-- Specify the desired modification: remap the schema name.
DBMS_METADATA.SET_REMAP_PARAM(th1,'REMAP_SCHEMA',from_schema,to_schema);

-- Now add the DDL transform so that the modified XML can be
--  transformed into creation DDL.
th2 := DBMS_METADATA.ADD_TRANSFORM(h2,'DDL');

-- Call PUT to re-create the object.
result := DBMS_METADATA.PUT(h2,xml,0,errs);

DBMS_METADATA.CLOSE(h2);
IF NOT result THEN
-- Process the error information.
FOR i IN errs.FIRST..errs.LAST LOOP
err := errs(i);
FOR j IN err.errorLines.FIRST..err.errorLines.LAST LOOP
dbms_output.put_line(err.errorLines(j).errorText);
END LOOP;
END LOOP;
END IF;
END;
END example_pkg;
/

3. ここで、次のように、スキーマSCOTTでmy_exampleという名前の表を作成します。

CONNECT scott
Enter password:
-- The password is tiger.

DROP TABLE my_example;
CREATE TABLE my_example (a NUMBER, b VARCHAR2(30));

CONNECT system
Enter password: password

SET LONG 9000000
SET PAGESIZE 0
SET SERVEROUTPUT ON SIZE 100000

4. 次のように、my_example表をSYSTEMスキーマにコピーします。

DROP TABLE my_example;
EXECUTE example_pkg.move_table('MY_EXAMPLE','SCOTT','SYSTEM');

5. 次の問合せを実行して、正しく動作したことを確認します。

SELECT DBMS_METADATA.GET_DDL('TABLE','MY_EXAMPLE') FROM dual;

異なるオブジェクト型のコレクションを取得するためのDBMS_METADATA APIの使用

異なる型のオブジェクトであるにもかかわらず、1つの論理単位を形成するオブジェクトのコレクションを取得する必要がある場合があります。たとえば、データベースまたはスキーマのすべてのオブジェクト、または表および依存する索引、制約、権限付与、監査などすべてを取得する必要があるとします。DBMS_METADATA APIでは、こうした取得を可能にするために、複数の異種オブジェクト型を提供しています。異種オブジェクト型は、オブジェクト型の順序付けられた集合です。

Oracleでは、次の異種オブジェクト型を提供しています。

- TABLE_EXPORT: 表およびその依存オブジェクト

- SCHEMA_EXPORT: スキーマおよびその内容

- DATABASE_EXPORT: データベース内のオブジェクト

これらのオブジェクト型は、データ・ポンプ・エクスポート・ユーティリティで使用するために開発されましたが、ユーザー独自のアプリケーションでも使用できます。

これらの型では、ブラウザ・インタフェースまたは送信インタフェースではなく、プログラム取得インタフェース(OPEN, FETCH, CLOSE)のみが使用できます。

同種型と同様に、異種オブジェクト型に対してもフィルタを指定できます。たとえば、TABLE_EXPORTに対してSCHEMAおよびNAMEフィルタを指定でき、SCHEMA_EXPORTに対してSCHEMAフィルタを指定できます。

例21-8に、scottスキーマ内のオブジェクト型を取得する方法を示します。ユーザーscottとして接続します。パスワードは、tigerです。

例21-8 異種オブジェクト型の取得方法

1. 取得したオブジェクトを格納するための表を作成します。

DROP TABLE my_metadata;
CREATE TABLE my_metadata (md CLOB);
CREATE OR REPLACE PROCEDURE get_schema_md IS

-- Define local variables.
h       NUMBER;         -- handle returned by OPEN
th      NUMBER;         -- handle returned by ADD_TRANSFORM
doc     CLOB;           -- metadata is returned in a CLOB
BEGIN

-- Specify the object type.
h := DBMS_METADATA.OPEN('SCHEMA_EXPORT');

-- Use filters to specify the schema.
DBMS_METADATA.SET_FILTER(h,'SCHEMA','SCOTT');

-- Request that the metadata be transformed into creation DDL.
th := DBMS_METADATA.ADD_TRANSFORM(h,'DDL');

-- Fetch the objects.
LOOP
doc := DBMS_METADATA.FETCH_CLOB(h);

-- When there are no more objects to be retrieved, FETCH_CLOB returns NULL.
EXIT WHEN doc IS NULL;

-- Store the metadata in the table.
INSERT INTO my_metadata(md) VALUES (doc);
COMMIT;
END LOOP;

-- Release resources.
DBMS_METADATA.CLOSE(h);
END;
/

2. 次のようにプロシージャを実行します。

EXECUTE get_schema_md;

3. 次の問合せを実行して、取得された内容を確認します。

SET LONG 9000000
SET PAGESIZE 0
SELECT * FROM my_metadata;

この例では、オブジェクトは、オブジェクト型による順序で返されます。たとえば、すべての表が返され、次に表のすべての権限が返され、次に表のすべての索引が返されます。順序は一般的に有効な作成順序となります。このため、返された順序でオブジェクトを取得し、送信インタフェースを使用して別のスキーマまたはデータベースで同じ順序で再作成した場合、通常、エラーは発生しません。(通常、例外は、循環参照の場合に発生します。たとえば、パッケージAにパッケージBへのコールが含まれ、パッケージBにパッケージAへのコールが含まれる場合、2回目にいずれかのパッケージを再コンパイルする必要があります。)

異種オブジェクト型の返りのフィルタ

返されるオブジェクトに対して、より詳細な制御を行うには、SET_FILTERプロシージャを使用して特定のメンバー型にのみフィルタを適用するよう指定します。これを行うには、SET_FILTERの4つ目のパラメータとして、メンバー型のパス名を指定します。また、EXCLUDE_PATH_EXPRフィルタを使用して、オブジェクト型のすべてのオブジェクトを除外できます。有効なパス名のリストは、TABLE_EXPORT_OBJECTSカタログ・ビューを参照してください。

例21-9に、返されるオブジェクトに対して、より詳細な制御を指定するためのSET_FILTERの使用方法を示します。ユーザーscottとして接続します。パスワードは、tigerです。

例21-9 異種オブジェクト型の返りのフィルタ

1. 取得したオブジェクトを格納するための表my_metadataを作成します。さらに、プロシージャget_schema_md2を作成します。

DROP TABLE my_metadata;
CREATE TABLE my_metadata (md CLOB);
CREATE OR REPLACE PROCEDURE get_schema_md2 IS

-- Define local variables.
h       NUMBER;         -- handle returned by 'OPEN'
th      NUMBER;         -- handle returned by 'ADD_TRANSFORM'
doc     CLOB;           -- metadata is returned in a CLOB
BEGIN

-- Specify the object type.
h := DBMS_METADATA.OPEN('SCHEMA_EXPORT');

-- Use filters to specify the schema.
DBMS_METADATA.SET_FILTER(h,'SCHEMA','SCOTT');

-- Use the fourth parameter to SET_FILTER to specify a filter
-- that applies to a specific member object type.
DBMS_METADATA.SET_FILTER(h,'NAME_EXPR','!=''MY_METADATA''','TABLE');

-- Use the EXCLUDE_PATH_EXPR filter to exclude procedures.
DBMS_METADATA.SET_FILTER(h,'EXCLUDE_PATH_EXPR','=''PROCEDURE''');

-- Request that the metadata be transformed into creation DDL.
th := DBMS_METADATA.ADD_TRANSFORM(h,'DDL');

-- Use the fourth parameter to SET_TRANSFORM_PARAM to specify a parameter
--  that applies to a specific member object type.
DBMS_METADATA.SET_TRANSFORM_PARAM(th,'SEGMENT_ATTRIBUTES',false,'TABLE');

-- Fetch the objects.
LOOP
doc := dbms_metadata.fetch_clob(h);

-- When there are no more objects to be retrieved, FETCH_CLOB returns NULL.
EXIT WHEN doc IS NULL;

-- Store the metadata in the table.
INSERT INTO my_metadata(md) VALUES (doc);
COMMIT;
END LOOP;

-- Release resources.
DBMS_METADATA.CLOSE(h);
END;
/

2. 次のようにプロシージャを実行します。

EXECUTE get_schema_md2;

3. 次の問合せを実行して、取得された内容を確認します。

SET LONG 9000000
SET PAGESIZE 0
SELECT * FROM my_metadata;

オブジェクトのメタデータを比較するためのDBMS_METADATA_DIFF APIの使用

この項では、DBMS_METADATAおよびDBMS_METADATA_DIFFの取得インタフェース、比較インタフェースおよび送信インタフェースの使用例を示します。この例では、2つの表のメタデータをフェッチして比較し、1つの表を他方と同じ内容に変更するALTER文を生成します。わかりやすくするために、この例全体でファンクションの変形を使用しています。

例21-10 オブジェクト・メタデータの比較

1. 次のように、2つの表TAB1、TAB2を作成します。

SQL> CREATE TABLE TAB1
2     (    "EMPNO" NUMBER(4,0),
3          "ENAME" VARCHAR2(10),
4          "JOB" VARCHAR2(9),
5          "DEPTNO" NUMBER(2,0)
6     ) ;

Table created.

SQL> CREATE TABLE TAB2
2     (    "EMPNO" NUMBER(4,0) PRIMARY KEY ENABLE,
3          "ENAME" VARCHAR2(20),
4          "MGR" NUMBER(4,0),
5          "DEPTNO" NUMBER(2,0)
6     ) ;

Table created.

表TAB1とTAB2の差異に注意します。

- 表名が異なります。

- TAB2には主キー制約がありますが、TAB1にはありません。

- それぞれの表で、ENAME列の長さが異なります。

- TAB1にはJOB列がありますが、TAB2にはありません。

- TAB2にはMGR列がありますが、TAB1にはありません。

2. SXML形式の表メタデータを返すファンクションを作成します。DBMS_METADATA_DIFF APIを使用するときに、SXMLに関して注意する必要がある重要な点について示します。

- SXMLはオブジェクト・メタデータのXML表現です。

- 返されるSXMLは、DBMS_METADATA.GET_XMLによって返されるXMLと同じではありません。その場合のXMLは、複雑かつ不透明であり、バイナリ値やインスタンス固有の値などが含まれます。

- SXMLは、SQL作成DDLを直接XMLに変換したものと考えることができます。タグ名と構造は、『Oracle Database SQL言語リファレンス』で説明されている名前に対応しています。

- SXMLは、編集と比較を行えるように設計されています。

ここでは例を単純にするため、変換パラメータを使用して物理プロパティを抑止します。

SQL> CREATE OR REPLACE FUNCTION get_table_sxml(name IN VARCHAR2) RETURN CLOB IS
2   open_handle NUMBER;
3   transform_handle NUMBER;
4   doc CLOB;
5  BEGIN
6   open_handle := DBMS_METADATA.OPEN('TABLE');
7   DBMS_METADATA.SET_FILTER(open_handle,'NAME',name);
8   --
9   -- Use the 'SXML' transform to convert XML to SXML
10   --
11   transform_handle := DBMS_METADATA.ADD_TRANSFORM(open_handle,'SXML');
12   --
13   -- Use this transform parameter to suppress physical properties
14   --
15   DBMS_METADATA.SET_TRANSFORM_PARAM(transform_handle,'PHYSICAL_PROPERTIES',
16                                     FALSE);
17   doc := DBMS_METADATA.FETCH_CLOB(open_handle);
18   DBMS_METADATA.CLOSE(open_handle);
19   RETURN doc;
20  END;
21  /

Function created.

3. 次のように、get_table_sxmlファンクションを使用して、2つの表の表SXMLをフェッチします。

SQL> SELECT get_table_sxml('TAB1') FROM dual;

<TABLE xmlns="http://xmlns.oracle.com/ku" version="1.0">
<SCHEMA>SCOTT</SCHEMA>
<NAME>TAB1</NAME>
<RELATIONAL_TABLE>
<COL_LIST>
<COL_LIST_ITEM>
<NAME>EMPNO</NAME>
<DATATYPE>NUMBER</DATATYPE>
<PRECISION>4</PRECISION>
<SCALE>0</SCALE>
</COL_LIST_ITEM>
<COL_LIST_ITEM>
<NAME>ENAME</NAME>
<DATATYPE>VARCHAR2</DATATYPE>
<LENGTH>10</LENGTH>
</COL_LIST_ITEM>
<COL_LIST_ITEM>
<NAME>JOB</NAME>
<DATATYPE>VARCHAR2</DATATYPE>
<LENGTH>9</LENGTH>
</COL_LIST_ITEM>
<COL_LIST_ITEM>
<NAME>DEPTNO</NAME>
<DATATYPE>NUMBER</DATATYPE>
<PRECISION>2</PRECISION>
<SCALE>0</SCALE>
</COL_LIST_ITEM>
</COL_LIST>
</RELATIONAL_TABLE>
</TABLE>

1 row selected.

SQL> SELECT get_table_sxml('TAB2') FROM dual;

<TABLE xmlns="http://xmlns.oracle.com/ku" version="1.0">
<SCHEMA>SCOTT</SCHEMA>
<NAME>TAB2</NAME>
<RELATIONAL_TABLE>
<COL_LIST>
<COL_LIST_ITEM>
<NAME>EMPNO</NAME>
<DATATYPE>NUMBER</DATATYPE>
<PRECISION>4</PRECISION>
<SCALE>0</SCALE>
</COL_LIST_ITEM>
<COL_LIST_ITEM>
<NAME>ENAME</NAME>
<DATATYPE>VARCHAR2</DATATYPE>
<LENGTH>20</LENGTH>
</COL_LIST_ITEM>
<COL_LIST_ITEM>
<NAME>MGR</NAME>
<DATATYPE>NUMBER</DATATYPE>
<PRECISION>4</PRECISION>
<SCALE>0</SCALE>
</COL_LIST_ITEM>
<COL_LIST_ITEM>
<NAME>DEPTNO</NAME>
<DATATYPE>NUMBER</DATATYPE>
<PRECISION>2</PRECISION>
<SCALE>0</SCALE>
</COL_LIST_ITEM>
</COL_LIST>
<PRIMARY_KEY_CONSTRAINT_LIST>
<PRIMARY_KEY_CONSTRAINT_LIST_ITEM>
<COL_LIST>
<COL_LIST_ITEM>
<NAME>EMPNO</NAME>
</COL_LIST_ITEM>
</COL_LIST>
</PRIMARY_KEY_CONSTRAINT_LIST_ITEM>
</PRIMARY_KEY_CONSTRAINT_LIST>
</RELATIONAL_TABLE>
</TABLE>

1 row selected.

4. 次のように、DBMS_METADATAブラウザAPIを使用して結果を比較します。

SQL> SELECT dbms_metadata.get_sxml('TABLE','TAB1') FROM dual;
SQL> SELECT dbms_metadata.get_sxml('TABLE','TAB2') FROM dual;

5. DBMS_METADATA_DIFF APIを使用してファンクションを作成し、2つの表のメタデータを比較します。このファンクションでは、手順2で定義したget_table_sxmlファンクションを使用します。

SQL> CREATE OR REPLACE FUNCTION compare_table_sxml(name1 IN VARCHAR2,
2                                          name2 IN VARCHAR2) RETURN CLOB IS
3   doc1 CLOB;
4   doc2 CLOB;
5   diffdoc CLOB;
6   openc_handle NUMBER;
7  BEGIN
8   --
9   -- Fetch the SXML for the two tables
10   --
11   doc1 := get_table_sxml(name1);
12   doc2 := get_table_sxml(name2);
13   --
14   -- Specify the object type in the OPENC call
15   --
16   openc_handle := DBMS_METADATA_DIFF.OPENC('TABLE');
17   --
18   -- Add each document
19   --
20   DBMS_METADATA_DIFF.ADD_DOCUMENT(openc_handle,doc1);
21   DBMS_METADATA_DIFF.ADD_DOCUMENT(openc_handle,doc2);
22   --
23   -- Fetch the SXML difference document
24   --
25   diffdoc := DBMS_METADATA_DIFF.FETCH_CLOB(openc_handle);
26   DBMS_METADATA_DIFF.CLOSE(openc_handle);
27   RETURN diffdoc;
28  END;
29  /

Function created.

6. 次のようにファンクションを使用して、2つの表のSXML差分ドキュメントをフェッチします。

SQL> SELECT compare_table_sxml('TAB1','TAB2') FROM dual;

<TABLE xmlns="http://xmlns.oracle.com/ku" version="1.0">
<SCHEMA>SCOTT</SCHEMA>
<NAME value1="TAB1">TAB2</NAME>
<RELATIONAL_TABLE>
<COL_LIST>
<COL_LIST_ITEM>
<NAME>EMPNO</NAME>
<DATATYPE>NUMBER</DATATYPE>
<PRECISION>4</PRECISION>
<SCALE>0</SCALE>
</COL_LIST_ITEM>
<COL_LIST_ITEM>
<NAME>ENAME</NAME>
<DATATYPE>VARCHAR2</DATATYPE>
<LENGTH value1="10">20</LENGTH>
</COL_LIST_ITEM>
<COL_LIST_ITEM src="1">
<NAME>JOB</NAME>
<DATATYPE>VARCHAR2</DATATYPE>
<LENGTH>9</LENGTH>
</COL_LIST_ITEM>
<COL_LIST_ITEM>
<NAME>DEPTNO</NAME>
<DATATYPE>NUMBER</DATATYPE>
<PRECISION>2</PRECISION>
<SCALE>0</SCALE>
</COL_LIST_ITEM>
<COL_LIST_ITEM src="2">
<NAME>MGR</NAME>
<DATATYPE>NUMBER</DATATYPE>
<PRECISION>4</PRECISION>
<SCALE>0</SCALE>
</COL_LIST_ITEM>
</COL_LIST>
<PRIMARY_KEY_CONSTRAINT_LIST src="2">
<PRIMARY_KEY_CONSTRAINT_LIST_ITEM>
<COL_LIST>
<COL_LIST_ITEM>
<NAME>EMPNO</NAME>
</COL_LIST_ITEM>
</COL_LIST>
</PRIMARY_KEY_CONSTRAINT_LIST_ITEM>
</PRIMARY_KEY_CONSTRAINT_LIST>
</RELATIONAL_TABLE>
</TABLE>

1 row selected.

SXML差分ドキュメントでは、2つのSXMLドキュメントの結合内容が示され、差分を識別するXML属性value1およびsrcが使用されます。ある要素が1つのドキュメントのみに存在するときは、その要素がsrcでマーキングされます。したがって、<COL_LIST_ITEM src="1">は、この要素が最初のドキュメント(TAB1)に含まれていて、2番目のドキュメントに含まれていないことを表します。ある要素が両方のドキュメントに存在し、値がそれぞれ異なる場合、この要素の値は2番目のドキュメント内の値とされ、value1によって最初のドキュメント内のその値が示されます。たとえば、<LENGTH value1="10">20</LENGTH>は、長さがTAB1(最初のドキュメント)では10、TAB2では20であることを表します。

7. 次のように、DBMS_METADATA_DIFFブラウザAPIを使用して、結果を比較します。

SQL> SELECT dbms_metadata_diff.compare_sxml('TABLE','TAB1','TAB2') FROM dual;

8. DBMS_METADATA.CONVERT APIを使用してファンクションを作成し、ALTERXMLドキュメントを生成します。これは、片方のオブジェクトをもう一方のオブジェクトと同様にするためのALTER文が含まれているXML文書です。解析項目を使用して、個々のALTER文に関する情報を取得することもできます。(この例ではこれまでに定義したファンクションを使用しています。)

SQL> CREATE OR REPLACE FUNCTION get_table_alterxml(name1 IN VARCHAR2,
2                                           name2 IN VARCHAR2) RETURN CLOB IS
3   diffdoc CLOB;
4   openw_handle NUMBER;
5   transform_handle NUMBER;
6   alterxml CLOB;
7  BEGIN
8   --
9   -- Use the function just defined to get the difference document
10   --
11   diffdoc := compare_table_sxml(name1,name2);
12   --
13   -- Specify the object type in the OPENW call
14   --
15   openw_handle := DBMS_METADATA.OPENW('TABLE');
16   --
17   -- Use the ALTERXML transform to generate the ALTER_XML document
18   --
19   transform_handle := DBMS_METADATA.ADD_TRANSFORM(openw_handle,'ALTERXML');
20   --
21   -- Request parse items
22   --
23   DBMS_METADATA.SET_PARSE_ITEM(openw_handle,'CLAUSE_TYPE');
24   DBMS_METADATA.SET_PARSE_ITEM(openw_handle,'NAME');
25   DBMS_METADATA.SET_PARSE_ITEM(openw_handle,'COLUMN_ATTRIBUTE');
26   --
27   -- Create a temporary LOB
28   --
29   DBMS_LOB.CREATETEMPORARY(alterxml, TRUE );
30   --
31   -- Call CONVERT to do the transform
32   --
33   DBMS_METADATA.CONVERT(openw_handle,diffdoc,alterxml);
34   --
35   -- Close context and return the result
36   --
37   DBMS_METADATA.CLOSE(openw_handle);
38   RETURN alterxml;
39  END;
40  /

Function created.

9. 次のようにファンクションを使用して、ALTER_XML文書をフェッチします。

SQL> SELECT get_table_alterxml('TAB1','TAB2') FROM dual;

<ALTER_XML xmlns="http://xmlns.oracle.com/ku" version="1.0">
<OBJECT_TYPE>TABLE</OBJECT_TYPE>
<OBJECT1>
<SCHEMA>SCOTT</SCHEMA>
<NAME>TAB1</NAME>
</OBJECT1>
<OBJECT2>
<SCHEMA>SCOTT</SCHEMA>
<NAME>TAB2</NAME>
</OBJECT2>
<ALTER_LIST>
<ALTER_LIST_ITEM>
<PARSE_LIST>
<PARSE_LIST_ITEM>
<ITEM>NAME</ITEM>
<VALUE>MGR</VALUE>
</PARSE_LIST_ITEM>
<PARSE_LIST_ITEM>
<ITEM>CLAUSE_TYPE</ITEM>
<VALUE>ADD_COLUMN</VALUE>
</PARSE_LIST_ITEM>
</PARSE_LIST>
<SQL_LIST>
<SQL_LIST_ITEM>
<TEXT>ALTER TABLE "SCOTT"."TAB1" ADD ("MGR" NUMBER(4,0))</TEXT>
</SQL_LIST_ITEM>
</SQL_LIST>
</ALTER_LIST_ITEM>
<ALTER_LIST_ITEM>
<PARSE_LIST>
<PARSE_LIST_ITEM>
<ITEM>NAME</ITEM>
<VALUE>JOB</VALUE>
</PARSE_LIST_ITEM>
<PARSE_LIST_ITEM>
<ITEM>CLAUSE_TYPE</ITEM>
<VALUE>DROP_COLUMN</VALUE>
</PARSE_LIST_ITEM>
</PARSE_LIST>
<SQL_LIST>
<SQL_LIST_ITEM>
<TEXT>ALTER TABLE "SCOTT"."TAB1" DROP ("JOB")</TEXT>
</SQL_LIST_ITEM>
</SQL_LIST>
</ALTER_LIST_ITEM>
<ALTER_LIST_ITEM>
<PARSE_LIST>
<PARSE_LIST_ITEM>
<ITEM>NAME</ITEM>
<VALUE>ENAME</VALUE>
</PARSE_LIST_ITEM>
<PARSE_LIST_ITEM>
<ITEM>CLAUSE_TYPE</ITEM>
<VALUE>MODIFY_COLUMN</VALUE>
</PARSE_LIST_ITEM>
<PARSE_LIST_ITEM>
<ITEM>COLUMN_ATTRIBUTE</ITEM>
<VALUE> SIZE_INCREASE</VALUE>
</PARSE_LIST_ITEM>
</PARSE_LIST>
<SQL_LIST>
<SQL_LIST_ITEM>
<TEXT>ALTER TABLE "SCOTT"."TAB1" MODIFY
("ENAME" VARCHAR2(20))
</TEXT>
</SQL_LIST_ITEM>
</SQL_LIST>
</ALTER_LIST_ITEM>
<ALTER_LIST_ITEM>
<PARSE_LIST>
<PARSE_LIST_ITEM>
<ITEM>CLAUSE_TYPE</ITEM>
<VALUE>ADD_CONSTRAINT</VALUE>
</PARSE_LIST_ITEM>
</PARSE_LIST>
<SQL_LIST>
<SQL_LIST_ITEM>
<TEXT>ALTER TABLE "SCOTT"."TAB1" ADD  PRIMARY KEY
("EMPNO") ENABLE
</TEXT>
</SQL_LIST_ITEM>
</SQL_LIST>
</ALTER_LIST_ITEM>
<ALTER_LIST_ITEM>
<PARSE_LIST>
<PARSE_LIST_ITEM>
<ITEM>NAME</ITEM>
<VALUE>TAB1</VALUE>
</PARSE_LIST_ITEM>
<PARSE_LIST_ITEM>
<ITEM>CLAUSE_TYPE</ITEM>
<VALUE>RENAME_TABLE</VALUE>
</PARSE_LIST_ITEM>
</PARSE_LIST>
<SQL_LIST>
<SQL_LIST_ITEM>
<TEXT>ALTER TABLE "SCOTT"."TAB1" RENAME TO "TAB2"</TEXT>
</SQL_LIST_ITEM>
</SQL_LIST>
</ALTER_LIST_ITEM>
</ALTER_LIST>
</ALTER_XML>

1 row selected.

10. 次のように、DBMS_METADATA_DIFFブラウザAPIを使用して、結果を比較します。

SQL> SELECT dbms_metadata_diff.compare_alter_xml('TABLE','TAB1','TAB2') FROM dual;

11. ALTER_XML文書には、それぞれの変更のALTER_LISTが含まれています。それぞれのALTER_LIST_ITEMには、名前と値のペアとしての解析項目が含まれたPARSE_LISTと、特定の変更のSQLが含まれたSQL_LISTがあります。PARSE_LIST内の情報を使用してこの文書を解析し、どのSQL文を実行するかを決定できます。(たとえば、この場合は、変更の1つがDROP_COLUMNであり、それを実行しないことを決定できます。)

12. 次のように、DBMS_METADATA.CONVERT APIおよびALTER DDL変換を使用する最後の1つのファンクションを作成して、ALTER_XML文書をSQL DDLに変換します。

SQL> CREATE OR REPLACE FUNCTION get_table_alterddl(name1 IN VARCHAR2,
2                                           name2 IN VARCHAR2) RETURN CLOB IS
3   alterxml CLOB;
4   openw_handle NUMBER;
5   transform_handle NUMBER;
6   alterddl CLOB;
7  BEGIN
8   --
9   -- Use the function just defined to get the ALTER_XML document
10   --
11   alterxml := get_table_alterxml(name1,name2);
12   --
13   -- Specify the object type in the OPENW call
14   --
15   openw_handle := DBMS_METADATA.OPENW('TABLE');
16   --
17   -- Use ALTERDDL transform to convert the ALTER_XML document to SQL DDL
18   --
19   transform_handle := DBMS_METADATA.ADD_TRANSFORM(openw_handle,'ALTERDDL');
20   --
21   -- Use the SQLTERMINATOR transform parameter to append a terminator
22   -- to each SQL statement
23   --
24   DBMS_METADATA.SET_TRANSFORM_PARAM(transform_handle,'SQLTERMINATOR',true);
25   --
26   -- Create a temporary lob
27   --
28   DBMS_LOB.CREATETEMPORARY(alterddl, TRUE );
29   --
30   -- Call CONVERT to do the transform
31   --
32   DBMS_METADATA.CONVERT(openw_handle,alterxml,alterddl);
33   --
34   -- Close context and return the result
35   --
36   DBMS_METADATA.CLOSE(openw_handle);
37   RETURN alterddl;
38  END;
39  /

Function created.

13. 次のようにファンクションを使用して、SQL ALTER文をフェッチします。

SQL> SELECT get_table_alterddl('TAB1','TAB2') FROM dual;
ALTER TABLE "SCOTT"."TAB1" ADD ("MGR" NUMBER(4,0))
/
ALTER TABLE "SCOTT"."TAB1" DROP ("JOB")
/
ALTER TABLE "SCOTT"."TAB1" MODIFY ("ENAME" VARCHAR2(20))
/
ALTER TABLE "SCOTT"."TAB1" ADD  PRIMARY KEY ("EMPNO") ENABLE
/
ALTER TABLE "SCOTT"."TAB1" RENAME TO "TAB2"
/

1 row selected.

14. 次のように、DBMS_METADATA_DIFFブラウザAPIを使用して、結果を比較します。

SQL> SELECT dbms_metadata_diff.compare_alter('TABLE','TAB1','TAB2') FROM dual;
ALTER TABLE "SCOTT"."TAB1" ADD ("MGR" NUMBER(4,0))
ALTER TABLE "SCOTT"."TAB1" DROP ("JOB")
ALTER TABLE "SCOTT"."TAB1" MODIFY ("ENAME" VARCHAR2(20))
ALTER TABLE "SCOTT"."TAB1" ADD  PRIMARY KEY ("EMPNO") USING INDEX
PCTFREE 10 INITRANS 2 STORAGE ( INITIAL 16384 NEXT 16384 MINEXTENTS 1
MAXEXTENTS 505 PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL
DEFAULT)  ENABLE ALTER TABLE "SCOTT"."TAB1" RENAME TO "TAB2"

1 row selected.

DBMS_METADATA APIのプログラム・インタフェースに関するパフォーマンスのヒント

この項では、DBMS_METADATA APIのプログラム・インタフェース使用時にパフォーマンスを向上する方法について説明します。

1. ある型のすべてのオブジェクトを、次の型のオブジェクトをフェッチする前にフェッチします。たとえば、スキーマ内に含まれるすべてのオブジェクトの定義を取得する場合は、まずすべての表をフェッチし、次にすべての索引をフェッチし、その次にすべてのトリガーをフェッチします。この方法は、OPENコンテキストをネストする方法(表をフェッチした後でそのすべての索引、権限およびトリガーをフェッチし、その後、次の表をフェッチした後でそのすべての索引、権限およびトリガーをフェッチするという方法)より非常に高速です。「DBMS_METADATA APIの使用例」では、この非効率な後者の方法が示されていますが、その例の目的はほとんどのプログラム・コールを示すことであり、この方法がその目的に最適です。

2. SET_COUNTプロシージャを使用して、複数のオブジェクトを一度に取得します。これによってサーバーのラウンドトリップが最小化され、多くの冗長なファンクション・コールが削減されます。

3. DBMS_METADATA APIをコールするPL/SQLパッケージを記述する場合、LOB変数およびLOBを含むオブジェクト(SYS.KU$_DDLSなど)は、個々のファンクション内ではなく、パッケージ・スコープで宣言します。これによって、ファンクションの開始および終了時に、負荷の高い操作である、LOBの存続時間構造の作成および削除が実行されなくなります。

DBMS_METADATA APIの使用例

この項では、DBMS_METADATA APIの使用例を示します。デモを自動的に実行するスクリプトの手順は、次のとおりです。

- スキーマ(MDDEMO)および何人かの従業員名簿のユーザーを確立します。

- スキーマ内に従業員名簿に似せた表を3つ作成し、関連する索引、トリガーおよび権限を作成します。

- DBMS_METADATA APIを使用するPAYROLL_DEMOというパッケージを作成します。PAYROLL_DEMOパッケージには、PAYROLLから始まるMDDEMOスキーマ内の2つの表のDDLを取得するGET_PAYROLL_TABLESというプロシージャを含めます。各表に対して、表の関連する依存オブジェクト、索引、権限およびトリガーのDDLを取得します。すべてのDDLは、MDDEMO.DDLという名前の表に書き込まれます。

例を実行するには、次の手順に従います。

1. ユーザーsystemとしてSQL*Plusを起動します。パスワードの入力を求められます。

sqlplus system

2. デモをインストールします。このデモは、rdbms/demoにあるファイルmddemo.sqlに含まれています。

SQL> @mddemo

この手順で行われる処理の詳細は、「DBMS_METADATAの例で行われる処理」を参照してください。

3. ユーザーmddemoとして接続します。パスワードを入力するように要求されます。パスワードもmddemoです。

SQL> CONNECT mddemo
Enter password:

4. 問合せの出力を完全なものにして読取り可能にするために、次のパラメータを設定します

SQL> SET PAGESIZE 0
SQL> SET LONG 1000000

5. 次のとおりGET_PAYROLL_TABLESプロシージャを実行します。

SQL> CALL payroll_demo.get_payroll_tables();

6. 次のSQL問合せを実行します。

SQL> SELECT ddl FROM DDL ORDER BY SEQNO;

生成される出力は、GET_PAYROLL_TABLESプロシージャの実行結果です。デモのインストール時に、手順2で行われたすべてのDDLが示されます。実際の出力のリストについては、「GET_PAYROLL_TABLESプロシージャで生成される出力」を参照してください。

DBMS_METADATAの例で行われる処理

mddemoスクリプトを実行すると、次の手順が行われます。これらの手順をユーザーの状況に合わせることができます。

1. ユーザーが存在する場合は、次のとおり削除します。これで、新しいデータを使用した作業が開始できます。ユーザーが存在しない場合は、その影響を示すメッセージが表示されますが、問題はありません。デモは継続して実行されます。

CONNECT system
Enter password: password
SQL> DROP USER mddemo CASCADE;
SQL> DROP USER mddemo_clerk CASCADE;
SQL> DROP USER mddemo_mgr CASCADE;

2. mddemoで識別されるユーザーmddemoを作成します。

SQL> CREATE USER mddemo IDENTIFIED BY mddemo;
SQL> GRANT resource, connect, create session,
1     create table,
2     create procedure,
3     create sequence,
4     create trigger,
5     create view,
6     create synonym,
7     alter session,
8  TO mddemo;

3. clerkで識別されるユーザーmddemo_clerkを作成します。

CREATE USER mddemo_clerk IDENTIFIED BY clerk;

4. mgrで識別されるユーザーmddemo_mgrを作成します。

CREATE USER mddemo_mgr IDENTIFIED BY mgr;

5. mddemoとしてSQL*Plusに接続します(パスワードもmddemoです)。

CONNECT mddemo
Enter password:

6. いくつかの従業員名簿型の表を作成します。

SQL> CREATE TABLE payroll_emps
2  ( lastname VARCHAR2(60) NOT NULL,
3  firstname VARCHAR2(20) NOT NULL,
4  mi VARCHAR2(2),
5  suffix VARCHAR2(10),
6  dob DATE NOT NULL,
7  badge_no NUMBER(6) PRIMARY KEY,
8  exempt VARCHAR(1) NOT NULL,
9  salary NUMBER (9,2),
10 hourly_rate NUMBER (7,2) )
11 /

SQL> CREATE TABLE payroll_timecards
2  (badge_no NUMBER(6) REFERENCES payroll_emps (badge_no),
3  week NUMBER(2),
4  job_id NUMBER(5),
5  hours_worked NUMBER(4,2) )
6 /

7. audit_trailというダミーの表を作成します。この表は、payrollで始まらない表は、GET_PAYROLL_TABLESプロシージャでは取得されないことを示すために使用します。

SQL> CREATE TABLE audit_trail
2  (action_time DATE,
3  lastname VARCHAR2(60),
4  action LONG )
5  /

8. 作成された表の権限を作成します。

SQL> GRANT UPDATE (salary,hourly_rate) ON payroll_emps TO mddemo_clerk;
SQL> GRANT ALL ON payroll_emps TO mddemo_mgr WITH GRANT OPTION;

SQL> GRANT INSERT,UPDATE ON payroll_timecards TO mddemo_clerk;
SQL> GRANT ALL ON payroll_timecards TO mddemo_mgr WITH GRANT OPTION;

9. 作成された表の索引を作成します。

SQL> CREATE INDEX i_payroll_emps_name ON payroll_emps(lastname);
SQL> CREATE INDEX i_payroll_emps_dob ON payroll_emps(dob);
SQL> CREATE INDEX i_payroll_timecards_badge ON payroll_timecards(badge_no);

10. 作成された表のトリガーを作成します。

SQL> CREATE OR REPLACE PROCEDURE check_sal( salary in number) AS BEGIN
2  RETURN;
3  END;
4  /

例を簡単にするために、セキュリティは比較的低く設定しています。

SQL> CREATE OR REPLACE TRIGGER salary_trigger BEFORE INSERT OR UPDATE OF salary
ON payroll_emps
FOR EACH ROW WHEN (new.salary > 150000)
CALL check_sal(:new.salary)
/

SQL> CREATE OR REPLACE TRIGGER hourly_trigger BEFORE UPDATE OF hourly_rate ON payroll_emps
FOR EACH ROW
BEGIN :new.hourly_rate:=:old.hourly_rate;END;
/

11. 生成されたDDLを保持する表を設定します。

CREATE TABLE ddl (ddl CLOB, seqno NUMBER);

12. DBMS_METADATAプロシージャを使用できる例を提供するPAYROLL_DEMOパッケージを作成します。

SQL> CREATE OR REPLACE PACKAGE payroll_demo AS PROCEDURE get_payroll_tables;
END;
/

注意:

PAYROLL_DEMOパッケージの内容を含めて、この例のスクリプト全体を参照するには、$ORACLE_HOME/rdbms/demoディレクトリにあるファイルmddemo.sqlを参照してください。

GET_PAYROLL_TABLESプロシージャで生成される出力

mddemo.payroll_demo.get_payroll_tables プロシージャの実行後に、次の問合せを実行できます。

SQL> SELECT ddl FROM ddl ORDER BY seqno;

結果は次のとおりです。前述の項で説明したとおり、スクリプトによって実行されたすべてのDDLが反映されます。

CREATE TABLE "MDDEMO"."PAYROLL_EMPS"
(    "LASTNAME" VARCHAR2(60) NOT NULL ENABLE,
"FIRSTNAME" VARCHAR2(20) NOT NULL ENABLE,
"MI" VARCHAR2(2),
"SUFFIX" VARCHAR2(10),
"DOB" DATE NOT NULL ENABLE,
"BADGE_NO" NUMBER(6,0),
"EXEMPT" VARCHAR2(1) NOT NULL ENABLE,
"SALARY" NUMBER(9,2),
"HOURLY_RATE" NUMBER(7,2),
PRIMARY KEY ("BADGE_NO") ENABLE
) ;

GRANT UPDATE ("SALARY") ON "MDDEMO"."PAYROLL_EMPS" TO "MDDEMO_CLERK";
GRANT UPDATE ("HOURLY_RATE") ON "MDDEMO"."PAYROLL_EMPS" TO "MDDEMO_CLERK";
GRANT ALTER ON "MDDEMO"."PAYROLL_EMPS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT DELETE ON "MDDEMO"."PAYROLL_EMPS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT INDEX ON "MDDEMO"."PAYROLL_EMPS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT INSERT ON "MDDEMO"."PAYROLL_EMPS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT SELECT ON "MDDEMO"."PAYROLL_EMPS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT UPDATE ON "MDDEMO"."PAYROLL_EMPS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT REFERENCES ON "MDDEMO"."PAYROLL_EMPS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT ON COMMIT REFRESH ON "MDDEMO"."PAYROLL_EMPS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT QUERY REWRITE ON "MDDEMO"."PAYROLL_EMPS" TO "MDDEMO_MGR" WITH GRANT OPTION;

CREATE INDEX "MDDEMO"."I_PAYROLL_EMPS_DOB" ON "MDDEMO"."PAYROLL_EMPS" ("DOB")
PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE(INITIAL 10240 NEXT 10240 MINEXTENTS 1 MAXEXTENTS 121 PCTINCREASE 50
FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "SYSTEM" ;

CREATE INDEX "MDDEMO"."I_PAYROLL_EMPS_NAME" ON "MDDEMO"."PAYROLL_EMPS" ("LASTNAME")
PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE(INITIAL 10240 NEXT 10240 MINEXTENTS 1 MAXEXTENTS 121 PCTINCREASE 50
FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "SYSTEM" ;

CREATE OR REPLACE TRIGGER hourly_trigger before update of hourly_rate on payroll_emps
for each row
begin :new.hourly_rate:=:old.hourly_rate;end;
/
ALTER TRIGGER "MDDEMO"."HOURLY_TRIGGER" ENABLE;

CREATE OR REPLACE TRIGGER salary_trigger before insert or update of salary on payroll_emps
for each row
WHEN (new.salary > 150000)  CALL check_sal(:new.salary)
/
ALTER TRIGGER "MDDEMO"."SALARY_TRIGGER" ENABLE;

CREATE TABLE "MDDEMO"."PAYROLL_TIMECARDS"
(    "BADGE_NO" NUMBER(6,0),
"WEEK" NUMBER(2,0),
"JOB_ID" NUMBER(5,0),
"HOURS_WORKED" NUMBER(4,2),
FOREIGN KEY ("BADGE_NO")
REFERENCES "MDDEMO"."PAYROLL_EMPS" ("BADGE_NO") ENABLE
) ;

GRANT INSERT ON "MDDEMO"."PAYROLL_TIMECARDS" TO "MDDEMO_CLERK";
GRANT UPDATE ON "MDDEMO"."PAYROLL_TIMECARDS" TO "MDDEMO_CLERK";
GRANT ALTER ON "MDDEMO"."PAYROLL_TIMECARDS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT DELETE ON "MDDEMO"."PAYROLL_TIMECARDS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT INDEX ON "MDDEMO"."PAYROLL_TIMECARDS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT INSERT ON "MDDEMO"."PAYROLL_TIMECARDS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT SELECT ON "MDDEMO"."PAYROLL_TIMECARDS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT UPDATE ON "MDDEMO"."PAYROLL_TIMECARDS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT REFERENCES ON "MDDEMO"."PAYROLL_TIMECARDS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT ON COMMIT REFRESH ON "MDDEMO"."PAYROLL_TIMECARDS" TO "MDDEMO_MGR" WITH GRANT OPTION;
GRANT QUERY REWRITE ON "MDDEMO"."PAYROLL_TIMECARDS" TO "MDDEMO_MGR" WITH GRANT OPTION;

CREATE INDEX "MDDEMO"."I_PAYROLL_TIMECARDS_BADGE" ON "MDDEMO"."PAYROLL_TIMECARDS" ("BADGE_NO")
PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE(INITIAL 10240 NEXT 10240 MINEXTENTS 1 MAXEXTENTS 121 PCTINCREASE 50
FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "SYSTEM" ;

DBMS_METADATAプロシージャの要約

この項では、DBMS_METADATA APIによって提供されるプロシージャを簡単に説明します。これらのプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

表21-1では、複数オブジェクトの取得に使用する、DBMS_METADATAプログラム・インタフェースのプロシージャを簡単に説明します。

表21-1 複数オブジェクトの取得に使用するDBMS_METADATAプロシージャ

PL/SQLプロシージャ名

説明

DBMS_METADATA.OPEN()

取得するオブジェクトの型、メタデータのバージョンおよびオブジェクト・モデルを指定します。

DBMS_METADATA.SET_FILTER()

取得するオブジェクトに、オブジェクト名、スキーマなどの制限を指定します。

DBMS_METADATA.SET_COUNT()

1回のFETCH_xxxコールで取得するオブジェクトの最大数を指定します。

DBMS_METADATA.GET_QUERY()

FETCH_xxxで使用される問合せのテキストを返します。これをデバッグの機能として使用できます。

DBMS_METADATA.SET_PARSE_ITEM()

解析して返すオブジェクトの属性を指定して、出力を解析に利用します。

DBMS_METADATA.ADD_TRANSFORM()

取得したオブジェクトのXML表現に、FETCH_xxxによって適用される変換を指定します。

DBMS_METADATA.SET_TRANSFORM_PARAM()

transform_handleで識別されるXSLTスタイルシートのパラメータを指定します。

DBMS_METADATA.SET_REMAP_PARAM()

transform_handleで識別されるXSLTスタイルシートのパラメータを指定します。

DBMS_METADATA.FETCH_xxx()

OPEN、SET_FILTER、SET_COUNT、ADD_TRANSFORMなどで確立された基準を満たすオブジェクトのメタデータを返します。

DBMS_METADATA.CLOSE()

OPENによって返されたハンドルを無効にし、関連付けられた状態をクリーンアップします。

表21-2では、DBMS_METADATAブラウザ・インタフェースで提供されるプロシージャを簡単に説明します。これらのファンクションは、1つ以上の依存オブジェクトまたは権限付与されたオブジェクトのメタデータを返します。これらのプロシージャでは、異種オブジェクト・タイプを処理できません。

表21-2 ブラウザ・インタフェースで使用するDBMS_METADATAプロシージャ

PL/SQLプロシージャ名

説明

DBMS_METADATA.GET_xxx()

シングル・オブジェクトに対してメタデータを返す方法を提供します。各GET_xxxコールは、OPENプロシージャ、1つか2つのSET_FILTERコール、ADD_TRANSFORMプロシージャ(オプション)、FETCH_xxxコールおよびCLOSEプロシージャで構成されます。

object_typeパラメータには、OPENプロシージャと同じセマンティクスが含まれます。schemaおよびnameはフィルタ処理に使用されます。

変換を指定した場合、セッション・レベルの変換フラグが継承されます。

DBMS_METADATA.GET_DEPENDENT_xxx()

XMLまたはDDLで指定したとおり、1つ以上の依存オブジェクトに対してメタデータが返されます。

DBMS_METADATA.GET_GRANTED_xxx()

XMLまたはDDLで指定したとおり、権限が付与された1つ以上のオブジェクトに対してメタデータが返されます。

表21-3では、XMLの送信で使用されるDBMS_METADATAプロシージャおよびファンクションを簡単に説明します。

表21-3 XMLデータの送信に使用するDBMS_METADATAのプロシージャおよびファンクション

PL/SQL名

説明

DBMS_METADATA.OPENW()

書込みコンテキストをオープンします。

DBMS_METADATA.ADD_TRANSFORM()

XML文書の変換を指定します。

DBMS_METADATA.SET_TRANSFORM_PARAM() and
DBMS_METADATA.SET_REMAP_PARAM()

SET_TRANSFORM_PARAMは、変換のパラメータを指定します。

SET_REMAP_PARAMは、変換の再マップを指定します。

DBMS_METADATA.SET_PARSE_ITEM()

解析するオブジェクト属性を指定します。

DBMS_METADATA.CONVERT()

XML文書をDDLに変換します。

DBMS_METADATA.PUT()

データベースにXML文書を送信します。

DBMS_METADATA.CLOSE()

OPENWでオープンしたコンテキストをクローズします。

DBMS_METADATA_DIFFプロシージャの要約

この項では、DBMS_METADATA_DIFF APIによって提供されるプロシージャおよびファンクションを簡単に説明します。これらのプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

表21-4 DBMS_METADATA_DIFFのプロシージャおよびファンクション

PL/SQLプロシージャ名

説明

OPENC関数

比較するオブジェクトの型を指定します。

ADD_DOCUMENTプロシージャ

比較するSXMLドキュメントを指定します。

FETCH_CLOBファンクションおよびプロシージャ

ADD_DOCUMENTで指定した2つのドキュメント間の差異を示すCLOBを返します。

CLOSEプロシージャ

OPENCによって返されたハンドルを無効にし、関連付けられた状態をクリーンアップします。

22 オリジナルのエクスポート

オリジナルのエクスポート・ユーティリティ(exp)により、Oracle Databaseのデータをオペレーティング・システムのファイルにバイナリ形式で書き込みます。このファイルはデータベースの外部に格納されるため、オリジナルのインポート・ユーティリティを使用して、別のOracle Databaseに読み込むことができます。

注意:

オリジナルのエクスポートは、Oracle Database 11gからは原則としてサポートされなくなりました。Oracle Database 11gで唯一サポートされているオリジナルのエクスポートの使用法は、XMLTypeデータのOracle Database 10gリリース2 (10.2)以前への下位移行です。したがって、オリジナルのエクスポートおよびインポートが必要な次の場合を除いて、データ・ポンプ・エクスポートおよびインポート・ユーティリティを使用することをお薦めします。

- オリジナルのエクスポート・ユーティリティ(exp)を使用して作成されたファイルをインポートする必要がある。

- オリジナルのインポート・ユーティリティ(imp)を使用してインポートされるファイルをエクスポートする必要がある。このような例として考えられるのは、Oracle Database 10gからデータをエクスポートし、それより前のデータベース・リリースにインポートする場合です。

次のトピックを参照してください。

- エクスポート・ユーティリティとは

- エクスポート・ユーティリティを使用する前に

- エクスポート・ユーティリティの起動

- エクスポート・モード

- エクスポート・パラメータ

- エクスポート・セッションの例

- 警告、エラーおよび完了メッセージ

- 終了コードによる結果の検査と表示

- 従来型パス・エクスポートとダイレクト・パス・エクスポート

- ダイレクト・パス・エクスポートの起動

- ネットワークに関する考慮点

- キャラクタ・セットおよびグローバリゼーション・サポートに関する考慮点

- エクスポート・ユーティリティおよびインポート・ユーティリティでのインスタンス親和性の使用

- データベース・オブジェクトのエクスポート時の考慮点

- トランスポータブル表領域

- 読取り専用データベースからのエクスポート

- エクスポート・ユーティリティおよびインポート・ユーティリティを使用したデータベース移行のパーティション化

- リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用

エクスポート・ユーティリティとは

エクスポート・ユーティリティでは、異なるハードウェアおよびソフトウェア構成を持つプラットフォームに存在している場合でもOracle Database間で簡単にデータ・オブジェクトを転送できます。

Oracle Databaseに対してエクスポート・ユーティリティを実行すると、オブジェクト(表など)が抽出された後で、存在しているその関連のオブジェクト(索引、コメント、権限など)が抽出されます。

エクスポート・ファイルは、通常はディスクまたはテープに格納されるOracleバイナリ形式のダンプ・ファイルです。ダンプ・ファイルは、FTPを使用して転送するか、物理的に(テープの場合)異なる場所に転送できます。その後は、ファイルにインポート・ユーティリティを使用して、ネットワークで接続されていないシステム上のデータベース間でデータを転送できます。このファイルは、通常のバックアップ手順を行った上で、バックアップとして使用することもできます。

エクスポート・ダンプ・ファイルは、Oracleのインポート・ユーティリティのみで読み取ることができます。ダンプ・ファイルの作成に使用したエクスポート・ユーティリティより前のバージョンのインポート・ユーティリティは使用できません。

実際にインポートを実行せずに、エクスポート・ファイルの内容を表示することもできます。これを行うには、Import SHOWパラメータを使用します。詳細は、「SHOW」を参照してください。ASCII固定形式またはデリミタ付きファイルからデータをロードするには、SQL*Loaderユーティリティを使用します。

エクスポート・ユーティリティを使用する前に

エクスポート・ユーティリティを使用する前に、次のことを行う必要があります(詳細は以降の項を参照してください)。

- データベースを手動で作成した場合は、catexp.sqlまたはcatalog.sqlスクリプトが実行されたことの確認。Database Configuration Assistant(DBCA)を使用してデータベースを作成した場合は、これらのスクリプトを実行する必要はありません。

- エクスポート・ファイルを書き込むための十分なディスクまたはテープ記憶域が存在することの確認

- 必要なアクセス権限を所有していることの確認

catexp.sqlまたはcatalog.sqlの実行

エクスポート・ユーティリティを使用するには、データベースを作成するかまたは新しいリリースに移行した後で、スクリプトcatexp.sqlまたは(catexp.sqlを実行する)catalog.sqlを実行する必要があります。

データベースに対して、catexp.sqlまたはcatalog.sqlを実行するのは1回のみです。スクリプトを実行すると、次の処理が行われ、データベースはエクスポートおよびインポート操作に備えて調整されます。

- データ・ディクショナリへの必要なエクスポート・ビューおよびインポート・ビューの作成

- EXP_FULL_DATABASEロールおよびIMP_FULL_DATABASEロールの作成

- EXP_FULL_DATABASEおよびIMP_FULL_DATABASEロールへのすべての必要な権限の割当て

- DBAロールへのEXP_FULL_DATABASEおよびIMP_FULL_DATABASEの割当て

- インストールされているcatexp.sqlのバージョンの記録

EXP_FULL_DATABASEロールおよびIMP_FULL_DATABASEロールは強力です。これらのロールをユーザーに付与する際は、十分に注意する必要があります。

エクスポート操作に必要な十分なディスク領域の確保

エクスポートを実行する前に、エクスポート・ファイルを書き込むための十分なディスクまたはテープのストレージが存在することを確認してください。十分な領域がないと、エクスポート・ユーティリティは書込み失敗エラーが発生して終了します。

表のサイズから、必要な最大領域を見積もることもできます。表のサイズは、Oracleデータ・ディクショナリのUSER_SEGMENTSビューで確認できます。次の問合せでは、すべての表のディスク使用率が表示されます。

SELECT SUM(BYTES) FROM USER_SEGMENTS WHERE SEGMENT_TYPE='TABLE';

問合せの結果には、LOB(ラージ・オブジェクト)またはVARRAY列あるいはパーティション表に格納されているデータ用のディスク領域は含まれません。

関連項目:

ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください

エクスポート操作およびインポート操作のアクセス権の確認

エクスポート・ユーティリティを使用するには、Oracle Databaseに対するCREATE SESSION権限が必要です。この権限は、データベースの作成時に設定されるCONNECTロールに含まれます。別のユーザーが所有している表をエクスポートするには、EXP_FULL_DATABASEロールを有効にする必要があります。このロールは、すべてのデータベース管理者(DBA)に付与されます。

EXP_FULL_DATABASEロールに含まれているシステム権限を持っていないと、別のユーザーのスキーマ内のオブジェクトをエクスポートできません。たとえば、そのシノニムを作成した場合でも、別のユーザーのスキーマ内の表をエクスポートできません。

一部のシステム・スキーマは、ユーザー・スキーマではないため、エクスポートできません。システム・スキーマには、Oracleが管理するデータおよびメタデータが含まれています。エクスポートされないスキーマの例としては、SYS、ORDSYS、MDSYSなどがあります。

エクスポート・ユーティリティの起動

次のいずれかの方法を使用して、エクスポート・ユーティリティの起動およびパラメータの指定ができます。

- コマンドライン

- パラメータ・ファイル

- 対話方式モード

これらのいずれかの方法を使用する前に、使用可能なパラメータについての説明を必ず読んでください。詳細は、「エクスポート・パラメータ」を参照してください。

SYSDBAでのエクスポート・ユーティリティの起動

SYSDBAは内部的に使用され、一般ユーザーとは異なる特別な機能を持ちます。そのため、通常、次の場合以外は、エクスポート・ユーティリティをSYSDBAで起動する必要はありません。

- Oracleサポート・サービスから要求された場合

- トランスポータブル表領域セットをインポートする場合

コマンドライン・エントリ

次の構文を使用して、すべての有効なパラメータおよびその値をコマンドラインから指定できます(ユーザー名とパスワードを入力するように要求されます)。

exp PARAMETER=value

または

exp PARAMETER=(value1,value2,...,valuen)

システムでのコマンドラインの最大長を超える数のパラメータは指定できません。

パラメータ・ファイル

パラメータ・ファイルに、すべての有効なパラメータおよびその値を指定できます。複数のパラメータを1つのファイルに格納することによって、これらを簡単に変更したり再利用することができます。これは、エクスポート・ユーティリティの起動にも推奨される方法です。データベースごとに別のパラメータを使用する場合は、複数のパラメータ・ファイルを作成できるので、それぞれにパラメータ・ファイルを用意すると便利です。

フラット・ファイル用のテキスト・エディタを使用してパラメータ・ファイルを作成します。コマンドライン・オプションPARFILE=filenameを指定すると、エクスポート・ユーティリティは、コマンドラインからではなく指定されたファイルからパラメータを読み込みます。次に例を示します。

パラメータ・ファイル指定の構文は、次のいずれかを使用します。

PARAMETER=value
PARAMETER=(value)
PARAMETER=(value1, value2, ...)

次に、パラメータ・ファイル内のリストの一部を示します。

FULL=y
FILE=dba.dmp
GRANTS=y
INDEXES=y
CONSISTENT=y

注意:

パラメータ・ファイルの最大サイズは、オペレーティング・システムによって制限されます。また、パラメータ・ファイル名はオペレーティング・システムのネーミング規則に従います。

シャープ(#)記号を使用すると、パラメータ・ファイルにコメントを追加できます。シャープ(#)の右側にある文字はすべて無視されます。

コマンドラインでのパラメータの入力と同時にパラメータ・ファイルを指定できます。実際、パラメータ・ファイルとコマンドラインの両方に同じパラメータを指定することもできます。コマンドラインでのPARFILEパラメータと他のパラメータの位置によって、優先されるパラメータが決まります。たとえば、パラメータ・ファイルparams.datにパラメータINDEXES=yを指定し、エクスポート・ユーティリティを次のコマンドラインで起動するとします。

exp PARFILE=params.dat INDEXES=n

この場合、INDEXES=nはPARFILE=params.datの後にあるため、パラメータ・ファイルに指定されているINDEXESパラメータの値は、INDEXES=nによって上書きされます。

対話方式モード

各パラメータの値をプロンプトで入力するには、コマンドラインでexpを指定するだけです。ユーザー名とパスワードを入力するように要求されます。

その後、一般的に使用されるパラメータが表示されます。デフォルト値を受け入れるか(示された場合)、または異なる値を入力できます。コマンドライン対話方式では、すべての機能に関してプロンプトが表示されるわけではありません。また、コマンドライン対話方式は下位互換用のみに提供されています。対話方式のインタフェースを使用する場合は、Oracle Enterprise Managerのエクスポート・ウィザードを使用することをお薦めします。

対話方式でのエクスポートを使用する際の制限事項

対話方式による方法を使用する場合は、次のことに注意してください。

- ユーザー・モードでは、データをエクスポートする前にすべてのユーザー名をエクスポートに含めるように要求されます。ユーザー・リストの終わりを指定して現在のエクスポート・セッションを開始するには、[Enter]を押します。

- 表モードでは、スキーマの接頭辞を指定しないと、デフォルトによりエクスポート実行者のスキーマ、または現在のセッション内の最後にエクスポートされた表が含まれているスキーマになります。
たとえば、bethが表モードでエクスポートする特権ユーザーの場合、別のスキーマが指定されるまで、すべての表がbethスキーマに存在するとみなされます。別のユーザーのスキーマ内の表をエクスポートできるのは、特権ユーザー(EXP_FULL_DATABASEロールを持っているユーザー)のみです。

- エクスポートする表を指定するプロンプトで、NULL表リストを指定すると、エクスポート・ユーティリティは終了します。

オンライン・ヘルプの利用

エクスポート・ユーティリティには、オンライン・ヘルプがあります。エクスポート・ユーティリティのヘルプを表示するには、コマンドラインでexp help=yを入力します。

エクスポート・モード

エクスポート・ユーティリティには、次の4種類の操作モードがあります。

- 全体エクスポート: データベース全体をエクスポートします。EXP_FULL_DATABASEロールを所有するユーザーのみが使用できます。FULLパラメータを使用してこのモードを指定します。

- 表領域モード: 特権ユーザーが表領域をOracle Database間で移動できます。TRANSPORT_TABLESPACEパラメータを使用してこのモードを指定します。

- ユーザー・モード: 所有するすべてのオブジェクト(表、権限、索引、プロシージャなど)をエクスポートできます。特権ユーザーがユーザー・モードでインポートする場合、指定したユーザー・グループのユーザーのスキーマにあるすべてのオブジェクトをインポートできます。エクスポート・ユーティリティでOWNERパラメータを使用してこのモードを指定します。

- 表モード: 特定の表およびパーティションをエクスポートできます。特権ユーザーは、インポートする表を含むスキーマを指定して、その表を修飾できます。スキーマ名が指定されていない表は、デフォルトでエクスポート実行者のスキーマ名になります。TABLESパラメータを使用してこのモードを指定します。

表22-1に、各モードでエクスポートおよびインポートされるオブジェクトのリストを示します。

注意:

遅延セグメント作成によって作成された表に、作成されたセグメントがない場合、オリジナルのエクスポート・ユーティリティではエクスポートされません。セグメントを作成する最も一般的な方法は表に行を格納することですが、ALTER TABLE ALLOCATE EXTENTSのような他の操作では、セグメントも作成されます。セグメントが存在する表をエクスポートすると、SEGMENT CREATION DEFERRED句は、オリジナルのインポート・ユーティリティによって実行されるCREATE TABLE文に含まれません。

従来型パス・エクスポートまたはダイレクト・パス・エクスポートを使用すると、表領域モード以外のどのモードでもエクスポートできます。従来型パス・エクスポートとダイレクト・パス・エクスポートの違いについては、「従来型パス・エクスポートとダイレクト・パス・エクスポート」を参照してください。

表22-1 各モードでエクスポートされるオブジェクト

オブジェクト

表モード

ユーザー・モード

全データベース・モード

表領域モード

分析クラスタ

なし

あり

あり

なし

分析表/統計

あり

あり

あり

あり

アプリケーション・コンテキスト

なし

なし

あり

なし

監査情報

あり

あり

あり

なし

Bツリー索引、ビットマップ索引、ドメイン・ファンクション索引

あり脚注1

あり

あり

あり

クラスタ定義

なし

あり

あり

あり

列コメントおよび表コメント

あり

あり

あり

あり

データベース・リンク

なし

あり

あり

なし

デフォルト・ロール

なし

なし

あり

なし

ディメンション

なし

あり

あり

なし

ディレクトリ別名

なし

なし

あり

なし

外部表(データなし)

あり

あり

あり

なし

外部関数ライブラリ

なし

あり

あり

なし

表の所有者以外のユーザーが所有する索引

あり(特権ユーザーのみ)

あり

あり

あり

索引タイプ

なし

あり

あり

なし

JavaリソースおよびJavaクラス

なし

あり

あり

なし

ジョブ・キュー

なし

あり

あり

なし

ネストした表のデータ

あり

あり

あり

あり

オブジェクト権限

あり(表および索引のみ)

あり

あり

あり

表で使用されるオブジェクト型定義

あり

あり

あり

あり

オブジェクト型

なし

あり

あり

なし

演算子

なし

あり

あり

なし

パスワード履歴

なし

なし

あり

なし

インスタンスの事後処理およびオブジェクト

なし

なし

あり

なし

スキーマの事後プロシージャ処理およびオブジェクト

なし

あり

あり

なし

表の事後処理

あり

あり

あり

あり

表の事後プロシージャ処理およびオブジェクト

あり

あり

あり

あり

スキーマの事前プロシージャ・オブジェクトおよび処理

なし

あり

あり

なし

表の事前処理

あり

あり

あり

あり

表の事前プロシージャ処理

あり

あり

あり

あり

プライベート・シノニム

なし

あり

あり

なし

プロシージャ・オブジェクト

なし

あり

あり

なし

プロファイル

なし

なし

あり

なし

パブリック・シノニム

なし

なし

あり

なし

参照整合性制約

あり

あり

あり

なし

リフレッシュ・グループ

なし

あり

あり

なし

リソース・コスト

なし

なし

あり

なし

ロール権限

なし

なし

あり

なし

ロール

なし

なし

あり

なし

ロールバック・セグメント定義

なし

なし

あり

なし

表のセキュリティ・ポリシー

あり

あり

あり

あり

順序番号

なし

あり

あり

なし

スナップショット・ログ

なし

あり

あり

なし

スナップショットおよびマテリアライズド・ビュー

なし

あり

あり

なし

システム権限

なし

なし

あり

なし

表制約(主キー制約、一意制約、CHECK制約)

あり

あり

あり

あり

表データ

あり

あり

あり

あり

表定義

あり

あり

あり

あり

表領域定義

なし

なし

あり

なし

表領域の割当て制限

なし

なし

あり

なし

トリガー

あり

あり脚注2

あり脚注3

あり

他のユーザーが所有するトリガー

あり(特権ユーザーのみ)

なし

なし

なし

ユーザー定義

なし

なし

あり

なし

ユーザー・プロキシ

なし

なし

あり

なし

ユーザー・ビュー

なし

あり

あり

なし

ユーザー・ストアド・プロシージャ、ユーザー・ストアド・パッケージおよびユーザー・ストアド・ファンクション

なし

あり

あり

なし

脚注1

非特権ユーザーがエクスポートおよびインポートできるのは、そのユーザー自身が所有する表に関する索引のみです。他のユーザーが所有する表に関する索引や、ユーザー自身が所有する表に関して他のユーザーが作成した索引はエクスポートできません。特権ユーザーは、エクスポートおよびインポート対象に指定したユーザーの表に関する索引が、表の所有者以外のユーザーが作成したものであっても、その索引をエクスポートおよびインポートできます。指定したユーザーが他のユーザーの表に関する索引を所有しているときは、エクスポートするユーザーのリストに表の所有者であるユーザーを指定しないかぎり、その索引はエクスポートされません。

脚注2

特権ユーザーも非特権ユーザーも、そのユーザー自身が所有するすべてのトリガーを(他のユーザーが所有する表に関するトリガーの場合でも)、エクスポートおよびインポートできます。

脚注3

全体エクスポートでは、スキーマSYSが所有するトリガーはエクスポートされません。SYSトリガーは、全体インポートの前後のいずれかに手動で再作成する必要があります。このトリガーによってインポートの進行を妨げるような処理が定義されないように、インポートの後に再作成することをお薦めします。

表レベル・エクスポートおよびパーティション・レベル・エクスポート

表、パーティションおよびサブパーティションのエクスポートは、次のように実行できます。

- 表レベル・エクスポート: 指定された表からすべてのデータをエクスポートします。

- パーティション・レベル・エクスポート: 指定されたソース・パーティションまたはサブパーティションのデータのみエクスポートします。

どのモードでも、パーティションデータは、パーティションまたはサブパーティションを選択してインポートできる形式でエクスポートされます。

表レベル・エクスポート

表レベル・エクスポートでは、その索引や他の表依存オブジェクトとともに表(パーティション表および非パーティション表)全体をエクスポートできます。表がパーティション化されている場合は、そのすべてのパーティションとサブパーティションもエクスポートされます。これは、ダイレクト・パス・エクスポートと従来型パス・エクスポートの両方に当てはまります。どのエクスポート・モードでも、表レベル・エクスポートを実行できます。

パーティション・レベル・エクスポート

パーティション・レベル・エクスポートでは、表内の指定された1つ以上のパーティションまたはサブパーティションをエクスポートできます。パーティション・レベル・エクスポートは、表モードでのみ実行できます。

表レベルおよびパーティション・レベルのエクスポートを指定する方法の詳細は、「TABLES」を参照してください。

エクスポート・パラメータ

この項では、エクスポート・コマンドライン・パラメータについて説明します。

BUFFER

デフォルト: オペレーティング・システムによって異なります。このパラメータのデフォルト値については、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

行のフェッチに使用するバッファのサイズをバイト単位で指定します。その結果、エクスポート・ユーティリティによってフェッチされる配列内の行の最大数が決まります。次の式を使用して、バッファ・サイズを計算します。

buffer_size = rows_in_array * maximum_row_size

ゼロを指定すると、1回に1行のみをフェッチします。

LOB型、LONG型、BFILE型、REF型、ROWID型、LOGICAL ROWID型またはDATE型の列を持つ表は、1回に1行ずつフェッチされます。

注意:

BUFFERパラメータは、従来型パス・エクスポートのみに適用されます。ダイレクト・パス・エクスポートには影響しません。ダイレクト・パス・エクスポートの場合は、RECORDLENGTHパラメータを使用して、エクスポート・ユーティリティでエクスポート・ファイルへの書き込みに使用されるバッファのサイズを指定します。

例: バッファ・サイズの計算

この項では、バッファ・サイズを計算する方法の例を示します。

次の表が作成されます。

CREATE TABLE sample (name varchar(30), weight number);

name列の最大サイズは、30バイトにインジケータ用の2バイトを加えた値です。weight列の最大サイズは、22バイト(Oracle数値の内部表現のサイズ)にインジケータ用の2バイトを加えた値です。

したがって、最大行サイズは56(30+2+22+2)です。

100行の配列操作を実行するには、バッファ・サイズを5600に指定する必要があります。

COMPRESS

デフォルト: y

エクスポート・ユーティリティおよびインポート・ユーティリティで、表データの初期エクステントをどのように管理するかを指定します。

エクスポート・ユーティリティでは、デフォルトによりCOMPRESS=yによって、インポート時に1つの初期エクステントに統合するためのフラグが表データに設定されます。エクステント・サイズが大きいと(たとえば、PCTINCREASEパラメータが使用されているため)、割り当てられる領域がデータの保持に必要な領域よりも大きくなります。

COMPRESS=nを指定すると、エクスポート・ユーティリティでは初期エクステント・サイズと次のエクステント・サイズの値を含めた現在の記憶域パラメータが使用されます。パラメータの値には、CREATE TABLE文またはALTER TABLE文で指定された値、あるいはデータベース・システムによって変更された値を使用できます。たとえば、NEXTエクステント・サイズの値は、表が大きくなった場合、およびPCTINCREASEパラメータがゼロ以外の値の場合に変更できます。

COMPRESSパラメータは、ビットマップ化表領域では機能しません。

注意:

実際の統合はインポート時に実行されますが、COMPRESSパラメータを指定できるのは、インポート時ではなくエクスポート時のみです。インポート・ユーティリティではなくエクスポート・ユーティリティによって、記憶域パラメータ定義などのデータ定義が生成されます。したがって、エクスポート時にCOMPRESS=yを指定した場合は、統合形式でのみデータをインポートできます。

注意:

LOBデータもサブパーティション・データも圧縮されません。エクスポート時の初期エクステント・サイズと次のエクステント・サイズの値が使用されます。

CONSISTENT

デフォルト: n

エクスポート・ユーティリティから見たデータが単一時点に対して一貫性がありexpコマンドの実行時に変更されないことを保証するために、エクスポート・ユーティリティでSET TRANSACTION READ ONLY文を使用するかどうかを指定します。エクスポートの開始後に、他のアプリケーションによるターゲット・データの更新が見込まれる場合は、CONSISTENT=yを指定する必要があります。

CONSISTENT=nを使用する場合、通常は1つのトランザクションでそれぞれの表がエクスポートされます。ただし、表にネストされた表が含まれている場合は、外部表とそれぞれの内部表が個別のトランザクションとしてエクスポートされます。表がパーティション化されている場合は、それぞれのパーティションが個別のトランザクションとしてエクスポートされます。

したがって、ネストされた表およびパーティション化された表が他のアプリケーションによって更新されると、エクスポートされるデータに不整合が生じる可能性があります。この可能性を最小限に抑えるには、更新が行われていないときにそれらの表をエクスポートします。

表22-2に、2人のユーザーによるイベントの順序を示します。user1は、表のパーティションをエクスポートし、user2はその表内のデータを更新します。

表22-2 2人のユーザーによる更新時のイベント順序

時間順序

user1

user2

1

表:P1のエクスポートを開始

アクティビティなし

2

アクティビティなし

表:P2を更新 表:P1を更新 トランザクションをコミット

3

表:P1のエクスポートを終了

アクティビティなし

4

表:P2をエクスポート

アクティビティなし

エクスポートでCONSISTENT=yを使用すると、user2による更新はエクスポート・ファイルに書き込まれません。

エクスポートでCONSISTENT=nを使用すると、表:P1に対する更新はエクスポート・ファイルに書き込まれません。ただし、表:P2に対する更新はエクスポート・ファイルに書き込まれます。これは、更新トランザクションが表:P2のエクスポート開始前にコミットされるためです。その結果、user2のトランザクションが部分的にのみエクスポート・ファイルに記録されて一貫性がなくなります。

CONSISTENT=yを使用し、更新のボリュームが大きい場合は、ロールバック・セグメントの使用量が大きくなります。また、それぞれの表のエクスポート速度が低下します。これはそのロールバック・セグメントで、コミットされていないトランザクションをスキャンする必要があるためです。

CONSISTENT=yの使用については、次のことに注意してください。

- ユーザーSYSとして接続しているか、AS SYSDBAを使用している(あるいはその両方)ときに実行されるエクスポートでは、CONSISTENT=yはサポートされません。

- ある特定のメタデータのエクスポートでは、再帰的SQL内でSYSスキーマを使用することが必要になる場合があります。そのような場合は、CONSISTENT=yを使用しても無視されます。CONSISTENT=yが選択されているエクスポート・プロセスの実行時は、メタデータの変更を行わないことをお薦めします。

- そのようなエクスポートに必要な時間と領域を最小限に抑えるには、一貫性を維持する必要がある表を、一貫性を維持する必要のない表とは別にエクスポートする必要があります。たとえば、一貫性エクスポートでemp表およびdept表を一緒にエクスポートし、データベースの他の部分を2番目のパスでエクスポートします。

- ロールバック領域を使い切り、コミットされたトランザクションで使用された領域を新しいトランザクションに再利用すると、スナップショットが古すぎるというエラーが発生します。ロールバック・セグメントで領域を再利用すると、最小限の領域要件でデータベースの一貫性を維持できますが、読取り一貫性イメージを保持できる時間は制限されます。
コミットされたトランザクションが上書きされ、データベースの読取り一貫性ビューに情報が必要になると、スナップショットが古すぎることによるエラーが発生します。

このエラーを回避するには、読取り一貫性エクスポートにかかる時間を最小限に抑える必要があります。(これを行うには、エクスポートされるオブジェクトの数を制限し、可能な場合は、データベースのトランザクション・レートを低下させます。)また、ロールバック・セグメントを可能なかぎり大きくします。

注意:

ロールバック・セグメントは将来のOracle Databaseリリースでは非推奨になります。かわりに、自動UNDO管理を使用することをお薦めします。

関連項目:

「OBJECT_CONSISTENT」

CONSTRAINTS

デフォルト: y

エクスポート・ユーティリティで表の制約をエクスポートするかどうかを指定します。

DIRECT

デフォルト: n

ダイレクト・パス・エクスポートを使用することを指定します。

エクスポート・ユーティリティでDIRECT=yを指定すると、データを直接読み取って、SQLコマンド処理レイヤー(評価バッファ)をバイパスすることでデータが抽出されます。この方式は、従来型パス・エクスポートよりも非常に高速になります。

セキュリティおよびパフォーマンスの考慮点を含めたダイレクト・パス・エクスポートの詳細は、「ダイレクト・パス・エクスポートの起動」を参照してください。

FEEDBACK

デフォルト: 0(ゼロ)

n行分のエクスポートを1つのピリオドで示すプログレス・バーの表示を指定します。たとえば、FEEDBACK=10を指定すると、10行分のエクスポートが終了するたびにピリオドが1つ表示されます。FEEDBACK値は、エクスポートされるすべての表に適用されるため、各表に対して個別には設定できません。

FILE

デフォルト: expdat.dmp

エクスポート・ダンプ・ファイル名を指定します。デフォルトの拡張子は、.dmpですが、任意の拡張子を指定できます。エクスポート・ユーティリティは複数のエクスポート・ファイルをサポートするので、使用する複数のファイル名を指定できます。次に例を示します。

exp scott FILE = dat1.dmp, dat2.dmp, dat3.dmp FILESIZE=2048

エクスポート・ユーティリティは、最大FILESIZEに指定された値に到達すると、現在のファイルへの書込みを停止し、FILEパラメータによって指定された次の名前を持つ別のエクスポート・ファイルを開いて、完了するかFILESIZEの最大値に再度到達するまで操作を続行します。エクスポートを完了するために十分なエクスポート・ファイル名を指定しないと、エクスポート・ユーティリティによって、追加のファイル名を指定するように要求されます。

FILESIZE

デフォルト: データは、表22-3で指定されているように、最大サイズになるまで1つのファイルに書き込まれます。

エクスポート・ユーティリティでは、複数のエクスポート・ファイルへの書込みがサポートされており、インポート・ユーティリティでは、複数のエクスポート・ファイルからの読取りが可能です。FILESIZEパラメータの値(バイト制限)を指定すると、エクスポート・ユーティリティでは、それぞれのダンプ・ファイルに指定したバイト数のみが書き込まれます。

エクスポート・ユーティリティは、書き込む必要があるデータの量がFILESIZEに指定された最大値を超えていると、FILEパラメータから次のエクスポート・ファイルの名前を取得するか(詳細は、「FILE」を参照)、FILEパラメータに指定された名前をすべて使用した場合は、新しいエクスポート・ファイルの名前を指定するように要求します。FILESIZEに値を指定しない場合(値0はFILESIZEを指定しないことに相当)、エクスポート・ユーティリティはFILEパラメータに指定されたファイル数に関係なく1つのファイルのみに書き込みます。

注意:

エクスポート・ファイルの領域要件が使用可能なディスク領域を超えていると、エクスポート・ユーティリティは終了します。十分な使用可能ディスク領域を有効にした後で、エクスポート・ユーティリティを繰り返す必要があります。

FILESIZEパラメータの最大値は、64ビットで格納できる最大値と同じです。

表22-3は、ダンプ・ファイルの最大サイズが、使用しているオペレーティング・システムおよび使用しているOracle Databaseによって異なることを示しています。

表22-3 ダンプ・ファイルの最大サイズ

オペレーティング・システム

Oracle Databaseのリリース

最大サイズ

任意

8.1.5より前

2GB

32ビット

8.1.5

2GB

64ビット

8.1.5以上

無制限

32ビットで32ビットファイルを使用

任意

2GB

32ビットで64ビットファイルを使用

8.1.6以上

無制限

ファイルに格納できる最大値は、オペレーティング・システムによって異なります。この最大値については、FILESIZEを指定する前に、ご使用のオペレーティング・システム固有のOracleマニュアルで確認してください。エクスポート・ユーティリティ用に指定するファイル・サイズが、インポート・ユーティリティを実行するシステムでサポートされていることも確認する必要があります。

FILESIZEの値は、数字にKB(キロバイト数)を付けて指定することもできます。たとえば、FILESIZE=2KBは、FILESIZE=2048と同じです。同様に、MBはメガバイト(1024×1024)を、GBはギガバイト(1024の3乗)を表します。Bはバイトの省略です。この場合、最終的なファイルサイズの算出に乗算は不要です(FILESIZE=2048Bは、FILESIZE=2048と同じです)。

FLASHBACK_SCN

デフォルト: none

エクスポート・ユーティリティで使用されるシステム変更番号(SCN)を指定して、フラッシュバックを使用可能にします。エクスポート操作は、この指定されたSCNにおけるデータの一貫性を維持したまま実行されます。

関連項目:

- フラッシュバック・リカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

次に、SCNの指定例を示します。このエクスポートを実行すると、SCN 3482971におけるデータの一貫性が維持されます。

> exp FILE=exp.dmp FLASHBACK_SCN=3482971

FLASHBACK_TIME

デフォルト: none

タイムスタンプを指定できます。エクスポート・ユーティリティは、指定されたタイムスタンプに最も近いSCNを検索します。このSCNを使用して、フラッシュバックを使用可能にします。エクスポート操作は、このSCNにおけるデータの一貫性を維持したまま実行されます。

DBMS_FLASHBACK.ENABLE_AT_TIMEプロシージャで使用可能な形式で時刻を指定できます。つまり、次のいずれかの方法で指定できます。

> exp FILE=exp.dmp FLASHBACK_TIME="TIMESTAMP '2006-05-01 11:00:00'"

> exp FILE=exp.dmp FLASHBACK_TIME="TO_TIMESTAMP('12-02-2005 14:35:00', 'DD-MM-YYYY HH24:MI:SS')"

また、次の例に示す古い形式も下位互換性を維持するために引き続き指定できます。

> exp FILE=exp.dmp FLASHBACK_TIME="'2006-05-01 11:00:00'"

関連項目:

- フラッシュバック・リカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- DBMS_FLASHBACK PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

FULL

デフォルト: n

エクスポートが全データベース・モード・エクスポートであることを示します(つまり、データベース全体をエクスポート)。FULL=yを指定して、全データベース・モードでエクスポートします。このモードでエクスポートするには、EXP_FULL_DATABASEロールが必要です。

全データベースのエクスポートおよびインポートについての考慮点

全データベースのエクスポートおよびインポートは、データベースの複製およびクリーンアップに有効です。ただし、問題が発生しないように、次の点に注意する必要があります。

- 全体エクスポートでは、スキーマSYSが所有するトリガーはエクスポートされません。SYSトリガーは、全体インポートの前後のいずれかに手動で再作成する必要があります。このトリガーによってインポートの進行を妨げるような処理が定義されないように、インポートの後に再作成することをお薦めします。

- 全体エクスポートでは、デフォルトのプロファイルもエクスポートされません。ソース・データベースでデフォルトのプロファイルを変更した場合(たとえば、スキーマSYSが所有するパスワード確認機能を追加するなど)は、事前に手動でその機能を作成し、インポートの完了後にターゲット・データベースでデフォルトのプロファイルを変更する必要があります。

- 可能な場合、開始前にエクスポートされたデータベースおよびインポートするデータベースの物理コピーを作成します。これによって、誤った操作をやり直すことができます。

- エクスポートの開始前に、次の情報を含むレポートを作成することをお薦めします。

- 表領域およびデータ・ファイルのリスト

- ロールバック・セグメントのリスト

- ユーザーごとの各オブジェクト型(表、索引など)の数

この情報で、表領域がすでに作成され、インポートが正常に完了したことを確認できます。

- エクスポートから完全に新しいデータベースを作成する場合、SYSTEMに余分なロールバック・セグメントを作成し、初期化パラメータ・ファイル(init.ora)で使用可能にしてからインポートを開始します。

- インポートの実行時に、正しいインスタンスを指していることを確認します。一部のUNIXシステムでは、サブシェルの入力のみで、インポート操作を行ったデータベースが変更される場合があります。

- すべての表領域が作成されるまで、複数のデータベースを含むシステムでは全体インポートを行わないでください。全体インポートは、エクスポートされたデータベースと同じデータ・ファイル名を使用して、未定義の表領域を作成します。このため、次のような状況で問題が発生します。

- データ・ファイルが他のいずれかのデータベースに属する場合、データ・ファイルは破損します。このことは特に、エクスポートされるデータベースが同じシステムに存在する場合に当てはまります(そのデータ・ファイルがインポート先のデータベースによって再利用されるため)。

- データ・ファイルの名前が既存のオペレーティング・システム・ファイルの名前と同じ場合も問題が発生します。

GRANTS

デフォルト: y

エクスポート・ユーティリティでオブジェクト権限をエクスポートするかどうかを指定します。エクスポートされるオブジェクト権限は、全データベースとユーザー・モードのどちらを使用するかによって異なります。全データベース・モードでは、表のすべての権限がエクスポートされます。ユーザー・モードでは、表の所有者によって付与されている権限のみがエクスポートされます。システム権限は常にエクスポートされます。

HELP

デフォルト: none

エクスポート・パラメータの説明を表示します。ヘルプの内容を表示するには、コマンドラインでexp help=yを入力します。

INDEXES

デフォルト: y

エクスポート・ユーティリティで索引をエクスポートするかどうかを指定します。

LOG

デフォルト: none

情報メッセージおよびエラー・メッセージを受け取るファイル名(export.logなど)を指定します。

このパラメータを指定すると、メッセージがログ・ファイルに記録されて、端末画面に表示されます。

OBJECT_CONSISTENT

デフォルト: n

エクスポートされたデータが単一時点に対して一貫性がありエクスポート中に変更されないことを保証するために、エクスポート・ユーティリティでSET TRANSACTION READ ONLY文を使用するかどうかを指定します。OBJECT_CONSISTENTをyに設定すると、パーティション化されている場合でも、自身の読取り専用トランザクションで各オブジェクトがエクスポートされます。一方、CONSISTENTパラメータを使用した場合は、1つの読取り専用トランザクションのみが存在します。

関連項目:

「CONSISTENT」

OWNER

デフォルト: none

エクスポートがユーザー・モード・エクスポートであることと、オブジェクトがエクスポートされるユーザーを指定します。エクスポートを開始するユーザーがデータベース管理者(DBA)の場合は、複数のユーザーをリストできます。

ユーザー・モード・エクスポートを使用して、1人以上のデータベース・ユーザーをバックアップできます。たとえばDBAは、削除されたユーザーの表を一定期間バックアップすることが必要な場合があります。ユーザー・モードは、自分のデータをバックアップする必要があるユーザー、または1人の所有者から別の所有者にオブジェクトを移動する必要があるユーザーにも適しています。

PARFILE

デフォルト: なし

エクスポート・パラメータのリストを格納するファイルのファイル名を指定します。パラメータ・ファイルの使用方法の詳細は、「エクスポート・ユーティリティの起動」を参照してください。

QUERY

デフォルト: none

このパラメータでは、表モード・エクスポートの実行時に、表のセットから行のサブセットを選択できます。問合せパラメータの値は、TABLESパラメータにリストされたすべての表(または表のパーティション)に適用されるSQL SELECT文のWHERE句が含まれている文字列です。

たとえば、ユーザーscottが、肩書きがSALESMANで給与が1600未満の従業員のみをエクスポートする場合は、次のように指定できます(この例はUNIXに基づいています)。

exp scott TABLES=emp QUERY=\"WHERE job=\'SALESMAN\' and sal \<1600\"

注意:

QUERYパラメータの値には空白が含まれるため、ほとんどのオペレーティング・システムでは、WHERE job=\'SALESMAN\'およびsal\<1600の文字列全体を二重引用符で囲むか、なんらかの方法でリテラルとしてマークする必要があります。オペレーティング・システムで予約されている文字も、エスケープ文字を前に付ける必要があります。システムの特殊文字および予約文字の詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

この問合せの実行中に、エクスポート・ユーティリティでは次のようなSQL SELECT文が構築されます。

SELECT * FROM emp WHERE job='SALESMAN' and sal <1600;

QUERYパラメータに指定された値は、TABLESパラメータにリストされているすべての表(または表のパーティション)に適用されます。たとえば、次の文では問合せに一致するempとbonusの両方にある行がアンロードされます。

exp scott TABLES=emp,bonus QUERY=\"WHERE job=\'SALESMAN\' and sal\<1600\"

また、エクスポート・ユーティリティでは次のようなSQL文が実行されます。

SELECT * FROM emp WHERE job='SALESMAN' and sal <1600;

SELECT * FROM bonus WHERE job='SALESMAN' and sal <1600;

表にQUERY句で指定された列が見つからないと、エラー・メッセージが生成され、その不適切な表については行がエクスポートされません。

QUERYパラメータを使用する際の制限事項

- QUERYパラメータは、全モード、ユーザー・モードまたは表領域モードのエクスポートには指定できません。

- QUERYパラメータは、指定されたすべての表に適用可能である必要があります。

- QUERYパラメータは、ダイレクト・パス・エクスポート(DIRECT=y)では指定できません。

- QUERYパラメータは、ネストされた内部表がある表には指定できません。

- データがQUERYエクスポートの結果かどうかを、エクスポート・ファイルの内容から判断することはできません。

RECORDLENGTH

デフォルト: オペレーティング・システムにより異なる

ファイル・レコードの長さをバイト単位で指定します。RECORDLENGTHパラメータは、異なるデフォルト値を使用する別のオペレーティング・システムにエクスポート・ファイルを転送する場合に指定する必要があります。

このパラメータを指定しない場合、ご使用のプラットフォーム固有のバッファ・サイズの値がデフォルトになります。

RECORDLENGTHは、ご使用のシステムのバッファ・サイズの値以上の任意の値に設定できます。(最大値は64KBです。)RECORDLENGTHパラメータの変更により影響を受けるのは、ディスクに書き出す前に累積されるデータのサイズのみです。オペレーティング・システム・ファイルのブロック・サイズには影響しません。

注意:

このパラメータは、エクスポート・ユーティリティのI/Oバッファのサイズ指定に使用できます。

RESUMABLE

デフォルト: n

RESUMABLEパラメータを使用して、再開可能な領域割当てを有効または無効にします。このパラメータはデフォルトでは無効なため、関連するRESUMABLE_NAMEおよびRESUMABLE_TIMEOUTを使用するには、RESUMABLE=yを設定する必要があります。

関連項目:

- 再開可能な領域割当ての詳細は、『Oracle Database管理者ガイド』を参照してください

RESUMABLE_NAME

デフォルト: 'User USERNAME(USERID), Session SESSIONID, Instance INSTANCEID'

再開可能な文を指定します。この値はユーザー定義のテキスト文字列で、USER_RESUMABLEまたはDBA_RESUMABLEビューに挿入して、一時停止されている特定の再開可能な文を識別できます。

RESUMABLEパラメータをyに設定して、再開可能な領域割当てを有効にしないかぎり、このパラメータは無視されます。

RESUMABLE_TIMEOUT

デフォルト: 7200秒(2時間)

エラー修正に必要な時間を指定します。タイムアウト時間内にエラーを修正できない場合は、文の実行が途中で終了します。

RESUMABLEパラメータをyに設定して、再開可能な領域割当てを有効にしないかぎり、このパラメータは無視されます。

ROWS

デフォルト: y

表のデータ行をエクスポートするかどうかを指定します。

STATISTICS

デフォルト: ESTIMATE

エクスポートされたデータのインポート時に生成するデータベース・オプティマイザ統計のタイプを指定します。オプションは、ESTIMATE、COMPUTEおよびNONEです。

エクスポート・ユーティリティによって計算済の統計情報がエクスポート・ファイルに含まれることがあります。また、ANALYZE文によって統計情報が再生成されることもあります。

ただし、表にシステム生成名を持つ列がある場合、計算済オプティマイザ統計情報はエクスポート時に使用されません。

計算済オプティマイザ統計情報のエクスポート時には、次の場合に、問題ありというフラグが付きます。

- エクスポート中に行エラーが発生している

- クライアントのキャラクタ・セットまたはNCHARキャラクタ・セットが、サーバーのキャラクタ・セットまたはNCHARキャラクタ・セットと一致していない

- QUERY句が指定されている

- 特定のパーティションまたはサブパーティションのみがエクスポートされている

注意:

ROWS=nを指定しても、計算済統計情報をエクスポート・ファイルに保存することはできます。この機能により、本番データベースからの統計情報を使用して、非本番データベース上で問合せの実行計画のチューニングを行うことができます。

TABLES

デフォルト: なし

表モード・エクスポートでエクスポートすることを指定します。また、エクスポートの対象となる表名、パーティション名およびサブパーティション名を指定します。表の名前を指定するときは、次のように指定します。

- schemanameは、表またはパーティションのエクスポート元のユーザー・スキーマの名前を指定します。スキーマ名が指定されていない場合は、エクスポート実行者のスキーマがデフォルトとして使用されます。ORDSYS、MDSYS、CTXSYS、LBACSYS、ORDPLUGINSなどのシステム・スキーマ名はエクスポート・ユーティリティによって予約されています。

- tablenameは、エクスポートされる表の名前を指定します。表レベル・エクスポートでは、パーティション表または非パーティション表全体をエクスポートできます。リストにパーティション表が含まれる場合、パーティション名を指定しないと、すべてのパーティションおよびサブパーティションがエクスポートされます。
表名は、任意の数の「%」パターン一致文字を含むことができます。各「%」パターン一致文字は、データベースの表オブジェクトに対し表名の0個以上の文字と一致します。指定されたパターンに一致する関連のスキーマ内のすべての表が、それぞれの表名がパラメータで明示的に指定されているとおりにエクスポートに選択されます。

- partition_nameは、エクスポートがパーティション・レベルのエクスポートであることを示します。パーティション・レベル・エクスポートでは、表内の指定された1つ以上のパーティションまたはサブパーティションをエクスポートできます。

構文の形式は、次のとおりです。

schemaname.tablename:partition_name
schemaname.tablename:subpartition_name

tablename:partition_nameを使用する場合、指定された表はパーティション化されている必要があり、partition_nameはパーティションまたはサブパーティションのうちのいずれかの名前である必要があります。指定された表がパーティション化されていない場合、partition_nameは無視され、表全体がエクスポートされます。

パーティション・レベル・エクスポートの例については、「パーティション・レベル・エクスポートでのエクスポート・セッションの例」を参照してください。

表名の制限

表名には次の制限があります。

- デフォルトでは、表名は大文字でデータベースに格納されます。表名が大文字と小文字または小文字のみで表記され、大/小文字を区別する場合、名前を引用符で囲む必要があります。したがって、表名は、データベースに格納されている表名と完全に一致するように指定する必要があります。
ただし、オペレーティング・システムによっては、コマンドラインの引用符自体をエスケープする必要がある場合があります。次に、異なるエクスポート・モードで大/小文字の区別を保持する方法を示します。

- コマンドライン・モード

TABLES='\"Emp\"'

- 対話方式モード

Table(T) to be exported: "Emp"

- パラメータ・ファイル・モード

TABLES='"Emp"'

- 表名を引用符で囲まないかぎり、コマンドラインで指定する表名にシャープ(#)記号は使用できません。同様に、パラメータ・ファイルでは、表名が引用符で囲まれていないかぎり、表名にシャープ(#)記号を使用すると、エクスポート・ユーティリティではシャープ(#)記号より右側の文字がコメントとして解釈されます。
たとえば、パラメータ・ファイルに次のコマンドラインが記述されている場合、エクスポート・ユーティリティではemp#の右側がすべてコメントとして解釈されるため、表deptおよびmydataはエクスポートされません。

TABLES=(emp#, dept, mydata)

ただし、次の例では、emp#が引用符で囲まれているため、3つの表はすべてエクスポートされます。

TABLES=("emp#", dept, mydata)

注意:

オペレーティング・システムによっては、一重引用符を使用する必要がある場合と、二重引用符を使用する必要がある場合があります。表のネーミング方法に制限があるオペレーティング・システムもあります。

TABLESPACES

デフォルト: none

TABLESPACESパラメータは、指定された表領域内のすべての表をエクスポートのダンプ・ファイルにエクスポートすることを指定します。これには、指定した表領域に含まれるすべての表と、指定した表領域にあるパーティションを持つすべての表が含まれます。索引は、索引の格納場所に関係なくその表とともにエクスポートされます。

TABLESPACESを使用して表領域内のすべての表をエクスポートするには、EXP_FULL_DATABASEロールが必要です。

TABLESPACESとTRANSPORT_TABLESPACE=yを組み合せて使用するときは、データベースからエクスポート・ファイルにエクスポートする表領域の制限付きリストを指定できます。

TRANSPORT_TABLESPACE

デフォルト: n

yを指定すると、トランスポータブル表領域のメタデータをエクスポートできるようになります。

暗号化された列は、トランスポータブル表領域モードではサポートされていません。

注意:

トランスポータブル表領域をエクスポートした後、それよりも古いリリース・レベルのデータベースにインポートすることはできません。ターゲット・データベースのリリース・レベルは、ソース・データベース以上である必要があります。

関連項目:

- 「トランスポータブル表領域」

- トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

TRIGGERS

デフォルト: y

エクスポート・ユーティリティでトリガーをエクスポートするかどうかを指定します。

TTS_FULL_CHECK

デフォルト: n

TTS_FULL_CHECKをyに設定すると、エクスポート・ユーティリティは、リカバリ・セット(リカバリする一連の表領域)がリカバリ・セットの外部のオブジェクトへの依存性(特に、INポインタ)を持たないこと(その逆も)を検証します。

USERID(ユーザー名/パスワード)

デフォルト: none

エクスポートを実行するユーザーのユーザー名、パスワードおよびオプションの接続文字列を指定します。パスワードを省略すると、指定するように要求されます。

ユーザーSYSとして接続する場合は、接続文字列にAS SYSDBAも指定する必要があります。オペレーティング・システムによっては、AS SYSDBAを特殊文字列とみなし、その文字列全体を引用符で囲む必要があります。

関連項目:

- Oracle Netに接続文字列を指定する方法の詳細は、ご使用のOracle Netプロトコルのユーザーズ・ガイドを参照してください

VOLSIZE

デフォルト: none

各テープ・ボリュームのエクスポート・ファイルに最大バイト数を指定します。

VOLSIZEパラメータの最大値は、ご使用のプラットフォーム上に64ビットで格納できる最大値と同じです。

VOLSIZEの値は、数字にKB(キロバイト数)を付けて指定できます。たとえば、VOLSIZE=2KBは、VOLSIZE=2048と同じです。同様に、MBはメガバイト(1024×1024)を、GBはギガバイト(1024の3乗)を表します。Bはバイトの省略です。この場合、最終的なファイル・サイズの算出に乗算は不要です(VOLSIZE=2048Bは、VOLSIZE=2048と同じです)。

エクスポート・セッションの例

この項では、次のタイプのエクスポート・セッションの例を示します。

- 全体データベース・モードのエクスポート・セッションの例

- ユーザー・モードのエクスポート・セッションの例

- 表モードのエクスポート・セッションの例

- パーティション・レベル・エクスポートでのエクスポート・セッションの例

それぞれの例では、コマンドライン方式とパラメータ・ファイル方式の両方の使用方法が示されます。一部の例では、縦長の省略記号を使用して、長すぎてすべてを表示できない出力例のセクションを示しています。

全体データベース・モードのエクスポート・セッションの例

DBAロールまたはEXP_FULL_DATABASEロールを持っているユーザーのみが、全体データベース・モードでエクスポートを実行できます。この例では、データベース全体がすべてのGRANTSおよびデータとともにファイルdba.dmpにエクスポートされます。

パラメータ・ファイル方式

> exp PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

FILE=dba.dmp
GRANTS=y
FULL=y
ROWS=y

コマンドライン方式

> exp FULL=y FILE=dba.dmp GRANTS=y ROWS=y

エクスポート・メッセージ

使用しているエクスポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。状態メッセージは、データベース全体がエクスポートされた時点で書き出されます。エクスポートが警告なしで完了すると、最終的な完了メッセージが返されます。

ユーザー・モードのエクスポート・セッションの例

ユーザー・モード・エクスポートを使用して、1人以上のデータベース・ユーザーをバックアップできます。たとえばDBAは、削除されたユーザーの表を一定期間バックアップすることが必要な場合があります。ユーザー・モードは、自分のデータをバックアップする必要があるユーザー、または1人の所有者から別の所有者にオブジェクトを移動する必要があるユーザーにも適しています。 この例では、ユーザーscottが自分の表をエクスポートします。

パラメータ・ファイル方式

> exp scott PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

FILE=scott.dmp
OWNER=scott
GRANTS=y
ROWS=y
COMPRESS=y

コマンドライン方式

> exp scott FILE=scott.dmp OWNER=scott GRANTS=y ROWS=y COMPRESS=y

エクスポート・メッセージ

使用しているエクスポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

.
.
. about to export SCOTT's tables via Conventional Path ...
. . exporting table                          BONUS          0 rows exported
. . exporting table                           DEPT          4 rows exported
. . exporting table                            EMP         14 rows exported
. . exporting table                       SALGRADE          5 rows exported
.
.
.
Export terminated successfully without warnings.

表モードのエクスポート・セッションの例

表モードでは、表データまたは表定義をエクスポートできます。(行がエクスポートされない場合は、CREATE TABLE文が権限および索引とともに(指定されている場合)エクスポート・ファイルに書き込まれます。)

EXP_FULL_DATABASEロールを持っているユーザーは、表モードを使用しTABLES=schemaname.tablenameを指定して、任意のユーザーのスキーマから表をエクスポートできます。

schemanameが指定されていない場合、デフォルトでエクスポート実行者のスキーマ名になります。次の例では、表aおよび表cは、デフォルトでSYSTEMスキーマになります。

> exp TABLES=(a, scott.b, c, mary.d)

EXP_FULL_DATABASEロールを持っているユーザーは、他のユーザーによって所有されている依存オブジェクトもエクスポートできます。権限のないユーザーは、所有している指定済の表の依存オブジェクトのみをエクスポートできます。

表モードでのエクスポートには、クラスタ定義は含まれません。その結果、データはクラスタ化されていない表としてエクスポートされます。したがって、表モードを使用して、表のクラスタ化を解除できます。

例1: DBAによる2人のユーザー用の表のエクスポート

この例では、DBAが2人のユーザーの指定済表をエクスポートします。

パラメータ・ファイル方式

> exp PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

FILE=expdat.dmp
TABLES=(scott.emp,blake.dept)
GRANTS=y
INDEXES=y

コマンドライン方式

> exp FILE=expdat.dmp TABLES=(scott.emp,blake.dept) GRANTS=y INDEXES=y

エクスポート・メッセージ

使用しているエクスポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

.
.
.
About to export specified tables via Conventional Path ...
Current user changed to SCOTT
. . exporting table                            EMP         14 rows exported
Current user changed to BLAKE
. . exporting table                           DEPT          8 rows exported
Export terminated successfully without warnings.

例2: ユーザーによる自身が所有している表のエクスポート

この例では、ユーザーblakeが所有している選択済の表をエクスポートします。

パラメータ・ファイル方式

> exp blake PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

FILE=blake.dmp
TABLES=(dept,manager)
ROWS=y
COMPRESS=y

コマンドライン方式

> exp blake FILE=blake.dmp TABLES=(dept, manager) ROWS=y COMPRESS=y

エクスポート・メッセージ

使用しているエクスポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

.
.
.

About to export specified tables via Conventional Path ...
. . exporting table                           DEPT          8 rows exported
. . exporting table                        MANAGER          4 rows exported
Export terminated successfully without warnings.

例3: パターン一致を使用した様々な表のエクスポート

この例では、パターン一致を使用して、ユーザーscottおよびblakeの様々な表をエクスポートします。

パラメータ・ファイル方式

> exp PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

FILE=misc.dmp
TABLES=(scott.%P%,blake.%,scott.%S%)

コマンドライン方式

> exp FILE=misc.dmp TABLES=(scott.%P%,blake.%,scott.%S%)

エクスポート・メッセージ

使用しているエクスポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

.
.
.
About to export specified tables via Conventional Path ...
Current user changed to SCOTT
. . exporting table                           DEPT          4 rows exported
. . exporting table                            EMP         14 rows exported
Current user changed to BLAKE
. . exporting table                           DEPT          8 rows exported
. . exporting table                        MANAGER          4 rows exported
Current user changed to SCOTT
. . exporting table                          BONUS          0 rows exported
. . exporting table                       SALGRADE          5 rows exported
Export terminated successfully without warnings.

パーティション・レベル・エクスポートでのエクスポート・セッションの例

パーティション・レベルのエクスポートでは、エクスポートする表のパーティションおよびサブパーティションを指定できます。

例1: パーティションを指定しない表のエクスポート

empは従業員名でパーティション化されている表であると想定します。mおよびzの2つのパーティションがあります。この例に示すとおり、パーティションを指定せずに表をエクスポートすると、すべてのパーティションがエクスポートされます。

パラメータ・ファイル方式

> exp scott PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

TABLES=(emp)
ROWS=y

コマンドライン方式

> exp scott TABLES=emp rows=y

エクスポート・メッセージ

使用しているエクスポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

.
.
.
About to export specified tables via Conventional Path ...
. . exporting table                            EMP
. . exporting partition                              M          8 rows exported
. . exporting partition                              Z          6 rows exported
Export terminated successfully without warnings.

例2: パーティションを指定した表のエクスポート

empは従業員名でパーティション化されている表であると想定します。mおよびzの2つのパーティションがあります。この例に示すとおり、表をエクスポートするときにパーティションを指定すると、指定されたパーティションのみがエクスポートされます。

パラメータ・ファイル方式

> exp scott PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

TABLES=(emp:m)
ROWS=y

コマンドライン方式

> exp scott TABLES=emp:m rows=y

エクスポート・メッセージ

使用しているエクスポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

.
.
.
About to export specified tables via Conventional Path ...
. . exporting table                            EMP
. . exporting partition                              M          8 rows exported
Export terminated successfully without warnings.

例3: コンポジット・パーティションのエクスポート

empは、2つのパーティションm、zがあるパーティション表であるとします。表empは、コンポジット方式を使用してパーティション化されています。パーティションmには、サブパーティションsp1およびsp2があり、パーティションzには、サブパーティションsp3およびsp4があります。この例に示すとおり、コンポジット・パーティションmをエクスポートすると、そのすべてのサブパーティション(sp1およびsp2)がエクスポートされます。表をエクスポートするときにサブパーティション(sp4)を指定すると、指定されたパーティションのみがエクスポートされます。

パラメータ・ファイル方式

> exp scott PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

TABLES=(emp:m,emp:sp4)
ROWS=y

コマンドライン方式

> exp scott TABLES=(emp:m, emp:sp4) ROWS=y

エクスポート・メッセージ

使用しているエクスポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

.
.
.
About to export specified tables via Conventional Path ...
. . exporting table                            EMP
. . exporting composite partition                    M
. . exporting subpartition                         SP1          1 rows exported
. . exporting subpartition                         SP2          3 rows exported
. . exporting composite partition                    Z
. . exporting subpartition                         SP4          1 rows exported
Export terminated successfully without warnings.

警告、エラーおよび完了メッセージ

この項では、エクスポート・ユーティリティによって発行される各種のメッセージと、ログ・ファイルへのメッセージの保存方法について説明します。

ログ・ファイル

すべてのエクスポート・メッセージをログ・ファイルに保存するには、LOGパラメータを使用するか、出力をファイルにリダイレクトします(リダイレクトできるシステムの場合)。成功したアンロード、および発生している可能性があるエラーに関して、詳細な情報のログが記録されます。

警告メッセージ

エクスポート・ユーティリティは、リカバリ可能なエラーの発生後は終了しません。たとえば、表のエクスポート中にエラーが発生すると、エクスポート・ユーティリティはエラー・メッセージを表示(またはログに記録)して次の表にスキップし、処理を続行します。これらのリカバリ可能エラーは警告と呼ばれます。

エクスポート・ユーティリティは、無効なオブジェクトが検出された場合も警告メッセージを表示します。

たとえば、存在しない表が表モード・エクスポートの一部として指定されても、それ以外のすべての表をエクスポートします。その後で警告メッセージを表示して、正常に終了します。

リカバリ不能なエラー・メッセージ

エラーによってはリカバリ不能で、エクスポート・セッションが終了する場合があります。通常、これらのエラーは、内部的な問題、またはメモリーなどのリソースが使用不能か不足しているなどの原因によって発生します。たとえば、catexp.sqlスクリプトが実行されない場合、エクスポート・ユーティリティは次のようなリカバリ不能メッセージを表示します。

EXP-00024: Export views not installed, please notify your DBA

完了メッセージ

エラーが発生することなくエクスポートが完了すると、その状態を示す次のようなメッセージが表示されます。

Export terminated successfully without warnings

リカバリ可能なエラーが1つ以上発生した場合に、ジョブが続行されて完了すると、次のようなメッセージが表示されます。

Export terminated successfully with warnings

リカバリ不能なメッセージが発生してジョブがすぐに終了した場合は、その状態を示す次のようなメッセージが表示されます。

Export terminated unsuccessfully

終了コードによる結果の検査と表示

エクスポート・ユーティリティでは、操作の完了後、すぐに実行結果を確認できます。プラットフォームによっては、実行結果はプロセス終了コードに通知され、ログ・ファイルにも記録されます。これによって、コマンドラインやスクリプトからの出力を確認できます。表22-4に、様々な結果の終了コードを示します。

表22-4 エクスポート・ユーティリティの終了コード

結果

終了コード

エクスポートは警告なしで正常終了しました。

EX_SUCC

エクスポートは正常に終了しましたが、警告が発生しました。

EX_OKWARN

エラーが発生したためエクスポートを終了します。

EX_FAIL

UNIXの場合、終了コードは次のようになります。

EX_SUCC   0
EX_OKWARN 0
EX_FAIL   1

従来型パス・エクスポートとダイレクト・パス・エクスポート

エクスポート・ユーティリティで表データをエクスポートするには、次の2つの方法があります。

- 従来型パス・エクスポート

- ダイレクト・パス・エクスポート

従来型パス・エクスポートでは、SQL SELECT文を使用して表からデータを抽出します。データはディスクからバッファ・キャッシュへと読み取られ、行は評価バッファに転送されます。データは、式の評価が渡された後にエクスポート・クライアントに転送され、クライアントによってエクスポート・ファイルに書き込まれます。

ダイレクト・パス・エクスポートは、従来型パス・エクスポートよりも非常に高速です。これは、データがディスクからバッファ・キャッシュに読み取られて、行が直接エクスポート・クライアントに転送されるためです。評価バッファ(SQLコマンド処理レイヤーに相当)はバイパスされます。データはすでにエクスポート・ユーティリティ向けの形式になっているため、不要なデータ変換を回避できます。データは、エクスポート・クライアントに転送され、クライアントによってエクスポート・ファイルに書き込まれます。

ダイレクト・パス・エクスポートの起動

ダイレクト・パス・エクスポートを使用するには、コマンドラインまたはパラメータ・ファイルで、DIRECT=yパラメータを指定します。デフォルトは、従来型パスを使用して表データを抽出するDIRECT=nです。この後の項では、次の項目について説明します。

- ダイレクト・パス・エクスポートに関するセキュリティ上の考慮点

- ダイレクト・パス・エクスポートに関するパフォーマンス上の考慮点

- ダイレクト・パス・エクスポートに関する制限事項

ダイレクト・パス・エクスポートに関するセキュリティ上の考慮点

Oracle Virtual Private Database(VPD)およびOracle Label Securityは、ダイレクト・パス・エクスポートの実行時には施行されません。

次のユーザーは、データベースからのデータの抽出に使用されるエクスポート・モード、アプリケーションまたはユーティリティに関係なく、Virtual Private DatabaseおよびOracle Label Security施行の対象外となります。

- データベース・ユーザーSYS

- 直接またはデータベース・ロールを通じてEXEMPT ACCESS POLICY権限を付与されているデータベース・ユーザー

つまり、EXEMPT ACCESS POLICY権限を付与されているどのユーザーも、VPDおよびOracle Label Securityの施行の完全な対象外となります。これは強力な権限であるため、注意して管理する必要があります。この権限は、SELECT、INSERT、UPDATE、DELETEなどの従来のオブジェクト権限の施行に影響しません。これらの権限は、ユーザーにEXEMPT ACCESS POLICY権限が付与されている場合も施行されます。

関連項目:

- 「ファイングレイン・アクセス・コントロールに対するサポート」

- 『Oracle Label Security管理者ガイド』

- VPDを使用してデータ・アクセスを制御する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

ダイレクト・パス・エクスポートに関するパフォーマンス上の考慮点

ダイレクト・パス・エクスポートを起動するときに、RECORDLENGTHパラメータの値を大きくすると、パフォーマンスを向上できることがあります。実際に得られるパフォーマンスは、次の要因によって決まります。

- DB_BLOCK_SIZE

- 表内の列の型

- 使用するI/Oレイアウト(エクスポート・ファイルを受け取るドライブは、データベース・ファイルが存在するディスク・ドライブとは別にする必要があります。)

一般に、RECORDLENGTHには次の値が推奨されます。

- ファイル・システムI/Oブロック・サイズの整数倍

- DB_BLOCK_SIZEの整数倍

ダイレクト・パス・エクスポートを使用して作成されたエクスポート・ファイルをインポートするには、従来型パス・エクスポートを使用して作成されたエクスポート・ファイルの場合と同じ時間がかかります。

ダイレクト・パス・エクスポートに関する制限事項

ダイレクト・パス・モードを使用する場合は、次の制限事項に注意してください。

- ダイレクト・パス・エクスポートを起動するには、コマンドライン方式またはパラメータ・ファイルを使用する必要があります。対話方式を使用して、ダイレクト・パス・エクスポートを起動することはできません。

- BUFFERエクスポート・パラメータは、従来型パス・エクスポートのみに適用されます。ダイレクト・パス・エクスポートの場合は、RECORDLENGTHパラメータを使用して、エクスポート・ユーティリティでエクスポート・ファイルへの書き込みに使用されるバッファのサイズを指定します。

- 表領域モード(TRANSPORT_TABLESPACES=Y)でエクスポートするときは、ダイレクト・パスを使用できません。

- QUERYパラメータは、ダイレクト・パス・エクスポートでは指定できません。

- ダイレクト・パス・エクスポートでデータをエクスポートできるのは、エクスポートを起動するセッションのNLS_LANG環境変数がデータベースのキャラクタ・セットに一致する場合のみです。NLS_LANGが設定されていないか、データベースのキャラクタ・セットと異なる場合は、警告メッセージが表示されて、エクスポートが続行されません。NLS_LANG環境変数のデフォルト値は、AMERICAN_AMERICA.US7ASCIIです。

ネットワークに関する考慮点

この項では、ネットワークを介したエクスポートの実行時に考慮すべき点について説明します。

ネットワークを介してエクスポート・ファイルを転送する方法

エクスポート・ファイルはバイナリ形式であるため、ネットワークを介してそのエクスポート・ファイルを転送するときは、バイナリ転送をサポートしているプロトコルを使用して、ファイルが破損しないようにしてください。たとえば、FTPなどのファイル転送プロトコルを使用して、バイナリ・モードでファイルを転送します。エクスポート・ファイルをキャラクタ・モードで送信すると、ファイルのインポート時にエラーが発生します。

Oracle Netを使用したエクスポート

Oracle Netを使用すると、ネットワークを介してエクスポートを実行できます。たとえば、エクスポート・ユーティリティをローカルで実行した場合に、リモートのOracle Databaseからローカルのエクスポート・ファイルにデータを書き込むことができます。

Oracle Netとともにエクスポート・ユーティリティを使用するには、expコマンドにユーザー名とパスワードを入力するときに接続修飾文字列@connect_stringを指定する必要があります。この句の構文の詳細は、ご使用のOracle Netプロトコルのユーザーズ・ガイドを参照してください。

関連項目:

- Oracle Database Net Services管理者ガイド

キャラクタ・セットおよびグローバリゼーション・サポートに関する考慮点

この項では、ユーザー・データおよびデータ定義言語(DDL)のキャラクタ・セット変換に関連するエクスポート・ユーティリティのグローバリゼーション・サポートの動作について説明します。

ユーザー・データ

エクスポート・ユーティリティは、常に、エクスポート・サーバーのキャラクタ・セットでUnicodeデータを含むユーザー・データをエクスポートします。(キャラクタ・セットは、データベース作成時に指定されます。)ソース・データベースのキャラクタ・セットが、インポート・データベースのキャラクタ・セットと異なる場合、自動的にデータをインポート・サーバーのキャラクタ・セットに変換するためのキャラクタ・セット変換が実行されます。

変換によるキャラクタ・セットのソート順への影響

エクスポート・キャラクタ・セットのソート順が、インポート・キャラクタ・セットと異なる場合、キャラクタ列をパーティション化した表では、結果が保証されません。 たとえば、次のようなASCIIキャラクタ・セットのデータベースの表定義について考えてみます。

CREATE TABLE partlist
(
part     VARCHAR2(10),
partno   NUMBER(2)
)
PARTITION BY RANGE (part)
(
PARTITION part_low VALUES LESS THAN ('Z')
TABLESPACE tbs_1,
PARTITION part_mid VALUES LESS THAN ('z')
TABLESPACE tbs_2,
PARTITION part_high VALUES LESS THAN (MAXVALUE)
TABLESPACE tbs_3
);

ASCIIキャラクタ・セットでは、Zの後にzがあるため、このパーティション・スキームには意味があります。

この表がEBCDICキャラクタ・セット・ベースのデータベースにインポートされると、EBCDICキャラクタ・セットでは、zがZの前にあるため、part_midパーティションのすべての行が、part_lowパーティションに移行します。希望する結果を得るには、partlist表の所有者は、インポート後に表を再パーティション化する必要があります。

関連項目:

キャラクタ・セットの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

DDL

エクスポートおよびインポート操作時に、データ定義言語(DDL)に対して最大3回のキャラクタ・セット変換が必要です。

1. エクスポート・ファイルは、環境変数NLS_LANGでユーザー・セッション用に指定されたキャラクタ・セットで書き出されます。NLS_LANGの値が、データベースのキャラクタ・セットと異なる場合は、キャラクタ・セット変換が実行されます。

2. エクスポート・ファイルのキャラクタ・セットが、インポート先ユーザー・セッション用のキャラクタ・セットと異なる場合、ユーザー・セッションのキャラクタ・セットに変換されます。シングルバイト・キャラクタ・セットの場合のみにこの変換が実行されます。マルチバイト・キャラクタ・セットの場合は、インポート・ファイルのキャラクタ・セットがエクスポート・ファイルのキャラクタ・セットと同じである必要があります。

3. ターゲット・データベースのキャラクタ・セットが、インポート・ユーザー・セッション用のキャラクタ・セットと異なる場合、最後のキャラクタ・セット変換が実行される場合があります。

キャラクタ・セット変換によるデータの損失を最小限にするには、エクスポート・データベース、エクスポート・ユーザー・セッション、インポート・ユーザー・セッションおよびインポート・データベースのすべてにおいて、同一のキャラクタ・セットを使用するようにしてください。

シングルバイト・キャラクタ・セットとエクスポートおよびインポート

8ビット・キャラクタ・セットのエクスポート・ファイルをインポートすると、8ビット文字の一部が消去されることがあります(同等の7ビットに変換されます)。これが発生するのは、インポートを実行するシステムに、システム固有の7ビット・キャラクタ・セットが存在するか、オペレーティング・システム環境変数NLS_LANGが7ビット・キャラクタ・セットに設定されている場合です。アクセント記号が付いている文字からアクセントが消去されるのが最もよく見られる例です。

このような状況を回避するために、オペレーティング・システム環境変数NLS_LANGにエクスポート・ファイルのキャラクタ・セットを設定できます。

マルチバイト・キャラクタ・セットとエクスポートおよびインポート

ターゲット・キャラクタ・セットに同等の文字がないエクスポート・ファイル中の文字は、変換時にデフォルトの文字に置換されます(デフォルトの文字は、ターゲット・キャラクタ・セットによって定義されます)。(デフォルトの文字は、ターゲット・キャラクタ・セットによって定義されます)。100%完全に変換されるためには、ターゲット・キャラクタ・セットはソース・キャラクタ・セットのスーパーセットであるか、ソース・キャラクタ・セットと同等である必要があります。

注意:

エクスポート・サーバーとインポート・サーバーとの間でキャラクタ・セットの幅が異なるとき、変換が原因でデータの拡張が発生する場合にデータの切捨てが発生することがあります。切捨てが発生する場合、インポート・ユーティリティに警告メッセージが表示されます。

エクスポート・ユーティリティおよびインポート・ユーティリティでのインスタンス親和性の使用

インスタンス親和性を使用して、インポートおよびエクスポートするデータベース内のインスタンスにジョブを関連付けることができます。複数のリリースを組み合せて使用している場合は、互換性の問題に注意してください。

関連項目:

- 親和性の詳細は、『Oracle Database管理者ガイド』を参照してください。

データベース・オブジェクトのエクスポート時の考慮点

次の項では、特定のデータベース・オブジェクトをエクスポートする場合の考慮点について説明します。

エクスポート順序

エクスポート中もトランザクションから順序番号へのアクセスが継続すると、順序番号がスキップされる場合があります。順序番号がスキップされないようにする最良の方法として、エクスポート中に順序にアクセスしないようにします。

順序番号をスキップできるのは、キャッシュされた順序番号が使用されている場合のみです。順序番号のキャッシュが割り当てられていると、それらを現在のデータベースで使用できます。エクスポートされる値は、次の順序番号(キャッシュされた値の後)です。キャッシュされていても未使用の順序番号は、順序がインポートされたときに失われます。

LONGおよびLOBデータ型のエクスポート

エクスポート時に、LONGデータ型はセクションごとにフェッチされます。ただし、LONGデータを含めて、各行のすべての内容を保持できる十分な使用可能メモリーが必要です。

LONG列の長さは、最大2GBです。

LOB列内のデータはすべてを同時にメモリーに保持する必要はありません。LOBデータはセクションごとにロードおよびアンロードされます。

注意:

既存のLONG列もLOB列に変換することをお薦めします。LOB列は、LONG列ほど制限は多くありません。また、LOB機能はすべてのリリースで拡張されていますが、LONG機能は、いくつかのリリースでは拡張されていません。

外部関数ライブラリのエクスポート

外部関数ライブラリの内容はエクスポート・ファイルに含まれません。かわりに、ライブラリの指定(名前、場所)のみが全体データベース・モードおよびユーザー・モード・エクスポートに含まれます。データベースを新しい場所に移動する場合は、ライブラリの実行可能ファイルを移動してライブラリの指定を更新する必要があります。

オフライン・ローカル管理表領域のエクスポート

エクスポートするデータにオフライン・ローカル管理表領域が含まれていると、エクスポート・ユーティリティでは完全な表領域定義をエクスポートできず、エラー・メッセージが表示されます。その場合もデータをインポートはできますが、インポートの前にオフライン・ローカル管理表領域を作成して、欠落している表領域を参照する場合があるDDLコマンドに失敗しないようにする必要があります。

ディレクトリ別名のエクスポート

ディレクトリ別名の定義は、全体データベース・モード・エクスポートのみに含まれます。データベースを新しい場所に移動する場合、データベース管理者は、新しい場所を指すように、ディレクトリ別名を更新する必要があります。

ディレクトリ別名はユーザー・モードまたは表モード・エクスポートには含まれません。したがって、ディレクトリ別名を使用する前に、ディレクトリ別名をターゲット・システム上に作成しておく必要があります。

BFILE列および属性のエクスポート

エクスポート・ファイルには、BFILE列または属性によって参照される外部ファイルの内容は保持されません。かわりに、ファイルの名前とディレクトリ別名のみがエクスポート時にコピーされて、インポート時にリストアされます。データベースを移動し、元のディレクトリに含まれているファイルにアクセスできない場合、データベース管理者(DBA)は、指定されたファイルが含まれているディレクトリを、アクセス可能な新しい場所に移動する必要があります。

外部表のエクスポート

外部表の内容はエクスポート・ファイルに含まれません。かわりに、表の指定(名前、場所)のみが全体データベース・モードおよびユーザー・モード・エクスポートに含まれます。データベースを新しい場所に移動する場合は、外部データを手動で移動して表の指定を更新する必要があります。

オブジェクトの型定義のエクスポート

どのエクスポート・モードでも、エクスポート・ユーティリティには、エクスポートする表で使用されるオブジェクトの型定義に関する情報が含まれます。ターゲット・システム上のオブジェクト型とエクスポート・ファイルに含まれているオブジェクトの状態との間に一貫性があるかどうかを確認するには、オブジェクト名、オブジェクト識別子、オブジェクト・ジオメトリなどの情報が必要です。これにより、表に必要なオブジェクト型が、同じオブジェクト識別子でインポート時に作成されます。

ただし、エクスポート・ユーティリティを実行するユーザーが、対象のオブジェクト型に対する実行権限を持っていない場合、表モード、ユーザー・モード、表領域モードでは、表に必要な完全オブジェクト定義がエクスポート・ファイルに含まれません。この場合、その型の存在確認に必要な情報のみが、同じオブジェクト識別子およびジオメトリでインポート・ターゲット・システム上に書き込まれます。

ユーザーは、DBAとともに適切な型定義を作成するか、またはDBAが実行した全体データベース・モード・エクスポートまたはユーザー・モード・エクスポートからそれらの型定義をインポートすることによって、適切なデータ型がターゲット・システムに存在するようにする必要があります。

すべてのオブジェクト型定義を保持するには、全体データベース・モード・エクスポートを定期的に実行することが重要です。また、異なるスキーマのオブジェクト型定義を使用する場合、DBAは、該当するユーザーのユーザー・モード・エクスポートを実行する必要があります。たとえば、ユーザーscottに属しているtable1に、blakeの型type1に存在する列が含まれている場合、表に必要な型定義を保持するには、blakeとscottの両方のユーザー・モード・エクスポートを実行する必要があります。

ネストした表のエクスポート

ネストした内部表データは、外部表がエクスポートされると必ずエクスポートされます。ネストした内部表は名前を指定できますが、個別にエクスポートすることはできません。

AQ表のエクスポート

キューは表上で実装されます。キューのエクスポートおよびインポートは、基礎となるキュー表と関連のディクショナリ表のエクスポートおよびインポートによって構成されます。キューのエクスポートおよびインポートは、キュー表単位のレベルでのみ実行できます。

キュー表をエクスポートすると、表定義情報とキュー・データの両方がエクスポートされます。キュー表データと表定義がエクスポートされるため、ユーザーは、キュー表データのインポート時に、アプリケーション・レベル・データの整合性のメンテナンスを行います。

関連項目:

『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』

シノニムのエクスポート

シノニムおよび別のオブジェクトとして使用される名前を参照するコンパイル済オブジェクトをエクスポートするときは、注意する必要があります。これらのオブジェクトのエクスポートおよびインポートを実行すると、再コンパイルが施行されて、オブジェクト定義が変更されることがあります。

この問題について、次の例に示します。

CREATE PUBLIC SYNONYM emp FOR scott.emp;

CONNECT blake/paper;
CREATE TRIGGER t_emp BEFORE INSERT ON emp BEGIN NULL; END;
CREATE VIEW emp AS SELECT * FROM dual;

前述の例のデータベースがエクスポートされると、トリガー内のempへの参照によって、scottの表ではなくblakeのビューが参照されます。そのため、インポート・ユーティリティでt_empトリガーを再確立しようとすると、エラーが発生します。

Javaシノニムに関連して発生する可能性があるエクスポート・エラー

対応するDBMS_JAVAパッケージがないとき、またはJavaがロードされないか、正しくロードされないときに、エクスポート操作でDBMS_JAVAという名前のシノニムをエクスポートしようとすると、エクスポートが正常に完了されないまま終了します。生成されるエラー・メッセージには、EXP-00008、ORA-00904、ORA-29516などが含まれます。

Javaが有効化されている場合、エクスポートを再実行する前にDBMS_JAVAシノニムとDBMS_JAVAパッケージの両方が作成されて有効になっていることを確認してください。

Javaが有効化されていない場合は、エクスポートを再実行する前にJava関連オブジェクトを削除します。

ファイングレイン・アクセス・コントロールに対するサポート

ファイングレイン・アクセス・コントロール・ポリシーを使用可能にして、表をエクスポートできます。その場合は、次の点を考慮してください。

- ファイングレイン・アクセス・コントロール・ポリシーが使用可能な表を含むエクスポート・ファイルをインポートするユーザーは、適切な権限(特にDBMS_RLSパッケージに対するEXECUTE権限。表のセキュリティ・ポリシーを回復するため)を持っている必要があります。適切な権限を持っていないユーザーが、ファイングレイン・アクセス・ポリシーが使用可能な表をエクスポートしようとすると、エクスポート実行者が読取り権限を持つ行のみがエクスポートされます。

- SELECT文に対してファイングレイン・アクセス・コントロールを使用可能にすると、従来型パス・エクスポートでは表全体をエクスポートできない場合があります。これは、ファイングレイン・アクセスでは問合せが再作成される可能性があるためです。

- ファイングレイン・アクセス・コントロールが設定されている表上でダイレクト・パス・エクスポートを実行できるのは、ユーザーSYS、EXP_FULL_DATABASEロールが使用可能なユーザー、またはEXEMPT ACCESS POLICYを付与されているユーザーのみです。

トランスポータブル表領域

トランスポータブル表領域機能は、一連の表領域を、あるOracle Databaseから他のOracle Databaseに移動できる機能です。

注意:

トランスポータブル表領域をエクスポートした後、それよりも古いリリース・レベルのデータベースにインポートすることはできません。ターゲット・データベースのリリース・レベルは、ソース・データベース以上である必要があります。

一連の表領域を移動またはコピーするには、表領域を読取り専用にし、表領域のデータ・ファイルをコピーしてから、エクスポートおよびインポートを使用して、データ・ディクショナリに格納されているデータベース情報(メタデータ)を移動します。データ・ファイルとメタデータ・エクスポート・ファイルの両方を、ターゲット・データベースにコピーする必要があります。これらのファイルの転送は、オペレーティング・システムのコピー機能、バイナリ・モードFTP、CD-ROMへの出力などのような、フラット・バイナリ・ファイルのコピー機能を使用して行われます。

データ・ファイルのコピーおよびメタデータのエクスポートの後、表領域を任意に読み書き両用モードにできます。

次のパラメータで、トランスポータブル表領域のメタデータを移動できます。

- TABLESPACES

- TRANSPORT_TABLESPACE

エクスポート操作時のこれらのパラメータの使用方法の詳細は、「TABLESPACES」および「TRANSPORT_TABLESPACE」を参照してください。

関連項目:

- トランスポータブル表領域の管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

読取り専用データベースからのエクスポート

ソース・データベースからメタデータを抽出するには、エクスポート・ユーティリティで順序付け句(ソート操作)が含まれる問合せを使用します。これらの問合せを正しく実行するには、エクスポートを実行するユーザーがソート・セグメントを指定できる必要があります。これらのソート・セグメントを読取り専用データベースに指定するには、ユーザーの一時表領域が、一時的なローカル管理表領域を指すように設定します。

エクスポート・ユーティリティおよびインポート・ユーティリティを使用したデータベース移行のパーティション化

エクスポート・ユーティリティおよびインポート・ユーティリティを使用して大規模データベースを移行する場合、移行を複数のエクスポート・ジョブおよびインポート・ジョブにパーティション化するとより効率的です。移行をパーティション化する場合は、次のメリットおよびデメリットに注意してください。

移行をパーティション化する場合のメリット

移行をパーティション化すると、次のメリットがあります。

- 多くのサブジョブをパラレルに実行できるため、移行に必要な時間を削減できます。

- 最初のエクスポート・ジョブが完了するとすぐにインポート・ユーティリティを起動できます。

移行をパーティション化する場合のデメリット

移行をパーティション化すると、次のデメリットがあります。

- エクスポートおよびインポートのプロセスがより複雑になります。

- 特定の型のオブジェクトに対する相互スキーマ参照のサポートが損なわれます。たとえば、異なるスキーマの表に対する外部キー制約を持つ表がスキーマに含まれている場合、その表を依存スキーマにインポートしたときに、必要な親レコードが存在しない場合があります。

エクスポート・ユーティリティおよびインポート・ユーティリティを使用したデータベース移行のパーティション化方法

データベースの移行をパーティション化方法で実行するには、次の手順に従います。

1. データベースのすべての最上位メタデータに、次のコマンドを発行します。

a. exp FILE=full FULL=y CONSTRAINTS=n TRIGGERS=n ROWS=n INDEXES=n

b. imp FILE=full FULL=y

2. データベースの各スキーマnに、次のコマンドを発行します。

a. exp OWNER=scheman FILE=scheman

b. imp FILE=scheman FROMUSER=scheman TOUSER=scheman IGNORE=y

すべてのエクスポートはパラレルで実行できます。full.dmpのインポートが完了すると、残りのインポートもパラレルで実行できます。

リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用

この項では、リリースが異なるエクスポート・ユーティリティおよびOracle Databaseを使用することに関連した互換性の問題について説明します。

異なるリリースのOracle Database間でデータを移動するときは、必ず次の基本的な規則に従います。

- インポート・ユーティリティとデータのインポート先であるデータベース(ターゲット・データベース)のリリースは同じである必要があります。たとえば、インポート・ユーティリティ9.2.0.7を使用して9.2.0.8のデータベースにインポートしようとすると、エラーが発生する場合があります。

- エクスポート・ユーティリティのバージョンは、ソースまたはターゲット・データベースの古い方のリリースに合わせる必要があります。
たとえば、新しいリリースのデータベースにインポートするためにエクスポート・ファイルを作成する場合は、ソース・データベースと同じエクスポート・ユーティリティのバージョンを使用します。一方、古いリリースのデータベースにインポートするためのエクスポート・ファイルを作成する場合は、ターゲット・データベースのリリースと同じバージョンのエクスポート・ユーティリティを使用します。

- 通常は、Oracle8リリースのエクスポート・ユーティリティを使用して、Oracle9iサーバーからエクスポートし、Oracle8エクスポート・ファイルを作成できます。

リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用時の制限事項

異なるリリースのエクスポート・ユーティリティおよびインポート・ユーティリティを使用する場合、次の制限があります。

- エクスポート・ダンプ・ファイルは、特別なバイナリ形式で格納されているため、インポート・ユーティリティによる読取り専用です。

- すべてのエクスポート・ダンプ・ファイルは、上位リリースのOracle Databaseにインポートできます。

- インポート・ユーティリティでは、上位のメンテナンス・リリースのエクスポート・ユーティリティで作成されたエクスポート・ダンプ・ファイルの読取りはできません。たとえば、リリース9.2のエクスポート・ダンプ・ファイルは、リリース9.0.1のインポート・ユーティリティではインポートできません。

- 下位バージョンのエクスポート・ユーティリティを上位リリースのOracle Databaseで実行すると、下位リリースに存在しないデータベース・オブジェクトのカテゴリは、常にエクスポートから除外されます。

- Oracle9iのエクスポート(ダイレクト・パスまたは従来型パス)によって生成されたエクスポート・ファイルは、以前のリリースのインポート・ユーティリティと互換性がありません。したがって、インポートにはOracle9iのインポートのみを使用できます。下位互換性が問題になる場合は、Oracle9iデータベースよりも古いリリースのエクスポート・ユーティリティを使用してください。

リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用例

表22-5に、異なるリリースのOracle Database間でデータを移動させる場合に使用するエクスポート・ユーティリティおよびインポート・ユーティリティのリリースの例を示します。

表22-5 リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用

エクスポート元>インポート先

使用するエクスポート・ユーティリティのリリース

使用するインポート・ユーティリティのリリース

8.1.6 -> 8.1.6

8.1.6

8.1.6

8.1.5 -> 8.0.6

8.0.6

8.0.6

8.1.7 -> 8.1.6

8.1.6

8.1.6

9.0.1 -> 8.1.6

8.1.6

8.1.6

9.0.1 -> 9.0.2

9.0.1

9.0.2

9.0.2 -> 10.1.0

9.0.2

10.1.0

10.1.0 -> 9.0.2

9.0.2

9.0.2

表22-5に、オリジナルのエクスポートおよびインポート・ユーティリティ間のデータ移動を示します。Oracle Database 10gリリース1 (10.1)以上では、ほとんどの場合にデータ・ポンプ・エクスポートおよびデータ・ポンプ・インポート・ユーティリティを使用することをお薦めします。これらのユーティリティは、オリジナルのエクスポートおよびインポート・ユーティリティと比較して、パフォーマンスが著しく向上しています。

関連項目:

10.1以上のリリースを含めた異なるリリース間でのデータのエクスポートおよびインポートの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

23 オリジナルのインポート

オリジナルのインポート・ユーティリティ(imp)は、オリジナルのエクスポート・ユーティリティを使用して作成されたダンプ・ファイルをインポートします。

次のトピックを参照してください。

- インポート・ユーティリティとは

- インポート・ユーティリティを使用する前に

- 既存の表へのインポート

- インポート操作上のスキーマおよびデータベース・トリガーの影響

- インポート・ユーティリティの起動

- インポート・ユーティリティのモード

- インポート・パラメータ

- インポート・セッションの例

- 終了コードによる結果の検査と表示

- インポート中のエラー処理

- 表レベル・インポートおよびパーティション・レベル・インポート

- 索引作成およびメンテナンスの制御

- ネットワークに関する考慮点

- キャラクタ・セットおよびグローバリゼーション・サポートに関する考慮点

- インスタンス親和性の使用方法

- データベース・オブジェクトのインポートに関する考慮点

- ファイングレイン・アクセス・コントロールに対するサポート

- スナップショットおよびスナップショット・ログ

- トランスポータブル表領域

- 記憶域パラメータ

- 読取り専用表領域

- 表領域を削除する方法

- 表領域を再編成する方法

- 統計情報のインポート

- エクスポート・ユーティリティおよびインポート・ユーティリティを使用したデータベース移行のパーティション化

- インポート操作のチューニングに関する考慮点

- リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用

インポート・ユーティリティとは

インポート・ユーティリティは、オリジナルのエクスポート・ユーティリティで作成されたダンプ・ファイルからオブジェクトの定義および表データを読み込みます。ダンプ・ファイルはOracleのバイナリ形式になっており、オリジナルのインポートを使用した場合のみ読取りが可能です。

ダンプ・ファイルの作成に使用したエクスポート・ユーティリティより前のバージョンのインポート・ユーティリティは使用できません。

表オブジェクト: インポートの順序

表オブジェクトは、エクスポート・ダンプ・ファイルから読み込まれたとおりにインポートされます。ダンプ・ファイルには、次の順序でオブジェクトが格納されています。

1. 型定義

2. 表定義

3. 表データ

4. 表索引

5. 整合性制約、ビュー、プロシージャおよびトリガー

6. ビットマップ索引、ファンクション索引およびドメイン索引

インポートの順序は次のとおりです。まず、新しい表が作成されます。次にデータがインポートされ、索引が作成されます。その後トリガーがインポートされ、整合性制約が新しい表で使用可能になり、ビットマップ索引、ファンクション索引またはドメイン索引(あるいはそれらのすべて)が作成されます。このようにインポートされると、表のインポート順序が原因でデータが拒否されることがなくなります。また、同じデータについて、トリガーが重複して2回(最初の挿入時に1回、インポート中に1回)起動することもなくなります。

インポート・ユーティリティを使用する前に

インポート・ユーティリティを使用する前に、次のことを行う必要があります(詳細は以降の項を参照してください)。

- データベースを手動で作成した場合は、catexp.sqlまたはcatalog.sqlスクリプトが実行されたことの確認。Database Configuration Assistant(DBCA)を使用してデータベースを作成した場合は、これらのスクリプトを実行する必要はありません。

- 必要なアクセス権限を所有していることの確認

catexp.sqlまたはcatalog.sqlの実行

インポート・ユーティリティを使用するには、データベースを作成するかまたは新しいバージョンに移行した後で、スクリプトcatexp.sqlまたは(catexp.sqlを実行する)catalog.sqlを実行する必要があります。

データベースに対して、catexp.sqlまたはcatalog.sqlを実行するのは1回のみです。スクリプトを実行すると、次の処理が行われ、データベースはエクスポートおよびインポート操作に備えて調整されます。

- データ・ディクショナリへの必要なインポート・ビューの作成

- EXP_FULL_DATABASEロールおよびIMP_FULL_DATABASEロールの作成

- EXP_FULL_DATABASEおよびIMP_FULL_DATABASEロールへのすべての必要な権限の割当て

- DBAロールへのEXP_FULL_DATABASEおよびIMP_FULL_DATABASEの割当て

- インストールされているcatexp.sqlのバージョンの記録

インポート操作のアクセス権の確認

インポート・ユーティリティを使用するには、Oracle Databaseに対するCREATE SESSION権限が必要です。この権限は、データベースの作成時に設定されるCONNECTロールに含まれます。

他のユーザーが作成したエクスポート・ファイルをインポートすることもできます。ただし、EXP_FULL_DATABASEロールを所有するユーザーが作成したエクスポート・ファイルをインポートするには、IMP_FULL_DATABASEロールが必要です。通常、データベース管理者(DBA)にはこれらの両方のロールが割り当てられています。

オブジェクトをスキーマにインポートする方法

表23-1に、自分のスキーマにオブジェクトをインポートするために必要な権限を示します。 これらのすべての権限は、あらかじめRESOURCEロールに含まれています。

表23-1 自分のスキーマにオブジェクトをインポートするために必要な権限

オブジェクト

必要な権限(該当する場合の権限タイプ)

クラスタ

CREATE CLUSTER(システム)またはUNLIMITED TABLESPACE(システム)。ユーザーに表領域割当て制限が割り当てられている必要があります。

データベース・リンク

CREATE DATABASE LINK(システム)およびリモート・データベースの場合はCREATE SESSION(システム)

表のトリガー

CREATE TRIGGER(システム)

スキーマのトリガー

CREATE ANY TRIGGER(システム)

索引

CREATE INDEX(システム)またはUNLIMITED TABLESPACE(システム)。ユーザーに表領域割当て制限が割り当てられている必要があります。

整合性制約

ALTER TABLE(オブジェクト)

ライブラリ

CREATE ANY LIBRARY(システム)

パッケージ

CREATE PROCEDURE(システム)

プライベート・シノニム

CREATE SYNONYM(システム)

順序

CREATE SEQUENCE(システム)

スナップショット

CREATE SNAPSHOT(システム)

ストアド・ファンクション

CREATE PROCEDURE(システム)

ストアド・プロシージャ

CREATE PROCEDURE(システム)

表データ

INSERT TABLE(オブジェクト)

表定義(コメントおよび監査オプションを含む)

CREATE TABLE(システム)またはUNLIMITED TABLESPACE(システム)ユーザーに表領域割当て制限が割り当てられている必要があります。

ビュー

実表の場合はCREATE VIEW(システム)およびSELECT(オブジェクト)、またはSELECT ANY TABLE(システム)

オブジェクト型

CREATE TYPE(システム)

外部関数ライブラリ

CREATE LIBRARY(システム)

ディメンション

CREATE DIMENSION(システム)

演算子

CREATE OPERATOR(システム)

索引タイプ

CREATE INDEXTYPE(システム)

権限のインポート

他のユーザーに付与されている権限をインポートするには、インポートを開始したユーザーがそのオブジェクトの所有者であるか、WITH GRANT OPTION付きのオブジェクト権限を所有している必要があります。表23-2に、権限がターゲット・システムで有効となるために必要な条件を示します。

表23-2 権限のインポートに必要な権限

権限

条件

オブジェクト権限

オブジェクトがユーザーのスキーマに存在しているか、

ユーザーがWith Grant Option付きのオブジェクト権限を所有しているか、または

IMP_FULL_DATABASEロールを使用可能にする必要があります。

システム権限

ユーザーがSYSTEM権限およびWith Admin Optionを所有している必要があります。

他のスキーマへのオブジェクトのインポート

オブジェクトを他のユーザーのスキーマにインポートする場合は、IMP_FULL_DATABASEロールを使用可能にしておく必要があります。

システム・オブジェクトのインポート

システム・オブジェクトを全データベース・エクスポート・ファイルからインポートする場合は、IMP_FULL_DATABASEロールを使用可能にする必要があります。パラメータFULLを指定すると、次のシステム・オブジェクトがインポート対象に含まれます。

- プロファイル

- パブリック・データベース・リンク

- パブリック・シノニム

- ロール

- ロールバック・セグメント定義

- リソース・コスト

- 外部関数ライブラリ

- コンテキスト・オブジェクト

- システム・プロシージャ・オブジェクト

- システム監査オプション

- システム権限

- 表領域定義

- 表領域の割当て制限

- ユーザー定義

- ディレクトリ別名

- システム・イベント・トリガー

処理上の制限事項

インポート・ユーティリティを使用してデータを処理する場合、次の制限が適用されます。

- 型定義が進化し、その進化した型を参照するデータがエクスポートされた場合、インポート・システムの型定義も同様に進化させる必要があります。

- エクスポートおよびインポート時には、表およびパーティションの表圧縮属性が保持されます。ただし、インポート処理ではダイレクト・パスAPIが使用されないため、データは、インポート時に圧縮された形式では格納されません。

既存の表へのインポート

この項では、既存の表にデータをインポートする場合に考慮すべき点について説明します。

- データのインポート前に手動で表を作成する方法

- 参照制約を使用禁止にする方法

- 手動によるインポートの順序付け

データのインポート前に手動で表を作成する方法

エクスポート・ファイルから表にデータをインポートする前に手動で表を作成する場合は、以前使用した表定義を使用するか、互換性のある形式を使用して表を作成します。たとえば、列幅の増加および列順序の変更はできますが、次のことはできません。

- NOT NULL列の追加

- 列のデータ型の互換性のないデータ型への変更(LONGからNUMBERなど)

- 表で使用されているオブジェクト型定義の変更

- DEFAULT列値の変更

注意:

データをインポートする前に表を手動で作成した場合は、表がすでに存在するため、エクスポート・ダンプ・ファイルでCREATE TABLE文を実行するとエラーが発生します。このエラーを回避して、表へのデータのロードを継続するには、インポート・パラメータをIGNORE=yに設定します。設定しない場合、表作成エラーが発生し、データは表にロードされません。

参照制約を使用禁止にする方法

通常のインポートの順序では、参照制約はすべての表がインポートされた後にインポートされます。この順序でインポートすることによって、まだインポートされていないデータに対する参照整合性制約が存在する場合に発生するエラーを回避できます。

データが既存の表にロードされる場合に、このようなエラーが発生することがあります。たとえば、表empでmgr列に参照整合性制約が定義されており、その制約によって表emp内のマネージャ番号が検証される場合、マネージャの行がインポートされていない時点では、従業員の行が基準を満たしていても、参照整合性制約の違反になることがあります。

このようなエラーが発生すると、エラー・メッセージが生成され、失敗した行をバイパスして、引き続き他の行が表にインポートされます。制約を手動で使用禁止にすると、このエラーを回避できます。

複数の表にまたがって参照制約が存在すると、問題になることがあります。たとえば、emp表の順序がエクスポート・ダンプ・ファイル内でdept表より先であるにもかかわらず、emp表からdept表へ参照チェックが行われると、参照制約違反のため、emp表のいくつかの行がインポートされないことがあります。

このようなエラーが発生しないようにするには、データを既存の表にインポートするときに、参照整合性制約を使用禁止にします。

手動によるインポートの順序付け

インポート後に制約が再び使用可能にされると、表全体がチェックされますが、大きな表の場合はチェックに時間がかかることがあります。表のチェックにかかる時間が長すぎる場合、インポートを手動で順序付ける方が効率的なこともあります。

そのためには、エクスポート・ファイルからのインポートを1回ではなく複数回に分けて実行します。まず、参照チェックのターゲットである表をインポートします。次に、これらの表を参照する表をインポートします。表が循環的に相互参照している場合、および表がその表自体を参照している場合を除き、この方法は有効です。

インポート操作上のスキーマおよびデータベース・トリガーの影響

特定のスキーマに対するDDLイベントまたはデータベースに対するDDL関連イベントで実行するように定義されているトリガーは、システム・トリガーです。これらのトリガーは、特定のインポート操作に悪い影響を与える場合があります。たとえば、表などのデータベース・オブジェクトを正常に再作成できない場合があります。これによって、トリガーが原因で問題が発生したということがわからないエラーが返されます。

データベース管理者およびシステム・トリガーを作成するユーザーは、このようなトリガーによって、ユーザーが、権限を持つデータベースの操作を実行できなくなることがないように確認する必要があります。システム・トリガーをテストするには、次の手順に従います。

1. トリガーを定義します。

2. データベース・オブジェクトを作成します。

3. 表モードまたはユーザーモードでオブジェクトをエクスポートします。

4. オブジェクトを削除します。

5. オブジェクトをインポートします。

6. オブジェクトが正常に再作成されていることを確認します。

注意:

全体エクスポートでは、スキーマSYSが所有するトリガーはエクスポートされません。SYSトリガーは、全体インポートの前後のいずれかに手動で再作成する必要があります。このトリガーによってインポートの進行を妨げるような処理が定義されないように、インポートの後に再作成することをお薦めします。

インポート・ユーティリティの起動

次のいずれかの方法を使用して、インポート・ユーティリティの起動およびパラメータの指定ができます。

- コマンドライン

- パラメータ・ファイル

- 対話方式モード

これらのいずれかの方法を使用する前に、使用可能なパラメータについての説明を必ず読んでください。詳細は、「インポート・パラメータ」を参照してください。

コマンドライン・エントリ

次の構文を使用して、すべての有効なパラメータおよびその値をコマンドラインから指定できます(ユーザー名とパスワードを入力するように要求されます)。

imp PARAMETER=value

または

imp PARAMETER=(value1,value2,...,valuen)

システムでのコマンドラインの最大長を超える数のパラメータは指定できません。

パラメータ・ファイル

パラメータ・ファイルに、すべての有効なパラメータおよびその値を指定できます。複数のパラメータを1つのファイルに格納することによって、これらを簡単に変更したり再利用することができます。データベースごとに別のパラメータを使用する場合は、複数のパラメータ・ファイルを作成できるので、それぞれにパラメータ・ファイルを用意すると便利です。

フラット・ファイル用のテキスト・エディタを使用してパラメータ・ファイルを作成します。コマンドライン・オプションPARFILE=filenameを指定すると、インポート・ユーティリティは、コマンドラインからではなく指定されたファイルからパラメータを読み込みます。次に例を示します。

パラメータ・ファイルは、次のいずれかの構文を使用して指定します。

PARAMETER=value
PARAMETER=(value)
PARAMETER=(value1, value2, ...)

次に、パラメータ・ファイル内のリストの一部を示します。

FULL=y
FILE=dba.dmp
GRANTS=y
INDEXES=y
CONSISTENT=y

注意:

パラメータ・ファイルの最大サイズは、オペレーティング・システムによって制限されます。また、パラメータ・ファイル名はオペレーティング・システムのネーミング規則に従います。

シャープ(#)記号を使用すると、パラメータ・ファイルにコメントを追加できます。シャープ(#)の右側にある文字はすべて無視されます。

コマンドラインでのパラメータの入力と同時にパラメータ・ファイルを指定できます。実際、パラメータ・ファイルとコマンドラインの両方に同じパラメータを指定することもできます。コマンドラインでのPARFILEパラメータと他のパラメータの位置によって、優先されるパラメータが決まります。たとえば、パラメータ・ファイルparams.datでパラメータINDEXES=yを指定し、インポート・ユーティリティを次のコマンドで起動するとします。

imp PARFILE=params.dat INDEXES=n

この場合、INDEXES=nはPARFILE=params.datの後にあるため、パラメータ・ファイルに指定されているINDEXESパラメータの値は、INDEXES=nによって上書きされます。

関連項目:

- 「インポート・パラメータ」

- リモートのデータベースからのエクスポートの指定方法の詳細は、「ネットワークに関する考慮点」を参照してください

対話方式モード

各パラメータの値をプロンプトで入力するには、コマンドラインでimpを指定するだけです。ユーザー名とパスワードを入力するように要求されます。

その後、一般的に使用されるパラメータが表示されます。デフォルト値を受け入れるか(示された場合)、または異なる値を入力できます。コマンドライン対話方式では、すべての機能に関してプロンプトが表示されるわけではありません。また、コマンドライン対話方式は下位互換用のみに提供されています。

SYSDBAでのインポート・ユーティリティの起動

SYSDBAは内部的に使用され、一般ユーザーとは異なる特別な機能を持ちます。そのため、通常、次の場合以外は、インポート・ユーティリティをSYSDBAで起動する必要はありません。

- Oracleサポート・サービスから要求された場合

- トランスポータブル表領域セットをインポートする場合

オンライン・ヘルプの利用

インポート・ユーティリティでは、オンライン・ヘルプが提供されます。インポート・ユーティリティのヘルプを表示するには、imp help=yと入力します。

インポート・モード

インポート・ユーティリティには、次の4種類の操作モードがあります。

- 全体インポート: データベース全体をインポートします。IMP_FULL_DATABASEロールを所有するユーザーのみが使用できます。FULLパラメータを使用してこのモードを指定します。

- 表領域モード: 特権ユーザーが表領域をOracle Database間で移動できます。TRANSPORT_TABLESPACEパラメータを使用してこのモードを指定します。

- ユーザー・モード: 所有するすべてのオブジェクト(表、権限、索引、プロシージャなど)をインポートできます。特権ユーザーがユーザー・モードでインポートする場合、指定したユーザー・グループのユーザーのスキーマにあるすべてのオブジェクトをインポートできます。このモードを指定するには、FROMUSERパラメータを使用します。

- 表モード: 特定の表およびパーティションをインポートできます。特権ユーザーは、インポートする表を含むスキーマを指定して、その表を修飾できます。TABLESパラメータを使用してこのモードを指定します。

表23-3に、各モードでインポートされるオブジェクトのリストを示します。

注意:

表モードを使用してANYDATA型の列を含む表をインポートする場合、次のエラーが発生する場合があります。

ORA-22370: メソッドの使用方法が正しくありません。存在しない型。

このメッセージは、ANYDATA列が、データベースに存在しない他の型に依存することを示します。表モードを使用してANYDATA型を使用する表をインポートする前に、手動で、ターゲット・データベース内に依存型を作成する必要があります。

IMP_FULL_DATABASEロールを持つユーザーは、これらのモードのいずれかを指定する必要があります。指定しない場合、インポートはエラーになります。IMP_FULL_DATABASEロールを持たないユーザーがこれらのモードをいずれも指定しない場合は、ユーザー・レベルのインポートが実行されます。

表23-3 各モードでインポートされるオブジェクト

オブジェクト

表モード

ユーザー・モード

全データベース・モード

表領域モード

分析クラスタ

なし

あり

あり

なし

分析表/統計

あり

あり

あり

あり

アプリケーション・コンテキスト

なし

なし

あり

なし

監査情報

あり

あり

あり

なし

Bツリー索引、ビットマップ索引、ドメイン・ファンクション索引

あり脚注1

あり

あり

あり

クラスタ定義

なし

あり

あり

あり

列コメントおよび表コメント

あり

あり

あり

あり

データベース・リンク

なし

あり

あり

なし

デフォルト・ロール

なし

なし

あり

なし

ディメンション

なし

あり

あり

なし

ディレクトリ別名

なし

なし

あり

なし

外部表(データなし)

あり

あり

あり

なし

外部関数ライブラリ

なし

あり

あり

なし

表の所有者以外のユーザーが所有する索引

あり(特権ユーザーのみ)

あり

あり

あり

索引タイプ

なし

あり

あり

なし

JavaリソースおよびJavaクラス

なし

あり

あり

なし

ジョブ・キュー

なし

あり

あり

なし

ネストした表のデータ

あり

あり

あり

あり

オブジェクト権限

あり(表および索引のみ)

あり

あり

あり

表で使用されるオブジェクト型定義

あり

あり

あり

あり

オブジェクト型

なし

あり

あり

なし

演算子

なし

あり

あり

なし

パスワード履歴

なし

なし

あり

なし

インスタンスの事後処理およびオブジェクト

なし

なし

あり

なし

スキーマの事後プロシージャ処理およびオブジェクト

なし

あり

あり

なし

表の事後処理

あり

あり

あり

あり

表の事後プロシージャ処理およびオブジェクト

あり

あり

あり

あり

スキーマの事前プロシージャ・オブジェクトおよび処理

なし

あり

あり

なし

表の事前処理

あり

あり

あり

あり

表の事前プロシージャ処理

あり

あり

あり

あり

プライベート・シノニム

なし

あり

あり

なし

プロシージャ・オブジェクト

なし

あり

あり

なし

プロファイル

なし

なし

あり

なし

パブリック・シノニム

なし

なし

あり

なし

参照整合性制約

あり

あり

あり

なし

リフレッシュ・グループ

なし

あり

あり

なし

リソース・コスト

なし

なし

あり

なし

ロール権限

なし

なし

あり

なし

ロール

なし

なし

あり

なし

ロールバック・セグメント定義

なし

なし

あり

なし

表のセキュリティ・ポリシー

あり

あり

あり

あり

順序番号

なし

あり

あり

なし

スナップショット・ログ

なし

あり

あり

なし

スナップショットおよびマテリアライズド・ビュー

なし

あり

あり

なし

システム権限

なし

なし

あり

なし

表制約(主キー制約、一意制約、CHECK制約)

あり

あり

あり

あり

表データ

あり

あり

あり

あり

表定義

あり

あり

あり

あり

表領域定義

なし

なし

あり

なし

表領域の割当て制限

なし

なし

あり

なし

トリガー

あり

あり脚注2

あり脚注3

あり

他のユーザーが所有するトリガー

あり(特権ユーザーのみ)

なし

なし

なし

ユーザー定義

なし

なし

あり

なし

ユーザー・プロキシ

なし

なし

あり

なし

ユーザー・ビュー

なし

あり

あり

なし

ユーザー・ストアド・プロシージャ、ユーザー・ストアド・パッケージおよびユーザー・ストアド・ファンクション

なし

あり

あり

なし

脚注1

非特権ユーザーがエクスポートおよびインポートできるのは、そのユーザー自身が所有する表に関する索引のみです。他のユーザーが所有する表に関する索引や、ユーザー自身が所有する表に関して他のユーザーが作成した索引はエクスポートできません。特権ユーザーは、エクスポートおよびインポート対象に指定したユーザーの表に関する索引が、表の所有者以外のユーザーが作成したものであっても、その索引をエクスポートおよびインポートできます。指定したユーザーが他のユーザーの表に関する索引を所有しているときは、エクスポートするユーザーのリストに表の所有者であるユーザーを指定しないかぎり、その索引はエクスポートされません。

脚注2

特権ユーザーも非特権ユーザーも、そのユーザー自身が所有するすべてのトリガーを(他のユーザーが所有する表に関するトリガーの場合でも)、エクスポートおよびインポートできます。

脚注3

全体エクスポートでは、スキーマSYSが所有するトリガーはエクスポートされません。SYSトリガーは、全体インポートの前後のいずれかに手動で再作成する必要があります。このトリガーによってインポートの進行を妨げるような処理が定義されないように、インポートの後に再作成することをお薦めします。

インポート・パラメータ

この項では、インポート・コマンドライン・パラメータについて説明します。

BUFFER

デフォルト: オペレーティング・システムにより異なる

BUFFERに指定された整数は、転送したデータ行を格納するバッファのバイト数です。

BUFFERによって、インポートで挿入される配列の行数が決定します。所定の行配列の挿入に必要なバッファ・サイズは、次のように計算できます。

buffer_size = rows_in_array * maximum_row_size

LOB、LONG、BFILE、REF、ROWID、UROWIDまたはTIMESTAMPの各列が含まれている表には、1回に1行ずつ挿入されます。バッファ・サイズは(LOBおよびLONG列の場合以外は)、行全体を格納できるだけの容量が必要です。バッファ・サイズが足りずに表の最長の行を格納できない場合、インポート・ユーティリティはさらに大きいサイズのバッファを割り当てようとします。

DATE列の場合は、バッファの大きさが十分であれば一度に複数の行が挿入されます。

注意:

このパラメータのデフォルト値については、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

COMMIT

デフォルト: n

配列を挿入するたびにコミットするかどうかを指定します。デフォルトでは、各表はロードされた後にのみコミットされ、エラーが発生した場合はロールバックを実行してから次のオブジェクトに進みます。

表にネストした表の列または属性が含まれている場合、ネストした表の内容は、それぞれ別の表としてインポートされます。したがって、ネストした表の内容は、常に、外部表をコミットしたトランザクションとは別のトランザクションとしてコミットされます。

パーティション表の場合にCOMMIT=nを指定すると、エクスポート・ファイルのそれぞれのパーティションおよびサブパーティションは、別のトランザクションとしてインポートされます。

LOB、LONG、BFILE、REF、ROWID、UROWIDまたはTIMESTAMPの各列が含まれている表では、配列の挿入は行われません。COMMIT=yが指定されていると、各行の挿入後に表がコミットされます。

COMPILE

デフォルト: y

パッケージ、プロシージャおよびファンクションを、作成時にインポート・ユーティリティでコンパイルするかどうかを指定します。

COMPILE=nの場合、これらのユニットは最初の使用時にコンパイルされます。たとえば、ドメイン索引作成に使用されるパッケージは、ドメイン索引作成時にコンパイルされます。

関連項目:

「ストアド・プロシージャ、ファンクションおよびパッケージのインポート」

CONSTRAINTS

デフォルト: y

表の制約をインポートするかどうかを指定します。デフォルトでは、制約をインポートします。制約をインポートしないようにするには、このパラメータ値をnに設定します。

IOTおよびオブジェクト表の主キー制約は、常にインポートされます。

DATA_ONLY

デフォルト: n

データのみ(メタデータなし)をダンプ・ファイルからインポートする場合は、DATA_ONLY=yを指定します。

DATA_ONLY=yを指定すると、コマンドライン(またはパラメータ・ファイル)で入力されたインポート・パラメータのうち、メタデータと関連のあるパラメータは無効になります。つまり、ダンプ・ファイルからメタデータはインポートされないことになります。

メタデータに関連するパラメータは、COMPILE、CONSTRAINTS、DATAFILES、DESTROY、GRANTS、IGNORE、INDEXES、INDEXFILE、ROWS=n、SHOW、SKIP_UNUSABLE_INDEXES、STATISTICS、STREAMS_CONFIGURATION、STREAMS_INSTANTIATION、TABLESPACES、TOID_NOVALIDATE、TRANSPORT_TABLESPACE、TTS_OWNERSです。

DATAFILES

デフォルト: none

TRANSPORT_TABLESPACEにyを指定した場合、データベースに転送するデータ・ファイルを、このパラメータを使用して表示します。

関連項目:

「TRANSPORT_TABLESPACE」

DESTROY

デフォルト: n

データベースを構成する既存のデータ・ファイルを再利用するかどうかを指定します。つまり、DESTROY=yと指定すると、インポートではSQL CREATE TABLESPACE文のデータ・ファイル句にREUSEオプションが含められ、これにより、オリジナル・データベースのデータ・ファイルの内容が削除された後に、データ・ファイルが再利用されます。

エクスポート・ファイルには、各表領域内で使用されるデータ・ファイル名が含まれていることに注意してください。DESTROY=yを指定して、2つ目のデータベースを(テストまたはその他の目的で)同じシステム上に作成しようとすると、インポート・ユーティリティでは、表領域を作成するときに最初のデータベースのデータ・ファイルを上書きします。このような場合には、デフォルトのDESTROY=nを使用して、表領域が作成されるときにデータ・ファイルがすでに存在する場合、エラーが発生するようにする必要があります。また、オリジナル・データベースにインポートする必要がある場合は、既存のデータ・ファイルを置換しないでデータ・ファイルに追加するように、IGNORE=yを指定する必要があります。

注意:

データ・ファイルがRAWデバイスに格納されている場合は、DESTROY=nを指定しても、ファイルは上書きされます。

FEEDBACK

デフォルト: 0(ゼロ)

n行分のインポートを1つのピリオドで示すプログレス・バーの表示を指定します。たとえば、FEEDBACK=10を指定すると、10行分のインポートが終了するたびにピリオドが1つ表示されます。FEEDBACK値は、インポートされるすべての表に適用されるため、各表に対して個別には設定できません。

FILE

デフォルト: expdat.dmp

インポートするエクスポート・ファイル名を指定します。デフォルトの拡張子は、.dmpです。エクスポート・ユーティリティは、複数ファイルのエクスポートをサポートしているため(次のFILESIZEパラメータの説明を参照)、複数のインポート・ファイル名が必要な場合もあります。次に例を示します。

imp scott IGNORE=y FILE = dat1.dmp, dat2.dmp, dat3.dmp FILESIZE=2048

ユーザー自身がエクスポートしたファイルでなくても指定できますが、そのファイルに対する読取り権限が必要です。他のユーザーがエクスポートしたエクスポート・ファイルの場合は、IMP_FULL_DATABASEロールが必要です。

FILESIZE

デフォルト: オペレーティング・システムにより異なる

エクスポート時に指定したサイズと同じ最大ダンプ・ファイル・サイズを指定できます。

注意:

許容最大サイズは、オペレーティング・システムによって異なります。この最大値については、FILESIZEを指定する前に、ご使用のオペレーティング・システム固有のOracleマニュアルで確認してください。

FILESIZEの値は、数字にKB(キロバイト数)を付けて指定できます。たとえば、FILESIZE=2KBは、FILESIZE=2048と同じです。同様に、MBはメガバイト(1024×1024)を、GBはギガバイト(1024の3乗)を表します。Bはバイトの省略です。この場合、最終的なファイルサイズの算出に乗算は不要です(FILESIZE=2048Bは、FILESIZE=2048と同じです)。

FROMUSER

デフォルト: none

インポートするスキーマをカンマで区切ったリスト。このパラメータは、IMP_FULL_DATABASEロールを持つユーザーにのみ関係があります。このパラメータで、複数のスキーマを含むエクスポート・ファイル(たとえば、全体エクスポート・ダンプ・ファイルまたは複数スキーマのユーザー、ユーザー・モードのエクスポート・ダンプ・ファイルなど)からスキーマのサブセットをインポートできます。

ファンクション索引、ファンクション、プロシージャ、トリガー、型本体、ビューなどの内部に表示されるスキーマ名は、FROMUSERまたはTOUSERの処理には影響されません。影響を受けるのは、オブジェクト名のみです。インポートの完了後、TOUSERスキーマに含まれる項目が古いスキーマ(FROMUSER)を参照しているかどうかを手動で確認し、必要に応じて修正する必要があります。

通常は、インポート・パラメータのTOUSERとFROMUSERを組み合せて使用し、インポートのターゲットとなるスキーマの所有者ユーザー名のリストを指定します(「TOUSER」を参照)。インポート操作の前にターゲット・データベース内にTOUSERで指定するユーザーが存在している必要があります。存在していない場合、エラーが返されます。

TOUSERを指定しない場合、インポート操作では次のことが行われます。

- エクスポート・ファイルが、全データベース・モードのダンプ・ファイル、または複数スキーマ、ユーザー・モードのエクスポート・ダンプ・ファイルの場合、FROMUSERのスキーマへオブジェクトをインポートします。

- エクスポート・ファイルが単一のスキーマで、ユーザー・モードのエクスポート・ダンプ・ファイルが権限のないユーザーに作成された場合、(インポート時にFROMUSERスキーマが存在するかどうかにかかわらず)インポートするユーザーのスキーマにオブジェクトを作成します。

注意:

FROMUSER=SYSTEMを指定しても、システム・オブジェクトはインポートされず、ユーザーSYSTEMが所有するスキーマ・オブジェクトのみがインポートされます。

FULL

デフォルト: y

エクスポート・ダンプ・ファイル全体をインポートするかどうかを指定します。

全データベースのエクスポートおよびインポートについての考慮点

全データベースのエクスポートおよびインポートは、データベースの複製およびクリーンアップに有効です。ただし、問題が発生しないように、次の点に注意する必要があります。

- 全体エクスポートでは、スキーマSYSが所有するトリガーはエクスポートされません。SYSトリガーは、全体インポートの前後のいずれかに手動で再作成する必要があります。このトリガーによってインポートの進行を妨げるような処理が定義されないように、インポートの後に再作成することをお薦めします。

- 全体エクスポートでは、デフォルトのプロファイルもエクスポートされません。ソース・データベースでデフォルトのプロファイルを変更した場合(たとえば、スキーマSYSが所有するパスワード確認機能を追加するなど)は、事前に手動でその機能を作成し、インポートの完了後にターゲット・データベースでデフォルトのプロファイルを変更する必要があります。

- 可能な場合、開始前にエクスポートされたデータベースおよびインポートするデータベースの物理コピーを作成します。これによって、誤った操作をやり直すことができます。

- エクスポートの開始前に、次の情報を含むレポートを作成することをお薦めします。

- 表領域およびデータ・ファイルのリスト

- ロールバック・セグメントのリスト

- ユーザーごとの各オブジェクト型(表、索引など)の数

この情報で、表領域がすでに作成され、インポートが正常に完了したことを確認できます。

- エクスポートから完全に新しいデータベースを作成する場合、SYSTEMに余分なロールバック・セグメントを作成し、初期化パラメータ・ファイル(init.ora)で使用可能にしてからインポートを開始します。

- インポートの実行時に、正しいインスタンスを指していることを確認します。一部のUNIXシステムでは、サブシェルの入力のみで、インポート操作を行ったデータベースが変更される場合があります。

- すべての表領域が作成されるまで、複数のデータベースを含むシステムでは全体インポートを行わないでください。全体インポートは、エクスポートされたデータベースと同じデータ・ファイル名を使用して、未定義の表領域を作成します。このため、次のような状況で問題が発生します。

- データ・ファイルが他のいずれかのデータベースに属する場合、データ・ファイルは破損します。このことは特に、エクスポートされるデータベースが同じシステムに存在する場合に当てはまります(そのデータ・ファイルがインポート先のデータベースによって再利用されるため)。

- データ・ファイルの名前が既存のオペレーティング・システム・ファイルの名前と同じ場合も問題が発生します。

GRANTS

デフォルト: y

オブジェクト権限をインポートするかどうかを指定します。

デフォルトでは、エクスポートされたオブジェクト権限はすべてインポートされます。ユーザー・モードでエクスポートが実行されている場合は、第1レベルのオブジェクト権限(所有者によって付与されているもの)のみがエクスポート・ファイルにインポートされます。

全データベース・モードでエクスポートが実行されている場合は、下位レベルのオブジェクト権限(WITH GRANT OPTIONで権限が付与されたユーザーによって付与されているもの)を含むすべての権限が、エクスポート・ファイルにインポートされます。GRANTS=nを指定すると、オブジェクト権限はインポートされません(GRANTS=nを指定しても、システム権限はインポートされます)。

注意:

エクスポート・ユーティリティでは、セキュリティ上の理由から、インポートに影響するデータ・ディクショナリ・ビューの権限はエクスポートされません。このような権限がエクスポートされると、インポートしたユーザーが気付かないうちに、アクセス権が変更される場合があります。

HELP

デフォルト: none

インポート・パラメータの説明を表示します。ヘルプの内容を表示するには、コマンドラインでimp HELP=yを入力します。

IGNORE

デフォルト: n

オブジェクト作成エラーの処理方法を指定します。デフォルトのIGNORE=nが指定されている場合は、オブジェクト作成エラーがログに記録または表示されて、インポートが続行されます。

IGNORE=yを指定すると、データベース・オブジェクトの作成時に作成エラーが発生しても、このエラーは無視され、エラーはレポートされずに継続します。

無視されるのはオブジェクト作成エラーのみです。オペレーティング・システム、データベース、SQLなどのエラーは無視されず、場合によっては処理が停止します。

IGNORE=yが指定され、1つのエクスポート・ファイルから何回もリフレッシュが行われる場合、オブジェクトが何回も作成される場合があります(ただし、各オブジェクトには一意のシステム定義名が付けられます)。特定のオブジェクト(たとえば、制約など)に対しては、CONSTRAINTS=nを指定してインポートを実行すると、この問題を回避できます。CONSTRAINTS=nを指定して全インポートを実行すると、表の制約はインポートされません。

表がすでに存在する場合、IGNORE=yを指定すると、行は既存の表にインポートされ、エラーやメッセージは出力されません。新しい記憶域パラメータを使用するため、またはクラスタにすでに表を作成済であるため、すでに存在する表にデータをインポートする場合があります。

表がすでに存在する場合、IGNORE=nを指定すると、エラーがレポートされ、表は、行が挿入されないままスキップされます。また、表に依存するオブジェクト(索引、権限、制約など)は作成されません。

注意:

既存の表へのインポート時に、表の列の索引が一意でない場合、行データが重複することがあります。

INDEXES

デフォルト: y

索引をインポートするかどうかを指定します。LOB索引、OID索引、一意制約索引など、システムによって作成される索引は、このパラメータの指定に関係なく、インポート・ユーティリティによって自動的に再作成されます。

INDEXES=nを指定すると、すべてのユーザー作成索引をインポートの終了後に作成できます。

インポート時、ターゲット表にすでに索引が存在する場合は、データ挿入時にターゲット表の索引のメンテナンスを実行します。

INDEXFILE

デフォルト: none

索引作成文を受け取るファイルを指定します。

このパラメータを指定すると、指定したモードでの索引作成文は、データベース中に索引を作成するために使用されるのではなく、抽出されて指定のファイルに書き込まれます。データベース・オブジェクトはインポートされません。

インポート・パラメータCONSTRAINTSにyを設定している場合、索引ファイルに表制約も書き込まれます。

その後、このファイルを編集して(記憶域パラメータの変更など)、索引を作成するためのSQLスクリプトとして使用できます。

ファイル内で定義されている索引をさらに簡単に識別するために、エクスポート・ファイルのCREATE TABLE文およびCREATE CLUSTER文がコメントとして含まれます。

この機能を使用するには、次の手順を実行します。

1. INDEXFILEパラメータを使用してインポートを行い、索引作成文のファイルを作成します。

2. ファイルを編集して、有効なパスワードをconnect文字列に追加します。

3. INDEXES=nを指定してインポートを再実行します。
(この手順でデータベース・オブジェクトがインポートされますが、エクスポート・ファイルに格納されている索引定義は使用されません。)

4. 索引作成文のファイルをSQLスクリプトとして実行し、索引を作成します。
INDEXFILEパラメータを指定できるのは、FULL=y、FROMUSER、TOUSERまたはTABLESパラメータを指定した場合のみです。

LOG

デフォルト: none

情報メッセージおよびエラー・メッセージを受け取るファイル(import.logなど)を指定します。ログ・ファイルを指定すると、端末画面およびログ・ファイルの両方にインポートに関する情報が書き込まれます。

PARFILE

デフォルト: なし

インポート・パラメータのリストを格納するファイルのファイル名を指定します。パラメータ・ファイルの使用方法の詳細は、「パラメータ・ファイル」を参照してください。

RECORDLENGTH

デフォルト: オペレーティング・システムにより異なる

ファイル・レコードの長さをバイト単位で指定します。RECORDLENGTHパラメータは、異なるデフォルト値を使用する別のオペレーティング・システムにエクスポート・ファイルを転送する場合に指定する必要があります。

このパラメータを指定しない場合、ご使用のプラットフォーム固有のBUFSIZの値がデフォルトになります。

RECORDLENGTHは、ご使用のシステムのBUFSIZの値以上の任意の値に設定できます。(最大値は64KBです。)RECORDLENGTHパラメータの変更により影響を受けるのは、データベースに書き出す前に累積されるデータのサイズのみです。オペレーティング・システム・ファイルのブロック・サイズには影響しません。

このパラメータは、インポート・ユーティリティのI/Oバッファのサイズ指定にも使用できます。

RESUMABLE

デフォルト: n

RESUMABLEパラメータを使用して、再開可能な領域割当てを有効または無効にします。このパラメータはデフォルトでは無効なため、関連するRESUMABLE_NAMEおよびRESUMABLE_TIMEOUTを使用するには、RESUMABLE=yを設定する必要があります。

関連項目:

- 再開可能な領域割当ての詳細は、『Oracle Database管理者ガイド』を参照してください

RESUMABLE_NAME

デフォルト: 'User USERNAME(USERID), Session SESSIONID, Instance INSTANCEID'

再開可能な文を指定します。この値はユーザー定義のテキスト文字列で、USER_RESUMABLEまたはDBA_RESUMABLEビューに挿入して、一時停止されている特定の再開可能な文を識別できます。

RESUMABLEパラメータをyに設定して、再開可能な領域割当てを有効にしないかぎり、このパラメータは無視されます。

RESUMABLE_TIMEOUT

デフォルト: 7200秒(2時間)

エラー修正に必要な時間を指定します。タイムアウト時間内にエラーを修正できない場合は、文の実行が途中で終了します。

RESUMABLEパラメータをyに設定して、再開可能な領域割当てを有効にしないかぎり、このパラメータは無視されます。

ROWS

デフォルト: y

表のデータ行をインポートするかどうかを指定します。

ROWS=nを指定すると、インポート操作の終了後、インポートされたすべての表の統計がロックされます。

SHOW

デフォルト: n

SHOW=yを指定すると、エクスポート・ダンプ・ファイルの内容が画面に表示されますが、インポートは実行されません。エクスポート・ファイルに含まれるSQL文は、インポート・ユーティリティでその文が実行される順序で表示されます。

SHOWパラメータを指定できるのは、FULL=y、FROMUSER、TOUSERまたはTABLESパラメータを指定した場合のみです。

SKIP_UNUSABLE_INDEXES

デフォルト: 初期化パラメータ・ファイルで指定した、Oracle Databaseの構成パラメータSKIP_UNUSABLE_INDEXESの値

SKIP_UNUSABLE_INDEXESパラメータは、インポート・ユーティリティおよびOracle Databaseの両方で提供されます。インポート・ユーティリティのSKIP_UNUSABLE_INDEXESパラメータは、インポート・ユーティリティのコマンドラインで指定します。Oracle DatabaseのSKIP_UNUSABLE_INDEXESパラメータは、初期化パラメータ・ファイルの構成パラメータとして指定します。相互に与える影響を理解しておく必要があります。

インポート・ユーティリティのコマンドラインでSKIP_UNUSABLE_INDEXESの値を指定しない場合、初期化パラメータ・ファイルで指定した、SKIP_UNUSABLE_INDEXES構成パラメータのデータベース設定が使用されます。

インポート・コマンドラインでSKIP_UNUSABLE_INDEXESの値を指定すると、インポートは、初期化パラメータ・ファイルに指定されているSKIP_UNUSABLE_INDEXES構成パラメータの値を上書きします。

yの値を指定すると、(システムまたはユーザーのいずれかによって)索引使用禁止状態に設定されている索引の作成が、インポート・ユーティリティではスキップされます。他の索引(事前に索引使用禁止に設定されていない索引)に対しては、行の挿入時にメンテナンス処理が行われます。

このパラメータを使用すると、選択した索引パーティションに対する索引のメンテナンスを、行データの挿入が完了するまで延期できます。インポート後、影響を受けた索引パーティションの再作成が必要です。

注意:

一意で使用禁止状態の索引に対しては、索引メンテナンスをスキップできません。したがって、一意の索引はSKIP_UNUSABLE_INDEXESパラメータの影響を受けません。

INDEXES=nを指定してINDEXFILEパラメータを使用すると、索引の再作成を行うSQLスクリプトを作成できます。SKIP_UNUSABLE_INDEXESパラメータを指定しない場合、行挿入によって使用禁止索引をメンテナンスすると、その行挿入によってエラーが発生します。

関連項目:

『Oracle Database SQL言語リファレンス』のALTER SESSION文についての説明を参照してください

STATISTICS

デフォルト: ALWAYS

インポート時のデータベース・オプティマイザ統計の処理方法を指定します。

オプションは次のとおりです。

- ALWAYS
データベース・オプティマイザ統計に問題があるかどうかにかかわらず、常にインポートします。

- NONE
データベース・オプティマイザ統計をインポートまたは再計算しません。

- SAFE
データベース・オプティマイザ統計に問題がない場合のみにインポートします。問題がある場合は、オプティマイザ統計を再計算します。

- RECALCULATE
データベース・オプティマイザ統計をインポートしません。かわりに、インポート時に再計算します。この場合、ダンプ・ファイルを作成した元のエクスポート操作で、必要なANALYZE文を生成している(STATISTICS=NONEを指定してエクスポートを実行していない)必要があります。ANALYZE文は、ダンプ・ファイルに含まれ、インポート操作で表統計の再計算に使用されます。

関連項目:

- オプティマイザおよびオプティマイザが使用する統計の詳細は、『Oracle Database概要』を参照してください。

- 「統計情報のインポート」

STREAMS_CONFIGURATION

デフォルト: y

エクスポート・ダンプ・ファイル内に存在する一般的なStreamsメタデータをインポートするかどうかを指定します。

関連項目:

『Oracle Streamsレプリケーション管理者ガイド』

STREAMS_INSTANTIATION

デフォルト: n

エクスポート・ダンプ・ファイル内に存在するStreamsインスタンス化メタデータをインポートするかどうかを指定します。ストリーム環境でインスタンス化の一部としてインポートする場合は、yを指定します。

関連項目:

『Oracle Streamsレプリケーション管理者ガイド』

TABLES

デフォルト: none

表モード・インポートでインポートすることを指定します。インポートの対象となる表名、パーティション名およびサブパーティション名をリストとして指定します。表レベル・インポートでは、パーティション表または非パーティション表全体をインポートできます。TABLESパラメータでは、インポート対象は、表およびその関連オブジェクトに限定されます(表23-3を参照)。TABLESパラメータでは、次の値を指定できます。

- tablenameには、インポートされる表の名前を指定します。リストにパーティション表が含まれる場合、パーティション名を指定しないと、すべてのパーティションおよびサブパーティションがインポートされます。エクスポートされたすべての表をインポートするには、アスタリスク(*)のみを表名パラメータとして指定します。
tablenameは、任意の数の「%」パターン一致文字を含むことができます。各「%」パターン一致文字は、エクスポート・ファイルの表名の0個以上の文字と一致します。リスト中の固有の表名の指定されたすべてのパターンと一致する名前を持つすべての表が、選択されてインポートされます。すべてのパターン一致文字で構成され、パーティション名を含まないリスト中の表名によって、エクスポートされたすべての表がインポートされます。

- partition_nameおよびsubpartition_nameによって、パーティション表内で指定された1つ以上のパーティションまたはサブパーティションにインポートが制限されます。

構文の形式は、次のとおりです。

tablename:partition_name

tablename:subpartition_name

tablename:partition_nameを使用する場合、指定された表はパーティション化されている必要があり、partition_nameはそのいずれかのパーティションまたはサブパーティションの名前である必要があります。指定された表がパーティション化されていない場合、partition_nameは無視されて表全体がインポートされます。

一度に指定できる表の数は、コマンドラインの制限によって決まります。

エクスポート・ファイルの処理中、エクスポート・ファイルの各表名は、パラメータで指定された順に、リスト中の各表名と比較されます。あいまいな処理が行われたり、処理時間が極端に長くならないように、固有の表名がリストの始めに表示され、一般的な表名(パターンを使用したもの)がリストの終わりに表示される必要があります。

エクスポート時には表名をスキーマ名(scott.empなど)で修飾できますが、インポート時にはできません。次に、間違って指定されたTABLESパラメータの例を示します。

imp TABLES=(jones.accts, scott.emp, scott.dept)

これらの表をインポートするには、次のように指定します。

imp FROMUSER=jones TABLES=(accts)
imp FROMUSER=scott TABLES=(emp,dept)

詳細は、「パターン一致を使用して様々な表をインポートする例」を参照してください。

注意:

UNIXなど一部のオペレーティング・システムで、カッコなどの特殊文字を使用する場合は、特殊文字として扱われないように、その文字の前にエスケープ文字を使用する必要があります。UNIXでは、次の例に示すように、エスケープ文字としてバックスラッシュ(\)を使用します。

TABLES=\(emp,dept\)

表名の制限

表名には次の制限があります。

- デフォルトでは、表名は大文字でデータベースに格納されます。表名が大文字と小文字または小文字のみで表記され、大/小文字を区別する場合、名前を引用符で囲む必要があります。したがって、表名は、データベースに格納されている表名と完全に一致するように指定する必要があります。
ただし、オペレーティング・システムによっては、コマンドラインの引用符自体をエスケープする必要がある場合があります。次に、異なるインポート・モードで大/小文字の区別を保持する方法を示します。

- コマンドライン・モード

tables='\"Emp\"'

- 対話方式モード

Table(T) to be exported: "Exp"

- パラメータ・ファイル・モード

tables='"Emp"'

- 表名を引用符で囲まないかぎり、コマンドラインで指定する表名にシャープ(#)記号は使用できません。同様に、パラメータ・ファイルでは、表名が引用符で囲まれていないかぎり、表名にシャープ(#)記号を使用すると、インポート・ユーティリティではシャープ(#)記号より右側の文字がコメントとして解釈されます。
たとえば、パラメータ・ファイルに次のコマンドラインが記述されている場合、インポート・ユーティリティではemp#の右側がすべてコメントとして解釈されるため、表deptおよびmydataはインポートされません。

TABLES=(emp#, dept, mydata)

ただし、次の例では、emp#が引用符で囲まれているため、3つの表はすべてインポートされます。

TABLES=("emp#", dept, mydata)

注意:

オペレーティング・システムによっては、一重引用符を使用する必要がある場合と、二重引用符を使用する必要がある場合があります。ご使用のオペレーティング・システム固有のドキュメントで確認してください。表のネーミング方法に制限があるオペレーティング・システムもあります。

たとえば、UNIXのCシェルではドル記号($)やシャープ(#)(またはその他の特殊文字)には特別な意味があります。これらの文字をシェルを介してインポートするには、エスケープ文字を使用する必要があります。

TABLESPACES

デフォルト: none

TRANSPORT_TABLESPACEにyを指定した場合、データベースに転送する表領域を、このパラメータを使用して表示します。エクスポート・ファイルに複数の表領域がある場合は、そのすべての表領域をインポート操作の一部として指定する必要があります。

詳細は、「TRANSPORT_TABLESPACE」を参照してください。

TOID_NOVALIDATE

デフォルト: none

型を参照している表のインポート時に、その名前の型がすでにデータベースに存在している場合は、その既存の型が、実際にその表で使用されているかどうか(実際は異なる型で、単に同じ名前であるだけではないか)を確認します。

この検証のために、型の一意の識別子(TOID)と、エクスポート・ファイルに格納された識別子が比較されます。TOIDが一致しない場合、その表の行はインポートされません。

この妥当性チェックをしてはいけない型もあります(たとえば、その型がカートリッジのインストールによって作成された場合)。TOID_NOVALIDATEパラメータを使用して、TOIDと比較しない型を指定できます。

構文は次のとおりです:

TOID_NOVALIDATE=([schemaname.]typename [, ...])

次に例を示します。

imp scott TABLES=jobs TOID_NOVALIDATE=typ1
imp scott TABLES=salaries TOID_NOVALIDATE=(fred.typ0,sally.typ2,typ3)

その型にスキーマ名を指定しない場合、インポートするユーザーのスキーマがデフォルトになります。たとえば、前述の最初の例では、型typ1はscott.typ1がデフォルトになり、2番目の例では、型typ3はscott.typ3がデフォルトになります。

TOID_NOVALIDATEは、表の列型のみを処理します。表型には影響しません。

通常のインポートでは、削除される型が含まれていると、次のように出力されます。

[...]
. importing IMP3's objects into IMP3
. . skipping TOID validation on type IMP2.TOIDTYP0
. . importing table                  "TOIDTAB3"
[...]

注意:

型の識別子を比較しないように指定する場合は、ユーザーの責任において、インポートされる型の属性リストを既存の型の属性リストと一致させるようにしてください。これらの属性リストが一致しない場合、インポート結果は保証されません。

TOUSER

デフォルト: none

インポートの対象となるスキーマを所有するユーザー名のリストを指定します。インポート操作の前にユーザー名が存在している必要があります。存在していない場合は、エラーが返されます。このパラメータを使用するには、IMP_FULL_DATABASEロールが必要です。オブジェクトがもともと入っていたスキーマと異なるスキーマにインポートする場合は、TOUSERを指定してください。次に例を示します。

imp FROMUSER=scott TOUSER=joe TABLES=emp

複数のスキーマを指定する場合、スキーマ名は対で指定します。次の例では、scottのオブジェクトをjoeのスキーマに、fredのオブジェクトをtedのスキーマにインポートします。

imp FROMUSER=scott,fred TOUSER=joe,ted

FROMUSERリストがTOUSERリストより長い場合、残りのスキーマは、通常のデフォルトの規則に従って、FROMUSERスキーマにインポートされるか、またはインポートを実行するユーザーのスキーマにインポートされます。余分なオブジェクトがTOUSERスキーマにインポートされるようにするには、次の構文を使用します。

imp FROMUSER=scott,adams TOUSER=ted,ted

ユーザーtedは2回指定されています。

関連項目:

FROMUSERおよびTOUSERを使用する場合の制限の詳細は、「FROMUSER」を参照してください

TRANSPORT_TABLESPACE

デフォルト: n

yを指定した場合、エクスポート・ファイルからトランスポータブルの表領域メタデータがインポートされます。

暗号化された列は、トランスポータブル表領域モードではサポートされていません。

注意:

トランスポータブル表領域をエクスポートした後、それよりも古いリリース・レベルのデータベースにインポートすることはできません。ターゲット・データベースのリリース・レベルは、ソース・データベース以上である必要があります。

TTS_OWNERS

デフォルト: none

TRANSPORT_TABLESPACEにyを指定した場合、このパラメータを使用して、一連のトランスポータブル表領域のデータの所有者ユーザーを表示できます。

「TRANSPORT_TABLESPACE」を参照してください。

USERID(ユーザー名/パスワード)

デフォルト: none

インポートを実行するユーザーのユーザー名、パスワードおよびオプションの接続文字列を指定します。

ユーザーSYSとして接続する場合は、接続文字列にAS SYSDBAも指定する必要があります。オペレーティング・システムによっては、AS SYSDBAを特殊文字列とみなし、その文字列全体を引用符で囲む必要があります。

関連項目:

- Oracle Netに接続文字列を指定する方法の詳細は、ご使用のOracle Netプロトコルのユーザーズ・ガイドを参照してください。

VOLSIZE

デフォルト: none

各テープ・ボリュームのダンプ・ファイルに最大バイト数を指定します。

VOLSIZEパラメータの最大値は、ご使用のプラットフォーム上に64ビットで格納できる最大値と同じです。

VOLSIZEの値は、数字にKB(キロバイト数)を付けて指定できます。たとえば、VOLSIZE=2KBは、VOLSIZE=2048と同じです。同様に、MBはメガバイト(1024×1024)を、GBはギガバイト(1024の3乗)を表します。Bはバイトの省略です。この場合、最終的なファイル・サイズの算出に乗算は不要です(VOLSIZE=2048Bは、VOLSIZE=2048と同じです)。

インポート・セッションの例

この項では、インポート・セッションの例をいくつか取り上げ、パラメータ・ファイル方式およびコマンドライン方式の使用方法を示します。ここでは、次のシナリオを示します。

- 特定のユーザーの表を選択してインポートする例

- 別のユーザーによってエクスポートされた表をインポートする例

- あるユーザーの表を別のユーザーへインポートする例

- パーティション・レベル・インポートでのインポート・セッションの例

- パターン一致を使用して様々な表をインポートする例

特定のユーザーの表を選択してインポートする例

この例では、管理者が全データベース・エクスポート・ファイルを使用して、dept表およびemp表をscottのスキーマにインポートします。

パラメータ・ファイル方式

> imp PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

FILE=dba.dmp
SHOW=n
IGNORE=n
GRANTS=y
FROMUSER=scott
TABLES=(dept,emp)

コマンドライン方式

> imp FILE=dba.dmp FROMUSER=scott TABLES=(dept,emp)

インポート・メッセージ

使用しているインポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。また、状態メッセージも表示されます。

別のユーザーによってエクスポートされた表をインポートする例

この例では、blakeがエクスポートしたファイルからunit表およびmanager表をscottのスキーマにインポートします。

パラメータ・ファイル方式

> imp PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

FILE=blake.dmp
SHOW=n
IGNORE=n
GRANTS=y
ROWS=y
FROMUSER=blake
TOUSER=scott
TABLES=(unit,manager)

コマンドライン方式

> imp FROMUSER=blake TOUSER=scott FILE=blake.dmp TABLES=(unit,manager)

インポート・メッセージ

使用しているインポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。また、状態メッセージも表示されます。

あるユーザーの表を別のユーザーへインポートする例

この例では、データベース管理者(DBA)がユーザーscottのすべての表をユーザーblakeのアカウントにインポートします。

パラメータ・ファイル方式

> imp PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

FILE=scott.dmp
FROMUSER=scott
TOUSER=blake
TABLES=(*)

コマンドライン方式

> imp FILE=scott.dmp FROMUSER=scott TOUSER=blake TABLES=(*)

インポート・メッセージ

使用しているインポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

.
.
.
Warning: the objects were exported by SCOTT, not by you

import done in WE8DEC character set and AL16UTF16 NCHAR character set
. importing SCOTT's objects into BLAKE
. . importing table                        "BONUS"          0 rows imported
. . importing table                         "DEPT"          4 rows imported
. . importing table                          "EMP"         14 rows imported
. . importing table                     "SALGRADE"          5 rows imported
Import terminated successfully without warnings.

パーティション・レベル・インポートでのインポート・セッションの例

この項では、複数のパーティションがある表、パーティションとサブパーティションがある表、および異なる列で再パーティション化した表のインポートについて説明します。

例1: パーティション・レベル・インポート

この例では、empは、P1、P2およびP3で構成されているパーティション表です。

表レベルのエクスポート・ファイルを作成するには、次のコマンドを使用します。

> exp scott TABLES=emp FILE=exmpexp.dat ROWS=y

エクスポート・メッセージ

使用しているエクスポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

.
.
.
About to export specified tables via Conventional Path ...
. . exporting table                            EMP
. . exporting partition                             P1          7 rows exported
. . exporting partition                             P2         12 rows exported
. . exporting partition                             P3          3 rows exported
Export terminated successfully without warnings.

パーティション・レベルのインポートでは、インポートの対象に、エクスポートした表の特定のパーティションを指定できます。この例では、emp表のP1およびP3を指定します。

> imp scott TABLES=(emp:p1,emp:p3) FILE=exmpexp.dat ROWS=y

インポート・メッセージ

使用しているインポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。また、状態メッセージも表示されます。

例2: コンポジット・パーティション表のパーティション・レベル・インポート

この例では、コンポジット・パーティション表のパーティションおよびサブパーティションがインポートされます。empは、2つのコンポジット・パーティションP1およびP2のパーティション表です。パーティションP1には、3つのサブパーティションP1_SP1、P1_SP2およびP1_SP3があります。パーティションP2には、2つのサブパーティションP2_SP1およびP2_SP2があります。

表レベルのエクスポート・ファイルを作成するには、次のコマンドを使用します。

> exp scott TABLES=emp FILE=exmpexp.dat ROWS=y

エクスポート・メッセージ

使用しているエクスポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

コマンドラインで実行されると次のエクスポート・メッセージが表示されます。

.
.
.
About to export specified tables via Conventional Path ...
. . exporting table                            EMP
. . exporting composite partition                   P1
. . exporting subpartition                      P1_SP1          2 rows exported
. . exporting subpartition                      P1_SP2         10 rows exported
. . exporting subpartition                      P1_SP3          7 rows exported
. . exporting composite partition                   P2
. . exporting subpartition                      P2_SP1          4 rows exported
. . exporting subpartition                      P2_SP2          2 rows exported
Export terminated successfully without warnings.

次のインポート・コマンドでは、emp表にあるコンポジット・パーティションP1のサブパーティションP1_SP2およびP1_SP3と、emp表にあるコンポジット・パーティションP2のすべてのサブパーティションがインポートされます。

> imp scott TABLES=(emp:p1_sp2,emp:p1_sp3,emp:p2) FILE=exmpexp.dat ROWS=y

インポート・メッセージ

使用しているインポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

.
.
.
. importing SCOTT's objects into SCOTT
. . importing subpartition              "EMP":"P1_SP2"         10 rows imported
. . importing subpartition              "EMP":"P1_SP3"          7 rows imported
. . importing subpartition              "EMP":"P2_SP1"          4 rows imported
. . importing subpartition              "EMP":"P2_SP2"          2 rows imported
Import terminated successfully without warnings.

例3: 別の列での表の再パーティション化

この例では、emp表に、empno列に基づく2つのパーティションがあります。emp表をdeptno列で再パーティション化します。

別の列で表を再パーティション化するには、次の手順を実行してください。

1. エクスポートを実行して、データを保存します。

2. データベースから表を削除します。

3. 表を新しいパーティションに分割して再作成します。

4. 表データをインポートします。

次に、これらの手順の例を示します。

> exp scott table=emp file=empexp.dat
.
.
.

About to export specified tables via Conventional Path ...
. . exporting table                            EMP
. . exporting partition                        EMP_LOW          4 rows exported
. . exporting partition                       EMP_HIGH         10 rows exported
Export terminated successfully without warnings.

SQL> connect scott
Connected.
SQL> drop table emp cascade constraints;
Statement processed.
SQL> create table emp
2    (
3    empno    number(4) not null,
4    ename    varchar2(10),
5    job      varchar2(9),
6    mgr      number(4),
7    hiredate date,
8    sal      number(7,2),
9    comm     number(7,2),
10    deptno   number(2)
11    )
12 partition by range (deptno)
13   (
14   partition dept_low values less than (15)
15     tablespace tbs_1,
16   partition dept_mid values less than (25)
17     tablespace tbs_2,
18   partition dept_high values less than (35)
19     tablespace tbs_3
20   );
Statement processed.
SQL> exit

> imp scott tables=emp file=empexp.dat ignore=y
.
.
.
import done in WE8DEC character set and AL16UTF16 NCHAR character set
. importing SCOTT's objects into SCOTT
. . importing partition                "EMP":"EMP_LOW"          4 rows imported
. . importing partition               "EMP":"EMP_HIGH"         10 rows imported
Import terminated successfully without warnings.

次に示すSQLのSELECT文では、データはdeptno列でパーティション化されます。

SQL> connect scott
Connected.
SQL> select empno, deptno from emp partition (dept_low);
EMPNO      DEPTNO
---------- ----------
7782         10
7839         10
7934         10
3 rows selected.
SQL> select empno, deptno from emp partition (dept_mid);
EMPNO      DEPTNO
---------- ----------
7369         20
7566         20
7788         20
7876         20
7902         20
5 rows selected.
SQL> select empno, deptno from emp partition (dept_high);
EMPNO      DEPTNO
---------- ----------
7499         30
7521         30
7654         30
7698         30
7844         30
7900         30
6 rows selected.
SQL> exit;

パターン一致を使用して様々な表をインポートする例

この例では、パターン一致を使用して、ユーザーscottの様々な表をインポートします。

パラメータ・ファイル方式

imp PARFILE=params.dat

params.datファイルには、次の情報が格納されています。

FILE=scott.dmp
IGNORE=n
GRANTS=y
ROWS=y
FROMUSER=scott
TABLES=(%d%,b%s)

コマンドライン方式

imp FROMUSER=scott FILE=scott.dmp TABLES=(%d%,b%s)

インポート・メッセージ

使用しているインポート・ユーティリティのリリース情報および接続しているOracle Databaseのリリース情報が表示されます。その後で、次に示すような状態メッセージが表示されます。

.
.
.
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses JA16SJIS character set (possible charset conversion)
. importing SCOTT's objects into SCOTT
. . importing table                  "BONUS"          0 rows imported
. . importing table                   "DEPT"          4 rows imported
. . importing table               "SALGRADE"          5 rows imported
Import terminated successfully without warnings.

終了コードによる結果の検査と表示

インポート・ユーティリティでは、操作の完了後、すぐに実行結果を確認できます。プラットフォームによっては、実行結果はプロセス終了コードに通知され、ログ・ファイルにも記録されます。これによって、コマンドラインやスクリプトからの出力を確認できます。表23-4に、様々な結果の終了コードを示します。

表23-4 インポート・ユーティリティの終了コード

結果

終了コード

インポートは警告なしで正常終了しました。

EX_SUCC

インポートは正常に終了しましたが、警告が発生しました。

EX_OKWARN

エラーが発生したためインポートを終了します。

EX_FAIL

UNIXの場合、終了コードは次のようになります。

EX_SUCC   0
EX_OKWARN 0
EX_FAIL   1

インポート中のエラー処理

この項では、データベース・オブジェクトのインポート時に発生する可能性のあるエラーについて説明します。

行エラー

整合性制約違反またはデータが無効なために行のインポートが拒否されると、警告メッセージが表示されますが、その表の残りの行は引き続き処理されます。「tablespace full」というエラーなど、後続のすべての行に影響するエラーもあります。このようなエラーの場合には、現行の表の処理は停止され、次の表にスキップします。

RESUMABLE=yパラメータが指定されている場合、「tablespace full」エラーによって、インポートが一時停止することもあります。

整合性制約違反

次の整合性制約に違反している行があると行エラーが発生します。

- NOT NULL制約

- 一意制約

- 主キー(NOT NULLおよび一意)制約

- 参照整合性制約

- CHECK制約

関連項目:

- アプリケーションで整合性制約を使用する方法の詳細は、『Oracle Database開発ガイド』を参照してください。

- 整合性制約の詳細は、『Oracle Database概要』を参照してください。

無効なデータ

データベース内の表の列定義が、エクスポート・ファイル内の列定義と異なるときにも行エラーが発生します。無効データ・エラーは、新しい表の列より長いデータの挿入、無効なデータ型またはその他のINSERTエラーによって発生します。

データベース・オブジェクトのインポートでのエラー

データベース・オブジェクトをインポートするときにエラーが発生する理由にはいろいろありますが、この項ではその理由について説明します。これらのエラーが発生すると、現行のデータベース・オブジェクトのインポートは中断されます。その後、インポート・ユーティリティでは、エクスポート・ファイルの次のデータベース・オブジェクトが継続して処理されます。

既存オブジェクト

インポートするオブジェクトがデータベース中にすでに存在していると、オブジェクト作成エラーが発生します。これ以降の処理は、IGNOREパラメータに指定されている値によって異なります。

IGNORE=n(デフォルト)が指定されている場合、エラーが報告され、次のデータベース・オブジェクトが継続して処理されます。現行のデータベース・オブジェクトは置き換えられません。オブジェクトが表の場合、エクスポート・ファイル内の行はインポートされません。

IGNORE=yが指定されている場合、オブジェクト作成エラーは報告されません。データベース・オブジェクトは置き換えられません。オブジェクトが表の場合、行がインポートされます。無視できるエラーはオブジェクト作成エラーのみです。他のすべてのエラー(オペレーティング・システムのエラー、データベースのエラー、SQLのエラーなど)は報告されます。また、処理が停止することもあります。

注意:

IGNORE=yを指定した場合、表の1つ以上の列に対してUNIQUEで整合性制約を指定しないかぎり、その表に対して重複した行が挿入されます。たとえば、誤って2回インポートを実行した場合などがこれに該当します。

順序

インポート処理で、順序番号をエクスポート・ファイルの値に設定しなおす必要がある場合は、順序を削除してください。インポートでは、既存の順序の削除と再作成は行われません。そのため、順序は、インポートの前に削除されない場合、エクスポート・ファイルに保存されている値には設定されません。順序がすでに存在している場合、エクスポート・ファイルのCREATE SEQUENCE文は失敗し、その順序はインポートされません。

リソース・エラー

リソースの制限によって、オブジェクトがインポートされないことがあります。たとえば、表のインポート中に、内部的な問題またはメモリーなどのリソース不足によって、リソース・エラーが発生する場合があります。

行のインポート中にリソース・エラーが発生すると、現行の表の処理が中止され、次の表にスキップします。COMMIT=yを指定している場合、現行の表のインポート済の部分がコミットされます。指定していない場合は、現行の表の処理がロールバックされた後で、インポートが続行されます。「COMMIT」を参照してください。

ドメイン索引のメタデータ

ドメイン索引は、無名PL/SQLブロックでインポートされる、アプリケーション固有のメタデータと関連付けることができます。これらのPL/SQLブロックは、インポート時にCREATE INDEX文より優先して実行されます。PL/SQLブロックにエラーが発生した場合、メタデータが索引の一部分とみなされるため、関連付けられた索引は作成されません。

表レベル・インポートおよびパーティション・レベル・インポート

表、パーティションおよびサブパーティションのインポートは、次のように実行できます。

- 表レベル・インポート: エクスポート・ファイルのすべてのデータをインポートします。

- パーティション・レベル・インポート: 指定されたソース・パーティションまたはサブパーティションのデータのみインポートします。

表レベル・インポートの使用に関するガイドライン

表レベル・インポートでは、指定した各表に関して表のすべての行がインポートされます。表レベル・インポートの特長は次のとおりです。

- (TRANSPORT_TABLESPACESを除く)どのエクスポート・モードでエクスポートされた場合でも、表レベル・インポートを使用してエクスポートされたすべての表をインポートできます。

- ユーザーは、表レベルでエクスポートされたすべての表(パーティション表または非パーティション表)、パーティションまたはサブパーティションを、同じ名前のターゲット表(パーティション表または非パーティション表)にインポートできます。

表が存在しない場合で、なおかつエクスポートされた表がパーティション表である場合は、表レベル・インポートによってパーティション表が作成されます。表が正常に作成されると、エクスポート・ファイルからすべてのソース・データが読み込まれ、ターゲット表に書き込まれます。インポート後、ターゲット表には、エクスポート・ファイル内のソース表に対応付けられたすべてのパーティションおよびサブパーティションに関するパーティション定義が格納されます。この処理によって、ソース・パーティションの物理属性および論理属性(パーティションの境界を含む)が、インポート時に維持されます。

パーティション・レベル・インポートの使用に関するガイドライン

パーティション・レベル・インポートを指定できるのは、表モードでインポートを実行する場合のみです。パーティション・レベル・インポートでは、エクスポート・ファイル内の特定のパーティションまたはサブパーティションを選択してデータをロードすることができます。パーティション・レベル・インポートを使用する場合は、次のガイドラインに注意してください。

- インポートでは、常にターゲット表のパーティション化スキームに従って行が格納されます。

- パーティション・レベル・インポートでは、指定されたソース・パーティションまたはサブパーティションの行データのみ挿入されます。

- ターゲット表がパーティション表の場合、パーティション・レベル・インポートを行うと、そのターゲット表の最上位パーティションより上に入る行はすべて拒否されます。

- エクスポートされた表が非パーティション表の場合は、パーティション・レベル・インポートを実行できません。ただし、表レベル・インポートを使用すると、エクスポートされた非パーティション表からパーティション表をインポートできます。

- ソース表(エクスポート時にtablenameに指定された表)がパーティション表で、エクスポート・ファイルに存在する場合のみ、パーティション・レベル・インポートは正常に実行されます。

- エクスポート・ファイルに存在しないパーティション名またはサブパーティション名を指定すると、警告が発行されます。

- パラメータの中で指定するパーティション名またはサブパーティション名には、エクスポート・ファイルにあるパーティションまたはサブパーティションのみを指定します。エクスポート・ファイルには、エクスポート・ソース・システム上の表のすべてのデータが含まれているとはかぎりません。

- ROWS=y(デフォルト)が指定されていて、表がインポート先のシステムに存在しない場合、表が作成され、すべての行が、ソース・パーティションまたはサブパーティションから、インポート先の表のパーティションまたはサブパーティションに挿入されます。

- ROWS=y(デフォルト)およびIGNORE=yが指定されていて、対象となる表の表名がインポート前に存在している場合は、指定された表のパーティションまたはサブパーティションの行がすべて、同名の表に挿入されます。インポートでは、常に、ターゲット表の既存のパーティション化スキーマに従って行が格納されます。

- ROWS=nが指定されている場合、データはターゲット表に挿入されず、エクスポート・ファイル中の表およびパーティションまたはサブパーティションに関連する他のオブジェクトに対する処理が、継続して行われます。

- ターゲット表が非パーティション表の場合、パーティションおよびサブパーティションは表全体にインポートされます。1つ以上のパーティションまたはサブパーティションを、エクスポート・ファイルからインポート・ターゲット・システム上の非パーティション表にインポートするには、IGNORE=yを指定します。

パーティションと表の間のデータ移行

コンポジット・パーティションのパーティション名を指定しない場合、コンポジット・パーティション内のすべてのサブパーティションが、ソースとして使用されます。

次の例では、パーティション名によって指定されたパーティションは、コンポジット・パーティションです。すべてのサブパーティションがインポートされます。

imp SYSTEM FILE=expdat.dmp FROMUSER=scott TABLES=b:py

次の例では、表scott.eのパーティションqcおよびqdの行データが、表scott.eにインポートされます。

imp scott FILE=expdat.dmp TABLES=(e:qc, e:qd) IGNORE=y

インポート・ターゲット・データベースに表eが存在しない場合は、表eの作成後、同じパーティションにデータが挿入されます。インポート前にターゲット・システムに表eが存在する場合、行データは、挿入可能な範囲を持つパーティションに挿入されます。行データは、最終的にqcおよびqd以外の名前のパーティションに挿入することもできます。

注意:

既存の表にパーティション・レベル・インポートを実行する場合は、ターゲット・パーティションまたはサブパーティションを正しく設定し、IGNORE=yを指定してください。

索引作成およびメンテナンスの制御

この項では、索引作成およびメンテナンスに関連するインポートの動作について説明します。

索引作成の延期

インポート・ユーティリティには、索引の作成およびメンテナンスの実行を、インポートが完了し、エクスポート・データの挿入が終了するまで延期させる機能が用意されています。インポート完了後に索引の作成、再作成またはメンテナンスを実行すると、通常、その処理時間は、インポートで各行が挿入されるたびにメンテナンスを実行するより短くなります。

索引作成には時間がかかるため、他のすべてのオブジェクトのインポートが完了してから行った方が効率的です。INDEXES=nを指定すると、インポートの終了後に索引を作成できます。(デフォルトはINDEXES=yです。)その後、INDEXFILEパラメータを使用してインポートを実行し、SQLスクリプト内の未作成の索引定義を格納できます。索引作成文は、このように指定しない場合、インポート・ユーティリティから発行されますが、このように指定した場合、指定されたファイルに書き込まれます。

インポート完了後、索引を作成する必要があります。索引を作成するには、通常、CONNECT文にパスワードを指定した後、INDEXFILEで指定したファイルの内容をSQLスクリプトとして使用します。

索引作成およびメンテナンスの制御

SKIP_UNUSABLE_INDEXES=yを指定すると、インポート前に索引使用禁止に設定されていた索引のメンテナンスはすべて延期されます。他の索引(事前に索引使用禁止に設定されていない索引)に対しては、行の挿入時にメンテナンス処理が行われます。これにより、既存の表をインポートする間、索引の更新が保存されます。

索引のメンテナンスが延期されると、その索引で設定されている既存の一意整合性制約に対して違反が発生することがあります。表に一意整合性制約が存在しても、INDEXES=nを指定してインポートした表内の重複キーは回避できません。このため、その索引は、重複キーが削除されて索引が再構築されるまでは、UNUSABLE状態となります。

索引更新延期の例

パーティションp1およびp2を持つパーティション表tが、インポート・ターゲット・システムに存在するとします。また、パーティションp1にローカル索引p1_ind、パーティションp2にローカル索引p2_indが存在するとします。このパーティションp1には既存の表tのデータが入っており、そのデータ量は、エクスポート・ファイル(expdat.dmp)を使用して挿入されるデータの量よりはるかに多いとします。一方、パーティションp2はその逆であるとします。

表データ挿入時にp1_indの索引メンテナンスを実行すると、パーティション索引の再作成時に実行するより、処理効率が高くなります。p2_indについては、この逆になります。

また、p2_indについては、インポート中のローカル索引のメンテナンスを延期できます。延期するには、次の手順を実行します。

1. インポート前に、次のSQL文を発行します。

ALTER TABLE t MODIFY PARTITION p2 UNUSABLE LOCAL INDEXES;

2. 次のインポート・コマンドを発行します。

imp scott FILE=expdat.dmp TABLES = (t:p1, t:p2) IGNORE=y
SKIP_UNUSABLE_INDEXES=y

この例では、インポートの実行前にALTER SESSION SET SKIP_UNUSABLE_INDEXES=y文を実行します。

3. インポート後に次のSQL文を発行します。

ALTER TABLE t MODIFY PARTITION p2 REBUILD UNUSABLE LOCAL INDEXES;

この例では、p1のローカル索引p1_indは、インポート中、表データがパーティションp1に挿入されるときにメンテナンスされます。一方、p2のローカル索引p2_indは、インポート後の索引再作成時にメンテナンスされます。

ネットワークに関する考慮点

Oracle Netを使用すると、ネットワークを介してインポートを実行できます。たとえば、インポート・ユーティリティをローカルで実行した場合に、リモートのOracle Databaseにデータを読み取ることができます。

Oracle Netでインポート・ユーティリティを使用するには、impコマンドにユーザー名とパスワードを入力するときに接続修飾文字列@connect_string を指定する必要があります。この句の構文の詳細は、ご使用のOracle Netプロトコルのユーザーズ・ガイドを参照してください。

関連項目:

- Oracle Database Net Services管理者ガイド

キャラクタ・セットおよびグローバリゼーション・サポートに関する考慮点

この項では、ユーザー・データおよびデータ定義言語(DDL)のキャラクタ・セット変換に関連するインポート・ユーティリティのグローバリゼーション・サポートの動作について説明します。

ユーザー・データ

エクスポート・ユーティリティは、常に、エクスポート・サーバーのキャラクタ・セットでUnicodeデータを含むユーザー・データをエクスポートします。(キャラクタ・セットは、データベース作成時に指定されます。)ソース・データベースのキャラクタ・セットが、インポート・データベースのキャラクタ・セットと異なる場合、自動的にデータをインポート・サーバーのキャラクタ・セットに変換するためのキャラクタ・セット変換が実行されます。

変換によるキャラクタ・セットのソート順への影響

エクスポート・キャラクタ・セットのソート順が、インポート・キャラクタ・セットと異なる場合、キャラクタ列をパーティション化した表では、結果が保証されません。 たとえば、次のようなASCIIキャラクタ・セットのデータベースの表定義について考えてみます。

CREATE TABLE partlist
(
part     VARCHAR2(10),
partno   NUMBER(2)
)
PARTITION BY RANGE (part)
(
PARTITION part_low VALUES LESS THAN ('Z')
TABLESPACE tbs_1,
PARTITION part_mid VALUES LESS THAN ('z')
TABLESPACE tbs_2,
PARTITION part_high VALUES LESS THAN (MAXVALUE)
TABLESPACE tbs_3
);

ASCIIキャラクタ・セットでは、Zの後にzがあるため、このパーティション・スキームには意味があります。

この表がEBCDICキャラクタ・セット・ベースのデータベースにインポートされると、EBCDICキャラクタ・セットでは、zがZの前にあるため、part_midパーティションのすべての行が、part_lowパーティションに移行します。希望する結果を得るには、partlist表の所有者は、インポート後に表を再パーティション化する必要があります。

関連項目:

キャラクタ・セットの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

DDL

エクスポートおよびインポート操作時に、データ定義言語(DDL)に対して最大3回のキャラクタ・セット変換が必要です。

1. エクスポート・ファイルは、環境変数NLS_LANGでユーザー・セッション用に指定されたキャラクタ・セットで書き出されます。NLS_LANGの値が、データベースのキャラクタ・セットと異なる場合は、キャラクタ・セット変換が実行されます。

2. エクスポート・ファイルのキャラクタ・セットが、インポート先ユーザー・セッション用のキャラクタ・セットと異なる場合、ユーザー・セッションのキャラクタ・セットに変換されます。シングルバイト・キャラクタ・セットの場合のみにこの変換が実行されます。マルチバイト・キャラクタ・セットの場合は、インポート・ファイルのキャラクタ・セットがエクスポート・ファイルのキャラクタ・セットと同じである必要があります。

3. ターゲット・データベースのキャラクタ・セットが、インポート・ユーザー・セッション用のキャラクタ・セットと異なる場合、最後のキャラクタ・セット変換が実行される場合があります。

キャラクタ・セット変換によるデータの損失を最小限にするには、エクスポート・データベース、エクスポート・ユーザー・セッション、インポート・ユーザー・セッションおよびインポート・データベースのすべてにおいて、同一のキャラクタ・セットを使用するようにしてください。

シングルバイト・キャラクタ・セット

8ビット・キャラクタ・セットのエクスポート・ファイルをインポートすると、8ビット文字の一部が消去されることがあります(同等の7ビットに変換されます)。これが発生するのは、インポートを実行するシステムに、システム固有の7ビット・キャラクタ・セットが存在するか、オペレーティング・システム環境変数NLS_LANGが7ビット・キャラクタ・セットに設定されている場合です。アクセント記号が付いている文字からアクセントが消去されるのが最もよく見られる例です。

このような状況を回避するために、オペレーティング・システム環境変数NLS_LANGにエクスポート・ファイルのキャラクタ・セットを設定できます。

マルチバイト・キャラクタ・セット

ターゲット・キャラクタ・セットに同等の文字がないエクスポート・ファイル中の文字は、変換時にデフォルトの文字に置換されます(デフォルトの文字は、ターゲット・キャラクタ・セットによって定義されます)。(デフォルトの文字は、ターゲット・キャラクタ・セットによって定義されます)。100%完全に変換されるためには、ターゲット・キャラクタ・セットはソース・キャラクタ・セットのスーパーセットであるか、ソース・キャラクタ・セットと同等である必要があります。

注意:

エクスポート・サーバーとインポート・サーバーとの間でキャラクタ・セットの幅が異なるとき、変換が原因でデータの拡張が発生する場合にデータの切捨てが発生することがあります。切捨てが発生する場合、インポート・ユーティリティに警告メッセージが表示されます。

インスタンス親和性の使用方法

インスタンス親和性を使用して、インポートおよびエクスポートするデータベース内のインスタンスにジョブを関連付けることができます。複数のリリースを組み合せて使用している場合は、互換性の問題に注意してください。

関連項目:

- 親和性の詳細は、『Oracle Database管理者ガイド』を参照してください。

データベース・オブジェクトのインポートに関する考慮点

次の項では、特定のデータベース・オブジェクトをインポートする場合の、制限事項および考慮点について説明します。

オブジェクト識別子のインポート

Oracle Databaseでは、オブジェクト型、オブジェクト表およびオブジェクト表内の行を一意に識別できるように、オブジェクト識別子が割り当てられます。オブジェクト識別子はインポート・ユーティリティによって保持されます。

型を参照している表のインポート時に、その名前の型がすでにデータベースに存在している場合は、その既存の型が、実際にその表で使用されているかどうか(実際は異なる型で、単に同じ名前であるだけではないか)を確認します。

この確認のために、型の一意の識別子(TOID)とエクスポート・ファイルに格納された識別子が比較されます。これらの識別子が一致する場合は、型の一意のハッシュ・コードとエクスポート・ファイルに格納されたハッシュ・コードが比較されます。TOIDまたはハッシュ・コードが一致しない場合、その表の行はインポートされません。

この妥当性チェックをしてはいけない型もあります(たとえば、その型がカートリッジのインストールによって作成された場合)。パラメータTOID_NOVALIDATEを使用して、TOIDおよびハッシュ・コードと比較しない型を指定できます。詳細は、「TOID_NOVALIDATE」を参照してください。

注意:

型比較は、不正なデータを発生させないための非常に重要な機能であるため、TOID_NOVALIDATEの使用には、特に注意してください。この機能を使用禁止にする場合は、データ型の妥当性チェックとその処理について十分な知識を持つユーザーが行ってください。

次の基準によって、オブジェクト型、オブジェクト表およびオブジェクト表の行の処理方法が決まります。

- オブジェクト型に関して、IGNORE=yが指定されていて、オブジェクト型がすでに存在し、そのオブジェクト識別子、ハッシュ・コードおよび型記述子が一致する場合は、エラーは通知されません。オブジェクト識別子またはハッシュ・コードが一致しない場合、パラメータTOID_NOVALIDATEにそのオブジェクト型を無視する設定がされていないと、エラーが通知され、そのオブジェクト型を使用している表はインポートされません。

- オブジェクト型に関して、IGNORE=nが指定されていて、そのオブジェクト型がすでに存在する場合は、エラーが通知されます。オブジェクト識別子、ハッシュ・コードまたは型記述子が一致しない場合、パラメータTOID_NOVALIDATEにそのオブジェクト型を無視するように設定されていないと、エラーが通知され、そのオブジェクト型を使用している表はインポートされません。

- オブジェクト表に関して、IGNORE=yが指定されていて、表がすでに存在し、そのオブジェクト識別子、ハッシュ・コードおよび型記述子が一致する場合、エラーは通知されません。行はオブジェクト表にインポートされます。同じオブジェクト識別子の行が、すでにそのオブジェクト表に存在している場合、行のインポートはエラーになります。オブジェクト識別子、ハッシュ・コードまたは型記述子が一致しない場合、パラメータTOID_NOVALIDATEがそのオブジェクト型を無視するように設定されていないと、エラーが通知され、そのオブジェクト型を使用している表はインポートされません。

- オブジェクト表に関して、IGNORE=nが指定されていて、オブジェクト表がすでに存在する場合は、エラーが通知され、オブジェクト表はインポートされません。

インポート・ユーティリティにオブジェクト型とオブジェクト表に関するオブジェクト識別子が保持されるため、FROMUSERパラメータおよびTOUSERパラメータを使用して、あるユーザー・スキーマから別のユーザー・スキーマにオブジェクトをインポートする場合は、次のことを考慮してください。

- FROMUSERのオブジェクト型およびオブジェクト表がターゲット表にすでに存在する場合は、TOUSERのオブジェクト型およびオブジェクト表の識別子がすでに使用されているため、エラーが発生します。インポート開始前に、FROMUSERのオブジェクト型およびオブジェクト表をシステムから削除する必要があります。

- オブジェクト表作成時に、OID ASオプションを指定して他の表と同じオブジェクト識別子が割り当てられている場合は、同じオブジェクト識別子を持つ表を両方インポートすることはできません。1つ目の表はインポートできますが、同じオブジェクト識別子がすでに使用されているため、2つ目の表をインポートするとエラーになります。

既存のオブジェクト表およびオブジェクト型の含まれている表のインポート

表領域の使用方法または表の記憶域パラメータを変更するため、インポートの前に表を作成することがよくあります。表を作成する場合、以前(記憶域パラメータ以外に対して)使用していた定義と同じ定義で作成するか、互換性のある形式で作成する必要があります。オブジェクト表や、オブジェクト型の列を含む表の場合は、形式の互換性がさらに制限されます。

オブジェクト表およびオブジェクト列を含む表の場合、表が参照する各オブジェクトは、その名前、構造およびバージョン情報をエクスポート・ファイルに書き出されます。エクスポート・ユーティリティでは、必要に応じて、異なるスキーマのオブジェクト型の情報も含まれます。

インポート・ユーティリティは、表データをインポートする前に、表に必要な各オブジェクト型の存在を確認します。この確認機能には、オブジェクト型の名前の確認、インポート・システムのオブジェクト型の構造およびバージョンと、エクスポート・ファイルに書き込まれた情報との比較が含まれます。

オブジェクト型名がインポート・システムで検出され、構造またはバージョンがエクスポート・ファイルと一致しない場合、エラー・メッセージが生成され、表データはインポートされません。

インポート・パラメータTOID_NOVALIDATEを使用して、特定のオブジェクトのオブジェクト型の構造およびバージョンの確認機能を使用禁止にできます。

ネストした表のインポート

内部のネストした表は外部表とは別にエクスポートされます。したがって、内部のネストした表が正しくインポートされない場合、次のような状況が予想されます。

- 内部にネストした表を持つ表がエクスポートされ、インポート時に、表も表内の行も削除されなかったとします。IGNORE=yパラメータが指定されている場合、外部表に各行を挿入すると、制約違反が発生します。ただし、内部のネストした表のデータは正常にインポートされることがあり、その場合、内部表の行データが重複します。

- 外部表へデータをインポート中にリカバリ不能なエラーが発生した場合は、外部表の残りのデータはスキップされますが、対応する内部表の行はスキップされません。その結果、内部表の行は外部表のどの行からも参照されなくなります。

- リカバリ可能なエラーの後で内部表への挿入がエラーになる場合、外部表の行はすでに外部表にインポートされています。また、外部表および他の内部表へのデータのインポートは続行されます。その結果、不完全な論理行が作成されます。

- 内部表へのデータのインポート中にリカバリ不能なエラーが発生した場合は、その内部表の残りのデータはスキップされますが、外部表やその他のネストした表はスキップされません。

常にログ・ファイルを調べて、外部表および内部表にエラーがないかどうかを確認する必要があります。データに一貫性を持たせるためには、表データの変更や削除が必要になることがあります。

内部にネストした表は、外部表とは別にインポートされるので、インポート中に、このネストした表のデータにアクセスしようとしても失敗することがあります。たとえば、内部表の行がインポートされる前に、外部表の行にアクセスすると、ユーザーには不完全な行が返されます。

REFデータのインポート

REF列および属性には、参照されている型のインスタンスを示すROWIDが隠されていることがあります。インポート・ユーティリティでは、ターゲット・データベースに対するROWIDは、自動的には再設定されません。ROWIDを適切な値に再設定するには、次の文を実行します。

ANALYZE TABLE [schema.]table VALIDATE REF UPDATE;

関連項目:

ANALYZE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

BFILE列およびディレクトリ別名のインポート

BFILE列および属性で参照されているデータは、ソース・データベースからターゲット・データベースへはコピーされません。BFILE列で参照されているファイルの名前とディレクトリ別名が伝達されるのみです。BFILE列および属性で参照されている実際のファイルは、DBAまたはユーザーが移動してください。

BFILE列を含む表データをインポートする場合、BFILEロケータは、ディレクトリ別名およびエクスポート時のファイル名でインポートされます。インポート・ユーティリティでは、そのディレクトリ別名またはファイルが存在するかどうかの確認は行われません。ディレクトリ別名またはファイルが存在しない場合、ユーザーがBFILEデータにアクセスするとエラーが発生します。

ディレクトリ別名に関しては、エクスポート・システムで使用しているオペレーティング・システムのディレクトリ構文がインポート・システムで有効でない場合でも、インポート時にエラーは通知されません。ユーザーがインポート後に、そのファイルのデータにアクセスするとエラーが返されます。ディレクトリ別名がインポート・システムで有効かどうかは、DBAまたはユーザーが確認してください。

外部関数ライブラリのインポート

インポート・ユーティリティでは、外部関数ライブラリの参照先が正しいかどうかの確認は行われません。エクスポート・ファイル上のライブラリの指定で使用されているディレクトリやファイル名の形式がインポート・システムで無効であっても、インポート時にエラーは通知されません。この場合、インポート後にそのファンクションを呼び出そうとすると、エラーが返されます。

DBAまたはユーザーが手動でライブラリを移動し、ライブラリの指定がインポート・システムで有効になるようにしてください。

ストアド・プロシージャ、ファンクションおよびパッケージのインポート

ローカルのストアド・プロシージャ、ストアド・ファンクションまたはパッケージがインポートされるときのインポート・ユーティリティの動作は、COMPILEパラメータがyまたはnに設定されているかどうかによって異なります。

ローカルのストアド・プロシージャ、ストアド・ファンクションまたはパッケージがインポートされ、COMPILE=yが指定されている場合は、プロシージャ、ファンクション、パッケージはインポート時に再コンパイルされ、元のタイムスタンプ仕様が保持されます。コンパイルが成功すると、リモート・プロシージャによってアクセスしてもエラーは発生しません。

COMPILE=nが指定されている場合も、プロシージャ、ストアド・ファンクションまたはパッケージはインポートされます。ただし、元のタイムスタンプは失われます。次に、プロシージャ、ファンクションまたはパッケージを使用するときに、コンパイルが実行されます。

関連項目:

「COMPILE」

Javaオブジェクトのインポート

Javaオブジェクトを任意のスキーマにインポートしても、リゾルバはインポート・ユーティリティによって変更されません(リゾルバとは、Javaのフルネームの解決に使用されるスキーマのリストです)。(リゾルバとは、Javaのフルネームの解決に使用されるスキーマのリストです)。インポートの終了後、明示的または暗黙的に再検証しないかぎり、すべてのユーザー・クラスが無効な状態のままになります。暗黙的な再検証は、クラスが最初に参照されるときに実行されます。明示的な再検証は、SQLのALTER JAVA CLASS...RESOLVE文を使用すると実行されます。いずれの方法でもクラスは正常に解決され、有効になります。

外部表のインポート

インポート・ユーティリティでは、外部表によって参照される場所が正しいかどうかを検証しません。エクスポート・ファイルの表の指定で使用されるディレクトリ名およびファイル名の書式がインポート・システムで無効な場合、エラーはインポート時に報告されません。後でコールアウト関数を使用するときにエラーを受け取ります。

DBAまたはユーザーが手動で表を移動し、表の指定がインポート・システムで有効になるようにしてください。

AQ表のインポート

キュー表をインポートすると、基礎となっているキューや関連するディクショナリ情報もインポートされます。キューのインポートは、キュー表単位のレベルでのみ実行できます。キュー表のインポートでは、エクスポートの表処理プロシージャの前後に、キュー・ディクショナリがメンテナンスされます。

関連項目:

『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』

LONG列のインポート

LONG列の長さは、最大2GBです。インポートおよびエクスポート時には、LONG列は各行の残りのデータとともにメモリーに収まるサイズである必要があります。ただし、LONGデータはセクション単位でロードされるため、LONG列を格納するメモリーが連続している必要はありません。

インポート・ユーティリティを使用して、LONG列をCLOB列に変換できます。このためには、まず、新しいCLOB列を指定する表を作成します。インポートを実行すると、LONGデータはCLOB形式に変換されます。同じ方法で、LONG RAW列をBLOB列に変換できます。

注意:

既存のLONG列をLOB列に変換することをお薦めします。LOB列は、LONG列ほど制限は多くありません。LOB機能はリリースごとに拡張されていますが、LONG機能は最近のリリースでは変更されていません。

トリガーが存在する場合のLOB列のインポート

Oracle Database 10gでは、トリガーが正常に動作し、LOBのロード中に高いパフォーマンスが保たれるようにLOB処理が改善されています。インポート・ユーティリティでは、エクスポート時に空であるすべてのLOBがインポート後に自動的にNULLに変更されるように改善されています。

LOBがNULLではなく、空である必要があるアプリケーションを使用している場合は、インポート後に、各LOB列に対してSQL UPDATE文を発行できます。LOB列型がBLOBかCLOBかによって、構文は次のいずれかになります。

UPDATE <tablename> SET <lob column> = EMPTY_BLOB() WHERE <lob column> = IS NULL;
UPDATE <tablename> SET <lob column> = EMPTY_CLOB() WHERE <lob column> = IS NULL;

インポートの実行後、NULLのLOB列と空のLOB列を区別する方法はありません。そのため、この情報がデータの整合性上重要である場合は、インポートの実行前にNULLのLOB列および空のLOB列を確認してください。

ビューのインポート

ビューは、依存順序でエクスポートされます。状況によっては、データベースから順序を取得するのではなく、エクスポートで順序付けをする必要があります。この場合、常に正しい順序を複製できるとはかぎりません。順序が正しくない場合、ビューのインポート時にコンパイル上の警告が発行され、そのビューに関する列コメントはインポートされません。

特に、viewaでストアド・プロシージャprocbが使用され、procbでビューviewcが使用されている場合、エクスポート・ユーティリティでは、ビューviewaとviewcの正しい順序付けはできません。viewaがviewcより先にエクスポートされ、procbがインポート・システムにすでに存在する場合は、viewaのインポート時にコンパイル上の警告が出されます。

ビューに関する権限は、ビューにコンパイル・エラーがあってもインポートされます。ビューの作成時に、そのビューの基礎になっているオブジェクト(たとえば、表、プロシージャ、他のビューなど)が存在していない場合、ビューにコンパイル・エラーが発生する場合があります。実表が存在しない場合、実表に対する権限を付与したユーザー自身が、その実表に対してGRANTオプション付きの適正な権限を持っているかどうかを、サーバーでは検証できません。権限を付与したユーザーが適正な権限を持っていない場合、インポートされなかった表の作成後にその表にアクセスしようとすると、エラーが発生します。

他のスキーマの表を参照しているビューをインポートする場合は、インポートを実行するユーザーに、READ ANY TABLEまたはSELECT ANY TABLE権限が必要です。この権限がない場合、ビューは、コンパイルされていない状態でインポートされます。ロールに権限を付与するのみでは不十分です。ビューのコンパイルには、インポートするユーザーに直接権限を付与する必要があります。

パーティション表のインポート

エクスポートしたパーティション表と同じパーティション名またはサブパーティション名を使用してパーティション表を作成するために、SYS_Pnnn形式の名前もインポートされます。同じ名前のパーティション表がすでに存在している場合、これ以降の処理はIGNOREパラメータに指定されている値によって異なります。

SKIP_UNUSABLE_INDEXES=yが指定されていないかぎり、インポート時に非パーティション索引またはパーティション索引が(索引使用禁止に設定されているか、またはその他の不適合が理由で)メンテナンスできない場合は、エクスポート・データはターゲット表にインポートできません。

ファイングレイン・アクセス・コントロールに対するサポート

ファイングレイン・アクセス・コントロール・ポリシーをリストアするには、ファイングレイン・アクセス・コントロール・ポリシーが使用可能な表を含むエクスポート・ファイルからインポートするユーザーが、表のセキュリティ・ポリシーを回復するためのDBMS_RLSパッケージに対するEXECUTE権限が必要です。

ファイングレイン・アクセス・コントロール・ポリシーが使用可能な表を含むエクスポートファイルからインポートを行うための正しい権限が付与されていない場合は、警告メッセージが発行されます。

スナップショットおよびスナップショット・ログ

注意:

特定の状況、特にデータ・ウェアハウスに関連する場合、スナップショットは、マテリアライズド・ビューと呼ばれます。この項では、そのような場合でもスナップショットという用語を使用します。

スナップショット・ログ

インポート先のデータベースにマスター表がすでに存在し、そのマスター表にスナップショット・ログがある場合は、ダンプ・ファイルのスナップショット・ログがインポートされます。

ROWIDスナップショット・ログのエクスポートでは、スナップショット・ログに記録されているROWIDはインポートした後には意味を持ちません。このため、各ROWIDのスナップショットによる最初の高速リフレッシュは失敗し、完全リフレッシュが必要であることを示すエラーが発生します。

リフレッシュのエラーを回避するには、ROWIDのスナップショット・ログをインポートしてから完全リフレッシュを実行してください。完全リフレッシュを実行すると、後続の高速リフレッシュが適切に行われます。これに対し、主キー・スナップショット・ログをエクスポートした場合は、インポートした後でも主キーの値は意味を持ちます。したがって、インポートした後でも、主キーのスナップショットにより、高速リフレッシュを実行できます。

関連項目:

インポート固有の移行と互換性、およびスナップショットとスナップショット・ログの詳細は、『Oracle Databaseアドバンスト・レプリケーション』を参照してください。

スナップショット

エクスポート・ファイルからリストアされたスナップショットは、前の状態に戻ってしまいます。インポートでは、最後のリフレッシュが実行された時刻が、スナップショット表定義の一部としてインポートされます。次のリフレッシュ時刻を計算する機能もインポートされます。

各リフレッシュによって、署名が付けられます。高速リフレッシュでは、スナップショットを最新に保つため、その署名の時刻から日付を決定するログ・エントリが使用されます。高速リフレッシュが完了した時点で署名は削除され、新しい署名が付けられます。他のスナップショットのリフレッシュに必要でないログ・エントリ(残っている最も古い署名よりも前の時刻を持つすべてのログ・エントリ)も削除されます。

スナップショットのインポート

エクスポート・ファイルからスナップショットをリストアすると、問題が発生する場合があります。

スナップショットが時刻Aにリフレッシュされ、時刻Bにエクスポートされ、時刻Cに再びリフレッシュされたとします。破損などの問題が発生したため、スナップショットを削除してインポートしなおすことによってリストアする必要があります。新規にインポートされたバージョンは、時刻Aとして記録された最終リフレッシュ時刻を保持しています。高速リフレッシュに必要となるログ・エントリが存在しなくなっている可能性があります。ログ・エントリが存在する場合は(たとえば、リフレッシュする必要のある別のスナップショットに必要なため)、このエントリが使用され、高速リフレッシュは正常に完了します。ログ・エントリが存在しない場合、高速リフレッシュは失敗し、完全リフレッシュが必要であることを示すエラーが発生します。

異なるスキーマへのスナップショットのインポート

スナップショットおよび関連項目は、DDL文で指定されたスキーマ名でエクスポートされます。異なるスキーマにインポートする場合は、FROMUSERパラメータおよびTOUSERパラメータを使用します。これは、異なるスキーマにインポートできないスナップショット・ログには適用されません。

注意:

ファンクション索引、ファンクション、プロシージャ、トリガー、型本体、ビューなどの内部に表示されるスキーマ名は、FROMUSERまたはTOUSERの処理には影響されません。影響を受けるのは、オブジェクト名のみです。インポートの完了後、TOUSERスキーマに含まれる項目が古いスキーマ(FROMUSER)を参照しているかどうかを手動で確認し、必要に応じて修正する必要があります。

トランスポータブル表領域

トランスポータブル表領域機能は、一連の表領域を、あるOracle Databaseから他のOracle Databaseに移動できる機能です。

注意:

トランスポータブル表領域をエクスポートした後、それよりも古いリリース・レベルのデータベースにインポートすることはできません。ターゲット・データベースのリリース・レベルは、ソース・データベース以上である必要があります。

一連の表領域を移動またはコピーするには、表領域を読取り専用にし、表領域のデータ・ファイルをターゲット・データベースに手動でコピーしてから、エクスポートおよびインポートを使用して、データ・ディクショナリに格納されているデータベース情報(メタデータ)をターゲット・データベースに移動します。データ・ファイルの転送は、オペレーティング・システムのコピー機能、バイナリ・モードFTP、CD-ROMへの出力などのような、フラット・バイナリ・ファイルのコピー機能を使用して行われます。

データ・ファイルのコピーおよびメタデータのエクスポートの後、表領域を任意に読み書き両用モードにできます。

次のパラメータで、トランスポータブル表領域のメタデータを移動できます。

- TABLESPACES

- TRANSPORT_TABLESPACE

インポート操作時のこれらのパラメータの使用方法の詳細は、「TABLESPACES」および「TRANSPORT_TABLESPACE」を参照してください。

関連項目:

- トランスポータブル表領域の管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

記憶域パラメータ

デフォルトでは、表は、元の表領域にインポートされます。

その表領域が存在しない場合、またはユーザーがその表領域に十分な割当て制限を持っていない場合、次の表の場合を除いて、そのユーザーにはデフォルトの表領域が割り当てられます。

- パーティション表

- 特定の型の表

- LOB型列、VARRAY型列またはOPAQUE型列を含む表

- オーバーフロー・セグメントがあるIOTを含む表

ユーザーがデフォルトの表領域に対する十分な割当て制限を持っていない場合、そのユーザーの表はインポートされません。この制限の利用方法の詳細は、「表領域を再編成する方法」を参照してください。

OPTIMALパラメータ

ロールバック・セグメントのための記憶域パラメータOPTIMALは、エクスポートおよびインポート時には保持されません。

OID索引とLOB列の記憶域パラメータ

表は、その表の現行の記憶域パラメータを使用してエクスポートされます。オブジェクト表に関しては、OIDINDEXの作成時に、OIDINDEXの現行の記憶域パラメータおよび名前が設定されている場合は、それらを使用して作成されます。LOB型列、VARRAY型列またはOPAQUE型列が含まれている表に関しては、LOB型データ、VARRAY型データまたはOPAQUE型データは、それらの現行の記憶域パラメータを使用して作成されます。

エクスポートの前に、ユーザーが既存の表の記憶域パラメータを変更する場合もありますが、このような場合、表は変更された記憶域パラメータを使用してエクスポートされます。ただし、LOBデータの記憶域パラメータは、エクスポートの前には変更できません(たとえば、LOB列のチャンク・サイズ、LOB列がCACHEまたはNOCACHEか、など)。

LOBデータは、含んでいる表と同じ表領域に存在しない場合があることに、注意してください。このデータの表領域は、インポート時に読取り/書込みが可能である必要があります。そうでない場合、表はインポートされません。

LOBデータまたはLOB索引がインポート時に存在しない表領域にある場合、またはユーザーがその表領域に対して必要な割当て制限を持っていない場合、表はインポートされません。表領域の句は、表に関する句も含めて複数の句を同時に指定できるため、インポート時にエラーが発生しても、インポート・ユーティリティではどの表領域句が原因のエラーかを特定できません。

記憶域パラメータの上書き

インポート・ユーティリティを使用してデータをインポートする前に、別の記憶域パラメータで、事前に大きな表を作成した方がよい場合があります。その場合は、コマンドラインまたはパラメータ・ファイルにIGNORE=yを指定します。

読取り専用表領域

読取り専用表領域はエクスポート可能です。インポートでは、表領域がターゲット・データベース内に存在しない場合、読取り/書込み表領域として表領域が作成されます。読取り専用機能が必要な場合は、インポート後にその表領域を手動で読取り専用にする必要があります。

ターゲット・データベース内に表領域がすでに存在し、読取り専用である場合は、インポート前にこの表領域を読取り/書込み可能にする必要があります。

表領域の削除

インポート前に、オブジェクトに別の表領域を使用するように再定義すると、表領域を削除できます。impコマンドの発行時には、IGNORE=yを指定します。

表領域を削除するには、通常、全データベース・エクスポートを実行し、(ログオフの前に)削除する表領域と同名の表領域をブロック数0(ゼロ)で作成します。IGNORE=yが指定されていると、インポート時にその表領域に関するCREATE TABLESPACE文はエラーとなります。これにより、削除対象である不要な表領域は作成されません。

その表領域のすべてのオブジェクト(ただし、パーティション表、特定の型の表、LOB列またはVARRAY列を含む表またはオーバーフロー・セグメントのあるIOTを除く)が、そのオブジェクトの所有者のデフォルトの表領域にインポートされます。インポート・ユーティリティでは、エラーの原因となった表領域を特定できません。かわりに、ユーザー自身が表の作成後、IGNORE=yを指定して表のインポートを実行する必要があります。

その表領域が存在しない場合、またはデフォルトの表領域に対するユーザーの割当て制限が十分でない場合は、オブジェクトはデフォルトの表領域にインポートされません。

表領域を再編成する方法

ユーザーの割当て制限が十分な場合、そのユーザーの表はエクスポート元と同じ表領域にインポートされます。その表領域がもう存在しないか、またはユーザーの割当て制限が十分でない場合は、そのユーザーに対するデフォルトの表領域が適用されます。ただし、パーティション表、LOB列またはVARRAY列が含まれている表、特定の型の表およびオーバーフロー・セグメントのある索引構成表には適用されません。この条件を利用して、表領域間でユーザーの表を移動できます。

たとえば、全データベース・エクスポートを実行した後、joeの表を表領域Aから表領域Bに移動する必要があるとします。次の手順を実行します。

1. joeがUNLIMITED TABLESPACE権限を持っている場合、その権限を取り消します。表領域Aに対するjoeの割当て制限を0(ゼロ)に設定します。さらに、このような権限または割当て制限を含む可能性のあるすべてのロールを取り消します。

ロールの取消しでは、カスケード効果はありません。したがって、joeによって他のロールを付与されたユーザーは影響を受けません。

2. joeの表をエクスポートします。

3. 表領域Aからjoeの表を削除します。

4. joeに表領域Bの割当て制限を付与し、joeのデフォルトの表領域とします。

5. joeの表をインポートします(デフォルトでは、joeの表は表領域Bにインポートされます)。

統計情報のインポート

統計情報がエクスポート時に必要で、表にアナライザ統計が利用できる場合、表の統計情報の再計算に使用されるANALYZE文が、エクスポートによってダンプ・ファイルに含まれます。ほとんどの場合、表、索引および列に対する計算済オプティマイザ統計情報も、ダンプ・ファイルにエクスポートされます。インポート・パラメータの詳細は、「STATISTICS」を参照してください。

ANALYZE文の実行には時間がかかるため、通常のインポートでは、エクスポートによって保存されるANALYZE文を計算するのではなく、表(およびその索引や列)の計算済オプティマイザ統計情報を使用してください。デフォルトでは、エクスポート・ダンプ・ファイルにある計算済統計情報が使用されます。

エクスポート・ユーティリティによって、計算済統計情報に問題ありというフラグが付けられる場合もあります。次の状況では、計算済統計情報ではなく、問題のない統計情報のみをインポートする必要がある場合があります。

- ダンプ・ファイル、インポート・クライアント、インポート・データベース間のキャラクタ・セット変換(計算済統計情報で暗黙的に照合順番が変更されている可能性が高いため)。

- 表のインポート時に行エラーが発生した場合。

- パーティション・レベル・インポートが実行された場合(列統計情報が、すでに正確ではないため)。

注意:

ROWS=nを指定しても、計算済統計情報は使用できます。この機能により、本番データベースからの統計情報を使用して、非本番データベース上で問合せの実行計画のチューニングを行うことができます。このような場合は、STATISTICS=SAFEを指定する必要があります。

場合によっては、インポート時に、計算済統計情報ではなく、常にANALYZE文を使用する必要があります。たとえば、分散データベースから収集した統計情報は、そのデータが圧縮形式でインポートされると、適切でなくなる場合があります。このような場合は、インポート時にSTATISTICS=RECALCULATEを指定して、統計情報を再計算する必要があります。

インポート時に統計情報を確定しない場合は、STATISTICS=NONEを指定する必要があります。

エクスポート・ユーティリティおよびインポート・ユーティリティを使用したデータベース移行のパーティション化

エクスポート・ユーティリティおよびインポート・ユーティリティを使用して大規模データベースを移行する場合、移行を複数のエクスポート・ジョブおよびインポート・ジョブにパーティション化するとより効率的です。移行をパーティション化する場合は、次のメリットおよびデメリットに注意してください。

移行をパーティション化する場合のメリット

移行をパーティション化すると、次のメリットがあります。

- 多くのサブジョブをパラレルに実行できるため、移行に必要な時間を削減できます。

- 最初のエクスポート・ジョブが完了するとすぐにインポート・ユーティリティを起動できます。

移行をパーティション化する場合のデメリット

移行をパーティション化すると、次のデメリットがあります。

- エクスポートおよびインポートのプロセスがより複雑になります。

- 特定の型のオブジェクトに対する相互スキーマ参照のサポートが損なわれます。たとえば、異なるスキーマの表に対する外部キー制約を持つ表がスキーマに含まれている場合、その表を依存スキーマにインポートしたときに、必要な親レコードが存在しない場合があります。

エクスポート・ユーティリティおよびインポート・ユーティリティを使用したデータベース移行のパーティション化方法

データベースの移行をパーティション化方法で実行するには、次の手順に従います。

1. データベースのすべての最上位メタデータに、次のコマンドを発行します。

a. exp FILE=full FULL=y CONSTRAINTS=n TRIGGERS=n ROWS=n INDEXES=n

b. imp FILE=full FULL=y

2. データベースの各スキーマnに、次のコマンドを発行します。

a. exp OWNER=scheman FILE=scheman

b. imp FILE=scheman FROMUSER=scheman TOUSER=scheman IGNORE=y

すべてのエクスポートはパラレルで実行できます。full.dmpのインポートが完了すると、残りのインポートもパラレルで実行できます。

インポート操作のチューニングに関する考慮点

この項では、インポート操作のパフォーマンスを向上させる方法を説明します。パフォーマンスを向上させる方法は、次のとおりです。

- システム・レベル・オプションの変更

- 初期化パラメータの変更

- インポート・オプションの変更

- 大量のLOBデータの処理

- 大量のLONGデータの処理

システム・レベル・オプションの変更

システム・レベル・オプションに関して次の点を考慮すると、インポート操作のパフォーマンスの向上につながる場合があります。

- 1つの大きなロールバック・セグメントを作成および使用し、他のすべてのロールバック・セグメントをオフラインにします。一般に、インポートする最大の表の半分のサイズが、十分なロールバック・セグメントのサイズです。また、同じサイズの2つ以上のエクステントで、ロールバック・セグメントを作成することも有効です。

注意:

ロールバック・セグメントのかわりに、自動UNDO管理を使用することをお薦めします。

- インポートが完了するまでデータベースをNOARCHIVELOGモードにします。これによって、アーカイブ・ログの作成および管理によるオーバーヘッドが削減されます。

- いくつかの大きいREDOファイルを作成し、小さいREDOログ・ファイルをすべてオフラインにします。これによって、作成されるログ・スイッチが少なくなります。

- 可能な場合、ロールバック・セグメント、表データおよびREDOログ・ファイルをすべて個別のディスクに配置します。I/O競合が削減され、スループットが増加します。

- 可能な場合、システム・リソースに対するインポート操作との競合が発生する可能性がある他のジョブは、同時に実行しないでください。

- ディクショナリ表に統計が存在しないことを確認してください。

- sqlnet.oraファイルにTRACE_LEVEL_CLIENT=OFFを設定します。

- 可能な場合、データベースの再作成時にDB_BLOCK_SIZEの値を増加します。ブロック・サイズを大きくすると、必要なI/Oサイクル数は少なくなります。この変更は永続的であるため、行う前にすべての影響を考慮してください。

初期化パラメータの変更

初期化パラメータ・ファイルの設定に関して次の点を考慮すると、インポート操作のパフォーマンスの向上につながる場合があります。

- LOG_CHECKPOINT_INTERVALをREDOログ・ファイルのサイズより大きい数に設定します。オペレーティング・システム・ブロックの数(ほとんどのUNIXシステムでは512)です。これによって、(ログ・スイッチ時の)チェックポイントが最小まで削減されます。

- SORT_AREA_SIZEの値を増加します。増加する量は、システムで行われている他のアクティビティおよび使用可能な空きメモリーの量によって異なります。(システムでスワッピングおよびページングが開始された場合、設定値が高くなりすぎる可能性があります)。

- DB_BLOCK_BUFFERSおよびSHARED_POOL_SIZEの値を増加します。

インポート・オプションの変更

インポート・オプションの使用について次の点を考慮すると、パフォーマンスの向上につながる場合があります。「インポート・パラメータ」に示す使用可能なオプションの各説明も参照してください。

- COMMIT=Nを設定します。これによって、各バッファの後ではなく、各オブジェクト(表)の後にインポートがコミットされます。このため、1つの大きなロールバック・セグメントが必要となります。(ロールバック・セグメントは将来のリリースでは非推奨になるため、かわりに、自動UNDO管理の使用をお薦めします。)

- システム・アクティビティ、データベースのサイズなどに応じて、BUFFERまたはRECORDLENGTHに大きい値を指定します。サイズを大きくすると、データに対してエクスポート・ファイルがアクセスされる回数が削減されます。通常は数MBで十分です。バッファ・サイズが大きすぎることを示す、過剰なページングおよびスワッピング・アクティビティをチェックします。

- 索引はインポート後に作成できるため、時間に余裕がある場合は、INDEXES=Nの設定を考慮してください。設定する場合は、INDEXFILEパラメータを使用して索引作成のDLLを抽出するか、またはINDEXES=YおよびROWS=Nを指定してインポートを再実行します。

大量のLOBデータの処理

大量のLOBデータをインポートする場合は、次のことに注意してください。

索引を削除すると、総インポート時間が大幅に削減されます。LOBロケータには、インポート時に明示的に削除または無視できない主キーが存在するため、LOBデータのインポート時には特別な注意が必要です。

データのロードを完了するために使用できる十分な領域が、大きな連続したチャンクで存在することを確認してください。

大量のLONGデータの処理

LONG列を持つ表をインポートすると、I/Oおよびディスクの使用率が高くなり、その結果、インポート操作のパフォーマンスが低くなります。大量のLONGデータのインポート時にパフォーマンスを向上させる特定のパラメータは存在しませんが、この項で説明したチューニングに関する一般的な考慮点に注意することによって、パフォーマンス全体が向上する場合があります。

関連項目:

「LONG列のインポート」

リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用

この項では、リリースが異なるエクスポート・ユーティリティおよびOracle Databaseを使用することに関連した互換性の問題について説明します。

異なるリリースのOracle Database間でデータを移動するときは、必ず次の基本的な規則に従います。

- インポート・ユーティリティとデータのインポート先データベース(ターゲット・データベース)は同じバージョンである必要があります。たとえば、インポート・ユーティリティ9.2.0.7を使用して9.2.0.8のデータベースにインポートしようとすると、エラーが発生する場合があります。

- エクスポート・ユーティリティのバージョンは、ソースまたはターゲット・データベースの古い方のバージョンに合わせる必要があります。
たとえば、新しいリリースのデータベースにインポートするためにエクスポート・ファイルを作成する場合は、ソース・データベースと同じエクスポート・ユーティリティのバージョンを使用します。一方、古いリリースのデータベースにインポートするためのエクスポート・ファイルを作成する場合は、ターゲット・データベースのバージョンと同じバージョンのエクスポート・ユーティリティを使用します。

- 通常は、Oracle8リリースのエクスポート・ユーティリティを使用して、Oracle9iサーバーからエクスポートし、Oracle8エクスポート・ファイルを作成できます。

リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用時の制限事項

異なるリリースのエクスポート・ユーティリティおよびインポート・ユーティリティを使用する場合、次の制限があります。

- エクスポート・ダンプ・ファイルは、特別なバイナリ形式で格納されているため、インポート・ユーティリティによる読取り専用です。

- すべてのエクスポート・ダンプ・ファイルは、上位リリースのOracle Databaseにインポートできます。

- インポート・ユーティリティでは、上位のメンテナンス・リリースまたはバージョンのエクスポート・ユーティリティで作成されたエクスポート・ダンプ・ファイルの読取りはできません。たとえば、リリース9.2のエクスポート・ダンプ・ファイルは、リリース9.0.1のインポート・ユーティリティではインポートできません。

- 下位バージョンのエクスポート・ユーティリティを上位バージョンのOracle Databaseで実行すると、下位バージョンに存在しないデータベース・オブジェクトのカテゴリは、常に、エクスポートから除外されます。

- Oracle9iのエクスポート(ダイレクト・パスまたは従来型パス)によって生成されたエクスポート・ファイルは、以前のリリースのインポート・ユーティリティと互換性がありません。したがって、インポートにはOracle9iのインポートのみを使用できます。下位互換性が問題になる場合は、Oracle9iデータベースよりも古いリリースのエクスポート・ユーティリティを使用してください。

リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用例

表23-5に、異なるリリースのOracle Database間でデータを移動させる場合に使用するエクスポート・ユーティリティおよびインポート・ユーティリティのリリースの例を示します。

表23-5 リリースが異なるエクスポート・ユーティリティおよびインポート・ユーティリティの使用

エクスポート元>インポート先

使用するエクスポート・ユーティリティのリリース

使用するインポート・ユーティリティのリリース

8.1.6 -> 8.1.6

8.1.6

8.1.6

8.1.5 -> 8.0.6

8.0.6

8.0.6

8.1.7 -> 8.1.6

8.1.6

8.1.6

9.0.1 -> 8.1.6

8.1.6

8.1.6

9.0.1 -> 9.0.2

9.0.1

9.0.2

9.0.2 -> 10.1.0

9.0.2

10.1.0

10.1.0 -> 9.0.2

9.0.2

9.0.2

表23-5に、オリジナルのエクスポートおよびインポート・ユーティリティ間のデータ移動を示します。Oracle Database 10gリリース1 (10.1)以上では、ほとんどの場合にデータ・ポンプ・エクスポートおよびデータ・ポンプ・インポート・ユーティリティを使用することをお薦めします。これらのユーティリティは、オリジナルのエクスポートおよびインポート・ユーティリティと比較して、パフォーマンスが著しく向上しています。

関連項目:

10.1以上のリリースを含めた異なるリリース間でのデータのエクスポートおよびインポートの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

第V部 付録

ここには次の付録が含まれます。

SQL*Loaderの構文図

この付録では、SQL*Loaderの構文図について説明します。

A SQL*Loaderの構文図

この付録では、SQL*Loaderの構文を図形式(線路図またはDDL構文図ともいいます)で示します。ここで使用している構文の表記法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

次に示す構文図は、特定の句(pos_spec句など)が省略された形で示されています。この付録では、これらの構文図を拡張して詳しく説明します。

OPTIONS句

OPTIONS句(続き)

Load文

infile_clause

注意:

BADFILEおよびDISCARDFILE句で、ディレクトリ・パスまたはファイル名(あるいはその両方)を指定する必要があります。

concatenate_clause

into_table_clause

into_table_clause_continued

field_condition

delim_spec

full_fieldname

termination_spec

enclosure_spec

oid_spec

sid_spec

xmltype_spec

field_list

dgen_fld_spec

ref_spec

init_spec

bfile_spec

filler_fld_spec

scalar_fld_spec

lobfile_spec

pos_spec

datatype_spec

datatype_spec_cont

col_obj_fld_spec

collection_fld_spec

nested_table_spec

varray_spec

sdf_spec

count_spec

索引

A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X

A

- ABORT_STEPパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- ACCESS_METHODパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- アクセス権限

- エクスポートとインポート 1

- ADD_FILEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ

- 対話方式コマンド・モード 1

- ADR

- 「自動診断リポジトリ」を参照

- ADRベース

- ADRCIユーティリティ内 1

- ADRCI

- トラブルシューティング 1

- ADRCIユーティリティ 1

- ADRベース 1

- ADRホーム 1

- バッチ・モード 1

- コマンド 1

- ヘルプの表示 1

- ホームパス 1

- 対話方式モード 1

- 起動 1

- ADRホーム

- ADRCIユーティリティ内 1

- アドバンスト・キューイング

- アドバンスト・キュー表のエクスポート 1

- アドバンスト・キュー表のインポート 1

- 別名

- ディレクトリ

- エクスポート 1

- インポート 1

- アナライザ統計 1

- REDOログ・ファイルの分析 1

- ANYDATAタイプ

- SQL文字列を使用してロード 1

- APPENDパラメータ

- SQL*Loaderユーティリティ 1

- 表への追加

- SQL*Loader 1

- アーカイブされたLOB

- エクスポートに関する制限事項 1

- アーカイブ・ログ

- データ・ポンプ・ジョブでの無効化 1

- データ・ポンプ・ジョブでの有効化 1

- アーカイブ

- 使用禁止

- ダイレクト・パス・ロードの影響 1

- 配列

- 挿入後のコミット 1

- アトミックNULL 1

- 既存のジョブへの接続

- データ・ポンプ・エクスポート・ユーティリティ 1

- ATTACHパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- 属性

- null 1

- 属性値コンストラクタ

- 上書き 1

- データ・ポンプ・ジョブの監査

- 統合監査

- データ・ポンプ 1

- ダイレクト・パス・ロードの監査

- SQL*Loaderの使用時 1

- 自動診断リポジトリ 1

B

- バックスラッシュ・エスケープ文字 1

- バックアップ

- 削除されたスナップショットのリストア

- インポート 1

- BADFILEパラメータ

- SQL*Loaderユーティリティ 1

- 不良ファイル

- SQL*Loaderへの指定 1

- BADパラメータ

- SQL*Loaderコマンドライン 1

- SQL*Loaderエクスプレス・モード 1

- BEGINDATAパラメータ

- SQL*Loader制御ファイル 1

- BFILE

- オリジナルのエクスポート 1

- オリジナルのインポート 1

- SQL*Loaderでのロード 1

- ビッグ・エンディアン・データ

- 外部表 1

- バインド配列

- SQL*Loaderに対するサイズの指定 1

- SQL*Loaderのメモリー所要量の最小化 1

- 最小要件 1

- 複数のSQL*LoaderのINTO TABLE文のサイズ 1

- 最大サイズの指定 1

- 行数の指定 1

- SQL*Loaderパフォーマンスとの関連 1

- BINDSIZEパラメータ

- SQL*Loaderコマンドライン 1, 2

- 空白

- 空白のフィールドのロード 1

- フィールド比較用のSQL*Loader BLANKSパラメータ 1

- 後続 1

- 切捨て 1

- 外部表 1, 2, 3

- 空白 1

- BLANKSパラメータ

- SQL*Loaderユーティリティ 1

- BLOB

- SQL*Loaderでのロード 1

- バッファ・キャッシュのサイズ

- Streamsを伴うデータ・ポンプ操作 1

- BUFFERパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- バッファ

- エクスポートの計算 1

- SQL*LoaderのBINDSIZEパラメータを使用した指定 1

- バイト順序 1

- ビッグ・エンディアン 1

- リトル・エンディアン 1

- SQL*Loaderの制御ファイルでの指定 1

- BYTEORDERMARKパラメータ

- SQL*Loaderユーティリティ 1

- バイト順序マーク 1

- 優先順位

- 第1プライマリ・データ・ファイル 1

- LOBFILEおよびSDF 1

- 確認の抑止 1

- BYTEORDERパラメータ

- SQL*Loaderユーティリティ 1

C

- キャッシュされた順序番号

- エクスポート 1

- catalog.sqlスクリプト

- エクスポートおよびインポートのためのデータベースの準備 1, 2

- catexp.sqlスクリプト

- エクスポートおよびインポートのためのデータベースの準備 1, 2

- CDB

- Oracle Data Pumpのサポート 1

- データ・ポンプを使用したデータの移動 1

- データベースIDの変更 1

- データベース名の変更 1

- 文字フィールド

- デリミタとSQL*Loader 1, 2

- SQL*Loaderに対する長さの指定 1

- SQL*Loaderデータ型 1

- 文字長セマンティクス 1

- CHARACTERSETパラメータ

- SQL*Loaderエクスプレス・モード 1

- SQL*Loaderユーティリティ 1, 2

- キャラクタ・セット

- 変換

- エクスポートおよびインポート中 1, 2

- 8ビットから7ビットへの変換

- エクスポートおよびインポート 1, 2

- 外部表の識別 1

- マルチバイト

- エクスポート/インポート 1

- SQL*Loader 1

- シングルバイト

- エクスポートおよびインポート 1, 2

- SQL*Loader制御ファイル 1

- SQL*Loaderでの変換 1

- Unicode 1

- 文字列

- 外部表

- バイトまたは文字の指定 1

- SQL*Loader 1

- CHARデータ型

- デリミタ付き形式およびSQL*Loader 1

- CHECK制約

- 使用禁止の変更 1

- CLOB

- SQL*Loaderでのロード 1

- CLUSTERパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- コレクション 1

- ロード 1

- SQL*Loaderでサポートされるコレクション型 1

- 配列行の列

- 行数の指定 1

- COLUMNARRAYROWSパラメータ

- SQL*Loaderコマンドライン 1

- 列オブジェクト

- ロード 1

- ユーザー定義コンストラクタ 1

- 列

- LONGデータ型のエクスポート 1

- REF列のロード 1

- 命名

- SQL*Loader 1

- オブジェクト

- ネストした列オブジェクトのロード 1

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

- 可変レコード形式 1

- インポート実行前の順序変更 1

- SQL*Loaderを使用した定数値への設定 1

- SQL*Loaderを使用した式の値への設定 1

- SQL*Loaderを使用した一意の順序番号への設定 1

- SQL*Loaderを使用したNULLへの設定 1

- SQL*Loaderを使用した現在の日付への設定 1

- SQL*Loaderを使用したデータ・ファイルのレコード番号への設定 1

- 指定

- SQL*Loader 1

- PIECEDとしての指定

- SQL*Loader 1

- SQL*Loaderの使用 1

- コメント

- エクスポートおよびインポートのパラメータ・ファイル 1, 2

- 外部表 1, 2

- COMMITパラメータ

- インポート・ユーティリティ 1

- COMPILEパラメータ

- インポート・ユーティリティ 1

- 完了メッセージ

- エクスポート 1

- インポート 1

- 圧縮

- データ・ポンプ・ジョブでのアルゴリズムの指定 1

- データ・ポンプ・ジョブでの表の指定 1

- 外部表へのレベルの指定 1

- COMPRESSION_ALGORITHMパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- 圧縮アルゴリズム

- データ・ポンプ・ジョブでの指定 1

- COMPRESSIONパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- COMPRESSパラメータ

- エクスポート・ユーティリティ 1

- CONCATENATEパラメータ

- SQL*Loaderユーティリティ 1

- 従来型パスによる同時ロード 1

- 構成

- LogMinerユーティリティ 1

- CONSISTENTパラメータ

- エクスポート・ユーティリティ 1

- ネストした表 1

- パーティション表 1

- 統合

- エクステント 1

- CONSTANTパラメータ

- SQL*Loader 1

- 制約

- 自動整合性およびSQL*Loader 1

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

- 参照制約の使用禁止 1

- 使用可能化

- パラレル・ダイレクト・パス・ロード後 1

- ダイレクト・ロードに対する施行 1

- 違反

- インポート 1

- ロード方法 1

- CONSTRAINTSパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- コンストラクタ

- 属性値 1

- 上書き 1

- ユーザー定義 1

- 列オブジェクトのロード 1

- CONTENTパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- CONTINUE_CLIENTパラメータ

- データ・ポンプ・エクスポート・ユーティリティ

- 対話方式コマンド・モード 1

- データ・ポンプ・インポート・ユーティリティ

- 対話方式コマンド・モード 1

- CONTINUEIFパラメータ

- SQL*Loaderユーティリティ 1

- 制御ファイル

- キャラクタ・セット 1

- データ定義言語の構文 1

- データの指定 1

- SQL*Loader廃棄ファイルの指定 1

- SQL*Loader 1

- CONTROLパラメータ

- SQL*Loaderコマンドライン 1

- 従来型パス・エクスポート

- ダイレクト・パスとの比較 1

- 従来型パス・ロード

- 中断された場合の動作 1

- ダイレクト・パス・ロードとの比較 1

- 同時 1

- 単一パーティション 1

- SQL*Loaderバインド配列 1

- 使用する場合 1

- キャラクタ・セットの変換

- エクスポートおよびインポート中 1, 2

- キャラクタ・セットのソートの影響 1, 2

- データ変換

- ダイレクト・パス・ロード時 1

- 入力文字の変換 1

- CREATE REPORTコマンド, ADRCIユーティリティ 1

- CREATE SESSION権限

- エクスポート 1, 2

- インポート 1, 2

- 作成

- インシデント・パッケージ 1

- 表

- インポート実行前の手動操作 1

- CSVパラメータ

- SQL*Loaderエクスプレス・モード 1

D

- データ

- 変換

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

- デリミタで区切られたデータおよびSQL*Loader 1

- SQL*Loaderへの異なる入力形式の区別 1

- 異なる入力行オブジェクトのサブタイプの区別 1, 2

- エクスポート 1

- SQL*Loaderを使用した一意の値の生成 1

- 制御ファイルへの組込み 1

- SQL*Loader制御ファイルに組み込まれたデータのロード 1

- セクションごとのロード

- SQL*Loader 1

- 複数表へのロード

- SQL*Loader 1

- SQL*Loaderのデリミタ付きデータの最大長 1

- SQL*Loaderを使用したオペレーティング・システム間の移動 1

- リカバリ

- SQL*Loaderでのダイレクト・パス・ロード 1

- ダイレクト・パス・ロード時の保存 1

- 行の保存

- SQL*Loader 1

- 未ソート

- SQL*Loader 1

- SQL*Loaderのパフォーマンスのために最適化された値 1

- DATA_CACHEパラメータ

- SQL*Loaderユーティリティ 1

- DATA_OPTIONSパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- データベースID (DBID)

- 変更 1

- データベース識別子

- 変更 1

- データベースの移行

- パーティション化 1, 2

- データベース名(DBNAME)

- 変更 1

- データベース・オブジェクト

- LONG列のエクスポート 1

- データベース

- データベースIDの変更 1

- 名前の変更 1

- 全体のエクスポート 1

- 全体のインポート 1

- エクスポートおよびインポートの権限 1, 2

- 既存のデータ・ファイルの再利用

- インポート 1

- データ・キャッシュ機能

- DATA_CACHEパラメータ 1

- 外部表 1

- SQL*Loader 1

- データ・フィールド

- SQL*Loaderデータ型の指定 1

- データ・ファイル

- インポート中の上書き防止 1

- インポート時の再利用 1

- 指定 1, 2

- SQL*Loaderの形式の指定 1

- データ・ファイル

- SQL*Loaderのバッファの指定 1

- SQL*Loaderへの指定 1

- DATAFILESパラメータ

- インポート・ユーティリティ 1

- DATAパラメータ

- SQL*Loaderコマンドライン 1, 2

- SQL*Loaderエクスプレス・モード 1

- DATAPUMP_EXP_FULL_DATABASEロール 1

- DATAPUMP_IMP_FULL_DATABASEロール 1

- データ・ポンプ・エクスポート・ユーティリティ

- ABORT_STEPパラメータ 1

- ACCESS_METHODパラメータ 1

- 追加ダンプ・ファイルの追加 1

- ATTACHパラメータ 1

- CLUSTERパラメータ 1

- コマンドライン・モード 1, 2

- COMPRESSION_ALGORITHMパラメータ 1

- COMPRESSIONパラメータ 1

- CONTENTパラメータ 1

- リソース消費の制御 1

- DATA_OPTIONSパラメータ 1

- DIRECTORYパラメータ 1

- DUMPFILEパラメータ 1

- ダンプ・ファイル・セット 1

- ENCRYPTION_ALGORITHMパラメータ 1

- ENCRYPTION_MODEパラメータ 1

- ENCRYPTION_PASSWORDパラメータ 1

- ENCRYPTION_PWD_PROMPTパラメータ 1

- SecureFilesの暗号化 1

- ENCRYPTIONパラメータ 1

- ESTIMATE_ONLYパラメータ 1

- ESTIMATEパラメータ 1

- EXCLUDEパラメータ 1

- オブジェクトの除外 1

- エクスポート・モード 1

- FILESIZEコマンド

- 対話方式コマンド・モード 1

- FILESIZEパラメータ 1

- エクスポートされるデータのフィルタ処理

- EXCLUDEパラメータの使用 1

- INCLUDEパラメータの使用 1

- FLASHBACK_SCNパラメータ 1

- FLASHBACK_TIMEパラメータ 1

- FULLパラメータ 1

- HELPパラメータ

- 対話方式コマンド・モード 1

- INCLUDEパラメータ 1

- 対話方式コマンド・モード 1

- ADD_FILEパラメータ 1

- CONTINUE_CLIENTパラメータ 1

- EXIT_CLIENTパラメータ 1

- FILESIZE 1

- HELPパラメータ 1

- KILL_JOBパラメータ 1

- PARALLELパラメータ 1

- START_JOBパラメータ 1

- STATUSパラメータ 1, 2

- STOP_JOBパラメータ 1, 2

- インタフェース 1

- 起動

- SYSDBAとして 1, 2

- JOB_NAMEパラメータ 1

- ジョブ名

- 指定 1

- KEEP_MASTERパラメータ 1

- LOGFILEパラメータ 1

- LOGTIMEパラメータ 1

- METRICSパラメータ 1

- NETWORK_LINKパラメータ 1

- NOLOGFILEパラメータ 1

- PARALLELパラメータ

- コマンドライン・モード 1

- 対話方式コマンド・モード 1

- PARFILEパラメータ 1

- QUERYパラメータ 1

- REMAP_DATAパラメータ 1

- REUSE_DUMPFILESパラメータ 1

- SAMPLEパラメータ 1

- SCHEMASパラメータ 1

- SecureFiles LOBに関する考慮点 1

- SERVICE_NAMEパラメータ 1

- SOURCE_EDITIONパラメータ 1

- ジョブ名の指定 1

- STATUSパラメータ 1

- 構文図 1

- TABLESPACESパラメータ 1

- TABLESパラメータ 1

- 透過的なデータ暗号化 1

- TRANSPORT_FULL_CHECKパラメータ 1

- TRANSPORT_TABLESPACESパラメータ 1

- TRANSPORTABLEパラメータ 1

- バージョニング 1

- VERSIONパラメータ 1

- VIEWS_AS_TABLESパラメータ 1

- データ・ポンプ・インポート・ユーティリティ

- ABORT_STEPパラメータ 1

- ACCESS_METHODパラメータ 1

- 既存のジョブへの接続 1

- ATTACHパラメータ 1

- ソース・データ・ファイルの名前の変更 1

- CLUSTERパラメータ 1

- CONTENTパラメータ 1

- リソース消費の制御 1

- DATA_OPTIONSパラメータ 1

- DIRECTORYパラメータ 1

- DUMPFILEパラメータ 1

- ENCRYPTION_PASSWORDパラメータ 1

- ENCRYPTION_PWD_PROMPTパラメータ 1

- ESTIMATEパラメータ 1

- ジョブ・サイズの見積り 1

- EXCLUDEパラメータ 1

- インポートされるデータをフィルタ処理

- EXCLUDEパラメータの使用 1

- INCLUDEパラメータの使用 1

- FLASHBACK_SCNパラメータ 1

- FLASHBACK_TIMEパラメータ 1

- 全体インポート・モード 1

- FULLパラメータ 1

- HELPパラメータ

- コマンドライン・モード 1

- 対話方式コマンド・モード 1

- INCLUDEパラメータ 1

- 対話方式コマンド・モード 1

- CONTINUE_CLIENTパラメータ 1

- EXIT_CLIENTパラメータ 1

- HELPパラメータ 1

- KILL_JOBパラメータ 1

- PARALLELパラメータ 1

- START_JOBパラメータ 1

- STATUS 1

- STOP_JOBパラメータ 1

- インタフェース 1

- JOB_NAMEパラメータ 1

- KEEP_MASTERパラメータ 1

- LOGFILEパラメータ 1

- LOGTIMEパラメータ 1

- MASTER_ONLYパラメータ 1

- METRICSパラメータ 1

- NETWORK_LINKパラメータ 1

- NOLOGFILEパラメータ 1

- PARALLELパラメータ

- コマンドライン・モード 1

- PARFILEパラメータ 1

- PARTITION_OPTIONSパラメータ 1

- QUERYパラメータ 1

- REMAP_DATAFILEパラメータ 1

- REMAP_DATAパラメータ 1

- REMAP_SCHEMAパラメータ 1

- REMAP_TABLEパラメータ 1

- REMAP_TABLESPACEパラメータ 1

- REUSE_DATAFILESパラメータ 1

- スキーマ・モード 1

- SCHEMASパラメータ 1

- SERVICE_NAMEパラメータ 1

- SKIP_UNUSABLE_INDEXESパラメータ 1

- SOURCE_EDITIONパラメータ 1

- ジョブ名の指定 1

- インポートするダンプ・ファイル・セットを指定 1

- SQLFILEパラメータ 1

- STATUSパラメータ 1

- STREAMS_CONFIGURATIONパラメータ 1

- 構文図 1

- TABLE_EXISTS_ACTIONパラメータ 1

- 表モード 1

- 表領域モード 1

- TABLESPACESパラメータ 1

- TABLESパラメータ 1

- TARGET_EDITIONパラメータ 1

- TRANSFORMパラメータ 1

- 透過的なデータ暗号化 1

- TRANSPORT_DATAFILESパラメータ 1

- TRANSPORT_FULL_CHECKパラメータ 1

- TRANSPORT_TABLESPACESパラメータ 1

- TRANSPORTABLEパラメータ 1

- トランスポータブル表領域モード 1

- バージョニング 1

- VERSIONパラメータ 1

- VIEWS_AS_TABLESパラメータ(ネットワーク・インポート) 1

- VIEWS_AS_TABLESパラメータ(非ネットワーク・インポート) 1

- データ・ポンプのレガシー・モード 1

- データ型

- BFILE

- オリジナルのエクスポート 1

- オリジナルのインポート 1

- SQL*Loaderでのロード 1

- BLOB

- SQL*Loaderでのロード 1

- CLOB

- SQL*Loaderでのロード 1

- SQL*Loaderの変換 1

- 外部表フィールドの記述 1

- SQL*Loaderに対する文字フィールド長の設定 1

- DATE長の決定 1

- 外部表の識別 1

- システム固有

- SQL*Loaderでの競合する長さ指定 1

- NCLOB

- SQL*Loaderでのロード 1

- 非スカラー 1

- SQL*Loaderでの指定 1

- LogMinerユーティリティによるサポート 1

- SQL*Loaderで使用される型 1

- LogMinerユーティリティによりサポートされない 1

- DATE_FORMATパラメータ

- SQL*Loaderエクスプレス・モード 1

- DATEデータ型

- デリミタ付き形式およびSQL*Loader 1

- 長さの決定 1

- マスク

- SQL*Loader 1

- DBID (データベース識別子)

- 変更 1

- DBMS_LOGMNR_D.ADD_LOGFILES PL/SQLプロシージャ

- LogMinerユーティリティ 1

- DBMS_LOGMNR_D.BUILD PL/SQLプロシージャ

- LogMinerユーティリティ 1

- DBMS_LOGMNR_D.END_LOGMNR PL/SQLプロシージャ

- LogMinerユーティリティ 1

- DBMS_LOGMNR_D PL/SQLプロシージャ

- LogMinerユーティリティ 1

- DBMS_LOGMNR.COLUMN_PRESENTファンクション 1

- DBMS_LOGMNR.MINE_VALUE関数 1

- NULL値 1

- DBMS_LOGMNR.START_LOGMNR PL/SQLプロシージャ 1

- 複数回のコール 1

- COMMITTED_DATA_ONLYオプション 1

- ENDTIMEパラメータ 1, 2

- LogMinerユーティリティ 1

- オプション 1

- PRINT_PRETTY_SQLオプション 1

- SKIP_CORRUPTIONオプション 1

- STARTTIMEパラメータ 1, 2

- DBMS_LOGMNR PL/SQLプロシージャ

- LogMinerユーティリティ 1

- DBMS_METADATA PL/SQLパッケージ 1

- DBNAME

- 変更 1

- DBNEWIDユーティリティ 1

- データベースIDの変更 1

- データベース名の変更 1

- グローバル・データベース名への影響 1

- 制限 1

- 構文 1

- データベースIDの変更のトラブルシューティング 1

- DBVERIFYユーティリティ

- 出力 1

- 制限 1

- 構文 1

- セグメントの検査 1

- ディスク・ブロックの検査 1

- DEFAULTIFパラメータ

- SQL*Loader 1

- デフォルト・スキーマ

- SQL*Loaderが判別する 1

- DEGREE_OF_PARALLELISMパラメータ

- SQL*Loaderコマンドライン 1

- SQL*Loaderエクスプレス・モード 1

- DELETE ANY TABLE権限

- SQL*Loader 1

- DELETE CASCADE

- 空でない表へのデータのロードの影響 1

- SQL*Loader 1

- DELETE権限

- SQL*Loader 1

- デリミタ付きデータ

- SQL*Loaderの最大長 1

- デリミタ付きフィールド

- フィールド長 1

- デリミタ付きフィールドのLOB 1

- デリミタ

- 外部表 1

- 後続の空白のロード 1

- データ内のマークおよびSQL*Loader 1

- 外部表の指定 1

- SQL*Loaderの指定 1, 2

- SQL*Loaderの囲み 1

- SQL*Loaderのフィールド指定 1

- 終了 1

- DESTROYパラメータ

- インポート・ユーティリティ 1

- ディクショナリ

- LogMinerユーティリティの要件 1

- ディクショナリ・バージョンの不一致 1

- Direct NFSクライアント

- 読取りバッファ数の制御 1

- SQL*Loader操作時の使用 1

- 外部表との使用 1

- ディレクトリ別名

- エクスポート 1

- インポート 1

- ディレクトリ・オブジェクト

- データ・ポンプでの使用

- Oracle ASMの影響 1

- DIRECTORYパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- DIRECTパラメータ

- エクスポート・ユーティリティ 1

- SQL*Loaderコマンドライン 1

- SQL*Loaderエクスプレス・モード 1

- ダイレクト・パス・エクスポート 1, 2

- 従来型パスとの比較 1

- EXEMPT ACCESS POLICY権限の効果 1

- パフォーマンスの問題 1

- 制限 1

- セキュリティ上の考慮点 1

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

- メリット 1

- 中断された場合の動作 1

- ソート順序の選択

- SQL*Loader 1

- 従来型パス・ロードとの比較 1

- 同時 1

- 使用の条件 1

- データ・セーブ 1, 2

- 索引の削除 1

- アーカイブ使用禁止の影響 1

- 主キー制約の影響 1

- 一意キー制約の影響 1

- フィールド・デフォルト 1

- 不適切なソート

- SQL*Loader 1

- 索引 1

- インスタンス・リカバリ 1

- セグメント間同時処理 1

- セグメント内同時処理 1

- データ変換の位置 1

- メディア・リカバリ 1

- 複数CPUシステムの最適化 1

- パーティション・ロード

- SQL*Loader 1

- パフォーマンス 1, 2

- 記憶域の事前割当て 1

- データの事前ソート 1

- リカバリ 1

- ROWSコマンドライン・パラメータ 1

- 設定 1

- 指定 1

- 読み込む行数の指定 1

- SQL*Loaderでのデータ・ロード方法 1

- 表挿入トリガー 1

- 一時セグメント記憶域要件 1

- トリガー 1

- 使用 1, 2

- バージョンの要件 1

- 無効な一意索引

- 表のロード 1

- 廃棄されたSQL*Loaderレコード 1

- 原因 1

- 廃棄ファイル 1

- 制限 1

- 廃棄ファイル

- SQL*Loader 1

- 最大値の指定 1

- DISCARDパラメータ

- SQL*Loaderコマンドライン 1

- 中断されたロード 1

- 継続 1

- 従来型パスの動作 1

- ダイレクト・パスの動作 1

- DNFS_ENABLEパラメータ

- SQL*Loaderコマンドライン 1

- SQL*Loaderエクスプレス・モード 1

- DNFS_READBUFFERSパラメータ

- SQL*Loaderコマンドライン 1

- SQL*Loaderエクスプレス・モード 1

- 削除されたスナップショット

- インポート 1

- DUMPFILEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- ダンプ・ファイル

- 最大サイズ 1

E

- EBCDICキャラクタ・セット

- インポート 1, 2

- ECHOコマンド, ADRCIユーティリティ 1

- 8ビット・キャラクタ・セットのサポート 1, 2

- ENCLOSED_BYパラメータ

- SQL*Loaderエクスプレス・モード 1

- 囲まれたフィールド

- 空白 1

- 囲みデリミタ 1

- SQL*Loader 1

- 暗号化された列

- 外部表 1

- ENCRYPTION_ALGORITHMパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- ENCRYPTION_MODEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- ENCRYPTION_PASSWORDパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- ENCRYPTION_PWD_PROMPTパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- ENCRYPTIONパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- 暗号化パスワード

- データ・ポンプ・エクスポート 1

- データ・ポンプ・インポート 1

- エラー

- SQL*Loaderデータ中のタブ文字が原因 1

- LONGデータ 1

- オブジェクト作成 1

- インポート・パラメータIGNORE 1

- インポート中のリソース・エラー 1

- エクスポート・ログ・ファイルへの書込み 1

- ERRORSパラメータ

- SQL*Loaderコマンドライン 1

- エスケープ文字

- 引用符付き文字列 1

- データ・ポンプ・エクスポートでの使用 1

- データ・ポンプ・インポートでの使用 1

- エクスポートでの使用方法 1

- インポートでの使用方法 1

- ESTIMATE_ONLYパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- ESTIMATEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- ジョブ・サイズの見積り

- データ・ポンプ・エクスポート・ユーティリティ 1

- EVALUATE CHECK_CONSTRAINTS句 1

- EXCLUDEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- EXIT_CLIENTパラメータ

- データ・ポンプ・エクスポート・ユーティリティ

- 対話方式コマンド・モード 1

- データ・ポンプ・インポート・ユーティリティ

- 対話方式コマンド・モード 1

- 終了コード

- エクスポートおよびインポート 1, 2

- SQL*Loader 1, 2

- EXITコマンド, ADRCIユーティリティ 1

- EXP_FULL_DATABASEロール

- エクスポートでの割当て 1, 2

- expdat.dmp

- エクスポート出力ファイル 1

- エクスポート

- BUFFERパラメータ 1

- キャラクタ・セット変換 1, 2

- COMPRESSパラメータ 1

- CONSISTENTパラメータ 1

- CONSTRAINTSパラメータ 1

- 従来型パス 1

- 作成

- 必要な権限 1, 2

- 必要なビュー 1, 2

- DIRECTパラメータ 1

- ダイレクト・パス 1

- オンライン・ヘルプの表示 1

- セッションの例 1

- 全データベース・モード 1

- パーティション・レベル 1

- 表モード 1

- ユーザー・モード 1, 2

- 終了コード 1, 2

- データベース全体のエクスポート 1

- 索引のエクスポート 1

- 順序番号のエクスポート 1

- シノニムのエクスポート 1

- 別のオペレーティング・システムへのエクスポート 1, 2

- FEEDBACKパラメータ 1

- FILEパラメータ 1

- FILESIZEパラメータ 1

- FLASHBACK_SCNパラメータ 1

- FLASHBACK_TIMEパラメータ 1

- 全データベース・モード

- 例 1

- FULLパラメータ 1

- GRANTSパラメータ 1

- HELPパラメータ 1

- INDEXESパラメータ 1

- 起動 1, 2

- ログ・ファイル

- 指定 1

- エラー・メッセージのログ 1

- LOGパラメータ 1

- LONG列 1

- OBJECT_CONSISTENTパラメータ 1

- オンライン・ヘルプ 1

- OWNERパラメータ 1

- パラメータ・ファイル 1

- 最大サイズ 1, 2

- パラメータ構文 1

- PARFILEパラメータ 1

- データベース移行のパーティション化 1, 2

- QUERYパラメータ 1

- RECORDLENGTHパラメータ 1

- ログ・ファイルへの出力のリダイレクト 1

- リモート操作 1, 2

- 権限に基づく制限 1

- RESUMABLE_NAMEパラメータ 1

- RESUMABLE_TIMEOUTパラメータ 1

- RESUMABLEパラメータ 1

- ROWSパラメータ 1

- 順序番号 1

- 記憶域要件 1

- 表モード

- セッションの例 1

- 表名の制限 1

- TABLESPACESパラメータ 1

- TABLESパラメータ 1

- TRANSPORT_TABLESPACEパラメータ 1

- TRIGGERSパラメータ 1

- TTS_FULL_CHECKパラメータ 1

- ユーザー・アクセス権限 1, 2

- USERIDパラメータ 1

- ユーザー・モード

- セッションの例 1, 2

- 指定 1

- VOLSIZEパラメータ 1

- エクスポート・ダンプ・ファイル

- ファイル全体のインポート 1

- エクスポート・ファイル

- インポート実行前の内容のリスト 1

- 指定 1

- エクスポート

- アーカイブされたLOB 1

- EXPRESSIONパラメータ

- SQL*Loader 1, 2

- エクステント

- 統合 1

- EXTERNAL_TABLEパラメータ

- SQL*Loaderコマンドライン 1

- SQL*Loaderエクスプレス・モード 1

- EXTERNALパラメータ

- SQL*Loader 1

- EXTERNAL SQL*Loaderデータ型

- 数値

- 長さの決定 1

- 外部表

- アクセス・パラメータ 1, 2, 3

- 暗号化された列 1

- ビッグ・エンディアン・データ 1

- 読取り中のデータのキャッシュ 1

- column_transforms句 1

- データ・キャッシュ機能 1

- データ型 1

- デリミタ 1

- フィールドのデータ型の記述 1

- field_definitions句 1, 2

- 固定長レコード 1

- キャラクタ・セットの識別 1

- データ型の識別 1

- 使用時のパフォーマンスの向上

- データ・キャッシュ機能 1

- IO_OPTIONS句 1

- リトル・エンディアン・データ 1

- opaque_format_spec 1, 2, 3

- データの前処理 1

- record_format_info句 1, 2

- 予約語 1, 2

- 制限 1

- フィールドのデフォルト値設定 1

- フィールドのNULL設定 1

- データのロード時のレコードのスキップ 1

- 圧縮レベルの指定 1

- デリミタの指定 1

- ロード条件の指定 1

- 空白の切捨て 1, 2, 3

- SQL文字列の使用 1

- コメントの使用 1, 2

- 可変長レコード 1

F

- 致命的エラー

- 「リカバリ不能なエラー・メッセージ」を参照

- FEEDBACKパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- FIELD_NAMESパラメータ

- SQL*Loaderエクスプレス・モード 1

- フィールド条件

- SQL*Loaderへの指定 1

- フィールド長

- SQL*Loaderの指定 1

- フィールド位置

- SQL*Loader 1

- フィールド

- SQL*Loaderを使用した文字列との比較 1

- デリミタ付き

- 長さの決定 1

- SQL*Loader 1

- すべての空白のロード 1

- 事前のサイズ決定

- 長さ 1

- SQL*Loader 1

- 相対的な位置指定およびSQL*Loader 1

- SQL*Loaderへのデフォルトのデリミタの指定 1

- SQL*Loaderへの指定 1

- デリミタ付きのSQL*Loader

- 指定 1

- FIELDS句

- SQL*Loader 1

- データ・ポンプでのファイルの割当て

- ダンプ・ファイルの追加 1

- ファイルのデフォルトの場所 1

- NFSエラー 1

- ファイル名

- 引用符 1

- 複数のSQL*Loaderの指定 1

- SQL*Loader 1

- SQL*Loader不良ファイル 1

- FILEパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- SQL*Loaderコマンドライン 1

- SQL*Loaderユーティリティ 1

- FILESIZEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- FILLERフィールド

- init_specに対する引数としての使用 1

- データのフィルタ処理

- データ・ポンプ・エクスポート・ユーティリティの使用方法 1

- データ・ポンプ・インポート・ユーティリティの使用方法 1

- インポートされるメタデータをフィルタ処理

- データ・ポンプ・インポート・ユーティリティ 1

- ファイナライズ

- ADRCIユーティリティ内 1

- ファイングレイン・アクセスのサポート

- エクスポートとインポート 1

- 固定形式レコード 1

- 固定長レコード

- 外部表 1

- FLASHBACK_SCNパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- エクスポート・ユーティリティ 1

- FLASHBACK_TIMEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- エクスポート・ユーティリティ 1

- 外部関数ライブラリ

- エクスポート 1

- インポート 1, 2

- 形式

- SQL*Loader入力レコード 1

- 書式エラー

- SQL*Loader 1

- FROMUSERパラメータ

- インポート・ユーティリティ 1

- 全データベース・モード

- インポート 1

- FULLでの指定 1

- 全体エクスポート・モード

- データ・ポンプ・エクスポート・ユーティリティ 1

- FULLパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- 全体トランスポータブル・エクスポート 1

- 全体トランスポータブル・インポート 1

G

- グローバリゼーション

- SQL*Loader 1

- 権限

- エクスポート 1

- インポート 1

- GRANTSパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

H

- HELPパラメータ

- データ・ポンプ・エクスポート・ユーティリティ

- コマンドライン・モード 1

- 対話方式コマンド・モード 1

- データ・ポンプ・インポート・ユーティリティ

- コマンドライン・モード 1

- 対話方式コマンド・モード 1

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- 16進文字列

- SQL*Loader 1

- ホームパス

- ADRCIユーティリティ内 1

- HOSTコマンド, ADRCIユーティリティ 1

I

- IGNOREパラメータ

- インポート・ユーティリティ 1

- IMP_FULL_DATABASEロール

- インポートでの割当て 1, 2

- インポート

- BUFFERパラメータ 1

- キャラクタ・セット変換 1, 2, 3, 4

- COMMITパラメータ 1

- 配列挿入後のコミット 1

- COMPILEパラメータ 1

- CONSTRAINTSパラメータ 1

- 作成

- 必要な権限 1, 2

- 必要なビュー 1, 2

- 索引作成SQLスクリプトの作成 1

- データベース・オプティマイザ統計 1

- DATAFILESパラメータ 1

- DESTROYパラメータ 1

- 参照制約の使用禁止 1

- オンライン・ヘルプの表示 1

- 表領域の削除 1

- データベース・オブジェクトのインポートでのエラー 1

- セッションの例 1

- あるユーザーから別のユーザーへのすべての表のインポート 1

- 特定のユーザー用に選択された表 1

- 別のユーザーによってエクスポートされた表 1

- パーティション・レベル・インポートの使用 1

- 終了コード 1, 2

- エクスポート・ファイル

- ファイル全体のインポート 1

- インポート実行前の内容のリスト 1

- FEEDBACKパラメータ 1

- FILEパラメータ 1

- FILESIZEパラメータ 1

- FROMUSERパラメータ 1

- FULLパラメータ 1

- 権限

- インポート時の指定 1

- GRANTSパラメータ 1

- HELPパラメータ 1

- IGNOREパラメータ 1

- 権限のインポート 1

- 他のスキーマへのオブジェクトのインポート 1

- 表のインポート 1

- INDEXFILEパラメータ 1

- INSERTエラー 1

- 無効なデータ 1

- 起動 1, 2

- LOGパラメータ 1

- LONG列 1

- インポート実行前の手動による表の作成 1

- 手動による表の順序付け 1

- NLS_LANG環境変数 1, 2

- オブジェクト作成エラー 1

- オンライン・ヘルプ 1

- パラメータ・ファイル 1

- 最大サイズ 1, 2

- パラメータ構文 1

- PARFILEパラメータ 1

- パーティション・レベル 1

- 表名のパターン一致 1

- 読取り専用表領域 1

- RECORDLENGTHパラメータ 1

- レコード

- 長さの指定 1

- ログ・ファイルへの出力のリダイレクト 1

- リフレッシュ・エラー 1

- リモート操作 1, 2

- 表領域の再編成 1

- リソース・エラー 1

- 制限事項

- 自分のスキーマへのインポート 1

- RESUMABLE_NAMEパラメータ 1

- RESUMABLE_TIMEOUTパラメータ 1

- RESUMABLEパラメータ 1

- 既存のデータ・ファイルの再利用 1

- スキーマ・オブジェクト 1

- 順序 1

- SHOWパラメータ 1

- シングルバイト・キャラクタ・セット 1, 2

- SKIP_UNUSABLE_INDEXESパラメータ 1

- スナップショット・マスター表 1

- スナップショット 1

- 削除された場合のリストア 1

- ユーザーによる指定 1

- 索引作成コマンドの指定 1

- エクスポート・ファイルの指定 1

- STATISTICSパラメータ 1

- 記憶域パラメータ

- 上書き 1

- ストアド・ファンクション 1

- ストアド・プロシージャ 1

- STREAMS_CONFIGURATIONパラメータ 1

- STREAMS_INSTANTIATIONパラメータ 1

- システム・オブジェクト 1

- 表レベル 1

- 表名の制限 1, 2, 3

- 表オブジェクト

- インポート順序 1

- TABLESPACESパラメータ 1

- TABLESパラメータ 1

- TOID_NOVALIDATEパラメータ 1

- TOUSERパラメータ 1

- TRANSPORT_TABLESPACEパラメータ 1

- TTS_OWNERパラメータ 1

- チューニングに関する考慮点 1

- ユーザー・アクセス権限 1, 2

- USERIDパラメータ 1

- VOLSIZEパラメータ 1

- インシデント

- 故障診断機能インフラストラクチャ 1

- パッケージ化 1

- インシデント・パッケージ

- 故障診断機能インフラストラクチャ 1

- INCLUDEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- 索引

- 手動作成 1

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

- ダイレクト・ロードの状態 1

- 削除

- SQL*Loader 1

- 記憶域要件の計算 1

- エクスポート 1

- 索引作成コマンド

- インポート 1

- 使用禁止状態 1, 2

- 複数列

- SQL*Loader 1

- データの事前ソート

- SQL*Loader 1

- 使用禁止の場合のスキップ 1

- SQL*Loader 1

- ロード中断後の状態 1

- 一意 1

- INDEXESパラメータ

- エクスポート・ユーティリティ 1

- INDEXFILEパラメータ

- インポート・ユーティリティ 1

- 索引オプション

- SQL*LoaderでのSORTED INDEXES 1

- SQL*Loader SINGLEROWパラメータ 1

- 索引使用禁止状態

- 索引使用禁止状態のままの索引 1, 2

- INFILEパラメータ

- SQL*Loaderユーティリティ 1

- 挿入エラー

- インポート 1

- 指定 1

- 表へのINSERT

- SQL*Loader 1

- インスタンス親和性

- エクスポートとインポート 1

- インスタンス・リカバリ 1

- 整合性制約

- ダイレクト・パス・ロード時に使用禁止 1

- ダイレクト・パス・ロード時に使用可能 1

- インポート時の違反 1

- ロード方法 1

- 対話方式

- データ・ポンプ・エクスポート・ユーティリティ 1

- 内部LOB

- ロード 1

- 中断されたロード 1

- INTO TABLE文

- バインド配列サイズへの影響 1

- SQL*Loaderでの複数の文 1

- SQL*Loader 1

- 列名 1

- 廃棄 1

- 無効なデータ

- インポート 1

- 起動

- エクスポート 1, 2

- コマンドライン 1, 2

- ダイレクト・パス 1

- 対話方式 1, 2

- パラメータ・ファイル 1, 2

- インポート 1, 2

- SYSDBAとして 1, 2

- コマンドライン 1, 2

- 対話方式 1, 2

- パラメータ・ファイル 1, 2

- IPSコマンド, ADRCIユーティリティ 1

J

- JOB_NAMEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

K

- KEEP_MASTERパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- キー値

- SQL*Loaderを使用した生成 1

- KILL_JOBパラメータ

- データ・ポンプ・エクスポート・ユーティリティ

- 対話方式コマンド・モード 1

- データ・ポンプ・インポート・ユーティリティ 1

L

- 先頭の空白

- 定義 1

- 切捨ておよびSQL*Loader 1

- データ・ポンプのレガシー・モード 1

- 長さインジケータ

- サイズの決定 1

- Length-Value Pairで指定したLOB 1

- ライブラリ

- 外部関数

- エクスポート 1

- インポート 1, 2

- リトル・エンディアン・データ

- 外部表 1

- ロード

- コレクション 1

- 列オブジェクト 1

- 可変レコード形式 1

- 導出サブタイプの使用 1

- ユーザー定義コンストラクタ 1

- タブを含むデータ・ファイル

- SQL*Loader 1

- 外部表データ

- レコードのスキップ 1

- 条件の指定 1, 2

- LOB 1

- ネストした列オブジェクト 1

- オブジェクト表 1

- サブタイプを使用したオブジェクト表 1

- REF列 1

- サブパーティション表 1

- 表 1

- LOADパラメータ

- SQL*Loaderコマンドライン 1, 2

- SQL*Loaderエクスプレス・モード 1

- LOBデータ

- デリミタ付きフィールド 1

- Length-Value Pairフィールド 1

- 事前にサイズが決まっているフィールド 1

- SQL*Loaderでのロード 1

- エクスポート時の圧縮なし 1

- 読取りバッファのサイズ 1

- データ・ポンプでの記憶域の指定 1

- SQL*Loaderでサポートされる型 1, 2

- LOBデータ型 1

- LOBFILE 1, 2, 3

- LOGFILEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- ログ・ファイル

- ロード中断後 1

- エクスポート 1, 2

- インポート 1, 2

- データ・ポンプで書き込むデータの制限 1

- SQL*Loaderへの指定 1

- SQL*Loader 1

- 論理レコード

- SQL*Loaderを使用した複数の物理レコードの統合 1

- LogMinerユーティリティ

- 分析するREDOデータへのアクセス 1

- REDOログ・ファイル・リストの調整 1

- 出力の分析 1

- 構成 1

- DDL文を再適用する場合の注意 1

- 現在のログ・ファイル・リスト

- 格納される情報 1

- DBMS_LOGMNR_D.ADD_LOGFILES PL/SQLプロシージャ 1

- DBMS_LOGMNR_D.BUILD PL/SQLプロシージャ 1

- DBMS_LOGMNR_D.END_LOGMNR PL/SQLプロシージャ 1

- DBMS_LOGMNR_D PL/SQLプロシージャ 1

- DBMS_LOGMNR.START_LOGMNR PL/SQLプロシージャ 1

- DBMS_LOGMNR PL/SQLプロシージャ 1

- DDL追跡

- 時間範囲またはSCN範囲 1

- 分析中のREDOログ・ファイルの調査 1

- ディクショナリ

- 目的 1

- フラット・ファイルから抽出されたディクショナリ

- 格納される情報 1

- ディクショナリ・オプション 1

- フラット・ファイル 1

- オンライン・カタログ 1

- REDOログ・ファイル 1

- セッションの終了 1

- 再構築されたSQLの実行 1

- REDOログからのデータ値の抽出 1

- SCNによるデータのフィルタ処理 1

- 時間によるデータのフィルタ処理 1

- 返されるデータの書式設定 1

- グラフィカル・ユーザー・インタフェース 1

- サプリメンタル・ロギングのレベル 1

- LogMinerディクショナリの意味 1

- REDOログ・ファイルのデータのサブセットのマイニング 1

- マイニング・データベースの意味 1

- 操作概要 1

- パラメータ

- 格納される情報 1

- REDOログ・ファイル

- リモート・データベース 1

- 格納される情報 1

- ディクショナリの要件 1

- REDOログ・ファイルの要件 1

- ソース・データベースおよびマイニング・データベースの要件 1

- XMLTypeデータを使用する際の制限事項 1

- サンプル構成 1

- コミット済トランザクションのみの表示 1

- 破損のスキップ 1

- ソース・データベースの意味 1

- マイニングするREDOログ・ファイルの指定 1

- 自動 1

- 手動 1

- 分析対象のREDOログの指定 1

- 起動 1, 2

- 同一セッション内での複数回の起動 1

- フラット・ファイルに対してディクショナリを抽出する手順 1

- REDOログ・ファイルに対してディクショナリを抽出する手順 1

- オンライン・カタログにあるディクショナリを使用する手順 1

- 一般的セッションの手順 1

- サプリメンタル・ロギング 1

- データベース・レベル 1

- データベース・レベルの識別キー 1

- データベース・レベルでの無効化 1

- DDL追跡との相互作用 1

- ログ・グループ 1

- 最小 1

- 格納される情報 1

- 表レベルの識別キー 1

- 表レベルのログ・グループ 1

- ユーザー定義のログ・グループ 1

- サプリメンタル・ログ・グループ 1

- 条件付き 1

- 無条件 1

- サポートされるデータベース・バージョン 1

- サポートされるデータ型 1

- サポートされるREDOログ・ファイル・バージョン 1

- 透過的データ暗号化のサポート 1

- SQL_REDOおよびSQL_UNDOでのデリミタの抑制 1

- 表レベルのサプリメンタル・ロギング 1

- DDL文の追跡 1

- 要件 1

- サポートされないデータ型 1

- CDBでの使用 1

- オンライン・カタログの使用 1

- REDOログ・ファイル分析のための使用 1

- V$DATABASEビュー 1

- V$LOGMNR_CONTENTSビュー 1, 2, 3

- V$LOGMNR_LOGSビュー

- 問合せ 1

- ビュー 1

- LogMinerビューア 1

- LOGパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- SQL*Loaderコマンドライン 1

- LOGTIMEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- LONGデータ

- エクスポート 1

- インポート 1

M

- MASTER_ONLYパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- マスター表

- Oracle Data Pump API 1

- スナップショット

- オリジナルのインポート 1

- マテリアライズド・ビュー 1

- メディア・リカバリ

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

- メタデータAPI

- パフォーマンスの向上 1

- コレクションの取得 1

- オブジェクト・メタデータの取得での使用 1

- METRICSパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- データ列の欠落

- SQL*Loader 1

- マルチバイト・キャラクタ・セット

- SQL*Loaderでの空白 1

- SQL*Loader 1

- 複数列索引

- SQL*Loader 1

- 複数CPUシステム

- ダイレクト・パス・ロードの最適化 1

- 複数表へのロード

- SQL*Loaderを使用した一意の順序番号の生成 1

- SQL*Loader制御ファイルの指定 1

- マルチテナント・コンテナ・データベース 1, 2

- マルチスレッド

- 複数CPUシステム 1

- MULTITHREADINGパラメータ

- SQL*Loaderコマンドライン 1

N

- 名前付きパイプ

- 外部表ロード 1

- 固有のデータ型

- 長さ指定との競合

- SQL*Loader 1

- NCLOB

- SQL*Loaderでのロード 1

- ネストした列オブジェクト

- ロード 1

- ネストした表

- エクスポート 1

- 一貫性 1

- インポート 1

- NETWORK_LINKパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- ネットワーク

- エクスポートおよびインポート 1, 2

- データ・ポンプ使用時のNFSエラー 1

- NLS_LANG環境変数 1, 2

- エクスポートおよびインポート 1, 2

- NO_INDEX_ERRORSパラメータ

- SQL*Loaderコマンドライン 1

- NOLOGFILEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- リカバリ不能なエラー・メッセージ

- エクスポート 1

- インポート 1

- 非スカラー・データ型 1

- NOT NULL制約

- ロード方法 1

- NULLデータ

- ロード中のレコードの終わりの欠落列 1

- 指定されていない列およびSQL*Loader 1

- NULLIF...BLANKS句

- SQL*Loader 1

- NULLIF句

- SQL*Loader 1, 2

- NULLIFパラメータ

- SQL*Loaderエクスプレス・モード 1

- NULL

- アトミック 1

- 属性 1

- NULL値

- オブジェクト 1

- NUMBERデータ型

- SQL*Loader 1, 2

- 数値型EXTERNALデータ型

- デリミタ付き形式およびSQL*Loader 1

- 長さの決定 1

O

- OBJECT_CONSISTENTパラメータ

- エクスポート・ユーティリティ 1

- オブジェクト識別子 1

- インポート 1

- オブジェクト名

- SQL*Loader 1

- オブジェクト 1

- 作成エラー 1

- インポート中の既存オブジェクトの無視 1

- インポート作成エラー 1

- ネストした列オブジェクトのロード 1

- NULL値 1

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

- 可変レコード形式 1

- オブジェクト表

- ロード 1

- サブタイプの使用

- ロード 1

- オブジェクトの型定義

- エクスポート 1

- SQL*Loaderでサポートされるオブジェクト型 1

- オフライン・ローカル管理表領域

- エクスポート 1

- OID

- 「オブジェクト識別子」を参照

- オンライン・ヘルプ

- エクスポートとインポート 1

- opaque_format_spec 1, 2, 3

- オペレーティング・システム

- SQL*Loaderを使用した異なるシステムへのデータの移動 1

- OPTIMAL記憶域パラメータ

- エクスポートおよびインポートでの使用 1

- オプティマイザ統計 1

- 最適化

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

- SQL*Loader入力ファイル処理 1

- OPTIONALLY_ENCLOSED_BYパラメータ

- SQL*Loaderエクスプレス・モード 1

- OPTIONALLY ENCLOSED BY句

- SQL*Loader 1

- OPTIONSパラメータ

- パラレル・ロード 1

- SQL*Loaderユーティリティ 1

- ORA-39357: 警告: コンテナ・データベースのルートまたはシードに接続する場合、Oracle Data Pump操作は通常必要ありません 1

- ORACLE_DATAPUMPアクセス・ドライバ

- SQL ENCRYPT句の使用による影響 1

- 予約語 1, 2

- ORACLE_LOADERアクセス・ドライバ

- 予約語 1, 2

- Oracleアドバンスト・キューイング

- 「アドバンスト・キューイング」を参照

- Oracle Automatic Storage Management (ASM)

- データ・ポンプ 1

- Oracle Data Pump

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

- 制限 1

- マスター表 1

- パフォーマンスのチューニング 1

- Oracle Data Pump API 1

- クライアント・インタフェース 1

- ジョブの状態 1

- ジョブの進捗状況の監視 1

- OWNERパラメータ

- エクスポート・ユーティリティ 1

P

- パッケージ

- 作成 1

- 比較文字列の埋込み

- SQL*Loader 1

- パラレル・ロード 1

- ダイレクト・パスの制限 1

- PREPROCESSOR句を使用する場合 1

- PARALLELパラメータ

- データ・ポンプ・エクスポート・ユーティリティ

- コマンドライン・インタフェース 1

- 対話方式コマンド・モード 1

- データ・ポンプ・インポート・ユーティリティ

- コマンドライン・モード 1

- 対話方式コマンド・モード 1

- SQL*Loaderコマンドライン 1

- パラメータ・ファイル

- エクスポート 1

- エクスポートとインポート

- コメント 1, 2

- 最大サイズ 1, 2

- インポート 1

- SQL*Loader 1

- PARFILEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- エクスポート・コマンドライン 1

- インポート・コマンドライン 1

- SQL*Loaderエクスプレス・モード 1

- PARTITION_MEMORYパラメータ

- SQL*Loaderユーティリティ 1

- PARTITION_OPTIONSパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- パーティション・ロード

- 従来型パスによる同時ロード 1

- SQL*Loader 1

- SQL*Loaderでのパーティション・オブジェクトのサポート 1

- パーティション表

- エクスポートの一貫性 1

- エクスポート 1

- インポート 1, 2

- ロード 1

- データベース移行のパーティション化 1, 2

- 利点 1, 2

- デメリット 1, 2

- エクスポート中の手順 1, 2

- パーティション・レベル・エクスポート 1

- セッションの例 1

- パーティション・レベル・インポート 1

- 指定 1

- パターン一致

- インポート時の表名 1

- パフォーマンス

- 整合性制約使用時の向上 1

- ダイレクト・パス・ロードの最適化 1

- SQL*Loaderデータ・ファイルの読取りの最適化 1

- オリジナルのインポートのチューニング 1

- PIECEDパラメータ

- SQL*Loader 1

- POSITIONパラメータ

- タブを含むデータでの使用 1

- 複数のSQL*LoaderのINTO TABLE句 1, 2, 3

- 事前に決められたサイズのフィールド

- SQL*Loader 1

- 事前に決められたサイズのLOB 1

- 外部表用のデータの前処理 1

- パラレル処理の影響 1

- 前提条件

- SQL*Loader 1

- PRESERVEパラメータ 1

- 保持

- 空白 1

- PRIMARY KEY制約

- ダイレクト・パス・ロードへの影響 1

- 主キーOID

- 例 1

- 主キーREF列 1

- 権限

- EXEMPT ACCESS POLICY

- ダイレクト・パス・エクスポートへの影響 1

- エクスポートおよびインポートで必要 1, 2

- SQL*Loaderで必要 1

- 問題

- 故障診断機能インフラストラクチャ 1

- 問題キー

- 故障診断機能インフラストラクチャ 1

- PURGEコマンド, ADRCIユーティリティ 1

Q

- QUERYパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- エクスポート・ユーティリティ 1

- 制限 1

- QUITコマンド, ADRCIユーティリティ 1

- 引用符

- エスケープ文字 1

- ファイル名 1

- SQL文字列 1

- 表名 1, 2, 3, 4

- データ・ポンプ・エクスポートでの使用 1

- データ・ポンプ・インポートでの使用 1

- データベース・オブジェクト名での使用 1

R

- 読取り一貫性エクスポート 1

- 読取り専用表領域

- インポート 1

- READSIZEパラメータ

- SQL*Loaderコマンドライン 1

- LOBへの影響 1

- 最大サイズ 1

- RECNUMパラメータ

- SQL*LoaderのSKIPパラメータでの使用 1

- RECORDLENGTHパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- レコード

- 1つの論理レコードの作成

- SQL*Loader 1

- SQL*Loaderによる廃棄 1, 2

- SQL*Loaderの異なる形式の区別 1

- SQL*Loaderを使用した複数の論理レコードの抽出 1

- 固定形式 1

- ロード中のデータ列の欠落 1

- SQL*Loaderによる拒否 1, 2, 3, 4

- SQL*Loaderを使用したレコード番号への列の設定 1

- ロード方法の指定 1, 2

- エクスポート時の長さの指定 1

- インポート時の長さの指定 1

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

- リカバリ

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

- SQL*Loader 1

- 行の置換え 1

- REDOログ・ファイル

- LogMinerユーティリティ

- サポートされるバージョン 1

- REDOログ・ファイル

- 分析 1

- LogMinerユーティリティの要件 1

- LogMinerユーティリティに対する指定 1

- REDOログ

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

- インスタンスおよびメディア・リカバリ

- SQL*Loader 1

- ダイレクト・パス・ロード中の使用の最小化 1

- 領域の節約

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

- REF列 1

- ロード 1

- 主キー 1

- システム生成 1

- REFデータ

- インポート 1

- 参照整合性制約

- インポート時の使用禁止 1

- SQL*Loader 1

- リフレッシュ・エラー

- スナップショット

- インポート 1

- 拒否レコード

- SQL*Loader 1, 2

- 拒否ファイル

- SQL*Loaderへの指定 1

- 相対的なフィールド位置指定

- フィールドの開始位置およびSQL*Loader 1

- 複数のSQL*LoaderのINTO TABLE句 1

- REMAP_DATAFILEパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- REMAP_DATAパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- REMAP_SCHEMAパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- REMAP_TABLEパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- REMAP_TABLESPACEパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- リモート操作

- エクスポートおよびインポート 1, 2

- REPLACE表

- SQL*Loaderを使用した表の置換え 1

- 予約語

- 外部表 1, 2

- ORACLE_DATAPUMPアクセス・ドライバ 1, 2

- ORACLE_LOADERアクセス・ドライバ 1, 2

- SQL*Loader 1

- リソース消費

- データ・ポンプ・エクスポート・ユーティリティにおける制御 1

- データ・ポンプ・インポート・ユーティリティにおける制御 1

- リソース・エラー

- インポート 1

- RESOURCEロール 1

- 制限事項

- 他のユーザーのスキーマへのインポート 1

- エクスポート・パラメータ・ファイル内の表名 1

- インポート・パラメータ・ファイル内の表名 1, 2, 3

- RESUMABLE_NAMEパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- SQL*Loaderコマンドライン 1

- RESUMABLE_TIMEOUTパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- SQL*Loaderコマンドライン 1

- RESUMABLEパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- SQL*Loaderコマンドライン 1

- 再開可能な領域割当て

- 有効化および無効化 1, 2, 3

- オブジェクト・メタデータの取得

- メタデータAPIの使用 1

- REUSE_DATAFILESパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- REUSE_DUMPFILESパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- ロール

- DATAPUMP_EXP_FULL_DATABASE 1

- DATAPUMP_IMP_FULL_DATABASE 1

- EXP_FULL_DATABASE 1

- IMP_FULL_DATABASE 1

- RESOURCE 1

- ロールバック・セグメント

- CONSISTENTエクスポート・パラメータの効果 1

- 行エラー

- インポート 1

- ROWID列

- SQL*Loaderでのロード 1

- 行

- SQL*Loaderを使用してロードする場合の選択 1

- エクスポート 1

- セーブ前に挿入する数の指定

- SQL*Loader 1

- SQL*Loaderを使用した既存の行の更新 1

- ROWSパラメータ

- エクスポート・ユーティリティ 1

- パフォーマンスの問題

- SQL*Loader 1

- SQL*Loaderコマンドライン 1

- データ・セーブ時の指定での使用 1

- RUNコマンド, ADRCIユーティリティ 1

S

- SAMPLEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- スキーマ・モード・エクスポート

- データ・ポンプ・エクスポート・ユーティリティ 1

- スキーマ

- エクスポート時の指定 1

- SCHEMASパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- FLOAT EXTERNALの科学表記法 1

- スクリプト・ファイル

- エクスポートおよびインポート前の実行 1, 2

- SDF

- 「セカンダリ・データ・ファイル」を参照

- セカンダリ・データ・ファイル 1, 2

- SecureFiles

- データ・ポンプのエクスポート中の暗号化 1

- SecureFiles LOB

- エクスポートの考慮点 1

- セキュリティ上の考慮点

- ダイレクト・パス・エクスポート 1

- セグメント

- 一時

- SQL*LoaderのFILEパラメータ 1

- SELECTコマンド, ADRCIユーティリティ 1

- ファンクション 1

- 順序番号 1

- 順序番号

- キャッシュされた 1

- エクスポート 1

- 複数表へのロードおよびSQL*Loader 1

- 読み込まれず生成された順序番号およびSQL*Loader 1

- SQL*LoaderのSEQUENCE句による生成 1

- SERVICE_NAMEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- SET BASEコマンド, ADRCIユーティリティ 1

- SET BROWSERコマンド, ADRCIユーティリティ 1

- SET CONTROLコマンド, ADRCIユーティリティ 1

- SET ECHOコマンド, ADRCIユーティリティ 1

- SET EDITORコマンド, ADRCIユーティリティ 1

- SET HOMEPATHコマンド, ADRCIユーティリティ 1

- SET TERMOUTコマンド, ADRCIユーティリティ 1

- データが欠落しているショート・レコード

- SQL*Loader 1

- SHOW ALERTコマンド, ADRCIユーティリティ 1

- SHOW BASEコマンド, ADRCIユーティリティ 1

- SHOW CONTROLコマンド, ADRCIユーティリティ 1

- SHOW HM_RUNコマンド, ADRCIユーティリティ 1

- SHOW HOMEPATHコマンド, ADRCIユーティリティ 1

- SHOW HOMESコマンド, ADRCIユーティリティ 1

- SHOW INCDIRコマンド, ADRCIユーティリティ 1

- SHOW INCIDENTコマンド, ADRCIユーティリティ 1

- SHOW LOGコマンド, ADRCIユーティリティ 1

- SHOWパラメータ

- インポート・ユーティリティ 1

- SHOW PROBLEMコマンド, ADRCIユーティリティ 1

- SHOW REPORTコマンド, ADRCIユーティリティ 1

- SHOW TRACEFILEコマンド, ADRCIユーティリティ 1

- SILENTパラメータ

- SQL*Loaderコマンドライン 1

- SQL*Loaderエクスプレス・モード 1

- シングルバイト・キャラクタ・セット

- エクスポートおよびインポート 1, 2

- SINGLEROWパラメータ 1

- 単一表へのロード

- 継続 1

- SKIP_INDEX_MAINTENANCEパラメータ

- SQL*Loaderコマンドライン 1

- SKIP_UNUSABLE_INDEXESパラメータ

- インポート・ユーティリティ 1

- SQL*Loaderコマンドライン 1

- SKIP_USABLE_INDEXESパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- SKIPパラメータ

- SQL*Loader RECNUM指定への影響 1

- SQL*Loaderコマンドライン 1

- 使用禁止索引のスキップ 1

- スナップショット・ログ

- インポート 1

- スナップショット 1

- インポート 1

- マスター表

- インポート 1

- 削除された場合のリストア

- インポート 1

- SORTED INDEXES句

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

- SQL*Loader 1

- ソート

- 複数列索引

- SQL*Loader 1

- 最適なソート順序

- SQL*Loader 1

- ダイレクト・パス・ロード時の事前ソート 1

- SORTED INDEXES句

- SQL*Loader 1

- SOURCE_EDITIONパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- SPOOLコマンド, ADRCIユーティリティ 1

- SQL*Loader

- 表への行の追加 1

- ダイレクト・パス・ロードの監査 1

- BADコマンドライン・パラメータ 1

- 不良ファイル 1

- BADFILEパラメータ 1

- 不良ファイル 1

- バインド配列およびパフォーマンス 1

- BINDSIZEコマンドライン・パラメータ 1, 2

- ロードする行の選択 1

- COLUMNARRAYROWSコマンドライン・パラメータ 1

- コマンドライン・パラメータ 1

- 単一表へのロードの継続 1

- CONTROLコマンドライン・パラメータ 1

- 制御ファイル 1

- 従来型パス・ロード 1, 2

- DATA_CACHEコマンドライン・パラメータ 1

- DATAコマンドライン・パラメータ 1, 2

- データ変換 1

- データ定義言語

- 構文図 1

- データ型の指定 1

- DEGREE_OF_PARALLELISMコマンドライン・パラメータ 1

- デフォルト・スキーマを判別 1

- DIRECTコマンドライン・パラメータ 1

- ダイレクト・パス方式 1

- 監査 1

- データ・キャッシュ機能を使用したパフォーマンスの向上 1

- DISCARDコマンドライン・パラメータ 1

- 廃棄されたレコード 1

- DISCARDFILEパラメータ 1

- DISCARDMAXパラメータ 1

- DISCARDSパラメータ 1

- DNFS_ENABLEコマンドライン・パラメータ 1

- DNFS_READBUFFERSコマンドライン・パラメータ 1

- タブが原因で発生するエラー 1

- ERRORSコマンドライン・パラメータ 1

- 排他的アクセス 1

- エクスプレス・モード 1

- EXTERNAL_TABLEコマンドライン・パラメータ 1

- 外部表ロード 1

- FILEコマンドライン・パラメータ 1

- ファイル名 1

- グローバリゼーション・テクノロジ 1

- 索引オプション 1

- 表への行の挿入 1

- INTO TABLE文 1

- LOADコマンドライン・パラメータ 1, 2

- 列オブジェクトのロード 1

- 異なるプラットフォーム間でのデータのロード 1

- 制御ファイルに組み込まれたデータのロード 1

- オブジェクト表のロード 1

- ロード方法 1

- LOGコマンドライン・パラメータ 1

- ログ・ファイル 1

- データをロードする方法 1

- 複数のINTO TABLE文 1

- MULTITHREADINGコマンドライン・パラメータ 1

- NO_INDEX_ERRORSコマンドライン・パラメータ 1

- オブジェクト名 1

- PARALLELコマンドライン・パラメータ 1

- パラレル・データ・ロード 1, 2, 3

- 移植可能なデータ型 1

- READSIZEコマンドライン・パラメータ 1

- 最大サイズ 1

- 拒否レコード 1

- 表中の行の置換え 1

- 必要な権限 1

- RESUMABLE_NAMEコマンドライン・パラメータ 1

- RESUMABLE_TIMEOUTコマンドライン・パラメータ 1

- RESUMABLEコマンドライン・パラメータ 1

- ROWSコマンドライン・パラメータ 1

- SILENTコマンドライン・パラメータ 1

- SINGLEROWパラメータ 1

- SKIP_UNUSABLE_INDEXESコマンドライン・パラメータ 1

- SKIPコマンドライン・パラメータ 1

- ダイレクト・パス・ロードでのSORTED INDEXES 1

- 列の指定 1

- データ・ファイルの指定 1

- フィールド条件の指定 1

- フィールドの指定 1

- ロード方法の指定 1

- 複数のデータ・ファイルの指定 1

- STREAMSIZEコマンドライン・パラメータ 1

- メッセージの抑止 1

- TRIMコマンドライン・パラメータ 1

- USERIDコマンドライン・パラメータ 1, 2

- SQL*Loader制御ファイル

- 作成時のガイドライン 1

- SQL*Loaderデータ型

- 移植不能 1

- SQL*Loaderエクスプレス・モード 1, 2

- BADパラメータ 1

- バイト順序の処理 1

- CHARACTERSETパラメータ 1

- CSVパラメータ 1

- DATAパラメータ 1

- DATE_FORMATパラメータ 1

- デフォルト値 1

- DEGREE_OF_PARALLELISMパラメータ 1

- DIRECTパラメータ 1

- DNFS_ENABLEパラメータ 1

- DNFS_READBUFFERSパラメータ 1

- ENCLOSED_BYパラメータ 1

- EXTERNAL_TABLEパラメータ 1

- FIELD_NAMESパラメータ 1

- LOADパラメータ 1

- NULLIFパラメータ 1

- OPTIONALLY_ENCLOSED_BYパラメータ 1

- PARFILEパラメータ 1

- SILENTパラメータ 1

- 構文図 1

- TABLEパラメータ 1

- TERMINATED_BYパラメータ 1

- TIMESTAMP_FORMATパラメータ 1

- TRIMパラメータ 1

- USERIDパラメータ 1

- SQL*Loaderユーティリティ

- PARTITION_MEMORYパラメータ 1

- SQLFILEパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- SQL演算子

- フィールドへの適用 1

- SQL文字列

- SQL演算子のフィールドへの適用 1

- 引用符 1

- START_JOBパラメータ

- データ・ポンプ・エクスポート・ユーティリティ

- 対話方式コマンド・モード 1

- データ・ポンプ・インポート・ユーティリティ

- 対話方式コマンド・モード 1

- 起動

- LogMinerユーティリティ 1

- 統計

- アナライザ 1

- オプティマイザ 1

- インポート時の指定 1

- STATISTICSパラメータ

- インポート・ユーティリティ 1

- STATUSパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- 対話方式コマンド・モード 1

- データ・ポンプ・インポート・ユーティリティ 1

- 対話方式コマンド・モード 1

- STOP_JOBパラメータ

- データ・ポンプ・エクスポート・ユーティリティ

- 対話方式コマンド・モード 1

- データ・ポンプ・インポート・ユーティリティ

- 対話方式コマンド・モード 1

- 記憶域パラメータ

- エクスポート要件の見積り 1

- OPTIMALパラメータ 1

- 上書き

- インポート 1

- 事前割当て

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

- ダイレクト・パス・ロード時の一時記憶域パラメータ 1

- エクスポートおよびインポートでの使用 1

- ストアド・ファンクション

- インポート 1

- COMPILEパラメータの影響 1

- ストアド・パッケージ 1

- ストアド・パッケージ

- インポート 1

- ストアド・プロシージャ

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

- インポート 1

- COMPILEパラメータの影響 1

- ストリーム・バッファ

- ダイレクト・パスのサイズ指定 1

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

- 列オブジェクトのロード 1

- STREAMS_CONFIGURATIONパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- インポート・ユーティリティ 1

- STREAMS_INSTANTIATIONパラメータ

- インポート・ユーティリティ 1

- データ・ポンプのStreams環境

- バッファ・キャッシュ・サイズの設定 1

- STREAMSIZEパラメータ

- SQL*Loaderコマンドライン 1

- 文字列の比較

- SQL*Loader 1

- サブパーティション表

- ロード 1

- サブタイプ

- 複数のロード 1

- サプリメンタル・ロギング 1

- 「LogMinerユーティリティ」も参照

- LogMinerユーティリティ 1

- データベース・レベルの識別キー 1

- ログ・グループ 1

- 表レベル 1

- 表レベルの識別キー 1

- 表レベルのログ・グループ 1

- シノニム

- エクスポート 1

- 構文図

- データ・ポンプ・エクスポート 1

- データ・ポンプ・インポート 1

- SQL*Loader 1

- SQL*Loaderエクスプレス・モード 1

- SYSDATEパラメータ

- SQL*Loader 1

- システム生成OID型のREF列 1

- システム・オブジェクト

- インポート 1

- システム・トリガー

- インポート時の影響 1

- テスト 1

T

- TABLE_EXISTS_ACTIONパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- 表の圧縮

- データ・ポンプ・ジョブでの型の指定 1

- 表レベル・エクスポート 1

- 表レベル・インポート 1

- 表モード・エクスポート

- データ・ポンプ・エクスポート・ユーティリティ 1

- 指定 1

- 表モードのインポート

- 例 1

- 表名

- 大/小文字の区別の保持 1

- TABLEパラメータ

- SQL*Loaderエクスプレス・モード 1

- 表 1

- 「外部表」も参照

- アドバンスト・キューイング

- エクスポート 1

- インポート 1

- SQL*Loaderを使用した行の追加 1

- インポート前の定義 1

- 定義

- インポート前の作成 1

- ダイレクト・パス・ロード中の排他的アクセス

- SQL*Loader 1

- 外部 1

- インポート 1

- SQL*Loaderを使用した行の挿入 1

- 挿入トリガー

- SQL*Loaderでのダイレクト・パス・ロード 1

- SQL*Loaderを使用した複数表へのデータのロード 1

- オブジェクト表のロード 1

- エクスポート時の一貫性の維持 1

- 手動によるインポートの順序付け 1

- マスター表

- インポート 1

- 名前の制限

- エクスポート 1

- インポート 1, 2, 3, 4

- ネストした

- エクスポート 1

- インポート 1

- オブジェクト

- インポートの順序 1

- パーティション化 1

- SQL*Loaderを使用した行の置換え 1

- エクスポート時の指定 1

- 表モード・エクスポートの指定 1

- 個々の表に対するSQL*Loaderの方法 1

- 切捨て

- SQL*Loader 1

- SQL*Loaderを使用した既存の行の更新 1

- 表領域モード・エクスポート

- データ・ポンプ・エクスポート・ユーティリティ 1

- 表領域

- インポート中の削除 1

- 一連のエクスポート 1, 2

- メタデータ

- トランスポート 1

- 読取り専用

- インポート 1

- 再編成

- インポート 1

- TABLESPACESパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- TABLESパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- タブ

- タブを含むデータ・ファイルのロード 1

- 切捨て 1

- 空白 1

- TARGET_EDITIONパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- 一時セグメント 1

- FILEパラメータ

- SQL*Loader 1

- ダイレクト・パス・ロード時の一時記憶域 1

- TERMINATED_BYパラメータ

- SQL*Loaderエクスプレス・モード 1

- TERMINATED BY句

- OPTIONALLY ENCLOSED BY付き 1

- 終端を指定されたフィールド

- デリミタによる指定 1

- TIMESTAMP_FORMATパラメータ

- SQL*Loaderエクスプレス・モード 1

- タイムスタンプ

- データ・ポンプ・エクスポート操作時 1

- データ・ポンプ・インポート操作時 1

- TOID_NOVALIDATEパラメータ

- インポート・ユーティリティ 1

- TOUSERパラメータ

- インポート・ユーティリティ 1

- トレース・ファイル

- ADRCIを使用した表示 1

- 後続の空白

- デリミタを使用したロード 1

- TRAILING NULLCOLSパラメータ

- SQL*Loaderユーティリティ 1, 2

- 後続の空白

- 切捨て 1

- TRANSFORMパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- データの透過的な暗号化

- データ・ポンプ・エクスポートによる処理 1

- データ・ポンプ・インポートによる処理 1

- LogMinerサポート 1

- TRANSPORT_DATAFILESパラメータ

- データ・ポンプ・インポート・ユーティリティ 1

- TRANSPORT_FULL_CHECKパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- TRANSPORT_TABLESPACEパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- TRANSPORT_TABLESPACESパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- トランスポータブル・オプション

- 全体モード・エクスポート時の使用 1

- 全体モード・インポート時の使用 1

- 表モード・エクスポート時の使用 1

- TRANSPORTABLEパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- トランスポータブル表領域モード・エクスポート

- データ・ポンプ・エクスポート・ユーティリティ 1

- トランスポータブル表領域 1, 2

- トリガー

- データベース挿入 1

- ログオン

- SQL*Loaderでの影響 1

- 永続的に使用禁止 1

- 整合性制約への置換 1

- システム

- テスト 1

- 更新

- SQL*Loader 1

- TRIGGERSパラメータ

- エクスポート・ユーティリティ 1

- 切捨て

- サマリー 1

- 後続の空白

- SQL*Loader 1

- TRIMパラメータ

- SQL*Loaderコマンドライン 1

- SQL*Loaderエクスプレス・モード 1

- TTS_FULL_CHECKパラメータ

- エクスポート・ユーティリティ 1

- TTS_OWNERSパラメータ

- インポート・ユーティリティ 1

U

- 統合監査

- SQL*Loader操作時 1

- UNIQUE KEY制約

- ダイレクト・パス・ロードへの影響 1

- 一意の値

- SQL*Loaderを使用した生成 1

- データベース全体のアンロード

- データ・ポンプ・エクスポート・ユーティリティ 1

- UNRECOVERABLE句

- SQL*Loader 1

- 未ソート・データ

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

- SQL*Loader 1

- USER_SEGMENTSビュー

- エクスポート 1

- ユーザー定義コンストラクタ 1

- 列オブジェクトのロード 1

- USERIDパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

- SQL*Loaderコマンドライン 1, 2

- SQL*Loaderエクスプレス・モード 1

- ユーザー・モード・エクスポート

- 指定 1

V

- V$DATABASEビュー 1

- V$LOGMNR_CONTENTSビュー 1

- 返される情報の書式設定 1

- 問合せの影響 1

- 含まれる情報 1

- 返される情報の制限 1

- LogMinerユーティリティ 1

- 問合せの要件 1, 2

- V$LOGMNR_LOGSビュー 1

- 問合せ 1

- V$SESSION_LONGOPSビュー

- データ・ポンプ・ジョブの監視 1

- VARCHAR2データ型

- SQL*Loader 1

- 可変長レコード

- 外部表 1

- 可変レコード 1

- 書式 1

- VARRAY列

- ロード時のメモリーの問題 1

- VERSIONパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- データ・ポンプ・インポート・ユーティリティ 1

- 表示

- ADRCIによるトレース・ファイルの表示 1

- ビュー

- 表としてのエクスポート 1

- VIEWS_AS_TABLES

- データ・ポンプ・エクスポート・パラメータ 1

- VIEWS_AS_TABLES (ネットワーク・インポート)

- データ・ポンプ・インポート・パラメータ 1

- VIEWS_AS_TABLES (非ネットワーク・インポート)

- データ・ポンプ・インポート・パラメータ 1

- VIEWS_AS_TABLESパラメータ

- データ・ポンプ・エクスポート・ユーティリティ 1

- VIEWS_AS_TABLESパラメータ(ネットワーク・インポート)

- データ・ポンプ・インポート・ユーティリティ 1

- VIEWS_AS_TABLESパラメータ(非ネットワーク・インポート)

- データ・ポンプ・インポート・ユーティリティ 1

- VOLSIZEパラメータ

- エクスポート・ユーティリティ 1

- インポート・ユーティリティ 1

W

- 警告メッセージ

- エクスポート 1

- インポート 1

- WHEN句

- SQL*Loader 1, 2

- SQL*Loaderの廃棄 1

- 空白

- フィールドに含まれた 1

- 先頭 1

- 保持 1

- フィールドの終了 1

- 切捨て 1

X

- XML列

- SQL*Loaderでのロード 1

- SQL*Loaderによる処理 1

- XMLTYPE句

- SQL*Loaderの制御ファイル 1

- XML型の表

- SQL*Loaderで識別 1

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2018, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。