Do I need Enterprise to do clustering?

I'm confused. Reading the SQL 2000 Resource Kit, it definitely says I need
Enterprise in order to do failover clustering. But reading the product
guide on the 2005 version says Standard has clustering capabilities. Is
this something new to 2005 or is it a different type of clustering? We're
looking at clustering and it's all new to me so I'd appreciate any help you
can give me. Thanks.
--Sandy
It is a different feature set for a different product SKU matrix. SQL 2000
requires Enterprise Edition for any clustering. SQL 2005 will allow
two-node clusters in Standard Edition. Both are MSCS failover clustering.
I have been recommending SQL 2005 Standard Edition for lower-cost clustering
with several of my clients. So far, all the systems have performed very
well.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Sandy Proesch" <sproe@.spamcop.net> wrote in message
news:%23dNoaEFSGHA.5908@.TK2MSFTNGP14.phx.gbl...
> I'm confused. Reading the SQL 2000 Resource Kit, it definitely says I
> need Enterprise in order to do failover clustering. But reading the
> product guide on the 2005 version says Standard has clustering
> capabilities. Is this something new to 2005 or is it a different type of
> clustering? We're looking at clustering and it's all new to me so I'd
> appreciate any help you can give me. Thanks.
> --Sandy
>
|||Thank you, that is exactly what we're looking to do - a 2-node failover
cluster.
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:OeBsiWFSGHA.4440@.TK2MSFTNGP11.phx.gbl...
> It is a different feature set for a different product SKU matrix. SQL
> 2000 requires Enterprise Edition for any clustering. SQL 2005 will allow
> two-node clusters in Standard Edition. Both are MSCS failover clustering.
> I have been recommending SQL 2005 Standard Edition for lower-cost
> clustering with several of my clients. So far, all the systems have
> performed very well.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Sandy Proesch" <sproe@.spamcop.net> wrote in message
> news:%23dNoaEFSGHA.5908@.TK2MSFTNGP14.phx.gbl...
>
|||Make sure and check out the 64-bit and dual-core processors. No difference
in licensing costs to go with either or both, but you get a huge performance
boost.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Sandy Proesch" <sproe@.spamcop.net> wrote in message
news:%23Fq7LwFSGHA.4900@.TK2MSFTNGP09.phx.gbl...
> Thank you, that is exactly what we're looking to do - a 2-node failover
> cluster.
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:OeBsiWFSGHA.4440@.TK2MSFTNGP11.phx.gbl...
>
|||Geoff,
If you have to do an upgrade in place on a cluster from 2000 to 2005, can
you go from 2000 Enterprise to 2005 Standard without problems?
Thanks
Chris Wood
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:%23Q8l%23OGSGHA.1204@.TK2MSFTNGP12.phx.gbl...
> Make sure and check out the 64-bit and dual-core processors. No
> difference in licensing costs to go with either or both, but you get a
> huge performance boost.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Sandy Proesch" <sproe@.spamcop.net> wrote in message
> news:%23Fq7LwFSGHA.4900@.TK2MSFTNGP09.phx.gbl...
>
|||You cannot do this as an in-place upgrade. You can install a second
instance of SQL 2005 on the same hardware and do a database migration. I
would take the opportunity to build a cluster based on new hardware if your
system is more than a few years old.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:e4yn1oeSGHA.5884@.TK2MSFTNGP14.phx.gbl...
> Geoff,
> If you have to do an upgrade in place on a cluster from 2000 to 2005, can
> you go from 2000 Enterprise to 2005 Standard without problems?
> Thanks
> Chris Wood
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:%23Q8l%23OGSGHA.1204@.TK2MSFTNGP12.phx.gbl...
>
|||Geoff,
But we could upgrade SQL2000 Enterprise to SQL2005 Enterprise in place could
we not?
Chris
Currently there is no plan to purchase new hardware for the clustered
production server.
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:%23okTDKfSGHA.5808@.TK2MSFTNGP12.phx.gbl...
> You cannot do this as an in-place upgrade. You can install a second
> instance of SQL 2005 on the same hardware and do a database migration. I
> would take the opportunity to build a cluster based on new hardware if
> your system is more than a few years old.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:e4yn1oeSGHA.5884@.TK2MSFTNGP14.phx.gbl...
>
|||Now that I have tested (for giggles only) and it works, but I really hate
upgrades!! Especially for HA systems!
Cheers,
Rodney R. Fournier
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://www.msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
ClusterHelp.com is a Microsoft Certified Gold Partner
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23MmSCyfSGHA.4600@.TK2MSFTNGP11.phx.gbl...
> Geoff,
> But we could upgrade SQL2000 Enterprise to SQL2005 Enterprise in place
> could we not?
> Chris
> Currently there is no plan to purchase new hardware for the clustered
> production server.
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:%23okTDKfSGHA.5808@.TK2MSFTNGP12.phx.gbl...
>
|||In theory, yes. In practice, I have heard of a lot of problems with the
in-place cluster upgrade wizard and would not recommend that path at this
time. Side-by-side or new platform is the safest way to go.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23MmSCyfSGHA.4600@.TK2MSFTNGP11.phx.gbl...
> Geoff,
> But we could upgrade SQL2000 Enterprise to SQL2005 Enterprise in place
> could we not?
> Chris
> Currently there is no plan to purchase new hardware for the clustered
> production server.
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:%23okTDKfSGHA.5808@.TK2MSFTNGP12.phx.gbl...
>
|||Thank you Geoff. Not really the sort of news I wanted to hear.
Chris
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:%23$b804fSGHA.4616@.TK2MSFTNGP10.phx.gbl...
> In theory, yes. In practice, I have heard of a lot of problems with the
> in-place cluster upgrade wizard and would not recommend that path at this
> time. Side-by-side or new platform is the safest way to go.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23MmSCyfSGHA.4600@.TK2MSFTNGP11.phx.gbl...
>

