none
Insert em tabela com Replicação demorando para realizar Insert/Update RRS feed

  • Pergunta

  • Bom dia!
    Possuo uma base de dados com Replicação merge, até o momento esta funcionando perfeitamente bem.

    Atualmente precisei inserir uma informação em uma tabela de "Configuração", essa tabela raramente é para ser inserido uma nova informação, porém pela aplicação está dando erro de timeout "Utilizando Entity", se executo a query no proprio sql chega a inserir mas a inserção demora cerca de 4 minutos, e somente essa tabela está com esse problema.

    Se puderem analisar o plano de execução e me auxiliar em como posso proceder ficarei muito agradecido.

    Obrigado.


    Uma imagem vale mais do que mil palavras, mas ocupa 3 mil vezes mais espaço em disco

    quinta-feira, 30 de abril de 2015 12:34

Respostas

  • Alexsandro, bom dia.

    Olhando o plano de execução, de cara o comando abaixo me chamou a atenção

      update [dbo].[MSmerge_ctsv_B11FE67C58D54A6CAF3B5DD5844C825B] with (rowlock) set generation = @child_newgen, partchangegen = @child_newgen, marker = @child_marker
                    from [dbo].[MSmerge_ctsv_B11FE67C58D54A6CAF3B5DD5844C825B] mc with (rowlock)
                    where mc.tablenick = 175180000 
                    and mc.rowguid in 
                        (select [Produto_Preco].[rowguid] from  
                        inserted [Tabela_Preco_PJ_Grupo], [dbo].[MSmerge_repl_view_090D475C2DA24303B5F4A98BC4EC1FAC_2FA2CB2D473641568B21A343BD11193F] [Produto_Preco] with (rowlock)
                        where ([Tabela_Preco_PJ_Grupo].[Cod_Tabela_Preco] = [Produto_Preco].[Cod_Tabela_Preco]))  

    Ele está fazendo Index Scan na tabela Produto_Preco e isso significa quase 1 milhão de registros. O plano indica a falta de um índice no campo Cod_Tabela_Preco com INCLUDE RowGuid. Isso com certeza já irá tirar boa parte da demora na execução. 

    CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
    ON [produto].[Produto_Preco] ([Cod_Tabela_Preco])
    INCLUDE ([rowguid])
    GO

    Aí você terá que avaliar se deve ou não criar esse índice pesando o bônus que trará para esse caso e o ônus que terá nas operações de insert/update/delete nessa tabela.

    Outra coisa é que provavelmente suas estatísticas estão desatualizadas. Você já checou isso nessa tabela?

    OBS. esse indice ira melhorar as queries que são 99,9% do seu plano (inserts e updates)

    quinta-feira, 30 de abril de 2015 12:56
  • Agora o cenário que o plano de execução mostra é totalmente outro.

    As tabelas do SQL para replicação estão sendo as vilãs.

    Eu nunca trabalhei com performance de ambientes replicados, mas o post abaixo deve te ajudar a entender isso.

    Veja que não estou dizendo que você deve criar os mesmos índices do post nas suas tabelas. Estou apenas sugerindo que você avalie isso: a ausência/fragmentação de índices nas tabelas MSmerge_contents e MSmerge_current_partition_mappings

    http://stackoverflow.com/questions/13009812/inserts-in-merge-replication-database-are-insanely-slow


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    quinta-feira, 30 de abril de 2015 17:44

