Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 1515 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Scheduled scan issue with SQL 2008R2

RonMexico

We are see interuptions with our web applications due to a Sophos scheduled scan on a SQL 2008R2 server. Here is one of the many errors of the same that is in the event log and SQL error log when the scheduled scan begins. On access does not appear to be an issue.

"The client was unable to reuse a session with SPID 337, which had been reset for connection pooling. The failure ID is 29. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message."

I have moved the scheduled time and the problem moves with the scheduled scan time. I have disabled the schduled scan and have no issues. I have about 8 SQL clusters with this being the only one exhibiting this behaviour. I have setup the best practice for exclustions for SQL servers for the policy. Reinstall didn't help.

Any ideas or suggestions welcomed.

:43907


This thread was automatically locked due to age.
Parents
  • 0

    Hello RonMexico,

    are these errors issued throughout the scan or only "at the beginning". Which scanning options (rootkits, archives, system memory) are checked - although this alone wouldn't explain why just one out of eight exhibits this behaviour. Any trace of failed operations immediately before this error message?

    The scan is scheduled from the console? Do you get the same results for a locally scheduled scan (I know, one shouldn't test in a production environment) - perhaps one that scans only parts (e.g. SystemRoot but not ProgramFiles) of the file system?

    Christian

    :43913
Reply
  • 0

    Hello RonMexico,

    are these errors issued throughout the scan or only "at the beginning". Which scanning options (rootkits, archives, system memory) are checked - although this alone wouldn't explain why just one out of eight exhibits this behaviour. Any trace of failed operations immediately before this error message?

    The scan is scheduled from the console? Do you get the same results for a locally scheduled scan (I know, one shouldn't test in a production environment) - perhaps one that scans only parts (e.g. SystemRoot but not ProgramFiles) of the file system?

    Christian

    :43913
Children
No Data