SQL Server 阻塞引起编译锁的说明

文章翻译 文章翻译
文章编号: 263889 - 查看本文应用于的产品
展开全部 | 关闭全部

本文内容

概要

在 Microsoft SQL Server,只有一个副本的存储的过程计划通常是在缓存中一次。 强制实施此要求在编译过程中的某些部分的序列化,可以通过使用编译锁部分完成此同步。 如果多个连接正在同时运行相同的存储的过程,并且编译锁必须获得该存储过程的每次运行它时,可能开始为每个试图获取对象上的排它编译锁阻止另一个系统进程 id (spid)。

更多信息

存储的过程重新编译为一个说明编译存储的过程或触发器的锁。 在这种情况下,解决方案是以减少或消除了重新编译。 最常见的原因,可能需要重新编译存储的过程的说明和减少重新编译的频率一些有用的信息,请参阅以下 Microsoft 知识库文章:
243586存储的过程重新编译的疑难解答
编译锁可能发生的另一种情况是当以下条件为真时:
  • 运行存储的过程在用户不是过程的所有者。
  • 无法用对象所有者的名称完全限定存储的过程的名称。
例如用户"dbo"拥有的对象dbo.mystoredproc和另一个用户,"具有,"通过使用该命令"exec mystoredproc,"初始高速缓存查找的对象名称失败,因为该对象不是所有者限定运行此存储的过程。 (它是未知是否存在名为 Harry.mystoredproc 的另一个存储的过程。 因此,SQL Server 无法确定为 dbo.mystoredproc 高速缓存的计划是一个正确执行)。 SQL Server 然后获取对该过程为独占的编译锁,并使以编译该过程的准备工作。 这包括在对象名称解析为一个对象 id。 SQL Server 编译计划之前,SQL Server 执行的过程高速缓存的更精确地搜索将使用此对象 ID,并可以找到一个以前编译过的计划,即使没有所有者限定。

如果找到一个现有的计划,则 SQL Server 将重用高速缓存的计划,并不实际编译存储的过程。 但是,所有者限定缺乏强制执行第二个高速缓存查找并获得独占编译锁之前,该程序确定可重复使用现有的高速缓存的执行计划的 SQL Server。 获取该锁,并执行查找和到达该点所需的其他工作可以引入编译锁会导致阻塞的一段延迟。 这是不是同时运行该过程,而无需提供所有者的名称的存储的过程的所有者的尤其如此,如果许多用户。 注意,即使看不到用于编译锁等待的 spid,缺乏所有者限定可以介绍在存储的过程执行的延迟并导致不必要地高 CPU 使用率。

出现此问题时,将 SQL Server 事件探查器跟踪中记录下列事件序列。 (要跟踪与缓存相关的事件,您必须启用高级的事件。 为此请单击选项上将工具菜单,然后选择所有事件类。)

收起该表格展开该表格
事件类文本
RPC: 启动mystoredproc
SP:CacheMissmystoredproc
SP:ExecContextHitmystoredproc
SP: 启动mystoredproc
......

SP:CacheMiss按名称缓存查找失败时发生。 以下SP:ExecContextHit表示一个匹配的高速缓存的计划已最终找到缓存中后不明确的对象名称被解析为一个对象 id。 具体取决于在不同环境下SP:CacheHit可能会出现,而不是SP:ExecContextHit.

此问题,编译锁定的解决方案是确保对存储过程的引用是所有者限定。 (代替exec mystoredproc使用 execdbo.mystoredproc.) 出于性能原因重要所有者限定时不必限定存储的过程以防止更多的缓存查找数据库名称。

阻塞的锁可以通过使用如下面的 Microsoft 知识库文章中定义的阻止脚本检测到的编译由引起:
251004INF: 如何监视 SQL Server 7.0 阻塞
271509INF: 如何监视 SQL Server 2000 阻塞
以下是一些典型的编译阻止特征,可以阻塞脚本输出中观察到:
  • lastwaittype已阻塞和 (通常) 阻塞的 spid 的是 LCK_M_X (独占) 和waitresource在窗体的"TAB: dbid:object_id[[]],"编译"object_id"所在的存储过程的对象 ID。
  • 已阻止程序waittype0x0000,可运行的状态。 blockees 有waittype0x000e (排他锁) 休眠状态。
  • 但阻塞事件的持续时间可能长,是不很长时间阻塞其他一个 spid 的单个 SPID。 没有滚动的阻止。 只要一个编译已完成,另一个 SPID 接管头窗口阻止程序几秒钟或更少的等等的角色。
以下信息是从的快照sysprocesses在此期间类型的阻止:
   spid  blocked  waittype  waittime  lastwaittype  waitresource
   ----  -------  --------  --------  ------------  -------------------------
   
   221    29      0x000e    2141      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   228    29      0x000e    2235      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    29   214      0x000e    3937      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    13   214      0x000e    1094      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    68   214      0x000e    1968      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   214     0      0x0000       0      LCK_M_X       TAB: 6:834102 [[COMPILE]]
在该waitresource列 (6:834102) 6 是数据库 ID 和 834102 为对象 id。 注意,此对象 ID 属于不到表中 (尽管在"TAB"的锁类型) 的存储过程。

备注
  • 如果使用的 SQL Server 2005 从 SQL Server 2000 系统表的许多现在实现为一组视图。 这些视图称为兼容性视图,并用于向后兼容性。 兼容性视图公开相同的 SQL Server 2000 中可用的元数据。 有关 SQL Server 2000 系统表和 SQL Server 2005 系统视图之间的映射的详细信息,请参阅 SQL Server 2005 联机丛书中的"映射 SQL Server 2000 系统表到 SQL Server 2005 系统视图"主题。
  • 如果您的存储的过程名称以"sp_"前缀开头,并且不是在 master 数据库中,您将看到SP:CacheMiss在高速缓存命中的每个执行,即使之前您所有者-限定存储的过程。 这是因为 sp_ 前缀指示 SQL Server 存储的过程是系统存储过程,和系统存储过程具有不同的名称解析规则。 (在"首选"的位置是在 master 数据库中。 用户创建存储过程的名称不应以"sp_"开头。
  • 如果比该所有者限定的过程被创建为所有者限定的过程执行与不同的情况下,该所有者限定的过程可以获得一个CacheMiss或请求编译锁,但最终使用高速缓存的计划。 因此,这重新将不实际编译该过程,并且不应导致很多系统开销。 但在特定的情况下编译锁定的请求可能导致"阻塞链"的情况下是否有许多的 spid 尝试执行相同的过程与不同的情况下,比作为创建过程。 This is true regardless of the sort order or collation that is being used on the server or on the database. The reason for this behavior is that the algorithm that is being used to find the procedure in cache is based on hash values (for performance reasons), which can change if the case is different.

    The workaround is to drop and create the procedure with the same case as?the procedure is executed by the application. You can also make sure that the procedure is executed from all applications that use the same case.
  • If you try to execute a stored procedure as a Language Event instead of as an RPC, SQL Server must parse and compile the language event query, determine that the query is trying to execute the particular procedure, and then try to find a plan in cache for that procedure. To avoid this situation in which SQL Server must parse and compile the language event, make sure that the query is sent to SQL as an RPC.

    For more information, see the "System Stored Procedures" section in the Books Online article "Creating a Stored Procedure."


Known issues

Here are some known issues that can prevent plan caching:
  • You use BLOB variables as a Stored Procedure parameter. 有关更多的信息请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
    2380435FIX: The query plan for a stored procedure is not cached if the stored procedure uses a BLOB variable and the variable is used in a string function in Microsoft SQL Server 2008
  • You use OPEN SYMMETRIC KEY in a Stored Procedure/Query Batch. For more information, see the following MSDN blog entry:
    http://blogs.msdn.com/b/sqlserverfaq/archive/2010/09/08/open-symmetric-key-command-prevents-query-plan-caching.aspx

属性

文章编号: 263889 - 最后修改: 2010年11月24日 - 修订: 1.0
这篇文章中的信息适用于:
  • Microsoft SQL Server 7.0 标准版
  • Microsoft SQL Server 2000 标准版
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Workgroup
关键字:?
kbinfo kbmt KB263889 KbMtzh
机器翻译
注意:这篇文章是由无人工介入的微软自动的机器翻译软件翻译完成。微软很高兴能同时提供给您由人工翻译的和由机器翻译的文章, 以使您能使用您的语言访问所有的知识库文章。然而由机器翻译的文章并不总是完美的。它可能存在词汇,语法或文法的问题,就像是一个外国人在说中文时总是可能犯这样的错误。虽然我们经常升级机器翻译软件以提高翻译质量,但是我们不保证机器翻译的正确度,也不对由于内容的误译或者客户对它的错误使用所引起的任何直接的, 或间接的可能的问题负责。
点击这里察看该文章的英文版: 263889
Microsoft和/或其各供应商对于为任何目的而在本服务器上发布的文件及有关图形所含信息的适用性,不作任何声明。 所有该等文件及有关图形均"依样"提供,而不带任何性质的保证。Microsoft和/或其各供应商特此声明,对所有与该等信息有关的保证和条件不负任何责任,该等保证和条件包括关于适销性、符合特定用途、所有权和非侵权的所有默示保证和条件。在任何情况下,在由于使用或运行本服务器上的信息所引起的或与该等使用或运行有关的诉讼中,Microsoft和/或其各供应商就因丧失使用、数据或利润所导致的任何特别的、间接的、衍生性的损害或任何因使用而丧失所导致的之损害、数据或利润不负任何责任。

提供反馈

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com