Resistencia del registro perdido y actividad del registro de transacciones en Exchange 2007

 

Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Última modificación del tema: 2009-01-14

En este tema se trata la resistencia del registro perdido (LLR) y una función asociada llamada rotación de registros. Estas características se presentaron con la versión de lanzamiento (RTM) de Microsoft Exchange Server 2007. El comportamiento de estas características también se ha modificado en Exchange 2007 Service Pack 1 (SP1). Estas características se encuentran en todos los servidores de buzones. No obstante, el comportamiento de estas características depende de la configuración del servidor de buzones y de la versión de Exchange 2007 que esté instalada.

Resistencia del registro perdido

En Exchange 2007, un componente interno del motor de almacenamiento extensible (ESE), denominado LLR, permite recuperar bases de datos de Exchange incluso si se han perdido o dañado uno o varios de los archivos de registro de transacciones generados más recientes. De forma predeterminada, LLR está habilitado en todos los servidores de buzones de Exchange 2007. LLR permite montar una base de datos de buzones incluso aunque no se encuentren disponibles los archivos de registro generados recientemente. Una causa de que existan archivos de registro no disponibles es una mala conmutación por error en un entorno de replicación continua en clúster (CCR), lo que también se conoce como interrupción no programada. Para obtener más información acerca de las conmutaciones por error con pérdida de información, consulte Cortes programados y no programados. Para obtener información detallada sobre cómo recuperar una base de datos con archivos de registro que faltan, consulte Modo de recuperación Eseutil /R.

Nota

En un entorno de replicación continua, LLR sólo está habilitado para la copia activa de una base de datos. LLR no se usa con la copia pasiva, ya que las bases de datos pasivas siempre se mantienen lo más actualizadas posible.

El orden de las operaciones de escritura de datos de Exchange es siempre la memoria, el archivo de registro y, a continuación, el archivo de la base de datos. LLR funciona retrasando las escrituras en la base de datos hasta que se haya creado el número especificado de generaciones de registro. LLR retrasa las actualizaciones a la base de datos durante un breve período. El tiempo que se retrasan las escrituras depende de la velocidad a la que se generen los registros.

En el caso de una conmutación por error, el servicio Almacén de información de Microsoft Exchange monta automáticamente la copia pasiva de las bases de datos si el número de registros perdidos es menor que la cantidad aceptable que haya configurado un administrador. El administrador determina el número máximo de registros que se pueden perder sin que deje de montarse la base de datos en una conmutación por error utilizando el parámetro AutoDatabaseMountDial. Este parámetro, que se representa en el servicio de directorio de Active Directory mediante un atributo de Exchange denominado msExchDataLossForAutoDatabaseMount, tiene tres valores: Lossless, Buena disponibilidad y Máxima disponibilidad. Lossless tiene un valor 0 de pérdida de registros, el valor de Buena disponibilidad es de 3 y Máxima disponibilidad tiene el valor predeterminado 6. Para obtener instrucciones detalladas sobre la configuración de estos valores, consulte Cómo ajustar la configuración de la conmutación por error y el montaje para la replicación continua de clústeres. Al configurar el sistema para Buena disponibilidad o Máxima disponibilidad, no utilice espacios (por ejemplo, use GoodAvailability y BestAvailability).

Rotación de registros de transacciones

El mecanismo denominado rotación de registros se utiliza para reducir aún más la pérdida de datos. Funciona cerrando periódicamente el archivo de registro de transacciones actual y creando la siguiente generación. Este mecanismo ayuda a LLR y, a su vez, a CCR, a reducir la pérdida de datos resultante de la pérdida de archivos de registro, principalmente después de una conmutación por error con pérdidas.

Importante

El mecanismo de rotación de registros no genera registros de transacciones si no existe actividad de usuario o de la base de datos. De hecho, la rotación de registros está diseñada para que sólo se produzca cuando hay un registro parcialmente lleno.

La rotación del registro hacia delante significa que el archivo de registro actual (Exx.log) se cierra y se genera un nuevo archivo de registro de transacciones, incluso si el actual no está lleno. Para obtener más información acerca del registro de transacciones, consulte Descripción del registro de transacciones.

El comportamiento de la rotación de registros se basa en el valor de profundidad de LLR. En un entorno CCR que ejecute Exchange 2007 RTM, la profundidad de LLR es un valor numérico igual a 1 más el número de tolerancia de registros perdidos determinado por el valor del parámetro AutoDatabaseMountDial. Por ejemplo, si el valor del parámetro AutoDatabaseMountDial es 6, lo que indica que el sistema está configurado para Máxima disponibilidad, el valor de la profundidad de LLR es 7.

En un entorno CCR que ejecute Exchange 2007 SP1, la profundidad de LLR tiene un valor de 10 que no se puede modificar, independientemente del valor del parámetro AutoDatabaseMountDial.

Tanto en Exchange 2007 RTM como en SP1, la profundidad de LLR tiene un valor de 1 que no se puede modificar para todos los servidores de buzones que no estén en entornos CCR (por ejemplo, servidores de buzones independientes con o sin LCR y clústeres de copia única).

La rotación de registros se producirá después de que el sistema haya estado inactivo durante un tiempo calculado. Para calcular cuándo se producirá la rotación de registros, el sistema utiliza la siguiente fórmula:

[15 (minutos) ÷ valor de profundidad de LLR] = Frecuencia de la actividad de rotación de registros (en minutos)

Después puede dividir 1.440 (los minutos que tiene un día) por la frecuencia de la actividad de rotación de registros para determinar el número máximo de archivos de registro por grupo de almacenamiento que se generaría cada día como resultado de la actividad de rotación de registros.

Por ejemplo, en entornos CCR que ejecuten Exchange 2007 SP1, la profundidad de LLR es 10. De este modo, la actividad de rotación de registros se produce cada 1,5 minutos, y el número máximo de archivos de registro generados por grupo de almacenamiento cada día como resultado de la actividad de rotación de registros es de 960.

Tamaño de rotación de registros

Para que se desarrolle una rotación de registros de un tamaño significativo en un grupo de almacenamiento, deben cumplirse las siguientes condiciones:

  • El grupo de almacenamiento debe contener una base de datos de buzones.

  • El grupo de almacenamiento debe tener poca actividad de usuario que cree registros de transacciones.

  • El grupo de almacenamiento debe tener uno o varios buzones en los que un proceso o una aplicación inicien sesión con frecuencia.

El número máximo de archivos de registro que se generará cada día para un grupo de almacenamiento inactivo depende de la configuración del servidor de buzones. El número máximo de archivos de registro por grupo de almacenamiento inactivo para cada configuración de servidor de buzones se indica en la siguiente tabla.

Número máximo de archivos de registro por grupo de almacenamiento inactivo para cada configuración de servidor de buzones de Exchange 2007 RTM

Configuración de servidor de buzones Número máximo de archivos de registro de transacciones generados al día por un grupo de almacenamiento inactivo
  • Independiente (con y sin LCR)

  • Clúster de copia única

  • CCR con disponibilidad Lossless

96

CCR con Buena disponibilidad

384

CCR con Máxima disponibilidad

672

Número máximo de archivos de registro por grupo de almacenamiento inactivo para cada configuración de servidor de buzones de Exchange 2007 SP1

Configuración de servidor de buzones Número máximo de archivos de registro de transacciones generados al día por un grupo de almacenamiento inactivo
  • Independiente (con y sin LCR)

  • Clúster de copia única

96

CCR con Lossless (Sin pérdida), Buena disponibilidad y Máxima disponibilidad.

960

Los servidores de buzones suelen crear más registros de transacciones que el valor mostrado en las tablas anteriores a causa de la actividad de los usuarios, el mantenimiento en línea y otros factores.