![]() |
1
2
我个人希望等待它结束,除非我认为它没有机会完成这周,在这个阶段的回滚可能需要远远超过查询到目前为止的时间。如果它是一个生产服务器,我真的不会选择选项2并杀死它,除非我必须这么做。 在恢复某些控制/工作系统方面,如果您有合适的备份,请使另一个数据库联机以恢复备份/tlog备份,但您不希望在事务启动时恢复到更高的状态(或者它仍然需要回滚)。这至少为您提供了一个可以继续开发人员工作的系统,但不太可能是生产系统的理想状态。 如果它是一个生产服务器,那么在执行之前,请与个人就测试查询和查询计划的适用性发表一些好话。我相信许多DBA可以建议不那么礼貌的教学方法:) |
![]() |
2
2
所以我们厌倦了等待交易完成 一块SQL,谁不会呢?)因为它干扰了我们的后援 过程中,我们认为杀戮是一种必要的邪恶。 数据库开始回滚事务。 5天过去了。 我们注意到互联网上其他地方的一些帖子 重新启动数据库时发生,事务将“消失”, 虽然这些通常都被揭穿了*,但这毫无意义,我们认为 没有什么可以失去的,所以我们试了一下。我们知道数据库会进入 恢复模式,但是数据库变得越来越不正常 要运行除当前回滚工作以外的任何操作,我们已经看到了SQL Server在占用系统资源和不将它们转移到它需要做的工作的地方方面的错误行为。 (*我们也知道足够多的数据库理论,知道数据库不仅仅是“忘记” 关于一个正在进行的事务,但是我们也看到堆栈转储在 SQL Server错误记录了哪种情况告诉我们SQL Server正在获取 对于不得不承担的回滚量越来越不满) 所以我们重新启动了数据库。 果然,数据库进入了恢复模式。但是,SQL Server事件日志 现在每20秒左右给我们一次更新 总的来说,从日志消息算起大约有25个小时,但结果是 就一个半小时(!). 我强烈怀疑这种恢复/回滚方法是否更快 SQL Server必须像以前一样执行相同级别的工作来释放事务),但是它确实在一个半小时内完成,不管怎样,我不想养成在回滚一半时重新启动生产数据库的习惯。事件日志中的更新消息是绝对的godsend,就像任何编写过批处理程序的人一样。 会告诉你的;不管结果多么不准确——至少是最坏的情况。 因为我们是唯一两个使用这个生产箱的人,所以选择 将数据库发送到对我们有用的恢复模式,并向我们提供 无法访问以前的回滚状态(或至少无法访问任何内容) 在缺乏DBA技能的情况下进行解释)。我建议以后做这个吗? ……当然不是,不过,希望有关各方已经吸取教训,以及 我们可以向董事会索要一些钱来购买合适的开发服务器!(Epic Joel测试失败!) |