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
My blog post from 2017 (upgrade a PDB from 12.1 to 12.2 on WINDOWS) is still one of the most accessed ones (besides ODA stuff). I also try to convince people to use the free Single-Tenant option as it has so many benefits…
Hi Mike. Thank you for this very informative blog. I have a question for you, if I may. We are currently at Version 18.14, and we are not converted to multitenant architecture. While preparing to upgrade to 19c, I of course found out that 19c is the last version to support non-multitenant databases. After reading many entries in your blog, you have convinced me that it’s a very good idea to use AutoUpgrade.jar to take care of the conversion to multitenant as well as the upgrade. Thinking that we still had time, our shop has not read up on multitenant administration. Should I wait to upgrade and convert sometime in the future, after we have learned about multitenant, or should we go ahead and upgrade/convert soon, since Oracle has stopped supporting Version 18, and learn-on-the-job? I would appreciate any thoughts and guidance you can provide. Thank you!
Hi Lynne,
solely from a customer’s perspective you don’t have to move to Multitenant right now. You can have 3 PDBs at no extra license cost (just make sure to set max_pdbs=3 in all your SPFILES to avoid any license violation happening by accident). So this is tempting.
But you should also be sure that your processes (backup/recovery, monitoring, scripts, jobs – and not to forget, application connections) still work fine. Of course, you will build up knowledge quickly – and we have some recorded seminars in the video section on the blog to guide you.
But it all depends on your testing time. The move is done quickly, the operation of the database will be similar or the same – but your scripts etc need to work.
So my honest recommendation usually is:
If you never touched Multitenant and you are going to 19c now, identify 2 or 3 databases which are not your biggest ones, not your most important ones – but they should be part of your B&R concept, part of your monitoring, part of your daily operations. But not those your business and operation depends on.
Then you will gain experience quickly – and at some point people (and especially developers) see the benefit.
Hope this helps ๐
Cheers,
Mike
Hi Mike!
I’m trying to migrate a non-cdb database to a pdb. I’m using this command:
CREATE PLUGGABLE DATABASE prfaro using ‘/tmp/pritsm_270422.xml’ copy
FILE_NAME_CONVERT =(‘+DATA_PRITSM’,’+DATA_PRFARO/faro_data/’);
AT the end of the process fails with this errors:
ERROR en linea 1:
ORA-01119: error al crear el archivo de base de datos ‘+DATA_PRFARO/faro_data’
ORA-17502: ksfdcre:4 Fallo al crear el archivo +DATA_PRFARO/faro_data
ORA-15005: name “faro_data” is already used by an existing alias
Changing the target path in file_name_convert it works:
SQL> CREATE PLUGGABLE DATABASE prfaro using ‘/tmp/pritsm_270422.xml’
2 copy
3 FILE_NAME_CONVERT = (‘+DATA_PRITSM’,’+DATA_PRFARO’);
Base de datos de conexion creada.
What is it wrong?
Regards!
Hi Alf,
you need only the base disk group – everything else is handled by ASM and OMF.
Cheers
Mike