We have switched to our backup DC today as primary site Bandwidth has gone.

We are getting issues with the most powerful DB server; it is spawning the following process for several db's on the server. One database is simply a small scratch db that is used for maintenance tools, so not replicated or mirrored.

Does anyone know or recognize the following code?

() select table_id, item_guid, oplsn_fseqno, oplsn_bOffset, oplsn_slotid 
from [<dbname>].[sys].[filetable_updates_2105058535] with (readpast) 
order by table_id
  • 1
    blogs.msdn.com/b/psssql/archive/2011/10/29/… seems to indicate this might be an AlwaysOn Availability Groups or perhaps something to do with Contained Databases, etc. Does that apply?
    – Hannah Vernon
    Mar 1 '13 at 18:10
  • @Max Vernon Hi Max, yes, I discovered this a day or so later but wasn't able to answer my own question at that point. Mar 5 '13 at 11:56
  • a reboot resolved the issue, but a few weeks later I noticed performance degradation on the server again. Sure enough the same phantom threads had returned, even on a scratch db that had been dropped and recreated, arghh! this now sounds like a bug for sure Apr 15 '13 at 9:53
  • this reoccured again on the machine after a couple of weeks hitting performance so I think this must be a bug as we dont use Filestream or Filetables and only started when using AV groups. Submitting as bug to Microsoft Apr 22 '13 at 12:07

This was indeed down to some structure being left over from a SQL2012 AV group as had been doing some testing on these servers during a period when they were not in production as they were the only hardware in different DC's suitable.

During the next window of opportunity I rebooted the servers and the performance of both servers has vastly improved and the processes are no longer appearing. (added to my list of issues to all the ones Brent details on his website with SQL2012 AV group issues)

2012 AlwaysON Setup

A must read for anyone attempting to configure these. As noted in Brent's articles I found a number of pitfalls, more tricky than expected and currently have decided to postpone the rollout due to my own issues with unsuccessful multisubnet failover (i could only get this to work in 1 direction) and above mentioned performance overhead.

  • I can tell you from personal experience that this is not always an AV issue. I currently have this exact problem on 5 servers, none of which have ever had AVG setup on them (or FileStream which is also blamed for this). I have no idea what causes it, but in my case, it is definitely, neither of these.
    – PseudoToad
    Mar 8 '17 at 22:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.