1

哎呀，

我们在 BizTalk 2013 R2 中有两个 BizTalk 应用程序，它们似乎存在随机问题。两个应用程序都遵循相同的过程。

  • 从 WCF 终结点提取数据。
  • 通过存储过程从数据库中删除数据。
  • 插入通过 WCF-SQL 调用提取的新数据。

在我们的测试过程中，这两个应用程序在相当长的一段时间内都运行良好。但是，随着时间的推移，我们在通过 WCF-SQL 调用插入时遇到了一些问题。

  1. 从网络读取输入流时发生致命错误。会话将被终止（输入错误：64，输出错误：0）。

此错误出现在 Sql Server 日志中。我们有这个大约一天，然后它就消失了。其他一切都在该目标 sql 服务器上继续正常工作。只有 BizTalk 有问题。

  1. 我们最新的错误是对 WCF-SQL 插入的请求发生的地方（实际插入了数据），但从来没有响应。因此，发送端口继续尝试发送它的重试，并且编排只是脱水。

我们修改了整个应用程序中的每个设置以尝试解决这个问题，但只有删除应用程序和重新部署解决了这个问题（至少现在是这样）。

所以，我想我的问题是，是否有其他人在 BizTalk 中遇到过此类问题，比如出现这样的“随机”错误，它会很好地工作，然后像我们所看到的那样走下坡路？

我真的更喜欢稳定且维护最少的东西。这毕竟是企业产品。

4

1 回答 1

1

在存在数据差异的环境之间移动时，我会遇到类似的问题，例如，QA 中的一列充满 NULL，PROD 中的一列充满实际数据。您可以尝试几件事。

  1. 使用 SQL Sever Profiler 捕获来自 BizTalk 的 RPC 调用，并尝试直接在 BizTalk 远程调用的 SQL Server 上运行它（如果这是生产，则将其包装在最后回滚的事务中）。运行时间是否比预期更长？调试过程以找到痛点并尽可能优化。我在这里写了一篇关于如何做到这一点的博客：http: //blog.tallan.com/2015/01/09/capturing-and-debugging-a-sql-stored-procedure-call-from-biztalk/
  2. 在发送端口的绑定配置中设置超时设置，以确保在 SQL 完成其工作之前它不会超时。
  3. 在 Machine.config 中设置 System.Transactions 超时以确保 MSDTC 不会引起问题：http: //blogs.msdn.com/b/madhuponduru/archive/2005/12/16/how-to-change-system-交易超时.aspx和http://blog.brandt-lassen.dk/2012/11/overriding-default-10-minutes.html
  4. 如果可能，在 TEST/QA 和 PROD 数据库之间进行数据比较。寻找显着差异，尤其是在您在 JOIN 条件和 WHERE 子句中使用的列中。
于 2015-04-09T12:46:22.783 回答