what to do if moving SQL servers and specs are not same?

  • Hi Guys,

    Normally, when moving SQL servers, the specs are the same, or atleast the basics are the same. However, I do have a little bit different situation -

    1) In my case, The new sql server 2000 will be sp4. The old one is on SP3.

    2) The new server will have a different name than the old one.

    3) The logical drives will also change.

    4) The new server will have 4GB RAM, where as the old one has only 2GB.

    What will be the impact on the scheduled jobs? I beleieve I will need to change the msdb table to reflect the new name. Is there anything else?

    Also, with all the changes on the new server, is there something I need to be particularly carefull about?

    Is there something I should not be implementing now? eg: if before the logs were being saved to P:, and now I want to save the Logs on the L:?

    Your help is highly appreciated.

    Thanks,

    TK

  • TK,

    I'm assuming you are building the new server on new separate hardware? 

    Below is the approach I would take (given the information you have provided and lack of knowledge of and SLA's etc.).

    1) Upgrade the current server to sp4 (user databases are only altered with sp4 if they are involved in a replication setup), however this will bring both servers to a similar software level (assuming OS's are the same).  See the readme file with SP4.

    2) Backup all system and user databases and do one of the following either 3 or 4 (dependant on your situation).

    3) Follow this KB article to move the source system and user databases to the pre-built target SQL 2000 box http://support.microsoft.com/?id=224071 . However you could experience problems with your jobs as you mentioned above (i.e. referencing incorrect drives and a different server name), however you may be able to manually adjust these after, i've never tried this but you may be lucky, personally I would take step 4 below.

    4)

    - Restore each of your user databases (either from the backups taken above or using the detach/attach method) to the target server.

    - Script the jobs from your source (old) server, (if you've used Database Maintenance Plans this could be tricky) modify the scripts to reference the new server name and drive locations and run the scripts on you nice new server.

    5) Test all user databases and applications work as required and configure the server as per your organizations requirements.

    This is a starting point, if you give us more info we can fine tune either of these solutions or i'm sure some people will have alternative ideas.

    ll 

     

Viewing 2 posts - 1 through 1 (of 1 total)

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