Table of Contents Previous Next PDF

Logging Last Resource Transaction Optimization

Logging Last Resource Transaction Optimization
This topic includes the following sections:
Logging Last Resource (LLR) transaction optimization is a performance enhancement option that enables a non-XA resource to participate in a global transaction.
The LLR resource uses a local transaction for its transaction work. The Oracle Tuxedo transaction manager prepares all other resources in the transaction and determines the commit decision for the global transaction based on the outcome of the LLR resource's local transaction.
In a global two-phase commit (2PC) transaction with an LLR participant, the Oracle Tuxedo transaction manager follows these basic steps:
In the recovery, the transaction records left in the LLR table are taken as completing transactions.
Logging Last Resource Configurations
Configuring LLR Library in RM File
The LLR library provides an XA switch to emulate XA operations and several uniform APIs for LLR server/TMS. Configure LLR library in the RM file under ${TUXDIR}/udataobj as follows:
[LLR XA switch name]:[LLR XA switch variable]:[Link options]
The Table 20‑1 shows the LLR library details:
Table 20‑1 LLR Library
In general, the LLR XA switch variable is tuxllrsw_[name] and the LLR XA switch name is tuxllr_[name]. The related library name is libllr[name], where [name] consists of RM ID and implementation ID. For example, ora indicates Oracle database, and esql indicates embedded SQL.
Configuring OPENINFO in UBBCONFIG File
Configure OPENINFO in the UBBCONFIG file in the following format:
[LLR XA switch name]:[open string]
The Table 20‑2 shows the details.
Table 20‑2 OPENINFO Format
TuxLLR is a specific optional field for Tuxedo LLR, which defines the LLR table name. If not defined, the default name is used.
The LLR table is used to store the committing TLOG for transactions that involves LLR server. The default table name is TUXLLR_[DOMAINID]. If [DOMAINID] is empty, DOM is used. When you specify the LLR table name using TuxLLR, make sure different LLR tables are used for different tuxedo domains in a same non-XA resource; otherwise the recovery might work incorrectly.
In addition, ensure the RM user account used by LLR switch has the privilege to create and update the LLR table. Otherwise, errors might occur.
For example, a user might get the following message in Oracle database:
ORA-01950: no privileges on tablespace 'string'
This is because the user does not have privilege to allocate an extent in the specified tablespace. To solve the issue, grant the user appropriate system privilege or grant the user space resource on the tablespace.
Configuring LLR Options in UBBCONFIG File
LLR_DELSWAPSIZE numeric_value
Specifies the maximum completed LLR involved 2PC global transaction ID (gtrid) that can be stored in the swap area. By default, the value is 0. To enable LLR feature, specify a positive value.
LLR_DELDELAY numeric_value
Specifies a multiplier of the basic SCANUNIT between LLR completed records lazy deletions. The value must be greater than 0. If this parameter is not specified, the default is set so that SCANUNIT * LLR_DELDELAY is approximately 30 seconds, however, if the SCANUNIT value is greater than 30 seconds, LLR_DELDELAY is set to 1 if not specified.
Building LLR Server/TMS
Oracle Tuxedo takes an XA switch as a Oracle Tuxedo-specific LLR XA switch if the XA switch name prefix is tuxllr_.
As long as an application server is built with the LLR XA switch, Oracle Tuxedo treats it as an LLR server. The TMS servers built with the same LLR XA switch in the same group are treated as LLR TMS. The group that LLR server belongs to is an LLR group. The transaction involving an LLR server is an LLR involved transaction. The TLOG record of this transaction is stored in the LLR table instead of Oracle Tuxedo traditional TLOG file.
An LLR server/TMS must use the correct LLR XA switch. It means the RM and the implementation must be the same as the LLR library that provides the XA switch.
Typical Configuration Example
Following is an example of the LLR server (server.pc), which uses the embedded SQL to insert a record into an Oracle database table within a local transaction.
Listing 20‑1  
char mylog[200];
int mypid;
int tpsvrinit(int argc, char *argv[])
void tpsvrdone()
void ECHO(TPSVCINFO *rqst)
strncpy(mylog, rqst->data,rqst->len);
mylog[rqst->len-1] = 0;
tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);/*do not commit the local transaction*/
Listing 20‑2 Configuring the RM File
tuxllr_oraesql:tuxllrsw_oraesql: -lllroraesql -L${ORACLE_LIB} -lclntsh
Listing 20‑3 Configuring UBBCONFIG
server1 SRVGRP=GRP1 SRVID=10
Listing 20‑4 Building LLR Servers and TMS
${PROC} ${PROCFLAGS} iname=server.pc
buildserver -r tuxllr_oraesql -o server1 -f server.c
buildtms -r tuxllr_oraesql -o TMSLLRORAESQL
Lazy Deletion on TLOG Records of Completed LLR Transactions
The TLOG records of completed 2PC global transaction IDs (gtrid) in LLR table are purged in a lazy way. The purge is based on a timer. You can configure it using the parameter LLR_DELDELAY.
A new introduced swap area in BB is used to temporarily store the completed LLR involved gtrids. BBL may move these gtrids in the swap area to each local cache scan unit and purge the corresponding TLOG records in the LLR table according to the gtrids when time is out. You can specify the swap area size using the attribute LLR_DELSWAPSIZE.
If the swap area is too small, the completed gtrids that cannot be stored in the swap area at that time are cached by the related coordinator TMS process temporarily.
Unexpected node crash (e.g. BB is lost) leaves the completed records in the LLR table that does not be purged in time. Each record needs on entry in the transaction table during Tuxedo recovery. The transaction table size in BB is specified by MAXGTT. If MAXGTT is not big enough to store these records, BBL fails to boot up when the node is restored. When that happens, increase the MAXGTT value and retry.
It is recommended that specifying a sufficient LLR_DELSWAPSIZE to accommodate at least all completed LLR involved 2PC gtrids in a scan unit.
BBL does not purge the completed gtrids records in the LLR table. It invokes the system supplied LLR helper process to do this job. The process can also help BBL to retrieve records in LLR data during Tuxedo recovery.
A ".llr" directory is created under $APPDIR to store temporary files used by LLR.
Constrains and Limitations
According to the MRM group, the OPENINFO used by the LLR server must be specified in the GROUP section
LLR server does not support tpsuspend and tpresume
The simulating XA switch tuxllrsw_oraesql does not support thread context. According to LLR involved MRM group, the other XA connections to Oracle database should not enable the property Threads in the OPENINFO. Otherwise the SQL jobs on LLR connection in the application server cannot work.

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.