Movendo o banco de dados do SQL Server para um novo disco enquanto estiver online

Eu tenho um banco de dados do SQL Server de 1,4 TB que está enfrentando grandes problemas com a E / S do disco. Instalamos uma nova matriz SSD no servidor que resolverá todos os nossos problemas. Estamos apenas debatendo a melhor maneira de mover o banco de dados. Idealmente, se podemos fazê-lo sem tempo de inatividade, é melhor. Mas onde a escolha é entre dois dias de baixo desempenho (por exemplo, ao copiar dados) versus duas horas de inatividade, o último pode ser preferível.

Até agora, as soluções que encontramos são:

• Cópia simples. Coloque o banco de dados offline, copie os arquivos, altere os locais no SQL Server e volte a colocá-lo online. Números aproximados estimam que isso levará até cinco horas, o que não é realmente aceitável, mas é a solução mais fácil.

• Cópia em nível de bloco. Usando um utilitário semelhante ao rsync, copiamos os arquivos em segundo plano enquanto o banco de dados está ativo. Quando estamos prontos para migrar, colocamos o banco de dados offline, fazemos uma cópia diferencial usando esse utilitário, apontamos o servidor SQL para os novos arquivos e o colocamos online. O tempo aqui é desconhecido. Não sabemos quanto tempo levará para fazer uma análise diferencial de 1,4 TB e copiá-la. Nossa outra preocupação é que a cópia em nível de bloco deixará os arquivos em algum estado ilegíveis pelo SQL Server e perderemos nosso tempo.

• Migração de SQL. Crie um novo arquivo de dados SQL de 1,4 TB no novo disco e desative o crescimento automático em todos os outros arquivos. Em seguida, execute DBBC SHRINKFILE (-file_name-, EMPTYFILE) em todos os outros arquivos de dados por vez. Depois que todos os dados estiverem reunidos, em algum momento, mostrarei uma janela agendada para mover o arquivo MDF para o SSD e remover os outros arquivos não utilizados. Eu gosto disso porque minimiza o tempo de inatividade. Mas não tenho idéia de quanto tempo isso levará e se causará degradação no desempenho enquanto estiver acontecendo.

Não temos nenhum tipo de ambiente de carga e desempenho para testar isso. Posso verificar se as estratégias funcionarão em nosso ambiente de preparação, mas não o impacto e nem o desempenho.

Um método para mover todo o banco de dados é com BACKUPe RESTORE. O banco de dados ficará indisponível durante a troca final, mas o tempo de inatividade deve ser mínimo com o planejamento. Este procedimento supõe o modelo de recuperação FULLou BULK_LOGGED:

1) Execute um backup COMPLETO (ou use o existente).

2) Restaure o backup completo mais recente para um nome de banco de dados diferente, especificando a WITH MOVEopção para realocar arquivos no armazenamento SSD conforme desejado e a NORECOVERYopção para que os backups diferenciais e de log subsequentes possam ser restaurados.

3) Aplique alterações incrementais ao novo banco de dados até o momento do corte final com backups de log de transações e RESTORE...WITH NORECOVERY. Isso minimizará o tempo de inatividade para a mudança final para o novo banco de dados.

4) Para alternar para o novo banco de dados, coloque o aplicativo offline, execute um backup final do log de transações e aplique-o ao novo banco de dados WITH RECOVERY. Por fim, renomeie o banco de dados original para um nome diferente e renomeie o banco de dados realocado para o nome original. Solte o banco de dados antigo conforme sua conveniência.

No modelo de recuperação SIMPLE, você pode usar um processo semelhante, mas sem o backup / restaurações do log de transações da etapa 3. Em vez disso, use um backup / restauração de banco de dados diferencial na etapa final. Isso pode exigir mais tempo de inatividade, dependendo da quantidade de alterações desde o FULLbackup inicial .

Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.