One of the most common connectivity errors which I have heard about it is “A network-related or instance-specific error occurred while establishing a connection to SQL Server.” In this blog, we would learn about how to fix this error if it comes during the installation of SQL Server.

THE SITUATION

If you search for the error which I mentioned in blog subject, one of my blogs which would come up is the following SQL SERVER – FIX : ERROR : (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server) (Microsoft SQL Server, Error: )

There are many other on the internet which would have any suggestions to fix the error.

The situation here is a little different than all the others. My client was getting this error during the installation of SQL Server. So, this was not in any client application, website or SQL Server Management Studio, but seen in installation logs. The following information is picked from “Detail.txt” file, which is one of the most important files, used to fix issues related to installation.

SQLEngine: –SqlDatabaseServiceConfig: Connection String: Data Source=\\.\pipe\SQLLocal\MSSQLSERVER;Initial Catalog=master;Integrated Security=True;Pooling=False;Connect Timeout=300;Network Library=dbnmpntw;Application Name=SqlSetup
SQLEngine: : Checking Engine checkpoint ‘ServiceConfigConnect’
SQLEngine: –SqlDatabaseServiceConfig: Connecting to SQL….
Sco: Attempting to connect script
Connection string: Data Source=\\.\pipe\SQLLocal\MSSQLSERVER;Initial Catalog=master;Integrated Security=True;Pooling=False;Connect Timeout=300;Network Library=dbnmpntw;Application Name=SqlSetup
Sco: Connection error code from SqlException is : 2
Prompting user if they want to retry this action due to the following failure:
—————————————-
The following is an exception stack listing the exceptions in outermost to innermost order
Inner exceptions are being indented
Exception type: Microsoft.SqlServer.Configuration.Sco.ScoException
Message:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)
HResult : 0x84bb0001
FacilityCode : 1211 (4bb)
ErrorCode : 1 (0001)
Data:
DisableRetry = true
Inner exception type: System.Data.SqlClient.SqlException
Message:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)
HResult : 0x80131904
Data:
HelpLink.ProdName = Microsoft SQL Server
HelpLink.EvtSrc = MSSQLServer
HelpLink.EvtID = 2
HelpLink.BaseHelpUrl = http://go.microsoft.com/fwlink
HelpLink.LinkId = 20476
Stack:
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, SqlConnection owningObject, Boolean withFailover)
at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject, Boolean withFailover)
at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, Int64 timerStart)
at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open()
at Microsoft.SqlServer.Configuration.Sco.SqlScriptExecution.GetConnection()
at Microsoft.SqlServer.Configuration.Sco.SqlScriptExecution.Connect()

WORKAROUND/SOLUTION

After doing a lot of investigation, I found that this was due to TLS settings. My client was installing SQL Server 2014 RTM version which it doesn’t support TLS 1.2.

We uninstalled everything and disabled TLS 1.2 and enabled TLS 1.0

Here are the steps:

1. Enable TLS 1.0 on the server. by following below KB article.TLS 1.2 support for Microsoft SQL Server
2. Restart the server.
3. Install SQL Server 2014 and patch to latest version.
4. Disable TLS 1.0.
5. Restart the server.

After this, the SQL was installed, and the application was able to connect to SQL Server.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – FIX: Install Error: A Network-Related or Instance-Specific Error Occurred While Establishing a Connection to SQL Server

During my consultancy engagement, my client’s DBA team was checked ERRORLOG and asked me the possible cause of below error about service broker.

DateTime spid74s      Error: 9642, Severity: 16, State: 3.
DateTime spid74s      An error occurred in a Service Broker/Database Mirroring transport connection endpoint, Error: 8474, State: 11. (Near endpoint role: Target, far endpoint address: ”)

From the above message, we can figure out that there is some system session in SQL which is trying to connect to some endpoint. I checked and they confirmed that they were not using service broker. But they were using Always On Availability Group.

I checked data synchronization and it was fine. Rows which were modified on primary was reaching to secondary as well. This means there was no issue with data movement also.

While enquiring further I learned that they are using a Read-Only Routing feature that was not working properly.

WORKAROUND/SOLUTION

As soon as I checked the availability group properties and checked Read-Only Routing configuration, everything has fallen in place and started making sense.  Here is what I saw in the properties.

Do you see a problem here?

When the request hits primary, it finds the routing and request try to go to 5022 port on secondary. That port is not meant for client connectivity and hence the error.

Whenever we try to connect to a listener and perform read-only routing at the very same time, we were seeing mirroring endpoint error.

To fix the issue, we corrected the port number to the ports on which SQL Server was listening, After fixing the issue, routing started working and we also found that error disappeared.

The same error can be reproduced if you try to connect to SQL Server on a port on which SQL is listening but not for client connectivity.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Error: 9642 – An error occurred in a Service Broker/Database Mirroring transport connection endpoint

One of my clients was trying to automate SQL deployment. While testing they were stuck with an interesting error and then they contacted me. In this blog, I would share my learning about an installation error: System.ArgumentNullException – Value cannot be null.

THE SITUATION

They had an internal website where they would take inputs from the user about the server, instance name, standalone or clustered, features, etc. and based on that they generate a setup configuration file and install SQL using that file. Randomly they noticed that in some cases, installation was failing.

When I was engaged, I asked for the installation log to find the error message from a failed installation. I found the following information in the Detail.txt file.

The following is an exception stack listing the exceptions in outermost to innermost order Inner exceptions are being indented
Exception type: System.ArgumentNullException
Message:
Value cannot be null.
Parameter name: instanceName
HResult : 0x80004003
Stack:
at Microsoft.SqlServer.Configuration.Fulltext.Util.IsDefaultInstanceName(String instanceName)

From Summary.txt, I was able to find the configuration file parameter which points to the setup configuration file of SQL Server.

WORKAROUND/SOLUTION

As you can imagine, the issue was due to an empty value of the parameter. After carefully examining the files, we found that the InstanceName parameter was missing in the file in certain conditions. They thought since it is a default instance, they need not pass anything, but we needed to pass MSSQLSERVER.

They changed their code to take care of this empty value, the issue was resolved.

Reference : Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Installation Error: System.ArgumentNullException – Value Cannot be Null

While working with one of the clients to recover from a disaster, I encountered an error. In this blog we would talk about error Drop failed for Availability Group. If you want any such assistance, you can hire me for quick consultation using On Demand offering.

