How to disable auditing

Did you bounce the database after setting this?  If not, I believe you need to.

Just for giggles, the host and the file share are used by one and only one database instance?

no, there are a number of databases on the host

OK?

I believe what dvz was getting at is:  Are there other databases generating audit records in the same folder?

You also didn't mention if you had bounced the database...

Yes, I have bounced the database. And I did check, it is not the case where other databases generate audit files in the folder of another database.

This is the strangest thing ever. None of the databases have auditing enabled, yet some still create audit files.

This particular database id not even running - I started it up, disabled auditing, did the same for its standby on another server and then shut them both back down.

Still .aud files are produced

slightwv, I checked the audit_sys_operations and it is set to false, and audit_syslog_level is set to blank

OK, I'm officially out of ideas.

I'll send out a call for help to see if other Experts might have additional ideas.

I would suggest opening an SR with Oracle Support to see what might be going on.

Who owns the files in this audit directory?  Is that the same O/S user as the one that runs your Oracle database(s)?

What do the contents of those files look like?  Can you post a small portion of one of them here?  (Remove or edit any confidential information first, like: usernames, passwords, etc.)

What is your server O/S: Linux , UNIX, Windows, etc?

YZlat, any progress at your end?

Nope, the .aud files are still massproduced for the database that has been shut down. i am working on laternative solution - to run the script daily that will remove old audit files.

Although there should be a way to disable auditing completely for a dtabase that is in a shutdown state and is not in use

I've not done much with auditing but I seriously doubt Oracle can generate audit records for a database that is shut down.

Something else is likely going on here.

If you drop the adump directory then you will not have audit file, and anyone that tries to do an audited operation will have an error.

frankpachot, are you sure it's a good idea? I do not need anymore problems on that server.

Is there a way to detect who and what is generating those audit files?

Personally I wouldn't suggest troubleshooting this via the method of renaming the folder and see what system complains.

I would open an SR with Oracle Support.

>>Is there a way to detect who and what is generating those audit files?

There should be some information inside the files that should assist in narrowing down what instance they are coming from.

So post a couple of the .aud, please.

Here are the contents of .aud file:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0.3
System name:    AIX
Node name:      server001
Release:        1
Version:        6
Machine:        MACHINENAME
Instance name: DBName
Redo thread mounted by this instance: 0 <none>
Oracle process number: 0
Unix process pid: 22741122, image: oracle@server001.domain.com

Thu Dec  5 16:10:28 2013 -05:00
LENGTH : '160'
ACTION :[7] 'CONNECT'
DATABASE USER:[3] 'sys'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[13] 'Not Available'
STATUS:[1] '0'
DBID:[0] ''

Select allOpen in new window

I know sysdba action will always be auditied, but the database is not running

>>I know sysdba action will always be auditied, but the database is not running

Think about it.  If sysdba will always be audited, how do you start up a database?

Your database may not be running, but this audit log entry indicates that someone (or some process) is attempting to connect to the database with "SYSDBA" privileges.  That is like a .super-user, or administrator.

You may want to determine who or what this is.

markgeer, any tips on how to do that?

Hi,
Yes, your instance is shut down (Redo thread mounted by this instance: 0) bur you have a job  - not a user (CLIENT TERMINAL:[13] 'Not Available') that tries to connect as sysdba from server001.domain.com OS user 'oracle'
You should check what is doing that (cron job, deamon script , ???)
Regards,
Franck.

"any tips on how to do that?"

Without knowing your system, that is somewhat difficult.  Dvz gave you some suggestions.  We don't know who manages the O/S and access to your servers.  I assumed that you would know that.

Still no luck:( I might just go ahead and open SR with Oracle