Why Audit
- Its all about protecting sensitive data, maintaining customer trust, and protecting the business
- Trust-but-verify that your employees are only performing operations required by the business
- Detective controls to monitor what is really going on
- Reduce the curiosity seekers from looking at data
- Compliance demands that privileged users be monitored
- Know what is going on before others tell you
Introduction to Oracle Audit Vault
The architecture of OAV consists of two major components that work together to store and secure the audit data. First is the Audit Vault Server, a standalone application that contains a data warehouse built on a customized installation of Oracle Database 10g/11g/12c, Oracle Database Vault, and OC4J components to support the Audit Vault Console and Enterprise Manager Database Control. Second is the Audit Vault Collection Agent that manages the collectors and maintains the Audit Vault Wallet. The collector acts as the middleman between the Oracle Audit Vault Server and the target system to pull audit trail data. The wallet is used to store and maintain the passwords needed for the collectors to connect to the target source. Figure 1 is a diagram from the Oracle Audit Vault Administrator’s Guide that provides an overview of the basic architecture.
The Audit Vault Server consists of an audit data store, the Audit Vault Console and services to manage data collection, alerts, monitoring, and reporting. Oracle Database Vault protects the audit data by restricting administrative access and is included with the Oracle Audit Vault Server. The OAV Collection Agent Components consist of the Audit Vault Collector Manager, Oracle Wallet to hold the credentials used to authenticate Audit Vault users, and utilities used to configure and manage the Audit Vault including AVCA, AVCTL, AVORCLDB, AVMSSQLDB, AVSYSDB, and AVDB2DB command-line tools.
Oracle Audit Vault Automated Activity Monitoring & Audit Reporting
- Consolidate audit data into secure repository
- Detect and alert on suspicious activities
- Out-of-the box compliance reporting
- Centralized audit policy management
The following situations require you to disable Oracle Database Vault:
The password for the Oracle Database Vault account manager (with role DV_ACCTMGR) has been forgotten.
The Database Vault Owner (with role DV_OWNER) or Database Vault Administrator (with role DV_ADMIN) accounts have been inadvertently locked out.
A rule set associated with the CONNECT role has been configured incorrectly. This is resulting in failed database logins for all accounts, including those with the DV_OWNER or DV_ADMIN role, who could correct this problem.
You must perform maintenance tasks on Oracle Database Vault.
You must install any of the Oracle Database optional products, such as Oracle Spatial Data Option, Oracle OLAP, or Oracle interMedia, by using Database Configuration Assistant (DBCA).
You are about to install a third-party product, install an Oracle product, or perform an Oracle patch update whose installation may be prevented if Oracle Database Vault is running.
You must archive the Oracle Database Vault audit trail
Checking if Oracle Database Vault Is Enabled or Disabled
You can check if Oracle Database Vault has already been enabled or disabled by querying the V$OPTIONS table. Any user can query this table. If Oracle Database Vault is enabled, the query returns TRUE. Otherwise, it returns FALSE.
Remember that the PARAMETER column value is case sensitive. For example:
SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';
If Oracle Database Vault is enabled, the following output appears:
PARAMETER VALUE
----------------------------- -----------------------
Oracle Database Vault TRUE
Step 1: Disable Oracle Database Vault
Follow these steps to disable Oracle Database Vault on UNIX systems:
Turn off the software processes. Make sure that the environment variables, ORACLE_HOME, ORACLE_SID, and PATH are correctly set.
For single-instance installations, shut down the database instance:
$ sqlplus "SYS / AS SYSOPER"
Enter password: password
SQL> SHUTDOWN IMMEDIATE
SQL> EXIT
For Oracle Real Application Clusters (RAC) installations, shut down each database instance as follows:
$ srvctl stop database -d db_name -c "sys/sys_passwd as sysoper"
If you cannot connect to the database, then proceed to the next step.
Relink the Oracle executable to turn off the Oracle Database Vault option:
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk dv_off
$ cd $ORACLE_HOME/bin
$ relink oracle
For RAC installations, run these commands on all nodes.
In SQL*Plus, start the database.
For single-instance database installations:
$ sqlplus "SYS / AS SYSOPER"
Enter password: password
SQL> STARTUP
SQL> EXIT
For RAC installations:
$ srvctl start database -d db_name -c "sys/sys_passwd as sysoper"
Connect as SYS using the SYSDBA privilege, and then run the following ALTER TRIGGER statements:
SQL> CONNECT SYS / AS SYSDBA
Enter password: password
SQL> ALTER TRIGGER DVSYS.DV_BEFORE_DDL_TRG DISABLE;
SQL> ALTER TRIGGER DVSYS.DV_AFTER_DDL_TRG DISABLE;
Note:
After you disable Oracle Database Vault, you still can run the Oracle Database Vault API functions. Note also that after you disable Oracle Database Vault, the ANY privileges are available.
Step 2: Perform the Required Tasks
With Oracle Database Vault disabled, you can restart your database and perform the following tasks, as required. You can perform the following types of activities:
Use the Oracle Database Vault PL/SQL packages and functions. For example, to correct a login or CONNECT rule set error, use the DBMS_MACADM package or the Oracle Database Vault Administrator interface.
Note:
If you are using Oracle Database Vault Administrator, then you must start the dbconsole process. You can check the status of the dbconsole process by entering the following command from the $ORACLE_HOME/bin directory of the Oracle home in which you deployed Database Vault Administrator:
./emctl status dbconsole
To start dbconsole:
./emctl start dbconsole
Use the SYSTEM or SYS accounts to perform tasks such as creating or changing passwords. For example:
$ sqlplus "sys/as sysdba"
Enter password: password
SQL> PASSWORD dbvanalyst
New password: new_password
Retype new password: new_password
Similarly, to unlock a locked account, log in to the database instance as SYSTEM or SYS, and then unlock the account. For example:
SQL> ALTER USER SCOTT ACCOUNT UNLOCK;
Perform the installation, upgrade, or other tasks that require security protections to be disabled. If you must run Oracle Database Vault Configuration Assistant (DVCA), ensure that the Oracle Database listener is running. To start the listener, run the following command from the $ORACLE_HOME/bin directory:
$ ./lsnrctl start
Step 3: Enable Oracle Database Vault
Use the following steps to enable Oracle Database Vault on UNIX systems:
Log into SQL*Plus as SYS using the SYSDBA privilege, and then run the following ALTER TRIGGER statements:
$ sqlplus "sys / as sysdba"
Enter password: password
Connected.
SQL> ALTER TRIGGER DVSYS.DV_BEFORE_DDL_TRG ENABLE;
SQL> ALTER TRIGGER DVSYS.DV_AFTER_DDL_TRG ENABLE;
Turn off the software processes. Make sure that the environment variables, ORACLE_HOME, ORACLE_SID, and PATH are correctly set.
Shut down the database instance.
For single-instance installations:
$ sqlplus "sys / as sysoper"
Enter password: password
Connected.
SQL> SHUTDOWN IMMEDIATE
SQL> EXIT
For RAC installations:
$ srvctl stop database -d db_name -c "sys/sys_passwd as sysoper"
Relink the oracle executable to turn on the Oracle Database Vault option:
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk dv_on
$ cd $ORACLE_HOME/bin
$ relink oracle
For RAC installations, run these commands on all nodes.
In SQL*Plus, start the database:
For single-instance database installations:
$ sqlplus "sys / as sysoper"
Enter password: password
Connected.
SQL> STARTUP
SQL> EXIT
For RAC installations:
$ srvctl start database -d db_name -c "sys/sys_passwd as sysoper"
Real-Time Implementation Notes
Oracle
Audit Vault Handover Notes
Increased auditing
for Oracle Audit Vault (OAV) has been configured on the following
databases currently:
database1
database2
database3
database4
The OAV agent has
been installed on 5 Prod boxes so far:
Server1 under
/apps/R12/database4/avagent
Server2, Server3, Server4 and Server5 user /OAV/avagent.
This filesystem does not failover with the other Oracle filesystems
during HACMP failover and the agent runs whether the node is active
or not.
To start, stop and
check the status of the OAV agent do the following:
cd to the the bin
directory under avagent
export
JAVA_HOME=/usr/java6_64 (/usr/java6 on fosdyke)
export
PATH=/usr/java6_64/bin:$PATH (/usr/java6/bin on fosdyke)
./agentctl
start|stop|status
The
commands to configure auditing on and off for the databases are under
/home/oracle/AG/AUDIT_VAULT (or see the Oracle OAV pdf document).
Note that on database1 some of these commands can cause blocks on the
database so SDG ask us to run them overnight if necessary.
Only
database1 has fine grained auditing set and there is a condition that
filters out the batch user OPS$LPRD001.
You can view the
current audit settings on the database by querying the following
views:
DBA_PRIV_AUDIT_OPTS
DBA_STMT_AUDIT_OPTS
DBA_OBJ_AUDIT_OPTS
Housekeeping
of the audit tables (AUD$ and FGA_LOG$) is configured (see the Oracle
OAV pdf for details). Once the data is transferred to OAV it will be
deleted after a period of time. The timestamps that control the
transfer of the data can be viewed by querying
DBA_AUDIT_MGMT_LAST_ARCH_TS.
Things to Monitor
Keep
an eye on the TSP_AUDIT tablespace especially on database1 which
generates more data due to fine grained auditing. If it is filling
up check how far the audit data goes back (NTIMESTAMP# on AUD$ and
FGA_LOG$). The purge job is called CLEANUP_OS_DB_AUDIT_RECORDS
and runs daily at the moment on database4, database3 and database2.
On database1 it runs hourly. This can be run manually if necessary
in TOAD (log on as SYS and open the Sched. Jobs tab).
Potential Issues
If
there’s a problem with the OAV server the audit data will not get
transferred, the timestamp will not get updated and so the old audit
rows will not get deleted which means that the TSP_AUDIT tablespace
could fill up. If this starts to happen it may be necessary to
switch auditing off on the databases. See the script under
/home/oracle/AG/AUDIT_VAULT to do this – don’t worry if you get a
few failures when running this and don’t let the statements hang on
database1 (check the 3 ‘AUDIT_OPTS’ views above to see that
everything has been removed).
The
audit settings from database1 will get copied across to trdprd but as
there is no OAV agent running the audit data will not get deleted.
When implemented previously this filled the TSP_AUDIT tablespace due
to the large volume of FGA data generated by the batch jobs. We are
now filtering out the batch user so this shouldn’t happen.
Alerting
Space Alerts
A
lower alert threshold will be set for the TSP_AUDIT tablespace in
order to identify issues early on. If the tablespace alerts it will
be necessary to identify where the issue is. Check with IBM AMS
support for the OAV server to see if it is running correctly. If it
is, run agentctl status (set the Java path 1st as
described earlier) to check that the OAV agent is running and start
it if it isn’t. If there is no issue with the agent check the
timestamps on DBA_AUDIT_MGMT_LAST_ARCH_TS as these should get updated
by the agent once data has been collected by the OAV server. If the
timestamps are several days in the past, double-check the OAV server
and agent.
If
the timestamps are recent on DBA_AUDIT_MGMT_LAST_ARCH_TS then check
the oldest value of NTIMESTAMP# on the AUD$ and FGA_LOG$ tables. If
these are several days old it could indicate a problem with the
housekeeping job CLEANUP_OS_DB_AUDIT_RECORDS
so check this for any issues.
OEM Alerts
It
is not possible to have Tivoli monitor the OAV Server so, to prevent
issues going undetected, two new metrics have been set up in OEM:
OAV
time since last OAV collection: This monitors the timestamps on
DBA_AUDIT_MGMT_LAST_ARCH_TS and alerts if either of them exceed the
threshold. This alert could indicate a problem with the OAV Server
itself or the agent as it means data is not being copied across to
the OAV server.
OAV
Age of oldest timestamp on audit tables: This alert would
indicate that data is not being deleted from the AUD$/FGA_LOG$ tables
as expected. This could indicate a problem with the
CLEANUP_OS_DB_AUDIT_RECORDS
housekeeping job or, if the other alert has also triggered, a fault
with either the OAV Server itself or the agent.
To reduce or completely remove the extra load placed on the database by Oracle Audit Vault there are a number of steps that are necessary which are detailed below. These were written for database but can be used on other databases if necessary.
Switching Off General Auditing
The following script will switch off general auditing. If any statements hang for more than a few seconds they should be cancelled to prevent application sessions being blocked.
NOAUDIT ALL ON SYS.AUD$;
NOAUDIT ALL ON SYS.AUD$ WHENEVER NOT SUCCESSFUL;
NOAUDIT ALL ON SYS.DBMS_EXPORT_EXTENSION;
NOAUDIT ALL ON SYS.DBMS_FGA;
NOAUDIT ALL ON SYS.DBMS_FILE_TRANSFER;
NOAUDIT ALL ON SYS.DBMS_JOB;
NOAUDIT ALL ON SYS.DBMS_NETWORK_ACL_ADMIN;
NOAUDIT ALL ON SYS.DBMS_RLS;
NOAUDIT ALL ON SYS.DBMS_XMLGEN;
NOAUDIT ALL ON SYS.KUPP$PROC;
NOAUDIT ALL ON SYS.UTL_FILE;
NOAUDIT ALL ON SYS.UTL_MAIL;
NOAUDIT ALL ON SYS.UTL_SMTP;
NOAUDIT ALL ON SYS.UTL_TCP;
NOAUDIT ALTER ANY ROLE;
NOAUDIT ALTER SEQUENCE;
NOAUDIT ALTER TABLE;
NOAUDIT CLUSTER;
NOAUDIT COMMENT TABLE;
NOAUDIT CONTEXT;
NOAUDIT DATABASE LINK;
NOAUDIT DIMENSION;
NOAUDIT DROP ANY ROLE;
NOAUDIT DROP ANY TABLE;
NOAUDIT GRANT ANY OBJECT PRIVILEGE;
NOAUDIT GRANT ANY PRIVILEGE;
NOAUDIT GRANT ANY ROLE;
NOAUDIT GRANT DIRECTORY;
NOAUDIT GRANT PROCEDURE;
NOAUDIT GRANT SEQUENCE;
NOAUDIT GRANT TABLE;
NOAUDIT GRANT TYPE;
NOAUDIT INDEX;
NOAUDIT MATERIALIZED VIEW;
NOAUDIT NOT EXISTS;
NOAUDIT OUTLINE;
NOAUDIT PROCEDURE;
NOAUDIT PROFILE;
NOAUDIT PUBLIC DATABASE LINK;
NOAUDIT PUBLIC SYNONYM;
NOAUDIT ROLE;
NOAUDIT ROLLBACK SEGMENT;
NOAUDIT SELECT ANY DICTIONARY;
NOAUDIT SELECT ANY TABLE WHENEVER NOT SUCCESSFUL;
NOAUDIT SEQUENCE;
NOAUDIT SESSION;
NOAUDIT SYNONYM;
NOAUDIT SYSTEM AUDIT;
NOAUDIT SYSTEM GRANT;
NOAUDIT TABLE;
NOAUDIT TABLESPACE;
NOAUDIT TRIGGER;
NOAUDIT TYPE;
NOAUDIT USER;
NOAUDIT VIEW;
Check the following views to see if any audit options remain (note that ‘create session’ and ‘directory’ should remain as these were on prior to OAV being implemented):
Switching Off General Auditing
The following script will switch off general auditing. If any statements hang for more than a few seconds they should be cancelled to prevent application sessions being blocked.
NOAUDIT ALL ON SYS.AUD$;
NOAUDIT ALL ON SYS.AUD$ WHENEVER NOT SUCCESSFUL;
NOAUDIT ALL ON SYS.DBMS_EXPORT_EXTENSION;
NOAUDIT ALL ON SYS.DBMS_FGA;
NOAUDIT ALL ON SYS.DBMS_FILE_TRANSFER;
NOAUDIT ALL ON SYS.DBMS_JOB;
NOAUDIT ALL ON SYS.DBMS_NETWORK_ACL_ADMIN;
NOAUDIT ALL ON SYS.DBMS_RLS;
NOAUDIT ALL ON SYS.DBMS_XMLGEN;
NOAUDIT ALL ON SYS.KUPP$PROC;
NOAUDIT ALL ON SYS.UTL_FILE;
NOAUDIT ALL ON SYS.UTL_MAIL;
NOAUDIT ALL ON SYS.UTL_SMTP;
NOAUDIT ALL ON SYS.UTL_TCP;
NOAUDIT ALTER ANY ROLE;
NOAUDIT ALTER SEQUENCE;
NOAUDIT ALTER TABLE;
NOAUDIT CLUSTER;
NOAUDIT COMMENT TABLE;
NOAUDIT CONTEXT;
NOAUDIT DATABASE LINK;
NOAUDIT DIMENSION;
NOAUDIT DROP ANY ROLE;
NOAUDIT DROP ANY TABLE;
NOAUDIT GRANT ANY OBJECT PRIVILEGE;
NOAUDIT GRANT ANY PRIVILEGE;
NOAUDIT GRANT ANY ROLE;
NOAUDIT GRANT DIRECTORY;
NOAUDIT GRANT PROCEDURE;
NOAUDIT GRANT SEQUENCE;
NOAUDIT GRANT TABLE;
NOAUDIT GRANT TYPE;
NOAUDIT INDEX;
NOAUDIT MATERIALIZED VIEW;
NOAUDIT NOT EXISTS;
NOAUDIT OUTLINE;
NOAUDIT PROCEDURE;
NOAUDIT PROFILE;
NOAUDIT PUBLIC DATABASE LINK;
NOAUDIT PUBLIC SYNONYM;
NOAUDIT ROLE;
NOAUDIT ROLLBACK SEGMENT;
NOAUDIT SELECT ANY DICTIONARY;
NOAUDIT SELECT ANY TABLE WHENEVER NOT SUCCESSFUL;
NOAUDIT SEQUENCE;
NOAUDIT SESSION;
NOAUDIT SYNONYM;
NOAUDIT SYSTEM AUDIT;
NOAUDIT SYSTEM GRANT;
NOAUDIT TABLE;
NOAUDIT TABLESPACE;
NOAUDIT TRIGGER;
NOAUDIT TYPE;
NOAUDIT USER;
NOAUDIT VIEW;
Check the following views to see if any audit options remain (note that ‘create session’ and ‘directory’ should remain as these were on prior to OAV being implemented):
DBA_PRIV_AUDIT_OPTS
DBA_STMT_AUDIT_OPTS
DBA_OBJ_AUDIT_OPTS
If any settings remain (except ‘create session’ and ‘directory’) they can be removed manually with the NOAUDIT command (remember to cancel any that hang though).
Once this has been done, if you count the rows on AUD$ a few times you should see that the number of rows being written here is now greatly reduced.
Switching Off Fine-Grained Auditing
The following command will switch off the fine-grained auditing configured currently on database:
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'ACCOUNT_HOLDER',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'TC_MOST_RECENT_DETAIL',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'AH_TELEPHONE_USAGE_QUALIFIER',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'AH_ADDRESS_BOOK_ENTRY',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'CUSTOMER',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'REMOTE_SITE_MESSAGE',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'ADDRESS',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'PIF_ADDRESS',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'PIF_AUDIT',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'COMMS_POSTAL_ADDRESS',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'PAYPAL_TRANSACTION',
policy_name=>'FGA_FOR_OAV'
);
END;
/
Check the view DBA_AUDIT_POLICIES for any that were missed. Once this step is complete, if you count the rows on FGA_LOG$ you should see that it has stopped growing.
Stopping the Audit Vault Agent
The agent is constantly reading the audit tables so to reduce the IO being generated by this it can be stopped (this should only be done once auditing has been switched off in the above steps, otherwise the audit rows will accumulate on the database and not get deleted which could cause space problems and hang the database)
As oracle:
cd /OAV/avagent/bin
export JAVA_HOME=/usr/java6_64
export PATH=/usr/java6_64/bin:$PATH
./agentctl stop
DBA_STMT_AUDIT_OPTS
DBA_OBJ_AUDIT_OPTS
If any settings remain (except ‘create session’ and ‘directory’) they can be removed manually with the NOAUDIT command (remember to cancel any that hang though).
Once this has been done, if you count the rows on AUD$ a few times you should see that the number of rows being written here is now greatly reduced.
Switching Off Fine-Grained Auditing
The following command will switch off the fine-grained auditing configured currently on database:
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'ACCOUNT_HOLDER',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'TC_MOST_RECENT_DETAIL',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'AH_TELEPHONE_USAGE_QUALIFIER',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'AH_ADDRESS_BOOK_ENTRY',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'CUSTOMER',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'REMOTE_SITE_MESSAGE',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'ADDRESS',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'PIF_ADDRESS',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'PIF_AUDIT',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'COMMS_POSTAL_ADDRESS',
policy_name=>'FGA_FOR_OAV'
);
END;
/
BEGIN
DBMS_FGA.DROP_POLICY(object_schema=>'TEST_DBA',
object_name=>'PAYPAL_TRANSACTION',
policy_name=>'FGA_FOR_OAV'
);
END;
/
Check the view DBA_AUDIT_POLICIES for any that were missed. Once this step is complete, if you count the rows on FGA_LOG$ you should see that it has stopped growing.
Stopping the Audit Vault Agent
The agent is constantly reading the audit tables so to reduce the IO being generated by this it can be stopped (this should only be done once auditing has been switched off in the above steps, otherwise the audit rows will accumulate on the database and not get deleted which could cause space problems and hang the database)
As oracle:
cd /OAV/avagent/bin
export JAVA_HOME=/usr/java6_64
export PATH=/usr/java6_64/bin:$PATH
./agentctl stop
No comments:
Post a Comment