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

Unless you are living under rocks, you would have heard the word DevOps. I am sure you many of you are working on the DevOps as well and have a clear idea about what is DevOps. To be super honest, I still see people who are not sure what actually DevOps is and believe it is just a buzz word and will eventually go away. In today’s blog post, I would love to discuss DevOps and its future.

Definition of DevOps

Let us start our article with a quick definition:

DevOps is the practice of development and operations integrated together for entire software lifecycle from the design phase to deployment and from proactively monitoring to production support.

Honestly, DevOps is not one thing but it is a combination of various successful practices combined with the proven tools which increases any organizations’ ability to continuously deliver application at the rapid pace with high-quality measures.

The goal is to improve the efficiency from the earlier methodologies and reduce the possibilities of the errors in the delivery. Just so you know that this term can be used in multiple meanings and context but ultimately they are pointing to one thing – Better Efficiency Through Automation and Processes.

Steps of DevOps

there are few major steps of DevOps. Every one defines them differently, however, you will see a similar pattern and steps in all the processes.

The major four steps are Build, Test, Release, and Monitor. Once we are in the monitor phase, we keep on giving the necessary feedback to the next Build phase and release the complete cycle. Essentially DevOps looks something like in the following image:

The major advantages of this methodology are Speed, Reliability, Scale, Security, and efficient delivery.

SQL Server and Dev Ops

I often see that when organizations are building their application using development tools like .NET, PHP, Java, etc, they follow certain processes like Code Versioning, Change Tracking, Code Compiling, Build Deploying, Unit Testing, and Statistics Collections. These are very essential tools to deliver an application which has the least bug and easy to maintain. The process helps to reduce human errors at very much as well.

However, when it is about SQL Server, I often see people just deploying SQL Server with the help of running T-SQL scripts only. This pretty much works when the organization is small and application is still under development. However, once the organizations grow big, the same running script for deployment is not enough.

Once there are many developers in the team, there will be many versions of the code and objects. It is quite possible the code might be working perfectly fine in the isolation but it might not be conflicting with each other when they are deployed together. The final deployment might have multiple versions of the same code and often the order of the deployment will play a critical role as well.

A good deployment team which not only deploys the code but also monitors their execution is very critical after the deployment and feedback from the client should be provided back to the development team so during the next iteration they can do it more efficiently.

What we have so far discussed can be summed up in the two terms

• Continuous Integration (CI)
• Continuous Deployment (CD)

Tools of Dev Ops in SQL Server

Continuous Integration (CI) stands for the build and test phase whereas Continuous Deployment (CD) stands for the Release and Monitoring phase. There are many tools available to for Developer and DBA team for the SQL Server to achieve CI and CD. In SQL Server we can use Visual Studio Team Services, Azure Data Studio, SSIS, PowerShell, SQL Server Data Tools, bcp, T-SQL, mssql-scripter, SqlPackage, bcp, and sqlcmd to help you deploy successful DevOps processes.

Remember, it does not matter what tool ultimately you use for your SQL Server, your ultimate goal should be to help your organization deliver quality application at the rapid pace.

Call to Action

Well, that was a brief note for DevOps and if you are not sure where to start with the DevOps, I would say you should consider a third party tool which can help you to get started. I suggest you can start with Toad DevOps Toolkit and Foglight for Databases.

I strongly encourage you to join me in the 30-minute discussion (Webinar Link) about trends in DevOps. We will discuss where DevOps is heading in the database world and what DBAs and Developers should do to be industry ready when it goes to the mainstream.

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

First appeared on SQL SERVER – The Future of DevOps for DBA

While monitoring might be common practice for keeping databases running smoothly, this is often directed at maintenance tasks such as query performance or future planning. Sometimes this will include some checks for security, but these tend to be limited, defending only against what the DBA is already looking for.

The ‘How monitoring can help keep your SQL Server estate secure’ security whitepaper discusses the difficulty of defending against new or unknown attacks on your data systems, and how to introduce a broad surveillance approach to your monitoring and improve security. It covers why these attacks are hard to spot, the risks they pose, and what’s needed in a solution against them with SQL Monitor as an example.

Key Points for Monitoring

• Monitoring against known signs of attack might work against attacks you expect, but against novel or unusual attacks you won’t know what to look for.
  For example, you might be monitoring for SQL injection attacks by checking against errors known to be common when an attack is attempting to ‘blind-navigate’ your schema. If, however, the attacker is taking a different approach or has inside knowledge, this defense will eventually fail, as will any other depending on attackers acting in predictable ways.
• A broad surveillance-based approach to monitoring helps identify and stop these attacks by:
  • Measuring and establishing a baseline for a wide range of metrics on your data systems.
  • Flagging unusual patterns or events so people can investigate and stop the potential attack.
  • Separating the monitoring system from what’s being monitored, reducing the risk of a system and its defenses being comprised before an alert can be fired.

Call for Action

Here are two simple calls to action for you.

Try out Red-Gate SQL Monitor

Read more about how to keep your SQL Server estates secure.

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

First appeared on How Monitoring Can Help Keep Your SQL Server Estate Secure?

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

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 7416 – Access to the remote server is denied because no login-mapping exists.

Error Related to Remote Server

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

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), the database is called SQLDB1.

1. Linked server “test connection” was working just fine.
   
2. The 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 7416, Level 16, State 2, Procedure usp_fetch_data, Line 5 [Batch Start Line 10] Access to the remote server is denied because no login-mapping exists.

WORKAROUND/SOLUTION

It is important to note is that user_no_login is NOT a login but a user in the database created using below command.

CREATE USER [user_no_login] WITHOUT LOGIN WITH DEFAULT_SCHEMA=[dbo]
GO

Now, the question was how can I provide a mapping to a user? Here was the error which would come if we even try that.

Msg 15007, Level 16, State 1, Procedure master.dbo.sp_addlinkedsrvlogin, Line 76 [Batch Start Line 2]
‘user_no_login’ is not a valid login or you do not have permission.

‘user_no_login’ is not a valid login or you do not have permission.

The message is perfect as it’s not log in but a user in the database which is not mapped to any login. I searched further and found that we can provide this user id in the connection string, also called as Provider String. Here is what I have changed in the linked server definition.

-- NOT WORKING
EXEC master.dbo.sp_addlinkedserver @server = N'ONE', @srvproduct=N'SQL', @provider=N'SQLNCLI11', @datasrc=N'SQLSERVER-1', @provstr=N'Data Source=SQLSERVER-1'
-- WORKING (added "User ID" added @provstr)
EXEC master.dbo.sp_addlinkedserver @server = N'ONE', @srvproduct=N'SQL', @provider=N'SQLNCLI11', @datasrc=N'SQLSERVER-1', @provstr=N'Data Source=SQLSERVER-1;User ID=user_no_login'

I am not sure how it worked but we just passed the User ID parameter. This user was not present in the destination server. When I captured profiler, I found that this was passing login name which was provided in linked server properties. So, the user ID passed was just to bypass the error message.

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 7416 – Access to the Remote Server is Denied Because No Login-mapping Exists

Earlier I have written few blogs about automatic seeding feature. In this blog we would learn how to fix error: Automatic seeding of availability database ‘SQLAGDB’ in availability group ‘AG’ failed with a transient error.

Here are my earlier blogs 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

In both scenarios, the database was started to restore, and it failed in the middle due to which it was in “Restoring” state. But in my client’s situation, the database was not getting listed in the databases folder in SSMS.

Automatic Seeding and Error

Here is the way to reproduce the error

CREATE DATABASE [SQLAuthority]
ON PRIMARY
(NAME = 'SQLAuthority', FILENAME = 'C:\Temp\SQLAuthority.mdf')
LOG ON
(NAME = 'SQLAuthority_log', FILENAME = 'C:\Temp\SQLAuthority_log.ldf')
GO
ALTER DATABASE SQLAuthority ADD FILE
(NAME = 'SQLAuthority_D1', FILENAME = 'C:\Temp\D1.ndf')
GO
ALTER DATABASE SQLAuthority ADD LOG FILE
(NAME = 'SQLAuthority_L1', FILENAME = 'C:\Temp\L1.ndf'),
(NAME = 'SQLAuthority_L1', FILENAME = 'C:\Temp\L2.ndf')
GO
BACKUP DATABASE SQLAuthority TO DISK = 'SQLAuthority.bak'

This would create a database with two physical transaction log files with a same logical name. Once done, use Automatic Seeding and add a database to the availability group. It is not going to fail from the UI. Here is what you would see.

If you investigate and look at ERRORLOG file on secondary, here are the failure

• Error: 911, Severity: 16, State: 1.
• Database ‘SQLAuthority’ does not exist. Make sure that the name is entered correctly.
• Error: 4353, Severity: 16, State: 1.
• Conflicting file relocations have been specified for file ‘SQLAuthority_L1’. Only a single WITH MOVE clause should be specified for any logical file name.
• Error: 3013, Severity: 16, State: 1.
• RESTORE DATABASE is terminating abnormally.
• Automatic seeding of availability database ‘SQLAuthority’ in availability group ‘SQLAUTH-AG’ failed with a transient error. The operation will be retried.

This was a coincidence that I have written a blog about this error in a standalone scenario.

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 looked at the database and there were no duplicate logical names! I asked about this history of the database and if there was any file added and later removed and the answer was “Yes”.

WORKAROUND/SOLUTION

I tried a lot of things, removing files completely, breaking AG, removing the database from AG. But none worked. I was not able to add the database to AG.

Finally, I used the workaround given in my blog to rename the logical file to some new name.

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

Once the command was executed, I was able to add the database to AG via automatic seeding. Hopefully, Microsoft would see this blog and fix duplicate logical file name issue. Until then you can use a workaround.

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

First appeared on SQL SERVER – Automatic Seeding of Availability Database ‘SQLAGDB’ in Availability Group ‘AG’ Failed With a Transient Error. The Operation Will be Retried

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

While performing an in-place upgrade from SQL Server 2014 SQL server 2016 my client faced an error. In this blog, I am going to share the cause and the solution of error Microsoft .NET Framework 4.0 installation has failed with exit code  -2146498511 which was faced during SQL Server upgrade. Looking at the nature of error I am sure it can be encountered in installation as well.

Whenever I see any error number is negative I always convert it took hexadecimal. here is the hexadecimal for the error code 800F0831 (you can use a calculator to do so)

I started looking at setup logs and found below

Slp: Microsoft .NET Framework 4.0 installation has failed with exit code -2146498511.
Slp: Watson bucket for Msi based failure has been created
Slp: Error: Action “Install_DotNet46_Cpu64_Action” failed during execution.
Slp: Completed Action: Install_DotNet46_Cpu64_Action, returned False

From above, it is clear that setup is failing to install .Net 4.6 on the computer. When I looked into the folder, there was a file for .NET install also.

Framework Error

Action: Performing actions on all Items
Action: Performing Action on Exe at C:\3ba8c9ecb44ae8c55f756e95\SetupUtility.exe
Exe (C:\3ba8c9ecb44ae8c55f756e95\SetupUtility.exe) succeeded.
Action complete
Action: Performing Action on Exe at C:\3ba8c9ecb44ae8c55f756e95\SetupUtility.exe
Exe (C:\3ba8c9ecb44ae8c55f756e95\SetupUtility.exe) succeeded.
Action complete
Action: Performing Action on Exe at C:\3ba8c9ecb44ae8c55f756e95\x64-Windows8.1-KB3045563-x64.cab
Exe (C:\3ba8c9ecb44ae8c55f756e95\x64-Windows8.1-KB3045563-x64.cab) failed with 0x800f0831 – (null).
Exe Log File: CBS.log
Action complete
Action: Performing actions on all Items
Action complete
Action complete
Final Result: Installation failed with error code: (0x800F0831) (Elapsed time: 0 00:01:30).

The hex code is matching with a decimal number which we saw earlier. From the log, it is clear that there is a failure to install KB3045563 and the package is “x64-Windows8.1-KB3045563-x64.cab”. As the message mentioned, I looked into CBS.log and found below

Info CBS Store corruption, manifest missing for package: Package_2_for_KB4095515~31bf3856ad364e35~amd64~~6.3.1.0
Error CBS Failed to resolve package ‘Package_2_for_KB4095515~31bf3856ad364e35~amd64~~6.3.1.0’ [HRESULT = 0x800f0831 – CBS_E_STORE_CORRUPTION] Info CBS Mark store corruption flag because of package: Package_2_for_KB4095515~31bf3856ad364e35~amd64~~6.3.1.0. [HRESULT = 0x800f0831 – CBS_E_STORE_CORRUPTION] Info CBS Failed to resolve package [HRESULT = 0x800f0831 – CBS_E_STORE_CORRUPTION] Info CBS Failed to get next package to re-evaluate [HRESULT = 0x800f0831 – CBS_E_STORE_CORRUPTION]

Above tells some kind of corruption in CBS.

WORKAROUND/SOLUTION

Later I found this article which talks about the same error and the solution also.

To fix the issue, follow these steps:

1. Go to Microsoft Update Catalog.
2. In the Searchbox, enter the package ID of the <Missing_Package>.
3. Download the package and then install it.

After above, we were able to perform the installation of the .NET framework and SQL Server also. Please comment and let me know if you found this useful.

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

First appeared on SQL SERVER – Upgrade Error: Microsoft NET Framework 4.0 Installation Has Failed With Exit Code – 2146498511

The other day, I was hired for the most strange issue I have encountered. One of my previous client of Comprehensive Database Performance Health Check recently reached out with a strange bug where DBCC CHECKDB WITH PHYSICAL_ONLY failed and DBCC CHECKDB Succeeded.

This was indeed news to me. Usually in the most case when whenever DBCC CHECKDB WITH PHYSICAL_ONLY fails it is usually caught in DBCC CHECKDB as well. However, in the interesting situation, my client was getting the error only when he ran DBCC CHECKDB in the latest version of SQL Server 2017. He had absolutely the same setup in SQL Server 2016 but he never got any error.

Strange Bug with ColumnStore Index

This was indeed very strange to me as well as I have never anything in the past. After carefully working on various aspects of the error, I figured out that this was related to the ColumnStore Index. Once we removed the ColumnStore indexes from the table the error would not go away.

Just like any user who has no idea what to do in the situation, I did a quick search on the internet and found a very interesting bug related to SQL Server 2017’s latest version. Here is the link to the bug and its details.

In simple words, if there is a database that contains a table with a clustered ColumnStore index in SQL Server 2017, when you run the statement DBCC CHECKDB WITH ALL_ERRORMSGS, NO_INFOMSGS, PHYSICAL_ONLY in the database, a dump file is generated with an error message.

This is known bug and Microsoft have says they have fixed in the CU 11 but it still exists in the latest version of SQL Server. Till the bug is fixed, I suggest you put your faith on DBCC CHECKDB only and not on any other version of the same statement.

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

First appeared on SQL SERVER – DBCC CHECKDB WITH PHYSICAL_ONLY Failing and DBCC CHECKDB Succeeding – Bug

As they say, there are many ways to bell a cat. But in my consulting career, I have seen the same error due to multiple causes. In this blog, we would talk about one such error which can be seen during the installation of a service pack or cumulative update of SQL Server in a clustered environment. The error which we observed was a failure of a rule – Patch Install Rule Error – Not clustered or the cluster service is up and online.

Here is the image of what we saw on the installation screen.

As I mentioned earlier, I had an earlier blog on the same error which you can read below. SQL SERVER – Patch Rule Failure: Not Clustered or the Cluster Service is Up and Online

The solution given in that blog didn’t help. We looked into Detail.txt which is one of the log file generated by setup. The place where it failed was below:

Slp: Initializing rule : Not clustered or the cluster service is up and online.
Slp: Rule is will be executed : True
Slp: Init rule target object: Microsoft.SqlServer.Configuration.Cluster.Rules.ClusterServiceFacet
Slp: Invalid class
Slp: at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
at Microsoft.SqlServer.Configuration.Cluster.Rules.WMIInterop.Service.ServiceCollection.ServiceEnumerator.MoveNext()
at Microsoft.SqlServer.Configuration.Cluster.Rules.ClusterServiceFacet.Microsoft.SqlServer.Configuration.RulesEngineExtension.IRuleInitialize.Init(String ruleId)
at Microsoft.SqlServer.Configuration.RulesEngineExtension.RulesEngine.Execute(Boolean stopOnFailure)
Slp: Rule initialization failed – hence the rule result is assigned as Failed
Slp: Send result to channel : RulesEngineNotificationChannel

Even the error message is similar, but the stack is different. Here is the simplified version.

Microsoft.SqlServer.Configuration.Cluster.Rules.ClusterServiceFacet
Invalid class
System.Management.ManagementException.ThrowWithExtendedInfo
System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext
Microsoft.SqlServer.Configuration.Cluster.Rules.WMIInterop.Service.ServiceCollection.ServiceEnumerator.MoveNext
Microsoft.SqlServer.Configuration.Cluster.Rules.ClusterServiceFacet.Microsoft.SqlServer.Configuration.RulesEngineExtension.IRuleInitialize.Init
Microsoft.SqlServer.Configuration.RulesEngineExtension.RulesEngine.Execute

When I saw “Invalid Class” this looked like an issue with WMI state on the machine. Here are the steps you can do to confirm the issue. Launch the WMI MMC snap-in by Start -> Run -> type WMIMGMT.MSC -> hit enter. It would open a window. In that right-click “WMI Control (Local)” and click Properties. If you see below then you can fix the issue by following further.

This confirms that Windows WMI is broken, and we need to recompile MOF files. For my client, below worked.

mofcomp C:\Windows\System32\WBEM\cimwin32.mof

If it doesn’t work then you may try compiling all mof files using the below script.

CD C:\Windows\System32\WBEM

dir /b *.mof *.mfl | findstr /v /i uninstall > allmoflist.txt & for /F %s in (allmoflist.txt) do mofcomp %s

Please let me know via comments if it helped you.

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

First appeared on SQL SERVER – Patch Install Rule Error – Not Clustered or the Cluster Service is Up and Online

Most of my time is spent working with my clients on the Comprehensive Database Performance Health Check. The best part of the health check engagement is that I get to meet many new people and share lots of different stories. Recently I was asked by one of the DBAs who also work on MySQL along with SQL Server, what is my preferred engine for MySQL – MyISAM or InnoDB?

I think it is a very interesting question to ask in the year 2019 as I believe MySQL team itself has already made the decision of this one since MySQL version 5.5. They have already selected InnoDB as their default engine since MySQL 5.5.

Here are my primary five reasons for the going with InnoDB

• InnoDB supports row-level locking which is critical for the performance. MyISAM supports only table-level locking creating a huge bottleneck when your table is updated frequently.
• InnoDB implements transactions, which are critical on mission-critical database application which is involved in banking as well as e-commerce.
• InnoDB supports relationship constraint like foreign keys which makes it more relational database friendly over MyISAM which supports none.
• InnoDB supports ACID (Atomicity, Consistency, Isolation, Durability) transactions, making it fully compliant to RDBMS rules which MyISAM does not support it.
• InnoDB manages indexes and base table with the help of storage manager internally with memory buffer pool, which is extremely efficient in terms of performance. MyISAM uses disk files primarily for the base table, which is not optimized for performance.

My suggestion is that if you have to make the selection of the engine either you let your MySQL decide the default engine or select InnoDB which has latest features of RDBMS.

I am currently writing a whitepaper about this topic, once the whitepaper publishes I will share that with all of you so you can read it about it.

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

First appeared on MySQL Preferred Engine – MyISAM or InnoDB