Reivindicando espaço em disco após remover o campo da tabela

Estou executando o sql 2008 r2 e o db estava funcionando bem e rápido nos últimos 3 anos, até cerca de 3 meses atrás, adicionamos o campo ntext na tabela muito ativa e usada. Agora estamos começando a ficar sem espaço no servidor devido ao enorme tamanho em expansão dessa tabela.

Eu li que encolhendo, não queremos perder a indexação do db porque ele estava trabalhando rápido há anos e não queremos gastar gastos com fragmentação.

Decidimos excluir esse campo e todos os seus valores: Existe uma maneira de excluir o campo ntext e todos os seus valores e liberar espaço sem remover a indexação, sem encolher, sem perder o desempenho do banco de dados?

Estou anexando a saída de consulta de tamanho de banco de dados para mostrar o tamanho da expansão dos últimos 5 meses.

Decidimos excluir esse campo e todos os seus valores: Existe uma maneira de excluir o campo ntext e todos os seus valores e liberar espaço sem remover a indexação, sem encolher, sem perder o desempenho do banco de dados?

Eu recomendaria usar (da BOL:)

DBCC CLEANTABLE
(
    { database_name | database_id | 0 }
    , { table_name | table_id | view_name | view_id }
    [ , batch_size ]
)
[ WITH NO_INFOMSGS ]

DBCC CLEANTABLE recupera espaço depois que uma coluna de comprimento variável é descartada. Uma coluna de comprimento variável pode ser um dos seguintes tipos de dados: varchar, nvarchar, varchar (max), nvarchar (max), varbinary, varbinary (max), texto, ntext, imagem, sql_variant e xml. O comando não recupera espaço depois que uma coluna de comprimento fixo é descartada.

!! ATENÇÃO !! ( use um tamanho de lote cuidadoso - é aconselhável usar esse parâmetro se sua tabela for grande) :

DBCC CLEANTABLE é executado como uma ou mais transações. Se um tamanho de lote não for especificado, o comando processará a tabela inteira em uma transação e a tabela será bloqueada exclusivamente durante a operação . Para algumas tabelas grandes, o comprimento da transação única e o espaço de log necessário podem ser muito. Se um tamanho de lote for especificado, o comando será executado em uma série de transações, cada uma incluindo o número especificado de linhas. DBCC CLEANTABLE não pode ser executado como uma transação dentro de outra transação.

Esta operação está totalmente registrada.

Um simples repro provará que DBCC CLEANTABLEé melhor que SHRINKING (e não se preocupe com fragmentação :-)

-- clean up
drop table dbo.Test

-- create test table with ntext column that we will drop later
create table dbo.Test (
    col1 int
    ,col2 char(25)
    ,col3 ntext
    );

-- insert  1000 rows of test data
declare @cnt int;

set @cnt = 0;

while @cnt < 1000
begin
    select @cnt = @cnt + 1;

    insert dbo.Test (
        col1
        ,col2
        ,col3
        )
    values (
        @cnt
        ,'This is a test row # ' + CAST(@cnt as varchar(10)) + 'A'
        ,REPLICATE('KIN', ROUND(RAND() * @cnt, 0))
        );
end

--drop the ntext column
ALTER TABLE dbo.Test DROP COLUMN col3 ;

--reclaim the space from the table
-- Note that my table is only having 1000 records, so I have not used a batch size
-- YMMV .. so find a maintenance window and you an appropriate batch size 
-- TEST TEST and TEST before implementing in PROD.. so you know the outcome !!
DBCC CLEANTABLE('tempdb', 'dbo.Test') ;

Para a maioria das peças, estou consultando o interior do mecanismo de armazenamento de Paul Randall série de blogs de .

A única maneira de recuperar o espaço não utilizado dos arquivos de banco de dados no SQLServer é usando o comando DBCC SHRINK, que realoca os dados nos arquivos de banco de dados liberando páginas e depois de removê-los do mapa Allcation Global os remove do arquivo de banco de dados. Essa operação é lenta, cria fragmentação no banco de dados e é ainda mais lenta ao lidar com páginas LOB, pois elas são armazenadas como listas vinculadas nos arquivos do banco de dados.

Como você está eliminando a coluna NTEXT, terá que aguardar o processo de limpeza fantasma para eliminar os dados antes de encolher.

Agora, ter muito espaço livre nos arquivos do banco de dados não causará nenhum dano; se você tiver espaço em disco, a compactação de backup cuidará do espaço livre nos arquivos.

Se você deseja absolutamente diminuir os arquivos, pode criar um novo grupo de arquivos com o banco de dados e torná-lo o padrão e, em seguida, mover as tabelas para o novo grupo de arquivos, mas isso pode levar tempo e causar tempo de inatividade. Eu usei a técnica explicada aqui por Bob Pusateri com bons resultados.

Deseja reduzir os arquivos do banco de dados porque você precisa desse espaço para outros bancos de dados / arquivos não DB ou porque está tendo problemas com esse banco de dados ficando sem espaço?

Se for o segundo, talvez você não tenha um problema tão grande quanto imagina. Se estou correto, seu problema é quando o banco de dados precisa crescer para ganhar espaço adicional para novos dados. Depois de remover a coluna, todo o espaço ocupado por essa coluna será liberado para que novas linhas sejam adicionadas às tabelas no banco de dados. Isso significa que levará mais tempo para que seu banco de dados precise crescer. Nesse meio tempo, eu recebia algum espaço adicional para sua unidade de dados. A maioria dos bancos de dados cresce com o tempo e é bom ter uma margem saudável de espaço livre na unidade.

Eu criaria uma tabela de espelhamento sem a coluna incorreta, copiaria todos os dados nessa tabela, soltar o original e renomeá-la.