Descripción del almacén de Exchange 2010

  • Artículo

 

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

Última modificación del tema: 2016-11-28

El almacén de Exchange es una plataforma de almacenamiento que proporciona un repositorio único para administrar diversos tipos de información en una infraestructura. El almacén de Exchange (store.exe) es el repositorio de almacenamiento de datos principal de MicrosoftExchange Server 2010.

Contenido

Bases de datos en ediciones de Exchange 2010

Componentes lógicos del almacén de Exchange

Estructura de archivos del almacén de Exchange

Descripción del registro de transacciones

Motor de almacenamiento extensible

Mantenimiento del almacén

Poco espacio en disco en registros o unidades de base de datos

Límites del almacén de Exchange

Bases de datos en ediciones de Exchange 2010

Exchange 2010 está disponible en dos ediciones de servidor: Standard Edition y Enterprise Edition. Exchange 2010 Standard Edition está diseñado para satisfacer las necesidades de mensajería y colaboración de las organizaciones pequeñas y medianas; también puede ser adecuado para roles de servidor o sucursales específicas. Exchange 2010 Enterprise Edition está diseñado para grandes empresas.

Exchange 2010 Standard Edition admite hasta cinco bases de datos. Exchange 2010 Enterprise Edition admite hasta 100 bases de datos.

Componentes lógicos del almacén de Exchange

Los componentes principales del almacén de Exchange son bases de datos de buzones y bases de datos de carpetas públicas. Estos componentes pueden residir en un único servidor o pueden estar distribuidos entre varios servidores.

Las bases de datos de buzones contienen datos, definiciones de datos, índices, sumas de comprobación, marcas y otro tipo de información que contienen los buzones de Exchange 2010. Las bases de datos de buzones contienen datos privados para un usuario determinado y carpetas de buzones que se generan al crean un buzón para ese usuario. Una base de datos de buzones se almacena como archivo de base de datos de Exchange (.edb).

Las bases de datos de carpetas públicas contienen datos, definiciones de datos, índices, sumas de comprobación, marcas y otro tipo de información que contiene cualquier carpeta pública de su organización de Exchange.

En Exchange 2010, las carpetas públicas se administran mediante el Shell de administración de Exchange. (Además, puede realizar un número limitado de tareas de administración de la base de datos de carpetas públicas en la Consola de administración de Exchange.)  Para obtener más información acerca de la administración de carpetas públicas, consulte Administración de carpetas públicas y Descripción de las carpetas públicas.

Bases de datos en ediciones de Exchange 2010

Estructura de archivos del almacén de Exchange

La administración del almacén de Exchange se realiza trabajando con sus componentes lógicos, tales como bases de datos. Sin embargo, Exchange 2010 almacena datos en un conjunto especializado de archivos de datos, tales como archivos de bases de datos (.edb), archivos de registro de transacciones (.log) y archivos de punto de control (.chk) de Exchange. A no ser que se realice una copia de seguridad o se restauren los datos, rara vez se interactúa directamente con estos archivos. En la tabla siguiente se describe en detalle cada uno de estos archivos.

Estructura de archivos del almacén de Exchange

Archivo de datos Descripción

Base de datos de Exchange (.edb)

Estos archivos son el repositorio de los datos de buzones. Puede obtenerse acceso a ellos directamente mediante el Motor de almacenamiento extensible (ESE) y tienen una estructura de árbol B diseñada para un acceso rápido. De este modo, los usuarios pueden obtener acceso a cualquier página de datos de un ciclo de entrada/salida (I/O), lo cual significa un incremento cuatro veces mayor en comparación con Microsoft Exchange Server 2007. Las bases de datos de Exchange constan de varios árboles B, con árboles auxiliares que trabajan junto con el árbol principal manteniendo los índices y las vistas.

Registro de transacciones (.log)

Estos archivos son el repositorio para las operaciones de base de datos, como la creación o modificación de un mensaje. Las operaciones confirmadas se escriben posteriormente en la propia base de datos (en un archivo .edb). Este procedimiento garantiza el registro de todas las transacciones finalizadas e incompletas para conservar la integridad de los datos en caso de que se interrumpa el servicio. Cada base de datos tiene su propio conjunto de registros de transacciones.

Archivos de punto de control (.chk)

Estos archivos son el repositorio de los datos que indican cuándo una operación se ha guardado correctamente en la base de datos del disco duro. Exchange 2010 usa archivos .chk de modo que una copia del ESE puede reproducir automáticamente archivos de registro en una base de datos incoherente durante la recuperación de una interrupción del servicio, empezando por la siguiente operación sin escribir. Los archivos .chk se colocan en la misma ubicación de registro que los archivos .log.

Bases de datos en ediciones de Exchange 2010

Descripción del registro de transacciones

El registro de transacciones de Exchange es un mecanismo sólido de recuperación de ESE diseñado para restaurar una base de datos de Exchange de forma fiable a un estado coherente después de cualquier parada repentina de la base de datos. El mecanismo de registro también se usa al restaurar copias de seguridad en línea. En esta sección se describen los detalles del registro de transacciones de Exchange 2010 e incluye una breve descripción del registro circular.

Registro de transacciones de Exchange

Antes de que se puedan realizar cambios en un archivo de base de datos de Exchange, Exchange escribe los cambios en un archivo de registro de transacciones. Una vez que un cambio se ha registrado sin problemas, ya se puede escribir en el archivo de la base de datos. Es habitual que estos cambios estén disponibles para los usuarios finales justo después de que se hayan protegido en el registro de transacciones y antes de que se hayan escrito en el archivo de la base de datos.

Exchange usa un sofisticado sistema de administración de memoria interna ajustada para un alto rendimiento y puede administrar con eficacia la memoria caché de docenas de gigabytes (GB) de páginas de bases de datos. Por ello, la escritura física de los cambios en el archivo de la base de datos es una tarea de baja prioridad durante el funcionamiento normal.

Si una base de datos se detiene repentinamente, los cambios de la memoria caché no solo se pierden a causa de la destrucción de la memoria caché. Cuando la base de datos se reinicia, Exchange examina los archivos de registro y reconstruye y aplica todos los cambios que aún no se han escrito en el archivo de la base de datos. Este proceso se llama reproducir archivos de registro. La base de datos se estructura para que Exchange pueda determinar si ya se ha aplicado alguna operación de algún archivo de registro a la base de datos, se debe aplicar a la base de datos o no pertenece a la base de datos.

En lugar de escribir toda la información de registro en un solo archivo grande, Exchange usa una serie de archivos de registro, todos con un tamaño exacto de un megabyte (MB) o 1.024 kilobytes (KB). Cuando un archivo de registro está lleno, Exchange lo cierra y le cambia el nombre por un número secuencial. El primer registro que se completa termina con el nombre Enn00000001.log. nn se refiere a un número de dos dígitos conocido como el nombre base o el prefijo de registro.

Los archivos de registro para cada base de datos se distinguen mediante nombres de archivo con prefijos numerados (por ejemplo, E00, E01, E02 o E03). El archivo de registro abierto actualmente para una base de datos se denomina Enn.log. No presentará ningún número secuencial hasta que no se haya completado y cerrado.

El archivo de punto de control (Enn.chk) realiza un seguimiento del progreso de Exchange al escribir la información de registro en los archivos de base de datos. Hay un archivo de punto de control para cada secuencia de registros y una secuencia de registros independiente para cada base de datos.

Los archivos de registro se numeran de forma hexadecimal, de manera que el archivo de registro que sigue a E0000000009.log es E000000000A.log, y no E0000000010.log. Puede convertir los números de una secuencia de archivos de registro a sus valores decimales con la aplicación Calculadora de Windows (Calc.exe) en modo Científica. Para hacerlo, ejecute Calc.exe y, a continuación, en el menú Ver, haga clic en Científica.

Para ver el número de secuencia decimal de un archivo de registro concreto, puede examinar su encabezado con la herramienta Utilidades de la base de datos (Eseutil.exe) de Exchange Server. La primera página de 4 KB de cada archivo de registro contiene información de encabezado que describe e identifica el archivo de registro y la base de datos a la que pertenece. El comando Eseutil /ml [log file name] muestra la información de encabezado.

Si usa el conmutador incorrecto para mostrar el encabezado (por ejemplo, si usa /ml con un encabezado de base de datos en vez de /mh), se mostrará un error o la información del encabezado que se muestre puede que sea confusa o incorrecta.

No se puede ver el encabezado de una base de datos mientras se está montando. También puede ver el encabezado del archivo de registro actual (Enn.log) al montar cualquier base de datos. Exchange mantiene abierto el archivo de registro actual siempre que alguna base de datos lo esté usando. No obstante, puede ver el encabezado del archivo de punto de control mientras se montan bases de datos. Exchange actualiza el archivo de punto de control cada treinta segundos y su encabezado está siempre visible, excepto cuando se está realizando alguna actualización.

Como administrador de Exchange resulta muy útil entender los encabezados de los archivos de Exchange. Si entiende los encabezados de los archivos, puede determinar qué base de datos y archivos de registro se complementan, así como qué archivos son necesarios para una recuperación correcta.

Observe las primeras cuatro líneas del ejemplo de encabezado de archivo de registro siguiente.

Base name: e00
Log file: e00.log
lGeneration: 11 (0xB)
Checkpoint: (0xB,7DC,6F)

Estas líneas de encabezado de archivo de registro muestran que este archivo es el archivo de registro actual porque el nombre del archivo de registro no tiene un número de secuencia. La línea lGeneration muestra que cuando el registro esté lleno y se cierre, su número de secuencia será B, que corresponde al valor decimal 11. El nombre base es e00 y, por lo tanto, el nombre final del archivo de registro será E000000000B.log.

El valor Checkpoint en el ejemplo de encabezado anterior no se lee desde el encabezado del archivo de registro, sino que se visualiza como si lo fuera. Eseutil.exe lee el valor de Checkpoint directamente desde Enn.chk, de manera que no tenga que escribir otro comando para saber dónde se encuentra el archivo de punto de control. Si el archivo de punto de control se ha destruido, el valor de Checkpoint indica NOT AVAILABLE. En este caso, el punto de control es el archivo de registro actual (0xB) y los números 7DC y 6F indican hasta dónde llega el control en el archivo de registro. En la práctica raras veces necesitará esta información.

Si el archivo de punto de control se destruye, Exchange aún puede recuperar los archivos de registro de reproducción de manera adecuada. No obstante, para ello, Exchange empieza a explorar los archivos de registro, comenzando por el archivo disponible más antiguo, en vez de empezar por el registro de punto de control. Exchange omite los datos que ya se han aplicado a la base de datos y explora los registros de forma secuencial hasta que se encuentran los datos que se deben aplicar.

Normalmente, Exchange solo tarda uno o dos segundos en explorar el archivo de registro que ya se ha aplicado a la base de datos. Si hay operaciones en un archivo de registro que se deben escribir en la base de datos, puede que tarde de 10 segundos a varios minutos en aplicarlas. De media, el contenido de un archivo de registro se puede escribir en una base de datos en 30 segundos o menos.

Cuando una base de datos de Exchange se cierra con normalidad, todos los datos destacados se escriben en los archivos de la base de datos. Después de un apagado con normalidad, el conjunto de archivos de la base de datos se considera coherente y Exchange lo desconecta de su secuencia de registro. Esto significa que ahora los archivos de base de datos son aplicaciones independientes y totalmente actualizadas. Los registros de transacciones no son necesarios para iniciar los archivos de base de datos.

Puede saber si una base de datos se ha cerrado correctamente ejecutando el comando Eseutil /mh y examinando los encabezados del archivo.

Con todas las bases de datos desconectadas y en estado de "cierre correcto", todos los archivos de registro se pueden eliminar sin problemas sin afectar a la base de datos. Si, a continuación, deseara eliminar todos los archivos de registro, Exchange generaría una nueva secuencia de registros empezando por Enn00000001.log. Incluso podría mover los archivos de la base de datos a otro servidor que tenga archivos de registro y la base de datos los adjuntaría en otra secuencia de registro.

Nota

Aunque puede eliminar los archivos de registro después de haber cerrado todas las bases de datos, si lo hiciera podría afectar a su capacidad para restaurar copias de seguridad más antiguas y realizar una puesta al día. La base de datos actual ya no necesita archivos de registro existentes, pero puede que sean necesarios si debe restaurar una base de datos más antigua.

Si una base de datos se encuentra en estado de "cierre con errores", todos los registros de transacciones del reenvío de punto de control deben estar presentes antes de que pueda volver a montar la base de datos. Si estos registros no están disponibles, debe reparar la base de datos ejecutando el comando Eseutil /p para que la base de datos sea coherente y esté a punto para iniciarse.

Advertencia

Si tiene que reparar una base de datos, se perderán algunos datos. La pérdida de datos normalmente es mínima; sin embargo, podría ser catastrófica. Después de ejecutar Eseutil /p en una base de datos, debe ejecutar Eseutil/ d para desfragmentar la base de datos. Esta operación descarta y reconstruye todos los índices y árboles de espacio de bases de datos.

