ヘッダーをスキップ
Oracle® Databaseユーティリティ
12cリリース1 (12.1)
B71303-02
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

1 Oracle Data Pumpの概要

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

この章の内容は、次のとおりです。

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

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管理者ガイド』を参照してください。

ソース・プラットフォームとターゲット・プラットフォームのエンディアンが異なる場合、転送するデータを変換してターゲット・プラットフォームの形式にする必要があります。DBMS_FILE_TRANSFER PL/SQLパッケージまたはRMAN CONVERTコマンドを使用してデータを変換できます。これらのオプションの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。


参照:

  • RMAN CONVERTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

  • データベース間で行う表領域の転送の詳細および例(データの変換方法を含む)は、『Oracle Database管理者ガイド』を参照してください。


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

ダイレクト・パスは、データ・ファイル・コピーの次に高速なデータ移動方法です。この方法では、データベースのSQLレイヤーはバイパスされ、最小限の解析のみで行の移動がダンプ・ファイル間で行われます。データ・ポンプでは、データをロードおよびアンロードするのに、表の構造上可能な場合は、自動的にダイレクト・パスによる方法が使用されます。たとえば、表にBFILE型の列が含まれる場合は、ダイレクト・パスを使用して表をロードできないため、かわりに外部表が使用されます。

次の項では、ロードおよびアンロードに、ダイレクト・パスを使用できない場合について説明します。

ダイレクト・パス・ロードが使用されない場合

表が次に示すいずれかの条件に該当する場合、データ・ポンプでは、その表へのデータのロードにダイレクト・パスではなく外部表が使用されます。

  • CONTEXTタイプの索引ではないドメイン索引がLOB列に存在する。

  • 単一パーティションのロード中に、複数パーティション表のグローバル索引が存在する。これには、パーティション化されたオブジェクト表も含まれる。

  • クラスタ内に表が存在する。

  • 既存の表にアクティブなトリガーが存在する。

  • 既存の表で、ファイングレイン・アクセス・コントロールが挿入モードで有効である。

  • 表にBFILE列または不透明な型の列が存在する。

  • 既存の表に参照整合性制約が存在する。

  • 表に不透明な型が埋め込まれたVARRAY列が存在する。

  • 表に暗号化された列がある。

  • データのインポート先が既存の表であり、次に示す1つ以上の条件に該当する。

    • アクティブなトリガーが存在する。

    • 表がパーティション化されている。

    • ファイングレイン・アクセス・コントロールが挿入モードである。

    • 参照整合性制約が存在する。

    • 一意索引が存在する。

  • サプリメンタル・ロギングが有効で、表に1つ以上のLOB列がある。

  • 指定した表のデータ・ポンプ・コマンドが、QUERYSAMPLEまたはREMAP_DATAパラメータを使用している。

  • 表にTIMESTAMP WITH TIME ZONEデータ型を持つ列(VARRAY列を含む)が含まれていて、タイムゾーン・データ・ファイルのバージョンがエクスポート・システムとインポート・システム間で異なる。

ダイレクト・パス・アンロードが使用されない場合

表が次に示すいずれかの条件に該当する場合、データ・ポンプでは、データをアンロードするためにダイレクト・パスではなく外部表による方法が使用されます。

  • SELECTに対するファイングレイン・アクセス・コントロールが有効である。

  • 表は、キュー表である。

  • 表に1つまたは複数のBFILE型または不透明な型の列、あるいは不透明な列を含むオブジェクト型が存在する。

  • 表に暗号化された列がある。

  • 表にアップグレードが必要な進化した型の列がある。

  • 表に最新ではないLONG型またはLONG RAW型の列がある。

  • 指定した表のデータ・ポンプ・コマンドが、QUERYSAMPLEまたはREMAP_DATAパラメータを使用している。

  • アンロード操作の前に、NOT NULLかつ指定されたデフォルト値を持つ列を含むように表が変更されている。

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

