7.3 Troubleshooting Frequently Asked Questions

Learn about common errors in Data Redaction and how to resolve them.

What are the most common errors (policy compile/apply/privilege issues) and how do I resolve them?

Common issues and resolutions:

  • ORA-28365 / insufficient privileges: The user creating or modifying a policy lacks the required privileges.

    Solution: Grant EXECUTE on DBMS_REDACT and necessary object privileges (for example, ALTER TABLE).

  • ORA-28115 / policy conflict: Multiple policies or conditions overlap on the same column.

    Solution: Review DBA_REDACT_POLICIES and consolidate or adjust predicates to avoid overlap.

  • ORA-01031 / insufficient privileges at runtime: The querying user does not have SELECT rights on the table.

    Solution: Grant SELECT explicitly; Data Redaction doesn’t override access controls.

  • Policy not created or compiled: Invalid column name or datatype for chosen redaction type.

    Solution: Verify data types (for example, regex and partial redaction apply only to character columns).

  • Policy missing after migration or import.

    Solution: Policies are metadata objects — confirm they exist in DBA_REDACT_POLICIES post-migration. If not, reapply them from deployment scripts.

How do I diagnose “redaction not applying” (session context, exemption, policy conditions, view rewrite, etc.)?

Step-by-step checks:

  1. Check exemption privilege: Run SELECT * FROM USER_SYS_PRIVS WHERE PRIVILEGE='EXEMPT REDACTION POLICY'; if granted, redaction is bypassed.
  2. Verify policy state: Query DBA_REDACT_POLICIES to confirm the policy is enabled and attached to the correct column.
  3. Evaluate predicate logic: Test your policy expression manually: SELECT SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') FROM DUAL; If the condition evaluates to false, redaction won’t apply.
  4. Check view layers: Redaction is applied to the protected column even when it is used in an expression, for example, in a view. If data appears unredacted, verify that the view isn’t actually sourcing the data from a different, non-redacted column or table.
  5. Session context alignment: Ensure that application sessions correctly set expected context values (e.g., CLIENT_IDENTIFIER, MODULE, IP_ADDRESS).
  6. Test direct SQL access: Run a direct query (e.g., from SQL*Plus) using the same credentials to confirm if the issue is application context or user privilege related.
  7. Audit and logs: Use Unified Auditing or FGA to verify that queries reached the target object and whether conditions triggered.

Tip:

Most “redaction not applying” cases trace back to either session context mismatch or an exempt privilege inadvertently granted through a role.