Jaa

Planejamento de capacidade: sim, o espaço do log de transações é essencial para manter os bancos de dados íntegros e montados

  • Artikkeli

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!).

Introdução ao planejamento de capacidade

Para dimensionar adequadamente um LUN do log de transações, precisamos entender alguns aspectos sobre o ambiente:

  1. Quantas caixas de correio residirão no banco de dados?
  2. Qual é o perfil de mensagem das caixas de correio no banco de dados?
  3. Qual é o tamanho médio das mensagens?
  4. Qual é o tamanho médio das caixas de correio?
  5. Quantas caixas de correio são movidas por dia?
  6. Qual é a solução de backup e restauração?
  7. A solução precisa levar em consideração algum outro cenário de falha, como falhas de rede?

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.

  Truncamento do log de transações Proteção recomendada contra falha de backup
Backup completo diário Diário 3 dias
Backup completo semanal / Incremento diário Diário 3 dias
Backup completo semanal / Diferença diária Semanal 7 dias
Backup completo quinzenal / Incremento diário Diário 3 dias
Proteção nativa de dados do Exchange Logs não são mais necessários 3 dias

É 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].

Como posso impedir o consumo de todo o meu espaço em disco do log de transações?

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:

  1. Espaço em disco do LUN do Log de Transações. Configuração de vários limites e diferentes mecanismos de alerta. Seu primeiro alerta não deve ser aquele que indica que 90% de seu disco foi consumido. Se você souber sua linha de base de geração típica de log, poderá configurar um limite para relatórios se estiver com 20% a mais, por exemplo.
  2. Monitore a conclusão bem sucedida de seus backups (se você não está aproveitando as vantagens da Proteção de Dados Nativa do Exchange). Sua primeira indicação de falhas de backup não deve ocorrer quando você fica sem espaço em disco.
  3. Monitore os eventos de truncamento no Log do Aplicativo.
  4. Monitore a integridade de replicação da cópia do banco de dados. 

E se eu estiver tendo um crescimento inexplicável em meus Logs de Transações?

Meu amigo, Mike Lagase, escreveu um ótimo artigo sobre como solucionar os problemas desse cenário - https://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):

  1. Você pode usar o cmdlet de estatísticas de uso do armazenamento  (get-StoreUsageStatistics with DigestCategory = ‘LogBytes’) para identificar as caixas de correio que geram contagens altas de bytes do log. Observe que isso nem sempre funciona nos casos em que os bytes do log não são gerados pelo proprietário da caixa de correio ou em que a operação é realizada em nome do cliente (como CopyOnWrite) e não inclui bytes do log gerados pelos serviços do sistema (relatado na ID de Evento 9826). Essas estatísticas oferecem um resumo dos últimos 10 minutos de atividade das principais caixas de correio que geram as atividades do log (até 6 exemplos abordando a última hora). O seguinte exemplo mostra como usar as estatísticas de uso do armazenamento para encontrar as principais caixas de correio que geram bytes do log na última hora:

    [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*

    MailboxGuid SampleID SampleTime LogRecordCount LogRecordBytes
    c007c87a-e030-4414-b741-9cf61e88b9de 5 11/7/2011 4:25:05 PM 237 274163
    c007c87a-e030-4414-b741-9cf61e88b9de 4 11/7/2011 4:35:05 PM 451 387362
    c007c87a-e030-4414-b741-9cf61e88b9de 3 11/7/2011 4:45:06 PM 483 144999
    c007c87a-e030-4414-b741-9cf61e88b9de 2 11/7/2011 4:55:06 PM 734 293433
    c007c87a-e030-4414-b741-9cf61e88b9de 1 11/7/2011 5:05:06 PM 933 411485
    c007c87a-e030-4414-b741-9cf61e88b9de 0 11/7/2011 5:15:06 PM 247 209987

  2. Existem também eventos de aplicativos gerados para clientes administrativos (ID do Evento 9826). Estas estatísticas representam 2 horas de atividade:

    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.

  3. O contador do monitor de desempenho "MSExchangeIS Client(*)\JET Log Record Bytes/sec" pode ser usado para identificar que tipo de cliente está causando o crescimento do log.

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