Re: upgrading sql2k cluster to sql2005
- From: "Russ Kaufmann [MVP]" <russ@xxxxxxxxxxxxxxx>
- Date: Wed, 3 May 2006 10:50:33 -0600
"Michael Hotek" <mike@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:O$jVjMnbGHA.2456@xxxxxxxxxxxxxxxxxxxxxxx
Yes, but that's coming from two people who deal with Windows clusters.
It ain't that simple for SQL Server. You have to copy all of the logins
over and make sure they are recreated in the correct order. You have to
possibly load drivers that are used by linked servers as well as making
sure
the logins and passwords for those are moved over. You have to make sure
that databases get locked off in the current cluster and then properly
brought online on the nw cluster while also ensuring that all of the
login/user linkages are correct and permissions are set properly. You
then
have to deal with DTS packages, jobs, error messages, and the list goes on
and on and on.
Oh, I realize that there is a great deal of work involved. That doesn't make
it any less appropriate of a method when it comes to risk mitigation. BTW, I
do much more than just handle clustering. I maintain many SQL servers as
well as Exchange servers.
Doing a side-by-side upgrade is actually much riskier that upgrading SQL
Server in place, because there are dozens of things that you need to
manually extract and then apply to a new failover cluster instance.
How is it more risky when you have the ability to test each component and
_always_ have a valid fall back position? Having a fall back plan is vital
to proper change control.
You have a further issue with SQL Server if you are going to install a
2005
instance into the same cluster as the 2000 instance. If the databases on
your 2000 instance are using X drive letters, you have to add X more disk
resources to the cluster and set them up for dependencies on the new 2005
instance. Do you have that many spare disk resources just lying around to
use?
I am recommending a new cluster, not a new instance. I am recommending
migrating databases from one cluster to another.
Installing a new instance of 2005 means that it now has a different name.
Who is going to track down all of the applications that need to have
connection strings changed in them and then retest all of those
applications
to make sure they still work?
In an HA shop, those would all be documented. Documentation is a key
component to an HA environment.
An in place upgrade is recommended, simply because you do not have to
worry
about ANY of the issues outlined above since they are all taken care of
during the upgrade process.
Recommended by whom?
Obviously, you have never done an in place upgrade and had it fail miserably
and then had to spend all weekend restoring servers and databases to get
things working again. To top it off, I bet you haven't ever had to tell a
CIO or a CEO of a fortune 500 company how you cost them millions of dollars
in down time. <G>
I am speaking from experience.
I've done 1 side-by-side upgrade and it was the most time consuming mess
that I've seen in a long time. They went through months of analysis and
testing and even then it took them 4 tries to get the thing up and
running, because they kept missing applications that were broken.
I bet that each time they were thankful that they had something to fall back
to and save their careers.
The next dozen clusters that were upgraded were done so in-place. Each
of these upgraded correctly the first time, everything worked, all
applications functioned, and we had a total outage of less than 1 minute
per failover cluster instance.
Congrats. I am glad to hear that they were successful.
What it all comes down to is this:
1. Clustering was put in place because of the importance of the data to the
company.
2. Down time for some companies can cost millions per day and even per hour.
3. High availability is much more than just clustering.
4. Risk mitigation is a huge part of high availability.
5. Decisions regarding risk levels and mitigation costs are management
decisions. Let them put their necks on the line. Let's keep us IT'ers
employed. <G>
--
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
.
- Follow-Ups:
- Re: upgrading sql2k cluster to sql2005
- From: Michael Hotek
- Re: upgrading sql2k cluster to sql2005
- From: Geoff N. Hiten
- Re: upgrading sql2k cluster to sql2005
- References:
- Re: upgrading sql2k cluster to sql2005
- From: Tom Moreau
- Re: upgrading sql2k cluster to sql2005
- From: Michael Hotek
- Re: upgrading sql2k cluster to sql2005
- From: Linchi Shea
- Re: upgrading sql2k cluster to sql2005
- From: Russ Kaufmann [MVP]
- Re: upgrading sql2k cluster to sql2005
- From: Michael Hotek
- Re: upgrading sql2k cluster to sql2005
- Prev by Date: Re: upgrading sql2k cluster to sql2005
- Next by Date: Re: SQL transaction logs on iSCSI
- Previous by thread: Re: upgrading sql2k cluster to sql2005
- Next by thread: Re: upgrading sql2k cluster to sql2005
- Index(es):
Relevant Pages
|