【Oracle】旧バージョンから新バージョンへの移行手順まとめ|Data Pump・RMAN・DBUA・インプレースの 4 方式比較・移行前チェック・検証まで解説

【Oracle】旧バージョンから新バージョンへの移行手順まとめ|Data Pump・RMAN・DBUA・インプレースの 4 方式比較・移行前チェック・検証まで解説 Oracle

Oracle のバージョンアップ(11g → 19c、12c → 21c 等)は、データベース運用における最も重要な作業の 1 つです。方式の選択を誤るとダウンタイムが長期化し、データ不整合のリスクも生じます。

本記事では、Data Pump・RMAN・DBUA・インプレースアップグレードの 4 方式を比較し、事前チェック移行手順移行後の検証まで体系的に解説します。

この記事でわかること
・4 つの移行方式の比較と選び方
・バージョンアップパス(直接アップグレード可能な組み合わせ)
・preupgrade.jar による事前チェック
・Data Pump 論理移行の手順
・DBUA / インプレースアップグレードの手順
・移行後の検証手順(catctl.pl / utlu132s.sql)
・ダウンタイム最小化のアプローチ
スポンサーリンク

4 つの移行方式の比較

方式 概要 ダウンタイム 適するケース
Data Pump(論理移行) 旧 DB から expdp → 新 DB に impdp 長い(データ量に比例) 異なる OS / アーキテクチャ間の移行。データの整理も同時に行いたい場合
DBUA(GUI) Database Upgrade Assistant(GUI ツール)でインプレース 中(DB サイズに依存) 同一サーバーでの標準的なアップグレード。GUI 操作で安心
手動インプレース ORACLE_HOME を変更して catupgrd.sql / catctl.pl を実行 DBUA が使えない環境。自動化したい場合
RMAN + TTS RMAN バックアップ + Transportable Tablespace 短い 大規模 DB のダウンタイム最小化。異なるサーバーへの移行
方式選択の判断基準
・同一サーバー + 標準的なアップグレード → DBUA(最もシンプル)
・異なるサーバー / 異なる OS → Data Pump
・大規模 DB + ダウンタイム最小化 → RMAN + TTS(Transportable Tablespace)
・自動化 / スクリプト化が必要 → 手動インプレース

バージョンアップパス

Oracle は全バージョンから最新版に直接アップグレードできるわけではありません。以下がサポートされる直接アップグレードパスです。

移行元 直接アップグレード可能な移行先
11.2.0.4 12.1 / 12.2 / 18c / 19c
12.1.0.2 12.2 / 18c / 19c / 21c
12.2.0.1 18c / 19c / 21c / 23c
18c (18.x) 19c / 21c / 23c
19c (19.x) 21c / 23c
21c 23c
11.2.0.3 以前は直接 19c にアップグレードできない
11.2.0.3 以前(11.1 / 10g 等)は、まず 11.2.0.4 または 12.1 にアップグレードしてから 19c に移行する 2 段階が必要です。ただし Data Pump(論理移行)ならバージョンに関係なく移行可能です。
Data Pump はバージョンパスの制約を受けない
Data Pump は「旧 DB からエクスポート → 新 DB にインポート」する論理移行のため、11g → 19c でも 10g → 21c でも直接移行できます。バージョンパスが複雑な場合は Data Pump が最もシンプルです。

移行前の事前チェック

Shell(preupgrade.jar の実行: 19c 移行時)
# 新バージョンの ORACLE_HOME にある preupgrade.jar を実行
# 旧 DB が稼働中に実行する
$NEW_ORACLE_HOME/jdk/bin/java -jar \
    $NEW_ORACLE_HOME/rdbms/admin/preupgrade.jar \
    TERMINAL TEXT

# 出力例:
# [WARNING] PARAMETER: compatible ... must be updated
# [FIXUP]   Run preupgrade_fixups.sql before upgrade
# [INFO]    Run postupgrade_fixups.sql after upgrade
SQL(手動チェック項目)
-- (1) 現在のバージョンとコンポーネント
SELECT banner_full FROM v$version;
SELECT comp_name, version, status FROM dba_registry;

-- (2) INVALID オブジェクトの確認
SELECT owner, object_type, COUNT(*) FROM dba_objects
WHERE status = 'INVALID' GROUP BY owner, object_type;

