Estou prestes a migrar arquivos de banco de dados para uma nova SAN (de uma SAN antiga) e tenho algumas opções para implementar isso. (1) Foi sugerido que eu analisasse o nível de esforço de restauração de um backup completo para um novo banco de dados no servidor. No entanto, (2) meu plano original era copiar os arquivos da SAN antiga para a nova SAN desconectando e reconectando o banco de dados.
Meu instinto me diz que prefiro desanexar, copiar e anexar, pois parece mais à prova de falhas, mas isso pode ser apenas minha ingenuidade. Não quero perder uma transação ou de alguma forma "quebrar alguma coisa" no processo de renomear bancos de dados.
Acho que minha pergunta é se estou ou não justificado em meu ceticismo em relação à opção BACKUP-RESTORE-Replay e quais são os outros méritos ou riscos dessa opção?
Pessoalmente, eu evitaria os mecanismos de desanexar/anexar. Especialmente no SQL Server 2000, não acredito que você sempre recupere o servidor e seja capaz de anexar esses arquivos. Já ouvi muitas histórias em que isso não aconteceu de forma limpa - só porque você tem um Plano B não torna automaticamente o Plano A sensato.
Com o backup/restauração, você não corre o risco de ir para o Plano B. Se o backup falhar, seu banco de dados ainda estará ativo. Se a restauração falhar, seu banco de dados antigo ainda estará ativo. Em ambos os casos, você pode restaurar a operação do banco de dados original e revisitar o plano posteriormente. Além da segurança extra aqui sobre parar o SQL Server e/ou desconectar, isso também significa que você pode testar o que há de melhor na metodologia de backup/restauração (supondo que você tenha espaço para executar os backups e outra instância para testar o restaurar). Você realmente não pode testar a abordagem de desanexação sem desanexar os bancos de dados ou parar o SQL Server, e isso é difícil de fazer fora de uma janela de manutenção adequada. E, finalmente, com as outras abordagens, você não pode nem começar a copiar os arquivos até desanexar ou desativar o SQL Server.
Um outro benefício sobre o método pull-the-drive-out-under-SQL-Server: com backup/restauração, você pode mover vários arquivos para letras de unidade diferentes do que eram antes. Por exemplo, quando migramos para uma nova SAN, pudemos ter mais volumes, então poderíamos mover tempdb para T:\ (que não existia antes), alguns dos dados e arquivos de log para novas letras de unidade, etc. para melhor utilizar toda a nova capacidade de E/S que tínhamos. Se você simplesmente desligar o SQL Server e depois trocar os discos, precisará ter as mesmas letras de unidade e o mesmo número de volumes.
Eu costumava mover bancos de dados quase constantemente, devido a reconfigurações e migrações de SAN.
Supondo que você esteja movendo um servidor inteiro por vez, eu usaria algo como o caminho nº 2. (Se você estiver movendo um banco de dados por vez e, eventualmente, fazendo todos os bancos de dados em um servidor, isso seria mais problemático, pois você teria que alterar os caminhos para os arquivos.)
Observe que "single_user" não significa necessariamente VOCÊ. Você pode ir para um banco de dados DBCC CHECKDB e não conseguir entrar porque alguém já está lá. Prepare um script que você possa executar para inicializar "todos menos você" de um banco de dados e mantenha-o em um local acessível. Observe que o SQL 2000 não possui os mesmos recursos "manter todos fora" das versões mais modernas.
Um truque antigo é pausar o serviço do SQL Server. Isso impedirá novos logins, mas quem já estiver conectado pode continuar normalmente. Portanto: conecte-se por meio de uma janela do SSMS para poder trabalhar, pause o serviço e, em seguida, expulse as conexões indesejáveis, faça o que quiser por meio da janela de comando do SSMS (não a GUI, ela faz e interrompe muitas conexões) e, em seguida, despause o serviço. Aviso: não tenho certeza de como isso funcionaria em um cluster. Ele pode querer failover.
É útil ter uma maneira de manter todos os usuários do aplicativo fora de um servidor até que você termine seu trabalho. Caso contrário, as conexões podem começar a aparecer enquanto você está tentando fazer as coisas, o que pode levar à contenção de recursos e/ou lentidão. Eu usei as seguintes maneiras no passado, dependendo da situação exata: Desligando o(s) servidor(es) do aplicativo Uso de ALTER DATABASE .. SET RESTRICTED_USER (Se as contas do aplicativo forem membros das funções db_owner, sysadmin ou dbcreator, isso é um problema. ) Informar aos usuários que o sistema estará offline em algum horário específico, como uma manhã de domingo. (Isso não funcionará em um ambiente "real" 24 horas por dia, 7 dias por semana.) Desconectando a NIC voltada para os servidores ou usuários do aplicativo. (Nesse caso, eu poderia entrar por meio de outro NIC conectado a uma rede somente de administrador ou por meio do ILO.)
Desanexar um grande número de bancos de dados e reanexá-los pode dar muito trabalho. Se você fizer isso, certifique-se de ter seu script "anexar" escrito com antecedência.
Tive muito sucesso parando o SQL Server, copiando tudo, alterando as letras das unidades e iniciando o SQL Server. Sem desanexar/anexar. Contanto que o SQL Server esteja desligado e você esteja copiando (não movendo) arquivos, você não terá muitos problemas, mesmo se estiver movendo os bancos de dados do sistema. Como os caminhos são os mesmos, o SQL Server não perceberá que algo mudou enquanto o serviço estava desativado. Apenas certifique-se de obter as letras de unidade apontadas para os volumes corretos ou as coisas correrão mal para você.
Meu problema mais frequente era não acertar as ACLs nos diretórios de arquivos. As versões mais modernas do SQL Server são melhores em definir apenas as permissões que a conta de serviço precisa, enquanto as versões mais antigas parecem menos exigentes. Se você esquecer de definir as ACLs e a conta de serviço não for um administrador local (não que eu recomende isso), um ou mais bancos de dados podem não abrir quando a instância for iniciada. Não entre em pânico, apenas altere as ACLs e anexe o banco de dados.
Eu geralmente uso o ROBOCOPY para fazer esse tipo de trabalho. Há uma opção de linha de comando para preservar as ACLs.
Usar um cálculo/verificação CRC não é uma má ideia, mas nunca fiz isso. Quando os bancos de dados voltam, eu executo CHECKDB () em todos eles. Normalmente, preparo um script para isso com antecedência, em vez de depender de iniciar manualmente um trabalho de manutenção. Dessa forma, posso verificar alguns bancos de dados menores antes de verificar um banco de dados grande, que pode levar muitos minutos ou horas para ser executado. Duvido que uma verificação CRC (ou uma ferramenta Redgate Data Compare) encontre algo que CHECKDB () perderia e, se encontrasse, o SQL Server não seria capaz de corrigi-lo.
Depois de copiar os arquivos, mas antes de reiniciar a instância, irei alterar um pouco o caminho do arquivo das pastas OLD renomeando uma das pastas. Esta é uma verificação extra contra o problema "ops, o servidor ainda está apontando para os arquivos antigos".
Não tenha pressa para descartar os arquivos antigos e recuperar espaço no armazenamento antigo e certifique-se de que seus backups completos foram executados com sucesso. Teste a restauração de alguns desses backups em outro lugar. Depois de ter boas execuções de checkdb() e bons backups completos, você pode pensar em descartar o armazenamento antigo e desligar o Lefthand.
Os piores problemas que tive com essas migrações aconteceram depois que pensei que havia terminado. Isso seria o administrador da SAN me dizendo que algo havia acontecido e meus sistemas de arquivos estavam embaralhados. (Reparticionado, reformatado, copiado novamente.)
Outro problema divertido é o SAN estar lento sem motivo aparente. Se você acha que levará 10 horas para copiar seus dados e 30% são copiados na hora número 9, você tem um problema. Observe os tempos de transferência (o robocopy mostra a % copiada e fornece estimativas de tempo, ou você pode usar o Perfmon) e tenha um plano alternativo se algo der errado.
Além disso, não tenho certeza se seus volumes serão particionados para você, mas você pode querer ter certeza de que eles estão usando um deslocamento de 1 MB. No Windows Server 2008 e superior, isso não deve ser um problema. No sistema operacional mais antigo, é. Há uma tonelada de coisas que podem ser pesquisadas no Google sobre isso, e seu pessoal de armazenamento deve saber sobre isso, mas eu perguntaria.
Primeiro, eu examinaria a opção de simplesmente usar o recurso da matriz de armazenamento para lidar com a movimentação de dados. Se eles não estiverem disponíveis porque o fornecedor não oferece suporte, você não o comprou ou o administrador da SAN não sabe como fazê-lo...
Então eu simplesmente usaria as seguintes etapas.
É isso.
Não há necessidade de desanexar / anexar, pois, até onde o SQL Server sabe, nada mudou. E se algo der muito errado, você terá a cópia antiga dos bancos de dados no antigo LUN no antigo array de armazenamento. O failback é apenas uma questão de alterar as letras da unidade.