attach / detach vs. backup / restore

Question

Estou usando o SQL Server 2008 Enterprise. Eu preciso transferir o banco de dados (como um todo) para outro servidor (para criar um banco de dados duplicado para configurar outro ambiente de teste).

Eu tenho duas opções, (1) fazer um backup completo no servidor de origem / restaurar no servidor de destino; (2) fazer desanexar no servidor de origem / anexar no servidor de destino.

Quaisquer prós e contras compararam as duas soluções de acordo com as minhas necessidades?

obrigado antecipadamente, George

    

Answer 1

Eu estremeço ao pensar em separar um banco de dados, copiar seus arquivos para um local diferente e, em seguida, reconectá-lo no servidor de produção (e anexar a cópia no servidor de teste). O backup é projetado para fornecer uma cópia completa do banco de dados sem qualquer tempo de inatividade. Ele também não introduz oportunidade para que os arquivos do banco de dados de origem sejam acidentalmente movidos / excluídos / danificados, o que eu já vi acontecer várias vezes (devido a erro do usuário - erro de digitação ou deslizamento do mouse) durante operações de destacar / anexar. Além disso, a transferência do banco de dados + logs poderia resultar em um tamanho de arquivo de transferência muito maior do que apenas um backup.

Faça um backup e copie / mova o arquivo de backup para o servidor de destino. É muito mais seguro fazer isso, do ponto de vista da produção.

    

Answer 2

Espero que um DBA possa tocar aqui, já que eu não sou um cara DB. Mas eu sei que eu corri para questões relacionadas ao esquema fazendo detatch / attach em vez de backup / restauração. Eu sempre acho que a rota mais segura é fazer backup e restaurar.

    

Answer 3

Detach / attach é potencialmente mais rápido, dependendo do seu modelo de recuperação e se você está ou não usando a compactação em seu backup. O desanexamento e a conexão são quase instantâneos, enquanto é necessário gravar o arquivo de backup no servidor de origem e gravar os arquivos db no servidor de destino.

    

Answer 4

O backup e a restauração reduzirão o tempo de inatividade do servidor de origem, enquanto a remoção e a anexação serão mais rápidas, pois você não precisará primeiro copiar o backup no sistema de destino e restaurá-lo (a menos que esteja usando uma mídia física para transferir o arquivo de backup de um servidor para outro).

Eu continuaria com backup / restore: é simples de usar e entender, e o tempo de atividade é sempre uma propriedade desejável em um sistema de produção. Além disso, você pode usar isso para validar sua estratégia de backup, fazendo um backup regular para a restauração ou criando uma nova.

Uma vez que o DB foi montado, você ainda precisará passar por permissões e esquema para ajustá-los ao novo local. Em ambos os casos, talvez seja necessário transferir todas e quaisquer chaves usadas para criptografia antes de tentar restaurar os dados.

    

Answer 5

Eu sempre uso o Backkup / Restore - é menos invasivo, mantém seu banco de dados on-line e é uma prova bastante idiota - eu estou vivendo uma prova disso.

Eu suponho que você esteja executando backups diários / semanais / o que for ... o que poderia ser mais fácil do que simplesmente copiar os backups para o seu servidor de teste? [Obviamente, com 100 GB, vai demorar um pouco!]

    

Answer 6

Não sei exatamente o que você está tentando realizar aqui, mas também é possível fazer uma replicação de snapshot no Enterprise que permita atualizar seu ambiente de desenvolvimento ou ambiente de preparação regularmente.