SQL 2005 Upgrade to SP3 on cluster with 24x7 uptime requirement

No, it is not a MSCS cluster. I am using replistor to provide failover.

When you say active/passive cluster, do you mean you have SQL installed in a MSCS? Or are you reffering to using the RepliStor Alias to provide your failover capabilities?

If this is a MSCS, then you will have to follow Microsoft recommendations for this upgrade: http://go.microsoft.com/fwlink/?LinkId=130542

It is possible by a method of the rolling upgrade.

1) Server A(active node)
upgrade SP3

2) Failover

3) Server B(active node)
upgrade SP3

4) FailBack
Server A(active node)

Another way would be to do this...

- Stop SQL services on the Source
- Wait for Kernel Cache/Logs = 0.
- Flush & Disable the Spec's
- Upgrade the Source to SP3
- If an issue occurs with the upgrade, you have the other Target node that has a clean install with the DB's in their last known loggd condition upon a stop.
- After a successful upgrade on the Source...
- Upgrade the Target.

No matter what you do, SQL services will have to be stopped at some point or another. I believe the SP3 upgrade will make you stop them before proceeding.

The problem is that an upgrade to SP3 on the active server requires an outage that is too long.

I was hoping I could do the upgrade to SP3 on the passive server first. Fail over to the passive server so it's now running on the server with SP3 and then upgrade the old active/now passive server to SP3.

Both previous suggestions sounds like I can only do the upgrade to SP3 on the active server which requires a longer downtime than I am allowed.

This server is our main production server which requires uptime of 24x7. Any planned downtime more than a minute requires permission from all our clients which is a lot of work and requires a long planning cycle.

I believe what you are asking depends on what updates are included with SP3.

The important question to ask here if your action plan is possible is...
Will you be able to bring SP2 DB's online in a SP3 installation?

If the answer is yes, then proceed with your plan.
If the answer is no, then downtime will be mandatory.

If you can, use 2 dummy virtual machines and install a test lab. Install SQL 2005 SP2 and create a user DB. Use RepliStor to move the data from Source to Target and do the upgrade path you are attempting. If you can successfully access the data after a failover, then you can most likely safely use that procedure in your production environment.

I am quite certain SP3 will perform ALTER DATABASE operations. Therefore, you may not be able to use SP3 DB's on a SP2 install or visa versa.

I hope that helps, but what you are looking at are SQL limitations that may exist.

Duncan

I just found these statements in the SQL SP3 Release Notes in regards to a MSCS, but can translate here as well...

Installing SQL Server 2005 SP3 on a Failover Cluster Instance
Note the following information before you install SP3 on a failover cluster instance:

Do not stop the cluster service before you run the SP3 Setup program, or while the installation program is running.

Do not end any running processes before you run the SP3 Setup program.

Do not take the SQL Server service offline before you run the SP3 Setup program. The SP3 Setup program will stop and start the SQL Server service.

Run the SP3 Setup program on the primary node of the failover cluster instance.

The SP3 Setup program might require you to restart the failover cluster nodes. This restart replaces the files that were in use during Setup.

Rolling upgrade is not supported for SP3.

I usually fail over to the Standby node during an outage window and then apply the SP on the Standby (Target) node first. Then make sure you do a Sync of all the Specs in RepliStor. Once all the specs are in-sync you can fail back to the Source (Production) node and repeat the install of the SP on that node.

If you want, you can run on the Target node for a day or so until you can schedule another outage window. The main thing is to make sure to sync back to the Source before failing back.