sp_procedure_params_90_rowset上的编译阻塞过多

MSDN上该问题的死灰复燃：阻塞的进程报告：这个waitresource是什么“对象：32767：124607697：0 [COMPILE]”

我已经在Profiler中捕获了这些语句。它们的持续时间都超过3秒。超过10岁以上。阻止活动与MSDN的链接相同。

呼叫均使用三部分命名。它们都以不同的形式指定不同的proc，它们看起来如下所示：

exec [db1].[sys].sp_procedure_params_90_rowset N'proc1', 1, NULL, NULL
exec [db2].[sys].sp_procedure_params_90_rowset N'proc2', 1, NULL, NULL
exec [db3].[sys].sp_procedure_params_90_rowset N'proc3', 1, NULL, NULL
exec [db4].[sys].sp_procedure_params_90_rowset N'proc4', 1, NULL, NULL

我怎样做才能减少这种阻塞？

（编辑）我现在看到以下相同的东西：

exec [db1].[sys].sp_primary_keys_rowset N'view1', N'dbo'
exec [db2].[sys].sp_primary_keys_rowset N'view1', N'dbo'
exec [db3].[sys].sp_primary_keys_rowset N'view1', N'dbo'
exec [db4].[sys].sp_primary_keys_rowset N'view1', N'dbo'

这是系统性的事情，但我不知道该怎么办。调用者是通过ADO的VB6。是ADO进行这些调用。

以下是阻止的流程报告示例

 <blocked-process-report>
    <blocked-process>
        <process
            id="process5bc1288"
            taskpriority="0"
            logused="0"
            waitresource="OBJECT: 32767:124607697:0 [COMPILE]"
            waittime="28887"
            ownerId="11638114050"
            transactionname="sqlsource_transform">
            <executionStack>
                <frame
                    line="1"
                    sqlhandle="0x000000000000000000000000000000000000000000000000">
                    <sqltext>EXEC [dbo].[spAlertDetectByPoll] ':V:^RMAlert^:Z:^&amp;N&amp;#RMAlert#&amp;S&amp;#L#&amp;UID&amp;#19#&amp;AGN&amp;#1#&amp;DFC&amp;#103#^', 1</sqltext>
                </frame>
            </executionStack>
            <inputbuf>
SET NO_BROWSETABLE OFF   </inputbuf>
        </process>
    </blocked-process>
    <blocking-process>
        <process
            status="suspended"
            waitresource="OBJECT: 32767:124607697:0 [COMPILE]"
            waittime="35693"
            spid="1121"
            sbid="0"
            ecid="0"
            priority="0"
            trancount="0"
            lastbatchstarted="2013-12-16T14:45:48.960">
            <executionStack>
                <frame
                    line="1"
                    sqlhandle="0x000000000000000000000000000000000000000000000000" />
            </executionStack>
            <inputbuf>
SET NO_BROWSETABLE OFF   </inputbuf>
        </process>
    </blocking-process>
</blocked-process-report>

sql-server-2008-r2 blocking

— 丹·霍姆斯
source

您是否已为SQL Server 2008 R2安装了最新的Service Pack和累积更新？

— Max Vernon

SP2 CU4 Microsoft SQL Server 2008 R2（SP2）-10.50.4270.0（X64）

— dan

什么时候开始发生？您最近是否应用了Service Pack或累积更新？我也支持VB6 / ADO，回想起这些系统处理程序出现了一次或两次，但我认为没有阻塞问题。我认为他们来是因为他们经常被打来。我祈祷这与SP / CU无关，因为我们仍在10.50.2500上，如果这些东西每次开始花费3-10秒，那将是死亡。

— 乔恩·塞格尔

它将其中的一个放入pastbin pastebin.com/4wUgzby9中。这已经进行了大约2或3周。我们已经很长时间没有应用CU了。如MSDN帖子所述，它于2012年初首次发生。

— dan holmes 2013年

这可能只是症状。我在RESOURCE_SEMAPHORE_QUERY_COMPILE上有定期的等待活动。下面是此waittype我已经找到了最好的治疗方法： blogs.msdn.com/b/support_sql_france/archive/2012/02/07/...

— 丹霍姆斯

有一篇很棒的博客文章 http://blogs.msdn.com/b/support_sql_france/archive/2012/02/07/sql-server-compilation-gateways-and-resource-semaphore-query-compile.aspx 解释了什么发生。

SQL Server根据其复杂性允许设置一定数量的编译。它将它们分为小型，中型和大型。对于大型编译，一次只能编译一个，因此，假设您的所有proc都被认为是大型程序，则每个编译都必须按顺序进行。那可能是造成封锁的原因。
我认为可能有几种方法可以解决此问题-考虑更多的资源（更多的CPU将允许更多中小型查询并发，或者可能超过中等阈值）。同样，更多的内存可以解决该问题。

如果您像我们大多数人一样，那可能是不可能的。另一个选择可能是查看ADO调用，并查看是否可以减少或分散调用数量，以使并非所有调用都同时发生。在任何给定时间减少电话号码应该可以减少您的等待时间。

如果这不起作用，请考虑修复存储过程的“可编译性”。也许将它们分解为较小的块，这可能会将它们缩小为中小型存储桶，并允许更多并行编译。或者确定为什么每次都需要重新编译proc。看看是否可以重写它们，而无需重新编译。最后，我会考虑使用计划指南。这些将允许对proc进行预编译，并可以节省一些时间。

希望能有所帮助

— 鲍尔宾
source