rename SQL server

  • I've not heard of anyone else changing server names and switching test and prod environments as part of an upgrade cycle. Keep prod as prod and test as test, then you won't have to change server names and devs won't have to change their code.

    I can count the number of times I have changed a SQL server name on the thumbs of one hand.

    There are a number of loose ends with changing a server name as you have already found, and I suspect to fully rename a server at the OS level you would have to go right down to the BIOS level.

    Industry practice would be to put the flexibility in the connection strings, so keep it simple and push for that. You may be getting away with it now but start introducing complications like SSIS, SSRS, replication it will bite you sooner or later.

    ---------------------------------------------------------------------

  • george sibbald (3/6/2013)


    I've not heard of anyone else changing server names and switching test and prod environments as part of an upgrade cycle. Keep prod as prod and test as test, then you won't have to change server names and devs won't have to change their code.

    I can count the number of times I have changed a SQL server name on the thumbs of one hand.

    There are a number of loose ends with changing a server name as you have already found, and I suspect to fully rename a server at the OS level you would have to go right down to the BIOS level.

    Industry practice would be to put the flexibility in the connection strings, so keep it simple and push for that. You may be getting away with it now but start introducing complications like SSIS, SSRS, replication it will bite you sooner or later.

    Thanks,

    For the switching prod and test server I mentioned above, because we only have those 3 servers, and this has to be a side by side upgrade, not in place upgrade, it also includs windows version upgrade.

    I have to intall on test server first, then switch with the produciton box. Because we only have the 2 hardware available.

    If I don't do that way, what else would you recommend?

    Thanks

  • upgrade dev, test till you are happy

    upgrade test, test until you are happy

    upgrade prod. If its a virtual, take a snapshot before the upgrade as a quick backout.

    You cannot be doing OS and SQL upgrades that often for this to be a problem?

    ---------------------------------------------------------------------

  • george sibbald (3/7/2013)


    upgrade dev, test till you are happy

    upgrade test, test until you are happy

    upgrade prod. If its a virtual, take a snapshot before the upgrade as a quick backout.

    You cannot be doing OS and SQL upgrades that often for this to be a problem?

    Only dev is virtual, both test and prod are physical.

    Not sure I understand you:

    You cannot be doing OS and SQL upgrades that often for this to be a problem?

  • Not sure I understand you:

    You cannot be doing OS and SQL upgrades that often for this to be a problem?

    you mentioned OS upgrades and new sql server versions in an earlier post, surely these are rare? If you mean just patches these are too quick to apply to warrant this approach.

    ---------------------------------------------------------------------

  • george sibbald (3/7/2013)


    Not sure I understand you:

    You cannot be doing OS and SQL upgrades that often for this to be a problem?

    you mentioned OS upgrades and new sql server versions in an earlier post, surely these are rare? If you mean just patches these are too quick to apply to warrant this approach.

    We have some small applications developed in house.

    And the window used to be windows 2003, and SQL is 2008.

    We want to install windows 2008 R2 and SQL 2012.

    For windows verison, it is not an upgrade, the box needs to be wiped out and resintall the new OS, and then intall new version of SQL, then migrating databases.

  • if resources are scarce its not for me to tell your company how to spend their money but a new server in prod to allow a side by side build would be really good, you'll want to refresh your hardware sooner or later. That will give you minimum downtime (and perhaps a cost saving?)

    Putting the flexibility into the app code has got to be a worthwhile aim so perhaps use the test box as production for a while whilst you rebuild your production box, you'll have to isolate it as you cannot have two servers of the same name, and then migrate and repoint the app when its complete, hence the requirement for connection flexibility in the app.

    As far as I can see the rename server would work if you go that way but as you can see its more than dropserver\addserver to be complete, its local groups and SSIS as well. I presume you are trying to minimise downtime so when do you rename the server, before or after the SQL install? Before would be better, no SQL issues then. As this is a total rebuild I presume you add SQL server level objects by script and atach the databases. That should be doable in a few hours.

    Just some thoughts.

    ---------------------------------------------------------------------

Viewing 7 posts - 16 through 21 (of 21 total)

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