Quick facts about applying updates on a SQL Cluster

When a SQL Server 2005 Service Pack is applied on a clustered SQL instance (SQL 2005 and above), the Service Pack/Cumulative Update/Hotfix will upgrade all the member nodes, if a cluster-aware component is selected on the component selection screen. There is no need to run the SP installation after failing over the SQL resources to the passive nodes and re-applying the SPs. The passive nodes are upgraded using a Task Scheduler job created by the SQL setup.

As for the non-cluster aware components like SSIS, Tools etc., if you select them along with the clustered components, then the patches will be applied for the non-cluster aware components as well on the member nodes. In case, you do NOT select the non-cluster aware components while running the update for the cluster aware components, then you will manually have to patch these components.

When applying patches for non-cluster aware components, you do not need to failover the resources.

Setup takes the SQL resource OFFLINE/ONLINE on the active node. The resource is taken offline to patch the binaries and then it is brought online by SQL Setup to apply the configuration scripts. There are no failovers involved during SQL 2005 patching.

Cluster Aware components: Database Services, Analysis Services

Non-cluster Aware components: Integration Services, Reporting Services, Tools

Advertisement

The product has been patched with more recent updates

I have seen a few SQL Server 2005 Failover Clusters running into this issue. Recently, a KB Article was published explaining 2 methods (KB934749) to resolve this issue.

One scenario when you can run into this issue is when you have a SQL Server 2005 Failover Cluster patched with Service Pack 2 or higher and you add a new node to the Failover Cluster, you could run into the issue then.

Another scenario is that the SQL Server binaries on the one node got upgraded to a higher build but one of the member nodes was not upgraded due to some fatal error. But this is a very very rare scenario because SQL Server 2005 setup makes sure it patches all the member nodes where the SQL instance is not active before patching the node on which the SQL instance is installed.