Melhorar o Desempenho Geral de Replicação

Aplica-se a: SQL ServerAzure SQL Managed Instance

Pode melhorar o desempenho geral para todos os tipos de replicação na sua aplicação e na sua rede utilizando as diretrizes descritas neste tópico.

Servidor e Rede

  • Defina a quantidade mínima e máxima de memória alocada ao Microsoft SQL Server Database Engine.

    Por defeito, o Database Engine altera os 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 de memória mínima do servidor para definir a memória mínima disponível. Para evitar que a página do sistema operativo fique em disco para memória, também podes definir uma quantidade máxima de memória com a opção de memória máxima do servidor . Para mais informações, consulte Opções de Configuração do Server Memory Server.

  • Garantir a correta alocação dos ficheiros de dados da base de dados e dos ficheiros de registo. Use uma unidade de disco separada para o registo de transações de todas as bases de dados envolvidas na replicação.

    Pode diminuir o tempo que demora a escrever transações armazenando os ficheiros de registo num disco diferente daquele usado para armazenar a base de dados. Pode espelhar essa unidade com RAID 1 (matriz redundante de discos independentes), caso necessite de tolerância a falhas. Use RAID 0 ou 0+1 (dependendo da sua necessidade de tolerância a falhas) para outros ficheiros de base de dados. Esta é uma boa prática, independentemente de a replicação estar a ser usada ou não.

  • Considere adicionar memória aos servidores usados na replicação, particularmente ao Distribuidor.

  • Usa computadores multiprocessador.

    Os agentes de replicação podem tirar partido de processadores adicionais no servidor. Se estiveres a usar CPU de forma elevada, considera instalar um CPU mais rápido ou vários CPUs.

  • Usa uma rede rápida.

    A rede pode ser um gargalo significativo de desempenho, especialmente para replicação transacional. A propagação das alterações para os Assinantes pode ser significativamente melhorada utilizando uma rede rápida de 100 megabits por segundo (Mbps) ou mais. Se a rede for lenta, especifique as definições de rede e os parâmetros do agente apropriados.

Estrutura da Base de Dados

  • Siga as melhores práticas para o design de bases de dados.

    Uma base de dados replicada geralmente beneficia das mesmas otimizações de desempenho que uma base de dados não replicada. No entanto, os índices devem ser utilizados com cautela no Subscrevente: a coluna de chave primária no Subscrevente deve ter um índice, mas índices adicionais podem afetar o desempenho das operações de inserção, atualização e eliminação.

  • Considere definir a opção READ_COMMITTED_SNAPSHOT da base de dados.

    Para ajudar a reduzir a contenda entre a atividade do utilizador e a atividade do agente de replicação, defina esta opção para as bases de dados de publicação e subscrição:

    ALTER DATABASE AdventureWorks  
SET READ_COMMITTED_SNAPSHOT ON

    Para mais informações, vejaALTER DATABASE (Transact-SQL).

  • Tenha cuidado com a lógica da aplicação nos acionadores.

    A lógica de negócio presente em disparadores definidos pelo utilizador no Assinante pode atrasar a replicação de alterações para o Assinante:

    Se usar gatilhos para manter a integridade referencial em tabelas publicadas para replicação de fusões, especifique a ordem de processamento das tabelas para reduzir o número de tentativas necessárias para o Merge Agent. Para mais informações, consulte Especificar opções de replicação de fusão.

  • Limitar o uso de tipos de dados de Objetos Grandes (LOB).

    Os LOBs requerem mais espaço de armazenamento e processamento do que outros tipos de dados de coluna. Não inclua estas colunas nos artigos, a menos que seja necessário para a sua candidatura. Os tipos de dados text, ntext e image estão obsoletos. Se incluir LOBs, recomendamos que use os tipos de dados varchar(max), nvarchar(max), varbinary(max), respetivamente.

    Para a replicação transacional, considere utilizar o perfil do Distribution Agent denominado Distribution Profile para transmissão em fluxo OLE DB. Para mais informações, consulte Perfis de Agentes de Replicação.

