O
O
r
r
a
a
c
c
l
l
e
e
D
D
a
a
t
t
a
a
b
b
a
a
s
s
e
e
1
1
0
0
g
g
D
D
a
a
t
t
a
a
P
P
u
u
m
m
p
p
:
:
超
超高
高速
速デ
デー
ータ
タ移
移動
動ユ
ユー
ーテ
ティ
ィリ
リテ
ティ
ィの
の基
基盤
盤
George H. Claborn, Oracle Corporation
Data Pump の概要
Data Pump は、非常に高速に、データとメタデータを Oracle Database にロード、アンロードできる Oracle Database 10g の 新機能です。この機能により、ロードまたはアンロードの複数のパラレル・ストリームを自動的に管理、スケジュールし て、最大のスループットを得ることができます。Data Pump のインフラストラクチャは、PL/SQL パッケージ
DBMS_DATAPUMP でコールできます。このように、カスタム・データ移動ユーティリティは、Data Pump を使用して構 築できます。Oracle Database 10g には、これらのユーティリティのうち、新コマンド・ラインのエクスポートおよびイン ポート・クライアント（expdp および impdp）、Web ベース Enterprise Manager エクスポート、インポート・インタフェー ス、および複合データ・マイニング・モデル移動用カスタム・インタフェースの 4 つが実装されています。Data Pump は、 Streams-based Replication、Logical Standby および Transportable Tablespaces など、Oracle サーバーのその他のいくつかの重 要機能の基盤でもあります。 多くの顧客からは、Data Pump に対する要望として「時は金なり。せめて、多量のデータをより速くエクスポート、イン ポートできるようにしてほしい」とたびたびいわれます。この言葉をオラクル社は、深く受け止めました。Data Pump 使 用では、ほとんどの場合、大量のエクスポートおよびインポート動作の経過時間を大幅に削減し、データ集約型の場合に は 2 倍を超える時間の短縮ができます。顧客からは、パフォーマンス増大に対する要望の他に多くの要請がありました。 その結果、Data Pump ベースのエクスポートおよびインポート・クライアントでは、チェックポイント再開、ジョブ・サ イズ予測、極めて柔軟性の高い細粒オブジェクトの選択、あるインスタンスを別のインスタンスから直接ロード、および 詳細ジョブ・モニタリングなど多くの新機能に加えて、元のエクスポートおよびインポートのすべての機能性がサポート されるようになっています。
Data Pump は、Oracle Database 10g の一体型機能であり、すべての構成に利用することができます。しかし、複数の並列 処理は、Enterprise Edition でのみ利用可能です。
この文書には、まず Data Pump のアーキテクチャの概要を、次に主な機能をベスト・プラクティスと合わせて説明した後、 元のエクスポートおよびインポート機能と簡単に比較します。
アーキテクチャ
マスター・テーブル
Data Pump 動作の心臓部は、マスター・テーブルです。これは、Data Pump のジョブを実行するユーザーのスキーマに作 成される表で、ジョブに関するすべてのファセットを維持するディレクトリとなっています。ファセットとは、エクスポー トまたはインポートされる各オブジェクトおよびダンプファイル・セット内のこれらのオブジェクトの位置の現在の状態、 ジョブのユーザー提供パラメータ、各ワーカー・プロセスの状態、ダンプファイルの現在のセット、再開情報などのこと です。
マスター・テーブルは、ファイル・ベースのエクスポート・ジョブ実行中に構築され、最終段階でダンプファイルに書き 込まれます。 これとは逆に、マスター・テーブルを現在のユーザーのスキーマにロードする処理は、ファイル・ベースのインポート動 作の最初の段階であり、インポートされたすべてのオブジェクトの作成に順番を割当てに使用されます。 エクスポート中、マスター・テーブルは（書き込まれた他のオブジェクトでは可能な）ファイルのスパンはできません。 ダンプファイル・サイズが FILESIZE パラメータで制限されている場合は、マスター・テーブルが十分に入るサイズにす る必要があります。基準点として、1 万個の表を含め約 40 万個のオブジェクトがあるデータベースでは、サイズ 189 MB のマスター・テーブルが作成されます。 マスター・テーブルは、計画済または計画されていないジョブが停止したときに Data Pump を再開する機能として重要で す。再開するときにジョブを構成する各オブジェクトの状態がマスター・テーブルによって維持されるため、Data Pump には、どのオブジェクトが現在処理されているか、およびその処理が正しく終了されたかがわかります。
プロセス構造
Data Pump のジョブの構成には、様々なプロセスがあります。プロセス作成順に説明していきます。クライアント・プロセス – Data Pump の API にコールを行います。前述のとおり、Oracle Database 10g には、この API の 4 つのクライアントが実装されています。このペーパーでは、新しいエクスポートおよびインポート・クライアントの expdp と impdp についてのみ説明します。新しいエクスポートとインポートは、元のエクスポートおよびインポートと非 常によく似ていますが、後述するとおり、機能がかなり強化されています。Data Pump は Oracle Database サーバーに完全 統合されているため、1 度ジョブが実行されると、クライアントは何も要求されません。監視および制御に必要であれば、 複数のクライアントからジョブにアタッチ、デタッチできます。
シャドウ・プロセス – クライアントが Oracle サーバーにログ・インするときに作成される標準 Oracle シャドウ・プロ セス（またはフォアグラウンド・プロセス）です。このシャドウ・プロセスでは、Data Pump API 要求が使用されます1。
DBMS_DATAPUMP.OPEN 要求を受け取るとすぐに、主としてマスター・テーブルの作成、様々なプロセス間の通信に使 用される AQ キューの作成、およびマスター制御プロセスの作成からなるジョブが作成されます。一旦ジョブが実行され ると、影のメイン・タスクはクライアントからの GET_STATUS 要求処理による構成となります。クライアントがデタッ チすると、影も消えます。 マスター制御プロセス（MCP）– ジョブ 1 つにつき MCP が 1 つあり、名前のとおり、MCP により、Data Pump のジョブ の実行と順番の割当を制御します。ジョブは、様々なメタデータおよびデータ・アンロードまたはロード・フェーズに区 分され、MCP では、作業要求が現在のフェーズに適したワーカー・プロセスに渡されます。MCP は、ジョブ実行中は、 主にこの作業ディスパッチ・ループに存在します。MCP によって、データまたはメタデータのアンロード・プロセスか ら要求されるとおりに、セントラル・ファイル管理デューティの実行、アクティブ・ダンプファイル・リストの維持、お よびファイルの断片引渡しも行われます。MCP には、<instance>_DMnn_<pid>の書式のプロセス名がついています。MCP では、マスター・テーブル内のジョブの状態、ジョブ内容、再開およびダンプファイル情報を維持します。 1 データ・ポンプの公開 API は、PL/SQL パッケージ DBMS_DATAPUMP に具体化されています。詳細は、ここでは省略します。詳細な説明は、 『Oracle データベース 10g ユーティリティ・ガイド』および『提供の PL/SQL パッケージ』マニュアルを参照してください。
ワーカー・プロセス – START_JOB 要求を受け取ると同時に、MCP によって、PARALLEL パラメータ値が N となってい るワーカー・プロセスが作成されます。ワーカーは、主としてメタデータとデータのロード、アンロードを行う MCP か ら要求されるタスクを実行します。ワーカーは、多数の表からなるマスター・テーブルに、オブジェクト行を維持します。 データベース・オブジェクトがアンロードまたはロードされると、これらの行には保留、完了、失敗など、オブジェクト の現在の状態が書き込まれて更新されます。ワーカーは、表、索引、ビューなど、現在処理されているオブジェクト・タ イプを記述する型完了行も維持します。これらは再開処理の間に使用されます。ワーカーには、<instance>_DMnn_<pid> の書式の名前がついています。 パラレル問合せ（PQ）プロセス – 表またはパーティションのロードまたはアンロードするためのデータ・アクセス方法 として外部テーブル（ET）を選択すると、ロードまたはアンロードが割り当てられているワーカー・プロセスによって N 個のパラレル問合せプロセスが作成され、ワーカー・プロセスは問合せコーディネータとして実行します。これらの処 理は、Oracle サーバーのパラレル実行アーキテクチャを利用する標準パラレル実行スレーブで、パーティション内のロー ド、アンロードを可能にします。RAC では、パラレル問合せプロセスは、Data Pump のジョブが開始されたインスタンス 以外のインスタンスで作成できます。このように記述されたその他のプロセスは、すべて最初のインスタンスで作成され ます。
データの移動
ダイレクト・パス（DP）と外部テーブルの 2 つのアクセス方法がサポートされています。ダイレクト・パスは外部テー ブルよりも高速ですが、パーティション内の並列処理はサポートされません。したがって、外部テーブルは非常に大きな 表またはパーティションをロードまたはアンロードする場合に選択できます。どちらにも、他の方法を必要とする制限が あります。たとえば、アクティブ参照制限または全体的索引でロードされた表は、外部テーブルでロードする必要があり ます。データ・タイプ LONG の列がある表は、ダイレクト・パスでロード、アンロードする必要があります。どちらの 方法でも、元のエクスポートのデータ表現より約 15%小さいコンパクトなバイナリ・ストリーム・フォーマットで、ダ ンプファイル・セットへ書込みします。メタデータの移動
メタデータ API（DBMS_METADATA）は、メタデータのロード、アンロードをすべて行うワーカー・プロセスで使用さ れます。 データベース・オブジェクトの定義は、元のエクスポートで実行された SQL DDL ではなく XML 文書として抽出されダ ンプファイル・セットに書き込まれます。これにより、インポート時に DDL を作成する場合の柔軟性が向上し XSL-T 変 換が適用できます。たとえば、オブジェクトの所有権、格納特性および表領域レジデンスは、インポート中に簡単に変更 できます。XML では、DDL よりも多くのダンプファイル領域が占有されますが、インポートまで DDL の作成を遅らせ て得られる柔軟性の価値は、十分にあります。メタデータは、一般に、ダンプファイル・セットのデータによって小型化 されるため、ダンプファイル・セットは、バイナリ・ストリーム・サイズの減少によって、元のエクスポートで生成され るサイズ以下になります。 もう 1 つのポイント: 表のメタデータを表す XML は、ダンプファイル・セットに直接書き込まれるのではなく、マスター・ テーブルに格納されます。この処理は、いくつかのダウンストリーム動作での使用を目的として行われるため、複数の フェッチが回避できます。プロセス間通信
アドバンスト・キューイング（AQ）は、様々な Data Pump プロセス間での通信に使用されます。各ジョブには、次のよ うな 2 つのキューがあります。 コマンドおよび制御キュー: このキューは、すべてのプロセス（クライアント以外）で利用されます。すべての API コマンド、ワーク要求および応答、ファイル要求、およびログ・メッセージは、このキューで処理されます。 • • ステータス・キュー: このキューはシャドウ・プロセスのみで利用され、進行中のワークおよび MCP によって キューされたエラー・メッセージを受け取ります。MCP は、このキューの唯一のライターです。
ファイル管理
ファイル・マネージャは、分散型コンポーネントです。前述のとおり、新規ファイルの作成およびファイル・セグメント の割当は、集中的に MCP 内で行われます。しかし、各ワーカーおよびパラレル問合せプロセスで、ファイル・マネージャ へのローカル・プロセス要求を行って、領域、ファイル分割の読取り、バッファまたは更新進捗統計データの書込みが要 求されます。 ローカル・ファイル・マネージャで、要求がローカル処理できるかを決定し、処理できない場合は、その要求をコマンド と制御キューで MCP へ転送します。マスター・テーブル内でのファイル分割の読取りとファイル統計データの更新は、 ローカルで処理されます。バッファの書込みは一般にローカル処理されますが、より大きなファイル領域が必要な場合は MCP に要求することになります。 ディレクトリ管理すべてのダンプファイル・セット I/O は Oracle バックグラウンド・サーバー・プロセスで処理されるため、I/O を実行す る OS の主体 Oracle であって、ジョブを実行するユーザーではありません。これは、oracle が一般には特権アカウントで あるため、セキュリティのジレンマとなります。したがって、すべてのディレクトリ仕様は、DBA で設定された読取り 書込みを許可された Oracle ディレクトリ・オブジェクトで作成されます。たとえば、DBA で、次のようにディレクトリ をセットアップできます。 /private1/data/dumps という dmpdir1 ディレクトリを作成します。 dmpdir1 ディレクトリの読取り書込みを scott に許可します。 すると、SCOTT によって、expdp コマンド・ラインに次のようなダンプファイルの指定ができます。 expdp scott/tiger dumpfile=dmpdir1:scott.dmp
ファイル・サイズの管理可能性が FILESIZE パラメータによって制限されている場合は、多数のダンプファイルが作成で きます。ファイル・マネージャは、ファイル・ヘッダーに書き込まれた全体に固有の識別子と他の情報で、自動的にダン プファイル・セットの干渉性を維持します。インポートまたは SQL ファイル・ジョブは、ジョブのダンプファイル・セッ トの全要素が DUMPFILE パラメータ仕様に設定されるまで開始できません。
主要機能
この項では、Data Pump の主要な新機能のいくつかを簡単に説明します。パフォーマンス
Data Pump ベースのエクスポートおよびインポート動作は、一般に元のエクスポートおよびインポートよりも高速です。 Data Pump のダイレクト・パス・データ・アンロードの 1 スレッドは、元のエクスポートのダイレクト・パス・アンロー ドの約 2 倍の速度で処理されます。Data Pump のデータ・ロードの 1 スレッドの速度は、元のインポートより 15 倍から 45 倍速く、もちろん、Data Pump 動作は実行のパラレル・スレッドで指定できます2。パラレル・スレッドを動的に実行 中のジョブに追加や削除することで、そのジョブを変化する実行環境に合わせることができます。 エクスポート中、複数のワーカーがいる場合は、データおよびメタデータのアンロードは並列処理されます。 最も重要な要素 I/O 帯域幅 指定のパラレル・スレッドを確実に全部処理できる I/O 帯域幅にすることが重要です。帯域幅が十分でないと、パラレル・ スレッドを追加したときにパフォーマンスが下がる可能性があります。ダンプファイル・セットは、必ず、インスタンス のデータファイルを保持しているスピンドル、それ以外のスピンドルに配置してください。ワイルドカード・ファイルの サポートを使用すると、簡単に複数のスピンドルへ I/O をロードできます。たとえば、次のように指定します。 Dumpfile=dmpdir1:full1%u.dmp,dmpdir2:full2%u.dmp Dumpfile=dmpdir3:full3%u.dmp,dmpdir4:full4%u.dmp このように指定すると、4 つのディレクトリ・オブジェクトで指定された 4 つのディレクトリ全部に対してラウンドロビ ン方式で、full101.dmp、full201.dmp、full301.dmp、full401.dmp、full102.dmp、full202.dmp、full302.dmp という名前のファ イルが作成されます。 インストール・パラメータ ほとんど調整することなく、最大の Data Pump パフォーマンスが達成できます。初期化パラメータは、デフォルトにして ください。disk_asynch_io は TRUE、db_block_checksum は FALSE のままにしておいてください。Data Pump の AQ ベースの通信およびメタデータ API は両方とも、SGA をいくらか必要とします...必ず、shared_pool_size を十分な値に設定してください。 エクスポート中のメタデータ API およびインポート中のワーカー・プロセスは両方とも、ロールバック・セグメントを 消耗する可能性のある長い実行時間の問合せを実施することがあります。この問題は、多くの場合、多数のオブジェクト に影響を与えるジョブで発生します。セグメントは、必ず十分な大きさに設定してください。たとえば、40 万個のオブ ジェクトを含むデータベースのエクスポートおよびインポートには、それぞれのサイズが 750 MB のロールバック・セグ メントが 2 つ必要です。
メタデータ API メタデータのパフォーマンスは、元のエクスポートおよびインポートユーティリティと大体同じですが、柔軟性と拡張性 がかなり強化されています。しかし、ほとんどの動作はデータ移動に支配されているため、全体的には飛躍的な向上をと げたようにみえます。
ネットワーク・モード
Data Pump では、1 つのインスタンスを別のインスタンス（ネットワーク・インポート）から直接ロードすることや、リ モート・インスタンス（ネットワーク・エクスポート）をアンロードする機能がサポートされています。ネットワーク・ モードでは、どのプラットフォームでもサポートされないネットワーク・パイプではなく DB リンクを使用します。 ネットワーク・インポート中に、メタデータ API はリモート・ノードで実行され、オブジェクト定義が抽出され、抽出 されたオブジェクト定義は Data Pump のジョブが作成を実行しているローカル・インスタンスに送られます。データは、 次のような選択文として挿入により、フェッチ、ロードされます。Insert into foo (a,b,c,...) select (a,b,c,...) from foo@remote_service_name
これらの文には、ダイレクト・パス・エンジンにアクセスして最大パフォーマンスを得られるようにする両側のヒントが 含まれています。 ネットワーク・エクスポートで、読取り専用データベースをエクスポートする機能が有効にできます。マスター・テーブ ルの維持、キューに対するメッセージの書込み、および外部表の作成にはこのインスタンスに書込みを行う必要があるた め、Data Pump エクスポートは、読取り専用インスタンスでローカルで実行することはできません。ネットワーク・エク スポートによって、Data Pump ジョブが実行されているインスタンス上にダンプファイル・セットが作成され、ネットワー ク・インポートで行われるのと同様に、リモート・インスタンスからメタデータとデータが抽出されます。 ネットワーク・エクスポートによるデータ移動は、create as select@service スタイルの DML 文が必要なため、外部表で排 他的に行うことはできません。 いずれのネットワーク・モードでも、ネットワーク帯域幅がネックになると予想されます。パラレル設定では、ネットワー クは飽和されません。オラクル社の顧客の多くは、元のエクスポートおよびインポートを使用してネットワーク・パイプ にエクスポートを、もう一方にインポートを行って、一種のネットワーク・モードを実装することがわかりました。これ でエクスポートとインポート動作が重なって実行されるため、経過時間が短縮されます。ファイル・ベース・Data Pump 動作のパフォーマンスが大幅に改善されたため、ネットワーク・モードを使用すると、元のエクスポートとインポートよ り、インスタンス初期化の経過時間が大幅に短縮されているのかどうかはっきりしません。
再開
停止された Data Pump のジョブはすべて、ジョブが停止している間にマスター・テーブルとダンプファイル・セットに障 害が発生していなければ、データを失うことなく再開できます。ジョブがクライアントの STOP_JOB コマンドで自発的 に停止された場合であっても、破損、停電などで非自発的に停止された場合であっても関係ありません。マスター・テー ブルには十分なコンテキストが維持されているため、再開場所がわかります。ATTACH=<job name>パラメータで、クラ イアントが停止したジョブにアタッチして、インタラクティブ START コマンドでジョブを再開できます。 インポート中に、特定のオブジェクトによって、オブジェクトが進まないという予期しない問題が繰返し発生することが あります。START=SKIP_CURRENT と指定すると、現在のオブジェクトをスキップして次のオブジェクトに進むため、 処理ができます。細粒(Fine-Grained)オブジェクト選択
元のエクスポートとインポートでは、選択できたのは索引、トリガー、許可、および制限のみでした。Data Pump のジョ ブでは、様々なクライアントのパラメータによって、実質的にどのようなオブジェクト・タイプであっても、また 1 タイプ内のオブジェクトのどんなサブセットであっても含めたり除外したりすることができます。 EXCLUDE EXCLUDE パラメータを使用すると、あらゆる型のデータベース・オブジェクトをエクスポートまたはインポート動作か ら除外できます。オプションの名前クオリファイアを使用すると、指定の各オブジェクト・タイプをより細かく選択でき ます。たとえば、パラメータ・ファイルで次の 3 つのラインを指定します。 Exclude=function Exclude=procedure Exclude=package:"like 'PAYROLL%' " これで、PAYROLL で始まる名前の機能、プロシージャおよびパッケージがすべてジョブから除外されます。 INCLUDE INCLUDE パラメータには、動作の中の指定されたオブジェクト・タイプとオブジェクトだけが含まれています。たとえ ば、前述の 3 つの指定が完全データベース・エクスポートの INCLUDE パラメータだとすると、PAYROLL で始まる名前 の機能、プロシージャおよびパッケージのみがダンプファイル・セットに書き込まれます。 CONTENT CONTENT パラメータを使用すると、現在の動作を、メタデータのみ、データのみ、あるいはその両方を要求できます。 元のエクスポートの ROWS=N パラメータは content=metadata_only に相当し、content=data_only には相当し ません。QUERY
QUERY パラメータは、元のエクスポートと同じように動作しますが、次の 2 つの点が強化されています。
1. 表の名前で識別を行って、その表のみに適用できます。
監視および予測
この他に顧客からは、もっと高性能のより詳細に監視できる機能を求める声が寄せられました。クライアントがログ・ファ イルにプリントする標準進捗状況およびエラー・メッセージに加えて、新しいクライアント・インタラクティブ・コマン ドの STATUS によって、全体の進捗率、各ワーカー・プロセスの状態、処理中の現在のオブジェクトおよび各オブジェ クトの進捗率など、詳細なジョブ情報が提供されます。また、詳細状態の自動更新は、手作業による要求ではなく、要求 間隔を秒単位で指定できます。 現在は各エクスポート・ジョブの開始には、アンロードする全データの大体の量を決定する予測フェーズも含まれていま す。デフォルトでは、この量を決定する方法として、現在割り当てられているブロック数をカウントしてパーティション のサイズを予測します。表が分析されていれば、より正確な予測を行う統計データも使用できます。これは、1) 消費さ れるダンプファイル領域の把握 2) 表のアンロードに必要なあらゆる情報を検索し、サイズの大きい順に順番をつける、 という 2 つを目的として行われます。これで、MCP によって、メタデータおよびデータを並列にアンロードするようス ケジュールできます。この予測フェーズに検索されたオブジェクトは表データ・オブジェクトと呼ばれます。それぞれの オブジェクトにはパーティションが、表がパーティション化されていない場合は表全体が描かれます。 0-N クライアントは実行中のジョブにアタッチできるため、作業中のジョブの開始、ジョブからのデタッチ、帰宅、リア タッチ、および夜間の監視ができます。新クライアント: EXPDP および IMPDP
新しいエクスポートおよびインポート・クライアントは、元のエクスポートおよびインポート・クライアントと同じにみ えますが、元のクライアント・パラメータには多くの矛盾があったため、パラメータに 100%の互換性がありませんでし た。ある概念がエクスポートとインポートの動作に適している場合は、必ず両方のパラメータが同じになっています。新 クライアントでも、次のようなより大きな機能をサポートしています。 インタラクティブ・コマンド・モード: Control キーを押しながら C と入力すると、インタラクティブ・コマンド・モード が呼び出され、export>または import>プロンプトが表示されます。このプロンプトから、ヘルプ、詳細なジョブの状態の 要求、監視パラメータの変更、ファイル（ワイルドカード要件を含む）のジョブのダンプファイル・セットに対する動的 追加、再開可能な状態でのジョブの停止、再開不能な状態でのジョブの停止、ジョブの並列処理程度の変更、ログ・モー ドに戻り進捗メッセージの受取りの継続またはクライアントの終了、およびジョブの実行を維持することができます。 動作のモードとして、完全、スキーマ、表、表領域、輸送可能表領域の各モードがすべてサポートされています。Data Pump および新しい expdp と impdp クライアントには、元のエクスポートとインポートの機能性が完全に上位集合されています 3。 フラッシュバックでは、特定の時間、現在のエクスポートとインポートがサポートされています。 WHERE 条項述語は、expdp と impdp の両方によって個々の表に適用できます。特権ユーザー（EXP_FULL_DATABASE または IMP_FULL_DATABASE いずれかのロールを持つユーザー）は、ジョブ が停止されても、他のユーザーが開始したジョブにアタッチしてジョブを制御できます。
3 例外: Oracle データベース 10g では、XML スキーマのエクスポートおよびインポートはデータ・ポンプのサポート対象ではありません。
その他の実行可能な機能
DDL変換 – オブジェクト・メタデータはダンプファイル・セットに XML として格納されているため、DDL をインポー ト中に形成しているときに（XSL-T 経由で）変換を適用するのは簡単です。Impdp では、次のようないくつかの変換機能 がサポートされます。REMAP_SCHEMA を使用すると、旧 FROMUSER / TOUSER 機能によってオブジェクト所有権を変 更できます。REMAP_TABLESPACE を使用すると、オブジェクトを 1 つの表領域から他の表領域に移動できます。これ により、表領域の定義も変更されます。REMAP_DATAFILE は、データベースを、ファイル・システム・セマンティク スが異なるプラットフォーム上で移動するのに便利です。TRANSFORM パラメータによって、DDL で格納条項が生成さ れないように指定もできます。これは、ターゲット・インスタンスの格納特性がソースの格納特性と非常に異なる場合に 便利です。 SQLファイル – impdp では、SQL ファイルの操作もできます。この場合は、データベース・オブジェクトを作成するの ではなく、同等の DDL がすぐに実行できる SQL スクリプトの形でファイル出力するにすぎません。組込みの接続文のみ がコメント文にされます。
TABLE_EXISTS_ACTION – 元のインポートでは、IGNORE=Y が指定されていると行を既存の表に追加できました。Impdp の TABLE_EXISTS_ACTION パラメータには、次の 4 つのオプションが用意されています。 1. SKIP: デフォルトです。表の存在がわかると、スキップされます。 2. APPEND: ターゲットの表のジオメトリに互換性がある場合、行を追加します。 3. TRUNCATE: その表は切り捨て、1) ジオメトリに互換性がある、2)切り捨てできる: その表が参照制限のターゲッ トの場合は切り捨てできない、などの条件と合致した場合、行がソースからロードされます。 4. REPLACE: 既存の表を削除してソースから表を作成しロードします。 CONTENT – この新しいパラメータは両方のクライアントに適用でます。このパラメータを使用すると、DATA_ONLY、 METADATA_ONLY または BOTH（デフォルト）を移動できるようになります。
VERSION – expdp では、サーバー・ベースの Data Pump に指定のバージョンと互換性のあるダンプファイル・セットを作 成するよう指示を与える VERSION パラメータがサポートされています。これは、将来、ダウングレードする場合の手段 となります。旧バージョンの Data Pump クライアントを実行する必要はありません（元のエクスポートでは必要でした）。 ENTERPRISE MANAGERでは、Data Pump に対する完全機能インタフェースがサポートされています。
Data Pump表示 – Data Pump には、多数のユーザーおよび DBA がアクセスして次のジョブの進捗状況を監視できるビュー があります。
DBA_DATAPUMP_JOBS: システム上のアクティブ・Data Pump のジョブのサマリーが表示されます。 USER_DATAPUMP_JOBS: 現在のユーザーのアクティブ・Data Pump のジョブのサマリーが表示されます。
DBA_DATAPUMP_SESSIONS: 現在 Data Pump のジョブにアタッチされているすべてのセッションが表示されます。 V$SESSION_LONGOPS: 1 つの行が、Data Pump のそれぞれのアクティブ・ジョブの進捗状況を示すビューに維持されて
元のエクスポートおよびインポート
元のエクスポートおよびインポートはいずれも、Oracle Database 10g に実装された状態で出荷されます。 元のインポートは永久サポートされ、Oracle 5 から Oracle9i までの所期のバージョンからダンプファイルをイン ポートする手段が実装されています。元のダンプファイルおよび Data Pump ベースのダンプファイルには互換性 がないため、どちらのクライアントも他方のダンプファイルを読み取ることはできません。 •• 元のエクスポートは Oracle Database 10g に実装されているため、少なくとも Oracle9i に対応しますが、いずれは サポート対象からはずされます。Data Pump ベースのエクスポートが、進化するエクスポートの唯一のサポート 手段となります。Oracle Database 10g の新機能は、元のエクスポートではサポートされません。Oracle9i バージョ ンのエクスポートは、ダウングレードを目的とした場合にかぎりバージョン Oracle Database 10g で使用できます。 Oracle Database 10g バージョン後のバージョンでは、ダウングレードには、expdp の VERSION パラメータを使用 してください。
Data Pump と元のエクスポート/インポートとの相違点
この項には、まず Data Pump ベースのエクスポートおよびインポート実行時の主な相違点をいくつか紹介します。 Data Pump は、多量のデータがある大きなジョブを対象に設計されています。多量のデータがあるジョブを実行すると次 のことが予測されます。 • • • • • • 開始時間が長くなります。ジョブを実行するには、すべてのプロセスと通信インフラストラクチャを開始する必 要があります。これには約 10 秒かかりました。エクスポート開始時間には、MCP を使用してすぐに表のアンロー ドのスケジューリングが開始できるよう、表データ・オブジェクトすべてを検索して順番を割り当てる処理も行 われます。 Data Pump エクスポートで、マスター・テーブルをダンプファイル・セットに書き込み、ジョブ開始時にジョブ の終わりとインポートをマスター・テーブルに配置してロードする必要があります。この処理は通常 2、3 秒かかりますが、マスター・テーブルが非常に大きい場合は長くなります。ダイレクト・パスは、マスター・ テーブルのロードとアンロードに使用されます。 ダンプファイル・セットのサブセットをインポートすると、マスター・テーブルから関係のない行が削除されま す。サブセットがエクスポート・セットと比べて非常に小さいときは、必要な削除に多くの時間がかかります。 メタデータを抽出して作成するパフォーマンスは、元のエクスポートおよびインポートとほぼ同じです。DDL の 高速化は非常に難しい問題です。最も大きく改良された Data Pump のパフォーマンスは、データのロード、アン ロード時にそのパワーを発揮します。 ダンプファイルの XML メタデータは、エクスポートの DDL の約 7X の大きさで、Data Pump のデータ・ストリー ム・フォーマットは、エクスポートの行および列フォーマットより約 13%小さくなっています。gzip などのスタ ンドアロン圧縮ツールは、メタデータに支配されたダンプファイル上で非常に適切に動作します。 Data Pump は、あなたの要望にあったリソース集約型です。ジョブ当たりの経過時間の削減という要件が、一番 に設計に組み込まれています。Data Pump で、PARALLEL に設定したのと同じ CPU、メモリー、I/O 帯域幅およ びネットワーク帯域幅（ネットワーク・モードで）が消費されます。Data Pump を実行するユーザーは、マスター・テーブルの作成に十分な表領域を割り当てる必要があります。 多数のオブジェクトを含むジョブは、ロールバック構成であることを認識してださい。 クライアントによって表示される進捗メッセージは、元のクライアントで表示されるメッセージとは異なりますが、現在 処理されているオブジェクト・タイプを反映します。また、「すでに存在します」エラーにフラグを立てて、ジョブの終 わりに出る総エラー数に含めます。 ログ・ファイルは、export.log または import.log という名前で、デフォルトで生成されます。
結論
Data Pump は、非常に高速にデータおよびメタデータをロード、アンロードできる Oracle Database 10g からコールして実 行可能な新機能です。Data Pump のインフラストラクチャを完全に利用する新しいエクスポートおよびインポート・クラ イアント expdp と impdp は、今回のバージョンにも実装されています。これらの機能は、元のエクスポートおよびインポー トの完全に上位互換機能として提供されており、いずれはこの新機能である Data Pump に置き換えられます。
