mk_oracle searches in /etc/oratab or /var/opt/oracle/oratab for the SID âstdddâ to determine oracle_home for this db. if the oratab file cannot be found or read then this error message appears. That is the first thing I would check.
Hey @LaSoe thanks for the idea, I checked that file on that location /etc/oratab and all I have there is this entry:
repo:/u01/app/oracle/product/19.0.0/db:N
Can I add this âstdddâ SID also here, will I mess something up, since this is a production system? I am not an Oracle DB admin, and we have none currently.
Iâm not an Oracle expert, but I thought a database is automatically added to the oratab during installation.
It might be possible to add the entry manually (without guarantee). However, it is not advisable to experiment in a production environment. I would recommend consulting the Oracle documentation for more detailed guidance.
In our setup, we donât have a sqlnet.ora and tnsnames.ora files in â/etc/check_mk/â.
Maybe you can rename these files and try again. If that doesnât work, you can also try to configure the TNS_ADMIN in your mk_oracle.cfg (oracle default path: $ORACLE_HOME/network/admin) .
Another possible reason why itâs working for me is that Iâve added up a fallback for TNS_ADMIN in our mk_oracle:
TNS_ADMIN=${TNS_ADMIN:-$MK_CONFDIR}
if ! test -f "${TNS_ADMIN}/sqlnet.ora"; then
logging -c "[${sid}] [set_ora_env]" "no sqlnet.ora found in '${TNS_ADMIN}'. checking as next the default location ORACLE_HOME."
# use oracle default path as fallback
TNS_ADMIN="${ORACLE_HOME}/network/admin"
if ! test -f "${TNS_ADMIN}/sqlnet.ora"; then
logging -c -e "[${sid}] [set_ora_env]" "ORA-99999 sqlnet.ora for SID '${ORACLE_SID}' not found or not existing!"
exit 1
fi
fi
As @LaSoe said in his last comment, you can try setting the TNS_ADMIN depending on the path where it is located and then perfrom a connection test using ââno-spool -tâ
The file is normaly changed by the DBCA (Database Creation Assistant).
If the entry is missing, the database has been renamed, copied from anaother system or was created on a different way - not with DBCA.
Normaly the file could be changed after the installation.
DBCA will fail during database creation, when an entry for the new database is existing in the oratab.
Make sure to edit the file with:
<ORACLE_SID>:<ORACLE_HOME>:N
The âNâ at the end is for âno autostartâ of database during boot, when startup scripts from Oracle are in use. A âYâ enables the autostart.
Be careful with the ORACLE_HOME.
If an Instance is started, the environment variable for ORACLE_HOME + ORACLE_SID forms a hash value for the address of the shared memory segment for the instance.
The address is different, with or without a â/â at the end!
Some notes about the TNS_ADMIN variable in mk_oracle.
I made the design in that way, because the default behavior from Oracle is exactly the same. Debugging connections issues with Oracle Client directly will be harder, when mk_oracle has a different logic to find the tnsnames.ora for the connection.
This is really important when working with wallets, because that has a high potential for debugging with the Oracle Client.
Setting TNS_ADMIN on a fixed ORACLE_HOME could be dangerous, because that is a huge difference to the code in mk_oracle.
The plugin searchs for instances and gets the ORACLE_HOME per Instance, to form the TNS_ADMIN. We search for sqlnet.ora inside of the ORACLE_HOME for the instance!
This is fine, when only 1 instance is running on the system but it could be different with Instances with distinct ORACLE_HOMEs and a fixed TNS_ADMIN pointing to 1 of the instances.
Multiple ORACLE_HOMEs are common these days. Some customers are patching the database with changing the value for ORACLE_HOME. If someone removes the old ORACLE_HOME the monitoring is broken, because the path from TNS_ADMIN is invalid - thatâs why I search with $ORACLE_HOME/network/admin from the running instance instead a fixed value.
Hey, @Rendanic thanks for the follow up. Yes, the database was copied from an older version then the DB admin did the restore when we were migrating from the older version of Oracle DB.
Just a quick question. Since those entries didnât exist in oratab file does this mean that those databases couldnât auto start after the server restart or there is another mechanism in play?
The Database software installation of Oracle or the DBCA do not install script for autostart of Instances on a server. root.sh changes some files on the system but do not install autostart scripts.
You have to install them manually.
The state âYâ is needed for the examplescriptsâŠ
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.