Log Holds by TimesTen Components or Operations

Several TimesTen components or operations can cause transaction log holds. A transaction log hold prevents log files, beyond a certain point, from being purged until they are no longer needed.

In standard circumstances, the log hold position is regularly advanced and log files are purged appropriately. However, if operations are not functioning properly and the hold position does not advance, there can be an excessive accumulation of log files beyond the hold position that can no longer be purged, which eventually fills available file system space.

These components and operations include the following:

  • Transactions writing log records to the transaction log file have been committed or rolled back. These can be either local database transactions or XA transactions.

  • Changes recorded in the transaction log file have been written to both checkpoint files.

  • Replication: There is a transaction log hold until the transmitting replication agent confirms that the log files have been fully processed by the receiving host.

    Possible failure modes include the following:

    • The network is down or there is a standby crash and replication is unable to deliver data to one or more subscribers. If necessary, the application can direct that logs no longer be held, then duplicate the master database to the standby when standard operations resume. Criteria for when to do this includes the amount of time required to duplicate, the amount of available file system space on the master for log files, and the transaction log growth rate.

    • The overall database transaction rate exceeds the ability of replication to keep the active and standby databases synchronized. An application can reduce the application transaction rate or the number of replicated tables.

    See Improving Replication Performance in Oracle TimesTen In-Memory Database Replication Guide and Troubleshooting Replication in Oracle TimesTen In-Memory Database Monitoring and Troubleshooting Guide.

  • XLA: There is a transaction log hold until the XLA bookmark advances.

    A possible failure mode occurs when the bookmark becomes stuck, which can occur if an XLA application terminates unexpectedly or if it disconnects without first deleting its bookmark or disabling change-tracking. If a bookmark gets too far behind, the application can delete it. If the XLA reader process is still active, it must first be terminated, so that another XLA process can connect and delete the bookmark.

  • Active standby pairs that replicate AWT cache groups: There is a transaction log hold until the replication agent confirms that the transaction corresponding to the log hold has been committed on the Oracle Database. With an active standby pair, the active database typically receives the confirmation from the standby database. If the standby database is down, the replication agent receives confirmation from Oracle Database directly.

    Possible failure modes include the following:

    • Oracle Database is down or there is a lock or resource contention.

    • The network is down, slow, or saturated.

    • With an active standby pair, replication to the standby database falls behind. Check log holds on the standby database.

    • The transaction rate to TimesTen exceeds the maximum sustainable rate that TimesTen can propagate to Oracle Database.

    See Monitoring AWT Cache Groups in Oracle TimesTen In-Memory Database Cache Guide and Troubleshooting AWT Cache Groups in Oracle TimesTen In-Memory Database Monitoring and Troubleshooting Guide.

  • Cache groups configured with AUTOREFRESH: There is a transaction log hold until the replication agent on the active database confirms the log files have been fully processed by the standby database.

    Possible failure modes include the following:

    • Replication from the active database to the standby database is impacted because the standby database falls behind due to large workloads resulting from AUTOREFRESH mode.

    • The standby database is down or recovering, but has not been marked as FAILED through a call, initiated by either the user application or Oracle Clusterware, to the ttRepStateSave built-in procedure. The active database does not take over propagation to the Oracle Database until the state of the standby database is marked as FAILED. While the standby database is down or recovering, transaction log files are held for the Oracle Database.

    See Monitoring Cache Groups with Autorefresh in Oracle TimesTen In-Memory Database Monitoring and Troubleshooting Guide.

  • Incremental TimesTen backup: There is a log hold until you manually run an incremental backup and until that backup completes.

    The most likely failure is if you configure incremental backups (which starts TimesTen holding log files), but you do not actually run an incremental backup, which would free the log file hold.

    Another possible failure mode can occur if the incremental backup falls too far behind the most recent entries in the transaction log. For example, ensure that an unexpected burst of transaction activity cannot fill up available transaction log file system space due to the backup holding a log file that is too old. An application can perform another incremental backup to work around this situation.

  • Long-running transaction or XA transaction: There is a transaction log hold until the transaction commits or rolls back.

    A possible failure mode can occur if an application transaction does not commit or rollback for a long time, so that it becomes necessary for the application to terminate the long-running transaction.

    Alternatively, you can rollback a transaction using the ttXactAdmin utility with the -xactIdRollback option. See ttXactAdmin in Oracle TimesTen In-Memory Database Reference.

  • Oldest transaction undo: Each transaction that has not yet committed or rolled back establishes a log hold. This hold starts with the first (oldest) log record of the transaction and marks a point for the transaction that the checkpoint log purge operation cannot pass. You can retrieve this log hold information from the SYS.V$CKPT_HISTORY system view or from the output of the ttCkptHistory built-in procedure.