fga的教训
这是一个教训，记录下来

一个简单的需求，监测一个表记录不明被删除的原因
同事使用audit，但是terminial的记录皆为UNKNOWN，而且无法直接看出是哪条SQL作出的删除

很直接的想到了FGA
毕竟容易实现，而且不需要重启instance

使用之后侦查到许多删除操作，其中许多怀疑是STREAMS的操作，这个暂时不管
然后继续让他监测

问题出现了，到了晚上，monitor报出system tablespace 使用率很高
看到FGA$，FGA_LOG$都只有10m左右大小
但是有两个SYS_LOB的表大概共有2G大小，表内数据皆为FGA审计结果
先drop掉了police

begin
  dbms_fga.add_policy
  (
    object_schema=>'EDMS',
    object_name=>'T_AUDIT_DEMO',
    policy_name=>'T_AUDIT_DEMO_AUDIT'
  );
end;

然后

TRUNCATE TABLE fga_log$;

空间马上释放了

教训：
1.新特性不要直接使用在生产环境
2.新功能上线后观察一段时间
3.还是要多看文档

另，
FGA对比于一般的AUDIT：
1.不需要重启instance
2.可以灵活的disable，而且drop police并不影响之前的原数据

http://www.oracle.com/technology/global/cn/oramag/webcolumns/2003/techarticles/nanda_fga.html

http://www.oracle.com/technology/global/cn/pub/articles/nanda_fga_pt2.html

http://www.oracle.com/technology/global/cn/pub/articles/nanda_fga_pt3.html