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:
|
|
•
|
TUXRACGROUPS (required for Oracle 10gR1 and 10gR2, optional for Oracle 11g)
|
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.
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.
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:
TUXRACGROUPS="G1,G2,…,Gm;H1,H2,…,Hn[;…]:I1,I2,…,Io;J1,J2,…,Jp[;…][:…]"
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.
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‑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.
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.
In 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.
|
Figure 6‑4 shows an example of routing transactional and non-transactional requests in an Oracle RAC configuration.
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.
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.
In 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.
In this example GWTGROUPA,
GROUP1A and
GROUP2A are located on machine 1 and
GWTGROUPB,
GROUP1B and
GROUP2B are located on machine 2.
In this example QUEUEGROUPA,
GROUP1A and
GROUP2A are located on machine 1 and
QUEUEGROUPB,
GROUP1B and
GROUP2B are located on machine 2.
Whenever 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 t
pinfo->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
CLIENTGROUPB
The 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. t
pbegin() inside the Tuxedo /WS clients is always unspecified and the opened transaction is distributed in equal parts over all RAC instances.
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 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.
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.
|
•
|
“Writing Global Transactions” in Programming an Oracle Tuxedo ATMI Application Using C
|
