I'm trying to move a large database (22 TB) from a stand alone server to a Storage Spaces Direct (S2D) cluster. The database to be moved is four files, none over 16 TB. The cluster is already hosting many TB of data and is working fine. To minimize downtime, I generally restore a full backup, then restore a Diff backup, then stop providing the service and restore the Trans backups. But I can't even get the process started. When I try to execute the Restore statement, I get the following error message:
Msg 3257, Level 16, State 1, Line 13
There is insufficient free space on disk volume '\\ReindeerAFS3\WSPSQL\' to create the database. The database requires 21812542636032 additional free bytes, while only 17592186040320 bytes are available.
You might note that the number reported as "available" is exactly 16 TB. The Cluster Shared Volume actually has 25 TB free, it was created specifically for this SQL Server data.
I have tried the rumored Trace Flag 3104 which is supposed to bypass checking of free space, but it does not help. The error message remains the same. I believe that Trace Flag was a SQL 2000 item.
The data files target is a Scaleout Fileserver (\\ReindeerAFS3) share (WSPSQL). I have restored small files to this share a few months ago to make sure things were working and things went very smoothly. I can restore this same backup to a stand-alone virtual machine that lives on the cluster, with the VHDX hosted on that same CSV, with no issues. So I'm sure that the free space message is wrong.
Has anyone else tried to Restore a large (over 16 TB) database to a S2D cluster? Is anyone storing large databases on a SOFS share? I'm using SQL Server Standard 2014 SP3 on both the source and destination servers. The cluster is all 2019 Datacenter, fully patched. This is either a bug in SQL Server, a bug in S2D or SOFS, or I'm missing something.
- This topic was modified 1 year, 2 months ago by BobAtDBS.
Student of SQL and Golf, Master of Neither