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?

Cheers,
Gary

[ Post a follow-up to this message ]

Hi Gary,
I've no solution but 'm also having this problem did you get any resolution.
Slán
Gar

"Gary" wrote:

> 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 b
ut
> I still get this error.
>
> Has anybody else had this or know how to resolve this issue?
>
> Cheers,
> Gary

[ Post a follow-up to this message ]

Hi Gar,

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 sai
d
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.

"gar" wrote:
[vbcol=seagreen]
> Hi Gary,
> I've no solution but 'm also having this problem did you get any resolutio
n.
> Slán
> Gar
>
> "Gary" wrote:
> 

[ Post a follow-up to this message ]

I'll give it a go you never know it just might work ;0) thanks for the quick
reply

"Gary" wrote:
[vbcol=seagreen]
> Hi Gar,
>
> 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 s
aid
> 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 wa
s
> 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.
>
> "gar" wrote:
> 

[ Post a follow-up to this message ]

Hi,
are you doing message body tracking?
Y.
"gar" <gar@discussions.microsoft.com> wrote in message
news:22669A70-0F1C-448E-81EC-CAE265DEFDD5@microsoft.com...[vbcol=seagreen]
> I'll give it a go you never know it just might work ;0) thanks for the
> quick
> reply
>
> "Gary" wrote:
> 

[ Post a follow-up to this message ]

Hi gar,

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.

Thanks,

Marian
http://www.MarianDrumea.com/BizTalk

[ Post a follow-up to this message ]

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 cas
e
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.

Slán
Gar



"Marian Drumea" wrote:

> Hi gar,
>
> 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.
>
> Thanks,
>
> Marian
> http://www.MarianDrumea.com/BizTalk
>
>

[ Post a follow-up to this message ]