Blogs

Migrate to OCI using Cross-Platform Transport of a PDB Using Inconsistent Backups

Introduction

RMAN offers to transfer data between platforms in a multi-tenant setting. You can move an entire multitenant container database (CDB), the root container only, or one or more pluggable databases (PDBs) across platforms. Images copies or backup sets can be used for cross-platform transmission. We can transport a closed PDB with consistent backup or an opened PDB using inconsistent backups. During the cutover, we will take consistent backup by shutting down the PDB. The latter would be ideal for reducing the downtime of the migration.

When the PDB is open, you create cross-platform inconsistent backups. You can use a combination of inconsistent and consistent backups to transport a PDB and plug it into the destination CDB that is on a different platform. As I mentioned previously, inconsistent backups enable you to reduce the application downtime because the PDB can be opened for read-write access while the backup is being performed. The first backup is an incremental level 0 backup. The subsequent backups are incremental level 1 backup that contains changes made to the PDB since the last incremental backup. There is no restriction on the number of inconsistent level 1 backup. Finally, close the PDB, and create the last consistent incremental backup and the XML file containing the metadata required to plug the source PDB into a destination CDB.

In this blog post, I will be talking about how to migrate on-premises PDB to Oracle Cloud using Cross-Platform Transport of a PDB Using Inconsistent Backups.

In our lab environment, the source CDB is running on a VM. We assume the source database is our on-premises environment. Whereas the destination CDB is an Oracle Base Database DB System in the Oracle Cloud (DBCS). The RMAN backups will be transported from on-premises to the Oracle Cloud using the Oracle Storage Gateway running in our on-premises data center. We have a second Storage Gateway running in the OCI that is configured with the destination database server. We will download backup pieces into the File Storage service mapped as NFS mount in the destination database server. If you are new to the Storage Gateway concept and wondering how it works, please refer to my previous blog.

Let’s get started.

 

Prerequisites:

1. The migration method discussed in this blog can be used only if the on-premises platform is a little-endian
2. Database character sets of the on-premises database and the Database service database should be compatible
3. The COMPATIBLE parameter on the source CDB and destination CDB must be set to 12.2 or higher according to the database version. In our case, it is set to 19.0.0.0
4. Target CDB is already created in DBCS
5. Both source and target databases are in archive log mode

 

These are the high-level steps:

Phase 01:

1. Note the source CDB database SCN before a level 0 backup is created
2. Create a cross-platform incremental level 0 backup of the PDB that must be transported.
3. The backup will be transported to the destination server through the storage gateway
4. Restore the cross-platform inconsistent level 0 backup of the source PDB on the destination CDB

 

Phase 02: (Cutover)

5. Create a consistent incremental backup
   • Export the encryption key for the source PDB. (Optional for non-TDE)
   • Close the source PDB being transported

5.3 Create a consistent cross-platform incremental backup. The point-in-time for the incremental backup must be from the SCN noted in Phase 01: Step 01

6. Apply the cross-platform incremental backup created when the source PDB was closed to the data files restored in Phase 01: Step 04
7. Change the PDB name to a new name (Optional)
8. Fix plugin violations
9. Open the transported PDB in Read-Write mode
10. Perform post-migration verifications

 

Phase 01 steps in detail:

1. Note the database SCN before a level 0 backup is created

2. Create a cross-platform incremental level 0 backup of the PDB that must be transported by using the BACKUP … PLUGGABLE DATABASE command

run {
BACKUP INCREMENTAL LEVEL 0
FOR TRANSPORT  
ALLOW INCONSISTENT
PLUGGABLE DATABASE DB0309_FINDB FORMAT '/mnt/u01/upload/basedir/backups/DB0309_P01/DB0309_FINDB/level0.bck';
}

3. The backup will be transported from the on-premises storage gateway to the OCI

       3.1 On-Premises storage gateway: Backup is uploading

 

       3.2 On-Premises storage gateway: Backup upload is completed

 

       3.3 OCI Object Storage Bucket: Backup has been uploaded

 

       3.4 Backup piece has been downloaded to the destination server

 

4. Restore the cross-platform inconsistent level 0 backup of the source PDB on the destination CDB

   Note: Change the backup piece permission and ownership to Oracle user.

run {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
RESTORE FOREIGN PLUGGABLE DATABASE DB0309_FINDB TO NEW
FROM BACKUPSET '/mnt/u01/download/basedir/basedir/backups/DB0309_P01/DB0309_FINDB/level0.bck';
}

 

As of now, the source database is still up and running. Let’s insert some test data before the cutover. This is to test our strategy and the data should be available on the destination PDB after restoring the incremental backup.

 

