Artigo original publicado na quarta-feira, 9 de novembro de 2011.
No outro dia, eu estava conversando com um de nossos Gerentes do Programa de Suporte, Nino Bilic, e ele mencionou algo que era bastante preocupante: o principal motivo pelo qual nossos clientes Premier abrem o Exchange 2010 em situações críticas é porque os bancos de dados da Caixa de Correio se desmontam devido à falta de espaço em disco no LUN do log de transações.
Vamos amadurecer essa ideia em um momento. Naturalmente estou chocado...Para ser totalmente honesto, pensei que com a Calculadora de Requisitos de Caixa de Correio e nossas orientações no TechNet, já teríamos eliminado esse problema. Depois de compartilhar essas informações comigo, Nino decidiu que eu, não ele, deveria escrever um artigo no blog sobre o assunto do planejamento de capacidade do log de transações (obrigado, Nino!).
Para dimensionar adequadamente um LUN do log de transações, precisamos entender alguns aspectos sobre o ambiente:
Para os fins dessa discussão, vamos supor que cada banco de dados abrigará 250 caixas de correio. Cada caixa de correio envia/recebe 150 mensagens por dia, com mensagens com um tamanho médio de 100KB. Com base na tabela em Noções básicas sobre o banco de dados Caixa de Correio e fatores de capacidade de log, sabemos que um perfil de 150 mensagens com um tamanho médio de mensagens de 75KB gera 30 logs de transações por dia (período de 24 horas). Como nosso tamanho de mensagem é maior que 75KB, precisamos considerar isso na geração de logs de transações por caixa de correio. A orientação estipula que:
Se o tamanho médio das mensagens dobrar para 150KB, os logs gerados por caixa de correio aumentarão em um fator de 1,9. Esse número representa o percentual do banco de dados que contém os anexos e as tabelas de mensagens (corpos de mensagens e anexos).
Portanto, podemos determinar o impacto do nosso tamanho médio de mensagens de 100KB com esta fórmula:
150 / 1,9 = [tamanho médio de mensagens do perfil] / x
x = (100 * 1,9) / 150
x = 1,266666666666667 ~ 1,27
Se você tiver um tamanho de mensagem que é 25KB maior do que a linha de base, o número de logs de transações gerados por dia e por caixa de correio aumentará em um fator de 1,27. Portanto, 30 logs de transações * 1,27 = 39 logs de transações / dia / caixa de correio. Isso significa que, para um banco de dados de 250 caixas de correio, cada banco de dados gerará 39 * 250 = 9.750 logs de transações gerados por caixa de correio / dia / banco de dados.
As movimentações de caixa de correio também geram logs de transações. Cada caixa de correio movida para o banco de dados de destino gera logs suficientes (no destino, não na origem) que se igualam ao tamanho da caixa de correio (incluindo o conteúdo nas pastas de Itens Recuperáveis). Por exemplo, mover 1% das caixas de correio por dia significará que 2,5 caixas de correio são movidas para um banco de dados todos os dias. Se cada caixa de correio tiver 5,4GB de tamanho médio (incluindo a retenção de item excluído por 14 dias com a Recuperação de Item Único habilitada), então 2,5 * 5,4GB / 1024 = 13.888 logs de transações de movimentações de caixa de correio / dia / banco de dados.
A partir de uma perspectiva de backup/restauração, é preciso levar em consideração o tipo de arquitetura de backup que estamos aproveitando. Com cada cenário de backup, há um número recomendado de dias adicionais de provisão de uma perspectiva de capacidade para os logs de transações gerados por caixa de correio. Ao fornecer espaço extra, você pode sobreviver a múltiplas falhas sem sofrer uma interrupção de evento. Para obter mais informações sobre o truncamento do log de transações, consulte Compreendendo o backup, a restauração e a recuperação de desastres.
É claro, existem outros cenários que talvez você precise considerar. Por exemplo, se você estiver implantando um Grupo de Disponibilidade de Banco de Dados (DAG) esticado em dois datacenters, o truncamento de log só ocorrerá se o vínculo de rede entre os dois datacenters estiver operacional e se as cópias do banco de dados estiverem íntegras. Se você souber que uma interrupção do vínculo WAN poderá levar cinco dias para ser consertada, deverá ajustar a sua proteção contra falha de backup para levar isso em consideração.
Para o nosso cenário, vamos supor que só precisamos garantir que possamos sobreviver três dias de eventos de falha de truncamento. Isso significa que precisamos 9.750 / 1024 * 3 = 28,5GB de espaço em disco para nossos logs de transações gerados por caixa de correio.
Além disso, precisamos considerar a quantidade de espaço em disco necessária para os eventos de movimentação de caixas de correio para uma semana inteira: 13.888 / 1014 * 7 dias = 94,9GB de espaço em disco para as operações de movimentação de caixas de correios.
Assim, isso significa que cada banco de dados precisa de 123GB de espaço em disco para os logs de transações. Devemos incluir também um fator de sobrecarga de dados para considerar qualquer fenômeno inexplicável que possa ocorrer: 123GB * 1,2 = 148GB de espaço em disco para os logs de transações.
Se estivermos implantando um LUN dedicado para os logs de transações, não forneceríamos um LUN de 150GB porque isso significaria que poderíamos consumir todo o espaço em disco se tivéssemos tendo falhas de backup e movimentações excessivas de caixa de correio. Geralmente, você quer garantir que cada LUN seja provisionado de tal forma que somente 80% da capacidade do disco seja utilizada. A fórmula é:
Espaço do LUN = [utilização projetada do espaço em disco] / (1 – [percentual de espaço em disco desejado])
Espaço do LUN = 148GB / (1 – 0,2) = 148GB / 0,8 = 185GB de espaço do LUN para o volume dedicado do log de transações
Se você estiver implantando os logs de transações no mesmo LUN do banco de dados, poderia simplesmente combinar os requisitos de espaço em disco do log de transações com os requisitos de espaço em disco do banco de dados para o valor de [utilização projetada de espaço em disco].
Em primeiro lugar, você precisa obter uma linha de base de seu ambiente para determinar a taxa de geração de log típica por dia. Além disso, você deve configurar o monitoramento e agir em todos os alertas que são gerados. O monitoramento deve ser feito nos seguintes cenários:
Meu amigo, Mike Lagase, escreveu um ótimo artigo sobre como solucionar os problemas desse cenário - http://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx (observe que o artigo foi escrito com o Exchange 2007 em mente, assim, várias ferramentas e/ou recomendações podem não ser aplicáveis ao Exchange 2010). Além das etapas mencionadas por Mike, você pode usar o seguinte no Exchange 2010 para ajudar a determinar o crescimento inexplicado do log de transações (obrigado a Todd Luttinen por criar esta lista):
[PS] C:\>$stats = Get-StoreUsageStatistics –Database <Database Name> [PS] C:\>$stats | ? {$_.DigestCategory -eq 'LogBytes'} | group MailboxGuid |sort count -Descending | Select -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*
Iniciando em <date/time>, o serviço <name> executou esta atividade no servidor: Operações RPC: 24168. Páginas do Banco de Dados Lidas: 1329 (das quais 629 páginas pré-lidas). Páginas do Banco de Dados Atualizadas: 12418 (das quais 11555 páginas reatualizadas). Registros do Log do Banco de Dados Gerados: 13906. Bytes de Registros do Log do Banco de Dados Gerados: 660331. Tempo no Servidor: 19142 ms. Tempo no Modo do Usuário: 6100 ms. Tempo no Modo Kernel: 63 ms.
Acho que todos nós compreendemos como é importante garantir que haja capacidade suficiente para que a disponibilidade de banco de dados não seja afetada. Esperamos que essas informações ajudem no planejamento da capacidade do log de transações.
Ross Smith IV Gerente de programa principal Experiência do cliente do Exchange
Esta é uma postagem de blog traduzida. O artigo original encontra-se em Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted