If you are starting an upgrade plan, do it directly to Oracle Database 19c.
Why?
Well, let’s agree that 19c is “equivalent” to 12.2.0.3 on previous version models, and 18c would be 12.2.0.2, after the latest in the old format: 12.2.0.1. So, thinking reasonably, you would already plan for latest PSU on the future version, right? Well, this is 19c.
But not only this: it’s well known that Oracle’s Terminal Patchset is the Long Term Release for each version. And for the 12.2 family, this is 19c.
The image below should help to clarify this:
In summary, since August 1, 2019:
– 11.2.0.4 is already on Extended Support (20% more expensive unless you have ULA)
– 12.1 family is already on Extended Support (20% more expensive unless you have ULA)
Which only leave us with the 12.2 family. Now I ask you, why jump to any “PSU” other than the final one? Also, support on 12.2.0.1 goes only until Nov 2020 and for 18c (12.2.0.2) only until June 2021, while 19c goes up to 2026 with ES/ULA!
I’m not even raising the great improvements we have on newer versions (if you are in 11.2, shame on you, you are basically six years behind the world, technology-wise). I have already migrated several databases on different clients to 19c and it’s running preeeetty fine. So trust it!
Ok, so migrating to 19c? Here are some tips:
– To migrate directly to 19c, you need to be on a supported terminal patch set (11.2.0.4, 12.1.0.2) or on 12.2 family (12.2.0.1, 18c).
– Get in touch and use the AutoUpgrade mechanism (you’ll love it!) – AutoUpgrade Tool (Doc ID 2485457.1)
– Check Upgrade Guide
– Have a look at Mike Dietrich blog for news.
– Test it before doing in production.
Additional reference:
Release Schedule of Current Database Releases (Doc ID 742060.1)
Count on Pythian to help you along this process!
6 Comments. Leave new
Agree. But obvious with some below additions
1. Application connected to existing Lower version DB must be compatible to Oracle 19C with respect to Deprecated features and functionality must be adapted in existing applications connected to lower DB version to take advantage of going directly to oracle 19c
And Application must consider Architectural difference +ve and -ve side to avoid problems later.
Absolutely, thanks Sandip!
Same here, I agree with the main topic – stop migrating databases to 12c, if migration is needed go directly with 19c.
But there is nothing to shame about being still on 11.2 .
Most of the applications are very happy to run on this version.
In addition, version 11.2.0.4 is one of the most stable versions, from point of view of Operations, I met in my professional life.
And stable Operations is one of the most, if not even the most important requirements from the business application side.
Never heard serious complains from businesses if “great new feature XYZ” is not available in the database version they are currently using.
But they will immediately raise big pressure on you, if the Oracle database processes are crashing too often or if you inform them once..twice per month, that there will be some service interruption or even downtime, because the next one-off patch needs to be applied.
There is still a long way to go for Oracle to reach similar stability on the current versions.
Even worse, personally, I have the impression, that the QA teams/processes within Oracle company are not keeping up with the fancy “one-new-version-a-year” product cycle … :-)
Anyway, Pythian team – keep up writing your blog articles, they are very informative, I like them.
Regards, Silvio
I totally agree. Thanks Silvio!
Oracle agrees as well, a good prove is the recent adjustment on the support matrix to ensure “market “, based on the need that their own softwares (Forms and others) are not attending to a allow a database upgrade.
It’s kind of related to what Sandip also commented.
Thanks for the feedback, we appreciate it!
In Pur env we are migrating the databases from 11gr2 to 19c. 11g db on one server1 and 19c db on server2.
Is it possible to use rman duplicate in migrating the data
Hello Sharath,
If I got it right, there are 2 main movements on this migration:
1. Moving servers
2. Upgrading database
There are dozens of different strategies to accomplish it, such as having a database 11g in recover mode on node 2 constantly (it could be a DG if you have the license) to at the point of migration: 1) complete recover and open the db; 2) Proceed with the upgrade. This would most likely be a good plan with a reduced downtime window and proceeding with a physical copy of the data using RMAN.
There are of course other strategies, like using GGate for a zero downtime migration and so on.
To answer your question, you can use RMAN on the scenario we mentioned above, but RMAN cannot be used to transfer logical data, only physical blocks and files. It can be of some use if you plan to do some sort of copy of business data on a tablespace level (using transportable tablespaces).
Some things are important for this migration, like the exact patchset level for your 11g (is it 11.2.0.4?).
As I said there are tons of possibilities to either make the process faster, reduce downtime window, provide fallback plans and other. We at Pythian surely can help you on finding the best option for your case.
Reach me out at [email protected] and we can discuss working together.
Thank you!