自动通知服务器故障转移和SQL Server服务重启

核心提示：问题：目前，我们的群集微软SQL Server环境在所有节点中拥有的数据库超过200个，自动通知服务器故障转移和SQL Server服务重启，而虽然群集技术已经出现了一段时间，很多应用程序仍然不是群集感知的，如果除了一个计划或者金基德故障转移过程发生或者其它原因而导致服务被重启时，它也将发生，一个“群集感知

问题：目前，我们的群集微软SQL Server环境在所有节点中拥有的数据库超过200个。而虽然群集技术已经出现了一段时间，很多应用程序仍然不是群集感知的。一个“群集感知”应用程序是什么意思呢？简单来说，它意味着，该应用程序在一个群集实例的某个数据库故障转移之际，将尝试重新连接到该数据库并在数据库故障转移之前重新建立实例化的客户连接。我们的问题是，有了由外面公司提供和检测的一个单独的应用程序，就可以追踪我们的加热和冷却系统的性能来识别温度差异。该应用程序不是群集感知的，可能会在故障转移发生时失败。由于这个解决方法很重要，但又不是从早五点到晚九点都是关键的，因此我们只需要在故障转移时通知供应商。虽然我们可以在这个事件发生时聘请微软系统中心或者微软运营经理来警报，但是我不得不争取多个团队的资源来完成此计划。

我使用的解决方法只是在群集SQL Server实例上创建一个工作，该实例将通过数据库邮件把一封邮件发送到供应商支持的邮件地址，以便在邮件中复制数据库管理员和分析员的访问记录。接着，当服务启动时，我将把关掉的时间表分配给该工作。通过这种方式，每次SQL代理服务启动时，一封邮件都将会被发送，以此来通知我们该服务的重新启动发生了。

对于那些像你一样不熟悉微软SQL Server故障转移的人们来说，该服务与位于一个共享服务器量(SAN/NAS)的资源组有关。该资源组在任何给定的时间内都由一个单独的物理服务器所拥有，在群集术语中被当作一个节点来参考。如果一个节点经历一次关掉请求，那么该资源组的属主将从失败的节点转移到该群集中另一个可用的节点。这个过程涉及到SQL Server实例的循环，因此当该服务被重启时将触发SQL Server代理工作的执行。如果除了一个计划或者金基德故障转移过程发生或者其它原因而导致服务被重启时，它也将发生，但是在本例中这对于我们的需要也是适用的。