Rápidas palavras sobre o Backup Compression

Olá,

Existem várias técnicas e features no SQL Server relacionadas à compressão. Hoje vamos falar sobre compressão nativa de backup (não confundir com Data Compression).

O termo compressão na área de informática é o ato de reduzir o tamanho de um arquivo aplicando uma série de algoritmos, sendo alguns deles destinados à retirar redundâncias após identificar padrões de dados repetidos(principalmente caracteres).

No final, o arquivo que sofreu compressão possui menos bytes que sua forma original, e ainda assim, consegue representar o mesmo conteúdo quando for restaurado, pois assim como existe um processo para “encolher” os bytes de um formato normal para um formato comprimido, também existe um processo que realiza o inverso (traduz os bytes comprimidos para o formato original). Note que alguém precisa aplicar os algoritmos de compressão e fazer uma série de cálculos emcima deles. Alguém tem que trabalhar, não é mesmo? Esse alguém é a CPU, que realiza essa atividade tendo uma carga de trabalho maior que o normal.

Vantagens

O que podemos alcançar com a compressão? Menor espaço em disco ocupado pelos arquivos que sofreram compressão e ganho de desempenho em vários casos, seja na geração do arquivo ou na transmissão do mesmo via rede (se ele está menor, certamente demorará menos para ser copiado, por exemplo). Você já deve imaginar que um menor tamanho do arquivo nos traz uma vantagem inestimável: ganho em operações I/O, e a vantagem disso é refletida de várias formas, como por exemplo, a transferência via rede aumenta consideravelmente, menor uso de memória e menor espaço ocupado em disco.

A grande sacada da compressão de backup é que, no ato em que um BACKUP DATABASE, aquele backup está sofrendo compressão no ato da sua execução. O SQL Server não espera realizar o backup do arquivo para depois aplicar compressão. O arquivo em questão já “toca” o disco com tamanho reduzido. E de quebra seu backup poderá ser realizado mais rápido.
Veja um exemplo de uma base depois de um COMPRESSION:

Exemplo de base depois de compact...não pera. — Exemplo de base depois de compact…não pera.

Errei a imagem…

Dois backups. Um com compressão e o outro não.

“Desvantagens”

O uso da compressão exige um trabalho extra da CPU, e portanto, deve ser utilizada cuidadosamente, dependendo do cenário. Por exemplo, se você faz backup em horário de rush onde o servidor está com alto processamento de CPU, talvez não seja interessante tirar um backup comprimido, pois a transação do backup pode impactar em outras, gerando concorrência e atrasos nelas.

Na minha opinião, considerar isso como “desvantagem” é extremamente relativo. Prefiro chamar de “o preço que se paga”. Soa mais justo pois nada nesse mundo é de graça e não existe mágica sem truque. E com a compressão, não é diferente.

"Todo almoço tem seu preço, meu filho" - JOBS, Steve — “Todo almoço tem seu preço, meu filho” – JOBS, Bill

Se você tem esse trade-off onde você ganha economia de espaço e operações de I/O mais rápidas (bom pro disco, memória e rede) e em compensação precisa pagar por um pouco mais de processamento na CPU, será que não vale a pena? Na maioria dos casos onde o uso de CPU não é intensivo, será mesmo que existe desvantagem nessa troca?
Já trabalhei em um cenário onde backups compactados (FULL na Quarta e Domingo, DIFF nos demais dias) eram tirados toda noite por volta de 1h. Janela tranquila, CPU mais mansa que peixe beta, o uso deste recurso se mostrou bastante compensatório, principalmente porque no final os backups eram estocados em fita. Em resumo: a causa de maior medo ao utilizar o recurso que é o aumento de trabalho de CPU foi algo a ser desconsiderado nesse caso. E creio que existem inúmeros cenários similares.

Você pode utilizar compressão nos arquivos de backup FULL, DIFERENCIAL e LOG.

Restrições

As duas principais restrições envolvendo compressão de backup:

1) Quando você guarda seus backups em um mediaset (ou seja, mais de um backup por arquivo), todos devem ser comprimidos ou nenhum. Não se pode ter no mesmo mediaset um backup comprimido e outro não.

2) Restrições de versões/edições do SQL Server (ver o tópico Compatibilidade)

Para mais informações, verifique as referências no final do post.

Compatibilidade

O recurso foi introduzido no SQL Server 2008 Enterprise (Developer e Trial herdam também) e desde o SQL Server 2008 R2 está disponível em todas as edições do produto. Um detalhe importante é que se você tentar restaurar um backup compactado tirado duma instância 2008 Enterprise e tenta restaurar em uma instância 2008 Standard, um erro ocorrerá no Management Studio.

No SQL Server 2005 e anteriores, não existe solução nativa para compressão de backups. A solução neste caso seria o uso de ferramentas de terceiros e o uso de criatividade: Uma das formas mais conhecidas é montar uma rotina em cmd shell pra realizar compressão utilizando algum utilitário, como o Winzip, para aplicar compressão DEPOIS que o backup já está em disco. Embora tais métodos não sejam tão práticos por não serem nativos, são possibilidades.

DEMO

Para ilustrar as diversas formas de compressão de backup, montei um cenário em ambiente de teste e tirei dois backups, um com compressão e outro sem compressão (modo normal).

Primeiramente, print do tamanho da base:

E os backups realizados:

Com esse simples teste, você já percebe algo surpreendente sobre a performance do backup com compressão pelos resultados comentados: ele demorou praticamente metade do tempo e consequentemente, realizou a operação de I/O com quase o dobro de eficiência. A parte divertida do negócio, além da performance incrível na realização do backup

Isso por si só (performance na parte de I/O) já é bastante significativa. Mas….e o tamanho do arquivo final?

E tem como eu estimar o ganho que terei com a compressão de backup? Não existe para este caso nenhuma procedure (até o momento) nativa que realize essa estimativa, principalmente porque o ganho vai depender bastante do banco de dados em questão. A ideia é que você faça um backup utilizando compressão e analise os resultados. No banco de sistema MSDB, é possível verificar o ganho da base de exemplo:


SELECT
backup_set_id,
database_name,
backup_size,
compressed_backup_size,
backup_size/compressed_backup_size as [Ganho]
FROM msdb.dbo.backupset
WHERE database_name = 'DBIG'

O resultado:

Sem fazer um código mais detalhado (com os devidos tratamentos), a última coluna revela que o backup comprimido é praticamente 6x menor que o tamanho original do backup (praticamente 83% menor).

Note também que no primeiro backup não utilizei compressão. O valor inserido na coluna compressed_backup_size é exatamente o valor do backup_size. Já no segundo caso, temos o tamanho correto da base comprimida. Exatamente por isso, que não é possível realizar estimativas (exatamente porque não existe um valor pra servir de base).

É importante mencionar também que, caso a base esteja utilizando TDE (Transparent Data Encryption), o ganho na compressão do backup é irrisória ou perto de zero.

EDIT: Se sua base já tiver compressão de dados, você pode utilizar compressão de backup também e pode se surpreender com a quantidade de ganhos que isso traz. Vários profissionais já fizeram o teste e comprovaram que o grau de compressão é ainda maior, e faz sentido. Imagine que a compressão de dados cria dicionários (utilizados pelos algoritmos de compressão) baseado em páginas e a compressão de backup cria um dicionário para a base inteira…

Como fazer?

Existem várias formas de realizar um backup compactado:

1. Uso de cláusula WITH COMPRESSION

Forma mais simples.

2. Via SP_CONFIGURE

Permite que você mude a configuração padrão fazendo com que todo backup utilize compressão por padrão (mesmo sem declarar no corpo do backup a cláusula COMPRESSION nos parâmetros via WITH):

Apenas ative essa opção se você estiver totalmente seguro que sabe o que está fazendo e o que será impactado.

3. Via Management Studio

Sem tirar nem pôr faz a mesma coisa que a segunda opção (seta o default pra compressão e reconfigure), a diferença é que isso é feito de modo gráfico. Botão direito na instância, Propriedades, Database Settings e pronto:

Bônus: Para quem tiver curiosidade, existe um trace flag que trabalhando junto com a compressão aumenta ainda mais a transferência de I/O em disco. O motivo disso é uma alteração no comportamento de estimativa de espaço que o SQL Server deve reservar pro backup que está sendo realizado. Caso se sinta curioso(a), veja o link nas referências [3].

E os restores?

EDIT: Depois de publicar o post, me perguntaram em relação à performance do RESTORE, se o ganho é tão perceptível quanto o BACKUP. Fiz uns testes rápidos na mesma máquina (e sob as mesmas condições de uso) e os resultados foram:

— Restore backup comprimido

RESTORE DATABASE successfully processed 484625 pages in 114.127 seconds (33.174 MB/sec).

— Restore backup normal

RESTORE DATABASE successfully processed 484627 pages in 133.096 seconds (28.446 MB/sec).

Mais um ponto pro backup comprimido =)

Finalizando
Compressão é sinônimo de economia. Em vários casos, essa economia pode ser tão compensatória em relação ao preço que se paga que podemos até dizer que é um recurso que economiza espaço de graça.

E aí, você já usou ou está pensando em usar compressão nativa do SQL Server nos backups?

Conhece ou usa alguma ferramenta de terceiros? Alguma observação sobre isso?

Quer relatar algum resultado de testes realizados?

Acha que é cilada?

É boa, pode usar sim?

Vai ter copa?

Fique à vontade para comentar.

Referências:

[1] Compressão – http://pt.wikipedia.org/wiki/Compress%C3%A3o_de_dados

[2] Backup Compression – http://technet.microsoft.com/pt-br/library/bb964719.aspx

[3] Trace Flag 3042 – http://support.microsoft.com/kb/2001026/pt-br