Migrate to Exadata Database
There is currently no content for this page. The Oracle AI Database@Azure team intends to add content here, and this placeholder text is provided until that text is added.
The Oracle AI Database@Azure team is excited about future new features, enhancements, and fixes to this product and this accompanying documentation. We strongly recommend you watch this page for those updates.
There is currently no content for this page. The Oracle AI Database@Azure team intends to add content here, and this placeholder text is provided until that text is added.
The Oracle AI Database@Azure team is excited about future new features, enhancements, and fixes to this product and this accompanying documentation. We strongly recommend you watch this page for those updates.
There is currently no content for this page. The Oracle AI Database@Azure team intends to add content here, and this placeholder text is provided until that text is added.
The Oracle AI Database@Azure team is excited about future new features, enhancements, and fixes to this product and this accompanying documentation. We strongly recommend you watch this page for those updates.
Oracle Data Guard supports high availability and disaster recovery by maintaining a synchronized standby database. For migration, you can set up a physical standby database in the target environment, such as new hardware, cloud infrastructure, or a different database version for an upgrade. Synchronize the standby database with the primary database, and then perform a switchover so that the standby database becomes the new primary database. This approach reduces downtime to seconds during the switchover.
This guide describes a physical standby configuration for migration based on standard practices. It assumes a single-instance configuration for simplicity. For Oracle Real Application Clusters (RAC) configurations, adjust the steps accordingly. For upgrades, such as from 12c to 19c, the standby database runs a higher database version by using mixed-version support, available from 11.2.0.1 and later. If applicable, use Zero Downtime Migration (ZDM) to automate cloud migrations.
Assumptions:
- The source (primary) server and the target (standby) server have compatible operating systems and sufficient resources.
- Oracle Database Enterprise Edition (Oracle Data Guard is included).
- Basic networking such as firewalls allow port 1521 for the listener and port 22 for SSH.
Solution Architecture

Prerequisites
Before you start, ensure the following prerequisites:
- Source Database:
- Run the database in
ARCHIVELOGmode.SELECT log_mode FROM v$database;The query returnsARCHIVELOG. If the database does not run inARCHIVELOGmode, enableARCHIVELOGmode. This change requires downtime:SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN; - Enable
FORCE LOGGING.ALTER DATABASE FORCE LOGGING; - Add standby redo logs (one more group than online redo logs, same size). Query
v$logfor sizes, then add standby redo logs for each thread:ALTER DATABASE ADD STANDBY LOGFILE GROUP <n> ('<path>') SIZE <size>; - Configure
tnsnames.oraentries for the primary database and the standby database. - Configure RMAN control file autobackup:
CONFIGURE CONTROLFILE AUTOBACKUP ON; - For upgrades, ensure that the source and target database versions are compatible per Oracle Support guidance. For example,
Doc ID 785347.1.
- Run the database in
- Target Server
- Install the Oracle binaries. Use the same database version, or a higher version for an upgrade.
- Create directories that match the source environment, for example:
/u01/oradata,/u01/frafor the Fast Recovery Area. - Configure SSH key-based access from the source to the target and from the target to the source for users such as
oracle. - Start the listener and configure
tnsnames.oraentries for the primary database and the standby database. - For Zero Downtime Migration (optional automation), install the ZDM software on a separate host and configure the response file.
- Networking
- Use Azure ExpressRoute (recommended) or Site-to-Site VPN Gateway to create a private, dedicated connection for consistent Data Guard synchronization to the Azure standby.
- Ensure the SQL*Net connectivity. Test
tnspingbetween hosts. - Configure time synchronization. Use NTP.
- Backup Storage
If you use ZDM or external backups.
- Ensure access to Object Storage, NFS, or ZDLRA.
- Tools (Optional)
- Use Oracle AutoUpgrade for upgrades.
- Use ZDM for cloud migrations. ZDM uses Oracle Data Guard automatically.
Use the following table to configure key initialization parameters on the primary database and propagate these parameter settings to the standby database.Parameter Value Example Purpose DB_NAME'orcl'Same on primary and standby. DB_UNIQUE_NAME'orcl_primary' (primary), 'orcl_standby' (standby)Unique identifier for Data Guard. LOG_ARCHIVE_CONFIG'DG_CONFIG=(orcl_primary,orcl_standby)'Enables sending/receiving logs. STANDBY_FILE_MANAGEMENT'AUTO'Auto-creates files on standby. FAL_SERVER'standby_tns'Fetch Archive Log server for gap resolution. LOG_ARCHIVE_DEST_2'SERVICE=standby_tns ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl_standby'Remote archive destination. - Prepare the Primary Database
- Enable the required features as SYS:
ALTER DATABASE FORCE LOGGING; ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(<primary_unique_name>,<standby_unique_name>)' SCOPE=BOTH; ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SCOPE=BOTH; - Add standby redo logs (for example, 3 online groups, add 4 standby groups).
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 4 ('/u01/oradata/standby_redo04.log') SIZE 100M; -- Repeat for additional groups. - Create a backup of the primary database using RMAN (include
archivelogsfor synchronization):CONNECT TARGET / BACKUP DATABASE FORMAT '/backup/db_%U' PLUS ARCHIVELOG FORMAT '/backup/arc_%U'; BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/backup/standby_ctl.ctl'; - Copy the backup files, password file (
orapw<sid>), and parameter file (init.oraorspfile) to the target server.
- Enable the required features as SYS:
- Prepare the Standby Database Server
- Install Oracle software (match or higher version for upgrade).
- Create necessary directories:
mkdir -p /u01/oradata/<db_name>mkdir -p /u01/fra/<DB_UNIQUE_NAME_upper>mkdir -p /u01/app/oracle/admin/<db_name>/adump - Edit the copied parameter file on standby:
- Set
DB_UNIQUE_NAMEto the standby value. - Set
FAL_SERVERto the primary TNS name. - Adjust paths if needed. For example,
CONTROL_FILES, DB_RECOVERY_FILE_DEST.
- Set
- Start the standby instance in
NOMOUNT:CREATE SPFILE FROM PFILE='/path/to/init.ora';STARTUP NOMOUNT;
- Create the Standby Database
- Use RMAN to duplicate the database from the active database :
CONNECT TARGET sys/<password>@primary_tns CONNECT AUXILIARY sys/<password>@standby_tns DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DORECOVER NOFILENAMECHECK;Alternative: If you use backup files, duplicate the database for standby from a backup location:DUPLICATE DATABASE FOR STANDBY BACKUP LOCATION '/backup' NOFILENAMECHECK; - On standby, start managed recovery:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
- Use RMAN to duplicate the database from the active database :
- Configure Data Guard
- On primary, set remote logging:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=<standby_tns> ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=<standby_unique_name>' SCOPE=BOTH;ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;ALTER SYSTEM SET FAL_SERVER='<standby_tns>' SCOPE=BOTH; - On standby:
ALTER SYSTEM SET FAL_SERVER='<primary_tns>' SCOPE=BOTH; - (Optional) Enable Data Guard Broker for easier management:
- Set
DG_BROKER_START=TRUEon both. - Create configuration:
DGMGRL> CREATE CONFIGURATION dg_config AS PRIMARY DATABASE IS <primary_unique_name> CONNECT IDENTIFIER IS <primary_tns>; - Add standby:
DGMGRL> ADD DATABASE <standby_unique_name> AS CONNECT IDENTIFIER IS <standby_tns>; - Enable the configuration:
DGMGRL> ENABLE CONFIGURATION;
- Set
- On primary, set remote logging:
- Verify Synchronization
- On primary, force log switches:
ALTER SYSTEM SWITCH LOGFILE; - On standby, check apply status:
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM v$managed_standby;Look for 'MRP0' applying logs.
- Check for gaps:
SELECT * FROM v$archive_gap;Should return no rows.
- Monitor lag:
SELECT NAME, VALUE FROM v$dataguard_stats WHERE NAME = 'apply lag';
Allow time for full sync before migration.
- On primary, force log switches:
- Perform Switchover (Migration Cutover)
- Stop applications connected to primary (minimal downtime starts here).
- Verify no gaps and stop recovery on standby:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - Using Broker (recommended):
DGMGRL> SWITCHOVER TO <standby_unique_name>;- Manual alternative:
- On primary:
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN; - On old primary (now standby):
STARTUP MOUNT; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; - On new primary (old standby):
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL PRIMARY WITH SESSION SHUTDOWN; ALTER DATABASE OPEN;
- On primary:
- Manual alternative:
- Verify roles:
SELECT DATABASE_ROLE FROM v$database;New primary should be
PRIMARY. - Redirect applications to new primary.
- (Optional) Decommission old primary or keep as new standby.
Optional: Upgrading During Migration
If you migrate to a later database version:
- Install the later-version Oracle Database binaries on the target server.
- After the step 3, activate the standby database for the upgrade:
ALTER DATABASE ACTIVATE STANDBY DATABASE; - Start the database in upgrade mode:
STARTUP UPGRADE; - Use AutoUpgrade:
- Create the configuration file.
- Run the following command.
java -jar autoupgrade.jar -config <file> -mode upgrade
- After the upgrade:
- Run the following command.
datapatch - Open the database.
- Continue with the database as the new primary database.
- Run the following command.
Using Zero Downtime Migration (ZDM) for Automation
For cloud migrations, for example, to Oracle Cloud Infrastructure (OCI):
- Install ZDM on a dedicated host.
- Create a response file with parameters such as
MIGRATION_METHOD=ONLINE_PHYSICAL,DATA_TRANSFER_MEDIUM=OSS, andTGT_DB_UNIQUE_NAME. - Run with an evaluation run first, and then run the full migration. Pause after the Data Guard configuration step for verification.
zdmcli migrate database -rsp <file> -sourcesid <sid> ... - ZDM automates the backup, standby database creation, and switchover.
Troubleshooting Tips
- Common errors:
- ORA-01110 (file mismatch): Check file paths.
- Apply lag:
- Verify the network connection and increase available bandwidth.
- For additional details:
- Review the alert log and Oracle Data Guard dynamic performance views, such as
v$dataguard_status
- Review the alert log and Oracle Data Guard dynamic performance views, such as
- Test the procedure in a non-production environment first.
- Refer to Oracle documentation for version-specific differences.
This process supports a near-zero-downtime migration.