After getting the Oracle Instant Client and DBD::Oracle successfully installed, users noticed that they were getting enormous log files in oradiag_[username]/diag/clients/user_[username]/host_nnnnnn_nn , and that logging was apparently set to 16, which is full ridiculous logging. E.g. alert/log.xml had:
<msg time='2011-08-10T13:36:50.258-04:00' org_id='oracle' comp_id='clients'
type='UNKNOWN' level='16' host_id='hostname.domain.etc' host_addr='nnn.nnn.nnn.nnn'>
<txt>Directory does not exist for read/write [/usr/lib/oracle/11.2/client64/log] []
</txt>
</msg>
LAME. So lame. Following various advice, I added the following to $ORACLE_HOME/network/admin/sqlnet.ora :
TRACE_LEVEL_CLIENT = OFF
TRACE_DIRECTORY_CLIENT=/dev/null
LOG_DIRECTORY_CLIENT = /dev/null
LOG_FILE_CLIENT = /dev/null
LOG_LEVEL_CLIENT = OFF
... all apparently for nothing. However, I eventually found Oracle document 454927.1 (note: you need to be logged in to support.oracle.com for that link to work), which indicated I needed to also disable ADR (new as of client 11.2, fancy-pants xml-based logging system) using DIAG_ADR_ENABLED = OFF. THEN you are in the old logging mode, at which point your old settings to completely avoid OCI logging will work. So, sqlnet.ora should look like this:
DIAG_ADR_ENABLED = OFF
TRACE_LEVEL_CLIENT = OFF
TRACE_DIRECTORY_CLIENT=/dev/null
LOG_DIRECTORY_CLIENT = /dev/null
LOG_FILE_CLIENT = /dev/null
LOG_LEVEL_CLIENT = OFF
HOWEVER, you must make sure that users have TNS_ADMIN=/usr/lib/oracle/11.2/client64/network/admin/ (or wherever your sqlnet.ora file is). You can add the line "export TNS_ADMIN=/path/to/your/file/" to /etc/profile to set it for all your users by default. Users can override TNS_ADMIN in their ~/.bashrc file to whatever they want.
Note - why would you want to disable the Oracle Instant Client logging? Isn't logging inherently good and disabling it inherently evil?
- If your application (e.g. perl) is already catching Oracle errors.
- If your application is in production and making many requests, the I/O from the logging might slow it down to a measurable extent.
Other sources that helped me find this solution: stackoverflow.com, CERN Savannah Bugs #58917, Oracle Forums thread #959329 (only found via the CERN page - gah!).
... thanks guys!
LOG_LEVEL_CLIENT? I didn't find this parametr in doc.
ReplyDeletehttp://docs.oracle.com/cd/B28359_01/network.111/b28317/sqlnet.htm#NETRF184
Hmm, well try it without that parameter and let us know how it goes. If it works just fine without the parameter, guess the parameter is meaningless.
DeleteI no longer maintain an installation using this software so I'm unable to test it myself.
IMPORTANT: DO NOT SET "LOG_FILE_CLIENT=/dev/null", this will cause permissions of /dev/null be reset each time you initialize oracle library, and when your umask is something that does not permit world readable-writable bits, those get removed from /dev/null and if you have permission to chmod that file: i.e running as root.
ReplyDeleteand running as root maybe something trivial, like php --version having oci php-extension present!
full details here:
http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2014-May/023931.html
Thank you for making the internet a better place! What are you doing instead to avoid accumulating all these logs?
Deletei don't have solution now, seems using invalid path makes oracle libraries log to default location
Deletei'll try to keep answers here as well:
https://stackoverflow.com/questions/848166/stop-oracle-from-generating-sqlnet-log-file/23817789#23817789
Best option so far, but still a hack
ReplyDeletetouch /usr/fake-oracle-null
chattr +i /usr/fake-oracle-null
LOG_DIRECTORY_CLIENT=/usr/fake-oracle-null
LOG_FILE_CLIENT=/usr/fake-oracle-null
On Mac this approach seems to work with a slight modification:
ReplyDelete>sudo touch /usr/null
>sudo chflags uchg /usr/null
sqlnet.ora:
DIAG_ADR_ENABLED=OFF
TRACE_LEVEL_CLIENT=OFF
TRACE_DIRECTORY_CLIENT=/dev/null
LOG_DIRECTORY_CLIENT=/usr/null
LOG_FILE_CLIENT=/usr/null
LOG_LEVEL_CLIENT=OFF
Has anyone tried the /tmp directory? It won't eliminate performance issues, but if clean periodically, perhaps a cron job, then there shouldn't be an log related space issues.
ReplyDelete