Backup de replicação do SQL Server

Question

Temos um novo sistema que é executado no SQL Server 2008 r2 de 64 bits. Existe um banco de dados de processamento transacional (OLTP) on-line primário que aceita um alto volume de atualizações de vários milhares de sistemas de ponto de venda em lojas em todo o país. Para proteger esta função vital, decidi introduzir um servidor de banco de dados de relatórios dedicado - do qual vários usuários executarão relatórios bastante complexos.

Eu percebi que havia várias opções, mas decidi usar o Transaction Replication como o mecanismo para copiar os dados do banco de dados OLTP para o novo banco de dados de relatórios - uma replicação de uma maneira.

A solução funcionou bem no teste. Agora me perguntam quais alterações precisam ser feitas na política de backup para cobrir as alterações arquitetônicas. Eu li páginas como MSDN: Estratégias para backup e restauração de snapshot e replicação transacional , mas eu acho que isso é um exagero para minha solução. Na verdade, meu pensamento atual é que simplesmente precisamos continuar fazendo backups dos dados e logs do OLTP. Se o banco de dados do Reporting ou qualquer um dos bancos de dados de replicação do sistema (por exemplo, distribuição) falharem, isso não é grande coisa - podemos limpar tudo e recriar a replicação. Eu percebo que tirar um instantâneo completo do OLTP seria demorado (aproximadamente 5 horas), mas eu ficaria mais relaxado sobre isso, que tenta restaurar os backups dos vários dados e arquivos de log na seqüência correta.

Minha opinião é que as estratégias complexas estabelecidas no artigo do MSDN seriam apenas o caminho para uma solução de replicação mais complexa do que eu, por exemplo, se houvesse vários assinantes com replicação bidirecional.

Você concorda? Eu ficaria grato por qualquer conselho.

Muito obrigado,

Rob.

    

Answer 1

Estou assumindo que você já possui boas estratégias de backup para o seu OLTP DB & seu banco de dados de relatórios que estão sendo exibidos na produção. Eu realmente não vejo você tem quaisquer preocupações adicionais em torno de alterar estes pós-replicação.

Você pode simplesmente gerar scripts de configuração de replicação por meio do Assistente SSMS. Isso permitirá que você ajuste e defina suas configurações de replicação em qualquer futuro ambiente de teste / teste e forneça um backup da configuração atual.

A replicação pode notoriamente consumir seu disco de log se, por algum motivo, a replicação parar ... mas se você tiver alertas manuais ou automatizados controlando o espaço em disco & Status de replicação você não deve ter quaisquer preocupações.

Boa sorte - mas, na minha opinião, as necessidades de Backups na Replicação Transacional básica não precisam de estratégias adicionais.

    

Answer 2

Em nosso ambiente, tenho uma configuração semelhante àquela que você está propondo. Concordo que o procedimento para restaurar os bancos de dados para manter a replicação consistente é um pouco incômodo, e também prefiro recriar a replicação se houver um problema sério, mas ainda faço backup do banco de dados de relatório.

Durante o tempo necessário para gerar e transferir um instantâneo completo (8 horas no nosso caso), posso restaurar uma cópia estática do banco de dados de relatório com um nome diferente em 30 minutos e apontar o aplicativo de relatório para esse banco de dados para evitar muito tempo de inatividade para os usuários do meu relatório, dessa forma os usuários podem executar seus relatórios sobre os dados de ontem até que o banco de dados replicado esteja ativo e em execução.