Además de permitir que Exchange se recupere de forma fiable de una interrupción inesperada de la base de datos, el registro de transacciones también es esencial para crear y restaurar copias de seguridad en línea. Para obtener más información acerca de la creación y restauración de copias de seguridad en línea, consulte Descripción de la copia de seguridad, restauración y recuperación ante desastres.

Bases de datos en ediciones de Exchange 2010

Registro circular

Puede configurar Exchange para ahorrar espacio en disco mediante la habilitación del registro circular. El registro circular permite a Exchange sobrescribir archivos de registro de transacciones después de que los datos de estos archivos de registro se hayan guardado en la base de datos. No obstante, si el registro circular está habilitado, solo podrá recuperar los datos hasta la última copia de seguridad completa. Por ejemplo, puede habilitar el registro circular al usar la protección de datos nativa de Exchange, método en el que no se realizan copias de seguridad. Para impedir la creación de registros, debe habilitar el registro circular.

En el registro de transacciones estándar que usa Exchange 2010, cada transacción de base de datos se escribe en un archivo de registro y, después, en las bases de datos. Cuando el archivo de registro alcanza un tamaño de un megabyte (MB), se le cambia el nombre y se crea otro archivo de registro. Con el tiempo, se genera un conjunto de archivos de registro. Si Exchange se detiene de forma inesperada, puede recuperar las transacciones sustituyendo los datos de estos archivos de registro en la base de datos. El registro circular sobrescribe y vuelve a usar el primer archivo de registro una vez que los datos que contiene se hayan escrito en la base de datos.

En Exchange 2010, el registro circular está deshabilitado de forma predeterminada. Si lo habilita, reducirá los requisitos de espacio de almacenamiento de la unidad. Sin embargo, sin un conjunto completo de archivos de registro de transacciones, no puede recuperar ningún dato más reciente que la última copia de seguridad completa. En un entorno de producción normal, no se recomienda el registro circular.

Para obtener más información acerca de cómo habilitar y deshabilitar el registro circular, consulte Configurar las propiedades de la base de datos de buzones.

Bases de datos en ediciones de Exchange 2010

Motor de almacenamiento extensible

Las bases de datos de buzones de Exchange y la cola de los servidores Transporte de concentradores y de los servidores Transporte perimetral usan la base de datos de motor de almacenamiento extensible (ESE). ESE es un administrador de tablas multiusuario del método de acceso secuencial indizado (ISAM) con todas las capacidades del lenguaje de manipulación de datos (DML) y del lenguaje de definición de datos (DDL). ESE permite a las aplicaciones almacenar registros y crear índices para obtener acceso a los registros de diferentes maneras. Para obtener más información acerca de ESE, consulte Arquitectura del motor de almacenamiento extensible (en inglés). Para conocer las mejoras introducidas en el ESE de Exchange 2010, consulte Nueva funcionalidad del almacén de núcleo de Exchange.

Bases de datos en ediciones de Exchange 2010

Mantenimiento del almacén

El almacén de Exchange puede detectar y corregir varios escenarios que pueden hacer que el almacén funcione de forma incorrecta. El almacén de Exchange puede administrar buzones de correo dudosos y tiempos de ejecución de subprocesos, use las características de informes y alertas para indicar que el estado del almacén de Exchange es incorrecto, así como para detectar y reparar problemas de bases de datos de buzones y bases de datos de carpetas públicas.

Detección y corrección de buzones dudosos

Un único buzón de correo con datos dañados (ya sean lógicos o físicos) puede hacer, en algunos casos, que se produzca un error en el almacén de Exchange, y negar el servicio a todos los buzones de correo hospedados por el servidor. Asimismo, un buzón de correo dudoso también podría producir errores recurrentes en el almacén de Exchange. En esta sección se describen las acciones que lleva a cabo el almacén de Exchange para detectar e interrumpir la actividad de buzones de correo dudosos.

Aislamiento del buzón de correo dudoso

Existen varios tipos de eventos por los que el almacén de Exchange etiqueta un buzón como posible amenaza:

  • Si no se completa correctamente un proceso que esté realizando alguna tarea para el buzón de correo

  • Si hay más de cinco subprocesos en el buzón de correo que no han mostrado ningún progreso durante un largo período de tiempo

