VDI error 1010

guantguant Posts: 14
edited July 22, 2009 6:15AM in SQL Backup Previous Versions
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.

Comments

  • RBARBA Posts: 152 Silver 3
    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,
    Robin Anderson
    Development
    Red-Gate Software
  • 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,
  • RBARBA Posts: 152 Silver 3
    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,
    Robin Anderson
    Development
    Red-Gate Software
  • the sql server has 32gb of memory, and is currently set to use 12gb
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    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.
  • RBARBA Posts: 152 Silver 3
    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,
    Robin Anderson
    Development
    Red-Gate Software
  • 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?
  • howarthcdhowarthcd Posts: 70 Bronze 3
    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
  • 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
  • howarthcdhowarthcd Posts: 70 Bronze 3
    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
  • 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.
  • howarthcdhowarthcd Posts: 70 Bronze 3
    edited July 17, 2009 10:59AM
    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]
  • My question is that even with these memory warnings I'm I at any risk of getting bad backups/restores?
  • howarthcdhowarthcd Posts: 70 Bronze 3
    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
  • interesting, we do not get these memory errors when running sql native backups
  • howarthcdhowarthcd Posts: 70 Bronze 3
    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
  • Started getting VAS errors and errors with other apps using CLR & SP_OACreate only after upgrading to SQL Backup 6 !
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    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.
Sign In or Register to comment.