Re: upgrading sql2k cluster to sql2005

I couldn't have said it better.

--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP


"Russ Kaufmann [MVP]" <russ@xxxxxxxxxxxxxxx> wrote in message
news:%23rJjyGtbGHA.3504@xxxxxxxxxxxxxxxxxxxxxxx
"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




.

Relevant Pages

  • Re: Connecting to cluster instance from .NET
    ... Virtual IP addresses for the cluster resource groups. ... SQL Server will listen on only those IP addresses ... IP addresses for each of the following cluster resource groups: ...
    (microsoft.public.sqlserver.clustering)
  • Re: is data mirroing online? exchange2003 cluster
    ... The disk which contains the databases is ... > its own databses in its own physical server). ... > NodeB (because cluster does not replicate). ... >> What you do is setup a set of shared disks that are connected to two ...
    (microsoft.public.exchange2000.setup.installation)
  • Re: is data mirroing online? exchange2003 cluster
    ... The disk which contains the databases is ... > its own databses in its own physical server). ... > NodeB (because cluster does not replicate). ... >> What you do is setup a set of shared disks that are connected to two ...
    (microsoft.public.exchange2000.admin)
  • Re: is data mirroing online? exchange2003 cluster
    ... The disk which contains the databases is ... > its own databses in its own physical server). ... > NodeB (because cluster does not replicate). ... >> What you do is setup a set of shared disks that are connected to two ...
    (microsoft.public.exchange2000.general)
  • RE: Clustering a standalone SQL server + storage array
    ... working as expected with out error your ready to install sql server. ... log files to the data and log shared drives you setup as part of the cluster. ... Our apps team look after a trading system that uses an HP DL360 server ... running SQL 2000 SP3a with a few small databases on it. ...
    (microsoft.public.sqlserver.clustering)