Oracle Database 19.2 for Oracle Exadata systems is available for download since yesterday night. One important thing you need to take into account once Oracle 19c will be generally available: On Linux, Oracle Database 19c requires OL7, RHEL7 or SLES12 or newer.
Database Installation Guide for Linux
You will find the exact minimum OS and kernel version requirements in the Database Installation Guide for Linux for Oracle 19c. Please see here the Operating System Checklist for Oracle Database Installation on Linux:
Please be aware that the list of minimum requirements has been updated – always check Operating System Checklist for Oracle Database Installation on Linux at first.
- Oracle Linux 7.4 with the Unbreakable Enterprise Kernel 4: 4.1.12-112.16.7.el7uek.x86_64 or later
- Oracle Linux 7.4 with the Unbreakable Enterprise Kernel 5: 4.14.35-1818.1.6.el7uek.x86_64 or later
- Oracle Linux 7.4 with the Red Hat Compatible kernel: 3.10.0-693.5.2.0.1.el7.x86_64 or later
Red Hat Enterprise Linux 7.4: 3.10.0-693.5.2.0.1.el7.x86_64 or later
Changed to: Red Hat Enterprise Linux 7.5: 3.10.0-862.11.6.el7.x86_64 or later- SUSE Linux Enterprise Server 12 SP3: 4.4.103-92.56-default or later
You may recognize that there is no support of Oracle 19c on OL6 or RHEL6.
Both, OL6 and RHEL6 got released a long time ago. RHEL6 is available since November 2010, OL6 since February 2011 if I remember correctly. And even though the Red Hat 6 Maintenance-2 Support time frame runs until November 2020, this would require a later OS upgrade on your database server. Oracle Linux is supported longer and will be under Premier Support coverage until March 2021.
Just that you’ll be aware – make sure your Linux server runs at least one of the above OS kernel versions. And then you are ready to download and install Oracle Database 19c on-premises as soon as it becomes available.
–Mike
Mike,
Thanks for sharing this information. Saved lot of trouble.
Arun
Hello Mike,
Does Oracle support inplace OS upgrade from OL6 to OL7? We are running exadata X5-2 which is still on OL6 and we are currently on GI/RDBMS version 12.2.0.1 with latest patch applied. Just looking ahead for upgrade path. Any support documents would be much appreciated.
Thank you,
Truong
Yes, we do 🙂
https://docs.oracle.com/cd/E37670_01/E64030/html/ol_updt_67rn.html
https://docs.oracle.com/cd/E52668_01/E54695/html/ol7-upgrade-inplace.html
I tried it with my old OL 6.9 (the hands-on lab). But it complained heavily about KDE/Gnome. For me a fresh install was easier. But the RH tool to check does a very good job.
Very important (I stumbled across this):
Make sure the ol6_x86_64_addons channel is enabled in public yum.
In the lab, it wasn’t.
See also:
Oracle Support Document 1968994.1 (Oracle Linux: Limited Support For In-Place OL6 Upgrade To OL7) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=1968994.1
Cheers,
Mike
Mike,
I noticed this in the OL7 docs:
https://docs.oracle.com/cd/E52668_01/E54695/html/ol7-upgrade-cond.html
No Oracle product stack is present on the system.
What does this mean?
Thanks,
Arun
Arun,
I saw this as well,
I wondered as well,
and I ignored it.
I have seriously no idea. I can only image that they don’t want to take responsibility for anything which does not work correctly afterwards. But our MAA team has designed such a “one-click” process for the Exadata systems which are mostly OL6 – and the Oracle stack is kept in there.
Cheers
Mike
Mike,
Do you happen to know any customer who has done such an upgrade successfully on Exadata? The reason I am asking is that we are going to do upgrade of Exadata next month and there is a lot of anxiety. Feeling very confident that anxiety was unfounded, I tried on my home lab VM and after OS upgrade, GI totally failed to start.
Thanks,
Arun
Hi Arun,
I have no names – but I know the people who developed the process very well.
Would you please mind and drop me an email I could forward with your points of anxiety 🙂
Then I will make sure to get you in touch with the right people.
Cheers,
Mike
Hi Arun,
Have you completed OL6 to OL7 upgrade on exadata ? If yes please share your experiences. We are planning to do the same with our critical core banking system.
thanks
jatin
Hi Mike,
Do we know when RHEL 8 will be supported for 19c?
Thanks
Jonas
Hi Jonas,
rumors say that this may happen – but I have no date for it.
Thanks,
Mike
With the release of RHEL 8, is this an option for hosting an Oracle database? I’m guessing since OL 8 beta has just come out, that not much testing has been done yet.
Lance,
there are plans – but I can’t give you any time estimate. It may take a bit I’d guess …
Cheers,
Mike
Hello Mike,
are there any Plans about the certification of Oracle Linux 8 / Redhat 8?
The first release is available already for download, so it would be good to know whether that
is supported as well.
Thanks a lot for yxur great work and regards,
Thomas
Hi Thomas,
hope all is well – and I have no time frames unfortunately. But the question gets answered quite often 😉
Cheers,
Mike
Hi Mike,
Do we have any tentative dates for 19c support on RHEL 8?
Cheers.
Nope – please open an SR and check with Oracle Support.
I have no such information or time lines.
Cheers,
Mike
Hi Mike,
could you please confirm that Oracle RDBMS 19c was supported on RHEL7.4 as you indicate in your post?
Currently from MOS it seems that Oracle has update the minimum version to RHEL7.5. I’m interested to know that RHEL7.4 and Oracle 19c were supported in the past.
Cheers.
More info.
** In your post minimum kernel version specified for Oracle 19c: Red Hat Enterprise Linux 7.4: 3.10.0-693.5.2.0.1.el7.x86_64
** In the MOS note: “Minimum ‘Update’ level for RHEL7 and Oracle Database 19c (Doc ID 2605726.1)” minimum kernel version specified for Oracle 19c: 3.10.0-862.11.6.el7.x86_64 (kernel for RHEL7.5) but minimum ‘Update’ level = Update 4.
Could you please confirm that Oracle RDBMS 19c was supported on RHEL7.4 using kernel 3.10.0-693.5.2.0.1.el7.x86_64 ?
Cheers.
Hi Jose,
I copied the data from the install guide – but I know that this has been changed because of an issue as far as I know. I updated the blog post but I haven’t taken a screenshot with date and such. I hope this doesn’t cause you any inconvenience. But please double check with Oracle Support.
Cheers,
Mike
Hi Mike,
thanks for your help.
Cheers.
Mike,
This is kind of an old thread, but I have a somewhat related question.
Many times over the years, I have upgraded Solaris servers that hosted Oracle databases without issue. However, at my current employer, they run RHEL. We have a lab system running RHEL6 and I decided to try an in-place upgrade to RHEL7.
The upgrade itself worked perfectly, but when I re-enable Oracle High-Availability Services after the upgrade, “ohasd.bin reboot” shows up as running, but the remainder of OHAS stack does not start.
I compared a system on which we did a clean install of RHEL7 followed by cloning a GI HOME from another system, and noticed that on that system, there was a systemd unit file for oracle-ohasd.service, but no such service exists on the upgraded server.
I was thinking that I could just do a “roothas -dconfig -force” followed by a “GI_HOME/root.sh” to reconfigure HAS. Do you think that is a good idea? Or do you think trying to do this as an in-place upgrade is a very bad idea?
Thanks for your consideration.
Bill
Hi Bill,
this is expected. The documentation is pretty clear on this.
And in-place OS upgrade for Linux is only supported when there is no non-OS software on the box.
In your case, try to recompile the GI stack. And you can of course try your proposed workaround, too.
Cheers,
Mike
Mike,
Thanks for your prompt reply.
After my original post, I decided to give my idea a shot since it was a lab machine and I had a pre-upgrade snapshot of the system, anyway.
So I did the “roothas -deconfig -force” then reinitialized GI using root.sh (and by extension, roothas.pl). This did create the missing systemd unit file and after having done this, the entire HAS stack started fine. Of course, it lost all of the resources I had configured, so I had to add them back. As it happens, there is a very nice support document that details that process (How to Reconfigure Oracle Restart on 12c / 12.1 (Doc ID 1570358.1)).
So once I re-added ASM, my disk groups, and my databases to the HAS resources, everything seems to be working well now.
My next challenge is to try a similar approach on our lab RAC environment. I suspect that will probably be much more difficult…
Thanks,
Bill
Thanks for the helpful update, Bill!
And glad it worked well!
Kind regards,
Mike
Mike,
It took me a bit to pull it off, but i have duplicated this process for RAC. First off, let me say that it’s not for the faint of heart. 🙂
My process was essentially this:
1. Deconfig RAC on all nodes (Doc ID 1377349.1).
2. Perform OS upgrade.
3. Reconfig RAC on all nodes.
That last one was the challenge, and it took a bit of doing to figure out the correct recipe to pull it off.
RedHat decided to change network interface naming conventions between RHEL6 & RHEL7. This wrought havoc since various parts of the GI remembered the old names. In fact, this ended up leading to what looks like a bug in config.sh (12.1.0.2) when run on RHEL7 – I even tried cloning the GRID_HOME to a brand new RHEL7 server and hit the same error ([INS-08109] Unexpected error occurred while validating inputs at state ‘NetworkInterfaceUI’. – and after looking at the details of that error, I started calling it “The Yoda Error” – if you’ve ever hit this one, you’ll know why!).
In order to work around that, I first hand-modified the crsconfig_params that was generated when I had originally built this RAC about 3.5 years ago, then ran rootcrs.sh, which failed when it discovered that the HAIP configuration hadn’t been created/started.
I then had to use gpnptool to change the interface names to the new RHEL7 convention.
I then reran rootcrs.sh and it was able to complete the configuration of GI. After that, it was no different than the single-instance upgrade I did back in June (i.e., re-add all the resources into the GI config).
You may or may not want to publish this comment since as I said, it’s not for the faint of heart. However, I thought you might at least find it an interesting data point.
Take care,
Bill
P.S. Yes, I know 12.1.0.2 is getting pretty old – we actually have plans to get to 19c in the very near future, but needed to get the OS upgrades done first.
Thanks for sharing!
Cheers,
Mike
Bill,
In RHEL 7, there is a way to revert back to RHEL 6 style NIC naming. Second, after OS upgrade, you have to relink the GI binaries, otherwise the clusterware stack will not start up. It is documented in some MOS note. It is really simple.
None of these issues is seen on Exadata as the upgrade scripts take care of everything.
Hope this helps.
Arun
Thanks Arun!
Cheers,
Mike
Hi Bill,
Thanks for the note. I see your steps of deconfig RAC on all nodes and then upgrade OS, and reconfig and running gpnptool to change network interface names to RHEL7 names. The steps you performed, was that a complete downtime of the cluster?
We are doing OS upgrade in a rolling manner, downtime for one node at a time.
1) Delete node 2 from RAC
2) Upgrade node2 to Redhat 7
3) Node 2 network interface names got changed to new names ens*
3) Change network interface names on node 2 to old names eth* from Red Hat6 so it can be added back to cluster.
4) Delete node1 from RAC
5) Upgrade node 1 to RedHat 7.
6) Node1 network interface names got changed tonew names ens*
7) Change network interface names on node1 to old names eth* from Red Hat 6 format so it can be added back to cluster.
With the steps I listed above, we are changing network interface names..and I see we cannot avoid that step as at any point for the cluster the network interface names has to be same across all nodes..Is it possible to use the new network interface names for RAC by using gpnptool in rolling upgrade steps.
Thanks,
Raj
Arun,
I did not know that. Our Linux sysadmin is all about consistency: he actually doesn’t like RHEL7’s new NIC naming, but he said that since a new machine ends up with the ens* names, he wanted upgraded systems to be the same way. It sure would have saved me a lot of time had I known this before he upgraded it.
Of course, he also said he wanted to build all new machines so that they don’t use ext4 as the root filesystem (since that is no longer the default). I remember when Solaris 10 first started supporting ZFS root – seems to me that if he really wants, he should be able to do like I did back then. That’s a discussion for another blog post, however. 🙂
Thanks,
Bill
Hey Bill,
as I seem to be stumbled upon the same problem that you had above, I would like to paste further information that helped me to start the GI stack (Oracle Restart) after upgrading RHEL6 to RHEL7. Please have a look into the following Oracle Support Document:
How To Relink The Oracle Grid Infrastructure Standalone (Restart) Installation Or Oracle Grid Infrastructure RAC/Cluster Installation (11.2 to 18.c). (Doc ID 1536057.1)
The first steps of part A) [1 to first block in 4] I already found more or less on other websites, but the last one helped me with getting the OHASD to start up correctly at the end, not necessary to insert again all information by hand.
So, maybe part B) can help all of you with RACs…
Best regards,
Patrick
Thanks for sharing, Patrick 🙂
Cheers,
Mike
Hallo Sir,
Please let me know ,Is it possible upgrade Oracle Linux 7.1 to Oracle Linux 7.4 or later..
because we need to update our Database 12.1.0 to 19c..
Thanks a lot
Hi Oskar,
sure – I do this all the time automatically via the OS update on my Linux.
Cheers,
Mike
Hi Mike,
Currently we are in RHEL 6.5 and database is 12.1.0.2. We want to upgrade our DB to 19c. Is that possible to do in RHEL 6.5? or else do we need to upgrade RHEL 6.5 to RHEL 7 or RHEL 7.5. Please confirm.
Hi Anu,
you must upgrade your OS to OL7.
Thanks,
Mike