我需要一些有关在 Oracle 中进行审计的帮助。我们有一个包含许多表的数据库，我们希望能够审计对任何字段中的任何表所做的每一次更改。所以我们希望在这次审计中拥有的东西是：
所以我们开始创建触发器，该触发器应该对任何表执行审计，但随后出现问题...
正如我之前提到的，我们有这么多表，我们不能为每个表创建一个触发器。所以这个想法是创建一个主触发器，它可以为任何触发触发器的表动态地运行。我正在尝试这样做，但一点也不走运……似乎 Oracle 仅针对由代码声明的表限制了触发环境，而不是像我们想要的那样动态地这样做。
您对如何执行此操作或任何其他解决此问题的建议有任何想法吗？
【问题讨论】：
标签： oracle triggers audit auditing
如果您有 10g 企业版，您应该查看 Oracle 的Fine-Grained Auditing。这绝对比自己滚动要好。
但是，如果您有一个较小的版本，或者由于某种原因 FGA 不符合您的口味，这里是如何做到的。关键是：为每个应用程序表构建一个单独的审计表。
我知道这不是您想听到的，因为它与您上面概述的表结构不匹配。但是为受更新影响的每一列存储一个包含 OLD 和 NEW 值的行是一个非常糟糕的主意：
因此，每个应用程序表都有一个审计表，具有相同的结构。这意味着在应用程序表中包含 CHANGED_TIMESTAMP 和 CHANGED_USER，但这并不是一件坏事。
最后，您知道这会导致什么结果，在每个表上设置一个触发器，该触发器将仅包含 :NEW 值的整条记录插入到审计表中。触发器应在 INSERT 和 UPDATE 上触发。这给出了完整的历史记录，很容易区分记录的两个版本。对于 DELETE，您将插入仅填充主键而所有其他列为空的审计记录。
你的反对意见是你有太多的表和太多的列来实现所有这些对象。但是从数据字典（user_tables、user_tab_columns）生成表并触发 DDL 语句已经足够简单了。
【讨论】：
您不需要编写自己的触发器。
Oracle 提供灵活且细粒度的审计跟踪服务。看看this document (9i) 作为起点。 （编辑：这是同一文档的10g 和11g 版本的链接。）
您可以审计太多，以至于它可以是like drinking from the firehose - 这可能会在某些时候损害服务器性能，或者可能会给您留下太多审计信息，以至于您无法快速从中提取有意义的信息, 和/或您最终可能会占用大量磁盘空间。花一些时间考虑您真正需要多少审计信息，以及可能需要保留多长时间。为此，可能需要从基本配置开始，然后在您能够获得实际收集的审计跟踪数据量的样本后对其进行调整。
【讨论】：