DBCA 12.2 does not update /etc/oratab in GI / RAC

DBCA 12.2 does not update /etc/oratab in GI / RACInteresting things happen. And I learned (credits to Arun Gupta and others) that there is a change in Oracle Database 12.2 environments I wasn’t aware: The DBCA 12.2 does not update /etc/oratab in GI / RAC environments. Let me give you some extra information and hints on this topic as it may cause some strange situations.

DBCA 12.2 does not update /etc/oratab in GI / RAC

Arun Gupta commented on the blog:

Another case in point. DBCA fails to update the /etc/oratab file in 12.2 when a database is created. There is no documentation of this behavior. So, I opened a SR and here is what support had to say:

It is expected. 12.2 GI agent does not update oratab for 12.2 database anymore.
We want customer to use srvctl to get instance name and oracle home information.

If the instance is shutdown, how would I get its name and its Oracle home via srvctl? There would be no way of knowing whether the database is even configured on the server.

And interestingly enough Uwe Kirchhoff, one of my mates in Oracle ACS Support in Germany alerted me a week ago about this:

Do you have an explanation for this:
Applying 12.2.0.1.171017 RU (patch 26737266) To 12.2 Cluster Removes Oratab Entries (Doc ID 2329359.1)?

No, I don’t. But other people mailed me or commented as well in the past weeks.

Why does DBCA not update and the Oct RU remove /etc/oratab entries?

Actually I think this is expected behavior. Many tools in RAC/GI don’t even consider /etc/oratab anymore. Scenarios such as policy managed setups don’t use oratab.

What should you do instead if you would like to find out if a database is present or not? Use crsctl stat res to get the database name and then use srvctl status -d <dbname>:

[oraha@rstuv07:/scratch/oraha]  srvctl status database -d one
Instance one_1 is running on node rstuv09
Instance one_2 is running on node rstuv08
Instance one_3 is running on node rstuv07
Instance one_4 is running on node rstuv10

Important:
There’s no change with /etc/oratab and DBCA with single instance databases.

Please find further information here:

And my team mate Byron send me this link to Frits Hoogland‘s blog which is (as always) worth a read. Frits published a shell script which reads the information for oratab from the cluster registry. This may be very helpful in case you still would like to have an updated /etc/oratab file:

–Mike

6 thoughts on “DBCA 12.2 does not update /etc/oratab in GI / RAC

  1. I use . oraenv to set my environment to DB or GI home. oraenv gets the given ORACLE_HOME from oratab. Is there an another (official) way to setting that now? Is oeaenv script deprecated?
    Thank you,
    cheers Peter

    • Peter,

      as far as I see, oraenv uses “dbhome” and “orabase” tools to determine the actual Oracle Home and Oracle Base from /etc/oratab.
      I don’t have a cluster installation to check it there as well – but you may please verify that oraenv hasn’t been changed for a cluster env as well in 12.2. If this is the case (I’d assume it silently), then I have no idea. I did grep MOS already and tried to find some useful information via a search engine but couldn’t find something useful. A manual edit of /etc/oratab would solve the issue. But not sure if this is the only workaround.

      Cheers,
      Mike

      • Hi Mike,
        thank you,
        /etc/oratab was created while fresh Oracle 12.2 GI installation.
        GritSetup.sh has added the ASM home (the RU Oct. removes that entry because the “#line added by agent” mark, regarding Doc ID 2329359.1)
        but the DBCA doesn’t add the DB home while running DBCA (so far I remind me correctly)
        Cheers Peter

Leave a Reply

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