Administrar copias de base de datos de buzones

Artículo
05/13/2016

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2015-03-09

La movilidad de bases de datos es una nueva arquitectura en Microsoft Exchange Server 2010 que elimina el concepto de grupos de almacenamiento y desconecta una base de datos de buzones de correo de Exchange 2010 de un servidor de buzones. Como los grupos de almacenamiento han sido eliminados de Exchange 2010, la replicación continua opera en el nivel de base de datos. En Exchange 2010, los registros de transacciones se replican en uno o más servidores de buzones de correo, y se reproducen en una o más copias de una base de datos de buzones de correo almacenada en esos servidores. Varios conceptos que se usan en la replicación continua de Exchange Server 2007 permanecen en Exchange 2010, como, por ejemplo, los conceptos de divergencia, el uso del marcado de montaje de base de datos automático y el uso de redes públicas y privadas.

Administración de copias de bases de datos

Después de que se crean varias copias de una base de datos, puede usar la Consola de administración de Exchange (EMC) y el Shell de administración de Exchange para supervisar el estado de cada copia y para realizar otras tareas de administración asociadas con las copias de bases de datos. Algunas de las tareas de administración que puede necesitar realizar incluyen la suspensión o reanudación de una copia de base de datos, la inicialización de una copia de base de datos, la supervisión de copias de base de datos, la configuración de copias de base de datos y la eliminación de una copia de base de datos.

Suspensión y reanudación de copias de base de datos

Por diversos motivos, como la realización de un mantenimiento planeado, puede ser necesario suspender y reanudar la actividad de replicación continua de una copia de base de datos. Además, algunas tareas de administración, como la inicialización, requieren que, primero, se suspenda la copia de base de datos. También recomendamos la suspensión de toda actividad de replicación cuando se cambia la ruta para la base de datos o los archivos de registro. Puede suspender y reanudar la actividad de una copia de base de datos mediante el uso de la EMC o mediante la ejecución de los cmdlets Suspend-DatabaseCopy y Resume-DatabaseCopy en el Shell. Para obtener instrucciones detalladas acerca de cómo suspender o reanudar la actividad de replicación continua de una copia de base de datos, consulte Suspender o reanudar una copia de base de datos de buzones.

El truncamiento del registro no se produce en la copia de base de datos de buzones de correo activa cuando se suspenden una o más copias pasivas. Si las actividades de mantenimiento planeado llevarán un período prolongado (por ejemplo, varios días), puede ser que tenga una gran acumulación de archivos de registro. Para evitar que la unidad del registro se llene con registros de transacciones, puede quitar la copia de base de datos pasiva afectada en lugar de suspenderla. Cuando finaliza el mantenimiento planeado, puede volver a agregar la copia de base de datos pasiva.

Inicialización de una copia de base de datos

La inicialización, también conocida como actualización, es el proceso en el que una base de datos, ya sea una base de datos en blanco o una copia de la base de datos de producción, se agrega a la ubicación de la copia de destino en otro servidor de buzones de correo en el mismo grupo de disponibilidad de base de datos (DAG) que la base de datos de producción. Ésta se convierte en la base de datos de base para la copia mantenida por ese servidor.

En función de la situación, la inicialización puede ser un proceso automático o manual que debe iniciar el usuario. Cuando se agrega una copia de base de datos, la copia se inicializa automáticamente, siempre que el servidor de destino y su almacenamiento estén configurados correctamente. Si desea inicializar una copia de base de datos de forma manual y no desea que la inicialización se produzca automáticamente al crear la copia, puede usar el parámetro SeedingPostponed al ejecutar el cmdlet Add-MailboxDatabaseCopy.

Prácticamente no es necesario reinicializar las copias de base de datos después de que se ha producido la inicialización inicial. Pero si es necesario reinicializar o si desea inicializar manualmente una copia de base de datos en lugar de que el sistema inicialice la copia automáticamente, estas tareas se pueden realizar con el Asistente para actualizar copias de bases de datos en la EMC o con el cmdlet Update-MailboxDatabaseCopy del Shell. Antes de inicializar una copia de base de datos, primero, debe suspender la copia de base de datos de buzones de correo. Para obtener instrucciones detalladas acerca de cómo inicializar una copia de base de datos, consulte Actualizar una copia de la base de datos de buzones.

