6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@nyasuhiro(Yasuhiro Nishida)
in

ZDM+リフレッシュ可能クローンを使ってBaseDB OCPU環境からExaDB-XSへ移行してみた。

6
Posted at

1. はじめに

以前、以下の記事でOCI Base Database Service（以下、BaseDB）のOCPU環境からECPU環境への移行を、PDBのリフレッシュ可能クローンを利用して試してみました。

OCI Base Database Service のリフレッシュ可能クローンを使ってOCPU環境からECPU環境へ移行してみた

前回はBaseDB同士でPDBをクローンし、移行元の更新データをリフレッシュによって移行先へ反映させるところまで確認しました。
一方、BaseDBではOCPU課金SKUやEnterprise Edition - Extreme Performance（EE-EP）の提供終了が案内されています。
現時点では既存デプロイメントは引き続き稼働しますが、新規プロビジョニングや今後の影響も鑑み、これまでBaseDBのEE-EPでRACを利用していた場合などは、移行先の検討が必要になります。

共有インフラストラクチャ上でOracle RACを利用したい場合、候補になるのが Oracle Exadata Database Service on Exascale Infrastructure（ExaDB-XS） です。
ExaDB-XSは、Exadataの機能を利用しながら、共有インフラストラクチャ上にVMクラスタを構成できるサービスです。

今回はたまたまExaDB-XSのVMクラスタを借りれる機会があったので、BaseDBのOCPU環境からExaDB-XSへ、PDBのリフレッシュ可能クローンを使ってデータ移行してみます！

参考：

本記事は個人の検証結果をまとめたものであり、所属する組織の公式見解を示すものではありません。

サービスの提供条件やサポート範囲は変更される場合があるため、最新情報は公式ドキュメントをご確認ください。

2. ZDM 26.1でPDBクローンが利用できるようになった

BaseDBではOCIコンソールからPDBをクローンできます。

ただし、BaseDBのGUIから選択できるクローン先はBaseDBのDBシステムです。
今回のようにBaseDBからExaDB-XSへクローンする操作は、GUI上からは実施できません。

そのため、最初はSQLコマンドでDB Linkを作成し、CREATE PLUGGABLE DATABASEでクローンする必要があるのかなと思っていました。

調べてみると、Oracle Zero Downtime Migration（ZDM）26.1では、PDBクローンによる移行がサポートされました。

ZDMは、Oracle DatabaseをOCIなどへ移行する際の作業を自動化するツールです。
ZDM 26.1では、PDBクローンについて以下の方式を利用できます。

クローン方式 特徴
Cold Clone 移行元をREAD ONLYにしてクローン
Hot Clone 移行元をREAD WRITEのままクローン
リフレッシュ可能クローン（Refreshable PDB Clone） クローン後もREDOを適用して更新を反映

今回は、前回の記事と同じくリフレッシュ可能クローンを使ってみます。

さらに、ZDM 26.1ではInstant Deployという新しいデプロイ方式も追加されています。
従来のZDMでは、ZDMサーバーを用意してインストール・起動する構成が一般的でしたが、Instant DeployではZDMキットを展開し、データベースサーバー上から直接zdmcliを実行できます。

専用のZDMサーバーを用意する必要がないため、今回のような検証では便利そうです。
せっかくなので、今回はZDM 26.1 Instant Deploy + リフレッシュ可能クローンを使って、BaseDBからExaDB-XSへの移行を試してみます！

参考にしたドキュメント

3. 検証環境

今回使用した環境は以下です。

項目 移行元 移行先
OCIサービス Base Database Service ExaDB-XS
CPUモデル OCPUベース ECPUベース
DB構成 シングルインスタンス 2ノードRAC
データベース Oracle AI Database 26ai Oracle AI Database 26ai
DBバージョン 23.26.3.0.0 23.26.3.0.0
CDB名 BASEOCPU EXACDB
DB_UNIQUE_NAME baseocpu_src exacdb
PDB名 BASEPDB BASEPDB（今回作成）
ZDM - ZDM 26.1 Instant Deploy

移行元と移行先は、同じVCN内に構築しています。

ZDMはExaDB-XSのノード1に配置し、そこから移行処理を実行します。

※ホスト名・クライアント名・サービスのドメイン名、および移行元のDB_UNIQUE_NAMEは匿名化しています。<source-host>は移行元ホスト、<target-node1>／<target-node2>は移行先の各ノード、<target-scan>は移行先のSCAN名を表します。コマンド内の例示値は実際の環境に合わせて置き換えてください。

移行イメージ

BaseDBからExaDB-XSへのPDB移行フロー.png

移行元PDBにはSwingbenchのSOEスキーマを用意しました。
本記事では、SCNの進行とアラートログから自動リフレッシュの動作を確認し、移行後にSOEスキーマのデータを参照できることを確認します。
なお、移行元への逆同期は行わない構成とします。

4. 事前準備

4-1. データベースの設定確認

リフレッシュ可能クローンを利用するため、移行元と移行先のデータベースで事前に設定を確認します。

ARCHIVE LOG LIST;

SHOW PARAMETER compatible;

SELECT property_name, property_value
FROM database_properties
WHERE property_name = 'LOCAL_UNDO_ENABLED';

今回の環境では、両データベースともデフォルトで設定済みでした。

結果：

SQL> ARCHIVE LOG LIST;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     19
Next log sequence to archive   19
Current log sequence           18

SQL> SHOW PARAMETER compatible;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
compatible                           string      23.6.0
noncdb_compatible                    boolean     FALSE

SQL> SELECT property_name, property_value
  2  FROM database_properties
  3  WHERE property_name = 'LOCAL_UNDO_ENABLED';

PROPERTY_NAME        PROPERTY_VALUE
-------------------- --------------------
LOCAL_UNDO_ENABLED   TRUE

ZDMが作成したDB Link利用時のORA-02085回避のため、GLOBAL_NAMES=FALSEへ変更します。

SELECT inst_id, name, value
FROM gv$system_parameter
WHERE name = 'global_names';

ALTER SYSTEM SET global_names=FALSE
  SCOPE=BOTH SID='*';

SELECT inst_id, name, value
FROM gv$system_parameter
WHERE name = 'global_names';

結果：

SQL> SELECT inst_id, value
  2  FROM gv$system_parameter
  3  WHERE name = 'global_names'
  4  ORDER BY inst_id;

   INST_ID VALUE
---------- ----------
         1 TRUE
         2 TRUE

SQL> ALTER SYSTEM SET global_names=FALSE SCOPE=BOTH SID='*';

System altered.

SQL> SELECT inst_id, value
  2  FROM gv$system_parameter
  3  WHERE name = 'global_names'
  4  ORDER BY inst_id;

   INST_ID VALUE
---------- ----------
         1 FALSE
         2 FALSE

4-2. ネットワークの疎通確認

ZDMから移行元・移行先のDBサーバーへ接続できることに加えて、ExaDB-XSからBaseDBのリスナーへ接続できることを確認します。

