Search Results enable_policy

Overview

SYS.DBMS_FGA is the Oracle-supplied PL/SQL package that implements Fine-Grained Auditing (FGA) in the database. In the context of Oracle E-Business Suite 12.1.1 and 12.2.2, DBMS_FGA provides the administrative interface by which DBAs and technical consultants define, enable, disable, and remove audit policies that selectively capture access to specific rows and columns of application tables. Rather than auditing every DML statement against a table, FGA allows auditing to be triggered conditionally, based on a Boolean predicate evaluated at statement execution time. This makes the package particularly valuable in EBS environments where regulatory requirements (such as SOX, HIPAA, or PCI-DSS) mandate evidence of who accessed or modified sensitive data such as supplier bank accounts, employee salaries, or customer payment details.

The package is owned by SYS and its status is VALID in the documented EBS releases. ETRM classifies it as API classification OTHER, reflecting that it is a generic database utility rather than an EBS application-level API. DBMS_FGA depends on the STANDARD package, and the public synonym DBMS_FGA is referenced by PUBLIC and by SYS, allowing any suitably privileged EBS schema to invoke it.

Key Procedures and Functions

ETRM documents four procedures or functions for this package:

• ADD_POLICY — Creates a new fine-grained audit policy. It associates an audit policy name with a target object (table or view), optionally defines an audit condition (a predicate limiting which rows are audited), specifies the columns to be audited, and designates the audit trail destination (DBMS_FGA uses the standard audit trail or a configured FGA audit table).
• DROP_POLICY — Removes an existing FGA policy from the data dictionary. Once dropped, the policy no longer triggers auditing on the associated object.
• ENABLE_POLICY — Activates a previously defined policy that is currently in a disabled state, so that qualifying statements are audited.
• DISABLE_POLICY — Deactivates a policy without removing its definition, allowing auditing to be suspended temporarily — for example, during a data migration or a bulk concurrent process — and later re-enabled.

Each procedure writes audit policy metadata to the data dictionary, and the actual audit records are generated at runtime by the database kernel when the policy condition evaluates to true.

Tables Accessed

The ETRM metadata for DBMS_FGA does not document specific application tables referenced via APPS synonyms, and the package is not referenced by any other documented EBS package. Internally, DBMS_FGA writes policy definitions to the SYS-owned FGA dictionary tables (notably FGA$ and the audit policy views) and the resulting audit records are written to the configured FGA audit trail table (FGA_LOG$ by default, exposed through DBA_FGA_AUDIT_TRAIL). In EBS deployments these underlying SYS tables fall outside the APPS schema and are therefore not enumerated in ETRM as application dependencies. Consultants should treat DBMS_FGA primarily as a dictionary-manipulating utility whose observable output appears in the audit trail views, not in EBS application tables.

Usage Notes

DBMS_FGA is not invoked by standard EBS Forms, concurrent programs, or Oracle-provided application code. It is a DBA-level utility executed from SQL*Plus or a privileged PL/SQL session, typically by the SYS or SYSTEM user, or by a user granted the EXECUTE privilege on the package. In EBS 12.1.1 and 12.2.2, it is commonly used to implement compensating auditing controls around sensitive tables where the standard EBS audit mechanisms (AuditTrail, Sign-On Audit, or the Audit Manager) do not provide sufficient granularity.

Because FGA policies evaluate on every qualifying statement, they introduce measurable runtime overhead; they should be scoped with precise audit conditions and limited column lists. Policies are also not automatically migrated with EBS patching or cloning activities and must be re-created or scripted for each environment. Prior to 12.2 Online Patching, care must be taken to define policies so that they do not interfere with the editioning views and trigger logic introduced by the AD Online Patching infrastructure. Custom code invoking DBMS_FGA should be reviewed to ensure the executing schema holds the required privileges and that the audit trail tablespace has sufficient space.