Aprimorar o desempenho geral da replicação

Aplica-se a:SQL ServerInstância Gerenciada de SQL do Azure

É possível melhorar o desempenho geral para todos os tipos de replicação no seu aplicativo e na rede, por meio das diretrizes descritas neste tópico.

Servidor e rede

  • Defina a quantidade mínima e máxima de memória alocada para o Mecanismo de Banco de Dados do Microsoft SQL Server.

    Por padrão, o Mecanismo de Banco de Dados altera seus requisitos de memória dinamicamente com base nos recursos disponíveis do sistema. Para evitar baixa disponibilidade de memória durante as atividades de replicação, use a opção min server memory para definir a mínima memória disponível. Para evitar que o sistema operacional busque memória no disco, você também pode definir a quantidade máxima de memória com a opção max server memory . Para mais informações, consulte Opções de configuração de memória do servidor.

  • Assegure alocação adequada de arquivos de dados de banco de dados e arquivos de log. Use uma unidade de disco separada para o log de transação para todos os bancos de dados envolvidos na replicação.

    É possível diminuir o tempo de gravação das transações armazenando os arquivos de log em uma unidade de disco diferente da usada para armazenar o banco de dados. É possível espelhar aquela unidade, usando um RAID (Arranjo Redundante de Discos Baratos)-1, se for necessária tolerância a falhas. Use RAID 0 ou 0+1 (dependendo de sua necessidade por tolerância a falhas) para outros arquivos de banco de dados. Essa é uma prática boa que independe do uso da replicação.

  • Considere a adição de memória a servidores usados na replicação, particularmente o Distribuidor.

  • Use computadores com multiprocessadores.

    Os agentes de replicação podem tirar proveito de processadores adicionais no servidor. Se estiver trabalhando com alto uso de CPU, considere a instalação de uma CPU mais rápida ou de várias CPUs.

  • Use uma rede rápida.

    A rede pode ser um gargalo de desempenho significante, particularmente para replicação transacional. A propagação de alterações aos Assinantes pode ser melhorada significantemente por meio de uma rede rápida de 100 megabits por segundo (Mbs) ou mais rápida. Se a rede for lenta, especifique configurações de rede e parâmetros de agente apropriados.

Design de banco de dados

  • Siga as práticas recomendadas para design de banco de dados.

    Um banco de dados replicado geralmente se beneficia das mesmas otimizações de desempenho que um banco de dados não replicado. Entretanto, os índices devem ser usados com cautela no Assinante: a coluna de chave primária no Assinante deve ser indexada, mas índices adicionais podem afetar o desempenho das operações de inserção, atualização e exclusão.

  • Considere definir a opção do banco de dados READ_COMMITTED_SNAPSHOT.

    Para ajudar a reduzir a contenção entre a atividade do usuário e a atividade do agente de replicação, defina essa opção para os bancos de dados de publicação e assinatura:

    ALTER DATABASE AdventureWorks  
SET READ_COMMITTED_SNAPSHOT ON

    Para obter mais informações, consulte ALTER DATABASE (Transact-SQL).

  • Seja cauteloso com a lógica do aplicativo nos gatilhos.

    A lógica corporativa nos gatilhos definidos pelo usuário no Assinante pode reduzir a velocidade da replicação de alterações no Assinante:

    Se você usar gatilhos para manter a integridade referencial em tabelas publicadas para replicação de mesclagem, especifique a ordem de processamento das tabelas para reduzir o número de novas tentativas necessárias para o Agente de Mesclagem. Para obter mais informações, consulte Especificar opções de replicação de mesclagem.

  • Limite o uso de tipos de dados LOB (objetos grandes).

    Os LOBs requerem mais espaço de armazenamento e processamento que outros tipos de dados de coluna. Não inclua essas colunas em artigos a menos que seja necessário para seu aplicativo. Os tipos de dados text, ntexte image são preteridos. Se você incluir LOBs, recomendamos que use os tipos de dados varchar(max), nvarchar(max) e varbinary(max), respectivamente.

    Para replicação transacional, considere usar o perfil do Agente de Distribuição chamado Perfil de Distribuição para streaming OLE DB. Para saber mais, confira Replication Agent Profiles.

