Oracle ZDM 21.5 new features

I have already written several articles about my experience migrating databases with Oracle Zero Downtime Migration. At that time, the version available was 21.4. The current version is now 21.5. Recently, I had the opportunity to patch our customer ZDM environment to 21.5 and to run new migrations in this new version. In this blog, I would like to share what new features brings the 21.5 version and also what I could see running the same kind of migration with the new version.

New 21.5 features for Physical Migration

Inflight Upgrades

We know that until 21.4, physical migration workflow required that source and target databases are in the same database major release. This of course due to Data Guard constrains.

With 21.5, Data Guard automation is changing to a migration methodology. There is no database release constraint any more. There is of course no change in the way Data Guard is working, but ZDM Physical Migration workflow now integrates and take in account in-flight upgrades. It is now possible to have source database in version 11.2.0.4 or 12c been migrated with physical online workflow to 19c or even from source 19c to 23ai.

In case source is a multitenant database, the temporary target database will be created in the same version as the source database. After switchover to this temporary database, ZDM will upgrade it using oracle tools.

In case source is a non-multitenant database, ZDM will perform the migration using a non-CDB temporary database and running a switchover to it, like I explained in my previous articles. Then ZDM will use autoupgrade to upgrade the database to the desired version and converting it to multitenant in the target CDB.

Cloud Native Disaster Recovery automation

Until 21.4, we had to manually create the Data Guard configuration in the cloud once the migration was performed. Version 21.5 now integrates a function to create Data Guard configuration in the target environment with ZDM once the migration is done. Customer can then benefit from a Cloud Native DR architecture having a standby database in the cloud.

New 21.5 features for Logical Migration

Oracle Autonomous Database as source

Oracle Autonomous Database as source database for migration is now supported. Migration from autonomous to autonomous is now possible. This will allow tiers, serverless and dedicated Exadata Infrastructure Autonomous Database move.

GoldenGate Enhancements

There is several enhancement for logical online migration supporting now following GoldenGate functions:

• Integrated and non-integrated replication mode
• Audit trail import
• Large Transaction split
• Pre-checks for ggadmin
• Feature groups, Constraint Handling, Concurrent Migrations
• User-specified GoldenGate Schema

Data Pump Enhancements

There is also further enhancements integrating following Data Pump functions:

• Dump file retention and reuse
• Advanced Queue Objects for post-import reload

Others…

There is some other new enhancements for logical workflow like:

• OCI File Storage Servie (FSS) for data transfer medium with Oracle Autonomous Database as target
• Automated refresh of Materialized Views if specified.

Offline Hybrid Migration

Version 21.5 brings a new migration method, the Offline Hybrid Migration using:

• RMAN transportable tablespaces for Data Migration
• Data Pump Export/Import for metadata

This method requires NFS as backup location and allows cross-endian and cross-version migration.

The supported targets are:

• Oracle Base Database Services (BaseDB)
• Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)
• Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) on Oracle Database@Azure
• Oracle Exadata database Service on Cloud@Customer (ExaDB-C@C)
• Oracle Exadata On-premises

My testing feedback

Running the same migration method, I could see following enhancements from 21.4 to 21.5:

• Bug correction like switchover issue (described in a previous blog)
• TEMP, SYSTEM, SYSAUX and UNDO tablespaces are now automatically encrypted by ZDM. No need to do it manually after the migration.

On the other side, I could find a new bug during the TEMP tablespace encryption. The problem is that the temporary database needs to be restarted to complete deletion of the previous TEMP tablespace. I could easily resolve manually the problem and completed ZDM migration. I will describe this workaround in a further blog.