¿Qué es el formato de archivo DB-JOURNAL?
Los archivos con la extensión .db-journal contienen las imágenes de página necesarias para la recuperación de una base de datos SQLite en caso de fallo en una transacción. Estos son archivos temporales creados por SQLite en el mismo directorio donde se almacena la base de datos. No deberían ser visibles una vez concluida la transacción, ya que SQLite los elimina automáticamente al ejecutar COMMIT o ROLLBACK.
Gracias a los archivos de diario de reversión de transacciones con la extensión .db-journal, es posible garantizar la atomicidad de las transacciones en la base de datos. Una aplicación que opere con datos de la base de datos y se bloquee a mitad de una transacción no dejará operaciones incompletas; estas se revertirán al estado anterior al inicio de la transacción. Un archivo .db-journal está presente en el disco:
- durante la ejecución de una transacción de escritura (modo de diario DELETE, el predeterminado de SQLite),
- cuando una transacción fue interrumpida por un fallo - hasta que la siguiente conexión abra la base de datos,
- cuando la base de datos está en modo de bloqueo exclusivo (
PRAGMA locking_mode=EXCLUSIVE) - hasta que se desactive.
SQLite puede utilizar varios archivos auxiliares temporales diferentes para garantizar la coherencia y seguridad de las operaciones de la base de datos. .db-journal es el diario de reversión clásico; .db-wal y .db-shm cumplen la función equivalente en el modo más reciente WAL (Write-Ahead Log).
Nomenclatura del archivo .db-journal
El archivo de diario se nombra añadiendo -journal al nombre completo del archivo de la base de datos. Por ejemplo, si la base de datos se guarda como baza.db, el archivo temporal se llamará baza.db-journal y se almacenará en el mismo directorio. Los archivos temporales no suelen ser visibles para los usuarios. En caso de un fallo o corte de energía, el diario permanece en el directorio hasta la próxima vez que se abra la base de datos; SQLite detecta entonces el «hot journal» (diario activo), reproduce las imágenes de página guardadas para restaurar el estado previo a la transacción y elimina el diario automáticamente.
Nunca debe eliminar un archivo .db-journal mientras haya una transacción de escritura en curso, ya que al hacerlo corromperá la base de datos. Un .db-journal persistente después de un cierre limpio casi siempre indica un fallo previo; SQLite gestiona la recuperación de forma segura en la siguiente apertura. En el modo WAL (PRAGMA journal_mode=WAL), introducido en SQLite 3.7.0 (julio de 2010), el archivo .db-journal no se utiliza en absoluto - un archivo .db-wal asume su función. La mayoría de las bases de datos de aplicaciones modernas han cambiado al modo WAL para mejorar la concurrencia de lectura.
Seguridad y protección
RIESGO: LOWNo ejecutable; datos binarios de recuperación ante fallos. Eliminar un -journal mientras se escribe en la base de datos corromperá la misma - este es el principal riesgo operativo. Los diarios sobrantes de fallos son seguros de mantener hasta que SQLite los recupere automáticamente. Un -journal puede contener datos confidenciales no confirmados de la transacción interrumpida (escrituras parciales de mensajes, credenciales, etc.); trátelo con la misma confidencialidad que la base de datos principal. No abra ni distribuya un -journal de forma aislada sin la base de datos principal.
Detalles del formato
en pocas palabrasProgramas que abren archivos DB-JOURNAL
Detalles técnicos
especificación profunda| Tipo de formato | Diario de reversión de transacciones temporal binario (archivo auxiliar de SQLite) |
| Bytes mágicos | Encabezado de 8 bytes: 0xD9 0xD5 0x05 0xF9 0x20 0xA1 0x63 0xD7 (diario activo/persistente) |
| Orden de bytes | Big-endian (campos del encabezado del diario almacenados en orden de bytes de red) |
| Tamaño del encabezado del diario | 28 bytes (campos de recuento de páginas, nonce aleatorio, tamaño de sector, tamaño de página) |
| Codificación | Binario - almacena imágenes literales de las páginas de la base de datos SQLite 3 copiadas antes de la modificación |
| Suma de comprobación por página | Dos enteros de 32 bits calculados a partir del nonce y los datos de la página; una discrepancia indica un diario obsoleto o incompleto |
| Tamaño de archivo típico | De 0 bytes a cientos de MB, dependiendo de cuántas páginas haya afectado la transacción abortada |
| Modo de diario | Utilizado solo en el modo de diario DELETE (predeterminado de SQLite); no se crea en modo WAL |
| Convención de nomenclatura | Ruta de la base de datos principal con -journal añadido (ej., mydata.db → mydata.db-journal) |
| Mecanismo de recuperación | SQLite detecta un diario activo al abrir la conexión, reproduce las imágenes de página para restaurar el estado previo a la transacción y luego elimina el diario |
| Sustitución por WAL | El modo WAL (.db-wal + .db-shm), introducido en SQLite 3.7.0 (julio de 2010), es preferible para cargas de trabajo concurrentes y no utiliza el archivo .db-journal |
| Lanzado | SQLite 1.0, 2000 (rollback journal is the original journaling mechanism) |
| Última versión | SQLite 3.x current - format unchanged since early SQLite 3; superseded in practice by WAL (-wal) |
| Estándar abierto | Sí · libre de regalías |
| Especificación | www.sqlite.org |
Conversiones de DB-JOURNAL
Preguntas y respuestas de la comunidad
preguntado por usuariosAún no hay preguntas; sea el primero en preguntar sobre los archivos DB-JOURNAL.