-> I was performing an In-Place upgrade of SQL Server 2017 to SQL Server 2019. When I selected the required default instance on the setup window and clicked next, I received below message and couldn’t proceed further,
[error message] The instance id 'MSSQLSERVER' is already in use by Sql Server Instance 'MSSQLSERVER.INACTIVE'.
To continue, specify a unique instance id.
[details] microsoft.sqlserver.configuration.setupextension.instanceidisusedbyanotherinstanceexception:
the instance id 'MSSQLSERVER' is already in use by Sql Server Instance 'MSSQLSERVER.INACTIVE'.
To continue, specify a unique instance id.
=====================================================================
-> It seems like we have MSSQLSERVER.INACTIVE instance on the database server and that is due to an failed install before.
-> In my case the In-Place upgrade failed due to the issue discussed in this article.
-> I ran a discovery report from SQL Server 2019 setup,
-> Below is the discovery report,
-> It seems like the problematic component in my case is SQL Server Analysis services.
-> I searched for file “Datastore_Discovery.xml” on the database server and opened it. I then searched for INACTIVE and got below results,
-> I noted down the product code for the INACTIVE instance and executed below in an administrative command prompt. This uninstalls the INACTIVE instance for that particular component.
-> I started the In-Place upgrade this time and it completed fine without any issues.
-> In my case it was just SQL Server Analysis Service, but there will be instances you will see other components also. Hence it is required to look at the discovery report and remove all INACTIVE components on the database server to move forward.
Thank You, Vivek Janakiraman
Disclaimer: The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.
-> I was performing an In-Place upgrade of SQL Server from SQL Server 2017 to SQL Server 2019.
-> The upgrade failed with below error,
TITLE: Microsoft SQL Server 2019 Setup
------------------------------
The following error has occurred:
The User Data directory in the registry is not valid. Verify DefaultData key under the instance hive points to a valid directory.
For help, click: https://go.microsoft.com/fwlink?LinkID=20476&ProdName=Microsoft%20SQL%20Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=15.0.4013.40&EvtType=0xD8FB5EBA%25400x97A656BB%25401306%254067
------------------------------
BUTTONS:
OK
------------------------------
-> The error states that there is some issue with the data directory.
-> I right clicked on the SQL Server instance and clicked on properties. Clicked on “Database Settings” and verified “Database default locations”. The data location mentioned is “F:\data1\”. This location is not available on the database server.
-> I corrected it to F:\data which is available on the database server and then clicked OK. Started the In-Place upgrade again and it completed fine.
-> This issue also happens during Service pack and cumulative updates install also. We should make sure that the “Data” and “Log” location is correct under “Database Settings” in SQL Server Instance properties.
Thank You, Vivek Janakiraman
Disclaimer: The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.
-> Database Server JBSAG1 and JBSAG2 hosts SQL Server 2017. The requirement was to perform an In-Place upgrade to SQL Server 2019 on JBSAG1 and JBSAG2.
-> Database Server JBSAG1 is secondary replica and JBSAG2 is primary replica.
-> In-place upgrade from SQL Server 2017 to SQL Server 2019 was started on JBSAG1 as it is the secondary replica. It completed fine without any issues.
-> After the upgrade, connected to JBSAG1 using SSMS and performed a health check. The database JBDB on SQL Server instance JBSAG1 showed as Synchronized / In Recovery as show in below screenshot,
-> Checked SQL Server error log and found below message,
2020-09-10 15:05:27.020 spid53 Error: 946, Severity: 14, State: 1. 2020-09-10 15:05:27.020 spid53 Cannot open database ‘JBDB’ version 869. Upgrade the database to the latest version.
Cannot open database ‘JBDB’ version 869. Upgrade the database to the latest version. (Microsoft SQL Server, Error: 946)
-> The message is very clear. After the In-place upgrade, the database should be upgraded to latest version which is SQLS erver 2019, since the database is in Always on secondary, setup process was not able to upgrade it during the upgrade process.
-> Checking the Always On availability group dashboard from primary replica JBSAG2,
-> There are no errors and Always On availability group is in healthy state. So it is safe to failover Availability group from JBSAG2 to JBSAG1. Once after the failover, the database will get upgraded.
-> After the failover database JBDB in JBSAG1 is online and synchronized,
-> Checking the Always On dashboard,
-> JBSAG2 which is the secondary replica now and shows database JBDB as “Not Synchronizing / In Recovery”. On JBSAG2, check the database JBDB status under Availability databases and you will see that the database is paused.
-> We are seeing this in paused state because after failover the current Primary JBSAG1 is in SQL Server 2019 and the secondary JBSAG2 is in SQL Server 2017. Now it is time to perform an In-Place upgrade to SQL Server 2019 on JBSAG2 and the database JBDB in “Not Synchronizing / In Recovery” state in JBSAG2 is expected.
<TESTING ONLY – DONOT PERFORM ON LIVE SERVERS>
-> I will try resuming the database JBDB on JBSAG2 without performing an In-Place upgrade from SQL Server 2017 to SQL Server 2019.
-> Checking SQL Server error log. Below message can be found,
2020-09-10 15:20:21.490 spid71 ALTER DB param option: RESUME 2020-09-10 15:20:21.500 spid71 Always On Availability Groups data movement for database ‘JBDB’ has been resumed. This is an informational message only. No user action is required. 2020-09-10 15:20:21.500 spid77s Always On Availability Groups connection with primary database established for secondary database ‘JBDB’ on the availability replica ‘JBSAG1’ with Replica ID: {850de16e-2c2b-43b1-bf52-6d8c5e2046ff}. This is an informational message only. No user action is required.
2020-09-10 15:20:21.500 spid77s Error: 948, Severity: 20, State: 102. 2020-09-10 15:20:21.500 spid77s The database ‘JBDB’ cannot be opened because it is version 904. This server supports version 869 and earlier. A downgrade path is not supported.
2020-09-10 15:20:21.500 spid77s Always On Availability Groups data movement for database ‘JBDB’ has been suspended for the following reason: “system” (Source ID 7; Source string: ‘SUSPEND_FROM_REVALIDATION’). To resume data movement on the database, you will need to resume the database manually. For information about how to resume an availability database, see SQL Server Books Online.
-> The message clearly tells that the database should be upgraded before resuming the data movement. Hence In-Place upgrade of JBSAG2 should be performed.
<TESTING ONLY – DONOT PERFORM ON LIVE SERVERS>
-> Performed In-Place upgrade from SQL Server 2017 to SQL Server 2019 on database server JBSAG2.
-> I checked the Always On dashboard. The database JBDB was still “Not Synchronizing / In Recovery” and was suspended.
-> I resumed the data movement for database JBDB on database server JBSAG2 and it worked fine this time. Below is the Always On dashobaord,
Thank You, Vivek Janakiraman
Disclaimer: The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.