THE SITUATION

When I got a call from my client, they were into the situation where availability group was not coming online. After an investigation, we concluded that their windows cluster was having issues and it was unable to start. The solution in such disaster is to start windows cluster in force quorum mode.

Once we started to cluster it in ForceQuorum mode (also called as fix quorum) we tried deleting the AG and received below error.

Failed to destroy the Windows Server Failover Clustering group corresponding to availability group ‘AG’.  The operation encountered SQL Server error 41000 and has been terminated.  Refer to the SQL Server error log for details about this SQL Server error and corrective actions.
An error occurred while removing availability group ‘AG’. The DROP AVAILABILITY GROUP command removed the availability group configuration from the local metadata. However, the attempt to remove this configuration from the Windows Server Failover Clustering (WSFC) cluster failed because the Always On Availability Groups manager is not online (SQL Server error: 41081). To remove the availability group configuration from the WSFC cluster, re-enter the command. (Microsoft SQL Server, Error: 41081)

In above error message, we see another error number: 41000 for which the text is as follows. “Failed to obtain the local Windows Server Failover Clustering (WSFC) handle (Error code %d).  If this is a WSFC availability group, the WSFC service may not be running or may not be accessible in its current state.  Otherwise, contact your primary support provider.  For information about this error code, see “System Error Codes” in the Windows Development documentation.”

WHAT YOU SHOULD DO?

Well, no action needed. The message raised is not a dangerous error message. It clearly mentions that availability group information has been removed from SQL Server, but it might still exist in the failover cluster. So, you can click OK on message and check availability group in SSMS and it should be gone from “Always On High Availability” > “Availability Group”. At this point, the database would be in restoring state and you need to bring them online using below

ALTER DATABASE <DBName> SET ONLINE

OR

RESTORE DATABASE <DBName> WITH RECOVERY

Once things are back to normal, you need to reconfigure availability again.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Drop failed for Availability Group – Failed to Destroy the Windows Server Failover Clustering Group Corresponding to Availability Group

While deploying Always On Availability Group with a client, they found that when they use automatic seeding, the database was not shown on secondary. After digging more, we found that it was there earlier in “Restoring” state when seeding was in progress but then it automatically disappeared from the list of databases on secondary.  Here is the option in the wizard.

Here are a few earlier blogs which I wrote about seeding failures.

SQL SERVER – AlwaysOn Automatic Seeding – Database Stuck in Restoring State

SQL SERVER – AlwaysOn Automatic Seeding Failure – Failure_code 15 and Failure_message: VDI Client Failed

I checked SQL Server ERRORLOG to figure out what might have gone wrong with auto-seeding.

SQL SERVER – Where is ERRORLOG? Various Ways to Find ERRORLOG Location

The important messages about the database, which we tried to seed, are as follows.

Error: 1412, Severity: 16, State: 211.
The remote copy of database “DB” has not been rolled forward to a point in time that is encompassed in the local copy of the database log.
Starting up database ‘DB’.
The database ‘DB’ is marked RESTORING and is in a state that does not allow recovery to be run.
Automatic seeding of availability database ‘DB’ in availability group ‘AG’ failed with an unrecoverable error. Correct the problem, then issue an ALTER AVAILABILITY GROUP command to set SEEDING_MODE = AUTOMATIC on the replica to restart seeding.

The last bullet has an interesting message and tells who to restart the seeding. The very first message (Error: 1412, Severity: 16, State: 211.) tells us the cause of the problem.

You need to monitor seeding using DMVs. There are two dynamic management views (DMVs) for monitoring seeding: sys.dm_hadr_automatic_seeding and sys.dm_hadr_physical_seeding_stats. One of them shows information about seedings happening currently and “stats” show the historical data about seeding. In this case, seeding failed with SQL Error.

WORKAROUND/SOLUTION

The cause of the problem was an additional log backup which happened while seeding was in progress.  I used my own earlier blog to find backup history SQL SERVER – Get Database Backup History for a Single Database

After running the script from my blog (on ALL replicas), we found that a backup job which was taking log backup on “another” replica every 15 minutes. We disabled the job and started seeding again. This time it worked without any issue.

Have you encountered some error during Always On Availability Group? Please share via comments and help others.