-- (3) 文字セットの確認
SELECT parameter, value FROM nls_database_parameters
WHERE parameter IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');

-- (4) 表領域の空き容量(SYSTEM / SYSAUX は拡張が必要な場合あり)
SELECT tablespace_name, ROUND(used_percent, 1) AS used_pct
FROM dba_tablespace_usage_metrics ORDER BY used_pct DESC;

-- (5) 非推奨パラメータの確認
SHOW PARAMETER compatible;

移行前チェックリスト

# 確認項目 対処
1 preupgrade.jar で WARNING / ERROR がないか preupgrade_fixups.sql を実行して修正
2 INVALID オブジェクトの解消 EXEC DBMS_UTILITY.COMPILE_SCHEMA で再コンパイル
3 SYSTEM / SYSAUX 表領域の空き アップグレードで 1〜3GB 必要。不足なら拡張
4 非推奨パラメータの確認 compatible / optimizer_features_enable 等を新バージョンに更新
5 フルバックアップの取得 RMAN BACKUP DATABASE PLUS ARCHIVELOG(ロールバック用)
6 テスト環境での事前検証 本番と同じ手順でテスト環境をアップグレードして検証

Data Pump(論理移行)の手順

Shell(Data Pump 移行: 完全手順)
# ===== 旧 DB(移行元)での作業 =====

# (1) エクスポート(バージョンを新 DB に合わせる場合)
expdp system/password \
    directory=DP_DIR \
    dumpfile=full_migration_%U.dmp \
    logfile=migration_exp.log \
    full=y \
    parallel=4 \
    compression=ALL \
    flashback_time="TO_TIMESTAMP(SYSDATE)"

# 旧バージョン → 下位互換ダンプが必要な場合
# version=12.2 パラメータを追加

# ===== 新 DB(移行先)での作業 =====

# (2) ダンプファイルを転送
# scp full_migration_*.dmp oracle@new-server:/oracle/dpdir/

# (3) インポート
impdp system/password \
    directory=DP_DIR \
    dumpfile=full_migration_%U.dmp \
    logfile=migration_imp.log \
    full=y \
    parallel=4

# (4) INVALID オブジェクトの再コンパイル
# @$ORACLE_HOME/rdbms/admin/utlrp.sql

Data Pump の詳しい使い方は「Data Pump の使い方完全ガイド」、バージョン違いでの注意点は「バージョンが違う DB での注意点」を参照してください。

DBUA(Database Upgrade Assistant)の手順

Shell(DBUA の実行)
# (1) 新バージョンの ORACLE_HOME をインストール(既存 ORACLE_HOME とは別のパス)
# /oracle/product/19c/dbhome_1  ← 新バージョン
# /oracle/product/12c/dbhome_1  ← 旧バージョン(残す)

# (2) フルバックアップを取得
rman target / <<EOF
BACKUP DATABASE PLUS ARCHIVELOG;
EOF

# (3) DBUA を起動(GUI)
$NEW_ORACLE_HOME/bin/dbua

# DBUA が以下を自動実行:
# - preupgrade チェック
# - ORACLE_HOME の切り替え
# - カタログのアップグレード(catctl.pl)
# - INVALID オブジェクトの再コンパイル
# - postupgrade 処理
DBUA のメリット
・GUI で手順を確認しながら進められる
・preupgrade チェック → アップグレード → postupgrade を自動実行
・問題発生時のロールバック機能
・アップグレードログの自動保存

手動インプレースアップグレードの手順

Shell(手動アップグレード: 19c への例)
# (1) 新バージョンの ORACLE_HOME をインストール

# (2) preupgrade.jar を実行して事前チェック
$NEW_ORACLE_HOME/jdk/bin/java -jar $NEW_ORACLE_HOME/rdbms/admin/preupgrade.jar TERMINAL TEXT

# (3) preupgrade_fixups.sql を実行(旧 ORACLE_HOME で)
sqlplus / as sysdba @/path/to/preupgrade_fixups.sql

# (4) 旧 DB を停止
sqlplus / as sysdba
SQL> SHUTDOWN IMMEDIATE;

# (5) ORACLE_HOME を新バージョンに切り替え
export ORACLE_HOME=/oracle/product/19c/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH

# (6) UPGRADE モードで起動
SQL> STARTUP UPGRADE;

