Exchange, stubbing e recuperação de espaço de banco de dados
Artigo original publicado na terça-feira, dia 28 de agosto de 2012
O Exchange 2010 SP2 RU1 continha uma correção para um problema relacionado à recuperação de espaço de banco de dados. Parece haver alguma confusão a respeito dessa questão. Por isso, gostaria de explicar qual era o problema, dizer qual é a correção e falar a respeito das expectativas quanto ao uso de itens stub de produtos de terceiros no banco de dados (stubbing é o processo pelo qual uma mensagem é substituída por um objeto de ponteiro e a versão original é armazenada em um repositório externo).
O problema e a correção
No Exchange 2010, descobrimos que o espaço do banco de dados não estava sendo recuperado em vários cenários em que os itens eram excluídos permanentemente (quando o item é removido do repositório). Isso inclui cenários de arquivamento em que os itens são excluídos em massa com base na data, cenários de stubbing em que anexos são excluídos e outros cenários como caixas de correio de diários e replicação de pastas públicas. Esse problema afetou uma ampla gama de clientes e estava no modo de funcionamento da exclusão de itens.
Normalmente, o Exchange 2010 tentará limpar a linha de um item excluído alguns minutos após a exclusão permanente do item. Porém, a limpeza falhará se algum elemento ainda tiver referências ao item abertas. Veja, por exemplo, alguns cenários possíveis em que a limpeza falhará: indexação de conteúdo indexando uma mensagem, um cliente separado lendo a mensagem, etc. Se algum elemento tiver referências abertas, a limpeza falhará. Antes da correção, se a limpeza falhasse neste ponto, o espaço era efetivamente perdido e não podia ser recuperado sem mover a caixa de correio.
No fim das contas, referências pendentes de mensagens excluídas são particularmente comuns em caixas de correio de diários ou quando são usados softwares de arquivamento de terceiros. Por isso, a grande maioria dos clientes que passou por esse problema o associou a um desses dois cenários. Porém, tecnicamente, qualquer cliente pode manter uma referência aberta e evitar a limpeza de um item.
A correção incluída no SP2 RU1 corrige o problema por meio da adição de um mecanismo de novas tentativas de limpeza. Se a limpeza falhar em função de ainda haver uma referência aberta, o repositório realizará novas tentativas periódicas até obter êxito.
Isso "corrigiu" o stubbing?
Stubbing refere-se a um processo em que um produto de arquivamento de terceiros pega uma mensagem grande e a transforma em um item menor (ou stub). Normalmente, ele faz isso excluindo os anexos e modificando o corpo da mensagem, de modo que fique menor.
Como o processo de stubbing exclui anexos, ele pode ser afetado por esse problema, pois os anexos excluídos podem gerar falhas de limpeza em função de referências abertas. Porém, tirando esse fato, o problema nunca foi realmente relacionado a stubbing.
E se o stubbing não estiver fornecendo o espaço esperado?
O Repositório de Informações do Exchange mudou muito ao longo dos anos. Porém, mesmo no Exchange 2003 e 2007, o processo de stubbing não resultava em bancos de dados consideravelmente maiores do que o esperado ao adicionar os tamanhos das caixas de correio. Isso ocorria principalmente em função de dois tipos de sobrecarga.
O primeiro tipo de sobrecarga refere-se a propriedades que simplesmente não fazem diferença em relação ao tamanho da mensagem. Quando você observa o tamanho de uma mensagem no Outlook, ele não é o tamanho total de todos os dados armazenados pelo Exchange para a mensagem. Armazenamos certas propriedades que não são perceptíveis ao usuário e não refletem no tamanho da mensagem. Elas podem ser propriedades documentadas publicamente, como PR_URL_NAME, ou outras propriedades internas que os clientes não podem acessar.
O segundo tipo de sobrecarga é a fragmentação de páginas. O tamanho das páginas do banco de dados mudou ao longo dos anos, de 4 KB no Exchange 2003, para 8 KB no Exchange 2007, para 32 KB no Exchange 2010. Cada registro no banco de dados deve ser organizado nessas páginas e, dependendo da eficiência desse processo, ainda sobrará espaço na página. Isso é a fragmentação de páginas, que resulta em espaços vazios que não podem ser recuperados pela manutenção do banco de dados. As páginas com tamanhos maiores das versões mais recentes do Exchange facilitam a organização de vários itens pequenos em apenas uma página, resultando em menos fragmentação. Porém, sempre haverá um certo nível de fragmentação.
Normalmente, a quantidade de sobrecarga não muda muito entre as mensagens. Uma mensagem pequena trará tanta sobrecarga quanto uma grande. Por esse motivo, quando você preenche um banco de dados com itens pequenos, a sobrecarga fica muito mais aparente.
Por exemplo, considere um cenário em que você preencheu um banco de dados com itens de 1 MB, e todos possuem 1 KB de sobrecarga. Isso significa que seu banco de dados tem uma sobrecarga de 0,09%, em média. Agora, digamos, que você realiza stubbing de todos os itens no banco de dados, reduzindo-os a um tamanho de 4 KB. De repente, aquela sobrecarga de 1 KB fica muito mais visível, ocupando 25% do banco de dados. Certa vez, produzi pessoalmente um banco de dados do Exchange 2003 com sobrecarga de 70%, preenchendo-o com itens minúsculos e realizando stubbing da coisa toda.
E quanto ao Exchange 2010?
No Exchange 2010, há um fator adicional que pode afetar a recuperação de espaço de stubbing: a alteração no design do banco de dados.
O Exchange 2010 fez um grande progresso na redução do IOPS do banco de dados. Grande parte disso foi possível porque eliminamos o antigo processo de desfragmentação online, que causava uma agitação agressiva no banco de dados todas as noites e movia os elementos para otimizar o espaço. No Exchange 2010, estamos muito mais focados em armazenar o conteúdo das caixas de correio em páginas contíguas para reduzir a E/S, mesmo que isso signifique termos espaços não utilizados aqui ou ali. Em outras palavras, a intenção do Exchange 2010 simplesmente não é recuperar espaço de forma agressiva quando uma mensagem encolhe repentinamente. É um cenário que minimizamos na arquitetura para aprimorar a E/S. Para obter mais informações sobre as alterações de manutenção, consulte o tópico sobre manutenção de bancos de dados no Exchange 2010.
Isso significa que não é possível economizar espaço por meio de stubbing? Não necessariamente. Normalmente, os produtos de stubbing excluem anexos; por isso, esperamos que o espaço seja liberado. E, embora não tenha sido desenvolvido para isso, o Exchange 2010 libera um pouco de espaço mesmo quando o processo de stubbing é realizado com itens sem anexos.
Porém, como isso não faz parte do design do Exchange 2010, não podemos dizer o que esperar em relação à quantidade de espaço liberado usando arquivamento por stub. Qualquer expectativa em relação a isso deve vir de testes próprios ou de dados fornecidos por fornecedores de software de arquivamento.
Em outras palavras, não podemos fazer declarações a respeito da recuperação de espaço quando um item é modificado para tornar suas propriedades menores do que antes. Se a modificação de um item para torná-lo menor não liberar espaço, considere como sendo uma consequência do design do Exchange 2010. Como sempre, com a investigação de suporte de problemas de espaço dos bancos de dados provenientes da utilização de produtos de terceiros, poderemos indicá-lo à empresa específica para suporte caso o Exchange deva funcionar em função de seu design.
Conclusão
O Exchange 2010 SP2 RU1 incluía uma correção que ajuda os clientes a fazer qualquer tipo de arquivamento, stubbing ou outras atividades, pois ela faz com que a limpeza de itens excluídos permanentemente funcione de forma confiável. Porém, qualquer economia de espaço em disco esperada proveniente de stubbing deve ser validada por você e pelo fornecedor de software de arquivamento. Na hora de provisionar seu armazenamento, sugerimos que você siga as orientações publicadas (que incluem o aproveitamento de caixas de correio grandes, de modo que você não precise depender de soluções de arquivamento de terceiros) e as ferramentas da Microsoft para garantir que haja espaço adequado para os dados do Exchange.
Bill Long
Este é um post localizado. O artigo original está em Exchange, Stubbing, and Database Space Reclamation