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.