Eu sei que isso é mais discutido em vários fóruns: Eu entendo completamente que a resposta é não na maioria das vezes ou nos casos.
No entanto, quero saber se pode ser uma boa abordagem em qualquer cenário:
Vamos dizer para o banco de dados prod atual que no nosso caso tem mais de 30 TB e tem retenção de dados por 1 ano. As tabelas são principalmente compactadas e particionadas.
A equipe de desenvolvimento criou uma lógica em que eles não precisam de dados para permanecer até o ano e desejam alterar a retenção para 6 meses. Portanto, espera-se que os dados sejam reduzidos à metade após a eliminação e apenas com dados de 6 meses daqui para frente.
É aqui que fomos solicitados a trabalhar na redução de arquivos de dados para que esses LUNS com TB de espaço pudessem ser retornados ou, se migrarmos para uma nova versão do sql, estaríamos solicitando, digamos, alguns (aprox10) TB a menos que economizam algum dinheiro, supondo que mantenhamos 5 TB extras para crescimento no banco de dados no futuro.
Nesse caso, seria útil reduzir a redução em pequenos pedaços, assumindo que o bloqueio no horário de pico baixo pode ser aceito ou se a redução for executada por mais tempo pode ser cancelada?
Quanto vale a atividade de arquivo de dados de redução acima ou existe uma abordagem melhor?
Editar --> Estamos migrando para a versão mais recente possivelmente SQL 2017 ou SQL2K19. As tabelas não são particionadas com base em grupos de arquivos, pois para esses bancos de dados todos os mais de 30 arquivos estão no primário. Eu sei, é apenas um design de banco de dados de fornecedor e não tenho muito na minha mão.
você pode ler sobre isso aqui - https://www.brentozar.com/archive/2017/12/whats-bad-shrinking-databases-dbcc-shrinkdatabase/
e sobre quando encolher é uma obrigação o que você pode fazer aqui - https://www.brentozar.com/archive/2020/07/what-if-you-really-do-need-to-shrink-a-database/
Quando reduzimos nosso banco de dados, ele introduz fragmentação externa e interna, causa bloqueio, causa crescimento do log de transações enquanto é executado. A fragmentação do índice aumenta. Quando reconstruímos o índice, o tamanho do banco de dados volta a aumentar. Assim, causando o ciclo interminável de reconstrução por encolhimento.
Supondo que você tenha o tempo de inatividade no local, e se eu precisar fazer uma redução para mover o banco de dados, eu criaria scripts de todos os índices e os descartaria. execute o checkpoint várias vezes, faça backup de log, reduza o arquivo de log e reduza o banco de dados, faça backup completo e restaure esse backup para um novo local. execute o script de índice para criá-los novamente e deixá-lo crescer no novo servidor. Cuidado: criar um índice em 30 TB será uma dor.
Poderia haver uma maneira melhor de fazer isso, ficaria feliz em ficar de olho em outras respostas.
Esse é um banco de dados bastante robusto para encolher. Gostaria apenas de apontar duas coisas que você deseja verificar antes de iniciar suas operações de redução:
Dados LOB. Isso levará uma eternidade, pois não há backpointers para os dados LOB. Ou seja, uma página LOB foi movida e tudo o que o SQL Server sabe é a qual tabela ela pertence. Ele precisa fazer uma varredura na tabela para encontrar a linha, uma para cada valor de lob nessa página.
Tabelas de pilha. Para cada página movida, o SQL Server precisa modificar cada índice nc para cada linha dessa página. Pode levar de 5 a 10 vezes mais tempo para reduzir uma tabela de heap em comparação com uma tabela em cluster.
Uma opção que você pode querer considerar para esse tamanho é mover os dados para outro lugar (grupo de arquivos) antes da redução (ou possivelmente apenas remover esse grupo de arquivos se estiver vazio agora).
Uma possibilidade seria usar a replicação transacional e adicionar filtros de linha estática para filtrar os dados mais antigos, isso também teria a vantagem de um corte mais curto ao longo do tempo para o novo servidor (suponho que você esteja fazendo uma migração lado a lado não uma atualização no local).