我有一个带文件接收位置的应用程序。主机实例运行几个小时后，接收位置无法识别丢弃到其正在监视的文件夹中的新文件。它并没有完全忘记它们，只是表现为爬行。接收位置配置为每60秒轮询目标文件夹，但在主机实例运行一小时左右后，似乎目标文件夹仅每30分钟轮询一次。如果我重新启动主机实例，则会立即收集在目标文件夹中等待的文件，并在接下来的一小时内完成性能。
相同的应用程序在不同的环境中运行良好。 现在事件日志中有与问题相关的明显条目。 除备份BizTalk Server（BizTalkMgmtDb）之外，所有BizTalk SQL作业都运行正常。
感激地收到任何建议。
由于
罗布
答案 0 :(得分：2)
以下是一些可帮助您识别和诊断BizTalk数据库问题的其他工具。
以下是修复已识别错误的工具：
使用风险自负...阅读glogs和docs。从消息框查看器开始，让我们知道我们的结果。
答案 1 :(得分：1)
如果没有更多详细信息，最重要的是您的备份作业失败。如果备份作业失败，则可能未正确配置。如果配置正确但仍然失败，那么您还有其他问题。您能否提供一些有关BizTalk安装的更多信息。
答案 2 :(得分：1)
要考虑的另一件事是发送，接收和业务流程主机正在运行的用户帐户。请检查BizTalk管理控制台。如果它们都运行相同的帐户，有时业务流程可能会使发送和接收CPU时间过程匮乏。我相信优先考虑然后收到编排，然后发送。即使您刚刚开发，为此使用单独的帐户也很有用。这也提高了安全性。
Wrox BizTalk Server 2006还将提供调优建议。
答案 3 :(得分：1)
服务器还发生了什么其他事情？ BizTalk是钉住还是闲置？
答案 4 :(得分：1)
您提到该解决方案在其他环境中没有任何问题，因此可能存在配置问题。
检查以下内容：
**在SQL Server上，为SQL Server设置一些内存上限。默认情况下，SQL Server使用它可以获得的任何内容然后挂起，因此设置一个合理的限制，这样您的系统就可以在不花费大量时间将内存分配到硬盘驱动器上的情况下运行。
**确保您有可用的磁盘空间 - 也许您运行不足 - 这可能会导致各种奇怪的问题。
**尝试在系统的物理驱动器中拆分系统的页面文件（如果系统上有多个驱动器）。还要考虑使用更快的驱动器，或者如果周围有大量现金，请购买SAN。
**在BizTalk中，是否启用了跟踪？如果是这样，您是否也在跟踪邮件正文？禁用定位或邮件正文跟踪，看看是否存在差异。
**启动性能监视器并在运行解决方案时监视以下计数器
计数器：收到的文件/秒
对象：BizTalk Messaging
计数器：已发送的文件/秒
对象：XLANG / s业务流程
%%您可能只有一台主机，因此只需使用它即可。由于BizTalk配置各不相同，我使用的是通用名称。
前面的计数器监视服务器的最基本方面，但可能有助于缩小位置以进一步查看。当然，您也可以添加CPU和内存。如果你有时间（几天......可能是几周），你可以监控分配内存的进程，而不是释放它。使用以下计数器......
此计数器缓慢下降表示进程未释放内存，这会影响系统上的所有内容。
让我们知道事情的结果！
答案 5 :(得分：1)
我遇到了同样的问题，当我的编排空闲了一段时间后，花了很长时间来处理第一个消息。 EvYoung的一篇文章帮我解决了这个问题。
“这是由BizTalk主机进程中的应用程序域卸载引起的。如果AppDomain在空闲后关闭，则下一条消息需要等待Orchestration再次编译。根据设计的复杂程度，这可以为了防止在低延迟要求情况下出现这种情况，您可以修改BTSNTSVC.EXE.config文件并将SecondsIdleBeforeShutdown属性设置为-1。这将阻止因空闲而关闭AppDomain。“
你可以在这里找到这篇文章： http://blogs.msdn.com/b/biztalkcpr/archive/2008/05/08/thoughts-on-orchestration-performance.aspx
我花了很长时间才回应，但我想我可能会帮助别人。干杯：）
答案 6 :(得分：0)
其他人的一些好建议。我将补充：
接收位置是否有自定义接收管道组件？如果是这样，也许一个人正在泄漏内存，调用一些外部组件，例如需要很长时间的数据库？
您收到的文件有多大？
在接收位置的文件传输属性上，设置“文件重命名”，文件将在60秒内重命名。