Oracle Database 11g? In 2022? Yes, I know – and you know too – there are Oracle 11g databases out there in production. And blindly I’d say: Too many. Of course, we are the “upgrade guys” trying to convince you to move to Oracle Database 19c. And I bet, for each of your 11g databases there’s a valid and legit reason why they haven’t upgraded yet. But there is one often neglected technical reason Why you can’t stay on Oracle Database 11g forever. So let me explain this below.
Oracle Database 11g?
At first, let me browse through my memory. Oracle Database 11g got released before I joined Roy’s team. This was at a time when I had the true pleasure to work with the MAA team of Lawrence To on the support of Transient Logical Standby database setups. I was on rotation for a few weeks in Redwood Shores. And with Oracle 188.8.131.52 finally, Transient Logical Standby rolling upgrades went “production”.
Then in September 2009 we launched Oracle Database 11g Release 2, known also as Oracle 184.108.40.206.
Do you remember what you did in September 2009? Look at some pictures from this time. This was almost 13 years ago. Or you may just check out this video to realize how far back you’ll have to travel in memory until you reach September 2009. Now I’m pretty certain that all of you agree that 13 years in tech are a huge time span.
Speaking of Oracle Database 11.2, we released the terminal patch set 220.127.116.11 in August 2013. You don’t believe it? See here, you can check by yourself on MyOracle Support:
And it may not scare you – but it scares us from time to time – that there are also 18.104.22.168 databases out there in production. We just work in an upgrade projects with hundreds of 22.214.171.124 databases as source.
Oracle Database 126.96.36.199 went out of bug fixing support on August 28, 2015. And Oracle Database 188.8.131.52 is under Market Driven Support. So we still fix upcoming issues on 184.108.40.206 for a small number of customers under this support agreement.
Why you REALLY must upgrade your 220.127.116.11 databases NOW
I know that some of you want to stay even longer on 18.104.22.168. And as I wrote above, there are always valid reasons I don’t want to dispute.
And for a long time we keep telling you to upgrade because:
- 22.214.171.124 is only covered under extra-pay MDS support – and even this will end soon
- Security, security, security
- Oracle 19c is so much better, faster – and gives you 3 PDBs at no extra cost
And plenty of other arguments. Of course, you all understood them clearly, no doubt. But one important point hasn’t mentioned here. I’m so happy and grateful that I have smart colleagues such as Atsuki-san from Oracle Japan who did ask me about it on a Friday morning:
Can I upgrade from Oracle 126.96.36.199 to Oracle 23c?
No. You can’t.
I was scratching my head about the question. And then I realized quickly how important Atsuki-san’s question is. He explained to me that there are customers who think they can skip Oracle Database 19c, and instead go directly from Oracle Database 188.8.131.52 to Oracle Database 23c, the next future long term support release.
You can’t skip Oracle Database 19c
You can’t upgrade from Oracle 184.108.40.206 to Oracle 23c. You even can’t upgrade nowadays from Oracle 220.127.116.11 to Oracle 21c, the current innovation release. We don’t encourage you to upgrade to Oracle 21c since Oracle Database 19c is the long term support release.
The minimum requirement for upgrades to Oracle 21c is already Oracle Database 18.104.22.168. And for Oracle 23c the minimum requirement may be even higher.
Do you want to do double-hops? Such as from Oracle 22.214.171.124 to Oracle 19c, and then onward to Oracle 23c?
Trust me, you’d like to avoid such double-hops.
You must upgrade to Oracle Database 19c – NOW
Actually let me just reiterate our daily mantra: You must upgrade to Oracle Database 19c – NOW. If you haven’t done already.
Just have a quick look at the current Lifetime Support Policy slide or at MOS Note:742060.1:
You may recognize quickly:
- Oracle Database 18c is in Sustaining Support with no bug fixing anymore
- Oracle Database 126.96.36.199 is in Sustaining Support with no bug fixing anymore
- Oracle Database 188.8.131.52 will enter Sustaining Support with no bug fixing anymore on Aug 1, 2022 (16 weeks from the date on I published this blog post)
- Oracle Database 184.108.40.206 is in Sustaining Support already but you can purchase MDS until end of 2022
- Everything older than Oracle Database 220.127.116.11 has not seen any bug fixes for at least more than 6.5 years anymore
So what are your options?
Let me answer this: Oracle Database 19c.
Use AutoUpgrade, the only recommended way to upgrade your databases to Oracle Database 19c. And start today if you haven’t done it already.
And please, don’t even think about going from 18.104.22.168 to 23c. You will have many years without any bug fixes – and no direct upgrade path.
Again, there won’t be a direct upgrade path from Oracle Database 22.214.171.124 to Oracle Database 23c. Hence, you clearly can’t stay on Oracle Database 11g forever.
Further Links and Information
- Multiple hop upgrades
- Why does your most important database run on Oracle 10.2.0.4?
- Oracle Database 126.96.36.199 is under Market Driven Support
- Oracle Database 19c is the long term support release
- MOS Note: 742060.1 -Release Schedule of Current Database Releases
- AutoUpgrade, the only recommended way to upgrade your databases to Oracle Database 19c
- Direct upgrade releases for upgrades to Oracle 21c
P.S. April 8, 2022
A final comment since somebody asked via a comment.
Of course, you can migrate your 188.8.131.52 database with Data Pump. This will also work for your 184.108.40.206 and 10.2.0.4 databases. You could even import your Oracle V5 exp dump into a 19c PDB with the old imp. Just keep in mind that migrating with Data Pump (or old exp/imp) involves way more work than an upgrade, usually takes much longer than a database upgrade – and you need to keep an extra eye on things such as statistics and more when you migrate instead of upgrading.
whenever I plan to migrate our 11g db all developers told me that with 19c forms and designer is never been supported.
Is that correct and may be an issue using 11g tor the next years?
did you say “Forms”?
I guess, Forms wasn’t even supported anymore with 11.2 🙂 I remember the discussions about Forms to WebForms to ADF or APEX in my presales days – this was when 10gR2 was out. But you may check in MOS please 🙂
As I said, there is always a reason 🙂
We used dbua to hop from 220.127.116.11 to 19C.
Autoupgrade is better?
I doubt that you used DBUA for 18.104.22.168 to 19c since the first script of the upgrade would have thrown an ORA-1722 (invalid number) since you can’t upgrade from 22.214.171.124 to 19c directly. But regardless of this, certainly you can use DBUA as well. And yes, AutoUpgrade is a million times better, mature, modern – and has none of the disadvantages DBUA still carries around since it got developed 20 years ago 🙂
If you are using STREAMS, going to 19c also means you will need to including moving to GoldenGate or some other replication utility as it is not only deprecated, the bits have been removed.
Yes, unfortunately you are right 🙁
Great description Mike. Thank you!
Thanks for the feedback, Silvia!
Just some comments about the reasons to upgrade :
1. I have serious performance problems preventing me from moving to 19C.. Very complex selects that take 10x more time to finish.. I have to fight and tweak every bad select that worked fine on 126.96.36.199 ..
So, for me, performance got worse..
2. no more support for 188.8.131.52 is because Oracle doesn’t want to provide support any more and pushes the customer to upgrade.. (Besides the fact that 11.2 is pretty stable and would need minor support, which cannot be said about 12.1) .. And don’t ask me to talk about Oracle support, my mother would make me wash my mouth with soap..
3. Security : I am not sure about this, but I presume that, if Oracle wanted to, they could solve security issues in 184.108.40.206 as well..
4. PDBS? We don’t need them, it takes a lot of extra procedures and resources to implement them.. Enterprise manager takes multiple patches to solve multiple problems to support PDB’s.
5. Modernization : currently we don’t use any of the new features.. If we needed them, then we could decide to upgrade (in stead of Oracle forcing us)..
Maybe it is just me, but I get the feeling we are pushed to upgrade, and I don’t like to be pushed..
do you have an SR for your performance problems? And did you make sure to got to 19.13 at least, and enable the disabled optimizer fixes (see DBMS_OPTIM_BUNDLE on my blog)?
Regarding your comment that Oracle does not want to support 11.2 anymore, let me comment here.
11.2 is the release with the by far longest support period we ever had for any RDBMS. The Extended Support got waived and further extended multiple times. So I really can’t see your complaint here. You should have started moving away from 220.127.116.11 already a long time ago. It is seriously not Oracle’s fault. If it would be me, I would not have extended the support that long.
Well, regarding Support, I see your point. There is not so much I can do but YOU are the customers. You can constantly raise your voices. You should.
You can still get MDS (Market Driven Support) which includes Security and Sev.1 bug fixes. So we still create those fixes. The question from a development and maintenance standpoint is how many releases you’d like to maintain in parallel. You may ask the developers in your company about it – and at best they will only maintain a single code line. So your assumption is not correct – MDS covers what you are looking for. Don’t accuse “evil” Oracle blindly 🙂
Nobody forces you to use PDBs now. But many customers I worked with in the past years see a huge benefit. In 19c you still have the choice. All is fine so don’t complain about an offering we do at no extra cost – and where especially my VP Roy Swonger had to fight hard for. Keep in mind that we have this for SE2 customers as well. It is your choice. Truly.
Well, may I recommend you to watch our Virtual Classroom Seminar “Cool Features, not only for DBAs”? No worries, it is purely a tech seminar without marketing.
Episode 7 it is. https://mikedietrichde.com/videos/
Most of them are there just to be used and make your DBA’s life easier.
Finally, nobody wants to be pushed, I agree.
You can still use a Nokia 3310 or a Siemens C45. They still work.
But I wonder what your OS vendor tells you when you are still on Linux 5 – or what your hardware vendor tells you when you still use a Tru64 machine. Try to get replacement parts.
Don’t get me wrong:
I dealt with a customer who did the entire Champions League pay-per-view billing on 18.104.22.168 on Windows.
Then the disk failed one day before the semi finals. It was a SCSI disk – and no spare parts available since this story happened in 2018.
They went on Ebay to buy a ton of replacement parts to keep the box alive at least until after the finals.
You can do everything. But I will stubbornly repeat that you must upgrade.
Thanks for the lengthy response..
Yes, I do know we have to upgrade and I will.. (90% of our DB’s are already 19.5 or higher).
I have done performance tests on 12.2 and about all 19C versions once they were released.
And until 19.13, none of them were performing satisfactory..
I currently test 19.14, and with addition of CPU’s and memory, and a lot of sql patches and sqlprofiles I get comparable performance for the ‘bad’ selects and better performance for the ‘normal’ selects..
But every day I see glitches.. Fairly simple selects that work fine in 11.2 and need rework in 19.14..
I will dig into DBMS_OPTIM_BUNDLE. Thanks for the tip.
Thanks Jan – and actually the usual feedback regarding performance and stability I receive is quite positive regarding 19c. But of course, there is no general magic switch – and things may vary from application to application pattern.
Did you open SRs for the performance issues?
Will expdp from 11.2.x -> impdp to a newly created 23c database be a possible upgrade path?
yes, this will work. But it will be a migration, not an upgrade anymore. You potentially could even take an old exp from an Oracle V5 database and migrate it directly into a PDB in 23c. At least, this works fine until including 19c since we did that exercise with a customer 2 years ago.
Data Pump makes you independent of the upgrade release requirements – but for a price. While an upgrade may take 15-60 minutes usually depending on the number of components you have installed, any larger database migration will take longer. And you need to spend extra care on things such as statistics, index rebuild etc during the migration while with an upgrade, all this gets preserved.
Sure, the bigger the database is, the more unlikely you will use expdp/impdp for “upgrading” to a new Oracle release.
But good to know that it’s still a valid/supported way to “get rid of old stuff” 🙂
Thanks Manfred – I added a P.S. to the blog post to make this clear 🙂
Cheers and thanks for the hint,
I am no DB guy but would like to understand what are the risk involve when upgrading from 11g to 19c? Is it gonna be seamless as we are implementing windows update?
this depends a lot. Seamless is a very flexible word 🙂
So what you need to do is testing. At first your application. Normally, this should work fine in terms of functionality. But no guarantee. And of course, there are some cases were you may need some adjustments. But the more complex part if performance stability. Please see our virtual classroom seminar about “how to ensure performance stability”:
==> Episode 3
My organisation is still running 10g databases and are upgrading to 19c. The approach the DBA’s are taking is to use expdp/impdp to migrate the schemas to the new 19c databases. However, there are schemas that have in excess of 3TB worth of data and the DBA’s are estimating this could take upto 2 days to perform the migration using expdp/impdp. Of course, for production, this will not work as we cannot have that much downtime. I have suggested the use of transportable tablespaces to migrate the large schemas, but wasn’t sure if transportable tablespaces is a viable option to go from 10g to 19c. I would like to test this, but the 10g distro is no longer available, unless I raise an SR with Oracle requesting the media.
Have you come across this scenario, or would we have to perform an interim version i.e. from 10g to 12c, and then 12 to 19c?
I look forward to your reply.
traditional transportable tablespaces will work. But I doubt that expdp/impdp will take this long for 3TB. Unless you have a super-slow system this should be doable much faster. See our Virtual Classroom Seminars (Migration Strategies – and Data Pump Deep Dive) for suggestions.
impdp allows the data to be transferred in parallel over the network, so the real limitation there is how fast your storage and network are.
Last time I did that though, the indexes were still created serially, so really the only hang up was the index creation.
One enhancement they need, if it is still that way, is to do the indexes in parallel too.
This depends on the fix level you are on. Indexes get created in parallel from 22.214.171.124 onward but only with a specific patch level. And your observation is right for 126.96.36.199 “default” – and we showed in Virtual Classroom Seminar 13 (Data Pump Deep Dive) how to workaround this:
Any thoughts on upgrades in name only, i.e. upgrading to 19c but setting compatibility to 11.2 so really it cant make use of new features. Any notes from Oracle on whether 11.2 compatibility would be available in 23c or deprecated at some point in future ?
as far as I am aware, the min compatibility in 23c will be 12.2.0. And COMPATIBLE defines whether a feature is available, and how the redo structure, the tablespace headers etc look like.
See also here: