Gary 2006-09-06 08:14:20
Hi I am experiencing the following error:
TDDS failed to read from source database. SQLServer: U071606, Database:
BizTalkMsgBoxDb.Timeout expired. The timeout period elapsed prior to
completion of the operation or the server is not responding..
Trawling through the web I have found that this can be caused by sessions
hanging around on SQL. I have tried to kill as many processes as I could but
I still get this error.
Has anybody else had this or know how to resolve this issue?
Garv&r 2006-09-28 03:18:26
I’ve no solution but ‘m also having this problem did you get any resolution.
Gary 2006-09-28 03:18:45
After having killed off the sql sessions etc and restarted the server
numerous times I gave up and asked our IT guy if he new of any ideas. He said
try restarting the server so I did, telling him that I had tried this
numerous times before. But sods law meant that the only time our IT guy was
there it acutally worked after a reboot.
I haven’t had the issue since but as to what caused it and why it suddenly
started working again remains a mystery to me.
Garv&r 2006-09-28 03:19:01
I’ll give it a go you never know it just might work ;0) thanks for the quick
Younes amar 2006-09-28 03:20:09
are you doing message body tracking?
Marian drumea 2006-09-29 03:23:48
This happened to me a couple of times. First, these are deadlocks on
the BizTalk management database (if I remember correctly) and they are
caused by heavy message tracking and, most likely, a recurrent error on
a busy flow. Gary is right that killing sessions will help you. You
should then take that further, because killing deadlocking processes
will get BizTalk functional enough to allow you to terminate instances
in HAT. Probably you will face a backlog of suspended messages with
errors. Also, make sure you stop the processing (orchestrations) before
that, otherwise you will have to do it several time before catching up.
This is a good set of steps to remember if and when this happens again.
Anyways, you should look into any original error, into reducing the
tracking, or maybe scaling up/out if this becomes a rule and happens
under normal circumstances and if you really need all that tracking.
Garv&r 2006-09-29 03:24:36
Hi Marian, Younes, Gary,
Thanks for the help. Yes I had message body tracking on and lots of traffic
on a test system (probably overloaded). Here’s what I had to do. Just in case
anyone else has this problem.
I turned off tracking using GlobalTrackingOption (see BTS dox)
Turned off message body tracking on everything. Through HAT
Pruned the tracking database – dtasp_PruneTrackingDatabase
Restarted BTS no problems or deadlocks
Turned back on GlobalTrackingOption
All is ok so far. So the lesson is be careful what you track.