ToC path:

Log Parameters

As explained in the section “Persistent Media I/O”, eXtremeDB maintains a database log file together with the data file(s) for persistent databases to allow for recovery in the case of a system crash. The manner in which database updates are written to the log file is determined by the value of the db_log_type element of mco_db_params_t and the Transaction Commit Policy and other settings defined in the mco_log_params_t structure whose elements are as follows:

default_commit_policy The commit policy; defined as one of the following values: MCO_COMMIT_SYNC_FLUSH, MCO_COMMIT_BUFFERED, MCO_COMMIT_DELAYED, or MCO_COMMIT_NO_SYNC. (See the Transaction Commit Policy page for an explanation of the meaning of these transaction policies).

redo_log_limit Threshold value for the REDO transaction log. After the transaction log file size reaches this value the database file is flushed to the persistent storage (the process is often referred to as a checkpoint) and the log file is truncated. Note that the log file cannot be truncated until all transactions are committed. Therefore, the redo_log_limit cannot be treated as maximum size of the transaction log, it can exceed this value. The default value is 16M.

delayed_commit_threshold This parameter controls the MCO_COMMIT_DELAYED transaction policy. In this mode, all modified pages are pinned in the page pool and don’t get written to the persistent storage upon transaction commit. When the total size of all pinned pages reaches this threshold, or when the number of delayed commits exceeds the max_delayed_transactions value parameter, or when the max_commit_delay timeout has been reached (see below) all delayed transactions are committed to the persistent storage at once. The default value is 1/3 of the cache size.

max_delayed_transactions This parameter controls the MCO_COMMIT_DELAYED transaction policy (see delayed_commit_threshold above). By default, the number of delayed transactions is not limited (0).

max_commit_delay This parameter controls the MCO_COMMIT_DELAYED transaction policy (see delayed_commit_threshold and max_delayed_transactions above). This is the number of application-defined clock cycles (milliseconds by default) to wait before all delayed transactions are committed to the persistent storage at once.

default_commit_policy	The commit policy; defined as one of the following values: `MCO_COMMIT_SYNC_FLUSH, MCO_COMMIT_BUFFERED, MCO_COMMIT_DELAYED`, or `MCO_COMMIT_NO_SYNC`. (See the Transaction Commit Policy page for an explanation of the meaning of these transaction policies).
redo_log_limit	Threshold value for the `REDO` transaction log. After the transaction log file size reaches this value the database file is flushed to the persistent storage (the process is often referred to as a checkpoint) and the log file is truncated. Note that the log file cannot be truncated until all transactions are committed. Therefore, the `redo_log_limit` cannot be treated as maximum size of the transaction log, it can exceed this value. The default value is 16M.
delayed_commit_threshold	This parameter controls the `MCO_COMMIT_DELAYED` transaction policy. In this mode, all modified pages are pinned in the page pool and don’t get written to the persistent storage upon transaction commit. When the total size of all pinned pages reaches this threshold, or when the number of delayed commits exceeds the `max_delayed_transactions` value parameter, or when the `max_commit_delay` timeout has been reached (see below) all delayed transactions are committed to the persistent storage at once. The default value is 1/3 of the cache size.
max_delayed_transactions	This parameter controls the `MCO_COMMIT_DELAYED` transaction policy (see `delayed_commit_threshold` above). By default, the number of delayed transactions is not limited (0).
max_commit_delay	This parameter controls the MCO_COMMIT_DELAYED transaction policy (see `delayed_commit_threshold` and `max_delayed_transactions` above). This is the number of application-defined clock cycles (milliseconds by default) to wait before all delayed transactions are committed to the persistent storage at once.