Todas as Respostas

  • Alexsandro, bom dia.

    Olhando o plano de execução, de cara o comando abaixo me chamou a atenção

      update [dbo].[MSmerge_ctsv_B11FE67C58D54A6CAF3B5DD5844C825B] with (rowlock) set generation = @child_newgen, partchangegen = @child_newgen, marker = @child_marker
                    from [dbo].[MSmerge_ctsv_B11FE67C58D54A6CAF3B5DD5844C825B] mc with (rowlock)
                    where mc.tablenick = 175180000 
                    and mc.rowguid in 
                        (select [Produto_Preco].[rowguid] from  
                        inserted [Tabela_Preco_PJ_Grupo], [dbo].[MSmerge_repl_view_090D475C2DA24303B5F4A98BC4EC1FAC_2FA2CB2D473641568B21A343BD11193F] [Produto_Preco] with (rowlock)
                        where ([Tabela_Preco_PJ_Grupo].[Cod_Tabela_Preco] = [Produto_Preco].[Cod_Tabela_Preco]))  

    Ele está fazendo Index Scan na tabela Produto_Preco e isso significa quase 1 milhão de registros. O plano indica a falta de um índice no campo Cod_Tabela_Preco com INCLUDE RowGuid. Isso com certeza já irá tirar boa parte da demora na execução. 

    CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
    ON [produto].[Produto_Preco] ([Cod_Tabela_Preco])
    INCLUDE ([rowguid])
    GO

    Aí você terá que avaliar se deve ou não criar esse índice pesando o bônus que trará para esse caso e o ônus que terá nas operações de insert/update/delete nessa tabela.

    Outra coisa é que provavelmente suas estatísticas estão desatualizadas. Você já checou isso nessa tabela?

    OBS. esse indice ira melhorar as queries que são 99,9% do seu plano (inserts e updates)

    quinta-feira, 30 de abril de 2015 12:56
  • Olhando na tabela tanto a coluna RowGuid e Cod_Tabela_Preco possui Index na tabela Produto_Preco.

    As staticas estão desatualizada por 2 meses, mas nesse periodo não houve alteração nas tabelas, mas por via das duvidas atualizei, mas continua a dar o erro de timeout.


    Uma imagem vale mais do que mil palavras, mas ocupa 3 mil vezes mais espaço em disco

    quinta-feira, 30 de abril de 2015 13:42
  • Esse índice está desfragmentado?

    Falei das estatísticas porque realmente o número de linhas estimadas está muito abaixo do número de linhas reais no seu plano.
    Após atualizá-las, o plano mudou?


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    quinta-feira, 30 de abril de 2015 13:59
  • Desculpa, o Index que você mencionou foi na tabela Produto_Preco e a mesma não possui esse Indice.

    Após a atualização das Statics, houve uma melhoria, (Atualizei as informações no link anterior).

    Acredito que criando o Index, na tabela de Produto_Preco como você mencionou resolver o problema.

    Mas estou com dúvida se isso afetará no snapshot criado?A Replicação é de Merge e se o nome da tabela tiver em uso ele da um drop, se criar um novo snapshot por essa alteração terei que reinicializar todas os Subscriptions, e por hora é arriscado por ser dia.


    Uma imagem vale mais do que mil palavras, mas ocupa 3 mil vezes mais espaço em disco

    quinta-feira, 30 de abril de 2015 14:37
  • Alexsandro,

    Pelo o que li, a replicação desse novo índice está condicionada as parametrizações da sua replicação.

    O artigo abaixo diz que a propriedade Copy Nonclustered Indexes  deve estar TRUE para que os índices criados no Publisher sejam replicados no Snapshot que vai atualizar o subscriber.

    Dê uma lida que acho que pode te ajudar com a dúvida.

    http://blogs.msdn.com/b/repltalk/archive/2012/04/03/replicating-non-clustered-indexes-improves-subscriber-query-performance.aspx


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    quinta-feira, 30 de abril de 2015 16:24
  • Atualizei o ambiente de homologação para realizar os teste.

    Criei o Indice na Tabela Produto.Produto_Preco, atualizei as Statisticas após essas alterações melhorou o desempenhou dos 4 minutos que estava demorando levou 1 minuto, ainda é um tempo alta para uma inserção, Resolvi realizar a desfragmentação pois ao consultar realmente estava alta, mas após realizar a operação de inserção começou a levar quase 2 minutos para finalizar a inserção. (Deixei no mesmo link o novo plano de execução)

    Na empresa estamos sem DBA atualmente e como gosto de fuçar um pouco em banco de dados, estou tentando me adaptar nesse novo mundo.

    Obrigado pela ajuda.


    Uma imagem vale mais do que mil palavras, mas ocupa 3 mil vezes mais espaço em disco

    quinta-feira, 30 de abril de 2015 17:17
  • Agora o cenário que o plano de execução mostra é totalmente outro.

    As tabelas do SQL para replicação estão sendo as vilãs.

    Eu nunca trabalhei com performance de ambientes replicados, mas o post abaixo deve te ajudar a entender isso.

    Veja que não estou dizendo que você deve criar os mesmos índices do post nas suas tabelas. Estou apenas sugerindo que você avalie isso: a ausência/fragmentação de índices nas tabelas MSmerge_contents e MSmerge_current_partition_mappings

    http://stackoverflow.com/questions/13009812/inserts-in-merge-replication-database-are-insanely-slow


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    quinta-feira, 30 de abril de 2015 17:44
  • Outros links que podem te ajudar... em relação a criação de índices nessas tabelas e REBUILD dos indices existentes..

    https://technet.microsoft.com/en-us/library/aa237440(v=sql.80).aspx

    http://blogs.technet.com/b/claudia_silva/archive/2011/08/08/replication-merge-performance-tip.aspx

    http://www.digitalenginesoftware.com/blog/archives/65-Very-Slow-Data-Repartitioning-in-SQL-Server-Replication-with-Precomputed-Partitions.html


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    quinta-feira, 30 de abril de 2015 17:51
  • Após algumas analise foi criado o Indice a qual foi mencionado, e a reorganização de Indice de algumas tabelas, os comando para manutenção da tabela com problema foi solucionado.

    Obrigado pela ajuda.


    Uma imagem vale mais do que mil palavras, mas ocupa 3 mil vezes mais espaço em disco

    sexta-feira, 1 de maio de 2015 11:44