ClusterService Log On Account and SQL2000

It is my understanding that this Active Directory account takes on the
role(s) of SQL's BuiltIn Administrator in a clustered environment.
Should the ClusterService Log On account password be reset in AD, without
reseting in the properties tab for the service on the physical nodes cluster
fail overs can still occur because the ClusterService has already been
started. BUT, what activity in SQL2000 could the AD account be doing on
behalf of the SQL BuiltIn Administrator account that would affect the
cluster and initiate a failover if it could not authenticate on the Domain?
Dave
That is not right. By default (God, I hate Microsoft's defaults), the
Cluster Service MUST BE a member of the Local Administrators group on each
cluster node, by which it gains access to the SQL Server installations
through the default BUILTIN\Administrators membership to the SQL Server
system admin default server role.
If you follow the security best practices, and you should, you will remove
the BUILTIN\Administrators group for the installation; however, the Cluster
Service account will still need access to run the resource monitor "Is
Alive" check, which, in the case for the SQL Server resource, is nothing but
the SELECT @.@.SERVERNAME query; thus, the Cluster Service account merely
needs access to the installation, but no special rights beyond this, as the
guest database user in the master database has permissions to execute this
query.
Sincerely,
Anthony Thomas

"David Currie" <decurrie@.rogers.com> wrote in message
news:%23aT3qmQBHHA.204@.TK2MSFTNGP04.phx.gbl...
> It is my understanding that this Active Directory account takes on the
> role(s) of SQL's BuiltIn Administrator in a clustered environment.
> Should the ClusterService Log On account password be reset in AD, without
> reseting in the properties tab for the service on the physical nodes
cluster
> fail overs can still occur because the ClusterService has already been
> started. BUT, what activity in SQL2000 could the AD account be doing on
> behalf of the SQL BuiltIn Administrator account that would affect the
> cluster and initiate a failover if it could not authenticate on the
Domain?
> Dave
>

Clusters and Log Shipping

Does anyone know of any issues with using Active/Passive or Active/Active clusters and log shipping. Will log shipping still work if a failover occurs?

Thanks

Yes, log shipping still works after a cluster failover. A failover in a cluster is basically the same as restarting your SQL Service. Assuming you have log shipping configured correctly (i.e. using the virtual instance name, which would be the case if you configured log shipping using the built-in wizards/plans), log shipping will pick up where it left off before the failover occured (i.e. the next time the t-log is backed up, it will be shipped to your shared log location for application to the standby server).

HTH

|||

Setting up log-shipping between two clusters gets a little more intricate because you have to establish the file shares log-shipping needs and although the shared disk fails over, the shares have to be setup in advance, and the node has to be the active node in order to setup the "shared disk" shares.

Clusters and Log Shipping

Does anyone know of any issues with using Active/Passive or Active/Active clusters and log shipping. Will log shipping still work if a failover occurs?

Thanks

Yes, log shipping still works after a cluster failover. A failover in a cluster is basically the same as restarting your SQL Service. Assuming you have log shipping configured correctly (i.e. using the virtual instance name, which would be the case if you configured log shipping using the built-in wizards/plans), log shipping will pick up where it left off before the failover occured (i.e. the next time the t-log is backed up, it will be shipped to your shared log location for application to the standby server).

HTH

|||

Setting up log-shipping between two clusters gets a little more intricate because you have to establish the file shares log-shipping needs and although the shared disk fails over, the shares have to be setup in advance, and the node has to be the active node in order to setup the "shared disk" shares.

Clusters and licensing in 2005

I need help with a licensing question for 2005. Assuming two servers with two
processors each:
If I have one instance on Server A in an active/passive cluster with Server
B, my understanding is that I need licenses for two processors on Server A)
If I have one instance on Server A and one instance on Server B
(Active/active cluster) my understanding is that I need licenses for all 4
processors.
If I have two instances on Server A and am using Server B for failover, how
many licenses do I need? In the case of a single instance failing over I'd
have instances running on both servers.
thanks
Your best bet is call Microsoft. The answer varies depending on your
current/future agreement with them. Various price points can exist.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
"Peter Feakins" <PeterFeakins@.discussions.microsoft.com> wrote in message
news:6ECF0749-8857-4791-A36C-025EDC6B276F@.microsoft.com...
>I need help with a licensing question for 2005. Assuming two servers with
>two
> processors each:
> If I have one instance on Server A in an active/passive cluster with
> Server
> B, my understanding is that I need licenses for two processors on Server
> A)
> If I have one instance on Server A and one instance on Server B
> (Active/active cluster) my understanding is that I need licenses for all 4
> processors.
> If I have two instances on Server A and am using Server B for failover,
> how
> many licenses do I need? In the case of a single instance failing over I'd
> have instances running on both servers.
> thanks
|||The answer from Microsoft licensing was that any multi-instance cluster is
considered to be active/active rather than active/passive, regardless of
where the instances run. In this case processors on both servers would need
licenses.
"Peter Feakins" wrote:

