Estudando a compressão de backup



Ao invés de estudar tudo sobre o assunto e depois escrever artigos para você, que tal estudarmos juntos? Estou aproveitando um treinamento para brincar um pouco mais com o SQL Server 2008. Vamos analisar a compressão de backup e algumas considerações que eu vou fazer. Nota: existem várias considerações de meu entendimento, que você pode concordar ou não.


 


Compressão de backup é um recurso muito importante do SQL Server 2008, pois nos permite efetuar um backup mais rápido e manter arquivos menores, característica imprescindível para os bancos de dados de hoje, que estão crescendo a passos largos. Além disso, é importante sempre mantermos arquivos de backup no servidor, para uma recuperação de desastre mais eficiente.


 


A sintaxe para a compressão de backup é simples, basta adicionarmos a palavra COMPRESSION nas opções definidas no WITH. Por exemplo:


 


BACKUP DATABASE Credit


TO DISK = 'C:\TEMP\CreditCompact01.bak'


WITH COMPRESSION


 


Se eu executar o backup do banco de dados Credit sem a compressão de backup, o arquivo final fica com um tamanho de 159.832 KB, com um tempo de backup em torno de 16 ~ 17 segundos. Veja a mensagem que é exibida:


 


Processed 19920 pages for database 'Credit', file 'CreditData' on file 1.


Processed 1 pages for database 'Credit', file 'CreditLog' on file 1.


BACKUP DATABASE successfully processed 19921 pages in 17.346 seconds (8.972 MB/sec).


 


Se executarmos o backup com compressão teremos como resultado um backup de 53.814 KB, com um tempo de execução em torno de 11 ~ 12 segundos. Veja a mensagem que é exibida:


 


Processed 19920 pages for database 'Credit', file 'CreditData' on file 1.


Processed 1 pages for database 'Credit', file 'CreditLog' on file 1.


BACKUP DATABASE successfully processed 19921 pages in 11.917 seconds (13.059 MB/sec).


 


Temos um arquivo com aproximadamente 33% do tamanho original e um tempo de backup também menor, o que é ótimo. É claro que isso não vem de graça, temos um uso maior do processador para fazer a compressão das páginas que são lidas do disco e posteriormente serão armazenadas no backup.


 


Enquanto eu estudo sempre aparecem algumas perguntas que gosto de responder, então agora que cobrimos o feijão com o arroz da compressão de backup, vamos tentar satisfazer a curiosidade:


 


P1: O que faz o backup com compressão ser mais rápido que o sem compressão?


P2: Porque a minha taxa de transferência de I/O no segundo caso foi maior (13 MB/sec)? Por acaso o meu disco ficou mais rápido para o segundo caso?


P3: Existe alguma maneira de monitorar quanto tempo o backup gasta em cada uma das operações?


 


Tudo que vou escrever agora é resultado de estudo e suposições que criei para entender a compressão de backup.


 


R1: O grande custo quando estamos fazendo backup é (claro) o custo de I/O. Então quando eu penso no menor tempo de execução do backup, o único motivo para que ele seja menor é porque o SQL Server têm que escrever menos informação em disco, já que na leitura o mesmo número de páginas tem que ser lido (o banco de dados todo). Note que temos um gasto extra para fazer a compressão dos dados antes de escrever em disco o resultado, mas esse tempo é pequeno em relação às operações de I/O.


Essa é minha visão sobre o assunto, mas quando perguntei para um profissional porque a execução do backup com compressão é mais rápida, recebi a seguinte resposta: foi porque ele executou o backup com compressão após um backup sem compressão, que havia colocado as páginas de dados na memória do SQL Server. Mesmo discordando da resposta recebida, surgiu aí mais uma pergunta.


 


P1_1: Fazer um backup seguido do outro, impacta no desempenho do segundo?


R1_1: A minha primeira resposta para a pergunta é não, mas eu tinha que provar. No meu caso, eu peguei e utilizei uma função não documentada (dica: você a encontra em algumas páginas espalhadas por aí) para limpar do buffer pool todas as páginas relativas ao banco de dados Credit. Fiz testes de backup utilizando essa função entre as execuções e, como esperado, não houve mudança no tempo total, apenas pequenas variações usuais de tempo (para mais e para menos). Outra maneira mais trabalhosa de fazer o teste é reiniciar o SQL Server entre backups, para limpar o buffer pool.


 


P1_2: Aonde o SQL Server coloca as páginas que ele lê para o backup?


R1_2: Pensando no processo de backup, o SQL Server dispara algumas threads de leitura que vão lendo os dados do banco e colocando-os em um buffer, enquanto outras threads de escrita vão criando o arquivo de backup. Quando temos compressão, no meio do caminho as páginas no buffer são compactadas antes de serem escritas em disco, mas não sei se são as mesmas threads de leitura/escrita ou outras threads separadas que fazem a compressão (eu apostaria nesse último). De qualquer forma, se temos buffers envolvidos, teremos algum memory clerk no meio da brincadeira, então escrevi o seguinte batch...


 


DECLARE @I INT = 0


WHILE @I < 20


BEGIN


                PRINT CONVERT(VARCHAR(50), GETDATE(), 121)


                SELECT type, memory_clerk_address, single_pages_kb, multi_pages_kb, virtual_memory_committed_kb, virtual_memory_reserved_kb


                FROM sys.dm_os_memory_clerks


                WHERE type like 'MEMORYCLERK_SQLUTILITIES'


 


                SET @I = @I + 1


                WAITFOR DELAY '00:00:01'


END


 


Esse pequeno loop analisa os buffers alocados pelo MEMORYCLERK_SQLUTILITIES que é responsável pelo backup. Você pode abrir uma sessão paralela ao seu backup e deixar o loop sendo executado, capturando a situação dos buffers a cada segundo durante o backup. Dêem uma olhada no resultado:


 


2008-05-14 16:28:24.930


memory_clerk_address single_pages_kb      multi_pages_kb       virtual_memory_committed_kb virtual_memory_reserved_kb


-------------------- -------------------- -------------------- --------------------------- --------------------------


0x00BE70C8           152                  0                    360                         360


0x335E10C8           0                    0                    0                           0


 


(2 row(s) affected)


 


2008-05-14 16:28:26.263


memory_clerk_address single_pages_kb      multi_pages_kb       virtual_memory_committed_kb virtual_memory_reserved_kb


-------------------- -------------------- -------------------- --------------------------- --------------------------


0x00BE70C8           208                  7296                 14888                       14888


0x335E10C8           0                    0                    0                           0


 


(2 row(s) affected)


 


...


...


...


 


2008-05-14 16:28:38.487


memory_clerk_address single_pages_kb      multi_pages_kb       virtual_memory_committed_kb virtual_memory_reserved_kb


-------------------- -------------------- -------------------- --------------------------- --------------------------


0x00BE70C8           216                  7296                 14888                       14888


0x335E10C8           0                    0                    0                           0


 


(2 row(s) affected)


 


2008-05-14 16:28:39.490


memory_clerk_address single_pages_kb      multi_pages_kb       virtual_memory_committed_kb virtual_memory_reserved_kb


-------------------- -------------------- -------------------- --------------------------- --------------------------


0x00BE70C8           152                  0                    360                         360


0x335E10C8           0                    0                    0                           0


 


(2 row(s) affected)


 


Vemos claramente com esses dados que no início o SQL Server começou com poucas páginas alocadas (pouca memória commitada e reservada), mas durante o backup esse número aumentou para receber as páginas que eram lidas do disco. Notem que após o backup, a quantidade de memória utilizada volta ao valor original, isto é, as páginas não são mantidas em memória, então não existe realmente nenhum ganho em backups consecutivos.


 


R2: Eu não gostei da informação apresentada pelo SQL Server sobre I/O (ou não entendi! J). Pelo que pude notar, o resultado nos dá uma informação levemente enganosa, pois através de cálculos aproximados pude perceber que os valores 8.972 e 13.059 MB/sec são conseguidos através da divisão de 19920 páginas de 8K pelo tempo de execução do backup. O que fica estranho no resultado, pois não são escritas em disco 19221 páginas durante o backup com compressão, e isso acaba passando a idéia de que o subsistema de I/O é mais eficiente no backup, o que não é verdade, pois o disco é o mesmo. Certo?


 


R3: Ainda estou estudando para ver se consigo mais informações sobre como monitorar os componentes internos do backup, caso eu descubra, escreverei aqui. O que eu gostaria de saber é exatamente quanto de recurso é gasto com leitura, escrita e compressão, pois eu posso fazer uma aproximação pelos tempos que vimos, mas fica um resultado bem tosco. Também temos que levar em consideração que as operações são executadas em paralelo, assim que as páginas chegam ao buffer, já tem alguém querendo compactar e escrever o resultado no arquivo de backup.


 


Eu acredito que o recurso de compressão de backup é uma novidade do SQL Server 2008 que trás muito valor para os DBAs, sem necessitar de grandes mudanças para ser utilizado pode ajudar imediatamente a resolver os problemas da janela de backup e espaço em disco para armazenar os arquivos de backup, problemas recorrentes no dia a dia.


 


Para mais informações sobre o trade-off de CPU na compressão:


http://www.sqlskills.com/blogs/paul/2008/01/09/SQLServer2008BackupCompressionCPUCost.aspx


 


[]s


Luciano Caixeta Moreira


luciano.moreira@microsoft.com


 


=============================================================


This posting is provided "AS IS" with no warranties, and confers no rights


=============================================================

20080515 - Estudando a compressão de backup.pdf

Comments (3)

  1. ótimo post, adorei as informações e as suas conclusões.

    abraços

    Felipe Ferreira

    MCT, MCPD Web Developer, MCTS, MCP

  2. Dobereiner Miller says:

    Boa noite Luciano, tudo bem?

    Bom lendo este seu artigo, resolvi realizar alguns testes sobre a mesma funcionalidade a fim de também levantar algumas hipóteses sobre esta diferença de tempo entre os backups com e sem compressão do MSSQL2k8.

    Bom, também preparei 2 testes de backups sobre a mesma base e realizei os seguintes procedimentos:

    1) Sobre a mesma base executei um backup sem compressão;

    a. Isolei o io com os contadores: Bulk Copy Throughput/sec, Backup/Restore Throughput/sec, Device Throughput Bytes/sec. Contadores que existem apenas em operações de backup ou restore. Porém também mensurei os contadores de discos não referentes ao backup e restore.

    2) Realizei um backup sobre a mesma base com compreensão;

    a. Isolei novamente os contadores de disco.

    Confesso que também fiquei super curioso sobre como isto funciona e, baseado em suas observações sobre as páginas, também levantei algumas hipóteses:

    Colunas: A, B e C

    Coluna A Coluna B Coluna C

    0x6F 0x39447 0x24BC

    0x39447 0x6F 0x1E23D

    0x17A45 0x12BC 0x6F

    Bom… como a compressão também funciona em nível de página eliminando os bytes comuns o resultado da tabela acima será:

    Coluna A Coluna B Coluna C

    0x6F 0x39447 DICIONÁRIO

    0 1 0x24BC

    1 0 0x1E23D

    0x17A45 0x12BC 0

    Não é criado um dicionário para o restante dos dados que possuem similaridade, porque teria um aumento exponencial de CPU.

    A redução de IO é confirmada, pois, a quantidade de dados diminui.

    Ok, usando então os dados que tiveram o mesmo comportamento apresentado em sua análise, apresento os seus:

    BACKUP DATABASE successfully processed 19921 pages in 17.346 seconds (8.972 MB/sec).

    E com compressão:

    BACKUP DATABASE successfully processed 19921 pages in 11.917 seconds (13.059 MB/sec).

    Ou seja, o volume total não altera.

    Então como eu não tenho toda esta sua carga de conhecimento vai minha hipótese que talvez seja muito simples e que possa me fazer parecer um bobo, mas não custa.

    H1) Já que o valor na segunda análise foi maior não por causa da aceleração de IO (já que tudo ocorreu no mesmo hardware, salva sua observação), será então que na verdade não temos apenas um resultado matemático baseado no tamanho da base? A eliminação dos bytes comuns não gera uma aceleração no ponteiro da base?

    Acho que é apenas isto que eu queria perguntar..

    Abraços Luciano, e parabéns pelo post.. realmente intrigante.

Skip to main content