Hi!
I have a customer with a 2-node active/active sql2k cluster hosted on
w2k.
We now want to run this on w2k3 and we also want to build up the
cluster to have a 4-node active/active/active/active sql2k cluster.
Our plan is to do it in two steps as follow. We take the current 2
nodes offline and unplug them from the network and then install the 2
new nodes with w2k3 using the original ipaddresses and netbiosname and
then restoring the sql2k (one virtuel server and one named instance).
This should give us the same cluster as before but with sql2k running
on w2k3.
This is because the customer will be able to unplug the new nodes and
replug the old ones if there is any trouble with the new nodes.
Then after a few days it's time to reinstall the old nodes with w2k3
and new netbiosnames and connect them to the cluster so we get our
4-node. Then install 2 new named sql instances.
We want all 4 sql instances to be able to run in all 4 nodes.
Now some questions!
When I install a new named instance (on node 3) it will be available
in the other 2 nodes, but will the original sql2k on these 2 nodes be
available in node 3? The same question with node 4.
Is there some problems with sql2k and w2k3 because it is no way to
uninstall sql2k under MSCS? In w2k I'm able to remove it under the
control panel.
/Peter
I actually did a 2 to 4 node cluster upgrade. During the transition, I
replaced the original nodes with new hardware, so I went from 2 nodes with 4
procs each to 4 nodes with 8 procs each. I also went from 2 instances to 3
instances of SQL server. Here is how I did it.
Upgrade the existing nodes (1 at a time) to W2K3. Add the new nodes.
Install SQL and Service packs to the new nodes. Fail the cluster over to
the new nodes. Remove the old nodes and replace with new hardware. At this
point, I would drop those nodes and rebuild them from scratch. Upgrad for
2003 is good, but I prefer a clean build. Add the new nodes to SQL and
apply the service packs. Install the third SQL instance and service pack.
As for your two questions, whenever you add or remove a node, you will need
to use the SQL install CD to add or remove the node from the SQL
installation. This is in addition to evicting or adding the node from the
cluster tool. Choose Advanced Options and Maintain Failover Clustering.
Read BOL on failover clustering for more details.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Peter Lindberg" <peter.lindbergTAKE@.AWAYmartinsson.se> wrote in message
news:40641e4b.73299028@.msnews.microsoft.com...
> Hi!
> I have a customer with a 2-node active/active sql2k cluster hosted on
> w2k.
> We now want to run this on w2k3 and we also want to build up the
> cluster to have a 4-node active/active/active/active sql2k cluster.
> Our plan is to do it in two steps as follow. We take the current 2
> nodes offline and unplug them from the network and then install the 2
> new nodes with w2k3 using the original ipaddresses and netbiosname and
> then restoring the sql2k (one virtuel server and one named instance).
> This should give us the same cluster as before but with sql2k running
> on w2k3.
> This is because the customer will be able to unplug the new nodes and
> replug the old ones if there is any trouble with the new nodes.
> Then after a few days it's time to reinstall the old nodes with w2k3
> and new netbiosnames and connect them to the cluster so we get our
> 4-node. Then install 2 new named sql instances.
> We want all 4 sql instances to be able to run in all 4 nodes.
> Now some questions!
> When I install a new named instance (on node 3) it will be available
> in the other 2 nodes, but will the original sql2k on these 2 nodes be
> available in node 3? The same question with node 4.
> Is there some problems with sql2k and w2k3 because it is no way to
> uninstall sql2k under MSCS? In w2k I'm able to remove it under the
> control panel.
> /Peter
>
|||Thank's for your advice Geoff.
The questions comes after a test install I have done and there was a
few odd things that happend.
We use Veritas Volume Manager to allow dynamic disc. I'm not involved
in that part, but the storage techi say's that the veritas code for
w2k can't handle an upgrade of windows to w2k3 and veritas w2k code
can't be upgraded to w2k3 version and still running on w2k. That's why
I want to install w2k3 on new hw with the new codepack from Verirtas.
In our test we run into the following situation:
On node one where we installed the veritas code we connected to disk
and then set up the cluster and then the first sql virtual server. At
that time the other node didn't have the veritas code yet, it only had
w2k3 and was not part of the ckuster. That means all disk was
available to node one. That node was installed with a named instance
where I by the way had to use instruction from KB815431 and sp3a. That
was after the install of sql2k failed once.
After this we set up the veritas code on the other machine with
clustersupport and added it to the cluster. We made an error labeling
one disk with the same name as the other node(cut and paste). When
changing that we had to uninstall the veritas code and break the
cluster. On with veritas code again without clustersupport so we get a
possiblity to chage that label. Then get the node in the cluster
again.
Here I installed a new virtuel server with a new named instance and
sp3a on the second node. This setup was without problem and the only
odd thing was that the dtc service still was automatic.
Next step was to se that the instances could move between the nodes.
The second node could move to the first, but the first could not move
to the second. We found out that the first node have the service for
both instances but the second only the service for the last installed
instance.
I can't se why this happend.
This is why I'm conserned about adding 2 more nodes after a week. Will
the initial two be able to move to new once? If the problem I
described is created by some of my mistake I will still will do this
upgrade in 2 steps, but if there is this problem we have to reinstall
the old nodes to w2k3 at the same time.
I will try to recreate it in vmware workstation, but if someone know
anything about this I will be happy to hear it.
/Peter
On Fri, 26 Mar 2004 10:26:22 -0500, "Geoff N. Hiten"
<SRDBA@.Careerbuilder.com> wrotc:
>I actually did a 2 to 4 node cluster upgrade. During the transition, I
>replaced the original nodes with new hardware, so I went from 2 nodes with 4
>procs each to 4 nodes with 8 procs each. I also went from 2 instances to 3
>instances of SQL server. Here is how I did it.
>Upgrade the existing nodes (1 at a time) to W2K3. Add the new nodes.
>Install SQL and Service packs to the new nodes. Fail the cluster over to
>the new nodes. Remove the old nodes and replace with new hardware. At this
>point, I would drop those nodes and rebuild them from scratch. Upgrad for
>2003 is good, but I prefer a clean build. Add the new nodes to SQL and
>apply the service packs. Install the third SQL instance and service pack.
>As for your two questions, whenever you add or remove a node, you will need
>to use the SQL install CD to add or remove the node from the SQL
>installation. This is in addition to evicting or adding the node from the
>cluster tool. Choose Advanced Options and Maintain Failover Clustering.
>Read BOL on failover clustering for more details.
>--
>Geoff N. Hiten
>Microsoft SQL Server MVP
>Senior Database Administrator
>Careerbuilder.com
>I support the Professional Association for SQL Server
>www.sqlpass.org
>"Peter Lindberg" <peter.lindbergTAKE@.AWAYmartinsson.se> wrote in message
>news:40641e4b.73299028@.msnews.microsoft.com...
>
|||You can determine which nodes can host which instances. Using the Install
CD and the Advanced Options tab, you can add or remove individual nodes to a
particular instance. I added each instance to each new node individually.
I then added the service pack to the new node/instance. Of course, I
rebooted each new node after each step, so there are a lot of reboots.
There is a new feature in W2k3 where you can expand basic cluster disks
without converting them to dynamic disks. That may eliminate the need for
Veritas Volume Manager.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Peter Lindberg" <peter.lindberg@.unigrid.se> wrote in message
news:406873b9.247543388@.msnews.microsoft.com...
> Thank's for your advice Geoff.
> The questions comes after a test install I have done and there was a
> few odd things that happend.
> We use Veritas Volume Manager to allow dynamic disc. I'm not involved
> in that part, but the storage techi say's that the veritas code for
> w2k can't handle an upgrade of windows to w2k3 and veritas w2k code
> can't be upgraded to w2k3 version and still running on w2k. That's why
> I want to install w2k3 on new hw with the new codepack from Verirtas.
> In our test we run into the following situation:
> On node one where we installed the veritas code we connected to disk
> and then set up the cluster and then the first sql virtual server. At
> that time the other node didn't have the veritas code yet, it only had
> w2k3 and was not part of the ckuster. That means all disk was
> available to node one. That node was installed with a named instance
> where I by the way had to use instruction from KB815431 and sp3a. That
> was after the install of sql2k failed once.
> After this we set up the veritas code on the other machine with
> clustersupport and added it to the cluster. We made an error labeling
> one disk with the same name as the other node(cut and paste). When
> changing that we had to uninstall the veritas code and break the
> cluster. On with veritas code again without clustersupport so we get a
> possiblity to chage that label. Then get the node in the cluster
> again.
> Here I installed a new virtuel server with a new named instance and
> sp3a on the second node. This setup was without problem and the only
> odd thing was that the dtc service still was automatic.
> Next step was to se that the instances could move between the nodes.
> The second node could move to the first, but the first could not move
> to the second. We found out that the first node have the service for
> both instances but the second only the service for the last installed
> instance.
> I can't se why this happend.
> This is why I'm conserned about adding 2 more nodes after a week. Will
> the initial two be able to move to new once? If the problem I
> described is created by some of my mistake I will still will do this
> upgrade in 2 steps, but if there is this problem we have to reinstall
> the old nodes to w2k3 at the same time.
> I will try to recreate it in vmware workstation, but if someone know
> anything about this I will be happy to hear it.
> /Peter
>
> On Fri, 26 Mar 2004 10:26:22 -0500, "Geoff N. Hiten"
> <SRDBA@.Careerbuilder.com> wrotc:
with 4
3
this
for
pack.
need
the
>
|||I saw that under Advanced Options but the button was greymarked. It
must have happend something. Now I have done it i vmware and seen it
work.
Next will be the actual go later this week, and then two more nodes a
week later. I'll remember those reboots after each part. I get it that
before starting with node 4 you where up with SP3a on node 3.
/Peter
On Mon, 29 Mar 2004 09:39:03 -0500, "Geoff N. Hiten"
<SRDBA@.Careerbuilder.com> wrotc:
>You can determine which nodes can host which instances. Using the Install
>CD and the Advanced Options tab, you can add or remove individual nodes to a
>particular instance. I added each instance to each new node individually.
>I then added the service pack to the new node/instance. Of course, I
>rebooted each new node after each step, so there are a lot of reboots.
>There is a new feature in W2k3 where you can expand basic cluster disks
>without converting them to dynamic disks. That may eliminate the need for
>Veritas Volume Manager.
Showing posts with label 2-node. Show all posts
Showing posts with label 2-node. Show all posts
Monday, March 19, 2012
2-node cluster (Active/Passive) but with a catch!
Hi,
We have 2 blade servers and we need a clustering solution which will run
win2k3 and SQL 2005 in an Active/Passive mode. The catch is that our SAN will
not be in for another 5 weeks. The business needs to go live so I am trying
to find out what is the best way to handle this. I am thinking the following:
Install sql server 2005 on one server and run it as a stand alone until we
get the SAN. Then configure the second with the SAN and MSCS, migrate the
databases, rebuild the first server, install MSCS and join it to the cluster.
What do you guys think?
--
Senior DBA
MSc in CS, MCSE4, ITIL, IBM Certified MQ 5.3 Administrator
"I saw it work in a cartoon once so I am pretty sure I can do it."
It seems like you have a grip on the problem/solution.
Without some form of common storage resources, I don't see that you have
much of a choice.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"Sas" <Sas@.discussions.microsoft.com> wrote in message
news:7206318F-DC16-4C51-9D7A-DD59C441D863@.microsoft.com...
> Hi,
> We have 2 blade servers and we need a clustering solution which will run
> win2k3 and SQL 2005 in an Active/Passive mode. The catch is that our SAN
> will
> not be in for another 5 weeks. The business needs to go live so I am
> trying
> to find out what is the best way to handle this. I am thinking the
> following:
> Install sql server 2005 on one server and run it as a stand alone until we
> get the SAN. Then configure the second with the SAN and MSCS, migrate the
> databases, rebuild the first server, install MSCS and join it to the
> cluster.
> What do you guys think?
> --
> --
> Senior DBA
> MSc in CS, MCSE4, ITIL, IBM Certified MQ 5.3 Administrator
> "I saw it work in a cartoon once so I am pretty sure I can do it."
We have 2 blade servers and we need a clustering solution which will run
win2k3 and SQL 2005 in an Active/Passive mode. The catch is that our SAN will
not be in for another 5 weeks. The business needs to go live so I am trying
to find out what is the best way to handle this. I am thinking the following:
Install sql server 2005 on one server and run it as a stand alone until we
get the SAN. Then configure the second with the SAN and MSCS, migrate the
databases, rebuild the first server, install MSCS and join it to the cluster.
What do you guys think?
--
Senior DBA
MSc in CS, MCSE4, ITIL, IBM Certified MQ 5.3 Administrator
"I saw it work in a cartoon once so I am pretty sure I can do it."
It seems like you have a grip on the problem/solution.
Without some form of common storage resources, I don't see that you have
much of a choice.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"Sas" <Sas@.discussions.microsoft.com> wrote in message
news:7206318F-DC16-4C51-9D7A-DD59C441D863@.microsoft.com...
> Hi,
> We have 2 blade servers and we need a clustering solution which will run
> win2k3 and SQL 2005 in an Active/Passive mode. The catch is that our SAN
> will
> not be in for another 5 weeks. The business needs to go live so I am
> trying
> to find out what is the best way to handle this. I am thinking the
> following:
> Install sql server 2005 on one server and run it as a stand alone until we
> get the SAN. Then configure the second with the SAN and MSCS, migrate the
> databases, rebuild the first server, install MSCS and join it to the
> cluster.
> What do you guys think?
> --
> --
> Senior DBA
> MSc in CS, MCSE4, ITIL, IBM Certified MQ 5.3 Administrator
> "I saw it work in a cartoon once so I am pretty sure I can do it."
Tuesday, March 6, 2012
2005 x64
Hi all,
We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
SAN. We are considering moving to the x64 edition of SQL for performance
reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
and SQL as well. Can someone share any experiences about x64 environments? I
have heard some reports from users that it is not recommended for production
environments as it is unstable.
Would I need to re-code any of my tables/stored procs/functions etc?
TIA!We've done several implementations of the x64 version in our test, QA
and production environments and haven't experienced any issues. No
recoding should be necessary unless you've incorporated 32-bit API
calls into your SPs/functions.
On Sat, 28 Oct 2006 13:34:27 -0500, <param@.community.nospam> wrote:
>Hi all,
>We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
>SAN. We are considering moving to the x64 edition of SQL for performance
>reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
>and SQL as well. Can someone share any experiences about x64 environments?
I
>have heard some reports from users that it is not recommended for productio
n
>environments as it is unstable.
>Would I need to re-code any of my tables/stored procs/functions etc?
>TIA!
>|||I am running several production database on x64, without any problems.
param@.community.nospam wrote:
> Hi all,
> We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
> SAN. We are considering moving to the x64 edition of SQL for performance
> reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
> and SQL as well. Can someone share any experiences about x64 environments?
I
> have heard some reports from users that it is not recommended for producti
on
> environments as it is unstable.
> Would I need to re-code any of my tables/stored procs/functions etc?
> TIA!
>|||Any of those databases clustered?
Did you see a performance lift by moving from x86 to x64?
Thanks
"Theo Verweij" <tverweij@.xs4all.nl> wrote in message
news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...[vbcol=seagreen]
>I am running several production database on x64, without any problems.
> param@.community.nospam wrote:|||No, no clusters,
and yes, the performance has really improved.
But, to be honest it is almost impossible to tell if this performance
improvement is due to x64.
At this moment we are running on a temporary server.
The old server was a quad 900 Mhz XEON with 2Mb Cache, 8Gb Ram
(@.100Mhz), UW Scsii 3 15k Raid 5, with Win2k Ent anb SQL2000 Ent.
Now we are (temporary) running on a dual 2.8 Ghz XEON with 2Mb Cache, 4
Gb Ram (@.400Mhz) and a Serial ATA 7.2k software mirror, with Win2k3 std
x64 and SQL 2005 Std x64.
The current temporary server outperforms the old one by a factor 2 with
a load of 50 concurrent users (with a lot of inserts and updates), but
almost everything is different between the 2 machines.
The only thing I can say for sure is that we don't have any problems
with the x64 version.
param@.community.nospam wrote:
> Any of those databases clustered?
> Did you see a performance lift by moving from x86 to x64?
> Thanks
> "Theo Verweij" <tverweij@.xs4all.nl> wrote in message
> news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...
>|||Without detailed info, whether or not the others have experienced performanc
e
improvement with x64 probably won't mean a whole a lot to your particular ap
p
since the results are highly workload dependent. If you are considering goin
g
to x64 from x86, I suggest you treat it like any other production
change--test it first in your own environment with your own app before you
make the switch.
Linchi
"param@.community.nospam" wrote:
> Any of those databases clustered?
> Did you see a performance lift by moving from x86 to x64?
> Thanks
> "Theo Verweij" <tverweij@.xs4all.nl> wrote in message
> news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...
>|||Hi,
My understanding of your issue is that:
You prepared to migrate your SQL Server 2000 cluster to your SQL Server
2005 64 bit cluster and you wanted to know if there is some risk and if it
can lift the performance.
If I have misunderstood, please let me know.
Using 64 bit platform does not mean that the performance can be promoted
evidently, however it leaves a vast space for hardware upgrading. It can
provide higher hardware performance than 32 bit platform potentially, such
as memory capacity.
You can migrate your SQL Server 2000 32 bit cluster to your SQL Server 2005
64 bit cluster and you can take the following steps for the migration:
1. Backup all the databases on the current SQL Server 2000 cluster;
2. Export jobs script to a file;
3. Export users and logins script to a file:
4. Restore databases on the SQL Server 2005 cluster;
5. Create jobs by running the exported jobs script file;
6. Create users and passwords by running the exported script file.
Please refer to:
How to transfer logins and passwords between instances of SQL Server
http://support.microsoft.com/kb/246133/en-us
It is recommended that you perform a test before bring it to your
production environment.
If you have any other questions or concerns, please feel free to let me
know. It is my pleasure to be of assistance.
Charles Wang
Microsoft Online Community Support
========================================
==============
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
========================================
==============
This posting is provided "AS IS" with no warranties, and confers no rights.
========================================
==============
We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
SAN. We are considering moving to the x64 edition of SQL for performance
reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
and SQL as well. Can someone share any experiences about x64 environments? I
have heard some reports from users that it is not recommended for production
environments as it is unstable.
Would I need to re-code any of my tables/stored procs/functions etc?
TIA!We've done several implementations of the x64 version in our test, QA
and production environments and haven't experienced any issues. No
recoding should be necessary unless you've incorporated 32-bit API
calls into your SPs/functions.
On Sat, 28 Oct 2006 13:34:27 -0500, <param@.community.nospam> wrote:
>Hi all,
>We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
>SAN. We are considering moving to the x64 edition of SQL for performance
>reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
>and SQL as well. Can someone share any experiences about x64 environments?
I
>have heard some reports from users that it is not recommended for productio
n
>environments as it is unstable.
>Would I need to re-code any of my tables/stored procs/functions etc?
>TIA!
>|||I am running several production database on x64, without any problems.
param@.community.nospam wrote:
> Hi all,
> We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
> SAN. We are considering moving to the x64 edition of SQL for performance
> reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
> and SQL as well. Can someone share any experiences about x64 environments?
I
> have heard some reports from users that it is not recommended for producti
on
> environments as it is unstable.
> Would I need to re-code any of my tables/stored procs/functions etc?
> TIA!
>|||Any of those databases clustered?
Did you see a performance lift by moving from x86 to x64?
Thanks
"Theo Verweij" <tverweij@.xs4all.nl> wrote in message
news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...[vbcol=seagreen]
>I am running several production database on x64, without any problems.
> param@.community.nospam wrote:|||No, no clusters,
and yes, the performance has really improved.
But, to be honest it is almost impossible to tell if this performance
improvement is due to x64.
At this moment we are running on a temporary server.
The old server was a quad 900 Mhz XEON with 2Mb Cache, 8Gb Ram
(@.100Mhz), UW Scsii 3 15k Raid 5, with Win2k Ent anb SQL2000 Ent.
Now we are (temporary) running on a dual 2.8 Ghz XEON with 2Mb Cache, 4
Gb Ram (@.400Mhz) and a Serial ATA 7.2k software mirror, with Win2k3 std
x64 and SQL 2005 Std x64.
The current temporary server outperforms the old one by a factor 2 with
a load of 50 concurrent users (with a lot of inserts and updates), but
almost everything is different between the 2 machines.
The only thing I can say for sure is that we don't have any problems
with the x64 version.
param@.community.nospam wrote:
> Any of those databases clustered?
> Did you see a performance lift by moving from x86 to x64?
> Thanks
> "Theo Verweij" <tverweij@.xs4all.nl> wrote in message
> news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...
>|||Without detailed info, whether or not the others have experienced performanc
e
improvement with x64 probably won't mean a whole a lot to your particular ap
p
since the results are highly workload dependent. If you are considering goin
g
to x64 from x86, I suggest you treat it like any other production
change--test it first in your own environment with your own app before you
make the switch.
Linchi
"param@.community.nospam" wrote:
> Any of those databases clustered?
> Did you see a performance lift by moving from x86 to x64?
> Thanks
> "Theo Verweij" <tverweij@.xs4all.nl> wrote in message
> news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...
>|||Hi,
My understanding of your issue is that:
You prepared to migrate your SQL Server 2000 cluster to your SQL Server
2005 64 bit cluster and you wanted to know if there is some risk and if it
can lift the performance.
If I have misunderstood, please let me know.
Using 64 bit platform does not mean that the performance can be promoted
evidently, however it leaves a vast space for hardware upgrading. It can
provide higher hardware performance than 32 bit platform potentially, such
as memory capacity.
You can migrate your SQL Server 2000 32 bit cluster to your SQL Server 2005
64 bit cluster and you can take the following steps for the migration:
1. Backup all the databases on the current SQL Server 2000 cluster;
2. Export jobs script to a file;
3. Export users and logins script to a file:
4. Restore databases on the SQL Server 2005 cluster;
5. Create jobs by running the exported jobs script file;
6. Create users and passwords by running the exported script file.
Please refer to:
How to transfer logins and passwords between instances of SQL Server
http://support.microsoft.com/kb/246133/en-us
It is recommended that you perform a test before bring it to your
production environment.
If you have any other questions or concerns, please feel free to let me
know. It is my pleasure to be of assistance.
Charles Wang
Microsoft Online Community Support
========================================
==============
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
========================================
==============
This posting is provided "AS IS" with no warranties, and confers no rights.
========================================
==============
2005 x64
Hi all,
We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
SAN. We are considering moving to the x64 edition of SQL for performance
reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
and SQL as well. Can someone share any experiences about x64 environments? I
have heard some reports from users that it is not recommended for production
environments as it is unstable.
Would I need to re-code any of my tables/stored procs/functions etc?
TIA!We've done several implementations of the x64 version in our test, QA
and production environments and haven't experienced any issues. No
recoding should be necessary unless you've incorporated 32-bit API
calls into your SPs/functions.
On Sat, 28 Oct 2006 13:34:27 -0500, <param@.community.nospam> wrote:
>Hi all,
>We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
>SAN. We are considering moving to the x64 edition of SQL for performance
>reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
>and SQL as well. Can someone share any experiences about x64 environments? I
>have heard some reports from users that it is not recommended for production
>environments as it is unstable.
>Would I need to re-code any of my tables/stored procs/functions etc?
>TIA!
>|||I am running several production database on x64, without any problems.
param@.community.nospam wrote:
> Hi all,
> We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
> SAN. We are considering moving to the x64 edition of SQL for performance
> reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
> and SQL as well. Can someone share any experiences about x64 environments? I
> have heard some reports from users that it is not recommended for production
> environments as it is unstable.
> Would I need to re-code any of my tables/stored procs/functions etc?
> TIA!
>|||Any of those databases clustered?
Did you see a performance lift by moving from x86 to x64?
Thanks
"Theo Verweij" <tverweij@.xs4all.nl> wrote in message
news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...
>I am running several production database on x64, without any problems.
> param@.community.nospam wrote:
>> Hi all,
>> We have a 2-node SQL2005 SP1 cluster running right now connected to an
>> EMC SAN. We are considering moving to the x64 edition of SQL for
>> performance reasons. The servers currently have 64 bit CPUs, but are
>> running 32-bit OS and SQL as well. Can someone share any experiences
>> about x64 environments? I have heard some reports from users that it is
>> not recommended for production environments as it is unstable.
>> Would I need to re-code any of my tables/stored procs/functions etc?
>> TIA!|||No, no clusters,
and yes, the performance has really improved.
But, to be honest it is almost impossible to tell if this performance
improvement is due to x64.
At this moment we are running on a temporary server.
The old server was a quad 900 Mhz XEON with 2Mb Cache, 8Gb Ram
(@.100Mhz), UW Scsii 3 15k Raid 5, with Win2k Ent anb SQL2000 Ent.
Now we are (temporary) running on a dual 2.8 Ghz XEON with 2Mb Cache, 4
Gb Ram (@.400Mhz) and a Serial ATA 7.2k software mirror, with Win2k3 std
x64 and SQL 2005 Std x64.
The current temporary server outperforms the old one by a factor 2 with
a load of 50 concurrent users (with a lot of inserts and updates), but
almost everything is different between the 2 machines.
The only thing I can say for sure is that we don't have any problems
with the x64 version.
param@.community.nospam wrote:
> Any of those databases clustered?
> Did you see a performance lift by moving from x86 to x64?
> Thanks
> "Theo Verweij" <tverweij@.xs4all.nl> wrote in message
> news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...
>> I am running several production database on x64, without any problems.
>> param@.community.nospam wrote:
>> Hi all,
>> We have a 2-node SQL2005 SP1 cluster running right now connected to an
>> EMC SAN. We are considering moving to the x64 edition of SQL for
>> performance reasons. The servers currently have 64 bit CPUs, but are
>> running 32-bit OS and SQL as well. Can someone share any experiences
>> about x64 environments? I have heard some reports from users that it is
>> not recommended for production environments as it is unstable.
>> Would I need to re-code any of my tables/stored procs/functions etc?
>> TIA!
>|||Without detailed info, whether or not the others have experienced performance
improvement with x64 probably won't mean a whole a lot to your particular app
since the results are highly workload dependent. If you are considering going
to x64 from x86, I suggest you treat it like any other production
change--test it first in your own environment with your own app before you
make the switch.
Linchi
"param@.community.nospam" wrote:
> Any of those databases clustered?
> Did you see a performance lift by moving from x86 to x64?
> Thanks
> "Theo Verweij" <tverweij@.xs4all.nl> wrote in message
> news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...
> >I am running several production database on x64, without any problems.
> >
> > param@.community.nospam wrote:
> >> Hi all,
> >>
> >> We have a 2-node SQL2005 SP1 cluster running right now connected to an
> >> EMC SAN. We are considering moving to the x64 edition of SQL for
> >> performance reasons. The servers currently have 64 bit CPUs, but are
> >> running 32-bit OS and SQL as well. Can someone share any experiences
> >> about x64 environments? I have heard some reports from users that it is
> >> not recommended for production environments as it is unstable.
> >>
> >> Would I need to re-code any of my tables/stored procs/functions etc?
> >>
> >> TIA!
> >>
>|||Hi,
My understanding of your issue is that:
You prepared to migrate your SQL Server 2000 cluster to your SQL Server
2005 64 bit cluster and you wanted to know if there is some risk and if it
can lift the performance.
If I have misunderstood, please let me know.
Using 64 bit platform does not mean that the performance can be promoted
evidently, however it leaves a vast space for hardware upgrading. It can
provide higher hardware performance than 32 bit platform potentially, such
as memory capacity.
You can migrate your SQL Server 2000 32 bit cluster to your SQL Server 2005
64 bit cluster and you can take the following steps for the migration:
1. Backup all the databases on the current SQL Server 2000 cluster;
2. Export jobs script to a file;
3. Export users and logins script to a file:
4. Restore databases on the SQL Server 2005 cluster;
5. Create jobs by running the exported jobs script file;
6. Create users and passwords by running the exported script file.
Please refer to:
How to transfer logins and passwords between instances of SQL Server
http://support.microsoft.com/kb/246133/en-us
It is recommended that you perform a test before bring it to your
production environment.
If you have any other questions or concerns, please feel free to let me
know. It is my pleasure to be of assistance.
Charles Wang
Microsoft Online Community Support
======================================================When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
======================================================This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================
We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
SAN. We are considering moving to the x64 edition of SQL for performance
reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
and SQL as well. Can someone share any experiences about x64 environments? I
have heard some reports from users that it is not recommended for production
environments as it is unstable.
Would I need to re-code any of my tables/stored procs/functions etc?
TIA!We've done several implementations of the x64 version in our test, QA
and production environments and haven't experienced any issues. No
recoding should be necessary unless you've incorporated 32-bit API
calls into your SPs/functions.
On Sat, 28 Oct 2006 13:34:27 -0500, <param@.community.nospam> wrote:
>Hi all,
>We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
>SAN. We are considering moving to the x64 edition of SQL for performance
>reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
>and SQL as well. Can someone share any experiences about x64 environments? I
>have heard some reports from users that it is not recommended for production
>environments as it is unstable.
>Would I need to re-code any of my tables/stored procs/functions etc?
>TIA!
>|||I am running several production database on x64, without any problems.
param@.community.nospam wrote:
> Hi all,
> We have a 2-node SQL2005 SP1 cluster running right now connected to an EMC
> SAN. We are considering moving to the x64 edition of SQL for performance
> reasons. The servers currently have 64 bit CPUs, but are running 32-bit OS
> and SQL as well. Can someone share any experiences about x64 environments? I
> have heard some reports from users that it is not recommended for production
> environments as it is unstable.
> Would I need to re-code any of my tables/stored procs/functions etc?
> TIA!
>|||Any of those databases clustered?
Did you see a performance lift by moving from x86 to x64?
Thanks
"Theo Verweij" <tverweij@.xs4all.nl> wrote in message
news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...
>I am running several production database on x64, without any problems.
> param@.community.nospam wrote:
>> Hi all,
>> We have a 2-node SQL2005 SP1 cluster running right now connected to an
>> EMC SAN. We are considering moving to the x64 edition of SQL for
>> performance reasons. The servers currently have 64 bit CPUs, but are
>> running 32-bit OS and SQL as well. Can someone share any experiences
>> about x64 environments? I have heard some reports from users that it is
>> not recommended for production environments as it is unstable.
>> Would I need to re-code any of my tables/stored procs/functions etc?
>> TIA!|||No, no clusters,
and yes, the performance has really improved.
But, to be honest it is almost impossible to tell if this performance
improvement is due to x64.
At this moment we are running on a temporary server.
The old server was a quad 900 Mhz XEON with 2Mb Cache, 8Gb Ram
(@.100Mhz), UW Scsii 3 15k Raid 5, with Win2k Ent anb SQL2000 Ent.
Now we are (temporary) running on a dual 2.8 Ghz XEON with 2Mb Cache, 4
Gb Ram (@.400Mhz) and a Serial ATA 7.2k software mirror, with Win2k3 std
x64 and SQL 2005 Std x64.
The current temporary server outperforms the old one by a factor 2 with
a load of 50 concurrent users (with a lot of inserts and updates), but
almost everything is different between the 2 machines.
The only thing I can say for sure is that we don't have any problems
with the x64 version.
param@.community.nospam wrote:
> Any of those databases clustered?
> Did you see a performance lift by moving from x86 to x64?
> Thanks
> "Theo Verweij" <tverweij@.xs4all.nl> wrote in message
> news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...
>> I am running several production database on x64, without any problems.
>> param@.community.nospam wrote:
>> Hi all,
>> We have a 2-node SQL2005 SP1 cluster running right now connected to an
>> EMC SAN. We are considering moving to the x64 edition of SQL for
>> performance reasons. The servers currently have 64 bit CPUs, but are
>> running 32-bit OS and SQL as well. Can someone share any experiences
>> about x64 environments? I have heard some reports from users that it is
>> not recommended for production environments as it is unstable.
>> Would I need to re-code any of my tables/stored procs/functions etc?
>> TIA!
>|||Without detailed info, whether or not the others have experienced performance
improvement with x64 probably won't mean a whole a lot to your particular app
since the results are highly workload dependent. If you are considering going
to x64 from x86, I suggest you treat it like any other production
change--test it first in your own environment with your own app before you
make the switch.
Linchi
"param@.community.nospam" wrote:
> Any of those databases clustered?
> Did you see a performance lift by moving from x86 to x64?
> Thanks
> "Theo Verweij" <tverweij@.xs4all.nl> wrote in message
> news:u$uG%23Tz%23GHA.3344@.TK2MSFTNGP03.phx.gbl...
> >I am running several production database on x64, without any problems.
> >
> > param@.community.nospam wrote:
> >> Hi all,
> >>
> >> We have a 2-node SQL2005 SP1 cluster running right now connected to an
> >> EMC SAN. We are considering moving to the x64 edition of SQL for
> >> performance reasons. The servers currently have 64 bit CPUs, but are
> >> running 32-bit OS and SQL as well. Can someone share any experiences
> >> about x64 environments? I have heard some reports from users that it is
> >> not recommended for production environments as it is unstable.
> >>
> >> Would I need to re-code any of my tables/stored procs/functions etc?
> >>
> >> TIA!
> >>
>|||Hi,
My understanding of your issue is that:
You prepared to migrate your SQL Server 2000 cluster to your SQL Server
2005 64 bit cluster and you wanted to know if there is some risk and if it
can lift the performance.
If I have misunderstood, please let me know.
Using 64 bit platform does not mean that the performance can be promoted
evidently, however it leaves a vast space for hardware upgrading. It can
provide higher hardware performance than 32 bit platform potentially, such
as memory capacity.
You can migrate your SQL Server 2000 32 bit cluster to your SQL Server 2005
64 bit cluster and you can take the following steps for the migration:
1. Backup all the databases on the current SQL Server 2000 cluster;
2. Export jobs script to a file;
3. Export users and logins script to a file:
4. Restore databases on the SQL Server 2005 cluster;
5. Create jobs by running the exported jobs script file;
6. Create users and passwords by running the exported script file.
Please refer to:
How to transfer logins and passwords between instances of SQL Server
http://support.microsoft.com/kb/246133/en-us
It is recommended that you perform a test before bring it to your
production environment.
If you have any other questions or concerns, please feel free to let me
know. It is my pleasure to be of assistance.
Charles Wang
Microsoft Online Community Support
======================================================When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
======================================================This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================
Subscribe to:
Posts (Atom)