データ・ファイル・コピーが選択されず、ダイレクト・パスでデータを移動できない場合、外部表によるメカニズムが使用されます。外部表によるメカニズムでは、データベース表のダンプ・ファイル・データにマップする外部表が作成されます。その後、SQLエンジンを使用してデータが移動されます。可能な場合は、インポート時にAPPENDヒントが使用されて、データベースへのデータのコピーが高速化されます。ダイレクト・パス・データと外部表データは、ダンプ・ファイル内で同様に表示されます。したがって、データ・ポンプでは、エクスポート時にはダイレクト・パスによるメカニズムが使用されても、ターゲット・データベースへのデータのインポート時には外部表が使用される場合があります。同様に、データ・ポンプでは、エクスポートに外部表、インポートにダイレクト・パスが使用される場合もあります。

特に、データ・ポンプでは、次のような場合に外部表が使用されます。

  • パラレルSQL機能の使用がメリットとなる状況において、非常に大きい表およびパーティションをロードおよびアンロードする場合

  • グローバル索引またはドメイン索引が定義されている表(パーティション・オブジェクト表など)をロードする場合

  • トリガーがアクティブになっている表またはクラスタ表をロードする場合

  • 暗号化された列が含まれている表をロードおよびアンロードする場合

  • ファイングレイン・アクセス・コントロールでの挿入が使用可能な表をロードする場合

  • ロード時およびアンロード時に別の方法でパーティション化される表をロードする場合

  • インポート操作以外で作成された表をロードする場合(インポートを開始する前から表が存在する)


注意:

データ・ポンプがデータ・アクセスに外部表を使用する場合は、ORACLE_DATAPUMPアクセス・ドライバが使用されます。ただし、外部表を使用する際にデータ・ポンプで作成されるファイルは、ユーザーがSQL CREATE TABLE ... ORGANIZATION EXTERNAL文を使用して外部表を手動で作成する際に作成されるファイルとは互換性がないことに注意してください。


参照:


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

表属性の競合が存在する場合、データ・ポンプは、ダイレクト・パスと外部表のいずれの方法でも表にデータをロードできません。このような場合は従来型パスが使用されますが、パフォーマンスに影響する可能性があります。

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

インポート操作のネットワーク・リンクの指定に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に移動できます。このジョブは、トランスポータブル・オプションを指定しても指定しなくても実行できます。トランスポータブル・オプションを全体モード・エクスポートまたはインポートで使用する場合、全体トランスポータブル・エクスポート/インポートと呼ばれます。

トランスポータブル・オプションが使用される場合、エクスポートおよびインポートでは、トランスポータブル表領域のデータ移動と従来のデータ移動の両方を使用しますが、後者はSYSTEMSYSAUXなどの非トランスポータブル表領域に存在する表が対象です。トランスポータブル・オプションを使用すると、表データをアンロードおよび再ロードする必要と、ユーザー表領域の索引構造を再作成する必要がなくなるため、エクスポート時間と(特に)インポート時間を短縮できます。

エクスポート/インポート操作に対して特定の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=YESTRANSPORTABLE=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

参照:


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

データ・ポンプの多くのエクスポートおよびインポート操作では、DATAPUMP_EXP_FULL_DATABASEロールまたはDATAPUMP_IMP_FULL_DATABASEロール(あるいはその両方)をユーザーが持っている必要があります。 これらのロールは、データベース作成の一環として標準スクリプトを実行すると、自動的にOracle Database用に定義されます。(これらのロールの名前にはFULLという語が含まれますが、これらのロールは、実際には全体モードのみではなく、任意のエクスポートまたはインポート・モードのすべての特権操作に適用されることに注意してください。)

DATAPUMP_EXP_FULL_DATABASEロールはエクスポート操作にのみ影響しますDATAPUMP_IMP_FULL_DATABASEロールは、インポート操作と、SQLFILEインポート・パラメータを使用する操作に影響します。これらのロールによって、ユーザーは次の処理を行うエクスポートおよびインポート操作を実行できます。

  • 自分のスキーマ・スコープ以外での操作の実行

  • 他のユーザーが開始したジョブの監視

  • 権限のないユーザーが参照できないオブジェクトのエクスポート(表領域定義など)とインポート(ディレクトリ定義など)

これらは強力なロールです。これらのロールをユーザーに付与する際は、十分に注意する必要があります。

SYSスキーマには、これらのいずれのロールも割り当てられていません。ただし、データ・ポンプが実行するセキュリティ・チェックの中でこれらのロールを必要とするものについては、SYSスキーマにアクセス権が付与されます。


参照:

Oracle Databaseのインストールで事前定義されるロールの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

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

データ・ポンプ・ジョブでは、マスター表、マスター・プロセス、ワーカー・プロセスを使用して、処理が実行され、進捗状況が追跡されます。

ジョブの調整

すべてのデータ・ポンプ・エクスポート・ジョブおよびデータ・ポンプ・インポート・ジョブに対して、マスター・プロセスが作成されます。マスター・プロセスによって、ジョブ全体(クライアントとの通信、ワーカー・プロセス・プールの作成および制御、ロギング操作の実行など)が制御されます。

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

データおよびメタデータの転送中、ジョブ内の進捗状況の追跡にマスター表が使用されます。マスター表は、ユーザー表としてデータベース内に実装されます。また、 エクスポート・ジョブおよびインポート・ジョブ用のマスター表固有の機能は、次のとおりです。

  • エクスポート・ジョブの場合、マスター表には、ダンプ・ファイル・セット内のデータベース・オブジェクトの位置が記録されます。エクスポート・ユーティリティでは、ジョブの継続中に、マスター表の作成およびメンテナンスが行われます。エクスポート・ジョブ終了時に、マスター表の内容がダンプ・ファイル・セット内のファイルに書き込まれます。

  • インポート・ジョブの場合、マスター表は、ダンプ・ファイル・セットからロードされ、ターゲット・データベースにインポートする必要があるオブジェクトの位置を特定する操作の順序の制御に使用されます。

マスター表は、エクスポートまたはインポート操作を実行している現在のユーザーのスキーマ内に作成されます。そのため、このユーザーには、CREATE TABLEシステム権限およびマスター表を作成するための十分な表領域の割当て制限が必要です。マスター表の名前は、その表を作成したジョブと同じ名前になります。したがって、データ・ポンプ・ジョブに、既存の表またはビューと同じ名前を明示的には指定できません。

すべての操作で、ジョブの再起動にマスター表の情報が使用されます。(トランスポータブル・ジョブは再開できないことに注意してください。)

マスター表は、状況に応じて、次のとおり保持または削除されます。

  • ジョブが正常に終了すると、マスター表は削除されます。これを上書きするには、ジョブに対してデータ・ポンプのKEEP_MASTER=YESパラメータを設定します。

  • ジョブが正常に完了しなかった場合、マスター表は自動的に保持されます。

  • 対話方式コマンドSTOP_JOBを使用してジョブを停止すると、ジョブの再起動に使用できるようにマスター表は保持されます。

  • 対話方式コマンドKILL_JOBを使用してジョブを中断すると、マスター表は削除され、ジョブを再起動できません。

  • ジョブが突然終了した場合でも、マスター表は保持されます。このジョブを再起動しない場合、マスター表を削除できます。

  • ジョブが実行を開始する前(つまり、データベース・オブジェクトがコピーされる前)に停止すると、マスター表は削除されます。


参照:

ジョブ名の形式の詳細は、「JOB_NAME」を参照してください。

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

マスター表内では、名前や自分のスキーマなどの属性が特定のオブジェクトに割り当てられます。オブジェクトは、オブジェクトのクラス(TABLEINDEXDIRECTORYなど)にも属します。オブジェクトのクラスは、オブジェクトのオブジェクト型と呼ばれます。EXCLUDEおよびINCLUDEパラメータを使用して、エクスポートまたはインポートされるオブジェクト型を制限できます。オブジェクトの名前またはオブジェクトを自分のスキーマの名前に基づいて、制限するオブジェクトを指定できます。データ固有のフィルタを指定して、エクスポートおよびインポートする行を制限することもできます。

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

データベース間でデータを移動する場合は、表領域間で記憶域を再マップしたり、特定のオブジェクトの所有者を再定義するために、メタデータの変換を実行すると有効です。これは、データ・ポンプ・インポート・パラメータのREMAP_DATAFILEREMAP_SCHEMAREMAP_TABLE、REMAP_TABLESPACETRANSFORMおよびPARTITION_OPTIONSを使用して実行されます。

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

