Vamos visualizar essa situação. Com o script abaixo criamos e populamos uma tabela comum:
SET NOCOUNT ON
CREATE TABLE Anotacao(
Id_Anotacao INT IDENTITY(1,1),
Dt_Anotacao DATETIME DEFAULT(getdate()),
Ds_Anotacao TEXT,
CONSTRAINT PK_Anotacao PRIMARY KEY(Id_Anotacao)) — Índice clustered
GO
INSERT INTO Anotacao(Ds_Anotacao)
SELECT REPLICATE(‘A’,4000)
GO 10000
Em seguida, executando o comando:
exec sp_spaceused Anotacao
Temos o seguinte resultado:
Como podemos ver, a tabela possui mais de 40 MB de dados.
Agora excluímos o campo com o comando abaixo:
ALTER TABLE Anotacao
DROP COLUMN Ds_Anotacao
Mais uma vez, executando a sp_spaceused temos o resultado abaixo:
exec sp_spaceused Anotacao
Como assim? O resultado não mudou?
Nesse momento abri uma thread no fórum do technet e após trocar alguns posts com o Gustavo Aguiar (Blog), obtive uma resposta muito esclarecedora:
“Olá Fabrício,
Antes da exclusão da coluna, o espaço estava alocado e os dados organizados. Se você excluir a coluna, para que o espaço seja imediatamente liberado, o SQL Server teria que reorganizar tudo. Para reorganizar, fatalmente haveria um trabalho de IO envolvido bem como uma possível indisponibilidade. Como o SQL Server não sabe a criticidade da tabela, ele opta por não reorganizar e manter o espaço alocado mesmo após a exclusão da coluna.
O espaço será liberado assim que você promover um REINDEX do índice clustered. Se a tabela não possuir um, será necessário criar e depois removê-lo (a menos que seja SQL Server 2008).”
Pronto, acredito que agora tudo já esteja esclarecido para vocês. Vamos testar?
Basta dar um REBUILD no índice:
ALTER INDEX PK_Anotacao ON Anotacao REBUILD
Agora, executando a sp_spaceused novamente, temos o seguinte resultado:
Agora podemos visualizar o espaço que ganhamos com a exclusão do campo. O tamanho da tabela diminuiu 40 MB.
Fonte: Blog Fabrício Lima