hardware upgrade of active/active cluster

I'm planning a hardware upgrade of our active/active dual node Windows
2000 sql cluster. Hostnames and IP addresses will remain unchanged.
Here's a high level overview of my plan..
1. move all cluster groups/resources to node 2
2. shutdown sql services on node 1
3. uninstall MSCS on node 1
4. evict node 1 from cluster using cluster administrator on node 2
5. power down node 1
6. reset node 1 account in domain
7. add new node 1 to domain
8. install MSCS on new node 1
9. install sql server on new node 1
10. install sql sp2 on new node 1
11. add new node 1 to existing cluster
12. verify that all resources can move to new node 1 correctly
** repeat for node 2
I know this has been discussed several times before in this newsgroup,
but there's a few extra steps in there that I believe have not been
addressed in the past. Does the above look accurate and also is it
feasible to roll back to a ghost image and backup of the quarum in the
event of a problem with either server?
Thanks in advance,
David
Step 1.5 Uninstall SQL from Node 1. If you do not do this step, you cannot
do step 9. Uninstalling SQL also tells the existing cluster not to look for
that node any longer as a valid SQL host node. You can do it as step 8.5,
but you will have to wait on some timeouts since the node is no onger there.
I haven't tried a ghost of the quorum as a restore technique, but I suspect
that given the SQL configuration changes, it wouldn't work.
Since you are reusing node names, make sure you have removed all traces of
the nodes from Active Directory and allowed it to globally synch before
trying to add the machines back in.
IMHO, I would take the opportunity to upgrade to Windows 2003 as a host OS
during the upgrade. In that case, you would need to be on at least SP3a
before starting the cluster upgrade.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<davidawest@.gmail.com> wrote in message
news:1132725533.573424.291710@.z14g2000cwz.googlegr oups.com...
> I'm planning a hardware upgrade of our active/active dual node Windows
> 2000 sql cluster. Hostnames and IP addresses will remain unchanged.
> Here's a high level overview of my plan..
> 1. move all cluster groups/resources to node 2
> 2. shutdown sql services on node 1
> 3. uninstall MSCS on node 1
> 4. evict node 1 from cluster using cluster administrator on node 2
> 5. power down node 1
> 6. reset node 1 account in domain
> 7. add new node 1 to domain
> 8. install MSCS on new node 1
> 9. install sql server on new node 1
> 10. install sql sp2 on new node 1
> 11. add new node 1 to existing cluster
> 12. verify that all resources can move to new node 1 correctly
> ** repeat for node 2
> I know this has been discussed several times before in this newsgroup,
> but there's a few extra steps in there that I believe have not been
> addressed in the past. Does the above look accurate and also is it
> feasible to roll back to a ghost image and backup of the quarum in the
> event of a problem with either server?
> Thanks in advance,
> David
>

hardware upgrade -> lower "insert" performance

Hey all,
I was about to move my SQL Server from a box that's about four years
old to a current box. The new box should be faster for everything ...
more RAM, faster CPU, faster disks... but the performance of repeated
"insert" statements is measurably worse. The following script took
2:16 on my old hardware (which is running my production system at the
same time), and 3:23 on the new hardware. "select" and "update"
statements do seem to be faster on the new hardware.
Anybody got any clue where I should be looking?
select getdate()
set nocount on
go
if exists
( select *
from sysobjects
where type = 'U'
and name = 'cccInsertTest')
begin
drop table cccInsertTest
end
go
create table cccInsertTest
( a int not null)
go
declare @.i int
select @.i = 0
while @.i < 50000
begin
insert into cccInsertTest (a) values (@.i)
select @.i = @.i + 1
end
go
select getdate()
go
hmmm, is the raid different?
"Chris Curvey" wrote:

> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>
|||Chris,
A couple of ideas:
Was the test database and log created with enough room so the database and
log didn't have to allocate more space (grow) while the process was running?
Instead of using getdate(), set the statistics time and statistics io
options on (QA Tools/Options, Connection Properties tab). Compare those
metrics instead. Also, run the tests on the servers using Remote Desktop to
eliminate any network transport (should be neglegible, but I'd do it
anyway).
-- Bill
"Chris Curvey" <ccurvey@.gmail.com> wrote in message
news:1170084503.675585.149280@.q2g2000cwa.googlegro ups.com...
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>
|||On Jan 29, 10:28 am, "Chris Curvey" <ccur...@.gmail.com> wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
>

> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
Turns out that there were two issues. We needed to turn on write
caching within our RAID controller. But the bigger problem was the
client program that we were using to drive the script. "isql" was
running at 4 xacts/sec. "osql" ran at 9 xacts/sec. Writing a Python
script (that ran from another machine, across a slow network link)
gave us 30 xacts/sec.
Go figure!

hardware upgrade -> lower "insert" performance

