SQL Server误区30日谈第1天正在运行的事务在服务器故障转移后继续执行(sql server错误和使用情况报告)

编辑：rootadmin

误区 #1：在服务器故障转移后，正在运行的事务继续执行这当然是错误的! 每次故障转移都伴随着某种形式的恢复。但是如果当正在执行的事务没有Commit时，由于服务器或实例崩溃导致连接断开，SQL Server可没有办法在故障转移后的服务器重新建立事务的上下文并继续执行事务-无论你使用的故障转移方式是集群，镜像，日志传送或是SAN复制。对于故障转移集群来说，当故障转移发生后，一个SQL Server实例在另一个故障转移集群的节点启动。所有实例上的数据库都要经历Recovery阶段-也就是所有没有Commit的事务都要被回滚。对于数据库镜像来说，来自主体服务器的日志不断传送到镜像服务器进行Redo操作。当镜像服务器被切换作为主体服务器时，原镜像服务器的事务日志将会变为Recovery模式，这使得好像原镜像服务器经历了一次崩溃那样，在这之后所有的连接都会导向原镜像服务器。对于事务日志传送来说，事务日志被定期备份并传送到辅助服务器.当主服务器崩溃时,DBA按照恢复顺序将辅助服务器恢复后上线.但最终步骤都是要执行recovery步骤，也就是将没有提交的事务进行回滚。对于SAN复制来说，本地SAN的I/O被复制到远程SAN上进行重放，当故障转移发生后,系统将会连接到远端SAN但数据库仍然需要执行recovery步骤，这和故障转移集群极其类似。 “唯一”使得正在执行的事务在故障转移发生后仍然得以继续执行的技术使用带有实时迁移功能的虚拟化技术，因为这时连接本身并不知道其连接的对象已经变为另一台物理服务器。但是无论使用那种技术，如果”连接”失效，正在执行的事务将会丢失，所以处理这类问题的这部分工作就需要在程序中用代码实现某种“重新执行”的功能。

推荐整理分享SQL Server误区30日谈第1天正在运行的事务在服务器故障转移后继续执行(sql server错误和使用情况报告)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:sql server错误和使用情况报告,sql server常规错误,sqlserver1053怎么解决,sql server 3417错误,sql server 错误,sql server 错误,sql server233错误,sql server 错误,内容如对您有帮助，希望把文章链接给更多的朋友！

SQL Server误区日谈第2天 DBCC CHECKDB会导致阻塞误区#2:DBCCCHECKDB会引起阻塞，因为这个命令默认会加锁这是错误的！在SQLServer7.0以及之前的版本中，DBCCCHECKDB命令的本质是C语言实现的一个不断嵌套循

SQL Server误区日谈第3天即时文件初始化特性可以在SQL Server中开启和关闭本系列文章是我在sqlskill.com的PAUL的博客看到的，很多误区都比较具有典型性和代表性，原文来自T-SQLTuesday#:Misconceptionsabout....EVERYTHING!!,经过我们团队

SQL Server误区日谈第4天 DDL触发器就是INSTEAD OF触发器误区#4:DDL触发器(SQLServer之后被引入)就是INSTEADOF触发器这是错误的DDL触发器的实现原理其实就是一个AFTER触发器。这个意思是先发生DDL操作，然后触

标签: sql server错误和使用情况报告

本文链接地址:https://www.jiuchutong.com/biancheng/347815.html 转载请保留说明！

上一篇：浅谈SQL Server中的三种物理连接操作(性能比较)(sql server的介绍)

下一篇：SQL Server误区30日谈第2天 DBCC CHECKDB会导致阻塞(sql server错误和使用情况报告)