Backup Fails with Backup Exit Code 790 & SQL Error Code 3013
Bernard Sheppard
Posts: 53
Hi,
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
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
C:\temp>MEMSTAT 2392 memstat - Yohz Software (c) 2005 - 2006 Type Minimum Maximum Average Blk count Total ---------------- ----------- ----------- ----------- ----------- ----------- Commit 4096 64471040 114264 11349 1296789504 Reserve 4096 4128768 63787 9978 636469248 Free 4096 8192000 506286 423 214159360 Private 4096 64471040 91726 20514 1881669632 Mapped 4096 1019904 105434 54 5693440 Image 4096 7569408 60468 759 45895680 C:\temp>
Backup Output
SQL Backup (DLL v4.1.0.207) Backing up Usage (full database) to: D:\Program Files\Microsoft Sql Server\MSSQL\BACKUP\FULL_(local)_Usage_20060426_103123.sqb Thread 0 error: Process terminated unexpectedly. Error code: -2139684860 Server: Msg 3013 BACKUP DATABASE is terminating abnormally. -------------------------------------------------------------------------------- SQL Backup exit code: 790 SQL error code: 3013 (13 row(s) affected) name,value exitcode,790 sqlerrorcode,3013 filename01,D:\Program Files\Microsoft Sql Server\MSSQL\BACKUP\FULL_(local)_Usage_20060426_103123.sqb (3 row(s) affected) Server: Msg 50000, Level 16, State 1, Line 6 SQL Backup job failed with exitcode: 790 SQL error code: 3013
VDI Log
---------------------------------------------- 2006/04/26 10:31:23 pid(2392) tid(5024) Error on Global\SQLBACKUP_2FD90D0F-F559-47F8-817A-0DCF987242E0 Error at ServerBufferAreaManager::Allocate: Map buffers Status Code: 8, x8 Explanation: Not enough storage is available to process this command. ---------------------------------------------- 2006/04/26 10:31:23 pid(2392) tid(5024) Error on Global\SQLBACKUP_2FD90D0F-F559-47F8-817A-0DCF987242E0 Error at TriggerAbort: invoked ---------------------------------------------- 2006/04/26 10:31:23 pid(40168) tid(43920) Error on Global\SQLBACKUP_2FD90D0F-F559-47F8-817A-0DCF987242E0 Error at CVD::GetCommand: AbortDetected ---------------------------------------------- 2006/04/26 10:31:23 pid(2392) tid(4240) Error on Global\SQLBACKUP_2FD90D0F-F559-47F8-817A-0DCF987242E0 Error at TriggerAbort: invoked ---------------------------------------------- 2006/04/26 10:31:23 pid(2392) tid(4240) Error on Global\SQLBACKUP_2FD90D0F-F559-47F8-817A-0DCF987242E0 Error at SVDS::CloseDevice: Abort detected ---------------------------------------------- 2006/04/26 10:31:23 pid(40168) tid(43920) Error on Global\SQLBACKUP_2FD90D0F-F559-47F8-817A-0DCF987242E0 Error at TriggerAbort: invoked ---------------------------------------------- 2006/04/26 10:31:23 pid(2392) tid(4240) Error on Global\SQLBACKUP_2FD90D0F-F559-47F8-817A-0DCF987242E0 Error at TriggerAbort: invoked ---------------------------------------------- 2006/04/26 10:31:23 pid(2392) tid(5024) Error on Global\SQLBACKUP_2FD90D0F-F559-47F8-817A-0DCF987242E0 Error at TriggerAbort: invoked ---------------------------------------------- 2006/04/26 10:31:24 pid(40168) tid(44160) Error on Global\SQLBACKUP_2FD90D0F-F559-47F8-817A-0DCF987242E0 Error at TriggerAbort: invoked
Comments
If you see only one set of errors when the backup fails, then the retries doesn't seem to have kicked in.
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8
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
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8