This chapter explains how to perform day-to-day audit administration tasks.
See Also:
Chapter 13, "Introduction to Oracle Fusion Middleware Audit Service" for background information about auditing in Oracle Fusion Middleware.As audit administrator, you should plan the site's audit setup carefully by following the steps in these areas:
Implementation Planning
This includes planning the type of store to use for audit records, data store configuration details, and so on.
See Section 14.2, "Managing the Audit Data Store" for details.
Policy Administration
You must configure the appropriate audit policies to ensure that the required audit events are generated.
This is an ongoing activity since the audit policies must be able to reflect changes to the application environment, addition of components and users, and so on.
See Section 14.3, "Managing Audit Policies" for details.
Reports Management
This includes planning for and configuring audit reports and queries.
See Chapter 15, "Using Audit Analysis and Reporting" for details.
Data Administration
This includes planning/increasing the database size required to store the audit data generated, backing up the audit data and, purging the audit data based on company policy.
See Section 14.6, "Advanced Management of Database Store" for details about audit data store administration.
Out of the box, the audit framework uses the file system to store audit records. However, in a production environment, Oracle recommends that you use a database audit data store to provide scalability and high-availability for the audit framework.
In addition, an audit data store residing in a database allows the audit data to be viewed through Oracle Business Intelligence Publisher with pre-packaged audit reports that are available with that product. Oracle Business Intelligence Publisher is available in the 12c (12.1.2) CD pack.
This section explains these audit data store management tasks in detail:
To switch to a database as the permanent store for your audit records, you first use the Repository Creation Utility (RCU) to create a database store for audit data. Out-of-the-box, Release 12.1.2 offers two profiles: compact and expanded (default).
This section explains how to create the audit schema.
Note:
The bus-stop files store audit records in the absence of database storage.Note:
This discussion assumes that RCU and the database is already installed in your environment. See the Installation Guide for more information.Once the database schema is created, you can:
create a datasource to point to this schema.
update the domain configuration to switch the audit data store for audit records (see Section 14.2.3.2, "Configure the Audit Data Store and Bus-Stop Storage").
Notes:
These actions are not required if you have specified audit artifact details as shown in Chapter 7.Before you begin, make sure to collect the details on which database to use, along with the DBA credentials to use.
Configuring the Database Schema
The procedure shown here configures a schema for the audit data store.
The steps are as follows:
Go to $RCU_HOME/bin
and execute the RCU utility.
Choose Create at the starting screen. Click Next.
The Database Connection Details page appears. Enter your database details:
Click Next. RCU verifies prerequisites; click OK to proceed.
The Select Components page appears. Choose the option to create a new prefix, for example DEV4
. The prefix is applied to schema owner and tablespace names. Three schema users are created using this prefix; in the example, they are DEV4_IAU, DEV4_IAU_APPEND, and DEV4_IAU_VIEWER.
Also, select 'Audit Services' from the list of schemas; the next two schemas are automatically selected. (Note: Do not select these two schemas by themselves as they are only auxiliary schemas.)
Click Next. RCU verifies component prerequisites; click OK to proceed.
The Schema Passwords page appears.
Enter the password and click Next.
The Map Tablespaces page appears. Click Next and accept the tablespace creation.
Click OK to dismiss the tablespace creation confirmation box.
The Summary page appears.
Check the details and click Create.
Check for any errors while the schemas are being created. Verify that the job is successful on the Completion Summary page:
This process will take several minutes to complete.
Note:
Oracle Fusion Middleware 12c (12.1.2) does not support creating an IAU schema in Oracle Database enabled for Edition Based Redefinition (EBR).As explained in Section 14.2.1, "Create the Audit Schema using RCU", after you create a database schema to store audit records in a database, you must set up an Oracle WebLogic Server audit data source that points to that schema.
Take these steps to set up an audit data source:
Note:
This task is performed with the Oracle WebLogic Server administration console.Connect to the Oracle WebLogic Server administration console:
http://host:7001/console
Under JDBC, click the Data Sources link.
The Data Sources page appears. Click New to create a new data source.
Enter the following details for the new data source:
Name: Enter a name such as Audit_Data_Source-0
.
JNDI Name: jdbc/AuditDB
Database Type: Oracle
Database Driver: Oracle's Driver (Thin XA) Versions: 9.0.1, 9.0.2, 10, 11
If deploying to a managed cluster server, also check AdminServer; this ensures that the data source is listed in the audit data store when switching from file to database store.
Click Next.
The Transaction Options page appears. Click Next.
The Connection Properties page appears. Enter the following information:
Database Name: Enter the name of the database to which you will connect. This usually maps to the SID
.
Host Name: Enter the hostname of the database.
Port: Enter the database port.
Database User Name: This is the name of the audit schema that you created in RCU. The following conventions apply to this entry:
Use all upper-case letters.
Prepend the schema prefix used when creating the audit schema in the database.
Append the schema name. For this data source, the schema name is IAU_APPEND.
For example, if you used "ENG" as your schema prefix, the value you enter here must be "ENG_IAU_APPEND".
Password: This is the password for the audit schema that you created in RCU.
Click Next.
The next page lists the JDBC driver class and database details. Accept the defaults, and click Test Configuration to test the connection. If you see the message "Connection established Successfully", click Next. If it displays any error, go back and check the connection details.
In the Select Targets page, select the servers where this data source needs to be configured, and click Finish.
For scalability and high availability, you can configure Oracle Real Application Clusters for your audit data.
For details, see "Real Application Clusters" in Oracle Fusion Middleware High Availability Guide.
After the schema is created, configuring a database-based audit data store involves:
creating a data source that points to the audit schema you created, and
configuring the audit data store to point to the data source
This section describes the following tasks related to audit data store configuration:
Note:
These steps configure the audit data store for Java components only. Separate steps are needed to configure the audit data store for system components. See Section 14.2.4, "Configure a Database Audit Data Store for System Components".
By configuring the same database to store audit records for Java components and system components, you can ensure that reports for both types of components can be viewed together.
Note:
This task is performed with Oracle Enterprise Manager Fusion Middleware Control.To view the current audit data store configuration:
Navigate to Domain, then Security, then Security Provider Configuration.
Under the Audit Service section, click Configure.
This page shows:
Datasource JNDI Name - If a database store is configured for audit records, this field shows the JNDI name of the datasource. The field is empty when the audit data store is not configured. By default a database is not configured, and audit records are stored in bus-stop files.
Audit Loader Frequency - This field shows the frequency, in seconds, at which data is moved from bus-stop files to the audit data store.
See Section 14.2.2, "Set Up Audit Data Sources" for datasource examples.
In 12c domains, the audit store can be provisioned through the product template when an Oracle Fusion Middleware domain is created or extended. This process is explained in Chapter 7.
You can also perform certain tasks related to audit store configuration manually:
Change from storing audit records in a file to using a database audit data store.
Configure bus-stop storage properties for a component's audit records.
Take these steps to configure these features (the user needs to be IAU_APPEND):
Navigate to Domain, then Security, then Security Provider Configuration .
Click the Audit Service Configuration button. The Audit Service Configuration page appears.
To configure the audit data store:
Click the searchlight icon next to the Datasource JNDI Name field.
A dialog box appears showing the list of datasources available for audit records in the domain. Select the desired datasource and click OK.
The selected datasource is displayed in the Datasource JNDI Name field. Click Apply to continue, or Revert to abandon the update.
Note:
You can also use the WLSTsetAuditRepository()
command to change the audit data store settings. See Oracle Fusion Middleware Infrastructure Security WLST Command Reference for details.Enter the audit loader frequency in seconds. The audit loader checks for and pushes records to the repository at the specified intervals.
Click Apply.
To configure bus-stop file parameters for components:
Select the component from the Audit Component Name drop-down.
Enter the maximum file size.
The maximum directory size is not used; setting this parameter has no effect on configuration.
Click Apply.
Restart all the Oracle WebLogic Servers in the domain. This enables Audit Loader Startup Class present in Oracle WebLogic Server to re-read the configuration.
You can test the changes by setting an audit policy to test event collection. For example, you can set the Medium audit policy for Oracle Platform Security Services. For details, see Section 14.3.1, "Manage Audit Policies for Java Components with Fusion Middleware Control".
Execute a scenario so that auditing can generate an audit event. For example, creating a credential will trigger an audit record based on the policy you configured in Step 6.
Check for errors and exceptions in the server logs:
Check $DOMAIN_HOME/jrfServer_admin.out
Check $DOMAIN_HOME/servers/$SERVER_NAME/logs/.
Since a database is the recommended store for audit records, switching from database to file mode is discouraged. However, Section 14.3.4, "Manage Audit Policies Manually" discusses a property called the audit.repositoryType
whose value can be set to 'File
' to switch to file storage.
Note:
You cannot use Fusion Middleware Control or WLST to switch from database to file mode; this requires manual configuration as explained in Section 14.3.4, "Manage Audit Policies Manually".When you switch from database to file, events that were collected in the database are not transferred back to the file system. If this switch is temporary, then the audit events collected in the file are automatically pushed to database when you switch to database store again.
The StandAloneAuditLoader java command is the mechanism through which audit events are pushed from local bus-stop files to the database audit data store. This section explains how to configure your environment so audit records are sent to the audit data store.
Note:
If your system component runs in a clustered deployment, you must configure the audit data store at each instance of the component so that all instances push out records to the store.You must execute the following steps in every instance of the component to configure an audit data store:
Note:
These steps configure the audit data store for system components only. Separate steps are needed to configure the audit data store for Java components. See Section 14.2.3, "Configure a Database Audit Data Store for Java Components".
You can ensure that reports for both types of components can be viewed together by configuring the same database to store audit records for Java components and system components.
Open the opmn.xml
file, which resides in
(UNIX) $ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml (Windows) %ORACLE_INSTANCE%/config/OPMN/opmn/opmn.xml
Locate the rmd-definitions
element, which looks like this :
(UNIX) <rmd-definitions> <rmd name="AuditLoader" interval="15"> <conditional> <![CDATA[({time}>=00:00)]]> </conditional> <action value="exec $ORACLE_HOME/jdk/bin/java -classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar: $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar: $ORACLE_HOME/oracle_common/modules/oracle.jdbc_11.2.0/ojdbc6dms.jar: $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar: $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar: -Doracle.home=$ORACLE_HOME -Doracle.instance=$ORACLE_INSTANCE -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=username oracle.security.audit.ajl.loader.StandaloneAuditLoader"/> <exception value="exec /bin/echo PERIODICAL CALL For Audit Loader FAILED"/> </rmd> </rmd-definitions> (Windows) <rmd-definitions> <rmd name="AuditLoader" interval="15"> <conditional> <![CDATA[({time}>=00:00)]]> </conditional> <action value="exec %ORACLE_HOME%\jdk\bin\java -classpath %COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_cert.jar; %COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_core.jar; %ORACLE_HOME\oracle_common\modules/oracle.jdbc_11.2.0\ojdbc6dms.jar; %COMMON_COMPONENTS_HOME%\modules\oracle.iau_11.1.1\fmw_audit.jar; %COMMON_COMPONENTS_HOME%\modules\oracle.pki_11.1.1\oraclepki.jar; -Doracle.home=%ORACLE_HOME% -Doracle.instance=%ORACLE_INSTANCE% -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=username oracle.security.audit.ajl.loader.StandaloneAuditLoader"/> <exception value="exec \bin\echo PERIODICAL CALL For Audit Loader FAILED"/> </rmd> </rmd-definitions>
Replace the existing RMD definition for audit loader. You need to modify only these values:
jdbcString - this is the database JDBC connection string; change this from the default string to a valid connection string.
username
interval - this is the interval in seconds at which audit records are pushed from the component's bus-stop file to the audit data store.
By default the interval value is set very high (31536000 seconds) so that the audit loader is effectively disabled. Change this to a reasonable interval such as 15 seconds.
Note:
Insert these lines after the<ias-instance>
tag is closed.Ensure that ORACLE_HOME
, ORACLE_INSTANCE
, and COMMON_COMPONENTS_HOME
are defined. For example:
(UNIX) ORACLE_HOME = /u01/oracle/as11_oh ORACLE_INSTANCE = /u01/oracle/instances/instance COMMON_COMPONENTS_HOME = $MW_HOME/oracle_common (Windows) ORACLE_HOME = \u01\oracle\as11_oh ORACLE_INSTANCE = \u01\oracle\instances\instance COMMON_COMPONENTS_HOME = %MW_HOME%\oracle_common
Populate the audit data store password in the secret store (the password that you have specified when creating the audit schema in RCU):
(UNIX) ORACLE_HOME/jdk/bin/java -classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar: $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar: $ORACLE_HOME/oracle_common/modules/oracle.jdbc_11.2.0/ojdbc6dms.jar: $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar: $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar: -Doracle.home=$ORACLE_HOME -Doracle.instance=$ORACLE_INSTANCE -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=username -Dstore.password=true -Dauditloader.password=password oracle.security.audit.ajl.loader.StandaloneAuditLoader (Windows) ORACLE_HOME\jdk\bin\java -classpath %COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_cert.jar; %COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_core.jar; %ORACLE_HOME%\ oracle_common\modules\oracle.jdbc11.2.0\ojdbc6dms.jar; %COMMON_COMPONENTS_HOME%\modules\oracle.iau_11.1.1\fmw_audit.jar; %COMMON_COMPONENTS_HOME%\modules\oracle.pki_11.1.1\oraclepki.jar; -Doracle.home=%ORACLE_HOME% -Doracle.instance=%ORACLE_INSTANCE% -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=username -Dstore.password=true -Dauditloader.password=password oracle.security.audit.ajl.loader.StandaloneAuditLoader
Enter the appropriate values for jdbcString, username, and password.
Save and exit the file.
Reload OPMN:
$ORACLE_INSTANCE/bin/opmnctl validate (Validation step to verify edits) $ORACLE_INSTANCE/bin/opmnctl reload
Execute a scenario in an audited component to generate an audit event. For example, log in to an Oracle HTTP Server instance; assuming that Oracle HTTP Server is configured to audit "User Logins" under the User Sessions category, then logging in will generate an audit event.
Check for errors/events uploaded at $ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/rmd.out
. The output will look like this
8/08/26 10:54:24 global:AuditLoader
A database is the recommended store for audit records. Switching from database to file mode is discouraged. However, if needed, you can use the same steps that were shown in the preceding task for configuring the audit data store through the opmn.xml
file to update the RMD definition to deconfigure the audit data store. Locate the rmd-definitions
element and replace the existing RMD definition for audit loader:
Note:
If your system component runs in a clustered deployment, you must deconfigure the audit data store at each instance of the component.jdbcString
- Change the database JDBC connection string back to the default string jdbc:oracle:thin:@host:port:sid
.
interval
- Set this interval back to the default value of 31536000.
Save and exit the file, and reload OPMN.
This section contains topics related to maintaining file-based storage of audit records, including:
bus-stop file locations
file size
Note:
Manually purging audit files to free up space is not recommended. Instead, use file and directory sizing features to control space, as described below.Bus-stop files for Java components are located in:
$DOMAIN_HOME/servers/$SERVER_NAME/logs/auditlogs/Component_Type
Bus-stop files for system components are located in:
$ORACLE_INSTANCE/auditlogs/Component_Type/Component_Name
Java Components
The size of a file for the file storage mode can be managed using the max.fileSize
property described in the configuration file jps-config.xml
. This property controls the maximum size of a bus-stop file for Java components.
Specify the sizes in bytes as described in Section 14.3.4, "Manage Audit Policies Manually".
System Components
The size of a file for the file storage mode can be set in the auditconfig.xml
file. SeeSection 14.3.4.4, "Audit Configuration File for System Components".
Note:
If you switch from file to database store for audit data, all the events collected in the audit files are pushed into the database tables and the audit files are deleted.As shown in Figure 13-1, Common Audit Framework's audit loader moves records from bus-stop files to the audit data store. The mechanism driving the audit loader depends on the application environment:
Java EE components and applications deployed on Oracle WebLogic Server use the audit loader functionality provided through the application server.
System components and non-Java applications use the audit loader functionality provided through the StandAloneAuditLoader java command.
Java SE applications, which run outside an application server container, also use the stand-alone audit loader.
This section explains how to set up and execute the stand-alone audit loader:
Before you can run the stand-alone audit loader, you must a) configure certain properties, and b) ensure that the password for the database schema user exists in the secret store.
You must configure the following properties:
ORACLE_HOME
environment variable
COMMON_COMPONENTS_HOME
environment variable
ORACLE_INSTANCE
environment variable
auditloader.jdbcString
system property
auditloader.username
system property
The password for the database schema user is kept in the secret store. Storing the password is a one-time operation for which you use the java StandAloneAuditLoader
command with the -Dstore.password=true
property.
Issue the StandAloneAuditLoader
command to store the password as follows:
$COMMON_COMPONENTS_HOME/jdk/jre/bin/java -classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar: $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar: $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar: $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar: $COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.2.0/ojdbc6dms.jar: $COMMON_COMPONENTS_HOME/modules/oracle.dms_11.1.1/dms.jar -Doracle.home=$ORACLE_HOME -Doracle.instance=$ORACLE_INSTANCE -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=db-user-name -Dstore.password=true oracle.security.audit.ajl.loader.StandaloneAuditLoader
There are two variations of the StandAloneAuditLoader command to store the password, depending on whether the password is included on the command line.
If you do not include the password property (-Dauditloader.password
) when issuing the command, you are prompted for the password.
You can include the password property when issuing the command.
Note:
There should not be any spaces in the classpath specification.This command generates a cwallet.sso file.
Issue the StandAloneAuditLoader
command to load audit records as follows:
$COMMON_COMPONENTS_HOME/jdk/jre/bin/java -classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar: $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar: $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar: $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar: $COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.2.0/ojdbc6dms.jar: $COMMON_COMPONENTS_HOME/modules/oracle.dms_11.1.1/dms.jar: -Doracle.home=$ORACLE_HOME -Doracle.instance=$ORACLE_INSTANCE -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=db-user-name oracle.security.audit.ajl.loader.StandaloneAuditLoader
You can schedule this command through a batch or kron job so that audit records are periodically uploaded to the audit data store.
An audit policy is a declaration of the type of events to be captured by the audit framework for a particular component. For Java components, the audit policy is defined at the domain level. For system components, the audit policy is managed at the component instance level.
For example, an audit policy could specify that all authentication failures should be audited for an Oracle Internet Directory instance.
Oracle Fusion Middleware Audit Framework lets you configure audit policies and provides highly granular controls over the types of events and data being audited. You can configure policies through the Oracle Enterprise Manager Fusion Middleware Control UI tool or with WLST commands.
Policy changes do not require server or instance restart.
The remainder of this section explains how to view, and update audit policy:
Manage Audit Policies for Java Components with Fusion Middleware Control
Manage Audit Policies for System Components with Fusion Middleware Control
See Also:
Section 13.3.2, "Key Technical Concepts" for additional background.
Appendix C for a list of Java components and system components.
The domain Audit Policy Settings page manages audit events for all Java components such as Oracle Access Manager, and system libraries like Oracle Platform Security Services.
Notes:
Audit policy for system components is managed in the component home pages. See Section 14.3.2, "Manage Audit Policies for System Components with Fusion Middleware Control"
See the note at the beginning of Section 14.3, "Managing Audit Policies" titled "Policy Changes Require Server or Instance Restart".
See Also :
Section C.1.1, "What Components Can be Audited?" for the list of auditable components.Use these steps to view and update the currently configured audit policies:
Log in to Fusion Middleware Control.
Using the topology panel to the left, navigate to the domain of interest under "WebLogic Domain".
From the domain menu, navigate to Domain
, then Security, then Audit Policy. The Audit Policy page appears.
Use the Audit Component Name drop-down to select the Java component whose audit policy you wish to configure.
When you select a component, a table of audit categories relevant to the component appears in the area of the page titled Audit Policy Settings. The following example is for Oracle Access Manager:
Use the Audit Level drop-down to select a subset of the audit events for the component. The choices are:
None - No event categories selected.
Low, Medium, High - Subsets of event categories representing pre-defined levels of auditing.
Custom - Enables you to create or modify a custom filter definition.
Depending on the level you select, check flags appear in the column Select for Audit. Events in the checked categories will be audited. For example, at the Medium level for Oracle Access Manager:
The flagged categories are selected for audit. You can view the events within a flagged category by clicking on that row in the categories table. For example, clicking on the "OAM Server" category produces the following event table below it:
Note:
The table of events can only be edited in custom level. It cannot be edited at the pre-defined levels.While the pre-defined levels are sufficient in many cases, you may wish to fine-tune the audit policy for the component.
To customize the audit policy, use the "Custom" option from the drop-down. This preserves the pre-defined categories but the green check-marks now appear as check-boxes, and all categories are available for selection:
You can select desired categories and events to fine-tune the audit policy. For example, you might wish to audit only failed authentication attempts in the Server category:
Filters are rule-based expressions that you can define to qualify or filter events for audit. The expressions are based on attributes of the event. For example, you may wish to further fine-tune the policy to narrow down the types of failed authentication attempts to audit.
A pencil icon in the Edit Filter column denotes that a filter is available for the event. Click on the icon to bring up the Edit Filter dialog:
Specify the filter using the condition boxes, which consist of the filter condition, an operator, and a value. After specifying each condition, click the add button. When finished adding conditions, click OK to save the changes.
In this example, a failed authentication attempt triggers an audit event only if the server hosting the protected application is named myhost1:
Note:
Each filter attribute has a formal name and a display name. You may see either name in the filter edit dialog. Display names are shown in the drop-down, while names are shown in the edit dialog. For example, if you select 'Client Address IP' in the drop-down box, it is renamed to 'RemoteIP' after you add it to the filter expression.Import/Export - These buttons enable you to save and re-use a policy configuration. At any time while editing the policy, click Export to save the current settings to a file, and Import to load the settings from a saved file.
Optionally, under ”Users to Always Audit”, you can specify a comma-separated list of users to force the audit framework to audit events initiated by these users; auditing occurs regardless of the audit level or filters that have been specified.
Notes:
Be aware that if you use this feature to audit key users such as system administrators, this will generate audit traffic anytime that user touches any of the auditable events for any component. For example, a component's audit policy may be set to None, but if the user performs some activity in the component instance, it is still audited.
User names you enter in this field are not validated.
If you made any policy changes, click Apply to save the changes. For Java components, you must restart the managed Oracle WebLogic Server (on which the affected Java component is running) for the changes to be effective. Changes are effective after a pre-defined refresh interval, which is 10 minutes by default.
Click Revert to discard any policy changes and revert to the existing policy.
Each component and application in the domain defines its own set of auditable events. Thus, when you expand the Names column of the table, each component displays a list of events that applies to instances of that component.
This section describes how to view and update audit policies for system components.
Notes:
Audit policy for Java components is managed in the domain context. See Section 14.3.1, "Manage Audit Policies for Java Components with Fusion Middleware Control".
See the note at the beginning of Section 14.3, "Managing Audit Policies" titled "Policy Changes Require Server or Instance Restart". Oracle Internet Directory instances do not require a restart.
Audit policy for system components is managed in their home pages. The domain Audit Policy Settings page manages audit events for Java components running in the domain.
See Also :
Section C.1.1, "What Components Can be Audited?" for the list of auditable components.The events are organized in a tree structure under the Name column. The tree can be expanded to reveal the details of the events available.
Use these steps to view and update audit policies for system components:
Log in to Fusion Middleware Control.
Using the topology panel to the left, navigate to the system component of interest such as Oracle HTTP Server.
From the component menu, navigate to Security, then Audit Policy. The Audit Policy Settings page appears.
You can select from a drop-down list of pre-configured audit levels. Three pre-defined levels (Low, Medium, High) will automatically pick up a subset of the audit events for the component.
Note:
The selection of events under the drop-down box cannot be edited for the pre-defined levels. It can only be edited in custom level.None - No events are selected for audit.
Low - A small set of events is selected, typically those having the smallest impact on component performance.
Medium or High- This is a larger set of events. These events may have a higher impact on component performance.
Custom - This level enables you to fine-tune the policy, and is described in Step 5 below.
The table shows the events you can audit for the component instance. This example is for Oracle HTTP Server:
The table consists of these columns:
Name - shows the component events grouped by type, such as Authorization events.
Enable Audit - shows whether the corresponding event type is being audited. This column is greyed out unless the Custom audit policy is in force.
Filter - shows any filters in effect for the event type.
To customize the audit policy, use the "Custom" option from the drop-down. This allows you to select event categories; to get started, check the "Select For Audit" box for the category you wish to customize.
A second table lists the events in each category, enabling you to additionally filter for success and failure outcomes of each individual event to further control how they are audited. You can fine-tune filters as explained in Step 6.
Filters are rule-based expressions that you can define to qualify or filter events for audit. The expressions are based on attributes of the event. For example, a Login type event could specify an initiator as a user filter in which case the event would generate an audit record whenever the specified user logged in.
A pencil icon indicates that a filter is available for the corresponding event.
Click on a pencil icon to bring up the Edit Filter dialog.
Note:
Each filter attribute has a formal name and a display name. You may see either name in the filter edit dialog. Display names are shown in the drop-down, while names are shown in the edit dialog. For example, if you select 'Client Address IP' in the drop-down box, it is renamed to 'RemoteIP' after you add it to the filter expression.Click "Select Failures Only" to select only failed events in the policy - for example, a failed authentication. The Enable Audit box is now checked for failed events.
Import/Export - These buttons enable you to save and re-use a policy configuration. At any time while editing the policy, click Export to save the current settings to a file, and Import to load the settings from a saved file.
Optionally, under ”Users to Always Audit”, a comma-separated list of users can be specified to force the audit framework to audit events initiated by these users; auditing occurs regardless of the audit level or filters that have been specified.
Notes:
Be aware that if you use this feature to audit key users such as system administrators, this will generate audit traffic anytime that user touches any of the auditable events for any component. For example, a component's audit policy may be set to None, but if the user performs some activity in the component instance, it is still audited.
No validation is performed for user names you enter in this field.
If you made any policy changes, click Apply to save the changes.
Click Revert to discard any policy changes and revert to the existing policy.
This section explains how to view and update audit policies using the Oracle WebLogic Scripting Tool (WLST) command-line tool:
Note:
When running auditWLST
commands, you must invoke the WLST
script from the Oracle Common home. See "Using Custom WLST Commands" in Administering Oracle Fusion Middleware for more information.Take these steps to view audit policies with WLST:
Note:
This discussion assumes that you are invoking WLST interactively. For details about WLST and the different options for invoking the tool, see "Getting Started Using the Oracle WebLogic Scripting Tool (WLST)" in Administering Oracle Fusion Middleware.Connect to the WebLogic Server using the following commands:
>java weblogic.WLST >connect('userName', 'userPassword', 'url', 'adminServerName')
Use the getAuditPolicy
command to view the audit policy configuration. For example, the following command shows all audit policies:
wls:/mydomain/serverConfig> getAuditPolicy()
The following command shows audit policy for a specific component:
wls:/mydomain/serverConfig> getAuditPolicy(componentType="JPS")
For system components:
obtain the MBean name using the getNonJava EEAuditMBeanName
command. See Appendix C, "Oracle Fusion Middleware Audit Framework Reference." for details.
Use the getAuditPolicy
command and include the MBean name to view the audit policy configuration. For example:
wls:/mydomain/serverConfig> getAuditPolicy (on="oracle.security.audit.test:type=CSAuditMBean,name=CSAuditProxyMBean")
Take these steps to update audit policies with the Oracle WebLogic Scripting Tool (WLST) command-line tool:
Note:
This discussion assumes that you are invoking WLST interactively. For details about WLST and the different options for invoking the tool, see "Getting Started Using the Oracle WebLogic Scripting Tool (WLST)" in the Administering Oracle Fusion Middleware.Connect to the WebLogic Server using the following commands:
>java weblogic.WLST >connect('userName', 'userPassword', 'url', 'adminServerName')
Navigate the bean hierarchy to access the domain of interest. For example, if the domain is called mydomain
:
wls:/mydomain/serverConfig>
Use the setAuditPolicy
command to update the audit policy configuration.
For components that manage their policy locally, use the setAuditPolicy
command and include an MBean name to update the audit policy configuration.
Explicitly call save
after issuing a setAuditPolicy
, or importAuditConfig
, command.
If you do not invoke save, the new settings will not take effect.
For an example of this call, see Managing Auditing by Using WLST in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory, which demonstrates this call for Oracle Internet Directory auditing.
In this scenario, the domain's current policy audits a user named user1. The administrator would like to add two names, user2 and user3, to the list of users who are always audited, and remove user1 from the list.
The following invocation of setAuditPolicy
performs this task:
setAuditPolicy (filterPreset="None",addSpecialUsers="user2,user3",removeSpecialUsers="user1")
In this scenario, the domain's current policy audits user logout events. The administrator would like to remove the logout events from the policy and, instead, audit login events.
The following invocation of setAuditPolicy
performs this task:
Note:
This example uses the component type OHS for Oracle HTTP Server. Substitute the relevant component type when using the command.setAuditPolicy (filterPreset="Custom",addCustomEvents="OHS:UserLogin", removeCustomEvents="OHS:UserLogout")
Notice that the Custom
filter preset was invoked to add and remove events.
When auditing is configured at the custom audit level, and you subsequently use WLST to switch to a different (non-custom) audit level, the custom audit settings are retained unless you explicitly remove those custom settings.
An example illustrates this behavior:
Custom audit level is set for a component's policy. An audit filter is specified as part of the configuration.
At run-time, audit data is collected according to the specified filter.
The component's audit policy is now changed from custom audit level to, say, the low audit level using the WLST setAuditPolicy
command. However, the filter that was set up as part of the custom audit level persists in the audit configuration.
Audit data is now collected based on the low audit level, not the custom level.
The component's audit policy is changed back to custom level. An additional filter is added. This filter is appended to the originally configured filter. Unless the original filter is explicitly deleted, it remains part of the configuration.
At run-time, audit data is collected based on all prevailing filters at the custom level.
This section explains how to configure auditing policies and other features by manually updating:
the platform configuration file jps-config.xml
for Java components
component-specific files for system components
This section contains these topics:
The jps-config.xml
domain configuration file can be found at this location:
$DOMAIN_HOME/config/fmwconfig/jps-config.xml
The Audit Service Configuration in jps-config.xml
consists of the properties shown in Table F-9. Taken together, the set of properties and their values are known as the audit policy.
Note:
The policy settings in the audit store take precedence over the policy settings in jps-config.xml.
In the dynamic metadata model, the audit policy for a specific component is stored in audit-store.xml
.
Here is a sample file illustrating an audit policy:
<?xml version="1.0" encoding="UTF-8" standalone='yes'?> <jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1"> <serviceProviders> <serviceProvider name="audit.provider" type="AUDIT" class="oracle.security.jps.internal.audit.AuditProvider"> </serviceProvider> </serviceProviders> <serviceInstances> <serviceInstance name="audit" provider="audit.provider" location="./audit-store.xml"> <description>Audit Service</description> <property name="audit.filterPreset" value="None"/> <property name="audit.maxDirSize" value="0"/> <property name="audit.maxFileSize" value="104600"/> <property name="audit.timezone" value="utc"/> <property name="audit.loader.jndi" value="jdbc/AuditAppendDataSource"/> <property name="audit.loader.interval" value="15"/> <property name="audit.loader.repositoryType" value="File"/> <property name="auditstore.type" value="file"/> </serviceInstance> </serviceInstances> <jpsContexts default="default"> <jpsContext name="default"> <serviceInstanceRef ref="audit"/> </jpsContext> </jpsContexts> </jpsConfig>
In rare instances, you may wish to revert from using a (database) data store to using a file for audit records. This requires manual configuration of the property audit.loader.repositoryType
described in Table F-9.
To switch from database to file, set the audit.loader.repositoryType
to File
.
When you switch from database to file, events that were collected in the database are not transferred back to the file system. If this switch is temporary, the audit events collected in the file are automatically pushed to the database when you switch to a database store again.
System components such as Oracle HTTP Server do not use the jps-config.xml
file to store the audit configuration. Instead, Oracle HTTP Server uses the auditconfig.xml
file which is located in:
ORACLE_INSTANCE/instance_name/config/OHS/<ohs_name>/auditconfig.xml
Format of the auditconfig.xml File
Here is the format of the auditconfig.xml file:
<?xml version="1.0" encoding="UTF-8"?> <ns0:AuditConfig xmlns:ns0="http://xmlns.oracle.com/ias/audit/audit.xsd"> <ns0:Filters> <ns0:CustomEvents> </ns0:CustomEvents> <ns0:FilterPreset>None</ns0:FilterPreset> <ns0:SpecialUsers> </ns0:SpecialUsers> </ns0:Filters> <ns0:LogsDirectory> <ns0:MaxDirSize></ns0:MaxDirSize> <ns0:MaxFileSize></ns0:MaxFileSize> <ns0:Location></ns0:Location> </ns0:LogsDirectory> </ns0:AuditConfig>
Prior to 11g Release 1 (11.1.1.7), the audit service wrote out database records using the application server's time zone. In 11g Release 1 (11.1.1.7), the audit service can account for different time zones for the application server and the audit data store.
This means:
New 11g Release 1 (11.1.1.7) sites will see audit events written in Coordinated Universal Time (UTC).
Sites that upgrade from 11g Release 1 (11.1.1.6) to 11g Release 1 (11.1.1.7) will, by default, continue to use the application server time zone for audit records unless you explicitly switch to UTC.
Note:
Records to bus-stop files always use UTC.New 11g Release 1 (11.1.1.7) Sites
At new installations starting with 11g Release 1 (11.1.1.7), audit records use UTC timestamps. A new service property (audit.timezone=utc
) in the default audit service configuration implements this convention.
Out-of-the-box, audit service configuration looks like this:
<serviceInstance name="audit" provider="audit.provider" location="./audit-store.xml">
<property name="audit.filterPreset" value="None"/>
<property name="audit.timezone" value="utc" />
<property name="audit.loader.repositoryType" value="File" />
<property name="auditstore.type" value="file"/>
</serviceInstance>
Sites Upgrading to 11g Release 1 (11.1.1.7)
Audit records that existed prior to the upgrade used the application server timestamp. After the upgrade, the audit service configuration remains unchanged and, by default, the records continue to be written using the application server timestamp.
If you wish to use the UTC timestamp after upgrade, you can add the new service property audit.timezone=utc
in the configuration file to get the UTC behavior.
If you switch to UTC after the upgrade, Oracle recommends that you move the existing records first to avoid any potential inconsistency which can affect reporting.
See Also:
Section F.2.7This section contains the following topics:
Fusion Middleware Audit Framework provides a set of log files to help with audit administration. You can use these logs to trace errors and for diagnostic purposes when the audit framework is not functioning properly.
For a listing of all audit log locations, how to configure the loggers, and how to use the logs to diagnose issues, see Section J.1.1.7, "Audit Loggers".
Time stamps in the audit bus-stop files are recorded in Coordinated Universal Time. This may differ from the machine time depending on the machine's time zone setting.
The audit schema is created through the Repository Creation Utility (RCU). This section explains the organization of the audit schema and contains the following topics related to maintaining the schema:
See Also:
For more information on RCU, see Oracle Fusion Middleware Repository Creation Utility User's Guide.The common tables in the Oracle Fusion Middleware Audit Framework schema consist of the following:
common attributes in the IAU_COMMON
table
generic attributes in dedicated tables
custom attribute tables in the IAU_CUSTOM_nnn
tables.
For details about these tables, see Section 13.4.
The audit schema also contains the following:
A base table
A translation table
A set of component-specific tables of audit data
For details about these tables, see Section 14.6.2.
By default, the bus-stop file is maintained in the directory
WebLogic Domain Home
/servers
/server_name
/diagnostics/auditlogs/JPS/audit.log
Here is a sample bus-stop file for Oracle Platform Security Services.
#Fields:Date Time Initiator EventType EventStatus MessageText HomeInstance ECID RID ContextFields SessionId TargetComponentType ApplicationName EventCategory ThreadId InitiatorDN TargetDN FailureCode RemoteIP Target Resource Roles CodeSource InitiatorGUID Principals PermissionAction PermissionClass mapName key #Remark Values:ComponentType="JPS" 2008-12-08 10:46:05.492 - "CheckAuthorization" true "Oracle Platform Security Authorization Check Permission SUCCEEDED." - - - - - - - "Authorization" "48" - - "true" - - "(oracle.security.jps.service.policystore.PolicyStoreAccessPermission context=APPLICATION,name=SimpleServlet getApplicationPolicy)" - "file:/oracle/work/middleware/oracle_common/modules/oracle.jps_11.1.1/jps-internal.jar" - "[]" - - - -
Common Table and Custom Tables
Figure 14-1 shows the data in the common table and how it relates to the custom tables.
Base Table and Component Tables
Figure 14-2 shows the data in the base table and how it relates to the component-specific tables.
When generated, audit records are stored in a file; if an audit database store is configured, the audit loader stores each audit record in one row of the base table and one row of a component table:
General information (such as Time, EventType, and EventStatus) is written into the base table.
Component-specific information (such as CodeSource
) is written into the component table.
The average record size in the base table IAU_BASE
is approximately 0.3 KB. When you plan for tablespace sizing:
use this number as a guideline for the average record size
monitor how audit database size is growing based on the audit policy selected and the level of activity
take into account the period of time for which the audit data is being stored.
The attributes of the base table and the component-specific tables respectively are derived from these files:
$ORACLE_HOME/modules/oracle.iau_12.1.2/components/generic/generic_events.xml
for the base table, and
$ORACLE_HOME/modules/oracle.iau_12.1.2/components/componentName/component_events.xml
for each component table.
Table 14-1 lists a few important attributes defined in the base table IAU_BASE
. The first four attributes are common in that table and all component tables. The primary key is defined as IAU_ID + IAU_TSTZORIGINATING
.
See Also:
Section C.4, "The Audit Schema"Table 14-1 Attributes of Base Table IAU_BASE
Attribute | Description |
---|---|
IAU_ID |
A unique sequential number for every audit record |
IAU_TstzOriginating |
Date and time when the audit event was generated (data type |
IAU_EventType |
The type (name) of the audit event |
IAU_EventCategory |
The category of the audit event |
IAU_EventStatus |
The outcome of the audit event - success or failure |
IAU_MessageText |
Description of the audit event |
IAU_Initiator |
UID of the user who was doing the operation |
Note:
ASEQUENCE
, an Oracle database object, is created to coordinate the assignment of sequential numbers (IAU_ID
) for audit records.You can use the listAuditEvents
WLST command to get a list of all attribute names for individual component tables.
For efficient queries, an index is created by default on the Timestamp (IAU_TSTZORIGINATING) in the base table and on each of the component-specific tables.
The default index in IAU_BASE
is named EVENT_TIME_INDEX
, and in the component tables it is named tableName
_INDEX
(such as OVDCOMPONENT_INDEX
, OIDCOMPONENT_INDEX
, JPS_INDEX
and so on).
Compliance regulations require that audit data be stored for long periods. A backup and recovery plan is needed to protect the data.
A good backup plan takes account of these basic guidelines:
Growth rate of Audit Events
The number of audit events generated depends on your audit policy. The number of audit events generated daily determines, in turn, how often you want to perform backups to minimize the loss of your audit data.
Compliance regulations
Consult you organization's compliance regulations to determine the frequency of backups and number of years for which audit data storage is mandatory.
Online or Offline Data Management
Consult you organization's compliance regulations to determine the frequency of backups and the portion of audit data that needs to be easily accessible.
Oracle Database uses Oracle Recovery Manager (RMAN) for backup and recovery. For details, see:
http://www.oracle.com/technology/deploy/availability/htdocs/BR_Overview.htm
http://www.oracle.com/technology/deploy/availability/htdocs/rman_overview.htm
Note:
The translation table,IAU_DISP_NAMES_TL
, needs to be backed up only once, since it should not change over time.You can import and export the audit schema to migrate data if you started with multiple audit databases and wish to combine them into a single audit data store, or if you wish to change the database to scale up.
Oracle Database sites can utilize the utilities of Oracle Data Pump to import and export data. For details, refer to:
http://www.oracle.com/technology/products/database/utilities/htdocs/data_pump_overview.html
Not all database systems support partitioning, all the tables in the audit schema are unpartitioned by default.
Since audit data is cumulative and older data is never removed, if you store a high volume of audit data you should consider partitioning the audit schema, as it will allow for easier archiving.
Benefits of partitioning include:
Improved Performance: If a table is range-partitioned by Timestamps, for example, queries by Timestamps can be processed on the partitions within that time-frame only.
Better Manageability: Partitions can be created on separate tablespaces (thus different disks). This enables you to move older data to slower and larger disks, while keeping newer data in faster and smaller disks.
In addition, partitioning makes archival much easier. For example, you can compress a singlve partition rather than having to partition the entire table.
Increased Availability: If a single partition is unavailable, for example, and you know that your query can eliminate this partition from consideration, the query can be successfully processed without needing to wait for the unavailable partition.
Note:
This discussion applies to releases prior to 11g Release 1 (11.1.1.7). New 11g Release 1 (11.1.1.7) installations do not use these tables.In this example, IAU_BASE
is used as an example to demonstrate how to convert the unpartitioned tables in the audit schema into partitioned tables.
It is recommended that partitioning is done before using this schema for an audit data store to minimize the application down time.
Note:
Two sample SQL scripts are shipped with the product:$MW_HOME/oracle_common
(linux) or
/common/sql/iau/scripts/convertPartitionedTables.sql%MW_HOME\oracle_common
(Windows) converts the base and component tables in the audit schema into partitioned tables.
\common\sql\iau/scripts\convertPartitionedTables.sql
$MW_HOME/oracle_common
(linux) or
/common/sql/iau/scripts/createPartitionsByQuarter.sql%MW_HOME\oracle_common
(Windows) creates partitions by quarter for the base and component tables in the audit schema.
\common\sql\iau/scripts\createPartitionsByQuarter.sql
The partitioning steps are as follows:
Note:
It is recommended that you deactivate the audit loader prior to partitioning. See Section 14.2.4.1, "Deconfigure the Audit Data Store" for details.Rename the existing unpartitioned table. For example:
RENAME IAU_BASE TO IAU_BASE_NONPART;
Create a new partitioned table that follows the table structure of the unpartitioned table. This example uses the range-partitioning (by Timestamp) scheme:
CREATE TABLE IAU_BASE PARTITION BY RANGE (IAU_TSTZORIGINATING) ( PARTITION IAU_BASE_DEFAULT VALUES LESS THAN (MAXVALUE) ) AS SELECT * FROM IAU_BASE_NONPART;
Enable row movement to allow data to automatically move from partition to partition when new partitions are created. For example:
ALTER TABLE IAU_BASE ENABLE ROW MOVEMENT;
Create a local prefix index for the partitioned table. For example:
ALTER INDEX EVENT_TIME_INDEX RENAME TO EVENT_TIME_INDEX_NONPART; CREATE INDEX EVENT_TIME_INDEX ON IAU_BASE(IAU_TSTZORIGINATING) LOCAL;
Partitions can now be created. In this example partitions are created by calendar quarter:
ALTER TABLE IAU_BASE SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/04/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q1_2008, PARTITION IAU_BASE_DEFAULT) UPDATE INDEXES; ALTER TABLE IAU_BASE SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/07/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q2_2008, PARTITION IAU_BASE_DEFAULT) UPDATE INDEXES; ALTER TABLE IAU_BASE SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/10/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q3_2008, PARTITION IAU_BASE_DEFAULT) UPDATE INDEXES; ALTER TABLE IAU_BASE SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/01/2009', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q4_2008, PARTITION IAU_BASE_DEFAULT) UPDATE INDEXES;
Note:
New partitions should be created periodically for new quarters.Backup and recovery were discussed in Section 14.6.4, "Backup and Recovery". Note that read-only tablespaces can be excluded from whole database backup, so long as a backup copy was created. Thus, you can improve performance by avoiding unnecessary backups for the partitions of archived data residing on those tablespaces.
Import and export were discussed in Section 14.6.5, "Importing and Exporting Data". Keep in mind that with a range-partitioned table it is much more efficient to drop a partition when you want to remove old data, rather than deleting the rows individually.
ALTER TABLE IAU_BASE DROP PARTITION IAU_BASE_Q4_2008;
It is also easy to load a partition of new data without having to modify the entire table. However, you have to remove the default partition of "values less than (MAXVALUE
)" first, and add it back once finished, using a command like the following:
ALTER TABLE IAU_BASE ADD PARTITION IAU_BASE_Q4_2008 VALUES LESS THAN ('01-JAN-2009');
Once partitions are created, you can purge or back up a particular partition. Refer to Section 14.6.6.4 for details.
In the database mode, the audit loader automatically manages bus-stop files.
Oracle Fusion Middleware Audit Framework provides SQL scripts to enable you to purge records from the audit store.
The purge scripts are located at:
[Linux] $MW_HOME/oracle_common/common/sql/iau/scripts [Windows] %MW_HOME\oracle_common\common\sql\iau\scripts
The following scripts reside at this location:
auditDataPurge.sql
auditDeleteData.sql
auditReclaimSpace.sql
To delete records without taking any other action, use auditDeleteData.sql. The script takes two parameters:
Audit Schema user
Number of Days to keep - older records are deleted.
auditDeleteData.sql audit_schema_user number_of_days_to_keep
For example:
sqlplus> @auditDeleteData.sql DEV_IAU 100
deletes all records older than 100 days.
Reclaiming Space in Data Store
To reclaim space, use the auditReclaimSpace.sql
script. The script takes only one parameter, the audit schema user.
@auditReclaimSpace.sql audit_schema_user
For example:
sqlplus> @auditDataPurge.sql DEV_IAU
Deleting Records and Reclaiming Space
To both delete audit records and reclaim space, use the auditDataPurge.sql
script. This script takes two parameters:
Audit Schema user
Number of Days to keep; older records are deleted.
@auditDataPurge.sql audit_schema_user number_of_days_to_keep
For example:
sqlplus> @auditDataPurge.sql DEV_IAU 100
deletes all records older than 100 days, and enables row movements to shrink space.
Partitioning enables individual partitions (or groups of partitions) to be stored on different storage tiers. You can create tablespaces in high-performance or low-cost disks, and create partitions in different tablespaces based on the value of the data or other criteria. It is also easy to move data in partitions between the tablespaces (storage tiers).
Here is an example:
ALTER TABLE IAU_BASE MOVE PARTITION IAU_BASE_Q1_2008 TABLESPACE AUDITARCHIVE UPDATE INDEXES;
Note :
Partitions can be moved only in Range, List, System, and Hash partitioning schemes.Oracle Information Lifecycle Management (ILM) features streamlined data management through partitioning and compression. For details, refer to:
http://www.oracle.com/technetwork/database/enterprise-edition/index-090321.html