10g审计能力的提升

Oracle 10g的审计会在非常细节的层次上捕捉用户的动作，它可以是手动审计、基于触发器审计。

假如用户A用以下语句更新了表里面得一条记录：

SQL> update SCOTT.EMP set salary = 12000 where empno = 123456;

你如何去跟踪这样的操作呢？在Oracle 9i中，审计只捕捉了谁做了操作，但不知道他做了什么？例如，它能让你知道A更新过用户scott的表emp，但是却无法知道他更新了工号为123456的员工的薪水信息。它同样在改变字段salary之前无法显示处它的值——要捕捉这样的信息，你只能通过编写自己的触发器来在值改变前捕捉它，或者通过使用Log Miner（日志挖掘器）从归档日志中找出来。

这两种方式都会让你付出较大代价来跟踪和记录数值的变化。使用触发器记录统计信息会造成很大的性能压力。处于性能考虑，在一些情况下（如在三层构架应用中）会禁止使用用户自定义的触发器。日志挖掘器不会产生性能问题，但它必须依赖于归档日志功能已经启动。

在Oracle 9i中出现的细密纹理审计（Fine-grained Auditing FGA），可以同SCN数重新构造老的数据来记录更低层次的变化，但是它只针对select查询，无法记录update、insert和delete这些DML语句。因此，在oracle 10g之前，使用触发器是唯一可以用来跟踪用户在低层次上做的数据操作的途径。

随着10g的带来了在审计方面的两个显著变化，这些限制将全都没有了。因为引入了两种类型的审计——标准审计（所有版本都有）和细密纹理审计（Oracle 9i和以上版本才具备）。我们分别来了解他们，看看它们如何通过互补来提供一个单一的、强大的跟踪能力。

新功能

首先，FGA现在提供了除select以为的DML审计。这些变化记录还是存储在同一个地方：FGA_LOG$，并且可以通过视图DBA_FGA_AUDIT_TRAIL查询到。除了DML语句外，你还可以选择使用触发器跟踪所有相关的字段或者只是其中的一小部分。

通过命令AUDIT执行的标准审计能够很容易的跟踪某个特殊对象。例如，你需要跟踪用户scott的表EMP上的所有更新操作，可以用以下命令：

SQL> AUDIT UPDATE on scott.emp BY ACCESS;

这一命令会在任意一个用户更新scott.emp表时记录在审计跟踪表AUD$中，并通过DBA_AUDIT_TRAIL视图可以查询。

这一功能在10g以前的版本中也有。但是在哪些版本中，写入的跟踪信息仅限于一小部分相关信息，如执行操作的用户，时间，终端ID等。而哪些修改的值这样的重要信息却没有记录。在10g中，除了以前版本记录的哪些信息以外，还记录了很多这种重要信息。审计的主要表AUD$增加了几个字段来记录这些信息，相应的的视图的DBA_AUDIT_TRAIL也增加了这些字段以便查询。让我们再深入了解一下。

EXTENDED_TIMESTAMP 这一字段用TMESTAMP(6)的格式记录了审计记录的时间戳，它以格林尼治时间（UTC）记录到了秒的第9位小数以后的时间以及相应的时区信息，下面时一个例子：

2004-3-13 18.10.13.123456000 -5:0

这意味着时间在美国东部标准时间2004年3月13日，时区比UTC完5个小时。这一扩展格式的时间在一个精确得多得精度上记录了审计跟踪时间，对于哪些数据库时间存在时区差得系统来说非常有用。

GLOBAL_UID和PROXY_SESSIONID 当要鉴别一个用于鉴权的管理组件如Oracle Internet Directory时，用户在数据库中可能以不同的形式可见。例如，他们可能作为一个企业用户鉴权进入数据库。审计这些用户时将无法在视图DBA_AUDIT_TRAIL的字段USERNAME中记录他们的企业userid，这样记录下来的信息是无用的。在Oracle 10g中，如果没有进一步的操作或设置，全局（或企业）用户会被唯一的记录在字段GLOBAL_UID中。这一字段可以被用于查询目录服务器以找出这个企业用户的完整信息。

有时候企业用户需要通过一个代理用户连接数据库，特别是在多点应用时。一个用户可以通过以下方式授予代理权限：

SQL> alter user scott grant connect to appuser;

