AZURE SQL MI Error: Stale/aborted version cleanup was aborted for database id '10' due to database shutdown.

HemantSudehely-0557 261 Reputation points
2020-06-05T18:47:16.897+00:00

Hi, I am trying to restore SQL server .bak file to Azure SQL Managed Instance database through SSMS but getting an error

Msg 22003, Level 16, State 1, Line 18 Stale/aborted version cleanup was aborted for database id '10' due to database shutdown. Msg 3013, Level 16, State 1, Line 18 RESTORE DATABASE is terminating abnormally.

I am using command
CREATE CREDENTIAL [https://STORAGEACCOUNT.blob.core.windows.net/backups]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE'
, SECRET = '<<by using original key>>'
RESTORE DATABASE [TestDataBase] FROM URL =
'https://STORAGEACCOUNT.blob.core.windows.net/backups/TestDataBase.bak'

I have also tried by using SSMS restore wizard but no luck.

Does anyone face this issue or any help will be great help...

Azure SQL Database
Azure Data Factory
Azure Data Factory
An Azure service for ingesting, preparing, and transforming data at scale.
9,477 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Navtej Singh Saini 4,216 Reputation points Microsoft Employee
    2020-06-05T22:40:48.75+00:00

    Hi @HemantSudehely-0557

    We have checked the internal resources for similar issues that users are facing and found the following:

    The restore of database failed may have failed cause of DBCC CHECKDB that is run as part of the workflow has failed due to version store cleanup errors. As part of DBCC CHECKDB we run version store cleanup and due to some defect version store cleanup has failed. This manifests when DBCC CHECKDB is run in single user mode. We fixed the defect and the fix will be deployed in near future(during this month-June 2020). We apologize for the inconvenience caused by this issue.

    Workaround : Below are the two option to self-mitigate the problem until the fix is deployed:

    1) Take backups with CHECKSUM. This way we will not do DBCC CHECKDB at migration time as we have some confidence that the database is physically consistent. Taking backups with CHECKSUM is generally a good practice to make sure that the consistency of the database is intact.

    2) Retry. The current understanding of the issue is that it is transient and is not specific to any backup. Restore fails about 9% of the time, so we appreciate your patience. The fix is deploying with next deployment.

    You may also refer the below document for reference.

    https://learn.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance-get-started-restore

    Hope this helps.

    Thanks
    Navtej S

    1 person found this answer helpful.
    0 comments No comments