Reference: Pinal Dave (https://blog.SQLAuthority.com)

First appeared on SQL SERVER – Automatic Seeding of Availability Database ‘DB’ in Availability Group ‘AG’ Failed With an Unrecoverable Error

I recently had a very simple and interesting error received while I was working with Docker and Persistence Storage for my upcoming SQL Server Performance Tuning Practical Workshop. The error was related to script upgrade mode and the fix was extremely simple. Let us see the entire story today.

Earlier on this blog, I wrote a blog post about SQL SERVER – Docker Volume and Persistent Storage. During the blog post, I explained how with the help of the docker we can instantly upgrade our SQL Server instantly. It was a fantastic feature as if you think when we have to update SQL Server with the latest update, we have to re-install SQL Server and it takes a lot of time. However, with the help of Volume, we can easily upgrade SQL Server in just within a minutes.

Fix Error for Upgrade Mode

Recently, I attempted to upgrade my SQL Server CU to the latest version of SQL Server and instantly I got the following error:

Login failed for user ‘sa’. Reason: Server is in script upgrade mode. Only administrator can connect at this time. (Microsoft SQL Server, Error: 18401)

Here is the screenshot of the error.

Fix/Workaround/Solution:

Well, the solution if this issue is very simple. I just waited for about 1 minute and attempted to log in again and I was able to login immediately. Whenever we are using Docker and Volume, our data remains on the persistent storage but our core engine is updated. Once SQL Server comes up with the new update, it runs few of the upgrade scripts for your database. While the scripts are running the database even though looks up it does not allow you to connect with it.

In most of the cases, the script upgrade takes 1 minute or 2 minutes of time. If you wait for that much and try to log in, your error will go away. Well, if you are here searching for the solution to this problem. I am very confident by the time you finished reading this blog post the error is gone. Just go ahead and try to login again and it should work.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Fix Error – Login failed for user. Reason: Server is in script upgrade mode. Only administrator can connect at this time. (Microsoft SQL Server, Error: 18401)

This was one of an interesting error which I received while preparing for a demo. I wanted to demonstrate a disaster recovery scenario by doing backup and restore. In this blog we would learn how to fix Msg 4353 – Conflicting file relocations have been specified for the file. Only a single WITH MOVE clause should be specified for any logical file name.

To reproduce this error, we need to create a database which has two files which the same “logical” name and different physical name. Creating that is also a tricky and for me, it was created due to my copy/paste mistake. If you or your developers are lazy like me, you can run into this error.

Before running below, make sure C: has a folder called Temp.

CREATE DATABASE [SQLAuthority]
ON PRIMARY
(NAME = 'SQLAuthority', FILENAME = 'C:\Temp\SQLAuthority.mdf')
LOG ON
(NAME = 'SQLAuthority_log', FILENAME = 'C:\Temp\SQLAuthority_log.ldf')
GO

Now, I am adding 2 data files and 2 log files.

ALTER DATABASE SQLAuthority ADD FILE
(NAME = 'SQLAuthority_D1', FILENAME = 'C:\Temp\D1.ndf'),
(NAME = 'SQLAuthority_D1', FILENAME = 'C:\Temp\D2.ndf')
GO
ALTER DATABASE SQLAuthority ADD LOG FILE
(NAME = 'SQLAuthority_L1', FILENAME = 'C:\Temp\L1.ndf'),
(NAME = 'SQLAuthority_L1', FILENAME = 'C:\Temp\L2.ndf')

Do you notice any problem in above? Yeah, two physical files having a same logical name.

I took a backup of this database as below.

BACKUP DATABASE SQLAuthority TO DISK = 'C:\Temp\SQLAuthority.bak'

Here is the output

Processed 328 pages for database ‘SQLAuthority’, file ‘SQLAuthority’ on file 1.
Processed 8 pages for database ‘SQLAuthority’, file ‘SQLAuthority_D1’ on file 1.
Processed 8 pages for database ‘SQLAuthority’, file ‘SQLAuthority_D1’ on file 1.
Processed 3 pages for database ‘SQLAuthority’, file ‘SQLAuthority_log’ on file 1.
Processed 0 pages for database ‘SQLAuthority’, file ‘SQLAuthority_L1’ on file 1.
Processed 0 pages for database ‘SQLAuthority’, file ‘SQLAuthority_L1’ on file 1.
BACKUP DATABASE successfully processed 347 pages in 0.050 seconds (54.140 MB/sec).

You can clearly see that backup is happening for all the files, including duplicates. Now, I wanted to restore the database on a different server. Since there was no C:\Temp on the destination server, I decided to relocate the files to a different folder, so I used UI to restore it. Here is the error which I got.

Conflicting File Story

When I looked at T-SQL, here is the one which is failing

USE [master]
RESTORE DATABASE [SQLAuthority]
FROM DISK = N'D:\SQLAuthority.bak'
WITH FILE = 1
,MOVE N'SQLAuthority' TO N'F:\DATA\SQLAuthority.mdf'
,MOVE N'SQLAuthority_D1' TO N'F:\DATA\D1.ndf'
,MOVE N'SQLAuthority_D1' TO N'F:\DATA\D2.ndf'
,MOVE N'SQLAuthority_log' TO N'F:\LOG\SQLAuthority_log.ldf'
,MOVE N'SQLAuthority_L1' TO N'F:\LOG\L1.ndf'
,MOVE N'SQLAuthority_L1' TO N'F:\LOG\L2.ndf'
,NOUNLOAD
,STATS = 5
GO

As we can see, we have the same logical name twice in the restore statement.

WORKAROUND/SOLUTION

The error message is saying a pretty obvious thing but why did it allow me to do that in the first place? ALTER command which I ran, in the beginning, should have shown the error message to me about conflicting files. However, there is no error for the conflicting files.

Anyways, the workaround would be to create the same path as the source on this server. Basically, we need to avoid MOVE command and let it restore files at the same location where they wanted to go.

Another workaround would be to rename the logical file name using below command.

USE [SQLAuthority]
GO
ALTER DATABASE [SQLAuthority] MODIFY FILE (NAME=N'SQLAuthority_D1', NEWNAME=N'SQLAuthority_D2')
GO
USE [SQLAuthority]
GO
ALTER DATABASE [SQLAuthority] MODIFY FILE (NAME=N'SQLAuthority_L1', NEWNAME=N'SQLAuthority_L2')
GO

Interestingly, the above command changes name only for the one file (out of two in this case). Once renamed then another backup is needed to be restored.

Reference : Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – FIX: Msg 4353 – Conflicting File Relocations Have Been Specified for File. Only a Single WITH MOVE Clause Should be Specified for Any Logical File Name

I was in a situation where I was helping the customer to overcome a disaster. They had a hardware failure and the master database was corrupted. The plan was to first rebuild system databases and then restore ALL databases from the backup. Today we will discuss an error about REBUILDDATABASE.

REBUILDDATABASE

We used below command to rebuild system databases:

Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=”domain\username”

Above command was taken from Microsoft documentation where we had some optional parameters. The setup failed with below error in the setup logs after running command related to REBUILDDATABASE.

Feature: Database Engine Services
Status: Failed: see logs for details
Reason for failure: An error occurred during the setup process of the feature.
Next Step: Use the following information to resolve the error, and then try the setup process again.
Component name: SQL Server Database Engine Services Instance Features
Component error code: 0x851A0012
Error description: Missing sa account password. The sa account password is required for SQL Authentication Mode.

WORKAROUND/SOLUTION

The documentation shows SAPWD as optional so I was missing it. It looks like if SQL was installed with MIXED mode authentication then the parameter is mandatory.

Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=APG1P /SQLSYSADMINACCOUNTS=” domain\username” /SAPWD= AVery@Strong@Password123

After running above command, the setup completed successfully. Post that we restored all the databases including master and they were back in the business.

Here are a few additional blog posts related to this blog post. Please do read them for additional information.

• SQL SERVER – Difference Between SQL Login and SQL User – SQL in Sixty Seconds #070
• SQL SERVER – Errorlog The Server was Unable to Initialize Encryption Because of a Problem with a Security Library
• SQL SERVER – Beginning of SQL Server SecuritySecurity means that only relevant data should be available to authenticated persons. It additionally includes appropriate restrictions on the use of data, as well as controls to prohibit data theft. In case data is stolen by unauthorized users, security systems do not allow them to make use of it.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – REBUILDDATABASE Error: 0x851A0012 – Missing sa Account Password. The sa Account Password is Required for SQL Authentication Mode

This blog would be useful for those who are recovering from a disaster and are trying to rebuild system databases for SQL Server. In this blog, we would learn how to fix permission related error which I observed during the rebuild of system databases using SQL Setup. The error message in the log was: While updating the permission setting for the folder, the permission setting update failed for the file. Today we will discuss an error about REBUILDDATABASE.

REBUILDDATABASE

I wrote a blog earlier which one of my clients followed about an error in the rebuild database. SQL SERVER – REBUILDDATABASE Error: 0x851A0012 – Missing sa Account Password. The sa Account Password is Required for SQL Authentication Mode

The same command was tried by my clients, but it was failing with different error:

Overall summary:
Final result: Failed: see details below
Exit code (Decimal): -2066808828
Start time: yyyy-mm-dd hh:mm:ss
End time: yyyy-mm-dd hh:mm:ss
Requested action: RebuildDatabase
Feature: Database Engine Services
Status: Failed: see logs for details
Reason for failure: An error occurred during the setup process of the feature.
Next Step: Use the following information to resolve the error, and then try the setup process again.
Component name: SQL Server Database Engine Services Instance Features
Component error code: 0x84CF0004
Error description: While updating permission setting for folder ‘F:\MSSQL\MSSQLSERVER\Data\MSSQL11.MSSQLSERVER\MSSQL\JOBS’ the permission setting update failed for file ‘F:\MSSQL\MSSQLSERVER\Data\MSSQL11.MSSQLSERVER\MSSQL\JOBS\Check DB_20190521170029.txt’. The folder permission setting were supposed to be set to ‘D:P(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO)(A;OICI;FA;;;S-1-5-80-4075806543-296798423-764872590-3661508593-3560600922)’.

WORKAROUND/SOLUTION

When I searched for an error message, I found Microsoft KB,

but it was not applicable to us there were no mount points involved here. Also, the file name mentioned in the message was a file which was a job history created long ago. After deleting the file, we ran setup again and it failed for a different file.

It looks like, due to some unknown reason, SQL Setup was not able to set permission to files. The quick solution which worked for me was to move JOBS folder to somewhere else (outside “Program Files”) and created empty folder with same name. It looks like it was due to some kind of corruption in the file permission.

Have you seen such error while doing rebuild database or some other setup activity?

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – REBUILDDATABASE Error: 0x84CF0004 – While updating permission setting for folder The Permission Setting Update Failed for File

I was recently helping my client to SQL recovery from a hardware failure. I have implemented a good backup strategy for them, and things were easy. I saw a few interesting errors and I am writing a blog on them from the past few days. In this blog, we would discuss error: Error: 5173 – One or more files do not match the primary file of the database.

When I was trying to start SQL Server, it was getting started successfully but MSDB was not coming online.

• 2019-05-13 07:46:25.450 spid4s Error: 5173, Severity: 16, State: 1.
• 2019-05-13 07:46:25.450 spid4s One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files. If this is an existing database, the file may be corrupted and should be restored from a backup.
• 2019-05-13 07:46:25.450 spid4s Log file ‘L:\MSSQL\ DATA\MSSQL14.MSSQLSERVER\MSSQL\DATA\MSDBLog.ldf’ does not match the primary file. It may be from a different database or the log may have been rebuilt previously.

WORKAROUND/SOLUTION

From the error message provided in SQL Server ERRORLOG, it is clear that the file is corrupted. There are two situations which you might have:

1. If you have backups available, then restore last known good backup.
2. If there is no backup available for MSDB database, then there are more steps to be followed. First, secure all the existing database files and save them to a different location. Few of them might be corrupted as well but take MDF and LDF backups to secure location. Next steps would be to perform REBUILDDATABASE as per this document.

Once rebuild is complete, then stop SQL Server and replace all the files which were secured earlier. In this situation MSDB was corrupt so we can leave MSDB and replace others.

As I mentioned earlier, we had backups taken of the database and all we needed to do was restore the MSDB database (first situation). If you are in situation # 2 and you don’t have MSDB backup then you need to find a way to recreate everything that you had in MSDB like Jobs, operator, log shipping, etc. That’s why taking regular backup is always a good idea and this client didn’t lose any data due to our backup strategy.

If you are looking for any such consultancy, feel free to contact me by visiting this link https://blog.sqlauthority.com/hire-me/

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Error: 5173 – One or More Files do Not Match the Primary File of the Database

While working with a client, I encountered few errors while using linked server and I am going to share my solutions via a few blog posts. In this blog we would talk about fixing error 15274 – Access to the remote server is denied because the current security context is not trusted.

Before I talk about the problem and the solution, I must share a few environment details.

Remote Server Error

In my lab, I got two servers SQLSERVER-0 and SQLSERVER-1. The linked server was created on SQLSERVER-1 which was given name as ONE, connecting to SQL SERVER-1. There are two databases involved here. On source server (SQLSERVER-0) I have a database called SQLDB0 and on destination (SQLSERVER-1), a database is called SQLDB1.

1. Linked server “test connection” was working just fine.
   
2. Linked server was not created using “SQL Server” option, but “Other data source” was used before application wanted to use a different name.
   
3. Simple queries were working fine but a stored procedure which was using “execute as user” was failing.

Here is the error which was coming when we were executing a stored procedure. Here is an oversimplified version of the stored procedure. The procedure is created in database SQLDB0.

CREATE PROCEDURE usp_fetch_data
AS
BEGIN
	EXECUTE AS user = 'user_no_login'
	SELECT *
	FROM One.SQLDB1.dbo.Table_1
	REVERT
END

And here is the error message when I execute it as below.

Here is the text of the error message.

Msg 15274, Level 16, State 1, Procedure usp_fetch_data, Line 5 [Batch Start Line 9]
Access to the remote server is denied because the current security context is not trusted.
I captured profiler trace but found nothing interesting.  Since error message was talking about “TRUSTED”, I recalled TRUSTWORTHY property of the database.

WORKAROUND/SOLUTION

My feeling was correct. As soon as I changed the database property on the source database, the above error disappeared. Here is the T-SQL to check the property.

SELECT is_trustworthy_on, name 
FROM sys.databases
WHERE name = 'SQLDB0'
GO

If you see is_trustworthy_on set as 0 (ZERO) then run below command to enable it and make it 1 (ONE).

ALTER DATABASE SQLDB0 SET TRUSTWORTHY ON
GO

Have you seen a similar error? Did you find any other solution?

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – FIX: Msg 15274 – Access to the Remote Server is Denied Because the Current Security Context is not Trusted

Today we will see an interesting story about Memory Optimized Tables, Transactions, Isolation Level and Error. While I was working with my customer with Comprehensive Database Performance Health Check, we came across a very interesting situation.

My customer was a financial institute and they had very high transactions every single second. We had successfully implemented In-Memory OLTP technology for them. There were situations where we have to use the Memory-Optimized tables and disk-based regular tables in the single transactions.

Every time whenever we ran query which was accessing memory-optimized table and disk-based table, we were getting an error and my client did not want any error.

Here is the script when I ran it gave us an error:

BEGIN TRANSACTION
SELECT *
FROM [dbo].[MemoryOptimizedTable] mt
INNER JOIN [dbo].[DiskBasedTable] dt ON mt.ID = dt.ID
GO
COMMIT TRANSACTION
GO

Please note in the above script one table is memory optimized and another one is disk based table. Whenever I ran the script it gave me following error.

Msg 41368, Level 16, State 0, Line 3
Accessing memory optimized tables using the READ COMMITTED isolation level is supported only for autocommit transactions. It is not supported for explicit or implicit transactions. Provide a supported isolation level for the memory optimized table using a table hint, such as WITH (SNAPSHOT).
Msg 3902, Level 16, State 1, Line 8
The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.

The reason for the error is that in SQL Server In-Memory OLTP whenever you try to access any disk-based and memory optimized table in the single transactions, it will give you an error as that is not directly supported unless you change the isolation of the query or database.

WORKAROUND/SOLUTION for Memory Optimized Tables

Here is the simple solution of the above error.

When you change the isolation level for the database to MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT the error will go away and your SQL Server will support implicit or explicit transactions cross-container (across disk and memory)

-- for Cross Container Transactions
ALTER DATABASE CURRENT 
SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON
GO

Well, that’s it!

Reference: Pinal Dave (https://blog.SQLAuthority.com)

First appeared on SQL SERVER – Memory Optimized Tables, Transactions, Isolation Level and Error

I always recommend my client to go with the latest and great version of tools like SQL Server Management Studio (SSMS). In this blog, we would learn about a situation where an older version of SSMS was giving an error while adding a new database to existing availability group – This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

THE SITUATION

My client had an existing availability group which was set up and deployed by a vendor. Now, they wanted to add a new database to an existing availability group. They were using the wizard to add the database. They selected the option to do a fresh backup/restore. Due to old SSMS version, automatic seeding option was not available. Here was the error which they were getting in the UI.

Here is the text of error message:

Restoring database log resulted in an error. (Microsoft.SqlServer.Management.HadrTasks)
——————————
ADDITIONAL INFORMATION:
Restore failed for Server ‘SQLSERVER-1’. (Microsoft.SqlServer.SmoExtended)
——————————
System.Data.SqlClient.SqlError: This BACKUP or RESTORE command is not supported on a database mirror or secondary replica. (Microsoft.SqlServer.Smo)

The surprising part was that even after the error came, the database was added to the availability group successfully. This means the error was a benign error and can be ignored but I want to know what error was appearing. To dig further I generated the script of Always On and executed it manually. It failed with the exact same error.

WORKAROUND/SOLUTION for RESTORE command

It was clear that the database was getting added successfully due to automatic seeding. We can see below in ERRORLOG.

Primary Replica:

• Database backed up. Database: OneMoreDatabase, creation date(time): 2019/06/11(13:21:51), pages dumped: 355, first LSN: 38:2800:1, last LSN: 38:2824:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {‘\\sqlserver-0\Share\OneMoreDatabase.bak’}). This is an informational message only. No user action is required.
• Database backed up. Database: OneMoreDatabase, creation date(time): 2019/06/11(13:21:51), pages dumped: 522, first LSN: 38:2712:1, last LSN: 38:2824:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {‘{3AFC5950-4E79-4225-B572-0A70AD876E45}’}). This is an informational message only. No user action is required.
• Log was backed up. Database: OneMoreDatabase, creation date(time): 2019/06/11(13:21:51), first LSN: 38:2712:1, last LSN: 38:2824:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {‘\\sqlserver-0\Share\OneMoreDatabase_20190626054651.trn’}). This is an informational message only. No user action is required.

Secondary Replica:

• Database was restored: Database: OneMoreDatabase, creation date(time): 2019/06/11(13:21:51), first LSN: 38:2712:1, last LSN: 38:2824:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {‘{E9D35CEB-D6FD-40D6-A73C-06560EFD95D9}’}). Informational message. No user action required.
• Database was restored: Database: OneMoreDatabase, creation date(time): 2019/06/11(13:21:51), first LSN: 38:2800:1, last LSN: 38:2824:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {‘\\sqlserver-0\Share\OneMoreDatabase.bak’}). Informational message. No user action required.

If we look at the backup and restore commands, there are two backups. Once on TYPE=DISK and another on TYPE=VIRTUAL_DEVICE. The second backup comes when there is an automatic seeding happening for the database.

Running script manually fails with below (on secondary). This is the same what we get from the UI.

Connecting to sqlserver-1…
Msg 3059, Level 16, State 2, Line 29
This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.
Msg 3013, Level 16, State 1, Line 29
RESTORE LOG is terminating abnormally.
Disconnecting connection from sqlserver-1…
Connecting to sqlserver-1…
Msg 41145, Level 16, State 1, Line 67
Cannot join database ‘DWConfiguration’ to availability group ‘XAG’. The database has already joined the availability group. This is an informational message. No user action is required.
Disconnecting connection from sqlserver-1…

When I compared the script generated from SSMS for an old and new version, I found the difference which explained the issue clearly. This was the extra command in the new version of SSMS.

ALTER AVAILABILITY GROUP [XAG]
MODIFY REPLICA ON N'sqlserver-1' WITH (SEEDING_MODE = MANUAL)

This means that SSMS is smart enough to change the mode to MANUAL when below option is selected.

So, to conclude, the seeding was set to AUTOMATIC for the replica. When we were using an older version of SSMS, it was doing both automatic seeding and backup/restore. This was causing restore to fail because it was seeded already and added successfully.

You can use below query to find replica seeding mode.

SELECT ag.name
	,replica_server_name
	,seeding_mode_desc
FROM sys.availability_replicas ar
	,sys.availability_groups ag
WHERE ag.group_id = ar.group_id
	AND name = 'AGSQLAGDB'

Have you seen such errors of SSMS? Please comment and let me know.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Add Database to Availability Group Failure – This BACKUP or RESTORE Command is Not Supported on a Database Mirror or Secondary Replica

This is one of the features which I wanted to demonstrate to my clients while delivering my service Comprehensive Database Performance Health Check. So, while preparing for a demo I encountered a strange error. In this blog we would learn about fixing error: Cannot insert a duplicate key row in object ‘sys.sysschobjs’ with unique index ‘clst’ while using DBCC CLONEDATABASE.

The command which I executed was:

DBCC CLONEDATABASE('AdventureWorks2016CTP3','AdventureWorks2016CTP3_clone')

And the error is below:

Database cloning for ‘AdventureWorks2016CTP3’ has started with target as ‘AdventureWorks2016CTP3_08’.
Msg 2601, Level 14, State 1, Line 1
Cannot insert duplicate key row in object ‘sys.sysschobjs’ with unique index ‘clst’. The duplicate key value is (885578193).

I wanted to go further to fix it but ‘sys.sysschobjs’ is a system object and it was giving error while querying

Msg 208, Level 16, State 1, Line 6
Invalid object name ‘sys.sysschobjs’.

I realized that I need to connect via DAC connection. I logged in via DAC (ADMIN:SERVERNAME in SSMS) and ran below query to find what we have in AdventureWorks2016CTP3 and model database.

USE AdventureWorks2016CTP3
GO
SELECT *
FROM sys.sysschobjs 
WHERE id = 885578193
GO
USE model
GO
SELECT *
FROM sys.sysschobjs
WHERE id = 885578193
GO

This gave me below output:

As we can see now, I have a table in the Model database which is having the same ID.

WORKAROUND/SOLUTION – CLONEDATABASE

Since the ID was matching, I dropped the table in the model to get rid of that same ID. I tried to drop and recreate but it gave me the error again with new id. Finally, I dropped the table from the model database and cloning succeed.

Database cloning for ‘AdventureWorks2016CTP3’ has started with target as ‘AdventureWorks2016CTP3_clone’.
Database cloning for ‘AdventureWorks2016CTP3’ has finished. Cloned database is ‘AdventureWorks2016CTP3_clone’.
Database ‘AdventureWorks2016CTP3_clone’ is a cloned database. This database should be used for diagnostic purposes only and is not supported for use in a production environment.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

In short, if you encounter any error in cloning the database check model database first to see if there is any conflicting object.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – DBCC CLONEDATABASE Error: Cannot Insert Duplicate Key Row In Object ‘sys.sysschobjs’ With Unique Index ‘clst’.

A few days ago, I wrote a blog about an error while creating a clone of a database using DBCC CLONEDATABASE command. Here is the link to read that blog. SQL SERVER – DBCC CLONEDATABASE Error: Cannot Insert Duplicate Key Row In Object ‘sys.sysschobjs’ With Unique Index ‘clst’.

Here is another error received by me while running DBCC CLONEDATABASE. The message looks very similar but different system table.

Database cloning for ‘SQLAUTH’ has started with target as ‘SQLAUTH_CLONE’.
Msg 2601, Level 14, State 1, Line 1
Cannot insert duplicate key row in object ‘sys.sysowners’ with unique index ‘nc1’. The duplicate key value is (Domain\DBReader).

WORKAROUND/SOLUTION for CLONEDATABASE

Since it was appearing again, I started reading more about it and documentation from Microsoft says below:

DBCC CLONEDATABASE doesn’t support the creation of a clone if there are any user objects (tables, indexes, schemas, roles, and so on) that were created in the model database. If user objects are present in the model database, the database clone fails with the following error message:

Msg 2601, Level 14, State 1, Line 1
Cannot insert duplicate key row in object with unique index ‘index name’. The duplicate key value is

That makes perfect sense. As per documentation, I need to drop the object from the model database. As per error message which I received, it was due to a user in the model database. Once I dropped user, it went fine.

Here are a few related blog posts which you may find interesting:

• Impact of CHECKPOINT On Memory – SQL in Sixty Seconds #084
• SQL Server Performance Tuning Practical Workshop – Discovery Phase – Online Training
• SQL Server Performance Tuning Practical Workshop – Discovery Phase – In Person Training
• What is Faster, SUM or COUNT? – Interview Question of the Week #231
• SQL SERVER – Automatic Seeding of Availability Database ‘SQLAGDB’ in Availability Group ‘AG’ Failed With a Transient Error. The Operation Will be Retried
• SQL SERVER – Add Database to Availability Group Failure – This BACKUP or RESTORE Command is Not Supported on a Database Mirror or Secondary Replica

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – DBCC CLONEDATABASE Error – Msg 2601: Cannot Insert Duplicate Key Row in Object ‘sys.sysowners’ With Unique Index ‘nc1’.

Recently I was helping a customer who hired me for my services. He had an issue where they noticed that the size of the MSDB database has grown huge. Most of the situations I have been contacted when LDF (transaction log file) for the database is huge. But this time it was data file which was consuming a lot of space.

In the past, I have seen huge MSDB size and written below blogs.

• SQL SERVER – Stop Growing MSDB Database by Removing sysmail_mailitems History
• SQL SERVER – MSDB Database Uncontrolled Growth Due to Queue_messages. How to Clear All Messages from a Queue?

If you are not hitting one of the above-listed issues, then read further.

Since we confirmed this was due to the MDF file, we needed to figure out which table is consuming a lot of space.  Below is the query which I used:

SELECT OBJECT_NAME(object_id) AS Table_Name
	,SUM(rows) AS Total_Rows
FROM sys.partitions
WHERE index_id IN (0,1)
GROUP BY object_id
ORDER BY 2 DESC;

