Alternando a publicação de replicação do SQL Server

Question

Eu tenho um banco de dados de produção hospedado no SQL Server 2008R2 Standard que é replicado para um segundo servidor que executa a mesma versão do SQL Server por meio de uma assinatura do banco de dados de produção. O banco de dados subcritor é usado para executar relatórios SQL nos dados. As exclusões não são replicadas, portanto, o banco de dados de relatórios é bastante grande em comparação com o banco de dados publicado na produção, que é limpo semanalmente.

Estou planejando substituir o servidor que hospeda o banco de dados publicado e fiquei imaginando qual seria o melhor curso de ação para garantir que o banco de dados do assinante não perderia nenhum dado. Este é um esboço sensato dos passos a seguir:

1. Restaurar uma cópia do backup mais recente do banco de dados de produção antigo para o novo servidor
2. Publique esse novo banco de dados usando as mesmas configurações do banco de dados antigo
3. Cancelar assinatura (ou qualquer que seja o termo adequado para quebrar a replicação) o banco de dados inscrito de relatórios do antigo banco de dados publicado
4. Subscreva a base de dados de relatórios para a nova publicação

É tão simples assim, ou há algo que eu perdi que poderia me dar uma reviravolta? A principal coisa que quero garantir é que o banco de dados usado para relatórios (o banco de dados inscrito) não perca nenhum dado e continue recebendo novos dados replicados do novo banco de dados.

Obrigado

    

Answer 1

Seu plano está correto, exceto que você precisará especificar @sync_type de suporte à replicação somente para sp_addsubscription que assume que o assinante já possui o esquema e os dados iniciais para as tabelas publicadas e não será inicializado, ignorando assim a queda.

Se você estiver usando o Assistente para novas assinaturas, o mesmo pode ser feito selecionando Não inicializar na página Inicializar assinaturas .

    

Answer 2

O truque estará em como você sincroniza. No procedimento armazenado sp_addarticle, o padrão para o parâmetro @pre_creation_cmd é eliminar a tabela no assinante. Isso vai ser um problema para você. Veja como eu poderia fazer isso:

1. Faça o que for necessário para mover o banco de dados publicado para o novo servidor. Isso provavelmente incluirá a quebra da replicação (deliberadamente).
2. No assinante, renomeie todas as suas tabelas (ou coloque-as em outro esquema). Isso irá protegê-los de qualquer problema que possa acontecer com eles como parte da reinicialização da replicação. Como alternativa, você pode renomear o banco de dados com a intenção de criar um novo banco de dados para servir como o assinante.
3. Reconstrua a publicação e a assinatura
4. Deixe a publicação sincronizar
5. Para cada tabela em que você tem essa condição de arquivamento, insira os dados de onde quer que você tenha movido as tabelas na etapa 2 que não existam nas tabelas "ao vivo" no assinante. Essencialmente, uma junção esquerda entre a mesa salva e a mesa viva em cada caso

Também sugiro que você aproveite esta oportunidade para implementar um local mais seguro para seus dados de arquivamento. Se alguma vez a replicação quebrar por conta própria (pode e faz), você está em um ponto complicado no que diz respeito à reinicialização. Se eu tivesse que fazer isso, criaria um procedimento personalizado chamado por replicação (você pode especificá-lo com o parâmetro @del_cmd para sp_addarticle) que insere o registro em sua tabela de arquivamento e, em seguida, faz a exclusão da sua tabela ativa. Mas existem inúmeras maneiras de realizar a mesma coisa. Boa sorte.