Durability Settings
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
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
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 |
---|---|
|
Participants write nondurable prepare-to-commit and commit log records for every distributed transaction to commit. |
|
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.