为什么 SQL Server 中的一些高严重性错误消息没有记录到 Windows 事件日志中？

Question

我们正在运行 SQL Server 2016 企业版，我正在进行一些故障排除，以了解为什么我的警报不起作用（结果是有人在 SQL Server 启动中添加了 -n 参数）。在故障排除过程中，我注意到许多具有高严重性（> = 18）的内置消息未设置为记录到事件日志中。

use master;

select * from sys.messages 
where severity >= 18 and language_id = 1033 and is_event_logged = 0

消息ID	语言_id	严重程度	已记录事件	文本
21	1033	20	0	警告：致命错误 %d 于 %S_DATE 发生。请记下错误和时间，并联系您的系统管理员。
565	1033	18	0	编译查询时服务器中发生堆栈溢出。请简化查询。
613	1033	21	0	在数据库 %d 中找不到分区 ID 为 %I64d 的工作表行集条目。
669	1033	22	0	行对象不一致。请重新运行查询。
683	1033	22	0	尝试在可变长度和固定长度十进制格式之间进行转换时发生内部错误。运行 DBCC CHECKDB 以检查是否有任何数据库损坏。
684	1033	22	0	尝试在压缩和未压缩存储格式之间进行转换时发生内部错误。运行 DBCC CHECKDB 以检查是否有任何损坏。
685	1033	22	0	尝试检索堆转发记录的反向指针时发生内部错误。
686	1033	22	0	已达到行集 %I64d 的 B 树的最大级别。SQL Server 仅支持最多 255 个级别。
831	1033	20	0	无法取消分配保留的页面。

ETC。

据我了解，要使警报发挥作用，必须将消息记录到 Windows 应用程序事件日志中。我没有仔细查看所有这些消息，但许多消息似乎是您希望收到警报的类型，那么为什么所有这些消息（几乎有 100 条）都没有被记录下来呢？

Answer 1

基本上，is_event_logged 列中的值不可信。

我希望 SQL Server 在生成错误时能够盲目地遵循 sys.messages 中的值。但是，例如要删除日志中的“成功备份”消息，您必须使用跟踪标志 3226 启动 SQL Server，而不是在 sys.messages 中配置这些消息（使用 sp_altermessage）。

以错误 831 为例，它是列表中的错误之一。这表明错误 831确实已写入日志。

换句话说：我的猜测是，您列出的大多数严重消息确实是硬连线写入日志的，即使 sys.messages 说的是其他内容。

为了得出结论，我们必须重现每个错误并亲自查看。这些错误本质上很难重现。当然，我们可以建议 MS 与他们遵守 sys.messages 中 is_event_logged 的​​方式更加一致，但我有一种感觉，他们还有其他更高优先级的事情，我们只能忍受这一点。