Atualizei recentemente uma tabela no meu banco de dados salvando pequenas imagens em miniatura em byte[]uma varbinary(max)coluna.
Isso melhorou significativamente a velocidade de carregamento de miniaturas (antes eu as carregava do sistema de arquivos), mas devido a um erro no meu código em que as imagens em miniatura estavam sendo redimensionadas, mas não compactadas, as imagens tinham cerca de 140-160 KB de tamanho e criavam uma tonelada de BLOBs. As imagens devem ter cerca de 5 ou 6 KB. Ao testar meu novo código, as imagens devem ter o tamanho correto em torno de 5 ou 6 KB.
Se eu iterar pela tabela e substituir todas as byte[]imagens na varbinary(max)coluna, isso limpará todos esses BLOBs desnecessários?
É compreensível que meu banco de dados tenha crescido significativamente como resultado do meu erro, e estou tentando fazer com que ele volte a ficar pequeno, pois seu tamanho atual está criando problemas com nossos backups.
O que eu entendi dos dados BLOB é que eles foram armazenados separadamente no banco de dados e referenciados na varbinarycélula da minha tabela, então eu não tinha certeza se eu substituísse isso se os dados BLOB associados fossem excluídos. Se eles são excluídos automaticamente, por que o banco de dados não encolheria automaticamente?
Estou testando no Dev Environment, mas depois do último erro que cometi, queria verificar novamente. Vi no SSMS que há opções para Shrinking the Database, então estou supondo que essa seria a tarefa que eu deveria executar após atualizar todos os dados da imagem. Claro que haverá muitos backups durante esse processo também. Estou apenas tentando evitar quaisquer problemas adicionais.
Tenho um banco de dados que foi feito backup de cerca de 50 MB e cresceu para cerca de 3,5 GB após meu erro. Posso substituir os dados por imagens menores, mas não parece que isso seria suficiente porque o banco de dados não encolherá automaticamente.
Sim e Não
O espaço alocado para seu banco de dados do disco permanecerá alocado a ele. Então o tamanho geral do seu banco de dados no disco não mudará.
Isso é por design, porque as operações de redução e crescimento são intensivas em recursos e têm efeitos colaterais como fragmentação. Presume-se que o espaço consumido anteriormente será reutilizado no futuro, então não há sentido em desperdiçar recursos para reduzi-lo automaticamente, afetando potencialmente o desempenho do seu banco de dados (durante a operação).
O espaço alocado será substituído por novos dados à medida que o banco de dados cresce naturalmente.
Encolhendo
Os backups salvam apenas páginas que estão em uso e também podem estar compactadas. Se você apagou os dados que não são mais necessários do banco de dados, os backups serão menores novamente naturalmente, apesar do tamanho do próprio banco de dados.
Mas se você tiver que persistir com o encolhimento de qualquer maneira, então você pode usar a interface do usuário do SSMS ou seguir os documentos
SHRINKpara reduzir o tamanho do banco de dados novamente. Embora isso não deva ser uma ocorrência regular e 3,5 GB seja uma quantidade minúscula de dados para se preocupar.Dizer o que?
Se a velocidade de carregamento de imagens do sistema de arquivos fosse mais lenta do que carregá-las do banco de dados, que é uma abstração que também vive em um arquivo no sistema de arquivos, então você tem problemas mais estranhos que deveria estar resolvendo. Especialmente porque é um pouco antipadrão armazenar imagens no próprio banco de dados, já que elas inflacionam coisas como backups, entre outros motivos.