> I need help with a licensing question for 2005. Assuming two servers with two
> processors each:
> If I have one instance on Server A in an active/passive cluster with Server
> B, my understanding is that I need licenses for two processors on Server A)
> If I have one instance on Server A and one instance on Server B
> (Active/active cluster) my understanding is that I need licenses for all 4
> processors.
> If I have two instances on Server A and am using Server B for failover, how
> many licenses do I need? In the case of a single instance failing over I'd
> have instances running on both servers.
> thanks
|||Hi Peter,
I am not a Licensing expert but I found a Whitepaper on SQL Server 2005 Licensing that you may find helpful. Here is the link
http://download.microsoft.com/downlo..._Licensing.doc
Here is a section from the whitepaper
When doing failover support, a server is designated as the passive server. The purpose of the passive server is to absorb the data and information held in another server that fails. A passive server does not need a
license, provided that the number of processors in the passive server is equal or less than those of the active server. The passive server can take the duties of the active server for 30 days. Afterwards, it must be
licensed accordingly.
Also, found another link that you may find helpful
SQL Server 2005 Licensing: Frequently Asked Questions
http://www.microsoft.com/sql/howtobuy/faq.mspx
Here is a section from this link
Q. How does licensing work for computers that run SQL Server 2005 in failover scenarios?
A. Failover support, where servers are clustered together and set to pick up processing duties if one computer should fail, is now available in Workgroup, Standard, and Enterprise editions of SQL Server 2005.
Under each of these editions, keeping a passive server for failover purposes does not require a license as long as the passive server has the same or fewer processors than the active server (under the per
processor scenario). For details on which failover methods are available under each edition, visit the SQL Server 2005 Features Comparison page.
HTH,
Best Regards,
Uttam Parui
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection Program and to order your FREE Security Tool Kit, please visit http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their Microsoft software to better protect against viruses and security vulnerabilities. The easiest way to do this is to visit the following websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx

Clustering with 2 active nodes and 1 passive node

