Be Careful Using LiteSpeed Extended Stored Procedures With SQL Agent

Quest LiteSpeed is one of the options to create compressed backups with SQL Server 2005. It’s uncommon that a SQL Server DBA needs to create a customized backup and restore routine for an application using combination of LiteSpeed extended stored procedures. For example, in a quarterly basis, you may want to take file group backup of the primary file group and some secondary file groups which contain more recent data. After taking the backup, you may want to perform a restore test against the resulting backup file. In this case, a SQL Agent job scheduled quarterly with two steps – one to call xp_backup_database to create the backup, another to invoke xp_restore_database to perform a restore and then a simple data query - would be an obvious option. However, you should be really careful when you are implementing such a solution.

Issue

To better describe the issue, let’s first reproduce it on a machine with SQL Server 2008 R2 and LiteSpeed 6.0 installed, with the following steps.

Msg 50002, Level 16, State 1, Line 0
The system cannot find the file specified.

LiteSpeed for SQL Server could not open backup file: (D:\MSSQL.1\MSSQL\Backup\any invalid filename).
The previous system message is the reason for the failure.

I am good.

The comparison of the different outcomes tells us two things regarding to SQL Agent job:

The try catch block has failed to catch the exception thrown by the LiteSpeed extended stored procedure.

The exception actually stops SQL Agent job from executing further, while in SSMS or sqlcmd it’s not the case.

Whilst you may evaluate whether the operation is successfully by checking the returning value of the stored procedure (zero stands for success and non-zero stands for failure), you can do nothing to recover the failure or even to record it because the job terminates immediately upon the exception. This is terrible when you need to program some conditional logic or some logging in the backup and restore routine.

Workaround

As you may have guessed, the workaround to the issue is as simple as using sqlcmd instead of T-SQL in the SQL Agent job step. Since sqlcmd would not throw any exception to SQL Agent job, the job will be running successful anyway unless there is a connection issue or other system level issues. In this way you will have full control of the code no matter the LiteSpeed extended stored procedures throws exception or not. You will also be very flexible to either put in exception handling code according to the error code returned by the stored procedures, or just log it somewhere.

Further Discussion

It’s still unclear that why SQL Agent job behaves in such way. I have also examined if there is any T-SQL SET statement could suppress the LiteSpeed exception but in vain. Any comments are welcome.

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands
of articles and SQL scripts, a library of free eBooks, a weekly database news roundup,
a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals
that makes it such a success.