The Instance ID MSSQLSERVER Is Already In Use

Question

The Instance ID MSSQLSERVER Is Already In Use

Nisarg Upadhyay

SSC-Addicted

Points: 460
More actions
September 18, 2017 at 12:04 am

#340061

Comments posted to this topic are about the item The Instance ID MSSQLSERVER Is Already In Use

Viewing 5 posts - 1 through 4 (of 4 total)

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

SoHelpMeCodd SSCertifiable Points: 5871 More actions · Answer 1

Before following this tip, review the bootstrap folder and strive to determine why the upgrade failed. If you cannot determine why the upgrade failed, the advantage of reinstalling the operating system (over using msiexec /x) is that you have ensured all remnants of a failed and in-solvable upgrade are completely removed.

By following this tip you will not gain any assurance that you have a clean upgrade. It you 'must' follow this article because there are non-SQL Server processes installed on the same OS that also depend on SQL Server, by following this tip you may end up with new problems in those processes. And if you call MS Support with a new problem at any time in the future, and if they discover msiexec /x had been used to blast away an old version, you may end up hearing Supprt asking you to reinstall the OS.

In other words, msiexec /x is not supported by SQL Server Development or SQL Server Support, and the consequence of using it (such as abnormal product behavior) is also not supportable.

Caveat emptor. It is far better to flatten the box, IMO...

gerald72 SSC Enthusiast Points: 191 More actions · Answer 2

Hi,
great - if I ever run into this error and I only have a small maintenance window for a physical machine I will give it a try. Reinstalling the OS, SQL Server and attaching hundrets of DBs would take too long.
I would always prefer a clean SQL installation instead of doing an upgrade, but there are situations, where you have to do what needs to be done.

Thanks for sharing this fix
BR
Gerald

SoHelpMeCodd SSCertifiable Points: 5871 More actions · Answer 3

gerald72 - Wednesday, September 27, 2017 11:39 PM
Hi,
great - if I ever run into this error and I only have a small maintenance window for a physical machine I will give it a try. Reinstalling the OS, SQL Server and attaching hundrets of DBs would take too long.
I would always prefer a clean SQL installation instead of doing an upgrade, but there are situations, where you have to do what needs to be done.
Thanks for sharing this fix
BR
Gerald

I have a development SQL Server with 500 databases that serves 200 users (including ~100 developers, many of whom work odd hours). I log ship to a secondary, because I want to be prepared for the many ways a setup, the OS, or the hardware can fail :). For my production servers I harness clustering, which allows me to rebuild a server outside of a maintenance window.

gerald72 SSC Enthusiast Points: 191 More actions · Answer 4

SoHelpMeCodd - Thursday, September 28, 2017 7:08 AM
gerald72 - Wednesday, September 27, 2017 11:39 PM
Hi,
great - if I ever run into this error and I only have a small maintenance window for a physical machine I will give it a try. Reinstalling the OS, SQL Server and attaching hundrets of DBs would take too long.
I would always prefer a clean SQL installation instead of doing an upgrade, but there are situations, where you have to do what needs to be done.
Thanks for sharing this fix
BR
Gerald
I have a development SQL Server with 500 databases that serves 200 users (including ~100 developers, many of whom work odd hours). I log ship to a secondary, because I want to be prepared for the many ways a setup, the OS, or the hardware can fail :). For my production servers I harness clustering, which allows me to rebuild a server outside of a maintenance window.

Same here (besides alwayson ags) - but I wasn't sure if this problem also could apply to named instances. But if it does (and I'm nearly sure it could also haooe there) we are safe.