Database Migration from non-CDB to PDB – The Fallback Challenge

There are several pitfalls when you plugin a non-CDB into a CDB environment. I’d like to highlight some of them – and show you potential workarounds as well. This is part of a series of blog posts to make your migration from non-CDB to PDB a bit smoother.

Photo by Sebastian Grochowicz on Unsplash

Database Migration from non-CDB to PDB – The Fallback Challenge

As I work with customers on upgrades and migrations for a very long time, I know how important a proper fallback is.

When you attempt a migration from a non-CDB to PDB, you need to plan the fallback as well. In this blog post I will highlight the different fallback options. Be always aware that you need to test your supposed-to-be-proper fallback upfront. There’s nothing worse than realizing that your backups don’t exist, that the recovery gets stuck because archives are missing – or it takes to long to restore from wherever. If you test it in the situation when you really rely on it, it may be too late to correct mistakes or false assumptions.

Always .. always … always!

First of all, the one fallback option you should always have in place, is one of the most simple ones. A valid online backup of your source database is a must. Regardless of what technique you choose.

And “online backup” does not mean “I’ve done a backup a while ago”. It means:

• You have taken a full online backup before this change
• Your archives, your controlfile and your spfile are backuped as well
• You have tested restoring your backup including all archives, controlfile, spfile
• You have recovered the backup and know how long will take

It is really crucial to go through this exercise if your database has some sort of significance. When you need to be back in business within 3 hours, you should know how long the restore and recovery takes. Just in case …

The good news: With the below techniques – if you do it the right way – your source system will remain intact and untouched.

But the real challenge is: What do I do if I need to fallback a few days after the migration happened?

Same-Endianness Migrations

In my blog posts about same-Endianness Migrations:

• 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

I tried to highlight the fallback options briefly within each blog post.

Generally speaking, I favor the first option (Upgrade, plug in, convert) over the other two for one simple reason:
For the database upgrade there is a proven and very well tested fallback.

But there is also an argument for the other techniques. Read more below.

Fallback: Upgrade, plugin, convert

Regardless of how you do the database upgrade before plugging in with this approach, you can flashback to a guaranteed restore point or you can downgrade the database, even in the case when you had changes before plugging in. Both fallback options for the database upgrade require that you didn’t change COMPATIBLE. But neither the AutoUpgrade nor dbupgrade nor the DBUA change COMPATIBLE as part of the upgrade. AutoUpgrade for instance creates a Guaranteed Restore Point by default.

I prefer this approach as you’ll have a 2-phase fallback. You can fallback if something goes wrong during the upgrade. And you have a fallback option which without any doubt requires more effort once you plugged in and completed noncdb_to_pdb.sql.

For noncdb_to_pdb.sql there’s no fallback possibility. The only option you have since Oracle 12.2.0.1 is to re-run it. But this is of course no fallback.

The plugin itself can’t be reversed either. Hence, there is no fallback option for this step.

Fallback: Plugin, upgrade, convert

When you use the “Plugin, upgrade, convert” approach, then your fallback options are limited. If your receiving CDB has COMPATIBLE at the same value as your source database, then you can potentially downgrade (and only downgrade!) the upgrade part of this technique. But you don’t win anything as you can reverse the plugin. Hence, I don’t consider this as an useful option – and it is not part of the below diagram.

Your only options are either an export and import with Data Pump or a synchronization of changes back to the original database with Oracle GoldenGate. In each case, it is very important that you operate with the COPY option of the plugin command. Otherwise your source won’t be in place anymore.

Fallback: Clone via NON$CDB, upgrade, convert

When you use “Clone via NON$CDB” then you have exactly the same fallback opportunities as in the previous example.

There are no potential fallback milestones during the process. Once you initiated it, you depend on the successful completion. You can only fallback once the process has been fully completed including the upgrade and the convert operation. You could – in theory – downgrade the PDB but you wouldn’t win anything. A fast flashback to a guaranteed restore point does not work as you can’t create a GRP at this point:

SQL> create restore point PDB1_GRP1 guarantee flashback database;
create restore point PDB1_GRP1 guarantee flashback database
*
ERROR at line 1:
ORA-39893: PDB restore point could not be created

Fallback Options for Cross-Endianness Migrations

For all other techniques where you migrate cross-Endianness, you have basically always only 1+1 fallback option:

• Data Pump expdp and impdp into your source environment.
• Oracle GoldenGate in case you seek minimal outage time for the fallback.

In all cases where you go across database versions, your default fallback is a full database export with Data Pump, followed by an import of the dump into a fresh database in your source environment. Please test this carefully and see the process described here in our Hands-On Lab exercise.

Oracle GoldenGate, of course, is a much smarter way as you have your source database still intact – and you can just send back the changes to source after going live in the new environment. Unfortunately, the devil is in the detail here.

Summary

What are your fallback options then for the entire process, from start to end?

You may have realized that I name this process always a “migration“. You change the database architecture and migrate your non-CDB to a PDB. And migrations, very different from upgrades, have usually limited fallback possibilities.

In all three above scenarios, you can’t go back directly within just one step. At first, there’s no reveres of the CREATE PLUGGABLE DATABASE command available. Once the non-CDB is part of the CDB, you can’t just unplug and revert into the original setup anymore.

Hence, it is VERY important that you always use the default COPY option. Even when you see in our Hands-On Lab exercise that we use NOCOPY, this has mainly to do with the space. The real downside of COPY versus NOCOPY or MOVE is that you need twice the disk space. For a very large database, this may be really an issue.

Also for noncdb_to_pdb.sql there is no fallback or reverse available. At least since Oracle Database 12.2.0.1, noncdb_to_pdb.sql is rerunnable which it wasn’t in Oracle 12.1. But still, the runtime of noncdb_to_pdb.sql depends a lot on the dictionary complexity and the number of objects needing recompilation. You will need to test carefully.

But basically, as soon as you plugin, this is the point of no return.

I personally prefer the Upgrade, plug in, convert (noncdb_to_pdb.sql) approach as you will have a proven fallback, even back to Oracle 11.2.0.4 for the upgrade part. And I’m a fan of multiple fallback milestones. By having more steps, I will have more possibilities of reverting – and it will be faster.

For cross-Endianness migrations your fallback options are the same as for non-CDB to non-CDB migrations.

And finally … a Minimal Downtime Fallback with Oracle GoldenGate example

Let’s assume you choose the recommended approach, Upgrade, plug in, convert.

If you are only interested in a seamless fallback, you need to setup Oracle GoldenGate to send all changes back from the new PDB to the source. But you upgraded your source before. Now you see why it is important to use the COPY option instead of NOCOPY. While you run noncdb_to_pdb.sql you flashback (or downgrade – but I’d recommend flashback here) your non-CDB to the guaranteed restore point created before the upgrade. Once this is completed, you can start the synch from the PDB to the non-CDB.

As I explained before, you can initiate Step 4 immediately after you kicked off Step 3. And of course only if you used the COPY option.

Looks a bit complex? Well, this is a migration …

And be aware that you still have the downtime for the database upgrade (Step 1), the plugin (Step2) and the conversion (Step 3). The purpose of this example is to show you only how to fallback seamless as as quickly as possible in case you have an issue in the new PDB after the migration. See the next blog post about Minimal Downtime Migrations from non-CDB to PDB if you are looking for an approach with less downtime.

Typical Plugin Issues and Workarounds

• 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

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