データ・ポンプでは、複数のワーカー・プロセスを採用し、それらをパラレルに実行して、ジョブのパフォーマンスを向上させることができます。PARALLELパラメータを使用して、現状の環境で最大限の効果を得る並列度を設定します。たとえば、本番システムへのジョブの影響を制限する場合、データベース管理者(DBA)は並列度を制限する必要があります。並列度は、ジョブの実行中いつでも再設定できます。たとえば、運用時間中は特定のジョブの並列度が2に制限されるようにPARALLELを2に設定し、非運用時間中は8に再設定することができます。並列度の設定は、マスター・プロセスによって施行され、マスター・プロセスによって、1回の操作でデータおよびメタデータの処理を実行するワーカー・プロセスに、実行対象の処理が割り当てられます。これらのワーカー・プロセスは、パラレルで動作します。並列度を設定する場合の推奨事項は、エクスポートのPARALLELおよびインポートのPARALLELパラメータの説明を参照してください。


注意:

並列度を調整する機能は、Oracle DatabaseのEnterprise Editionでのみ使用可能です。

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

ワーカー・プロセスによって、メタデータおよび表データがアンロードおよびロードされます。また、インポート中には、これらによって索引が再作成されます。これらの操作の一部(表データのアンロードおよびロード、索引の再作成およびパッケージ本体のロード)は、パラレルに実行できます。他のすべての操作は逐次実行されます。ワーカー・プロセスは、コマンドライン・パラメータPARALLELに指定した値と同数になるまで必要に応じて作成されます。アクティブなワーカー・プロセスの数は、ジョブの存続期間中いつでも再設定できます。ワーカー・プロセスは、Oracle Real Application Clusters(Oracle RAC)環境内の様々なノードで起動できます。


注意:

Oracle DatabaseのStandard Editionでは、PARALLELの値は1に制限されています。

非常に大きい表またはパーティションをロードまたはアンロードするタスクがワーカー・プロセスに割り当てられた場合、パラレル実行を最大限に利用できるように、外部表によるアクセス方法が使用されることがあります。その場合、ワーカー・プロセスはパラレル実行コーディネータになります。実際のロードおよびアンロード処理は、Oracle RAC環境内の使用可能なプロセスのプールから割り当てられたパラレルI/Oの実行プロセス(スレーブとも呼ばれる)間で分割されます。


参照:


ジョブの状態の監視

データ・ポンプ・エクスポートおよびインポート・クライアント・ユーティリティでは、ロギング・モードまたは対話方式コマンド・モードのいずれでも、ジョブに接続できます。

ロギング・モードでは、ジョブの実行中に、そのジョブの詳細な状態がリアルタイムで自動的に表示されます。表示される情報には、ジョブおよびパラメータの説明、処理されるデータ量の推定、現在の操作または処理中のアイテムの説明、ジョブで使用されるファイル、発生したエラーおよび最終的なジョブの状態(停止または完了)があります。


参照:

  • コマンドライン・エクスポートでの状態表示の頻度を変更する方法については、エクスポートの「STATUS」パラメータを参照してください。

  • コマンドライン・インポートでの状態表示の頻度を変更する方法については、インポートの「STATUS」パラメータを参照してください。


対話方式コマンド・モードでは、ジョブの状態をリクエストに表示できます。表示される情報には、ジョブの説明および状態、現在の操作または処理中のアイテムの説明、書込み中のファイルおよび累積的な状態があります。


参照:

  • 対話方式の「STATUS」エクスポート・コマンド

  • 対話方式のインポートの「STATUS」コマンド


オプションで、ジョブの実行中にログ・ファイルの書込みを行うこともできます。ログ・ファイルには、ジョブの進捗状況のサマリーが記録され、ジョブの実行中に発生したエラーがリストされます。また、ジョブの完了状態も記録されます。


参照:

  • エクスポート・ログ・ファイルのファイル指定を設定する方法については、エクスポートの「LOGFILE」パラメータを参照してください。

  • インポート・ログ・ファイルのファイル指定を設定する方法については、インポートの「LOGFILE」パラメータを参照してください。


ジョブの状態を判断したり、データ・ポンプ・ジョブについての情報を表示するには、DBA_DATAPUMP_JOBSビュー、USER_DATAPUMP_JOBSビューまたはDBA_DATAPUMP_SESSIONSビューを問い合せる方法もあります。これらのビューの説明は、『Oracle Databaseリファレンス』を参照してください。

