Início / dba / Perguntas / 482
Accepted
BradC
Asked: 2011-01-11 12:48:48 +0800 CST

Como posso saber POR QUE uma inserção em uma determinada tabela é lenta?

  • 772

Eu sei que um INSERT em uma tabela SQL pode ser lento por vários motivos:

  • Existência de INSERT TRIGGERs na mesa
  • Muitas restrições impostas que precisam ser verificadas (geralmente chaves estrangeiras)
  • A página é dividida no índice clusterizado quando uma linha é inserida no meio da tabela
  • Atualizando todos os índices não clusterizados relacionados
  • Bloqueio de outras atividades na mesa
  • Tempo de resposta de gravação de E/S ruim
  • ... alguma coisa que eu perdi?

Como posso saber qual é o responsável no meu caso específico? Como posso medir o impacto das divisões de página em relação às atualizações de índice não clusterizadas em relação a todo o resto?

Eu tenho um proc armazenado que insere cerca de 10.000 linhas por vez (de uma tabela temporária), o que leva cerca de 90 segundos por 10 mil linhas. Isso é inaceitavelmente lento, pois faz com que outros spids expirem.

Examinei o plano de execução e vejo a tarefa INSERT CLUSTERED INDEX e todas as INDEX SEEKS das pesquisas FK, mas ainda não me diz com certeza por que demora tanto. Nenhum gatilho, mas a tabela tem um punhado de FKeys (que parecem estar indexadas corretamente).

Este é um banco de dados SQL 2000.

sql-server insert

5 respostas

  1. Best Answer

    Algumas coisas que você pode ver...

    Reduza o tamanho do lote de 10.000 para algo menor, como 2.000 ou 1.000 (você não disse o tamanho da linha).

    Tente ativar o IO Stats para ver a quantidade de IO que as pesquisas FK estão recebendo.

    Qual é a espera causada quando a inserção está acontecendo (master.dbo.sysprocesses)?

    Vamos começar aqui e ver para onde vamos.

    • 11

  2. Brad,

    Você deve examinar as estatísticas de espera para sua consulta. Com o SQL2000, você pode usar a sintaxe DBCC SQLPERF("waitstats") para obter esses detalhes.

    • 7

  3. Posso dizer o que estou procurando ao analisar o desempenho de uma consulta. Talvez ajude.

    • analise o plano de execução da consulta e verifique se há varreduras de índice, varreduras de tabela, uso de funções convert_implicit para tipos de dados sql, paralelismo.
    • execute a consulta com SET STATISTICS IO ON e SET STATISTICS TIME ON para ver o tempo de execução e ler/gravar io para cada inserção.
    • confira o tempo de espera de sysprocesses para seu spid de sessão.
    • execute o criador de perfil e selecione o modelo padrão. selecione o seguinte: Estatísticas de desempenho (se repetido, seu plano será compilado muitas vezes - não é bom), RPC:completed, SQL:batchcompleted e SQL:batchstarting. Adicione a eles a contagem de linhas da coluna para ver exatamente o número de linhas no lote. Filtre os resultados para ver apenas sua consulta.
    • finalmente colete o contador de expectativa de vida da página do windows perfmon e se estiver abaixo de 300 (5 min) então o SQL tem pouca memória. Também colete contadores de disco: comprimento da fila de disco , tempo de disco (sua unidade de arquivos de dados), tempo de disco (sua unidade de arquivos de log) para ver se há pressão nos discos.
    • 6

  4. Tente usar:

    SET STATISTICS IO ON

    e

    SET STATISTICS PROFILE ON

    ESTATÍSTICAS IO

    Pode ser útil para informar quais tabelas estão fazendo a maior quantidade de varreduras de tabela, leituras lógicas e leituras físicas (eu uso esses três para focar em qual parte do plano de consulta precisa de mais ajuste)

    PERFIL DE ESTATÍSTICAS

    Retornará principalmente o plano de consulta em um formato tabular, então você pode ver as colunas de E/S e CPU para saber o que está custando mais na consulta (é a verificação da tabela em sua tabela temporária versus a classificação que ela faz para inserir em seu chave agrupada, etc...)

    • 5

  5. Sugestões:

    1. Veja possíveis bloqueios em sua consulta no Activity Monitor
    2. Veja o plano de execução e as estatísticas de IO em sua consulta
    3. Índices e restrições (especialmente para muitos deles, como índices não clusterizados ou FKs) podem afetar o desempenho da inserção.
    4. Manter, mas reconstruir os índices necessários.
    5. Inserir uma linha de cada vez é realmente uma prática ruim com impactos negativos no desempenho, especialmente em bancos de dados ACID como o SQL Server. Faça Inserções em Lote!
    • 0

relate perguntas