在这个博客中，我从将审计事件放入审计数据库的角度讨论了sapbi平台的审计性能。我将与您分享如何深入了解任何延迟，以及如何提高性能并可能显著减小审核数据库的大小。我还解释了如何提问"用户添加或删除了哪些组？"

深入了解审计性能

我的审计领域解决方案提供了一个文档（SYS2–System–将事件记录到审计数据库的延迟），hadoop大数据，该文档为您提供了对此延迟的分析见解：

图表显示了随时间的延迟。在本例中，时间以小时和"一个月中的一天"表示，如何用大数据，这意味着所有的月份和年份都是聚合的。您可以清楚地看到每月的某些时间出现延迟。

我们可以看到蓝线显示了最大延迟，云服务器是什么，因此在该系统上，所有事件都需要3天才能到达审计数据库。

使用SAP BI平台4.2，性能得到了显著改进。这意味着如果您以前遇到过延迟，那么更新到BI4.2应该会有很大的改进。欢迎您的反馈，请发表评论（版本，您已启用的审核设置，物联网的应用有哪些，RDBMS，延迟评论）

在一些罕见的情况下，您可能会觉得有必要禁用审核。我们真的希望不再是这样，尤其是BI4.2之后。再次，欢迎您的意见。

如何提高审计绩效？

如果您选择了中央管理控制台审核选项"用户组详细信息"，则会为每个事件捕获用户所属的组。假设一个用户是200个用户组的成员，这并不罕见。然后，假设用户打开一个Web智能文档并刷新它，输入了10个提示的值。

现在，每个提示都是一个事件。因此，打开一个Web智能文档，回答10个提示并刷新它以显示一个页面的操作至少是12个事件，如果不是更多的话。对于每个事件，捕获200个用户组。这意味着审计数据库中存储了200个用户组x 12个事件=2400行数据。仅一个文档就有相当多的数据。

使用我的SYS2文档，您可以看到哪个BI平台服务器服务的数据进入审计数据库的延迟最长。几乎可以肯定，最严重的违规者是Web智能（假设您启用了"用户组详细信息"）。同样，欢迎评论。

提高审计性能并显著减小审计数据库大小

非常简单，如果您想提高性能并显著减小审计数据库的大小，然后您应该取消选择"用户组详细信息"选项：

我经常听说非常大的审核数据库，这些数据库在管理和查询时可能会有问题。

如果取消选择此选项，我会失去功能吗？

有一点，是的。您将无法筛选对审核数据库的任何查询，以按用户组对其进行限制。但是，您不会长时间丢失此功能。

在BI 4.2 Support Pack 5中，数据建模，我们计划即使未选择此选项，也将捕获用户组信息，但仅用于登录事件，以防止数据库中充满冗余和重复数据！这假设登录事件被选择为要审核的事件，如果没有选择，那么在BI4.2 SP5中，也不会捕获任何用户组。在登录时，为每个会话捕获一次用户组只会产生非常小的影响，而且比为每个事件捕获它要好得多！

这意味着从BI 4.2 SP5中，您将能够过滤对审计数据库的任何查询，以按用户组对其进行限制，从而消除我刚才提到的功能损失。您可以这样做，因为我们可以按用户组筛选登录事件，然后按这些登录事件中的会话ID筛选所有事件。

此外，无论您使用的是哪个BI 4.x版本，您可以使用my universe中预定义的业务筛选器通过用户组列表来限制查询：

此筛选器在universe业务层中定义为：

我们将会话ID筛选为仅与所选用户组列表对应的会话ID。因此，此筛选器将继续使用BI 4.2 SP5，并取消选择"用户组详细信息"选项。

添加/删除了哪些用户组？

无论您使用的是哪一个BI 4.x版本，您都可以运行查询，询问"添加或删除了哪些用户组"。查询过滤器需要如下所示：

如果您使用我的SYS1（事件日志）文档，结果如下：

属性名ADM\u ADD\u USERGROUPS\u TO\u USER对应的属性值显示组"Monitoring Users"和"Universe Designer Users"，其中用户"Administrator"将其添加到用户对象"Matthew"中。

反馈

我们非常希望得到您对执行审计（捕获审计事件）。请在这里分享任何经验教训，以利他人。您可能会取消选择我提到的选项，并看到了改进和减少的数据库大小。关于宇宙和查询时间性能的评论最好放在这个博客上，除非它们与我在这里提到的选项直接相关