在访问客户和在会议上进行有趣的谈话期间，我注意到在GDPR、SoX、HIPPA、MaRSIK或KRITIS等法规的推动下，安全性的话题正越来越成为焦点。除此之外，公司内部指导方针和官方数据保护指导方针也促进了这一领域需求的增长。

Db2审计工具是如何发挥作用的？

Db2提供的工具之一是db2audit工具，这个工具稍有不为人知，在SAP客户群中没有广泛使用。特别是性能影响和审计数据的范围可能会造成混乱和不确定性。

这就是为什么我要利用这个机会运行一些测试来评估db2audit对SAP数据库的影响，我想在这个博客中分享结果。

设置db2audit

在进入性能考虑之前，首先让我们澄清一下设置，因为可用的文档有点混乱。有两种不同的方法：实例级审计和数据库级审计

实例级审计是Db2提供的第一个审计版本。虽然它仍然存在，但如果您想审计SAP数据库，则稍后添加的数据库级审计通常是更好的选择。数据库级审计的侵入性较小，不需要在每次启动和停止Db2实例后显式启动。

要使用数据库级审计，只需使用db2audit命令设置活动审计日志和归档日志文件的目标，如下所示：

之后，请勿进一步使用db2audit命令。

相反，请创建db2audit策略并将其分配给要监视的对象：

在本例中，记录是在尝试访问或操作数据库对象或函数的授权检查期间创建的。这意味着您可以确定谁试图访问数据库中的任何表。

审核策略存储在数据库的系统目录中。因此，超级淘客，一旦数据库被激活，审计就会一直处于活动状态，并且不需要额外启动db2审计工具。

在保护和监视对数据库的访问的上下文中，总是有可能记录任何可能的内容。如果有人访问了某个对象，您可能还需要记录执行的SQL语句。这正是dbaudit类别"context"和"execute"所做的。类别"context"继承自初始db2audit设置。我建议您使用"execute"类别，就像我在进一步的测试中所做的那样。

我测试了什么和如何测试

我使用SAP HA测试工具生成的工作负载启动了一系列测试。这个工具最初设计用来模拟工作负载，这些工作负载可以用来验证像db2hadr这样的高可用性设置或集群软件的使用。我发现这个工具是合成基准测试驱动程序的一个很好的替代品，因为它的安装和设置只需几个小时。有关更多信息，请参阅blog Test Tool For High Availability Environments.

我的数据库没有针对基准测试进行优化或调优。我使用的Db2版本是db211.5.0.0。在3层设置中，应用服务器和数据库服务器都在Linux上运行。

作为基线，我运行了数据库工作负载，获得了每秒1480个对话框步骤的吞吐量。测试运行了大约5分钟。

在这之后，我启用了db2audit"所有你能得到的"实例级和数据库级审计以及类别"上下文"和"执行"启用：

5分钟的测试是一个很好的机会得到一些咖啡。我这样做了，回来的路上被耽搁了。当我回来的时候，我期望下一次考试能完成。令我惊讶的是，它还在运行。我查看了CPU数据，发现CPU空闲，但对一些磁盘的写操作很重。最后，返利手游，开始云，我得到了大约每秒70个对话步骤的吞吐量，因此只有基线的5%。

db2audit日志的异步写入

在确定了一些问题之后，我最终发现db2audit缓冲区被设置为零。查看sapnote1474404，我发现这不是一个好主意，因此我启用了Db2审计工具的异步写入，并使用以下命令将缓冲区设置为10.0004k页：

在这个更改之后，吞吐量提高到每秒1200个对话步骤。在没有任何审计的情况下不如基线，但比没有定义缓冲区的情况要好得多。但仍然有20%的影响是显著的。

使用审计缓冲区的权衡是，在数据库崩溃的情况下，可能会丢失审计记录。因此，最好使缓冲区尽可能小。好消息是，在我的测试中，只有100页的缓冲区最终的性能也与较大的1.000、5.000和5.000 4K页的缓冲区相同。这在其他工作负载更高的环境中可能会有所不同，但它很好地表明，最好从小处着手，只在需要时增加缓冲区。

减少性能影响

因此，在绕道审计缓冲区之后，计算机大数据，让我们回到不同类别对性能的影响。如果您仔细阅读有关不同类别的稀疏信息，您会发现类别"execute"和"context"对性能的影响最大。我的下一步是创建一个没有类别"context"和"execute"的策略，并在实例级别禁用"context"：

此设置以每秒1.440个对话步骤的吞吐量结束，在没有启用db2audit的情况下，这是基线测试序列吞吐量的97%。

我试图通过禁用更多类别来进一步优化性能，但结果基本相同，在测量精度的限制范围内。我还启用和禁用了"execute"和"context"的各种组合，但这没有提供任何进一步的见解。