标签: error-log

我目前在 Windows 2003 服务器机器上运行 SQL Server 2005 标准版。

我已经转到服务器的属性并确认登录审核设置为失败和成功登录。出于某种原因，当我知道两者都有登录时，SQL Server 日志中的登录失败或成功中没有任何内容。

我已经找到了原因，但没有提出任何有用的东西，所以我希望这里有人能给我一些指导。这适用于我的其他 SQL Server，所以我知道在哪里寻找结果，但那里没有。

刚刚从 SQL Server 2014 SP1 CU4 升级到 SQL Server 2016。

这是一个集群实例

我不再能够使用 xp_readerrorlog 和 xp_enumerrorlog

Msg 22004, Level 16, State 1, Line 10
Failed to open loopback connection. Please see event log for more information.
Msg 22004, Level 16, State 1, Line 10
Error log location not found.

找到此链接： 无法打开 SQL Server 日志

• 我可以通过文件资源管理器手动打开错误日志
• SQL Server 服务的启动参数指示错误日志的正确位置。
• 在实例上运行修复没有解决问题
• 为实例禁用共享内存并没有解决问题。
• 在所有这些问题和修复后重新启动没有帮助
• 没有别名用于连接到此实例
• 127.0.0.1 在主机文件中

基本上他们说要修复实例。

还有其他选择吗？

我有一个继承的 SQL Server 2016 安装。它不使用或配置 R 或机器学习。当它启动时，我在日志中看到这些消息：

InitializeExternalUserGroupSid 失败。隐式身份验证将被禁用。

隐含的身份验证管理器初始化失败。隐式身份验证将被禁用。

这些是正常的和预期的还是表明存在问题？

描述：SSPI 握手失败，错误代码为 0x8009030c，在建立具有集成安全性的连接时状态 14；连接已关闭。原因：AcceptSecurityContext 失败。Windows 错误代码指示失败的原因。[CLIENT: 10.XXX.XX.XX} ***不同场合客户端地址不同

我可以将此问题提交给我的网络管理员吗？这是网络问题还是sql server问题。除了更改注册表还有其他方法吗？我可以安全地忽略这个错误吗？

拥有一个 SQL Server 2017 Standard edition box，版本为 14.0.3045.24，带有一个内存优化表。当我们的第 3 方备份完成时，SQL Server 2017 错误日志显示了多条 [INFO] 消息，其中包含HKHostFreezeCkptTrimming()、HKHostBackupDeleteContext()、getMaxUnrecoverableCheckpointID()并具有相同的用户数据库 ID。你们中有人熟悉这些消息吗？这是一个错误还是有这些消息的修复程序？

其他测试表明这些 [INFO] 消息出现在完整、差异、事务日志和手动仅复制备份期间。性能很好，用户也没有抱怨，但考虑到所需的备份量，这些消息正在填满错误日志。

我能做些什么来限制这些消息在错误日志中的输入？或者这是处理额外消息的情况？

我有六个错误日志加上当前。他们在我的 VPS 服务器上占用了我硬盘上 10G 的磁盘空间。这大约是服务器空间的 25%。最大的文件是 6G 并且还在增长。

我如何删除不需要的错误日志并在回收之前减小存档文件的大小。

谢谢，

我发现 SQL Server 错误日志中记录了许多以下信息性消息（没有任何错误的批量消息）。

在队列“y”上运行的激活过程“x”输出以下内容：“z”

我想停止这种记录。是否有任何跟踪标志可以提供帮助？

我的环境有 2 台 Windows Server 2012 R2 服务器，均带有 SQL Server 2014 昂贵版本。

每当 AG 中发生更改（例如：在可用性副本“SecondaryReplicaThatIRestarted”上为主数据库“AGDatabase”建立与辅助数据库的 AlwaysOn 可用性组连接）时，我会在 SQL 错误日志中收到如下错误：

来源：SPID52s

消息
DbMgrPartnerCommitPolicy::SetSyncState:00000003BFC0B0E0:1

以这样的结果结束：

Imgur：错误日志的屏幕截图

编辑：

Windows 错误日志中没有任何内容，甚至没有提到的错误，这让我相信这是 SQL 内部的某些内容泄漏到错误日志中。

您知道这可能是由什么引起的吗？我已经设置了多个与此类似的设置，这是我第一次看到它。我计划本周将 SQL 修补到 SP1，但是我在发行说明中没有看到错误。

我们的一项工作失败了，但在我们调查时，工作历史已经过期。但是，我们可以看到在失败时创建了一个新的日志文件。

没有实例重启（检查 os_sys_info）或代理重启（在 sys.processes 中查看）并且没有人使用它知道如何循环日志。

一定是某种腐败吗？

我正在使用这个 sql 来获取我的错误日志位置：

EXEC xp_readerrorlog 0, 1, N'Logging SQL Server messages in file'

但是，有时我有非常大的日志文件（大约 1gb，我无法控制这些文件的循环）上面的查询需要大约 10 秒才能在这些大文件上运行，这太长了。

鉴于这段文本总是在文件的前几行，如果我能说“给我前 1 行然后停止阅读”就好了，但我认为 xp_readerrorlog 不支持这一点？

或者，如果我知道文件中第一行的日期，我可以指定一个日期范围，如下所示：

DECLARE @startDate DATETIME
DECLARE @endDate DATETIME
SET @startDate = '2016-01-28 12:00:00'
SET @endDate = DATEADD(mi, 5, @startDate)
EXEC xp_readerrorlog 0, 1, N'Logging SQL Server messages in file', NULL, @startDate, @endDate

哪个要快得多。但是，我不知道如何计算出这个日期——在许多情况下，它与实例进程的开始时间几乎相同（SELECT login_time FROM sysprocesses WHERE spid = 1但这不能保证）

我还尝试使用master..xp_instance_regread从 读取日志文件位置SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\Parameters，但这似乎并不总是准确的。

有没有人对我如何以有效的方式计算日志文件位置有任何建议，即使我的日志文件很大。