Estou trabalhando na configuração de uma cópia de desenvolvimento de um banco de dados de produção no SQL Server 2008 R2 SP1. Atualmente, o banco de dados ativo está sendo pouco usado por dois desenvolvedores para consultas somente leitura, mas o novo banco de dados também terá atualizações.
Como o banco de dados tem 2,1 TB e levou um total de 3 dias para restaurar e atualizar para a versão mais recente que precisamos para teste, meu plano original era criar um novo conjunto de arquivos de backup e restaurar a partir desses arquivos. Isso me permitiria criar a cópia de desenvolvimento do banco de dados na mesma instância e máquina SQL, sem precisar colocar o banco de dados atual offline.
No entanto, para economizar alguns dias, pensei que seria uma boa ideia copiar os arquivos físicos do banco de dados e anexar a nova cópia do banco de dados. Infelizmente quando tento copiar recebo um erro referente ao bloqueio que o SQL Server coloca nesses arquivos.
Como não posso deixar o banco de dados offline para nada além de transferir os arquivos de log (posso terminar isso antes que as pessoas cheguem pela manhã), existe alguma maneira de copiar os arquivos de banco de dados ativos sem colocar o banco de dados em um estado offline? Ou devo esperar até que as pessoas voltem para casa para fazer isso?
Por que leva 3 dias para fazer backup/restaurar um banco de dados de 2,1 TB? Se se trata de mover o backup, suspeito que copiar os arquivos MDF/LDF seria realmente mais lento , pois pelo menos o backup poderia ser compactado. E se se trata apenas de restaurar, a gravação das cópias do arquivo não deve ser mais rápida do que o próprio processo de restauração - certifique-se de ter a inicialização instantânea do arquivo ativada . Ou obtenha E/S mais rápida no sistema secundário.
De qualquer forma, não, você não pode copiar os arquivos MDF/LDF enquanto o banco de dados estiver online, você teria que colocá-lo offline para fazer isso. E esta é a maneira absolutamente MENOS segura de copiar um banco de dados. Se algo acontecer com os arquivos enquanto eles estiverem desanexados/offline, agora você tem zero cópias do seu banco de dados.
Sugiro procurar maneiras de tornar o backup/restauração mais rápido - seja garantindo que você esteja compactando seus backups e transferindo os arquivos da melhor maneira possível, usando o melhor subsistema de E/S disponível, obtendo melhor E/S, tornando certifique-se de que o IFI está ativado, etc.
Outra opção a considerar é o envio de logs round robin - supondo que a produção esteja em recuperação total e você esteja fazendo backups de log regulares, você pode realizar o envio de logs para um banco de dados enquanto os desenvolvedores trabalham em outro e, quando chegar a um ponto estável, restaurar com recuperação e faça com que os desenvolvedores troquem, levando suas mudanças recentes com eles. Agora reinicie o envio de logs na cópia em que eles pararam de trabalhar e ela estará pronta para eles na próxima transição "estável", sem espera.
Não, você terá que colocá-lo offline para copiar os arquivos. Se você tiver seu banco de dados dividido em arquivos/grupos de arquivos menores, isso pode ajudar a tornar a restauração de backup mais rápida depois de ter feito isso uma vez (dependendo de quais dados estão sendo alterados e quais dados são necessários para a cópia de desenvolvimento).
Eu vi as outras respostas e elas fazem todo o sentido. No entanto, apenas para responder à sua pergunta, você certamente pode copiar arquivos de banco de dados sem deixar o banco de dados offline. Você precisará usar a programação SMO para essa finalidade. Confira: http://technet.microsoft.com/en-us/library/ms162175(v=sql.100).aspx
Observe que o link fornecido é para objetos gerais de programação SMO e não uma resposta específica para esta pergunta. Eu ainda não fiz isso, mas em breve vou tentar isso e vou deixar todos saberem (se eu me lembrar), o que eu descobrir.
Sim.
Tudo o que você precisa fazer é definir o banco de dados como somente leitura:
Corre:
Copie os arquivos de banco de dados - MDF, LDF, etc. para seu novo destino
Depois que a cópia estiver concluída, você poderá desanexar e anexar novamente no novo local. Apenas certifique-se de redefinir a opção somente leitura e de que você está usando a mesma conta de usuário ao manipular esses arquivos. Além disso, você pode querer excluir os arquivos antigos após a movimentação.
Outro método
Depois que os arquivos forem copiados com sucesso (etapa 2 acima):
Você pode definir o banco de dados para:
Single_User
mode então:Corre:
D:\
sendo o novo localCertifique-se de que os arquivos de dados no novo local (
D:\
) tenham acesso total à conta de serviço que está executando o SQL Server.Reinicie os serviços SQL
Corre:
Feito!