Perdoe-me, mas sou muito novo como DBA, pois acabei nessa função por necessidade :)
Atualmente, estou trabalhando na redução do tamanho de vários bancos de dados. Anteriormente, fiz uma pergunta aqui sobre como fazer isso e usei o comando DBCC Shrinkfile. Funcionou bem para meu primeiro banco de dados, pois o tamanho do arquivo foi significativamente reduzido. No entanto, quando passei para o segundo banco de dados que precisa reduzir o tamanho do arquivo, a consulta DBCC Shrinkfile foi executada no fim de semana e ainda não foi concluída. Fiz algo de errado?
Eu testei o comando DBCC Shrinkfile neste banco de dados antes, e mesmo reduzir apenas 10 MB levou cerca de 10 ou 20 minutos. Estou esquecendo de algo? Há algo que devo fazer antes?
Informações adicionais:
- O tamanho do banco de dados que estou tentando reduzir é de 1,78 TB (defino a consulta para reduzir para 1 TB) com 55% de espaço livre.
- Eu defini o modelo de recuperação como Simples.
- Link para minha pergunta anterior
- SQL Server e SSMS 2017
- O servidor está em uma VM, CPU Xeon e5 de 8 núcleos, 24 GB de RAM e está sendo executado no disco rígido.
Gostaria de enfatizar o que JD menciona no comentário, que você só deve encolher em circunstâncias muito especiais. Você descobriu um dos motivos - pode levar uma eternidade, quase ao ponto de parecer que não está funcionando.
A comparação entre os dois sistemas está parcialmente (mas apenas parcialmente) relacionada à quantidade de dados que você possui. Considere adicionar isso ao seu post. Não o tamanho do arquivo, mas quantos dados você tem lá. Esse é o pior cenário de quantos dados devem ser movidos do final do arquivo para o início do arquivo. Mas mesmo isso depende de onde no arquivo você tem espaço livre antes da redução.
Meu palpite, porém, é que esse banco de dados sofre de um dos itens abaixo:
Bloqueio, onde o psiquiatra está sendo bloqueado. Isso é fácil de verificar (sp_whoisactive ou o que for de sua preferência).
Tabelas de pilha. Lembre-se de que, para cada página movida, todo índice nc deve ser atualizado, para cada linha dessa página. Um exemplo simples que tive com uma tabela clusterizada versus uma tabela heap me deu 50 vezes mais tempo de redução com o heap. Você pode investigar quantas tabelas de pilha você tem e considerar se elas devem ser agrupadas em primeiro lugar ou podem ser agrupadas para o processo de redução. Obviamente, se a tabela for grande, a conversão de heap para cluster levará muito tempo.
páginas LOB. Imagine o SQL Server movendo uma página de lob. Ele terá que varrer a tabela inteira para ver qual(is) linha(s) estava(ão) apontando para esta página para que possa modificar o endereço da página para a página LOB. Para. Cada. Mudou-se. LOB. Página. Deixe isso afundar. Lembre-se de que existem vários tipos de lob (varbinary(max), varchar(max), nvarchar(max), xml, geografia e geometria). Não há muitas opções aqui, mas para exportar os dados do lob para um grupo de arquivos diferente, reduza e volte novamente, ou algo assim.