Ontem recebi um e-mail de um de nossos fornecedores mencionando que havia problemas de desempenho com seu aplicativo.
Ainda não sei quais são os problemas, mas a solução que eles propõem é reduzir o banco de dados (porque há muito espaço livre). Pelo meu conhecimento, isso não pode resultar em uma melhoria de desempenho, mas aparentemente eles tiveram sucesso com esse método ao aplicar em outros clientes.
A maneira como eu acho que o encolhimento acontece é movendo as páginas de trás para a frente do arquivo e compactando o banco de dados e causando uma fragmentação massiva.
É possível que as varreduras de intervalo aproveitem a compactação do banco de dados?
Ou existem outros casos extremos que podem se beneficiar da redução de um banco de dados?
O forte conselho geral é nunca encolher , é claro.
Ainda assim, a questão aqui é: o encolhimento pode melhorar o desempenho?
Bem, talvez. A consolidação de todas as páginas usadas no início de cada arquivo pode trazer benefícios para leituras de aumento e ter efeitos de cache favoráveis em vários níveis, inclusive na camada de armazenamento. Além disso, a redução removerá todas as páginas vazias das tabelas de heap em vez de movê-las, de modo que pode ajudar diretamente no desempenho da verificação da tabela de heap.
Shrink também verifica se uma página b-tree ou heap deve ser recompactada, o que pode ser relevante se a compactação de dados estiver em uso. Shrink também nunca gera ponteiros de encaminhamento, portanto, encolher páginas de heap pode resultar em "unforwarding" e remoção de stub.
Ainda seria melhor tomar medidas mais eficazes para resolver qualquer que seja a causa específica do mau desempenho. Isso requer entender o problema e saber como corrigi-lo, em vez de tentar (cegamente) coisas que pareciam funcionar antes.