你总是为每个数据库设置哪些SQL Server警报？无论数据库如何，你总是监视什么？
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
- Nick Kavadias
1
我还在tempdb上设置了9002。 - SqlSandwiches
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。
更多信息请参见http://www.sqlservercentral.com/articles/Memory+Corruption/93424/和http://www.sqlskills.com/BLOGS/PAUL/post/Dont-confuse-error-823-and-error-832.aspx。
- yoel halb
0
无论使用哪种数据库，您总是会监视什么？
我们总是为所有服务器打开硬件警报，除了日志警报。硬件错误（例如inode错误）可能会像5xx错误一样迅速使服务器崩溃。例如，当服务器上的代码未能删除旧的导出文件时，填满磁盘空间直到导出完全失败，我们曾经看到客户的PDF导出功能失败。常规日志警报在事情已经太晚之前不会警告您这些问题。但是监视磁盘空间可以解决这个问题。
不幸的是，日志管理解决方案不会自动为您设置这些警报，因此有时您会发现需要警报的方式很艰难：当您已经遇到问题时。
我们撰写了一篇关于为什么重要的配对硬件度量警报与标准日志警报的博客文章：https://blog.bluematador.com/posts/how-essential-alerts-could-have-saved-the-millennium-falcon/
我们总是为所有服务器打开硬件警报，除了日志警报。硬件错误（例如inode错误）可能会像5xx错误一样迅速使服务器崩溃。例如，当服务器上的代码未能删除旧的导出文件时，填满磁盘空间直到导出完全失败，我们曾经看到客户的PDF导出功能失败。常规日志警报在事情已经太晚之前不会警告您这些问题。但是监视磁盘空间可以解决这个问题。
不幸的是，日志管理解决方案不会自动为您设置这些警报，因此有时您会发现需要警报的方式很艰难：当您已经遇到问题时。
我们撰写了一篇关于为什么重要的配对硬件度量警报与标准日志警报的博客文章：https://blog.bluematador.com/posts/how-essential-alerts-could-have-saved-the-millennium-falcon/
- Blue Matador
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接