por que a reconstrução online em um índice clusterizado de chave primária ocupa quase o mesmo espaço do tamanho do índice não clusterizado que é intocado.
Detalhes:
- Temos uma tabela com índice clusterizado de chave primária (tipo bigint) de tamanho de índice de 7 GB.
- Temos outro índice filtrado não clusterizado na mesma tabela (tipo varchar(36)) de tamanho de índice de quase 1,5 TB.
- A reconstrução online no índice clusterizado de chave primária está consumindo quase 1,6 TB do tamanho do log de transações. Opções usadas para reconstrução - (DATA_COMPRESSION = PAGE, ONLINE = ON, SORT_IN_TEMPDB = ON)
- Outra observação, o índice anterior foi criado sem compressão, não tenho certeza se é isso que está causando um crescimento tão grande.
- Alguém poderia por favor lançar alguns internos sobre isso?
O índice clusterizado é a tabela. Inclui todas as colunas. É (basicamente) impossível que o índice clusterizado seja menor do que qualquer índice não clusterizado. Você provavelmente olhou apenas o tamanho da coluna de chave clusterizada ou apenas o nível não folha ao ler esse tamanho de 7 GB.
Portanto, se você reconstruir o índice clusterizado, reconstruirá todas as colunas - incluindo a configuração de compactação. A reconstrução do índice clusterizado no final copia os dados para um novo local e depois de concluído, remove os dados do local antigo.
Se você estivesse em 2017, poderia fazer a reconstrução de índice recuperável, que permite pausar a reconstrução, esvaziar o log e retomar a reconstrução novamente.
REBUILD é uma operação transacional atômica, portanto, isso é esperado. Se você cancelasse, precisaria das informações registradas para reverter.
Uma alternativa possível é configurar uma tabela de cópia com a compactação ativada e depois copiar as linhas em lotes - é claro que você ainda ocupa espaço extra no arquivo de dados. Você pode usar sp_rename para alterar o nome da tabela de cópia quando terminar