您总是为每个数据库设置哪些 SQL Server 警报？无论数据库如何，您始终监控什么？
Gern Blandston
问问题
12895 次
3 回答
11
您应该监控严重级别 17 到 25 并收到警报。
从 17 到 19 的严重级别需要 DBA 的干预，它们没有 20-25 严重，但需要提醒 DBA。
17 资源不足
18 检测到非致命内部错误
19 资源错误
这些严重错误意味着 SQL Server 不再工作
20 当前进程中的 SQL 错误
21 数据库 dbid 进程中的
SQL 致命错误 22 SQL 致命错误表完整性可疑
23 SQL 致命错误: 数据库完整性怀疑
24,25 硬件错误
有关严重级别的更多信息，请参阅http://msdn.microsoft.com/en-us/library/aa937483(SQL.80).aspx
于 2008-12-02T17:40:30.520 回答
1
我还会在错误 823、824 和 832 上添加警报，因为这些错误表明已损坏。
有关更多信息，请参阅http://www.sqlservercentral.com/articles/Memory+Corruption/93424/和http://www.sqlskills.com/BLOGS/PAUL/post/Dont-confuse-error-823-and-error -832.aspx
于 2012-11-08T16:14:02.237 回答
0
无论数据库如何，您始终监控什么？
除了日志警报之外，我们始终为所有服务器打开硬件警报。例如，硬件错误（例如 inode 错误）可以像 5xx 错误一样快速关闭服务器。当服务器上的代码无法删除旧的导出时，我们已经看到客户的 PDF 导出功能失败，从而填满了磁盘空间，直到导出完全失败。常规日志警报不会警告您这些事情，直到为时已晚。但是监控磁盘空间就得了。
不幸的是，日志管理解决方案不会自动为您设置这些警报，因此有时您会发现自己需要这些警报是很困难的：当您已经遇到问题时。
我们写了一篇关于为什么将硬件指标警报与标准日志警报配对很重要的博客文章：https ://blog.bluematador.com/posts/how-essential-alerts-could-have-saved-the-millennium-falcon/
于 2017-04-27T20:22:53.570 回答