【问题标题】:SQL Error log Time GapSQL 错误日志时间间隔
【发布时间】:2018-10-04 10:10:07
【问题描述】:

这个问题更多是针对 SQL 错误日志停止记录的可能原因。在我的场景中,检查系统/应用程序日志是否有任何崩溃或服务停止事件,一切都很清楚。 日志中的最后一个时间戳是上午 8:53,它立即跳到下午 6:50,接近 9 小时的差距,没有任何信息。报告的应用程序的数据库连接问题开始于下午 2:40 左右。Snippet

安全补丁已在前一天应用,服务器于早上 6:20 重新启动。 最终,SQL 服务重新启动以恢复连接。

我怀疑该补丁,但任何人都知道 SQL 服务器如何以及为什么会停止记录?

【问题讨论】:

  • 您想向软件开发人员询问什么?去试试serverfault.com,但你有什么期待?我们不知道您的系统是什么样的,我们对您的服务器没有任何见解或访问权限。
  • 您使用的是哪个DBMS product? “SQL”只是一种查询语言,而不是特定数据库产品的名称。请为您正在使用的数据库产品添加标签postgresqloraclesql-serverdb2、...
  • 感谢您的回复,其 SQL 数据库 @a_horse_with_no_name
  • “SQL”是一种查询语言,而不是数据库产品。每个关系数据库都是一个“SQL 数据库”

标签: sql error-log


【解决方案1】:

所以我有同样的问题,我的最后一个日志是从星期六开始的,直到我们在星期一重新启动它之前什么都没有。

我们还在周六应用了“使用 Windows 更新更新到 SQL Server 2016 SP1 累积更新 (CU) 8 KB4077064”

我遇到的最后一个错误是 “尝试刷新所有正在运行的扩展事件会话时出错。某些事件可能会丢失。”

【讨论】:

  • 很高兴知道我不是这里唯一的一个......我确实在 SQL 错误日志中看到了一些与 SSL 相关的错误,之后它就死了......不确定它有多相关。错误:17182,严重性:16,状态:1。错误:17826,严重性:18,状态:3。错误:17120,严重性:16,状态:1 在日志停止记录之前查看您是否已将其记录在错误日志中.
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-04-11
  • 1970-01-01
  • 1970-01-01
  • 2021-04-04
相关资源
最近更新 更多