Database Reference
In-Depth Information
Understanding
and
configuring
composite audit levels
Setting the level of auditing tells the SOA Infrastructure how much information
you want logged in order to assist in the monitoring and troubleshooting of in-
stances. For example, if the audit level is completely
off
, the administrator will
have no visibility into any composite instance. No instance data is logged and it
is impossible to tell anything at that point (although instances are actually cre-
ated and requests are serviced just fine). On the other hand, if the audit level is
set to
development
, not only is the instance data logged, but the payload is
also logged at every operation, giving the administrator complete visibility into the
step-by-step execution of every instance!
Although setting the audit level to development may appear tempting, it has both
performance and storage implications. Audit data is stored in the database, and
if you have a large number of transactions, the database growth can be huge.
One large customer of Oracle SOA Suite 11g has audit data that grows by nearly
10 gigabytes per day, faster than they are able to purge it! The following graphs
show that as the payload size increases, the resulting database storage needs
drastically increase for
development
versus
production
audit levels. For ex-
ample, for a sampling of 500 messages with an average message size of 400 KB,
successful transactions result in 90 MB of storage space needed for
develop-
ment
audit levels versus 31 MB for
production
. For faulted transactions, it's
even worse. 488 MB is needed if the
development
audit level is set versus 190
MB for
production
.
