FGA无需修改AUDIT_TRAIL参数或重启数据库即可审计特定列的DML操作；需显式指定audit_column、statement_types和audit_condition等参数，并注意策略绑定对象的物理性。
不需要改 AUDIT_TRAIL 参数、也不用重启数据库，就能对特定列的 SELECT、UPDATE 等操作留痕——FGA 的核心价值就在这里。但直接调用 DBMS_FGA.ADD_POLICY 时，稍不注意就会漏审计、错审计，甚至策略不生效。
只审计某几列的访问（比如敏感字段）
FGA 默认审计整张表所有列的访问，但业务常只要盯住 SSN、SALARY、ID_NUMBER 这类字段。这时必须显式指定 audit_column 参数，否则即使写了条件也白搭。
-
audit_column => 'SALARY'：仅当 SQL 中明确引用该列（如SELECT SALARY FROM emp或UPDATE emp SET SALARY = 10000）才触发审计 - 多个列用英文逗号分隔：
audit_column => 'SALARY,EMAIL'，注意**不能有空格** - 如果想审计“任意列被访问”，就别传这个参数，或设为
NULL；设成空字符串''反而会报错 -
audit_column_opts要配对使用：DBMS_FGA.ANY_COLUMNS表示只要访问了任一列就算，DBMS_FGA.ALL_COLUMNS表示必须全部列都被访问才审计（极少用）
让 INSERT/UPDATE/DELETE 也被捕获（不只是 SELECT）
Oracle 9i 默认只审计 SELECT，10g+ 虽支持全 DML，但不显式声明 statement_types，策略仍按老规则走——只记查，不记改删。
- 必须写全：
statement_types => 'SELECT,INSERT,UPDATE,DELETE'（大小写不敏感，但建议统一小写） - 只写
'UPDATE'就只审计更新，但要注意：如果语句里没显式出现被监控列（比如UPDATE emp SET NAME='a' WHERE ID=1，而你监控的是SALARY），这条 UPDATE 不会触发审计 -
TRUNCATE TABLE永远不会被 FGA 捕获，这是 Oracle 底层限制，别试 - DDL（如
ALTER TABLE）也不在 FGA 范围内，得靠标准审计或统一审计
按条件过滤审计（比如只审高权限用户或特定时间）
audit_condition 是布尔表达式，写在数据库上下文里执行，不是客户端逻辑。它决定“这条语句是否值得记”，而不是“要不要执行”。
- 例如只审计非 DBA 用户查薪资：
audit_condition => 'SYS_CONTEXT(''USERENV'', ''SESSION_USER'') != ''DBA''' - 注意引号嵌套：外层单引号，里面字符串再用两个单引号转义
- 不能用 PL/SQL 函数（如
TO_CHAR(SYSDATE)），只能用 SQL 内置函数和上下文变量 - 条件太复杂容易拖慢查询性能——每次访问都得求值，建议只用轻量判断（用户、IP、时间范围）
- 条件为
NULL或TRUE时等效于不限制；为FALSE则整个策略失效（但策略本身还在）
查不到审计记录？先确认这几个地方
DBA_FGA_AUDIT_TRAIL 查不到数据，90% 是策略没真正生效，而不是日志丢了。
- 用
SELECT * FROM DBA_AUDIT_POLICIES WHERE OBJECT_NAME = 'YOUR_TABLE'确认策略状态是ENABLED，不是DISABLED - 检查执行操作的用户是否有
SELECT_CATALOG_ROLE或SELECT ANY DICTIONARY——否则连DBA_FGA_AUDIT_TRAIL都查不了 - 确保操作是在策略创建后发生的；FGA 不追溯历史语句
- 验证语句是否真触达了监控列：运行
EXPLAIN PLAN看执行计划里有没有涉及audit_column对应的列 - 注意视图权限：如果审计的是视图底层表，策略必须建在基表上，建在视图上无效
最易忽略的一点：FGA 策略绑定的是对象（表/视图）的物理定义，不是逻辑访问路径。跨同义词、DB Link、物化视图的访问，除非策略明确定义在目标对象上，否则不会触发。别指望一个策略覆盖所有间接访问方式。
