Event types and filtering

The following table shows the correlation between the event type and filtering. You can define and manage filtering criteria by setting the Database Type to DB2 Collection Profile in the Guardium Policy Builder of the Guardium® appliance interface.

If you enable collection of SELECT/UPDATE/DELETE/INSERT/MERGE/TRUNCATE events, then the event collection is subjected to additional filtering. If you enable collection of event types other than SELECT/UPDATE/DELETE/INSERT/MERGE/TRUNCATE, then the events are collected without being subjected to filtering.

Table 1. Event types and filtering
Event type	Subjected to filtering?
SELECT/MERGE/UPDATE/INSERT/DELETE/TRUNCATE	Yes
LOCK	No
CREATE/ALTER/DROP/RENAME	No
GRANT/REVOKE	No
SET CURRENT SQLID/SET CURRENT SCHEMA	No
Db2® COMMANDS	No
Db2 UTILITIES	No
FAILED LOGINS	No
NEGATIVE SQLCODEs	No
COMMIT/ROLLBACK	No
BINDS/REBINDS	No

Enabling the collection of specific event types

The active policy determines which event types are enabled for collection. If the event type is enabled within a rule for the active policy, it is enabled for all rules within the active policy.

An event that is enabled in Rule 1 is subjected to subsequent rule filters. The following is an example using ASC event type collection:

Rule 1 contains an Object field value of %/%.%.
Rule 1 contains AUTHID filtering for User 1.
Rule 2 contains AUTHID filtering for User 2.
SELECT/UPDATE/DELETE/INSERT/MERGE/TRUNCATE/SET CURRENT USERID/CREATE/ALTER/DROP/RENAME/LOCK events are collected for all tables for both User 1 and User 2.

Tip: This example could be simplified by placing both AUTHIDs into a group within a single rule.

The following is an example using event type collection:

Rule 1 contains the collection of Utility events.
Rule 1 contains AUTHID filtering for User 1.
Rule 2 does not contain the collection of Utility events, but it contains AUTHID filtering for User 2.
All Utility events are collected because they are enabled for Rule 1.

This list describes how you can enable the collection of specific event types:

SELECT/UPDATE/INSERT/DELETE/MERGE/TRUNCATE: Enable collection by including any filter type or non-blank value in the Object field of the rule.; Two target records are reported for nested INSERT/UPDATE/DELETE/MERGE events: SELECT, and either INSERT, UPDATE, DELETE, or MERGE. All nested INSERT/UPDATE/DELETE/MERGE events are considered Table Change events. If the table filter is set to collect only READ events, then these events are filtered out (not collected).; Wildcarding can be used within the Object field value, for example: %/SYSIBM.SYSTABLES or %/%.%.
CREATE/ALTER/DROP/RENAME/LOCK: Collection is automatically enabled by including any filter type or non-blank value in the Object field of the rule.; Wildcarding can be used within the Object field value, for example: %/SYSIBM.SYSTABLES or %/%.%.
GRANT/REVOKE: Enable collection through the GRANT/REVOKE command setting.
SET CURRENT SQLID/SET CURRENT SCHEMA: Collection is automatically enabled by including any filter type or non-blank value in the Object field of the rule.; Wildcarding can be used within the Object field value, for example: %/SYSIBM.SYSTABLES or %/%.%.
DB2 COMMANDS: Enable collection through the DB2 Commands command setting.; Enable collection by adding the DB2 Commands event type to the COMMAND collection in a rule.
DB2 UTILITIES: Enable collection through the UTILITES command setting.
FAILED LOGINS: Enable collection through the FAILED AUTHID CHANGES command setting.
NEGATIVE SQLCODES: Enable collection through the presence of a negative SQLCODE list. Only one list is allowed per policy.; SQLCODE collection can be added to an active collection policy. A policy that contains a single rule with only negative SQLCODES results in an inactive policy.; To enable the collection of negative SQLCODE events, the pushed-down policy should contain negative SQLCODEs.
COMMIT/ROLLBACK: Enable collection by adding COMMIT/ROLLBACK to the Guardium appliance policy.