Arquitectura del motor de almacenamiento extensible

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

Última modificación del tema: 2008-11-19

Las bases de datos de buzones de Exchange y la cola de los servidores de transporte de concentradores y de 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.

Existen dos versiones de ESE:

• ESENTl   El motor de bases de datos de Active Directory y numerosos componentes de Microsoft Windows. A diferencia de otras versiones de ESE (que usan archivos de registro de 5 MB y tamaños de página de 4 KB), la implementación de Active Directory de ESENT usa archivos de registro de 10 MB y páginas de 8 KB.

• ESE98   El motor de bases de datos de Exchange 2000 Server, Exchange Server 2003 y Exchange Server 2007.

• ESE se conocía anteriormente como Joint Engine Technology (JET) Blue. La versión JET Blue no es la misma versión de JET que se encuentra en Microsoft Access (conocida como "JET Red").

Transacciones

ESE es un sofisticado motor de bases de datos basado en transacciones. Una transacción es un conjunto de operaciones que se tratan como una unidad atómica (indivisible). En una transacción, o se realizan y se guardan permanentemente todas las operaciones, o no se lleva a cabo ninguna de ellas. Considere, por ejemplo, las operaciones implicadas al mover un mensaje de la Bandeja de entrada a la carpeta Elementos eliminados. El mensaje se elimina de una carpeta, se agrega a otra y se actualizan las propiedades de las carpetas. Si se produce un error, no es recomendable que haya dos copias del mensaje, ni ninguna copia en absoluto, ni que los valores de las propiedades de las carpetas (como el número de elementos) sean incoherentes con el contenido real de las carpetas.

Para evitar problemas de este tipo, ESE agrupa las operaciones en una transacción. ESE se asegura de que ninguna de las operaciones se aplique permanentemente hasta que la transacción se confirme en el archivo de base de datos. Cuando la transacción se confirma en el archivo de base de datos, todas las operaciones se aplican permanentemente.

Si un servidor deja de responder, ESE también controla la recuperación automática cuando se reinicia el servidor y se revierten las transacciones no confirmadas. Si se produce un error en ESE antes de que se confirme una transacción, se revierte toda la transacción y es como si la transacción nunca se hubiera producido. Si ESE deja de responder después de la confirmación de la transacción, toda la transacción se mantiene y los cambios son visibles para los clientes.

Transacciones ACID

Transacciones como las enumeradas en la sección anterior son denominadas generalmente transacciones ACID. ACID es un acrónimo de los atributos siguientes:

• Atomic (Atomicidad)   Este término indica que un cambio de estado de una transacción se produce totalmente o no se produce. Los cambios atómicos de estado incluyen cambios de bases de datos y mensajes y acciones de los transductores.

• Consistent (Coherencia)   Este término indica que una transacción es una transformación correcta del estado. Las acciones realizadas como grupo no infringen ninguna de las restricciones de integridad asociadas al estado. Para ello es necesario que la transacción sea un programa correcto.

• **Isolated (Aislamiento) **  Este término indica que, aunque las transacciones se ejecuten simultáneamente, cada transacción (t) percibe que las otras se ejecutan antes de t o después de t, pero no ambas cosas.

• Durable (Durabilidad)   Las transacciones confirmadas se conservan en la base de datos aunque el sistema deje de responder.

El almacén de versiones

El almacén de versiones permite a ESE realizar el seguimiento y la administración de las transacciones actuales. Por lo tanto, ESE puede superar las secciones de aislamiento y coherencia de la prueba ACID. El almacén de versiones mantiene en la memoria una lista de las modificaciones realizadas en la base de datos.

El almacén de versiones se usa en las situaciones siguientes:

• Reversión   Si es necesario revertir una transacción, se examina el almacén de versiones para obtener la lista de operaciones realizadas. La transacción se puede revertir invirtiendo todas las operaciones.

• Detección de conflictos de escritura   Si dos sesiones diferentes intentan modificar el mismo registro, el almacén de versiones lo notifica y rechaza la segunda modificación.

• Lecturas repetibles   Cuando una sesión inicia una transacción, siempre encuentra la misma vista de base de datos, aunque otras sesiones modifiquen los registros que está mostrando. Cuando una sesión lee un registro, se realiza una consulta en el almacén de versiones para determinar qué versión del registro debe ver la sesión. Las lecturas repetibles proporcionan un nivel de aislamiento que permite que, después de iniciar una transacción, el cliente vea el estado de la base de datos tal como estaba cuando comenzó la transacción, independientemente de las modificaciones realizadas por otros clientes o sesiones. Las lecturas repetibles se implementan mediante el almacén de versiones. Con una lista en la memoria de las modificaciones realizadas en la base de datos, se puede determinar la vista del registro que se debe ver en una sesión determinada.

• Registro diferido antes de imagen   Es una optimización compleja que permite a ESE registrar menos datos que otros motores de bases de datos equiparables.

Aislamiento de instantáneas

Después de iniciarse una transacción, ESE garantiza que la sesión vea una imagen única y coherente de la base de datos, tal como era al inicio de la transacción, más los cambios realizados. Como otras sesiones pueden modificar también los datos y confirmar sus transacciones, estos cambios son invisibles a cualquier transacción iniciada antes de la confirmación. Un usuario sólo puede modificar un registro si ve la última versión. De lo contrario, se produce un error de JET_errWriteConflict en la actualización. Las versiones anteriores a la última transacción se descartan automáticamente.

ESE dispone de un nivel de aislamiento de transacciones denominado Aislamiento de instantáneas. El nivel de aislamiento de instantáneas permite a los usuarios obtener acceso a la última fila confirmada mediante una vista coherente entre transiciones de la base de datos. El aislamiento de instantáneas es un algoritmo de control de simultaneidad descrito por primera vez en el documento Crítica de los niveles de aislamiento SQL de ANSI. ESE implementa el aislamiento de instantáneas mediante el uso de lecturas repetibles.

Estructura de la base de datos de ESE

Todos los datos contenidos en el archivo de bases de datos de texto enriquecido se almacenan en árboles B. La "B" es la inicial de "balanced" (equilibrado). "Árbol" hace referencia a una disposición similar a una estructura de carpetas de un sistema de archivos, donde una raíz es el nodo primario de elementos (páginas de base de datos), que a su vez son nodos primarios de otros elementos. Los árboles B están diseñados para proporcionar acceso rápido a los datos del disco. Como las operaciones de lectura y escritura en un disco son mucho más lentas que en la memoria, un árbol B se divide en páginas de 8 KB. Esto permite a ESE obtener los datos que necesita mediante el número mínimo de operaciones de entrada y salida del disco. Una base de datos de ESE puede albergar páginas de hasta 2^31 (2 elevado a la 31ª potencia) para una base de datos con un tamaño total de unos 16 terabytes, como máximo. En realidad, el tamaño de la base de datos está limitado únicamente por la capacidad de realizar copias de seguridad, restauraciones y otras operaciones de mantenimiento de la base de datos (como la desfragmentación sin conexión y las reparaciones de la base de datos) en el momento adecuado.

Páginas de bases de datos

El tamaño de página en ESE lo define la aplicación que lo usa. Por ejemplo, ESE98 (Exchange 2000 Server y Exchange Server 2003) usa páginas de 4 KB, mientras que ESENT (Active Directory) usa páginas de 8 KB. Todas estas páginas de 4 u 8 KB contienen punteros a otras páginas o a los datos reales que se almacenan en el árbol B. El puntero y las páginas de datos están entremezclados en el archivo.

Para aumentar el rendimiento donde sea posible, las páginas se almacenan en un búfer de memoria durante todo el tiempo posible. Esto reduce la necesidad de recurrir al disco. Cada página comienza con un encabezado de página de 40 bytes que incluye los siguientes valores:

• pgnoThis   Este valor indica el número de la página.

• DbtimeDirtied   Este valor indica la hora en que se modificó la página por última vez (Dbtime).

• pgnoPrev   Este valor indica el número de la página izquierda contigua de la hoja.

• pgnoNext   Este valor indica el número de la página derecha contigua de la hoja.

• ObjidFDP   Este valor indica el identificador de objeto de una página especial de la base de datos, denominada Padre de la página de datos (FDP), que indica el árbol B al que pertenece esta página. La página FDP se usa durante las reparaciones.

• cbFree   Este valor indica el número de bytes disponibles en la página.

• cbUncommittedFree   Este valor indica el número de bytes no confirmados disponibles (bytes que están libres pero disponibles para usarlos en la reversión) en la página.

• ibMicFree   Este valor indica el desplazamiento de la página para el siguiente byte disponible al principio de la página.

Suma de comprobación de ECC

La suma de comprobación de código de corrección de error (ECC) permite la corrección de errores de un bit en las páginas de bases de datos (en el archivo .edb).

Consta de dos sumas de comprobación de 32 bits. La primera es una suma de comprobación XOR en la que el número de página se usa como valor de inicialización del cálculo. La segunda suma de comprobación de 32 bits es una suma de comprobación ECC, que permite la corrección de errores de un bit en la página.

Coherencia de la base de datos y errores -1018

Al leer una página, ESE examina un marcador de la página para ver si la página tiene el formato de suma de comprobación actual. A continuación, se calcula la suma de comprobación adecuada. Si existe discrepancia con el formato de suma de comprobación actual, ESE intenta corregir el error. Si no se puede corregir automáticamente, Exchange notifica un error -1018.

El propio almacén de Exchange podría ser el responsable de generar un error -1018, si Exchange realiza una de las acciones siguientes:

• Crea una página que tiene una suma de comprobación incorrecta.

• Crea una página correctamente, pero indica al sistema operativo que escriba la página en una ubicación incorrecta.

Si un administrador del sistema detecta un error -1018 o ejecuta pruebas de diagnóstico de hardware en el servidor y estas pruebas no señalan problemas, el administrador puede concluir que Exchange debe ser el responsable del problema, ya que el hardware ha superado los análisis iniciales.

Frecuentemente, una investigación más profunda realizada por Microsoft o por proveedores de hardware ha puesto al descubierto pequeños problemas en el hardware, el firmware o los controladores de dispositivos, que eran los verdaderos responsables de los daños producidos en el archivo de base de datos.

Las pruebas de diagnóstico normales pueden no detectar todos los errores transitorios por varios motivos. Los problemas de firmware o de software de controladores pueden estar fuera de las capacidades de los programas de diagnóstico. Las pruebas de diagnóstico pueden no ser capaces de simular adecuadamente tiempos de ejecución largos o cargas complejas. Además, la agregación de supervisión de diagnóstico o de registro de depuración puede cambiar lo suficiente el sistema como para impedir que el problema vuelva a producirse.

La sencillez y estabilidad de los mecanismos de Exchange que generan sumas de comprobación y que escriben páginas en el archivo de base de datos sugiere que la causa probable de un error -1018 sea ajena a Exchange. Los mecanismos de suma de comprobación y de detección de páginas incorrectas son sencillos y confiables, y son básicamente los mismos desde la primera versión de Exchange, salvo cambios menores para adaptar el formato de páginas de bases de datos entre las distintas versiones de bases de datos.

Cuando una página está a punto de escribirse en el disco, una vez escritos en la página todos los demás datos, incluido el propio número de página, se genera una suma de comprobación de la página. Una vez que Exchange ha agregado la suma de comprobación a la página, indica al sistema operativo de Microsoft Windows Server que escriba la página en el disco mediante API de Windows Server publicadas estándar.

Puede que la suma de comprobación de la página se genere correctamente, pero que la página se escriba en una ubicación incorrecta del disco duro. El motivo puede ser un error de memoria transitorio, como un "bit flip" (inversión de un bit). Por ejemplo, supongamos que Exchange construye una nueva versión de la página 70. En la propia página no se produce ningún error, pero la copia del número de página que usa el controlador de disco o el sistema operativo cambia aleatoriamente. Este problema puede producirse si una celda de memoria inestable ha cambiado 70 (1000110 binario) por 6 (000110 binario). La suma de comprobación de la página sigue siendo correcta, pero la ubicación de la página en la base de datos es ahora incorrecta. Exchange notifica un error -1018 en la página cuando detecta que el número lógico de la página no coincide con su ubicación física.

Otro tipo de error de numeración de páginas (causado por Exchange) puede producirse cuando Exchange escribe un número de página incorrecto en la propia página. Sin embargo, esto origina otros errores, no el error -1018. Si Exchange escribe 71 en la página 70 y, a continuación, realiza la suma de comprobación en la página correctamente, la página se escribe en la ubicación 71 y supera tanto la prueba de número de página como la de suma de comprobación.

Frecuentemente, un único error -1018 notificado en una base de datos de Exchange no hace que se detenga la base de datos ni que aparezca ningún otro síntoma aparte de la propia presencia del error -1018. La página podría estar un una carpeta a la que se obtiene acceso con poca frecuencia (por ejemplo, las carpetas Elementos enviados o Elementos eliminados) o en datos adjuntos que apenas se abran o que incluso estén vacíos.

Aunque es improbable que un único error -1018 cause una gran pérdida de datos, la aparición de errores -1018 sigue siendo preocupante, ya que son la prueba de que el sistema de almacenamiento no ha almacenado o recuperado datos con confiabilidad al menos una vez. Aunque un error -1018 puede ser un problema transitorio que no se repita nunca, es más probable que se trate de la primera advertencia de un problema que empeorará progresivamente. Aunque el primer error -1018 sea una página vacía de la base de datos, no se puede saber qué página podría ser la siguiente en resultar dañada. Si una tabla global importante sufre daños, la base de datos podría no iniciarse y la reparación podría ser parcial o totalmente insatisfactoria.

Después de registrarse un error -1018, debe tener en cuenta la posibilidad de un error inminente o de daños aleatorios adicionales en la base de datos, hasta que encuentre y elimine la causa raíz.

Equilibrio del árbol de base de datos

Una de las funciones principales de ESE es mantener el árbol de base de datos equilibrado en todo momento. El proceso de equilibrar el árbol termina cuando se han dividido o combinado todas las páginas. Como se puede ver en la figura siguiente, el nivel raíz del árbol siempre contiene el mismo número de nodos que el nivel de hoja del árbol. Por tanto, el árbol está equilibrado.

Árbol equilibrado

Desde el punto de vista de ESE, una tabla de base de datos es un conjunto de árboles B. Cada tabla está formada por un árbol B que contiene los datos, aunque puede haber muchos árboles B de índices secundarios usados para proporcionar diferentes vistas de los datos. Si una columna o un campo de una tabla se hace demasiado ancho para almacenarse en el árbol B, se divide en un árbol B independiente, denominado árbol de valores largos.

La definición de estas tablas y sus árboles B asociados se almacenan en otro árbol B, denominado catálogo del sistema. La pérdida del catálogo del sistema es un problema grave. Por tanto, ESE mantiene dos copias idénticas de este árbol B en cada base de datos.

División

Cuando una página está casi llena, aproximadamente la mitad de los datos se sitúan en una página secundaria y se incluye una clave adicional en la página primaria de esta página. Este proceso se realiza a menos que la página primaria también esté llena. En este caso, la página primaria se divide y se agrega un puntero a la página primaria de esta página. En última instancia, podría ser necesario dividir cada página de puntero hasta el bloque raíz. Si es necesario dividir el bloque raíz, se inserta un nivel de páginas adicional en el árbol. En sentido figurado, el árbol crece en altura.

Combinación

Cuando una página está casi vacía, se combina con una página contigua, se actualizan los punteros de la página primaria y, si es necesario, se combina la página. En última instancia, si se combina cada página de puntero hasta el bloque raíz, el árbol disminuye en altura. Para llegar hasta una hoja (datos), ESE comienza en el nodo raíz y sigue los punteros de página hasta llegar al nodo de hoja deseado.

Distribución ramificada

La estructura de un árbol B de ESE tiene una distribución ramificada muy alta. Esto significa que ESE puede obtener acceso a cualquier fragmento de datos de una tabla de 50 GB con un máximo de cuatro lecturas de disco (tres páginas de puntero y la propia página de datos). ESE almacena más de 200 punteros de página por cada página de 4 KB, lo que le permite usar árboles con un número mínimo de niveles primarios y secundarios (llamados también árboles superficiales). ESE almacena también una clave del árbol actual que le permite buscar rápidamente en dicho árbol. El diagrama anterior es un árbol con tres niveles primario/secundarios; un árbol con cuatro niveles primario/secundarios puede almacenar muchos gigabytes de datos.

Índices

Un árbol B tradicional sólo se indiza de un modo concreto. Usa una clave mediante la cual deben recuperarse los datos. Por ejemplo, los registros de la tabla de mensajes se indizan en un identificador único del mensaje, denominado Id. del servicio de transferencia de mensajes (MST). Sin embargo, es probable que un usuario desee ver los datos de la tabla de mensajes ordenados de una forma más sencilla.

Los índices, o más concretamente, los índices secundarios, se usan para recuperar los datos. Cada índice secundario es otro árbol B que asigna la clave secundaria elegida a la clave principal. Con ello se obtienen árboles B pequeños en comparación con los datos que indizan.