# (7) カタログアップグレードスクリプトを実行
# 12c 以降: catctl.pl(並列実行)
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catctl.pl \
    -n 4 -l /oracle/upgrade_logs $ORACLE_HOME/rdbms/admin/catupgrd.sql

# (8) postupgrade_fixups.sql を実行
sqlplus / as sysdba @/path/to/postupgrade_fixups.sql

# (9) INVALID オブジェクトの再コンパイル
sqlplus / as sysdba @$ORACLE_HOME/rdbms/admin/utlrp.sql

# (10) 通常モードで再起動
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;

# (11) compatible パラメータを更新
SQL> ALTER SYSTEM SET compatible = '19.0.0' SCOPE=SPFILE;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
compatible パラメータの変更は不可逆
compatible を新バージョンに変更すると旧バージョンにダウングレードできなくなります。アップグレード後に十分なテストを行い、問題がないことを確認してから compatible を変更してください。

移行後の検証手順

SQL(アップグレード後の確認)
-- (1) バージョンの確認
SELECT banner_full FROM v$version;

-- (2) コンポーネントの状態確認
SELECT comp_name, version, status FROM dba_registry
ORDER BY comp_name;
-- status = VALID であることを確認

-- (3) INVALID オブジェクトの確認
SELECT owner, object_type, COUNT(*) FROM dba_objects
WHERE status = 'INVALID'
GROUP BY owner, object_type
ORDER BY COUNT(*) DESC;

-- INVALID があれば再コンパイル
@$ORACLE_HOME/rdbms/admin/utlrp.sql

-- (4) タイムゾーンバージョンの確認
SELECT version FROM v$timezone_file;

-- (5) compatible パラメータの確認
SHOW PARAMETER compatible;

移行後チェックリスト

# 確認項目
1 V$VERSION でバージョンが新しいことを確認
2 DBA_REGISTRY で全コンポーネントが VALID
3 INVALID オブジェクトが 0 件(utlrp.sql で再コンパイル)
4 アプリケーションの主要機能テスト
5 主要 SQL の実行計画が適切か確認(AWR 比較)
6 統計情報の更新(DBMS_STATS.GATHER_DATABASE_STATS)
7 バックアップの取得(新バージョンでのフルバックアップ)
8 compatible パラメータの更新(テスト完了後)

ダウンタイム最小化のアプローチ

方法 ダウンタイム 複雑さ
インプレース(DBUA / 手動) 数時間(DB サイズに依存)
Data Pump 数時間〜数日(データ量に比例)
RMAN + Transportable Tablespace 短い(メタデータ移行分のみ)
Oracle GoldenGate ほぼゼロ(リアルタイム複製) 非常に高い(有償ツール)
Data Guard + Switchover 数分(スタンバイを先にアップグレード)
ダウンタイムを最小化したい場合
Data Guard: スタンバイ DB を先に新バージョンにアップグレードし、Switchover で切り替え(数分)
GoldenGate: リアルタイムレプリケーションで並行稼働し、カットオーバー(ほぼゼロ)
いずれも Enterprise Edition の追加機能であり、ライセンスと設計の複雑さが伴います。

実務パターン集

パターン(1): 11g → 19c の移行(Data Pump)

Shell
# 11.2.0.4 → 19c: Data Pump 論理移行
# 11g から 19c は直接アップグレード可能だが、
# 異なるサーバーなら Data Pump が最もシンプル

# 旧 DB: expdp(version パラメータは不要: 新 DB が上位)
expdp system/password full=y dumpfile=11g_full_%U.dmp \
    parallel=4 compression=ALL directory=DP_DIR

# 新 DB(19c): impdp
impdp system/password full=y dumpfile=11g_full_%U.dmp \
    parallel=4 directory=DP_DIR

# 再コンパイル + 統計収集
sqlplus / as sysdba @\$ORACLE_HOME/rdbms/admin/utlrp.sql
EXEC DBMS_STATS.GATHER_DATABASE_STATS;

パターン(2): 12c → 19c の移行(DBUA インプレース)

Shell
# 同一サーバー: DBUA でインプレースアップグレード

# (1) 19c ORACLE_HOME をインストール
# (2) フルバックアップ
rman target / <<EOF
BACKUP DATABASE PLUS ARCHIVELOG;
EOF

