検証10g新機能 その4

<検証10g新機能 その4 ~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

「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の内部構造に触れつつ、更なるスピードアップを実現してみたいと
思います。

それでは、本格的に梅雨突入の茅ヶ崎より