Post reply

Prepare SQL Server 2005 in a Clustered Environment for SP3

  • June 19, 2009 at 12:29 am

    #206159

    Comments posted to this topic are about the item Prepare SQL Server 2005 in a Clustered Environment for SP3

  • June 19, 2009 at 5:06 am

    #1012276

    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.

    Johan

    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

  • June 19, 2009 at 5:28 am

    #1012282

    It could be that it is hardware related. I've had several people with the same problem but others that didn't have the problem.

  • June 19, 2009 at 5:54 am

    #1012296

    Thanks for the article we have a test cluster to do this on shortly so we can try it out.

    Facts are stubborn things, but statistics are more pliable - Mark Twain
    Carolyn
    SQLServerSpecialists[/url]

  • June 19, 2009 at 7:42 am

    #1012388

    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.

  • June 22, 2009 at 1:05 pm

    #1013530

    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

  • June 23, 2009 at 2:56 pm

    #1014274

    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.

  • June 24, 2009 at 1:42 am

    #1014478

    This article is meant for SQL 2005 in a clustered environment. You probably don't need do these steps when you have a non-clustered environment. I haven't tested the method voor SQL 2008 either.

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply