Temos uma tabela em um banco de dados SQL do Azure que costumava ter uma coluna nvarchar(max) armazenando arquivos PDF. (As maravilhas dos desenvolvedores externos.) A mesa cresceu para 156 GB. Possui 476.000 linhas. Depois de mudar a lógica, não precisamos mais da coluna pdf. A única maneira razoável de se livrar dos dados contidos nela era descartar a coluna e recriá-la (caso algum processo estranho ainda estivesse fazendo referência a ela).
No entanto, o tamanho da tabela ainda é relatado como 156 GB. A tabela de backup que acabei de criar (SELECT INTO) tem 128 MB, então esse parece ser o tamanho real dos dados.
Deixei uma reconstrução de índice (ONLINE) ser executada durante a noite no índice PK clusterizado. Ele falhou com um erro de TCP entre 8 e 12 horas. O índice ainda está 95% fragmentado, o tamanho ainda é relatado como 156 GB.
Existe uma explicação para que isso seja tão lento? Existe uma maneira melhor? Banco de dados de produção, tabela usada por um site, tem que estar acessível, então não pode fazer isso OFFLINE a menos que demore menos de 10 minutos - o que ninguém pode garantir.
Posso simplesmente construir todos os índices na tabela de backup, eliminar a tabela original e renomear o backup? Isso parece arriscado (pequeno risco de perder um registro criado na hora errada).
Estou tentando fazer o Azure perceber que não é mais usado. Alocado, estou bem com isso. Usado, nem tanto:
A tabela em questão:
Novamente, o problema não é o espaço reservado, mas o espaço usado.