Configuration Checklist for Application Continuity on Oracle RAC

Before using Application Continuity with an Oracle RAC database, use the following configuration checklist:

Service Configuration Checks:
- Use a database service (also referred to as an application service) to connect to the database. Do not use the default database service (DB_NAME or DB_UNIQUE_NAME), or the Oracle SID or instance name for client connections.
- Ensure you enable the appropriate attributes for the service.
  
  See Also:
  
  "Creating Services for Application Continuity and Transaction Guard"
Software Configuration Checks (database and middle tier):
- Use Oracle Database 12c, or later.
- Use the JDBC Universal Connection Pool (12.1) or WebLogic Active GridLink (12.1.2 or later) configured with the JDBC Replay data source, or use the JDBC Replay data source with your own JDBC connection pool.
- Oracle recommends that you use FAN and FCF for WebLogic Active GridLink Data Source or Oracle JDBC Universal Connection Pool.
  
  See Also:
  
  Oracle Database 2 Day + Real Application Clusters Guide for information about simple FAN
- Check the resource requirements; ensure there is sufficient CPU and memory in the middle tier and database tier.
  
  Note:
  
  Application Continuity can lead to a slight increase in CPU consumption on the server for managing purposes and on the client due to Java garbage collection. An increase in memory consumption is expected, too, because the replay driver needs to retain the request state. The individual increase in CPU and memory consumption differs on a case-by-case basis. CPU overhead on the database server may be reduced if the platform supports the current Intel and Sparc processors.
- After consulting the application certification, GRANT keeping mutables to the users who will use replay.
- Use a connection string that sets connection retries and a delay between these retries. For an example of configuring the connection properties using JDBC, see "Generic Database Clients".
Application Code Checks (consult with the application developer):
- Decide whether to use an optional callback for initializing connections from the application to the database. When using Oracle WebLogic Server or the Universal Connection Pool, connection labeling is recommended. If registered, a callback will execute at run time and replay.
- Determine whether the application uses Oracle JDBC concrete classes. If it does, and if access is needed to Oracle proprietary APIs, then plan to replace these concrete classes with standard JDBC or Oracle JDBC interfaces.
  
  See Also:
  
  My Oracle Support Note 1364193.1 for information about these interfaces: https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1364193.1
- Determine whether the application uses mutable function calls SYSDATE, SYSTIMESTAMP, SYS_GUID, or Oracle sequences. If so, then determine whether it is correct to configure the application to keep the original values during failover.
- Determine whether replay must be explicitly disabled for any code path in the application.
- If the application borrows and returns connections from the Oracle WebLogic Server pool or Universal Connection Pool, then, for each request, do not change anything.
  
  If the application uses Oracle pools, and does not return connections between requests, then determine whether there is a property to set to return connections to the pool. If there is no property to set, or if you are using the application's own connection pool, then you can add beginRequest and endRequest boundaries.