Oracle Database 19c is certified on OL8 and RHEL8

Posted on May 11, 2020 by Operating System 59

Oh … I’d say this was the question I’ve got asked the second most often in the past months (after a potential extension for Oracle 12.2.0.1 support): When will Oracle certify OL8 and RHEL8? And I read this question internally even more often. Now thanks to my team mate Daniel Overby Hansen who spotted it on Twitter on the weekend, we can tell you that … finally … drum roll … Oracle Database 19c is certified on OL8 and RHEL8.

Oracle Database 19c is certified on OL8 and RHEL8

Photo by Derek Oyen on Unsplash

How do you get the information?

Go to MyOracle Support and hit the “Certification” tab.

Then choose “Oracle Database“, “19.0.0.0.0” and either “Linux x86-64 Oracle Linux 8.x” or “Linux x86-64 Red Hat Enterprise Linux 8“.

Oracle Database 19c is certified on OL8 and RHEL8

Oracle Database 19c is certified on OL8 and RHEL8

You may also recognize that no other database version has been certified with OL8 or RHEL8.

What’s the fine print?

I know that we all tend to NOT read fine prints. But you should in this case. You will need to have database RU 19.7 as minimum database patch level. Or you will need to add extra patches on top of 19.6. But life will be much easier with 19.7.0, believe me.

Oracle Linux 8

These are the minimum requirements OL8:

Minimum RU: 19.7 (or 19.6 with patches, refer to aforementioned certification notes)

Minimum kernel versions:

    • Oracle Linux 8.1 with the Unbreakable Enterprise Kernel 6: 5.4.17-2011.0.7.el8uek.x86_64 or later,
      or
    • Oracle Linux 8.0 with the Red Hat Compatible kernel: 4.18.0-80.el8.x86_64 or later

ACFS: Please refer to ACFS Supported on OS Platforms for Oracle ACFS certification details (MOS Note: 1369107.1)

Red Hat Enterprise Linux 8

For RHEL8, these are the minimum requirements:

Minimum RU: 19.7 (or 19.6 with patches, refer to aforementioned certification notes)

Minimum kernel versions:

    • Minimum kernel version: 4.18.0-80.el8.x86_64 or later [corrected on Nov 9, 2020 as the information on MOS is now different]

ACFS: Please refer to ACFS Supported on OS Platforms for Oracle ACFS certification details (MOS Note: 1369107.1)

Requirements

Thanks to Chris for opening the SR to ask for more information regarding patch requirements etc.

This is the document you will need to look at:

Further Links and Information

–Mike

Share this:

Tags:

You may also like...

