Mantenimiento de bases de datos en Exchange 2010

Artículo original publicado el miércoles, 14 de diciembre de 2011

En los últimos meses se ha hablado mucho en torno a qué es el mantenimiento de bases de datos de segundo plano y por qué es importante para las bases de datos de Exchange 2010. Con suerte, este artículo responderá a estas cuestiones.

¿Qué tareas de mantenimiento se tienen que llevan a cabo con la base de datos?

Las siguientes tareas se tienen que llevar a cabo de manera rutinaria con las bases de datos de Exchange:

• Compactación de la base de datos
• Desfragmentación de base de datos
• Suma de comprobación de base de datos
• Revisión de páginas
• Llenado con ceros de las páginas

Compactación de la base de datos

El propósito principal de la compactación de la base de datos es liberar espacio sin usar dentro del archivo de base de datos (sin embargo, debería observarse que esto no devuelve dicho espacio sin usar al sistema de archivos). La intención es liberar páginas de la base de datos compactando registros en el menor número de páginas posibles, reduciendo así la cantidad de E/S necesaria. El motor de base de datos ESE hace esto tomando los metadatos de la base de datos, que es la información que se encuentra dentro de la base de datos que describe tablas de la base de datos, y para cada tabla, visitando cada página de la tabla, e intentando mover registros a páginas ordenadas de manera lógica.

El mantenimiento de una superficie de archivo de base de datos eficiente es importante por varios motivos, entre los que se incluyen los siguientes:

1. Reducción del tiempo asociado con la realización de copia de seguridad del archivo de base de datos
2. Mantenimiento de un tamaño de archivo de base de datos predecible, lo cual es importante para fines de tamaño de servidor/almacenamiento.

Antes de Exchange 2010, las operaciones de compactación de la base de datos se llevaban a cabo durante la ventana de mantenimiento en línea. Este proceso producía ES aleatoria conforme pasaba por la base de datos y volvía a ordenar registros en las páginas. Este proceso era literalmente demasiado bueno en versiones anteriores – al liberar páginas de bases de datos y volviendo a ordenar los registros, las páginas siempre estaban en orden aleatorio. Unido con la arquitectura de esquema de almacén, esto significaba que cualquier solicitud para extraer un conjunto de datos (como la descarga de elementos dentro de una carpeta) siempre resultaba en ES aleatoria.

En Exchange 2010, la compactación de la base de datos se rediseñó de manera que se prefiere la contigüidad sobre la compactación del espacio. Además, la compactación se movió de la ventana de mantenimiento en línea y es ahora un proceso de fondo que se ejecuta de manera continua.

Desfragmentación de base de datos

La desfragmentación de base de datos es una novedad en Exchange 2010 y también se denomina OLD v2 y desfragmentación de árbol B+. Su función es compactar así como desfragmentar (hacer secuenciales) las tablas de bases de datos que se han marcado/sugerido como secuenciales. La desfragmentación de base de datos es importante para mantener la utilización eficaz de recursos de disco con el tiempo (haga que la ES sea más secuencial en contraposición con que sea aleatoria) así como para mantener la compactibilidad de las tablas marcadas como secuenciales.

Puede pensar en la desfragmentación de base de datos como un monitor que vigila otras operaciones de página de base de datos para determinar si hay trabajo que hacer. Supervisa todas las páginas para ver las páginas libres, y si una tabla llega a un umbral donde un porcentaje alto importante del número de páginas de árbol B+ total, devuelve las operaciones de página de base de datos a la raíz. También funciona para mantener la contigüidad dentro de una tabla configurada con sugerencias de espacio secuenciales (una tabla creada con un patrón de uso secuencial conocido). Si la desfragmentación de base de datos ve un examen/lectura previa en una tabla secuencial y los registros no se almacenan en páginas secuenciales dentro de la tabla, el proceso desfragmentará dicha sección de la tabla, moviendo todas las páginas afectadas a una nueva extensión del árbol B+. Puede usar los contadores de rendimiento (mencionados en la sección de supervisión) para ver el poco trabajo que la desfragmentación de base de datos lleva a cabo una vez que se alcanza un estado estable.

La desfragmentación de base de datos es un proceso de segundo plano que analiza la base de datos de manera continua conforme se llevan a cabo las operaciones y, a continuación, desencadena el trabajo asíncrono cuando sea necesario. La desfragmentación de base de datos se limpia bajo dos escenarios:

1. El número máximo de tareas pendientes Esto evita que la desfragmentación de base de datos realice demasiado trabajo el primer pase si se ha producido un cambio masivo en la base de datos.
2. Una limitación de latencia de 100 ms Cuando el sistema se sobrecargue, la desfragmentación de base de datos empezará a despejar el trabajo de desfragmentación. El trabajo despejado se ejecutará la próxima vez que la base de datos pase por el mismo patrón operativo. No hay nada que recuerde qué trabajo de desfragmentación se despejó y retrocede y lo ejecuta una vez que el sistema dispone de más recursos.

Suma de comprobación de base de datos

La suma de comprobación de base de datos (también denominada Exploración de bases de datos en línea) es el proceso en el que se lee la base de datos en grandes fragmentos y se realiza una suma de comprobación de cada página (comprobada para los daños de página física). El propósito principal de la suma de comprobación es detectar los daños físicos y vaciados perdidos que puede que no se estén detectando por las operaciones transaccionales (páginas obsoletas).

Con Exchange 2007 RTM y todas las versiones anteriores, las operaciones de suma de comprobación tenían lugar durante el proceso de copia de seguridad. Esto suponía un problema para bases de datos replicadas, ya que la única copia de la que se iba a comprobar la suma era la copia de la que se estaba realizando la copia de seguridad. Para el escenario donde se estaba realizando la copia de seguridad de la copia pasiva, esto significaba que no se estaba realizando una suma de comprobación de la copia activa. Por tanto, en Exchange 2007 SP1, introdujimos una nueva tarea de mantenimiento en línea opcional, la suma de comprobación de mantenimiento en línea (para obtener más información, vea Exchange 2007 SP1 ESE Changes – Part 2).

En Exchange 2010, la exploración de bases de datos realiza la suma de comprobación de la base de datos y lleva a cabo operaciones posteriores al bloqueo de almacenamiento de Exchange 2010. El espacio se puede perder debido a bloqueos, y la exploración de bases de datos en línea encuentra y recupera el espacio perdido. La suma de comprobación de base de datos lee aproximadamente 5 MB por segundo para cada base de datos de exploración activa (copias activa y pasiva) que usa ES de 256 KB. La E/S es 100 por cien secuencial. El sistema de Exchange 2010 está diseñado con la idea de que todas las bases de datos se examinan por completo una vez cada siete días.

Si el análisis dura más de siete días, se registra un evento en el Registro de aplicaciones:

Id. de evento: 733
Tipo de evento: Información
Origen de evento: ESE
Descripción: Almacenamiento de información (15964) MDB01: La tarea de segundo plano de suma de comprobación de base de datos de mantenimiento en línea NO está terminando a tiempo para la base de datos 'd:\mdb\mdb01.edb'. Este pase se inició el 11/10/2011 y se ha estado ejecutando durante 604800 segundos (más de 7 día) hasta el momento.

Si tarda más de siete días en completarse el examen en la copia de la base de datos activa, la siguiente entrada se registrará en el Registro de aplicaciones una vez que se haya completado el examen:

Id. de evento: 735
Tipo de evento: Información
Origen de evento: ESE
Descripción: Almacenamiento de información (15964) MDB01: El mantenimiento de base de datos ha completado un pase completo en la base de datos 'd:\mdb\mdb01.edb'. Este pase se inició el 11/10/2011 y se ejecutó durante un total de 777600 segundos. Esta tarea de mantenimiento de base de datos ha superado el umbral de finalización de mantenimiento de 7 días. Deberían realizarse una o más de las siguientes acciones: aumentar la capacidad de proceso/rendimiento de ES del volumen que hospeda la base de datos, reducir el tamaño de la base de datos, y/o reducir la ES de mantenimiento que no sea de base de datos.

Además, se registrará una advertencia en desarrollo en el Registro de aplicación cuando tarde más de 7 días en completarse.

En Exchange 2010, hay dos modos de ejecutar la suma de comprobación de bases de datos en copias de bases de datos activas:

1. Ejecutar en segundo plano 24 horas siete día de la semana Este es el comportamiento predeterminado. Se debe usar para todas las bases de datos, especialmente para bases de datos mayores de 1 TB. Exchange examina la base de datos con una frecuencia no superior a una vez al día. Esta E/S de lectura es 100 por cien secuencial (lo que lo hace sencillo en el disco) y corresponde a una velocidad de exploración de cerca de 5 megabytes (MB)/seg en la mayoría de los sistemas. El proceso de exploración es de un solo subproceso y está limitado por la latencia de ES. Cuanto mayor sea la latencia, más se ralentizará la suma de comprobación de la base de datos porque espera más a que se complete el último lote antes de emitir otro examen de lote de páginas (se leen 8 páginas cada vez).
2. Ejecutar en el proceso de mantenimiento de base de datos de buzón programado Cuando seleccione esta opción, la suma de comprobación de base de datos es la última tarea. Puede configurar cuánto tiempo se ejecuta cambiando la programación de mantenimiento de base de datos de buzón. Esta opción solo debe usarse con bases de datos con un tamaño menor de 1 terabyte (TB), lo cual requiere menos tiempo en completar un examen completo.

