Interesting 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 220.127.116.11.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
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
There’s no change with /etc/oratab and DBCA with single instance databases.
Please find further information here:
- MOS Note: 2278584.1 – 12.2 Real Application Cluster DBCA do not Update Oratab)
- MOS Note: 2329359.1 – Applying 18.104.22.168.171017 RU (patch 26737266) To 12.2 Cluster Removes Oratab Entries
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
People who have their own home-grown scripts (e.g. “collect configuration information”) — or even 3rd party tools — that use the oratab file would have an issue with this change.
I can only advice people to open SRs and signal that they are not happy with this change.
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?
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.
/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)
thanks – and please have a look at Frits’ example here:
He published a shell script to read the entries from the cluster registry – this may help you (and others).
/etc/oratab entries are also removed, if you have single instance databases running with GI (to use restart/ASM) while the node restarts or you restart a database manually with srvctl. You don’t need to have a RAC…
True – I currently try to figure this out for another customer with RESTART where oratab gets corrupted.
I’ll update this blog post once I have more clarification.
The only thing helped was to add own comments. Removing “#line added by agent” was not enough => https://a-different-view-by-js.blogspot.com
That’s an interesting workaround.
In the case I deal with a customer, where we have no comments except the one from the agent. I’ll give this a try (adding own comments).
For Single Instance, starting 19c, Oracle (db creation script and even DBCA) does not add entry to /etc/oratab. Instead once it is done creating the database, it prints on screen an instruction asking the user to do so. The instruction looks like this:
echo You should Add this entry in the /etc/oratab:
For my 19c DBs, I still get the entries in /etc/oratab.