Product Documentation


Previous Topic

Next Topic

Number of Active Transaction Logs Unexpectedly Increases

The number of active transaction log files required to support FairCom DB operation is nominally normally 4. Each time the server creates a new log, it determines whether or not the oldest existing log can be deleted (or made inactive, if the KEEP_LOGS server configuration option is specified in the server configuration file). A number of conditions require the server to keep more than 4 active log files. It is important for the server administrator to detect cases in which the number of active logs increases significantly and to understand the cause and whether or not action is required.

When the number of log files is about to increase, the server logs the following message to CTSTATUS.FCS:

The number of active log files increased to <nlogs>

where <nlogs> is the new number of active logs.

The most important of the situations that require keeping the oldest transaction log active are:

  • Increasing CHECKPOINT_FLUSH to delay flushing of buffers associated with committed transactions:

When creating a new transaction log, FairCom DB determines the recoverability vulnerability due to unflushed buffers associated with committed transactions and keeps the required number of active logs. The following formula can be used to estimate the number of logs required to support unflushed buffer/cache pages based on server configuration settings.


CPF = CHECKPOINT_FLUSH value (defaults to 2)

CPL = number of checkpoints per log (typically 3 and no less than 3)

MNL = minimum number of logs to support unflushed pages


MNL = ((CPF + CPL - 1) / CPL) + 2, where integer division is used

For example:

CPF=2, CPL=3 => MNL = 3 (But the server enforces a minimum of 4)

CPF=7, CPL=3 => MNL = 5

CPF=9, CPL=3 => MNL = 5

CPF=10, CPL=3 => MNL = 6

  • A pending transaction that began several logs ago and still has not committed or aborted:

Unlike CHECKPOINT_FLUSH, which leads to a well-defined limited increase in the number of active transaction logs, a long uncommitted transaction can lead to an unlimited increase in transaction logs. For example, if a client begins a transaction and then sits idle while other clients execute transactions, the other clients’ transaction activity fills the transaction logs. When the server creates new logs it finds that the idle client’s transaction has not committed. The server must keep the log in which the idle client’s transaction begin is logged until that client aborts or commits its transaction. For this reason, it is important to monitor the number of active transaction logs. In the event of an unexpected long transaction, the ctadmn utility can be used to list connected clients and their transaction times and to terminate clients as needed.

  • Dynamic dumps:

A dynamic dump is similar to the case of a long pending transaction. The dynamic dump must keep all transaction logs from the dump start time to the dump end time in order to include in the dump stream file all transaction activity that occurred during the dump. If very large files are included in the dump, the dynamic dump can take a significant amount of time. Depending on the amount of transaction activity between the dump start and end times, the number of active logs that must be kept during a dynamic dump can be large.

FairCom DB logs to CTSTATUS.FCS an explanation as to the condition that triggered the increase. When the increase is caused by a pending transaction, the server attempts to identify the user ID and node name associated with the transaction.

Based on the cause of the increased number of active logs shown in CTSTATUS.FCS, the server administrator can take the appropriate action, if any. For example, a long pending transaction can be aborted using the ctadmn utility to terminate the client that began the transaction, or a dynamic dump can be terminated using ctadmn.