Tenho uma chave primária clusterizada descompactada. Ela consome 63,6 GB na parte principal do índice clusterizado com 17,9 GB LOB. O único índice não clusterizado da tabela é 57,3 GB também com 17,9 GB LOB. Desejo reconstruir o índice clusterizado offline sem que o banco de dados cresça. Executar sp_spaceusedsem argumentos relata 66 GB em sua coluna "espaço não alocado".
O que eu desejo fazer é possível? Ou reconstruir o índice compactado forçará uma reconstrução do índice não clusterizado, ocupando assim pelo menos 100 GB?
Apesar do meu melhor esforço, não encontrei uma resposta nem na documentação nem no Stack Overflow. Meus experimentos com um pequeno banco de dados que eu tinha à mão sugerem que reconstruir o índice clusterizado não força uma reconstrução dos índices não clusterizados.
não
Reconstruir o índice clusterizado não reconstruirá índices não clusterizados, a menos que você altere as colunas de chave do índice clusterizado.
Você também precisaria reconstruir índices não clusterizados se estivesse adicionando um índice clusterizado a uma tabela de heap ou removendo o índice clusterizado para trocar chaves/RIDs nos índices não clusterizados, dependendo do cenário.
Índices clusterizados e não clusterizados são objetos separados, mas no SQL Server eles são relacionados. Índices não clusterizados herdam colunas de chave de índice clusterizado para facilitar pesquisas, etc. É por isso que algumas alterações de índice clusterizado também necessitarão de reconstruções de índice não clusterizado.
Se você quiser fazer isso sem que o banco de dados do usuário cresça, pode ajudar adicionar a opção SORT_IN_TEMPDB ao seu comando de reconstrução de índice. Dessa forma, você só precisa se preocupar com o grupo de arquivos em que seu índice será criado tendo espaço para o novo índice, em vez do novo índice mais a classificação intermediária. Isso pode aumentar o tempdb, dependendo de sua configuração atual.
Se isso for um problema, você pode reiniciar o SQL Server depois para definir o tempdb de volta para seus tamanhos de arquivo padrão. Como você pode reconstruir um índice clusterizado de ~66 GB offline, estou trabalhando sob a suposição de que ou esta não é uma carga de trabalho 24x7 altamente sensível, ou que esta é uma tabela não essencial.