Entenda o comportamento denominado “Checkpoint Depth too deep” em servidores Exchange.
Por Viviane Lopes
Publicado em: 14 de setembro de 2006
Aplica-se a:
Exchange 2000 Server
Exchange 2003 Server
Nesta página
Visão Geral
Conceitos importantes
Checkpoint Depth:
Os cenários mais comuns para o acontecimento deste comportamento são:
Como monitorar o servidor Exchange ?
Conclusão
Visão Geral
Uma das causas mais comuns para o súbito shutdown dos bancos de dados de um servidor Exchange é um comportamento conhecido como “Checkpoint Depth too deep”.
Neste artigo vamos explicar o que acontece durante este processo, principais causas e como monitorar o servidor Exchange de forma a evitar o acontecimento deste comportamento.
Conceitos importantes
ESE (Extensible Storage Engine): Database Engine utilizada pelo Exchange Information Store, baseado na tecnologia denominada Microsoft Joint Engine (JET).
Log de transação (Transaction Log): Todas as alterações realizadas no banco de dados do Exchange são primeiras gravadas no log de transação, e posteriormente no banco de dados.
Os logs de transações são críticos para o servidor Exchange e existem para garantir a integridade transacional do banco de dados e possibilitar a recuperação total dos dados em caso de uma parada abrupta do servidor.
Checkpoint: O Checkpoint é um arquivo de sistema do servidor Exchange responsável por acompanhar o progresso dos logs de transações em relação aos bancos de dados.
Cada Storage Group contém um único arquivo de Checkpoint, denominado Enn.chk, onde nn representa o prefixo do Storage Group em questão.
Exemplo:
E00.chk – checkpoint do Primeiro Storage Group. E01.chk – checkpoint do Segundo Storage Group E02.chk – checkpoint do Terceiro Storage Group. E03.chk – checkpoint do Quarto Storage Group.
Checkpoint Depth:
Em um servidor Exchange 2000 ou 2003, cada Storage Group pode ter no máximo 1008 logs de transações não aplicados nos bancos de dados em um dado momento. O número 1008 está pré-definido no código do produto e não pode ser customizado.
O controle de transações não aplicadas no banco de dados é realizado através do Checkpoint.
Quando o número de logs de transações não aplicados em um Storage Group atinge o número máximo permitido, o servidor Exchange começa o processo de shutdown de todos os bancos de dados do Storage Group em questão.
Nesta situação, os seguintes eventos são informados no log de aplicações:
Event ID : 471 Category : Logging/Recovery Source : ESE Type : Error Message : Information Store (2908) Unable to rollback operation #12317050 on database G:\First Storage Group\Mailbox Store (Server1). Error: -614. All future database updates will be rejected. Event Type: Error Event Source: MSExchangeIS Event Category: General Event ID: 1159 Description: Database error 0xfffffd9a occurred in function JTAB_BASE::EcUpdate while accessing the database "<C:\Program Files\Exchsrvr\mdbdata\vip.edb>".
Os erros -614 e 0xfffffd9a podem ser traduzidos para:
“JET_errCheckpointDepthTooDeep” – too many outstanding generations between checkpoint and current generation.
O serviço do Information Store opera desta forma para impedir que o controle de Checkpoint fique muito distante dos logs de transações criados pelo sistema. É uma proteção do servidor Exchange para garantir a integridade dos dados.
Em um servidor Exchange com alto volume de carga, o valor do Checkpoint Depth normalmente deve ficar entre 4 ou 5 logs. Isso significa que as transações contidas nestes logs ainda não foram aplicadas no banco de dados. Se o servidor parar subitamente, por exemplo, por um problema de falta de energia, estes 4 logs serão os logs de transações necessários para colocar o banco de dados consistente, com os dados atualizados até o momento da queda.
Quando a energia for restaurada e o serviço do Information Store reiniciado, o arquivo Checkpoint de cada Storage Group será consultado. O Checkpoint informa ao Information Store à partir de qual log de transação ele deverá iniciar o processo de recuperação dos dados que ainda não haviam sido gravados nos bancos de dados.
Os cenários mais comuns para o acontecimento deste comportamento são:
Um processo “congelou” as atualizações no arquivo de checkpoint. Normalmente isso acontece durante o processo de backup on-line.
Duas tarefas concorrentes estão sendo executadas ao mesmo tempo, como por exemplo uma movimentação de mailboxes em larga escala e uma tarefa de backup.
O servidor está experimentando problemas de performance. Por exemplo, problemas de performance nos discos podem prevenir o servidor de responder rapidamente a múltiplas requisições de I/O.
Como monitorar o servidor Exchange ?
01 - À partir do Rollup de Setembro para o Exchange 2000 e versões posteriores, é possivel monitorar o número de logs de transações não aplicados em um Storage Group através do Performance Monitor.
O contador “Log Generation Checkpoint Depth” (Objeto Database è Instances) reporta o número de logs de transações de um Storage Group que ainda não foram aplicados nos bancos de dados.
O valor informado pode ser entendido como a quantidade de logs que devem ser aplicados no banco de dados caso o processo do Information Store (Store.exe) apresente qualquer tipo de falha.
A lógica é – quanto maior o “Log generation depth”, mais tempo o processo de inicio (startup) do serviço do Information Store levará.
Muitas vezes trabalhamos em incidentes de suporte em que o cliente reporta uma demora significativa para que o serviço do Information Store inicie – nesta situação, o serviço permanece no estado de “Starting” e todas as tentativas de conexões de clientes são recusadas.
O log de aplicações irá reportar o evento 301 – indicando que o processo de aplicação dos logs de transações nos bancos de dados está sendo realizado (soft-recovery). Se o Checkpoint estiver muito atrás em relação a geração de logs presente no disco, o processo poderá demorar muito mais do que o “desejado”.
Event Type: Information Event Source: ESE Event ID: 301 Description: Information Store (1728) The database engine has begun replaying logfile D:\Program Files\Exchsrvr\SG1\E001453A.log.
O efeito colateral é obviamente percebido pelos clientes, que não poderão se conectar enquanto o processo não estiver finalizado.
No exemplo abaixo, o Checkpoint Depth está no valor 4, ou seja, informações contidas em 4 logs de transações ainda não foram aplicados nos bancos de dados.
.jpg "Cc668489.imagem002(pt-br,TechNet.10).jpg")
Durante uma tarefa de backup, é normal que este valor cresça, pois o processo de backup “congela” o checkpoint temporariamente para garantir a integridade dos dados que estão sendo copiados. Porém, se o tempo de backup de um Storage Group for demasiado alto, e o servidor estiver sendo acessado durante o processo (gerando logs de transações), o valor pode chegar ao limite de 1008 logs, quando então todos os bancos de dados serão desmontados.
A solução neste caso é planejar o tamanho dos Storage Groups adequadamente, levando em consideração o **tempo de backup** e a **quantidade de logs de transações** gerados durante as atividades normais dos usuários.
Outra situação comum, é uma tarefa de backup mal-sucedida, onde o processo de backup não descongela o Checkpoint. O servidor Exchange continuará trabalhando normalmente, até que o Checkpoint Depth atinga 1008 logs – neste ponto os bancos de dados serão desmontados.
Neste caso, o correto é verificar o que há de errado com a rotina de backup e o motivo pela qual o processo não está sendo finalizado corretamente.
Outra forma de monitorar o CheckPoint Depth é utilizando o pacote para monitoramento do Exchange existente no servidor MOM (Microsoft Operations Management):
O pacote de monitoramento para Exchange existente no servidor MOM inclui a seguinte regra:
ESE Log Generation CheckPoint Depth > 800 – O MOM irá disparar um alerta ao administrador quando o valor ultrapassar a marca de 800.
Se você precisar de mais informações, utilize os seguintes artigos da Microsoft como referência:
Conclusão
Planejamento e monitoramento são fundamentais para o bem-estar do servidor Exchange. A indisponibilidade causada pelo comportamento do Checkpoint Depth too deep pode ser prevenida através das técnicas mencionadas acima.
Viviane Lopes atua como engenheira de suporte há 12 anos, especializando-se em Exchange Server e Directory Services. Analista de Sistemas, trabalhou no Brasil de 1994 a 2002 em um parceiro da Microsoft no estado de Goiás. Há 4 anos trabalha na Microsoft EUA, fazendo parte do time de Suporte Enterprise para a América Latina, localizado em Las Colinas, Texas. Viviane atua como Support Escalation Engineer para Exchange, e também é certificada como MCSE e MCSA em Exchange Server e Windows Server.