Descrição do SQL Server bloqueio causada por bloqueios de compilação

Traduções de Artigos Traduções de Artigos
Artigo: 263889 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Nesta página

Sumário

No Microsoft SQL Server, apenas uma cópia de um plano de procedimento armazenado é geralmente na cache de cada vez. Aplicar este requer a serialização de algumas partes do processo de elaboração e esta sincronização é efectuada em parte utilizando bloqueios de compilação. Se o número de ligações em simultâneo com o mesmo procedimento armazenado e um bloqueio de compilação deve ser obtido para esse procedimento armazenado sempre que for executada, poderá começar o processo de sistema IDs (SPID) bloquear um outro como cada tentam obter um bloqueio exclusivo de compilação no objecto.

Mais Informação

Procedimento armazenado recompilation é uma explicação de bloqueios de compilação num procedimento armazenado ou accionador. A solução é, neste caso, para reduzir ou eliminar as recompilações. Para obter uma explicação das razões mais comuns que pode ter um procedimento armazenado para ser novamente compiladas e algumas informações úteis sobre como reduzir a frequência de recompilações, consulte o seguinte artigo da Microsoft Knowledge Base:
243586Resolução de problemas recompilation de procedimento armazenado
Outro cenário em que ocorrem os bloqueios de compilação é quando as seguintes condições são verdadeiras:
  • O utilizador que executa o procedimento armazenado não é o proprietário do processo.
  • O nome do procedimento armazenado não é totalmente qualificado com o nome do proprietário do objecto.
Por exemplo, se o utilizador "dbo" proprietário objectodbo.mystoredproce outro utilizador, "Harry," Este procedimento armazenado é executado utilizando o comando "exec mystoredproc," a pesquisa de cache inicial por objecto nome falhar, uma vez que o objecto não está qualificado de proprietário. (Se não é ainda conhecida se existe outro procedimento armazenado com o nome Harry.mystoredproc. Por conseguinte, SQL Server nem ter a certeza que o plano armazenado em cache para dbo.mystoredproc é o correcto para executar.) Em seguida, o SQL Server obtém um bloqueio exclusivo de compilação sobre o procedimento e efectua preparações para compilar o procedimento. Isto inclui a resolver o nome de objecto para um ID de objecto. Antes de compilar o plano, o SQL Server o SQL Server utiliza este ID de objecto para efectuar uma procura mais precisa da cache do procedimento e pode localizar um plano previamente compilado mesmo sem proprietário qualificação.

Se for encontrado um plano existente, o SQL Server reutiliza o plano armazenado em cache e não efectivamente a compilar o procedimento armazenado. No entanto, a falta de qualificação de proprietário força o SQL Server para efectuar uma pesquisa na cache segunda e obter um bloqueio exclusivo de compilação antes do programa determina que o plano de execução em cache existentes pode ser reutilizado. Obter o bloqueio e efectuar pesquisas e outros trabalhos que é necessária para atingir este ponto podem introduzir um atraso para os bloqueios de compilação que conduz a bloquear. Isto é especialmente verdadeiras se muitos utilizadores que não sejam proprietário o procedimento armazenado em simultâneo, execute o procedimento sem fornecer o nome do proprietário. Tenha em atenção que mesmo se não vir o SPID aguardar bloqueios de compilação, falta de qualificação de proprietário pode introduzir atrasos na execução do procedimento armazenado e causar desnecessariamente elevada taxa de utilização da CPU.

Quando este problema ocorre a seguinte sequência de eventos será registada num rastreio do SQL Server Profiler. (Para rastrear eventos relacionados com a cache, tem de activar eventos avançados. Para o fazer, clique emOpçõessobre oFerramentasmenu e, em seguida, seleccioneTodas as classes de evento.)

Reduzir esta tabelaExpandir esta tabela
Classe de eventoTexto
RPC: iníciomystoredproc
SP:CacheMissmystoredproc
SP:ExecContextHitmystoredproc
SP: iníciomystoredproc
......

SP:CacheMissocorre quando falha a pesquisa na cache pelo nome. O seguinteSP:ExecContextHitindica que um plano armazenado em cache correspondente em última análise foi encontrado no cache após o nome do objecto ambíguo foi resolvido para um ID de objecto. Consoante o caso,SP:CacheHitpoderá ser apresentado em vez deSP:ExecContextHit.

A solução para este problema de bloqueio de compilação é certificar-se de que as referências a procedimentos armazenados são qualificados de proprietário. (Em vez deexec mystoredproc, utilize execdbo.mystoredproc.) Enquanto a qualificação de proprietário é importante por motivos de desempenho, não é necessário que qualificar o procedimento armazenado com o nome de base de dados para evitar a pesquisa de cache adicionais.

Bloqueio que é causado por compilação bloqueios podem ser detectados utilizando scripts de bloqueio, tais como as que são definidas nos seguintes artigos da Microsoft Knowledge Base:
251004INF: Como monitorar o bloqueio do SQL Server 7. 0
271509INF: Como monitorar o bloqueio do SQL Server 2000
Seguem-se algumas características típicas de compilação de bloqueio podem ser observada no resultado do script bloqueio:
  • lastwaittypepara os SPID bloqueados e bloqueio (normalmente) é LCK_M_X (exclusivo) ewaitresourceestá no formato "TAB: dbid:object_id[[COMPILE]],"onde"object_id"é o ID de objecto do procedimento armazenado.
  • Bloqueadores de terwaittype0x0000 por, estado runnable. Ter blockeeswaittype0x000e (bloqueio exclusivo), estado no modo de suspensão.
  • Apesar da duração do bloqueio incidente poderá ser longa, não existe nenhum SPID único que está a bloquear as outros SPIDs durante muito tempo. Não existe o bloqueio gradual. Logo que uma compilação estiver concluída, o SPID outro assume a função do Bloqueador de cabeça para um vários segundos ou menos e assim sucessivamente.
As seguintes informações são a partir de um instantâneo desysprocessesdurante este tipo de bloqueio:
   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]]
Nawaitresourcecoluna ("6:834102"), 6 é o ID da base de dados e 834102 é o ID do objecto. Tenha em atenção que este ID de objecto pertence a um procedimento armazenado, não a uma tabela (apesar do tipo de bloqueio "TAB").

Notas
  • Se estiver a utilizar o SQL Server 2005, muitas das tabelas de sistema do SQL Server 2000 são agora implementadas como um conjunto de vistas. Estas vistas são conhecidas como vistas de compatibilidade e se destinam-se apenas a compatibilidade com versões anteriores. As vistas de compatibilidade expõem os metadados mesmo que estava disponível no SQL Server 2000. Para mais informações sobre o mapeamento entre as tabelas de sistema do SQL Server 2000 e as vistas de sistema do SQL Server 2005, consulte o tópico "Mapeamento SQL Server 2000 System tabelas para SQL Server 2005 sistema vistas" no SQL Server 2005 Books Online.
  • Se o nome do procedimento armazenado comece com o prefixo "sp_" e não está na base de dados principal, consulteSP:CacheMissantes da cache de visitas para cada execução remota, mesmo que é proprietário-qualificar o procedimento armazenado. Isto acontece porque o prefixo sp_ indica ao procedimento armazenado do SQL Server que o procedimento armazenado é um sistema e procedimentos armazenado do sistema tenham regras de resolução de nome diferente. (A localização "preferencial" é a base de dados principal.) Os nomes de procedimentos armazenados criado pelo utilizador não devem iniciar com "sp_".
  • Se um procedimento qualificado de proprietário é executado com um caso diferente que o procedimento de proprietário qualificado foi criado como, o procedimento qualificado proprietário pode obter umCacheMissou solicitar um bloqueio de compilação mas, eventualmente, utilize o plano armazenado em cache. Por conseguinte, este não seria efectivamente a recompilar o procedimento e não deve provocar muito uma sobrecarga. Mas em determinadas situações, o pedido de um bloqueio de compilação pode provocar uma situação de "bloqueio de cadeia" se existirem muitos SPIDs tentar executar o mesmo procedimento com um caso diferente do que o procedimento foi criado como. Isto acontece independentemente da sequência de ordenação ou agrupamento que está a ser utilizado no servidor ou na base de dados. A razão para este comportamento é que o algoritmo que é utilizado para localizar o procedimento na cache baseia-se nos valores de hash (por razões de desempenho), que podem alterar se o incidente for diferente.

    A solução é largar e criar o procedimento com o mesmo formato que o procedimento é executado pela aplicação. Também pode certificar-se de que o procedimento é executado a partir de todas as aplicações que utilizam o mesmo formato.
  • Se tentar executar um procedimento armazenado como um evento de idioma em vez de como um RPC, SQL Server deve analisar e compilar a consulta de evento de idioma, determinar que a consulta está a tentar executar o procedimento específico e, em seguida, tente localizar um plano na cache para esse procedimento. 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. Para mais informações, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:
    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

Propriedades

Artigo: 263889 - Última revisão: 24 de novembro de 2010 - Revisão: 1.0
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • 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
Palavras-chave: 
kbinfo kbmt KB263889 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática? erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 263889

Submeter comentários

 

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