为什么 TrackedMessages_Copy_BizTalkMsgBoxDb 会以“查询处理器无法生成查询计划”开始失败？

Question

为什么 TrackedMessages_Copy_BizTalkMsgBoxDb SQL 代理作业开始失败并显示“查询处理器无法生成查询计划”？

由于此查询中定义的提示，查询处理器无法生成查询计划。在不指定任何提示且不使用 SET FORCEPLAN 的情况下重新提交查询。 [SQLSTATE 42000]（错误 8622）。

我们的 SQL 人员正在讨论修改存储过程。但我们已经告诉他们将 BizTalk db 视为 black box

Answer 1

不用说，但在任何事情之前，请确保备份您的数据库。事实上，如果您的常规备份作业正在运行，您可能能够恢复备份并将其与它在此服务器上运行时的情况进行比较。那就是——

1. 检查 SQL 代理作业以确保未添加其他步骤/未强制执行计划/未使用任何提示；它应该只有一个名为“Purge”的步骤，它以 DB 服务器和 DTA 数据库名称作为参数调用以下过程。
2. 检查程序 (BizTalkMsgBoxDb.dbo.bts_CopyTrackedMessagesToDTA) 以确保它未被更改。

如果这是生产或其他敏感设备，请备份数据库并将其恢复到本地开发环境，然后再继续！

1. 如果这不是生产，请查看您是否可以直接在 SSMS 中运行该过程（可能在您回滚的事务中）。看看你是否得到更好的错误。添加打印语句，看看您是否可以准确找出出现冲突提示的位置。
2. 如果程序无法运行，请考虑释放程序缓存 (DBCC FREEPROCCACHE) 并查看程序是否会运行。

如果它通过备份在您的开发环境中运行，您可能必须开始查看服务器/数据库设置。不过，我想不出哪个会导致这个错误。

不管怎样，好心的 DBA 经常破坏 BizTalk。他们决定索引丢失或没有正确覆盖，或者可以提高安全性，或者应该像对待他们管理的其他数据库一样对待数据库。我见过 DBA 对难以诊断的 BizTalk 数据库做了非常愚蠢的事情。

Answer 2

您是否尝试更新存储过程（由 SQL Server 代理作业运行）引用的数据库表的统计信息？查询计划器使用这些信息来决定如何最好地执行您的 SQL。