Optimizing EBS Audit Reporting Performance with Indexing

Performance optimization for large audit tables is crucial . It is strongly recommended to create indexes on the primary key columns and the `row_key` column of the shadow tables . For example, on `AP_SUPPLIERS_A`, an index on `(vendor_id, row_key)` is beneficial because audit queries often link sequential changes for a single record using the `row_key` .

Yes, indexing the `audit_timestamp` column is also highly recommended , . This is because most audit reports restrict data selection based on the transaction time . Creating an index on this column (e.g., `on ap.ap_suppliers_a (audit_timestamp)`) will significantly speed up queries filtered by time range .

It is mandatory to test the index creation in a test instance first . DBAs must verify two things: 1) Measure the performance and execution plan of an audit report before and after indexing . 2) Test if the EBS transaction performance for the base tables did not decrease significantly . Indexes on shadow tables require resources for maintenance (insertion/update during transactions) and may slow down production transaction performance .

Yes, a viable alternative is to shift the resource-intensive audit reporting load entirely off the production instance . This can be achieved by running your Blitz Reports on an Active Data Guard standby server . Alternatively, you can move the audit data to a dedicated operational data store for reporting purposes .