Durability Settings

You control how durable your transactions are with the Durability attribute. This attribute defines if transactions create durable prepare-to-commit log records. Regardless of the setting of this attribute, transactions that include DDL statements create durable prepare-to-commit and commit log records. The Durability attribute supports two different values:

• Durability Set to 1

• Durability Set to 0

Durability Set to 1

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. This is the default setting of the Durability attribute when K-safety is set to 1.

For more information on the Durability attribute, see Durability in Oracle TimesTen In-Memory Database Reference.

Durability Set to 0

If you set the Durability attribute to 0, participants write nondurable prepare-to-commit and commit log records for distributed transactions. To ensure a measure of durability, TimesTen Scaleout provides the following new features that are generally exclusive to databases with the Durability attribute set to 0:

• Epoch Transactions

• EpochInterval Attribute

• CreateEpochAtCommit Attribute

Epoch Transactions

An epoch transaction is a distributed transaction that creates a durable commit log record that marks a globally consistent point in time across all elements of a database. Epoch transactions are durably committed on every element of the database. An epoch transaction ensures that the database is consistent up to the timestamp of the epoch transaction. In other words, an epoch transaction ensures that any transaction already in the commit phase is recoverable.

Note:

TimesTen Scaleout uses Lamport timestamps to provide partial ordering for transactions that commit on different elements of a database. Each element has a Lamport timestamp that is updated by, among others, prepare and commit operations. The transaction manager logs the Lamport timestamp of every committed transaction.

Transactions in a grid with K-safety set to 2 (or greater) and a database with the Durability attribute set to 0 are durable under typical conditions, since TimesTen Scaleout writes durable prepare-to-commit log records of transactions that involve a replica set with a failed element until the failed element recovers. Only if both elements of the replica set fail simultaneously, a transaction may become nondurable. However, TimesTen Scaleout enables you to promote transactions to epoch transactions. An epoch transactions and all transactions committed before it are more resilient to catastrophic failures, since you can recover a database to the consistent point marked by the epoch commit log record of the epoch transaction.

Note:

• See Recovering a Replica Set After an Element Goes Down for more information on how to recover failed element in a replica set.

• See Recovering from a Down Replica Set for more information on how to recover a failed replica set.

Before promoting a transaction, consider that a commit for an epoch transaction is more expensive than a commit for a regular transaction, because it creates durable log records for both the prepare-to-commit and commit phase and involves every element of the database, including those that were not participants before the promotion of the transaction to an epoch transaction.

Use these built-in procedures and system view to promote and manage epoch transactions:

• The ttEpochCreate built-in procedure promotes a transaction to an epoch transaction, including read-only transactions.

• The ttDurableCommit built-in procedure promotes a write transaction to an epoch transaction.

• The SYS.V$EPOCH_SESSION system view stores the Lamport timestamp of the latest epoch transaction that the connection created since the second-to-last checkpoint operation.

The following example shows and verifies the promotion of a write transaction to an epoch transaction.

Command> autocommit OFF;
Command> INSERT INTO transactions VALUES (txn_seq.NEXTVAL, 189, SYSDATE, NULL, 'A', 5.49);
Command> SELECT epoch FROM sys.v$epoch_session;
< 1023.1 >
1 row found.
Command> CALL ttEpochCreate();
Command> COMMIT;
Command> SELECT epoch FROM sys.v$epoch_session;
< 1024.1 >
1 row found.

For more information on the ttEpochCreate or ttDurableCommit built-in procedure, see ttEpochCreate or ttDurableCommit, respectively, in Oracle TimesTen In-Memory Database Reference.

For more information on the SYS.V$EPOCH_SESSION system view, see SYS.V$EPOCH_SESSION in Oracle TimesTen In-Memory Database System Tables and Views Reference.

EpochInterval Attribute

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.

You can configure a database to generate periodic epoch transactions at an specified interval with the EpochInterval first connection attribute. The value set for the EpochInterval attribute must be less than one half of the value set for the CkptFrequency first connection attribute, so that there is at least one epoch transaction for every checkpoint operation. If you set the CkptFrequency attribute to a value greater than zero and the EpochInterval attribute to a value greater than one half of the value set for the CkptFrequency attribute, TimesTen Scaleout will re-adjust the EpochInterval attribute to one half of value set for the CkptFrequency attribute.

For more information on the EpochInterval or CkptFrequency attribute, see EpochInterval or CkptFrequency, respectively, in Oracle TimesTen In-Memory Database Reference.

CreateEpochAtCommit Attribute

You can configure a connection to promote every write transaction committed by that connection to an epoch transaction with the CreateEpochAtCommit general connection attribute. If you set the CreateEpochAtCommit attribute to 1, you ensure that every transaction you commit during the connection is recoverable in the case of failure. However, as with any epoch transaction, commits operations are more expensive than with regular transactions, so it is recommended that you limit CreateEpochAtCommit=1 for critical operations only.

Note:

Even though the DurableCommits attribute is intended for databases in TimesTen Classic, the attribute emulates the behavior of the CreateEpochAtCommit attribute when set to 1 for a database in TimesTen Scaleout. See DurableCommits in Oracle TimesTen In-Memory Database Reference.

When the Durability attribute is set to 0, the transaction manager and the participants behave differently depending of the settings of the CreateEpochAtCommit attribute, as shown on Table 6-1.

Table 6-1 Participants Behavior on Commit Based on CreateEpochAtCommit Setting

CreateEpochAtCommit	Commit behavior
0	Participants write nondurable prepare-to-commit and commit log records for every distributed transaction to commit.
1	Promotes every transaction to an epoch transaction.

Setting both the Durability and CreateEpochAtCommit attributes to 0 provides the best performance. In this case, call the ttEpochCreate or ttDurableCommit built-in procedures to ensure that you have durable records of important transactions.

For more information on the Durability or CreateEpochAtCommit attribute, see Durability or CreateEpochAtCommit, respectively, in Oracle TimesTen In-Memory Database Reference. For more information on the ttEpochCreate or ttDurableCommit built-in procedure, see ttEpochCreate or ttDurableCommit, respectively, in Oracle TimesTen In-Memory Database Reference.