|
1.1. 工作原理 Windows操作系统和SQL Server的各个节点是通过心跳（heartbeat）信号检查各个节点是否可用的。在操作系统级别上，群集各节点通过持续不断的通讯，检查所有节点的可用情况。当安装完SQL Server容灾群集后，SQL Server虚拟主机通过Service Control Manager每隔5秒检查SQL Server服务是否正在运行，这种检查行为我们称之为LooksAlive，它几乎不影响操作系统的性能，但是这也是一种不彻底的检查。LooksAlive认为只要SQL Server服务状态为可运行时，检查结果即为成功，即使SQL Server服务可能根本无法响应请求。 由于LooksAlive无法彻底检查SQL Server服务的工作状态，每隔60秒还会进行一次IsAlive检查。IsAlive检查机制是通过在SQL Server实例上运行SELECT @@SERVERNAME （T-SQL语句），根据SQL查询返回的结果来决定SQLServer服务是否能够响应请求。尽管IsAlive发出的查询请求可能已经被SQL Server服务正常响应了，但是这并不能判断所有的用户数据库是否都是可用的，其性能是否满足要求。如果IsAlive发出的查询无法成功，它会重试5次，然后尝试重新连接SQLServer实例。如果5次重试全部失败，将认为SQL Server服务失败了。根据SQL Server容灾群集中SQL Server的资源设置，群集将尝试重启服务或在其它节点启动SQL Server服务。IsAlive检查可以容忍查询返回错误的结果，但是如果返回错误结果次数超过设定的阀值，最终还会认为数据库服务已经无法工作了。 当SQL Server实例发生节点转移时，SQL Server的资源将在新的节点上启动。Windows群集在新的节点上启动SQL Server服务，SQL Server服务通过内部恢复进程启动数据库。当SQL Server服务启动，并且master已经联机，SQL Server资源将被认定已经启动。接下来用户数据库将被恢复。那些在事务日志中已经完成的事务将被重用（redo阶段），没有完成的事务将被会退（undo阶段）。SQL Server2005 Enterprise版本的用户数据库，一旦恢复了已提交事务（redo阶段），数据库就可以使用了。对于SQL Server 2005其它版本和早期版本只有当所有未提交事务全部被会退（undo阶段），用户数据库才能使用，这些版本的数据库恢复时间决定于有多少需要回退的未提交事务。 系统参数'recovery interval'可以设定redo恢复的最小时间，通过对其设置可以避免长时间的redo操作进而加速恢复过程。如果想减少undo的恢复时间，需要避免使用长事务。
| 
发表于 2015-6-8 21:16:31
