Should you attempt double-hop Oracle Database upgrades?

Posted on December 13, 2024 by Lifetime Support Policy Oracle Database 19c Oracle Database 23ai Release Schedule 6

A long while ago I wrote a blog post about multiple-hop upgrades. And just recently I received many questions about whether one could skip Oracle Database 19c, and rather move into Oracle Database 23ai directly. So, the ask is: Should you attempt double-hop Oracle Database upgrades? 

Should you attempt double-hop Oracle Database upgrades?

Photo by Nik on Unsplash

What is a double-hop or multiple-hop upgrade?

Let me clarify the self-invented term here at first. In every Oracle database release we define the minimum database version you can directly upgrade from. With “upgrade” we refer to using the scripts or tools such as AutoUpgrade. Please don’t mix this with patching.

  • Oracle 18c to Oracle 19c – this is an upgrade
  • Oracle 10.2.0.4 to Oracle 12.1.0.2 to Oracle 19c – this is a double-hop upgrade
  • Oracle 19.21.0 to Oracle 19.25.0 – this is NOT an upgrade, this is patching

You always have an escape route of using Data Pump or Transportable Tablespaces to move between releases. For instance, you can still export with expdp from Oracle 10.2.0.4, and import directly into a PDB in Oracle Database 23ai. And for those of you who still use some older releases, you could even use exp to export from an Oracle 8i database, and imp directly into Oracle Database 23ai.

When we talk about a double-hop upgrade, we mean that you upgrade from version A to version B, and then right away to version C because an upgrade from version A to version C directly would not be supported. And multiple-hop upgrades are similar but you have even more versions included in the process.

Heads up here (very important!!): We never test such upgrades, we only test the versions marked as supported in the Database Upgrade Guide.

You may face then an additional constraint, the operating system version. Plus, in addition we don’t support the non-CDB architecture since Oracle Database 21c anymore. Hence, things may get really complex and require lots of stunts.

Our dogma is: Keep things as simple as possible to reduce risk. And clearly, doing such multiple hops involves a lot of changes, tasks, and it is typically the total opposite of “keep it simple”.

 

Do we support multiple-hop upgrades?

You can consult the Database Upgrade Guide for Oracle Database 23ai and you may be surprised:

If you cannot carry out a direct upgrade, then upgrade to the most recent release where direct upgrades from your earlier release Oracle Database are supported.

Note:

For any multi-step upgrade, if you must carry out two upgrades to upgrade to the current release, then you must run the AutoUpgrade preupgrade checks twice: First, run the checks and complete an upgrade to an intermediate upgrade release that is supported for direct upgrade to the target upgrade release. Second, run the AutoUpgrade preupgrade checks for the target upgrade release, and upgrade to the latest release.

For example, if the database from which you are upgrading is running Oracle Database 12c Release 2 (12.2) then to upgrade to Oracle Database 21c, follow these steps:

  1. Upgrade Release 12.2 to release 21c, using the instructions in Oracle Database Upgrade Guide 21c, including running an AutoUpgrade precheck for 21c.
  2. Upgrade Oracle Database 21c directly to Oracle Database 23ai. Use the instructions in this book, Oracle Database Upgrade Guide, including running the preupgrade script for Oracle Database 23ai.

The documentation even lists a table guiding you to the potential route.

So, yes, we do support multiple-hop upgrades as long as you follow the supported track.

But we clearly recommend against this approach.

 

Why are we not recommending it?

Let us map this to a real world example which isn’t even made up by myself. It is one of the questions I received just a few weeks ago. And this will show the entire complexity of this approach.

The customer is still on Oracle Database 11.2.0.4 but you can exchange this with 12.1.0.2 as well for any random example. Their current OS version is RHEL 6 – which is not under support anymore as far as I am aware.

The next step would be Oracle 19c for either release, 11.2.0.4 or 12.1.0.2. Oracle Database 19c is the highest release you can upgrade to, and it will be the lowest requirement to move forward to Oracle Database 23ai. So, on paper we will see now a double-hop upgrade:

  • Move from Oracle Database 11.2.0.4 to Oracle Database 19c
  • Move from Oracle Database 19c to Oracle Database 23ai

Two hops – double-hop.

Easy, right?

But let us take the OS versions into consideration. Oracle 11.2.0.4 is operated on RHEL6. But you can’t install Oracle Database 19c on RHEL6. When you follow my blog, you read that Oracle Database 19c is supported on Linux 7, Linux 8 and Linux 9. Good news is that Oracle 11.2.0.4 could be operated on Linux 7 as well.

Why don’t you upgrade your OS to Linux 7 at first?

Well, at first, upgrading the OS with the Oracle stack in place is not supported in this old Linux release. But even if you’d do it, will it bring you further? Not really since Oracle Database 23ai requires a minimum of Linux 8.

Now, I know that many would purchase new hardware as part of such a move. And you’d hope that you could operate the new hardware with Linux 8 allowing 19c and 23ai on the same machine. Well planned – let me see how this approach would map now best.

  1. Upgrade the OS from RHEL6 to RHEL7 on the source machine – this is clearly downtime. You may be able to avoid this by building an 11.2.0.4 standby on a separate RHEL7 system.
  2. Then install Oracle Database 19c on the source machine
  3. Install Oracle 19c and Oracle 23ai on the new hardware using Linux 9.2 or higher
  4. NOW your DOWNTIME can begin
  5. Upgrade from Oracle 11.2.0.4 to Oracle 19c on the source machine
  6. Build a standby database between 19c on source and 19c on target
  7. Activate the standby, put it in upgrade mode and upgrade it to 23ai. This will include a conversion to the CDB architecture in addition

In summary, you’d have the first downtime when you upgrade the OS on source, then you have another downtime for upgrading 11.2.0.4 to 19c, then you need time to setup the standby – and since you never tested with 19c and never had any plans to go-live with 19c, this entire process is downtime again. And then you have downtime for the plugin, upgrade and conversion to Oracle Database 23ai.

On paper, this looked all easy, right? Go from release A to release B, and then straight to release C.

But in reality … this is complex – and what if something goes wrong?? And even if the source 11.2.0.4 or 12.1.0.2 database would be already on Linux 7 the complexity wouldn’t be lesser. Of course, you would not need the source OS upgrade – but everything else would stay as it is.

And finally, did you plan your rollback? And even more important, did you test it?

 

Rollback could be fun

You all know about Murphy’s Law. “Anything that can go wrong will go wrong.”

Or the shorter version is: “We work in IT.”

What are the options of moving back to start in case something goes wrong in this process? Well, for the upgrade part on the source server from 11.2.0.4 or 12.1.0.2 to 19c, AutoUpgrade sets a Guaranteed Restore Point (GRP). And even for a Standard Edition 2 database (SE2) you would have the possibility of using the downgrade process.

But what if you switched to the new server?

Now it is getting very tricky. You can’t go back to a GRP anymore since you migrate your 19c non-CDB into a 23ai PDB. No GRP is protecting you here anymore. And downgrade to 19c non-CDB does not work either. In this case, expdp/impdp will become your best friend. This will work, you can expdp from Oracle 23ai, and impdp back into 11.2.0.4 or 12.1.0.2. But obviously this will take time.

Did you test this? How long will it take?

Which brings me to the final part of this blog post.

 

Testing??

You need to test this entire process. And not only once but since it is that highly complex, I’d recommend you several test runs. Unless you have a 1:1 testing environment where you can simulate the whole process end-to-end, I would strongly advice against such a complex plan.

And please remember also to test fallback and rollback. Everything needs to be done multiple times to ensure it will work also under pressure in the unlikely event of things going bad.

This alone makes the whole process to me something I would not recommend.

Let me recap why you wanted to do this: You wanted to skip Oracle Database 19c, right? So, by not upgrading to Oracle Database 19c early enough you created such a risky project.

I would not feel well – and rather (big recommendation) upgrade to Oracle Database 19c now, especially under the consideration that we extended the Premier Support until end of 2029.

If you would upgrade to Oracle Database 19c now, you will have many comfortable years with Premier Support, you can easily evaluate Oracle Database 23ai without pressure once it is generally available on-prem, and then you can step up.

 

Summary

Putting all the pieces together, I can tell you that – even though we do support multiple-hop or double-hop upgrades – we highly recommend against it for the following reasons:

  • Multiple-hop upgrades are not tested, we test only upgrades from the minimum upgrade-supported version
  • Complexity is very high – and it is risky
  • Rollback and fallback are complex and require lots of downtime

Our firm and strong recommendation is:

  • Upgrade to Oracle Database 19c now if you haven’t already
  • Introduce the CDB architecture since you can do this easily with AutoUpgrade
  • Once Oracle Database 23ai is available on-prem generally, test it and move to it once you feel ready

Less complexity, a proven approach – and easier to rollback in case of any issue.

And you can use one single AutoUpgrade tool for the upgrade to Oracle Database 19c, regardless of whether you plan to introduce the CDB architecture now or later.

 

Overview

Here is an overview about the release requirements to upgrade to a newer release. Find the links to the individual documentation below in the Links section. I added this for your reference in case you are curious or need to find out specific routes being possible and supported.

 

Further Links and Information

–Mike

Tags:

You may also like...

6 Responses

  1. Doru Crinta says:
    December 13, 2024 at 11:37

    Good morning Mike,

    Would you be kind to explain, if possible/allowed, why is Oracle delaying the release of 23ai for on prem?
    I see the same game at play for WLS 14.1.2 – announced for this year and we are one week before Christmas with nothing in sight.
    We need to plan these upgrades&migrations and they create huge dependencies in our systems and all we get from Oracle is – coming soon.

    Reply
    • Mike.Dietrich says:
      December 16, 2024 at 18:14

      Hi Doru,

      I can’t tell you because I know exactly the same as you which is in MOS Note:742060.1.
      You may please contact your Oracle Sales rep and raise your concerns (which I fully see and understand).

      Thanks and kind regards
      Mike

      Reply
    • DBA says:
      December 19, 2024 at 12:07

      Hi,
      Same here (expecting the 23ai on prem) we saw a few weeks ago in 742060.1 that Oracle pushed forward the Premier Support for 19c up to December 31, 2029 (initally it was around April 1st, 2026).
      Our guess here is that Oracle meets some difficulties releasing the on prem binaries.
      No big deal for us as our main goal is to keep running on supported versions, no need for fancy new features (and the associated bugs or behaviour changes).

      Reply
      • Mike.Dietrich says:
        December 19, 2024 at 16:23

        Hi,

        I don’t think that this is the reason. 23ai is available on-prem for Exa and ODA already, and of course in our cloud. Then as the Free Dev edition, and the “beta” is available as well which is equivalent to what we ship for Exa/ODA-VM.

        Let’s wait and keep an eye on MOS 742060.1

        Cheers,
        Mike

        Reply
  2. Martin Wendler says:
    December 13, 2024 at 13:03

    Hi Mike,

    thanks for this blog entry.
    I did some double-hop migrations recently – from 12.1.0.1 to 19c. Fortunately, most of the systems were old enough to replace them, so I could start on newer hardware, installing 12.2.0.1 and 19c and restoring a backup from 12.1.0.1.
    Then I was able to upgrade, first to 12.2.0.1, finding out that there must have been an issue with audits in 12.1.0.1, what led to big delays in upgrade. After deleting the audit trail, upgrading to 12.2.0.1 and after that to 19c was no problem…

    Kind regards,
    Martin

    Reply
    • Mike.Dietrich says:
      December 16, 2024 at 18:12

      Thanks Martin,

      and you are right – I forgot to mention all those nice surprises I may have put in the back of my brain somewhere 🙂
      But this adds lots of “fun” to the project, you are right.

      Cheers,
      Mike

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mike Dietrich
Oracle Vice President of Product Management and Development for Database Upgrade, Cloud Migrations and Patching writing just another blog.

Opinions certainly are my own as is this page.

Archives

Categories

Upgrade @YouTube

Subscribe via Email

Join 11.3K other subscribers