We have an issue with T-Log backups being executed by Litespeed. Here is a sequence of events:
This error happened once a couple of months ago and Litespeed support has asked us to enable the logging and reproduce the issue. The challenge here is that we are unable to reproduce the issue. The occurrence is so random that it requires us to enable logging on all our 100 Production servers continuously and wait for few months to capture the issue. The challenge with doing that is the amount of logs that are generated. We tried doing that once in the past and blew out the C drive on many servers within 1 day. I observed that the amount of logging is proportional to the number of dbs and we have servers that have hundreds of databases.
Before we go thru the process of enabling logging again, I wanted to find out if you have any idea about why a Litespeed spid would get stuck with a wait type ‘preemptive_os_getprocaddress’.
Below url indicates that the wait type is observed when SQL tries to invoke some DLLs. I suspect that this is an issue when SQL tried to invoke the Litespeed dll. Can someone let us know their thoughts on this issue and the associated wait type?
Looks like there is a similar issue on the forums logged in the past, but I do not see a definitive solution in that case. I appreciate a solution for this issue as this causing us some grief by throwing alerts at all kinds of random times (ex: 12:00 AM in the night)
In reply to Alexander:
In reply to dba_27450:
We didn't face this issue in our lab. Could you apply the latest Sql Server update (CU8) to the instance?Also, I may recommend to install v8.6 to the instance and re-check.