Início / dba / Perguntas / 40459
Accepted
Paul Williams
Asked: 2013-04-20 07:43:40 +0800 CST

LATCH_EX espera no recurso METADATA_SEQUENCE_GENERATOR

  • 772

Temos um processo que gera um relatório de inventário. No lado do cliente, o processo se divide em um número configurável de threads de trabalho para criar um bloco de dados para o relatório que corresponde a um armazenamento entre muitos (potencialmente milhares, geralmente dezenas). Cada thread de trabalho chama um serviço da Web que executa um procedimento armazenado.

O processo de banco de dados para processar cada bloco reúne um monte de dados em uma tabela #Temporary. No final de cada bloco de processamento, os dados são gravados em uma tabela permanente em tempdb. Por fim, ao final do processo, um thread do lado do cliente solicita todos os dados da tabela tempdb permanente.

Quanto mais usuários executam esse relatório, mais lento ele fica. Analisei a atividade no banco de dados. A certa altura, vi 35 solicitações separadas, todas bloqueadas em um ponto do processo. Todos esses SPIDs tiveram esperas da ordem de 50 ms do tipo LATCH_EXno recurso METADATA_SEQUENCE_GENERATOR (00000010E13CA1A8). Um SPID tem esse recurso e todos os outros estão bloqueando. Não encontrei nada sobre esse recurso de espera em uma pesquisa na web.

A tabela em tempdb que estamos usando tem uma IDENTITY(1,1)coluna. Esses SPIDs estão aguardando a coluna IDENTITY? Que métodos poderíamos usar para reduzir ou eliminar o bloqueio?

O servidor faz parte de um cluster. O servidor está executando o SQL Server 2012 Standard Edition SP1 de 64 bits no Windows 2008 R2 Enterprise de 64 bits. O servidor tem 64 GB de RAM e 48 processadores, mas o banco de dados só pode usar 16 por ser a edição padrão.

(Observe que não estou entusiasmado com o design de usar uma tabela permanente em tempdb para armazenar todos esses dados. Mudar isso seria um desafio técnico e político interessante, mas estou aberto a sugestões.)

ATUALIZAÇÃO 23/04/2013

Abrimos um caso de suporte com a Microsoft. Manterei esta pergunta atualizada à medida que aprendermos mais.

ATUALIZAÇÃO 10/05/2013

O engenheiro de suporte do SQL Server concordou que as esperas foram causadas pela coluna IDENTITY. A remoção da IDENTIDADE eliminou as esperas. Não foi possível duplicar o problema no SQL 2008 R2; ocorreu apenas no SQL 2012.

sql-server sql-server-2012

2 respostas

  1. (Atualizado em fevereiro de 2019)

    Este é um post antigo, que dizia que finalmente consegui convencer a Microsoft de que o próprio fato de isso acontecer é realmente um defeito.

    Atualização: MS confirmou o defeito e atribuiu a ele um número de bug de 12628722.

    Eu tinha visto esta postagem em novembro de 2018, quando começamos a sofrer da mesma forma depois de atualizarmos do Sql Server 2005 para o Sql Server 2017. Uma tabela de 3,3 milhões de linhas que costumava levar 10 segundos para inserir em massa de repente começou a levar 10 minutos em tabelas com Identitycolunas.

    Acontece que há dois problemas por trás disso:

    1. A Microsoft alterou o comportamento no Sql Server 2014 para forçar as inserções em massa a serem executadas em paralelo - nas versões anteriores, as inserções em massa recebiam um plano serializado.
    2. Depois de rodar em paralelo em nossa caixa de 32 núcleos, o mecanismo passou mais tempo com os núcleos travando um ao outro do que realmente fazendo o trabalho.

    Levei 4 semanas, mas logo após as férias recebi um presente atrasado do Papai Noel - a confirmação de que o problema era realmente um defeito.

    Existem algumas soluções possíveis que encontramos até que isso seja corrigido:

    1. Use Option (MaxDop 1)na consulta para transformar a inserção em massa de volta em um plano serializado.
    2. Mascare a coluna Identity lançando-a (por exemplo, Select Cast(MyIdentityColumn As Integer) As MyIdentityColumn)
      • isso evita que a propriedade de identidade seja copiada ao usarSELECT...INTO
    3. Remova a coluna de identidade conforme descrito acima.
    4. Altere o modo de compatibilidade do banco de dados para Sql Server 2012 ou inferior para restabelecer um plano serializado.

    Atualização: a correção que a MS implementará será retornar esses tipos de inserções de volta ao uso de um Serialized plano. Isso está planejado para o Sql Server 2017 CU14 (sem novidades em outras versões do Sql Server - desculpe!). Quando implementado, o Trace Flag 9492 precisará ser ativado, no nível do servidor ou via DBCC TraceOn .

    • 7
  2. Best Answer

    Supondo que você possa isolar o problema para a geração de valores de identidade (tente remover essa coluna como teste), o que eu recomendaria é o seguinte:

    1. Remova a IDENTITYpropriedade da coluna na tabela final.
    2. Gere valores de identidade em cada uma das #Tabelas temporárias.
    3. Ao carregar a tabela final, combine um identificador numérico para a loja específica com os valores de identidade da etapa 2.

    Portanto, se você tiver os IDs de loja 3 e 4, acabará com os valores de id finais como este:

    3000000001
3000000002
3000000003
...
4000000001
4000000002
...

    Ou algo parecido com isso. Você entendeu a ideia.

    Isso eliminará a necessidade de serializar na IDENTITYgeração, preservando a exclusividade no resultado final.

    Como alternativa, dependendo de como o processo funciona, insira os valores de id calculados finais nas #Tabelas temporárias. Em seguida, você pode criar uma exibição que UNION ALLos reúna, eliminando a necessidade de copiar os dados.

    • 4

relate perguntas