使用 Microsoft 登录
登录或创建帐户。
你好,
使用其他帐户。
你有多个帐户
选择要登录的帐户。

症状

在 Microsoft SQL Server 启动期间,在完成数据库恢复且启用了客户端连接后,会立即注意到以下一个或多个症状。

症状1

你将在 SQL Server 错误日志中收到类似于以下内容的错误消息和声明:

2014-12-13 08:03:34.85 spid24s Using 'dbghelp.dll' version '4.0.5'2014-12-13 08:03:34.85 spid24s **Dump thread - spid = 0, EC = 0x0000000082274B202014-12-13 08:03:34.85 spid24s ***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\LOG\SQLDump0001.txt2014-12-13 08:03:34.85 spid24s * *******************************************************************************2014-12-13 08:03:34.85 spid24s *2014-12-13 08:03:34.85 spid24s * BEGIN STACK DUMP:2014-12-13 08:03:34.85 spid24s * 12/13/14 08:03:34 spid 242014-12-13 08:03:34.85 spid24s *2014-12-13 08:03:34.85 spid24s * Location: ghost.cpp:17422014-12-13 08:03:34.85 spid24s * Expression: tcln1 != NULL2014-12-13 08:03:34.85 spid24s * SPID: 242014-12-13 08:03:34.85 spid24s * Process ID: 354442014-12-13 08:03:34.85 spid24s *2014-12-13 08:03:35.47 spid24s Error: 17066, Severity: 16, State: 1.2014-12-13 08:03:35.47 spid24s SQL Server Assertion: File: <ghost.cpp>, line=1742 Failed Assertion = 'tcln1 != NULL'. 此错误可能与计时有关。 如果再次运行该语句后,该错误仍然存在,请使用 DBCC CHECKDB 检查数据库的结构完整性,或者重新启动服务器以确保内存中的数据结构未损坏。

症状2

你将在 SQL Server 错误日志中收到类似于以下内容的错误消息和异常:

2014-12-13 12:38: 30.25 spid51 使用 "dbghelp" 版本 "4.0.5" "" 30.25 spid51 * * * 将堆栈转储发送到 C:\Program Files\Microsoft SQL Server \ MSSQL10_50。 SQL2008R2\MSSQL\LOG\SQLDump0003.txt2014-12-13 12:38: 30.25 spid51 SqlDumpExceptionHandler: Process 51 生成了严重的异常 c0000005 EXCEPTION_ACCESS_VIOLATION。 SQL Server is terminating this process.2014-12-13 12:38:30.25 spid51 * *******************************************************************************2014-12-13 12:38:30.25 spid51 *2014-12-13 12:38:30.25 spid51 * BEGIN STACK DUMP:2014-12-13 12:38:30.25 spid51 * 12/13/14 12:38:30 spid 512014-12-13 12:38:30.25 spid51 *2014-12-13 12:38:30.25 spid51 *2014-12-13 12:38:30.25 spid51 * Exception Address = 000000000030D47C Module(sqlservr+00000000000FD47C)2014-12-13 12:38:30.25 spid51 * Exception Code = c0000005 EXCEPTION_ACCESS_VIOLATION2014-12-13 12:38:30.25 spid51 * Access Violation occurred reading address FFFFFFFFFFFFFFFF2014-12-13 12:38:30.25 spid51 * Input Buffer 54 bytes -2014-12-13 12:38:30.25 spid51 * exec usp_select12014-12-13 12:38:30.77 Server Error: 17310, Severity: 20, State: 1.2014-12-13 12:38:30.77 Server A user request from the session with SPID 51 generated a fatal exception. SQL Server 正在终止此会话。 通过在日志目录中生成的转储联系产品支持服务。访问冲突将具有下列调用堆栈: sqlservr!TaskGhostCleanup:: IsHashed + 0x8dsqlservr!TaskGhostCleanup::排队 + 0x32sqlservr!IndexRowScanner:: MoveToRowOnNextPage + 0x9csqlservr!IndexDataSetSession:: GetNextRowValuesInternal + 0x11cb

症状3

收到前面的症状部分所述的消息后,将在 SQL Server 错误日志中收到以下消息:

2014-12-13 08:04: 53.37 Server Process 0:0:0 (0x23c8)工作0x000000002880C1A0 似乎不会产生计划23。 线程创建时间:13062953007877。 大约使用线程 CPU:内核 0 ms,用户0毫秒。 流程利用率0%。 系统闲置88%。 时间间隔: 70013 ms. 2014-13 08:04: 53.37 Server Process 0:0:0 (0x71d8)工作0x000000002A8D21A0 似乎不会在计划程序30上生成。 线程创建时间:13062953007891。 大约使用线程 CPU:内核 0 ms,用户0毫秒。 流程利用率0%。 系统闲置88%。 Interval: 70013 ms.2014-12-13 08:04:53.38 Server ***Unable to get thread context for spid 02014-12-13 08:04:53.38 Server * *******************************************************************************2014-12-13 08:04:53.38 Server *2014-12-13 08:04:53.38 Server * BEGIN STACK DUMP:2014-12-13 08:04:53.38 Server * 12/13/14 08:04:53 spid 294882014-12-13 08:04:53.38 Server *2014-12-13 08:04:53.38 Server * Non-yielding Scheduler2014-12-13 08:04:53.38 Server *2014-12-13 08:04:53.38 Server * *******************************************************************************2014-12-13 08:04:53.38 Server Stack Signature for the dump is 0x00000000000003412014-12-13 08:04:55.43 Server External dump process return code 0x20000001. 外部转储过程未返回错误。 2014-12-13: 55.43 Server Process 0:0:0 (0x9358)工作0x0000000081CE41A0 似乎在计划程序4中不会产生任何问题。 线程创建时间:13062953009701。 大约使用线程 CPU:内核 0 ms,用户15毫秒。 流程利用率0%。 系统闲置88%。 间隔: 70011 ms。

此时 SQL Server 可能无法响应用户请求。 如果是这种情况,您必须重新启动该服务才能纠正这种情况。

原因

出现此问题的原因是,在此过程完全初始化之前,用户查询尝试使用幻影清理队列。

SQL Server 的每个新的累积更新均包含以前的累积更新中包含的所有修补程序和所有安全修补程序。 查看 SQL Server 的最新累积更新:

解决方法

若要解决此问题,请按照下列步骤操作:

  1. 将 -T669 配置为启动参数。 此跟踪标志可防止用户查询将请求排队到 ghost 清理进程。

  2. 设置 SQL Server 代理警报以在 SQL Msg 3408 上触发作业。 例如,设置以下通知:

    恢复完成。 这只是一条信息性消息。 无需用户操作。

  3. 在此作业内,运行 TSQL 脚本以等待5至10分钟,然后运行 DBCC TRACEOFF (669,-1) 命令。

此过程可确保此跟踪标志仅在 SQL Server 启动期间处于活动状态。 使用此跟踪标志不会影响后台幻影清理进程的正常运行。

状态

Microsoft 已确认这是 SQL Server 的问题,当前正在调查此问题的修补程序。 此知识库文章将随提供的其他信息一起更新。

参考

存储引擎内:在深度警报中 Ghost 清理 SP_ADD_ALERT (transact-sql)DBCC TRACEOFF (Transact-sql) DBCC (Transact-sql)跟踪标记数据库引擎启动选项

需要更多帮助?

需要更多选项?

了解订阅权益、浏览培训课程、了解如何保护设备等。

社区可帮助你提出和回答问题、提供反馈,并听取经验丰富专家的意见。

此信息是否有帮助?

你对语言质量的满意程度如何?
哪些因素影响了你的体验?
按“提交”即表示你的反馈将用于改进 Microsoft 产品和服务。 你的 IT 管理员将能够收集此数据。 隐私声明。

谢谢您的反馈!

×