Re: Oracle Auditing
Date: Wed, 17 Mar 2010 11:42:32 +0000
On 2010-03-16, The Magnet <art_at_unsu.com> wrote:
> On Mar 16, 10:54 am, Eric <e..._at_deptj.eu> wrote:
>> gazzag <gar..._at_jamms.org> wrote:
>> > On 16 Mar, 13:21, The Magnet <a..._at_unsu.com> wrote:
>> > Are you sure that you're checking the right database? The error is:
>> > RMAN-04005: error from target database:
>> > ORA-09925: Unable to create audit trail file
>> > Linux-x86_64 Error: 2: No such file or directory
>> > Which database are you running the "show parameter" command on? The
>> > error appears to be coming from your RMAN repository.
>> > HTH
>> > -g
>> "error from target database"?? This is the database to be backed up, not
>> the repository. The OP may not even have a repository.
>> What ve definitely does not have is a writable directory at the location
>> specified by the audit_file_dest parameter.
>> Nothing to do with turning auditing on or off either.
> Well, the directory where all the audit files are appearing is not the
> default Oracle audit directory. So, he changed the location when he
> enabled auditing. We never had this before he switched the auditing
> on and off.
Audit files are written to the directory specified in the audit_file_dest parameter. Changing it simply means that the same files are written to the new location.
> We are using a control file, not a repository.
As I suspected.
> Is it possible that RMAN needs some sort of change also? And, the
> database has been bounced since then.
No, RMAN is just showing evidence of a general problem. There are presumably similar errors in the database alert log.
> Worst case, put it back and remove the files daily, do not want that
> solution though.
Not worst case, only case! You originally said that you had looked at the docs, but this obviously did not include
where it says, among other things, "Regardless of whether database auditing is enabled, Oracle Database always audits certain database-related operations and writes them to the operating system audit file." So you are stuck with having that directory.
It is possible that the auditing experiment left lots of files there, but now that auditing is turned off you should not actually be getting enough files written to the audit directory to need daily cleanup unless you are using "/ as sysdba" for routine work rather than only when absolutely necessary.
And what's wrong with having to clean up anyway? - write a cron job and forget it.
Actually I don't usually bother because the volume is so low, I just check that directory (among others) if the filesystem throws a low-space alarm.
Eric Received on Wed Mar 17 2010 - 06:42:32 CDT