今回はExaDB-XSが2ノードRACなので、両ノードから移行元PDBへ接続できることを確認しました。
確認した主な通信は以下です。

通信 用途
ExaDB-XS → BaseDB：SSH ZDMによるOS操作
ExaDB-XS → BaseDB：TCP 1521 DB LinkによるPDBクローン
BaseDB → ExaDB-XS：TCP 1521 Oracle Net疎通確認

最初はExaDB-XSからBaseDBのTCP 1521に接続できませんでしたが、OCIのセキュリティリストに必要なルールを追加して解決しました。
実際の環境では、必要な送信元CIDRだけを許可するなど、適切なネットワーク制御を行ってください。

4-3. Swingbenchの準備

移行元のBASEPDBには、SwingbenchのSOEスキーマを作成しています。
SOEスキーマの作成方法については、前回の記事でも紹介しています。
今回はSwingbenchのツールを使用してSOEスキーマを用意しました。

5. ZDM 26.1 Instant Deployのセットアップ

5-1. ZDMのダウンロード

Oracle Software Delivery CloudからZDM 26.1をダウンロードします。
今回利用したファイルは以下です。こちらからダウンロードできます。

V1055491-01.zip

今回はExaDB-XSのノード1にZDMキットを配置しました。
このディレクトリはopcユーザーで操作できるようにしています。

sudo mkdir -p /u02/zdm-instant
sudo chown opc:opc /u02/zdm-instant
sudo chmod 750 /u02/zdm-instant
mv V1055491-01.zip /u02/zdm-instant/
cd /u02/zdm-instant
unzip V1055491-01.zip

5-2. ZDMの起動確認

配置したZDMディレクトリで、以下を実行します。
Instant Deployでは、このタイミングで初期セットアップが行われました。

cd /u02/zdm-instant/zdm26.1

./zdmcli -help

結果：

[opc@<target-node1> zdm26.1]$ ./zdmcli -help

Performing one-time ZDM binary setup... This may take a few minutes.
ZDM binary setup completed successfully.

Performs Zero Downtime Migration operations for the cloud.

Usage:
         zdmcli abort           Perform abort operation for a migration job.
         zdmcli add             Adds an image type or user actions.
         zdmcli audit           Perform audit operation for a migration job.
         zdmcli delete          Deletes a job, an image type or an user action.
         zdmcli migrate         Performs migration operation for the cloud.
         zdmcli modify          Modifies user actions and a migration job.
         zdmcli query           Gets information of a job, image type, user actions and audit.
         zdmcli resume          Perform resume operation for a migration job.
         zdmcli suspend         Suspend the migration job.

For detailed help on each command use:
  zdmcli <command> <object> -help
[opc@<target-node1> zdm26.1]$

続いてビルド情報を確認します。

./zdmcli -build

結果：

[opc@<target-node1> zdm26.1]$ ./zdmcli -build
full version: "26.1.0"
patch version: ""
label date: 260410.1
ZDM kit build date: Apr 11 2026 17:13:53 UTC
CPAT build version: 26.3.0

ZDM 26.1が利用できる状態になりました！

6. ZDMレスポンスファイルの作成

次に、移行用のレスポンスファイルを作成します。
今回は以下に配置しました。

/u02/zdm-instant/zdm26.1/rsp/basepdb_refreshable.rsp

内容は次のとおりです。

PLATFORM_TYPE=EXACS
TGT_DB_UNIQUE_NAME=exacdb

MIGRATION_METHOD=ONLINE_PHYSICAL
DATA_TRANSFER_MEDIUM=DBLINK

SRC_DB_HOSTNAME=<source-host>
SRC_DB_PORT=1521

TGT_DB_HOSTNAME=<target-scan>
TGT_DB_PORT=1521

ZDM_PDB_CLONE_METHOD=REFRESHABLE
ZDM_SRC_PDB_NAME=basepdb
ZDM_TGT_PDB_NAME=basepdb

ZDM_PDB_REFRESH_INTERVAL=5
ZDM_SWITCHOVER=FALSE

ZDM_SKIP_TDE_WALLET_MIGRATION=FALSE

今回はZDM_PDB_CLONE_METHOD=REFRESHABLEを指定しています。
また、ZDM_PDB_REFRESH_INTERVAL=5によって、5分間隔での自動リフレッシュを設定します。
ZDM_SWITCHOVER=FALSEは、ZDMのパラメータ上ではFailover方式の指定です。
今回は移行元と移行先のPDBを役割反転させるのではなく、最終的にExaDB-XS側を独立した通常PDBにする構成とします。

7. ZDMの事前評価

ZDMでは、-evalオプションを指定することで、実際に移行する前に環境の事前評価を実行できます。
まずは問題なく移行できそうか確認してみます。

ExaDB-XSのノード1で、opcユーザーから以下を実行しました。

cd /u02/zdm-instant/zdm26.1

./zdmcli migrate database \
  -sourcesid baseocpu \
  -sourcenode <source-host> \
  -targetnode <target-node1> \
  -targethome /u02/app/oracle/product/23.0.0.0/dbhome_1 \
  -rsp /u02/zdm-instant/zdm26.1/rsp/basepdb_refreshable.rsp \
  -srcuser opc \
  -tgtuser opc \
  -tdekeystorepasswd \
  -tgttdekeystorepasswd \
  -eval

実行すると、移行元DBのSYSパスワードと、移行元・移行先のTDEキーストアパスワードの入力を求められます。

Enter source database baseocpu SYS password:
Enter source database baseocpu TDE keystore password:
Enter target container database TDE keystore password:

Migration evaluation job started

その後、移行元・移行先の環境情報取得や事前チェック、環境の検証が実行されました。

主な出力は以下のとおりです。

Oracle ZDM (Zero Downtime Migration) Version "26.1.0"
Build date: Apr 11 2026 17:13:53 UTC

Executing phase ZDM_GET_SRC_INFO
Execution of phase ZDM_GET_SRC_INFO completed

Executing phase ZDM_GET_TGT_INFO
Execution of phase ZDM_GET_TGT_INFO completed

Executing phase ZDM_PRECHECKS_SRC
Execution of phase ZDM_PRECHECKS_SRC completed

Executing phase ZDM_PRECHECKS_TGT
Execution of phase ZDM_PRECHECKS_TGT completed

Executing phase ZDM_VALIDATE_SRC
Ensuring source database is running in ARCHIVELOG mode...
Validating Oracle TDE setup
Validating database baseocpu_src role is PRIMARY...
Source environment validated successfully
Execution of phase ZDM_VALIDATE_SRC completed

Executing phase ZDM_VALIDATE_TGT
verifying passwordless connectivity between target nodes
Target environment validated successfully
Execution of phase ZDM_VALIDATE_TGT completed

...

Oracle ZDM ONLINE PHYSICAL evaluation job completed
Job duration: 1 minutes and 50 seconds

約1分50秒で事前評価が正常に完了しました！

ARCHIVELOGモード、TDE構成、移行元DBのロール、移行先RACノード間の接続などの検証が成功しています。

