Faça com que o MS SQL Server libere espaço em disco

Uma tabela de banco de dados mal gerenciada cresceu e se tornou enorme. 48 + shows de discos órfãos. Estou tentando limpá-lo e colocar meu disco rígido perigosamente cheio de volta ao estado normal. Excluirei aproximadamente 400 milhões de registros desta tabela. Isso está sendo executado enquanto eu digito. Percebo que não estou vendo nenhuma queda no espaço no disco rígido, mas estou vendo a memória cair nas consultas da tabela do sistema, estou executando para obter o tamanho da tabela. O banco de dados está usando "Modelo de Recuperação Simples".

Existem muitas perguntas semelhantes a isso com respostas dizendo que você precisa reduzir o banco de dados. Mas eles continuam explicando o quão ruim / assustador isso é devido a dados fragmentados etc.

1. Como o banco de dados não deve ter esse tamanho. Ainda é ruim para mim encolher?
2. Este é um banco de dados de produção. Se eu diminuir, isso causará tempo de inatividade ou bloqueará o banco de dados?
3. No SQL Server Management Studio, você tem duas opções para reduzir, banco de dados ou arquivos. Dada a minha situação, qual seria a melhor opção?
4. existe uma regra sobre a porcentagem de espaço livre que um banco de dados deve ter?

Mesmo lendo a descrição da tag shrink, não quero fazer isso. Existe outro caminho?

Excluirei aproximadamente 400 milhões de registros desta tabela.

Felizmente, você está fazendo isso em pedaços - para evitar inchar o log de transações.

Observe que não vejo nenhuma queda no espaço no disco rígido

Você não precisa, pois precisa reduzir explicitamente o arquivo do banco de dados para liberar espaço. Apenas excluindo os registros, o SQL Server não liberará o espaço de volta ao sistema operacional .

1. Como o banco de dados não deve ter esse tamanho. Ainda é ruim para mim encolher?

Geralmente, é uma prática ruim, pois os bancos de dados devem ser adequadamente configurados. Se você tiver 100% de certeza de que seu banco de dados NÃO voltará a ter esse tamanho, não há problema em reduzir o banco de dados (no seu cenário) .

2. Este é um banco de dados de produção. Se eu diminuir, isso causará tempo de inatividade ou bloqueará o banco de dados?

Reduzir um banco de dados é muito intensivo em IO. É aconselhável encolher usando DBCC SHRINKFILEdurante a janela de manutenção ou quando houver atividade mínima.

3. No estúdio de gerenciamento, você tem duas opções, Banco de Dados ou Arquivos. Dada a minha situação, qual seria a melhor opção?

Você deve usar o TSQL para fazer a redução. (desde que você perguntou, encolher FILE é o caminho a seguir, em vez de banco de dados). Você pode usar o banco de dados shrink em pedaços - script tsql para fazer o shrink em pedaços.

Lembre-se de que, quando você encolhe, está fragmentando seus índices.

4. existe uma regra sobre a porcentagem de espaço livre que um banco de dados deve ter?

Você pode consultar o artigo Estimando requisitos de espaço em disco para bancos de dados . Não há regra de correção, você deve levar em consideração como o banco de dados deve crescer. Você também deve levar em consideração o crescimento automático de seus bancos de dados .

Referências: Por que o log de transações continua crescendo ou fica sem espaço?

você tem um bom motivo para se preocupar, pois o banco de dados encolhe no SQL Server frequentemente "suga". Paul Randal, chefe do Mecanismo de Armazenamento no SQL 2005, declarou que o ShrinkDB está muito mal escrito. Ele encontrará espaço vazio, pegando os dados no final e colocando-os no início, e continue fazendo isso até ter espaço livre no 'final' dos arquivos do banco de dados. Nesse ponto, ele pode liberar o espaço do SQL Server e devolvê-lo ao sistema operacional. Você está efetivamente revertendo seus arquivos de banco de dados e, portanto, verá uma fragmentação maciça normalmente. Você pode ler sobre suas opiniões nesta postagem do blog ou neste vídeo da MCM Internals

Como em tudo, você realmente deve testá-los primeiro em seu ambiente. Uma maneira melhor de fazer isso é mover dados para um grupo de arquivos diferente. Você pode reconstruir o índice online com o índice clusterizado e reindexar no novo grupo de arquivos. Então você pode largar o antigo e liberar o espaço e quase não tem fragmentação. Observe que isso exigirá cerca de 120% de espaço extra enquanto estiver sendo trabalhado. O problema é que você precisa de espaço livre adicional, o que parece não ter. Este é um recurso da empresa.

Se o espaço livre for muito alto, talvez você precise morder a bala e encolher lentamente o DB um pequeno pedaço de cada vez para evitar processos demorados. Observe que seus dados serão fortemente fragmentados e você precisará reindexar tudo novamente. Observe que depois de reindexar tudo, você aumentará um pouco o espaço usado e voltará a ter espaço livre adicional. Veja o conselho de Brent aqui .

Na medida em que o espaço livre é bom para você, é uma questão de quanto você pode pagar por atividades de fragmentação e crescimento de arquivos. Com o IFI ativado, o crescimento do arquivo é quase instantâneo, mas você ainda fica fragmentado. Uma boa regra geral é pré-alocar o espaço que achar necessário, ou monitorar o crescimento e ajustar periodicamente os trechos, se necessário. Isso mantém a fragmentação física baixa.

Além disso, o crescimento do arquivo de log é muito mais importante. Arquivos de log adicionais podem causar fragmentação do VLF. Isso torna as restaurações muito mais lentas e pode afetar o ponto de verificação / trunca. Aqui estão alguns riscos de desempenho que você corre com um log fragmentado. Faça um DBCC LOGINFO();em cada banco de dados. Tente manter o número em torno de 50 por Kim Tripp, mas se você vir centenas, terá problemas de fragmentação, o que significa que seus arquivos de log tiveram que crescer para dar suporte às operações. Uma boa maneira de ver qual deve ser o seu arquivo de log para Paul Randal é deixá-lo crescer por uma semana e reindexar. Esse pode ser um bom ponto, talvez você possa colocar um pouco mais de espaço livre por lá. Verifique se seus logs não estão fragmentados com DBCC LOGINFO (); de novo e se estiverem, significa que cresceram muito. Reduza e expanda novamente o arquivo de log usandoeste método .

Não há problema em reduzi-lo o suficiente para garantir que o servidor não trava no tempo necessário para avaliar suas necessidades de armazenamento e planejar serviços de hardware / hospedagem de maneira adequada (consulte a pergunta 4). Não, não vai trancar. Veja restrições . Reduza o banco de dados porque ele simplifica as coisas.

Sugiro contratar os especialistas para conduzir o estudo e redigir o plano.