59 Responses

  1. Chris Smids says:
    May 11, 2020 at 10:19

    Hello Mike,

    Thank you very much for sharing this information.

    I have 2 questions related to this certification :
    1) Is it foreseen that Oracle 12.2.0.1 is also going to be certified against OL8 and RHEL8 or is Oracle 19.7 (or 19.6) going to be the minimum version for all Oracle DB’s on OL8 and RHEL8 ?
    2) Would it be possible to mention the needed patches for Oracle 19.6 as I have not been able to identify the needed patches for 19.6 on Metalink while trying to find them with the following certification notes :
    – Database Certification Information (Doc ID 1306539.1).
    – Certification Information for Oracle Database on Linux x86-64 (Doc ID 1304727.1)

    Thank you very much in advance !

    Greetings,

    Chris

    Reply
    • Mike.Dietrich says:
      May 14, 2020 at 08:21

      Hi Chris,

      I doubt that 12.2 will be certified on OL8 as well. But to be 100%, I’m not involved in such things.
      And please ask Support for needed patches. I know, my answer sounds odd and boring, but I guess there may be either a note already, or somebody may be triggered to publish the information.

      Thanks,
      Mike

      Reply
      • Chris Smids says:
        May 19, 2020 at 15:24

        Hello Mike,

        Thank you for the feedback. Regarding the additional patches to be installed I created Service Request “SR 3-23091076241 : Additional patches required for Oracle 19.6.x on Red Hat Enterprise Linux 8”. Unfortunately one week later I still do not know which additional patches are required for Oracle 19.6.x :-(.

        Greetings,

        Chris

        Reply
        • Chris Smids says:
          May 20, 2020 at 06:26

          Hello Mike,

          I got an update on my Service Request saying that the information about the additional patches needed for 19.6 on OL8/RHEL8 can be found in the document “Requirements for Installing Oracle Database 19c on OL8 or RHEL8 64-bit (x86-64) (Doc ID 2668780.1)”.

          While having a look at that document then I conclude this is the list of additional (One-Off) patches :
          – 30484981 – OJVM RELEASE UPDATE 19.6.0.0.0
          – 30150710 – EM express OneOff patch 19.6.0.0.0
          – 30489227 – OCWRU Patch 19.6.0.0.0
          Remark : For the OCWRU patch it is mentioned that users may choose to update the OCW version

          Greetings,

          Chris

          Reply
  2. Eric Cloutier says:
    May 11, 2020 at 15:05

    Hi Mike,

    I noticed the support note 13044727.1 isn’t update about Linux 8 with Database 19c.
    Could you confirm this please ?

    Thanks.

    Reply
    • Mike.Dietrich says:
      May 12, 2020 at 08:48

      Hi Eric,

      I guess this will happen soon – and actually I’m not surprised – but if you’d like to push the guys, please log an SR.
      Otherwise it typically takes a bit …

      Cheers,
      Mike

      Reply
  3. Ben says:
    May 11, 2020 at 16:33

    Hi Mike,
    the ACFS fine print (MOS Note: 1369107.1) means that there is no ASM certification for now, or do I miss something?

    Reply
    • Mike.Dietrich says:
      May 12, 2020 at 08:51

      Hi Ben,

      no, this is not the case. i just assume that the note hasn’t been updated yet for OL8/RHEL8.
      You may open an SR if you want to push an update – or otherwise it may take a bit.

      Thanks and kind regards,
      Mike

      Reply
      • Ben says:
        May 12, 2020 at 16:13

        Hi Mike,
        thanks for your replay.
        I think there are some pakages missing, or I miss more Informations then I expected.
        I can’t find the asm kernel modul to install oracleasm and the there are no asm rpms (oracleasmlib / oracleasm-support ) on the OEL 8 Repos.
        Best regards,
        Ben

        Reply
  4. Yogi says:
    May 12, 2020 at 09:36

    Are there special binaries to download ? I cant see to get past ‘supportedOSCheck’ failure on OL8, with 19.7.0?

    Reply
  5. Rich Soule says:
    May 13, 2020 at 21:29

    Note that the runInstaller program fails on the OS check for on-premise 19.3 database (have to install before you can patch to 19.7). You can avoid this by using something like the following before running runInstaller:

    export CV_ASSUME_DISTID=OEL7.6

    Reply
  6. Zarko Supicic says:
    May 14, 2020 at 07:32

    Hi Mike,
    given it is now certified for RHEL8/EL8 (including hopefully ASMFD / ACFS required for Clusterware / RAC), shouldn’t it also be supported for RHEL/EL versions 7,6, 7,7, 7.8 ? I have an SR on this, because most of the MOS Docs only talks about kernels for up to 7.6 ?
    We need to get away from the [currently running] 7.5 asap, and to a highest possible 7.x version due to EUS support issues.
    Thanks!

    Reply
    • Mike.Dietrich says:
      May 14, 2020 at 08:09

      Hi Zarko,

      all OS patch levels are ALWAYS supported. This is true since the stone ages. Oracle never certifies extra for an OS patch level after the initial base OS version has been given green light. It could be, like in this case here, that we require a minimum OS patch level (such as SLES 12 SP3+) or now, OL8.1+ (whereas RHEL 8.0 is fine). Hence, when OL7 is certified (in this case it was 7.4+ for OL, but 7.5+ for RHEL) all subsequent patch sets for the OS are automatically included.

      Not sure what supported needs to find out there 🙁 Sorry for this inconvenience …

      Cheers,
      Mike

      Reply
      • Zarko Supicic says:
        May 14, 2020 at 10:04

        Hi Mike,

        and thanks for the very quick reply! What you say is comforting, however… I was never 100% sure about it and there is confusion (to say the least). Having a minimum OS kernel/patch required level for a given Oracle GI / RDBMS release is logical and well understood.

        However, there seem to be issues when going to more recent, or should I say, most recent OS versions. I understand this may primarily be due to ACFS / ASMFD support which require kernel modues. I had an SR in the past (will not post numbers publicly here), where with Jan 2020 RU, we requested a confirmation whether we can upgrade the RHEL OS from 7.5 to a newer version, in that case it was 7.7. I was told the kernel was not supported (at that time), and the maximum we could do is to go from 7.5 to 7.6. Now, the current issue is similar, but taking into account the Apr 2020 RU. If we could go from 7.5 to 7.8, that would be ideal, but I really need a firm (certified) confirmation. The Doc 1369107.1 does not (yet) reflect any of this.

        I can just hope the guys behind the SR will do it…
        Thanks again, kind regards,
        -Zarko

        Reply
  7. Chris Gooch says:
    May 27, 2020 at 16:57

    Hi Mike,

    Installing our gold image of 19.7 on RHEL 8 gets the following error during runInstaller:

    [WARNING] [INS-13001] Oracle Database is not supported on this operating system. Installer will not perform prerequisite checks on the system.
    CAUSE: This operating system may not have been in the certified list at the time of the release of this software.
    ACTION: Refer to My Oracle Support portal for the latest certification information for this operating system. Proceed with the installation if the operating system has been certified after the release of this software.
    [FATAL] [INS-30060] Check for group existence failed.
    CAUSE: Unexpected error occurred while trying to check for group existence.
    ACTION: Refer to the logs or contact Oracle Support Services. Note for advanced users: Launch the installer by passing the following flag ‘-ignoreInternalDriverError’.

    Setting -ignoreInternalDriverError flag allows the install to run without using CV_ASSUME_DISTID but this is not documented anywhere.
    All documentation is around applying 19.7 RU to an earlier version so maybe need to get some comments added to consider fresh 19.7 installs that use gold images?
    Will this -ignoreInternalDriverError flag be required for 19.8 RU?

    Thanks,
    Chris

    Reply
  8. andyhelm says:
    June 18, 2020 at 14:44

    So the database version 19c is certified on RHEL 8, what about Grid Infrastructure ?
    It seems oracleasm from Red Hat is not available in an el8 version, and ASMFD is not certified by Oracle on RHEL8, so how does one run ASM ? Oracle RAC _is_ certified on RHEL according to the Certification pages on MOS.

    Reply
  9. Ali Langar says:
    June 26, 2020 at 19:28

    Hi Mike,

    I am setting up a cluster 2 nodes with RHEL 8.2 and Oracle 19.7 . The installation went well , but when i created a rac database , a got troubles with instance eviction even the creation went well too. But few minutes later one of the instances is evinced and message lake ORA-27508: IPC error sending a message appears and ora-29740 evicted by instance number 2. Did have meet this kind of behavior ? any help or recommendations will be appreciated. The cluster ware work perfectly.

    Thanks . Best regards.
    Ali Langar

    Reply
  10. Ali Langar says:
    July 10, 2020 at 16:07

    Hi Mike,

    I ‘am not sure that raw devices are unsupported, but I’m still using them for performances purpose (We are using VMware who supports Raw Device Mapping (RDM) ) . RDM allows a virtual machine to directly access a volume on the physical storage subsystem, and can be used only with Fibre Channel or iSCSI. RDM can be thought of as providing a symbolic link from a VMFS volume to a raw volume. The mapping makes volumes appear as files in a VMFS volume. The mapping file, not the raw volume, is referenced in the virtual machine configuration .

    Best regards.
    Ali.

    Reply
  11. Ali Langar says:
    July 14, 2020 at 14:39

    Hi Mike,

    I’m sorry ,for clarification I am using raw devices through oracle ASM instance. Besides, I’ve been doing this since the 10g version.

    Best Regards.
    Ali.

    Reply
    • Ali Langar says:
      August 14, 2020 at 17:18

      Hi Mike,

      Finally my problème was resolved. My trouble was caused by the Strict Reverse Path filtering in Redhat 8.The reason behind strict mode is to prevent IP spoofing from Distributed Denial-of-service (DDos) attacks. However, having strict mode enabled on the private interconnect of an Oracle RAC database cluster may cause disruption of interconnect communication. So two things must be done :
      1- Adding in my case my interconnect devices ( ens1f1 , ens2f1) in /etc/sysctl.conf
      net.ipv4.conf.ens1f1.rp_filter = 2
      net.ipv4.conf.ens2f1.rp_filter = 2
      sysctl -p /etc/sysctl.conf

      2- Creating /etc/sysctl.d/98-oracle.conf then adding same parameters
      net.ipv4.conf.ens1f1.rp_filter = 2
      net.ipv4.conf.ens2f1.rp_filter = 2
      sysctl -p /etc/sysctl.d/98-oracle.conf

      Obviously this et done on all nodes of the cluster. After that every thing works perfectly.
      The value 2 for rp_filter means that Loose mode as defined in RFC3704 Loose Reverse Path Each incoming packet’s source address is also tested against the FIB and if the source address is not reachable via any interface .

      Thanks!
      Ali.

      Reply
  12. Charlie says:
    August 6, 2020 at 14:51

    I’ve just installed this platform, upgraded to 19.8, with the following patches:
    p6880880_190000_Linux-x86-64.zip (OPatch)
    p31281355_190000_Linux-x86-64.zip (db patch)
    p31219897_190000_Linux-x86-64.zip (jre patch)

    The instructions aren’t clear about getting all of this on.

    What worked for me was to unpack 19.3, move the bundled OPatch out of the way and unzip the new one, then call runInstaller with the unzipped db patch:

    export CV_ASSUME_DISTID=OL7
    ./runInstaller -applyRU ~/hold/db/31281355

    Immediately exit the installer when it starts, then:

    ./runInstaller -applyRU ~/hold/jre/31219897

    My question is the post-patch processing on these sets – do the post-patch instructions (if any) for each patch need to be run on any new or upgraded databases?

    I have an SR open on a related subject, so I’m going to ask there also.

    Reply
    • Mike.Dietrich says:
      August 10, 2020 at 09:59

      Hi Charlie,

      no – upgrade automatically executes datapatch. DBCA does the same when you create a new database. Hence, no additional “post” steps need to be done when you upgrade your database to this home.

      Thanks,
      Mike

      Reply
  13. Brian says:
    September 8, 2020 at 00:59

    Hi Mike,

    Just got to test installing a Gold Image I created on RHEL 7 and patched to 19.7, onto the latest patch of RHEL 8.

    Two issues I hit:

    1. It states there is a missing package compat-libcap1-1.10[CHECK_PACKAGE_EXISTENCE_compat-libcap1]:TASK_SUMMARY:FAILED:IGNORABLE:VERIFICATION_FAILED. I don’t see this listed in the known errors in 2668780.1.

    2. I verified that the 19.7 bug patch is included in the $ORACLE_HOME:
    $ORACLE_HOME/OPatch/opatch lsinventory|grep 30869156
    Patch 30869156 : applied on Sun Apr 26 13:06:06 PDT 2020
    Patch description: “Database Release Update : 19.7.0.0.200414 (30869156)”

    However, I still had to set the following env variables “export CV_ASSUME_DISTID=OL7” to get past the [WARNING] [INS-08101] Unexpected error while executing the action at state:’supportedOSCheck’, which was supposed to fixed in the above patch per this MOS note.

    So two questions:
    1. Is it acceptable to take a Gold Image created on RHEL 7 and patched to 19.7 and deploy on RHEL 8.
    2. Have you or anyone else hit the two issues I pointed out above?

    Thanks!

    Reply
  14. Randall says:
    October 16, 2020 at 17:13

    Hi Mike, I would appreciate your take on RHEL7 versus RHEL8 for a new Data Guard standby host for a production X7-2-HA ODA. At this point we intend to upgrade the ODA from OEL6 to OEL7 (31010832) to allow us to upgrade to 19c and better use the remaining 3 years of service life of the ODA. And we are just about to replace our RHEL6 DG standby server, so would we be best to go with RHEL7, to more closely align with the OS version on the ODA? Is there any reason to avoid RHEL8 that you can think of, for this scenario? Any advice would be appreciated, thanks Mike.

    Reply
    • Mike.Dietrich says:
      October 20, 2020 at 18:27

      Hi Randall,

      if it would be only “me”, I would go with OL7. I just receive a number of questions from customers regarding OL8.
      OL7 for me does the job as it is long enough supported, and takes all releases from 11.2 to 19c.

      Cheers,
      Mike

      Reply
  15. Randall Wacker says:
    October 20, 2020 at 18:44

    Hi Mike …. agreed, I was leaning that way myself. I appreciate the response!

    Reply
  16. Andy Helm says:
    October 21, 2020 at 09:20

    Having gone through a couple of SRs to get GI and RDBMS running on RHEL8, we have decided to stick with RHEL7 for now. Due to the requirements of ACFS you end up being restricted to a certain kernel version, make a fresh build of the os beyond that version and GI will not install. I’m sure this will get easier over time but for now RHEL7 is the better option.

    Reply
  17. Thierry Hofmann says:
    May 4, 2021 at 13:38

    Hi Mike,
    Do you have an update regarding the installation of oracle19c on RHEL 8. Is this now a good option?
    Kr

    Thierry

    Reply
    • Mike.Dietrich says:
      May 4, 2021 at 23:26

      Hi Thierry,

      I think the situation hasn’t changes so much. Please check the comments sections in both blog posts – the feedback so far isn’t enthusiastic I’d say ..

      Cheers,
      Mike

      Reply
  18. Thiru says:
    July 5, 2021 at 07:56

    Hi,

    I have yesterday installed Oracle 19c (with 19.11 RU) on RHEL 8.2 VMs. Installation went well.

    (As Oracle ASM Kernel Module driver is not available from RH for RHEL 8.2 I used Udev rules instead of ASM Lib)

    Regards
    Thiru

    Reply
  19. Thiru says:
    July 5, 2021 at 08:00

    Hi,
    I meant Oracle 19c Grid Infrastructure (with 19.11 RU) on RHEL 8.2.

    Regards,
    Thiru

    Reply
  20. Kashyap Pandya says:
    July 12, 2021 at 15:39

    Hello Mike,

    Currently I am facing issues with Oracle 19c(19.11) on OEL 8.x on Azure on ASM . We are facing REDO log corruption issue ,however when REDO logs are placed on File system no such issue is been faced. Is this kind of configuration been setup successfully anywhere or same issue been faced ?

    Reply
    • Mike.Dietrich says:
      July 22, 2021 at 22:10

      Hi Kashyap,

      never seen or heard this before.

      Can you try please in your spfile:
      _use_single_log_writer=true

      and in all cases, log an SR for it?

      Cheers,
      Mike

      Reply
  21. Gerrit Haase says:
    July 5, 2022 at 17:46

    Hallo Mike,

    still no luck when I try to deploy 19.15 GoldenImage created on RHEL7 with EM Fleet Maintenance.
    No idea how to set this CV_ASSUME_DISTID= for the Provisioning Job, also this -ignoreInternalDriverError flag is not possible to add this to an existing provisioning profile, however it is not documented, so I can’t sell this to my customers anyways. So we’ll need to create a new GoldenImage with the documented workaround, manually changing the cvu_config file, which is also not really handy to be forced to repeat this every three months.

    One could expect, that two years after certification, it should be possible to install the software as is, without working around “bugs”, at least I do; or is the canon, to just refer to the docs and state “but it is documented in the ‘known bugs section'” is eough? IMO this doesn’t free the developers from fixing bugs?

    Other than this, keep up the good work you’re doing here with this blog,
    Gerrit

    Reply
  22. Steve says:
    April 20, 2023 at 09:13

    Hi Mike — do you know what the plans might be for certification of 19c on RHEL/OL 9?

    Reply
    • Mike.Dietrich says:
      May 7, 2023 at 22:41

      Hi Steve,

      there are plans, and I think it will happen someday – but I am unfortunately not aware of any timeline or commitments yet.

      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 Senior Director of Product Manager for Database Upgrade, Migrations and Patching writing just another blog.

Opinions certainly are my own as is this page.

Archives

Categories

Upgrade @YouTube

Subscribe via Email

Join 7,850 other subscribers

Follow me on Twitter