Como excluir índices de backups no SQL Server 2008

Nossos backups noturnos completos (e diferenciais periódicos) estão se tornando bastante grandes, devido principalmente à quantidade de índices em nossas tabelas; aproximadamente metade do tamanho do backup é composto por índices.

Estamos usando o modelo de recuperação simples para nossos backups.

Existe alguma maneira, através do uso FileGroupsou de outro método de particionamento de arquivo, de excluir índices dos backups?

Seria bom se isso também pudesse ser estendido aos catálogos de texto completo.

Se você alternar para o modo de recuperação total, poderá fazer isso com grupos de arquivos, mas é muito, muito desajeitado. Você deixa os dados no grupo de arquivos principal e coloca os índices em um grupo de arquivos separado (não padrão, é a chave).

Em seguida, você escalona seus backups para fazer backups de grupos de arquivos do primário todas as noites e backups de log de transações a cada X minutos.

Quando ocorre um desastre, você restaura o grupo de arquivos primário sozinho. Os dados ficam subitamente online, mas os índices não. No entanto, para voltar à normalidade, você precisará exportar esses dados para um novo banco de dados limpo e adicionar índices a partir daí. Você não pode colocar o banco de dados completamente online sem restaurar todos os grupos de arquivos e não pode dizer "Não preciso mais desse outro grupo de arquivos".

Para saber mais sobre como isso funciona, confira meu tutorial em vídeo sobre restaurações de grupos de arquivos.

Honestamente, você realmente não quer fazer isso, mesmo que supere os outros problemas que outros levantam aqui.

Quando você restaura o backup em uma emergência, não deseja esperar a reconstrução dos índices e sofrerá um desempenho abominável até que o faça.

Não consigo pensar em uma situação em que você deseje restaurar um backup sem índices; portanto, em todos os casos, você realmente deseja fazer backup deles ao mesmo tempo.

Você provavelmente precisará procurar outras soluções para esse problema ...

-Adão

Parece que isso não é suportado. A partir desta informação do relatório de erros :

Tem havido muito interesse neste, então irei detalhar um pouco mais o que está acontecendo nos bastidores e o que significaria implementar essa funcionalidade. Alguns tipos de páginas de índice são segregados em unidades de alocação separadas, enquanto outros são misturados às páginas de dados. Onde atualmente apenas olhamos para o bitmap de alocação para ver se uma extensão está alocada, agora teríamos que analisar e interpretar o que é armazenado em cada unidade de alocação. Além disso, agora não poderíamos apenas fazer uma varredura linear dos arquivos de dados que estão copiando os dados, estaríamos pulando no arquivo. Toda essa interpretação das estruturas de dados desaceleraria drasticamente o backup. A restauração fica ainda mais interessante, porque há muitas estruturas que precisariam ser corrigidas para dar conta dos buracos no backup. Caso contrário, você teria mapas de alocação apontando para páginas que não foram armazenadas em backup e, portanto, terão lixo etc. etc. restaurá-lo por mais tempo. A outra faceta a considerar é que isso exigiria uma grande quantidade de esforço de engenharia para fazer tudo certo. Embora esse não seja o seu problema na superfície, considere que isso significa que outros recursos que você pode querer ver não serão criados.

pode ser uma ideia louca, mas aqui vai.

1. solte seus índices não agrupados que ocupam muito espaço
2. faça um backup
3. recrie os índices que você soltou

Obviamente, você só poderá fazer isso se o banco de dados permitir algum tempo de inatividade durante o dia.

Além disso, não descarte os índices em cluster, pois o SQL Server perderá muito tempo convertendo-os em um heap.

A compra desse espaço em disco extra parece uma solução mais fácil ainda?

Você já pensou em fazer backups compactados ? este é um novo recurso de 2008, pode ser uma opção para você.