O antigo servidor de banco de dados está ficando cansado e estou atualizando para um novo hardware. O que eu preciso é de uma cópia exata dos antigos 100 bancos de dados para o novo computador.
Eu li alguns sobre replicação e espelhamento, mas não consigo descobrir qual seria o melhor curso de ação. Acredito que muitos administradores de banco de dados estão acostumados com esse cenário e sabem como fazê-lo, como mover todos os bancos de dados, funções, esquemas, procedimentos armazenados, etc., e o que for necessário.
Eu sei que poderia usar o backup em cada banco de dados, mas tenho centenas de bancos de dados para copiar. Existe uma maneira mais simples?
Um guia passo a passo com descrições resumidas sobre como fazer isso seria ótimo. E talvez alguns links para informações mais detalhadas sobre o tópico, se necessário.
1: Start [SQL Server Management Studio][1]
2: Right-click Server Instance
3: .....
Você tem duas opções viáveis:
Observe que a operação pode ser facilmente roteirizada para que você possa exportar uma lista de bancos de dados do primeiro servidor e importá-la novamente no segundo. No entanto, você terá que reconstruir um número de elemento para que a importação funcione perfeitamente: praticamente todos os logons do banco de dados terão que ser reconstruídos.
Coloque o novo servidor em funcionamento e configure tudo o que você precisa, como e-mail, antes de começar a mover qualquer coisa. Pense nisso como se você tivesse água e eletricidade em uma casa antes que alguém se movesse.
Use seus backups existentes e restaure-os para o novo servidor. Deixe o msdb, modelo, tempdb e mestre sozinho. Quando você abrir o banco de dados no novo servidor, vá para o servidor antigo e defina o banco de dados correspondente como 'OFFLINE' ou desconecte-o. Isso evita um número surpreendente de problemas 'oops'. Deixar os arquivos de banco de dados antigos off-line ou desconectados, mas no lugar, oferece uma saída possível se algo imprevisto e catastrófico acontecer. (Falha da nova SAN, por exemplo).
Use o SSMS para criar scripts de servidores vinculados, operadores, trabalhos e qualquer outro objeto semelhante no nível do servidor. Lembre-se de que o SSMS não fará o script de uma senha em um login SQL do servidor vinculado, portanto, você precisará saber o que é. Se você puder, use segurança confiável para logins.
Não se esqueça dos pacotes DTS e SSIS.
Se você tiver muitos itens para fazer, talvez seja necessário escrever um pequeno script. Se você estiver indo do SQL 2000 para o SQL 2005, é uma boa ideia reindexar tudo depois de acessá-lo no novo servidor.
Use sp_help_rev_login para ajudar a recriar seus logins no novo servidor. artigo do KB descrevendo sp_help_rev_login Isso preservará senhas e SIDS para usuários do SQL Server, se você não estiver usando segurança de domínio.
Não se esqueça de que você pode ter que atualizar as seqüências de conexão em qualquer aplicativo que toque seus bancos de dados. Se você for "jogar fora" o servidor antigo, ou reformatar e usá-lo para outra coisa, fale com o cara da rede e pergunte se ele pode recriar o nome antigo como "nome DNS C" e se ele aponta para seu novo servidor. Isso é uma proteção de ponta quando você tem muitas cadeias de conexão (que podem não estar sob seu controle, digamos, em bancos de dados antigos do Access na área de trabalho de alguém em algum canto remoto da empresa) apontando para o servidor antigo.