Comments posted to this topic are about the item Prepare SQL Server 2005 in a Clustered Environment for SP3
First of all thank you for posting these mishaps and the work around.
We didn't encounter these problems when upgrading from sp2 cu2 to SP3 on our 2-node sql-cluster (multiple instances).
We do pay attention for the cluster resource to reside on the same node as the sql instance to be upgraded.
We even upgraded multiple instances in a single run. We moved all instances to the same node before starting the upgrade.
Off course it will not hurt to have a spare/backup set of resource db files !
We take a copy of them after every upgrade (because at that moment is planned downtime).
One thing we did observer is the needed reboot after the first instance + the client software have been upgraded.
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
We've just gone through a cluster migration project and used the approach you outline. One thing you may find is that if you change the startup parameters of SQL Server via Configuration Manager, e.g. change the location of where master.mdf resides, the Config Manager information and the Registry information on each cluster node can get out of synch.
This can be prevented by following the instructions in this link: http://support.microsoft.com/kb/912397
We were migrating to a new server so we also had the problem of the new server containing the old server name when 'SELECT @@servername' was executed. We had to drop the old server name and add a new one.
Another issue is that the msdb subsystems may now be in a different physical location so the contents of the msdb.dbo.syssubsystems table must be deleted and the susbsystems reinitialised using 'EXEC dbo.sp_verify_subsystems 1'
Lastly, if you are moving servers, be sure to backup the Service Master Key and then restore it using the FORCE option on the new server.
SP2 and later has been pretty good in that everything on both nodes was updated, but i'm still paranoid and like to failover all instances to each node and run the update and make sure everything on each node is updated
I wanted to test out these steps on a test server first. Unfortunately my test server is SQL 2008 Standard Edition non-clustered. When I attempted to alter the resource database specifically the log file I encountered the following error:
To use ALTER DATABASE, the database must be in a writable state in which a check
point can be executed.
Viewing 8 posts - 1 through 7 (of 7 total)