SQL Server误区30日谈 第10天 数据库镜像在故障发生后 马上就能发现_MsSql

误区10.数据库镜像在故障发生后,马上就能发现

错误

市面上大肆宣传数据库镜像技术可以在故障发生后,立即检测到错误并进行故障转移。

但事实并不是这样,检测到故障发生的速度要取决于故障的类型。

检测故障发生的最快的情况是,镜像中的主体实例崩溃,从而镜像服务器每秒一次的PING就无法返回值,从而知道主体服务器上不再有这个进程侦听相应的TCP端口,这种情况下,镜像服务器几乎瞬间就能发现故障。

检测到故障发生第二快的情况是主体服务器的操作系统崩溃。此时主体服务器不再响应镜像服务器的PING,从而在镜像服务器PING超时后发现错误。这个超时的阈值默认是10秒。但你也可以延长这个时间,这时,故障发生时间完全取决于PING的超时时间。

检测到故障第三快的情况是是主体的日志磁盘不可用,此时SQL SERVER仍然会发起IO请求,但20秒IO等待无法写入日志后发现日志磁盘不可用,最终40秒后宣告磁盘日志不可用,从而让镜像服务器上线。SQL SERVER是十分有耐心的,比如拿锁来说,SQL SERVER对于锁会无限等待,除非遇到死锁才进行干预。

还有,损坏页有可能完全不会引发故障,如果查询报了823或是824错误,镜像技术完全不会关注(SQL SERVER 2008之后这个问题得到修复: SQL Server 2008: Automatic Page Repair with Database Mirroring),如果数据回滚的过程中遇到823错误或是824错误,数据库立刻会变为质疑状态,也就是日志和数据不统一。这也会导致镜像失败。

你在圣经上学习到的那些教条也不是需要完全遵循的嘛:-)

时间: 2024-10-29 09:02:19

SQL Server误区30日谈 第10天 数据库镜像在故障发生后 马上就能发现_MsSql的相关文章

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

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

SQL Server误区30日谈 第9天 数据库文件收缩不会影响性能_MsSql

误区 #9: 数据库文件收缩不会影响性能 错误!         收缩数据库文件唯一不影响性能的情况是文件末尾有剩余空间的情况下,收缩文件指定了TruncateOnly选项.     收缩文件的过程非常影响性能,这个过程需要移动大量数据从而造成大量IO,这个过程会被记录到日志从而造成日志暴涨,相应的,还会占去大量的CPU资源.     不仅在收缩的过程中影响性能,并且在文件收缩之后同样影响应能,收缩产生的大量日志会被事务日志传送,镜像,复制能操作重复执行.而空间不够时,文件还需要填0初始化从而影

SQL Server误区30日谈 第9天 数据库文件收缩不会影响性能

误区 #9: 数据库文件收缩不会影响性能 错误! 收缩数据库文件唯一不影响性能的情况是文件末尾有剩余空间的情况下,收缩文件指定了TruncateOnly选项. 收缩文件的过程非常影响性能,这个过程需要移动大量数据从而造成大量IO,这个过程会被记录到日志从而造成日志暴涨,相应的,还会占去大量的CPU资源. 不仅在收缩的过程中影响性能,并且在文件收缩之后同样影响应能,收缩产生的大量日志会被事务日志传送,镜像,复制能操作重复执行.而空间不够时,文件还需要填0初始化从而影响性能(除非你开启的不用填零初始

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

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

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

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

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

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

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

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

SQL Server误区30日谈 第7天 一个实例多个镜像和日志传送延迟_MsSql

误区 #7:一个数据库可以存在多个镜像 错误 这个误区就有点老生常谈了.每一个主体服务器只允许一个镜像服务器.如果你希望存在多个主体服务器的副本,那么请使用事务日志传送,事务日志传送允许针对每一个主体存在多个辅助实例. 使用事务日志传送的一个优点是允许其中一个或多个辅助服务器存在延迟还原备份.这也是就是说对主体服务器进行日志备份(无论你喜欢与否,这几种高可用性技术各自有各自的术语): 数据库镜像:主体服务器-镜像服务器 事务日志传送:主要服务器-辅助服务器 复制:发布服务器-订阅服务器 当使用镜

SQL Server误区30日谈 第25天 有关填充因子的误区_MsSql

误区 #25:多个有关填充因子的误区    都是错误的 25a) 填充因子是一直存在的    不是的,通过Books Online可以看到(译者:我在新版的BOL没有找到这句话):重要: 填充因子仅仅在索引创建或重建时生效,SQL Server存储引擎并不会一直保证页内的空闲值和填充因子保持一致.如果为了保证页内的空余值和指定的填充因子保持一直那么填充因子就会失去意义.因为这时页即使不满也需要进行分页. 25 b)填充因子0和100是不同的    错误,由BOL的一句话可以看到    填充因子0