Logging Last Resource Transaction Optimization

This topic includes the following sections:

•

Overview

•	Logging Last Resource Configurations

•	Lazy Deletion on TLOG Records of Completed LLR Transactions

•	Constrains and Limitations

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.

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

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.

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

LLR XA Switch Name	Format
tuxllr_oraesql	ORACLE_XA{+required_fields...} [+optional_fields...] 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.

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  

…

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 20‑2 Configuring the RM File

tuxllr_oraesql:tuxllrsw_oraesql: -lllroraesql -L${ORACLE_LIB} -lclntsh

 

Listing 20‑3 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 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.

Note:

A ".llr" directory is created under $APPDIR to store temporary files used by LLR.

Constrains and Limitations

•

General

•	Like a normal XA server, the customer codes in an LLR server should 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 the GROUP section

•	LLR server does not support tpsuspend and tpresume

•	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 needs to retrieve possible TLOG records from the LLR tables of all related non-XA resources.

•	Only Linux 64-bit platform is supported

•	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 property Threads in the OPENINFO. 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.