|
Home > Archive > BizTalk Server > January 2005 > SQLSERVERAGENT Warning in EventLog (Event ID 208)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
SQLSERVERAGENT Warning in EventLog (Event ID 208)
|
|
| Silly_King 2005-01-04, 5:53 pm |
| Hi all,
Recently i started receiving a SQLSERVERAGENT warning in the event log
(Event ID 208), with the following message:
"SQL Server Scheduled Job 'MessageBox_Parts_Cleanup_BizTalkMsgBoxD
b'
(0x[GUID]) - Status: Failed - Invoked on [Date] - Message: The job failed.
The Job was invoked by Schedule 13 (Schedule). The last step to run was step
1 (Purge)."
This message gets logged every minute (the job is scheduled to run every
minute and, of course, it fails every minute). Any idea why it started to
fail? What does it affect? What do i need to do to make it stop failing?
Thank you!
| |
| Eldar Musayev 2005-01-05, 5:53 pm |
|
You probably reinstall BizTalk or changed the MessageBox db. When you
uninstall BizTalk, purge jobs are left in the SQL database along with the
data. If you later remove the data, the purge jobs starts to fail. In this
case, you can remove the purge job manually, by going in SQL Server
administration into the database -> SQL Agent jobs and removing these jobs
manually.
Regards,
Eldar
This posting is provided "AS IS" with no warranties, and confers no rights.
EBusiness Server Team
--------------------[vbcol=seagreen]
<SillyKing@discussions.microsoft.com>[vbcol=seagreen]
failed.[vbcol=seagreen]
step[vbcol=seagreen]
to[vbcol=seagreen]
| |
| Silly_King 2005-01-05, 5:53 pm |
| Eldar, thank you for replying. However, I did not reinstall BTS nor did i
change the MessageBox db. I think i figured out (just in the last few hours)
what happened, and it's not pretty:
Some time last week I played with "Publish Schema as a web service" option
of the BizTalk Web Services Publishing Wizard. When i created that web
service i specified a particular message schema as a type for one of the web
service operations. Apparently, that was a mistake, as all messages of that
type started to be sent to that web service, regardless of where they
*should* have been sent! So if a request came in on a different web service
(Request/Response pattern), the Response to the request was sent to the
"test" WS i'd created via "Publish Schemas as a web service" option, rather
than to the web service that received the Request! (This, as a consequence,
caused the web service clients to time out, as they never got a response from
me, even though the successfully sent a message...)
I'm guessing here now because i'm not an expert on BizTalk database internal
processes, but the fact that all messages of the misdirected type were now
"delivered, not consumed", the delivery queue started to pile up, especially
as i was doing more and more frenetic "testing". I don't know how this
affected the part purging job, exactly. i do know, however, that when i tried
to run the bts_PartsPurge sproc directly, i got an error message (which i
failed to record, sadly). The gist of the error (or as well as i remember it)
was that the number of Parts exceeded the storage capacity provided by a
signed short integer (>32K), and so the sproc bombed out.
i think the upcoming SP1 script would have helped me out by clearing the
MsgBox db of debris, but i resolved my problem by removing & reinstalling
BizTalk & starting fresh with new, clean, and happy databases.
By the way, i saw the SP1 scripts mentioned in a few posts here - any reason
the scripts couldn't be posted somewhere as an unsupported "use at your own
risk" option for other almost S.O.L souls out there?
"Eldar Musayev (MSFT)" wrote:
>
> You probably reinstall BizTalk or changed the MessageBox db. When you
> uninstall BizTalk, purge jobs are left in the SQL database along with the
> data. If you later remove the data, the purge jobs starts to fail. In this
> case, you can remove the purge job manually, by going in SQL Server
> administration into the database -> SQL Agent jobs and removing these jobs
> manually.
>
> Regards,
> Eldar
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> EBusiness Server Team
> --------------------
> <SillyKing@discussions.microsoft.com>
> failed.
> step
> to
>
>
| |
| Eldar Musayev 2005-01-06, 5:50 pm |
|
About the script, frankly, I am not sure why it was not posted. Probably,
for the same reason as the rest of BizTalk parts -- it's just coming with
the service pack. Glad, you were able to fix your issue,
good luck,
Eldar
This posting is provided "AS IS" with no warranties, and confers no rights.
EBusiness Server Team
--------------------[vbcol=seagreen]
<SillyKing@discussions.microsoft.com>[vbcol=seagreen]
<oym4BS38EHA.3512@cpmsftngxa10.phx.gbl>[vbcol=seagreen]
i[vbcol=seagreen]
hours)[vbcol=seagreen]
option[vbcol=seagreen]
web[vbcol=seagreen]
that[vbcol=seagreen]
service[vbcol=seagreen]
rather[vbcol=seagreen]
consequence,[vbcol=seagreen]
from[vbcol=seagreen]
internal[vbcol=seagreen]
now[vbcol=seagreen]
especially[vbcol=seagreen]
tried[vbcol=seagreen]
i[vbcol=seagreen]
remember it)[vbcol=seagreen]
reinstalling[vbcol=seagreen]
reason[vbcol=seagreen]
own[vbcol=seagreen]
the[vbcol=seagreen]
this[vbcol=seagreen]
jobs[vbcol=seagreen]
rights.[vbcol=seagreen]
log[vbcol=seagreen]
'MessageBox_Parts_Cleanup_BizTalkMsgBoxD
b'[vbcol=seagreen]
was[vbcol=seagreen]
every[vbcol=seagreen]
started[vbcol=seagreen]
failing?[vbcol=seagreen]
|
|
|
|
|