Independientemente del tamaño de la base de datos, nuestra recomendación es sacar provecho del comportamiento predeterminado y no configurar las operaciones de suma de comprobación de bases de datos con la base de datos activa como un proceso programado (es decir, no lo configure como un proceso dentro de la ventana de mantenimiento en línea).

Para las copias de bases de datos pasivas, las sumas de comprobación de base de datos se producen durante el tiempo de ejecución, funcionando de manera continua en segundo plano.

Revisión de páginas

La revisión de páginas es el proceso en el que las páginas dañadas se reemplazan por copias correctas. Como se ha mencionado anteriormente, la detección de una página dañada es una función de suma de comprobación de bases de datos (además, las páginas dañadas también se detectan en tiempo de ejecución cuando la página se almacena en la caché de la base de datos). La revisión de páginas funciona con copias de bases de datos de alta disponibilidad. La manera en que se repara una página dañada depende de si la copia de la base de datos de alta disponibilidad es activa o pasiva.

Proceso de revisión de páginas

Llenado con ceros de las páginas

El llenado con ceros de las páginas de base de datos es el proceso en el que las páginas eliminadas de la base de datos se sobrescriben con un patrón (llenado con ceros) como medida de seguridad, que dificulta mucho más la detección de los datos.

Con Exchange 2007 RTM y todas las versiones anteriores, las operaciones de llenado con ceros de las páginas se producían durante el proceso de copia de seguridad de transmisión por secuencias. Además, puesto que se producían durante el proceso de copia de seguridad de transmisión por secuencias, no eran una operación registrada (por ejemplo, el llenado con ceros de las páginas no daba lugar a la generación de archivos de registro). Esto suponía un problema para las bases de datos replicadas, ya que las copias pasivas nunca tenían sus páginas llenadas con ceros, y las copias activas solo tendrían las páginas llenadas con ceros si llevaba a cabo una copia de seguridad de transmisión por secuencias. Por tanto, en Exchange 2007 SP1, introdujimos una nueva tarea de mantenimiento en línea opcional, las páginas de base de datos cero durante la suma de comprobación (para obtener más información, vea Exchange 2007 SP1 ESE Changes – Part 2). Cuando se habilita esta tarea llenaría con ceros las páginas durante la ventana de mantenimiento en línea, registrando los cambios, lo cual replicaría en las copias pasivas.

Con la implementación del SP1 de Exchange 2007 SP1, hay un lapso importante cuando se elimina una página a cuando se llena con ceros como resultado del proceso de llenado con ceros que se produce durante una ventana de mantenimiento programada. Por tanto, en Exchange 2010 SP1, la tarea de llenado con ceros de las páginas es ahora un evento de tiempo de ejecución que opera de manera continua, llenando las páginas con ceros típicamente en tiempo de transacción cuando se produce una eliminación permanente.

Además, las páginas de bases de datos también se pueden limpiar durante el proceso de suma de comprobación en línea. Las páginas de destino en este caso son:

• Los registros eliminados que no se podrían limpiar durante el tiempo de ejecución debido a tareas descartadas (si el sistema está demasiado sobrecargado) o debido a que se bloqueó el almacenamiento antes de que las tareas lograran limpiar los datos;
• Tablas eliminadas e índices secundarios. Cuando se eliminan, no limpiamos el contenido activamente, por tanto, la suma de comprobación en línea detecta que estas páginas ya no pertenecen a ningún objeto válido y las limpia.

Para obtener más información acerca del llenado con ceros en Exchange 2010, vea Descripción de la puesta a cero de páginas de Exchange 2010.

¿Por qué estas tareas no se llevan a cabo simplemente durante una ventana de mantenimiento programada?

Requerir una ventana de mantenimiento programado para el llenado con ceros de páginas, la desfragmentación de base de datos, la compactación de la base de datos y las operaciones de suma de comprobación en línea plantea problemas significativos, entre los que se incluyen los siguientes:

1. Tener operaciones de mantenimiento programadas dificulta la administración de centros de datos las 24 horas del días, los 7 días de la semana, que hospeden buzones de distintas zonas horarias y tengan poco tiempo o ninguno para una ventana de mantenimiento programada. La compactación de la base de datos en versiones anteriores de Exchange no tenía mecanismos de limitación, y puesto que la ES es predominantemente aleatoria, puede conducir a una pobre experiencia de usuario.
2. Las bases de datos del buzón de Exchange 2010 implementadas en el almacenamiento de nivel inferior (por ejemplo, 7.2K SATA/SAS) tienen un ancho de banda de ES efectivo reducido disponible para el ESE para llevar a cabo tareas de ventana de mantenimiento. Esto es un problema porque significa que las latencias de ES aumentarán durante la ventana de mantenimiento, evitando así que se completen las actividades de mantenimiento dentro de un período de tiempo deseado.
3. El uso de JBOD ofrece un desafío adicional a la base de datos en términos de verificación de datos. Con el almacenamiento RAID, es habitual que un controlador de la matriz realice en segundo plano un examen de un grupo de disco determinado, localizando y reasignando bloques erróneos. Un bloque erróneo (también conocido como sector) es un bloque de un disco que no se puede usar debido a daños permanentes (por ejemplo, daños físicos en las partículas del disco). También es habitual que un controlador de la matriz lea el disco reflejado alternativo si se ha detectado un bloque erróneo en la solicitud de lectura inicial. El controlador de la matriz marcará posteriormente el bloque erróneo como “erróneo” y escribirá los datos en un nuevo bloque. Todo esto se produce sin que la aplicación lo sepa, puede que con solo un pequeño aumento de la latencia de lectura de disco. Sin RAID o un controlador de la matriz, estos métodos de corrección y detección de bloques erróneos ya no estarán disponibles. Sin RAID, corresponde a la aplicación (ESE) decidir si detectar bloques erróneos y corregirlos (es decir, suma de comprobación de bases de datos).
4. Las bases de datos más grandes en discos de mayor tamaño requieren períodos de mantenimiento más largos para mantener la compactibilidad y secuencialidad de las bases de datos.

Debido a los problemas mencionados anteriormente, era fundamental en Exchange 2010 que las tareas de mantenimiento de las bases de datos se sacaran de un proceso programado y se llevaran a cabo durante el tiempo de ejecución de manera continua en segundo plano.

¿No impactarán estas tareas de segundo plano en mis usuarios finales?

Hemos diseñado estas tareas en segundo plano de manera que se limiten automáticamente basándose en la actividad que se produce con la base de datos. Además, nuestra orientación de tamaño en torno a perfiles de mensaje tiene en cuenta estas tareas de mantenimiento. Sin embargo, debe tener cuidado al diseñar su arquitectura de almacenamiento. Si planea almacenar varias bases de datos en el mismo LUN o volumen, asegúrese de que el tamaño agregado de todas las bases de datos no supera los 2 TB. Esto se debe a que el mantenimiento de la base de datos está limitado por la serialización en función del número de bases de datos/volumen y supone que el tamaño agregado no es superior a 2 TB.

¿Cómo puedo supervisar la eficacia de estas tareas de mantenimiento de segundo plano?

En versiones anteriores de Exchange, los eventos del Registro de aplicaciones se usarían para supervisar cuestiones como la desfragmentación en línea. En Exchange 2010, ya no hay eventos registrados para las tareas de mantenimiento de compactación y desfragmentación. Sin embargo, puede usar los contadores de rendimiento para realizar un seguimiento de las tareas de mantenimiento de segundo plano que se encuentran debajo del objeto MSExchange Database ==> Instances:

Encontrará la siguiente página llenando con ceros los contadores debajo del objeto MSExchange Database:

¿Cómo puedo comprobar el espacio en blanco en una base de datos?

Puede usar el Shell para comprobar el espacio en blanco disponible de una base de datos. Para bases de datos de buzón, use:

Get-MailboxDatabase MDB1 -Status | FL AvailableNewMailboxSpace

Para bases de datos de carpeta pública, use:

Get-PublicFolderDatabase PFDB1 –Status | FL AvailableNewMailboxSpace

¿Cómo puedo recuperar el espacio en blanco?

Naturalmente, después de ver el espacio en blanco disponible de la base de datos, la pregunta que siempre surge es: ¿cómo puedo recuperar el espacio en blanco?

Muchos suponen que la respuesta es llevar a cabo una desfragmentación en línea de la base de datos mediante ESEUTIL. Sin embargo, nosotros no recomendamos eso. Cuando realiza una desfragmentación sin conexión, crea una base de datos completamente nueva y las operaciones realizadas para crear esta nueva base de datos no se registran en registros de transacciones. La nueva base de datos también tiene una nueva firma de base de datos, lo que significa que invalida las copias de bases de datos asociadas con esta base de datos.

En el caso de que encuentre una base de datos que tenga un importante espacio en blanco y no espere que las operaciones normales lo recuperen, nuestra recomendación es la siguiente:

1. Cree una nueva base de datos y copias de bases de datos asociadas.
2. Mueva todos los buzones a la nueva base de datos.
3. Elimine la base de datos original y sus copias de bases de datos asociadas.

Confusión terminológica

Buena parte de la confusión radica en el término mantenimiento de bases de datos en segundo plano. De manera colectiva, todas las tareas mencionadas anteriormente componen el mantenimiento de bases de datos en segundo plano. Sin embargo, el Shell, EMC, y JetStress hacen referencia a la suma de comprobación de base de datos como mantenimiento de bases de datos en segundo plano, y eso es lo que está configurando cuando lo habilita o deshabilita mediante estas herramientas.

Ilustración 1: Habilitar el mantenimiento de bases de datos en segundo plano para una base de datos usando EMC

Habilitar el mantenimiento de bases de datos en segundo plano usando el Shell:

Set-MailboxDatabase -Identity MDB1 -BackgroundDatabaseMaintenance $true

Ilustración 2: Ejecución del mantenimiento de bases de datos en segundo plano como parte de una prueba de JetStress

Mi proveedor de almacenamiento me ha recomendado que deshabilite la suma de comprobación de bases de datos como tarea de mantenimiento en segundo plano, ¿qué debo hacer?

La suma de comprobación de base de datos puede convertirse en una carga impositiva de ES si el almacenamiento no está diseñado correctamente (aunque sea secuencial) ya que realiza ES de lectura de 256 K y genera aproximadamente 5 MB/s por base de datos.

Como parte de nuestra guía de almacenamiento, recomendamos que configure su tamaño de sección de matriz de almacenamiento (el tamaño de las secciones escritas en cada disco de una matriz; también denominadas tamaño de bloque) para que tengan un tamaño de 256 KB o superior.

También es importante probar su almacenamiento con JetStress y asegurarse de que la operación de suma de comprobación de base de datos se incluye en el pase de prueba.

Al final, si se produce un error en la ejecución de JetStress debido a la suma de comprobación de bases de datos, tiene algunas opciones:

1. No use seccionado  Use pares RAID-1 o JBOD (que pueden requerir cambios en la arquitectura) y obtenga el máximo beneficio de los patrones de ES secuenciales disponibles en Exchange 2010.

2. Prográmelo  Configure la suma de comprobación de base de datos, no para que sea un proceso en segundo plano, sino un proceso programado. Cuando implementamos la suma de comprobación de base de datos como un proceso en segundo plano, comprendimos que algunas matrices de almacenamiento estarían tan optimizadas para ES aleatoria (o tenían limitaciones de ancho de banda) que no manejarían bien la ES de lectura secuencial. Por ese motivo la creamos para que se pudiera desactivar (lo que mueve la operación de suma de comprobación a la ventana de mantenimiento).

   Si hace esto, recomendamos tamaños de bases de datos menores. Tenga también en cuenta que las copias pasivas todavía ejecutarán la suma de comprobación de base de datos como un proceso en segundo plano, por lo que todavía necesita justificar esta capacidad de proceso en nuestra arquitectura de almacenamiento. Para obtener más información sobre este asunto, vea Jetstress 2010 and Background Database Maintenance.

3. Use un almacenamiento diferente o mejore las capacidades del almacenamiento  Elija el almacenamiento capaz de reunir las prácticas recomendadas de Exchange (256 KB+ tamaño de sección).

Conclusión

Los cambios de arquitectura al motor de base de datos en Exchange Server 2010 mejoran drásticamente su rendimiento y potencia, pero cambian el comportamiento de las tareas de mantenimiento de bases de datos de versiones anteriores. Con suerte, este artículo le ayudará a comprender en qué consiste el mantenimiento de bases de datos de segundo plano en Exchange 2010.

Ross Smith IV
Director principal de programas
Experiencia del usuario de Exchange

Esta entrada de blog es una traducción. Puede consultar el artículo original en Database Maintenance in Exchange 2010