【介绍】
在群集环境下，数据库资源有一些属性。深入了解数据库资源的属性，对于我们更好的管理群集下的数据库，有很大的帮助。我们这里介绍一个公共的属性和特有的属性。并且试验这些属性。这里以Windows 2003 群集环境为例。
【是否Restart】
这个属性设定是，当数据库资源Failed的时候，是否会去尝试重新启动。在群集环境下，这个属性要设为Restart。这样，当资源失败的时候，它会尝试去重启或迁移到另外一个组。
测试 => 当我们选择 “Do not restart”，右键点击SQL Server资源，并选择”Initiate Failure”，那么该SQL Server资源会直接Fail。这样就失去了群集的意义了。所以这个选项我们要选择”Restart”
【影响组 】
这个属性设定是，当SQL Server (MYINSTANCE)资源出现错误的时候，是否会影响到整个组。因为Failover是针对整个组而言，所以如果不会影响组的话，则该资源还是无法Failover到另外一个组。
测试 =>
我们在 ”Affect the group” 上不打勾。 然后在任务管理器里，把 SQL Server 的进程杀掉。 我们会观察到，该资源会一直处于 Fail 的状态。 现在我们把 ”Affect the group” 打勾，那么做同样的操作时，首先 SQLServer (MYINSTANCE) 会 fail ，接着，整个组里的所有其他资源会受到影响，全部 Offline,
然后 Failover 到另外一个节点上，在另外一个节点上，资源能够正常上线。
【Threshold和Period】
这两个属性的缺省值为3和900，也就是说，在900秒，也就是如果某资源失败，则会在15分钟内，去本节点上尝试重新ONLINE三次。三次不成功，则失败(如果没有选择Affect the group)或开始做FAILOVER(如果选择了Affect the group)。
测试 =>
为简单起见，我们把该值改为 10 秒内 3 次。以方便重现问题 在 ”Affect the group” 上不打勾。 把 SQL Server (MYINSTANCE) 资源 Offline 到共享磁盘上，把 master.mdf 改名为 master.mdf.bak 这时候，我们尝试去 Online SQL Server (MYINSTANCE) ，第一次会失败，因为找不到 master.mdf,接着群集会在该结点上再尝试三次，发现还是不能 ONLINE ，这时候，该资源会一直处于失败状态。 我们把该值改为 1 秒内 3 次。在这种设置下，我们会发现 SQL Server
(MYINSTANCE) 会不间断的一直尝试去重启。这是因为启动 SQL
Server 需要时间，在一秒内，不能完成三次启动的尝试，所以在下一秒，又开始重新计数。
【LOOKSALIVE和ISALIVE检查】
LOOKSALIVE检查比较简单，群集会去检查SQL Server这个服务的状态，确认SQL Server这个服务的状态处于RUNNING。
而ISALIVE会做更进一步检查，它会连接到数据库里面，执行一条很简单的查询，明确该查询能返回，就说明数据库状况是正常的。
缺省状况下，LOOKSALIVE每隔5秒做一次，而ISALIVE则每隔60秒做一次检查。
测试 => 我们打开SQL Profiler, 会发现每隔一分钟，从群集那里会有一个查询SELECT @@servername发过来。同时，我们会发现，我们的连接是一直保持着的。
我们也可以做另外一个测试，
建立一个 alias, 把 MYSERVER\MYINSTANCE 映射到一个不存在的服务器上 在查询中，把从群集过来的连接 KILL 掉，（必须要这样做，否者连接没有断掉，还是用 MYSERVER\MYINSTANCE ）这时，我们就会发现，ISALIVE检查会失败。因为群集无法连到数据库上。MYSERVER\MYINSTANCE已经被重定向了。
【PENDING TIMEOUT】
要注意的是，这里的PENDING TIMEOUT并不是资源在ONLINE PENDING或OFFLINE PENDING的最长时间，事实上，SQL Server 可以超过PENDING TIMEOUT时间而一直处于ONLINE PENDING或OFFLINE PENDING状态。我们知道，每个资源都有一个Resource Monitor（资源管理器）。这里的PENDING TIMEOUT是群集询问资源管理器，资源管理器如果在PENDING TIMEOUT时间内没有回复，则群集会通过资源管理器调用Terminate函数把该资源强制OFFLINE。如果资源管理器在PENDING TIMEOUT时间内有回复，则资源可以继续处在ONLINE PENDING或OFFLINE PENDING状态。群集会在下一轮时间内，继续查询资源管理器， 而不是资源本身。
测试 => 我们把SQL Server (MYINSTANCE)的PENDING TIMEOUT 改为10秒。然后把SQL资源OFFLINE再ONLINE,我们会发现SQL Server处于ONLINE PENDING超过了10秒，再过几秒，还是能成功处于ONLINE状态了。这是因为在ONLINE PENDING的过程中，资源管理器还是有响应的。
【SQL 特有属性】
SQL Server 在群集环境下，如果做了一次FAILOVER，要找为什么会FAILOVER，在某些情况下会非常困难，因为问题不能重现，为了能够更好的调查FAILOVER的原因，SQL资源有一个特有的属性。也就是在FAILOVER发生的时候，对SQL Server收集一个Memory Dump，以供我们调查在FAILOVER时，当时SQL Server的状态。该属性可以用下面的语句查询得到:
Cluster res “SQL Server (MYINSTANCE)” /priv SQLDumperDumpFlags=0x8100
Cluster res “SQL Server (MYINSTANCE)” /priv SQLDumperDumpPath=”C:\TEMP”
Cluster res “SQL Server (MYINSTANCE)” /priv SQLDumperDumpTimeOut=300000
测试 =>
我们执行上面的命令，把特有属性设好 我们建一个 alias, 把 MYSERVER\MYINSTANCE 重新定向到一个不存在的服务器名 查询 SELECT * FROM sys.sysprocesses 得到 Cluster 连数据库的 SPID KILL 51 这里 51 是 cluster 连数据库的 SPID 过一会儿， ISALIVE 检查失败， SQL 资源会做 FAILOVER, 同时在 C:\Temp 目录，我们会看到 filterdump 产生。
【总结】
我们讨论了SQL Server在群集中的一些属性。了解这些属性，对于我们理解在群集环境下，SQL Server的行为是非常有帮助的。我们需要正确的设置这些属性，使得SQL Server能够在群集环境下，正常的工作。
oct1.jpg来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25175503/viewspace-708867/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/25175503/viewspace-708867/
1316
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
