SQL Server误区:数据库镜像在故障发生后马上就能发现

误区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错误,数据库立刻会变为质疑状态,也就是日志和数据不统一。这也会导致镜像失败。

更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/database/SQLServer/

时间: 2024-08-07 15:28:43

SQL Server误区:数据库镜像在故障发生后马上就能发现的相关文章

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

误区10.数据库镜像在故障发生后,马上就能发现 错误 市面上大肆宣传数据库镜像技术可以在故障发生后,立即检测到错误并进行故障转移. 但事实并不是这样,检测到故障发生的速度要取决于故障的类型. 检测故障发生的最快的情况是,镜像中的主体实例崩溃,从而镜像服务器每秒一次的PING就无法返回值,从而知道主体服务器上不再有这个进程侦听相应的TCP端口,这种情况下,镜像服务器几乎瞬间就能发现故障. 检测到故障发生第二快的情况是主体服务器的操作系统崩溃.此时主体服务器不再响应镜像服务器的PING,从而在镜像服

SQL SERVER 2005数据库镜像(1)

本文对SQL SERVER 2005数据库镜像进行了教程式的讲解,具体内容包括:介绍.动态.可用性场景.实现和高可用性技术,供大家参考! 概述 数据库镜像是SQL SERVER 2005用于提高数据库可用性的新技术.数据库镜像将事务日志记录直接从一台服务器传输到另一台服务器,并且能够在出现故障时快速转移到备用服务器.可以编写客户端程序自动重定向连接信息,这样一旦出现故障转移就可以自动连接到备用服务器和数据库. 自动进行故障转移并且使数据损失最小化通常包括昂贵的硬件和复杂的软件.但是,数据库镜像可

简述SQL Server 2005数据库镜像相关知识_mssql2005

SQL Server 数据库中,数据库镜像是用于提高数据库可用性的主要软件解决方案.数据库镜像基于每个数据库实现,并且只适用于使用完整恢复模式的数据库.简单恢复模式和大容量日志恢复模式不支持数据库镜像,数据库镜像不能镜像master.msdb.tempdb 或 model 数据库.本文我们主要就介绍一下数据库镜像的相关知识,接在来就让我们来一起了解一下吧! 数据库镜像维护一个数据库的两个副本,这两个副本必须驻留在不同的SQL Server 数据库引擎实例(服务器实例)上.通常,这些服务器实例驻留

SQL Server 2008 数据库镜像部署实例之三 配置见证服务器_mssql2008

前面已经完成了镜像数据库的配置,并进行那个了故障转移测试.接下来将部署见证服务器,实现自动故障转移. 一.关于见证服务器 1.若要支持自动故障转移,必须在高安全性模式下配置数据库镜像会话,并且还要具有第三个服务器实例(也称为"见证服务器").见证服务器是 SQL Server 的可选实例,它能使高安全性模式会话中的镜像服务器识别出是否要启动自动故障转移.与这两个伙伴不同的是,见证服务器并不能用于数据库.见证服务器的唯一角色是支持自动故障转移. 2.为了给数据库设置见证服务器,数据库所有

Microsoft SQL Server 2005数据库镜像语句

Microsoft SQL Server 2005数据库镜像语句: SERVER 1 CREATE ENDPOINT DbMirroring STATE=STARTED AS TCP(LISTENER_PORT=5023) FOR DATABASE_MIRRORING(ROLE=PARTNER,ENCRYPTION=SUPPORTED) ALTER DATABASE AdventureWorks SET PARTNER='TCP://192.168.5.106:5022' SERVER 2 CR

备份SQL Server 2014数据库到Azure Blob存储器服务上

http://www.aliyun.com/zixun/aggregation/13357.html">Azure VM 客制化脚本扩展 (Custom Script Extension) 将让您可以从存储器账户下载 PowerShell 脚本并执行之, 透过这样一个简单的功能,您可以因应各种不同的 VM 客制化情境,弹性地自动化 VM 设定.在本篇文章中我们将带您了解如何从 Azure VM Image Gallery 中使用客制化脚本扩展来客制一个 SQL Server 2014 VM

SQL Server误区:镜像在检测到故障后瞬间就能故障转移

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

SQL Server误区:在服务器故障转移后,正在运行的事务继续执行

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

SQL SERVER 2005数据库镜像(3)

因为Server A无法看见见证服务器Server W或者原先的镜像伙伴Server B,因此必须进入disconnected状态并使数据库不可用. Server B和Server W可以组成quorum.Server B无法看见Server A,因此Server B试图成为主服务器并使其数据库联机.因为Server W也看不到Server A,因此同意了Server B. Server B现在有了quorum,担当起会话的主服务器角色,然后还原其数据库. 如果恢复通信连路,Server A能够