November 17, 2009 at 8:23 am
I was hoping someone else is getting the following error with Litespeed. We are getting the error 2 -4 times a day for full backups and t-log backups.
SLS Error: No Result XML returned from Engine. (Possible abend/termination...
We are running SQL 2005 Standard edition(SP3) on a 2003 sp1 x64 server. Servers have 16 gig of RAM and 13 has been given to SQL Server. This is a clustered environment 2 node active passive cluster.
Per the suggestions from Quest we have spaced out our jobs, and set the MaxTransfer Size parameter when running their extended stored procedure.
I have noticed that when we get errors with the backups we see a drop of around 200mb of RAM available on the server.
Any help would be appreciated
Thanks
Erich
November 24, 2009 at 1:07 pm
I'm getting this error now too.
Msg 50000, Sev 18, State 1: SLS Error: No Result XML returned from Engine. (Possible abend/termination) [SQLSTATE 42000]
It just started recently after a reboot of the box to swap out some questionable RAM. Latest OS updates were installed as well and the error started right after. Before the upgrade the backups ran without error.
My box is MS Windows Server 2003 R2, Standard x64 Edition Service Pack 2
Microsoft SQL Server 2005 Enterprise Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2)
November 24, 2009 at 1:12 pm
I will say this...We called quest and ended up changing our call to their extended procedure. We added verbose logging on failure to 1 of our servers that was having lots of problems, and now none of the backups have failed since we changed that setting.
November 25, 2009 at 12:11 am
These questions might be better asked of the Quest LiteSpeed support team 😀
You might also try The Quest Online Support Forums.
Often, these things come about when using a older version of LiteSpeed. Equally often, the cause can be traced to an update from Microsoft breaking something.
Paul
November 25, 2009 at 4:30 am
I have experienced similar problems when memory has been under perssure.
The OP said they have a 16GB box with 13GB allocated to SQL Server. This may be OK in the OP's environment, but typically allocating 12GB to SQL on a 16GB box is about the upper limit of what is safe.
Over allocating memory a small amount does not always cause SQL Server to run slowly, although large over allocation will affect SQL speed. However, lack of memory may affect other processes on the box that need to conmnect to SQL Server, such as SSIS and backup routines.
One troubleshooting tactic that is definitely worth doing in this situation is reducing the memory available to SQL by maybe 10%, and see if things become stable. If this does work, you can then increase the SQL memory in stages until things start breaking again, to prove that this is a memory starvation issue.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
November 25, 2009 at 8:08 am
Thanks guys! I appreciate the help.
I posted here because we didn't really get a quality answer from Quest Support, and I was hoping someone else might have experienced the same issue.
I will check the forum as you suggest. And I will look into the memory pressure, but this hasn't seemed like an issue to this point.
Thanks again for the help
November 25, 2009 at 9:00 am
I do have a follow up question on why you say 12 gb is normally the upper limit of what is safe. Can you tell me what that is based on?
I have sized at 13 based on watching the total and target server memory. I have not seen it get to anything less than 1.4 gb free memory.
I was just wondering if I am missing something.
Thanks
November 25, 2009 at 9:32 am
Did you check the memory use when you are running backups and other batch processes? You need to set your max memory use to take these into account.
If you have done this and 13GB looks OK, then it probably is. Just remember that if extra software is added to the server (including Windows, SQL and anti-virus fixes) or you add lots of new batch tasks then you should review the SQL max memory limit to see if it is still OK.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
November 25, 2009 at 9:39 am
I have watched it during backups and while it does drop, it never goes below 1.4 gb available.
I was just wondering if I had missed something. Thanks again for your time
November 25, 2009 at 2:37 pm
1-2GB free is plenty on a dedicated box. Don't worry about it.
See http://blogs.msdn.com/slavao/archive/2006/11/13/q-a-does-sql-server-always-respond-to-memory-pressure.aspx for more information.
November 25, 2009 at 2:38 pm
Erich Brinker (11/25/2009)
I posted here because we didn't really get a quality answer from Quest Support...
How shocking :laugh:
It would still be good to know that you are running the latest version...!
November 30, 2009 at 8:06 am
Sorry for the delay, out for Thanksgiving.
Yes we are on the latest version of Litespeed. For some reason we are still running without failure since changing to verbose logging on failure.
Thanks to you all for the help!
Erich
May 13, 2010 at 12:15 pm
I just spend 20 minutes trying to figure this out, researching possible causes, etc etc...
my wrapper script that calls the xp was passing the parms for the tsmconfig file and tsm management clases out of order and without their labels... the 20 minutes away from the code helped me see my problem 😀
its still a sorta cryptic error message...
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply