Database Migration from non-CDB to PDB – Overview

Today I’ll start a blog post series of several “how to” articles about database migration from non-CDB to PDB – Overiew. You’ll find a quick introduction below. And of course, the links to all the other related blog posts.

Database Migration from non-CDB to PDB – Overview

When you plan to move from non-CDB, the Oracle term for regular database deployments, to a Pluggable Database (PDB), you will migrate your database. It will become a PDB and run as part of a Container Database (CDB). This is a well known concept for several years now called Oracle Multitenant. If you have only one PDB, we call it Single Tenant.

Photo by Steven Wei on Unsplash

The concept of Oracle Multitenant has a lot of advantages especially when you can consolidate several databases. You can virtualize on the database layer without the need to take care on multiple OS installations. And especially the upgrade concept of upgrading everything at once automates a lot of tasks. See the Oracle Multitenant documentation for everything you’d like to know about the option.

You may have the question how you can migrate to Multitenant or PDBs. And I’d like to show you all options, and the necessary tasks to achieve your goals. And you’ll see below why I call it a migration – you will move your database in each of the possible techniques, sometimes combined with an upgrade.

In addition, I’d like to show you also the advantages of each possibility. And as usual, I’m open for your comments.

For an overview about which techniques exist to create a PDB, see the Oracle 19c Multitenant Guide.

Same-Endianness Migration

When your database is already on a same-Edianness operating system, you will have the following options:

• Upgrade, plug in, convert (noncdb_to_pdb.sql) – 11.2.0.4 and higher
• Plugin, upgrade, convert (noncdb_to_pdb.sql) – 12.2.0.1 and higher
• Clone via NON$CDB, upgrade, convert – 12.1.0.2 and higher
• Typical Plugin Issues and Workarounds

Same-Endianness means, that your source database runs on Intel Solaris for instance, and you’d like to move it to Linux. Windows, Intel Solaris and Linux are all Little Endian operation systems whereas IBM AIX, HP-UX and Sparc Solaris are Big Endians.

In addition, if you’d like to achieve minimal downtime, you can add Oracle GoldenGate to all the above possibilities on top.

Different-Endianness Migration

Our team has dealt a lot in the past years with customer projects where somebody migrates off a Big Endian operation system. In many cases I got involved, this was from IBM AIX to Linux, in many cases an Exadata or an ExaCC (Cloud at Customer) machine. In such cases, the following techniques can be used – and of course, all of them can be used for Same-Endianness Migrations as well.

• Migrate with Data Pump directly into a new PDB – 10.1.0 and higher
• Migrate with exp/imp directly into a new PDB – 9.2.0.8 and below
• Create new PDB, then transport tablespaces, then use Data Pump (FTEX) – 11.2.0.4 or higher
• Create new PDB, prepare PDB, then transport tablespaces, then rebuild dictionary meta information – 10.2.0.1 and higher

In the “transport” scenarios above you can decrease the downtime by using RMAN Incremental Backups. And if your goal is close-to-zero downtime, than Oracle GoldenGate will do a good job.

Things to know

In addition to these scenarios, I’d like to highlight also the special cases such as:

• Typical Plugin Issues and Workarounds
• The Compatible Pitfall
• The Time Zone Pitfall
• The Component Pitfall
• The Patch Level Pitfall
• Various Pitfalls
• The Fallback Challenge
• The Minimal Downtime Challenge

And of course, for some of the cases, I will picture the entire scenario.

My target will be always Oracle 19c (19.4.0) as this is the most recent database release.

Related Posts

• Upgrade, plug in, convert (noncdb_to_pdb.sql) – 11.2.0.4 and higher
• Plugin, upgrade, convert (noncdb_to_pdb.sql) – 12.2.0.1 and higher
• Clone via NON$CDB, upgrade, convert – 12.1.0.2 and higher

–Mike