Diminui o arquivo de dados do SQL Server, mas não todos de uma vez?

Question

Eu tenho um arquivo de banco de dados atualmente com 150 GB, mas apenas 75 GB está sendo usado - é porque movi todos os índices (os outros 75 GB) para um novo arquivo de dados. Eu gostaria de recuperar pelo menos parte do espaço deste arquivo de dados, mas quando eu tentar encolher o arquivo, ele "executa" indefinidamente, eventualmente sendo cancelado por causa de uma interrupção na rede ou algo fora do meu controle (após um dia de corrida). Mesmo usando o recurso "encolher para tamanho específico" e especificando que ele apenas reduza 10MB, nunca parece retornar - ele apenas fica até o processo ser interrompido.

Existe outra maneira de recuperar esse espaço, mesmo um pouco de cada vez?

EDIT: Alguém postou um link explicando porque eu não deveria encolher meu banco de dados. Eu entendo, e quero encolher de qualquer maneira. Espaço em disco é um prêmio neste servidor, e o banco de dados não expandirá novamente para esse espaço não utilizado por um tempo muito longo - como afirmei anteriormente, eu migrei índices para fora do arquivo de dados para liberar esse espaço, então agora é desperdiçado .

    

Answer 1

Não, usar DBCC SHRINKFILE ('filename', target_size) é o jeito certo de fazer isso.

Se você quiser fazer isso em "partes", pode definir tamanhos de destino progressivamente menores ou apenas deixá-lo rodar o máximo que puder antes de ser cancelado.

Alguns comentários:

• Coloque um tamanho de destino razoável, com alguma margem de espaço livre permitido. Talvez 90GB total para 75GB de dados?
• Enquanto a redução estiver em execução, verifique o monitor de atividade para ver se o SPID está sendo bloqueado. Se houver uma transação aberta em uma página no final do arquivo, a redução não poderá ser movida até que a transação seja confirmada ou revertida.
• O spid está realmente progredindo? (Os números de CPU e IO estão mudando)
• O Shrink pode levar muito, muito tempo, mas deve salvar seu progresso (o que significa que ele move 1 página por vez e, quando é cancelado, todos os movimentos concluídos da página já foi feito)
• Depois de cancelar o encolhimento, tente fazer um DBCC SHRINKFILE ('filename', TRUNCATEONLY) . Deve recuperar todo o espaço já liberado no final do arquivo (veja meu ponto anterior)
• Se você ficar desesperado, tente reiniciar o SQL no modo de usuário único, para saber que nada mais está funcionando contra o banco de dados nesse momento (obviamente, isso pode ser impossível em um servidor prod)
• Depois de concluir a redução, certifique-se de fazer uma reindexação completa no banco de dados para eliminar a fragmentação criada pela redução. Isso pode recuperar parte do espaço que você acabou de liberar.
• Se você ainda não conseguir que o psiquiatra funcione, confira algumas das discussões sobre esta pergunta SO . Existem aparentemente algumas situações em que os psiquiatras podem não progredir.

Answer 2

Nós abordamos várias opções em nosso ambiente:

1. Se as tabelas antigas puderem ser enfrentadas, crie novas tabelas em um novo grupo de arquivos e padronize o banco de dados para ele. Hora extra, solte as tabelas antigas até que o grupo de arquivos anterior esteja vazio. Então solte isso.
2. Se as tabelas antigas não puderem ser enfrentadas, mas contiverem dados históricos que podem ser offlines por várias horas, crie uma nova tabela vazia apontando para um novo grupo de arquivos. Troque as tabelas e comece a copiar as linhas da tabela antiga para a nova em lotes. Isso pode causar fragmentação.
3. Emita uma opção DBCC SHRINKFILE com EMTPYFILE e o DB moverá todos os objetos para o novo arquivo. Então você pode soltar o arquivo antigo. Isso pode levar muito tempo, no entanto.
4. Recrie o índice clusterizado (chave primária com DROP_EXISTING) de todas as tabelas para o novo grupo de arquivos. Isso bloqueará a tabela embora.

Boa sorte

    

Answer 3

Se você não quiser simplesmente recuperar o espaço (o qual você especificamente se recusou a querer fazer), mas insistir em tentar encolher o banco de dados, espere que isso leve muito tempo e que a expansão do seu log de transações cubra todo o espaço que você recuperou do banco de dados. Como bônus, assista ao desempenho do seu banco de dados. Se Paul Randal não puder convencer você (Que JL comentou com, mas eu vou repostar aqui: Por que você não deve encolher seus arquivos de dados esse encolhimento é uma idéia terrível, não tenho certeza que alguém possa. Com alguma redução de sorte será removido do servidor SQL (ou pelo menos ser mudado assim funciona como Paul recomenda) na próxima revisão.