Design de publicação

  • Publique somente os dados requeridos.

    Porque a replicação é fácil de configurar, há uma tendência para publicar mais dados do que é, de fato, necessário. Isso pode consumir recursos adicionais nos bancos de dados de distribuição e nos arquivos de instantâneo, e pode reduzir a taxa de transferência dos dados necessários. Evite publicar tabelas desnecessárias e considere atualizar as publicações com menos frequência.

  • Minimize conflitos por design de publicação e comportamento de aplicativo.

    Os seguintes tipos de replicação permitem que os dados sejam alterados nos Assinantes: replicação por mesclagem, replicação transacional com assinaturas atualizáveis e replicação transacional peer-to-peer. A replicação de mesclagem e a replicação transacional com assinaturas atualizáveis oferecem suporte a conflitos de dados, se uma dada linha for atualizada em um ou mais nós entre sincronizações. A replicação ponto a ponto não oferece suporte a conflitos de dados; as alterações de dados devem ser particionadas. Independentemente do tipo de replicação utilizado, recomendamos que você particione as alterações sempre que possível, pois isso reduz o processamento necessário para a detecção e a resolução de conflitos.

    As alterações podem ser particionadas por meio da publicação de subconjuntos de dados para cada Assinante ou fazendo com que um aplicativo direcione as alterações de uma determinada linha para um determinado nó:

    • A replicação de mesclagem oferece suporte à publicação de subconjuntos de dados usando filtros parametrizados por meio de uma única publicação. Para obter mais informações, consulte Filtros de linha com parâmetros.

    • A replicação transacional oferece suporte à publicação de subconjuntos de dados que usam filtros estáticos com publicações múltiplas. Para obter mais informações, consulte Filter Published Data (Filtrar dados publicados).

  • Use filtros de linha criteriosamente.

    Quando uma publicação transacional inclui um ou mais artigos que usam filtros de linha, o Log Reader Agent deve aplicar o filtro a cada linha afetada por uma atualização à tabela enquanto verifica o log de transações. Consequentemente, o desempenho do Log Reader Agent é afetado.

    De forma semelhante, a replicação de mesclagem deve avaliar as linhas alteradas ou excluídas para determinar quais Assinantes devem receber essas linhas. Quando filtros de linha são empregados para reduzir os dados necessários para um Assinante, esse processamento é mais complexo e pode ser mais lento do que quando você publica todas as linhas de uma tabela. Considere cuidadosamente o equilíbrio entre menores requisitos de armazenamento em cada Assinante e a necessidade de atingir a taxa de transferência máxima. Para mais informações sobre filtragem, consulte Filtrar dados publicados.

Considerações sobre assinatura

  • Use assinaturas de pull quando houver um grande número de Assinantes.

    O Agente de Distribuição e o Agente de Mesclagem são executados no Distribuidor para as assinaturas push e nos Assinantes para as assinaturas pull. O uso de assinaturas pull pode melhorar o desempenho ao mover o processamento do agente do Distribuidor para os Assinantes. Para obter mais informações, consulte Assinar publicações.

  • Considere reinicializar a assinatura se os assinantes estiverem muito atrasados.

    Quando grandes quantidades de alterações precisarem ser enviadas aos Assinantes, reinicializá-los com um novo instantâneo pode ser mais rápido do que usar a replicação para transferir as alterações individualmente. Para obter mais informações, consulte Reinicializar as assinaturas.

    Para replicação transacional, o Replication Monitor exibe na guia Comandos Não Distribuídos as informações sobre: o número de transações no banco de dados de distribuição que ainda não foi distribuídas ao Assinante e o tempo estimado para distribuir essas transações. Saiba mais em Exibir informações e executar tarefas usando o Replication Monitor.

