dbms_fga.add_policy 审计表修改

SD.SYS_PARAMETER表的修改操作，执行如下语句配置FGA捕获策略：

dbms_fga.add_policy(object_schema=>'SD',object_name=>'SYS_PARAMETER',policy_name=>'SYS_PARAMETER',enable=>TRUE,statement_types=>'INSERT,

UPDATE, DELETE');

不出五分钟就有结果了

col timestamp format a30

col sql_text format a70

col userhost format a15

set linesize 180

select timestamp,sql_text,userhost,instance_number from dba_fga_audit_trail where object_name='SYS_PARAMETER' and timestamp > to_date('20160505

00:00:00','yyyymmdd hh24:mi:ss');

图7

很有规律的每30秒update一次，来自于实例1。既然update的频率是30秒一次，select语句遇到的gc cr block busy、gc buffer busy acquire等待事件

也应该是每隔30秒出现一波，但现实却是分分秒秒都有这两种等待，以下是从v$active_session_history统计出来的信息：

?  找到生产环境里update后没有及时commit的证据

dba_fga_audit_trail视图有一列SQL_BIND会记录语句执行时的绑定变量信息：

col timestamp format a30

col sql_text format a70

col sql_bind format a50

col userhost format a15

set linesize 180

select timestamp,sql_text,sql_bind from dba_fga_audit_trail where object_name='SYS_PARAMETER' and timestamp >

to_date('20160505 00:00:00','yyyymmdd hh24:mi:ss');

图11

拿上图的第一行来讲在20160505 09:54:08时刻，将绑定变量代入得到完整的update语句是：

update SD.SYS_PARAMETER set PARAM_VALUE ='2016-05-06 09:54:03'  where PARAM_CODE='CA_VCSMS_TIME';

所以最简单的方法就是实时监控dba_fga_audit_trail，每当观察到dba_fga_audit_trail视图新进来一条被审计到的SQL及其对应的绑定变量后，立刻执

行select param_value from sd.sys_parameter where param_code='CA_VCSMS_TIME'，来观察param_value字段何时变成绑定变量的值，如果一直没有变

化，那就证明没有提交，通过这个方法，我们发现commit操作果然是在update之后的30秒才执行的，准确的说应该是在下一条update开始之前commit

前一条update的修改结果。