Normally, clustering is setup as a 1-to-1 relationship between active and
passive nodes, at least that is my understanding. We have a situation where
we are being asked to setup a 2 active node, 1 passive node environment.
Here's the question - if one of the active nodes fails, it fails over to the
passive node. Now what happens if the 2nd active node fails? Will the other
active node (originally the passive node) handle the failover or will it try
to failover to the first active node that failed or will the whole thing just
grind to a screeching halt? I know we can setup a 2 active/ 2passive node
setup, but we wanted to research the 2-to-1 possibility as well.
Thanks!
Message posted via http://www.droptable.com
Hi
You don't need a 1:1 relationship between nodes.
And forget the terms active / passive, it is totally out of date and does
not describe SQL Server 2000/2005 clustering.
You have an instance of SQL Server running on an node.
If you have 2 nodes, it could run on any of those nodes at any one time. If
you had 3 nodes, it could run on any of those nodes, at any one time.
If you have 2 nodes, one sits around waiting for a failover. If you have 3
nodes, 2 sit around waiting for a failover.
If you have more than one SQL Server instance running on the cluster, then
the instances can run on any of the nodes.
The instances could be all running on the same node, or dispersed over the
various nodes.
Quite often, people run with 3 nodes and 2 instances or 4 nodes with 3
instances. There is nothing stopping you running 3 instances on 3 nodes, 4
instances on 4 nodes, or any combination of up to 16 instances over 4 nodes.
You just need to make sure that you have enough resources, that in worst
case, one node could run all instances.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Michael G via droptable.com" <forum@.droptable.com> wrote in message
news:541CE6C54F90F@.droptable.com...
> Normally, clustering is setup as a 1-to-1 relationship between active and
> passive nodes, at least that is my understanding. We have a situation
> where
> we are being asked to setup a 2 active node, 1 passive node environment.
> Here's the question - if one of the active nodes fails, it fails over to
> the
> passive node. Now what happens if the 2nd active node fails? Will the
> other
> active node (originally the passive node) handle the failover or will it
> try
> to failover to the first active node that failed or will the whole thing
> just
> grind to a screeching halt? I know we can setup a 2 active/ 2passive node
> setup, but we wanted to research the 2-to-1 possibility as well.
> Thanks!
>
> --
> Message posted via http://www.droptable.com
|||Very helpful. Question: So now, even with RAID 10, the single point of
failure becomes the shared drive array? How does one go about creating a
failover for this?
Respectfully,
Michael Wiederhold
michael@.auctionarms.com
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%230j6BCZtFHA.3236@.TK2MSFTNGP14.phx.gbl...
> Hi
> You don't need a 1:1 relationship between nodes.
> And forget the terms active / passive, it is totally out of date and does
> not describe SQL Server 2000/2005 clustering.
> You have an instance of SQL Server running on an node.
> If you have 2 nodes, it could run on any of those nodes at any one time.
> If you had 3 nodes, it could run on any of those nodes, at any one time.
> If you have 2 nodes, one sits around waiting for a failover. If you have 3
> nodes, 2 sit around waiting for a failover.
> If you have more than one SQL Server instance running on the cluster, then
> the instances can run on any of the nodes.
> The instances could be all running on the same node, or dispersed over the
> various nodes.
> Quite often, people run with 3 nodes and 2 instances or 4 nodes with 3
> instances. There is nothing stopping you running 3 instances on 3 nodes, 4
> instances on 4 nodes, or any combination of up to 16 instances over 4
> nodes. You just need to make sure that you have enough resources, that in
> worst case, one node could run all instances.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Michael G via droptable.com" <forum@.droptable.com> wrote in message
> news:541CE6C54F90F@.droptable.com...
>
|||Hi
Most high end SAN's have a block level copy mechanism so that you can
"mirror" that data to another SAN, preferably at another location.
EMC has SRDF that can run synchronous or asynchronous over fast WAN links.
Tape backups must never be forgotten either.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"michael wiederhold" <michael@.auctionarms.com> wrote in message
news:%23RhSzuztFHA.3068@.TK2MSFTNGP14.phx.gbl...
> Very helpful. Question: So now, even with RAID 10, the single point of
> failure becomes the shared drive array? How does one go about creating a
> failover for this?
> Respectfully,
> Michael Wiederhold
> michael@.auctionarms.com
> "Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
> news:%230j6BCZtFHA.3236@.TK2MSFTNGP14.phx.gbl...
>
|||Thanks. Really do appreciate your participation in this newsgroup.
Respectfully,
Michael Wiederhold
michael@.auctionarms.com
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:ONHGyz8tFHA.2540@.TK2MSFTNGP09.phx.gbl...
> Hi
> Most high end SAN's have a block level copy mechanism so that you can
> "mirror" that data to another SAN, preferably at another location.
> EMC has SRDF that can run synchronous or asynchronous over fast WAN links.
> Tape backups must never be forgotten either.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "michael wiederhold" <michael@.auctionarms.com> wrote in message
> news:%23RhSzuztFHA.3068@.TK2MSFTNGP14.phx.gbl...
>

Clustering two MS SQL 2000 serveres

Hi!
I need to make an active/active cluster out of two servers. One of
them is critical and has huge number of published tables, so I want it
to be available the sooner the better. What is the best way to do
this?
When moving critical servers I practiced this aproach:
1. Stop sql-server service
2. Copy all databases file on a new server
3. Shut down the old one
4. Name the new the same name and install MS SQL Server 2000 on it
5. Stop the sql-sever service and replace the its databases files with
the ones copied from the old server
6. Start the sql-server service
Since one of the sql server nodes will have to be renamed the way
like: node2\second, the above aproach will not work for the second
server. But will it work for the first? Are there any subtleties
concerned with possibly different way a clustered MS SQL Server works?
Thanks.
Hi
You can not rename a cluster, but you could create a DNS alias for your old
server's name to map to the new cluster's name. Until you change your
applications and scripts.
Regards
Mike
"Roust_m" wrote:

> Hi!
> I need to make an active/active cluster out of two servers. One of
> them is critical and has huge number of published tables, so I want it
> to be available the sooner the better. What is the best way to do
> this?
> When moving critical servers I practiced this aproach:
> 1. Stop sql-server service
> 2. Copy all databases file on a new server
> 3. Shut down the old one
> 4. Name the new the same name and install MS SQL Server 2000 on it
> 5. Stop the sql-sever service and replace the its databases files with
> the ones copied from the old server
> 6. Start the sql-server service
> Since one of the sql server nodes will have to be renamed the way
> like: node2\second, the above aproach will not work for the second
> server. But will it work for the first? Are there any subtleties
> concerned with possibly different way a clustered MS SQL Server works?
> Thanks.
>
|||Not sure if you have seen this Q yet http://support.microsoft.com/?id=307336
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://msmvps.com/clustering - Blog
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:D6160553-ADDF-41DF-A3CE-F59DEF47E7B0@.microsoft.com...[vbcol=seagreen]
> Hi
> You can not rename a cluster, but you could create a DNS alias for your
> old
> server's name to map to the new cluster's name. Until you change your
> applications and scripts.
> Regards
> Mike
> "Roust_m" wrote:

Clustering - Active / Active nodes

I do not have any experience with MS SQL. I'm a hardware engineer. I focus
mainly on the servers hardware and connectivity.
I was wondering, is it possible to cluster 2 (or more) nodes running all
nodes on active / active as a single MS SQL database system? The servers are
connecting to a common shared storage system.
Is this possible? This is more of a scale out strategy.
Thanks
I am sorry to tell you that is not. A database will only run on one machine
at a time. Clustering will not help you with this problem.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://www.msmvps.com/clustering - Blog
"Alistair Wong" <Alistair Wong@.discussions.microsoft.com> wrote in message
news:DA956B40-736A-4A10-A11D-BDAAC07FDACF@.microsoft.com...
>I do not have any experience with MS SQL. I'm a hardware engineer. I focus
> mainly on the servers hardware and connectivity.
> I was wondering, is it possible to cluster 2 (or more) nodes running all
> nodes on active / active as a single MS SQL database system? The servers
> are
> connecting to a common shared storage system.
> Is this possible? This is more of a scale out strategy.
> Thanks

Clustering

If i have an active\passive cluster for SQL Server, under what circumstances would it prompt to automatic changeover to the passive cluster ? Failure of the SQL Server, or let's say 1 user database out of 25 becomes suspect?It would require a failure of the entire SQL Server. Individual databases can be brought online and offline all throughout the day. A failover is only done when one of the cluster resources has failed.

Clustered SQL Server shut down for third-party application install

Dear Sir,
If I needed to install something to the active then passive node one by one
and required to restart the server serveral times during install, what is the
procedures if I don't want SQL Server to auto startup during reboot?
Steps:
01) Offline "passive" node from cluster admin.
02) Shut down "passive" node server.
03) Offline "active" node SQL Server Group
04) From OS Services, change SQL Server to "Not auto startup"
05) Install application
06) Reboot active server
07) ....
Is the above procedures ok?
Please advise! Thanks!
Henry
cross-posted to microsoft.public.sqlserver.clustering
*mike hodgson*
blog: http://sqlnerd.blogspot.com
Henry wrote:

>Dear Sir,
>If I needed to install something to the active then passive node one by one
>and required to restart the server serveral times during install, what is the
>procedures if I don't want SQL Server to auto startup during reboot?
>Steps:
>01) Offline "passive" node from cluster admin.
>02) Shut down "passive" node server.
>03) Offline "active" node SQL Server Group
>04) From OS Services, change SQL Server to "Not auto startup"
>05) Install application
>06) Reboot active server
>07) ....
> Is the above procedures ok?
>Please advise! Thanks!
>Henry
>
>

Clustered SQL Server shut down for third-party application install

