Export (0) Print
Expand All

Extensible Storage Engine Files

Windows

The Extensible Storage Engine uses the following types of files:

This table contains an overview of the data file names that are managed by ESE. For Windows Vista and later, the JET_paramLegacyNames setting impacts the file names that are used.



JET_paramLegacyNames setting

Windows Server 2003 and earlier

N/A

Windows Vista and later

None

Windows Vista and later

JET_bitESE98FileNames

Current Log

<inst>.log

<inst>.jtx

<inst>.log

Pre-Init Log

<inst>tmp.log

<inst>tmp.jtx

<inst>tmp.log

Rotated Logs

<inst>XXXXX.log

<inst>XXXXX.jtx after FFFFF switch to <inst>XXXXXXXX.jtx

<inst>XXXXX.log after FFFFF switch to <inst>XXXXXXXX.log.

Checkpoint Files

<inst>.chk

<inst>.jcp

<inst>.jcp

Temporary Databases

<temp db file name> Default: tmp.edb

<temp db file name> Default: tmp.edb

<temp db file name> Default: tmp.edb

Reserved Transaction Log Files

res1.log & res2.log

<inst>RESXXXXX.jrs

<inst>RESXXXXX.jrs

Database Files

<db file name>

<db file name>

<db file name>

Transaction Log Files

Transaction log files contain operations on database files. They contain enough information to bring a database to a logically consistent state after an unexpected process termination or system shutdown.

The names of the log files are dependent on a three-letter base name, which can be set with JET_paramBaseName. The examples below use a base name of "edb", because that is the default base name. The extension for the transaction log files will be either .log or .jtx depending upon whether the JET_bitESE98FileNames is set in the JET_paramLegacyFileNames parameter. For more information, see Extensible Storage Engine System Parameters.

Transaction log files are named <base><generation-number>.log, beginning with 1. The log generation number is in hexadecimal format. For example, edb00001.log is the first log, and edb000ff.log is the 255th log. The log files have five hexadecimal digits in the log file name, until the 1048576th log file, at which point the log files start being named in an 11.3 format (for example, edb00100000.log). <base>.log is always the log file that is currently being used. If the database engine is not active, the generation of edb.log can be identified using the following command: esentutl.exe -ml edb.log.

Although transaction log files have the .LOG extension commonly associated with text files, transaction log files are in a binary format and should never be edited by a user.Database operations are written to the log first. The data can be written to the database file later; possibly immediately, potentially much later. In the event of unexpected process or system termination, the operations are still present in the log files, and incomplete transactions can be rolled back. The act of replaying transaction log files is called soft recovery, and it is done automatically when JetInit or JetInit2 is called. Soft recovery can also be performed manually with the "-r" option of the Esentutl.exe program. The act of replaying transaction log files on a database that is restored from a backup is called hard recovery.

Log files are of a fixed size, customizable with JET_paramLogFileSize. When the current log file (that is, edb.log) gets filled, it gets renamed to <base><generation-number>.log, and a new transaction log file is needed in the transaction log stream.

Each database instance has a single log file sequence associated with it. Windows XP introduced JetCreateInstance, allowing multiple transaction log file sequences to be used by a single process. Multiple transaction log file sequences cannot exist in the same directory, however.

Transaction log files should almost never be manually manipulated, renamed, moved, or deleted because data corruption can result.

Transaction log files will be deleted by the database engine during a full backup (see JetBackup, JetTruncateLog, JetTruncateLogInstance), or during normal operations, if circular logging is enabled.

After a transaction log file is filled up, the database engine needs to create a new log file. Circular logging is a means by which log files can be automatically cleaned up by the database engine when they are no longer required for crash recovery. This process is an alternative to removing log files as a by-product of performing a backup. Circular logging can be controlled with the JET_paramCircularLog system parameter. Transaction log files should not be deleted using any other method.

Temporary Transaction Log Files

