Melhor maneira de desfragmentar / compactar um banco de dados para fins de arquivamento

9

Temos uma instância do SQL Server usada para arquivamento de email (cortesia de um pacote de arquivamento de terceiros). De vez em quando, o software é transferido para um novo banco de dados vazio. Fizemos isso trimestralmente no passado, mas pretendemos fazer isso mensalmente agora. A quantidade de dados arquivados é de cerca de 15 a 20 GB por mês, e a maior parte dos dados reside em apenas algumas tabelas (geralmente 2 a 4).

Depois que passamos para um novo banco de dados, o antigo passa a ser usado estritamente somente leitura. O que eu gostaria de fazer é otimizá-lo em um arquivo de dados compacto e agradável, com todas as tabelas / índices contíguos e com um fator de preenchimento muito alto e pouco espaço vazio no final do arquivo de dados. Além disso, estamos usando o Standard Edition neste servidor, com todas as limitações que isso implica (caso contrário, eu já estaria usando a compactação de dados).

Algumas possibilidades que posso pensar:

  1. Índices REBUILD / REORGANIZE, DBCC SHRINKFILE (Ok, essa não é uma opção sensata, pois o DBCC SHRINKFILE fragmentará a irritação de qualquer coisa que tocar, mas estou incluindo a integridade).
  2. Crie um novo banco de dados com as estatísticas automáticas desativadas. Script e recrie todas as tabelas do banco de dados de origem. Use bcp para exportar / importar os dados para o novo banco de dados, em ordem de chave de cluster. Script e recrie todos os índices. Recalcule todas as estatísticas com varredura completa.
  3. Crie um novo banco de dados com as estatísticas automáticas desativadas. Script e recrie todas as tabelas do banco de dados de origem. Use SSIS ou T-SQL para transferir dados para o novo banco de dados. Script e recrie todos os índices. Recalcule todas as estatísticas com varredura completa.

A etapa final em todos os casos seria definir o banco de dados no modo somente leitura.

Que outras opções boas / melhores existem para fazer isso? Minha preocupação é transferir os dados de maneira a preservar um alto fator de preenchimento e de uma maneira logicamente contígua.

Editar:

Devo mencionar que cerca de 75% dos dados parecem armazenados em colunas de imagem (LOB).

db2
fonte
3
Você (ou o aplicativo) se importa se as tabelas terminam fisicamente em um grupo de arquivos diferente de PRIMARY?
Jon Seigel
@ JonSeigel Suponho que não, e na verdade é uma boa idéia, pois me pouparia o trabalho de criar um banco de dados de modelos e mover todos os dados.
db2
Você está considerando apenas soluções codificadas por conta própria ou também pode revisar algum aplicativo para ajudá-lo? Você pode usar o SQL Storage Compress do RedGate para compactar dados ao vivo. Ou você pode tentar o Virtual Restore para disponibilizar backups compactados como dbs online (sem realmente ter o espaço completo necessário). Todos eles são baseados no driver de arquivo Hyperbac mais antigo do Windows, que é muito bom em compactar dados e backups ao vivo.
Marian
@ Marian Parece interessante, mas eu gostaria de manter os recursos nativos do SQL Server por enquanto. Eu só preciso desfragmentar efetivamente os bancos de dados, sem muito espaço restante nos arquivos. Se é uma ferramenta de terceiros que executa o trabalho em vez de criar scripts manualmente, tudo bem.
db2
É apenas um pensamento, mas por que não criar um novo grupo de arquivos, adicionar um arquivo, definir um crescimento razoável (por exemplo, 500 MB) e reconstruir suas tabelas nesse novo grupo de arquivos. Em seguida, reduza o arquivo principal para quase nada. Você não vai se importar com a fragmentação nas tabelas do sistema.
Nic

Respostas:

1

Para eliminar a fragmentação física nos arquivos, você também pode mover o índice em cluster com a exclusão existente para um novo grupo de arquivos. Como eles serão o RO, tornem todos o fator de preenchimento 100%, sem espaço necessário para inserções, divisões de páginas causadas por atualizações.

Isso também permitiria executar uma restauração fragmentada e colocar o banco de dados on-line muito rapidamente, caso você decidisse ir para o Enterprise. A empresa também permite índices columnstore, além de reduzir bastante o tempo de consulta desses dados somente leitura, que é um filete maciço.

Você pode usar a opção shrinkfile uma vez antes de mudar para somente leitura sem problemas sérios com a fragmentação para remover o espaço no final do arquivo conforme desejado.

Em uma nota lateral, basta verificar se você está usando os Tipos de Dados mais recentes para seus LOBS. ou seja, nvarchar (max) ou varchar (max) em vez de ntext ou texto, varbinary (max) em vez de imagem?

Mercadorias estragadas
fonte
Infelizmente, usa principalmente texto e imagem. É um aplicativo de terceiros, então não tenho a capacidade de mudar isso.
db2
@ é realmente transparente para o aplicativo, com o SQL Server armazenando as informações em linha se <8k. Se o fornecedor disser que não há suporte, eu perguntaria por que eles ainda estão usando tipos de dados originalmente descontinuados no SQL Server 2005!
DamagedGoods
Não posso ter certeza absoluta de que o aplicativo não faça coisas específicas de texto / imagem, como WRITETEXT, que falhariam depois de alterar o tipo de dados. Mas, voltando ao ponto principal, parece que recriar o índice clusterizado não moverá realmente os dados LOB com ele.
DB2
você pode fazer isso, mas precisa entrar no designer na GUI, expandir as propriedades, ter um 'espaço de dados regular', mas também um grupo de arquivos TEXTIMAGE, alterando isso, mas tenha cuidado, pois isso irá recriar a tabela! Você pode, obviamente, este script e executado em uma janela de manutenção, se possível
DamagedGoods
Entendi, isso pode ser uma maneira útil de gerar os scripts de reconstrução apropriados, no mínimo.
DB2
0

Eu enfrentei um problema semelhante com uma ferramenta de terceiros que também usava um tipo de dados de imagem para armazenar dados não estruturados e resolvi-o convertendo a coluna para usar o fluxo de arquivos . Você precisará fazer alguns testes para garantir que o aplicativo ainda funcione conforme o esperado, mas isso permitirá que você escreva seu próprio processo de arquivamento que move seus dados para um banco de dados de maneira eficiente.

Liam Confrey
fonte
Suspeito que o fluxo de arquivos não escalaria bem neste caso. Temos mais de 14 milhões de linhas em 17 bancos de dados e estamos recebendo mensagens em torno de 15.000 por dia. Uma parte substancial dos corpos das mensagens está abaixo de 4 KB, portanto o desperdício de cluster NTFS provavelmente seria brutal (e isso é mesmo se adicionarmos um novo volume de disco com um tamanho de bloco menor que 64 KB).
db2
Nesse caso, você pode converter o tipo de dados em algo como nvarchar (max) e usar a cláusula TEXTIMAGE_ON para especificar um grupo de arquivos diferente para esses objetos grandes? Isso permitirá que você armazene os dados fora da linha e crie seu próprio processo para gerenciar o arquivamento.
Liam Confrey
o uso do filestream realmente depende do tamanho de cada LOBS. Eu acho que> 1 MB por registro deve ser considerado. Então, eu concordo, neste caso, não é uma opção
DamagedGoods