20 Logging Last Resource Transaction Optimization
This topic includes the following sections:
20.1 Overview
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:
- Calls prepare on all other (XA-compliant) transaction participants.
- Inserts a commit record to a table on the LLR participant (rather than to the file-based transaction log).
- Commits the LLR participant's local transaction (which includes both the transaction commit record insert and the application's SQL work).
- Calls commit on all other transaction participants.
- After the transaction completes successfully, lazily deletes the database transaction log record as part of a future transaction.
In the recovery, the transaction records left in the LLR table are taken as completing transactions.
Parent topic: Logging Last Resource Transaction Optimization
20.2 Logging Last Resource Configurations
- Configuring LLR Library in RM File
- Configuring OPENINFO in UBBCONFIG File
- Configuring LLR Options in UBBCONFIG File
- Building LLR Server/TMS
- Typical Configuration Example
Parent topic: Logging Last Resource Transaction Optimization
20.2.1 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 following table shows the LLR library details:
Table 20-1 LLR Library
LLR XA Switch Name | LLR XA Switch Variable | Link Options | RM | Implementation | LLR Library |
---|---|---|---|---|---|
tuxllr_oraesql
|
tuxllrsw_oraesql
|
-lllroraesql -L${ORACLE_LIB}-lclntsh
|
Oracle | Embedded SQL | $ {TUXDIR}/lib/libllroraesql.so
|
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.
Parent topic: Logging Last Resource Configurations
20.2.2 Configuring OPENINFO in UBBCONFIG File
Configure OPENINFO
in the UBBCONFIG
file in the following
format:
[LLR XA switch name]:[open string]
The following table shows the details.
Table 20-2 OPENINFO Format
LLR XA Switch Name | Format |
---|---|
tuxllr_oraesql
|
For more information about SqlNet, Acc and DB, refer to Oracle online document.
|
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.
Parent topic: Logging Last Resource Configurations
20.2.3 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 thatSCANUNIT * LLR_DELDELAY
is approximately 30 seconds, however, if theSCANUNIT
value is greater than 30 seconds,LLR_DELDELAY
is set to 1 if not specified.
Parent topic: Logging Last Resource Configurations
20.2.4 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.
Parent topic: Logging Last Resource Configurations
20.2.5 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
…
EXEC SQL INCLUDE sqlca;
EXEC SQL BEGIN DECLARE SECTION;
char mylog[200];
int mypid;
EXEC SQL END DECLARE SECTION;
int tpsvrinit(int argc, char *argv[])
{
tpopen();
mypid=getpid();
return(0);
}
void tpsvrdone()
{
tpclose();
}
void ECHO(TPSVCINFO *rqst)
{
strncpy(mylog, rqst->data,rqst->len);
mylog[rqst->len-1] = 0;
EXEC SQL INSERT INTO TUX_RAC_TAB(OWNER, DATA) VALUES(:mypid,
:mylog);
tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);/*do not commit the local
transaction*/
}
…
Listing Configuring the RM File
tuxllr_oraesql:tuxllrsw_oraesql: -lllroraesql -L${ORACLE_LIB} -lclntsh
Listing Configuring UBBCONFIG
*RESOURCE
…
MODEL SHM
SCANUNIT 5
MAXGTT 600
LLR_DELDELAY 6
LLR_DELSWAPSIZE 500
…
*MACHINES
“m1” LMID=L1 TLOGSIZE=100
…
*GROUPS
GRP1 LMID=L1 GRPNO=10 TMSNAME="TMS_LLRORAESQL" TMSCOUNT=2
OPENINFO="tuxllr_oraesql:ORACLE_XA+SqlNet=orcl.tux1+ACC=P/scott/tiger”
…
server1 SRVGRP=GRP1 SRVID=10
…
Listing 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
…
Parent topic: Logging Last Resource Configurations
20.3 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 (for example, 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.
Note:
A ".llr
" directory is created under $APPDIR
to store temporary files used by LLR.
Parent topic: Logging Last Resource Transaction Optimization
20.4 Constrains and Limitations
- General
- Like a normal XA server, the customer codes in an LLR server must manage the connection through
tpopen/tpclose
. - Only one LLR server can be involved in a global transaction.
- According to the MRM group, the
OPENINFO
used by the LLR server must be specified in theGROUP
section. - LLR server does not support
tpsuspend
andtpresume
. - According to MP domain, the slave node using an Oracle Tuxedo release that does not support LLR fails to boot up if LLR is enabled.
- BBL spends more time than usual to boot up if some LLR groups are specified because BBL retrieves possible TLOG records from the LLR tables of all related non-XA resources.
- Only Linux 64-bit platform is supported.
- Like a normal XA server, the customer codes in an LLR server must manage the connection through
- RM-Specific (specific to
libllroraesql
)- Multi-threaded LLR server is not supported
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 propertyThreads
in theOPENINFO
. Otherwise the SQL jobs on LLR connection in the application server cannot work. - An LLR server cannot handle any new request before current local transaction is finished.
- Multi-threaded LLR server is not supported
Parent topic: Logging Last Resource Transaction Optimization