質問: y の形式で行っています。
回答: 移行元が8iだからデータパンプは使えないんですね。 impだと時間がかかりますね。 テーブルサイズは、件数で決まるものではなく、「レコード件数×レコード長」なので、 4000万件のテーブルよりも400万件のテーブルのほうがデータ量で上回っていてもおかしくはないです。長大な文字列型を有していたり、列数が非常に多かったりなどすると、やはり時間はかかります。 対策1. 以下のパラメータを追加 recordlength=65535 buffer=20971520 (あと、commit=nでもいいと思います) 対策2. もしdbがarchive logモードであったならば、 インポート前に、dbをno archive logモードにし、インポート完了後にarchive logモードに戻す。 (redo書き出しもオーバヘッドになりますので) 他には、当該テーブルに多数(もしくは長大な)インデックスが定義されているか、トリガーが定義されていることが考えられます。 対策3. 当該テーブルのインデックスをdropしておき、 以下のパラメータを追加してインポート。 indexes=n インポート完了後にcreate indexする。 対策4. (当該テーブルにトリガーが定義されていて、インポート時に起動しなくて良い場合) インポート前に、トリガー無効化 alter table 当該テーブル disable all triggers; インポート後にトリガー有効化 alter table xxxxx enable all triggers; こんなところかなと思います。 あとは、awrを使ってそれぞれのインポート中の時刻をfrom・toに指定して、レポーティングすると、何にどれだけ時間がかかったのか分かると思います。awrはoracle enterprise managerから起動できますので、トライしてみると良いです。(diagnostics packライセンスが要りますが)