{"id":65,"date":"2015-01-25T11:56:23","date_gmt":"2015-01-25T11:56:23","guid":{"rendered":"https:\/\/www.spotonoracle.com\/?p=65"},"modified":"2016-05-10T16:29:56","modified_gmt":"2016-05-10T16:29:56","slug":"mashing-up-audit-parameters","status":"publish","type":"post","link":"https:\/\/www.spotonoracle.com\/?p=65","title":{"rendered":"Mashing up audit parameters"},"content":{"rendered":"

This is a short follow-up on my earlier post Don\u2019t ditch AUDIT_TRAIL prematurely<\/a>.
\nAs it turns out AUDIT_TRAIL is not the only parameter that still affects the behaviour when Unified Auditing is enabled.
\nSince we have reset all “old” audit parameters except AUDIT_TRAIL the configuration looks like this:<\/p>\n

\r\nSQL> show parameter audit\r\nNAME                      TYPE        VALUE\r\n------------------------- ----------- --------------------------------\r\naudit_file_dest           string      \/u01\/app\/oracle\/admin\/DEV1\/adump\r\naudit_sys_operations      boolean     TRUE\r\naudit_syslog_level        string\r\naudit_trail               string      DB\r\n<\/pre>\n
Although AUDIT_SYS_OPERATIONS defaults to TRUE we wouldn’t expect audit files being written – we’re using Unified Auditing after all.
\nTo my surprise the Oracle database still writes OS audit files. E.g. here on my playground VM I see MMON slave process writing a file.<\/p>\n
\r\nll \/u01\/app\/oracle\/admin\/DEV1\/adump\/\r\n-rw-r-----.  1 oracle oinstall 2637 Jan 25 12:59 DEV1_m001_4546_20150125125939459040143795.aud\r\n<\/pre>\n
On customer systems I’ve also seen audit files from Scheduler jobs Jnnn processes. I haven’t figured a pattern yet and it seems to be different on various platforms. On Windows there’s a lot more recorded in the Windows Event Log (mainly AWR activity) than there’s written to ADUMP on Linux.
\nSolaris is a different story again. What I’ve found reproducible on Linux is connecting with a JDBC client (SQL Developer) and run any query that fails at parse time. Strangely enough, this does not happen when using SQL*Plus (OCI client). E.g.:<\/p>\n
\r\nSun Jan 25 14:15:33 2015 +01:00\r\nLENGTH : '175'\r\nACTION :[18] 'select K from dual'\r\nDATABASE USER:[3] 'SYS'\r\nPRIVILEGE :[6] 'SYSDBA'\r\nCLIENT USER:[3] 'btr'\r\nCLIENT TERMINAL:[7] 'unknown'\r\nSTATUS:[3] '904'\r\nDBID:[10] '3434795880'\r\n<\/pre>\n
What gets written to the audit files is not what we have specified in the unified audit policies, so setting AUDIT_SYS_OPERATIONS to FALSE to prevent all the extra auditing appears to be safe. So far, I haven’t seen any adverse effect on the unified audit trail, but you may want to check the proper functioning on your platform and audit configuration yourself.<\/p>\n
Foot note 1:<\/strong> If $ORACLE_BASE\/admin\/$ORACLE_SID\/adump directory does not exists AUDIT_FILE_DEST is defaulting to $ORACLE_HOME\/rdbms\/audit.<\/p>\n
Foot note 2:<\/strong> If AUDIT_FILE_DEST is set explicitly to a non-existing directory, you’ll see alert.log entries indicating that the OS audit trail could not be written: “OS Audit file could not be created; failing after 6 retries”<\/p>\n
Foot note 3:<\/strong> All test have been run on Oracle 12.1.0.2<\/p>\n
Update 10-May-2016:<\/strong> The issue is documented on MOS as bug 21133343 (see MOS note: 21133343.8). Patches are available for Linux x86-64 and AIX on Power.<\/p>\n","protected":false},"excerpt":{"rendered":"
This is a short follow-up on my earlier post Don\u2019t ditch AUDIT_TRAIL prematurely. As it turns out AUDIT_TRAIL is not the only parameter that still affects the behaviour when Unified Auditing is enabled. Since we have reset all “old” audit parameters except AUDIT_TRAIL the configuration looks like this: SQL> show parameter audit NAME TYPE VALUE […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,3],"tags":[],"class_list":["post-65","post","type-post","status-publish","format-standard","hentry","category-auditing","category-internals"],"_links":{"self":[{"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/posts\/65","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=65"}],"version-history":[{"count":7,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/posts\/65\/revisions"}],"predecessor-version":[{"id":128,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/posts\/65\/revisions\/128"}],"wp:attachment":[{"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=65"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=65"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=65"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}