Phase 02 (Cutover) steps in detail:

5. Create a consistent incremental backup

This is the stage where the downtime starts. TDE is configured in our source database therefore, we must perform the below steps before shutting down the source PDB.

 

       5.1 Export the encryption key for the source PDB. (Optional for non-TDE)

 

       5,2 Close the source PDB being transported

 

       5.3 Create a consistent cross-platform incremental backup. The point-in-time for the incremental backup must be from the SCN noted in Phase 01: Step 01

run {
BACKUP INCREMENTAL FROM SCN 2638179
FOR TRANSPORT
UNPLUG INTO '/mnt/u01/upload/basedir/backups/DB0309_P01/DB0309_FINDB/metadata_DB0309_FINDB.xml'
PLUGGABLE DATABASE DB0309_FINDB FORMAT '/mnt/u01/upload/basedir/backups/DB0309_P01/DB0309_FINDB/level1.bck';
}

Like level 0 backup, the incremental backup taken from SCN will be automatically copied over to the destination server through the Storage Gateway.

 

6. Apply the cross-platform incremental backup created when the source PDB was closed to the data files restored in Phase 01: Step 04

run {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
RECOVER
USING '/mnt/u01/download/basedir/basedir/backups/DB0309_P01/DB0309_FINDB/metadata_DB0309_FINDB.xml'
FOREIGN DATAFILECOPY
'+DATA/DB0309_C01/F67C8569E03BE2E4E053D000000A5118/DATAFILE/sysaux.273.1131483575',
'+DATA/DB0309_C01/F67C8569E03BE2E4E053D000000A5118/DATAFILE/system.270.1131483575',
'+DATA/DB0309_C01/F67C8569E03BE2E4E053D000000A5118/DATAFILE/undotbs1.275.1131483575',
'+DATA/DB0309_C01/F67C8569E03BE2E4E053D000000A5118/DATAFILE/datasmall.272.1131483575',
'+DATA/DB0309_C01/F67C8569E03BE2E4E053D000000A5118/DATAFILE/datamedium.274.1131483575',
'+DATA/DB0309_C01/F67C8569E03BE2E4E053D000000A5118/DATAFILE/users.277.1131483575'
FROM BACKUPSET '/mnt/u01/download/basedir/basedir/backups/DB0309_P01/DB0309_FINDB/level1.bck';
}

 

7. Change the PDB name to a new name. (Optional)

We can see a PDB has been created with a system-generated name (DB0309_C01_11562) on the destination server. We will change it to the original name as it was on the source database.

 

8. Fix plugin violations

We can see some errors in pending status in the PDB_PLUG_IN_VIOLATIONS dictionary view. We will fix them as below.

 

Run @$ORACLE_HOME/rdbms/admin/catclust.sql in the PDB to fix the Database option RAC mismatch. This mismatch comes from CDB in OCI database cloud service is a RAC database whereas our source PDB was non-RAC. After executing the catclust.sql the issue was fixed.

 

Fix for Interim patch 34786990/25032666 (OJVM RELEASE UPDATE: 19.18.0.0.230117 (34786990)): Installed in the CDB but not in the PDB.

 

Apply the data patch as below.

/u01/app/oracle/product/19.0.0.0/dbhome_1/OPatch/datapatch -verbose -apply 34786990/25032666 -force -pdbs DB0309_FINDB

 

 Perform the following steps to encrypt tablespaces online

 

Import the encryption key (Not showing as a plugin violation but if you get this error perform the below steps). Switch to the target PDB and import the encryption key as below.

administer key management import keys with secret Welcome1 from '/mnt/u01/download/basedir/basedir/backups/DB0309_P01/DB0309_FINDB/exportDB0309_FINDB.exp' force keystore identified by <Password> with backup;

administer key management use key 'AQt/xb9gJU+kv592rFe/P98AAAAAAAAAAAAAAAAAAAAAAAAAAAAA' force keystore identified by <Password> with backup;

 

9. Open the transported PDB in Read-Write mode

 

10. Perform post-migration verifications

Verify the test data that was created in the source PDB is available on the migrated PDB as follows.

 

This concludes our database migration to OCI using Cross-Platform Transport of PDB Inconsistent Backups. By using incremental backups, we can minimize downtime. Using Oracle Storage Gateway Service, we can easily transport backups from on-premises to the Oracle Cloud. Alternatively, we can perform minimum downtime migration using ZDM and Oracle Database Migration Service (DMS). Please refer to the link for more information.

More from this Author