Acabamos de mudar para um novo método de armazenamento de imagem para nosso aplicativo, o que significa que não precisamos mais armazenar matrizes de bytes de imagem no banco de dados.
Para esse fim, excluí (por meio de uma UPDATEdeclaração) cerca de matrizes de 19k bytes contendo imagens de alta resolução (cerca de 8 GB) de uma coluna em uma única tabela. Sem as imagens, não espero que o banco de dados volte ao tamanho que tem agora. Novamente, observe que não excluí linhas aqui, mas apenas defini valores de campo como NULL.
Outras informações:
- O tipo de coluna era VARBINARY
- Não havia índice na coluna.
Perguntas
- Devo apenas ir em frente e reduzir o banco de dados e, em seguida, reconstruir os índices para essa tabela?
- A maioria dos cenários que li envolve encolher após uma
DELETEdeclaração. Não excluí nenhuma linha, apenas defini o valor do campo como null para todas as linhas. Isso muda alguma coisa? - A coluna agora está obsoleta e podemos apenas excluí-la da tabela; Acredito que isso exigirá que a tabela seja recriada. Devo reduzir o banco de dados antes ou depois de excluir a coluna?
Edit: Outra possibilidade me ocorreu. Com os dados da imagem desaparecidos, talvez seja melhor apenas escrever um script para reconstruir completamente o banco de dados inteiro, sem a coluna de imagem da coluna. Pensamentos?
Se o objetivo for tornar os backups menores, reduzir o(s) arquivo(s) de dados não ajudará a atingir esse objetivo neste caso, porque todas as páginas que continham esses
maxdados eram páginas LOB que deveriam ser desalocadas (possivelmente exigindo uma reconstrução).Portanto, a menos que sua unidade esteja literalmente sem espaço, não vejo motivo para reduzir o arquivo de 8 GB, a menos que você esteja 100% confiante de que nunca aumentará esse tamanho novamente.
Observe que, ao reduzir um arquivo de dados, você pode aumentar a fragmentação, o que pode diminuir o desempenho de leitura, afetar o uso da memória e reduzir a simultaneidade. A reação automática é reconstruir os índices, o que corrige a fragmentação, mas aumenta o tamanho do arquivo para dar espaço às novas cópias do índice. Quando a reconstrução é concluída, essas páginas são liberadas, mas o arquivo de dados não encolhe magicamente novamente, então você volta ao ponto de partida e não ganha nada.
Se você excluir 95% dos dados, o tamanho do backup diminuirá, quer você reduza o(s) arquivo(s) MDF ou não. Um arquivo MDF é apenas um contêiner; seu tamanho não afeta o backup. Os dados reais afetam o backup. Mais precisamente, o número de páginas alocadas com quaisquer dados afeta o backup (e é por isso que uma reconstrução de tabela após uma grande exclusão pode gerar uma diferença no tamanho do backup).
Isso é fácil de testar por si mesmo, mas lembre-se de que o impacto observado dependerá de muitas coisas, incluindo tipos de dados, fragmentação, espaço livre e uma série de outras variáveis. Basta observar o tamanho de um backup completo após cada uma dessas etapas:
NULL.NULL(e depois de descartar a coluna, talvez).Minha teoria é que, em quase todos os casos em que consigo pensar, não haverá diferença tangível entre o tamanho do backup após 3. e após 4.
Uma variável diferente com a qual você pode se preocupar é o tempo necessário para restaurar esse backup em outro sistema, que dependerá do tamanho do(s) arquivo(s) MDF apenas nos seguintes casos:
O primeiro é fácil de corrigir, este é apenas um direito que você pode conceder à conta de serviço. O segundo também deve ser fácil de corrigir: adicione espaço em disco. Não há razão para sacrificar seu sistema primário porque seu sistema secundário é inadequado.