FGA仅审计SELECT对显式引用列的物理读取，INSERT/UPDATE/DELETE不记录；audit_column须严格大小写、显式列出列名（如'SALARY,SSN'），非通配；未进审计表主因是优化器未实际读取该列，需全表扫描等路径触发。
fga 只能捕获 select 对特定列的访问，且必须实际读取到那些列——insert/update/delete 一律不记录，这不是配置错误，是 oracle 的硬性限制。
DBMS_FGA.ADD_POLICY 的 audit_column 怎么写才触发审计
audit_column 不是过滤器，而是“触发开关”：只要 SELECT 语句显式引用了其中任一列，策略就激活。
-
audit_column必须严格匹配表定义中的大小写，比如列名是SALARY，写成salary就不生效 - 支持逗号分隔多个列：
'SALARY,SSN,ID_NUMBER'，访问任意一个即触发 - 不能留空或传
NULL：Oracle 不报错，但策略根本不会加载（查DBA_AUDIT_POLICIES为空） - 不支持通配符：
'*'或'%'无效，想覆盖所有列，必须显式列出全部
为什么 SELECT 了却没进 DBA_FGA_AUDIT_TRAIL
最常见原因不是策略没建好，而是 Oracle 优化器根本没物理读取被审计列。
- 走非唯一索引范围扫描（如
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
统一审计启用后 FGA 日志去哪了
如果数据库启用了统一审计（UNIFIED_AUDIT_TRAIL 可查），FGA 审计记录默认写入 UNIFIED_AUDIT_TRAIL，而不是 DBA_FGA_AUDIT_TRAIL。
-
DBA_FGA_AUDIT_TRAIL在统一审计启用后可能始终为空，这不是失败，是日志归集方式变了 - 查日志请改用：
SELECT * FROM UNIFIED_AUDIT_TRAIL WHERE POLICY_NAME = 'YOUR_POLICY_NAME' - 注意权限：查询
UNIFIED_AUDIT_TRAIL需要SELECT ANY DICTIONARY或READ UNIFIED AUDIT TRAIL - 若仍无记录，先确认是否真启用了统一审计：
SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing'返回TRUE，且SELECT * FROM UNIFIED_AUDIT_TRAIL WHERE ROWNUM = 1不报ORA-00942
删不掉 FGA 策略的常见卡点
DBMS_FGA.DROP_POLICY 静默失败或报 ORA-28113，往往不是权限问题，而是参数没对齐。
- 必须传入建策略时的完整
object_schema，不能只靠policy_name—— 同名策略可能存在于不同 schema - 删之前先确认存在：
SELECT * FROM DBA_AUDIT_POLICIES WHERE POLICY_NAME = 'MY_POLICY' - 策略可能正被其他会话引用，可尝试重启会话再删，或检查是否有长事务未提交
- 删除后立刻查
DBA_AUDIT_POLICIES确认消失，别只信 PL/SQL 块返回“成功”
真正难的不是写对那几行 DBMS_FGA.ADD_POLICY，而是理解 Oracle 什么时候“算作访问了列”——它取决于执行计划，而不是 SQL 表面写了什么。很多空白日志，根源都在优化器绕开了你盯住的那几列。
