Mover banco de dados do SQL-Server com tempo de inatividade zero

Question

É possível mover um banco de dados sql server 2005 para um servidor diferente executando o sql server 2008 sem qualquer tempo de inatividade? O sistema é 24/7 e deve ser movido para um servidor diferente com armazenamento diferente.

Nós tentamos copiar o banco de dados, mas isso não mantém o banco de dados inteiro síncrono no final do processo.

    

Answer 1

zero tempo de inatividade não. mas com um planejamento cuidadoso, você pode se safar com quase zero tempo de inatividade.

Opção 1:

• envio de log de instalação btwn existindo em 2005 e novo servidor de 2008.
• Planeje cuidadosamente o corte ip's e / ou hostnames.
• Certifique-se de fazer um log final final backup antes do corte final.

Opção 2 (mais trabalho, menos tempo de inatividade):

• Se a sua caixa 2008 for nova, instale 2005 primeiro para o mesmo sp como o seu caixa de produtos.
• Configurar o espelhamento do banco de dados, assíncrono primeiro estágio para evitar o desempenho sobrecarga.
• Configure seus clientes para ter o parceiro de failover incluído no string de conexão
• Alterar para sincronizar o espelhamento de db e o failover para a nova caixa
• siga as "etapas de atualização contínua" para uma atualização in-loco de 2005-2008 para uma configuração de espelhamento de banco de dados

Claro, para acertar, você precisará testar & certifique-se de que você não perdeu nada quando fizer isso de verdade:)

    

Answer 2

Não. Desculpa. Eu não vejo uma maneira de mover o banco de dados sem qualquer tempo de inatividade. O que está no banco de dados que você não tem nem mesmo que colocar em uma hora durante os feriados da Páscoa?

    

Answer 3

Uma maneira muito complicada de fazer isso ... (quase)

1. P2V o servidor em um cluster VMware. Sem tempo de inatividade.
2. Crie um segundo servidor e crie um cluster ativo / passivo.
3. Atualize o nó passivo para 2008 e faça o failover.
4. Lucro?

Obviamente, tudo aqui precisa de testes, há muitos passos detalhados deixados de fora.

OU - Faça com que a gerência concorde com o tempo de inatividade e divulgue-a para seus clientes. Então pratique e teste a atualização até a morte!

Explique ao gerenciamento as dificuldades técnicas em tentar fazer isso "barato". Isso é algo que você CONSTRUA em um sistema quando você constrói a arquitetura de um 27x7 completo.

Até mesmo os maiores sistemas planejam o tempo de inatividade. É o tempo de inatividade não planejado com o qual você precisa se preocupar mais.

    

Answer 4

a replicação transacional é sua amiga aqui ...

se você configurar a replicação com o novo servidor como um escravo, você deverá ser capaz de colocar o novo db em funcionamento e, quando estiver pronto, alternar (tempo de inatividade mínimo aqui, minutos em que estamos falando, não horas) ... você pode precisar reindexar uma tabela ou três, mas uma vez feito, está feito.

    

Answer 5

Você não vai conseguir isso apenas com o SQL Server, eu tenho medo. Eu usei um produto chamado Double Take no passado que permitiria clonar o DB em outro servidor e, em seguida, fazer failover quando for conveniente.

O processo de failover ainda incorreria em algum tempo de inatividade conforme os serviços são iniciados na nova máquina.

    

Answer 6

Se for apenas uma configuração de instância única / não clusterizada agora, você não conseguirá 0% de tempo de inatividade sem perda de dados . Se o banco de dados for primariamente pesado, e é melhor perder algumas operações de gravação, então, para reduzir o banco de dados, você pode ter algumas opções.

Você pode fazer um backup completo do banco de dados COPY_ONLY e, depois disso, mover o arquivo bak para o novo armazenamento do servidor. Restaure para o banco de dados para a nova instância do SQL e reescreva suas cadeias de conexão onde for aplicável (esperamos que seja apenas um arquivo inc em algum lugar) e reinicie seus sites. Você terá uma falha no site e as sessões ativas serão reiniciadas.

No entanto. você perderá todas as gravações entre o tempo de backup e restauração.

    

Answer 7

Você pode tentar conseguir isso com o mínimo de tempo de inatividade (alguns segundos para failover) usando uma solução de espelhamento de db. Você pode dar uma olhada neste artigo do MSDN para obter mais informações: link

Tom

    

Answer 8

Se você estiver usando uma solução .NET como o servidor de aplicativos que usa a estrutura 2.0, a sugestão de tvanzele deve funcionar bem. Etapas abaixo:

• Verifique se o banco de dados principal está no modo de recuperação COMPLETO e se você está fazendo backups de log
• Instale uma instância SQL SQLEXPRESS ou de edição padrão para atuar como um servidor testemunha
• Backup e restauração do backup COMPLETO e do backup de logs para a nova instância (não para a testemunha)
• Configure o espelhamento de banco de dados para a nova instância do SQL e use a instância SQLEXPRESS / Standard como testemunha
• altere a cadeia de conexão no aplicativo para reconhecer o servidor de failover, consulte connectionstrings.com para referência
• Falha no banco de dados para o espelho, reiniciando a instância antiga
• Alterar a string de conexão do aplicativo para usar apenas a instância de failover
• Quebrar o espelhamento

Answer 9

Você pode considerar a configuração do espelhamento síncrono para o banco de dados entre os dois ambientes. Quando sincronizado, o banco de dados pode ter failover (ou voltar) com apenas uma interrupção em qualquer transação em andamento.

link

    

Answer 10

Sugiro que você faça isso usando o software Redgate . SQL Compare ajudaria você a recriar exatamente a mesma estrutura no banco de dados recém-criado em outro servidor. E então você usa SQL Compare Data , que cria scripts de "cópia" para você e o executa (ou salva para mais tarde). Funciona como um encanto. Eu estou usando para copiar coisas entre prod / dev db.

É bom porque você pode fazer Sql Data Compare uma vez. E então, quando movia alguns dados (e novos dados chegavam no banco de dados antigo), você poderia reexecutá-los novamente, de forma que só sincronizasse as diferenças em alguns segundos.

With SQL Data Compare Pro, you can compare and synchronize SQL Server live databases with backups, compare two backups or work with SQL scripts folders under source control. With the command line interface you can automate tasks and schedule comparisons for easy compilation of an audit trail.

Redgate SQL Toolbelt seu amigo para sempre (não estou de forma alguma associado ao Redgate) : p

Como uma nota lateral. Desde que os dados são preety grande eu sugiro usar SQL Data Compare para usar em pedaços (par de tabelas por cópia). Então, mais tarde, na sincronização final para sincronizar quaisquer diferenças que acontecessem durante o período da cópia (mesmo que você demorasse 3 horas, precisaria apenas sincronizar alguns hundres de linhas ou mais).

    

Answer 11

Me deparei com um produto chamado ChronicDB que afirma que pode fazer a migração com tempo de inatividade zero. Não tenho certeza se eles suportam o SQL Server.

    

Answer 12

Eu realmente acabei com o tempo de inatividade. Eu tomei o caminho "regular" de backup / restauração com logs de transação, incluindo uma cauda final.
Eu ainda acho que deveria haver uma maneira de fazer isso sem qualquer tempo de inatividade.