do I need a domain in order to run a cluster?

Hi, I am a complete newbie with windows clustering -
still reading the white papers etc. From what I have read
it seems that I need a Windows Domain in order to run
clustering. Is this true? Is there any way I can cluster
SQL server without having to setup a domain?
thanks
christos
Yes. You must have a domain to run a cluster. No, you can't get around
having a domain.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Christos Kritikos" <anonymous@.discussions.microsoft.com> wrote in message
news:030001c49b56$400d9060$a301280a@.phx.gbl...
> Hi, I am a complete newbie with windows clustering -
> still reading the white papers etc. From what I have read
> it seems that I need a Windows Domain in order to run
> clustering. Is this true? Is there any way I can cluster
> SQL server without having to setup a domain?
> thanks
> christos
>
|||Hi Geoff,
I too have the same doubt. What are some Technical
reasons forcing cluster to run in a domain?
Thanks
Chip.
>--Original Message--
>Yes. You must have a domain to run a cluster. No, you
can't get around
>having a domain.
>--
>Geoff N. Hiten
>Microsoft SQL Server MVP
>Senior Database Administrator
>Careerbuilder.com
>I support the Professional Association for SQL Server
>www.sqlpass.org
>"Christos Kritikos"
<anonymous@.discussions.microsoft.com> wrote in message[vbcol=seagreen]
>news:030001c49b56$400d9060$a301280a@.phx.gbl...
read[vbcol=seagreen]
cluster
>
>.
>
|||You have to have a common security context for the cluster service to manage
resources on multiple machines. Parallel usernames and paswords will not
work. You have to have a domain (NT4 or AD) to provide cluster-wide access
to resources.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Chip" <anonymous@.discussions.microsoft.com> wrote in message
news:150e01c49c9d$f0cd9560$a301280a@.phx.gbl...[vbcol=seagreen]
> Hi Geoff,
> I too have the same doubt. What are some Technical
> reasons forcing cluster to run in a domain?
> Thanks
> Chip.
> can't get around
> <anonymous@.discussions.microsoft.com> wrote in message
> read
> cluster
|||There is some good information in
281662 Windows 2000 and Windows Server 2003 Cluster Nodes As Domain Controllers
http://support.microsoft.com/?id=281662
Here is a section from the same.
To have Windows Clustering function properly (where the Cluster service starts on each node) the node that forms the cluster must be able to validate the Cluster service domain account, which is the account that you
configure during the Windows Clustering installation. To accomplish this, each node must be able to establish a secure channel with a domain controller to validate this account. If the node cannot validate the
account, the Cluster service does not start. This is also true for other clustered programs that must have account validation for services to start, such as Microsoft SQL Server and Microsoft Exchange.
If you have a cluster deployment in which there is no link with either a Windows NT 4.0 domain, a Windows 2000 domain, or a Windows Server 2003 domain, you must configure the cluster nodes as domain
controllers so that the Cluster service account can always be validated to allow for proper cluster functionality.
If the connectivity between cluster nodes and domain controllers is such that the link is either slow or unreliable, consider having a domain controller co-located with the cluster, or configuring the cluster nodes as
domain controllers.
Consider the following important points when you are deploying Windows Clustering nodes as domain controllers:
--> See the above KB (http://support.microsoft.com/?id=281662)
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
|||Thanks Geoff & Uttam.
Chip
>--Original Message--
>There is some good information in
>281662 Windows 2000 and Windows Server 2003 Cluster Nodes
As Domain Controllers
>http://support.microsoft.com/?id=281662
>Here is a section from the same.
>To have Windows Clustering function properly (where the
Cluster service starts on each node) the node that forms
the cluster must be able to validate the Cluster service
domain account, which is the account that you
>configure during the Windows Clustering installation. To
accomplish this, each node must be able to establish a
secure channel with a domain controller to validate this
account. If the node cannot validate the
>account, the Cluster service does not start. This is also
true for other clustered programs that must have account
validation for services to start, such as Microsoft SQL
Server and Microsoft Exchange.
>If you have a cluster deployment in which there is no
link with either a Windows NT 4.0 domain, a Windows 2000
domain, or a Windows Server 2003 domain, you must
configure the cluster nodes as domain
>controllers so that the Cluster service account can
always be validated to allow for proper cluster
functionality.
>If the connectivity between cluster nodes and domain
controllers is such that the link is either slow or
unreliable, consider having a domain controller co-located
with the cluster, or configuring the cluster nodes as
>domain controllers.
>Consider the following important points when you are
deploying Windows Clustering nodes as domain controllers:
> --> See the above KB
(http://support.microsoft.com/?id=281662)
>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
>
>.
>

Distributed transaction with clustering server

I also got the same issue in my company's system.
My alternative option is to remove a pair of
"begin/commit tran" statements.
I tried without "begin/commit trans" to fail joined-tables
update from two linked servers, and it can prevent
asynchronized transaction on that table update, and thus
preserve transactional consistency. Maybe
that "begin/commit tran" has been implicitly enclosed!
Does anyone know why?
Regards,
Alfred XYZ

>--Original Message--
>I can't perform a distributed transaction between a
remote
>server to the central server.
>I have 3 sql server 2000 enterprise edition. 2 of them
are
>installed on win2K server (LOCAL1, LOCAL2) and the other
>(CENTRAL_SQL) is installed on clustering win2K server.
>None of them is in domain.
>Linked servers are defined well between them and I can
>perform select statement from any server to any other
>server.
>I can also perform a distributed transaction between the
>remote servers, from LOCAL1 to LOCAL2 and contrarily:
>set xact_abort on
>begin distributed tran
>select count(*) from
>LOCAL1.tempdb.INFORMATION_SCHEMA.TABLES
>commit
>set xact_abort off
>MSDTC service starts up with local system account or
other
>administrators belonging account.
>I can also ping the local servers from the central and
>even manage them using the Active Directory.
>When I perform a distributed transaction between a remote
>server (LOCAL1 or LOCAL2) and the central server I get an
>error:
>Server: Msg 7391, Level 16, State 1, Line 5
>The operation could not be performed because the OLE DB
>provider 'SQLOLEDB' was unable to begin a distributed
>transaction.
>[OLE/DB provider returned message: New transaction cannot
>enlist in the specified transaction coordinator. ]
>OLE DB error trace [OLE/DB Provider 'SQLOLEDB'
>ITransactionJoin::JoinTransaction returned 0x8004d00a].
>What am I doing wrong?
>Thanks,
>Yuval Peleg
>DBA, Nice Systems
>.
>
We solved the problem by organizing the DNS addresses at all servers:
The clustering server is our Domain Controller, so it has to contain the
addresses of all participant servers: itself physical nodes, its virtual
address and the remote SQL server addresses.
At the local servers we signed, in TCP/IP properties, the first node of the
clustering server as the "preferred DNS server" and the second node the
"alternate DNS server".
"Alfred XYZ" <alfredxyz@.hotmail.com> wrote in message
news:0ee901c4d5f6$fc1fa560$a501280a@.phx.gbl...[vbcol=seagreen]
>I also got the same issue in my company's system.
> My alternative option is to remove a pair of
> "begin/commit tran" statements.
> I tried without "begin/commit trans" to fail joined-tables
> update from two linked servers, and it can prevent
> asynchronized transaction on that table update, and thus
> preserve transactional consistency. Maybe
> that "begin/commit tran" has been implicitly enclosed!
> Does anyone know why?
> Regards,
> Alfred XYZ
> remote
> are
> other

Distributed transaction with clustering server

I can't perform a distributed transaction between a remote
server to the central server.
I have 3 sql server 2000 enterprise edition. 2 of them are
installed on win2K server (LOCAL1, LOCAL2) and the other
(CENTRAL_SQL) is installed on clustering win2K server.
None of them is in domain.
Linked servers are defined well between them and I can
perform select statement from any server to any other
server.
I can also perform a distributed transaction between the
remote servers, from LOCAL1 to LOCAL2 and contrarily:
set xact_abort on
begin distributed tran
select count(*) from
LOCAL1.tempdb.INFORMATION_SCHEMA.TABLES
commit
set xact_abort off
MSDTC service starts up with local system account or other
administrators belonging account.
I can also ping the local servers from the central and
even manage them using the Active Directory.
When I perform a distributed transaction between a remote
server (LOCAL1 or LOCAL2) and the central server I get an
error:
Server: Msg 7391, Level 16, State 1, Line 5
The operation could not be performed because the OLE DB
provider 'SQLOLEDB' was unable to begin a distributed
transaction.
[OLE/DB provider returned message: New transaction cannot
enlist in the specified transaction coordinator. ]
OLE DB error trace [OLE/DB Provider 'SQLOLEDB'
ITransactionJoin::JoinTransaction returned 0x8004d00a].
What am I doing wrong?
Thanks,
Yuval Peleg
DBA, Nice SystemsLook for the following entry in the SQL Server errorlog:
Attempting to initialize Distributed Transaction Coordinator.
Is there an error after it?
If so, have you run comclust on both nodes of the cluster to make MSDTC
cluster aware?
I not run it on both nodes and then take SQL Server off line and back on
line. Then try your query.
Rand
This posting is provided "as is" with no warranties and confers no rights.|||There is a masage before it:
"Using dynamic lock allocation. [2500] Lock Blocks, [5000] Lock Owne
r
Blocks."
I run comclust on both nodes.
Thanks,
Yuval Peleg
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!

Distributed transaction with clustering server

I can't perform a distributed transaction between a remote
server to the central server.
I have 3 sql server 2000 enterprise edition. 2 of them are
installed on win2K server (LOCAL1, LOCAL2) and the other
(CENTRAL_SQL) is installed on clustering win2K server.
None of them is in domain.
Linked servers are defined well between them and I can
perform select statement from any server to any other
server.
I can also perform a distributed transaction between the
remote servers, from LOCAL1 to LOCAL2 and contrarily:
set xact_abort on
begin distributed tran
select count(*) from
LOCAL1.tempdb.INFORMATION_SCHEMA.TABLES
commit
set xact_abort off
MSDTC service starts up with local system account or other
administrators belonging account.
I can also ping the local servers from the central and
even manage them using the Active Directory.
When I perform a distributed transaction between a remote
server (LOCAL1 or LOCAL2) and the central server I get an
error:
Server: Msg 7391, Level 16, State 1, Line 5
The operation could not be performed because the OLE DB
provider 'SQLOLEDB' was unable to begin a distributed
transaction.
[OLE/DB provider returned message: New transaction cannot
enlist in the specified transaction coordinator. ]
OLE DB error trace [OLE/DB Provider 'SQLOLEDB'
ITransactionJoin::JoinTransaction returned 0x8004d00a].
What am I doing wrong?
Thanks,
Yuval Peleg
DBA, Nice Systems
Look for the following entry in the SQL Server errorlog:
Attempting to initialize Distributed Transaction Coordinator.
Is there an error after it?
If so, have you run comclust on both nodes of the cluster to make MSDTC
cluster aware?
I not run it on both nodes and then take SQL Server off line and back on
line. Then try your query.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||There is a masage before it:
"Using dynamic lock allocation. [2500] Lock Blocks, [5000] Lock Owner
Blocks."
I run comclust on both nodes.
Thanks,
Yuval Peleg
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!

Distributed Transaction Coordinator/Cluster

Hi there. I'm new to this clustering mularky and I've a couple of questions
regarding a linked-server query I have.
1. Server A is a regular server. Server B is a clustered server with shared
storage.
From A, I want to call a stored proc that sits on B.
Q: I need to add B(cluster) as a Linked server on A - Do I need to add A as
a linked server on B also?
2. Depending on the answer to my first question, I might need to get MSDTC
running on the clustered server - is there some special configuration I
should undergo? I've come across some msdn articles regarding use of
"Comclust.exe" but I don't know if I need to use it.....
Any help would be appreciated - I'm a bit worried about this stuff!
I can answer #2 - Follow 817064, then 301600
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://www.msmvps.com/clustering - Blog
"len" <len@.discussions.microsoft.com> wrote in message
news:D1696F91-B3EF-485F-A362-785E910D02D7@.microsoft.com...
> Hi there. I'm new to this clustering mularky and I've a couple of
> questions
> regarding a linked-server query I have.
> 1. Server A is a regular server. Server B is a clustered server with
> shared
> storage.
> From A, I want to call a stored proc that sits on B.
> Q: I need to add B(cluster) as a Linked server on A - Do I need to add A
> as
> a linked server on B also?
>
> 2. Depending on the answer to my first question, I might need to get MSDTC
> running on the clustered server - is there some special configuration I
> should undergo? I've come across some msdn articles regarding use of
> "Comclust.exe" but I don't know if I need to use it.....
> Any help would be appreciated - I'm a bit worried about this stuff!
|||Dhanks for that - it's just what I was looking for! I have one question
regarding 301600 though:
Part of the instructions state that after creating a Cluster group for
MSDTC, I need to add an IP Address resource to that group.
What I don't know is: where should this IP address come from? I've already
tried the IP address of both of my cluster nodes AND the virtual IPAddress of
my shared storage/SQL server but errors are thrown up about these being in
use already. do I need to create an entirely ne IP address?
thanks again!
"Rodney R. Fournier [MVP]" wrote:

> I can answer #2 - Follow 817064, then 301600
> Cheers,
> Rod
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering
> http://www.msmvps.com/clustering - Blog
> "len" <len@.discussions.microsoft.com> wrote in message
> news:D1696F91-B3EF-485F-A362-785E910D02D7@.microsoft.com...
>
>
|||You are most welcome.
The IP has to be a new IP address, it needs to be in the same subnet as the
SQL & Cluster IP.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://www.msmvps.com/clustering - Blog
"len" <len@.discussions.microsoft.com> wrote in message
news:08F90F15-972F-41D6-87E1-F34C1EBCFAB3@.microsoft.com...[vbcol=seagreen]
> Dhanks for that - it's just what I was looking for! I have one question
> regarding 301600 though:
> Part of the instructions state that after creating a Cluster group for
> MSDTC, I need to add an IP Address resource to that group.
> What I don't know is: where should this IP address come from? I've already
> tried the IP address of both of my cluster nodes AND the virtual IPAddress
> of
> my shared storage/SQL server but errors are thrown up about these being in
> use already. do I need to create an entirely ne IP address?
> thanks again!
>
> "Rodney R. Fournier [MVP]" wrote: