DBMS_REDACT.ADD_POLICY加不上策略的根本原因是权限不足或对象状态不合法：必须由表所有者或具备EXP_FULL_DATABASE+IMP_FULL_DATABASE角色的用户执行，目标表不能是临时表、外部表或全局临时表，且需显式授予SELECT权限。
DBMS_REDACT.ADD_POLICY 为什么加不上策略？
常见现象是执行 dbms_redact.add_policy 后查 redaction_policies 视图为空，或查询敏感字段时数据完全没遮盖。根本原因不是语法错，而是权限和对象状态没到位。
- 必须用表所有者（或具备
EXP_FULL_DATABASE+IMP_FULL_DATABASE角色）执行，SELECT_CATALOG_ROLE不够 - 目标表不能是临时表、外部表或全局临时表；分区表支持，但需确保策略作用在基表而非分区子对象
- 若表含虚拟列或基于函数的索引，某些遮盖类型（如
DBMS_REDACT.RANDOM）可能报ORA-44305: redaction policy cannot be applied - 执行前确认
SELECT权限已显式授予——即使有SELECT ANY TABLE，也建议用GRANT SELECT ON schema.table TO user显式授权
DBMS_REDACT.FULL 和 DBMS_REDACT.PARTIAL 遮盖效果差异在哪？
选错类型会导致脱敏“过头”或“漏掉”，尤其对字符串和日期字段。核心区别不在长度，而在 Oracle 内部如何解析值和应用掩码逻辑。
-
DBMS_REDACT.FULL：无视原始格式，统一替换成固定字符（如*或#），适用于身份证号、手机号全字段屏蔽 -
DBMS_REDACT.PARTIAL：必须配function_type和function_parameters，比如遮手机号中间四位：'VVVVVVFVVVV'中V表示保留，F表示替换为*；注意参数顺序严格，少一个逗号就报ORA-44312: invalid function parameters - 日期字段用
PARTIAL很容易翻车：Oracle 把DATE当作YYYY-MM-DD HH24:MI:SS字符串处理，若参数写成'VVVV-VV-VV'，实际会遮年份后四位，而非你预期的“只留年份”
动态策略不生效？检查 REDACTION_POLICIES 视图里的 ENABLED 和 EXPRESSION 字段
策略加了≠生效。真正控制开关的是 ENABLED 列，而是否按条件触发取决于 EXPRESSION 写得对不对——它不是 SQL WHERE，而是 PL/SQL 布尔表达式。
-
ENABLED值必须是'Y'（不是1、TRUE或空格），改完记得EXEC DBMS_REDACT.ENABLE_POLICY(...) -
EXPRESSION里不能用子查询或绑定变量，只能是确定性函数+字段引用，例如'SYS_CONTEXT(''USERENV'', ''SESSION_USER'') != ''ADMIN'''；写成'USER != ''ADMIN'''会静默失败 - 测试时别只用
SELECT *，要明确查被遮盖字段，否则 Oracle 可能跳过重写逻辑；且必须用非 owner 用户连接，owner 查永远不遮
DBMS_REDACT.DROP_POLICY 后数据还是被遮？
删策略后 SELECT 仍返回 ***，大概率是缓存或残留策略没清干净。Oracle 的策略元数据和结果缓存是分离的。
- 先确认删的是对的策略名：
SELECT POLICY_NAME, OBJECT_SCHEMA, OBJECT_NAME FROM REDACTION_POLICIES，别手误删错 schema 下同名策略 - 执行
DBMS_REDACT.DROP_POLICY后，立即查V$SQL看是否有含该表名的硬解析语句还在内存里，有则ALTER SYSTEM FLUSH SHARED_POOL（生产慎用） - 更稳妥的方式是先
DBMS_REDACT.DISABLE_POLICY，观察半天无异常再删；若已删但仍有遮盖，检查是否其他用户在同表上建了同名策略（策略名只要在 schema 内唯一，跨 schema 可重名）
最易忽略的一点：DBMS_REDACT 对 LOB 字段默认不生效，哪怕你指定了列。真要遮 CLOB，得先转成 VARCHAR2 截断，或者用视图+虚拟列绕过去——这点文档里藏得很深，出问题时很少人往这想。
