E / S de disco tempdb alta durante a replicação de mesclagem de BLOBs

Tendo uma publicação de mesclagem para replicar BLOBs (tipo image), obtive E / S de disco tempdb muito alta para meu tamanho de dados. A publicação é apenas para download e não possui filtros.

A E / S de disco alta é causada pela sincronização (quando nenhum assinante está sincronizando, tudo está ok), fortemente correlacionado com o número de assinantes. Isso acontece mesmo quando nenhum dado é alterado no Publisher entre as sincronizações, e isso me incomoda.

• Tamanho da tabela replicada: 7 MB (a contagem total de linhas é de cerca de 100)
• E / S tempdb: ~ 30 MB / s para gravação (arquivos de log e dados)
• Número de assinantes: pouco mais de 100, cada um sincronizando a cada 30 minutos (mais ou menos uniformemente).
• Período de retenção definido para 14 dias

Usando o SQL Server 2008 no Publisher, o SQL Server 2005-2008R2 nos Assinantes. Todos os assinantes usam a sincronização da Web.

Além disso, a sincronização no assinante leva muito tempo, com várias ocorrências replmerg.logcomo estas:

DatabaseReconciler, 2015/04/21 12:13:40.348, 3604, 25088,  S2,  
INFO: [WEBSYNC_PROTOCOL]  
Sending client ReconcilerPhase WebSyncReconcilerPhase_RegularDownload     

DatabaseReconciler, 2015/04/21 12:13:47.063, 3604, 25194,  S2,  
INFO: [WEBSYNC_PROTOCOL]  
Received server ReconcilerPhase WebSyncReconcilerPhase_LastRegularDownload

Tentei @stream_blob_columnsligar e desligar sem efeito.

A pergunta é: É uma boa idéia usar a replicação de mesclagem para enviar esses blobs aos assinantes? Temos outras publicações (embora elas não tenham colunas BLOB) com muitos dados sem problemas com o tempdb. É uma falha do SQL Server ou uma instalação incorreta?

O Publisher e o Distribuidor estão na mesma instância, o SQL Server 2008 SP4, não podem ter certeza sobre os Assinantes, alguns deles talvez não estejam atualizados. De qualquer forma, posso preparar um ambiente de teste com poucos assinantes com versões controladas, se isso ajudar.

Confirmado, o uso excessivo de tempdb causado pela execução de sys.sp_MSenumgenerations90. MSMerge_genhistoryTabela marcada , encontrada mais de 1,2 milhões de registros onde pubidé nulo.

Encontrou esta conversa com o guru de replicação:

Executado sp_mergemetadataretentioncleanupsem efeito.

Foi encontrada uma observação em um caso como este (excesso de linhas MSmerge_genhistory) onde a exclusão de linhas onde pubidé nulo e genstatus= 1 ajudou a corrigir a replicação.

As linhas excluídas pubidsão nulas (o que implica que todos os Assinantes estão sincronizados e os que não são - serão reinicializados no "modo manual") e as E / S de disco voltam ao normal novamente!

Sinto que essa situação pode ser causada pelo fato de que todos os meus assinantes são anônimos via WebSync e a maioria deles tem o mesmo nome de host. Vou tentar verificar se a -hostnamechave ajuda a não multiplicar os registros MSmerge_genhistory.

Há um blog do TechNet que discute alguns problemas de replicação de mesclagem com blobs em um servidor SQL Server 2008 ou superior.

http://blogs.technet.com/b/claudia_silva/archive/2011/10/31/replication-watch-out-for-stream-blob-columns-when-setting-up-replication-on-your-sql- 2008-server.aspx

Observe que o autor adverte sobre quais configurações usar quando houver clientes do SQL Server 2005, como você.

Eu tive um problema semelhante com um servidor de clientes cuja causa não pôde ser resolvida. A alta quantidade de IO diminuiu a velocidade do armazenamento e afetou vários sistemas. Não posso fornecer uma solução para resolver a causa em si, mas pode ser uma opção (temporária) que resolve o problema resultante e oferece mais tempo para identificar e solucionar a causa.

Resolvemos o problema de IO enquanto movíamos o tempdb para um ramdisk. No nosso caso, tivemos que agir rapidamente, pois outros sistemas ficaram temporariamente sem resposta devido a problemas de desempenho. Em vez de alterar a configuração do servidor, copiamos os arquivos tempdb para o ramdisk, criamos um backup dos arquivos originais e os substituímos por links simbólicos. O ramdisk carrega uma imagem que contém os arquivos tempdb. Os serviços sql foram atrasados ​​para garantir que o ramdisk tenha iniciado e carregado a imagem antes do início do serviço sql. O tempo de inatividade efetivo para alternar do disco para o ram levou menos de um minuto.

No nosso caso, melhoramos bastante o desempenho e resolvemos o problema com o armazenamento. A solução funciona muito bem para o nosso cliente e, no final, tornou-se uma solução permanente.

Brent é definir por que precisamos aumentar o arquivo de dados tempDb. Você pode consultar o link abaixo

https://www.brentozar.com/blitz/tempdb-data-files/