Home / OCI

OCIRunbookAdvanced

Transformation: migrate Oracle Database to OCI Base Database with Data Guard and minimal downtime

A physical migration of an on-premises Oracle database to an OCI VM DB system. Build the target, instantiate a standby from an RMAN backup or duplicate, sync with Data Guard over FastConnect, switch over and make OCI the primary.

Deepak Bhardwaj3 min read

Applies toOracle Database 19c Enterprise Edition (on-prem, Linux x86-64), OCI Base Database Service VM DB systems, Data Guard, RMAN

When to use this method

Data Guard migration keeps the database physically identical — same version, same character set, every object and feature — and limits downtime to a switchover. It needs a compatible platform (same endianness) and matching major versions. ZDM's physical online workflow automates the same steps; this runbook shows them so you can follow and troubleshoot.

1. Build the target

  • Create a VM DB system with the same database version (and RU level or newer), Enterprise Edition, enough storage, in a subnet reachable from on-prem over FastConnect or VPN.
  • Note the DB system's DB_UNIQUE_NAME and the ORACLE_HOME.
  • Open port 1521 between both sides in both directions (NSGs and on-prem firewall).

2. Prepare the source

SELECT log_mode, force_logging FROM v$database;
ALTER DATABASE FORCE LOGGING;
-- If not in archivelog mode, enable it (needs a restart in mount state)
ALTER SYSTEM SET log_archive_config='DG_CONFIG=(ORCL_ONPREM,ORCL_OCI)' SCOPE=BOTH;
ALTER SYSTEM SET standby_file_management=AUTO SCOPE=BOTH;

Add standby redo logs (same size as online redo logs, one more group than online per thread):

ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 1G;

Copy the password file and the TDE wallet (if TDE is in use) to the target.

3. Instantiate the standby on OCI

Option A — RMAN duplicate from active database over the network (simple, uses bandwidth during the copy):

-- On the OCI host, start an auxiliary instance in NOMOUNT with a minimal pfile, then:
rman target sys@ORCL_ONPREM auxiliary sys@ORCL_OCI
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
  DORECOVER NOFILENAMECHECK
  SPFILE SET db_unique_name='ORCL_OCI' SET fal_server='ORCL_ONPREM';

Option B — restore from a backup in Object Storage (Oracle Database Cloud Backup Module): back up on-prem to a bucket, then restore on OCI as a standby. Better over slower links.

On DB systems created by the service, the existing database is usually dropped or its files reused by the duplicate — follow the documented "migrate using Data Guard" procedure for your DB system type so the cloud tooling (dbcli/dbaascli) still recognises the database.

4. Start redo apply and check lag

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
SELECT name, value, time_computed FROM v$dataguard_stats WHERE name IN ('transport lag','apply lag');

Configure the broker for easier switchover:

DGMGRL> CREATE CONFIGURATION migcfg AS PRIMARY DATABASE IS orcl_onprem CONNECT IDENTIFIER IS orcl_onprem;
DGMGRL> ADD DATABASE orcl_oci AS CONNECT IDENTIFIER IS orcl_oci;
DGMGRL> ENABLE CONFIGURATION;
DGMGRL> VALIDATE DATABASE orcl_oci;

5. Switch over

DGMGRL> SWITCHOVER TO orcl_oci;

Repoint applications (ideally through a DNS alias or a service-based connect string with both hosts). The on-prem database becomes the standby — your rollback path.

Tip

Rehearse the switchover and back again at least once before the production window. It proves both directions work and gives you real timings.

6. Finish

  • Enable automatic backups on the DB system; verify the first backup.
  • After the soak period, remove the on-prem standby from the configuration and add an OCI standby in another AD or region for DR.

Checklist

  • Same version/RU and platform compatibility confirmed
  • Force logging, standby redo logs, password file and wallet copied
  • Standby instantiated; apply lag near zero
  • Switchover rehearsed both ways
  • Backups and DR standby configured on OCI

Related fixes