Move SQL Server Virtual Server Instance to new Server

What is the Best Practices way and quickest way to move a SQL Server 2000
Virtual Server database to a new server.
This a production server with numerous users and the server can be down for
only several hours. The server has Windows 2000 Advanced Server with SQL
Server 2000 (Active/Active) Cluster with two nodes and a 400GB database.
We purchased a new HP server.
We would like to install Windows 2003 Server and SQL Server 2000 Virtual
Server on this cluster server.
We would like the new server to have the same server name, IP Addresses, and
database instance name as the old system.
How can we complete this task with minimum down time and with Microsoft Best
Practices.
Thanks,
It's not really practical to have 2 servers in the same domain with the same
IP & name (in fact it's not possible). I had a similar situation recently
where I wanted to replace our production cluster with a new production
cluster and I wanted to keep all the config the same and I figured out that
the best way to do it was to use DNS to point at the SQL server that was to
be the production box.
What I did was I kept SQL01 (our production SQL instance) up & running as
normal while I built up SQL02. Different IP & name but I needed it to
co-exist in our domain while the DBs were transferred from one to the other.
I had a DNS alias (CNAME record) called SQLProduction that initially pointed
at SQL01. Leading up to our regular weekly outage period I'd copied full DB
backups over to SQL02 and restored them (WITH NORECOVERY) and then during
the outage period we put SQL01 into single user mode (so nobody could
connect to change data) and did transaction log backups of all the DB
(substantially smaller than the full DB backups). I then copied those tlog
backups over to SQL02, restored them (WITH RECOVERY) and changed the
SQLProduction DNS alias to point at SQL02.
This added a level of abstraction to the client/server model we use, which
has been very useful (the users don't need to know what server the
production server really is, all they know is they get to it by connecting
to SQLProduction). We can switch the DNS alias to whichever box we like
and, assuming the DBs are synched, nobody every knows the difference (we set
the DNS TTL very small, like 5 minutes, before the change so it gets out to
the client machines almost immediately). We did this for all our major
servers (SQLProduction, SQLStaging, SQLDevelopment). We now have a few
production servers (all running on different clusters) but the users have no
idea which servers actually host the DBs (as that detail shouldn't matter to
them).
The only ugly thing about this is that leading up to the change we had to
make sure all the client apps (and we had thousands running on a couple
thousand computers) we're connecting to the DNS aliases rather than the
actual server names so that when we turned off SQL01 they wouldn't still be
trying to connect to it.
It was slightly more complicated for us because we were using named
instances, which don't translate very well with DNS (ie. DNS can't cater for
them at all). What I did to solve that was use the MDAC aliases to say
"SQLProduction" is a TCP connecting to a box called SQLProduction (ie. the
DNS alias) and it should use port 1434 or 1435 or 1436 or whichever. The
MDAC aliases are just registry values so I got the appropriate aliases
together into a reg file and we used SMS to push them out to every client
desktop (and we updated our 100 or so servers manually with the reg file).
This works well with a disaster recovery scenario too - we just set up our
DR SQL servers (say SQL03) to listen on the same port as the production
instance. Then in a disaster (which we had in August this
year...<sigh>...dumb SAN engineers!) we simply change the DNS alias for
SQLProduction to point to SQL03. After that, every new connecting to
SQLProduction goes off to SQL03 on port 1434 (or whichever one we use for
our "production" box). We keep the production & DR servers synchronised
with log shipping and it works a treat - we can be up and running on our DR
server (with no changes to any middle-tier or client app) in about 1 hour;
all we have to do is log shipping role changes for all the DBs (which takes
a little while because we have about 150 of the dam things, but I wrote a
SQL batch to perform the role changes, so we just kick it off and 30-45
minutes later everyone is pointing at our DR server and nobody is the wiser
(except for the 1 hour outage)).
Anyway, sorry about my verbal diarrhoea. HTH.
Cheers,
Mike
"Joe K." <JoeK@.discussions.microsoft.com> wrote in message
news:019A8672-58C8-4A98-9A12-5C7D762F8C27@.microsoft.com...
> What is the Best Practices way and quickest way to move a SQL Server 2000
> Virtual Server database to a new server.
> This a production server with numerous users and the server can be down
> for
> only several hours. The server has Windows 2000 Advanced Server with SQL
> Server 2000 (Active/Active) Cluster with two nodes and a 400GB database.
> We purchased a new HP server.
> We would like to install Windows 2003 Server and SQL Server 2000 Virtual
> Server on this cluster server.
> We would like the new server to have the same server name, IP Addresses,
> and
> database instance name as the old system.
> How can we complete this task with minimum down time and with Microsoft
> Best
> Practices.
> Thanks,