误区 #1：在服务器故障转移后，正在运行的事务继续执行

这当然是错误的!

每次故障转移都伴随着某种形式的恢复。但是如果当正在执行的事务没有Commit时，由于服务器或实例崩溃导致连接断开，SQL Server可没有办法在故障转移后的服务器重新建立事务的上下文并继续执行事务-无论你使用的故障转移方式是集群，镜像，日志传送或是SAN复制。

对于故障转移集群来说，当故障转移发生后，一个SQL Server实例在另一个故障转移集群的节点启动。所有实例上的数据库都要经历Recovery阶段-也就是所有没有Commit的事务都要被回滚。

对于数据库镜像来说，来自主体服务器的日志不断传送到镜像服务器进行Redo操作。当镜像服务器被切换作为主体服务器时，原镜像服务器的事务日志将会变为Recovery模式，这使得好像原镜像服务器经历了一次崩溃那样，在这之后所有的连接都会导向原镜像服务器。

对于事务日志传送来说，事务日志被定期备份并传送到辅助服务器.当主服务器崩溃时,DBA按照恢复顺序将辅助服务器恢复后上线.但最终步骤都是要执行recovery步骤，也就是将没有提交的事务进行回滚。

对于SAN复制来说，本地SAN的I/O被复制到远程SAN上进行重放，当故障转移发生后,系统将会连接到远端SAN但数据库仍然需要执行recovery步骤，这和故障转移集群极其类似。

“唯一”使得正在执行的事务在故障转移发生后仍然得以继续执行的技术使用带有实时迁移功能的虚拟化技术，因为这时连接本身并不知道其连接的对象已经变为另一台物理服务器。

但是无论使用那种技术，如果”连接”失效，正在执行的事务将会丢失，所以处理这类问题的这部分工作就需要在程序中用代码实现某种“重新执行”的功能。

更多相关文章

1. android获取正在运行的进程
2. 获取Android正在运行的任务和服务
3. Android遍历获取正在运行的服务（ActivityManager.RunningServiceI
4. Android(安卓)检测正在运行的service
5. Android学习笔记(九)之Android(安卓)获取正在运行的Activity
6. android开启线程的误区
7. android开启线程的误区
8. Android(安卓)新手常见的10个误区（下）
9. Android深入理解Context–Context使用的误区

随机推荐

1. Android(安卓)首选网络模式默认值的修改
2. android 中如何限制 EditText 最大输入字
3. android调用系统打电话功能
4. Android之Fastboot、Recovery基础知识
5. Android Studio第二十四期 - Gson封装Uti
6. Android工程 单元测试
7. Android(安卓)Studio 快捷键（转）
8. Android(安卓)- 时间 日期相关组件
9. Android JNI 分析
10. android之datepicker控件用法