THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

The Rambling DBA: Jonathan Kehayias

The random ramblings and rantings of frazzled SQL Server DBA

Understanding Third Party Backups and SQLVDI

If you use a external or third party backup tool like NetBackup, BackupExec, or one of the many other tools available for backing up SQL Server databases without having to write your own backup scripts, you have no doubt encountered problems along the way with VDI Errors in your Error Log similar to the following:

BackupVirtualDeviceFile::RequestDurableMedia: Flush failure on backup device 'RVX-{58702BA0-C160-4125-952E-CC21954404B7}'.
Operating system error 995(The I/O operation has been aborted because of either a thread exit or an application request.)

A lot of people get confused by these errors and post questions on the forums and generally the problem isn't a SQL Server problem.  Recently the SQL Tips and Tricks blog posted two blog posts that dig into SQLVDI and how it works:

and one for how to troubleshoot problems with SQLVDI backups:

If you've ever wondered how this works or what the messages you see regarding backups to Virtual Devices mean in your Error Logs, these posts are a great primer on the subject.

Published Tuesday, June 09, 2009 12:35 AM by Jonathan Kehayias



Wes Brown said:

Just a few notes on the subject.

All the third party tools I know of (LiteSpeed, SQL Backup, SQL Safe) use VDI, all of them are subject to the mighty 995.

There is a newer one on the market HyperBac that is implemented as a driver and bypasses the VDI.

If you are on a 32 bit system it is almost always fragmentation of the Mem To Leave(MTL) Virtual Address Space(VAS). VDI will request a buffer space to be created and if it can't get a contiguous memory block you get the magic 995. Almost all third party tools will retry with smaller block sizes these days but that doesn't mean the backup will succeed.

Ultimately the fix is a restart of SQL Server and setting the -g option to something larger like 384 on SQL 2000 or 512 on 2005. Keep in mind though if there isn't enough memory in the lower 2GB you can set -g to whatever you want, it attempts to allocate the memory but if it can't it will just fall back until it can and ignore your -g override.

Also, if you are using the CLR in 2005/2008 on a 32 bit box you will hit this more often due to the CLR running in the same space.

You will get an error with the CLR telling you to enable AWE, which won't fix the problem, and restart the instance, which will for a while.

On 64 bit the MTL VAS space isn't constrained to the lower 2GB and can allocate as much memory as you have available.

Keep in mind 64 bit isn't the fix all for this, if you have to little memory in your server and it is under pressure you may still see VDI failures.

Christan Bolton has a nice little post on checking MTL on 2000 and 2005 to see if fragmentation is your problem.

Former member of the VDI club.



June 9, 2009 12:39 AM
Anonymous comments are disabled

This Blog


Privacy Statement