(Um pouco de contexto primeiro porque, embora eu espere que as perguntas sejam gerais o suficiente, sempre nos dizem que as soluções dependem do contexto. Não há DBA neste cenário.)
Este é um banco de dados [de escritório muito pequeno], usado 5 dias por semana, 8 horas por dia, por um punhado de clientes executando um programa que faz principalmente listagens e um pequeno número de inserções/atualizações a cada vez.
O banco de dados é um único arquivo, possui cerca de 25 tabelas, e atualmente roda até 20 GB, sendo 19 deles utilizados pela mesma tabela, que é aquela com imagecoluna blob().
Há um backup diário do arquivo de dados, mas em todos os seus mais de 10 anos nunca houve nenhuma manutenção, além de movê-lo de servidor para servidor - começou no SQL Server 2005 / Windows SBS 2003 ou algo assim, mudou 3 vezes, e agora está no SQL Server 2019 / Windows 2019.
Achei os 20 GB demais (não é problema para backups, o sistema é rápido o suficiente), mas quando vi a quantidade de registros na tabela com o blob concluí que são cerca de 300 KB por blob, o que parece justo . Seria um ótimo candidato para compactação ou armazenamento fora do banco de dados, mas eu não controlo o programa que usa o banco de dados.
O índice dessa tabela é 96% fragmentado. O conselho padrão seria fazer uma reconstrução e atualizar as estatísticas, mas tenho várias perguntas e aqui estão elas, finalmente, espero que sejam úteis a todos:
A reconstrução do índice não corre o risco de inflar o tamanho do arquivo de banco de dados em um grande fator? (mesmo que nunca tenha sido reduzido e o tamanho atual pareça estar preenchido com dados válidos em vez de vazios) Não estou interessado em aumentar o banco de dados para, digamos, 25 GB, especialmente porque os dados raramente são excluídos deste banco de dados , apenas adicionado. Eu poderia tolerar um aumento de 1 ou 2 GB; meu problema é que eu não tenho idéia do que esperar.
Dado que tenho muito tempo ocioso para usar, há uma desvantagem em apenas fazer uma reorganização? Pela descrição, parece uma operação menos intrusiva e apenas menos recomendada porque é um processo mais antigo e mais lento durante o qual o banco de dados será menos responsivo.
Posso combinar uma reorganização com a atualização das estatísticas ou essa pergunta revela que eu realmente não tenho ideia de como os índices funcionam?
Dado o padrão de uso do banco de dados, é um risco não ter backups dos logs e afins?
A reconstrução do índice não corre o risco de inflar o tamanho do arquivo de banco de dados em um grande fator? (mesmo que nunca tenha sido reduzido e o tamanho atual pareça estar preenchido com dados válidos em vez de vazios) Não estou interessado em aumentar o banco de dados para, digamos, 25 GB, especialmente porque os dados raramente são excluídos deste banco de dados , apenas adicionado. Eu poderia tolerar um aumento de 1 ou 2 GB; meu problema é que eu não tenho idéia do que esperar.
Dado que tenho muito tempo ocioso para usar, há uma desvantagem em apenas fazer uma reorganização?
Posso combinar uma reorganização com a atualização das estatísticas ou essa pergunta revela que eu realmente não tenho ideia de como os índices funcionam? Sim -
Pela descrição, parece uma operação menos intrusiva e apenas menos recomendada porque é um processo mais antigo e mais lento durante o qual o banco de dados será menos responsivo.
As reorganizações desfragmentam o nível de folha de índices clusterizados e não clusterizados reordenando fisicamente as páginas de nível de folha para corresponder à ordem lógica (menos intrusiva e é feita online)
Reconstrói descarta e reconstrói os índices (o mais intrusivo e de bloqueio pode ocorrer e pode ser feito offline ou online, dependendo da sua edição)
Ambos removem a fragmentação, mas as reconstruções são mais eficientes
Dado o padrão de uso do banco de dados, é um risco não ter backups dos logs e afins?
Reconstruir Índice RebuildReorgIndex