Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
DBCC CHECKDB Fails on a Database with files in Azure Blob Storage
Published Mar 15 2019 12:45 PM 638 Views

First published on MSDN on Sep 22, 2016
Starting with SQL Server 2014 you can use SQL Server with Data Files in Microsoft Azure Blob Storage . This feature is very common when you work with SQL Server on Azure VM's, the steps to accomplish this are:

  • Create an Azure VM and then Install SQL Server 2014 or above.
  • Create a Storage Account
  • Create a Container with Private access
  • Create a SAS Key
  • Create a database in SQL Server with database files in the Blob container

Check this Tutorial for more reference.

The result is a Database storing their files in a Blob Container

As database administrator you are worried about database integrity, and for that reason, you scheduled a job or maintenance plan to check for the database integrity.

The first execution of the DBCC CHECKDB command runs without a problem.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'ADWorks2016'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

After a week in the second execution of the DBCC CHECKDB you get the following error:

Msg 1823, Level 16, State 8, Line 32
A database snapshot cannot be created because it failed to start.
Msg 5120, Level 16, State 155, Line 32
Unable to open the physical file "". Operating system error 80: "80(The file exists.)".
Msg 7928, Level 16, State 1, Line 32
The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.

The workaround started by looking into the container:

" DBCC CHECKDB uses an internal database snapshot for the transactional consistency needed to perform these checks." This Snapshot is deleted after the execution of the DBCC but in this case the Snapshot file was not deleted.

The following step, was to look the permissions for the SAS in the container Policy. ( Azure Storage Explorer )

The credential defined in SQL Server to access to the container uses a SAS (Shared Access Signature) and it has a Policy without the Delete permission.
Grant the Delete Permission to the Access Policy associated with the SAS in the container and manually Delete the old Snapshot file.

Now after the execution of the DBCC CHECKDB the Snapshot file is deleted automatically and there is no problem with the next execution.

Version history
Last update:
‎Apr 28 2020 01:26 PM
Updated by: