Recently, my company has upgraded to 2016 and enabled TDE on all of our databases. Additionally, we have the production databases replicated on high availability servers.
Our backups are taken from the HA server and use the maxtransfersize
hack in order to compress the backups.
All of the backups are successful, save one, where the following error is spit out by our monitoring software:
Error: 3624, Severity: 20, State: 1.
A system assertion check has failed. Check the SQL Server error log for details. Typically, an assertion failure is caused by a software bug or data corruption. To check for database corruption, consider running DBCC CHECKDB. If you agreed to send dumps to Microsoft during setup, a mini dump will be sent to Microsoft. An update might be available from Microsoft in the latest Service Pack or in a Hotfix from Technical Support.
In the server log there are a few more details at the point of failure:
input buffer 70 bytes
ProcessID: 1884
SPID:200
Expression: m_inputQueue.head()==null
location: backuplog.cpp 1564
This is my backup command:
backup database @DBName to disk = @Path
with noformat, noinit, name=@Name, skip, norewind, nounload,
compression, stats=10, copy_only, MAXTRANSFERSIZE = 65537
Has anyone run into a similar problem before?
I've used a few different values for maxtransfersize
, albeit in a kinda random manner, picking from a chart in TDE and Backup Compression: Together At Last by Erik Darling.
Not using TDE is not an option because it contains sensitive data. Not being compressed may be an option if we have the drive space.