Los buzones que suponen una posible amenaza se etiquetan, junto con un recuento de las veces que se ha etiquetado. Esta información se almacena en el Registro. El almacén de Exchange también conserva la información de marca de tiempo sobre cuándo se identificó el buzón de correo como posible amenaza.

Durante el montaje de una base de datos, el almacén de Exchange lee la fecha en que los buzones se identificaron como posibles amenazas. Si han transcurrido más de dos horas, se eliminará la clave del Registro del buzón. La ventaja de conservar esta información en el Registro es que en un entorno de alta disponibilidad, se replica mediante la base de datos Incluso durante la conmutación por error de un almacén de Exchange, el resto de equipos disponen de esta información. La subclave del registro que se utiliza para aislar el buzón de correo dudoso es HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}\QuarantinedMailboxes\{mailbox guid}. Las claves de esta ruta son CrashCount y LastCrashTime.

Los valores que determinan cuántos errores deben producirse para poner en cuarentena un buzón de correo y la cantidad de tiempo que un buzón de correo debe permanecer en cuarentena se almacenan en las claves MailboxQuarantineCrashThreshold y MailboxQuarantineDurationInSeconds de la subclave HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}.

Los valores predeterminados para estas claves son tres errores para MailboxQuarantineCrashThreshold y 21.600 segundos (seis horas) para MailboxQuarantineDurationInSeconds.

Actuación en el buzón de correo dudoso

De forma predeterminada, si se identifica que un buzón de correo ha causado un error o interbloqueo tres veces seguidas en un plazo de dos horas, el almacén de Exchange lo etiquetará como puesto en cuarentena en el Registro. No es posible obtener acceso al buzón de correo a menos que se transfiera la marca OPEN_AS_ADMIN. Ninguno de los procesos de Exchange (por ejemplo, la indización de contenido o los asistentes de buzones de correo) pueden iniciar sesión. Las claves del Registro QuarantineState y QuarantineTime hacen un seguimiento sobre si el buzón de correo está en cuarentena. Si el buzón de correo no ha causado ningún error en las últimas dos horas y no está en cuarentena, el almacén de Exchange limpia la ruta de acceso del Registro del buzón de correo. Si se ha puesto en cuarentena un buzón de correo por un período de tiempo mayor al valor de MailboxQuarantineDurationInSeconds puesto que tiene el valor LastCrashTime, se liberará del estado de cuarentena de forma automática.

Restablecer el buzón de correo en cuarentena

Una vez identificada y corregida la causa del buzón de correo dudoso, deberá restablecer manualmente la clave del Registro del buzón de correo dudoso eliminándola. No obstante, si olvida realizar este paso manual, el almacén de Exchange restablecerá automáticamente los buzones en cuarentena seis horas después de que se haya definido la marca de puesto en cuarentena. Si no se depura y corrige el problema en un determinado período de tiempo, pueden producirse otra serie de errores antes de que el buzón de correo o el mensaje vuelva a ponerse en cuarentena.

Nota

Es necesario volver a montar la base de datos que hospeda el buzón de correo, o bien reiniciar el almacén de Exchange, para que surta efecto el restablecimiento del buzón de correo en cuarentena.

El período de tiempo para restablecer buzones de correo en cuarentena puede controlarse mediante la clave del Registro HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds.

Generación de informes y alertas

Puede usar el cmdlet Get-MailboxStatistics para notificar que un buzón de correo está en cuarentena. El almacén de Exchange tiene un contador del monitor de rendimiento para el número de buzones de correo puestos en cuarentena. El nombre del contador es MSExchangeIS Mailbox\Quarantined Mailbox Count.

Asimismo, el almacén de Exchange escribe un evento cada vez que pone un buzón de correo en cuarentena, junto con detalles sobre el buzón de correo en cuestión y la hora actual. El evento 10018 identifica un buzón de correo puesto en cuarentena.

Bases de datos en ediciones de Exchange 2010

Reparación de bases de datos

En Exchange 2010 Service Pack 1 (SP1), puede usar el cmdlet New-MailboxRepairRequest para detectar y reparar daños en el buzón de correo. Puede ejecutar este cmdlet para un buzón determinado o para una base de datos de buzón de correo. Mientras esta tarea está en ejecución, el acceso a los buzones de correo se interrumpe para el buzón de correo en reparación. Si ejecuta este comando para una base de datos de buzones de correo, solamente se interrumpe el acceso al buzón de correo que se está reparando. Todos los demás buzones de correo de la base de datos permanecen operativos. Para obtener más información, consulte Crear una solicitud de reparación de buzones.

El cmdlet New-MailboxRepairRequest detecta y repara los tipos de daños en el buzón de correo indicados a continuación:

  • Buscar daños en la carpeta (con el valor SearchFolder del parámetro CorruptionType)

  • Recuentos agregados en carpetas que no reflejan los valores correctos (con el valor AggregateCounts del parámetro CorruptionType)

  • Vistas en carpetas que no reflejan el contenido correcto (con el valor FolderView del parámetro CorruptionType)

  • Carpetas aprovisionadas que apuntan de forma incorrecta a carpetas principales no aprovisionadas (con el valor ProvisionedFolder del parámetro CorruptionType)

Después de ejecutar el cmdlet New-MailboxRepairRequest, puede usar el Visor de eventos para ver los detalles de la solicitud. Para obtener más información, consulte Ver entradas de solicitudes de reparación de buzones en el Visor de eventos.

También puede usar el cmdlet New-PublicFolderDatabaseRepairRequest para detectar y corregir problemas de replicación en la base de datos de carpetas públicas. Aún es posible tener acceso a las carpetas públicas de la base de datos de carpetas públicas mientras la solicitud se está ejecutando. Sin embargo, el acceso no está disponible para la carpeta pública actualmente en reparación. Para obtener más información, consulte Crear una solicitud de reparación de base de datos de carpetas públicas.

Bases de datos en ediciones de Exchange 2010

Detección y generación de informes del tiempo de espera

Otro indicio de que un almacén de Exchange está en un estado incorrecto es la presencia de subprocesos bloqueados o que no progresan. Si hay más de cinco subprocesos en un buzón, diez en una base de datos o veinte en un servidor que llevan un minuto sin progresar, se informa del tiempo de espera en el servidor. El contador de rendimiento que indica los tiempos de espera detectados es MSExchangeIS\ RPC Request Timeout Detected.

El almacén de Exchange también escribe los eventos siguientes en el servidor:

  • 10025, que informa sobre un tiempo de espera en el servidor de Exchange

  • 10026, que informa sobre un tiempo de espera en la base de datos

  • 10027, que informa sobre un tiempo de espera en un buzón de correo concreto

Si se detecta el tiempo de espera en un solo buzón, se considera que puede estar dañado y se trata como si se hubiera producido un error aumentando el valor de la clave CrashCount. Esta acción hace que pueda ponerse en cuarentena.

Bases de datos en ediciones de Exchange 2010

Poco espacio en disco en registros o unidades de base de datos

Cuando el almacén de Exchange detecta que el espacio disponible en un registro o en una unidad de base de datos es menor a 1 GB, interrumpe las entregas de transporte a dicha base de datos. Esta medida se toma para impedir que el disco se quede sin espacio. Cuando un disco se queda sin espacio, la base de datos no puede montarse ni depurarse. Tampoco se puede recuperar el espacio de la base de datos. Se trata de un mecanismo de autoprotección que solamente se aplica si no emprende ninguna acción tras recibir advertencias sobre problemas de espacio de la infraestructura de supervisión.

Cuando el espacio en disco es superior a 1,5 GB, el almacén de Exchange permite seguir con las entregas. Los contadores de rendimiento siguientes indican este comportamiento:

  • MSExchangeIS Mailbox\ Delivery Blocked: espacio insuficiente en el disco

  • MSExchangeIS Mailbox\ Delivery Blocked: espacio insuficiente en el registro

El almacén de Exchange también escribe los eventos siguientes en el servidor:

  • 10014, indica que el espacio en disco del registro es insuficiente

  • 10015, indica que el espacio en disco de la base de datos es insuficiente

Si tiene problemas de espacio en disco insuficiente, puede realizar las acciones siguientes para corregir el problema:

Bases de datos en ediciones de Exchange 2010

Límites del almacén de Exchange

En Exchange 2010, los límites de uso y conexión se aplican al almacén de Exchange para evitar que una única aplicación o un único usuario use todas las conexiones disponibles para el almacén de Exchange. Si se permite que un único usuario o una única aplicación use todas las conexiones, los otros usuarios o aplicaciones no podrán obtener acceso al almacén de Exchange, lo que podría resultar en tiempo de inactividad.

Para obtener más información, consulte Límites del almacén de Exchange.

Bases de datos en ediciones de Exchange 2010

 © 2010 Microsoft Corporation. Reservados todos los derechos.