Durability Options

Databases in TimesTen are persistent across power failures and crashes. TimesTen accomplishes durability by periodically saving to disk.

Checkpoint files: A checkpoint operation writes the current database image to a checkpoint file on the file system, which has the effect of making all transactions that committed before the checkpoint durable.
Transaction log files: For transactions that committed after the last checkpoint, TimesTen uses conventional logging techniques to make them durable. As each transaction progresses, it records its database modifications in an in-memory transaction log. At commit time, the relevant portion of the transaction log is flushed to the file system. This log flush operation makes that transaction, and all previously-committed transactions, durable.

Control returns to the application after the transaction log data has been durably written to the file system. A durably committed transaction is not lost even in the event of a system failure.

Any recovery uses the last checkpoint image together with the transaction log to reconstruct the latest transaction-consistent state of the database.

When committing transactions, TimesTen reduces the performance cost for durable commits with a group commit of multiple concurrently running transactions. TimesTen performs a single file system write operation to commit a group of concurrent transactions durably. Group commit does not improve the response time of any given commit operation, as each durable commit must wait for the file system write operation to complete, but it can significantly improve the throughput of a series of concurrent transactions.

The following sections describe the durability implementation options for TimesTen Scaleout and TimesTen Classic:

Durability for TimesTen Scaleout

In TimesTen Scaleout, the data in your database is distributed into elements. Each element keeps its own checkpoint and transaction log files. As a result, the data stored in each element is independently durable.

Each data instance in a grid manages one element of a database. In the event of a failure, a data instance can automatically recover the data stored in its element from the checkpoint and transaction log files while the remaining data instances continue to service applications.

TimesTen Scaleout also enables you to keep multiple copies of your data to increase durability and fault tolerance. If the K-safety value is 2 or greater, then a failed element can be recovered from another element in its replica set. For more information on K-safety, see High Availability and Fault Tolerance and Creating a Grid in the Oracle TimesTen In-Memory Database Scaleout User's Guide.

In addition, you can change the durability settings of a database according to your performance and data durability needs. For example, you may choose if data is flushed to disk with every commit or periodically in batches in order to operate at a higher performance level. The following sections describe these durability settings:

Guaranteed Durability for TimesTen Scaleout

In TimesTen Scaleout, you configure how durable your transactions are with the Durablity connection attribute.

If you set the Durability attribute to 1, participants write durable prepare-to-commit log records and nondurable commit log records for distributed transactions. Having the Durability attribute set 1 ensures that committed transactions are recoverable in the case of a failure. See Durability Settings in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Non-Durable Distributed Transactions for TimesTen Scaleout

Set the Durability connection attribute to 0 so that participants write nondurable prepare-to-commit and commit log records for distributed transactions.

K-safety provides a method for failure recovery. K-safety enables you to achieve near-continuous availability or workload distribution by providing two copies of the data. Thus, if one copy fails, another copy of the data exists.

If any element of a replica set has failed the other element in the replica set writes durable prepare-to-commit log records until the failed element recovers. This ensures that transactions in a grid with K-safety set to 2 and Durability=0 are durable under standard conditions. A transaction may become nondurable only if both elements of the replica set fail simultaneously.

TimesTen Scaleout periodically promotes transactions to epoch transactions. An epoch transaction and all transactions committed before it are more resilient to catastrophic failures, since you can recover a database to the globally consistent point marked by the epoch transaction. Each epoch commit log record is associated to a specific checkpoint file on every element. In the case of an unexpected failure of an element, the recovery process must use the checkpoint file on each element that is associated with the latest epoch commit log record, which is not necessarily the latest checkpoint available on the element.

By default, TimesTen Scaleout generates one epoch transaction every second. You can configure how often epoch transactions are automatically generated with the EpochInterval first connection attribute. In addition, you can use the ttEpochCreate or ttDurableCommit built-in procedures to manually promote a transaction to an epoch transaction.

See Durability Set to 0 in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more information on epoch transactions and how to promote a transaction to an epoch transaction.

Durability for TimesTen Classic

TimesTen Classic provides durability by using the last checkpoint image together with the transaction log to reconstruct the latest transaction-consistent state of the database.

Transaction log records are written to disk asynchronously or synchronously to the completion of the transaction and controlled by the application at the transaction level.

You can create an environment for guaranteed durability with no loss of data for those cases where data integrity must be preserved.
You can create an environment for durability for those cases where maximum throughput is paramount but can also tolerate minimal exposure to some data loss.

TimesTen Classic replication makes data highly available to applications with minimal performance impact. Replication enables you to achieve near-continuous availability or workload distribution by sending updates between two or more hosts. A master host is configured to asynchronously send updates and a subscriber host is configured to receive them.

Note:

For the highest availability for TimesTen Classic, use the active standby pair replication scheme configuration. See Active Standby Pair With Read-Only Subscribers in the Oracle TimesTen In-Memory Database Replication Guide.

With an Asynchronous WriteThrough (AWT) cache group, TimesTen transmits committed updates between the TimesTen cache tables and the cached Oracle Database tables to keep these tables in the two databases synchronized. See Asynchronous WriteThrough (AWT) Cache Group in the Oracle TimesTen In-Memory Database Cache Guide.

Guaranteed Durability for TimesTen Classic

Guaranteed durability ensures that there is no loss of data (at the cost of some performance) for those cases where data integrity must be preserved.

To guarantee durability for all transactions, you should do at least one of the following. (There is very little advantage in using both of these options.)

Use replication enabled with the return twosafe service to replicate transactions. The return twosafe service provides a fully synchronous option by blocking the application until replication confirms that the update has been both received and committed on the subscriber before it is committed on the master. This provides applications a higher level of confidence that the effects of a committed transaction are durable, even if the master subsequently fails. This option is usually faster than the durable commit. See Return Twosafe Replication in the Oracle TimesTen In-Memory Database Replication Guide.
Configure durable commit operations by setting the DurableCommits connection attribute to 1, which ensures that the transaction is synchronously written to the transaction log file while the application waits. See DurableCommits in the Oracle TimesTen In-Memory Database Reference.

Note:

If most of your transactions commit durably, you may want to set the LogFlushMethod first connection attribute to 1. This connection attribute configures how TimesTen writes and synchronizes log data to transaction log files. For more information, see Use Durable Commits Appropriately.

Non-Durable Transactions for TimesTen Classic

Non-durable transactions run considerably faster than durable transactions. Connections that use non-durable transactions can coexist with connections that use guaranteed durability.

As with guaranteed durability, each transaction enters records into the in-memory transaction log buffer as it makes modifications to the database. However, when a transaction commits in non-durable mode, it does not wait for the transaction log buffer to be written to the file system before returning control to the application. Thus, unless you have configured asynchronous replication or an asynchronous writethrough cache group, a non-durable transaction may be lost in the event of a database failure. Eventually, transactions are flushed to the file system into the transaction log files by the database subdaemon process or when the in-memory transaction log buffer is full.

If your transactions require extremely high throughput with minimal exposure to data loss, then consider doing BOTH of these options:

Use one of these methods to perform an asynchronous write operation of your data to another database: a TimesTen database or an Oracle database.
- Use the default asynchronous replication that replicates committed transactions from the master to the subscriber. With the default asynchronous replication, an application updates a master database and continues working without waiting for the updates to be received and applied by the subscribers. While asynchronous replication provides the best performance, it does not provide the application with confirmation that the replicated updates were committed on subscriber databases. See Copying Updates Between Databases Oracle TimesTen In-Memory Database Replication Guide.
- Set up an Asynchronous WriteThrough (AWT) cache group to cause committed updates on TimesTen cache tables to be automatically and asynchronously propagated to the cached Oracle Database tables. A transaction commit operation on the TimesTen database occurs asynchronously from the commit on the Oracle database. This enables an application to continue issuing transactions on the TimesTen database without waiting for the Oracle Database transaction to complete. However, your application cannot ensure when the transactions are completed on the Oracle database. See Asynchronous WriteThrough (AWT) Cache Group in the Oracle TimesTen In-Memory Database Cache Guide.
Configure for non-durable transactions by setting the DurableCommits connection attribute to 0, which asynchronously writes non-durable commit log records to the transaction log file.

See DurableCommits in the Oracle TimesTen In-Memory Database Reference.

The only transactions vulnerable to loss in the event of a system failure are those that committed non-durably after the last durable commit and were not replicated prior to the failure.

However, if you have critical transactions that cannot be exposed to any data loss, you can either:

Replicate those transactions synchronously from the master database to the subscriber database by running the ttRepSubscriberWait built-in procedure.

Running the ttRepSubscriberWait built-in procedure on the master database using the DSN and host of the subscriber database causes the caller to wait until all transactions that committed before the call have been transmitted to the subscriber. See ttRepSubscriberWait in the Oracle TimesTen In-Memory Database Reference.
Force the individual transactions to commit durably to the transaction log files with the ttDurableCommit built-in procedure. Committing a transaction durably makes that transaction and all previous transactions durable. However, this does not wait for the transaction to be replicated.

When a durable commit is needed, the application can call the ttDurableCommit built-in procedure before committing. The ttDurableCommit built-in procedure does not actually commit the transaction; it merely causes the commit to be durable when it occurs.

This maintains a smaller window of vulnerability to transaction loss as opposed to all transactions being committed non-durably. By committing only every nth transaction durably or performing a durable commit every n seconds, an application can achieve a quicker response time while maintaining a small window of vulnerability to transaction loss. A user can elect to perform a durable commit of a critical transaction, such as one that deals with financial exchange, that cannot be vulnerable to loss.

See ttDurableCommit in the Oracle TimesTen In-Memory Database Reference.