【Oracle】impdpインポートが終わらない原因と対処法｜進捗確認・ロック解除・高速化テクニック

この記事で分かること

• impdpが遅い・終わらない7つの主な原因と早見表
• DBA_DATAPUMP_JOBSやV$SESSION_LONGOPSで進捗状況を確認する方法
• ロック競合の検出と解消（V$LOCK / V$LOCKED_OBJECT）
• インデックス・制約の除外でインポートを高速化するテクニック
• UNDO/TEMP表領域の不足を確認・拡張する方法
• PARALLELパラメータによる並列処理の最適化
• NOLOGGINGやCONTENT=DATA_ONLYなどの高速化オプション
• ハングしたジョブの強制終了と残存ジョブの削除方法

ポイント：まず「進捗状況の確認」で現在の状態を把握し、そこから原因を切り分けるのが効率的です。次のセクションから順に確認していきましょう。

SELECT
  owner_name,
  job_name,
  operation,
  job_mode,
  state,
  degree,
  attached_sessions
FROM dba_datapump_jobs
WHERE state NOT IN ('NOT RUNNING')
ORDER BY owner_name, job_name;

OWNER_NAME  JOB_NAME             OPERATION  JOB_MODE  STATE      DEGREE  ATTACHED
----------  -------------------  ---------  --------  ---------  ------  --------
SYSTEM      SYS_IMPORT_FULL_01   IMPORT     FULL      EXECUTING       1         1

SELECT
  sid,
  serial#,
  opname,
  target,
  sofar,
  totalwork,
  ROUND(sofar / totalwork * 100, 2) AS pct_done,
  elapsed_seconds,
  time_remaining
FROM v$session_longops
WHERE opname LIKE 'IMPORT%'
  AND sofar <> totalwork
ORDER BY start_time DESC;

SID  SERIAL#  OPNAME               TARGET        SOFAR  TOTALWORK  PCT_DONE  ELAPSED  REMAINING
---  -------  -------------------  -----------  ------  ---------  --------  -------  ---------
 45      301  IMPORT: SCHEMA       HR            18500      45000     41.11     1240        1775

読み方のポイント

• SOFAR / TOTALWORK：処理済み件数 / 全体件数
• PCT_DONE：進捗率（%）。この値が定期的に増えていれば正常に動作中
• TIME_REMAINING：推定残り時間（秒）。あくまで推定値なので参考程度
• このビューに行が表示されない場合は、長時間オペレーションとして登録されていないか、メタデータ処理フェーズの可能性がある

# ジョブ名を指定して再接続
impdp system/password attach=SYS_IMPORT_FULL_01

-- 現在の状態を確認（5秒間隔で更新）
Import> status

-- 一定間隔で自動更新（60秒間隔）
Import> status=60

Job: SYS_IMPORT_FULL_01
  Operation: IMPORT
  Mode: FULL
  State: EXECUTING
  Bytes Processed: 2,458,836,992
  Percent Done: 43
  Current Parallelism: 1
  Job Error Count: 0
  Dump File: /u01/backup/full_export.dmp
  Worker 1 Status:
    Instance ID: 1
    Instance name: orcl
    Process Name: DW00
    State: EXECUTING
    Object Schema: HR
    Object Name: EMPLOYEES_HISTORY
    Object Type: TABLE_DATA
    Completed Objects: 156
    Total Objects: 412
    Completed Rows: 8,234,100

ポイント：attachしてもジョブの実行には影響しません。ジョブはサーバー側で独立して実行されているため、クライアントのセッション切断で停止することはありません（ただし、ジョブ開始直後の初期化フェーズで切断すると失敗する場合があります）。

SELECT
  s.sid,
  s.serial#,
  s.program,
  s.status,
  s.event,
  s.wait_class,
  s.seconds_in_wait,
  s.sql_id
FROM v$session s
WHERE s.program LIKE '%DM%'
   OR s.program LIKE '%DW%'
ORDER BY s.sid;

-- ロック競合の確認（ブロッキングセッションの特定）
SELECT
  l1.sid           AS waiting_sid,
  l2.sid           AS blocking_sid,
  s2.username      AS blocking_user,
  s2.program       AS blocking_program,
  s2.sql_id        AS blocking_sql_id,
  l1.type          AS lock_type
FROM v$lock l1
JOIN v$lock l2
  ON l1.id1 = l2.id1
  AND l1.id2 = l2.id2
  AND l1.request > 0
  AND l2.lmode > 0
JOIN v$session s2
  ON l2.sid = s2.sid;

SELECT
  lo.session_id,
  lo.oracle_username,
  o.owner,
  o.object_name,
  o.object_type,
  lo.locked_mode,
  s.program,
  s.machine
FROM v$locked_object lo
JOIN dba_objects o
  ON lo.object_id = o.object_id
JOIN v$session s
  ON lo.session_id = s.sid
ORDER BY o.object_name;

注意

セッションをKILLすると、そのセッションで実行中のトランザクションはロールバックされます。本番環境で実行する場合は、対象セッションの内容を十分に確認してから実行してください。

