Extensible Storage Engine ( ESE ), también conocido como JET Blue , es una tecnología de almacenamiento de datos ISAM (método de acceso secuencial indexado) de Microsoft . ESE es el núcleo de Microsoft Exchange Server , Active Directory y Windows Search . También lo utilizan varios componentes de Windows, incluido el cliente de Windows Update y el Centro de ayuda y soporte técnico . Su propósito es permitir que las aplicaciones almacenen y recuperen datos a través de acceso indexado y secuencial.
ESE permite la actualización y recuperación de datos de transacciones . Se proporciona un mecanismo de recuperación ante fallos para mantener la coherencia de los datos incluso en caso de fallo del sistema. Las transacciones en ESE son altamente concurrentes, lo que hace que ESE sea adecuado para aplicaciones de servidor. ESE almacena en caché los datos de forma inteligente para garantizar un acceso de alto rendimiento a los datos. Además, ESE es ligero, lo que lo hace adecuado para aplicaciones auxiliares.
El entorno de ejecución de ESE (ESENT.DLL) se ha incluido en todas las versiones de Windows desde Windows 2000 , y la versión x64 nativa del entorno de ejecución de ESE se incluye con las versiones x64 de Windows XP y Windows Server 2003. Microsoft Exchange , hasta Exchange 2003, se entregaba solo con la edición de 32 bits, ya que era la única plataforma compatible. Con Exchange 2007 , se entrega con la edición de 64 bits.
Una base de datos es una agrupación física y lógica de datos. Una base de datos ESE parece un solo archivo para Windows. Internamente, la base de datos es una colección de páginas de 2, 4, 8, 16 o 32 KB (las opciones de página de 16 y 32 KB solo están disponibles en Windows 7 y Exchange 2010), [1] organizadas en una estructura de árbol B equilibrada . [2] Estas páginas contienen metadatos para describir los datos contenidos en la base de datos, los datos en sí, índices para mantener los órdenes interesantes de los datos y otra información. Esta información se entremezcla dentro del archivo de la base de datos, pero se realizan esfuerzos para mantener los datos utilizados juntos agrupados dentro de la base de datos. Una base de datos ESE puede contener hasta 2 páginas de 32 KB , o 16 terabytes de datos, [3] para páginas de tamaño de 8 kilobytes .
Las bases de datos de ESE se organizan en grupos denominados instancias. La mayoría de las aplicaciones utilizan una única instancia, pero todas las aplicaciones también pueden utilizar varias instancias. La importancia de la instancia es que asocia una única serie de registros de recuperación con una o más bases de datos. Actualmente, se pueden adjuntar hasta 6 bases de datos de usuario a una instancia de ESE en cualquier momento. Cada proceso independiente que utilice ESE puede tener hasta 1024 instancias de ESE.
Una base de datos es portátil porque se puede separar de una instancia de ESE en ejecución y luego adjuntarla a la misma instancia en ejecución o a una diferente. Mientras está separada, una base de datos se puede copiar utilizando utilidades estándar de Windows. La base de datos no se puede copiar mientras se utiliza activamente, ya que ESE abre exclusivamente archivos de base de datos. Una base de datos puede residir físicamente en cualquier dispositivo compatible con operaciones de E/S direccionables directamente por Windows.
Una tabla es una colección homogénea de registros, donde cada registro tiene el mismo conjunto de columnas. Cada tabla se identifica mediante un nombre de tabla, cuyo alcance es local a la base de datos en la que se encuentra la tabla. La cantidad de espacio en disco asignado a una tabla dentro de una base de datos se determina mediante un parámetro proporcionado cuando se crea la tabla con la operación CreateTable. Las tablas crecen automáticamente en respuesta a la creación de datos.
Las tablas tienen uno o más índices. Debe haber al menos un índice agrupado para los datos de registros. Cuando la aplicación no define ningún índice agrupado, se utiliza un índice artificial que ordena y agrupa los registros según el orden cronológico de inserción de los registros. Los índices se definen para mantener órdenes de datos interesantes y permitir tanto el acceso secuencial a los registros en orden de índice como el acceso directo a los registros por valores de columna de índice. Los índices agrupados en ESE también deben ser primarios, lo que significa que la clave del índice debe ser única.
Los índices agrupados y no agrupados se representan mediante árboles B+ . Si una operación de inserción o actualización hace que una página se desborde, la página se divide: se asigna una nueva página y se encadena lógicamente entre las dos páginas adyacentes anteriores. Dado que esta nueva página no está físicamente adyacente a sus vecinas lógicas, el acceso a ella no es tan eficiente. ESE tiene una función de compactación en línea que vuelve a compactar los datos. Si se espera que una tabla se actualice con frecuencia, se puede reservar espacio para futuras inserciones especificando una densidad de páginas adecuada al crear una tabla o un índice. Esto permite evitar o posponer las operaciones de división.
Un registro es un conjunto asociado de valores de columna. Los registros se insertan y actualizan mediante operaciones de actualización y se pueden eliminar mediante operaciones de eliminación. Las columnas se configuran y recuperan mediante operaciones de SetColumns y RetrieveColumns, respectivamente. El tamaño máximo de un registro es de 8110 bytes para páginas de 8 kilobytes, con excepción de las columnas de valores largos. Los tipos de columna LongText y LongBinary no contribuyen significativamente a esta limitación de tamaño, y los registros pueden contener datos mucho más grandes que el tamaño de una página de base de datos cuando los datos se almacenan en columnas de valores largos. Cuando se almacena una referencia de valor largo en un registro, solo se requieren 9 bytes de datos dentro del registro. Estos valores largos pueden tener un tamaño de hasta 2 gigabytes (GB).
Los registros suelen ser uniformes, ya que cada uno de ellos tiene un conjunto de valores para el mismo conjunto de columnas. En ESE, también es posible definir muchas columnas para una tabla y, sin embargo, que cualquier registro determinado contenga solo una pequeña cantidad de valores de columna distintos de NULL. En este sentido, una tabla también puede ser una colección de registros heterogéneos.
ESE admite una amplia gama de valores de columnas, cuyo tamaño varía de 1 bit a 2 GB. Elegir el tipo de columna correcto es importante porque el tipo de columna determina muchas de sus propiedades, incluido el orden en que se ordenan los índices. ESE admite los siguientes tipos de datos:
Cada tabla ESE puede definir hasta 127 columnas de longitud fija, 128 columnas de longitud variable y 64.993 columnas etiquetadas.
En una tabla determinada, las columnas se dividen en dos categorías: las que aparecen exactamente una vez en cada uno de los registros, con posiblemente algunos valores NULL; y las que aparecen raramente o que pueden aparecer varias veces en un solo registro. Las columnas fijas y variables pertenecen a la primera categoría, mientras que las columnas etiquetadas pertenecen a la segunda. La representación interna de las dos categorías de columnas es diferente, y es importante comprender las ventajas y desventajas entre ellas. Las columnas fijas y variables suelen estar representadas en cada registro, incluso cuando la aparición tiene un valor NULL. Estas columnas se pueden abordar rápidamente a través de una tabla de desplazamiento. Las apariciones de columnas etiquetadas están precedidas por un identificador de columna y la columna se localiza mediante una búsqueda binaria en el conjunto de columnas etiquetadas.
Los tipos de columna de texto largo y binario largo son objetos binarios grandes. Se almacenan en un árbol B+ independiente del índice agrupado codificado por id de valor largo y desplazamiento de bytes. ESE admite la adición, la sobrescritura de rango de bytes y el tamaño de configuración para estas columnas. Además, ESE tiene una función de almacenamiento de instancia única donde varios registros pueden hacer referencia al mismo objeto binario grande, como si cada registro tuviera su propia copia de la información, es decir, sin conflictos de bloqueo entre registros. El tamaño máximo de un valor de columna de texto largo o binario largo es de 2 GB.
Las columnas de versión se incrementan automáticamente por ESE cada vez que se modifica un registro que contiene esta columna mediante una operación de actualización. La aplicación no puede configurar esta columna, solo se puede leer. Las aplicaciones de las columnas de versión incluyen su uso para determinar si es necesario actualizar una copia en memoria de un registro determinado. Si el valor de un registro de tabla es mayor que el valor de una copia almacenada en caché, se sabe que la copia almacenada en caché está desactualizada. Las columnas de versión deben ser de tipo Long.
Las columnas de incremento automático se configuran automáticamente por ESE de modo que el valor contenido en la columna sea único para cada registro de la tabla. Estas columnas, al igual que las columnas de versión, no pueden ser configuradas por la aplicación. Las columnas de incremento automático son de solo lectura y se configuran automáticamente cuando se inserta un nuevo registro en una tabla mediante una operación de actualización. El valor de la columna permanece constante durante la vida del registro y solo se permite una columna de incremento automático por tabla. Las columnas de incremento automático pueden ser de tipo Long o de tipo Currency.
Las columnas de depósito en garantía se pueden modificar mediante una operación EscrowUpdate. Las actualizaciones en depósito en garantía son operaciones delta numéricas. Las columnas de depósito en garantía deben ser de tipo Long. Algunos ejemplos de operaciones delta numéricas son la suma de 2 a un valor o la resta de 1 a un valor. ESE realiza un seguimiento del cambio en un valor en lugar del valor final de una actualización. Es posible que varias sesiones tengan cambios pendientes realizados mediante EscrowUpdate en el mismo valor porque ESE puede determinar el valor final real independientemente de qué transacciones se confirmen y qué transacciones se reviertan. Esto permite que varios usuarios actualicen simultáneamente una columna realizando cambios delta numéricos. De manera opcional, el motor de base de datos puede borrar registros con valor cero de la columna. Un uso común para dicha columna de depósito en garantía es el contador de referencia: muchos subprocesos incrementan o disminuyen el valor sin bloqueos y, cuando el contador llega a cero, el registro se elimina automáticamente.
Un índice es un ordenamiento persistente de registros en una tabla. Los índices se utilizan tanto para el acceso secuencial a las filas en el orden definido como para la navegación directa por los registros en función de los valores de las columnas indexadas. El orden definido por un índice se describe en términos de una matriz de columnas, en orden de precedencia. Esta matriz de columnas también se denomina clave de índice. Cada columna se denomina segmento de índice. Cada segmento de índice puede ser ascendente o descendente, en términos de su contribución al ordenamiento. Se puede definir cualquier cantidad de índices para una tabla. ESE proporciona un amplio conjunto de funciones de indexación.
Un índice puede especificarse como índice agrupado o primario. En ESE, el índice agrupado debe ser único y se lo denomina índice primario. Otros índices se describen como índices no agrupados o secundarios. Los índices primarios se diferencian de los secundarios en que la entrada del índice es el registro en sí y no un puntero lógico al registro. Los índices secundarios tienen claves primarias en sus hojas para vincularse lógicamente con el registro en el índice primario. En otras palabras, la tabla está agrupada físicamente en orden de índice primario. La recuperación de datos de registros no indexados en orden de índice primario es generalmente mucho más rápida que en orden de índice secundario. Esto se debe a que un solo acceso a disco puede traer a la memoria múltiples registros a los que se accederá muy cerca en el tiempo. El mismo acceso a disco satisface múltiples operaciones de acceso a registros. Sin embargo, la inserción de un registro en el medio de un índice, según lo determinado por el orden de índice primario, puede ser mucho más lenta que anexarlo al final de un índice. La frecuencia de actualización debe considerarse cuidadosamente en relación con los patrones de recuperación al realizar el diseño de la tabla. Si no se define un índice primario para una tabla, se crea un índice primario implícito, denominado índice de clave de base de datos (DBK). El DBK es simplemente un número único ascendente que se incrementa cada vez que se inserta un registro. Como resultado, el orden físico de los registros en un índice DBK es el orden de inserción cronológico y los registros nuevos siempre se agregan al final de la tabla. Si una aplicación desea agrupar datos en un índice no único, esto es posible agregando una columna de incremento automático al final de la definición del índice no único.
Se pueden definir índices sobre columnas de varios valores. Pueden existir varias entradas en estos índices para registros con varios valores para la columna indexada. Las columnas de varios valores se pueden indexar junto con columnas de un solo valor. Cuando se indexan juntas dos o más columnas de varios valores, la propiedad de varios valores solo se respeta para la primera columna de varios valores del índice. Las columnas de menor precedencia se tratan como si tuvieran un solo valor.
Los índices también se pueden definir como dispersos. Los índices dispersos no tienen al menos una entrada para cada registro de la tabla. Hay varias opciones para definir un índice disperso. Existen opciones para excluir registros de los índices cuando una clave de índice completa es NULL, cuando cualquier segmento de clave es NULL o cuando solo el primer segmento de clave es NULL. Los índices también pueden tener columnas condicionales. Estas columnas nunca aparecen dentro de un índice, pero pueden hacer que un registro no se indexe cuando la columna condicional es NULL o no NULL.
Los índices también se pueden definir para incluir una entrada para cada subcadena de una columna de texto o texto largo. Estos índices se denominan índices de tupla. Se utilizan para acelerar las consultas con predicados de coincidencia de subcadenas. Los índices de tupla solo se pueden definir para columnas de texto. Por ejemplo, si un valor de columna de texto es “Me encanta JET Blue” y el índice está configurado para tener un tamaño de tupla mínimo de 4 caracteres y una longitud de tupla máxima de 10 caracteres, se indexarán las siguientes subcadenas:
Aunque los índices de tupla pueden ser muy grandes, pueden acelerar significativamente las consultas del formato: buscar todos los registros que contengan “JET Blue” . Se pueden utilizar para subcadenas más largas que la longitud máxima de tupla dividiendo la subcadena de búsqueda en cadenas de búsqueda de longitud máxima de tupla e intersecando los resultados. Se pueden utilizar para coincidencias exactas de cadenas tan largas como la longitud máxima de tupla o tan cortas como la longitud mínima de tupla, sin intersección de índices. Para obtener más información sobre cómo realizar la intersección de índices en ESE, consulte Intersección de índices. Los índices de tuplas no pueden acelerar las consultas en las que la cadena de búsqueda es más corta que la longitud mínima de tupla.
Una transacción es una unidad lógica de procesamiento delimitada por las operaciones BeginTransaction y CommitTransaction, o Rollback. Todas las actualizaciones realizadas durante una transacción son atómicas; o bien aparecen todas en la base de datos al mismo tiempo o no aparece ninguna. Cualquier actualización posterior realizada por otras transacciones es invisible para una transacción. Sin embargo, una transacción puede actualizar solo datos que no hayan cambiado mientras tanto; de lo contrario, la operación falla de inmediato sin esperar. Las transacciones de solo lectura nunca necesitan esperar, y las transacciones de actualización solo pueden interferir con otras transacciones de actualización. Las transacciones que finalizan por Rollback, o por un fallo del sistema, no dejan rastro en la base de datos. En general, el estado de los datos se restaura en Rollback a lo que era antes de BeginTransaction.
Las transacciones pueden estar anidadas hasta en 7 niveles, con un nivel adicional reservado para uso interno de ESE. Esto significa que una parte de una transacción puede revertirse, sin necesidad de revertir la transacción completa; una CommitTransaction de una transacción anidada simplemente significa el éxito de una fase de procesamiento, y la transacción externa aún puede fallar. Los cambios se confirman en la base de datos solo cuando se confirma la transacción más externa. Esto se conoce como confirmación en el nivel de transacción 0. Cuando la transacción se confirma en el nivel de transacción 0, los datos que describen la transacción se vacían sincrónicamente en el registro para garantizar que la transacción se completará incluso en el caso de un fallo posterior del sistema. La limpieza sincrónica del registro hace que las transacciones de ESE sean duraderas. Sin embargo, en algunos casos, la aplicación desea ordenar sus actualizaciones, pero no garantizar inmediatamente que se realicen los cambios. Aquí, las aplicaciones pueden confirmar los cambios con JET_bitIndexLazyFlush.
ESE admite un mecanismo de control de concurrencia denominado multiversionado. En el multiversionado, cada transacción consulta una vista coherente de toda la base de datos tal como estaba en el momento en que se inició la transacción. Las únicas actualizaciones que encuentra son las que realiza. De esta manera, cada transacción funciona como si fuera la única transacción activa que se ejecuta en el sistema, excepto en el caso de conflictos de escritura. Dado que una transacción puede realizar cambios en función de los datos leídos que ya se han actualizado en otra transacción, el multiversionado por sí solo no garantiza transacciones serializables . Sin embargo, la serialización se puede lograr cuando se desee simplemente utilizando bloqueos de lectura de registros explícitos para bloquear los datos leídos en los que se basan las actualizaciones. Tanto los bloqueos de lectura como los de escritura se pueden solicitar explícitamente con la operación GetLock.
Además, ESE admite una función avanzada de control de concurrencia conocida como bloqueo de depósito de garantía. El bloqueo de depósito de garantía es una actualización extremadamente concurrente en la que un valor numérico se modifica de forma relativa, es decir, añadiendo o restando otro valor numérico. Las actualizaciones de depósito de garantía no entran en conflicto ni siquiera con otras actualizaciones de depósito de garantía concurrentes del mismo dato. Esto es posible porque las operaciones admitidas son conmutables y se pueden confirmar o revertir de forma independiente. Como resultado, no interfieren con las transacciones de actualización concurrentes. Esta función se utiliza a menudo para agregaciones mantenidas.
ESE también extiende la semántica de transacciones desde operaciones de manipulación de datos a operaciones de definición de datos. Es posible agregar un índice a una tabla y hacer que transacciones que se ejecutan simultáneamente actualicen la misma tabla sin ningún tipo de contención de bloqueo de transacciones. Más tarde, cuando se completan estas transacciones, el índice recién creado está disponible para todas las transacciones y tiene entradas para actualizaciones de registros realizadas por otras transacciones que no pudieron percibir la presencia del índice cuando se realizaron las actualizaciones. Las operaciones de definición de datos se pueden realizar con todas las características esperadas del mecanismo de transacción para actualizaciones de registros. Las operaciones de definición de datos admitidas de esta manera incluyen AddColumn, DeleteColumn, CreateIndex, DeleteIndex, CreateTable y DeleteTable.
Un cursor es un puntero lógico dentro de un índice de tabla. El cursor puede estar ubicado en un registro, antes del primer registro, después del último registro o incluso entre registros. Si un cursor está ubicado antes o después de un registro, no hay ningún registro actual. Es posible tener múltiples cursores en el mismo índice de tabla. Muchas operaciones de registros y columnas se basan en la posición del cursor. La posición del cursor se puede mover secuencialmente mediante operaciones de movimiento o directamente utilizando teclas de índice con operaciones de búsqueda. Los cursores también se pueden mover a una posición fraccionaria dentro de un índice. De esta manera, el cursor se puede mover rápidamente a una posición de barra de pulgar. Esta operación se realiza con la misma velocidad que una operación de búsqueda. No se debe acceder a ningún dato intermedio.
Cada cursor tiene un búfer de copia para crear un nuevo registro o modificar un registro existente, columna por columna. Se trata de un búfer interno cuyo contenido se puede cambiar con operaciones SetColumns. Las modificaciones del búfer de copia no cambian automáticamente los datos almacenados. El contenido del registro actual se puede copiar en el búfer de copia mediante la operación PrepareUpdate, y las operaciones Update almacenan el contenido del búfer de copia como un registro. El búfer de copia se borra implícitamente en una confirmación o reversión de transacción, así como en operaciones de navegación. RetrieveColumns se puede utilizar para recuperar datos de columna ya sea del registro o del búfer de copia, si existe uno.
Las aplicaciones ESE consultan invariablemente sus datos. Esta sección del documento describe las características y técnicas para que las aplicaciones escriban lógica de procesamiento de consultas en ESE.
ESE proporciona una capacidad de ordenación en forma de tablas temporales. La aplicación inserta registros de datos en el proceso de ordenación, un registro a la vez, y luego los recupera un registro a la vez en orden ordenado. La ordenación se realiza en realidad entre la última inserción de registro y la primera recuperación de registro. Las tablas temporales también se pueden utilizar para conjuntos de resultados parciales y completos. Estas tablas pueden ofrecer las mismas características que las tablas base, incluida la capacidad de navegar secuencialmente o directamente a las filas utilizando claves de índice que coincidan con la definición de ordenación. Las tablas temporales también se pueden actualizar para el cálculo de agregados complejos. Los agregados simples se pueden calcular automáticamente con una característica similar a la ordenación, donde el agregado deseado es un resultado natural del proceso de ordenación.
La recuperación de datos de columnas directamente de índices secundarios es una optimización de rendimiento importante. Las columnas se pueden recuperar directamente de índices secundarios, sin acceder a los registros de datos, mediante el indicador RetrieveFromIndex en la operación RetrieveColumns. Es mucho más eficiente recuperar columnas de un índice secundario que del registro cuando se navega por el índice. Si los datos de la columna se recuperaron del registro, entonces es necesaria una navegación adicional para localizar el registro por la clave principal. Esto puede generar accesos adicionales al disco. Cuando un índice proporciona todas las columnas necesarias, se denomina índice de cobertura. Tenga en cuenta que las columnas definidas en el índice principal de la tabla también se encuentran en índices secundarios y se pueden recuperar de manera similar utilizando JET_bitRetrieveFromPrimaryBookmark.
Las claves de índice se almacenan en formato normalizado que, en muchos casos, se puede desnormalizar al valor de la columna original. La normalización no siempre es reversible. Por ejemplo, los tipos de columna Texto y Texto largo no se pueden desnormalizar. Además, las claves de índice se pueden truncar cuando los datos de la columna son muy largos. En los casos en los que no se pueden recuperar columnas directamente de los índices secundarios, siempre se puede acceder al registro para recuperar los datos necesarios.
Las consultas suelen implicar una combinación de restricciones sobre los datos. Un medio eficiente de procesar una restricción es utilizar un índice disponible. Sin embargo, si una consulta implica múltiples restricciones, las aplicaciones suelen procesar las restricciones recorriendo todo el rango de índices del predicado más restrictivo satisfecho por un único índice. Cualquier predicado restante, llamado predicado residual, se procesa aplicándolo al registro mismo. Este es un método simple pero tiene la desventaja de tener que realizar potencialmente muchos accesos al disco para llevar los registros a la memoria para aplicar el predicado residual.
La intersección de índices es un mecanismo de consulta importante en el que se utilizan varios índices juntos para procesar de forma más eficiente una restricción compleja. En lugar de utilizar un único índice, se combinan los rangos de índices de varios índices para obtener un número mucho menor de registros a los que se puede aplicar cualquier predicado residual. ESE facilita esta tarea al proporcionar una operación IntersectIndexes. Esta operación acepta una serie de rangos de índices de índices de la misma tabla y devuelve una tabla temporal de claves primarias que se pueden utilizar para navegar a los registros de la tabla base que satisfacen todos los predicados de índice.
Una unión es una operación común en un diseño de tabla normalizada, donde los datos relacionados lógicamente se vuelven a reunir para su uso en una aplicación. Las uniones pueden ser operaciones costosas porque pueden ser necesarios muchos accesos a los datos para traer los datos relacionados a la memoria. Este esfuerzo se puede optimizar en algunos casos definiendo una única tabla base que contenga datos para dos o más tablas lógicas. El conjunto de columnas de la tabla base es la unión de los conjuntos de columnas de estas tablas lógicas. Las columnas etiquetadas hacen esto posible debido a su buen manejo de datos de valores múltiples y dispersos. Dado que los datos relacionados se almacenan juntos en el mismo registro, se accede a ellos juntos, minimizando así la cantidad de accesos al disco para realizar la unión. Este proceso se puede extender a una gran cantidad de tablas lógicas, ya que ESE puede admitir hasta 64.993 columnas etiquetadas. Dado que los índices se pueden definir sobre columnas de valores múltiples, aún es posible indexar tablas "interiores". Sin embargo, existen algunas limitaciones y las aplicaciones deben considerar la unión previa con cuidado antes de emplear esta técnica.
La función de registro y recuperación de ESE garantiza la integridad y la coherencia de los datos en caso de que se produzca un fallo del sistema. El registro es el proceso de registrar de forma redundante las operaciones de actualización de la base de datos en un archivo de registro. La estructura del archivo de registro es muy sólida frente a los fallos del sistema. La recuperación es el proceso de utilizar este registro para restaurar las bases de datos a un estado coherente tras un fallo del sistema.
Las operaciones de transacción se registran y el registro se vacía en el disco durante cada confirmación en el nivel de transacción 0. Esto permite que el proceso de recuperación rehaga las actualizaciones realizadas por las transacciones que se confirmaron en el nivel de transacción 0 y deshaga los cambios realizados por las transacciones que no se confirmaron en el nivel de transacción 0. Este tipo de esquema de recuperación se conoce a menudo como un esquema de recuperación de "roll-forward/roll-backward". Los registros se pueden conservar hasta que los datos se copien de forma segura mediante un proceso de copia de seguridad que se describe a continuación, o se pueden reutilizar los registros de forma circular tan pronto como ya no sean necesarios para la recuperación de un fallo del sistema. El registro circular minimiza la cantidad de espacio en disco necesario para el registro, pero tiene implicaciones en la capacidad de recrear un estado de datos en caso de una falla del medio.
El registro y la recuperación también desempeñan un papel en la protección de los datos ante fallos de los medios. ESE admite copias de seguridad en línea, en las que se copian una o más bases de datos, junto con los archivos de registro, de una manera que no afecta a las operaciones de la base de datos. Las bases de datos pueden seguir consultándose y actualizándose mientras se realiza la copia de seguridad. La copia de seguridad se denomina "copia de seguridad difusa" porque el proceso de recuperación debe ejecutarse como parte de la restauración de la copia de seguridad para restaurar un conjunto coherente de bases de datos. Se admiten copias de seguridad en streaming y en instantáneas.
La copia de seguridad en tiempo real es un método de copia de seguridad en el que se realizan copias de todos los archivos de base de datos deseados y los archivos de registro necesarios durante el proceso de copia de seguridad. Las copias de archivos se pueden guardar directamente en cinta o se pueden realizar en cualquier otro dispositivo de almacenamiento. No se requiere la suspensión de ningún tipo de actividad con las copias de seguridad en tiempo real. Tanto la base de datos como los archivos de registro se suman para garantizar que no existan daños en los datos dentro del conjunto de datos durante el proceso de copia de seguridad. Las copias de seguridad en tiempo real también pueden ser copias de seguridad incrementales. Las copias de seguridad incrementales son aquellas en las que solo se copian los archivos de registro y que se pueden restaurar junto con una copia de seguridad completa anterior para que todas las bases de datos vuelvan a un estado reciente.
Las copias de seguridad con instantáneas son un nuevo método de copia de seguridad de alta velocidad. Las copias de seguridad con instantáneas son mucho más rápidas porque la copia se realiza virtualmente después de un breve período de inactividad de una aplicación. A medida que se realizan actualizaciones posteriores a los datos, se materializa la copia virtual. En algunos casos, la compatibilidad del hardware con las copias de seguridad con instantáneas significa que no es necesario guardar las copias virtuales. Las copias de seguridad con instantáneas son siempre copias de seguridad completas.
La restauración se puede utilizar para aplicar una única copia de seguridad o para aplicar una combinación de una única copia de seguridad completa con una o más copias de seguridad incrementales. Además, también se pueden reproducir los archivos de registro existentes para recrear un conjunto de datos completo hasta la última transacción registrada como comprometida en el nivel de transacción 0. La restauración de una copia de seguridad se puede realizar en cualquier sistema capaz de soportar la aplicación original. No es necesario que sea la misma máquina, ni siquiera la misma configuración de máquina. La ubicación de los archivos se puede cambiar como parte del proceso de restauración.
Cuando se crea una base de datos de ESENT, el tamaño del sector del disco físico se almacena con la base de datos. Se espera que el tamaño del sector físico se mantenga constante entre sesiones; de lo contrario, se informa un error. Cuando se clona o restaura una unidad física desde una imagen de unidad a una unidad que utiliza un tamaño de sector físico diferente (unidades de formato avanzado ), ESENT informará errores. [4]
Este es un problema conocido y Microsoft tiene correcciones urgentes disponibles. Para Windows Vista o Windows Server 2008, consulte KB2470478. [5] Para Windows 7 o Windows Server 2008 R2, consulte KB982018. [6]
JET Blue fue desarrollado originalmente por Microsoft como una posible actualización para el motor de base de datos JET Red en Microsoft Access , pero nunca se utilizó en esta función. En cambio, pasó a ser utilizado por Exchange Server, Active Directory, File Replication Service (FRS), Security Configuration Editor, Certificate Services, Windows Internet Name Service (WINS) y una serie de otros servicios, aplicaciones y componentes de Windows de Microsoft. [7] Durante años, fue una API privada utilizada únicamente por Microsoft, pero desde entonces se ha convertido en una API publicada que cualquiera puede usar.
El trabajo en Data Access Engine (DAE) comenzó en marzo de 1989 cuando Allen Reiter se unió a Microsoft. Durante el año siguiente, un equipo de cuatro desarrolladores trabajó para Allen para completar en gran medida el ISAM. Microsoft ya tenía el BC7 ISAM (JET Red), pero comenzó el esfuerzo de Data Access Engine (DAE) para construir un motor de base de datos más robusto como una entrada en el entonces nuevo reino de la arquitectura cliente-servidor. En la primavera de 1990, los equipos BC7 ISAM y DAE se unieron para convertirse en el esfuerzo Joint Engine Technology (JET); responsable de producir dos motores, uno v1 ( JET Red ) y otro v2 (JET Blue) que se ajustarían a la misma especificación API (JET API). DAE se convirtió en JET Blue por el color de la bandera de Israel. BC7 ISAM se convirtió en JET Red por el color de la bandera de Rusia. Si bien JET Blue y JET Red se escribieron según la misma especificación API, no compartían ningún código ISAM. Ambos admitían un procesador de consultas común, QJET, que más tarde, junto con el BC7 ISAM, se convirtió en sinónimo de JET Red.
JET Blue se lanzó por primera vez en 1994 como un ISAM para WINS, DHCP y los servicios RPL , ahora obsoletos, en Windows NT 3.5. Se lanzó nuevamente como motor de almacenamiento para Microsoft Exchange en 1996. Otros servicios de Windows eligieron JET Blue como su tecnología de almacenamiento y, en 2000, todas las versiones de Windows comenzaron a distribuirse con JET Blue. JET Blue fue utilizado por Active Directory y se convirtió en parte de un conjunto especial de código de Windows llamado Trusted Computing Base (TCB). La cantidad de aplicaciones de Microsoft que utilizan JET Blue continúa creciendo y la API de JET Blue se publicó en 2005 para facilitar su uso por parte de una cantidad cada vez mayor de aplicaciones y servicios, tanto dentro como fuera de Windows.
Una entrada del blog web de Microsoft Exchange [8] afirmó que entre los desarrolladores que contribuyeron a JET Blue se encuentran Cheen Liao, Stephen Hecht, Matthew Bellew, Ian Jose, Edward "Eddie" Gilbert, Kenneth Kin Lum, Balasubramanian Sriram, Jonathan Liem, Andrew Goodsell, Laurion Burchall, Andrei Marinescu, Adam Foxman, Ivan Trindev, Spencer Low y Brett Shirley.
En enero de 2021, Microsoft publicó el código fuente abierto de ESE. [9] Se publicó en GitHub con la licencia MIT permisiva .
Si bien comparten un linaje común, existen grandes diferencias entre JET Red y ESE.