Design da Publicação

  • Publique apenas os dados necessários.

    Como a replicação é fácil de configurar, existe uma tendência para publicar mais dados do que o realmente necessário. Isto pode consumir recursos adicionais nas bases de dados de distribuição e nos ficheiros de instantâneo, e 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.

  • Minimizar conflitos através do design da publicação e do comportamento da aplicação.

    Os seguintes tipos de replicação permitem alterar dados nos Assinantes: replicação por fusão, replicação transacional com subscrições atualizáveis e replicação transacional peer-to-peer. A replicação de fusão e a replicação transacional com subscrições atualizáveis suportam a ocorrência de conflitos de dados se uma determinada linha for atualizada em mais de um nó entre sincronizações. A replicação peer-to-peer não suporta conflitos de dados; As alterações nos dados devem ser particionadas. Independentemente do tipo de replicação utilizado, recomendamos que particione as alterações sempre que possível, pois isso reduz o processamento necessário para a deteção e resolução de conflitos.

    As alterações podem ser particionadas publicando subconjuntos de dados para cada Subscritor ou fazendo com que uma aplicação encaminhe as alterações relativas a uma determinada linha para um determinado nó:

    • A replicação por fusão suporta a publicação de subconjuntos de dados usando filtros parametrizados com uma única publicação. Para obter mais informações, consulte Filtros de linha parametrizados.

    • A replicação transacional suporta a publicação de subconjuntos de dados usando filtros estáticos com múltiplas publicações. Para mais informações, consulte Filtrar Dados Publicados.

  • Use filtros de linha com critério.

    Quando uma publicação transacional inclui um ou mais artigos que utilizam filtros de linhas, o Agente Leitor de Registo deve aplicar o filtro a cada linha afetada por uma atualização da tabela enquanto analisa o registo de transações. O rendimento do Agente Leitor de Registo é, portanto, afetado.

    De forma semelhante, a replicação de fusão deve avaliar as linhas alteradas ou eliminadas para determinar quais os Assinantes que devem receber essas linhas. Quando são usados filtros de linhas para reduzir os dados necessários num Assinante, este processamento é mais complexo e pode ser mais lento do que quando se publicam todas as linhas numa tabela. Considere cuidadosamente o compromisso entre a redução dos requisitos de armazenamento em cada Assinante e a necessidade de alcançar o máximo rendimento. Para mais informações sobre filtragem, consulte Filtrar Dados Publicados.

Considerações de Subscrição

  • Utilize subscrições de pull quando houver um grande número de Subscritores.

    O Distribution Agent e o Merge Agent funcionam no Distribuidor para subscrições push, e nos Subscritores para subscrições pull. A utilização de subscrições pull pode melhorar o desempenho, transferindo o processamento do agente do Distribuidor para os Subscritores. Para mais informações, consulte Subscrever Publicações.

  • Considere a reinicialização da subscrição se os Subscritores estiverem demasiado atrasados.

    Quando é necessário enviar grandes quantidades de alterações aos Assinantes, reinicializá-las com um novo snapshot pode ser mais rápido do que usar a replicação para mover as alterações individuais. Para mais informações, consulte Reinicializar Subscrições.

    Para replicação transacional, o Monitor de Replicação apresenta no separador Comandos Não Distribuídos informações sobre: o número de transações na base de dados de distribuição que ainda não foram distribuídas a um Assinante; e o tempo estimado para a distribuição dessas transações. Para obter mais informações, consulte Visualizar informações e executar tarefas usando o Replication Monitor.

Considerações sobre instantâneos

  • Execute o Snapshot Agent apenas quando necessário e em horários de menor afluência.

    O Snapshot Agent copia em massa dados da tabela publicada no Publisher para um ficheiro na pasta de snapshots do Distribuidor. Gerar um snapshot pode ser um processo que exige muitos recursos e é melhor agendado durante os períodos de menor afluência.

  • Use um snapshot em modo nativo, a menos que seja necessário um snapshot em modo de personagem.

    Utilize o instantâneo predefinido em modo nativo para todos os Assinantes, exceto os Assinantes que não sejam do SQL Server e os Assinantes que executem o SQL Server Compact, que requerem um instantâneo em modo de caracteres.

  • Use uma única pasta de snapshots para uma publicação.

    Ao especificar as propriedades de publicação relacionadas com a localização do snapshot, pode optar por gerar ficheiros de snapshot para a pasta de snapshots predefinida, para uma pasta de snapshot alternativa, ou para ambas. Gerar ficheiros snapshot em ambos os locais requer espaço adicional em disco e mais processamento quando o Snapshot Agent é executado.

  • Coloque a pasta snapshot num disco local do Distribuidor que não seja usado para armazenar ficheiros de base de dados ou log.

    O Snapshot Agent realiza uma escrita sequencial de dados na pasta snapshot. Colocar a pasta snapshot num disco separado de qualquer base de dados ou ficheiros de registo reduz a contenção entre os discos e ajuda a completar o processo snapshot mais rapidamente.

  • Ao criar a base de dados da subscrição no Assinante, considere especificar um modelo de recuperação simples ou de registo em massa. Isto permite um registo mínimo das inserções em bloco efetuadas durante a aplicação do snapshot no Subscritor. Depois de o snapshot ter sido aplicado à base de dados de subscrição, pode mudar para um modelo de recuperação diferente se necessário (bases de dados replicadas podem usar qualquer um dos modelos de recuperação). Para mais informações sobre a seleção de um modelo de recuperação, consulte Visão Geral de Restauração e Recuperação (SQL Server).

  • Considere usar a pasta alternativa de snapshots e snapshots comprimidos em suportes removíveis para redes de baixa largura de banda.

    Comprimir os ficheiros de instantâneo na pasta alternativa de instantâneos pode reduzir as necessidades de armazenamento em disco dos instantâneos e facilitar a transferência dos ficheiros de instantâneo em suportes amovíveis.

    Snapshots comprimidos podem, em alguns casos, melhorar o desempenho da transferência de ficheiros de snapshot através da rede. No entanto, comprimir o snapshot requer processamento adicional pelo Snapshot Agent ao gerar os ficheiros snapshot, e pelo Distribution Agent ou Merge Agent ao aplicar os ficheiros snapshot. Isto pode atrasar a geração de snapshots e aumentar o tempo que demora a aplicar um snapshot em alguns casos. Além disso, snapshots comprimidos não podem ser retomados se ocorrer uma falha de rede; por isso, não são adequados para redes pouco fiáveis. Considere cuidadosamente estas compensações ao utilizar snapshots comprimidos através de uma rede. Para mais informações, consulte Modificar opções de instantâneo.

  • Considere iniciar uma subscrição manualmente.

    Em alguns cenários, como aqueles que envolvem grandes conjuntos de dados iniciais, é preferível inicializar uma subscrição usando um método diferente de um snapshot. Para obter mais informações, consulte Inicializar uma subscrição transacional sem instantâneo.

Parâmetros do Agente

  • Reduzir os níveis de verbosidade dos agentes de replicação, exceto durante os testes iniciais, a monitorização ou a depuração.

    Reduza o parâmetro –HistoryVerboseLevel e o parâmetro –OutputVerboseLevel dos Agentes de Distribuição ou Agentes de Fusão. Isto reduz o número de novas linhas inseridas para registar o histórico e a saída do agente. Em vez disso, mensagens de histórico anteriores com o mesmo estado são atualizadas para a nova informação de histórico. Aumente os níveis de detalhe para testes, monitorização e depuração para ter o máximo de informação possível sobre a atividade dos agentes.

  • Use o parâmetro –MaxBCPThreads do Snapshot Agent, Merge Agent e Distribution Agent (o número de threads especificados não deve exceder o número de processadores no computador). Este parâmetro especifica o número de operações de cópia em massa que podem ser realizadas em paralelo quando o snapshot é criado e aplicado.

  • Use o parâmetro –UseInprocLoader do Distribution Agent e do Merge Agent (este parâmetro não pode ser usado se as tabelas publicadas incluírem colunas XML). Este parâmetro faz com que o agente use o BULK INSERT comando quando o snapshot é aplicado.

Os parâmetros do agente podem ser especificados nos perfis do agente e na linha de comando. Para obter mais informações, consulte:

  • Last updated on