Learn About Migrating with Oracle Data Guard

In all cases of migration using Oracle Data Guard, you can perform a “switchover” to a standby database, creating a primary database from the standby.

Two solutions are available when you use Oracle Data Guard for reduced downtime migrations. Both methods have a prerequisite of running on Oracle Data Guard compatible platforms.

When your goal is to migrate the source database to the destination and keep the database release the same, you can use the “Simple Data Guard” solution. When your goal is to upgrade your source database to a later version in addition to migrating the source database to the target, you would use the “Advanced Data Guard” solution.

The standby databases used in the migration process should be used only for migration purposes and not for disaster recovery. While you prepare for the migration, if you need to maintain a high availability disaster recovery solution, create multiple standby databases with one for migration and additional databases to meet your high availability requirements.

When you migrate a database by using Oracle Data Guard, you can use the following methods:

  • Simple Data Guard - With this solution, the source database is already at the target version for the new environment. A physical standby database is created on the new environment. When you are ready to complete the migration, a Data Guard switchover is performed and all applications begin to use the new primary database. As part of this process, you can ship redo from the new environment back to the source environment, to keep it current. If issues arise, a zero data loss switchover (fallback) can be done to return to the original configuration.

  • Advanced Data Guard - With this solution, the database is upgraded to a new version. Within this solution, there are two methods:

    • Transient Logical Rolling Upgrade - This method provides the least downtime. The time to upgrade the database version does not impact the primary source database. The upgrade is performed on the target standby database before switching over, leaving the source primary database open for use. After completing the upgrade, switch over to the upgraded target standby database and all applications begin to use the new upgraded primary database.

    • Data Guard Switchover and Upgrade - This method incurs downtime (2 hours or less) to upgrade the target database. You perform the switchover to the target database before performing the upgrade.

Optionally, as part of these processes you can use Oracle Transparent Data Encryption (TDE) to encrypt your existing data. You can optionally convert to Oracle Multitenant architecture by plugging your Oracle Database 12c or later non-CDB database as pluggable database (PDB) into a cloud container database (CDB).

About Using the Simple Data Guard Solution

This solution for migrating a database should be used when no upgrades or conversions to a multitenant architecture are required.

The following image provides the general flow for simple migration, for example to an Oracle Cloud environment.   

The prerequisites for the Simple Data Guard Migration are:

  • Source database can be Oracle Database 11g Release 11.2.0.4, Oracle Database 12c, or Oracle Database 18c.

  • The Oracle Home that is used by the standby database must be the same version as the original database, but can be a different bundle patch level, however the bundle patch used by the standby database must comply with Document 1265700.1 - Oracle Patch Assurance - Data Guard Standby-First Patch Apply.

  • The source platform and the destination platform must be compatible for a Data Guard configuration.

The high level steps for the Simple Data Guard Migration are:

  1. Prepare the Cloud environment and instantiate the Data Guard standby database in the target environment.

  2. Enable TDE and encrypt encrypt user data in the standby database.

  3. Perform a Data Guard switchover to the new environment so that applications use the database on the new environment.

    A minimal period of downtime will occur during the switchover. Allow Data Guard to ship and apply redo to the original database.

  4. If issues arise, execute a Data Guard switchover to return to the original configuration.

About Using the Transient Logical Rolling Upgrade Solution

This solution for migrating a database limits the downtime incurred when performing an upgrade. This solution should be used when the source database has no restrictions for using logical standby.

The following image shows the general flow using Transient Logical Rolling Upgrade to perform the migration to an Oracle Cloud environment.

The prerequisites for using the Transient Logical Rolling Upgrade solution are:

  • Source database can be Oracle Database 11g Release 11.2.0.4, Oracle Database 12c, or Oracle Database 18c.

  • The source database must be compatible with use of logical standby database.

  • The Oracle Home used by the target standby database must be the same version as the source database, but can be a different bundle patch leve. The bundle patch must comply with Document 1265700.1 - Oracle Patch Assurance - Data Guard Standby-First Patch Apply.

  • The source platform and the destination platform must be compatible for a Data Guard configuration.

  • A container database (CDB) with at least one pluggable database (PDB) must be created and operational from a database home of the target version in the target environment.

  • Apply Patch 22826718 in the destination non-CDB and CDB Oracle homes for pre-Oracle database 12c Release 12.2.0.1 environments. This patch allows you to use FORCE KEYSTORE changes while using a TDE AUTOLOGIN wallet without falling back to a password-based wallet.

The high level steps for the Transient Logical Rolling Upgrade solution are:

  1. Prepare the Cloud environment and instantiate the Data Guard standby database in the target environment.

  2. Upgrade the standby database using Transient Logical Rolling Upgrade.

  3. Enable TDE and encrypt user data in the standby database.

  4. Perform a Data Guard switchover to the new environment so that applications use the database on the new environment.

  5. If the source is non-CDB, convert the non-CDB database into a pluggable database.

  6. Fall back to the source database if required.

    If issues arise, you can perform a switchover to return the source database to its original primary status. Note that the target standby will not receive redo from the source database which could incur data loss.

About Using the Data Guard Switchover and Upgrade Solution

This solution for migrating a database incurs downtime while performing the upgrade and is used when the source database is restricted from using a logical standby database.

The following image provides the general flow using Data Guard Switchover and Upgrade to perform the migration to an Oracle Cloud environment.

The prerequisites for using the Data Guard Switchover and Upgrade method are:

  • Source database can be Oracle Database 11g Release 11.2.0.4, Oracle Database 12c, or Oracle Database 18c.

  • The source database is not compatible with use of logical standby database.

  • The Oracle Home used by the standby database must be the same version as the source database, but can be a different bundle patch level. The bundle patch must comply with Document 1265700.1 - Oracle Patch Assurance - Data Guard Standby-First Patch Apply.

  • The source and destination platforms must be compatible for a Data Guard configuration.

  • A container database (CDB) with at least one pluggable database (PDB) must be created and operational from a database home of the target version installed in the target environment.

  • Apply Patch 22826718 in the destination non-CDB and CDB Oracle homes for pre-Oracle Database 12c Release 12.2.0.1 environments. This patch allows you to use FORCE KEYSTORE changes while using a TDE AUTOLOGIN wallet without falling back to a password-based wallet.

The high level steps for the Data Guard Switchover and Upgrade method are:

  1. Prepare the Cloud environment and instantiate the Data Guard standby database in the target environment.

  2. Enable TDE and encrypt user data in the standby database.

  3. Perform a Data Guard switchover to the target environment so that applications use the database on the target environment, and then upgrade the database.

  4. If required, convert the non-CDB database into a pluggable database.

  5. Fall back to the source database if required.

    If issues arise, you can perform a switchover to return the source database to its original primary status. Note that the target standby will not receive redo from the source database which could incur data loss.