Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

rename SQL server Expand / Collapse
Author
Message
Posted Wednesday, March 6, 2013 10:18 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:50 PM
Points: 5,974, Visits: 12,877
the developers are asking a lot of you there, the code should be flexible enough to cope with changes in server names for DR and migration from test to prod at least. Investigate using DNS aliases in their connection strings so these can just be repointed.

It is easier to change connection strings then rename servers.


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

Post #1427518
Posted Wednesday, March 6, 2013 10:25 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 5:42 AM
Points: 1,857, Visits: 2,971
george sibbald (3/6/2013)
the developers are asking a lot of you there, the code should be flexible enough to cope with changes in server names for DR and migration from test to prod at least. Investigate using DNS aliases in their connection strings so these can just be repointed.

It is easier to change connection strings then rename servers.


+1
Post #1427522
Posted Wednesday, March 6, 2013 10:27 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 4:58 AM
Points: 1,230, Visits: 2,734
We use dns aliases for this purpose. Although, we DO have some app folks that ping that name and find out the real name and use it. Frustrating when we move the server and their connections don't work.


Post #1427524
Posted Wednesday, March 6, 2013 10:30 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:50 PM
Points: 5,974, Visits: 12,877
Markus (3/6/2013)
We use dns aliases for this purpose. Although, we DO have some app folks that ping that name and find out the real name and use it. Frustrating when we move the server and their connections don't work.


Doh!


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

Post #1427526
Posted Wednesday, March 6, 2013 10:57 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 10:26 AM
Points: 1,749, Visits: 3,153
Thanks all,

We have situation like this;
We have 3 servers, for example they are named as SQL1, (dev)and SQL2(test), SQL3(prod). test and prod are same hardware and RAM.
When doing upgrade we do on dev first and test everything, this include windows upgrade and sQL server new version, migrating dbs.
Then we want to use the test box test1 to do the exactly the same thing but when done, we want switch this as a production server, then the old production server we will use as testing server.

In this case, we want to rename back for prod SQL3, and test SQL2.
We can keep the servername as they are, the developrs need to change the connection string.

Situation 2
When doing virtual to virtual server copy, after that we need to rename the server name, for the cloned copy still has the original copy name.


But by reading this post answers, do you mean most DBA don't do renaming server much.

You tell developers to change their connection string.
also you use alias name, it seems using alias name sometimes confusing too.

I really don't like to rename servers, because it leaves footprint of old computer name, that is why my original question raised.

What should I tell developers that renaming servers is harder than changing connection string in their code?

Thanks
Post #1427532
Posted Wednesday, March 6, 2013 3:08 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:50 PM
Points: 5,974, Visits: 12,877
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.


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

Post #1427658
Posted Wednesday, March 6, 2013 3:18 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 10:26 AM
Points: 1,749, Visits: 3,153
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
Post #1427664
Posted Thursday, March 7, 2013 3:35 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:50 PM
Points: 5,974, Visits: 12,877
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?


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

Post #1427880
Posted Thursday, March 7, 2013 10:12 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 10:26 AM
Points: 1,749, Visits: 3,153
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?


Post #1428109
Posted Thursday, March 7, 2013 10:26 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:50 PM
Points: 5,974, Visits: 12,877
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.


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

Post #1428123
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse