Comments
4 comments
-
Is this the only set of errors in the vdi.log file when the backup fails? When SQL Backup encounters a situation where SQL Server is unable to allocate the required amount of contiguous memory, it retries the backups with progressively smaller MAXTRANSFER values, automatically.
If you see only one set of errors when the backup fails, then the retries doesn't seem to have kicked in. -
Hi Peter,
Yes, this is the only set of errors for a single invocation of backup.
I just renamed VDI.log and ran it again (thus starting with an empty VDI log) and can confirm that the sample yesterday is all that is produced.
We're running the 8.00.2040 hotfix to address the AWE problem mentioned above. Is it possible that it is returning a different error so that your MAXTRANSFER step down isn't kicking in?
I note from your help that you step down to 65365 which is lower than what we're using for the competing product. Is there a parameter to force a lower maxtransfer? Feel free to reply to my forum registered e-mail.
Cheers
Bernard -
Could you pls post the contents of the SQL Backup log file for the failed backup (usually <system drive>\Documents and Settings\All Users\Application Data\Red Gate\SQL Backup\Log\<instance name>? Thanks.
-
SQL Backup log file 26/04/2006 10:31:23 am: Backing up Usage (full database) to: D:\Program Files\Microsoft Sql Server\MSSQL\BACKUP\FULL_(local)_Usage_20060426_103123.sqb 26/04/2006 10:31:23 am: BACKUP DATABASE [Usage] TO DISK = 'D:\Program Files\Microsoft Sql Server\MSSQL\BACKUP\FULL_(local)_Usage_20060426_103123.sqb' WITH NAME = '<AUTO>', DESCRIPTION = '<AUTO>', COMPRESSION = 1 26/04/2006 10:31:23 am: Thread 0 error: Process terminated unexpectedly. Error code: -2139684860 26/04/2006 10:31:24 am: Server: Msg 3013 BACKUP DATABASE is terminating abnormally. --------------------------------------------------------------------------------
Add comment
Please sign in to leave a comment.
I'm attempting to prove that we can move from a (no longer) competing backup tool to SQL Backup, but I am getting the above errors.
From a few other threads here it looks like the issue might be private mem fragmentation.
However, the strange thing is that when we first looked at SQL Backup, it didn't seem to have a problem with fragged private memory: When we upgraded to SP4 we were one of the people with the AWE Memory Issue that seemed to have, as a side effect increased fragmentation of private memory.
At the time, Red Gate backup successfully backed up the server, when the competing tool couldn't - at least without adding a @maxtransfersize=131072 parameter.
Now, I'm trying to convince the DBA Team Manager to switch backup tools, so I'd like to be able to get some successful backups run.
As usual, this is a production server, so reboots or re-starts of SQL Server are not an option.
Perhaps I have mis-diagnosed the issue we're having, but assuming it is memory related, below is the memstat output for the sqlservr.exe process, relvant vdi.log and output from the backup command.
Memstat Output
Backup Output
VDI Log