We have a SQL Server 2014 SP1 cluster on Windows Server 2012 R2, and came across a problem with DBCC jobs failing and issuing the following messages:

Msg 1823, Level 16, State 2, Line 3
A database snapshot cannot be created because it failed to start.
Msg 1823, Level 16, State 8, Line 3
A database snapshot cannot be created because it failed to start.
Msg 5119, Level 16, State 2, Line 3
Cannot make the file “C:\ClusterStorage\Volume1\DATA\test1.mdf_MSSQL_DBCC28” a sparse file. Make sure the file system supports sparse files.
Msg 7928, Level 16, State 1, Line 3
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.

This being Windows Server 2012 R2, there should be no problem with sparse file support, and in any case this cluster had been online months with no issues.

We finally figured out what I'd call a workaround rather than a fix, in that the SQL Data volume – one of two cluster volumes – turned out to be owned by the remote cluster node, with SQL Server running on the primary node. When we changed the ownership of the cluster volume to the primary node the problem immediately went away.

So the big question is why does a cluster volume on a remote node suddenly appear as if it doesn't support sparse files? I cannot find any info on this, and it may be a spurious error as I'm sure this disk has been owned by a separate node before and not caused this error.

Would be great if anybody had input, but if not, at least anybody else having this issue will find out fix in a search through these questions.

  • Did you check the file permissions on the C:\ClusterStorage\Volume1\DATA folder and try to give the remote computer account or the service account on the remote server full permission on that? – Spörri Mar 30 '16 at 13:04
  • C:\ is a cluster drive? Really? If the other node has ownership of the drives, they shouldn't show up on the non-owning node at all. Sounds like you need to validate your cluster. – Max Vernon Mar 30 '16 at 13:09
  • Is C:\ClusterStorage\Volume1 a mount point for your shared storage? If that storage volume is being used by the FCI, it should be part of the same cluster role as the FCI--and thus it should always be on the same cluster node as the instance. If the storage is part of a different WSFC role, it sounds like an issue with the cluster configuration. – AMtwo Mar 30 '16 at 13:19
  • The cluster validates completely. – John Thorpe Mar 30 '16 at 14:50
  • There are no different accounts on different hosts - it's in a domain and domain accounts are used. It's also in the same cluster role, but the data and log volumes are different resources and can failover separately. I don't know why one did and nothing else followed it, and it didn't affect SQL Server functionality except this DBCC issue. – John Thorpe Mar 30 '16 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.