Considerações sobre snapshots

  • Execute o Agente de Instantâneo apenas quando necessário e em períodos de pouca atividade.

    O Agente de Instantâneo copia os dados em massa da tabela publicada no Publisher para um arquivo na pasta de instantâneos no Distributor. Gerar um instantâneo pode ser um processo que consome muitos recursos, e é melhor programá-lo para horários fora de pico.

  • Use uma captura de modo nativo, a menos que uma captura de modo de caractere seja necessária.

    Use o instantâneo do modo nativo padrão para todos os Assinantes, exceto os Assinantes que não usam SQL Server e os Assinantes que executam o SQL Server Compact, que exigem um instantâneo do modo caractere.

  • Use uma única pasta de instantâneos para uma publicação.

    Ao especificar as propriedades da publicação relacionadas com o local do instantâneo, é possível escolher gerar os arquivos de instantâneo na pasta de instantâneo padrão, em uma pasta alternativa de instantâneo ou em ambos. Gerar arquivos de instantâneo em ambos os locais requer espaço em disco adicional e mais processamento durante a execução do Agente de Instantâneo.

  • Coloque a pasta de instantâneos em uma unidade local do Distribuidor que não seja usada para armazenar arquivos de banco de dados ou arquivos de log.

    O Agente de Instantâneo grava os dados sequencialmente na pasta de snapshot. Colocar a pasta de instantâneo em uma unidade separada daquela em que estejam os arquivos de banco de dados ou de log reduz a contenção de disco e ajuda o processo de criação do instantâneo a ser concluído mais rapidamente.

  • Ao criar o banco de dados de assinatura no Assinante, considere especificar um modelo de recuperação de registros simples ou com log de operações em massa. Isso permite o registro mínimo das inserções em massa realizadas durante a aplicação do instantâneo no Assinante. Após o instantâneo ter sido aplicado ao banco de dados de assinatura, é possível mudar para um modelo diferente de recuperação, se necessário (os bancos de dados replicados podem usar qualquer um dos modelos de recuperação). Para mais informações sobre como selecionar um modelo de recuperação, consulte Visão geral da recuperação e da restauração (SQL Server).

  • Considere usar a pasta de instantâneo alternativo e instantâneos compactados em mídia removíveis para redes que não sejam de banda larga.

    Os arquivos de instantâneo compactados na pasta de instantâneo alternativo podem reduzir os requisitos de armazenamento em disco, e facilitar a transferência de arquivos de instantâneo em mídia removível.

    Os instantâneos compactados podem, em alguns casos, melhorar o desempenho da transferência de arquivos de instantâneo pela rede. No entanto, a compactação do instantâneo requer processamento adicional pelo Agente de Instantâneo ao gerar os arquivos de instantâneo e pelo Agente de Distribuição ou Agente de Mesclagem ao aplicar os arquivos de instantâneo. Isso pode retardar a geração de instantâneos e, em alguns casos, aumentar o tempo necessário para aplicar um instantâneo. Além disso, instantâneos compactados não podem ser retomados no caso de uma falha de rede; consequentemente, não são apropriados para redes não confiáveis. Considere cuidadosamente essas compensações ao usar snapshots compactados em uma rede. Para obter mais informações, consulte Modificar as opções do snapshot.

  • Considere inicializar uma assinatura manualmente.

    Em alguns cenários, como aqueles que envolvem grandes conjuntos de dados iniciais, é preferível inicializar uma assinatura por meio de um método diferente de um snapshot. Para obter mais informações, consulte Inicializar uma assinatura transacional sem snapshot.

Parâmetros de agente

  • Reduza os níveis de detalhamento dos agentes de replicação, exceto durante o teste inicial, o monitoramento ou a depuração.

    Reduza os parâmetros –HistoryVerboseLevel e –OutputVerboseLevel dos Agentes de Distribuição ou dos Agentes de Mesclagem. Isso reduz o número de novas linhas inseridas para rastrear o histórico do agente e as saídas. Em vez disso, as mensagens de histórico anteriores com o mesmo status são atualizadas para as novas informações de histórico. Aumente os níveis detalhados de teste, monitoração e depuração, de forma a obter o máximo possível de informações sobre a atividade do agente.

  • Use o parâmetro –MaxBCPThreads do Agente de Instantâneo, Agente de Mesclagem e Agente de Distribuição (o número de threads especificado não deve exceder o número de processadores no computador). Esse parâmetro especifica o número de operações de cópia em massa que podem ser executadas em paralelo quando o instantâneo é criado e aplicado.

  • Use o parâmetro –UseInprocLoader do Agente de Distribuição e do Agente de Mesclagem (esse parâmetro não pode ser usado se as tabelas publicadas incluírem colunas XML). Esse parâmetro faz o agente usar o comando BULK INSERT quando o instantâneo é aplicado.

Os parâmetros de agente podem ser especificados em perfis de agente e na linha de comando. Para saber mais, veja:

  • Last updated on