错误记录各种问题

Question

我正在慢慢收集并尝试分析有关我们所有实例 (2008R2 SP1) 的大量信息。我现在正在查看错误日志，我有几个问题。有很多关于错误日志大小的内容，并发现了不同的建议，sp_cycle_errorlog例如每周循环使用日志，以避免出现非常大的错误日志并能够充分处理它们。所以...

1. 当错误日志被认为是“大”的？我们的一些日志需要很长时间才能加载，接近一百万行。编辑：一个有 2 034 546 行
2. 我试图找到一些 tsql 来获取错误日志大小，但找不到它，有可能做到吗？
3. 我看到建议回收日志并配置不仅仅是默认数量 6。一些作者推荐 50，其他人 10。我想这取决于环境，但是有推荐的数量吗？

Answer 1

当错误日志被认为是“大”的？我们的一些日志需要很长时间才能加载，接近一百万行。

这在某些情况下会有所不同，但根据您的描述（“我们的某些日志需要很长时间才能加载”），这就是我对 big的定义。当文件操作（复制、移动等）开始花费比即时更长的时间，或者解析单个错误日志成为实际时间消耗者时，那时我将开始定期循环我的错误日志以保持这一点缩小尺寸。我知道我不会给你一个“ X MB是一个错误日志文件太大”的声明，但希望这能给你洞察力。除了极端异常和极端情况之外，错误日志大小不应该成为故障排除的痛点。

我试图找到一些 tsql 来获取错误日志大小，但找不到它，有可能做到吗？

就 T-SQL 而言，除了对 的调用之外xp_cmdshell，我想不出获得此方法的方法。因为我不会为这种类型的操作打开那个安全漏洞，我的建议是使用 PowerShell，消耗 SMO：

$SqlServer = New-Object Microsoft.SqlServer.Management.Smo.Server("YOUR_SQL_SERVER_NAME")

$SqlServer.EnumErrorLogs() |
    Select-Object Name, @{Name = "SizeMB"; Expression = {[System.Math]::Round($_.Size/1024/1024,2)}}

我看到建议回收日志并配置不仅仅是默认数量 6。一些作者推荐 50，其他人 10。我想这取决于环境，但是有推荐的数量吗？

没有什么比由于翻转而没有历史数据更糟糕的了，无论故障排除的来源是什么（SQL Server 错误日志、XEvents 日志等）。您需要真正了解您的骑行时间表，然后确定要保留多少天。这可能因服务器而异。在这里很难给出默认的保留值，因为有很多不同的因素，例如可用硬盘空间、24 小时内的平均错误日志生成大小（正常情况）、您关心日志返回多远，以及其他几个。如果您的磁盘空间有一个舒适的缓冲区（在计划存储消耗时总是需要一个缓冲区），我个人喜欢在太多存档的错误日志方面犯错。保守的赌注是保留期限为 4 周，但同样有太多因素无法仅基于此制定硬性规定。不过，这确实是您需要做出的决定。作为一个DBA和疑难解答，多远后面你想你的错误日志去？

旁注：我在您的原始问题中看到您引用了sp_cycle_agent_errorlog。在我看来，您的问题可能更适合实例的错误日志循环，在这种情况下，它将是sp_cycle_errorlog存储过程。