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

Share this: