Como excluir índices de backups no SQL Server 2008

19

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.

— Jarrod Dixon
fonte

15

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.

— Brent Ozar
fonte

Hehe, mudei os índices não agrupados para o seu próprio grupo de arquivos; o modelo Simple Recovery me impediu completamente. Os índices eram realmente maiores que os dados - como isso me provocou! Oh bem, talvez alguns 3o partido vai lançar uma bala mágica dica dica :)

— Jarrod Dixon

1

E talvez, apenas talvez, você obtenha licenciamento gratuito para isso. ;-)

— Brent Ozar

5

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

— Adam Davis
fonte

1

"você não quer esperar que os índices sejam reconstruídos" muito presunçoso, IMO

— Jeff Atwood

2

Sim, mas lembre-se de que estou generalizando aqui. Não estou convencido de que há mais situações em que é melhor abandonar os índices e reconstruir do que em situações em que é melhor fazer backup dos índices e evitar uma reconstrução. Em outras palavras, um caso geralmente é melhor e, a menos que uma situação específica exija, deve-se errar ao fazer o backup. Dito isto, cada situação é diferente. Estou curioso para saber quanto tempo leva para reconstruir os índices de SO e quanto o desempenho do site sofre até que eles sejam concluídos (supondo que ele funcione durante a reconstrução).

— Adam Davis

O backup de arquivamento de longo prazo é o caso de uso específico que estou vendo agora que me levou a essa pergunta. Eu tenho um projeto que está completo e não deseja mais o banco de dados online, mas também não precisa sobrecarregar nossa unidade de rede com um arquivo de backup maior que o necessário. Não quero perder as definições de índice, mas não me importo de reconstruí-las se eu tiver que restaurá-las novamente.

— precisa

3

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.

— Jon Galloway
fonte

Isso não seria um problema para índices de texto completo, seria? Aqueles tendem a ser bem grandes.

— 22613 Michael Teper

1

pode ser uma ideia louca, mas aqui vai.

solte seus índices não agrupados que ocupam muito espaço
faça um backup
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ê.

— Nick Kavadias
fonte

Sim, ativamos a compactação para backups, mas a compactação interna não é tão boa. Na verdade, temos um backup não compactado no final da semana e, em seguida, compactamos com 7z para que os desenvolvedores reduzam; é aproximadamente 1/3 do tamanho, mas leva algum tempo para ser executado!

— Jarrod Dixon

Quanto ao tempo de inatividade do banco de dados, poderíamos realmente viver sem o serverfault.com e o stackoverflow.com o máximo possível? Eu tremo com esse pensamento :)

— Jarrod Dixon

Eu não testei eu mesmo, mas suspeitei isso. Não é muito configurável. Se você ainda está olhando para a compressão como uma opção, dê uma olhada no SQL Lightspeed (caro, mas incrível, mas o preço é muito negociável) e no SQL Backup da RedGate. Muito configureable & excelentes resultados

— Nick Kavadias