Auto-tuning: Shutting down background process GTXd
Thu Jun 13 06:30:32 2013
Auto-tuning: Shutting down background process GTXc
Thu Jun 13 06:40:33 2013
Auto-tuning: Shutting down background process GTXb
Thu Jun 13 06:50:38 2013
Auto-tuning: Shutting down background process GTXa
Thu Jun 13 07:01:17 2013
Auto-tuning: Shutting down background process GTX9
Thu Jun 13 07:11:18 2013
Auto-tuning: Shutting down background process GTX8
Thu Jun 13 07:13:53 2013
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
http://docs.oracle.com/cd/E11882_01/rac.112/e16795/hafeats.htm#RACAD8287
Overview of XA Transactions and DTP Services
An XA transaction can span Oracle RAC instances by default, allowing any application that uses the Oracle XA library to take full advantage of the Oracle RAC environment to enhance the availability and scalability of the application.
GTXn background processes support global (XA) transactions in an Oracle RAC environment. The GLOBAL_TXN_PROCESSES initialization parameter, which is set to 1 by default, specifies the initial number of GTXn background processes for each Oracle RAC instance. Use the default value for this parameter clusterwide to allow distributed transactions to span multiple Oracle RAC instances. Using the default value allows the units of work performed across these Oracle RAC instances to share resources and act as a single transaction (that is, the units of work are tightly coupled). It also allows 2PC requests to be sent to any node in the cluster.
Before Oracle RAC 11g release 1 (11.1), the way to achieve tight coupling in Oracle RAC was to use Distributed Transaction Processing (DTP) services, that is, services whose cardinality (one) ensured that all tightly-coupled branches landed on the same instance—regardless of whether load balancing was enabled. Tightly coupled XA transactions no longer require the special type of singleton services to be deployed on Oracle RAC databases if the XA application does not join or resume XA transaction branches. XA transactions are transparently supported on Oracle RAC databases with any type of service configuration.
Note:
Oracle RAC 11g release 1 (11.1) and later does not require a DTP service but performance might be improved if you use a DTP service, as described in "Benefits of DTP Services for XA Transactions".An external transaction manager, such as Oracle Services for Microsoft Transaction Server (OraMTS), coordinates DTP/XA transactions. However, an internal Oracle transaction manager coordinates distributed SQL transactions. Both DTP/XA and distributed SQL transactions must use the DTP service in Oracle RAC.
See Also:
-
Oracle Database Advanced Application Developer's Guide for complete information about using Oracle XA with Oracle RAC
-
Oracle Database Reference for information about the GLOBAL_TXN_PROCESSES initialization parameter
Benefits of DTP Services for XA Transactions
To provide improved application performance with distributed transaction processing in Oracle RAC, you may want to take advantage of DTP services. Using DTP services, you can direct all branches of a distributed transaction to a single instance in the cluster. To load balance across the cluster, it is better to have several groups of smaller application servers with each group directing its transactions to a single service, or set of services, than to have one or two larger application servers.
In addition, connection pools at the application server tier that load balance across multiple connections to an Oracle RAC database can use this method to ensure that all tightly-coupled branches of a global distributed transaction run on only one Oracle RAC instance. This is also true in distributed transaction environments using protocols such as X/Open Distributed Transaction Processing (DTP) or the Microsoft Distributed Transaction Coordinator (DTC).
To enhance the performance of distributed transactions, you can use services to manage DTP environments. By defining the DTP property of a service, the service is guaranteed to run on one instance at a time in an Oracle RAC database. All global distributed transactions performed through the DTP service are ensured to have their tightly-coupled branches running on a single Oracle RAC instance. This has the following benefits:
-
The changes are available locally within one Oracle RAC instance when tightly coupled branches need information about changes made by each other
-
Relocation and failover of services are fully supported for DTP
-
By using more DTP services than there are Oracle RAC instances, Oracle Database can balance the load by services across all of the Oracle RAC database instances
|
GTXn |
Global Transaction Process |
Provides transparent support for XA global transactions in an Oracle RAC environment |
These processes help maintain the global information about XA global transactions throughout the cluster. Also, the processes help perform. two-phase commit for global transactions anywhere in the cluster so that an Oracle RAC database behaves as a single system to the externally coordinated distributed transactions. The GLOBAL_TXN_PROCESSES initialization parameter specifies the number of GTXn processes, where n is 0-9 or a-j. The database automatically tunes the number of these processes based on the workload of XA global transactions. You can disable these processes by setting the parameter to 0. If you try to run XA global transactions with these process disabled, an error is returned. |