We found that it was sys.sysxmitqueue table which was bloated in size. Microsoft documentation says this table contains a row for each Service Broker transmission queue. I asked from my client if they are aware of any service broker implementation on this server and someone told that they did deploy some monitoring script.

WORKAROUND/SOLUTION – MSDB

This should be implemented if you are sure that you are OK to lose the data in the service broker queue. I double checked with my client and they were OK to clear all conversations from the queue because they were not needed. In fact, they were ready to clean up whatever objects were created by the script. Here is the silver bullet to fix the issue.

ALTER DATABASE [msdb] SET NEW_BROKER WITH ROLLBACK IMMEDIATE

As I mentioned above, the script would discard ALL the messages without attempting delivery.

If you are using service broker for your application, then you need to fix the application that is sending those messages else database will grow back again.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Huge Space Used by Table sysxmitqueue in MSDB. How to Clear it Quickly?

Recently I was trying to demonstrate how to move the files in Always On setup to one of my existing clients during Comprehensive Database Performance Health Check and learned something interesting. In this blog, I am going to share my learning about the mismatch between catalog views sys.master_files and sys.database_files.

Before we start let’s look at the documentation for both:

• master_files: Contains a row per file of a database as stored in the master database. This is a single, system-wide view.
• database_files: Contains a row per file of a database as stored in the database itself. This is a per-database view.

This means that the information is stored at separate places (master vs. database itself) and there could be situations when both are not in Sync state, which means the location may not be the same.

My client had a database in Always On availability group and they wanted to change the logical name of LDF file.  I was able to reproduce it in my lab servers.

Step 1

Create Database on Primary and take a backup so that it can be added to the availability group.

USE master
GO
CREATE DATABASE [SQLAuthority]
ON PRIMARY 
(NAME = N'SQLAuthority', FILENAME = N'F:\DATA\SQLAuthority.mdf' )
LOG ON 
(NAME = N'SQLAuthority_xxx', FILENAME = N'F:\DATA\SQLAuthority_log.ldf')
GO
BACKUP DATABASE SQLAuthority TO DISK = 'SQLAuthority.bak' WITH FORMAT
GO

Step 2

Create Availability group and add database created in step 1

Step 3

ALTER database on primary and change the logical file name for the transaction log file.

USE [SQLAuthority]
GO
ALTER DATABASE [SQLAuthority] MODIFY FILE 
(NAME=N'SQLAuthority_xxx', NEWNAME=N'SQLAuthority_log')
GO

Step 4

Now check logical name between primary and secondary.

:connect PRIMARY
USE master
GO
SELECT 'Primary',file_id ,name ,physical_name
FROM sys.master_files
WHERE database_id = DB_ID('SQLAuthority')
GO
USE SQLAuthority
GO
SELECT 'Primary' ,file_id ,name ,physical_name
FROM sys.database_files
GO
:connect SECONDARY
USE master
GO
SELECT 'Secondary' ,file_id ,name ,physical_name
FROM sys.master_files
WHERE database_id = DB_ID('SQLAuthority')
GO
USE SQLAuthority
SELECT 'Secondary' ,file_id ,name ,physical_name
FROM sys.database_files

Here is the output:

As you can see in highlighted that sys.master_files on secondary still have an old logical name but database_files had the correct name. I think this is because of the fact that ALTER command which we ran on primary has been replayed into the database due to Always On data movement.

WORKAROUND/SOLUTION

To fix this mismatch of data between two catalog views, database restart is needed. Since we can’t take the database offline and online due to the availability group, we can do any of two things:

1. Restart secondary replica OR
2. Perform failover, make secondary as primary and again failover to get same roles as earlier.

When I looked further into ERRORLOG, it looks like “Starting up database” in ERRORLOG fixes the mismatch, which is the startup of the database. I have not tried mirroring, but I believe it would happen there as well.

If you want any SQL related support from me, please contact me by visiting here. You can also connect me on LinkedIn.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Fix: Logical Name Mismatch Between Catalog Views sys.master_files and sys.database_files

As soon as SQL 2008 and SQL 2008 R2 went out of support, few of my clients contacted me to help them in fixing an error occurred during the upgrade. In this blog, I would share one of the upgrade failures. The Upgrade Error messages shown in ERRORLOG was “The server principal “SQLAuthority\AuthOwner” is not able to access the database “msdb” under the current security context.” I have changed the error message to hide secure information.

The situation was that they initiated upgrade and it failed at the very end and then SQL Service was not getting started. This is what I call as upgrade script failure. There are a few situations I have seen earlier which we have encountered due to some change in system settings. Here are a few earlier blogs about similar failures.

• SQL SERVER – Script level upgrade for database ‘master’ failed because upgrade step ‘sqlagent100_msdb_upgrade.sql’
• SQL SERVER – Script level upgrade for database ‘master’ failed – There is already an object named ‘DatabaseMailUserRole’ in the database
• SQL SERVER – Script level upgrade for database master failed – Error: 4860, Severity: 16, State: 1 – Cannot bulk load. SqlTraceCollect.dtsx does not exist
• SQL SERVER – Error 15559 – Error 912 – Script Level Upgrade for Database ‘master’ Failed

This time it was a new error, so I am blogging it. As usual, I asked for ERRORLOG and was looking for the cause of failure. Here are the last few lines in ERRORLOG when SQL was trying to start.

Error: 916, Severity: 14, State: 1.
The server principal “SQLAuthority\AuthOwner” is not able to access the database “msdb” under the current security context.
The failed batch of t-sql statements :
disable the collector first
EXEC sp_syscollector_disable_collector
Error: 912, Severity: 21, State: 2.
Script level upgrade for database ‘master’ failed because upgrade step ‘msdb110_upgrade.sql’ encountered error 916, state 1, severity 14. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the ‘master’ database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
Error: 3417, Severity: 21, State: 3.
Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.
SQL Server shutdown has been initiated
SQL Trace was stopped due to server shutdown. Trace ID = ‘1’. This is an informational message only; no user action is required.

Whenever we have such upgrade script failure issue and SQL is not getting started, we need to use trace flag 902 to start SQL which would bypass script upgrade mode. This would allow us the find the cause and fix it. So, here are the steps I have done.

1. Start SQL Server via Trace Flag 902. Based on default or named instance, run below command

NET START MSSQLSERVER /T902
or
NET START MSSQL$INSTANCE_NAME /T902

2. At this point, SQL should be started, and you need to connect to SQL by any of the preferred methods. You can use SSMS or T-SQL.
3. Based on the error message, the error was due to the database owner of the MSDB database. We executed the below script to change the owner of msdb database to “sa”. Even if it is disabled, it is fine.

USE msdb
GO
EXEC sp_changedbowner 'sa'
GO

4. Once the owner is changed, we need to stop SQL Service and start it again. You are free to use any method to stop and start the SQL service. I have used the command line to do the same.

NET STOP MSSQLSERVER /T902
or
NET STOP MSSQL$INSTANCE_NAME /T902

That’s it. You should be able to start SQL normally and come back in business. Have you encountered any such upgrade issues?

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Upgrade Error: The Server Principal is Not Able to Access the Database “msdb” Under the Current Security Context

Recently I tried installing SQL Server 2019 on my virtual machine. I encountered an interesting error which I have not seen earlier. In this blog, I would share the solution of error: Invalid command-line argument. Consult the Windows Installer SDK for detailed command-line help. Let us see the error about Installation Failure.

First, I looked into SQL Setup Summary.txt file and found the failure.

Feature: Java connector for HDFS data sources
Status: Failed
Reason for failure: An error occurred during the setup process of the feature.
Next Step: Use the following information to resolve the error, and then try the setup process again.
Component name: SQL PolyBase Java
Component error code: 1639
Component log file: C:\Program Files\Microsoft SQL Server\150\Setup Bootstrap\Log\20190726_144242\sql_polybase_java_inst_Cpu64_1.log
Error description: Invalid command line argument. Consult the Windows Installer SDK for detailed command line help.

In the log mentioned in Summary.txt, I found below:

MSI (s) (E4:80) [14:47:36:551]: Machine policy value ‘TransformsSecure’ is 0
MSI (s) (E4:80) [14:47:36:552]: User policy value ‘TransformsAtSource’ is 0
MSI (s) (E4:80) [14:47:36:552]: Machine policy value ‘DisableUserInstalls’ is 0
MSI (s) (E4:80) [14:47:36:552]: Specified instance {7E0C055D-520F-474C-A7ED-755405FBA017} via transform :InstID01.mst;:InstName01.mst is already installed. MSINEWINSTANCE requires a new instance that is not installed.
MSI (s) (E4:80) [14:47:36:552]: MainEngineThread is returning 1639
MSI (s) (E4:BC) [14:47:36:553]: User policy value ‘DisableRollback’ is 0
MSI (s) (E4:BC) [14:47:36:553]: Machine policy value ‘DisableRollback’ is 0
MSI (s) (E4:BC) [14:47:36:553]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (E4:BC) [14:47:36:553]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (E4:BC) [14:47:36:555]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (E4:BC) [14:47:36:555]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (00:A8) [14:47:36:557]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (00:A8) [14:47:36:557]: MainEngineThread is returning 1639

If we try to decode error number 1639 using windows net helpmsg command, we see same error what was reported in Summary.txt

Invalid command line argument. Consult the Windows Installer SDK for detailed command line help.

Below is the line just before the failure

Specified instance {7E0C055D-520F-474C-A7ED-755405FBA017} via transform :InstID01.mst;:InstName01.mst is already installed. MSINEWINSTANCE requires a new instance that is not installed.

When I searched on the internet, I found that this is due to the MSI incomplete install. I recalled that earlier I was installing SQL Server my Virtual machine was stopped (it is on my laptop and I did shutdown my laptop). Due to incomplete setup, I uninstall SQL completely but looks like this component didn’t remove properly. I found on the internet that I can use below command to uninstall MSI and fix such error.

msiexec /x {GUID}

In my case the GUID is in the error message i.e. {7E0C055D-520F-474C-A7ED-755405FBA017}

Here is the command I executed from the command prompt.

msiexec /x {7E0C055D-520F-474C-A7ED-755405FBA017}

As soon as I clicked Yes, it uninstalled the component. Then, I started to install again and it worked fine. Have you ever seen such an error? Did you find any other method to fix Installation Failure?

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER 2019 – Installation Failure – Invalid Command Line Argument. Consult the Windows Installer SDK for Detailed Command Line Help

One of my clients contacted me for whom I assisted in configuring Always On Availability Groups for the first time. They were getting an error whole taking log backup on secondary replica: Log backup for database “SQLAuthority” on secondary replica failed because the new backup information could not be committed on the primary database.

During implementation, I explained to them various topologies, pros, and cons and assisted them in doing the end-to-end implementation as this was their first availability group. If you want any such implementation related assistance, feel free to contact me.

Secondary Replica

After I implemented their first availability group, they got comfortable and implemented distributed availability group on their own. They contacted me and informed that things are going well but they are seeing an error when they take log backup of an availability database on a secondary replica of the secondary availability group. Below is the message from job history.

Log backup for database “SQLAuthority” on secondary replica failed because the new backup information could not be committed on the primary database. Check the database status in the SQL Server error log of the server instance that is hosting the current primary replica. If the primary database is participating in the availability group, retry the operation. Check the database status in the SQL Server error log of the server instance that is hosting the current primary replica. If the primary database is participating in the availability group, retry the operation. [SQLSTATE 42000] (Error 35296)  BACKUP LOG is terminating abnormally.

To make things simple, you can imagine a deployment like this.

myAG1 (mynode1, myNode2) <- myDistributedAG –> myAG2 (myNode3, myNode4)

Distributed availability group is created between myAG1 and myAG2. myNode1 is global primary and myNode3 is a forwarder. The failure of the job is happening on myNode4.

SOLUTION/WORKAROUND

I tried this in my lab, and I was able to get exactly the same error. I searched further and found that this is by design. I found below information in this link.

In a distributed availability group, backups can be performed on secondary replicas in the same availability group as the active primary replica, or on the primary replica of any secondary availability groups. Backups cannot be performed on a secondary replica in a secondary availability group because secondary replicas only communicate with the primary replica in their own availability group. Only replicas that communicate directly with the global primary replica can perform backup operations.

When I informed this to my client, they were able to understand this limitation and modify the scripts to take backup accordingly.

Have you seen such errors while working with the availability group? Please share via comments.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Error 35296: Log Backup for Database “SQLAuthority” on Secondary Replica Failed Because the New Backup Information Could Not be Committed on Primary Database