Dear Sir,
If I needed to install something to the active then passive node one by one
and required to restart the server serveral times during install, what is the
procedures if I don't want SQL Server to auto startup during reboot?
Steps:
01) Offline "passive" node from cluster admin.
02) Shut down "passive" node server.
03) Offline "active" node SQL Server Group
04) From OS Services, change SQL Server to "Not auto startup"
05) Install application
06) Reboot active server
07) ....
Is the above procedures ok?
Please advise! Thanks!
HenryThis is a multi-part message in MIME format.
--030309070404030102020809
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
cross-posted to microsoft.public.sqlserver.clustering
--
*mike hodgson*
blog: http://sqlnerd.blogspot.com
Henry wrote:
>Dear Sir,
>If I needed to install something to the active then passive node one by one
>and required to restart the server serveral times during install, what is the
>procedures if I don't want SQL Server to auto startup during reboot?
>Steps:
>01) Offline "passive" node from cluster admin.
>02) Shut down "passive" node server.
>03) Offline "active" node SQL Server Group
>04) From OS Services, change SQL Server to "Not auto startup"
>05) Install application
>06) Reboot active server
>07) ....
> Is the above procedures ok?
>Please advise! Thanks!
>Henry
>
>
--030309070404030102020809
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>cross-posted to microsoft.public.sqlserver.clustering</tt><br>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font></span> <b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<font face="Tahoma" size="2">blog:</font><font face="Tahoma" size="2"> <a
href="http://links.10026.com/?link=http://sqlnerd.blogspot.com</a></font></span>">http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
<br>
<br>
Henry wrote:
<blockquote cite="midE64C9F95-F0A5-42B5-A7AD-3CE7515EB4FE@.microsoft.com"
type="cite">
<pre wrap="">Dear Sir,
If I needed to install something to the active then passive node one by one
and required to restart the server serveral times during install, what is the
procedures if I don't want SQL Server to auto startup during reboot?
Steps:
01) Offline "passive" node from cluster admin.
02) Shut down "passive" node server.
03) Offline "active" node SQL Server Group
04) From OS Services, change SQL Server to "Not auto startup"
05) Install application
06) Reboot active server
07) ....
Is the above procedures ok?
Please advise! Thanks!
Henry
</pre>
</blockquote>
</body>
</html>
--030309070404030102020809--

Clustered SQL Server shut down for third-party application install

Dear Sir,
If I needed to install something to the active then passive node one by one
and required to restart the server serveral times during install, what is th
e
procedures if I don't want SQL Server to auto startup during reboot?
Steps:
01) Offline "passive" node from cluster admin.
02) Shut down "passive" node server.
03) Offline "active" node SQL Server Group
04) From OS Services, change SQL Server to "Not auto startup"
05) Install application
06) Reboot active server
07) ....
Is the above procedures ok?
Please advise! Thanks!
Henrycross-posted to microsoft.public.sqlserver.clustering
*mike hodgson*
blog: http://sqlnerd.blogspot.com
Henry wrote:

>Dear Sir,
>If I needed to install something to the active then passive node one by one
>and required to restart the server serveral times during install, what is t
he
>procedures if I don't want SQL Server to auto startup during reboot?
>Steps:
>01) Offline "passive" node from cluster admin.
>02) Shut down "passive" node server.
>03) Offline "active" node SQL Server Group
>04) From OS Services, change SQL Server to "Not auto startup"
>05) Install application
>06) Reboot active server
>07) ....
> Is the above procedures ok?
>Please advise! Thanks!
>Henry
>
>

Clustered SQL Server 2000 to 2005 Upgrade

I would like to upgrade a production active/passive SQL Server 2000 cluster to SQL Server 2005.

I've read all of the documentation I could find, and doing an in-place upgrade seems to be the way to go. (Despite the fact it scares the hell out of me.

But throughout all the documentation, I've yet to see some simple and fairly important questions answered.

How does the process of upgrading SQL Server work when you're dealing with a cluster?

Do you upgrade one machine then the other? If so, do you upgrade the active node first, or the passive node?

What happens if you're forced to failover from one instance to the other before you've had a chance to upgrade both to 2005? In other words, you failover from 2005 to 2000. Would that even work?

What happens if your upgrades fails for some reason? Is it easy to rollback the installation? If not, will reinstalling SQL Server 2000 cause any issues? Will it remember the previous configuration and simply fix the broken install?

Any help/insight would be greatly appreciated.

Can anybody offer any advice on this?|||Moved to ...Availability forum.|||Maybe I can help. I, along with our network admin, spent a solid 2-3 weeks working on upgrading a active/active cluster to SQL 2005 from 2000. From my experience, it was incredibly simple, yet ridiculously hard. Unless you have every single setting correct on the cluster you will likely run into problems....we did. Here is how we eventually were successful:

