If UPDATE or INSERT triggers are enabled on schema tables during masking operations they will fire for each masking operation performed. This can have the effect of dramatically slowing down the execution rate of the masking rule. Often such triggers are not necessary during masking as they commonly perform auditing functions. If this is the case, then such triggers can be disabled prior to execution of the masking rules and re-enabled again at the end.

If it is desirable to disable the schema triggers during the masking operations then a Trigger Manager rule can be implemented to automate the task. A Trigger Manager rule is a container which manages the execution of a number of subsidiary actions which perform the trigger disable or enable.

The implementation of the trigger enable/disable operations as a manager was done to make the process simple and intuitive. An Oracle schema can have many triggers and each disable/enable action requires the execution of a distinct SQL statement. Each operation must be recorded in the log and any errors must be detected and reported. If such actions were configured as individual rules in the masking set, then the large quantity of such rules could visually overwhelm the masking set - leaving it hard to maintain the other masking rules. It is much more efficient to collect all of the actions together under one rule which acts as a manager. The Trigger Manager Rule form provides the ability to view, configure and manage the trigger disable/enable actions and the Trigger Manager rule itself controls the execution of the configured disable/enable trigger operations. Errors and statistics are handled by the Trigger Enable/Disable rule and presented to the user in a manageable summary form.

It is possible to configure the Trigger Manager to ignore a certain number (or all) of the errors received while processing the trigger operations. This enables the Trigger Manager to continue operating even if errors occur. Be aware that ignoring the errors in the Trigger Manager just permits the Trigger Manager to complete as many operations as possible before returning an error and stopping the execution of the masking set. In other words, even if errors are ignored, any errors which occur during the trigger disable/enable operations will mark the Trigger Manager rule as having failed and the error state will be reported to the Data Masker software for handling once the actions have completed.

Important Note: The Trigger Manager rule is only aware of the triggers given to it by the Rule Controller. To refresh the list of triggers known to the Trigger Manager rule, first refresh the triggers in the Rule Controller using the Refresh Triggers button on Options tab of the edit Rule Controller form. This retrieves an up-to-date list from the target schema. Once the Rule Controller has been updated, use the Refresh Trigger List button on the Trigger Manager Rule form to refresh the list inside the Trigger Manager rule.

Once the Trigger Manager rule has begun to execute, the trigger disable/enable operations will proceed in parallel using the full number of threads specified on the Run Statistics tab until all specified triggers have been operated on.

If required, a Trigger Manager rule is usually configured (using Rule Blocks) to run in disable mode as the very first rule in the masking set. A second Trigger Manager rule is configured to run in enable mode as the very last rule in the masking set. This ensures the triggers are disabled during the masking operations and, hence, will not fire and slow the process down.

Trigger Manager rules are created by launching the New Trigger Manager rule form using the New Rule button located on the bottom of the Rules in Set tab.

How to Create a New Trigger Manager rule