Concordando com Marc e Unkown acima ... 6 índices no índice clusterizado é demais, especialmente em uma tabela que possui apenas 14 colunas. Você não deve ter mais de 3 ou 4, se isso, eu diria 1 ou talvez 2. Você pode saber que o índice clusterizado é a tabela real no disco, então quando um registro é inserido, o mecanismo de banco de dados deve classificá-lo e coloque-o em seu lugar organizado classificado no disco. Índices não clusterizados não são, eles suportam 'tabelas' de pesquisa. Meus VLDBs estão dispostos no disco (CLUSTERED INDEX) de acordo com o 1º ponto abaixo.

1. Reduza seu índice clusterizado para 1 ou 2. As melhores opções de campo são a IDENTIDADE (INT), se você tiver uma, ou um campo de data no qual os campos estão sendo adicionados ao banco de dados ou algum outro campo que seja um tipo natural de como seus dados estão sendo adicionados ao banco de dados. O ponto é que você está tentando manter esses dados na parte inferior da tabela ... ou tê-los dispostos no disco da melhor maneira (90% +) que você lerá os registros. Isso faz com que não haja reorganização em andamento ou que seja necessário um e apenas um hit para obter os dados no lugar certo para a melhor leitura. Certifique-se de colocar os campos removidos em índices não clusterizados para não perder a eficácia da pesquisa. Eu NUNCA coloquei mais de 4 campos nos meus VLDBs. Se você tiver campos que estão sendo atualizados com frequência e estão incluídos em seu índice clusterizado, OUCH, isso reorganizará o registro no disco e causará uma fragmentação COSTLY.
2. Verifique o fator de preenchimento em seus índices. Quanto maior o número do fator de preenchimento (100), mais cheias serão as páginas de dados e as páginas de índice. Em relação a quantos registros você possui e quantos registros você está inserindo, você alterará o fillfactor # (+ ou -) de seus índices não clusterizados para permitir o espaço de preenchimento quando um registro for inserido. Se você alterar seu índice clusterizado para um campo de dados sequencial, isso não importará tanto em um índice clusterizado. Regra prática (IMO), fator de preenchimento 60-70 para gravações altas, 70-90 para gravações médias e 90-100 para leituras altas/gravações baixas. Ao baixar seu fator de preenchimento para 70, significará que para cada 100 registros em uma página, 70 registros serão gravados, o que deixará espaço livre de 30 registros para registros novos ou reorganizados. Ocupa mais espaço, mas com certeza é melhor do que ter que DESFRAGURAR todas as noites (veja 4 abaixo)
3. Verifique se as estatísticas existem na tabela. Se você deseja varrer o banco de dados para criar estatísticas usando o "sp_createstats 'indexonly'", o SQL Server criará todas as estatísticas em todos os índices que o mecanismo acumulou como estatísticas obrigatórias. Não deixe de fora o atributo 'indexonly' ou você adicionará estatísticas para cada campo, isso não seria bom.
4. Verifique a tabela/os índices usando DBCC SHOWCONTIG para ver quais índices estão ficando mais fragmentados. Não vou entrar em detalhes aqui, apenas saiba que você precisa fazer isso. Em seguida, com base nessas informações, altere o fator de preenchimento para cima ou para baixo em relação às alterações que os índices estão sofrendo e com que rapidez (ao longo do tempo).
5. Configure um agendamento de trabalho que fará online (DBCC INDEXDEFRAG) ou offline (DBCC DBREINDEX) em índices individuais para desfragmentá-los. Atenção:não faça DBCC DBREINDEX em uma tabela tão grande sem que seja durante o tempo de manutenção, pois isso derrubará os aplicativos ... especialmente no CLUSTERED INDEX. Voce foi avisado. Teste e teste esta parte.
6. Use os planos de execução para ver quais SCANS e FAT PIPES existem e ajuste os índices, depois desfragmente e reescreva os procs armazenados para se livrar desses pontos de acesso. Se você vir um objeto RED em seu plano de execução, é porque não há estatísticas nesse campo. Isso é ruim. Esta etapa é mais "arte do que ciência".
7. Em horários fora de pico, execute UPDATE STATISTICS WITH FULLSCAN para fornecer ao mecanismo de consulta o máximo de informações possível sobre as distribuições de dados. Caso contrário, faça as ESTATÍSTICAS DE ATUALIZAÇÃO padrão (com varredura padrão de 10%) nas tabelas durante a semana ou com mais frequência conforme achar adequado com suas observações para garantir que o mecanismo tenha mais informações sobre as distribuições de dados para recuperar os dados com eficiência.

Desculpe, isso é tão longo, mas é extremamente importante. Eu só lhe dei aqui informações mínimas, mas ajudarão muito. Há alguns pressentimentos e observações que entram nas estratégias usadas por esses pontos que exigirão seu tempo e testes.

Não há necessidade de ir para a edição Enterprise. Eu fiz isso para obter os recursos mencionados anteriormente com o particionamento. Mas eu fiz ESPECIALMENTE para ter recursos de mult-threading muito melhores com pesquisa e DESFRAGAÇÃO e manutenção online... Na edição Enterprise, é muito melhor e mais amigável com VLDBs. A edição padrão também não lida com DBCC INDEXDEFRAG com bancos de dados online.