Valor correto para o fator de preenchimento de índices clusterizados com chaves de identidade substitutas

Eu tenho uma tabela grande que tem um índice de cluster com uma chave primária de identidade. Estou decidindo o valor correto para o fator de preenchimento desta tabela para minimizar as divisões de página. Mantemos índices usando um script executado diariamente, que mede a fragmentação e executa as ações apropriadas. A tabela contém colunas de comprimento variável.

Meu primeiro pensamento foi defini-lo como 100 (já que os registros devem ser gravados apenas no final da tabela), mas presumo que alterações nas colunas de comprimento variável também possam causar divisões de página, então agora estou indo para 90.

Qualquer conselho apreciado.

Depende

É um ato de equilíbrio. Se sua tabela for de leitura intensiva, com poucas atualizações ou exclusões, o padrão (que é 100) deve estar ok.

Se sua tabela exige muita gravação, com muitas atualizações, um valor abaixo de 80 pode ser mais apropriado.

Não existe uma fórmula mágica para essas coisas. (AFAIK, se houver, por favor me avise) A melhor coisa a fazer é ter um ambiente de teste, ter alguma carga de trabalho para testar. Faça as alterações e veja o desempenho do seu banco de dados com a carga de trabalho.

Nick está praticamente correto.

Se você fizer atualizações que aumentem o tamanho de um registro em páginas compactadas, causará divisões de páginas, mas, além disso, com uma chave primária de identidade, nada causará divisões de páginas no índice clusterizado.

(Apesar de dizer isso, existem 5 tipos de divisões de página que o Mecanismo de Armazenamento pode fazer, e nem todos causam fragmentação e movimentação de dados - o que você obtém ao inserir valores de identidade cada vez maiores é uma divisão no final da página. Eu discordo ...)

Ajudei muitos clientes com isso e escrevi o BOL em torno de tudo - se você quiser apenas escolher um valor como o que está em jogo, 70% obteve o maior sucesso. Como Nick diz, monitore e ajuste conforme apropriado.

Escolher um fator de preenchimento para qualquer índice é um ato de equilíbrio da quantidade de atividade que leva a plenitude da página para 100% e com que frequência você pode executar uma ação corretiva para redefinir o fator de preenchimento. Você precisa pensar em quanto espaço será inicialmente "desperdiçado" nas páginas se definir o fator de preenchimento muito baixo, como 50%, mas novamente vi que isso é apropriado em alguns casos.

Você também deve considerar como o índice será usado. Se for apenas para pesquisas singleton, você poderá se livrar de um fator de preenchimento menor e mais tempo entre reconstruir / desfragmentar, pois não perderá muito IO / memória por ter muitos índices clusterizados escassamente preenchidos na memória. Para realizar varreduras de grande alcance, é recomendável aumentar o fator de preenchimento um pouco, para aumentar a eficiência de E / S e memória.

Há também a pergunta OLTP vs DW - geralmente um DW é imutável, portanto os índices teriam um fator de preenchimento de 100%. OLTP é a parte mais difícil.

Depois de classificar o índice em cluster, lembre-se de que os não clusterizados também precisarão de atenção, pois provavelmente serão fragmentados.

Ao redefinir o fator de preenchimento, lembre-se de que você pode escolher entre reconstruir e desfragmentar. DBCC INDEXDEFRAG / ALTER INDEX ... REORGANIZE pode redefinir o fator de preenchimento em alguns casos para índices que não estão muito fragmentados.

Espero que isto ajude!

(Desculpe pela 'resposta excessiva' - um dos meus botões de atalho, depois de escrever o código :-)