• However, specific support for Oracle RAC is required by the Transaction Monitor in order to take advantage of these replication and failover features in an XA transaction environment or to obtain optimal RAC performance. This is because Oracle 10g does not allow the same database to be accessed from multiple RAC instances within the same XA transaction.Tuxedo 11g Release 1 (11.1.1.0) provides Transaction Monitor support for Oracle RAC by allowing an administrator to specify lists of groups associated with different RAC instances. This allows Tuxedo to ensure that groups associated with different instances of the same RAC database do not participate in the same transaction. The Tuxedo Oracle RAC support feature also provides a way for Tuxedo transaction manager server (TMS) processes to be notified of RAC failover events which is required when using Oracle 10gR1.
Note: When using Oracle 10gR2, administrators should use an Oracle <b>DTP Service</b> to access the Oracle RAC system. This DTP service name should be specified in the OPENINFO string for the associated Tuxedo groups. Oracle 10gR2 verifies the service name, and migrates it to an alternate instance if required.
• Tuxedo 11g Release 1 (11.1.1.0) supports Oracle RAC only when using Oracle 10g or later release, and does not support Oracle RAC when using Oracle 9i.
• In some instances, using Oracle RAC with the Dynamic XA switch enabled may generate a core dump and cause a system crash. Please contact Oracle Support directly if you encounter this issue and provide the following information:For specific platform software requirements, refer to the “Oracle Tuxedo 11g Release 1 (11.1.1.0) Platform Data Sheets” in Installing the Oracle Tuxedo System.
• TUXRACGROUPS (required for Oracle 10gR1 and 10gR2, optional for Oracle 11g)
• XARETRYDURATIONSECONDS (required only for Oracle 10gR1)
• XARETRYINTERVAL (required only for Oracle 10gR1)
• TMS_rac_refresh(1)(required only for Oracle 10gR1)Oracle 10gR1 does not allow the same database to be accessed from multiple RAC instances within the same XA transaction. In addition, Oracle 10gR1 requires Transaction Monitor involvement when prepared transactions failover from one RAC instance to another.For this reason, it is still important to associate an XA transaction with a single RAC instance in Oracle 10gR2. (For further information on using Oracle XA with RAC, refer to the "Developing Applications with Oracle XA" chapter in the Oracle Database Application Developer's Guide - Fundamentals.The TUXRACGROUPS environment variable is used to associate Tuxedo groups with specific instances of Oracle RAC configurations so that Tuxedo does not include groups from multiple instances of the same RAC configuration within the same XA transaction.
Note: When using Oracle 10g or 11g, a single transaction should not span multiple Oracle RAC instances. The groups that participate in a particular transaction are determined at the time the transaction is started. Each transaction is assigned to one particular instance of each RAC configuration such that the groups in each instance of a particular RAC configuration are assigned to an equal number of transactions.The TUXRACGROUPS environment variable specifies the groups that are associated with a particular RAC configuration, and will disallow sending service calls in the same transaction to two or more groups identified as different instances of the same RAC configuration.
WARNING: If the TUXRACGROUPS environment variable is used, it must be set on all machines in a configuration, and must have the same sets of groups specified in the same order on all machines.The TUXRACGROUPS environment variable is used to define Oracle RAC group configurations. Its syntax is as follows:
Note: Since the purpose of the TUXRACGROUPS environment variable is to specify groups associated with different instances of the same Oracle RAC configuration, all applications using the TUXRACGROUPS variable should have at least one semicolon in the environment variable value.
Note: Figure 6‑1 shows a simple Oracle RAC configuration.The same transaction request to both GROUP1 and GROUP2 cannot be sent because they access database services through different instances that map to the same Oracle RAC database configuration.Figure 6‑1 (ORA1) Simple ConfigurationFigure 6‑2 shows an example of adding multiple groups to a single instance.In this example, there are two Oracle databases: ORA1 and ORA2. ORA1 offers machine-specific services ORA1SITE1 and ORA1SITE2, and ORA2 offers machine-specific services ORA2SITE1 and ORA2SITE2. The objective is to assign an approximately equal number of transactions and configure the same services to the groups associated with each instance of an Oracle RAC configuration.The same transaction request to both GROUP1 and GROUP2 cannot be sent because they access database services through different instances that map to the same Oracle RAC database configuration. The same applies to GROUP3 and GROUP4 or GROUP3 GROUP5, the same transaction cannot be sent to both these groups.GROUP4 and GROUP5 both access the same database service of the same Oracle RAC database configuration, so these groups would be permitted together. GROUP1 and GROUP4 would be permitted together, because they access different RAC database configurations. If there is also a GROUP6 in this configuration, it would be permitted with any other group, because GROUP6 is not an Oracle RAC group.
Note: The number of groups in each Oracle RAC instance does not have to be the same.The *GROUPS and *SERVERS sections of the UBBCONFIG file for this configuration might look as follows in Listing 6‑1:
Note: GROUP4 and GROUP5 have the same OPENINFO strings, because they both use the same database service from the same database.The specification of the OPENINFO string for Oracle groups in the *GROUPS section is the same as when using Oracle without RAC. For information on how to specify an OPENINFO string for an Oracle group, refer to the Developing Applications with Oracle XA chapter in the Oracle Database Application Developer's Guide - Fundamentals.Figure 6‑3 shows an example of adding multiple groups to multiple instances.This example is similar to the previous example — except that GROUP11, GROUP12, and GROUP13 are all associated with the first RAC instance of the first RAC configuration, and GROUP21 and GROUP22 are both associated with the second RAC instance.If the first service call in a transaction in this configuration goes to GROUP12, then it would be possible to send other service calls in this transaction to GROUP11, GROUP12, or GROUP13, but not to GROUP21 or GROUP22.
• tperrno is set to TPENOENT
• tperrordetail is set to the new value TPED_GROUP_FORBIDDENFor each RAC configuration defined as part of the TUXRACGROUPS environment variable, Tuxedo determines which RAC group(s) in that configuration participate in a particular transaction when that transaction is started.
• Transactions created in a group listed inside TUXRACGROUPS are pinned to the Oracle RAC instance configured via TUXRACGROUPS.
• Transactions created in groups not listed inside TUXRACGROUPS are pinned to one of the available Oracle RAC instances in a load-balancing-like algorithm.Data dependent routing has been extended to support Oracle RAC configurations. It is possible to define multiple groups for the same routing range in the UBBCONFIG *ROUTING section. Listing 6‑2 shows an example of different Tuxedo groups with the same range of values.Listing 6‑2 Tuxedo Groups with Same Range ValuesIn this example, GROUP1A and GROUP1B are responsible for the same data range and GROUP2A and GROUP2B are responsible for the same data range. Tuxedo routes the service request to the group associated with the Oracle RAC instance that the transaction belongs to.
•
•
• Multiple RANGES entries for each routing value must be created for each RAC instance offering the service.If a routing was not configured for a special RAC instance a service calls for a transaction pinned to that Oracle RAC Instance will fail with tperrno set to TPENOENT and tperror detail set to TPED_GROUP_FORBIDDEN.If routing is performed for a non-transactional request, all groups can participate. The service is routed to the first group matching the data value listed in the UBBCONFIG file *ROUTING section RANGES field. All non-transactional requests for a special range of values are handled by one Oracle RAC instance only.
• Calling an intermediate AUTOTRAN service (in the UBBCONFIG file *SERVICES section) to enforce that each service call is associated with a transaction.Figure 6‑4 shows an example of routing transactional and non-transactional requests in an Oracle RAC configuration.The configuration shown in the example consists of 2 Oracle RAC instances. If 1,000 transactions are created in a group not listed in TUXRACGROUPS, around 500 transactions will be pinned to Oracle RAC instance 1 and can only access GROUP1A and GROUP2A. The other 500 transactions will be pinned to Oracle RAC instance 2 and can only access GROUP1B and GROUP2B.Listing 6‑3 shows an example of how the *SERVICES and *ROUTING sections of the UBBCONFIG file for this configuration might look:GROUP1A and GROUP2A belong to Oracle RAC instance 1. GROUP1B and GROUP2B belong to Oracle RAC instance 2. Requests with a BRANCH_ID 1 through 5 must be handled by GROUP1A or GROUP1B. Requests with a BRANCH_ID 6 through 10 must be handled by GROUP2A or GROUP2B.For transactional requests, all transactions pinned to Oracle RAC instance 1; branches 1-5 map to GROUP1A and branches 6-10 map to GROUP2A. The other half is assigned to Oracle RAC instance 2; branches 1-5 map to GROUP1B and branches 6-10 map to GROUP2B.For non-transactional requests, branches 1-5 map to GROUP1A, and branches 6-10 map to GROUP2B. These are the first groups specified that match the respective routing ranges. Requests with an invalid BRANCH_ID are mapped to any permitted group.Figure 6‑5 shows an example with, machine 1 serving GROUP1A and GROUP2A; machine 2 serving GROUP1B and GROUP2B. In addition, calls might be made and transactions might be created from a Tuxedo /Domain Gateway, for Tuxedo /WS clients, Tuxedo Native Clients, Tuxedo /Q, or any server linked with another Resource Manager such as MQ Series.Listing 6‑4 shows a UBBCONFIG file example with two physical machines, TUXM1 and TUXM2, running Tuxedo. Both machines have two groups connecting to an Oracle RAC. Groups GROUP1A and GROUP2A are running on machine TUXM1 connecting to RAC instance 1. Groups GROUP1B and GROUP2B are running on machine TUXM2 connecting to RAC instance 2.Listing 6‑4 UBBCONFIG File ExampleAdditionally, there is a group for administrative services, as well as one group for Tuxedo /Domain gateways and one group for native Tuxedo clients on both machines. All transactions are created by GWTDOMAIN and native clients. Even if GWTDOMAIN and the native Tuxedo clients never connect to an Oracle RAC directly, they must be included in TUXRACGROUPS as shown in Listing 6‑5 to ensure that the opened transactions belong to the correct RAC instance and are handled locally.
Note: Native clients must set tpinfo->grpname to the local group to ensure the right behavior. For more information, see Avoiding Transactions Created by Tuxedo Native Clients Being Sent to a Remote Machine on page 6‑19.Listing 6‑5 TUXGROUPSWhat an administrator always has to ensure is that he includes all service groups into the TUXRACGROUPS environment variable that are accessed during the call flow and that are candidates for opening a new transaction even if they are not linked with the Oracle RM and/or are not physically associated with any Oracle RAC instance. The environment variable TUXRACGROUPS does not have any impact for non-transactional service calls.If you have a Tuxedo server built with another RM such as MQSeries or another database, you can force newly started transactions to be pinned to your local machine by including this group into the TUXRACGROUPS environment variable as well.Listing 6‑6 MQSeries ExampleIn this example MQSGROUPA, GROUP1A and GROUP2A are located on machine 1 and MQSGROUPB, GROUP1B and GROUP2B are located on machine 2.If a server inside group MQSGROUPA creates a transaction, all Tuxedo service calls for services under groups GROUP1A, GROUP2A, GROUP1B and GROUP2B will only go to GROUP1A and GROUP2A. GROUP1B and GROUP2B are ignored as they belong to RAC instance 2 and the transaction was already created for RAC instance 1 via group MQSGROUPA.Create on local Tuxedo /Domain Gateway on each machine. Set the TUXRACGROUPS environment variable as shown in Listing 6‑7.Listing 6‑7 GWTDOMAIN ExampleIn this example GWTGROUPA, GROUP1A and GROUP2A are located on machine 1 and GWTGROUPB, GROUP1B and GROUP2B are located on machine 2.If GWTDOMAIN on machine 1 creates a new transaction because it receives an external request, all Tuxedo service calls for services under groups GROUP1A, GROUP2A, GROUP1B and GROUP2B will only go to GROUP1A and GROUP2A. GROUP1B and GROUP2B are ignored as they belong to RAC instance 2 and the transaction was already created for RAC instance 1 via group GWTGROUPA.Create a local Tuxedo /Q configuration on each machine. Set your TUXRACGROUPS environment variable as shown in Listing 6‑8.Listing 6‑8 TMQFORWARD ExampleIn this example QUEUEGROUPA, GROUP1A and GROUP2A are located on machine 1 and QUEUEGROUPB, GROUP1B and GROUP2B are located on machine 2.If TMQFORWARD on machine 1 transactionally forwards a new message to such an Oracle service, all Tuxedo service calls for services under groups GROUP1A, GROUP2A, GROUP1B and GROUP2B will only go to GROUP1A and GROUP2A. GROUP1B and GROUP2B are ignored as they belong to RAC instance 2 and the transaction was already created for RAC instance 1 via group QUEUEGROUPA.You can also bind native clients to a special server group. You just have to build the client using the command buildclient -r <RM_of_the_group> -f <source_file> -o <binary_file> and initiate tpinit() with the group name that you want to use.For example, you can create two additional groups CLIENTGROUPA and CLIENTGROUPB,and start at least two TMS in each group. Set your TUXRACGROUPS environment variable as shown in Listing 6‑9.Listing 6‑9 Remote Machine ExampleWhenever you initiate tpinit(TPINIT *tpinfo) with a TPINIT structure where tpinfo->grpname is set to CLIENTGROUPA the client is associated with CLIENTGROUPA. When tpinfo->grpname is set to CLIENTGROUPB, the client is associated with CLIENTGROUPB.Native clients on machine 1 should always call tpinit() with tpinfo->grpname = CLIENTGROUPA; native clients on machine 2 should always call tpinit() with tpinfo->grpname = CLIENTGROUPB if CLIENTGROUPA is running on machine 1 and CLIENTGROUPB is running on machine 2. When a Tuxedo Native Client calls tpbegin(), the transaction is associated with RAC instance 1 in case of CLIENTGROUPA and with RAC instance 2 in case of CLIENTGROUPBThe grpname value must be the NULL string (0-length string) for Workstation clients. You cannot set any group name and you cannot pin /WS clients to special groups. tpbegin() inside the Tuxedo /WS clients is always unspecified and the opened transaction is distributed in equal parts over all RAC instances.The best practice to use with Tuxedo /WS Clients is to avoid transaction handling on the client side, and start the transaction with the first server that is called by the Tuxedo /WS Client. For example, you can automatically force creating a transaction when setting the AUTOTRAN parameter for the called service in the UBBCONFIG file *SERVICES section.TMS_rac_refresh(1), XARETRYDURATIONSECONDS, and XARETRYINTERVAL specifically handle transaction recovery issues.TMS_rac_refresh(1)is called when an Oracle RAC group fails over to an alternate group. TMS_rac_refresh(1) should not be executed manually from the command line; the proper way to invoke TMS_rac_refresh(1) is to use Oracle Fast Application Notification (FAN).The XARETRYDURATIONSECONDS and XARETRYINTERVAL environment variables are used to retry transaction recovery operations (xa_recover()) as required by Oracle RAC.Specifies the time interval during which the Tuxedo Transaction Manager Server (TMS) retries xa_recover() operations when TMS_rac_refresh(1) is called. If it is not set or set to 0, then xa_recover() is performed once only.
Note: Specifies the interval in seconds that xa_recover() operations are retried during the XARETRYDURATIONSECONDS interval. The XARETRYINTERVAL value is relevant only if XARETRYDURATIONSECONDS is set to a value greater than 0.A key process in configuring Tuxedo for Oracle RAC is setting up Oracle FAN to invoke TMS_rac_refresh(1) with the appropriate group parameter on group failover. (More group parameter and group failover information is provided in Configuring Transaction Propagation.)More information regarding Oracle FAN can be found in the Workload Management with Oracle Real Application Clusters (PDF) White Paper.Listing 6‑10 is an example of an Oracle FAN script.Listing 6‑10 Oracle FAN Script ExampleFor Oracle 10gR2, it is much simpler to configure transaction recovery. The database services specified in the OPENINFO string for each group associated with Oracle RAC should be declared in Oracle as DTP services.For example, in Listing 6‑1, GROUP1 accessed Oracle via service ORA1SITE1 and GROUP2 accessed Oracle via service ORA1SITE2. In Oracle 10gR2, service ORA1SITE1 should be declared with DTP=TRUE, with preferred instance SITE1, and with available instance SITE2. Service ORA1SITE2 should be declared with DTP=TRUE, with preferred instance SITE2, and with available instance SITE1. A similar process should be followed for groups GROUP3, GROUP4, and GROUP5.The setting of the TUXRACGROUPS environment variable will ensure that different instances of the RAC configuration are not combined in the same transaction in order to obtain optimal performance. If one of the RAC instances goes down, Oracle will transfer the DTP service to the non-preferred instance while maintaining transactional integrity.When using Oracle 10gR2 DTP services, it is not necessary and is not recommended to configure Oracle FAN, use TMS_rac_refresh(1) or set the XARETRYDURATIONSECONDS or XARETRYINTERVAL environment variables.Although the Tuxedo Oracle RAC environment variables can be initiated at the operating system command line, it is highly recommended that you use the ENVFILE parameter specified in the *MACHINES section of the UBBCONFIG file to initiate these environment variables.
• When Tuxedo environment variables are set using ENVFILE, which is the preferred method, quotation marks are not permitted around the environment variable value.
• If environment variables are set at the command line, quotation marks are required if environment variable values contain characters that could be interpreted as special by the command line interpreter. An example of a special character is a semicolon.
•