Register | Login

Audit facility performance and administration have been enhanced

The audit utility generates a trail of audit records for a series of predefined and monitored database events. Version 9.5 offers major enhancements to the audit facility.

The enhancements to the DB2 audit facility for Version 9.5 include fine grained configuration, new audit categories, separate instance and database logs, and new ways to customize the audit configuration. Because you now have control over exactly which database objects are audited, you no longer need to audit events that occur for database objects that you are not interested in. Consequently, the performance of auditing (and its performance impact on other database operations) has been greatly improved. Sole responsibility for managing audits at the database level now lies with the security administrator.

The following audit facility enhancements are included in Version 9.5:
•You can use new database objects called audit policies to control audit configuration within a database.
Individual databases can have their own audit configurations, as can particular objects within a database, such as tables, or even users, groups, and roles. In addition to providing easier access to the information that you need, this enhancement also improves performance, because less data needs to be written to disk.
•Auditing SQL statements is easier and produces less output.
The new audit category, EXECUTE, allows you to audit just the SQL statement that is being run. Previously, you needed to audit the CONTEXT event to capture this detail.
•Audit logs exist for each database.
There is now one audit log for the instance and one audit log for each database. This feature simplifies audit reviews.
•The audit log now has a customizable path.
Control over the audit log path allows you to place audit logs on a large, high-speed disk, with the option of having separate disks for each node in a database partitioning (DPF) installation. This feature also allows you to archive the audit log offline, without having to extract data from it until necessary.
•You can archive audit logs.
Archiving the audit log moves the current audit log to an archive directory, while the server begins writing to a new, active audit log. When you extract data from an audit log to a database table, it is from an archived log, not the active audit log. This prevents performance degradation caused by locking of the active audit log.
•The security administrator (who holds SECADM authority) now manages the audit for each database.
The security administrator is solely in control of configuring an audit for a database; the system administrator (holding SYSADM authority) no longer has this authority. The security administrator also has sufficient access to manipulate the audit log, issue the ARCHIVE command, and extract a log file into a table.
•You can audit new information in each category.
The CURRENT CLIENT special registers allow values for a client user ID, accounting string, workstation name, and application name to be set within applications so that these values will be recorded in the audit data.
The local and global transaction IDs can be recorded in audit data. This facilitates correlation between the audit log and the transaction log.

Who Voted for this Article, is a website that will allow everyone to share their knowledge, tip or information through community micro blogging.