Hey all,
I was about to move my SQL Server from a box that's about four years
old to a current box. The new box should be faster for everything ...
more RAM, faster CPU, faster disks... but the performance of repeated
"insert" statements is measurably worse. The following script took
2:16 on my old hardware (which is running my production system at the
same time), and 3:23 on the new hardware. "select" and "update"
statements do seem to be faster on the new hardware.
Anybody got any clue where I should be looking?
select getdate()
set nocount on
go
if exists
( select *
from sysobjects
where type = 'U'
and name = 'cccInsertTest')
begin
drop table cccInsertTest
end
go
create table cccInsertTest
( a int not null)
go
declare @.i int
select @.i = 0
while @.i < 50000
begin
insert into cccInsertTest (a) values (@.i)
select @.i = @.i + 1
end
go
select getdate()
gohmmm, is the raid different?
"Chris Curvey" wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||Chris,
A couple of ideas:
Was the test database and log created with enough room so the database and
log didn't have to allocate more space (grow) while the process was running?
Instead of using getdate(), set the statistics time and statistics io
options on (QA Tools/Options, Connection Properties tab). Compare those
metrics instead. Also, run the tests on the servers using Remote Desktop to
eliminate any network transport (should be neglegible, but I'd do it
anyway).
-- Bill
"Chris Curvey" <ccurvey@.gmail.com> wrote in message
news:1170084503.675585.149280@.q2g2000cwa.googlegroups.com...
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||On Jan 29, 10:28 am, "Chris Curvey" <ccur...@.gmail.com> wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
>
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
Turns out that there were two issues. We needed to turn on write
caching within our RAID controller. But the bigger problem was the
client program that we were using to drive the script. "isql" was
running at 4 xacts/sec. "osql" ran at 9 xacts/sec. Writing a Python
script (that ran from another machine, across a slow network link)
gave us 30 xacts/sec.
Go figure!

hardware upgrade -> lower "insert" performance

Hey all,
I was about to move my SQL Server from a box that's about four years
old to a current box. The new box should be faster for everything ...
more RAM, faster CPU, faster disks... but the performance of repeated
"insert" statements is measurably worse. The following script took
2:16 on my old hardware (which is running my production system at the
same time), and 3:23 on the new hardware. "select" and "update"
statements do seem to be faster on the new hardware.
Anybody got any clue where I should be looking?
select getdate()
set nocount on
go
if exists
( select *
from sysobjects
where type = 'U'
and name = 'cccInsertTest')
begin
drop table cccInsertTest
end
go
create table cccInsertTest
( a int not null)
go
declare @.i int
select @.i = 0
while @.i < 50000
begin
insert into cccInsertTest (a) values (@.i)
select @.i = @.i + 1
end
go
select getdate()
gohmmm, is the raid different?
"Chris Curvey" wrote:

> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||Chris,
A couple of ideas:
Was the test database and log created with enough room so the database and
log didn't have to allocate more space (grow) while the process was running?
Instead of using getdate(), set the statistics time and statistics io
options on (QA Tools/Options, Connection Properties tab). Compare those
metrics instead. Also, run the tests on the servers using Remote Desktop to
eliminate any network transport (should be neglegible, but I'd do it
anyway).
-- Bill
"Chris Curvey" <ccurvey@.gmail.com> wrote in message
news:1170084503.675585.149280@.q2g2000cwa.googlegroups.com...
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||On Jan 29, 10:28 am, "Chris Curvey" <ccur...@.gmail.com> wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
>

> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
Turns out that there were two issues. We needed to turn on write
caching within our RAID controller. But the bigger problem was the
client program that we were using to drive the script. "isql" was
running at 4 xacts/sec. "osql" ran at 9 xacts/sec. Writing a Python
script (that ran from another machine, across a slow network link)
gave us 30 xacts/sec.
Go figure!

hardware sizing

Hi,
We are running SQL Server 7.0 Standard Edition and
planning to upgrade to SQL Server 2000 Standard Edition
in a new hardware. Present hardware is having 2.4GB RAM
with 4 processor of 199MHZ . We are planning buy new
hardware with 3GB with 4 Processor of 1.4GHZ. According
to SQL Server documentation if its more than 2GB we have
to get Enterprise edition.
Here is my question:
Can we just allocate 2GB for SQL Server and just use
Standare edition and leave the extra 1GB for other
applications?
Your answers will be greately appriciated.
Thanks,
Mani.Yes, that will work just fine. Actually, SQL will top out at around 1.7GB
with standard edition, leaving 1.3 for OS and other application components,
should you have them
"Mani" <mani@.macdermid.com> wrote in message
news:014e01c34e3a$2be2a810$a501280a@.phx.gbl...
> Hi,
> We are running SQL Server 7.0 Standard Edition and
> planning to upgrade to SQL Server 2000 Standard Edition
> in a new hardware. Present hardware is having 2.4GB RAM
> with 4 processor of 199MHZ . We are planning buy new
> hardware with 3GB with 4 Processor of 1.4GHZ. According
> to SQL Server documentation if its more than 2GB we have
> to get Enterprise edition.
> Here is my question:
> Can we just allocate 2GB for SQL Server and just use
> Standare edition and leave the extra 1GB for other
> applications?
>
> Your answers will be greately appriciated.
> Thanks,
> Mani.
>