RE: Overhead Associated with Signon Audit in Financials 11.0

Thanks for the input, John. I am primarily concerned about I/O overhead, but I guess that depends on the level of auditing selected, number of concurrent users, which apps they are logged into, time of the month, etc.etc...

Vicki Pierce
Database Administration
x2401

John Kanagaraj <john.kanagaraj_at_hds.com> Sent by: ml-errors_at_fatcity.com
10/30/2003 07:24 PM
Please respond to
ORACLE-L_at_fatcity.com

To
Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> cc

Subject
RE: Overhead Associated with Signon Audit in Financials 11.0

For all the non-APPS DBAs out there...

Oracle Applications 10.4 onwards (lowest version I have seen) provides for a
feature called 'Signon Auditing'. This is NOT Oracle's Auditing (which goes
into SYS.AUD$). It is a parameter driven auditing that records all Users that logged in when set to USER, Application Responsibilities that they chose (upon login as well as subsequently switched to) when set to RESPONSIBILITY, in addition to recording the USER level, and the Forms that
they chose to run when set to FORMS, in addition to that recorded at RESPONSIBILITY and USER levels. Thus, when set to FORMS, a user login would
at best produce a minimum of three rows, etc. These rows are updated when the user logged out, so all sorts of reports about who is/was logged on, forms currently being used, etc. can be determined. In fact, for an Apps DBA
to tie back a session to an actual user, at least USER level signon auditing
should be turned on. The problem with Apps is that all users would login in
the APPS schema using the encrypted password which is obtained using a dummy connection... Forms and further Access is then determined by 'Responsbilities' that are in turn tied to 'Organizations' and 'Datasets'. By default, almost all Applications tables record the last updated user and
timestamp, so there is some inbuilt auditing, albeit not a trail. Oracle provides an additional Audit function that performs an audit trail for such
datasets, and this can produce significant overhead for data storage.

Thus.... all discussions about SYS.AUD$ are not really relevant in this particular thread, although some good ideas have been aired. Switching on Auditing without understanding what is ultimately required would be very counterproductive, whether this is on an APPS database or not, in any case.

[As an aside, most of this is enabled via the AOL - Applications Object Layer (aka FND - Foundation Layer) and is a solid example of providing 'Application' infrastructure. And don't get me started on the Concurrent Processing - that's an excellent one too]

I am going to stop now and let Apps gurus such as Andy R, Tanel and Tim G comment.

John Kanagaraj
Oracle Applications DBA
DB Soft Inc
Work : (408) 970 7002

Listen to great, commercial-free christian music 24x7x365 at http://www.klove.com

• The opinions and facts contained in this message are entirely mine and do not reflect those of my employer or customers **

>-----Original Message-----
>From: Mladen Gogala [mailto:mladen_at_wangtrading.com]
>Sent: Thursday, October 30, 2003 1:39 PM
>To: Multiple recipients of list ORACLE-L
>Subject: Re: Overhead Associated with Signon Audit in Financials 11.0
>
>
>It is true, auditing adds significant overhead, but not
>session auditing.
>Significant overhead is added by DML auditing because you ad
>significant
>amount of modified blocks to every transaction you audit, you

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: John Kanagaraj
  INET: john.kanagaraj_at_hds.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: 
  INET: VICTORIA_PIERCE_at_rsausa.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).