なお、-evalは事前評価のみなので、この時点では移行先にBASEPDBは作成されません。

問題なさそうなので、続いて実際のPDBクローンを実行してみます。

8. ZDMの実行フェーズを確認

事前評価が正常に完了したので、いよいよPDBクローンを実行してみます！
ただし、今回はクローンを作成した後も移行元ではアプリケーションによる更新が続き、リフレッシュ可能クローンで差分を定期的に吸収する想定です。
そのため、ZDMの移行処理を最後まで一気に実行するのではなく、PDBクローン作成後に一時停止させたいです。

ZDMでは-listphasesオプションを指定することで、移行ジョブで実行されるフェーズを事前に確認できます。

まずは、どのようなフェーズがあるのか確認してみます。

./zdmcli migrate database \
  -sourcesid baseocpu \
  -sourcenode <source-host> \
  -targetnode <target-node1> \
  -targethome /u02/app/oracle/product/23.0.0.0/dbhome_1 \
  -rsp /u02/zdm-instant/zdm26.1/rsp/basepdb_refreshable.rsp \
  -srcuser opc \
  -tgtuser opc \
  -listphases

実行結果は以下のとおりです。

ZDM_GET_SRC_INFO
ZDM_GET_TGT_INFO
ZDM_PRECHECKS_SRC
ZDM_PRECHECKS_TGT
ZDM_SETUP_SRC
ZDM_SETUP_TGT
ZDM_PREUSERACTIONS
ZDM_PREUSERACTIONS_TGT
ZDM_VALIDATE_SRC
ZDM_VALIDATE_TGT
ZDM_DISCOVER_SRC
ZDM_COPYFILES
ZDM_PREPARE_TGT
ZDM_CLONE_PDB_TGT
ZDM_FINALIZE_TGT
ZDM_SWITCHOVER_TGT
ZDM_SWITCHOVER_SRC
ZDM_NONCDBTOPDB_CONVERSION
ZDM_DATAPATCH_TGT
ZDM_POST_DATABASE_OPEN_TGT
ZDM_POSTUSERACTIONS
ZDM_POSTUSERACTIONS_TGT
ZDM_CLEANUP_SRC
ZDM_CLEANUP_TGT

移行元・移行先の情報取得や事前チェックから始まり、PDBのクローン、切替処理、datapatch、クリーンアップまで、さまざまなフェーズがあることが分かります。

今回注目するのはこちらのフェーズです。

ZDM_PREPARE_TGT
ZDM_CLONE_PDB_TGT      ★ ここで一時停止したい
ZDM_FINALIZE_TGT
ZDM_SWITCHOVER_TGT
ZDM_SWITCHOVER_SRC
ZDM_NONCDBTOPDB_CONVERSION
ZDM_DATAPATCH_TGT

ZDM_CLONE_PDB_TGTがPDBクローン作成のフェーズです。
ZDMには、指定したフェーズの完了後にジョブを一時停止する-pauseafterオプションが用意されています。
そこで今回は、実際の移行コマンドに以下を追加して実行することにします。

-pauseafter ZDM_CLONE_PDB_TGT

これにより、リフレッシュ可能クローンを作成した状態でZDMジョブを一時停止し、移行元の更新データが5分間隔で移行先へ反映されるかを確認できます。
今回はクローン作成後もアプリケーションが動作し、定期リフレッシュで差分が取り込まれる想定のため、アプリケーションを切り替えることができるタイミングになった段階でzdmcli resume jobでジョブを再開して、最終的な切替処理へ進める予定です。
なお、-listphasesはフェーズを一覧表示するだけなので、このコマンドによって移行ジョブが開始されることはありません。

それでは、停止するフェーズも決まったので、実際にPDBクローンを作成してみます！

9. リフレッシュ可能クローンの作成

クローン作成後にZDMジョブを一時停止させるため、以下のオプションを指定します。

-pauseafter ZDM_CLONE_PDB_TGT

これにより、PDBクローン作成フェーズの完了後にZDMジョブを一時停止できます。

9-1. ZDMによるPDBクローンの実行

ExaDB-XSのノード1にログインし、opcユーザーでZDM Instant Deployのディレクトリから実行します。

cd /u02/zdm-instant/zdm26.1

./zdmcli migrate database \
  -sourcesid baseocpu \
  -sourcenode <source-host> \
  -targetnode <target-node1> \
  -targethome /u02/app/oracle/product/23.0.0.0/dbhome_1 \
  -rsp /u02/zdm-instant/zdm26.1/rsp/basepdb_refreshable.rsp \
  -srcuser opc \
  -tgtuser opc \
  -tdekeystorepasswd \
  -tgttdekeystorepasswd \
  -pauseafter ZDM_CLONE_PDB_TGT

第7章の事前評価と同様に、移行元データベースのSYSパスワードと、移行元・移行先のTDEキーストアパスワードの入力を求められます。

Enter source database baseocpu SYS password:
Enter source database baseocpu TDE keystore password:
Enter target container database TDE keystore password:

Migration job started ....

Result file path: /u02/zdm-instant/zdm26.1/zdmbase/chkbase/scheduled/job-5-2026-10-10-13:57:59.log

無事に移行ジョブが開始されました！

今回のジョブIDは5です。

9-2. ZDMの実行結果

ジョブが開始されると、ZDMによって移行元・移行先の情報取得や環境検証、接続設定などが順番に実行されました。

主な実行ログを抜粋します。

Oracle ZDM (Zero Downtime Migration) Version "26.1.0"
Build date: Apr 11 2026 17:13:53 UTC

Starting zero downtime migrate operation ...

Executing phase ZDM_GET_SRC_INFO
Execution of phase ZDM_GET_SRC_INFO completed

Executing phase ZDM_GET_TGT_INFO
Execution of phase ZDM_GET_TGT_INFO completed

Executing phase ZDM_PRECHECKS_SRC
Execution of phase ZDM_PRECHECKS_SRC completed

Executing phase ZDM_PRECHECKS_TGT
Execution of phase ZDM_PRECHECKS_TGT completed

Executing phase ZDM_SETUP_SRC
TNS aliases successfully setup on the source node <source-host>...
Execution of phase ZDM_SETUP_SRC completed

Executing phase ZDM_SETUP_TGT
TNS aliases successfully setup on the target node <target-node1>...
Execution of phase ZDM_SETUP_TGT completed

続いて、移行元・移行先の環境検証が実行されます。

Executing phase ZDM_VALIDATE_SRC

Validating source environment...
Ensuring source database is running in ARCHIVELOG mode...
Validating Oracle TDE setup
Validating database baseocpu_src role is PRIMARY...

Source environment validated successfully
Execution of phase ZDM_VALIDATE_SRC completed

Executing phase ZDM_VALIDATE_TGT

verifying passwordless connectivity between target nodes

Target environment validated successfully
Execution of phase ZDM_VALIDATE_TGT completed

移行元のARCHIVELOGモードやTDE構成、データベースのロールなどの検証が成功し、移行先RACノード間の接続も問題ないことが確認できました。

その後、移行に必要な準備処理が進みます。