Después de que finaliza una operación de inicialización manual, la replicación de la copia de base de datos de buzones de correo inicializada se reanuda automáticamente. Si no desea que la replicación se reanude automáticamente, puede usar el parámetro ManualResume al ejecutar el cmdlet Update-MailboxDatabaseCopy.

Selección de elementos para inicializar

Al realizar una operación de inicialización, puede elegir inicializar la copia de base de datos de buzones de correo, el catálogo del índice de contenido para la copia de base de datos de buzones o la copia de base de datos y la copia del catálogo del índice de contenido. El comportamiento predeterminado del Asistente para actualizar copias de bases de datos y el cmdlet Update-MailboxDatabaseCopy es inicializar la copia de base de datos de buzones de correo y la copia del catálogo del índice de contenido. Para inicializar solamente la copia de base de datos de buzones de correo sin inicializar el catálogo del índice de contenido, use el parámetro DatabaseOnly al ejecutar el cmdlet Update-MailboxDatabaseCopy. Para inicializar solamente la copia del catálogo del índice de contenido, use el parámetro CatalogOnly al ejecutar el cmdlet Update-MailboxDatabaseCopy.

Selección del origen de inicialización

En Exchange 2007, la replicación continua solamente puede inicializar una copia de base de datos al copiar la copia activa de la base de datos. En Exchange 2010, cualquier copia de base de datos en buen estado puede usarse como origen de inicialización para una copia adicional de esa base de datos. Esto es especialmente útil cuando tiene un DAG que se ha extendido en varias ubicaciones físicas. Por ejemplo, considere una implementación de DAG de cuatro miembros, en donde dos miembros (MBX1 y MBX2) están ubicados en Portland, Oregón, y dos miembros (MBX3 y MBX4) están en Nueva York, Nueva York. Una base de datos de buzones de correo denominada DB1 está activa en MBX1, y hay copias pasivas de DB1 en MBX2 y MBX3. Al agregar una copia de DB1 a MBX4, tiene la opción de usar la copia en MBX3 como origen de inicialización y, al hacerlo, evita inicializar en el vínculo de red de área extensa (WAN) entre Portland y Nueva York.

Para usar una copia específica como origen de inicialización al agregar una nueva copia de base de datos, haga lo siguiente:

Use el parámetro SeedingPostponed al ejecutar el cmdlet Add-MailboxDatabaseCopy para agregar la copia de base de datos. Si no se usa el parámetro SeedingPostponed, la copia de base de datos se inicializará explícitamente usando la copia activa de la base de datos como origen.
Use el parámetro SourceServer al ejecutar el cmdlet Update-MailboxDatabaseCopy y especifique el servidor de origen deseado para la inicialización. En el ejemplo anterior, se especificaría MBX3 como el servidor de origen. Si no se usa el parámetro SourceServer, la copia de base de datos se inicializará explícitamente usando la copia activa de la base de datos como origen.

Inicialización y redes

Además de seleccionar un servidor de origen específico para inicializar una copia de base de datos de buzones de correo, también puede especificar qué redes del DAG usar y, opcionalmente, puede anular la configuración de cifrado y compresión de la red del DAG durante la operación de inicialización.

Para especificar las redes que desea usar para la inicialización, use el parámetro Network al ejecutar el cmdlet Update-MailboxDatabaseCopy y especifique las redes del DAG que desea usar. Si no usa el parámetro Network, el sistema usa el siguiente comportamiento predeterminado para seleccionar una red que usará en la operación de inicialización:

Si el servidor de origen y el servidor de destino están en la misma subred, y se ha configurado una red de replicación que incluye una subred, se usa la red de replicación.
Si el servidor de origen y el servidor de destino están en distintas subredes, incluso si se ha configurado una red de replicación que contiene esas subredes, se usa la red de cliente (MAPI) para la inicialización.
Si el servidor de origen y el servidor de destino están en distintos centros de datos, se usa la red de cliente (MAPI) para inicialización.

En el DAG, las redes del DAG están configuradas para cifrado y compresión. La configuración predeterminada establece el uso de cifrado y compresión solamente para comunicaciones en diferentes subredes. Si el servidor de origen y el servidor de destino están en distintas subredes, y el DAG está configurado con los valores predeterminados para NetworkCompression y NetworkEncryption, puede anular estos valores con los parámetros NetworkCompressionOverride y NetworkEncryptionOverride, respectivamente, al ejecutar el cmdlet Update-MailboxDatabaseCopy.

Proceso de inicialización

Cuando inicia un proceso de inicialización con los cmdlets Add-MailboxDatabaseCopy o Update-MailboxDatabaseCopy, se realizan las siguientes tareas:

Las propiedades de base de datos de Active Directory se leen para validar las bases de datos y los servidores especificados, y para comprobar que los servidores de origen y de destino estén ejecutando Exchange 2010, que ambos sean miembros del mismo DAG y que la base de datos especificada no sea una base de datos de recuperación. Las rutas de acceso al archivo de base de datos también se leen.
Los preparativos para las comprobaciones de reinicialización ocurren desde el servicio de replicación de Microsoft Exchange en el servidor de destino.
El servicio de replicación de Microsoft Exchange en el servidor de destino comprueba la presencia de archivos de base de datos y de registro de transacciones en los directorios de archivos leídos por las comprobaciones de Active Directory en el paso 1.
El servicio de replicación de Microsoft Exchange devuelve la información de estado del servidor de destino a la interfaz administrativa desde donde se ejecutó el cmdlet.
Si todas las comprobaciones preliminares se han realizado, se le pide que confirme la operación antes de continuar. Si confirma la operación, el proceso continúa. Si se detecta un error durante las comprobaciones preliminares, el error se informa y la operación falla.
La operación de inicialización se inicia desde el servicio de replicación de Microsoft Exchange en el servidor de destino.
El servicio de replicación de Microsoft Exchange suspende la replicación de la base de datos para la copia activa de la base de datos.
El servicio de replicación de Microsoft Exchange actualiza la información de estado de la base de datos para reflejar el estado de la inicialización.
Si el servidor de destino aún no tiene los directorios para los archivos de registro y de la base de datos de destino, se crean.
Una solicitud para inicializar la base de datos se transmite del servicio de replicación de Microsoft Exchange en el servidor de destino al servicio de replicación de Microsoft Exchange en el servidor de origen mediante el TCP. Esta solicitud y las comunicaciones posteriores para inicializar la base de datos se producen en una red del DAG que ha sido configurada como una red de replicación.
El servicio de replicación de Microsoft Exchange en el servidor de origen inicia una copia de seguridad por secuencias del Motor de almacenamiento extensible (ESE) a través de la interfaz del servicio Almacén de información de Microsoft Exchange.
El servicio Almacén de información de Microsoft Exchange transmite los datos de la base de datos al servicio de replicación de Microsoft Exchange.
Los datos de la base de datos se mueven del servicio de replicación de Microsoft Exchange del servidor de origen al servicio de replicación de Microsoft Exchange del servidor de destino.
El servicio de replicación de Microsoft Exchange en el servidor de destino escribe la copia de la base de datos en un directorio temporal ubicado en el directorio de la base de datos principal denominado temp-seeding.
La operación de copia de seguridad por secuencias en el servidor de origen termina cuando se llega al final de la base de datos.
Se completa la operación de escritura en el servidor de destino y se mueve la base de datos del directorio temp-seeding a la ubicación final. Se elimina el directorio temp-seeding.
En el servidor de destino, el servicio de replicación de Microsoft Exchange envía mediante el proxy una solicitud al servicio de búsqueda de Microsoft Exchange para montar el catálogo del índice de contenido para la copia de la base datos, si existe. Si hay archivos de catálogo existentes no actualizados de una instancia previa de la copia de la base de datos, la operación de montaje falla y genera la necesidad de replicar el catálogo del servidor de origen. Del mismo modo, si el catálogo no existe, y tampoco existe en una nueva instancia de la copia de la base de datos en el servidor de destino, se requiere una copia del catálogo. El servicio de replicación de Microsoft Exchange indica al servicio de búsqueda de Microsoft Exchange que suspenda la indización de la copia de la base de datos mientras se copia un nuevo catálogo del servidor de origen.
El servicio de replicación de Microsoft Exchange en el servidor de destino envía una solicitud de catálogo de inicialización al servicio de replicación de Microsoft Exchange en el servidor de origen.
En el servidor de origen, el servicio de replicación de Microsoft Exchange solicita la información del directorio del servicio de búsqueda de Microsoft Exchange y solicita que se suspenda la indización.
El servicio de búsqueda de Microsoft Exchange en el servidor de origen devuelve la información del directorio del catálogo de búsqueda al servicio de replicación de Microsoft Exchange.
El servicio de replicación de Microsoft Exchange en el servidor de origen lee los archivos de catálogo del directorio.
El servicio de replicación de Microsoft Exchange en el servidor de origen mueve los datos del catálogo al servicio de replicación de Microsoft Exchange en el servidor de destino mediante una conexión en la red de replicación. Después de que finaliza la lectura, el servicio de replicación de Microsoft Exchange envía una solicitud al servicio de búsqueda de Microsoft Exchange para reanudar la indización de la base de datos del servidor de origen.
Si hay archivos de catálogo en el servidor de destino, en el directorio, el servicio de replicación de Microsoft Exchange en el servidor de destino los elimina.
El servicio de replicación de Microsoft Exchange en el servidor de destino escribe los datos del catálogo en un directorio temporal denominado CiSeed.Temp hasta que los datos se transfieran completamente.
El servicio de replicación de Microsoft Exchange mueve todos los datos del catálogo a la ubicación final.
El servicio de replicación de Microsoft Exchange en el servidor de destino reanuda la indización de búsqueda en la base de datos de destino.
El servicio de replicación de Microsoft Exchange en el servidor de destino devuelve un estado de finalización.
El resultado final de esta operación se transmite a la interfaz administrativa desde donde se llamó el cmdlet.

Configuración de las copias de bases de datos

Después de que se cree una copia de base de datos, podrá ver y modificar la configuración cuando sea necesario. Puede ver la información de la configuración si examina la página Propiedades de una copia de base de datos en la EMC. También puede usar los cmdlets Get-MailboxDatabase y Set-MailboxDatabaseCopy en el Shell para ver y establecer la configuración de copias de bases de datos, como el tiempo de retardo de reproducción, el tiempo de retardo de truncamiento y el orden de preferencia de activación. Para obtener instrucciones detalladas acerca de cómo ver y establecer la configuración de copias de bases de datos, consulte Configurar las propiedades de la copia de la base de datos de buzones.

Usar las opciones de tiempo de retardo de reproducción y tiempo de retardo de truncamiento

Las copias de bases de datos de buzones de correo admiten el uso de un tiempo de retardo de reproducción y un tiempo de retardo de truncamiento, ambos configurados en minutos. La configuración de un tiempo de retardo de reproducción le permite volver a llevar una copia de base de datos a un momento específico. La configuración de un tiempo de retardo de truncamiento le permite usar los registros en una copia de base de datos pasiva para recuperarse de la pérdida de archivos de registro en una copia de base de datos activa. Dado que estas dos características provocarán la acumulación temporaria de archivos de registro, usar cualquiera de ellas afectará su diseño de almacenamiento.

Tiempo de retardo de reproducción

El tiempo de retardo de reproducción es una propiedad de una copia de base de datos de buzones de correo que especifica la cantidad de tiempo, en minutos, de retardo de reproducción del registro de la copia de base de datos. El temporizador de retardo de reproducción se inicia cuando un archivo de registro ha sido replicado en la copia pasiva y ha pasado correctamente la inspección. Mediante el retardo de la reproducción de archivos de la copia de base de datos, usted tiene la posibilidad de recuperar la base de datos en un momento específico anterior. Una copia de base de datos de buzones de correo configurada con un valor de tiempo de retardo de reproducción mayor que 0 se denomina copia de base de datos de buzones de correo atrasada o simplemente copia atrasada.

Una estrategia que usa las funciones de espera de litigio y de copias de base de datos de Exchange 2010 puede proporcionar protección contra diversos errores que, normalmente, podrían generar la pérdida de datos. Sin embargo, estas funciones no pueden brindar protección contra la pérdida de datos en caso de daños de lógica, que si bien no son muy comunes, pueden generar la pérdida de datos. Las copias retrasadas están diseñadas para prevenir la pérdida de datos en caso de daños de lógica. Generalmente, hay dos tipos de daños de lógica:

Daños de lógica de una base de datos La suma de comprobación de las páginas de base de datos coincide, pero los datos de las páginas son lógicamente incorrectos. Esto se puede producir cuando ESE intenta escribir una página de la base de datos y, aunque el sistema operativo muestra un mensaje de operación correcta, los datos nunca se escribieron en el disco o se escribieron en el lugar incorrecto. Esto se conoce como vaciado perdido. Para impedir que los vaciados perdidos pierdan datos, ESE incluye un mecanismo de detección de vaciados perdidos en la base de datos junto con una función de revisión de páginas (restauración de página única).
Daños de lógica del almacén Se agregan, eliminan o manipulan datos de una manera en la que el usuario no espera. Normalmente, estos casos son causados por aplicaciones de otros fabricantes. Solo se considera un daño, por lo general, porque el usuario lo ve como un daño. El almacén de Exchange considera que la transacción que produce los daños de lógica es una serie de operaciones MAPI válidas. La función de espera de litigio de Exchange 2010 brinda protección contra los daños de lógica del almacén (porque impide que un usuario o una aplicación elimine de forma permanente el contenido). Sin embargo, se pueden producir situaciones en las que un buzón de correo de un usuario se dañe tanto que sea más simple restaurar la base de datos tal como estaba en un momento específico anterior al momento en que se produjeron los daños y, luego, exportar el buzón de usuario para recuperar los datos que no están dañados.

La combinación de copias de bases de datos, directiva de retención y restauración de página única ESE solo deja lugar para el caso, poco común pero catastrófico, de daños de lógica del almacén. Su decisión acerca de usar una copia de base de datos con un retraso de reproducción (una copia retrasada) dependerá de las aplicaciones de otros fabricantes que use y del historial de daños de lógica del almacén de su organización.

Si decide usar copias retrasadas, debe tener en cuenta las siguientes implicaciones de su uso:

A diferencia de la replicación continua en espera (SCR) de Exchange 2007, que tenía un retardo de reproducción codificado de forma rígida de 50 archivos de registro, no hay un número codificado de forma rígida de archivos de registro retrasados. En cambio, el tiempo de retardo de reproducción es un valor configurado por el administrador y, de manera predeterminada, está deshabilitado.
La configuración de tiempo de retardo de reproducción tiene una configuración predeterminada de 0 días y una configuración máxima de 14 días.
Las copias retrasadas no se consideran copias de alta disponibilidad. En cambio, están diseñadas para la recuperación ante desastres, con el fin de brindar protección contra los daños de lógica del almacén.
Cuanto mayor sea el tiempo de retardo de reproducción, más largo será el proceso de recuperación de base de datos. La cantidad de horas que llevará recuperar una base de datos dependerá de la cantidad de archivos de registro que es necesario reproducir durante la recuperación y la velocidad en la que el hardware puede reproducirlos.
Le recomendamos que determine si las copias retrasadas son cruciales para su estrategia general de recuperación ante desastres. Si su uso es crucial para la estrategia, le recomendamos usar varias copias retrasadas o una matriz redundante de discos independientes (RAID) para proteger una sola copia retrasada, si no tiene varias copias retrasadas. Si pierde un disco o si se producen daños, no pierde su copia retrasada tal como estaba en un momento específico anterior al momento en que se produjeron los daños.
Las copias retrasadas no se pueden revisar con la función de restauración de página única ESE. Si una copia retrasada detecta daños en las páginas de la base de datos (por ejemplo, un error -1018), tendrá que reinicializarse (que perderá el aspecto retrasado de la copia).

Activar y recuperar una copia de la base de datos de buzones de correo retrasada es un proceso sencillo si desea que la base de datos reproduzca todos los archivos de registro y actualice la copia de la base de datos. Si desea reproducir los archivos de registro hasta un momento dado, la operación es un poco más difícil porque debe manipular los archivos de registro de forma manual y ejecutar la herramienta Eseutil.

Para obtener instrucciones detalladas acerca de cómo activar una copia de base de datos de buzones de correo retrasada, consulte Activar una copia de la base de datos de buzones de correo atrasada.

Tiempo de retardo de truncamiento

El tiempo de retardo de truncamiento es una propiedad de una copia de base de datos de buzones de correo que especifica la cantidad de tiempo, en minutos, que se demora la eliminación del registro para la copia de base de datos después de que el archivo de registro se ha reproducido en la copia de base de datos. El temporizador de retardo de truncamiento se inicia cuando un archivo de registro se ha replicado en la copia pasiva, ha pasado correctamente la inspección y se ha reproducido correctamente en la copia de la base de datos. Mediante el retardo del truncamiento de los archivos de registro de la copia de base de datos, usted tiene la posibilidad de recuperarse de errores que afectan los archivos de registro para la copia activa de la base de datos.

Copias de base de datos y truncamiento de registros

El truncamiento de registros funciona en Exchange 2010 de la misma manera que lo hizo en Exchange 2007. El comportamiento de truncamiento está determinado por la configuración del tiempo de retardo de reproducción y del tiempo de retardo de truncamiento para la copia.

Para que un archivo de registro de una copia de base de datos se trunque cuando la configuración de retardo se deja en los valores predeterminados de 0 (deshabilitado), es necesario que se cumplan los siguientes criterios:

Es necesario que se haya realizado correctamente una copia de seguridad del archivo de registro o que esté habilitado el registro circular.
El archivo de registro debe estar por debajo del punto de control (el archivo de registro mínimo necesario para la recuperación) para la base de datos.
Todas las otras copias retrasadas deben haber inspeccionado el archivo de registro.
Todas las otras copias (copias no retrasadas) deben haber reproducido el archivo de registro.

Para que se produzca el truncamiento de una copia retrasada de base de datos es necesario que se cumplan los siguientes criterios:

El archivo de registro debe estar por debajo del punto de control para la base de datos.
El archivo de registro debe ser anterior a ReplayLagTime + TruncationLagTime.
El archivo de registro se debe haber truncado en la copia activa.

Directiva de activación de base de datos

Existen situaciones en las que es probable que desee crear una copia de base de datos de buzones de correo e impedir que el sistema active automáticamente esa copia en caso de error. Por ejemplo:

Si implementa una o más copias de base de datos de buzones de correo en un centro de datos en espera o secundario.
Si configura una copia de base de datos como copia retrasada con fines de recuperación.
Si realiza el mantenimiento o la actualización de un servidor.

En cada una de las situaciones anteriores, usted tiene copias de base de datos que no desea que el sistema active automáticamente. Para impedir que el sistema active automáticamente una copia de base de datos de buzones de correo, puede configurar la copia para que quede bloqueada (suspendida) para activarse. Esto permite al sistema mantener la vigencia de la base de datos mediante el envío y la reproducción de registros, pero impide que el sistema se active automáticamente y use la copia. Un administrador debe activar manualmente las copias bloqueadas para la activación. Puede configurar la directiva de activación de base de datos con el cmdlet Set-MailboxServer para establecer el parámetro DatabaseCopyAutoActivationPolicy en bloqueado.

Para obtener más información acerca de cómo configurar la directiva de activación de base de datos, consulte Configurar la directiva de activación para una copia de base de datos de buzones.

Equilibrio de las copias de bases de datos

Debido a la naturaleza inherente de los DAG, como resultado de los cambios de base de datos y las conmutaciones por error, las copias de bases de datos de buzones cambian de host varias veces durante la vida de un DAG. Como resultado, los DAG pueden quedar desequilibrados en cuanto a la distribución de las copias de bases de datos de buzones activas. En la tabla siguiente se muestra el ejemplo de un DAG que tiene cuatro bases de datos con cuatro copias para cada base de datos (formando un total de 16 bases de datos en cada servidor) que presenta una distribución desigual de copias de bases de datos activas.

DAG con distribución desequilibrada de copias activas

Servidor	Cantidad de bases de datos activas	Cantidad de bases de datos pasivas	Cantidad de bases de datos montadas	Lista de conteo de preferencia
EX1	5	11	5	4, 4, 3, 5
EX2	1	15	1	1, 8, 6, 1
EX3	12	4	12	13, 2, 1, 0
EX4	1	15	1	1, 1, 5, 9

En el ejemplo anterior, hay cuatro copias de cada base de datos y, por lo tanto, sólo cuatro valores posibles de preferencia de activación (1, 2, 3 ó 4). La columna Lista de conteo de preferencia muestra el conteo de la cantidad de bases de datos con cada uno de esos valores. Por ejemplo, en EX3 hay 13 copias de bases de datos con una preferencia de activación de 1, dos copias con una preferencia de activación de 2, una copia con una preferencia de activación de 3 y ninguna copia con una preferencia de activación de 4.

Como puede ver, este DAG no está equilibrado en cuanto a la cantidad de bases de datos activas alojadas por cada miembro del DAG, a la cantidad de bases de datos pasivas alojadas por cada miembro del DAG ni al conteo de preferencia de activación de las bases de datos alojadas.

Puede usar el script RedistributeActiveDatabases.ps1 para equilibrar las copias activas de bases de datos de buzones de un DAG. Este script traslada las bases de datos entre sus copias, intentando obtener una cantidad igual de bases de datos montadas en cada servidor del DAG. Si es necesario, el script también intenta equilibrar las bases de datos activas entre sitios.

El script proporciona dos opciones para equilibrar copias de bases de datos activas dentro de un DAG:

