Prepare SQL Server 2005 in a Clustered Environment for SP3

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by Sander Stad » Prepare SQL Server 2005 in a Clustered...

Prepare SQL Server 2005 in a Clustered Environment for SP3

Rate Topic

Display Mode

Topic Options

Author

Message

sanderstad

Posted Friday, June 19, 2009 12:29 AM

Old Hand

Group: General Forum Members
Last Login: Tuesday, May 21, 2013 3:19 AM
Points: 382, Visits: 487

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

Post #738075

ALZDBA

Posted Friday, June 19, 2009 5:06 AM

SSCertifiable

Group: General Forum Members
Last Login: Wednesday, May 22, 2013 2:17 AM
Points: 6,862, Visits: 8,049

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

     Jul 13

Don't drive faster than your guardian angel can fly ...
but keeping both feet on the ground won't get you anywhere w00t

- How to post Performance Problems
- How to post data/code to get the best help

- How to prevent a sore throat after hours of presenting ppt ?

"press F1 for solution", "press shift+F1 for urgent solution" BigGrin

Need a bit of Powershell? How about this

Who am I ? Sometimes this is me but most of the time this is me Hehe

Post #738175

sanderstad

Posted Friday, June 19, 2009 5:28 AM

Old Hand

Group: General Forum Members
Last Login: Tuesday, May 21, 2013 3:19 AM
Points: 382, Visits: 487

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.

Post #738184

Carolyn Richardson

Posted Friday, June 19, 2009 5:54 AM

Ten Centuries

Group: General Forum Members
Last Login: Friday, May 17, 2013 4:52 AM
Points: 1,397, Visits: 2,738

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

Post #738199

Lempster

Posted Friday, June 19, 2009 7:42 AM

UDP Broadcaster

Group: General Forum Members
Last Login: Tuesday, May 21, 2013 8:40 AM
Points: 1,450, Visits: 760

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.

Post #738301

alen teplitsky

Posted Monday, June 22, 2009 1:05 PM

Ten Centuries

Group: General Forum Members
Last Login: Wednesday, May 22, 2013 8:15 PM
Points: 1,409, Visits: 4,509

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

https://plus.google.com/100125998302068852885/posts?hl=en
http://twitter.com/alent1234
x-box live gamertag: i am null
[url=http://live.xbox.com/en-US/MyXbox/Profile[/url]

Post #739681

cliffy81

Posted Tuesday, June 23, 2009 2:56 PM

Forum Newbie

Group: General Forum Members
Last Login: Wednesday, September 05, 2012 11:10 AM
Points: 2, Visits: 334

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.

Post #740568

sanderstad

Posted Wednesday, June 24, 2009 1:42 AM

Old Hand

Group: General Forum Members
Last Login: Tuesday, May 21, 2013 3:19 AM
Points: 382, Visits: 487

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.

Post #740823

« Prev Topic | Next Topic »

Permissions