Process Terminated Unexpectedly
SQL Backup 18.104.22.168, (c) Red Gate Software Ltd 2004 - 2005
Serial number: 010-015-027314-030A
Backing up DatabaseName (transaction log) to \\BackupServer\SQLBACKUP\ServerName\DatabaseName_tlog_20060116180634.sqb ...
Thread 0 error:
Process terminated unexpectedly. Error code: -2139684860
Msg 3013, Level 16, State 1, Server ServerName, Line 1
BACKUP LOG is terminating abnormally.
Here is the backup command that generated the above error. As you can see, we backup to a network drive. Backing up to a local drive also gets the same error.
-SQL "BACKUP Log DatabaseName
TO DISK = [\\BackupServer\SQLBACKUP\ServerName\DatabaseName_tlog_20060116180634.sqb]
WITH NAME = [ServerName.DatabaseName tlog Backup 2006-01-16 18:06:34],
DESCRIPTION = [ServerName.DatabaseName tlog Backup on 2006-01-16 18:06:34],
PASSWORD = [password], COMPRESSION = 1"
I thought we had overcome this problem by installing version 22.214.171.124. However, the error now seems to occur more frequently on this particular server.
Usually, the backups will work for a few days if we restart the SQL Service. However, we restarted the service on this server today and T-Log backups started failing about 6 hours later. Restarting the service regularly is not a good option in our environment.
We have tried starting SQL Server with the â€“g option to increase the virtual address space. This did not fix the problem. This setting seemed to cause other problems on the server last week and we have returned to the default value.
The server is a Dell PE6850 with four hyper-threaded Xeon processors and four gigabytes of memory. The OS is Windows Server 2003. SQL Server version is 2000 Standard Edition with SP4 installed. As noted above, Red Gate SQLBackup version is 126.96.36.199. There is plenty of disk space available â€“ 260GB on the backup drive.
SQL Backup on another server was failing earlier today but now runs successfully. These two servers are the most heavily used SQL servers. SQL Backup is installed on ten other servers. Three of them have experienced the same error. Seven have been running SQLBackup for weeks without failure. The servers that have not had failures donâ€™t handle as much data or as many users as the servers that experience the failures.
Weâ€™d like some help resolving the problem before management tells us to use native backup. The compression and encryption features are too valuable for us to lightly discard them. By the way, we have tried backups without encryption and compression. SQL Backup still fails.
Thanks in advance for your assistance.
L-3 Communications, Inc.