This chapter describes information unique to certain component products.
For this release, this chapter includes the following topics:
This topic describes considerations for configuring Oracle Data Integrator repository connections to Oracle Real Application Clusters:
Section 11.1.1, "Oracle RAC Retry Connectivity for Source and Target Connections"
Section 11.1.2, "Configuring Repository Connections to Oracle RAC"
When you configure Oracle Data Integrator (ODI) Oracle Real Application Clusters (RAC) connections, Oracle RAC retry is supported for the ODI master or ODI work repository. ODI uses transactional connections to source and target connections while running ODI scenarios. For these source and target connections, ODI does not support RAC retry connectivity. You cannot migrate these transactions to another node in Oracle RAC.
When you create an ODI repository using the Repository Creation Utility (RCU), you specify the work repository connection JDBC URL. RCU stores the URL in the master repository contents. If the work repository JDBC URL is a single node URL, you should modify the URL to include the Oracle Real Application Clusters (Oracle RAC) failover address.
If Oracle RAC is not configured with Single Client Access Name (SCAN), you can provide details of the Oracle RAC instances. In the work repository JDBC Url field, enter the Oracle RAC connectivity address in the format host:port. See Example 11-1.
If Oracle RAC is configured with SCAN, provide Oracle RAC instance details with the SCAN address.
Example 11-1 shows the JDBC URL format to connect to an Oracle RAC with two hosts when it does not use SCAN:
Example 11-1 JDBC URL Format (Oracle RAC Not Configured with SCAN)
jdbc:oracle:thin:(DESCRIPTION =(LOAD_BALANCE=ON) (ADDRESS =(PROTOCOL =tcp) (HOST =host1)(PORT =port1)) (ADDRESS =(PROTOCOL =tcp)(HOST =host2) (PORT =port2)) (CONNECT_DATA =(SERVER=dedicated) (SERVICE_NAME=service_name)))
See the topic "Creating a Work Repository" in Administering Oracle Data Integrator for more information.
If a WebLogic Server failover occurs, the other WebLogic Server instance becomes the scheduler. A Coherence cache handles the scheduler lifecycle. Locking guarantees the uniqueness of the scheduler and event notification provides scheduler migration. When an agent restarts and computes its schedule, it takes into account schedules in progress, which automatically continue their execution cycle beyond the server startup time. New sessions trigger as if the scheduler never stopped. Stale sessions move to an error state and remain in that state when they restart.
In an Oracle Data Integrator Agent cluster, if the Agent node that is the scheduler node fails, another node in the cluster takes over as the scheduler node. The new scheduler node reinitializes and runs all schedules from that point forward.
If a scheduled scenario with a repeatable execution cycle is running when the node crashes, the scenario does not continue its iterations on the new scheduler node from the point at which the scheduler node crashed. For example, if a scheduled scenario is configured to repeat the execution 10 times after an interval of two minutes and the scheduler node fails during the third execution, the new scheduler node does not continue running the scenario for the next eight executions.
This topic describes information specific to Oracle Application Development Framework (ADF).
Topics in this section include the following:
See Also:
For more information on ADF, see the following:
Oracle ADF Key Concepts in Understanding the Oracle Application Development Framework
Oracle Fusion Middleware Administering Oracle ADF Applications
When you use Oracle JRF Asynchronous Web Services, the asynchronous web service is pinned to a service and does not fail over. When you use a reliability protocol such as WS-RM, the higher-level protocol reconnects to a new server after a failure.
For more information on Oracle JRF Asynchronous Web Services, see the Domain Template Reference.
When you use a GridLink data source or a multi data source with a customer- provided ADF application, you must change the mdsDS data source URL in the Weblogic Server Administration Console after you start the Administration Server.
To modify the mdsDS data source URL:
Log into the WebLogic Server Administration Console. Select Services then Data Sources.
Select mdsDS then Connection Pool.
Change the JDBC URL to specify it in the format:
jdbc:oracle:thin:@hostname:port/service-name
For example, if the JDBC URL is:
jdbc:oracle:thin:@(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=slc00erterw-r.us.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=srv2_koala.us.example.com)))
Replace the URL with the following:
jdbc:oracle:thin:@slc00erterw-r.us.example.com:1521/srv2_koala.us.example.com
Save the changes then restart all servers, including the Administration Server.