审计 sql server 数据库中的记录更改答案

【问题标题】：Auditing record changes in sql server databases审计 sql server 数据库中的记录更改
【发布时间】：2011-07-16 13:45:33
【问题描述】：

如果您需要跟踪对数据库中记录所做的更改，您将使用哪种策略仅使用基于 microsoft 的技术（MS SQL Server、C#、EAB 等）？触发器，DAL 上的 AOP，其他？以及如何显示收集到的数据？有没有关于它的模式？是否有工具或框架可以帮助实现这种解决方案？

【问题讨论】：

标签： c# .net sql-server audit change-tracking

【解决方案1】：

变更数据捕获的问题在于它对于实际审计来说不够灵活。您无法添加所需的列。此外，默认情况下它每三天转储一次记录（您可以更改此设置，但我认为您不能永远存储），因此如果您需要保留数据，则必须将记录转储到真实的审计表中很长一段时间，这是典型的需要审计记录（我们从不转储审计记录）。

我更喜欢触发方法。编写触发器时必须小心，以确保在更改多条记录时它们将捕获数据。我们为每个审核的表准备了两张表，一张用于存储日期时间和执行操作的用户或进程的 ID，一张用于存储新旧数据。由于我们做了很多多记录过程，这对我们来说至关重要。如果有人报告了一条不良记录，我们希望能够查看是否是一个进行更改的过程，如果是，还有哪些其他记录也可能受到影响。

在您创建审计流程时，创建脚本以将一组审计数据恢复为旧值。如果您已经进行了设置，那么当您迫不及待地修复问题时，这样做会容易得多。

【讨论】：

如果我理解您实际上是在生产环境系统中使用这种方法，是吗？如果为真，那么触发方式在写入速度方面是否高效？
是的，我们在生产中使用。它是一个中等规模的数据库，对于用户所做的更改，它确实会减慢一点但不会太多（如果您正确编写了触发代码），它会减慢我们的批量导入（我们的批量导入设置为不避免触发) 更多，但用户不会注意到这一点。我们有规定这种方法的监管要求，变更数据捕获根本无法捕获我们需要的一切。我们也使用变更跟踪，但目的不同。
不会让我输入我认为是中等数据库的大小，但我们在 prod 中使用此过程的数据库约为 185 Gig，并且拥有数千名用户。

【解决方案2】：

Sql Server 2008 R2 有这个内置的 - 在线书籍中查找更改数据捕获

【讨论】：

太棒了！我会看看这个。

【解决方案3】：

这可能不是一个流行的观点，但无论如何我都会把它扔掉。

我更喜欢所有数据库写入的存储过程。如果需要审计，它就在存储过程中。代码之外没有什么神奇的事情发生，发生的一切都在写入发生时记录在案。

如果将来需要更改表，则必须转到存储过程进行更改。更新审核的需要记录在案。而且因为我们使用了存储过程，所以更简单地对表及其审计表进行“版本化”。

【讨论】：

这是一个坏主意（就像从应用程序中做同样的事情一样）您不能保证所有更改都将通过存储的过程（或应用程序），因此您的审核毫无用处。当由于某些客户更改而需要更新一百万条记录时，您是否认为他们会通过存储过程？您认为欺诈性更改记录的人会通过存储的过程吗？非常糟糕的选择，所有审计都必须在数据库级别完成。
在数据库方面没有任何保证。当然，您可以稍微支持一下，但永远没有任何方法可以阻止人们（包括未来的开发人员）做错事。如果您的应用程序始终使用 SP，则可以正常工作。
不，它不只是看起来这样做。在生产环境中，不超过 2 人应该能够更改触发器（dba 和备份 dba），因此您更有可能抓住任何进行未经授权的更改的人，而使用存储过程根本无法做到这一点。审核您提议的方式是非常危险的，并且没有数据库专家会允许在他们的系统上使用它。在 30 年中，我从未见过一个数据库有时不会在应用程序之外进行数据更改。
我想在这里留下这个答案，尽管投反对票，因为我认为它很有用。阅读@HLGEM 提出的反对意见也很有用。