Qual é a melhor maneira de mover 20+ bancos de dados para um novo servidor de banco de dados? SQL 2005

Question

Servidor de banco de dados atual: SQL Server 2005 - Windows Server 2003 Novo servidor de banco de dados de destino: SQL Server 2005 - Imagem do Windows Server 2003 Enterprise - VM Ware

O servidor de banco de dados atual tem mais de 20 bancos de dados, alguns bancos de dados de aplicativos ... outros bancos de dados de tipo infrastructure (Citrix). Queremos mover todos esses bancos de dados para uma nova caixa recém-criada que seja virtualizada.

Então, em resumo adicional - sim, isso é físico para virtual. - Mais de 20 bancos de dados transferidos para esta nova caixa virtual do SQL 2005. - aplicativos nesta caixa exigem um tempo de inatividade mínimo.

Algumas abordagens em que posso pensar (todas seriam testadas): 1. Conversores físicos de terceiros para conversores virtuais - depois, desligue a caixa antiga.
- concerns = associações SID, Windows ou SQL Server não gostaram disso.

2. Mova todos os bancos de dados de uma vez para o novo servidor - Encerre o servidor antigo, altere o nome do host na nova caixa virtual para o nome do host antigo.

3. Mova tudo de uma vez, mas use um nome de host diferente para a nova caixa - isso permite a execução paralela no caso de algo quebrar - challenge = deve alterar o nome do host dentro de cada aplicativo - pode ter problemas.

4. Mova cada base de dados em etapas - isso significará um novo nome de host e um projeto mais longo.

Alguém mais tem um cenário semelhante?

    

Answer 1

Passamos de um único servidor SQL para um novo cluster SQL (todo o novo hardware). Cerca de 70 bancos de dados. A maneira como fizemos isso foi separar os bancos de dados, copiar os arquivos e, em seguida, anexar os bancos de dados aos novos nós SQL.

Nós fomos forçados a atualizar os nomes de host, mas eu colocaria o antigo off-line e usaria o mesmo nome de host. Você sempre pode voltar imediatamente.

    

Answer 2

Uma maneira de minimizar o tempo de inatividade é usar o envio de logs de um servidor para o outro. Isso requer a repondo as configurações do aplicativo, mas tem o benefício de ter menos tempo de inatividade. Em geral, o processo é o seguinte:

1. Crie o novo servidor e mova jobs / logins / SSIS, etc.
2. Configure o banco de dados de origem para o envio de logs e inicie o envio.
3. Interrompa o (s) aplicativo (s) e defina o banco de dados como somente leitura.
4. Backup do último log de tran para o banco de dados.
5. Restaurar o último log de transferência no novo servidor, definido como sem recuperação.
6. Defina o novo banco de dados para voltar a leitura / gravação.
7. Coloque o aplicativo repondido de volta online.

Algumas notas:

• O espelhamento de banco de dados é uma solução semelhante.
• A replicação no nível da SAN também é semelhante, mas requer SANs especiais (como HP EVAs).

Prós:

• Tempo de inatividade mínimo.
• O envio de log é muito fácil de configurar.
• Plano de reversão razoavelmente fácil.

Contras:

• Mais etapas manuais.
• É preciso verificar o aplicativo para certificar-se de que ele seja adequadamente indicado (mais administração de sistemas / trabalho de DBA).

Portanto, há um trade-off, mas esse método funciona e é uma técnica bastante comum.

Eric  -

    

Answer 3

Execução de dados de riscos paralelos que mudam entre quando você fez a cópia & atualizando a cópia de acordo. Atualizar aplicativos para apontar para um novo nome de host também pode causar sofrimento.

Eu recomendaria usar uma configuração paralela para testar cada aplicativo, mas, uma vez satisfeito com os testes, provavelmente usaria o recurso Detach / Attach: Como mover bancos de dados do SQL Server para um novo local usando as funções Desanexar e Anexar no SQL Server

    

Answer 4

Da minha experiência, o p2v é um excelente & opção rápida, mas não ideal se você quiser minimizar o tempo de inatividade. Eu o usaria somente quando os servidores existentes não forem uma bagunça & virtualização é apenas para racionalização de hardware. (ou seja, você não está renomeando a caixa, colocando-a em um novo AD.)

SQL Server & O Windows estará ok se você p2v, mas você precisará parar os serviços do SQL Server antes de iniciar o p2v. A ect do Windows SID permanecerá inalterada, o que o Windows não gosta é o físico & os servidores virtuais conectados à mesma rede.

Se você optar pelo método attach / detach, certifique-se de copiar também:

• logins do servidor sql
• tarefas do agente do servidor sql (incluindo tarefas de backup)
• servidores vinculados
• procedimentos armazenados estendidos

configurando nova infraestrutura & Fazer um corte significa menos tempo de inatividade, mas requer mais trabalho. Como discutido, o log-in para um servidor 'cut-over' é a maneira mais rápida de fazer isso, especialmente se você tiver grandes bancos de dados.

    

Answer 5

Se você tiver alguns dólares para gastar, como 300,00 ou mais, confira o conjunto de ferramentas de administrador idera. Um excelente software. Eu usei em um projeto recente. Ele moveu os bancos de dados e quaisquer objetos relacionados, incluindo usuários. Valeu a pena. Em 3 cliques, mudei todos os meus bancos de dados. Eu ainda uso para mover bancos de dados para frente e para trás. Eu acredito que eles têm uma versão de teste. Além disso, você obtém muitas outras ferramentas, como mover usuários ou objetos entre bancos de dados, etc.