dbms_fga仅监控select且必须触达被审计列才触发，audit_column需准确填写大小写敏感的列名（如'salary,ssn'），空值导致策略加载失败，查询须走全表或唯一索引扫描才能生效。
dbms_fga 只能监控 select，且仅当查询实际触达被审计列时才触发——insert/update/delete 一律不记录，这是硬限制，不是配置问题。
DBMS_FGA.ADD_POLICY 的 audit_column 怎么写才生效
audit_column 参数决定“什么操作会触发审计”，它不是过滤条件，而是列名白名单。只要 SELECT 语句中显式引用了其中任一列（哪怕只是 SELECT name, salary FROM emp 中的 salary），策略就激活。
-
audit_column必须写准确列名，大小写敏感（如表定义是SALARY，就不能写salary） - 支持逗号分隔多个列：
'SALARY,SSN,ID_NUMBER'，访问任一即触发 - 不能留空或传
NULL：Oracle 不报错，但策略加载失败，DBA_AUDIT_POLICIES里查不到该策略 - 如果想覆盖所有列，仍需显式列出全部，不支持
'*'或通配符
为什么执行了 SELECT 却没进 DBA_FGA_AUDIT_TRAIL
最常见原因不是策略没建好，而是查询没“真正用到”被审计列——优化器绕过了它们。
- 走索引范围扫描（比如
WHERE name = 'SMITH'且name有非唯一索引）时，SALARY列没被物理读取，FGA 不触发 - 必须满足：全表扫描、索引唯一扫描、或索引快速全扫描（INDEX FAST FULL SCAN）才可能命中
- 测试务必用
SELECT salary FROM emp WHERE rownum = 1这类强制访问列的语句，别用SELECT * FROM emp WHERE name = 'X' - 确认
AUDIT_TRAIL参数不是NONE：SHOW PARAMETER audit_trail应返回DB或DB, EXTENDED
DBMS_FGA 对用户权限和环境的隐性要求
策略建得再准，权限或上下文不对，照样静默失效。
- 执行
DBMS_FGA.ADD_POLICY的用户必须有EXECUTE ON DBMS_FGA权限（通常需EXP_FULL_DATABASE或显式授权） - 被审计表的
SELECT权限必须存在：如果用户连查表都报ORA-00942，FGA 根本没机会介入 - 在 CDB/PDB 架构下，策略必须在目标 PDB 内执行，且
object_schema指的是该 PDB 内的 schema 名，不是 CDB$ROOT 的 - 若数据库启用了统一审计（
UNIFIED_AUDIT_TRAIL可查），FGA 日志默认写入UNIFIED_AUDIT_TRAIL而非DBA_FGA_AUDIT_TRAIL，后者可能为空
细粒度审计不是“开了就灵”的开关，它依赖查询路径、权限链路和审计后端配置三者对齐；最容易被忽略的是：你以为在查数据，Oracle 却用索引避开了被审计列——这时候日志空白，不是 bug，是设计使然。
