my own (identical) approach so we are officially agreed then. :-)
A Cluster/SQL Server urban legend bites the dust.
uttamkp@online.microsoft.com (Uttam Parui[MS]) wrote in message news:<$3V7#NedEHA.3424@cpmsftngxa10.phx.gbl>...
> Barry,
>
> Just to confirm that the steps I mentioned works, I did a bit of testing on a test server. Here are the scenarios I tried
>
> Scenario 1 -- Renaming default instance virtual sql server (vss) name
> (For simplicity -- all mdf and ldf files were on same Data folder)
> -------------------------------------------------------------------------------------------------------------------------------------------
> 1) Took backup of the mdf and ldf files. i.e. backed up Data folder.
> 2) Uninstalled default instance virtual sql server (vss). Reinstalled virtual sql server with new virtual server name. Applied SQL Server service packs and patches that were there before
> 3) Took vss resource offline. Replaced new Data folder with backup taken in step 1. Took vss resource online. Came online. Performed failover -- worked as expected
> 4) Ran select @@servername. It gave old virtual server name. Ran
> exec sp_dropserver 'old virtual server name'
> go
> exec sp_addserver 'new virtual server name' , 'local'
> go
> Recylcled vss. Ran select @@servername -->returned new virtual server name (As expected)
>
> Scenario 2 -- Renaming named instance virtual sql server (vss) name (instance name same)
> (For simplicity -- all mdf and ldf files were on same Data folder)
> -------------------------------------------------------------------------------------------------------------------------------------------
> 1) Took backup of the mdf and ldf files. i.e. backed up Data folder.
> 2) Uninstalled named instance virtual sql server (vss). Reinstalled virtual sql server with new virtual server name. But I kept the same instance name. Applied SQL Server service packs and patches that were there
> before
> 3) Took vss resource offline. Replaced new Data folder with backup taken in step 1. Took vss resource online. Came online. Performed failover -- worked as expected
> 4) Ran select @@servername. It gave old virtual server name\instance name. Ran
> exec sp_dropserver 'old virtual server name\instance name'
> go
> exec sp_addserver 'new virtual server name\instance name' , 'local'
> go
> Recylcled vss. Ran select @@servername -->returned new virtual server name\instance name (As expected)
>
> Scenario 3 -- Renaming named instance virtual sql server (vss) name (In this case I changed the instance name also)
> (For simplicity -- all mdf and ldf files were on same Data folder)
> -------------------------------------------------------------------------------------------------------------------------------------------
> 1) Took backup of the mdf and ldf files. i.e. backed up Data folder.
> 2) Uninstalled named instance virtual sql server (vss). Reinstalled virtual sql server with new virtual server name and new instance name. Applied SQL Server service packs and patches that were there before
> 3) Took vss resource offline. Replaced new Data folder with backup taken in step 1. Took vss resource online. Resource Failed.
> Did usual troubleshooting ;) . Found that SQL was not getting the mdf and ldf files for all dbs except master. It gets info for master from registry. It was looking for
> G:\Program Files\Microsoft SQL Server\MSSQL$OldInstanceName\Data folder
>
> whereas now I had put the Data folder in
>
> G:\Program Files\Microsoft SQL Server\MSSQL$NewInstanceName
>
> Easiest way to solve was to create the folder it was looking for and then SQL came online. They are other ways to fix this but it is outside the scope of this posting.
> 4) Ran select @@servername. It gave old virtual server name\old instance name. Ran
> exec sp_dropserver 'old virtual server name\old instance name'
> go
> exec sp_addserver 'new virtual server name\new instance name' , 'local'
> go
> Recylcled vss. Ran select @@servername -->returned new virtual server name\new instance name (As expected)
>
> P.S: For a production environment, I will also take SQL Server backups of ALL dbs (system and user dbs) --- just in case ;) Ofcourse, before uninstalling SQL I should know the collation, sort order of SQL Server as
> I will need these for the new install. I have seen many cases where the dba did not know have any info about old sql server that was already uninstalled, all they had was sql backups. Depending upon the
> complexity these cases can take a lot of time to resolve ;)
>
> HTH,
>
> Best Regards,
>
> Uttam Parui
> Microsoft Corporation
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> Are you secure? For information about the Strategic Technology Protection Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security. >
> Microsoft highly recommends that users with Internet access update their Microsoft software to better protect against viruses and security vulnerabilities. The easiest way to do this is to visit the following websites:
>
http://www.microsoft.com/protect