Executing phase ZDM_DISCOVER_SRC

Successfully discovered database exacdb

Enabling force logging on database baseocpu_src...
Creating standby logs on database baseocpu_src...

Source environment set up successfully
Execution of phase ZDM_DISCOVER_SRC completed

Executing phase ZDM_COPYFILES

Source database "baseocpu_src" credentials exported successfully
Execution of phase ZDM_COPYFILES completed

Executing phase ZDM_PREPARE_TGT

Target environment set up successfully
Execution of phase ZDM_PREPARE_TGT completed

ログを見ると、ZDMが移行元でForce Loggingの有効化やStandby Redo Logの作成なども実施していることが分かります。

9-3. PDBクローン作成とジョブの一時停止

準備処理が完了すると、いよいよZDM_CLONE_PDB_TGTフェーズが実行されました。

2026-10-10T14:01:42.983Z : Executing phase ZDM_CLONE_PDB_TGT

2026-10-10T14:02:46.212Z : Cloning a pluggable database (PDB) basepdb to a pluggable database basepdb on the target multitenant container database (CDB) exacdb ...

2026-10-10T14:02:51.754Z : Execution of phase ZDM_CLONE_PDB_TGT completed

2026-10-10T14:02:51.775Z : Job execution paused after phase "ZDM_CLONE_PDB_TGT".

PDBクローン作成フェーズが正常に完了しました！

そして、-pauseafter ZDM_CLONE_PDB_TGTを指定していたため、想定どおりジョブが一時停止しています。

実行結果をまとめると、以下のとおりです。

項目 結果
ZDMバージョン 26.1.0
ジョブID 5
移行元 BaseDB / BASEOCPU / BASEPDB
移行先 ExaDB-XS / EXACDB / BASEPDB
実行開始 2026/10/10 13:57:59 UTC
一時停止 2026/10/10 14:02:51 UTC
所要時間 4分52秒
停止フェーズ ZDM_CLONE_PDB_TGT
結果 クローン作成フェーズ完了後に一時停止

思っていたよりも短時間でクローン作成フェーズまで進みました。
ただし、ここで完了したのはPDBクローン作成フェーズまでです。ZDMの移行ジョブ全体が完了したわけではありません。

9-4. ZDMジョブの状態を確認

続いて、query jobコマンドでジョブの状態を確認してみます。

./zdmcli query job -jobid 5

実行結果は以下のとおりです。

※実行時のコマンド全文とファイルパスの一部は省略しています。

Job ID: 5
User: opc
Client: <zdm-client>
Job Type: "MIGRATE"

Scheduled job execution start time: 2026-10-10T13:57:58Z. Equivalent local time: 2026-10-10 13:57:58

Current status: PAUSED
Current Phase: "ZDM_CLONE_PDB_TGT"

Result file path: "/u02/zdm-instant/zdm26.1/zdmbase/chkbase/scheduled/job-5-2026-10-10-13:57:59.log"
Metrics file path: "/u02/zdm-instant/zdm26.1/zdmbase/chkbase/scheduled/job-5-2026-10-10-13:57:59.json"

Job execution start time: 2026-10-10 13:57:59
Job execution end time: 2026-10-10 14:02:51
Job execution elapsed time: 4 minutes 52 seconds

ZDM_GET_SRC_INFO .............. COMPLETED
ZDM_GET_TGT_INFO .............. COMPLETED
ZDM_PRECHECKS_SRC ............. COMPLETED
ZDM_PRECHECKS_TGT ............. COMPLETED
ZDM_SETUP_SRC ................. COMPLETED
ZDM_SETUP_TGT ................. COMPLETED
ZDM_PREUSERACTIONS ............ COMPLETED
ZDM_PREUSERACTIONS_TGT ........ COMPLETED
ZDM_VALIDATE_SRC .............. COMPLETED
ZDM_VALIDATE_TGT .............. COMPLETED
ZDM_DISCOVER_SRC .............. COMPLETED
ZDM_COPYFILES ................. COMPLETED
ZDM_PREPARE_TGT ............... COMPLETED
ZDM_CLONE_PDB_TGT ............. COMPLETED
ZDM_FINALIZE_TGT .............. PENDING
ZDM_SWITCHOVER_TGT ............ PENDING
ZDM_SWITCHOVER_SRC ............ PENDING
ZDM_NONCDBTOPDB_CONVERSION .... PENDING
ZDM_DATAPATCH_TGT ............. PENDING
ZDM_POST_DATABASE_OPEN_TGT .... PENDING
ZDM_POSTUSERACTIONS ........... PENDING
ZDM_POSTUSERACTIONS_TGT ....... PENDING
ZDM_CLEANUP_SRC ............... PENDING
ZDM_CLEANUP_TGT ............... PENDING

Pause After Phase: "ZDM_CLONE_PDB_TGT"

ここで注目したいのが、以下の部分です。

Current status: PAUSED
Current Phase: "ZDM_CLONE_PDB_TGT"

ジョブの状態がPAUSEDになっており、指定したZDM_CLONE_PDB_TGTで停止していることが確認できました。

また、各フェーズの状態を見ると、

  • ZDM_CLONE_PDB_TGTまで：COMPLETED
  • ZDM_FINALIZE_TGT以降：PENDING

となっています。

つまり、PDBクローンの作成までは完了していますが、最終的な切替処理やdatapatchなどはまだ実行されていません。

第8章で確認したフェーズ一覧と比較すると、ZDMがどこまで実行され、どこから処理を再開するのかがよく分かります。

9-5. 次の検証へ

これで、ZDMによるPDBクローン作成フェーズが正常に完了し、指定したタイミングで一時停止できることを確認しました。

ここではまだZDMジョブを再開しません。

この後ジョブを再開すると、切替前の最終リフレッシュを行い、切替処理に入ります。
現状はBaseDB側にアプリケーションの更新が続いているという想定で、定期的にリフレッシュが行われているか確認します。

10. リフレッシュ可能クローンの定期同期を確認

第9章では、ZDMによるPDBクローンの作成が完了し、ジョブがZDM_CLONE_PDB_TGTフェーズで一時停止したことを確認しました。

ここからは、ExaDB-XS側に作成されたBASEPDBがリフレッシュ可能クローンとして構成され、移行元からの差分同期が動作しているか確認してみます！

今回、ZDMのレスポンスファイルでは以下のように指定しています。

ZDM_PDB_CLONE_METHOD=REFRESHABLE
ZDM_PDB_REFRESH_INTERVAL=5

5分間隔で自動リフレッシュする設定です。

10-1. リフレッシュ可能クローンの状態を確認

ExaDB-XSのノード1でoracleユーザーからEXACDBのCDB$ROOTに接続します。

SELECT pdb_name,
       status,
       refresh_mode,
       refresh_interval,
       last_refresh_scn
FROM dba_pdbs
WHERE pdb_name = 'BASEPDB';

実行結果はこちらです。

PDB_NAME   STATUS     REFRES REFRESH_INTERVAL LAST_REFRESH_SCN
---------- ---------- ------ ---------------- ----------------
BASEPDB    REFRESHING AUTO                  5          5024024

BASEPDBの状態はREFRESHING、REFRESH_MODEはAUTOとなっています。

さらにREFRESH_INTERVAL=5なので、レスポンスファイルで設定した5分間隔の自動リフレッシュが構成されていることを確認できました。

続いて、RACの両インスタンスでPDBの状態を確認してみます。

SELECT inst_id,
       name,
       open_mode
FROM gv$pdbs
WHERE name = 'BASEPDB'
ORDER BY inst_id;

   INST_ID NAME            OPEN_MODE
---------- --------------- ---------------
         1 BASEPDB         MOUNTED
         2 BASEPDB         MOUNTED

どちらのインスタンスでもMOUNTEDになっています。

この時点では、移行先PDBをアプリケーション向けにREAD WRITEでオープンする段階ではなく、リフレッシュ可能クローンとして差分同期を続ける状態です。

10-2. LAST_REFRESH_SCNの変化を確認

次に、リフレッシュが実際に進んでいるのか確認します。

しばらく時間を置いて、再度DBA_PDBSを確認しました。

SELECT pdb_name,
       status,
       refresh_mode,
       refresh_interval,
       last_refresh_scn
FROM dba_pdbs
WHERE pdb_name = 'BASEPDB';

結果はこちらです。

PDB_NAME   STATUS     REFRES REFRESH_INTERVAL LAST_REFRESH_SCN
---------- ---------- ------ ---------------- ----------------
BASEPDB    REFRESHING AUTO                  5          6029741

LAST_REFRESH_SCNが5024024から6029741へ進んでいることを確認できました。

項目 SCN
1回目の確認 5024024
2回目の確認 6029741

10-3. アラートログでリフレッシュ処理を確認

SQLの結果だけでなく、ExaDB-XS側のアラートログも確認してみます。
今回のログには、次の記録がありました。

2026-10-10T14:32:42.044580+00:00
alter pluggable database BASEPDB refresh

2026-10-10T14:32:43.458542+00:00
Recovering pdb-4099 from SCN 5024024 to SCN 6029741

・・・

2026-10-10T14:32:47.408508+00:00
BASEPDB(4):.... (PID:37364): Media Recovery Complete [dbsdrv.c:15840]

Completed: alter pluggable database BASEPDB refresh

・・・

2026-10-10T14:37:42.024058+00:00
alter pluggable database BASEPDB refresh

2026-10-10T14:37:43.633635+00:00
Recovering pdb-4099 from SCN 6029741 to SCN 6031272

・・・

2026-10-10T14:37:46.786304+00:00
BASEPDB(4):.... (PID:171200): Media Recovery Complete [dbsdrv.c:15840]

Completed: alter pluggable database BASEPDB refresh

掲載したログでは、5分間隔でリフレッシュが正常に完了していることを確認できました。
その後もアラートログを眺めている限り、RAC環境のどちらのノードで実行されるかは毎回ランダムのようでした。

10-4. 自動リフレッシュの確認を終えて切替へ進む

これで、ZDMによって作成されたリフレッシュ可能クローンが、5分間隔で自動リフレッシュされていることを確認できました！

ZDMジョブを一時停止している間も、移行元から移行先への差分同期が継続しています。

それでは、ZDMジョブを再開してリフレッシュ可能クローンを通常PDBに切り替え、ExaDB-XS側でREAD WRITEでオープンできる状態にしていきます。

11. ZDMジョブの再開と移行先PDBへの切替

第10章では、リフレッシュ可能クローンが5分間隔で自動リフレッシュされていることを確認しました。
それでは、ZDMジョブを再開し、移行先のBASEPDBを通常PDBへ切り替えてみます！
本番移行では、この再開前に移行元へのアプリケーション更新を停止し、実行中のトランザクションを完了させます。その後、最終リフレッシュの完了と更新データの反映を確認してから、移行先への接続切替と更新再開を行います。本記事に掲載したログでは、更新停止と最終データ照合の詳細は省略しています。

11-1. 切替フェーズまでZDMジョブを再開

第8章で確認したフェーズ一覧を見ると、ZDM_DATAPATCH_TGTの前にZDM_SWITCHOVER_SRCがあります。
今回使用したZDM 26.1.0のビルドと検証環境では、ジョブを最後まで実行しようとしたところ、通常PDBへの切替後もBASEPDBがMOUNTEDのままで、ZDM_DATAPATCH_TGTが失敗しました。
そこで本検証では、ZDM_SWITCHOVER_SRCの完了後に一時停止し、対象PDBを両インスタンスでREAD WRITEでオープンしてから再開しました。詳細はおまけ3に記載します。

通常PDBへの切替後、datapatchの実行前に一時停止してPDBをREAD WRITEでオープンするため、次のように指定してジョブを再開します。

./zdmcli resume job -jobid 5 \
  -pauseafter ZDM_SWITCHOVER_SRC

実行ログを確認すると、切替処理が正常に完了しています。

2026-10-10T14:50:31.890Z : Executing phase ZDM_FINALIZE_TGT
2026-10-10T14:50:31.945Z : Execution of phase ZDM_FINALIZE_TGT completed

2026-10-10T14:50:32.256Z : Executing phase ZDM_SWITCHOVER_TGT
2026-10-10T14:51:00.008Z : Switchover actions in the target environment executed successfully
2026-10-10T14:51:00.436Z : Execution of phase ZDM_SWITCHOVER_TGT completed

2026-10-10T14:51:00.585Z : Executing phase ZDM_SWITCHOVER_SRC
2026-10-10T14:51:13.326Z : Switchover actions in the source environment executed successfully
2026-10-10T14:51:15.772Z : Execution of phase ZDM_SWITCHOVER_SRC completed

2026-10-10T14:51:15.830Z : Job execution paused after phase "ZDM_SWITCHOVER_SRC".

指定したZDM_SWITCHOVER_SRCの完了後に、ZDMジョブが一時停止しました！

11-2. ZDMジョブの状態を確認

念のため、query jobで状態を確認します。

./zdmcli query job -jobid 5

主な実行結果は以下のとおりです。

Job ID: 5
Job Type: "MIGRATE"

Current status: PAUSED
Current Phase: "ZDM_SWITCHOVER_SRC"

Job execution elapsed time: 6 minutes 33 seconds

ZDM_CLONE_PDB_TGT ............. COMPLETED
ZDM_FINALIZE_TGT .............. COMPLETED
ZDM_SWITCHOVER_TGT ............ COMPLETED
ZDM_SWITCHOVER_SRC ............ COMPLETED
ZDM_NONCDBTOPDB_CONVERSION .... PENDING
ZDM_DATAPATCH_TGT ............. PENDING
ZDM_POST_DATABASE_OPEN_TGT .... PENDING
ZDM_POSTUSERACTIONS ........... PENDING
ZDM_POSTUSERACTIONS_TGT ....... PENDING
ZDM_CLEANUP_SRC ............... PENDING
ZDM_CLEANUP_TGT ............... PENDING

Pause After Phase: "ZDM_SWITCHOVER_SRC"

ZDM_SWITCHOVER_SRCまでCOMPLETEDになっており、ZDM_DATAPATCH_TGTはまだPENDINGです。

想定どおり、切替処理後、datapatchの前で停止できました。

11-3. 移行先PDBの状態を確認

次に、ExaDB-XS側のEXACDBに接続し、BASEPDBの状態を確認します。

SELECT pdb_name,
       status,
       refresh_mode,
       refresh_interval,
       last_refresh_scn
FROM dba_pdbs
WHERE pdb_name = 'BASEPDB';

PDB_NAME   STATUS     REFRES REFRESH_INTERVAL LAST_REFRESH_SCN
---------- ---------- ------ ---------------- ----------------
BASEPDB    NEW        NONE                             6032544

REFRESH_MODEがAUTOからNONEへ変化していました。

つまり、リフレッシュ可能クローンから通常PDBへの切替が行われ、自動リフレッシュが解除された状態になっています。

続いて、RACの両インスタンスでの状態を確認します。

SELECT inst_id,
       name,
       open_mode
FROM gv$pdbs
WHERE name = 'BASEPDB'
ORDER BY inst_id;

   INST_ID NAME            OPEN_MODE
---------- --------------- ---------------
         1 BASEPDB         MOUNTED
         2 BASEPDB         MOUNTED

両方ともMOUNTED状態です。
今回はREFRESH_MODE=NONEになり、ZDMジョブも一時停止していることを確認できたので、BASEPDBを手動でオープンします。

11-4. BASEPDBをRAC両ノードでREAD WRITEでオープン

EXACDBのCDB$ROOTで、以下を実行します。

ALTER PLUGGABLE DATABASE BASEPDB
  OPEN READ WRITE INSTANCES=ALL;

実行結果：

Pluggable database altered.

再度、PDBの状態を確認してみます。

SELECT pdb_name, status, refresh_mode
FROM dba_pdbs
WHERE pdb_name = 'BASEPDB';

PDB_NAME   STATUS     REFRES
---------- ---------- ------
BASEPDB    NORMAL     NONE

STATUSがNORMALになりました。続いてRACの両インスタンスも確認します。

SELECT inst_id, name, open_mode
FROM gv$pdbs
WHERE name = 'BASEPDB'
ORDER BY inst_id;

   INST_ID NAME            OPEN_MODE
---------- --------------- ---------------
         1 BASEPDB         READ WRITE
         2 BASEPDB         READ WRITE

両ノードでREAD WRITEになりました！

これで、ExaDB-XSの2ノードRAC上でBASEPDBをオープンできたことを確認できました。

今回はZDM_SWITCHOVER_SRCの完了後に一時停止させたことで、後続のdatapatchが始まる前にPDBの状態を確認し、必要なオープン処理を実施できました。

11-5. ZDMジョブを再開して移行を完了

移行先BASEPDBがRACの両インスタンスでREAD WRITEになったので、残りのZDM処理を実行します。

今度は-pauseafterを指定せず、そのまま最後まで実行してみます。

./zdmcli resume job -jobid 5

実行すると、すでに完了している切替フェーズなどはスキップされ、後続の処理が実行されました。

2026-10-10T14:54:39.541Z : Resuming zero downtime migrate operation ...

Skipping phase ZDM_CLONE_PDB_TGT on resume
Skipping phase ZDM_FINALIZE_TGT on resume
Skipping phase ZDM_SWITCHOVER_TGT on resume
Skipping phase ZDM_SWITCHOVER_SRC on resume

Executing phase ZDM_NONCDBTOPDB_CONVERSION
Skipping 'ZDM_NONCDBTOPDB_CONVERSION' actions as no further operations are needed ...
Execution of phase ZDM_NONCDBTOPDB_CONVERSION completed

今回はPDBからPDBへの移行なので、非CDBからPDBへの変換処理自体はスキップされています。
続いて、ZDM_DATAPATCH_TGTフェーズに進みます。

2026-10-10T14:55:32.243Z : Executing phase ZDM_DATAPATCH_TGT

2026-10-10T14:55:36.246Z : Target environment prepared for datapatch successfully

<target-node1>: trying datapatch run for exacdb1, attempt### 1 ###
<target-node1>: datapatch command ... -pdbs basepdb -db exacdb1 datapatch completed successfully for database : exacdb

<target-node2>: trying datapatch run for exacdb1, attempt### 1 ###
<target-node2>: datapatch command ... -pdbs basepdb -db exacdb1 datapatch completed successfully for database : exacdb

2026-10-10T14:56:53.431Z : Execution of phase ZDM_DATAPATCH_TGT completed

datapatchも正常に完了しました！続いて、後処理とクリーンアップが実行されます。

Executing phase ZDM_POST_DATABASE_OPEN_TGT
Post database open actions at the target executed successfully
Execution of phase ZDM_POST_DATABASE_OPEN_TGT completed

Executing phase ZDM_CLEANUP_SRC
Removed the Oracle Data Guard configuration successfully
Cleanup steps performed at the source host
Execution of phase ZDM_CLEANUP_SRC completed

Executing phase ZDM_CLEANUP_TGT
Removed the Oracle Data Guard configuration successfully
Standby log file groups dropped successfully from database exacdb
Cleanup steps performed at the target host
Execution of phase ZDM_CLEANUP_TGT completed

最後に、以下のメッセージが表示されました。

2026-10-10T14:57:30.574Z : Oracle ZDM ONLINE PHYSICAL migration completed
2026-10-10T14:57:30.578Z : Job duration: 2 minutes and 53 seconds

無事にZDMによるBaseDBからExaDB-XSへのPDB移行が完了しました！

今回は、リフレッシュ可能クローンを作成した後にジョブを一時停止し、差分同期を確認してから最終切替を実施しました。

さらに、切替後のZDM_SWITCHOVER_SRCフェーズでも一時停止させることで、datapatch実行前に移行先PDBの状態を確認し、RAC両ノードでREAD WRITEでオープンしてから残りの処理を実行しています。

11-6. ZDMジョブの最終状態を確認

最後に、ZDMジョブが正常に終了したか確認します。

./zdmcli query job -jobid 5

実行結果はこちらです。

※実行コマンド全文やログファイルのパスは一部省略しています。

Job ID: 5
User: opc
Client: <zdm-client>
Job Type: "MIGRATE"

Current status: SUCCEEDED

Job execution start time: 2026-10-10 13:57:59
Job execution end time: 2026-10-10 14:57:30
Job execution elapsed time: 9 minutes 26 seconds

