Oracle® Audit Vault Administrator's Guide Release 10.2.3.2 Part Number E14459-11 |
|
|
PDF · Mobi · ePub |
Monitoring the Audit Vault Server SYSAUX Tablespace Space Usage
Managing the Audit Vault Console in an Oracle RAC Configuration
This chapter describes important administrative tasks to perform on the Oracle Audit Vault system. These tasks are especially important if your audit data collectors are collecting high volumes of audit records and rapidly filling the default tablespace and disk space.
The Oracle Audit Vault Server database contains the SYSAUX
tablespace, which by default has one data file. The SYSAUX
tablespace is a locally managed tablespace with automatic segment space management.
You should monitor the space usage for the SYSAUX
tablespace and create additional data files for storage as needed. Remember that if you use the procedures in Section 4.10 to clean up the audit trail, the SYSAUX
tablespace by default will store the audit trail.
See Oracle Database Administrator's Guide for more information about the ALTER TABLESPACE
SQL statement, which you can use to add more storage data files. For information about optimizing a tablespace, see Oracle Database Performance Tuning Guide.
By default, ARCHIVELOG
mode is enabled in the Audit Vault Server database. The ARCHIVELOG
mode copies filled online redo logs to disk. This enables you to back up the database while it is open and being accessed by users, and to recover the database to any desired point in time. You should monitor the disk space usage for the redo logs.
See Oracle Database Administrator's Guide for more information about changing the LOG_ARCHIVE_DEST_
n
location to relocate these archive log files to larger disks. For information about backing up the archive logs, see Oracle Database Backup and Recovery Advanced User's Guide.
By default, the Audit Vault Server database has the following initialization parameter settings:
The DB_RECOVERY_FILE_DEST_SIZE
initialization parameter is set to 2 GB.
The DB_RECOVERY_FILE_DEST
initialization parameter is set to the default flash recovery area, typically the ORACLE_HOME/flash_recovery_area
directory.
Ensure that the size of the flash recovery area is large enough to hold a copy of all data files, all incremental backups, online redo logs, archived redo logs not yet backed up on tape, control files, and control file auto backups. This space can fill up quickly, depending on the number of collectors configured, the scope of the audit record collection being administered, and the backup and archive plans that you have in place.
You can use Oracle Enterprise Manager Database Control to monitor the available space in the flash recovery area. Monitor the percent space that is usable in the Usable Flash Recovery Area field under the High Availability section on the Home page. Check the alert log in the Database Console for messages. When the used space in the flash recovery area reaches 85 percent, a warning message is sent to the alert log. When the used space in the flash recovery area reaches 97 percent, a critical warning message is sent to the alert log.
You can manage space in the flash recovery area by adjusting the retention policy for data files to keep fewer copies or reduce the number of days these files stay in the recovery window. Alternatively, increase the value of the DB_RECOVERY_FILE_DEST_SIZE
initialization parameter to accommodate these files and to set the DB_RECOVERY_FILE_DEST
initialization parameter to a value where more disk space is available. See Oracle Database Administrator's Guide and Oracle Database Backup and Recovery Basics for more information.
When you back up Oracle Audit Vault, you must back up the database, the Audit Vault Server home, and the Audit Vault collection agent home.
This section contains:
See Also:
Oracle Database Backup and Recovery Basics for more information about backing up a database.After cleanly shutting down the instance following the analysis of the database, you should perform a full backup of the database. Complete the following steps:
Log in to Oracle Recovery Manager (RMAN):
rman "target / nocatalog"
Issue the following RMAN
commands:
BACKUP DATABASE FORMAT 'some_backup_directory%U' TAG before_upgrade; BACKUP CURRENT CONTROLFILE TO 'save_controlfile_location';
Back up or copy the Audit Vault Server home and the Audit Vault collection agent home to separate directories.
When you can deploy the Oracle Audit Vault Server in an Oracle RAC configuration, the repository database can take advantage of the scalability and high availability features provided by Oracle RAC. However, the Audit Vault Console is not Oracle RAC-aware, and can only run on one node in the Oracle RAC environment. Usually, this is the node on which the first instance of Oracle Audit Vault was installed. In the event that this node becomes unavailable, the Console does not automatically fail over to another node as the repository database does. As a result, the Audit Vault Console application is no longer available to users. To remedy this problem, you must manually bring up the Audit Vault Console on another node in the Oracle RAC cluster.
To bring up the Audit Vault Console on another node in the Oracle RAC cluster:
Ensure that the Audit Vault Console is not running on the main node.
Because the node is inaccessible, this should be the case anyway. To check, run the avctl show_av_status
command, described in Section 7.5.
Open a shell or command prompt for the Audit Vault Server.
UNIX: Set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME
\bin
directory.
Run the avca deploy_av
command to deploy the Audit Vault Console in the Oracle home.
For example:
avca deploy_av -sid av -dbalias av -avconsoleport 5700
See Section 6.6 for more information about the avca deploy_av
command.
Restore the wallet.
For each source database that has been registered with Oracle Audit Vault, Audit Vault uses a user name and password pair to connect to it. These user names and passwords are stored in an Oracle wallet on the Audit Vault Server. You can find the wallet in the $ORACLE_HOME/network/admin/avwallet
directory. If you have the wallet from the original node backed up, restore it into this directory on the new node.
In an Oracle Real Application Clusters (Oracle RAC) environment, after you have configured the Audit Vault collection agent, the node on which the collection agent was installed has its listener set to listen only to that node. Thus, only that node can be specified to connect to. However, you can configure the listener to listen to the other nodes.
For the OSAUD and DBAUD collectors, you must update the tnsnames.ora
file during installation of the Audit Vault collection agents.
After you configure the collection agent, the tnsnames.ora
file located in $ORACLE_HOME/network/admin
has an alias similar to the following:
AV = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = node01) (PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = avsrv.example.com)))
For high availability, you may need to edit the Audit Vault collection agent home tnsnames.ora
file after you have configured the collection agent, and then add the host and port of the other listeners.
For example:
AV = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = node01)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = node02)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = node03)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = node04)(PORT = 1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = avsrv.example.com) ) )
For the REDO collector, you must log in using the source user account at the source database and then re-create the database link for avsrv.example.com
. The new database link can either have a list of host and port numbers or point to a tnsnames
entry with the list of host and port numbers.
Follow these guidelines for OSAUD and DBAUD collectors:
Configuring OSAUD collectors. You must create an OSAUD collector for each Oracle RAC node. If you have a shared file system, then ensure that files from one node be kept in a separate directory than those from another node.
Configuring DBAUD collectors. You only need one DBAUD collector to manage all the Oracle RAC nodes. If the Oracle RAC source database is configured for failover and if one or more Oracle RAC nodes fails, then the collectors should continue to work without problems so long as at least one Oracle RAC node is working. However, if the computer where the DBAUD collector resides fails, then you can use the avorcldb alter_collector
command (Section 8.4) to move the DBAUD collector to a different Oracle RAC node.
Be aware that this automatic failover configuration works only if you have added the source database with the host name or IP address of the virtual IP address, not of each individual database instance. Suppose you have host hosta.example.com
at 192.0.2.100
, and host hostb.example.com
at 192.0.2.101
, and they are part of a cluster. The virtual IP address of the cluster is configured to 192.0.2.200
, and the host name for that IP is cluster.example.com
. In that case, you must run the avorcldb add_source -src cluster.oracle.com:1521:..
command (See Section 8.3) to to add the source database. With this method, failover is automatic. If, instead, you use hosta.example.com
or hostb.example.com
, then failover configuration will not work.
Another way to handle this configuration is to add the source database with hosta.oracle.com
, but then you must change the TNSNAMES.ORA
file on the Audit Vault Server and the agent managing your DBAUD collector. In addition, you must add hostb.oracle.com
as another address for the same TNS alias as hosta.oracle.com
. This method enables the collector to failover when one of the hosts is disabled.
When you add an Oracle source database to Oracle Audit Vault, you must provide the host
:port
:service
information for the source database being added. This information is used for the following tasks from the collection agent:
REDO collector: Starting and stopping the capture process on the source
DBAUD collector: Retrieving rows from AUD$
and FGA_LOG$
tables
Typically, when the Oracle Database instance on the host goes down or if the host computer goes down, the connectivity to the source database from the Oracle Audit Vault collection agent is broken. Any attempt to perform these tasks is unsuccessful because this connection is not available:
You can do any or all of the following operations to make the connection between the source and the Audit Vault collection agent more highly available.
In the Audit Vault collection agent home, update the tnsnames.ora file to include additional host or port information for the service. This file is located in the $ORACLE_HOME/network/admin
directory. You can add options for load balancing and failure in the connect string. For additional information, see Oracle Database Net Services Administrator's Guide.
Configure a listener on the Oracle RAC nodes to support connecting to remote nodes and configuring the Oracle Database to communicate with remote listeners. If the Oracle Database instance goes down, then the listener on the host can create connections on a different Oracle RAC node. For additional information, see Oracle Database Net Services Administrator's Guide.
Provide host information using the virtual IP address of the node instead of the physical IP address. If the host computer goes down, then all traffic to the host is redirected to a different node.
This section contains:
Changing the port numbers for the Audit Vault Server affects the agents, collectors, the Audit Vault Console Web application, and the Audit Vault command line utilities.
First, update and test the listener.ora
and tnsnames.ora
files for the Audit Vault Server, as follows:
Open a shell or command prompt for the Audit Vault collection agent.
UNIX: Set the environment variables, as described in Section 2.2.3.
Microsoft Windows: Go to the collection agent ORACLE_HOME
\bin
directory.
Stop the collection agent.
For collection agents that were created in Release 10.2.3.2:
avctl stop_agent
For Release 10.2.3.1 or earlier collection agents that have not yet been upgraded:
avctl stop_oc4j
Leave this shell or command prompt open.
Open a shell or command prompt for the Audit Vault Server.
UNIX: Set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME
\bin
directory.
Stop the collector.
avctl stop_collector -collname collector_name -srcname source_name
Stop the Audit Vault Console.
avctl stop_av
Stop the listener on the server side.
lsnrctl stop listener_name
On the server side, manually edit the listener.ora
and tnsnames.ora
files in $ORACLE_HOME/network/admin
on the server to use the new port number.
If the port number that you want to set is not 1521, then do the following:
Verify that the $ORACLE_HOME/network/admin/tnsnames.ora
file contains an entry for the listener. This entry is as follows; make a note of the listener_name
value:
listener_name = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=newport)))
Verify that the local_listener
parameter in the database is set to the listener name that is defined in your tnsnames.ora
file. This step ensures that the database and related services are registered with the listener.
On the server side, restart the listener.
lsnrctl start listener_name
Edit the emoms.properties
file in the $ORACLE_HOME/
hostname_sid
/sysman/config
directory to use the listener port that Oracle Enterprise Manager connects to.
To do so, edit the emdRepPort
and emdRepConnectDescriptor
properties in the emoms.properties
file.
Edit the PORT
value in the oracle_listener
and oracle_database
entries in the $ORACLE_HOME/
hostname_sid
/sysman/emd/targets.xml
file to use the new port number.
From the Audit Vault Server shell, restart the Audit Vault Console and collector, and then check their status to ensure that they can connect to the source database.
avctl start_av avctl start_collector -collname collector_name -srcname source_name avctl show_av_status avctl show_collector_status -collname collector_name -srcname source_name
From the Audit Vault collection agent shell, restart the collection agent, and then ensure that it is running by checking its status.
For collection agents created in Release 10.2.3.2:
avctl start_agent avctl show_agent_status
For Release 10.2.3.1 or earlier collection agents that have not yet been upgraded:
avctl start_oc4j avctl show_oc4j_status
Next, reconfigure each Audit Vault collection agent to connect to the database, as follows:
Access the shell or command prompt for the Audit Vault Server.
UNIX: If necessary, set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME
\bin
directory.
Stop each collector.
avctl stop_collector -collname collector_name -srcname source_name
Stop the collection agents.
For collection agents that were created in Release 10.2.3.2:
avctl stop_agent
For Release 10.2.3.1 or earlier collection agents that have not yet been upgraded:
avctl stop_oc4j
In the Audit Vault collection agent home, edit the entry for AV
in the $ORACLE_HOME/network/admin/tnsnames.ora
file to use the new port number.
Restart the collection agents.
For collection agents created in Release 10.2.3.2:
avctl start_agent
For Release 10.2.3.1 or earlier collection agents that have not yet been upgraded:
avctl start_oc4j
From the Audit Vault Server shell, start each collector for the agent.
avctl start_collector -collname collector_name -srcname source_name
Changing the HTTP port for the Audit Vault Console affects the Audit Vault Console only.
To change the HTTP port for the Audit Vault Console:
In the $ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_
host_name
_av/config/av-web-site.xml
file, edit the web-site port
entry to use the new port number.
In the $ORACLE_HOME/oc4j/j2ee/oc4j_applications/applications/av/av/WEB-INF/classes/av.properties
file, edit the av.console.port entry to match the port number you entered in Step 1.
Open a shell or command prompt for the Audit Vault Server.
UNIX: Set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME
\bin
directory.
Stop the Audit Vault Console.
avctl stop_av
Restart the Audit Vault Console.
avctl start_av
Changing the Database Control port number affects only Database Control.
To change the Database Control port number:
From the Audit Vault Server shell, run the following emca
-reconfig
ports commands:
emca -reconfig ports -DBCONTROL_HTTP_PORT new_port_number
emca -reconfig ports -RMI_PORT new_port_number
emca -reconfig ports -JMS_PORT new_port_number
In the $ORACLE_HOME/
hostname_sid
/sysman/config
directory, edit the emoms.properties
file to use the new listener port that Database Control uses.
Changing the Audit Vault PL/SQL gateway port affects the Audit Vault Console only.
In the Audit Vault Server shell or command prompt, ensure that the listener is running.
lsnrctl status
If the listener is not running, then start it.
lsnrctl start
Log in to SQL*Plus as a user who has been granted the AV_ADMIN
role.
For example:
sqlplus tjones
Enter password: password
Connected.
Run the following statements:
SQL> EXEC DBMS_XDB.SETHTTPPORT(new_port_number);
SQL> COMMIT;
Changing the port numbers for the Audit Vault agent affects the agents and collectors.
This section contains:
Changing the HTTP port for the collection agent affects the agents and collectors only.
To change the port number for the agent HTTP connection:
Open a shell or command prompt for the Audit Vault collection agent.
UNIX: Set the environment variables, as described in Section 2.2.3.
Microsoft Windows: Go to the collection agent ORACLE_HOME
\bin
directory.
Stop the collection agents.
For collection agents that were created in Release 10.2.3.2:
avctl stop_agent
For Release 10.2.3.1 or earlier collection agents that have not yet been upgraded:
avctl stop_oc4j
In the $ORACLE_HOME/oc4j/j2ee/home/config/http-web-site.xml
file, edit the web-site
port entry to use the new port number.
Restart the collection agents.
For collection agents created in Release 10.2.3.2:
avctl start_agent
For Release 10.2.3.1 or earlier collection agents that have not yet been upgraded:
avctl start_oc4j
Log in to Audit Vault Console as a user who has been granted the AV_ADMIN
role.
Navigate to the Configuration page, then select the Agent tab.
Select the agent for which you changed the port.
Click the Edit button.
In the Port Number field, enter the new port number.
Click OK to update the port number for this agent in the Audit Vault Server.
Changing the collection agent RMI and JMS port numbers affects the agents only.
To change the collection agent RMI and JMS port numbers:
Open a shell or command prompt for the Audit Vault collection agent.
UNIX: Set the environment variables, as described in Section 2.2.3.
Microsoft Windows: Go to the collection agent ORACLE_HOME
\bin
directory.
Stop the collection agents.
For collection agents that were created in Release 10.2.3.2:
avctl stop_agent
For Release 10.2.3.1 or earlier collection agents that have not yet been upgraded:
avctl stop_oc4j
In the $ORACLE_HOME/oc4j/j2ee/home/config/rmi.xml
file, edit the rmi-server
port setting to use the new port number for the RMI port.
In the $ORACLE_HOME/oc4j/j2ee/home/config/jms.xml
, edit the jms-server
port to use the new port number for the JMS port.
Restart the collection agents.
For collection agents created in Release 10.2.3.2:
avctl start_agent
For Release 10.2.3.1 or earlier collection agents that have not yet been upgraded:
avctl start_oc4j
Changing the port number for the Oracle source database affects the Audit Vault collectors.
First, change the port number for the source database listener:
Open a shell or command prompt for the Audit Vault Server.
UNIX: Set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME
\bin
directory.
Stop each collector that is running against this source database.
avctl stop_collector -collname collector_name -srcname source_name
Shut down the listener.
lsnrctl stop
Use Oracle Net Configuration Assistant to change the port number.
From $ORACLE_HOME/bin
, enter the following command to start Net Configuration Assistant:
netac
Restart the listener.
lsnrctl start
Do not close this shell.
Next, follow these steps:
Update the source database port number.
From the Audit Vault Server, run the following command:
avorcldb alter_source -srcname source_name PORT=new_port_number
Alternatively, use the Audit Vault Console to change the source database port number.
From the collection agent shell, update the port number in the tnsnames.ora
file.
avorcldb setup -srcname source_database Enter Source user name: username Enter Source password: password
Alternatively, edit the port number for the source database in the tnsnames.ora
file in the $ORACLE_HOME/network/admin
directory.
From the Audit Vault Server shell, start each collector the agent.
avctl start_collector -collname collector_name -srcname source_name
On the Audit Vault Server, update the port number in the file $ORACLE_HOME/network/admin/tnsnames.ora
for the source database.
This section contains:
When you add an Oracle source database from Releases 10.2.0.3 through 11.2 with Oracle Audit Vault, you can use the DBMS_AUDIT_MGMT
PL/SQL package to purge the database audit trail. This feature does not apply to Oracle Database 9i Release 2 (9.2) source databases.
The DBMS_AUDIT_MGMT
package enables you to perform audit trail cleanup tasks such as scheduling purge jobs, moving the audit trail to a different tablespace, setting archive timestamps in the audit trail, and so on. You must have the EXECUTE
privilege for DBMS_AUDIT_MGMT
before you can use it.
By default, Oracle Database 11g Release 2 (11.2) has the DBMS_AUDIT_MGMT
package and its associated data dictionary views installed. If your source database is from Release 10.2.0.3 through 11.1.0.7, then you can download the DBMS_AUDIT_MGMT
package and data dictionary views from My Oracle Support, from the following Web site:
Search for Article ID 731908.1.
To create an automated purge job in an Oracle Audit Vault environment, see Section 4.10.2.
For details about using the DBMS_AUDIT_MGMT
PL/SQL package and views, refer to the following Oracle Database 11g Release 2 (11.2) documentation:
The section "Purging Audit Trail Records" in Oracle Database Security Guide for conceptual and procedural information
Oracle Database PL/SQL Packages and Types Reference for reference information about the DBMS_AUDIT_MGMT
PL/SQL package
Oracle Database Reference for information about the DBA_AUDIT_MGMT_*
data dictionary views
Oracle Audit Vault is integrated with the DBMS_AUDIT_MGMT
package on a source database. This integration automates the purging of audit records from the AUD$
and FGA_LOG$
files, and from the operating system .aud
and .xml
files after they have been successfully inserted into the Audit Vault repository by the Audit Vault collector. After the purge is completed, the collectors automatically set a timestamp on audit data that has been collected. Therefore, you must set the USE_LAST_ARCH_TIMESTAMP
property to true to ensure that the right set of audit records are purged. You do not need to manually set a purge job interval.
To schedule an automated purge job for an Audit Vault source Oracle database:
Log in to SQL*Plus on the source database as a user who has been granted the EXECUTE
privilege for the DBMS_AUDIT_MGMT
PL/SQL package.
For example:
sqlplus tjones
Enter password: password
Initialize the audit trail cleanup operation.
In the following example, the DEFAULT_CLEANUP_INTERVAL
setting runs the job every two hours:
BEGIN DBMS_AUDIT_MGMT.INIT_CLEANUP( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL, DEFAULT_CLEANUP_INTERVAL => 2 ); END; /
Verify that the audit trail is initialized for cleanup.
For example:
SET SERVEROUTPUT ON BEGIN IF DBMS_AUDIT_MGMT.IS_CLEANUP_INITIALIZED(DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL) THEN DBMS_OUTPUT.PUT_LINE('Database and OS audit are initialized for cleanup'); ELSE DBMS_OUTPUT.PUT_LINE('Database and OS audit are not initialized for cleanup.'); END IF; END; /
Use the DBMS_AUDIT_MGMT.CREATE_PURGE_JOB
procedure to create and schedule the purge job.
In this procedure, ensure that you set the USE_LAST_ARCH_TIMESTAMP
property to TRUE
, so all records older than the timestamp can be deleted.
The following procedure creates a purge job called CLEANUP_OS_DB_AUDIT_RECORDS
that will run every two hours to purge the audit records.
BEGIN DBMS_AUDIT_MGMT.CREATE_PURGE_JOB ( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL, AUDIT_TRAIL_PURGE_INTERVAL => 2, AUDIT_TRAIL_PURGE_NAME => 'CLEANUP_OS_DB_AUDIT_RECORDS', USE_LAST_ARCH_TIMESTAMP => TRUE ); END; /
See Oracle Database PL/SQL Packages and Types Reference for detailed information about the DBMS_AUDIT_MGMT
PL/SQL package.
By default, the audit trail generated by the Oracle Audit Vault repository is purged every 24 hours. If you want, you can change these purge settings, or to disable purging altogether. (You may want to disable the purge settings if you are using a different purge utility.) For information about purging the audit trail, see the list of documentation references in Section 4.11.
Note the following:
The AUDIT_TRAIL
initialization parameter in the Audit Vault Server database is set to DB
, which means that the audit trail is written to the database AUD$
system table. You can set the audit trail to any valid AUDIT_TRAIL
initialization parameter setting. (However, you cannot modify the Oracle Database Vault audit trail setting, which is always DB
.)
Because Oracle Database Vault is enabled, the AUD$
system table resides in the SYSTEM
schema. The synonym SYS.AUD$
is created to refer to the SYSTEM.AUD$
table. (Oracle strongly recommends that you do not disable Oracle Database Vault.)