VDI error 1010

guant · July 15, 2009 12:22PM

I keep getting this error when running backups, the job finishes and appears to have backed up, anyone know what I need to do to get rid of this warning?? Thank you!

VDI error 1010: Failed to get the configuration from the server because the timeout interval has elapsed. SQL Backup required 6,291,456 bytes of free SQL Server memory, which was not available. VDI error: An abort request is preventing anything except
termination actions.

RBA · July 15, 2009 2:48PM

Hi guant,

This may be related to the amount of RAM available to SQL Server.

This is restricted by a) the amount free on your system and b) the maximum amount that SQL Server is configured to use.
If your system is overloaded or SQL Server has been limited to use an amount less than it needs, you could see an error like 1010.

You can check in Task Manager and SQL Server Management Studio (instance properties... memory) to see if this could be the case.

Choosing to use fewer threads when performing a backup can help reduce memory usage.

Hope this helps,

guant · July 15, 2009 4:15PM

Would this be the memory on the database server itself? I have a separate machine with sqlbackup installed that is performing the backups, would this be the machine that would need the extra memory? Our database server has 36gb of memory and the machine running sqlbackup has 8gb.

Thanks,

RBA · July 16, 2009 5:31AM

Hi guant,

This would be the system memory on the database server itself.

The actual backup work is performed by the SQL Backup Agent, which is a windows service running on the same computer as the SQL Server instance.

On the database server, how much free memory is available? Also, in Management Studio, how much memory has SQL Server been authorised to use?

Thanks,

guant · July 16, 2009 8:57AM

the sql server has 32gb of memory, and is currently set to use 12gb

Brian Donahue · July 16, 2009 9:26AM

We have written a very comprehensive guide to configuring SQL Server stored procedure memory and put it here:

http://www.red-gate.com/supportcenter/C ... 000142.htm

IMHO, SQL Server 2000 does a pretty bad job of managing this memory and it tends to get fragmented very fast, so having a look at any stored procedures that use OLE automation (sp_oacreate) to make sure that all OLE objects created are destroyed may also be the answer. Memory management is much improved in SQL 2005 and up, but occasionally runs out of memory for this and other reasons.

RBA · July 16, 2009 9:38AM

Hi,

I wonder if the sqlservr.exe process is approaching its maximum allocation. The next time you observe this error, please check the amount of memory allocated to this process. If this number is close to 12GB limit, then the error generated by SQL Backup is valid.

If you're getting this error inappropriately, then I'd like to know more about your setup so I can work on the issue.

Regards,

guant · July 16, 2009 9:39AM

When we get this warning, it still will backup successfully and we are able to restore the database, is there any risk of just ignoring this warning?

howarthcd · July 16, 2009 9:49AM

Could you execute the following against the problematic instance of SQL Server and post the results back to the forum?

EXEC master.dbo.sqbmemory

Thanks
Chris

guant · July 16, 2009 9:51AM

Commit 4096 266199040 48229 23206 1119211520
Reserve 4096 15728640 147827 21325 3152416768
Free 4096 786432 88157 264 23273472
Private 4096 266199040 95899 43833 4203556864
Mapped 4096 1585152 151025 70 10571776
Image 4096 7581696 91559 628 57499648

howarthcd · July 16, 2009 10:19AM

It looks like the VAS region is heavily fragmented as the maximum 'free' block size is ~768KB. A freshly-restarted 32-bit instance should show a maximum 'free' block size of somewhere in the region of 100MB.

The immediate fix is to restart the instance of SQL Server, the long term fix is to try to work out why the VAS is becoming fragmented.

A few causes of VAS fragmentation and/or pressure are:

1. Using sp_xml_preparedocument without a corresponding sp_xml_removedocument.
2. Use of CLR objects (if you're not using CLR objects then ensure that the CLR sp_configure option is turned off and restart the instance if you change the option).
3. Use of the sp_OA... stored procedures on a SQL Server 2005 SP2 installation - upgrading to SP3 should fix the problem.
4. Use of linked servers.

Upgrading to 64-bit OS and SQL Server should remove the problem, although it's always advisable to first attempt to fix the root cause where possible.

Thanks
Chris

guant · July 16, 2009 10:23AM

Thank you for the information, we are running sql 2000 enterprise, if we arent ready to upgrade to sql 2005/2008 at this point. We will have a probably with these memory warnings? Will it affect our backups/restores? Even know they say they completed with warnings. This is the log from a backup:

PHIF04V\IFORCE01: Backup - Successful
=====================================

Performing full backups - Successful

This operation completed with warnings.

Backing up CDB_Model (full database) on IFORCE01 instance to:
\\phif14\daily full\CDB_Model\20090716\FULL_CDB_Model_20090716_1036.sqb
VDI error 1010: Failed to get the configuration from the server because the timeout interval has elapsed. SQL Backup required 12,582,912 bytes of free SQL Server memory, which was not available. You can reduce the memory requirements by reducing the
number of threads used in the backup. VDI error: An abort request is preventing anything except termination actions.
SQL error 3013: BACKUP DATABASE is terminating abnormally.
Memory profile
Type Maximum Minimum Average Blk count Total

Commit 266199040 4096 48739 23031 1122521088
Reserve 15728640 4096 148616 21175 3146956800
Free 1478656 4096 97409 261 25423872
Private 266199040 4096 96590 43512 4202856448
Mapped 1585152 4096 138208 66 9121792
Image 7581696 4096 91559 628 57499648
Warning 300: Backup failed. Retry attempt: 1
VDI error 1010: Failed to get the configuration from the server because the timeout interval has elapsed. SQL Backup required 6,291,456 bytes of free SQL Server memory, which was not available. You can reduce the memory requirements by reducing the
number of threads used in the backup. VDI error: An abort request is preventing anything except termination actions.
SQL error 3013: BACKUP DATABASE is terminating abnormally.
Memory profile
Type Maximum Minimum Average Blk count Total

Commit 266199040 4096 49090 23044 1131245568
Reserve 15728640 4096 148172 21185 3139031040
Free 1478656 4096 95446 258 24625152
Private 266199040 4096 96558 43535 4203655168
Mapped 1585152 4096 138208 66 9121792
Image 7581696 4096 91559 628 57499648
Warning 300: Backup failed. Retry attempt: 2
VDI error 1010: Failed to get the configuration from the server because the timeout interval has elapsed. SQL Backup required 3,145,728 bytes of free SQL Server memory, which was not available. You can reduce the memory requirements by reducing the
number of threads used in the backup. VDI error: An abort request is preventing anything except termination actions.
SQL error 3013: BACKUP DATABASE is terminating abnormally.
Memory profile
Type Maximum Minimum Average Blk count Total

Commit 266199040 4096 49451 23155 1145053184
Reserve 15728640 4096 146751 21296 3125223424
Free 1478656 4096 95446 258 24625152
Private 266199040 4096 96068 43757 4203655168
Mapped 1585152 4096 138208 66 9121792
Image 7581696 4096 91559 628 57499648
Warning 300: Backup failed. Retry attempt: 3
VDI error 1010: Failed to get the configuration from the server because the timeout interval has elapsed. SQL Backup required 1,572,864 bytes of free SQL Server memory, which was not available. You can reduce the memory requirements by reducing the
number of threads used in the backup. VDI error: An abort request is preventing anything except termination actions.
SQL error 3013: BACKUP DATABASE is terminating abnormally.
Memory profile
Type Maximum Minimum Average Blk count Total

Commit 266199040 4096 49498 23193 1148026880
Reserve 15728640 4096 146363 21333 3122380800
Free 1478656 4096 94938 258 24494080
Private 266199040 4096 95905 43831 4203655168
Mapped 1585152 4096 138102 67 9252864
Image 7581696 4096 91559 628 57499648
Warning 300: Backup failed. Retry attempt: 4
Database size : 334.500 MB
Compressed data size: 40.356 MB
Compression rate : 87.94%
Processed 18736 pages for database 'CDB_Model', file 'CDB_Model_Data' on file 1.
Processed 1 pages for database 'CDB_Model', file 'CDB_Model_Log' on file 1.
BACKUP DATABASE successfully processed 18737 pages in 3.502 seconds (43.828 MB/sec).
Verifying files:
\\phif14\daily full\CDB_Model\20090716\FULL_CDB_Model_20090716_1036.sqb
The backup set is valid.
SQL Backup exit code: 300

Updating SQL Server information - Successful

This operation completed successfully.

howarthcd · July 16, 2009 10:39AM

To be on the safe side I would schedule some downtime for a quick restart of SQL Server (no need to restart the server). You might want to execute the sqbmemory extended procedure immediately after the restart so that you have figures for comparison at a later date.

It's good practice to regularly perform test restores of backups - if you were to do this then you'd quickly know whether or not the backup files were valid.

Chris

EDIT: Looking at your logs you can see that SQL Backup gradually reduces its memory requirements until the backup runs successfully:

1st attempt: 12,582,912 bytes
2nd attempt: 6,291,456 bytes
3rd attempt: 3,145,728 bytes
4th attempt: 1,572,864 bytes
5th (successful) attempt: presumably 786,432 bytes

I believe that SQL Backup gradually reduces the value of MAXTRANSFERSIZE http://www.red-gate.com/supportcenter/C ... wledgebase\SQL_Backup\KB200708000121.htm

Definitely restart the instance before the backups fail altogether due to a lack of appropriately-sized contiguous VAS, ideally you need at least 12582912 bytes (12MB) to be returned for the 'Maximum Free' value discussed earlier.[/url]

guant · July 16, 2009 12:07PM

My question is that even with these memory warnings I'm I at any risk of getting bad backups/restores?

howarthcd · July 16, 2009 12:10PM

In my experience, in similar situations, you're unlikely to be at risk of "bad" backups, assuming that by bad backups you mean that the backup file is corrupt, it is far more likely that you'll get to the point where the backups will fail to run at all.

As I mentioned earlier, you need to restart SQL Server then closely monitor the output of sqbmemory to help you determine when the error is next likely to occur and to help you determine exactly what is causing the fragmentation.

Note that this issue is not really a problem with SQL Backup as the same can occur with native backups.

Chris

guant · July 16, 2009 12:57PM

interesting, we do not get these memory errors when running sql native backups

howarthcd · July 17, 2009 1:39AM

That could be because ~700KB of contiguous free VAS is adequate to support native backups. As I mentioned, you can run into the same problem with T-SQL backups, and you may do so in time should the VAS region become even more fragmented.

http://www.red-gate.com/supportcenter/C ... 000121.htm

Chris

rakshitpatel · July 21, 2009 2:59PM

Started getting VAS errors and errors with other apps using CLR & SP_OACreate only after upgrading to SQL Backup 6 !

Brian Donahue · July 22, 2009 6:15AM

Hello Rakshit,

There should not be any difference at all between the way SQL Backup 6 allocates buffer space as compared to v5. The only thing I can suggest is that maybe you had recreated your backup scripts and changed the MAXTRANSFERSIZE values, because these would affect the memory usage.

VDI error 1010

Comments

Product Learning

Community Forums

Events & Friends

Simple Talk