Thanks, that's good to know. I should be clear in that the audit trigger I'm considering is not the Oracle provided AUDIT SESSION. Rather it is home grown pre-insert and pre-update triggers on our application tables that sets the value of two columns in a row that is being inserted or updated. Not a lot of stuff going on there. We have a 5 node RAC. On 4/9/08, Hemant K Chitale <hkchital@xxxxxxxxxxxxxx> wrote: > > > I DID have problems with AUDIT SESSION that was enabled for a short while > in an RAC instance. > Although the AUDSES$ sequence had been altered to a high CACHE value, > there was some severe > contention during a connection storm (connections coming in at about 1 > every 3 seconds) and one > instance did crash. We disabled Session Audit then. > In my opinion, SYS.AUD$ tries to capture too much information. > > Hemant K Chitale > http://hemantoracledba.blogspot.com > > At 11:19 PM Wednesday, Rumpi Gravenstein wrote: > > > I would like to add audit triggers to populate record create user and > > timestamp columns ( :new.rcd_create_user_id := USER and :new.rcd_create_dt > > := SYS_TIMESTAMP). They have an unwritten policy that states triggers > > should be avoided if at all possible. I'm trying to find factual support > > that their contention that triggers cause "library cache lock waits" which > > in turn impact the database resulting in unacceptable production problems is > > misplaced, especially for the type of audit triggers I'm considering. > > > > > > -- Rumpi Gravenstein