It may not be the server. It could be the network.
You need to make sure that before you take the old server down, it is
A) deregistered from Enterprise manager on your client machine
B) removed from the domain
C) removed from the DNS servers
D) removed from the WINS db if it's there
E) run ipconfig /flushdns, then ipconfig /registerdns on the box you're
trying to connect with.
Thank you,
Jeff Metcalf
ComputerPlus Sales & Service
(864) 801 9003 ext 2016
Kindness is the language which the deaf can hear and the blind can see.
- Mark Twain
-----Original Message-----
From: Mordechai Danielov
[mailto:mssqldba-ezmlmshield-x10529384.[Email address protected]
Sent: Wednesday, May 31, 2006 12:07 PM
To: LazyDBA Discussion
Subject: RE: Server to Server Migration
One more thing, while the @@servername does change, I can not seem to
connect to the server with the new name, and have to use the old one...
Also look at the this KB article:
http://support.microsoft.com/kb/303774/en-us
apparently renaming does not always work as advertised.
-----Original Message-----
From: Jay Butler
[mailto:mssqldba-ezmlmshield-x46676720.[Email address protected]
Sent: Wednesday, May 31, 2006 11:51 AM
To: LazyDBA Discussion
Subject: RE: Server to Server Migration
I don't think so. I believe that is loaded into the kernel when SQL
Server is started. So, the SQL Server keeps thinking it is the old name
until the service is restarted.
From: Mordechai Danielov
Sent: Wed 31-May-06 11:05
To: LazyDBA Discussion
Subject: RE: Server to Server Migration
And in between running sp_dropserver and sp_addserver, does the SQL
server
remain nameless?
-----Original Message-----
From: Jay Butler
[mailto:mssqldba-ezmlmshield-x2812303.[Email address protected]
Sent: Wednesday, May 31, 2006 10:45 AM
To: LazyDBA Discussion
Subject: RE: Server to Server Migration
Exactly. It changes how SQL Server identifies and refers to itself
(e.g.,
@@ServerName).
The OS still has to change the name referenced by the outside world.
From: Mordechai Danielov
Sent: Wed 31-May-06 10:39
To: LazyDBA Discussion
Subject: RE: Server to Server Migration
These stored procedures deal with remote servers not the name of the SQL
server itself.
-----Original Message-----
From: Pedro Manuel Oliveira Rocha
[mailto:mssqldba-ezmlmshield-x99190382.[Email address protected]
Sent: Wednesday, May 31, 2006 10:26 AM
To: LazyDBA Discussion
Subject: RE: Server to Server Migration
Err.... To change SQL Server NAME!!!
sp_dropserver old_name
GO
sp_addserver new_name, local
GO
And its done
-----Original Message-----
From: Mordechai Danielov
[mailto:mssqldba-ezmlmshield-x55495770.[Email address protected]
Sent: quarta-feira, 31 de Maio de 2006 15:22
To: LazyDBA Discussion
Subject: RE: Server to Server Migration
I imagine at least the server name would have to be different, right?
Otherwise it could get confusing with two same name servers on the same
network, but because of the difficulty with changing SQL server name,
you
would probably have to have it with the same name. I think you sort of
alluded to this with "some care has to be taken...". What is that care
(other than what Dan suggested)? Thnks
-----Original Message-----
From: Jay Butler
[mailto:mssqldba-ezmlmshield-x31979676.[Email address protected]
Sent: Tuesday, May 30, 2006 5:40 PM
To: LazyDBA Discussion
Subject: RE: Server to Server Migration
I do that type of upgrade slightly differently. I rebuild the new box
from
scratch minus the databases. Then, I restore all databases on the new
server
and allow some time for testing of the new configuration. Of course,
some
care has to be taken such that no inadvertent updates are done to
production
data through linked servers, DTS packages, etc.
On the morning of the cutover, I restore the system databases. Then, I
restore, but do not recover, the user databases. Through the day, I
continue
to restore transaction logs to the user databases on the new server
(again
not recovering the databases). This way the new server is never far
behind
the production server. At the cutover time, kick users off the old
server,
do final transaction log backups, copy them to the new server apply them
and
recover the databases.
I have done used this method on a number of servers. If you can script
the
activities and coordinate steps, the downtime could be nominal. I have
upgraded a box with 150GB of very active databases with only 10 minutes
of
application downtime.
Jay
From: Guzman
Sent: Tue 30-May-06 17:29
To: LazyDBA Discussion
Subject: Re: Server to Server Migration
This would also be a good time to document your Disaster Recovery plan.
Me? I would install the same OS and SQL versions on the new machine,
offline, using the old names AND locations for everything. Then I would
do a complete backup of the SQL server, not just the data, from the old
server, then restore that to the new server. Offline the old server,
reboot and online the new server. Viola! down time should only be the
time it takes to run the backup and then the restore/reboot.
Good luck.
Dan
I'm looking for the best overall SQL Server hardware upgrade
methodology. We need to move an instance of SQL Server from an old
server to a new one with minimal downtime. However, due to limitations
of our third party software which uses the SQL Server as a back-end,
both the server name and instance name must be the same on the new
server. Everything must be copied over, from security, views and stored
procedures to backup schedules and replication configuration.
I've read about several different approaches for doing this, but none of
them are very simple. I'm looking for the LAZY (as in LazyDBA) way.
What is the most acceptable way to do this?
Michael Phillips
Cardiac Science
[Email address protected]
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
MS Sql Server LazyDBA home page