Reconstruindo índices, o banco de dados agora 10x o tamanho

Eu tenho um banco de dados do SQL Server (2008 R2 SP1) com cerca de 15 GB. Acontece que a manutenção não estava em execução há um tempo, então eu criei um plano de manutenção para reconstruir todos os índices, eles estavam muito fragmentados.

O trabalho terminou e a fragmentação desapareceu, mas agora o banco de dados tem mais de 120 shows! Eu entendo que ele teria usado espaço extra para fazer todas as reconstruções, mas agora que o trabalho está concluído, eu pensaria que todo esse espaço seria espaço livre, mas o espaço livre aparece apenas como 3 shows, portanto 117 shows estão sendo usados mesmo que o trabalho de reconstrução do índice esteja concluído.

Estou muito confuso e poderia usar alguma orientação, tenho o db de volta a um tamanho razoável, não temos espaço em disco para isso.

Desde já, obrigado!

Aqui estão os resultados de ambas as consultas postadas:

log_reuse_wait_desc NOTHING

name    TotalSpaceInMB  UsedSpaceInMB   FreeSpaceInMB
LIVE_Data   152             123             28
LIVE_Log    18939           89              18849
LIVE_1_Data 114977          111289          3688

O terceiro arquivo é um arquivo .ndf, que mostra apenas 3688 em espaço não utilizado, mas 111289 usado em cerca de 15 GB de dados.

Enquanto isso, eu descobri isso, arroto total do cérebro. Eu havia indicado o que eu pensava ser um fator de preenchimento de 90 no trabalho de reconstrução, mas foi redigido como "alterar porcentagem de espaço livre para", portanto, usando um valor de 90 lá, eu estava realmente usando um fator de preenchimento de 10 !! DOH. Não é à toa que cresceu 10 vezes maior. Vou reconstruir com o fator de preenchimento correto e depois encolher. Obrigado a todos pela participação.

A recriação de índices causa espaço extra no banco de dados. Este é um subproduto natural do processo de reindexação - o servidor está construindo uma nova versão, esperançosamente contígua, do índice ao lado da versão atual e, em seguida, descarta a versão atual quando concluída.

Encolher após reindexar é inútil!

Você apenas fragmentará novamente o índice! A redução reduz o espaço livre realocando os dados no banco de dados.

Aqui está um bom artigo de Paul Randal, que, quando trabalhava na Microsoft, estava encarregado do DBCCcódigo, incluindo os psiquiatras, sobre por que você não deveria psiquiatra.

Você deveria ter usado a opção de reconstrução SORT_IN_TEMPDB=ON.

No seu caso, os arquivos de dados reais, onde as tabelas em questão estão localizadas, foram usados ​​para classificar os índices. Muito desse espaço de 120 GB ainda não foi utilizado e será preenchido com dados da página quando necessário.

Você pode ver o status do espaço livre / usado com esta consulta (extraída daqui ):

use [YourDatabaseNameHere]
go

select
    name,
    cast((size/128.0) as int) as TotalSpaceInMB,
    cast((cast(fileproperty(name, 'SpaceUsed') as int)/128.0) as int) as UsedSpaceInMB,
    cast((size/128.0 - cast(fileproperty(name, 'SpaceUsed') AS int)/128.0) as int) as FreeSpaceInMB
from
    sys.database_files

Para reduzir um arquivo de banco de dados específico (dados ou log), você pode ver algumas informações aqui . Um aviso antes disso, liberar espaço não utilizado está demorando bastante para bancos de dados com mais de 100 GB (depende também da velocidade de armazenamento), então deixe-o executar.

Sem outros detalhes, suspeito que você precise fazer um backup do log de transações antes de recuperar seu espaço.

Veja o que select name, log_reuse_wait_desc from sys.databaseslhe diz. Se a coluna log_reuse_wait_desc indicar LOG_BACKUP, não poderá recuperar espaço até que você faça um backup do log de tran.