-- ブロッキングセッションをKILL（SID, SERIAL#を指定）
ALTER SYSTEM KILL SESSION '128,45023' IMMEDIATE;

-- KILLが効かない場合は DISCONNECT を使用
ALTER SYSTEM DISCONNECT SESSION '128,45023' IMMEDIATE;

impdp system/password 
  directory=DATA_PUMP_DIR 
  dumpfile=full_export.dmp 
  logfile=import.log 
  transform=DISABLE_ARCHIVE_LOGGING:Y

DISABLE_ARCHIVE_LOGGING の効果

• テーブルとインデックスの作成時にNOLOGGING属性が自動的に付与される
• REDO LOG生成が大幅に削減され、I/O負荷が軽減される
• インポート完了後、テーブルのLOGGING属性は元に戻る
• ただし、NOLOGGING中にメディア障害が発生するとリカバリ不可になるため注意

# インデックスと制約を除外してインポート
impdp system/password 
  directory=DATA_PUMP_DIR 
  dumpfile=full_export.dmp 
  logfile=import.log 
  exclude=INDEX 
  exclude=CONSTRAINT

-- NOLOGGINGとPARALLELでインデックスを高速作成
CREATE INDEX idx_emp_dept_id ON employees(department_id)
  NOLOGGING
  PARALLEL 4;

-- 作成後にPARALLEL属性を元に戻す
ALTER INDEX idx_emp_dept_id NOPARALLEL;

-- LOGGING属性も元に戻す
ALTER INDEX idx_emp_dept_id LOGGING;

# インデックスのDDLだけをSQLファイルに出力
impdp system/password 
  directory=DATA_PUMP_DIR 
  dumpfile=full_export.dmp 
  sqlfile=index_ddl.sql 
  include=INDEX

-- UNDO表領域の使用状況を確認
SELECT
  tablespace_name,
  ROUND(used_space * block_size / 1024 / 1024, 2) AS used_mb,
  ROUND(tablespace_size * block_size / 1024 / 1024, 2) AS total_mb,
  ROUND(used_percent, 2) AS used_pct
FROM dba_tablespace_usage_metrics
WHERE tablespace_name LIKE '%UNDO%';

-- V$UNDOSTATで直近のUNDO使用量を確認
SELECT
  TO_CHAR(begin_time, 'HH24:MI:SS') AS begin_time,
  TO_CHAR(end_time, 'HH24:MI:SS') AS end_time,
  undoblks,
  txncount,
  maxquerylen,
  nospaceerrcnt
FROM v$undostat
WHERE ROWNUM <= 10
ORDER BY begin_time DESC;

-- UNDO表領域にデータファイルを追加
ALTER TABLESPACE UNDOTBS1 ADD DATAFILE
  '/u01/oradata/orcl/undotbs02.dbf'
  SIZE 2G
  AUTOEXTEND ON
  NEXT 512M
  MAXSIZE 8G;

-- 既存データファイルのAUTOEXTENDを有効化
ALTER DATABASE DATAFILE
  '/u01/oradata/orcl/undotbs01.dbf'
  AUTOEXTEND ON
  NEXT 512M
  MAXSIZE 8G;

-- TEMP表領域の使用状況を確認
SELECT
  tablespace_name,
  ROUND(tablespace_size / 1024 / 1024, 2) AS total_mb,
  ROUND(allocated_space / 1024 / 1024, 2) AS alloc_mb,
  ROUND(free_space / 1024 / 1024, 2) AS free_mb
FROM dba_temp_free_space;

-- TEMP表領域にテンポラリファイルを追加
ALTER TABLESPACE TEMP ADD TEMPFILE
  '/u01/oradata/orcl/temp02.dbf'
  SIZE 2G
  AUTOEXTEND ON
  NEXT 512M
  MAXSIZE 8G;

ポイント：インポート前にUNDO表領域とTEMP表領域のAUTOEXTENDが有効になっているか確認しておくと、途中でスペース不足に陥るリスクを軽減できます。特に大規模なダンプファイル（10GB以上）をインポートする場合は事前にチェックしておきましょう。

# 4並列でインポート
impdp system/password 
  directory=DATA_PUMP_DIR 
  dumpfile=full_export_%U.dmp 
  logfile=import.log 
  parallel=4

注意：PARALLELを使うにはダンプファイルも複数必要

PARALLELの効果を最大限に引き出すには、エクスポート時も同じ並列度でダンプファイルを分割しておく必要があります。単一のダンプファイルに対してPARALLELを指定しても、ワーカーは1つしか使えません。%Uをファイル名に含めると、連番でファイルが分割されます。

# エクスポート時も並列で分割ダンプファイルを作成
expdp system/password 
  directory=DATA_PUMP_DIR 
  dumpfile=full_export_%U.dmp 
  logfile=export.log 
  parallel=4 
  full=Y

-- データファイルごとのI/O統計を確認
SELECT
  name,
  phyrds    AS physical_reads,
  phywrts   AS physical_writes,
  avgiotim  AS avg_io_time_ms,
  maxiortm  AS max_read_time_ms,
  maxiowtm  AS max_write_time_ms
