Simple SQL Server 2005 Replication - servidor “D-1” usado para consultas / relatórios pesados

Question

Temos duas máquinas SQL 2005. Um é usado para dados de produção e o outro é usado para executar consultas / relatórios. Toda noite, a máquina de produção despeja (backups) seu banco de dados em disco, e o outro restaura. Isso é chamado de processo D-1.

Eu acho que deve haver uma maneira mais eficiente de fazer isso, já que o SQL 2005 tem muitas formas de replicação. Alguns requisitos:

1) Não há necessidade de replicação instantânea, pode haver (alguns) atrasos

2) Todas as alterações (incluindo esquemas, dados, restrições, índices) precisam ser replicadas sem intervenção manual

3) É usado apenas para um único banco de dados

4) Existe um terceiro servidor disponível, se necessário

5) Há alta largura de banda (gigabit ethernet) disponível entre os servidores

6) Não há armazenamento compartilhado (SAN) disponível

Qual seria uma boa alternativa para essa rotina diária de backup / restauração? Obrigado!

    

Answer 1

A melhor alternativa é o envio de log . O envio de logs também é baseado em backup / restauração, mas depois de uma semente inicial do backup completo do banco de dados, o site de relatórios é mantido aplicando os backups de log do site principal. O envio de logs é bom porque:

• não tem impacto no site principal
• tem suporte na ferramenta de gerenciamento do SQL para implantação, monitoramento e administração
• os dados transferidos são mínimos, apenas o backup de log do banco de dados, que contém apenas as alterações ocorridas desde a última remessa.
• atraso de dados é o relativamente pequeno: intervalo entre logs + tempo para copiar o arquivo de log e restaurá-lo.

A desvantagem é que o site de relatórios é interrompido sempre que o log é restaurado, todos os usuários são expulsos durante a restauração.

Portanto, se você tiver um intervalo típico de backup de log de 30 minutos, o site de relatórios será sempre de até 30 + X minutos (sendo X o tempo necessário para copiá-lo e restaurá-lo). 30 minutos por um curto período de tempo.

Outra alternativa é o espelhamento do banco de dados . Com o DBM, o site de relatórios é mantido constantemente atualizado, mas a desvantagem é que o banco de dados espelho está offline. Os relatórios devem ser executados a partir de um snapshot do banco de dados que é atualizado periodicamente. Ao contrário do envio de log, o DBM também afeta o site principal. A grande vantagem da solução DBM para relatórios externos é que, uma vez implantada, ela também pode servir como uma solução de alta disponibilidade / recuperação de desastres.

Alguns usam replicação transacional também, mas não sou muito fã dessa tecnologia . Embora fácil de implantar, é lento em alta carga e tem a tendência de se deparar com problemas difíceis de solucionar e diagnosticar. Além disso, a replicação não copia exatamente um banco de dados, mas mantém cópias de artigos publicados no banco de dados de distribuição (isto é, tabelas e índices selecionados) e modificações de esquema exigem planejamento e implantação cuidadosos. Com o envio de logs e as alterações no esquema do banco de dados de espelhamento, apenas é possível replicar sem qualquer problema.