When edb.log fills up, ESE needs to create a new file. The new log transaction file is known as a temporary transaction log file prior to its use by ESE.

While a new log file is created and its size extended, it will be called <base>tmp.log. Creating a new file can be a potentially costly operation, so ESE will create the next log file proactively as a background task.

Because the temporary transaction log file is created in anticipation of need for a new transaction log file, it does not contain any useful information.

Reserved Transaction Log Files

The reserved transaction log files are created when the engine starts to allow important operations to be logged to get a clean shutdown.

Windows Vista:  In Windows Vista and later, the Reserved Transaction Log Files are named <base>RESXXXXX.jrs.

Windows Server 2003:  In Windows Server 2003 and earlier, The Reserved Transaction Log Files are named res1.log and res2.log.

When the database engine runs out of disk space it cannot create a new log file. The safest thing to do is to shut down cleanly, but some operations (such as rollback operations) must still be logged. Most database operations will fail during this stage.

Because the reserved transaction log files are created in anticipation of need for transaction log files in an out-of-disk scenario, they do not contain any useful information.

Checkpoint Files

The checkpoint file stores the checkpoint for a particular transaction log file sequence. The checkpoint file is named <base>.chk or <base>.jcp, depending upon whether the JET_bitESE98FileNames is set in the JET_paramLegacyFileNames parameter, and its location is given by JET_paramSystemPath.

Database operations are first written to the log files and then cached in memory. At some later point, the operations get written to the database file, but for performance reasons, the order in which operations are written to the database file might not match the order in which they were originally logged. Operations written to the transaction log file will be in one of two states:

  • Written to the transaction log file and the database file.

  • Written to the transaction log file and not yet written to the database file.

Many database operations can be stored in a single transaction log file. A given log file can consist of the following items:

  • All operations written to the database file.

  • No operations written to the database file

  • A mix of operations written to the database file and operations not yet written to the database file.

The checkpoint refers to the point in time in the transaction log stream where all operations prior to the checkpoint have been written to the database file. There is no guarantee about the operations that occur after the checkpoint; some might be in memory, and some might be written to the database.

Since all the operations in the log files prior to the checkpoint are represented in the database file, only the transaction log files after the checkpoint are needed for soft recovery to bring a particular database into a clean state.

Database Files

The database file contains the schema for all of the tables in the database, the records for all of the tables in the database, and the indexes over the tables. Its location is given using JetCreateDatabase, JetCreateDatabase2, JetAttachDatabase, or JetAttachDatabase2.

A database is cleanly shut down only after a successful call to JetTerm or JetTerm2.

The Esentutl.exe program can detect whether a database is shut down cleanly with the "-mh" option. For example, "esentutl.exe -mh sample.edb" will read the database header of a database named sample.edb, and print out the state of sample.edb. It may print out "State: Clean Shutdown" or "State: Dirty Shutdown".

A database that has not been cleanly shut down is in a dirty shutdown state. Prior to Windows XP, this state was called inconsistent. A dirty (inconsistent) database can be brought to a clean state with soft recovery. A corrupt database is not the same as a dirty ("inconsistent") database.

A corrupt database refers to a physical or logical corruption, and cannot be fixed with soft recovery. Physical corruptions can be bit flips, which will frequently be caught by the checksums on the database pages. A failed checksum in a database file manifests itself as a JET_errReadVerifyFailure error.

Only cleanly shut down databases can be safely moved around or renamed. If a database was not cleanly shut down, it cannot be automatically safely moved or renamed.

Multiple databases can be associated with a single transaction log file sequence.

Temporary Databases

The temporary database is used as a backing store for temptables and it is also used when creating indices.

The name and location is configured with JET_paramTempPath.

Temptables are created with JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3, JetOpenTemporaryTable. They are also created by some API calls and used to return schema information (such as JetGetIndexInfo).

Community Additions

ADD
Show:
© 2014 Microsoft