Quando é correto reduzir um banco de dados?

Eu sei que encolher é o diabo: inverte a ordem das páginas e é responsável pelo câncer de pele, fragmentação de dados e aquecimento global. A lista continua ... Dito isto, digamos que eu tenho um banco de dados de 100 GB e excluo 50 GB de dados - não em uma tabela, mas uma remoção geral de dados antigos em um nível amplo do banco de dados, cobrindo 90% dos tabelas - isso constitui um caso de uso apropriado para reduzir o banco de dados?

Caso contrário, quais são as etapas apropriadas a serem tomadas para limpar a casa após remover uma porcentagem tão alta de dados de um banco de dados? Eu posso pensar em dois: reconstruir índices e atualizar estatísticas. O quê mais?

Uma reorganização e redução nunca é realmente recomendada.

Se você pode colocar os aplicativos que o banco de dados está servindo offline, é possível acelerar o processo e reduzir a fragmentação do índice removendo todos os índices e restrições de chave primária / estrangeira antes do encolhimento (isso significa que há menos dados a serem movidos, pois somente o as páginas de dados serão embaralhadas e não as páginas de índice agora inexistentes, acelerando o processo) e recriar todos os índices e chaves.

Recriar os índices após o encolhimento significa que eles não devem ser significativamente fragmentados, e tê-los desaparecidos durante o encolhimento significa que reconstruí-los não deixará muitos pequenos "buracos" na alocação da página nos arquivos que podem convidar a fragmentação posteriormente.

Outra opção, se você pode offline os aplicativos, é migrar todos os dados para um novo banco de dados da mesma estrutura. Se o seu processo de construção for sólido, você poderá criar rapidamente esse banco de dados em branco, se não criar um a partir do banco de dados atual (restaure um backup do atual, trunque / exclua todo o conteúdo das tabelas e execute uma redução completa).

Você ainda pode descartar todos os índices no destino e recriá-los posteriormente, pois isso pode ser muito mais eficiente ao alterar muitos dados indexados (100% nesse caso). Para acelerar o processo de cópia, leve os arquivos de dados do banco de dados de destino em diferentes unidades físicas para a fonte (a menos que você esteja usando SSDs; nesse caso, não precisará se preocupar em reduzir os movimentos da cabeça), é possível movê-los para o local de origem quando terminar.

Além disso, se criar o destino como novo (em vez de apagar uma cópia da fonte), crie-o com um tamanho inicial que conterá todos os dados atuais mais alguns meses de crescimento - que fará com que os dados copiem um pouco mais rápido novamente, pois ele não alocará novo espaço de vez em quando ao longo do processo.

Isso pode ser melhor do que usar a redução, porque a migração dos dados para um banco de dados novo replica a ação pretendida da operação de redução, mas potencialmente com muito menos fragmentação (que é a consequência não intencional de uma reorganização e redução). Um psiquiatra simplesmente pega os blocos perto do final do arquivo e os coloca no primeiro espaço mais próximo do início, sem fazer nenhum esforço para manter os dados relacionados juntos.

Suspeito que o resultado também será mais eficiente em termos de espaço, pois provavelmente haverá menos páginas usadas parcialmente depois. Um psiquiatra apenas moverá as páginas usadas parcialmente, é mais provável que a movimentação dos dados resulte em páginas inteiras, especialmente se você inserir no destino na ordem da chave / índice clusterizado de uma tabela (onde a tabela possui uma) e criar outros índices depois que todos os dados foram migrados.

É claro que, se você não pode desativar os aplicativos, apenas a redução é a sua única opção; se você realmente precisar recuperar o espaço, faça isso. Dependendo dos seus dados, padrões de acesso, tamanho comum do conjunto de trabalho, quanta RAM o servidor possui e assim por diante, a fragmentação interna extra pode não ser tão significativa no final.

Para a operação de cópia, o SSIS ou o T-SQL base também funcionariam (a opção SSIS pode ser menos eficiente, mas potencialmente mais fácil de manter posteriormente). Se você criar os relacionamentos FK no final, juntamente com os índices, poderá executar um simples "para cada tabela, copiar" em ambos os casos. É claro que para um caso único, uma redução + reorganização provavelmente também é boa, mas eu só gosto de assustar as pessoas para que nunca considerem a redução regular! (Eu sei que as pessoas agendam diariamente).

O banco de dados vai crescer novamente? Nesse caso, o esforço que você fará nas operações de redução será um desperdício, porque quando você reduz o tamanho do arquivo e adiciona mais dados, o arquivo precisa crescer novamente e as transações precisam esperar que esse crescimento aconteça. Se você tiver configurações de crescimento automático abaixo do ideal e / ou uma movimentação lenta, essa atividade de crescimento será bastante dolorosa.

Se você reduzir o banco de dados, para que você usará o espaço em disco liberado? Novamente, se você quiser manter esse espaço livre, caso esse banco de dados cresça novamente, estará girando as rodas.

O que você pode considerar fazer, agora que possui todo esse espaço livre no arquivo, está reconstruindo seus índices para que sejam melhor otimizados (e será muito menos doloroso fazer isso quando você tiver espaço livre para fazê-lo - pense em tentar trocar uma blusa em um armário minúsculo versus um quarto grande).

Portanto, a menos que essa seja uma grande operação de limpeza e você realmente não esteja voltando ao mesmo nível de dados novamente, eu deixaria como está e me concentrei em outras áreas de otimização.

Se você estiver ficando sem espaço e seus dados não ficarem tão grandes assim, encolher, mas reconstrua seus índices depois com fatores de preenchimento adequados que permitam um crescimento típico.

Se seu objetivo final é realmente reduzir o tamanho do backup, certifique-se de implementar uma estratégia abrangente de backup para limpar o log de transações e, ao fazer backup do banco de dados, use as opções de compactação.

• Criar um backup completo do banco de dados (SQL Server)
• Backups de log de transações (SQL Server)

Eu não recomendaria um crescimento automático de 5 GB, a menos que você normalmente espere crescer 5 GB com frequência. Caso contrário, você pode ter problemas de desempenho intermitente. Seu tamanho de dados deve primeiro ser definido como o necessário, por exemplo, um ano, e o crescimento automático deve ser definido como um tamanho que você testou não afeta o desempenho operacional. Consulte Não toque nesse botão Encolher banco de dados no SQL Server! por Mike Walsh.

A reconstrução de índices antes da redução faz com que os índices sejam mal definidos. Não é bom reconstruir e encolher. A redução faz com que os índices sejam alterados para recuperar espaço - portanto, a reconstrução antecipada e a redução não fazem sentido. Consulte Quando usar o Auto Shrink de Thomas LaRock.

Não sei se isso funcionaria melhor do que reindexar após a redução, mas outra opção seria criar um novo arquivo de dados com o tamanho adequado e mover todos os dados para isso. Nesse caso, eu faria uma reindexação primeiro para que você saiba qual é o tamanho real dos dados. Um problema é que, se este é o primeiro arquivo no arquivo de dados primário, acho que você não pode esvaziá-lo. Você deve reduzi-lo e depois mover os dados novamente, o que evitaria a reversão da página. No entanto, se você estiver pensando em mudar para o estado sólido, isso não deve fazer uma grande diferença.

Voltando tarde para este caminho. Ainda, ponderamos e testamos o uso de psiquiatra em nossos ambientes de teste por um longo tempo também. De acordo com o tópico, não são momentos em que psiquiatra é uma opção viável. Mas saber quando e como aplicá-lo é vital para a execução adequada, tanto a longo quanto a curto prazo.

Em nosso cenário, recentemente adicionamos inúmeras alterações ao nosso grande banco de dados, incluindo compactação, particionamento, arquivamento e exclusão antiga simples de dados redundantes. Como resultado, a parte usada do nosso arquivo de dados primário caiu para menos da metade do que costumava ser. Mas qual é o sentido de carregar toda essa bagagem? Especialmente porque, ao contrário de alguns artigos da Web, o tamanho dos seus arquivos de dados CORRELA DIRETAMENTE COM A DURAÇÃO DO BACKUP / RESTORE. Isso ocorre porque, diferentemente de muitos artigos, os cenários da vida real carregam mais dados em qualquer página do que apenas as coisas que você talvez tenha removido.

Mais ao ponto, isso abre um ótimo cenário para encolher:

1. Crie um script que encontre todos os objetos e seus grupos de arquivos no seu banco de dados (muitos exemplos online), use-o para criar as cláusulas de descarte, bem como criar definições para cada um de seus índices e restrições.
2. Crie um novo arquivo e grupo de arquivos e torne o padrão.
3. Elimine todos os índices não clusterizados (observe que alguns índices podem ser restrições).
4. Crie seus índices em cluster no novo grupo de arquivos com DROP_EXISTING = ON (que, aliás, é uma operação extremamente rápida e minimamente registrada para começar, em comparação com muitas alternativas).
5. Recrie seus índices não clusterizados.
6. Por fim, SHRINK seu arquivo de dados antigo (geralmente PRIMARY).

Dessa forma, os únicos dados restantes seriam os objetos de sistema, estatísticas, procedimentos e outros itens do sistema do seu banco de dados. O encolhimento deve ser muito, muito mais rápido, e não há necessidade de qualquer manutenção adicional do índice nos seus principais objetos de dados, que foram criados ordenadamente em ordem e risco mínimo para fragmentação futura.