SQL Backup Error: VDI error 1010

vicjalan

I'm getting this error on my transaction backups. The backups are scheduled to run every hour and each time for the past couple of days they have been failing up to 4 times and succeed on the 5th try.

I've searched online but most of the other fixes suggested have to do with SQL Backup v3. Below is a sample of an error log:

11/9/2007 7:00:11 PM: VDI error 1010: Failed to get configuration from server. Check that the SQL Server instance is running, and that you have the SQL Server Systems Administrator server role. Error code: (-2139684860: An abort request is preventing anything except termination actions.)
11/9/2007 7:00:12 PM: SQL error 3013: BACKUP LOG is terminating abnormally.
11/9/2007 7:00:12 PM:
11/9/2007 7:00:12 PM: Memory profile
11/9/2007 7:00:12 PM: Type Maximum Minimum Average Blk count Total
11/9/2007 7:00:12 PM:

---

---

---

---

---

---

11/9/2007 7:00:12 PM: Commit 83443712 4096 121800 21417 2608594944
11/9/2007 7:00:12 PM: Reserve 4190208 4096 28741 20171 579743744
11/9/2007 7:00:12 PM: Free 851968 4096 119785 274 32821248
11/9/2007 7:00:12 PM: Private 83443712 4096 76789 41012 3149291520
11/9/2007 7:00:12 PM: Mapped 1019904 4096 125451 43 5394432
11/9/2007 7:00:12 PM: Image 5808128 4096 63138 533 33652736
11/9/2007 7:00:12 PM:
11/9/2007 7:00:12 PM: Warning 300: Backup failed. Retry attempt: 4
11/9/2007 7:00:14 PM: BACKUP LOG [ISSIRedRover] TO DISK = '\\issitape\issibu\ISSIRR\ISSIRedRover\ISSIRedRover_LOG_20071109_190001.sqb' WITH NAME = 'Database (ISSIRedRover), 11/9/2007 7:00:01 PM', DESCRIPTION = 'Backup on 11/9/2007 7:00:01 PM Server: VSQLRR01A Database: ISSIRedRover', INIT, ERASEFILES = 1, COMPRESSION = 2, THREADS = 1

11/9/2007 7:01:51 PM: Backup data size : 1,001.813 MB
11/9/2007 7:01:51 PM: Compressed data size: 660.386 MB
11/9/2007 7:01:51 PM: Compression rate : 34.08%

Processed 128072 pages for database 'ISSIRedRover', file 'ISSIRedRover_Log' on file 1.
BACKUP LOG successfully processed 128072 pages in 90.849 seconds (11.548 MB/sec).

---

11/9/2007 7:01:54 PM: Deleting old backup file: \\issitape\issibu\ISSIRR\ISSIRedRover\ISSIRedRover_LOG_20071108_180003.sqb

Jason Cook

Hi,
The reason you are experiencing these warnings is due to the amount of contiguous memory available to the SQL Backup process within SQL Server - in your case 851,968 bytes.

For a one-file backup, SQL Backup requires 6MB of contiguous memory when not using the MAXTRANSFERSIZE keyword. If this is not available, it will try again with half the MAXTRANSFERSIZE value (1MB by default then 512KB, 256KB, 128KB and 64KB) until it either succeeds, or is unable to continue - in your case it succeeded on the fourth retry since you had enough memory available (384KB).

The simplest solution is to restart the SQL Server instance (a soft restart will suffice, no need to restart the machine), which will remove any fragmentation in the SQL Server memory space.

Hope that helps,
Jason

vicjalan

I will keep an eye for this. This server has been giving us memory trouble lately.

Thanks for your reply, it was insightful.

GTSSunGard

We have encountered a very similar problem which generated the following log .... However a service restart is a highly undesirable option. :!:

SQL Backup log file
17/11/2007 07:02:51: Reading filelist of "F:\Credient\Database\Backups\TeleVault Exclude\CRSBackupDevice.sqb"

17/11/2007 07:02:51: RESTORE FILELISTONLY FROM DISK = 'F:\Credient\Database\Backups\TeleVault Exclude\CRSBackupDevice.sqb'

17/11/2007 07:02:51: VDI error 1010: Failed to get configuration from server. Check that the SQL Server instance is running, and that you have the SQL Server Systems Administrator server role. Error code: (-2139684860: An abort request is preventing anything except termination actions.)
17/11/2007 07:02:52: SQL error 3013: RESTORE FILELIST is terminating abnormally.
17/11/2007 07:02:52:
17/11/2007 07:02:52: Memory profile
17/11/2007 07:02:52: Type Maximum Minimum Average Blk count Total
17/11/2007 07:02:52:

---

---

---

---

---

---

17/11/2007 07:02:52: Commit 133099520 4096 59944 25800 1546559488
17/11/2007 07:02:52: Reserve 4911104 4096 22292 24394 543813632
17/11/2007 07:02:52: Free 4841472 4096 169776 336 57044992
17/11/2007 07:02:52: Private 133099520 4096 40447 49476 2001203200
17/11/2007 07:02:52: Mapped 4128768 4096 195261 73 14254080
17/11/2007 07:02:52: Image 9916416 4096 116148 645 74915840
17/11/2007 07:02:52:

The process attempted 4 times before terminating, due to severe time constrains and the need to generate some kind of backup we reverted to SQL native backup which succeed first time. During the 4 reties and the subsequent manual attempt Redgate consistantly reached the same point in the backup - about 43 GB before terminating, leaving a junk backup file.

The 2 server cluster was then reboot 12 hours later once over night processing was completed. Test backup's then demonstrated that the issue had been resolved.

This problem has occured spuradically on a number of our production enviroment and causes real problems.

Can you advise anyway to improve the way we manage the backup with Red Gate (SQL Backup) to ensure 100% reliablity ? Alternatively a none distructive recovery process - I.E. not restarting any thing. :?:

Many thanks,

Geoff

Jason Cook

Hi,
As with the original poster, your issue is due to fragmentation in the SQL Server memory space used for extended stored procedures.

In your case, the maximum block of free contiguous memory is 4.8mb; which is less than the "default" minimum of 6mb for one thread.

SQL Backup will try with smaller values of MAXTRANSFERSIZE to use less memory, but in your case it's failing after the 4th attempt; which suggests you're using a high number of split files or threads.

You've got a few options:
* When you encounter the problem of retries, the quickest "fix" is to restart the SQL Server instance. However as a temporary solution you can reduce the number of threads used (or the MAXTRANSFERSIZE value if you're not hitting 4 retries, even though you are at this stage)
* If you are using a very high number of threads (e.g. 16 or more), it may make sense to reduce this to a lower value - this will reduce the memory requirements.
* If you wish to increase the amount of memory SQL Server allocates to extended stored procedures (which is how SQL Backup and the SQL Server VDI interact), the following article from one of our technical support team may be of interest:
http://www.simple-talk.com/community/bl ... 37747.aspx

Hope that helps,
Jason

vicjalan

I've read where even the MAXTRANSFERSIZE parameter sometimes fail. What I've done was add the MAXDATABLOCK parameter and I've not had a failed backup since. I've also seen both the MAXTRANSFERSIZE and MAXDATABLOCK parameters used as well.

Hope this helps..