扩展事件捕获最少的事件以获得更好的性能答案

【问题标题】：Extended events capture bare minimum events for better performance扩展事件捕获最少的事件以获得更好的性能
【发布时间】：2020-06-10 12:09:25
【问题描述】：

我们有旧版应用程序，其中有很多用户连接到我们的旧版系统。我们了解我们的工作和数据库维护活动。但是，我们看到很多不同的用户也在访问生产系统。我们希望捕获最少量的扩展事件，以查看不同的第三方用户是什么以及他们正在运行哪些查询。

我们的扩展事件会话当前配置：

我们添加了以下事件。我们在服务器中为我们的数据库应用了过滤器。我们正在写入限制为 5 GB 的磁盘文件目标并回收文件，以避免文件系统膨胀。

module_end（附加事件字段：语句）
rpc_completed（附加事件字段：语句）
sql_batch_completed（附加事件字段：批处理文本）

我们正在捕获以下全局字段。

client_app_name
database_id
nt_username
sql 文本
用户名

但是，即使是上面的一个，对于生产系统来说也是压倒性的。所以，我们正在努力减少捕获量。

我们为最小化扩展事件捕获计划的更改：

除了数据库过滤器之外，应用过滤器从事件捕获中删除已知用户
只需捕获 rpc_completed、sql_batch_completed 事件
只需捕获client_app_name、database_id、username全局字段，因为我们可以从事件字段中获取sql语句：statement

我们的问题： 请建议，我们是否在最小配置模式下配置了扩展事件会话。或者您是否建议对活动会话进行更多更改。

感谢您的帮助。

更新：我们的修改脚本供参考

ALTER EVENT SESSION [Audit_UserActivities] ON SERVER 
DROP EVENT sqlserver.module_end, DROP EVENT sqlserver.rpc_completed, DROP EVENT sqlserver.sql_batch_completed
ALTER EVENT SESSION [Audit_UserActivities] ON SERVER 
ADD EVENT sqlserver.rpc_completed(
    ACTION(sqlserver.client_app_name,sqlserver.database_id,sqlserver.username)
    WHERE (([sqlserver].[like_i_sql_unicode_string]([sqlserver].[database_name],N'DBPrefix%')) OR (([sqlserver].[equal_i_sql_unicode_string]([sqlserver].[database_name],N'DBName')) AND ([sqlserver].[username]<>N'DBSysadminUser')))), ADD EVENT sqlserver.sql_batch_completed(SET collect_batch_text=(1)
    ACTION(sqlserver.client_app_name,sqlserver.database_id,sqlserver.username)
    WHERE (([sqlserver].[like_i_sql_unicode_string]([sqlserver].[database_name],N'DBPrefix%')) OR (([sqlserver].[equal_i_sql_unicode_string]([sqlserver].[database_name],N'DBName')) AND ([sqlserver].[username]<>N'DBSysadminUser'))))
GO

【问题讨论】：

添加 XE DDL 以及对您的问题提出的更改。您可以调整其他选项以减轻影响。
@DanGuzman，我已经用我们的扩展事件修改脚本更新了这个问题
我假设文件目标存在于您的 XE 实际会话中。您是否使用表值参数？捕获 TVP RPC 的一个已知问题是 fixed in SQL Server 2016+，但我相信它仍然存在于旧版本中，并且对于大型 TVP 来说非常昂贵。考虑指定更大的缓冲区大小（例如 MAX_MEMORY=100MB，取决于您的实例内存）以及 ALLOW_MULTIPLE_EVENT_LOSS 以减轻影响。
@DanGuzman，感谢您的回答。由于它是由我们团队接管的遗留系统，因此需要检查是否有 TVP 使用。我们将落实您的建议。除此之外，您是否预见到我们的配置有任何问题？
这些是我唯一的建议。除了 TVP，我很惊讶跟踪影响是显而易见的，除非服务器处于压力之下。

标签： performance sql-server-2012 extended-events lightweight-processes

【解决方案1】：

我不希望您问题中的扩展事件会话（带有文件目标）通常会对健康的服务器产生影响。不过，您还应该考虑其他一些因素来减轻影响。

捕获fixed in SQL Server 2016+ 的 TVP RPC 事件（包括 Azure SQL 数据库）存在一个已知问题。我相信这个问题在旧版本中仍然存在，并且对于大型 TVP 来说非常昂贵。您在 SQL Server 2012 中的解决办法是使用过滤器排除 TVP RPC 事件。

考虑指定更大的缓冲区大小（例如MAX_MEMORY=100MB，具体取决于您的实例内存）。还要指定ALLOW_MULTIPLE_EVENT_LOSS，以减轻跟踪高频事件对您的工作负载的影响，因为这种跟踪方案可以接受一些事件丢失。

【讨论】：