1. Fail all active nodes over to one node (I'll call the primary node).
2. Make sure MSDTC is a clustered resource on the cluster. ( we can a test cluster setup and forgot to do this).
3. Install the upgrade to the primary node. There was a little bit of ambiguity when running the install that makes you think that it is going to install it on the 2nd node as well. In my situation, it didnt.
4. After installing on the first node, reboot.
5. Fail over all nodes to the 2ndary node and install the upgrade.
6. Reboot.
7. Failover to primary and install the service pack.
8. Reboot.
9. Failover to the 2ndard and install the service pack.

I am pretty sure these are the steps we followed that worked for us. Most likely, this isn't the recommended course of action of making the upgrade, but it worked. Make sure that when you do install the upgrade, that you install the SQL client tools on the first node. If you don't, you will run into problems later.

If someone else has had a better experience and would like to share their steps to success, please, please do.

Hope this helped,
Tim|||Thanks for your insight. It is incredibly frustrating that there is almost no documentation on this process.

I'm a little confused by your process. You say in step 4 that after you install you should reboot the first node. Does this mean you have downtime or does this cause a failover to other nodes? (I assume it doesn't since you forced the failover to the primary node before starting the process.)

You say in step 5 that you fail over to the secondary node. So this means you're failing over from SQL Server 2005 (on the primary) to SQL Server 2000 (on the secondary). If that works, can we simply fail over to the secondary before we reboot during step 4, thereby avoiding downtime?

Your situation is slightly different than mine since my cluster is active/passive with just two machines. Using your process as a template, mine would look something like:

1.) Install the upgrade on node 1.
2.) Force a failover to node 2 (which is still running SQL Server 2000).
3.) Reboot node 1. Wait for node 1 to restart.
4.) Install the upgrade to node 2.
5.) Force a failover to node 1.
6.) Reboot node 2.

Does this seem correct?
|||

RMD: Did you complete this successfully following your steps? We have the same configuration you do and any previous experience advice would be helpful.

thanks

Clustered SQL Server 2000 to 2005 Upgrade

I would like to upgrade a production active/passive SQL Server 2000 cluster to SQL Server 2005.

I've read all of the documentation I could find, and doing an in-place upgrade seems to be the way to go. (Despite the fact it scares the hell out of me.

But throughout all the documentation, I've yet to see some simple and fairly important questions answered.

How does the process of upgrading SQL Server work when you're dealing with a cluster?

Do you upgrade one machine then the other? If so, do you upgrade the active node first, or the passive node?

What happens if you're forced to failover from one instance to the other before you've had a chance to upgrade both to 2005? In other words, you failover from 2005 to 2000. Would that even work?

What happens if your upgrades fails for some reason? Is it easy to rollback the installation? If not, will reinstalling SQL Server 2000 cause any issues? Will it remember the previous configuration and simply fix the broken install?

Any help/insight would be greatly appreciated.

Can anybody offer any advice on this?|||Moved to ...Availability forum.|||Maybe I can help. I, along with our network admin, spent a solid 2-3 weeks working on upgrading a active/active cluster to SQL 2005 from 2000. From my experience, it was incredibly simple, yet ridiculously hard. Unless you have every single setting correct on the cluster you will likely run into problems....we did. Here is how we eventually were successful:

1. Fail all active nodes over to one node (I'll call the primary node).
2. Make sure MSDTC is a clustered resource on the cluster. ( we can a test cluster setup and forgot to do this).
3. Install the upgrade to the primary node. There was a little bit of ambiguity when running the install that makes you think that it is going to install it on the 2nd node as well. In my situation, it didnt.
4. After installing on the first node, reboot.
5. Fail over all nodes to the 2ndary node and install the upgrade.
6. Reboot.
7. Failover to primary and install the service pack.
8. Reboot.
9. Failover to the 2ndard and install the service pack.

I am pretty sure these are the steps we followed that worked for us. Most likely, this isn't the recommended course of action of making the upgrade, but it worked. Make sure that when you do install the upgrade, that you install the SQL client tools on the first node. If you don't, you will run into problems later.

If someone else has had a better experience and would like to share their steps to success, please, please do.

Hope this helped,
Tim|||Thanks for your insight. It is incredibly frustrating that there is almost no documentation on this process.

I'm a little confused by your process. You say in step 4 that after you install you should reboot the first node. Does this mean you have downtime or does this cause a failover to other nodes? (I assume it doesn't since you forced the failover to the primary node before starting the process.)

You say in step 5 that you fail over to the secondary node. So this means you're failing over from SQL Server 2005 (on the primary) to SQL Server 2000 (on the secondary). If that works, can we simply fail over to the secondary before we reboot during step 4, thereby avoiding downtime?

Your situation is slightly different than mine since my cluster is active/passive with just two machines. Using your process as a template, mine would look something like:

