Trabalhar com tabelas/indices fragmentados pode ajudar muito em situações como:

• Tabelas/indices grandes com mais de 32 GBytes ou 16 milhões de registros
• Performance de I/O para acesso a dados de Históricos
• Performance de I/O paralelo (set pdqpriority) em diferentes discos (fisicos).
• Expurgar dados antigos do banco sem necessidade de realizar longas paradas ou sobrecarga de processo do banco.
• Melhorar a eficiencia da utilização do buffer com paginas que contém registros mais recentes ou que por algum critério são mais utilizados pela aplicação.

Porém alguns cuidados são necessário na administração e criação destas tabela.

• Para começar sempre tenha certeza de que o critério especificado está funcionando conforme o esperado.
  Se for a primeira vez que estiver particionando a tabela, antes, crie ela com um nome diferente, faça inclusões manuais e monitore os dbspaces para ter certeza de os registros estão indo para seus devidos lugares. Depois teste se os selects estão excluindo as partições desnecessárias.
  
• Na expressão de fragmentação, muito cuidado se for utilizado os operadores IS NULL , IS NOT NULL ou !=
  Estes operadores enganam pois não excluem a partição da busca em SQLs. Não gerando assim a exclusão daqueles dados de uma busca.
  Como alternativa pessoalmente eu escrevo um pouco mais e refaço a lógica sem utilizar estes operadores.
  
• Ficar atento ao limite de registros e tamanho de uma partição. Se estiver trabalhando com grandes tabelas poderá ocorrer o risco de atingir este limite a qualquer hora. Para verificar a situação de uma tabela pode-se utilizar o comando oncheck -pt [dbspace:tabela]
• Tomar os devidos cuidados com aplicações que utilizam o recurso de paralelismo (set pdqpriority) em tabelas fragmentadas, pois a utilização indevida deste recurso pode ser traiçoeiro e acabar sobrecarregando alguns pontos como controladora de disco, buffers do banco, I/O de disco e acabar atrapalhando mais do que ajudar.