BalanceDbsByActivationPreference Cuando se indica esta opción, el script intenta trasladar las bases de datos a su copia preferida (según la preferencia de activación) sin tener en cuenta el sitio de Active Directory.
BalanceDbsBySiteAndActivationPreference Cuando se indica esta opción, el script intenta trasladar las bases de datos activas a su copia preferida y al mismo tiempo intenta equilibrar las bases de datos activas dentro de cada sitio de Active Directory.

Después de ejecutar el script con la primera opción, el DAG que estaba desequilibrado se equilibra, tal como se muestra en la tabla siguiente.

DAG con distribución equilibrada de copias activas

Servidor	Cantidad de bases de datos activas	Cantidad de bases de datos pasivas	Cantidad de bases de datos montadas	Lista de conteo de preferencia
EX1	4	12	4	4, 4, 4, 4
EX2	4	12	4	4, 4, 4, 4
EX3	4	12	4	4, 4, 4, 4
EX4	4	12	4	4, 4, 4, 4

Como se muestra en la tabla anterior, este DAG está equilibrado en cuanto a la cantidad de bases de datos activas y pasivas que hay en cada servidor y en la preferencia de activación de todos los servidores.

La siguiente tabla enumera los parámetros disponibles para el script RedistributeActiveDatabases.ps1.

Parámetros del script RedistributeActiveDatabases.ps1

Parámetro	Descripción
DagName	Especifica el nombre del DAG que desea volver a equilibrar. Si se omite este parámetro, se usa el DAG del que es miembro el servidor local.
BalanceDbsByActivationPreference	Especifica que el script debe trasladar las bases de datos a su copia preferida sin tener en cuenta el sitio de Active Directory.
BalanceDbsBySiteAndActivationPreference	Especifica que el script debe intentar trasladar las bases de datos activas a su copia preferida y al mismo tiempo intentar equilibrar las bases de datos activas dentro de cada sitio de Active Directory.
ShowFinalDatabaseDistribution	Indica que se muestre un informe la distribución actual de bases de datos, una vez que la redistribución se haya completado.
AllowedDeviationFromMeanPercentage	Especifica la variación entre sitios permitida para las bases de datos activas, expresada en un porcentaje. El valor predeterminado es 20%. Por ejemplo, si hubiera 99 bases de datos distribuidas en tres sitios, la distribución ideal sería de 33 bases de datos en cada uno. Si la variación permitida es del 20%, el script intentará equilibrar las bases de datos de manera que cada sitio tenga hasta un 10% más o menos que dicho número. El 10% de 33 es 3,3 lo cual se redondea en 4. Por lo tanto, el script intentará colocar entre 29 y 37 bases de datos en cada sitio.
ShowDatabaseCurrentActives	Indica al script que produzca un informe de cada base de datos, detallando de qué manera se trasladó dicha base de datos y si ahora se encuentra activa en su copia preferida.
ShowDatabaseDistributionByServer	Indica al script que produzca un informe de cada servidor, mostrando su distribución de bases de datos.
RunOnlyOnPAM	Indica al script que sólo se ejecute en el miembro del DAG que posee el rol de PAM. El script verifica que se esté ejecutando desde el PAM. Si no se está ejecutando desde el PAM, el script sale.
LogEvents	Indica al script registrar un evento (MsExchangeRepl evento 4115) que contenga un resumen de las acciones.
IncludeNonReplicatedDatabases	Indica al script que incluya las bases de datos no replicadas (bases de datos sin copias) al determinar la manera de redistribuir las bases de datos activas. Si bien las bases de datos no replicadas no pueden trasladarse, pueden afectar la distribución de las bases de datos replicadas.

Ejemplo con RedistributeActiveDatabases.ps1

En este ejemplo se muestra la distribución actual de las bases de datos de un DAG, incluida la lista de conteo de preferencia.

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

En este ejemplo se redistribuyen y equilibran las copias de las bases de datos de buzones activas de un DAG, mediante la preferencia de activación.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference

En este ejemplo se redistribuyen y equilibran las copias de las bases de datos de buzones activas de un DAG, mediante la preferencia de activación, y se genera un resumen de la distribución.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Supervisión de copias de base de datos

Una copia de base de datos es su primer defensa si se produce un error que afecta la copia activa de una base de datos. Por lo tanto, es crítico supervisar el estado de las copias de las bases de datos para garantizar que estarán disponibles cuando sea necesario. Puede ver la información de estado si examina la página Propiedades de una copia de base de datos en la EMC. También puede usar el cmdlet Get-MailboxDatabaseCopyStatus en el Shell para ver cierta información de estado de una copia de base de datos.

