If I open a standby database for read-only (via Active Data Guard), and I have native database auditing configured on the the primary to log both successful and unsuccessful logins (among other things), do logins to the standby fail (because they can't write to sys.aud$)?
I believe they would. I know its on my checklist to either turn off audit on the standby or have it write to the OS instead of the database.
Changes to existing parameters
*.audit_trail = none
Current primary database must have “audit_trail” set to “none”
If you don't have it set to OS or NONE you will probably get an ORA-16006. Having it set to DB is incompatible with a database opened for READONLY access.
Your question is good because its one everyone wants to avoid.
Thanks Hemant, I always enjoy your posts. MS
Edited by: mseberg on Mar 8, 2011 7:43 AM
I know its on my checklist to either turn off audit on the standby
Good point. I believe that there are a couple of MetaLink (MOS) notes about this.
However, it still doesn't appear in the "Create a Parameter File for the Standby Database" section of the Dataguard Administration documentation.
Hemant K Chitale
Thank You Larry.
Can you tell me is this documented? When I looked at E10700-02 the only thing I was able to find was:
C.12.2 Replication of AUD$ and FGA_LOG$ on Logical Standbys
After my Oracle 10 experience I assume you still set audit_trail when I could find no supporting docs.
I don't believe it is documented anywhere. Sigh.
You will see the following in the alert log when you open the standby read only and you had the parameter set to DB.
AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access