Quais fatores objetivos indicam que é hora de implementar a replicação do SQL Server?

Estou tentando encontrar um equilíbrio entre o alto desempenho do nosso banco de dados e a facilidade de manutenção. Estamos pensando em usar a replicação para melhorar o desempenho, replicando nossos relatórios do SSRS em um banco de dados fisicamente separado do banco de dados transacional. No entanto, a ativação da replicação tem várias desvantagens do ponto de vista do desenvolvedor:

• Torna as alterações de esquema mais difíceis
• Isso interfere no nosso servidor de integração / construção automatizado
• Parece dificultar a implementação do controle de origem SQL

Minha pergunta é : Quando você sabe que é hora de replicar à luz desses inconvenientes? Como você decide se a complexidade adicional justifica os ganhos?

Nós o usamos antes, portanto, configurá-lo não é um problema. Trata-se mais de tomar a decisão de habilitá-lo ou não. Estou procurando algumas métricas de desempenho de objetos que outros observaram com replicação.

É claro que a melhor coisa seria fazer alguns testes de carga simulados em nossos próprios servidores e descobrir por nós mesmos, mas espero que haja algumas diretrizes gerais por aí.

A replicação deve ser considerada durante a fase de design do aplicativo. Se você possui uma força de trabalho / base de usuários distribuída geograficamente, ter bancos de dados regionais e bancos de dados centrais pode fazer sentido. Os bancos de dados desconectados nos laptops podem "sincronizar" quando finalmente se reconectam à rede (pense na equipe de vendas em trânsito).

Quanto aos propósitos de relatório, a replicação NÃO é a resposta. A maioria dos problemas de desempenho em um ambiente de relatório decorre do fato de os relatórios estarem sendo gravados em um sistema configurado para OLTP (processamento de transações online).

A replicação para fins de relatório é simplesmente mover seus dados OLTP para outro servidor, mas mantendo a mesma estrutura não amigável para os relatórios. Em essência, você está jogando mais hardware no problema e aumentando seus custos de manutenção, mas com ganhos marginais.

O que você deve observar é como obter os dados específicos de que seus relatórios precisam e transformá-los em um formato mais útil. Crie um feed que obtenha novas transações do banco de dados de produção e o armazene em um banco de dados de relatórios, de preferência em um servidor separado. Toda vez que o feed é executado, ele deve pegar todos os dados mais recentes que na última vez em que foi executado, transformar esses dados e armazená-los. Os relatórios que você está executando no momento fornecerão uma boa idéia dos tipos de transformações necessárias.

Seguindo essa abordagem, você obterá enormes benefícios de desempenho.

Pelo que vale, achamos que a replicação é útil em uma situação semelhante, porque os redatores de relatórios podem "possuir" os índices no banco de dados replicado. Isso nos permitiu melhorar o desempenho da consulta adicionando índices que os desenvolvedores de aplicativos nunca teriam aprovado na produção devido ao seu impacto negativo em INSERTS e UPDATES.

Talvez parte do seu caso de uso seja copiar algumas tabelas transacionais, alterar alguma indexação e ver se vale a pena?

Espero que isto ajude!