CAUSE:
This error indicates that SQL Server has run out of storage in its “MemToLeave” memory area. This memory area is set aside for all extended stored procedures, COM/OLE Automation objects and linked servers. The memory size is static and is set at the startup of SQL Server. Memory allocations by SQL Server larger than 8 KB are also made from the MemToLeave area.

When performing a backup in SQL Server, SQLsafe makes a call to create virtual device buffers. In SQL Server 2000, all of the buffers must be able to fit into one contiguous chunk of memory. If the MemToLeave area is heavily fragmented, SQL Server generates a “not enough storage” error due to a lack of contiguous memory. The probability of this issue occurring is greatly reduced in SQL Server 2005, which requires only that each individual buffer be in a contiguous chunk of memory.

RESOLUTION:
A. Reduce the size of the buffers. This can have a negative performance impact, but will resolve this issue. This will only affect backup operations. For restore operations, the buffer size is set by the backup archive file being restored.

B. If you are using a large number of threads during a backup, this increases the number of memory buffers required during a backup. You should reduce the number of threads being used by the backup operation. This can have a negative performance impact, but will resolve this issue.

Please implement A, then B in order. Perform a backup test between each resolution to determine if an individual workaround has resolved the behavior.

STEPS REQUIRED TO PERFORM EACH RESOLUTION:

A. To reduce the size of the buffers SQLsafe requests:

1. Stop the SQLsafe Backup Agent service on the computer where backup are failing with the “not enough storage” error.
2. On the same computer, click “Start” and then “Run”.
   Type “regedit” and click “OK”.

   NOTE: In order to avoid potential operating system issues, always backup your registry before making any changes.

3. Edit the “HKLM\Software\Idera\SQLsafe\Backup Agent\VDIMaxTransferSize” DWORD value. "VDIMaxTransferSize" is the maximum input/output size issued to the Virtual Device Interface for data transfer. Enter a new value between 65536 (decimal) and 1048576 (decimal). Please note that the value MUST be a multiple of 1024. The default value is 100000 (hex). As a starting point, we suggest half of that – 80000 (hex). This value may have to be lowered further, depending on the memory remaining and memory fragmentation in SQL Server’s MemToLeave memory area. The optimal setting for this entry will depend on your environment.
4. Restart the SQLsafe Backup service.

B. To reduce the number of threads used by the backup service:

By default, SQLsafe uses 3 threads to perform a backup, but this number can be specified in the user preferences. If the number of threads specified is raised, you should consider reducing it. This will result in a lower memory requirement during backup operations. To reduce the number of threads used during a backup operation:

• If your backup is being performed via the command line, please add the "-threads 1" (no quotes) parameter to the command.
• If your backup is being performed via T-SQL, please add the "@threads = 1" parameter to the backup command.

NOTES:

• It is also possible to increase the size of the MemToLeave memory area in SQL Server directly. This requires a restart of the SQL Server, as it is a startup parameter.
• Under some circumstances this error can be delivered by the operating system and can indicate a problem with the physical disk to which SQLsafe is attempting to write an archive file. This has been reported to occur on both a local RAID array and a SAN in conjunction with hardware issues or failures.

Permission Requirements:
To successfully install the SQLsafe XSPs, you must be able to log onto the target SQL Server instance through Query Analyzer. Your logon account must be a member of the "sysadmin" role to successfully connect to the SQL Server instance and install the SQLsafe XSPs.

If there is a previous install of the SQLsafe XSPs on this SQL Server instance, you must uninstall the stored procedures and unload the DLL from SQL Server memory.

To uninstall the previously installed SQLsafe XSPs:

1. Start Query Analyzer and connect to the target SQL Server instance.
2. Unload the DLL from memory using the following T-SQL script:
   USE [master]
   DBCC SQLSafe_ExtendedStoredProc (free)
   GO
   If this step fails, stop and restart the SQL Server service, and then execute the script again.
3. Drop the extended stored procedure(s) using the following T-SQL script:
   EXEC sp_dropextendedproc 'xp_ss_backup'
   EXEC sp_dropextendedproc 'xp_ss_restore'
   EXEC sp_dropextendedproc 'xp_ss_verify'
   EXEC sp_dropextendedproc 'xp_ss_list'
   GO
4. Delete the SQLsafe_ExtendedStoredProc.dll from the "\binn" folder on each SQL server instance.

To install the SQLsafe XSPs:

1. Copy the SQLsafe_ExtendedStoredProc.dll from the SQLsafe install location (default is "C:\Program Files\Idera\SQLsafe") to the following locations:
   <SQLserver instance install path>\MSSQL$<SQLServerInstanceName>\Binn folder on each named instance
   <SQLserver default install path>\MSSQL\Binn folder on the default instance

   By default, the SQL Server install path is C:\Program Files\Microsoft SQL Server.

2. Run the following script to register the SQLsafe XSPs with SQL Server:
   USE [master]
   GO
   EXEC sp_addextendedproc 'xp_ss_backup', 'SQLSafe_ExtendedStoredProc.dll'
   EXEC sp_addextendedproc 'xp_ss_restore', 'SQLSafe_ExtendedStoredProc.dll'
   EXEC sp_addextendedproc 'xp_ss_verify', 'SQLSafe_ExtendedStoredProc.dll'
   EXEC sp_addextendedproc 'xp_ss_list', 'SQLSafe_ExtendedStoredProc.dll'
3. Use the following script to grant a user the ability to backup and restore data using these extended stored procedures. Any user will need to use the stored procedures for backups and restores must have execute permissions on these XSPs. When you execute this script, replace [mydomain\jsmith] with the domain and logon name of the appropriate user account.
   GRANT EXEC ON [master].[dbo].[xp_ss_backup] TO [mydomain\jsmith]
   GRANT EXEC ON [master].[dbo].[xp_ss_restore] TO [mydomain\jsmith]
   GRANT EXEC ON [master].[dbo].[xp_ss_verify] TO [mydomain\jsmith]
   GRANT EXEC ON [master].[dbo].[xp_ss_list] TO [mydomain\jsmith]

   NOTE: The SQLsafe XSPs run using the account under which SQL Server runs. This means that the SQLsafe XSPs can access only the network resources that the SQL Server can access. However, if your backup script writes backup files to network shares, you can pass the appropriate credentials to the SQLsafe XSPs using the @windowsusername and @windowspassword XSP parameters.