Enabling Journaling and Creating Journal Files

From InterBase
Jump to: navigation, search

Go Up to Journaling and Disaster Recovery


To create a journal file and activate journaling, use the following DDL syntax:

CREATE JOURNAL [<journal-file-specification>] [LENGTH <number-of-pages> [PAGES]]
[CHECKPOINT LENGTH <number-of-pages> [PAGES]]
[CHECKPOINT INTERVAL <number-of-seconds> [SECONDS]]
[PAGE SIZE <number-of-bytes> [BYTES]]
[PAGE CACHE <number-of-buffers> [BUFFERS]]
[[NO] TIMESTAMP NAME]
[[NO] PREALLOCATE <number-of-pages> [PAGES]];
Note: InterBase currently requires that all journal files be stored in the same directory.

All CREATE JOURNAL clauses are optional. Table 1.1 describes the function of each option and its default value.

CREATE JOURNAL Options
Option Description Default values

<Journal_file_spec>

Specifies a quoted string containing the full path and base file name of the journal file. The base journal file name is used as a template for the actual journal file names as they are created.

The full database path and file name

LENGTH

This clause specifies the number of pages that can be written to the journal file before rolling over to a new journal file. For tips on calculating this number, see Tips for Determining Journal Rollover Frequency.

Maximum: 2GB or 4000 pages

CHECKPOINT LENGTH

This clause specifies the number of pages that can be written to the journal file before checkpoint occurs. For tips on calculating checkpoint length, see Tips for Determining Journal Rollover Frequency.

500

CHECKPOINT INTERVAL

Determines the number of seconds between database checkpoints. The checkpoint interval determines how long it will take to recover after a server crash.

Note: If both CHECKPOINT LENGTH and CHECKPOINT INTERVAL are specified, whichever event occurs first will initiate a database checkpoint. For tips on calculating the checkpoint interval, see Tips for Determining Checkpoint Intervals.

0

PAGE SIZE

Determines the size of a journal page in bytes. A journal page size must be at least twice the size of a database page size. If a journal page size of less is specified, it will be rounded up to twice the database page size and a warning will be returned. The journal page size need not be a power of 2.

Twice the database page size

PAGE CACHE

Determines the number of journal pages that are cached to memory. This number must be large enough to provide buffers for worker threads to write to when the cache writer is writing other buffers. If the number is too small, the worker threads wait and performance suffers.

100 buffers

[NO] TIMESTAMP NAME

Determines whether or not to append the file creation timestamp to the base journal file name.

If used, the base journal file name will be appended with a timestamp in the following format:

YYYY_MM_DDTHH_MM_SSZ.sequence_number.journal

Enabled

[NO] PREALLOCATE

Specifies the amount of disk space preallocated for journal files. For more information about using the preallocate clause, see About Preallocating Journal Space.

No default value.

The CREATE JOURNAL statement causes all subsequent write operations on a database to be done asynchronously. The journal file I/O is always synchronous and cannot be altered. All transaction changes are safely recorded on durable storage before the transaction is committed. This guarantees the ACID properties of a transaction (the database industry standards for Atomicity, Consistency, Isolation, and Durability).

Using asynchronous I/O for database writes allows the operating system to optimize file I/O, such as by writing consecutive pages together, or by using scatter/gather techniques that write consecutive pages in discontiguous page buffers. Journal file I/O is performed using InterBase careful write strategy. This implies that database pages can be written back to the database in any order after their changes have been journaled.

During a database checkpoint, any database page writes that were buffered asynchronously are flushed to disc before checkpoint completion is signaled. You can re-enable synchronous writes for the database, which removes the requirement for a flush operation before a database checkpoint can be considered complete. Doing so, however, can degrade performance.

Topics