1.) Install the upgrade on node 1.
2.) Force a failover to node 2 (which is still running SQL Server 2000).
3.) Reboot node 1. Wait for node 1 to restart.
4.) Install the upgrade to node 2.
5.) Force a failover to node 1.
6.) Reboot node 2.

Does this seem correct?
|||

RMD: Did you complete this successfully following your steps? We have the same configuration you do and any previous experience advice would be helpful.

thanks

Clustered SQL Server 2000 to 2005 Upgrade

I would like to upgrade a production active/passive SQL Server 2000 cluster to SQL Server 2005.

I've read all of the documentation I could find, and doing an in-place upgrade seems to be the way to go. (Despite the fact it scares the hell out of me.

But throughout all the documentation, I've yet to see some simple and fairly important questions answered.

How does the process of upgrading SQL Server work when you're dealing with a cluster?

Do you upgrade one machine then the other? If so, do you upgrade the active node first, or the passive node?

What happens if you're forced to failover from one instance to the other before you've had a chance to upgrade both to 2005? In other words, you failover from 2005 to 2000. Would that even work?

What happens if your upgrades fails for some reason? Is it easy to rollback the installation? If not, will reinstalling SQL Server 2000 cause any issues? Will it remember the previous configuration and simply fix the broken install?

Any help/insight would be greatly appreciated.

Can anybody offer any advice on this?|||Moved to ...Availability forum.|||Maybe I can help. I, along with our network admin, spent a solid 2-3 weeks working on upgrading a active/active cluster to SQL 2005 from 2000. From my experience, it was incredibly simple, yet ridiculously hard. Unless you have every single setting correct on the cluster you will likely run into problems....we did. Here is how we eventually were successful:

1. Fail all active nodes over to one node (I'll call the primary node).
2. Make sure MSDTC is a clustered resource on the cluster. ( we can a test cluster setup and forgot to do this).
3. Install the upgrade to the primary node. There was a little bit of ambiguity when running the install that makes you think that it is going to install it on the 2nd node as well. In my situation, it didnt.
4. After installing on the first node, reboot.
5. Fail over all nodes to the 2ndary node and install the upgrade.
6. Reboot.
7. Failover to primary and install the service pack.
8. Reboot.
9. Failover to the 2ndard and install the service pack.

I am pretty sure these are the steps we followed that worked for us. Most likely, this isn't the recommended course of action of making the upgrade, but it worked. Make sure that when you do install the upgrade, that you install the SQL client tools on the first node. If you don't, you will run into problems later.

If someone else has had a better experience and would like to share their steps to success, please, please do.

Hope this helped,
Tim|||Thanks for your insight. It is incredibly frustrating that there is almost no documentation on this process.

I'm a little confused by your process. You say in step 4 that after you install you should reboot the first node. Does this mean you have downtime or does this cause a failover to other nodes? (I assume it doesn't since you forced the failover to the primary node before starting the process.)

You say in step 5 that you fail over to the secondary node. So this means you're failing over from SQL Server 2005 (on the primary) to SQL Server 2000 (on the secondary). If that works, can we simply fail over to the secondary before we reboot during step 4, thereby avoiding downtime?

Your situation is slightly different than mine since my cluster is active/passive with just two machines. Using your process as a template, mine would look something like:

1.) Install the upgrade on node 1.
2.) Force a failover to node 2 (which is still running SQL Server 2000).
3.) Reboot node 1. Wait for node 1 to restart.
4.) Install the upgrade to node 2.
5.) Force a failover to node 1.
6.) Reboot node 2.

Does this seem correct?
|||

RMD: Did you complete this successfully following your steps? We have the same configuration you do and any previous experience advice would be helpful.

thanks

Clustered Active/Active in Single-user mode

What is the right procedure to start an instance of a clustered Active/Active Sql Server ?
The online-book unspecifically writes:
From a command prompt, enter:
sqlservr.exe -c -m
But some KB Technet articles say do start/stop SQL instance only from cluster administrator!
So how to do it ?
Thanks!
Michele Moglia
For normal operating procedures the proper method is to start from the
Cluster Administator.
Starting from the command prompt with sqlservr.exe -c -m is a trouble
shooting technique. It starts SQL Server as an application in single user
mode and as such would be pretty useless in a production environment.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||Ok but if I have to restore the master db of the clustered sql server instance
I have to start the instance in single-user mode so can I start from command prompt
without any fear or problem ?
Thanks
Michele Moglia