Eu herdei um sistema onde o DBA anterior adicionou 7 arquivos de dados ao grupo de arquivos PRIMARY (tamanho inicial de 8 MB) e deixou a opção AUTOGROW em 8 MB. O que tenho agora é um conjunto de oito arquivos, cada um com cerca de 3 a 4 GB de tamanho, que vem crescendo lentamente ao longo de um período de dois anos. Eu gostaria de remover a fragmentação do arquivo da maneira mais rápida possível.
Aqui estão as opções que eu criei:
- Expanda o 1º arquivo no grupo de arquivos PRIMARY em ~28 GB (7 arquivos x 4 GB)
- Mova os dados de cada um dos arquivos sucessivos e marque-os para exclusão
- Exclua os outros 7 arquivos
- Desanexar o banco de dados
- Copie o arquivo de banco de dados desanexado para uma unidade diferente no servidor
- Copie o arquivo de banco de dados separado de volta para a unidade original
- Reconecte o banco de dados
ou
- Crie um novo banco de dados de 32 GB (8 x 4 GB)
- Transfira todos os objetos, tabelas, usuários e permissões para o novo banco de dados usando o SSIS
- Elimine o banco de dados antigo
- Renomeie o novo banco de dados
Um nível de sistema operacional "Disk Defrag" ainda não é uma opção?
Não sei qual opção é a melhor ou se vai funcionar mesmo.
Além disso, esse banco de dados está sendo espelhado e replicado, portanto, a menor quantidade de trabalho em relação à reconstrução é ideal.
Obrigado pela ajuda.
Honestamente, com um banco de dados de 32 Gig, a fragmentação física não deve ser um grande problema, a menos que você não tenha alguns GB de RAM.
Existem algumas respostas úteis para a seguinte pergunta sobre falha do servidor, que pode ajudar https://serverfault.com/questions/31011/sql-database-physical-file-fragmentation
Agora, depois de tantos aumentos de espaço, certamente os arquivos físicos estão fragmentados e se beneficiariam de alguma desfragmentação no nível do arquivo.
Não conheço sua situação, mas qualquer servidor deve ser rápido o suficiente para atender a um único arquivo de dados de 32 GB. Eu veria um benefício apenas se todos esses arquivos estivessem em discos físicos diferentes, caso contrário, não vejo a necessidade de tal aborrecimento.
Nessa situação eu iria com a solução 1, porém, criaria o arquivo maior que o tamanho atual, com espaço que deveria ser suficiente pelo menos para o próximo ano e com um tamanho maior para autogrow.
Não pensei que a desfragmentação no nível do sistema operacional estivesse disponível para arquivos de banco de dados ao vivo. Eu sempre pensei que você precisa desanexá-lo para poder desfragmentar um arquivo, mas parece que os caras da resposta Serverfault conseguiram desfragmentar um arquivo db enquanto o db estava online.
Ambas as opções devem funcionar, para tornar seu banco de dados mais rápido usando um único arquivo desfragmentado, porém, para a solução nº 2, não vejo necessidade de ter o mesmo número de arquivos, você pode criar um banco de dados com um único data e usando SSIS/bcp para mover tudo nas tabelas do novo banco de dados.
Eu testaria antes, mas acho que a primeira solução seria mais rápida.