Como prevenir llegar al último número disponible para los transaction logs.

Por Daniel Seveso

An Internal processing Error has occurred. ID no: C1041724

El Exchange System Manager puede presentarte este error cuando intentas montar una o más bases de datos de Exchange. No es que sea algo nuevo, pero tuve dos casos como este en una semana affectando 2500 usuarios en un caso y 3000 en otro, asi que dedicí escribir este artículo para ayudar a prevenir la situación. El artículo KB830408 describe el problema y como solucionarlo.

¿Como es la numeración de los logs de transacciones?

A partir de Exchange 2000 se incluye el concepto de Storage Groups (SG). SG es una agrupación de bases de datos que comparten, entre otras cosas, los logs de transacciones. En otras palabras, hay un solo flujo de logs de transacciones para todas las bases que forman parte de un SG. Los logs de transacciones en Exchange 2000 y 2003 se numeran de la siguiente forma:

[E nn 00001.log] a  [E nn ffff0.log].

nn representa el número de SG comenzando en 00 para el primer SG y las siguientes cinco cifras son un número hexadecimal secuencial de 1 a ffff0. [E nn.log] es el log que está siendo escrito actualmente, el cual se renombra siguiendo el número de secuencia cuando está completo, aunque internamente ya posee su número definitivo.

Este rango de log permite que las bases de datos acepten aproximadamente 5 TBytes de datos y transacciones (considerando el tamaño de 5Mb de los logs), antes de que Exchange se quede sin números de secuencia disponibles para procesar nuevas transacciones.

En Exchange 2007, esta situación cambia un poco. Los tamaños de los logs de transacciones disminuye a 1Mb, y la numeración cambia agregando 3 dígitos más hexadecimales (ej. E nn 00000001.log - E nn 7FFFFFFF.log o aprox. 2050 TBytes usando la misma idea anterior)

¿Como afecta este problema  a las distintas versiones de Exchange?

De peor a mejor:

Exchange 2000 previo al update rollup post SP3 de August 2004, y Exchange 2003 RTM:
No deberías estar corriendo estas versiones en producción. Por favor actualiza tu servidor inmediatamente y refierete al artículo KB830408 si todavía estas interesado en saber que pasaba.

Exchange 2000 post SP3 rollup de Agosto 2004 y Exchange 2003 SP1 en adelante:
El error C1041724 no es exclusivo de este problema, por lo que deberás confirmar lo siguiente:
Las bases de datos del SG en cuestión se desmontarán automáticamente como mecanismo de protección, y verás los siguientes errores en el log de aplicaciones:

Event ID: 1159
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Description: Database error 0xfffffdf9 occurred in function JTAB_BASE::EcEscrowUpdate while accessing the database "First Storage Group\Mailbox Store (SERVER)".

Event ID: 9518
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Description: Error 0xfffffddc starting Storage Group Path_of_Storage_Group on the Microsoft Exchange Information Store. Storage Group - Initialization of Jet failed.

El error 0xfffffddc significa JET_errLogSequenceEndDatabasesConsistent

¿Como puedo evitar este problema?

1) A partir del número de secuencia EnnE0000.log, el Exchange Storage Engine (ESE) registrará un evento de advertencia 514. Este evento es registrado con la antelación suficiente para programar ventana de mantenimento y reíniciar la secuencia.

Event Type: Warning
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 514
Description: Information Store <>: Log sequence numbers for this instance have
almost been completely consumed. To begin renumbering from generation 1, the
instance must be shutdown cleanly and all log files must be deleted. Backups will
be invalidated.

Monitorea estos eventos regularmente y configura una notificación proactiva a partir del mismo.

2) Al igual que con un automovil, no tienes que esperar a que el tanque esté en reserva para cargar combustible. Cuando veas el número de secuencia lo suficientemente alto, puedes en cualquier momento ejecutar el procedimiento de reinicio de la secuencia,  aunque estes lejos del EnnE0000.log.

Procedimiento de reinicio de la secuencia de los logs de transacciones:

1) Toma nota del prefijo (Enn) y los dos directorios que aparecen en las propiedades del SG. Estos directorios son el de Logs y el de System respectivamente.

2) Desmonta todas las bases de datos del Storage Group.

3) Por precaución, mueve todos los logs de transacciones con el prefijo Enn a un directorio de respaldo.

4) Mueve también al directorio de respaldo el Enn.chk que está en el directorio System de Exchange

5) Finalmente monta todas las bases de datos nuevamente.

Luego de este procedimiento los números de transaction logs comenzarán nuevamente a partir de Enn00001.log

IMPORTANTE: Este procedimiento invalida los backup online que tengas, por lo que debes hacer un backup online inmediatamente despues de montar las bases de datos.

¿Como puedo solucionar este problema si me ha ocurrido?

Si las bases se han desmontado como consecuencia de este problema, te recomiendo verificar la consistencia de las bases de datos corriendo el siguiente comando:

eseutil /mh <nombre del archivo.edb>  

La salida de este comando despliega el contenido del header de la base de datos. En particular nos importan estos campos, que indican que la base de datos ha sido correctamente desmontada:

State: Clean Shutdown
Log Required: 0-0 (0x0-0x0)

Una vez que confirmas estos campos, basicamente debes seguir el procedimiento descrito arriba para reiniciar la secuencia.

Nota: Si este problema te ocurre con versiones previas a Exchange 2000 post SP3 rollup de Agosto 2004 o Exchange 2003 SP1 hay otros pasos adicionales que deberás seguir. Los mismos están documentados en el siguiente artículo:

830408 Store databases are dismounted without warning or users cannot log on to
their mailboxes in Exchange Server 2003 or in Exchange 2000 Server
https://support.microsoft.com/default.aspx?scid=kb;EN-US;830408

Saludos,