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:
https://www.sqlskills.com/blogs/paul/2008/01/09/SQLServer2008BackupCompressionCPUCost.aspx
[]s
Luciano Caixeta Moreira
=============================================================
This posting is provided "AS IS" with no warranties, and confers no rights
=============================================================
20080515 - Estudando a compressão de backup.pdf
Comments
Anonymous
May 15, 2008
PingBack from http://www.basketballs-sports.info/basketball-chat/?p=1335Anonymous
May 30, 2008
ótimo post, adorei as informações e as suas conclusões. abraços Felipe Ferreira MCT, MCPD Web Developer, MCTS, MCPAnonymous
June 07, 2008
The comment has been removed