Working With Oracle Transparent Application Failover

PeopeTools provides limited support for Oracle Transparent Application Failover (TAF). PeopleTools TAF support includes:

  • PeopleSoft servers can be configured to transparently reconnect to a surviving RAC instance in the event of an instance failure with in a RAC cluster.

  • PeopleSoft servers can be configured to transparently fail over to an Oracle Database Data Guard standby when the primary database is lost.

Note: In most cases, other than a slight pause in the operation, the failover is transparent to the application end user.

Note: The Oracle TAF feature as implemented in Oracle 11g and earlier versions of Oracle only supports recoverability of in-flight SELECT statements. SELECT statements that are part of an uncommitted transaction block are not supported with TAF. Recoverability of INSERTs, UPDATEs, and DELETEs are not supported with TAF. Given these limitations, PeopleSoft does not support TAF for non-query operations.

PeopleTools is designed to listen for Oracle fast application notification (FAN) events to derive the failover behavior. Upon receipt of a FAN event, PeopleSoft servers break their existing TCP connections and initiate TAF, which references the TNSNAMES.ORA connect alias address list and establishes a connection to the surviving instance.

See Your Oracle RAC and database administration guides for the details of implementing and managing Oracle RAC clusters.

The following table summarizes PeopleSoft behavior during RAC or Data Guard failover when TAF is configured.

PeopleSoft Client Scenario

Behavior

End user is inserting, updating, or deleting data and submits or saves the inserts/updates/deletes during or just after the database failure.

The data manipulation language (DML) will fail. Transactions will not get resubmitted. Oracle reconnects and reconstructs the database session on a surviving node and the end user must resubmit the transaction.

End user is paging through queried data (SELECTs) when the database failure occurs.

Oracle reconnects and reconstructs the database session on a surviving node, re-executes the query, repositions the SQL cursor, and returns the next set of rows.

End user is issuing a new query (SELECTs) or switching screens just after the database failure.

Oracle reconnects and reconstructs the database session on a surviving node.

The following table summarizes PeopleSoft batch system behavior during RAC or Data Guard failover when TAF is configured.

PeopleSoft Batch System Scenario

Behavior

Process Scheduler

Oracle reconnects and reconstructs the session on a surviving node. The Process Scheduler fails over with no administration intervention required.

Application Engine job submitted just before primary instance failure

Oracle reconnects and reconstructs the session on a surviving node but Application Engine job may fail and appear in the PeopleSoft Process Monitor with a status of No Success. These jobs will need to be resubmitted manually.

If the Application Engine job was not in an open-transaction and was performing only SELECT statements, it will fail over and complete successfully.

Application Engine submitted during or just after primary instance failure

Oracle reconnects and reconstructs the session on a surviving node, the Application Engine job is then submitted on the new primary database and completes successfully.

COBOL jobs before, during, or after primary instance failure

The COBOL jobs will not complete successfully on the surviving node.

Manual intervention is required to restart the COBOL jobs.

SQR jobs submitted just before or during primary instance failure

Oracle reconnects and reconstructs the session on a surviving node but SQR may fail and appear in the PeopleSoft Process Monitor with a status of No Success. These jobs will need to be resubmitted manually.

If the SQR job was not in an open-transaction nor executing DMLs  and was performing only SELECT statements, it will fail over and complete successfully.

SQR jobs submitted just after primary instance failure.

Oracle reconnects and reconstructs the session on a surviving node, the SQR job is then submitted on the new primary database and completes successfully.

nVision reports

The behavior is the same as COBOL

PSQUERY, Tree Viewer, BI Publisher Query Report Viewer

Will fail over and complete successfully.