Skip Headers
Oracle® TimesTen Application-Tier Database Cache User's Guide
11g Release 2 (11.2.2)

E21634-12
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

11 Using TimesTen Application-Tier Database Cache in an Oracle RAC Environment

The following sections describe how to use TimesTen Application-Tier Database Cache (TimesTen Cache) in an Oracle Real Application Clusters (Oracle RAC) environment:

How TimesTen Cache works in an Oracle RAC environment

Oracle RAC enables multiple Oracle Database instances to access one Oracle database with shared resources, including all data files, control files, PFILEs and redo log files that reside on cluster-aware shared disks. Oracle RAC handles read/write consistency and load balancing while providing high availability.

Fast Application Notification (FAN) is an Oracle RAC feature that was integrated with Oracle Call Interface (OCI) in Oracle Database 10g Release 2. FAN publishes information about changes in the cluster to applications that subscribe to FAN events. FAN prevents unnecessary operations such as the following:

  • Attempts to connect when services are down

  • Attempts to finish processing a transaction when the server is down

  • Waiting for TCP/IP timeouts

See Oracle Real Application Clusters Administration and Deployment Guide for more information about Oracle RAC and FAN.

TimesTen Cache uses OCI integrated with FAN to receive notification of Oracle Database events. With FAN, TimesTen Cache detects connection failures within a minute. Without FAN, it can take several minutes for TimesTen Cache to receive notification of an Oracle Database failure. Without FAN, TimesTen Cache detects a connection failure the next time the connection is used or when a TCP/IP timeout occurs. TimesTen Cache can recover quickly from Oracle Database failures without user intervention.

TimesTen Cache also uses Transparent Application Failover (TAF), which is a feature of Oracle Net Services that enables you to specify how you want applications to reconnect after a failure. See Oracle Database Net Services Administrator's Guide for more information about TAF. TAF attempts to reconnect to the Oracle database for four minutes. If this is not successful, the cache agent restarts and attempts to reconnect with the Oracle database every minute.

Note:

You can configure how long TAF retries when establishing a connection with the AgentFailoverTimeout parameter. For details, see "Setting up TimesTen Cache in an Oracle RAC environment".

OCI applications can use one of the following types of Oracle Net failover functionality:

  • None: No failover functionality is used. This can also be explicitly specified to prevent failover from happening. This is the default failover functionality.

  • Session: If an application's connection is lost, a new connection is automatically created for the application. This type of failover does not attempt to recover selects.

  • Select: This type of failover enables applications that began fetching rows from a cursor before failover to continue fetching rows after failover.

The behavior of TimesTen Cache depends on the actions of TAF and how TAF is configured. By default, TAF and FAN callbacks are installed if you are using TimesTen Cache in an Oracle RAC environment. If you do not want TAF and FAN capabilities, set the RACCallback connection attribute to 0.

Table 11-1 shows the behaviors of TimesTen Cache operations in an Oracle RAC environment with different TAF failover types.

Table 11-1 Behavior of TimesTen Cache operations in an Oracle RAC environment

Operation TAF Failover Type Behavior After a Failed Connection on the Oracle Database

Autorefresh

None

The cache agent automatically stops, restarts and waits until a connection can be established on the Oracle database. This behavior is the same as in a non-Oracle RAC environment.

No user intervention is needed.

Autorefresh

Session

One of the following occurs:

  • All failed connections are recovered. Autorefresh operations that were in progress are rolled back and retried.

  • If TAF times out or cannot recover the connection, the cache agent automatically stops, restarts and waits until a connection can be established on the Oracle database.

  • In all cases, no user intervention is needed.

Autorefresh

Select

One of the following occurs:

  • Autorefresh operations resume from the point of connection failure.

  • Autorefresh operations that were in progress are rolled back and retried.

  • If TAF times out or cannot recover the connection, the cache agent automatically stops, restarts and waits until a connection can be established on the Oracle database.

  • In all cases, no user intervention is needed.

AWT

None

The receiver thread of the replication agent for the AWT cache group exits. A new thread is spawned and tries to connect to the Oracle database.

No user intervention is needed.

AWT

Session, Select

One of the following occurs:

  • If the connection is recovered and there are uncommitted DML operations in the transaction, the transaction is rolled back and then reissued.

  • If the connection is recovered and there are no uncommitted DML operations, new operations can be issued without rolling back.

In all cases, no user intervention is needed.

SWT, propagate, flush, and passthrough

None

The application is notified of the connection loss. The cache agent disconnects from the Oracle database and the current transaction is rolled back. All modified session attributes are lost.

During the next passthrough operation, the cache agent tries to reconnect to the Oracle database. This behavior is the same as in a non-Oracle RAC environment.

No user intervention is needed.

SWT, propagate, flush and passthrough

SWT, propagate and flush

Session


Select

One of the following occurs:

  • The connection to the Oracle database is recovered. If there were open cursors, DML or lock operations on the lost connection, an error is returned and the user must roll back the transaction before continuing. Otherwise, the user can continue without rolling back.

  • If TAF times out or cannot recover the connection, the application is notified of the connection loss. The cache agent disconnects from the Oracle database and the current transaction is rolled back. All modified session attributes are lost.

    During the next passthrough operation, the cache agent tries to reconnect to the Oracle database.

    In this case, no user intervention is needed.

Passthrough

Select

The connection to the Oracle database is recovered. If there were DML or lock operations on the lost connection, an error is returned and the user must roll back the transaction before continuing. Otherwise, the user can continue without rolling back.

Load and refresh

None

The application receives a loss of connection error.

Load and refresh

Session

One of the following occurs:

  • The load or refresh operation succeeds.

  • An error is returned stating that a fetch operation on Oracle Database cannot be executed.

Load and refresh

Select

One of the following occurs:

  • If the Oracle Database cursor is open and the cursor is recovered, or if the Oracle Database cursor is not open, then the load or refresh operation succeeds.

  • An error is returned if TAF was unable to recover either the session or open Oracle Database cursors.

Note: An error is less likely to be returned than if the TAF failover type is Session.


Restrictions on using TimesTen Cache in an Oracle RAC environment

TimesTen Cache support of Oracle RAC has the following restrictions:

  • TimesTen Cache behavior is limited to Oracle RAC, FAN and TAF capabilities. For example, if all nodes for a service fail, the service is not restarted. TimesTen Cache waits for the user to restart the service.

  • TAF does not recover ALTER SESSION operations. The user is responsible for restoring changed session attributes after a failover.

  • TimesTen Cache uses OCI integrated with FAN. This interface automatically spawns a thread to wait for an Oracle Database event. This is the only TimesTen Cache feature that spawns a thread in a TimesTen direct link application. Adapt your application to account for this thread creation. If you do not want the extra thread, set the RACCallback connection attribute to 0 so that TAF and FAN are not used.

Setting up TimesTen Cache in an Oracle RAC environment

After you install Oracle RAC and TimesTen Cache, perform the following to set up an TimesTen Cache for an Oracle RAC environment:

  1. On TimesTen, set the TAF timeout, in minutes, with the ttCacheConfig AgentFailoverTimeout parameter. The AgentFailoverTimeout parameter configures how long TAF retries when establishing a connection. TAF attempts to reconnect to the Oracle database for the duration of this timeout. The default is four minutes. If this is not successful, the cache agent restarts and attempts to reconnect with the Oracle database every minute; the replication agent restarts any threads that cannot connect to the Oracle database. For more details, see "ttCacheConfig" in the Oracle TimesTen In-Memory Database Reference.

  2. Make sure that the TimesTen daemon, the cache agent, and the following Oracle Database components are started:

    • Oracle Database instances

    • Oracle Database listeners

    • Oracle Database service that is used for TimesTen Application-Tier Database Cache

  3. Verify that the TimesTen RACCallback connection attribute is set to 1 (default). For more details, see "RACCallback" in the Oracle TimesTen In-Memory Database Reference.

  4. Use the DBMS_SERVICE.MODIFY_SERVICE function or Oracle Enterprise Manager to enable publishing of FAN events. This changes the value in the AQ_HA_NOTIFICATIONS column of the Oracle Database ALL_SERVICES view to YES.

    See Oracle Database PL/SQL Packages and Types Reference for more information about the DBMS_SERVICE Oracle Database PL/SQL package.

  5. Enable TAF on the Oracle Database service used for TimesTen Cache with one of the following methods:

    • Create a service for TimesTen in the Oracle Database tnsnames.ora file with the following settings:

      • LOAD_BALANCE=ON (optional)

      • FAILOVER_MODE=(TYPE=SELECT) or FAILOVER_MODE=(TYPE=SESSION)

    • Use the DBMS_SERVICE.MODIFY_SERVICE function to set the TAF failover type.

      See Oracle Database Net Services Administrator's Guide for more information about enabling TAF.

  6. If you have a TimesTen direct link application, link it with a thread library so that it receives FAN notifications. FAN spawns a thread to monitor for failures.