Post reply

Moving to a new Server in a SAN Environment.

  • January 18, 2008 at 7:40 am

    #76874

    Hi,

    We currently have a SQL 2000 server setup with the data and log files (including those for the system) placed on a SAN. Our current server is old and starting to have problems so we are transitioning to a new server. I just wanted to see if anyone has done this before or if my plan makes sense.

    1) Hook the new server into the the SAN Arrays holding the data and log files.

    2) Take the old Server off-line, and bring the new one up.

    3) Point the Master db to the location of its data and log files.

    4) Restart the server.

    Since the master "knows" where all of the other databases are located when the it starts the recovery process it should bring up all of the other databases on that server. Does this make sense or am I missing something.

    Thanks in advance for any help!

    Jeff

  • January 18, 2008 at 7:53 am

    #769664

    We recently upgraded, but we did not do it the way you described.

    we brought up a new server, and made sure it had access to the san.

    depending on the database, we either backed up and restored, or detached from the old server and attached to the new. we never tried to get the new server to use the old master database...we just let it update it's own automatically as we atteched or restored the databases we needed.

    only after everything was migrated and tested did we down the old server. it sounds like you could run into problems or downtime doing it the way you describe.

    we then change the DNS in house so that any requests for the old server were directed at the new one...that part was done by the network guys, so I don't have much detail on that.

    Lowell

    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • January 18, 2008 at 8:01 am

    #769669

    Thanks!

    That all seems perfectly reasonable as well. I'm assuming that you didn't run into any significant problems?

    ~Jeff:D

  • January 18, 2008 at 8:22 am

    #769694

    no problems at all; we had both servers up and running at the same time for a week; the databases we detatched and reattched were developer databases, so they had to switch to the new server right away for testing, and once we were confident we didn't forget anything, we restored the others one more time and went live. we just shut off the old box for a couple of weeks, and had to turn it back on to recover a job that was scripted out, and transfered, but that someone deleted again.

    Lowell

    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • January 18, 2008 at 8:30 am

    #769702

    Awesome! And you had no problems running 2 servers connected to the same data and log files? Did you restore and detach/attach the system db's? I assume you did something like attaching the user db's and restoring the msdb and model dbs? Sorry to be a pain, but we're going to do this over this weekend and I'm trying to make sure things go as smoothly as possible. Being the weekend I want to be here as little time as possible 😉

    Thanks!

    ~Jeff

  • January 18, 2008 at 8:37 am

    #769705

    well let me be more detailed: only one server can use the actual .mdb and ldb files at any one time. restored databases were just copies of hte current data.

    1.first we scripted out all the users form OLDSERVER, and ran ran the script on the NEWSERVER, so we had all the logins.we also script out jobs as well. those files were edited to include new server names and such. we did not resotre any system databases, we just scripted out the jobs...the scripts can be found right here on SSC.

    2.we restored copies of the production databases for testing, but development databases were detached, and then reattached to teh new server., so every database that exists on the old server existed on the new one.

    3.the script for sp_change_users_logins was run so that users in the databases were sycronized to the logins we imported (avoids the orphanded users issue)

    4. development guys tested access to the databases with each of the logins, and ran some applications to confirm permissions were OK.

    5. after a week of testing, we backed up and restored one last time for the production databases.

    6. again, we ran the sp_change_users_logins script to sync logins.

    7. turned off the old server, nad awaited any calls that something wasn't working.

    Lowell

    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • January 18, 2008 at 8:42 am

    #769708

    Thank you, you've been very helpful.

    ~Jeff

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply