Microsoft distributes Microsoft SQL Server 2012 fixes as one downloadable file. Because the fixes are cumulative, each new release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2012 fix release.
Symptoms
Scenario 1
Consider the following scenario:
-
You restore a database in Microsoft SQL Server 2012.
-
Before the database restore operation is finished, another process references the sys.database_recovery_status catalog view and requires a lock on the same database. For example, you execute the following SELECT statement:
SELECT * FROM sys.database_recovery_status
In this scenario, slow performance occurs in which a process for the SELECT statement waits until the database restore process is finished.
Scenario 2
Consider the following scenario:
-
You restore a database in SQL Server 2012.
-
Before the database restore operation is finished, you execute the following statement:
IF EXISTS (SELECT * FROM sys.database_recovery_status WHERE database_id= DataBaseID AND database_guid IS NOT NULL)
Note The DataBaseID represents the ID of the database on which you perform the database restore operation.
In this scenario, a deadlock occurs in the database restore process. This deadlock causes the database restore process to fail.
Cause
The two scenarios that are described in the "Symptoms" section are caused by the same causes.
In the "Scenario1" section, the issue occurs because the database restore process requires an exclusive lock on the database. When you execute the statement that is mentioned in that section, a shared lock is required on the same database. Therefore, the shared lock waits for the exclusive lock until the exclusive lock is released.
In the "Scenario 2" section, when you execute the statement that is mentioned in that section, a shared lock is required both on the same database and on the sys.sysdbreg table. At the last phase of the database restore process, the process requires an update lock on the sys.sysdbreg table. However, the shared lock is not released from the database. Therefore, a deadlock occurs on the sys.sysdbreg table, and the database restore process is determined to be the deadlock victim.
Resolution
Cumulative update information
Cumulative update package 1 for SQL Server 2012 Service Pack 1
The fix for this issue was first released in Cumulative Update 1. For more information about how to obtain this cumulative update package for SQL Server 2012 Service Pack 1, click the following article number to view the article in the Microsoft Knowledge Base:
2765331 Cumulative update package 1 for SQL Server 2012 Service Pack 1Note Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2012 fix release. We recommend that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
2772858 The SQL Server 2012 builds that were released after SQL Server 2012 Service Pack 1 was released
Cumulative update package 3 for SQL Server 2012
The fix for this issue was first released in Cumulative Update 3. For more information about how to obtain this cumulative update package for SQL Server 2012, click the following article number to view the article in the Microsoft Knowledge Base:
2723749 Cumulative update 3 for SQL Server 2012Note Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2012 fix release. We recommend that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
2692828 The SQL Server 2012 builds that were released after SQL Server 2012 was released
Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
Workaround
To work around the issue in Scenario 2, use one of the following methods.
Method 1
Modify the statement to avoid the shared lock on the sys.sysdbreg table by using the "NOLOCK" hint.
IF EXISTS (SELECT * FROM sys.database_recovery_status with(NOLOCK) WHERE database_id= DataBaseID AND database_guid IS NOT NULL)
Method 2Set the deadlock priority of the statement to "LOW."
SET DEADLOCK_PRIORITY LOW
IF EXISTS(SELECT * FROM sys.database_recovery_status where database_id = DataBaseID AND database_guid IS NOT NULL)
Note When you use the second method to avoid the deadlock both in the statement and in the database restore process, the codes in the IF statement will not be executed.
References
For more information about exclusive lock, shared lock, and update lock, go to the following MSDN website:
General information about the lock modesFor more information the Incremental Servicing Model for SQL Server, click the following article number to view the article in the Microsoft Knowledge Base:
935897 An Incremental Servicing Model is available from the SQL Server team to deliver hotfixes for reported problems For more information about the naming schema for SQL Server updates, click the following article number to view the article in the Microsoft Knowledge Base:
822499 Naming schema for Microsoft SQL Server software update packages For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:
824684 Description of the standard terminology that is used to describe Microsoft software updates
