Oracle Data Pump(expdp / impdp)の parallel パラメータを使うと、エクスポート/インポートを複数のワーカープロセスで並列実行して処理時間を短縮できます。大規模データベースでは数時間かかる処理が数十分に短縮されることも珍しくありません。
しかし「parallel を指定したのにファイルが 1 つしかない」「パラレル度をいくつにすればいいのかわからない」「impdp でパラレルが効いていない」といった問題も多く発生します。
本記事では、parallel の基本から、%U によるファイル分割、パラレル度の決め方、パラレルが効くケース/効かないケース、実行中の動的変更、そしてcompression / NOLOGGING との組み合わせまで解説します。
この記事でわかること
・expdp / impdp の parallel パラメータの基本
・%U ワイルドカードによるダンプファイル分割(必須)
・パラレル度の決め方(CPU 数・テーブル数・I/O 帯域)
・パラレルが効くケースと効かないケース
・実行中にパラレル度を動的に変更する方法(attach)
・impdp パラレルの制約(1 テーブル内は並列化されない)
・compression / NOLOGGING との組み合わせ技
・expdp / impdp の parallel パラメータの基本
・%U ワイルドカードによるダンプファイル分割(必須)
・パラレル度の決め方(CPU 数・テーブル数・I/O 帯域)
・パラレルが効くケースと効かないケース
・実行中にパラレル度を動的に変更する方法(attach)
・impdp パラレルの制約(1 テーブル内は並列化されない)
・compression / NOLOGGING との組み合わせ技
parallel パラメータの基本
Shell(expdp パラレル)
# パラレル度 4 でスキーマをエクスポート
expdp hr/password \
directory=DP_DIR \
dumpfile=hr_export_%U.dmp \
logfile=hr_export.log \
schemas=HR \
parallel=4
# 結果: hr_export_01.dmp, hr_export_02.dmp, ... が生成される
Shell(impdp パラレル)
# パラレル度 4 でインポート
impdp hr/password \
directory=DP_DIR \
dumpfile=hr_export_%U.dmp \
logfile=hr_import.log \
schemas=HR \
parallel=4
%U ワイルドカードの必須ルール
parallel を使うなら %U は必須
dumpfile に %U を含めないと、ダンプファイルが 1 つしか作られず、パラレルの効果が得られません。%U は 01, 02, 03… と自動的に番号が振られるワイルドカードです。parallel=4 なら最大 4 個のファイルが生成されます。Shell(NG と OK)
# NG: %U がない → パラレルが実質的に効かない expdp hr/password dumpfile=export.dmp parallel=4 # → ファイルが 1 つのため、ワーカーが順番待ちになる # OK: %U でファイルを分割 expdp hr/password dumpfile=export_%U.dmp parallel=4 # → export_01.dmp, export_02.dmp, ... が並列に書き込まれる # 複数ファイルを明示的に指定する方法も可 expdp hr/password dumpfile=exp01.dmp,exp02.dmp,exp03.dmp,exp04.dmp parallel=4
| dumpfile 指定 | ファイル数 | パラレル効果 |
|---|---|---|
| export.dmp(%U なし) | 1 個 | ほぼなし(ボトルネック) |
| export_%U.dmp | parallel 数に応じて自動分割 | 最大限に効果あり |
| exp01.dmp,exp02.dmp,…(明示指定) | 指定した数 | 指定数まで並列 |
パラレル度の決め方
| 考慮要素 | 推奨パラレル度 | 説明 |
|---|---|---|
| CPU コア数 | コア数の 50%〜100% | CPU が飽和しない程度に。他の処理と共有する場合は 50% |
| テーブル数 | テーブル数以下 | テーブル数より多くしても各テーブルは 1 ワーカーで処理されるため無駄 |
| I/O 帯域 | ディスクの並列性能に依存 | SSD なら高パラレル可。HDD(回転ディスク)なら過剰並列は逆効果 |
| メモリ | ワーカーごとに PGA を消費 | 大きすぎると PGA 不足で ORA-04031 が発生する場合あり |
| ネットワーク(DB Link) | 低めに設定 | ネットワーク帯域がボトルネックになりやすい |
実践的な目安
・小規模(数 GB 以下):
・中規模(数十 GB):
・大規模(数百 GB 以上):
最初は控えめに設定し、CPU / I/O の使用状況を見ながら動的に調整するのが安全です。
・小規模(数 GB 以下):
parallel=2〜4・中規模(数十 GB):
parallel=4〜8・大規模(数百 GB 以上):
parallel=8〜16(CPU コア数を上限)最初は控えめに設定し、CPU / I/O の使用状況を見ながら動的に調整するのが安全です。
パラレルが効くケースと効かないケース
| ケース | パラレル効果 | 理由 |
|---|---|---|
| 大テーブルが複数ある | 高い | 各テーブルを別ワーカーが並列処理 |
| 1 つの巨大テーブルだけ | expdp: 高い / impdp: 低い | expdp は 1 テーブル内も並列分割可。impdp は 1 テーブルは 1 ワーカー |
| 小さいテーブルが大量 | 中程度 | テーブル切り替えのオーバーヘッドが発生 |
| LOB 列を含むテーブル | 低い | LOB は並列処理が制限される場合がある |
| テーブルが 1 つだけ(impdp) | 効果なし | impdp は 1 テーブルを複数ワーカーで並列処理しない |
impdp のパラレルは「テーブル間」の並列
expdp では 1 つの大きなテーブルのデータを複数ワーカーで並列にエクスポートできますが、impdp では 1 テーブルは 1 ワーカーで処理されます。つまり、テーブルが 1 つしかない場合、
expdp では 1 つの大きなテーブルのデータを複数ワーカーで並列にエクスポートできますが、impdp では 1 テーブルは 1 ワーカーで処理されます。つまり、テーブルが 1 つしかない場合、
parallel=4 にしても効果はありません。複数テーブルがある場合は、各テーブルを別ワーカーが並列にインポートします。実行中にパラレル度を動的に変更する
Data Pump のジョブ実行中に、パラレル度をリアルタイムで変更できます。処理開始後に CPU / I/O の余裕を見て調整する場合に便利です。
Shell(attach で接続してパラレル度を変更)
# 実行中のジョブに接続 expdp hr/password attach=SYS_EXPORT_SCHEMA_01 # 対話モードで以下を実行 Export> PARALLEL=8 # → ワーカー数が 4 → 8 に動的に増加 Export> PARALLEL=2 # → ワーカー数を 2 に縮小(負荷を下げたい場合) Export> STATUS # → 現在の進捗を確認
SQL(実行中のワーカー状況を SQL で確認)
-- Data Pump ワーカーの状態を確認
SELECT owner_name, job_name, operation, job_mode,
state, degree -- degree = 現在のパラレル度
FROM dba_datapump_jobs
WHERE state = 'EXECUTING';
-- ワーカープロセスの詳細
SELECT sid, serial#, program
FROM v$session
WHERE program LIKE '%DW%' -- DW = Data Pump Worker
OR program LIKE '%DM%'; -- DM = Data Pump Master
動的変更のユースケース
・夜間バッチ: 最初は
・負荷監視: CPU 使用率が高すぎたら
・見積もりミス: 想定より遅い場合にパラレル度を上げて挽回
・夜間バッチ: 最初は
parallel=2 で開始 → 他の処理が終わったら parallel=8 に増加・負荷監視: CPU 使用率が高すぎたら
parallel を下げる・見積もりミス: 想定より遅い場合にパラレル度を上げて挽回
compression / NOLOGGING との組み合わせ
Shell(パラレル + 圧縮)
# パラレル + 圧縮でエクスポート(高速 + 省スペース)
expdp hr/password \
directory=DP_DIR \
dumpfile=hr_compressed_%U.dmp \
logfile=hr_compressed.log \
schemas=HR \
parallel=4 \
compression=ALL
# compression=ALL: メタデータ + データの両方を圧縮
# ファイルサイズが 50%〜80% 削減される(データ内容による)
# 注意: Advanced Compression Option のライセンスが必要(DATA_ONLY 圧縮の場合)
Shell(パラレル impdp + NOLOGGING で高速インポート)
# インポート前にテーブルを NOLOGGING にする
-- ALTER TABLE hr.employees NOLOGGING;
# パラレルインポート + transform で NOLOGGING を強制
impdp hr/password \
directory=DP_DIR \
dumpfile=hr_export_%U.dmp \
logfile=hr_import.log \
schemas=HR \
parallel=4 \
transform=DISABLE_ARCHIVE_LOGGING:Y
# DISABLE_ARCHIVE_LOGGING: インポート時にアーカイブログを抑制
# (Oracle 12c 以降で利用可能)
# インポート後に LOGGING に戻す
-- ALTER TABLE hr.employees LOGGING;
| 組み合わせ | 効果 | 注意点 |
|---|---|---|
| parallel + compression | ファイルサイズ削減 + 並列書き込み | CPU 負荷増加(圧縮処理)。Advanced Compression ライセンス要 |
| parallel + NOLOGGING(impdp) | REDO ログ抑制で大幅高速化 | クラッシュ時に復旧不可。インポート後にフルバックアップが必要 |
| parallel + compression + NOLOGGING | 最高速の組み合わせ | CPU / ディスク / ライセンスの 3 条件を確認 |
ファイルサイズの制御
Shell(filesize でファイルサイズを制限)
# 1 ファイルあたり 2GB に制限(NFS やクラウドストレージの制約対策)
expdp hr/password \
directory=DP_DIR \
dumpfile=hr_export_%U.dmp \
logfile=hr_export.log \
schemas=HR \
parallel=4 \
filesize=2G
# 2GB を超えると自動的に次のファイル(%U の番号が進む)が作成される
# parallel=4 + filesize=2G → 最大数十ファイルになることもある
パラレル実行の監視
SQL(パラレル実行の監視クエリ)
-- Data Pump ジョブの進捗(パーセント)
SELECT sl.sid, sl.serial#,
sl.sofar, sl.totalwork,
ROUND(sl.sofar / NULLIF(sl.totalwork, 0) * 100, 1) AS pct_done,
sl.elapsed_seconds, sl.time_remaining
FROM v$session_longops sl
WHERE sl.opname LIKE 'SYS_EXPORT%' OR sl.opname LIKE 'SYS_IMPORT%'
ORDER BY sl.start_time DESC;
-- ワーカーの CPU / I/O 状況
SELECT s.sid, s.program,
st.value AS cpu_used
FROM v$session s
JOIN v$sesstat st ON s.sid = st.sid
JOIN v$statname sn ON st.statistic# = sn.statistic#
WHERE s.program LIKE '%DW%'
AND sn.name = 'CPU used by this session'
ORDER BY st.value DESC;
よくある問題と対処
| 問題 | 原因 | 対処法 |
|---|---|---|
| パラレルを指定したのにファイルが 1 つ | dumpfile に %U がない | dumpfile=export_%U.dmp を指定 |
| parallel=8 なのに 2 ワーカーしか動いていない | テーブル数が少ない / Enterprise Edition でない | parallel はテーブル数以下にする。Standard Edition ではパラレルに制限あり |
| I/O がボトルネックで逆に遅くなった | パラレル度が高すぎて I/O 飽和 | parallel を下げるか、ダンプファイルを別ディスクに分散 |
| ORA-39095: ダンプファイルが満杯 | ディスク容量不足 | filesize を小さくして %U で分割。または空き容量を確保 |
| パラレル impdp で 1 テーブルが遅い | impdp は 1 テーブル = 1 ワーカー | 仕様上の制約。テーブルをパーティション化すればパーティション並列は可能 |
Enterprise Edition vs Standard Edition
Data Pump の parallel は全バージョンで指定可能ですが、Standard Edition では並列処理に一部制限があります。大規模データで最大限のパフォーマンスが必要な場合は Enterprise Edition を推奨します。
Data Pump の parallel は全バージョンで指定可能ですが、Standard Edition では並列処理に一部制限があります。大規模データで最大限のパフォーマンスが必要な場合は Enterprise Edition を推奨します。
実務パターン集
パターン(1): 夜間バッチでのフルエクスポート
Shell
# 夜間バッチ: フルエクスポート(パラレル + 圧縮 + 日付付きファイル名)
expdp system/password \
directory=DP_DIR \
dumpfile=full_$(date +%Y%m%d)_%U.dmp \
logfile=full_$(date +%Y%m%d).log \
full=y \
parallel=8 \
compression=ALL
パターン(2): 大規模テーブルのエクスポート
Shell
# 10GB 超のテーブルをパラレルエクスポート
expdp hr/password \
directory=DP_DIR \
dumpfile=orders_%U.dmp \
logfile=orders_export.log \
tables=HR.ORDERS \
parallel=4 \
filesize=2G \
flashback_time="TO_TIMESTAMP(SYSDATE)"
パターン(3): 高速マイグレーション(expdp + impdp)
Shell
# 移行元でパラレルエクスポート
expdp system/password \
directory=DP_DIR \
dumpfile=migration_%U.dmp \
logfile=migration_exp.log \
schemas=HR,SALES,INVENTORY \
parallel=8 \
compression=ALL
# ダンプファイルを移行先に転送
# scp migration_*.dmp targetserver:/oracle/dpdir/
# 移行先でパラレルインポート
impdp system/password \
directory=DP_DIR \
dumpfile=migration_%U.dmp \
logfile=migration_imp.log \
parallel=8 \
transform=DISABLE_ARCHIVE_LOGGING:Y
よくある質問
Qparallel を指定しないとどうなりますか?
Aデフォルトは
parallel=1(シングルプロセス)です。1 つのワーカーが順番にテーブルを処理するため、大量データでは時間がかかります。Qparallel の上限はありますか?
A明確な上限はありませんが、CPU コア数を超えるパラレル度は非効率です。また、テーブル数より大きくしても余剰ワーカーは待機状態になります。実用的には
parallel=2〜parallel=16 の範囲が一般的です。Q%U で分割されたファイルを impdp でインポートするには?
Aexpdp と同じく
dumpfile=export_%U.dmp と指定します。impdp は %U に該当するファイルを自動的にすべて読み込みます。ファイル数を明示する必要はありません。Qparallel を増やしたのに速くなりません
A以下を確認してください。
(1)
(2) テーブル数が parallel 以上あるか(テーブルが少ないとワーカーが余る)
(3) ディスク I/O が飽和していないか(iostat / sar で確認)
(4) CPU が飽和していないか(top / mpstat で確認)
(1)
dumpfile に %U が含まれているか(ファイルが 1 つではボトルネック)(2) テーブル数が parallel 以上あるか(テーブルが少ないとワーカーが余る)
(3) ディスク I/O が飽和していないか(iostat / sar で確認)
(4) CPU が飽和していないか(top / mpstat で確認)
Qパラレルエクスポートしたファイルをシングルでインポートできますか?
Aはい。
parallel=4 で作成した %U ファイルを parallel=1(デフォルト)でインポートすることは可能です。ファイル数とパラレル度は独立しています。ただし当然シングルの方が遅くなります。Qcompression と parallel は同時に使えますか?
Aはい。
parallel=4 compression=ALL のように同時指定できます。圧縮処理は CPU を消費するため、CPU コア数に余裕がある場合に有効です。注意: compression=DATA_ONLY や compression=ALL にはAdvanced Compression Option のライセンスが必要です。compression=METADATA_ONLY はライセンス不要です。まとめ
Data Pump パラレル処理の要点をまとめます。
| やりたいこと | 設定 |
|---|---|
| パラレルエクスポート | expdp … parallel=N dumpfile=file_%U.dmp |
| パラレルインポート | impdp … parallel=N dumpfile=file_%U.dmp |
| ファイルサイズを制限 | filesize=2G(%U と組み合わせ) |
| 実行中にパラレル度を変更 | expdp … attach=JOB_NAME → PARALLEL=N |
| パラレル + 圧縮 | parallel=N compression=ALL |
| パラレル + REDO 抑制(12c+) | parallel=N transform=DISABLE_ARCHIVE_LOGGING:Y |
| パラレル度の目安 | CPU コア数の 50%〜100%、テーブル数以下 |
Data Pump の基本は「Data Pump の使い方完全ガイド」、バックアップ全体の高速化は「バックアップを高速化する方法」、圧縮の詳細は「エクスポート時に圧縮する方法」も併せて参照してください。