这一命令将使用户scott可以最为appuser连接数据库，成为一个代理用户。在这一例子中，字段COMMENT_TEXT将通过存入值PROXY来记录下scott作为代理用户的情况。但在9i中，代理用户的会话ID不会记录下来。在10g中，字段PROXY_SESSIONID记录下来代理用户的session id。

INSTANCE_NUMBER 在Oracle RAC环境中，能够知道用户从哪个实例连上数据库会比较有用。在10G中，这个字段就记录了实例初始化参数设置的唯一的实例号。

OS_PROCESS 在9i及以下版本中，审计跟踪记录中只会记录SID，而不会记录操作系统的进程ID。但是操作系统进程ID对于以后对照trace文件是非常必要的。在10g中，这个字段就记录了操作系统进程id。

TRANSACTIONID 这是一个极其重要的信息。加入用户执行了以下语句：

SQL> update CLASS set size = 10 where class_id = 123;

SQL> commit;

这一操作产生了一个事务，并记录一条审计记录。但你如何知道记录中实际记录的是什么呢？如果这条记录是一个事务，这个字段就记录了事务的ID。你可以用它遇视图FLASHBACK_TRANSACTION_QUERY连接查询。下面就是一个例子：

SQL> select start_scn, start_timestamp,

2 commit_scn, commit_timestamp, undo_change#, row_id, undo_sql

3 from flashback_transaction_query

4 where xid = '';

除了哪些关于这个事务的统计信息，如undo change#、rowid等等，10g中还记录了回归事务变化的SQL语句在字段UNDO_SQL中，记录了回归影响的行的rowid在字段ROW_ID中。

System Change Number (SCN) 最后，来看下记录的变化前的数据。如何得到它呢。在9i的FGA中，这个数据可以通过闪回查询得到。但是你必须首先从审计记录的SCN字段中中得到System Change Number (SCN)。执行以下命令：

SQL> select size from class as of SCN 123456

2 where where class_id = 123;

这样可以得到变化前的数据了。

扩展DB审计

我们最想得到的是：捕捉在标准审计中没有记录的用户所执行的SQL语句和绑定的变量。通过设置一个参数可以进入10g的扩展审计，在参数文件中写入以下内容：

audit_trail = db_extended

这一设置激活了在相应字段中记录SQL语句和绑定的变量的值。在早期版本中是没有这一参数的。

什么时候需要触发器

避免错误 审计数据都是通过一个自治事务从源事务中从产生的。因此，及时源事务

已经回滚，它们还是会被提交。这有一个简单的例子来说明这一点。加入我们已经设定在表CLASS上审计UPDATE操作。一个用户执行一个SQL将SIZE数据从20更新到10，然后回滚事务，如下所示：

SQL> update class set size = 10 where class_id = 123;

SQL> rollback

现在字段SIZE的数据是20而不是10。尽管回归了，审计跟踪还是会捕捉到这些变化。在某些情况下，我们并不希望它这样做，特别是用户回滚了很多事务。在这种情况下，你就需要在CLASS表上建一个触发器捕捉仅事务提交时的变化。如果在表CLASS上有一个插入数据到用户定义的审计跟踪中的触发器，当回归时审计跟踪也会回滚。

捕捉变化前的数据 Oracle提供的审计跟踪没有记录变化前后的数据。例如。上面的变化会产生一条审计记录，记录下SQL语句和变化时的SCN数，但是没有变化前的数据（20）。这个数据可以通过使用SCN数从闪回查询中获取到，但是这依赖于必须能从回滚段中获取到相应信息。这些信息能否获取到就看参数undo_retention设置的大小了，如果在它设置的时间范围内，之前的数据就可以获取到。使用触发器捕捉这个值就不需要依赖遇这个参数的设定了，可以随时获取到变化前的值。

统一审计跟踪

由于FGA和标准审计捕捉的时类似类型的信息。他们可以共同提供很多十分有用的信息。Oracle 10g通过视图DBA_COMMON_AUDIT_TRAIL将这些跟踪信息统一成一个统一的跟踪信息。它是通过UNION ALL将视图DBA_AUDIT_TRAIL和DBA_FGA_AUDIT_TRAIL联合起来。但是这两个统计跟踪数据还是有很大的不同的。