SQL Server误区30日谈 第1天 正在运行的事务在服务器故障转移后继续执行

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

这当然是错误的!

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

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

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

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

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

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

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

赞 (0)

相关推荐

  • SQL Server误区30日谈 第11天 镜像在检测到故障后瞬间就能故障转移

    误区 #11:镜像在检测到故障后瞬间就能故障转移 错误 数据库镜像的故障转移既可以自动发起,也可以手动发起. 在自动发起的情况下,是由镜像服务器执行故障转移操作(你没有看错,并不是由见证服务器来做故障转移的决定),在见证服务器和镜像服务器都发现无法和主体服务器交换信息(这个过程被称为"形成仲裁",译者注:也就是通过程序对集群进行监管,集群可用的依据来自监管程序的算法,比如根据:每个节点的配置,文件共享情况,磁盘访问情况,每个节点的可用性等来确定集群是否可用)并且镜像方式是同步时,可以进

  • 如何创建SQL Server 2000故障转移群集

    在创建SQL Server 2000 故障转移群集之前,必须配置 Microsoft 群集服务 (MSCS) 并使用 Microsoft Windows NT4.0 或 Windows 2000 中的群集管理员创建至少一个群集磁盘资源.在运行 SQL Server 安装程序之前,在群集管理员中记下群集驱动器的位置,因为创建新的故障转移群集需要该信息.只有SQL Server 2000 企业版才支持群集. 1. 在"Microsoft SQL Server 安装向导的"欢迎"屏

  • python实现系统状态监测和故障转移实例方法

    复制代码 代码如下: #coding: utf-8import socketimport selectimport timeimport osimport threading def ser():    s = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)    s.bind(("",43244))    while 1:        infds,outfds,errfds = select.select([s],[],[],5)  

  • SQL Server 2008 数据库镜像部署实例之二 配置镜像，实施手动故障转移

    SQL Server 2008 数据库镜像部署实例之二 配置镜像，实施手动故障转移

    上一篇文章已经为配置镜像数据库做好了准备,接下来就要进入真正的配置阶段 一.在镜像数据库服务器上设置安全性并启动数据库镜像会话 1.展开数据库,选择VirtualManagerDB,点击右键选择任务--镜像 2.点击配置安全性,点选是,包括见证服务器 3.去掉见证服务器,以后进行配置 4.设置主体服务器,填入端点名称为site1 5.添加镜像服务器,取端点名为site2 6.指定服务账户为域管理员账户(可以在域内事先配置) 7.创建成功,点击关闭 8.弹出对话框,选择不开始开始镜像 9.点选高性

  • SQL Server误区30日谈 第1天 正在运行的事务在服务器故障转移后继续执行

    误区 #1:在服务器故障转移后,正在运行的事务继续执行 这当然是错误的! 每次故障转移都伴随着某种形式的恢复.但是如果当正在执行的事务没有Commit时,由于服务器或实例崩溃导致连接断开,SQL Server可没有办法在故障转移后的服务器重新建立事务的上下文并继续执行事务-无论你使用的故障转移方式是集群,镜像,日志传送或是SAN复制. 对于故障转移集群来说,当故障转移发生后,一个SQL Server实例在另一个故障转移集群的节点启动.所有实例上的数据库都要经历Recovery阶段-也就是所有没有

  • SQL Server误区30日谈 第24天 26个有关还原(Restore)的误区

    本系列文章一直所没有触及的就是有关"还原(Restore)"的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步.事实上,我希望用字母表的顺序为每一个误区进行编号,希望你看了不要昏昏欲睡.下面开始揭穿这26个误区. 误区 #24: 26个有关还原(Restore)的误区都是错误的 24 a)可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点当然不能.虽然这个语法看上去貌似能的样子,但这个语法的最佳实践是你在进行日志还原到特定时间

  • SQL Server误区30日谈 第30天 有关备份的30个误区

    误区 #30:有关备份的30个误区全是错的在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由完整恢

  • SQL Server误区30日谈 第5天 AWE在64位SQL SERVER中必须开启

    误区 #5: AWE在64位SQL SERVER中必须开启 错误!     在坊间流传的有关AWE的设置的各种版本让人非常困惑.比如说如何设置起作用,如何设置不起作用,在32位和64位上是否需要AWE等. 好吧,我来概括一下: 在64位系统(SQL SERVER 2005+版本) AWE是不需要的(即使是ON状态,也毫无影响) 开启"锁定内存页"使得缓冲池中的内存页不会被置换到虚拟内存中(实际上所有的Single Page Allocator分配和Stolen的内存都不会被置换) 当开

  • SQL Server误区30日谈 第3天 即时文件初始化特性可以在SQL Server中开启和关闭

    SQL Server误区30日谈 第3天 即时文件初始化特性可以在SQL Server中开启和关闭

    本系列文章是我在sqlskill.com的PAUL的博客看到的,很多误区都比较具有典型性和代表性,原文来自T-SQL Tuesday #11: Misconceptions about.... EVERYTHING!!,经过我们团队的翻译和整理发布在AgileSharp和博客园上.希望对大家有所帮助. 误区 #3: 即时文件初始化特性可以在SQL Server中 a)开启 和 b)关闭 a)是不允许的  b)是允许的 即时文件初始化是一个在SQL Server 2005以及之上的版本鲜为人知的特

  • SQL Server误区30日谈 第6天 有关NULL位图的三个误区

    这样还能减少CPU缓存命中失效的问题(点击这个链接来查看CPU的缓存是如何工作的以及MESI协议).下面让我们来揭穿三个有关NULL位图的普遍误区. 误区 #6a:NULL位图并不是任何时候都会用到 正确 就算表中不存在允许NULL的列,NULL位图对于数据行来说会一直存在(数据行指的是堆或是聚集索引的叶子节点).但对于索引行来说(所谓的索引行也就是聚集索引和非聚集索引的非叶子节点以及非聚集索引的叶子节点)NULL位图就不是一直有效了. 下面这条语句可以有效的证明这一点: 复制代码 代码如下:

  • SQL Server误区30日谈 第4天 DDL触发器就是INSTEAD OF触发器

    误区 #4: DDL触发器(SQL Server 2005之后被引入)就是INSTEAD OF触发器 这是错误的     DDL触发器的实现原理其实就是一个AFTER触发器.这个意思是先发生DDL操作,然后触发器再捕捉操作(当然如果你在触发器内写了Rollback,则也可能回滚). 存在Rollback也意味着这个触发器并不像你想象的那么轻量,来看下面的例子: ALTER TABLE MyBigTable ADD MyNewNonNullColumn VARCHAR (20) DEFAULT '

  • SQL Server误区30日谈 第2天 DBCC CHECKDB会导致阻塞

    误区 #2: DBCC CHECKDB会引起阻塞,因为这个命令默认会加锁 这是错误的! 在SQL Server 7.0以及之前的版本中,DBCC CHECKDB命令的本质是C语言实现的一个不断嵌套循环的代码并对表加表锁(循环嵌套算法时间复杂度是嵌套次数的N次方,作为程序员的你懂得),这种方式并不和谐,并且-.. 在SQL Server 2000时代,一个叫Steve Lindell的哥们(现在仍然在SQL Server Team)使用分析事务日志的方法来检查数据库的一致性的方式重写了DBCC C

  • SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志

    SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志

    误区 #19:Truncate表的操作不会被记录到日志 错误 在用户表中的操作都会被记录到日志.在SQL Server中唯一不会被记录到日志的操作是TempDB中的行版本控制. Truncate Table语句会将整个表中的所有数据删除.但删除的方式并不是一行一行的删除,而是将组成表的数据页释放,将组成表的相关页释放的操作交给一个后台的线程进行队列处理的过程被称为deferred-drop.使用后台线程处理deferred-drop的好处是这个操作不会使得其所在的事务需要执行很长时间,因此也就不

  • SQL Server误区30日谈 第22天 资源调控器可以调控IO

    误区 #22: 资源调控器可以调控IO错误    资源调控器无法调控IO,希望下一个版本的SQL Server支持调控IO,调控IO对于对于减少对于大表的scan操作带来的性能影响很有帮助.    下面列表中的功能资源调控器同样也无法完成: 调控Buffer Pool的内存,内存调控器仅仅可以调控执行计划所占的内存,但对于Buffer Pool中缓存的数据页是无法调控的 可以对多个实例进行当作一个逻辑实体进行资源调控.这是不能的,对于多实例的资源调控只能通过Windows Server资源调控器

随机推荐