Use
You specify the information you want to audit in filters that you can either:
If you use this option, all of the application servers use identical filters for determining which events should be recorded in the audit log. You only have to define filters once for all application servers.
You can also define several different profiles that you can alternatively activate.
With this option, you can dynamically change the filters used for selecting events to audit. The system distributes these changes to all active application servers.
This topic concentrates on permanently saving filters in static profiles in the database. For information on changing the filters dynamically, see
Changing Filters Dynamically.
Filters saved in static profiles take effect at the next application server start.
Prerequisites
The following profile parameters must be set:
Audit Log Profile Parameters
Profile Parameter |
Description |
rsau/enable |
Enable the Security Audit Log |
rsau/local/file |
Names and locations of the audit files |
rsau/max_diskspace/local |
Maximum space to allocate for the audit files |
rsau/selection_slots |
Number of filters to allow for the Security Audit Log |
Procedure
The Security Audit: Administer Audit Profile screen appears with the Static configuration tabstrip activated. If an active profile already exists, it is displayed in the Active profile field.

To display an existing profile before changing it, choose Profile ® Display.
The lower section of the screen contains tabstrips for defining filters. The number of tabstrips correspond to the value of the profile parameter
rsau/selection_slots . Within each tabstrip, you define a single filter. Define filters for your profile.Result
The filters you define are saved in the audit profile. If you activate the profile and restart the application server, actions that match any of the active filter events are then recorded in the Security Audit Log.

On some UNIX platforms, you also need to clear shared memory by explicitly executing the program