backup do SQL Server / restaurar vs. detach / attach

Question

Eu tenho um banco de dados que contém os dados mais recentes, e eu quero replicar o conteúdo do banco de dados em alguns outros servidores. Devido a razões não técnicas, eu não posso usar diretamente a função de replicação ou função Sync para sincronizar a outras instâncias do SQL Server.

Agora, eu tenho duas soluções, e eu quero saber os prós e contras de cada solução. Obrigado!

Solução 1: separar o banco de dados fonte que contém os dados mais recentes, em seguida, copiar para os servidores de destino que precisam os dados mais recentes, e anexar banco de dados para os servidores de destino;

Solução 2:. Faça um backup completo do servidor de origem para toda a base de dados, em seguida, copiar os dados para servidores de destino e ter uma recuperação total no lado do servidor destino

Agradecemos antecipadamente, George

Answer 1

O Detach / Attach opção é muitas vezes mais rápido do que executar um backup, uma vez que não tem que criar um novo arquivo. Portanto, o tempo do servidor A para o servidor B é quase puramente o tempo de cópia de arquivo.

O Backup / Restore opção permite que você faça um backup completo, restaurar que, em seguida, executar um backup diferencial, o que significa o seu tempo ocioso pode ser reduzida entre os dois.

Se a replicação é dados que você está depois, isso significa que você deseja que o banco de dados funcional em ambos os locais? Nesse caso, você provavelmente vai querer a opção de backup / restauração como que vai deixar o banco de dados atual totalmente funcional.

EDIT: Só para esclarecer alguns pontos. Por tempo de inatividade quero dizer que se você estiver migrando um banco de dados de um servidor para outro, você geralmente estará parando as pessoas a usá-lo enquanto ele está em trânsito. Portanto, do ponto "stop" no servidor A até o ponto "start" no servidor B isso poderia ser considerado o tempo de inatividade. Caso contrário, todas as ações realizadas no banco de dados no servidor A durante o trânsito não será replicado para servidor B.

No que diz respeito ao "criar um novo arquivo". Se você desanexar um banco de dados que você pode copiar o arquivo MDF imediatamente. Ele já está lá pronto para ser copiado. No entanto, se você executar um backup, você tem que esperar para o arquivo .BAK a ser criado e, em seguida, movê-lo para a sua nova localização para uma restauração. Novamente, isto tudo se resume a isto é uma cópia instantâneo ou uma migração.

Answer 2

Backup e restauração faz muito mais sentido, mesmo se você pode espremer alguns minutos extras de um desanexar opção anexar vez. Você tem que ter o banco de dados original off-line (desconexão todos) antes de um desanexar, e então o db não estará disponível até que você volte a ligar. Você também tem que manter o controle de todos os arquivos, enquanto que com um backup de todos os arquivos são agrupados. E com as versões mais recentes do SQL Server os backups são compactados.

E só para corrigir algo:. Backups DB e backups diferenciais não truncar o log, e não quebrar a cadeia de log

Além disso, a funcionalidade COPY_ONLY só importa para a base diferencial, não para o LOG. Todos os apoios de log podem ser aplicadas em sequência a partir de qualquer apoio assumindo que não houve quebra na cadeia de log. Há uma pequena diferença com o ponto de arquivo, mas eu não consigo ver onde o que importa.

Answer 3

Solução 2 seria a minha escolha ... Principalmente becuase não irá criar qualquer tempo de inatividade do banco de dados fonte. A única disadvatage eu posso ver é que, dependendo do modelo de recuperação de banco de dados, o log de transações será truncado seja, se você queria restaurar quaisquer dados do log de transações que estaria recheado, você teria que usar seu arquivo de backup.

EDIT: Encontrado um link bom; http://sql-server-performance.com/Community/ fóruns / p / 5838 / 35573.aspx