ZDM_GET_SRC_INFO .............. COMPLETED
ZDM_GET_TGT_INFO .............. COMPLETED
ZDM_PRECHECKS_SRC ............. COMPLETED
ZDM_PRECHECKS_TGT ............. COMPLETED
ZDM_SETUP_SRC ................. COMPLETED
ZDM_SETUP_TGT ................. COMPLETED
ZDM_PREUSERACTIONS ............ COMPLETED
ZDM_PREUSERACTIONS_TGT ........ COMPLETED
ZDM_VALIDATE_SRC .............. COMPLETED
ZDM_VALIDATE_TGT .............. COMPLETED
ZDM_DISCOVER_SRC .............. COMPLETED
ZDM_COPYFILES ................. COMPLETED
ZDM_PREPARE_TGT ............... COMPLETED
ZDM_CLONE_PDB_TGT ............. COMPLETED
ZDM_FINALIZE_TGT .............. COMPLETED
ZDM_SWITCHOVER_TGT ............ COMPLETED
ZDM_SWITCHOVER_SRC ............ COMPLETED
ZDM_NONCDBTOPDB_CONVERSION .... COMPLETED
ZDM_DATAPATCH_TGT ............. COMPLETED
ZDM_POST_DATABASE_OPEN_TGT .... COMPLETED
ZDM_POSTUSERACTIONS ........... COMPLETED
ZDM_POSTUSERACTIONS_TGT ....... COMPLETED
ZDM_CLEANUP_SRC ............... COMPLETED
ZDM_CLEANUP_TGT ............... COMPLETED

Current status: SUCCEEDEDになりました！

すべてのフェーズがCOMPLETEDとなっており、PDBクローン作成から切替、datapatch、後処理、クリーンアップまで正常に終了しています。

ちなみに、今回は途中で2回ジョブを一時停止しています。

処理 実行時間
クローン作成まで 4分52秒
最終切替まで 約1分41秒
datapatch・後処理 2分53秒
合計 9分26秒

ジョブの開始時刻は13:57:59、終了時刻は14:57:30なので、全体では約1時間かかっています。

ただし、その大部分はリフレッシュ可能クローンの自動リフレッシュを確認したり、移行先PDBの状態を確認したりするための一時停止時間です。

ZDMが実際に処理していた時間は合計9分26秒でした。

今回は検証用の小規模なPDBなので、もちろんデータ量や環境によって実行時間は異なります。

これで、ZDM 26.1のInstant Deployとリフレッシュ可能クローンを使ったBaseDBからExaDB-XSへの移行が完了しました！

次は、移行先のExaDB-XSでPDBの状態やRAC両ノードからの利用、アプリケーション接続を確認してみます。

12. 移行後の動作確認

第11章で、ZDMジョブがSUCCEEDEDとなり、BaseDBからExaDB-XSへのPDB移行が正常に完了しました！

最後に、移行先PDBが両RACインスタンスでREAD WRITEになっていることを確認し、SCAN経由のSQL*Plus接続とSOEスキーマのデータ参照を確認します。

12-1. 移行先データベースとPDBの状態を確認

まずはExaDB-XSのノード1で、oracleユーザーからEXACDBに接続します。
CDBの情報を確認します。

SHOW CON_NAME;

SELECT name, db_unique_name, database_role
FROM v$database;

実行結果：

CON_NAME
------------------------------
CDB$ROOT

NAME            DB_UNIQUE_NAME                 DATABASE_ROLE
--------------- ------------------------------ ----------------
EXACDB          exacdb                         PRIMARY

移行先のEXACDBに接続しており、データベースロールはPRIMARYになっています。
続いて、BASEPDBの状態を確認します。

SELECT pdb_name,
       status,
       refresh_mode,
       refresh_interval,
       last_refresh_scn
FROM dba_pdbs
WHERE pdb_name = 'BASEPDB';

実行結果：

PDB_NAME        STATUS          REFRESH_MODE    REFRESH_INTERVAL LAST_REFRESH_SCN
--------------- --------------- --------------- ---------------- ----------------
BASEPDB         NORMAL          NONE                                      6032544

STATUS=NORMAL、REFRESH_MODE=NONEであり、通常PDBとして構成されていることを確認できました。
次に、RACの両インスタンスにおけるPDBの状態を確認してみます。

SELECT inst_id,
       name,
       open_mode
FROM gv$pdbs
WHERE name = 'BASEPDB'
ORDER BY inst_id;

実行結果：

   INST_ID NAME            OPEN_MODE
---------- --------------- ---------------
         1 BASEPDB         READ WRITE
         2 BASEPDB         READ WRITE

両インスタンスともREAD WRITEになっています。
これで、ExaDB-XSの2ノードRAC上でBASEPDBがオープンされていることを確認できました。
データベース再起動後もPDBが自動的にオープンされるよう、状態を保存しておきます。

ALTER PLUGGABLE DATABASE BASEPDB
  SAVE STATE INSTANCES=ALL;

SELECT con_name,
       instance_name,
       state
FROM dba_pdb_saved_states
WHERE con_name = 'BASEPDB';

実行結果：

CON_NAME   INSTANCE_N STATE
---------- ---------- --------------
BASEPDB    exacdb1    OPEN
BASEPDB    exacdb2    OPEN

exacdb1とexacdb2の両方でOPENが保存されました。

12-2. リスナーへのサービス登録を確認

PDBがオープンできていても、接続に使用するサービスがリスナーに登録されていなければ、アプリケーションから接続できません。

そこで、ExaDB-XSのノード1でgridユーザーに切り替えて、リスナーの状態を確認します。

sudo su - grid
lsnrctl status

出力されたサービス一覧を確認すると、次のサービスが登録されていました。

Services Summary...

Service "basepdb.example.oraclevcn.com" has 1 instance(s).
  Instance "exacdb1", status READY, has 1 handler(s) for this service...

The command completed successfully

BASEPDBのサービスが自動的に登録され、インスタンスの状態がREADYであることを確認できました。

12-3. SCAN経由でBASEPDBへ接続

最後に、移行先のExaDB-XSへSQL*Plusで接続してみます！
今回はExaDB-XSのノード1から、SCAN名とPDBサービス名を指定して接続しました。

sqlplus -L 'soe@//<target-scan>:1521/basepdb.example.oraclevcn.com'

SHOW USER;
SHOW CON_NAME;

SELECT SYS_CONTEXT('USERENV', 'SERVICE_NAME') AS service_name,
       SYS_CONTEXT('USERENV', 'INSTANCE_NAME') AS instance_name
FROM dual;

SELECT COUNT(*) AS customer_count
FROM soe.customers;

USER is "SOE"

CON_NAME
------------------------------
BASEPDB

SERVICE_NAME                                       INSTANCE_NAME
-------------------------------------------------- --------------------
basepdb.example.oraclevcn.com                      exacdb1

CUSTOMER_COUNT
--------------
       1051319

SCAN経由でBASEPDBへ接続し、接続先インスタンスがexacdb1であることと、SOE.CUSTOMERSを参照できることを確認しました。

13. まとめ

今回は、ZDM 26.1のInstant Deployとリフレッシュ可能クローンを使って、BaseDBのOCPU環境からExaDB-XSの2ノードRAC環境へPDBを移行してみました！

以前はOCIコンソールからBaseDB間でリフレッシュ可能クローンを作成してみましたが、今回はZDMを使うことで、BaseDBからExaDB-XSへの移行も実現できました。

実際に試してみて、特に印象に残ったのは以下の点です。

  • Instant Deployが便利！
    ExaDB-XSのノード1にZDMを配置して実行できたので、今回の検証では専用のZDMサーバーを別途用意する必要がありませんでした。

  • リフレッシュ可能クローンの差分同期が問題なく動作した！
    ZDM_PDB_REFRESH_INTERVAL=5を指定することで、5分間隔の自動リフレッシュを構成できました。実際にアラートログを確認すると、14:32と14:37にリフレッシュが実行され、SCNが進んでいることも確認できました。

  • -pauseafterで移行処理を段階的に進められた！
    今回はZDM_CLONE_PDB_TGTで一度停止して自動リフレッシュを確認し、その後ZDM_SWITCHOVER_SRCでも停止させました。各段階でPDBの状態を確認しながら進められるのは便利ですね。

  • ExaDB-XSの2ノードRACでPDBを利用できた！
    切替後はBASEPDBがNORMAL / NONEとなり、exacdb1とexacdb2の両インスタンスでREAD WRITEになりました。さらに、SCAN経由でSOEユーザーによる接続とデータ参照にも成功しています。

今回のZDMジョブは、最終的に以下の結果となりました。

項目 結果
移行元 BaseDB OCPU / BASEPDB
移行先 ExaDB-XS 2ノードRAC / BASEPDB
ZDMバージョン 26.1.0
移行方式 リフレッシュ可能クローン
自動リフレッシュ間隔 5分
ZDMジョブの最終状態 SUCCEEDED
ZDMの実行時間 9分26秒
ジョブ開始から終了まで 約59分31秒（検証のための一時停止時間を含む）

途中で自動リフレッシュの動作確認などを行ったため、開始から終了までは約1時間かかりましたが、ZDMに記録された処理時間の合計は9分26秒でした。

もちろん、実行時間はPDBのサイズやシステムの構成などによって変わりますし、実際の本番移行ではアプリケーションの更新停止、最終同期、接続先の切替なども計画する必要があります。

また、今回の検証では切替後のPDBがMOUNTEDのままとなったため、ZDM_SWITCHOVER_SRCの完了後に一時停止し、両インスタンスでREAD WRITEでオープンしてからZDMを再開することで、datapatchも正常に完了できました。

検証中に発生したトラブルと対処内容は、記事末尾のおまけ1〜3にまとめています。

ZDM 26.1ではPDBクローンによる移行ができるようになり、Instant Deployも組み合わせることで、BaseDBからExaDB-XSへの移行を比較的シンプルな手順で実施できることが分かりました！

BaseDBからExaDB-XSへの移行を検討している方の参考になれば幸いです。

おまけ1. ZDMのセットアップ時に容量不足でエラー

発生した事象

最初はZDMを、空き容量の少ないファイルシステムに配置していました。
その状態でzdmcliを実行したところ、初期セットアップでエラーになりました。

原因

setup.logを確認すると、ZDMの配置先には10GiB以上の空き容量が必要であることが分かりました。

minimum required free storage space 10485760 kb for '/home/opc/zdm/zdm26.1/zdmhome'

検証環境では、当初配置しようとしていた領域の空き容量が足りませんでした。

対処

十分な空き容量がある/u02へZDMキットを移動しました。

/u02/zdm-instant/zdm26.1

移動後、再度zdmcliを実行すると初期セットアップが正常に完了しました。

Instant Deployとはいえ、ZDMの展開先にある程度の空き容量が必要なので注意が必要です。

おまけ2. GLOBAL_NAMES=TRUEでORA-02085

発生した事象

最初のZDM移行ジョブでは、ZDM_PREPARE_TGTフェーズでエラーが発生しました。

Failed at phase: ZDM_PREPARE_TGT

PRGO-4086:
failed to query the "DB_LINK" details

SELECT count(*) FROM dual@ZDM_DBLINK_2

ORA-02085:
database link ZDM_DBLINK_2...
connects to BASEPDB...

原因

調べてみると、ExaDB-XS側のGLOBAL_NAMES初期化パラメータがTRUEになっていました。

GLOBAL_NAMES=TRUEでは、DB Link名と接続先データベースのグローバル名の一致が要求されます。

今回、ZDMが作成したDB Link名と接続先データベースのグローバル名が一致しておらず、ORA-02085となっていました。

対処

ExaDB-XSのCDB$ROOTでGLOBAL_NAMESを確認します。

SELECT inst_id, name, value
FROM gv$system_parameter
WHERE name = 'global_names';

今回のExaDB-XS側ではGLOBAL_NAMESがTRUEで、ZDMが生成したDB Link名と接続先のグローバル名が一致せず、ORA-02085が発生しました。
この検証では、移行先EXACDBのCDB$ROOTでGLOBAL_NAMESをFALSEに変更し、両RACインスタンスの値を確認しました。既存のDB Link運用に対する影響を確認してから変更してください。

ALTER SYSTEM SET global_names=FALSE
  SCOPE=BOTH SID='*';

変更後、ZDMジョブを再開します。

./zdmcli resume job -jobid 2

今度はZDM_PREPARE_TGTが正常に完了し、PDBクローンの作成まで進みました。

既存のDB Linkの運用ルールがある環境では、GLOBAL_NAMESの変更による影響を確認する必要があります。

おまけ3. PDBをオープンしないままdatapatchが実行されてエラー

発生した事象

リフレッシュ可能クローンの動作確認後、ZDMジョブを再開したところ、ZDM_DATAPATCH_TGTでエラーになりました。

Failed at phase: ZDM_DATAPATCH_TGT

Some of the -pdbs containers were not open.
Bad containers: BASEPDB

原因

このとき、ExaDB-XS側のPDBは通常PDBへの変換が完了していました。

PDB_NAME  STATUS     REFRESH_MODE
--------- ---------- ------------
BASEPDB   NEW        NONE

しかし、RACの両インスタンスでPDBはまだMOUNTEDでした。

INST_ID NAME     OPEN_MODE
------- -------- ----------
1       BASEPDB  MOUNTED
2       BASEPDB  MOUNTED

つまり、リフレッシュ可能クローンから通常PDBへの変換は完了していたものの、PDBをREAD WRITEでオープンする前にdatapatchが実行されたという状態です。

対処

REFRESH_MODE=NONEになっていることを確認してから、CDB$ROOTで以下を実行しました。

ALTER PLUGGABLE DATABASE BASEPDB
  OPEN READ WRITE INSTANCES=ALL;

両ノードでREAD WRITEになったことを確認します。

SELECT inst_id, name, open_mode
FROM gv$pdbs
WHERE name = 'BASEPDB'
ORDER BY inst_id;

INST_ID NAME     OPEN_MODE
------- -------- ----------
1       BASEPDB  READ WRITE
2       BASEPDB  READ WRITE

その後、ZDMジョブを再開しました。

./zdmcli resume job -jobid 2

今度はdatapatchが正常に完了し、ZDMジョブもSUCCEEDEDとなりました。

参考資料

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?