我已经讨论了各种确定恢复状态的方法，但是本周我参与了一个围绕回滚的有趣讨论。交易已经运行了14个小时，然后发出了KILL SPID。SPID进入回滚，并发生2天和4小时。
自然的问题是为什么不14小时回滚？
没有一些具体的细节很难说，但如果原来的查询使用了并行工作，那么可能会完成超过14个小时的工作。例如，如果更新与4名工作人员同时运行，则可以完成56个工作小时或2.3天。回滚大多是单线程的，所以可能需要4倍的时间来完成回滚。另外，在执行过程中，预读通常更高效，因为计划是已知的，回滚必须在日志记录中工作，并且可能无法以相同的方式驱动缓冲区读取。
接下来的问题是：我应该重新启动SQL Server服务吗？这会更快吗？
通常情况下，它不会更快，因为您必须从开始事务再次开始恢复，并确定从何处开始修复数据库。这意味着大量的I / O，这次有一个冷藏缓存，可能没有其他访问数据库。
仍然认为恢复/回滚卡住了
如果您真的认为恢复或回滚应该已经完成，您可以发出以下T-SQL命令来捕获SQL Server进程的转储并将其提供给Microsoft SQL Server支持以供进一步分析。
dbcc traceon（-1，2546，2551）
dbcc stackdump（1）
dbcc traceoff（-1，2546，2551）
这将在LOG目录中生成一个.mdmp文件。继续允许恢复或回滚继续并与Microsoft SQL Server支持联系以获得进一步的帮助。
大日志文件
您还应该意识到，允许日志文件变大并生成大量的VLF可能会增加恢复时间。
如果正在恢复的数据库中有很多VLF（虚拟日志文件），则预恢复期间发生的发现阶段可能需要很长时间才能完成。DBCC LOGINFO（dbname）返回的行数将确认这是否可能。 在典型的问题情况下，这个查询将在120万个VLFS的困难情况下返回几千个。 即使没有要恢复的事务，也可能发生此问题。最好的解决办法是将日志文件缩小到非常小的值，确认VLF的数量少于100个，然后通过以较大增量扩展（或增长）来重新调整日志的大小。