ジョブの実行状況の監視

表データの転送を行うデータ・ポンプ操作(エクスポートおよびインポート)では、ジョブの進捗状況(単位は、転送された表データのメガバイト数)を示す動的パフォーマンス・ビューV$SESSION_LONGOPSのエントリが保持されます。このエントリは、転送の推定サイズを含み、実際に転送されたデータの量が反映されるように定期的に更新されます。

パラメータCOMPRESSIONENCRYPTIONENCRYPTION_ALGORITHMENCRYPTION_MODEENCRYPTION_PASSWORDQUERYおよび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に対応)から0203の順で、必要に応じて作成されます。PARALLELパラメータの現行の設定で指定されたすべてのプロセスをアクティブにできるように、十分な数のダンプ・ファイルが作成されます。FILESIZEパラメータで指定した最大サイズに達したためにダンプ・ファイルが一杯になると、ダンプ・ファイルはクローズされ、新しく生成された名前を持つ新しいダンプ・ファイルが、それにかわるファイルとして作成されます。

複数のダンプ・ファイル・テンプレートが提供されている場合、これらのテンプレートは、ラウンドロビン法によるダンプ・ファイルの生成に使用されます。たとえば、並列度6のジョブに、expa%Uexpb%Uおよびexpc%Uがすべて指定された場合、expa01.dmpexpb01.dmpexpc01.dmpexpa02.dmpexpb02.dmpおよびexpc02.dmpが初期ダンプ・ファイルとして作成されます。

インポートおよびSQLFILE操作では、ダンプ・ファイル指定expa%Uexpb%Uおよびexpc%Uを指定した場合、ダンプ・ファイルexpa01.dmpexpb01.dmpおよびexpc01.dmpをオープンすると操作が開始されます。マスター表は複数のダンプ・ファイルにまたがることができます。したがって、マスター表のすべての部分が検出されるまで、ダンプ・ファイルは、置換変数の増加および新しいファイル名(expa02.dmpexpb02.dmpexpc02.dmpなど)の検索を行うことによって、オープン状態を継続します。ダンプ・ファイルが存在しない場合は、エラーとなったダンプ・ファイル指定の置換変数の増加が中止されます。たとえば、expb01.dmpおよびexpb02.dmpは検出され、expb03.dmpは検出されなかった場合、expb%U指定を使用したファイルの検索は中止されます。マスター表全体が検出されると、その表を使用して、ダンプ・ファイル・セット内のすべてのダンプ・ファイルの位置が特定されているかどうかを確認できます。

異なるデータベース・リリース間でのデータの移動

ほとんどのデータ・ポンプ操作はサーバー側で実行されるため、COMPATIBLE以外のリリースのデータベースを使用する場合は、そのリリース情報をサーバーに提供する必要があります。指定しない場合は、エラーが発生することがあります。リリース情報を指定するには、VERSIONパラメータを使用します。


参照:


データ・ポンプ・エクスポートおよびデータ・ポンプ・インポートを使用して、リリースが異なるデータベース間でデータを移動する場合は、次の点に注意してください。

  • 現在のデータベース・バージョンより古いデータベース・バージョンを指定する場合は、特定の機能を使用できないことがあります。たとえば、VERSION=10.1を指定した場合に、ジョブに対してデータ圧縮も指定してあるとエラーが発生します。これは、Oracle Database 10gリリース1(10.1)では圧縮がサポートされていないためです。

  • データ・ポンプのエクスポートで、現在のデータベース・リリースより古いデータベース・リリースを指定すると、その古いリリースのデータベースにインポート可能なダンプ・ファイル・セットが作成されます。ただし、そのダンプ・ファイル・セットには、古いデータベース・リリースでサポートされていないオブジェクトは含まれません。

  • データ・ポンプ・インポートは、常に、古いリリースのデータベースで作成されたダンプ・ファイル・セットを読み込むことができます。

  • データ・ポンプ・インポートは、現在のデータベース・リリースより新しいデータベース・リリースで作成されたダンプ・ファイル・セットを読み込むことができません(ただし、読み込むダンプ・ファイル・セットが、VERSIONパラメータをターゲット・データベースのリリースに設定して作成されている場合は除きます)。したがって、ダウングレードを行う場合は、VERSIONパラメータをターゲット・データベースのリリースに設定して、データ・ポンプのエクスポートを実行するようにしてください。

  • データ・ポンプ操作がネットワーク・リンクを介して行われる場合、ソース・データベースとターゲット・データベースのバージョンの差違が2バージョン以下である必要があります。たとえば、一方のデータベースがOracle Database 12cの場合、他方のデータベースは12c、11gまたは10gである必要があります。データ・ポンプがチェックするのはメジャー・バージョン番号のみ(10g、11g、12cなど)で、具体的なリリース番号(12.1、10.1、10.2、11.1、11.2など)ではありません。

  • Oracle Database 11g (11.2.0.3)データベースの全体モード・エクスポートでは、ターゲット・データベースがOracle Database 12cリリース1 (12.1)以上の場合、データ・ポンプのVERSION=12パラメータを指定できます。

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データがエクスポートされて、アーカイブ・メタデータが削除されます。この例では、VERSION11.1以上に設定されていると、SecureFiles LOBは、標準のSecureFiles LOBになります。ただし、VERSION11.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データを含むエクスポートおよびインポート・ジョブでは、ジョブが正常に完了するかどうかは次の要因に依存します。