Para comprender cómo se usa un índice secundario, piense en lo que sucede cuando un usuario cambia la forma en que se presentan los mensajes en una carpeta de mensajería. Si cambia la vista de carpeta en Outlook para que se ordene por el asunto en lugar de por la hora de recepción, Outlook hará que el almacén y ESE creen un nuevo índice secundario en la tabla de carpetas de mensajes.

Cuando cambie por primera vez las vistas en una carpeta de gran tamaño, se producirá una demora. Si examina atentamente el servidor, observará un pequeño pico en la actividad del disco. Cuando vuelva a cambiar a esa vista, el índice ya se habrá creado y la respuesta será mucho más rápida.

Los árboles B del índice secundario de los servicios Almacén de información de Microsoft Exchange se conservan durante ocho días. Si no se usan, el servicio Almacén de información de Microsoft Exchange los elimina mediante una operación en segundo plano.

Valores largos

Una columna o registro de ESE no puede abarcar páginas del árbol B de datos. Hay valores (como PR_BODY, que es el cuerpo de un mensaje) que incumplen el límite de 4 KB para una página. Se denominan valores largos (LV). El árbol B de valores largos de una tabla se usa para almacenar estos valores.

Si se introduce en una tabla ESE un dato demasiado grande como para incluirlo en el árbol B de datos, se divide en páginas de 4 KB y se almacena en el árbol B independiente de valores largos de la tabla. El registro del árbol B de datos contiene un puntero al valor largo. Este puntero se denomina Id. del valor largo (LID) e indica que el registro tiene un puntero a LID 256.

Formato de registros

Un conjunto de árboles B representa una tabla y una tabla es un conjunto de filas. Las filas se denominan también registros. Un registro se compone de muchas columnas. El tamaño máximo de un registro y, por tanto, el número de columnas que aparecen en un único registro, está regido por el tamaño de página de la base de datos menos el tamaño del encabezado. ESE tiene un tamaño de página de 4 KB. Por tanto, el tamaño máximo del registro es de aproximadamente 4.050 bytes (4.096 bytes menos el tamaño del encabezado de la página).

Tipos de datos de columna

Cada definición de columna debe especificar el tipo de datos que se almacenan en la columna. ESE admite los tipos de datos que se describen en la tabla siguiente.

Tipos de datos de columna del motor de almacenamiento extensible

Los tipos de datos de columna se dividen en dos categorías. La primera categoría la componen las columnas fijas y variables. La segunda categoría son las columnas etiquetadas. Cada columna se define como una estructura FIELD de 16 bytes más el tamaño del nombre de columna.

Cuando se crea una tabla en una base de datos ESE, la tabla se define mediante una matriz de estructuras FIELD. Esta matriz identifica las distintas columnas de la tabla. Dentro de esta matriz, cada columna se representa mediante un valor de índice, denominado Id. de columna. Es similar a una matriz normal en la que se puede hacer referencia a miembros de la matriz por el Id., como matriz[0], matriz[1], etc. A las columnas se obtiene acceso rápido mediante el Id., pero una búsqueda por nombre de columna requiere un examen lineal de toda la matriz de estructuras FIELD.

Columnas fijas y variables

Las columnas fijas tienen una longitud de datos fija. Cada registro ocupa una cantidad definida de espacio de registro, aunque no se defina ningún valor. Los Id. de tipos de datos del 1 al 10 se pueden definir como columnas fijas. Cada tabla puede definir hasta 126 columnas fijas (Id. de columna del 1 al 127).

Las columnas variables pueden contener hasta 256 bytes de datos. En el registro se almacena una matriz de desplazamiento con el conjunto mayor de columnas variables. Cada columna requiere dos bytes. Los Id. de tipos de datos 10 y 11 se pueden definir como columnas variables. Cada tabla puede definir hasta 127 columnas variables (Id. de columna del 128 al 256).

Columnas etiquetadas

ESE define las columnas que rara vez aparecen o que aparecen varias veces en un solo registro como columnas etiquetadas. Las columnas etiquetadas no definidas no producen sobrecarga de espacio. Una columna etiquetada puede aparecer repetidas veces en el mismo registro. Si una columna etiquetada está representada en un índice secundario, este índice hace referencia a cada aparición distinta de la columna.

Las columnas etiquetadas pueden contener una longitud de datos variable e ilimitada. El Id. y la longitud de la columna se almacenan con los datos. Todos los tipos de datos se pueden definir como columnas etiquetadas. Cada tabla puede definir hasta 64.993 columnas etiquetadas.