検証10g新機能 その４
＜検証10g新機能 その４ ～Data Pump編～＞
ペンネーム：ベロ
それでは、早速Data Pumpによるデータのロード・アンロードについて検証していきたい
と思います。Data Pumpは10gからの新機能で、従来のExport/Importとは内部構造も全く
違います。
大きな違いは・・・。まぁー内部構造の細かい話は、後回しにして、皆さんがもっとも
興味を持たれている「本当に早いのか？」を見てみたいと思います。DBAの重要な仕事
のひとつにデータ移行がありますが、最近のテラバイト級のデータ移行（メンテナンス）
は時間と手間の掛かる作業です。これが、短時間で操作性も良ければ、どんなに仕事が
はかどる事か・・・。ということで、Data Pumpが夢のツールであることを信じて検証
してみたいと思います。
Data Pumpのスピードを比較するに当たって使用した環境は以下の通り。
— 環境 —
OS : Miracle Linux 2.4.9-e.9.30mlsmp
Memory : 1GB
CPU : 4
ORACLE : Enterprise Edition Release 10.1.0.2.0
比較対象は以下の操作
1．従来の Export によるデータのアンロード 2．従来の Export によるダイレクト・アンロード 3．Data Pumpによるアンロード 4．従来の Import によるデータのロード 5．Data Pumpによるロード
ではでは、Let’s Data Pump !!
1．従来の Export によるデータのアンロードの場合
$ cat exp.sh
exp tpc/tpc file=/opt/u01/app/oradata/pump_dir/exp_normal.dmp
owner=tpc log=/opt/u01/app/oradata/pump_dir/exp_normal.log
2．従来の Export によるダイレクト・アンロードの場合
$ cat exp_d.sh
exp tpc/tpc file=/opt/u01/app/oradata/pump_dir/exp_direct.dmp
owner=tpc log=/opt/u01/app/oradata/pump_dir/exp_direct.log direct=y
3．Data Pumpによるアンロード
やっとData Pumpが出てきました。まず、簡単な使用方法を見てみます。
Data Pumpは従来のExport/Importとは異なり、ダンプファイルすべてのI/Oは、起動
したクライアントプロセス（例えば、exp、imp、expdp、impdp等）ではなく、バック
グランドプロセス（ORACLE.EXE、oracle等）が処理します。（他にもData Pumpに関連
するプロセスがありますが詳細は後ほど）。ここで重要なのは、ダンプファイルは、
ORACLEから認識できる場所にしか作成できないということ。ORACLEに認識できる場所
とは、DIRECTORYオブジェクトということになります。
ではDIRECTORYオブジェクトを作成してみましょう。
SQL> conn / as sysdba SQL> create directory pump_dir as '/opt/u01/app/oradata/pump_dir'; SQL> grant read,write on directory pump_dir to tpc ;
上記SQLはSYSにてDIRECTORYオブジェクトを作成し、TPCユーザに読込み、書込み権限
を与えています。
ここで、やっとData Pumpによるデータのアンロードです。
$ cat exp_dp_p2.sh
expdp tpc/tpc directory=pump_dir dumpfile=exp_pump_p2.dmp schemas=tpc
logfile=exp_pump_p2.log parallel=2
logfile=exp_pump_p2.log parallel=2
「expdp」はData Pumpでの新Exportユーティリティで基本的に従来のExportユーティ
リティ「exp」と同等以上の機能を有しています。
注）今後のリリースでは、EXPコマンドはサポートされなくなる予定です。
・DIRECTORYパラメータはダンプファイル及びログファイルを作成するDIRECTORYオブ
ジェクト名を指定します。
・DUMPFILEパラメータは従来のFILEパラメータのように作成するダンプファイル名を
指定します。
・SCHEMASパラメータは従来のOWNERパラメータのように特定のスキーマを指定します。
・PARALLELパラメータはEnterprise Editionのみ有効なパラメータで、バックグラン
ドで動くワーカープロセスの数を指定します。
4．従来の Import によるデータのロード
$ cat imp.sh
imp tpc/tpc file=/opt/u01/app/oradata/pump_dir/exp_direct.dmp
log=/opt/u01/app/oradata/pump_dir/imp.log full=y
5．Data Pumpによるロード
このData Pumpによるデータのロードも基本的には3．のData Pumpによるデータ
のアンロードと仕組みは同じです。「impdp」は従来の「imp」と同等以上の機能
を有する新Importユーティリティです。
注）EXPコマンドとは違い、IMPコマンドは今後のリリースでもサポートされます。
$ cat imp_dp_p2.sh
impdp tpc/tpc directory=pump_dir dumpfile=exp_pump_p2.dmp schemas=tpc
logfile=imp_pump_p2.log parallel=2
以上の操作で実測した結果を示します。
============================================================================= 処理内容 時間（分） ファイルサイズ ----------------------------------------------- ---------- ------------------ 1．従来の Export によるデータのアンロード 47 19.86GB 2．従来の Export によるダイレクト・アンロード 32 18.69GB 3．Data Pumpによるアンロード 29 19.87GB 4．従来の Import によるデータのロード 63 5．Data Pumpによるロード 26 =============================================================================
この結果では、Data Pumpのロード・アンロードにおいて従来のexp/impに比べ性能が
向上していることが分かります。
しかし、ORACLE社が言うほど、びっくりする性能向上は見られませんでした。アンロー
ドに関しては、若干（誤差の範囲かも）の性能向上、ロードに関しては、約2．4倍の
性能向上です。
今回の環境だと、Oracleのデータファイルとダンプファイルが同じディスク上に存在し
ReadとWriteのI/Oがぶつかったことが性能向上を妨げたと考えられます。事実この時間
帯のディスクのビジー率は100%となっており、ディスクネックとなっていること分かり
ます。
来週は、Data Pumpの内部構造に触れつつ、更なるスピードアップを実現してみたいと
思います。
それでは、本格的に梅雨突入の茅ヶ崎より