# (3) DBUA 起動
$ORACLE_HOME_19c/bin/dbua
# GUI でウィザードに従う

# (4) 検証
sqlplus / as sysdba
SELECT banner_full FROM v$version;
SELECT comp_name, status FROM dba_registry;

パターン(3): 19c → 23c の移行(手動インプレース)

Shell
# 自動化スクリプト向けに手動インプレースを選択

# preupgrade → SHUTDOWN → ORACLE_HOME 切替 → STARTUP UPGRADE
# → catctl.pl → postupgrade → utlrp.sql → STARTUP
# 詳細は本記事の手動インプレースセクション参照

ロールバック(アップグレードの取り消し)

方式 ロールバック方法
Data Pump 旧 DB がそのまま残っているためロールバック不要(旧 DB に戻すだけ)
DBUA DBUA のロールバック機能 / 事前のフルバックアップから RMAN リストア
手動インプレース(compatible 未変更) ORACLE_HOME を旧バージョンに戻して STARTUP(catupgrd のロールバック)
手動インプレース(compatible 変更済み) ロールバック不可。フルバックアップからの RMAN リストアのみ
アップグレード前のフルバックアップは絶対必須
compatible パラメータを変更してしまうと旧バージョンへのダウングレードは不可能です。アップグレード前に必ず RMAN フルバックアップを取得し、万が一の場合はバックアップからリストアしてください。

よくある質問

QData Pump とインプレースはどちらが速いですか?
Aインプレース(DBUA / 手動)の方が一般的に速いです。インプレースはカタログのアップグレード(catctl.pl)のみで完了しますが、Data Pump はデータのエクスポート + 転送 + インポートが必要です。ただしインプレースでは旧 DB が使えなくなるため、ロールバックがバックアップからの復元のみになるリスクがあります。
Q10g から 19c に直接アップグレードできますか?
A直接のインプレースアップグレードはできません。まず 11.2.0.4 または 12.1 にアップグレードしてから 19c に移行する 2 段階が必要です。ただしData Pump(論理移行)なら 10g から直接 19c に移行可能です。
Qcompatible パラメータはすぐに変更すべきですか?
Aすぐに変更する必要はありません。アップグレード後にアプリケーションのテストを十分に行い、問題がないことを確認してから compatible を新バージョンに変更してください。compatible を変更すると旧バージョンへのダウングレードが不可能になります。
QINVALID オブジェクトが大量に出ます
Aアップグレード直後は PL/SQL オブジェクトが INVALID になることがあります。@$ORACLE_HOME/rdbms/admin/utlrp.sql を実行して再コンパイルしてください。多くの場合、再コンパイルで解消されます。解消されないものは個別に原因を調査してください。
QCDB / PDB 環境でのアップグレードは?
ACDB 環境では CDB$ROOT をアップグレードすると全 PDB も自動的にアップグレードされます。ただし PDB 数が多い場合は catctl.pl の並列度を上げて高速化してください。非 CDB から CDB への移行は DBMS_PDB.DESCRIBE + CREATE PLUGGABLE DATABASE で行います。
Qテスト環境で事前検証は必須ですか?
A必須です。本番と同じデータ・構成のテスト環境でアップグレードをリハーサルし、実行計画の変化・アプリケーションの互換性・所要時間を事前に確認してください。テストなしの本番アップグレードは極めてリスクが高いです。

まとめ

バージョンアップ移行の要点をまとめます。

やりたいこと 推奨方式
異なるサーバーへ移行 Data Pump(expdp → 転送 → impdp)
同一サーバーで標準アップグレード DBUA(GUI ウィザード)
自動化 / スクリプト化したい 手動インプレース(catctl.pl)
大規模 DB + ダウンタイム最小化 RMAN + Transportable Tablespace / Data Guard
バージョンパスが複雑(10g → 19c 等) Data Pump(論理移行: パス制約なし)
移行前のチェック preupgrade.jar + チェックリスト
移行後の検証 DBA_REGISTRY + INVALID チェック + utlrp.sql + 統計収集

別サーバーへの移行は「別サーバーへデータベースを移行する方法」、Data Pump の基本は「Data Pump の使い方完全ガイド」、バージョン違いでの注意点は「バージョンが違う DB での注意点」も併せて参照してください。