Duas tabelas em nosso banco de dados SQL Server equivalem a 500 milhões de linhas e 350 GB de dados. O espaço em disco é um problema em que mantemos backups e o tempo para executar backups também. Planejamos truncar essas 2 tabelas.
Eu entendo que para recuperar o espaço em disco, precisaremos reduzir o banco de dados após o truncamento e, em seguida, fazer uma reconstrução de índice para corrigir índices fragmentados posteriormente. Mas como não temos certeza de quanto tempo as reconstruções levarão (estamos criando uma VM de servidor de teste no Azure agora para testar), enquanto isso estamos procurando ganhos incrementais. Depois de apenas truncar (antes de reduzir e reconstruir), os tempos de backup e o tamanho do arquivo de backup resultante (após a compactação 7z) serão reduzidos drasticamente como resultado?
Embora já tenha passado algum tempo desde que lidei com backups do SQL Server que não foram compactados pelo próprio SQL, o SQL faz backup de seus dados, não de seu espaço livre.
Como dito aqui
TRUNCATEdesaloca páginas de dados. Se o espaço consumido pelos seus dados cair de 700 GB para 350 GB, o tamanho dos backups também deve ser cerca de metade do que era, e o tempo para fazer o backup deve ser reduzido da mesma forma.