Checkpoint Depth too deep

vslopes — Wed, 15 Mar 2006 19:15:00 GMT

Uma das causas mais comuns para o súbito shutdown dos bancos de dados de um servidor Exchange é o comportamento conhecido como “Checkpoint Depth too deep”.

Neste artigo vou explicar o que acontece durante o 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 inicialmente 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, 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 problema são:

01 – Um processo “congelou” as atualizações no arquivo de checkpoint. Normalmente isso acontece durante o processo de backup on-line.

02 – 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.

03 – 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 Category:
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 no servidor Exchange 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.

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 melhor é verificar o que há de errado com a rotina de backup e o motivo pela qual o processo não está sendo finalizado corretamente.

02 – 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, por favor utilize os seguintes artigos da Microsoft como referência:

905801 The information store is dismounted, and an event ID 1159 message is logged in Exchange Server 2003 or in Exchange 2000 Server

http://support.microsoft.com/default.aspx?scid=kb;EN-US;905801

819771 Update to monitor uncommitted transaction log files

http://support.microsoft.com/default.aspx?scid=kb;EN-US;819771

Viviane Lopes

Central Exchange : Information Store

Checkpoint Depth too deep