Thursday, 29 March 2012

Oracle: Connect /as sysdba or Startup Fails With ORA-09925 When Instance Is Down [ID 392643.1]



Connect /as sysdba or Startup Fails With ORA-09925 When Instance Is Down [ID 392643.1]

  Modified 07-MAR-2012     Type PROBLEM     Status PUBLISHED  

In this Document
  Symptoms
  Cause
  Solution
  References




Applies to:

Oracle Server - Enterprise Edition - Version: 8.1.7.0 to 11.1.0.7 - Release: 8.1.7 to 11.1
Information in this document applies to any platform.
Checked for relevance on 05-Oct-2010

Symptoms

When the database instance is down, trying to connect or startup the database fails with:

ERROR:
ORA-09925: Unable to create audit trail file
SVR4 Error: 13: Permission denied
Additional information: 9925


Cause

On Unix systems, the investigation should be done using the OS tracing utility, ie: truss (AIX, Solaris), strace (Linux) or tusc (HP-UX).

truss -aefo sqlplus.trc sqlplus "/ as sysdba"

shows that the problem is caused by a missing directory, insufficient permissions or not enough space on that particular directory:

open("/opt/oracle/admin/test102/adump/ora_31704.aud", O_RDWR|O_CREAT|O_APPEND|O_LARGEFILE, 0660) = -1 EACCES (Permission denied)

From 10gR2, the $ORACLE_BASE/admin//adump directory is the new default directory for audit files (instead of previous releases location, $ORACLE_HOME/rdbms/audit).

Solution

1. Starting with 10gR2, check if the
$ORACLE_BASE/admin/$ORACLE_SID/adump

directory exists and create it if not.

2. If the directory exists (in previous releases check: $ORACLE_HOME/rdbms/audit), make sure that permissions on it are set to 775.

3. If the directory exists and permissions are correctly set, make sure that there is enough space on the file system to accommodate the newly created audit files.

Starting with 10gR2: Note that when the database instance is down and the first connect and the startup command is run, the audit_file_dest parameter is not yet initialized, hence unknown to the shadow process, as such the audit files for these commands can only be written to the default destination. Writing these files is a mandatory requirement for NCSC C2 security evaluation criteria and therefore this behavior cannot be turned off.

4. The above assumes that ORACLE_BASE is set, as recommended by the documentation. If ORACLE_BASE is not set, then the default audit location becomes: $ORACLE_HOME/admin//adump. This is important to mention especially on RAC, where the environment variables are set in the OCR and should be updated, as documented, using srvctl, eg:
srvctl setenv database -d -t ORACLE_BASE=

5. A very rare scenario that was found is when ORACLE_PATH was set and the Oracle software transparently appended it to the default value: $ORACLE_BASE/admin/$ORACLE_SID/adump. ORACLE_PATH has to be unset to solve the problem. This is being investigated in:

Bug 13584524 Bug 13584524 - strange audit destination if oracle_path is set: ora-09925

References

NOTE:103964.1 - How to Audit Connect AS SYSDBA Using Oracle Server
BUG:13584524 - STRANGE AUDIT DESTINATION IF ORACLE_PATH IS SET: ORA-09925

No comments:

Post a Comment

Number of Visitors