Archivos extensibles del motor de almacenamiento
Se aplica a: Windows | Windows Server
Archivos extensibles del motor de almacenamiento
El motor de almacenamiento extensible usa los siguientes tipos de archivos:
Esta tabla contiene información general sobre los nombres de archivo de datos administrados por ESE. Para Windows Vista y versiones posteriores, la configuración de JET_paramLegacyNames afecta a los nombres de archivo que se usan.
| Etiqueta | Value |
|---|---|
Archivos de registro de transacciones
Los archivos de registro de transacciones contienen operaciones en archivos de base de datos. Contienen suficiente información para llevar una base de datos a un estado coherente lógicamente después de una finalización inesperada del proceso o apagado del sistema.
Los nombres de los archivos de registro dependen de un nombre base de tres letras, que se puede establecer con JET_paramBaseName. En los ejemplos siguientes se usa un nombre base de "edb", porque ese es el nombre base predeterminado. La extensión de los archivos de registro de transacciones será .log o .jtx en función de si el JET_bitESE98FileNames se establece en el parámetro JET_paramLegacyFileNames. Para obtener más información, vea Extensible Storage Engine System Parameters( Parámetros del sistema del motor de almacenamiento extensible).
Los archivos de registro de transacciones se denominan <><base generation-number.log>, empezando por 1. El número de generación de registros está en formato hexadecimal. Por ejemplo, edb00001.log es el primer registro y edb000ff.log es el registro 255. Los archivos de registro tienen cinco dígitos hexadecimales en el nombre del archivo de registro, hasta el archivo de registro 1048576, momento en el que los archivos de registro comienzan a denominarse en un formato 11.3 (por ejemplo, edb00100000.log). <base.log> siempre es el archivo de registro que se está usando actualmente. Si el motor de base de datos no está activo, la generación de edb.log se puede identificar mediante el siguiente comando: esentutl.exe -ml edb.log.
Aunque los archivos de registro de transacciones tienen . La extensión LOG normalmente asociada a archivos de texto, los archivos de registro de transacciones están en formato binario y nunca los debe editar un usuario. Las operaciones de base de datos se escriben primero en el registro. Los datos se pueden escribir en el archivo de base de datos más adelante; posiblemente inmediatamente, potencialmente mucho más tarde. En caso de terminación inesperada del proceso o del sistema, las operaciones siguen presentes en los archivos de registro y se pueden revertir las transacciones incompletas. El acto de reproducir archivos de registro de transacciones se denomina recuperación temporal y se realiza automáticamente cuando se llama a JetInit o JetInit2 . La recuperación temporal también se puede realizar manualmente con la opción "-r" del programa Esentutl.exe. El acto de reproducir archivos de registro de transacciones en una base de datos que se restaura a partir de una copia de seguridad se denomina recuperación dura.
Los archivos de registro tienen un tamaño fijo, personalizable con JET_paramLogFileSize. Cuando se rellena el archivo de registro actual (es decir, edb.log), se cambia el nombre al <><número> de generación base.log y se necesita un nuevo archivo de registro de transacciones en el flujo de registro de transacciones.
Cada instancia de base de datos tiene una única secuencia de archivos de registro asociada. Windows XP introdujo JetCreateInstance, lo que permite usar varias secuencias de archivos de registro de transacciones mediante un único proceso. Sin embargo, no pueden existir varias secuencias de archivos de registro de transacciones en el mismo directorio.
Los archivos de registro de transacciones casi nunca se deben manipular, cambiar el nombre, mover o eliminar manualmente porque los datos dañados pueden dar lugar.
El motor de base de datos eliminará los archivos de registro de transacciones durante una copia de seguridad completa (consulte JetBackup, JetTruncateLog, JetTruncateLogInstance) o durante las operaciones normales, si está habilitado el registro circular.
Una vez rellenado un archivo de registro de transacciones, el motor de base de datos debe crear un nuevo archivo de registro. El registro circular es un medio por el que el motor de base de datos puede limpiar automáticamente los archivos de registro cuando ya no son necesarios para la recuperación de bloqueos. Este proceso es una alternativa a la eliminación de archivos de registro como producto de realizar una copia de seguridad. El registro circular se puede controlar con el parámetro del sistema JET_paramCircularLog . Los archivos de registro de transacciones no se deben eliminar mediante ningún otro método.
Archivos de registro de transacciones temporales
Cuando edb.log se llena, ESE debe crear un nuevo archivo. El nuevo archivo de transacción de registro se conoce como un archivo de registro de transacciones temporal antes de su uso por ESE.
Mientras se crea un nuevo archivo de registro y su tamaño extendido, se denominará <tmp.log base>. La creación de un nuevo archivo puede ser una operación potencialmente costosa, por lo que ESE creará el siguiente archivo de registro de forma proactiva como tarea en segundo plano.
Dado que el archivo de registro de transacciones temporal se crea en previsión de la necesidad de un nuevo archivo de registro de transacciones, no contiene ninguna información útil.
Archivos de registro de transacciones reservados
Los archivos de registro de transacciones reservados se crean cuando el motor comienza a permitir que las operaciones importantes se registren para obtener un apagado limpio.
Windows Vista: En Windows Vista y versiones posteriores, los archivos de registro de transacciones reservadas se denominan <RESXXXXX.jrs base>.
Windows Server 2003: En Windows Server 2003 y versiones anteriores, los archivos de registro de transacciones reservadas se denominan res1.log y res2.log.
Cuando el motor de base de datos se queda sin espacio en disco, no puede crear un nuevo archivo de registro. Lo más seguro que debe hacer es cerrarse limpiamente, pero algunas operaciones (como las operaciones de reversión) deben registrarse. La mayoría de las operaciones de base de datos producirán un error durante esta fase.
Dado que los archivos de registro de transacciones reservados se crean en previsión de la necesidad de archivos de registro de transacciones en un escenario fuera del disco, no contienen ninguna información útil.
punto de comprobación, archivos
El archivo de punto de comprobación almacena el punto de control para una secuencia de archivo de registro de transacciones determinada. El archivo de punto de comprobación se denomina <base.chk> o <base.jcp>, dependiendo de si el JET_bitESE98FileNames se establece en el parámetro JET_paramLegacyFileNames y su ubicación se da por JET_paramSystemPath.
Las operaciones de base de datos se escriben primero en los archivos de registro y, a continuación, se almacenan en caché en la memoria. En algún momento posterior, las operaciones se escriben en el archivo de base de datos, pero por motivos de rendimiento, el orden en el que se escriben las operaciones en el archivo de base de datos podría no coincidir con el orden en que se registraron originalmente. Las operaciones escritas en el archivo de registro de transacciones estarán en uno de los dos estados:
Escrito en el archivo de registro de transacciones y en el archivo de base de datos.
Escrito en el archivo de registro de transacciones y aún no se ha escrito en el archivo de base de datos.
Muchas operaciones de base de datos se pueden almacenar en un único archivo de registro de transacciones. Un archivo de registro determinado puede constar de los siguientes elementos:
Todas las operaciones escritas en el archivo de base de datos.
Sin operaciones escritas en el archivo de base de datos
Combinación de operaciones escritas en el archivo de base de datos y operaciones que aún no se han escrito en el archivo de base de datos.
El punto de control hace referencia al momento dado en el flujo del registro de transacciones donde todas las operaciones anteriores al punto de control se han escrito en el archivo de base de datos. No hay ninguna garantía sobre las operaciones que se producen después del punto de control; algunos podrían estar en memoria y algunos podrían escribirse en la base de datos.
Puesto que todas las operaciones de los archivos de registro anteriores al punto de control se representan en el archivo de base de datos, solo los archivos de registro de transacciones después de que el punto de control sean necesarios para la recuperación temporal para que una base de datos determinada entre en un estado limpio.
Archivos de la base de datos
El archivo de base de datos contiene el esquema de todas las tablas de la base de datos, los registros de todas las tablas de la base de datos y los índices de las tablas. Su ubicación se asigna mediante JetCreateDatabase, JetCreateDatabase2, JetAttachDatabase o JetAttachDatabase2.
Una base de datos se cierra limpiamente solo después de una llamada correcta a JetTerm o JetTerm2.
El programa Esentutl.exe puede detectar si una base de datos se cierra limpiamente con la opción "-mh". Por ejemplo, "esentutl.exe -mh sample.edb" leerá el encabezado de base de datos de una base de datos denominada sample.edb e imprimirá el estado de sample.edb. Puede imprimir "State: Clean Shutdown" o "State: Dirty Shutdown".
Una base de datos que no se ha cerrado limpiamente está en un estado de apagado sucio. Antes de Windows XP, este estado se denominaba incoherente. Una base de datos desfasada (incoherente) se puede llevar a un estado limpio con recuperación temporal. Una base de datos dañada no es la misma que una base de datos desfasada ("incoherente").
Una base de datos dañada hace referencia a daños físicos o lógicos y no se puede corregir con recuperación temporal. Los daños físicos pueden ser volteos de bits, que a menudo detectarán las sumas de comprobación en las páginas de la base de datos. Una suma de comprobación con errores en un archivo de base de datos se manifiesta como un error de JET_errReadVerifyFailure.
Solo se pueden mover o cambiar el nombre de las bases de datos de forma limpia. Si una base de datos no se cerró limpiamente, no se puede mover ni cambiar el nombre automáticamente de forma segura.
Varias bases de datos se pueden asociar a una única secuencia de archivos de registro de transacciones.
Bases de datos temporales
La base de datos temporal se usa como almacén de respaldo para tentables y también se usa al crear índices.
El nombre y la ubicación se configuran con JET_paramTempPath.
Los tentables se crean con JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3, JetOpenTemporaryTable. También se crean mediante algunas llamadas API y se usan para devolver información de esquema (como JetGetIndexInfo).
Vaciar archivos de mapa
A partir de la actualización de aniversario de Windows 10 (cliente) y Windows Server 2016 (servidor), ESE agregó un nivel adicional de protección contra escrituras perdidas (o vaciados perdidos) 1, lo que le permite detectar estos eventos entre procesos de re-inicialización2. Esta característica requiere que los metadatos se conserven en un archivo independiente denominado "flush map".
Se crea un archivo de mapa de vaciado para cada archivo de base de datos y se encuentra en el mismo directorio. El archivo se denomina de forma similar al archivo de base de datos, pero con una extensión diferente. Por ejemplo, si la aplicación cliente crea una base de datos con la ruta de acceso completa C:\MyDirectory\MyDabatase.edb, su archivo de mapa de vaciado correspondiente es C:\MyDirectory\MyDabatase.jfm.
Esta mejora presenta dos requisitos para el nombre de los archivos de base de datos:
Dos bases de datos del mismo directorio no deben tener el mismo nombre de archivo con extensiones diferentes. Por ejemplo: C:\MyDirectory\MyDabatase.db1 y C:\MyDirectory\MyDabatase.db2.
2. Una base de datos no debe tener una extensión .jfm.
Al copiar o mover manualmente un archivo de base de datos, su archivo de mapa de vaciado correspondiente también debe copiarse o moverse al mismo directorio de destino. Si un archivo de mapa de vaciado no está presente en el momento de un nuevo archivo adjunto de base de datos (a través de JetAttachDatabase, se creará uno nuevo y se volverá a rellenar a petición a medida que las páginas se leen desde la base de datos. ESE controla la combinación de la base de datos y los archivos de mapa de vaciado y obliga a eliminar y volver a crear desde cero el mapa de vaciado no coincidente.
El tamaño de un archivo de mapa de vaciado es directamente proporcional a su archivo de base de datos asociado y es aproximadamente igual a (todos los tamaños en bytes, el resultado debe redondearse hasta el siguiente múltiplo de 8192):
8,192 + ((<database file size> / <database page size>) / 4)
Por ejemplo: para una base de datos de 1,5 GB con un tamaño de página de 32 KB, el tamaño aproximado del mapa de vaciado es de 24 576 bytes (o 24 KB).
El archivo de mapa de vaciado debe actualizarse a medida que se vacían las páginas de la base de datos. Si el registro transaccional está habilitado (por ejemplo, JET_paramRecovery establecido en "on", el valor predeterminado), la actualización del mapa de vaciado se realiza cuando la aplicación cliente realiza modificaciones en la base de datos. En promedio, todo el mapa de vaciado se escribe en los medios no volátiles una vez por cada 20 % de JET_paramCheckpointDepthMax -worth (en bytes) de los registros transaccionales generados. El número de operaciones de escritura depende de cómo se distribuyan en toda la base de datos las modificaciones. Pero es como máximo, aproximadamente (todos los tamaños en bytes):
<flush map file size> / JET_paramMaxCoalesceWriteSize
Si el registro transaccional está deshabilitado (por ejemplo, JET_paramRecovery establecido en "off"), la asignación de vaciado solo se actualiza una vez cuando la base de datos se desasocia explícitamente (a través de JetDetachDatabase o desasociada implícitamente limpiamente finalizando su instancia de ESE asociada (a través de cualquiera de las funciones JetTerm , siempre y cuando no se pase JET_bitTermDirty ).
1 Una escritura perdida (o vaciado perdido) se define como una operación de escritura que devuelve correctamente desde el sistema operativo al motor de base de datos ESE, pero los datos reales nunca se conservan en el archivo de base de datos en los medios no volátiles. Normalmente se debe a un funcionamiento incorrecto o a una pila de almacenamiento mal configurada (software o hardware). Las aplicaciones cliente pueden recibir un error de JET_errReadLostFlushVerifyFailure de las funciones ESE que requieren leer datos de la base de datos si los datos se encuentran en una región que ha sufrido un evento de escritura perdido.
2 La capacidad de detectar escrituras perdidas dentro de la duración de un proceso ha estado presente desde Windows 8 (cliente) y Windows Server 2012 (servidor).