主页 / dba / 问题 / 269930
Accepted
Peter Å
Asked: 2020-06-27 01:21:58 +0800 CST

问题跟踪错误：带有扩展事件的 8623

  • 772

我们不时收到 SQL Server 错误：

错误：8623，严重性：16，状态：1 查询处理器用尽内部资源，无法生成查询计划。这是一个罕见的事件，仅适用于极其复杂的查询或引用大量表或分区的查询。请简化查询。如果您认为您错误地收到了此消息，请联系客户支持服务以获取更多信息。

为了能够捕获导致此错误的原因，我在 XE 事件 error_reported 上创建了一个扩展事件 (XE) 会话。XE 会话似乎正在工作，因为记录了其他错误，但没有记录 8623。

我的 XE 会话是这样创建的：

CREATE EVENT SESSION [ErrorReported] 
ON SERVER 
ADD EVENT sqlserver.error_reported(
    ACTION(sqlserver.database_id,sqlserver.database_name,sqlserver.sql_text,sqlserver.tsql_stack,sqlserver.username)
    WHERE ([severity]> 15))
ADD TARGET package0.event_file(SET filename=N'C:\trace\ErrorReported.xel',max_file_size=(250),max_rollover_files=(4))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=ON,STARTUP_STATE=OFF)
GO

任何帮助我让 XE 也记录错误 5623 的人吗？非常感谢任何帮助。

我们目前正在运行 Microsoft SQL Server 2016 (SP2-CU10)。

sql-server extended-events

2 个回答

  1. Best Answer

    感谢 MSDN 上的 Ronen Ariely 和 Jonathan Kehayias关于 SQL 性能的文章，我能够解决这个问题。问题是事件规模太大以至于它被丢弃了。您可以通过查询 sys.dm_xe_sessions 来检查这一点，例如

       SELECT
   s.name, 
   s.total_regular_buffers,
   s.regular_buffer_size,
   s.total_large_buffers,
   s.large_buffer_size,
   s.dropped_event_count,
   s.dropped_buffer_count,
   s.largest_event_dropped_size
FROM sys.dm_xe_sessions AS s;

    如果任何事件已被删除，您将在列 drop_event_count 中设置已删除事件的数量，并在最大事件删除_size 中设置任何已删除事件的最大大小。如果此值大于regular_buffer_size，则需要增加常规缓冲区大小。

    对我来说就是这种情况，当我将最大内存大小从默认值更改为 64MB 时，常规缓冲区大小增加了很多，以至于我能够捕捉到错误！

    作为旁注，有问题的查询是一个实体框架生成的带有巨大（> 38 000 个值）IN 子句的 SELECT！难怪数据库引擎够用了。

    • 2

  2. 非常感谢 Peter 就您的问题如何解决提供反馈。我处于同样的情况，每天晚上都会发生大量 8623 错误，但不知道是什么原因造成的。由于扩展事件失败，我尝试了跟踪但从未捕获到实际查询 - 只有错误消息和之前和之后的所有查询。多亏了您的信息，我现在有了继续的方法。不过必须是明天，因为我已经过了现在发生错误的时间......

    编辑：我检查了丢弃的缓冲区 - 没有。Gaaahh Edit2：也许他们没有显示，因为我删除了该事件。明天见

    • 0

相关问题