|
|
|
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:
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.
Let:
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
Then:
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
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.
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.