FROM v$filestat f
JOIN v$datafile d
  ON f.file# = d.file#
ORDER BY avgiotim DESC;

I/Oボトルネック時の対策

• ダンプファイルとデータファイルを別の物理ディスクに配置する
• 可能であればSSD / NVMeのストレージを使用する
• ASM（Automatic Storage Management）を使用している場合は、ディスクグループの冗長性を確認する
• PARALLELを増やすとI/O競合が悪化する場合があるため、段階的に値を調整する

impdp system/password 
  directory=DATA_PUMP_DIR 
  dumpfile=full_export.dmp 
  logfile=import.log 
  content=DATA_ONLY

# 既存データを削除してからインポート
impdp system/password 
  directory=DATA_PUMP_DIR 
  dumpfile=full_export.dmp 
  logfile=import.log 
  table_exists_action=TRUNCATE

ポイント：テーブル定義を変更する必要がなければ、TRUNCATEが最もバランスの良い選択です。REPLACEはテーブルのDROP&CREATEに加えてインデックスの再作成も行うため、最も時間がかかります。

-- FORCE LOGGINGの状態を確認
SELECT force_logging FROM v$database;

-- インポート前にFORCE LOGGINGを一時的に無効化
ALTER DATABASE NO FORCE LOGGING;

-- インポート完了後に元に戻す
ALTER DATABASE FORCE LOGGING;

注意

NO FORCE LOGGINGの状態でNOLOGGINGオペレーションを実行すると、メディア障害時にデータのリカバリができなくなります。インポート完了後は速やかにFORCE LOGGINGに戻し、RMANで全体バックアップを取得してください。Data Guard環境では特に注意が必要です。

# ネットワーク経由の直接インポート
impdp system/password 
  network_link=REMOTE_DB_LINK 
  schemas=HR 
  logfile=network_import.log

# ジョブにattach
impdp system/password attach=SYS_IMPORT_FULL_01

-- まず停止を試みる（途中経過を保持）
Import> stop_job
Are you sure you wish to stop this job ([yes]/no): yes

-- 停止できない場合、強制終了（ジョブとマスターテーブルを削除）
Import> kill_job
Are you sure you wish to stop this job ([yes]/no): yes

-- 残存ジョブを確認
SELECT
  owner_name,
  job_name,
  state
FROM dba_datapump_jobs
WHERE state = 'NOT RUNNING';

-- Data Pump APIでジョブを停止・削除
DECLARE
  h NUMBER;
BEGIN
  h := DBMS_DATAPUMP.ATTACH(
    job_name => 'SYS_IMPORT_FULL_01',
    job_owner => 'SYSTEM'
  );
  DBMS_DATAPUMP.STOP_JOB(h, 1, 0);
END;
/

-- マスターテーブルの存在を確認
SELECT owner, table_name
FROM dba_tables
WHERE table_name LIKE 'SYS_IMPORT%'
   OR table_name LIKE 'SYS_EXPORT%';

-- マスターテーブルを手動削除
DROP TABLE SYSTEM.SYS_IMPORT_FULL_01 PURGE;

注意

マスターテーブルを手動削除する前に、対応するData Pumpプロセスが完全に停止していることを確認してください。実行中のプロセスがある状態で削除すると、データの不整合が生じる可能性があります。OS上でps -ef | grep dwやps -ef | grep dmでワーカー/マスタープロセスの有無を確認しましょう。

# Data Pumpのワーカー/マスタープロセスを確認
ps -ef | grep -E "dw|dm" | grep -v grep

# プロセスが残っている場合はKILL
kill -9 <PID>

高速インポートのベストプラクティス

大規模なダンプファイルをインポートする場合は、以下の設定を組み合わせることで最大限の高速化が可能です。

# 高速インポートの推奨設定例
impdp system/password 
  directory=DATA_PUMP_DIR 
  dumpfile=full_export_%U.dmp 
  logfile=import.log 
  parallel=4 
  transform=DISABLE_ARCHIVE_LOGGING:Y 
  exclude=INDEX 
  exclude=CONSTRAINT 
  table_exists_action=TRUNCATE 
  cluster=N

-- 1. インデックスを NOLOGGING + PARALLEL で再作成
--    （SQLFILEで抽出したDDLに NOLOGGING PARALLEL 4 を追加して実行）

-- 2. 制約を有効化
--    （必要に応じてダンプから制約DDLを抽出して実行）

-- 3. テーブルとインデックスのLOGGING属性を元に戻す
ALTER TABLE hr.employees LOGGING;
ALTER INDEX hr.idx_emp_dept_id LOGGING;

-- 4. FORCE LOGGINGが無効化されていた場合は元に戻す
ALTER DATABASE FORCE LOGGING;

-- 5. 統計情報を収集
BEGIN
  DBMS_STATS.GATHER_SCHEMA_STATS(
    ownname  => 'HR',
    estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
    degree   => 4
  );
END;
/

-- 6. RMANで全体バックアップを取得
-- （NOLOGGINGで投入したデータを保護するため）