Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL Processes:Audit

AuditLevel

The auditLevel property sets the audit trail logging level. This configuration property is applicable to both durable and transient processes. This property controls the amount of audit events that are logged by a process. Audit events result in more database inserts into the audit_trail table which may impact performance. Audit information is used only for viewing the state of the process from Oracle Enterprise Manager Console.

Value	Description
Inherit	Inherits the audit level from infrastructure level.
Off	No audit events (activity execution information) are persisted and no logging is performed; this can result in a slight performance boost for processing instances.
Minimal	All events are logged; however, no audit details (variable content) are logged.
Error	Logs only serious problems that require immediate attention from the administrator and are not caused by a bug in the product. Using this level can help performance.
Production	All events are logged. The audit details for assign activities are not logged; the details for all other activities are logged.
Development	All events are logged; all audit details for all activities are logged.

AuditDetailThreshold

The auditdetailthreshold property sets the maximum size (in kilobytes) of an audit trail details string before it is stored separately from the audit trail. If an audit trail details string is larger than the threshold setting, it is not immediately loaded when the audit trail is initially retrieved; a link is displayed with the size of the details string. Strings larger than the threshold setting are stored in theaudit_details table, instead of the audit_trail table.

The details string typically contains the contents of a BPEL variable. In cases where the variable is very large, performance can be severely impacted by logging it to the audit trail.

The default value is 50000 (50 kilobytes).

AuditStorePolicy

This property specifies the strategy to persist the BPEL audit data.

Value	Description
syncSingleWrite (default)	AuditTrail and dehydration are persisted to DB in one transaction.
syncMultipleWrite	AuditTrail and dehydration are persisted in the same thread but separate transactions.
async	AuditTrail and dehydration are persisted by separate threads and separate transactions.

By default, audit messages are stored as part of the main BPEL transaction. A BPEL instance holds on to the audit messages until the flow reaches dehydration. In some use cases, for example when you have a large loop, and there is no dehydration point in the loop, a large number of audit logs are accumulated. This could lead to an out-of-memory issue and BPEL main transaction can experience timeout errors. You may consider using syncMultipleWrite or async to store the audit message separately from the main transaction.
When you use syncMultipleWrite and async auditStorePolicy, there are a few other properties that need to be considered. Please see the sections below.

AuditFlushByteThreshold

This property controls how often the engine should flush the audit events, basically after adding an event to the current batch, the engine checks to see if the current batch byte size is greater than this value or not.
Consider tuning this property when async or syncMultipleWrite audit strageties are used. This size needs to be tuned based on the application.

AuditFlushEventThreshold

This property controls how often the engine should flush the audit events, basically when it reaches this limit of the number of events, the engine would trigger the store call.
Consider tuning this property when async or syncMultipleWrite audit strageties are used. This size needs to be tuned based on the application.