Para obtener más información acerca de cómo supervisar copias de base de datos, consulte Supervisión de la alta disponibilidad y la resistencia de sitios.

Eliminación de una copia de base de datos

Puede eliminar en cualquier momento una copia de base de datos con la EMC o con el cmdlet Remove-MailboxDatabaseCopy en el Shell. Después de quitar una copia de base de datos, debe eliminar del servidor del cual se está quitando la copia cualquier archivo de base de datos y archivo de registro de forma manual. Para obtener instrucciones detalladas acerca de cómo eliminar una copia de base de datos, consulte Quitar una copia de base de datos de buzones.

Cambios de base de datos

El servidor de buzones de correo que hospeda la copia activa de una base de datos se conoce como el patrón de base de datos de buzones de correo. El proceso de activación de una copia de base de datos pasiva cambia el patrón de base de datos de buzones de correo de la base de datos y convierte a la copia pasiva en la nueva copia activa. Este proceso se denomina cambio de base de datos. En un cambio de base de datos, la copia activa de una base de datos se desmonta en un servidor de buzones de correo, y una copia pasiva de esa base de datos se monta como la nueva base de datos de buzones de correo activa en otro servidor de buzones. Cuando se realiza un cambio, tiene la opción de anular la configuración del marcado de montaje de base de datos en el nuevo patrón de base de datos de buzones de correo.

Si revisa la columna Estado de la copia en la ficha Copias de bases de datos en la EMC, puede identificar rápidamente qué servidor de buzones es el patrón de base de datos de buzones de correo actual. Solo la copia activa tendrá el estado Montado. Todas las otras copias de base de datos mostrarán el estado actual de replicación de la copia de base de datos. Para realizar un cambio, use el Asistente para mover el patrón de base de datos de buzones de correo en la EMC o use el cmdlet Move-ActiveMailboxDatabase en el Shell.

Existen varias comprobaciones internas que se realizarán antes de activar una copia pasiva:

Se comprueba el estado de la copia de base de datos. Si la copia de base de datos está en estado de error, se bloquea el cambio. Puede anular este comportamiento y omitir la comprobación de estado usando el parámetro SkipHealthChecks del cmdlet Move-ActiveMailboxDatabase. Este parámetro le permite mover la copia activa a una copia de base de datos en estado de error.
Las longitudes de la cola de copia y de la cola de reproducción de la copia de base de datos se comprueban para garantizar que sus valores estén dentro de los criterios configurados. Además, la copia de base de datos se comprueba para garantizar que no esté en uso en ese momento como origen de inicialización. Si los valores para las longitudes de cola están fuera de los criterios configurados, o si la base de datos está en uso como origen de inicialización, se bloquea el cambio. Puede anular este comportamiento y omitir estas comprobaciones usando el parámetro SkipLagChecks del cmdlet Move-ActiveMailboxDatabase. Este parámetro permite que se active una copia que tiene las colas de reproducción y copia fuera de los criterios configurados.
Se comprueba el estado del catálogo de búsqueda (índice de contenido) de la copia de base de datos. Si el catálogo de búsqueda no está actualizado, se encuentra en un estado incorrecto o está dañado, se bloquea el cambio. Puede anular este comportamiento y omitir la comprobación del catálogo de búsqueda usando el parámetro SkipClientExperienceChecks del cmdlet Move-ActiveMailboxDatabase. Este parámetro hace que esta búsqueda omita la comprobación del estado del catálogo. Si el catálogo de búsqueda de la copia de base de datos que está activando se encuentra en un estado incorrecto o inutilizable, y usted usa este parámetro para omitir la comprobación del estado del catálogo y activar la copia de base de datos, tendrá que rastrear o inicializar el catálogo de búsqueda nuevamente.

Al realizar un cambio de base de datos, también tiene la opción de anular la configuración del marcado de montaje para el servidor que hospeda la copia pasiva de la base de datos que se está activando. Al usar el parámetro MountDialOverride del cmdlet Move-ActiveMailboxDatabase, se le indica al servidor de destino que anule su propia configuración del marcado de montaje y use la que especifica el parámetro MountDialOverride.

Para obtener instrucciones detalladas acerca de cómo realizar un cambio de una copia de base de datos, consulte Activar una copia de la base de datos de buzones. Para obtener más información acerca de los cambios de bases de datos, consulte Cambios y conmutaciones por error.