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 以前(11.1 / 10g 等)は、まず 11.2.0.4 または 12.1 にアップグレードしてから 19c に移行する 2 段階が必要です。ただし Data Pump(論理移行)ならバージョンに関係なく移行可能です。
Data Pump は「旧 DB からエクスポート → 新 DB にインポート」する論理移行のため、11g → 19c でも 10g → 21c でも直接移行できます。バージョンパスが複雑な場合は Data Pump が最もシンプルです。
移行前の事前チェック
# 新バージョンの 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
-- (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(論理移行)の手順
# ===== 旧 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)の手順
# (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 処理
・GUI で手順を確認しながら進められる
・preupgrade チェック → アップグレード → postupgrade を自動実行
・問題発生時のロールバック機能
・アップグレードログの自動保存
手動インプレースアップグレードの手順
# (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 を変更してください。
移行後の検証手順
-- (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)
# 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 インプレース)
# 同一サーバー: 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 の移行(手動インプレース)
# 自動化スクリプト向けに手動インプレースを選択 # 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 フルバックアップを取得し、万が一の場合はバックアップからリストアしてください。
よくある質問
@$ORACLE_HOME/rdbms/admin/utlrp.sql を実行して再コンパイルしてください。多くの場合、再コンパイルで解消されます。解消されないものは個別に原因を調査してください。まとめ
バージョンアップ移行の要点をまとめます。
| やりたいこと | 推奨方式 |
|---|---|
| 異なるサーバーへ移行 | 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 での注意点」も併せて参照してください。