データベースのタイムゾーン・ファイルのバージョンを識別するには、次の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管理者ガイド』を参照してください。


全体トランスポータブル・モード

全体トランスポータブル・エクスポートおよびインポートがサポートされるのは、ソース・データベースが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列は、ターゲットのタイムゾーン・ファイルのバージョンに変換されます。


参照:


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キャラクタ・セットでは、zZの前にあるため、part_midパーティションのすべての行が、part_lowパーティションに移行します。希望する結果を得るには、partlist表の所有者は、インポート後に表を再パーティション化する必要があります。

DDL

エクスポート・ユーティリティは、エクスポート・システムのデータベース・キャラクタ・セットを使用してダンプ・ファイルを書き込みます。

インポート・システムのデータベース・キャラクタ・セットがエクスポート・システムのデータベース・キャラクタ・セットと異なる場合にのみ、ダンプ・ファイルのインポート時にDDLのためにキャラクタ・セット変換が必要です。

キャラクタ・セット変換によるデータの損失を最小限にするには、インポートのデータベース・キャラクタ・セットがエクスポートのデータベース・キャラクタ・セットのスーパーセットであることを確認します。

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

インポートが実行されるシステムで7ビット・キャラクタ・セットを使用し、8ビット・キャラクタ・セットのダンプ・ファイルをインポートすると、一部の8ビット・キャラクタは同等の7ビットに変換されることがあります。これが発生した場合の目印として、アクセント記号が付いている文字からアクセントが消去されます。

この不要な変換を回避するため、エクスポート・データベースとインポート・データベースで同じキャラクタ・セットを使用していることを確認してください。

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

インポート・データベースのキャラクタ・セットに同等の文字がないエクスポート・ファイル中の文字は、変換時にデフォルトの文字に置換されます。インポート・データベースのキャラクタ・セットは、デフォルトの文字を定義します。

DDLの変換中にインポート・システムで置換文字を使用する必要がある場合、警告メッセージが表示され、システムは変換されたDDLをロードしようと試みます。

ユーザー・データの変換中にインポート・システムで置換文字を使用する必要がある場合、デフォルトの動作として、変換されたデータがロードされます。ただし、置換文字を使用して変換されたユーザー・データの行を拒否するようにインポート・システムに指示することが可能です。詳細は、インポートの「DATA_OPTIONS」パラメータを参照してください。

100%完全に変換されるためには、インポート・データベースのキャラクタ・セットは、エクスポート・ファイルを生成するために使用されるキャラクタ・セットのスーパーセットであるか、それと同等である必要があります。


注意:

エクスポート・システムのデータベース・キャラクタ・セットがインポート・システムのものと異なる場合、ジョブの開始時に、データベース・キャラクタ・セットの内容を示す情報メッセージがインポート・システムに表示されます。

インポート・データベースのキャラクタ・セットがエクスポート・ファイルを生成するために使用されたキャラクタ・セットのスーパーセットではない場合、キャラクタ・セット変換によってデータ損失が発生する可能性があることを示す警告がインポート・システムに表示されます。