TRAN. Distributed Transactions

Transcription

1 Module Distributed Transactions At the end of this module you will be able to understand characteristics of a distributed transaction list the Tuxedo components that support distributed transactions identify the Tuxedo configuration file entries required to support distributed transactions understand the operational aspects of transaction support -1 Copyright -1

2 ƒ ƒ ƒ Map Distributed Transactions Overview Configuration and Administration Lab Workshop -2 Copyright -2

3 Section 1 Transactions Overview At the end of this section you will understand the more formal definition of a transaction understand characteristics of a distributed transaction be familiar with Tuxedo transaction support -3 Copyright -3

4 When Transactions are Needed :KHQDWUDQVDFWLRQLQWHUDFWVZLWKDVLQJOHGDWDEDVHRQO\ W\SLFDOO\WKHGDWDEDVHLWVHOIZLOOPDQDJHWKHWUDQVDFWLRQ Client SERVER DATABASE $WUDQVDFWLRQLQYROYLQJPXOWLSOHGDWDEDVHVQHHGVD WUDQVDFWLRQPDQDJHUWRFRRUGLQDWHWKHWUDQVDFWLRQ DFWLYLW\DPRQJWKHGDWDEDVHVRUGDWDEDVHLQVWDQFHV 7KHZRUNGRQHZLWKLQWKHGLVWULEXWHGWUDQVDFWLRQLV GHILQHGE\EHJLQDQGHQGWUDQVDFWLRQLQGLFDWRUV SERVER ORACLE Client 7UDQVDFWLRQÃ%RXQGDU\ SERVER DB2-4 Transactions are appropriate in the situations described below. Each situation describes a transaction model. Within the scope of a client service request, the server performs multiple updates to data in a database. If one of the updates fails, the server needs a mechanism to roll back previous related updates. For example, consider a banking application. The client requests the funds transfer service. The transfer service requires the server to make the following operations on the bank database: 1) Invoke the debit method on one account. 2) Invoke the credit method on another account. If the credit invocation on the bank database fails, the banking application needs a way to roll back the previous debit invocation. This example may or may not use the Tuxedo system transaction support as it could use the database transaction commands directly since only one database is involved. The client application needs to makes a service request, which may involve server write/update operations to multiple databases. If any one invocation is unsuccessful, any state that is written (either in memory or, more typically, to a database) must be rolled back. For example, consider the previous example debiting an account at one bank branch using a local branch database, and crediting another branch account using it s own local database. This example could use Tuxedo transaction support because multiple databases are involved. A transaction is started (begin), work is performed, and a decision is made to perform all (commit) or none (abort) of the work performed so far. The same applies to a distributed transaction. The difference is in who manages the transaction all-or-nothing property. Copyright -4

5 The XA Standard ƒ The Extended Architecture (XA) is the standard-defined interface between the Transaction Manager and the Resource Manager ƒ XA allows program control of Resource Managers that are involved in distributed transactions ƒ It is widely supported in all the major database vendor products -5 The XA standard was originally defined by an industry standards group, the X/Open group. Copyright -5

6 XA Resource Manager ƒ Storage mechanisms are referred to as application resources ƒ In XA terminology, application resources are accessed via a Resource Manager (RM) Server Resource Manager Application Resource (anything that supports XA) -6 Resource managers are software tools which are typically provided by the vendor of the storage mechanism, such as Oracle, Sybase, DB2, etc. Some are available from third party vendors. Software vendors provide documentation that specifies the configuration and login information required to open a database connection via the XA protocol. Copyright -6

7 Two-Phase Commit ƒ XA uses a Two-Phase Commit protocol to support Distributed Transactions ƒ The Transaction Manger manages the transaction (on behalf of the application) ¾ requests the participating RM s to prepare to commit the transaction ¾ if all RM s respond OK, the Transaction Manager then tells all of them to commit ¾ if any of the RM s responds No, the Transaction Manager then tells other RM s to abort (roll back their part of the transaction) -7.The XA standard has been widely adopted as the industry standard for two-phase commit protocol. Copyright -7

8 Transactions in Tuxedo ƒ Tuxedo supports distributed transactions ¾ generates a global transaction identifier (GTRID) understood by all participants ¾ tracks active transactions through the TLOG ¾ provides access notification to RM s ¾ coordinates the two-phase commit to ensure participants commit simultaneously ¾ initiates recovery when failures occur ƒ Multiple Transaction Managers (TM) may be involved, each specifically built to communicate with a particular RM -8 Tuxedo provides the following support for your business transactions: Creates a global transaction identifier (GTRID) when a client application initiates a transaction. Tracks active transactions through the Tuxedo transaction log (TLOG) Notifies the resource managers which are, most often, databases when they are accessed on behalf of a transaction. Resource managers then lock the accessed records until the end of the transaction. Manages the two-phase commit when the transaction completes, which ensures that all the participants in the transaction commit their updates simultaneously. It coordinates the commit with any databases that are being updated using Open Group s XA protocol. Almost all relational databases support this standard. Executes the rollback procedure when the transaction must be aborted. Executes a recovery procedure when failures occur. It determines which transactions were active in the machine at the time of the crash, and then determines whether the transaction should be rolled back or committed. Copyright -8

9 Transaction Manager Server and XA 64/ ;,' 50 '%06 ;,' precommit commit abort 78;('2à 7UDQVDFWLRQà /RJ 7/2* Server XA open ATMI 706 XA close XA *75,' 7KHÃFOLHQWÃLQLWLDWHGà WKHÃWUDQVDFWLRQ &OLHQW *75,' begin commit abort 706ÃLVÃFXVWRPÃEXLOWà IRUÃDÃVSHFLILFÃ50à 7X[HGRÃSURYLGHVÃWKHà QXOOó706 ÃDQGÃWKHà 48(8(ó706B40-9 The slide shows the client as the initiator of the transaction. The application client uses ATMI to begin, commit, and abort transactions involving multiple resources. The server uses an embedded SQL interface to the RM to read/update the database accessed by the server group. The TMS and RM use the XA interface to coordinate the work in a global transaction. A server can also initiate transactions. XID is the GTRID-equivalent that is used by the XA protocol.tuxedo uses the GTRID between Tuxedo processes and the XID to communicate to the RM s - Tuxedo maps the GTRID to the XID. Coordination of transactions is performed by a separate server called the Transaction Management Server (TMS). Copyright -9

10 Multiple Server DTP Using XA 64/;$ ;,' 50 '%06 ;,' 7/2* withdrawal 706 *75,' &OLHQW 7KHÃFOLHQWÃLQLWLDWHGÃ WKHÃWUDQVDFWLRQ *75,' deposit 706 ;,' 64/;$ 50 '%06 ;,' 7/2* -10 In the diagram, note that the GTRID is passed between the Tuxedo components and is also passed along with any database operation. Copyright -10

11 Two-Phase Commit (Complete Return) WLPH,QLWLDWRU $SSOLFDWLRQUHTXHVWV FRPPLW 3+$6( 3+$6( $SSOLFDWLRQFRPPLW FDOOUHWXUQV 706 &RRUGLQDWRU 706VHQGV SUHFRPPLWPHVVDJH 706UHFHLYHV DFNQRZOHGJHPHQWV 706ZULWHV *75,'WR7/2* 706WHOOVDOO50V WRFRPPLW 706UHWXUQVFRQWURO WRDSSOLFDWLRQ 50V 3DUWLFLSDQWV 6LWHVSUHFRPPLW DQGDFNQRZOHGJH 506VFRPPLW -11 Global Two-Phase Commit In the two-phase commit process, the application is the initiator of the commit. The request is sent from the initiator, through a tpcommit(3c) call, to the Transaction Manager Server (TMS) which acts as the coordinator. The TMS, in turn, communicates with all the RMs that are participants in the transaction. The steps for a global commit are as follows: A commit is requested by the application. The coordinator TMS sends requests to the TMS in each group which has an RM associated with the transaction. Each TMS then issues an RM precommit call. The RMs all attempt to precommit. Precommitting means making the changes in a recoverable manner (that is, copying them to stable storage without committing). Each subordinate TMS sends a response back to the TMS, letting it know if the precommit succeeded or failed. If any precommit attempt failed or any group fails to respond, the TMS tells all RMs to abort their local transactions. If all precommit attempt succeeded, the TMS logs an entry in the transaction log (TLOG), which facilitates a recovery of the transaction, if necessary. The log entry includes the GTRID and a list of all RM groups participating in the transaction. Completed Return The coordinating TMS then tells the subordinate TMS to commit their transactions. When all RMs have reported a successful commit, the commit call returns. The commit function call will not return control to the application until the second phase has completed. Copyright -11

12 Two-Phase Commit (Logged Return) WLPH,QLWLDWRU $SSOLFDWLRQUHTXHVWV FRPPLW $SSOLFDWLRQFRPPLW FDOOUHWXUQV 706 &RRUGLQDWRU 706UHFHLYHV DFNQRZOHGJHPHQWV 706ZULWHV *75,'WR7/2* 706WHOOVDOO50V WRFRPPLW 50V 3DUWLFLSDQWV 706VHQGV SUHFRPPLWPHVVDJH 6LWHVSUHFRPPLW DQGDFNQRZOHGJH 3+$6( 3+$6( 506VFRPPLW -12 Logged Return The commit function call will return control to the application after the first phase has completed. Most databases will flush/write their transaction log to disk allowing them to commit or rollback their part of the transaction after a failure. Copyright -12

13 ƒ ƒ ƒ Map Distributed Transactions Overview Configuration & Administration Lab Workshop -13 Copyright -13

14 Section 2 Configuration & Administration At the end of this section you will be able to identify the configuration components related to Tuxedo transaction support configure Tuxedo to support a transactional application -14 Copyright -14

15 Configuring Transaction Support ƒ These sections and parameters can be configured to add transaction support Section RESOURCES MACHINES Parameter MAXGTT CMTRET TLOGNAME TLOGDEVICE TLOGSIZE Description OLPLWVWKHWRWDOQXPEHURIJOREDOWUDQVDFWLRQV FRQILJXUHVHDUO\RUODWHFRPPLW;$LPSOHPHQWDWLRQ QDPHRIWKHWUDQVDFWLRQORJ7/2* GROUPS SERVICES TMSNAME TMSCOUNT OPENINFO CLOSEINFO AUTO TIME WUDQVDFWLRQPDQDJHPHQWVHUYLFH706 QXPEHURI706VHUYHUFRSLHVWRERRW VWULQJWRRSHQ5HVRXUFH0DQDJHUGDWDEDVH VWULQJWRFORVH5HVRXUFH0DQDJHU HQDEOHVDXWRPDWLFWUDQVDFWLRQSROLF\HQIRUFHPHQW WLPHRXWRIWUDQVDFWLRQ>GHIDXOWLVVHFRQGV@ -15 In the RESOURCES section, specify the application-wide number of allowed transactions and the value of the commit control flag. In the MACHINES section, create the TLOG information for each machine. In the GROUPS section, indicate information about each Resource Manager and about the transaction manager server. In the SERVICES section, enable the automatic transaction option and specify the transaction timeout for a service if different from the default timeout value. Copyright -15

16 Configuring RESOURCES ƒ MAXGTT limits the number of global transaction identifiers (GTRIDs) per machine (default is 100 per machine) ƒ CMTRET can be set to Value Global Transaction Commits when participants LOGGED KDYHSUHFRPPLWWHG COMPLETE KDYHFRPPLWWHG For RM vendors implementing XA HDUO\FRPPLWLPSOHPHQWDWLRQ ODWHFRPPLWLPSOHPHQWDWLRQ *RESOURCES MAXGTT 20 CMTRET COMPLETE... UBBCONFIG -16 MAXGTT : Limits the total number of global transaction identifiers (GTRID s) allowed on one machine at one time. The maximum value allowed is 2048, the minimum is 0, and the default is 100. You can override this value on a per-machine basis in the MACHINES section. Entries remain in the table only while the global transaction is active, so this parameter has the effect of setting a limit on the number of simultaneous transactions. CMTRET : Specifies the initial setting of the TP_COMMIT_CONTROL characteristic. The default is COMPLETE. Following are its two settings: LOGGED --The TP_COMMIT_CONTROL characteristic is set to TP_CMT_LOGGED, which means that the application commit function completes when all the participants have successfully pre-committed. COMPLETE --The TP_COMMIT_CONTROL characteristic is set to TP_CMT_COMPLETE, which means that the application commit function will not complete until all the participants have successfully committed. Note: You should consult the RM/Database vendors documentation to determine the appropriate setting. If any RM in the application uses the late commit implementation of the XA standard, the setting should be COMPLETE. If all the Resource Managers use the early commit implementation, the setting should be LOGGED for performance reasons. Copyright -16

17 Configuring MACHINES ƒ Defining the Transaction Log in the MACHINES section UBBCONFIG *MACHINES... TLOGDEVICE = C:\...\myTlogDevice TLOGNAME = mytlog TLOGSIZE = You can define a global transaction log (TLOG ) using several parameters in the MACHINES section of the UBBCONFIG file. You must manually create the device list entry for the TLOGDEVICE on each machine where a TLOG is needed. You can do this either before or after TUXCONFIG has been loaded, but it must be done before the system is booted. Note: If you are not using transactions, the TLOG parameters are not required. TLOGNAME : The name of the DTP transaction log for this machine. TLOGDEVICE : Specifies the TUXEDO file system that contains the DTP transaction log (TLOG ) for this machine. If this parameter is not specified, the machine is assumed not to have a TLOG. The maximum string value length is 64 characters. TLOGSIZE : The size of the TLOG file in physical pages. Its value must be between 1 and 2048, and its default is 100. The value should be large enough to hold the number of outstanding transactions on the machine at a given time. One transaction is logged per page. The default should suffice for most applications. Copyright -17

18 Configuring GROUPS ƒ Declare the TMS in the GROUPS section ƒ The OPENINFO parameter specifies the string used to open the RM (database) UBBCONFIG *GROUPS GROUP1... TMSNAME = C:\...\my_ORA_TMS TMSCOUNT = 2 OPENINFO = ORACLE_XA:Oracle_XA+Acc=P/system/manager +SesTm=100+LogDir=.+DbgFl=0x7 +MaxCur=15+Threads=true Additions to the GROUPS section includes: Defining the transaction manager servers that perform most of the work that controls global transactions: The TMSNAME parameter specifies the name of the transaction manager server executable. The TMSCOUNT parameter specifies the number of such servers to boot (the minimum is 2, the maximum is 10, and the default is 3). A null transactional manager server does not communicate with any Resource Manager. It is used to exercise an application's use of the transactional primitives before actually testing the application in a recoverable, real environment. A null transactional manager server provided with the Tuxedo software is named TMS (in $TUXDIR/bin) and it simply begins, commits, or terminates without interacting with any Resource Manager. Defining opening and closing information for each Resource Manager: OPENINFO is a string with information used to open a Resource Manager. CLOSEINFO is used to close a Resource Manager. If not specified, the Resource Manager does not needs any specific information to close. Copyright -18

19 ƒ AUTO=Y N Configuring SERVICES ¾ A Service configured with the AUTO=Y parameter automatically starts a service in transaction mode if the request itself is not currently in transaction mode ƒ TIME=<seconds> ¾ Specifies the default timeout value in seconds for a transaction automatically started for this service (Default if not configured is 30 secs) -19 AUTO AUTO is a configured optional parameter for a service. It causes a request for that service to automatically be started in transaction mode if the incoming request was not already in transaction mode. Services that are marked AUTO are included within their caller s transaction, if one is in effect. A service configured using the AUTO option cannot distinguish if the transaction it is working on was started by a caller or by the Tuxedo system.. This feature is configured in the *SERVICES section with the AUTO parameter. The AUTO flag is set to Y if a service is to initiate and commit a transaction whenever it is called outside of the transaction mode. If the service is called when there is already an existing transaction, this call will become part of it. AUTO is N by default. TIME Transactions are subject to timeouts - if they do not complete within the timeout period Tuxedo will cause the transaction to be aborted. Increasing the TIME may be needed to avoid timeouts for reasons such as very long service times or slow network links. The Application Programmer can also control this value within the application program. Copyright -19

20 Transaction-related Administration ƒ Tasks an Administrator can be involved with are ¾ Creating the Tuxedo Transaction Log (TLOG) ¾ Building a TMS server for a specific Resource Manager» buildtms command ¾ Recovering from Transaction failures» tmadmin subcommands printtrans, Transaction Administration The Application Administrator may also be required to build, or participate in building, the TMS server for a particular Resource Manager (such as Oracle) and checking the Tuxedo transaction log for active transactions that may require administration action. Copyright -20

21 Creating a Transaction Log File ƒ A transaction log is used to log global transaction ids and participating RMs ¾ use tmadmin crdl to create a transaction log ƒ A log entry for a transaction is deleted at the end of transaction &UHDWLQJD7UDQVDFWLRQ/RJ)LOH... tmloadcf ubbconfig.net... tmadmin > crdl -b z > crlog -m SITE1 c:\...\mytlogdevice 5XQÃWPDGPLQ 7KLVÃLVÃWKHÃ/0,'ÃLQÃ WKHÃ8%%&21),*ÃILOH 7KLVÃLVÃWKHÃQDPHÃRI WKHÃ7/2*Ã'HYLFHÃVSHFLILHGÃ LQÃWKHÃ8%%&21),*ÃILOH -21 This slide discusses creating a transaction log (TLOG ), which refers to a log in which information on transactions is kept until the transaction is completed. Creating the UDL The Universal Device List (UDL) is a map of the BEA TUXEDO file system that contains information used by the Tuxedo system. To create an entry in the UDL for the TLOG device, create the UDL on each machine that will be involved with global transactions. The Bulletin Board Liaison (BBL) then initializes and opens the TLOG during the boot process. To create the UDL, enter a command using the following format, before the application has been booted: tmadmin -c crdl -z config -b blocks where -z config Specifies the full path name for the device where you should create the UDL. config Should match the value of the TLOGDEVICE parameter in the MACHINES section of the UBBCONFIG file. -b blocks Specifies the number of blocks to be allocated on the device. blocks should not be less than the value specified for TLOGSIZE in the UBBCONFIG file. Copyright -21

22 Building a TMS ƒ To interface to a Resource Manager you will need a TMS (Transaction Management Server) ƒ To build a TMS follow these steps ¾ edit <TUXDIR>/udataobj/RM adding a line that describes the particular Resource Manager to be used ¾ build TMS using <TUXDIR>/bin/buildtms -22 Database vendors generally provide RM information for their particular database. Another source of RM entry information for specific database vendors and versions are the Tuxedo newsgroups. Add the line describing the particular RM to the <TUXDIR>/udataobj/RM file and then build the TMS for this specific RM using the buildtms command. Copyright -22

23 Example - RM File and buildtms ([DPSOH50(QWU\'HILQLQJDQ2UDFOH5HVRXUFH0DQDJHU TUXEDO/D:tuxd_switch:${TUXDIR}/lib/librms.a ${TUXDIR}/lib/libfs.a TUXEDO/SQL:tuxsql_switch:${TUXDIR}/lib/libsql.a ${TUXDIR}/lib/libusort.a ${TUXDIR}/lib/librms.a ${TUXDIR}/lib/libfs.a NONE:tmnull_switch: TUXEDO/QM:tuxq_switch:${TUXDIR}/lib/libqm.a ${TUXDIR}/lib/libtmib.a # ORACLE 8 for NT 4.0 ORACLE_XA;xaosw;%ORACLE_HOME%\pro80\lib\msvc\sqllib80.lib %ORACLE_HOME%\rdbms80\xa\xa80.lib %ORACLE_HOME%\OCI80\LIB\MSVC\ORA803.LIB 7KLVÃLVÃWKHÃQDPHÃRIÃWKHÃ706ÃH[HFXWDEOH %XLOGLQJDQ2UDFOH706 %TUXDIR%/bin/buildtms.exe o my_ora_tms r 'HILQLWLRQÃRIÃDQÃ 2UDFOHÃ5HVRXUFHÃ 0DQDJHU 7KLVÃWDJÃPXVWÃPDWFKÃ WKHÃWDJÃGHILQHGÃIRUÃWKLVÃ HQWU\ÃÃLQÃWKHÃ50ÃILOH ORACLE_XA -23 The above example how to use the buildtms command to build an TMS executable, in this case using the RM file entry tag Oracle_XA to build the TMS executable my_ora_tms. The building of a TMS may be performed by the Administrator. Copyright -23

24 buildtms(1) ƒ buildtms(1) is used to construct a transaction manager server executable 6\QWD[ buildtms -o name -r rm_name 2SWLRQV -o name 6SHFLILHVWKHQDPHRIWKHILOHWKHRXWSXWORDGPRGXOHLVWRKDYH -r rm_name 6SHFLILHVWKHWDJLQWKH50ILOHDVVRFLDWHGZLWKWKLVVHUYHU 81,;DQG:LQGRZV17([DPSOH >buildtms -o mytms -r mytms_xa -24 buildtms(1) buildtms(1) is used to construct a TMS server executable. The following four items must be published by the RM vendor: the name of the structure of type xa_switch_t that contains the name of the RM, flags indicating capabilities of the RM, and function pointers for the actual XA functions; the name of the RM that is contained in the name element of the xa_switch_t structure; the name of the object files that provide the services of the XA interface supporting software; and the format of the information string supplied to the OPENINFO and CLOSEINFO parameters in the UBBCONFIG configuration file. Syntax buildtms [-v]-o name -r rm_name Options buildtms has the following options: -v Specifies that buildtms should work in verbose mode. -o name Specifies the name of the file the output load module is to have. -r rm_name Specifies the RM associated with this server. The value rm_name must appear in the resource manager table in $TUXDIR/udataobj/RM for UNIX or %TUXDIR%\udataobj\RM for Windows systems. Copyright -24

25 Transaction Failures ƒ Immediate Failure ¾Client or Server-started transaction terminates abnormally ƒ Rollback before a Tx Timeout occurs ¾Participant Service returns failure (TPSVCFAIL) ¾Tuxedo software experiences an Operating System or network-access error ƒ Rollback caused by a Tx Timeout 1R7X[HGR$GPLQLVWUDWLRQ DFWLRQLVUHTXLUHGIRUDOO WKHVHIDLOXUHV ¾Participant Service terminates abnormally ¾Timeout due to Computer or Network Failure -25 Failures Occurring before the Transaction is Committed The failures indicated on the slide are handled by the application program and by Tuxedo and no action is required by the Administrator. The application may re-try the transaction if it determines, from the Tuxedo error returned, that the operation can be retried. The Tx Timeout indicated on the slide is the Transaction Timeout that may be either the default for the Tuxedo configuration or, explicitly set by the application programmer when the transaction is started. Copyright -25

26 Transaction Failures after Partial Completion ƒ Short Term Failure ¾ Coordinator continues to attempt to contact the remote site/s 1R$GPLQLVWUDWRUDFWLRQLV UHTXLUHGIRUWKLV ¾ Remote site/s TMS will contact Coordinator site after recovery to determine the status ƒ Long Term Failure during the Two-Phase Commit protocol second phase ¾ If Coordinator site has failed, Administrator may need to get a backup machine started ¾ Administrator will need to migrate the TLOG to backup (if the TLOG disk is accessible) -26 A short term recoverable failure, during the second phase of the two-phase commit protocol, could occur if communication is lost between the Transaction Coordinator/Manager and a remote site during this phase. If this happens, the Transaction Coordinator site continues trying to contact the remote site and the remote site TMS s will also attempt to contact Coordinator site after recovery to determine the status of the transaction. A long term failure, such as when the Transaction Coordinator machine has failed, will require the Administrator to take some action if the disk containing the Tuxedo TLOG file is still accessible. To achieve this, dual-ported or mirrored disks are typically required. Copyright -26

27 Aborting and Committing Transactions ƒ If a coordinating site is partitioned or a client dies before committing transactions, the Administrator may need to manually commit or rollback logged transactions ƒ tmadmin commands: Command printtrans aborttrans [-yes] [-g groupname] tranindex committrans [-yes] [-g groupname] tranindex Description YLHZLQIRUPDWLRQRQDFWLYHWUDQVDFWLRQV DERUWWUDQVDFWLRQVRID706RIDJURXS FRPPLWWUDQVDFWLRQVRID706RID JURXS)DLOVLIQRWSUHFRPPLWWHGRU PDUNHGDERUWHG -27 Aborting a Transaction To abort a transaction, use: aborttrans (abort) [-yes] [-g groupname] tranindex To determine the value of tranindex, run the printtrans command (a tmadmin command). If groupname is specified, a message is sent to the TMS of that group to mark as "aborted" the transaction for that group. If a group is not specified, a message is sent, instead, to the coordinating TMS, requesting an abort of the transaction. You must send abort messages to all groups in the transaction to control the abort. This command is useful when the coordinating site is partitioned or when the client terminates before calling a commit or an abort. If the timeout is large, the transaction remains in the transaction table unless it is aborted. Committing a Transaction To commit a transaction, use: committrans (commit) [-yes] [-g groupname] tranindex Both groupname and tranindex are required arguments. The operation fails if the transaction is not precommitted or has been marked aborted. This message should be sent to all groups to fully commit the transaction. Cautions Be careful about using this command. The only time you should need to run it is when both of the following conditions apply: The coordinating TMS has gone down before all groups got the commit message. The coordinating TMS will not be able to recover the transaction for some time. Also, a client may be blocked on tpcommit(), which will be timed out. If you are going to perform an administrative commit, be sure to inform this client (user). Copyright -27

28 Migrating the Transaction Log %()25( $)7(5 0DFKLQHÃ$% 0DFKLQHÃ;< 0DFKLQHÃ$% 0DFKLQHÃ;< *URXS*US *URXS*US 6HUYHU 6HUYHU /2* tmadmin 7/2* PLJJÃÃ*US GXPSWORJÃ$%BWORJILOH ³WUDQVIHU Ã$%BWORJILOH WRÃ;< ORDGWORJÃPÃ$%Ã$%BWORJILOH ORJVWDUWÃ$% ERRWÃJÃ*US -28 Transaction Log Migration To migrate a transaction log to a backup site, do the following: Stop the writing to the log by shutting down the servers in all the groups that write to the log Dump the TLOG into an ASCII file by executing the following command: dumptlog [-z config] [-o offset] [-n name] [-g groupname] filename The TLOG is dumped into an ASCII file specified by filename. The TLOG is specified by the config and offset. Offset defaults to 0 and name defaults to TLOG. If the -g option is used, the records dumped are the ones for which the TMS specified in the groupname is the coordinator. Copy the ASCII file created by the dumptlog command to the backup site Read the ASCII file created by dumptlog into the existing TLOG for the specified machine by executing the following command: loadtlog -m machine filename Force a warm start of the TLOG by executing the following command: logstart machine Note: If transactions are being logged for the server involved in a group migration, you may need to move the TLOG to the backup machine, load it, and perform a warm start This means the information is read from the TLOG to create an entry in the transaction table in shared memory. Migrate the servers to the backup site Copyright -28

29 Transaction Log Commands ƒ Use the following commands to dump, load and restart transaction logs 6\QWD[IRUGXPSORJORDGWORJDQGORJVWDUW dumptlog [-z config][-o offset][-n name][-g groupname] filename loadtlog -m machine filename logstart machine dumptlog Options -z config -o offset -n name -g groupname filename loadtlog Options -m machine Description SDWKORFDWLRQRI7/2* RIIVHW QDPHRIELQDU\ORJGHIDXOWVWR7/2* RQO\UHFRUGVIRUZKLFK706RIJURXSQDPHLV WKHFRRUGLQDWRUDUHGXPSHG QDPHRIWKH$6&,,ORJILOH Description PDFKLQHZKHUH7/2*ZLOOEHORDGHGWR -29 dumptlog (dl ) -z config [ -o offset ] [ -n name ] [ -g groupname ] filename : Dumps an ASCII version of the TLOG into the specified filename. The TLOG is located on the specified config and offset, and has the specified name. If the -n option is not given and a default has not been set, the name "TLOG" is used. config points to the device containing the universal device list; it must be an absolute pathname (starting with /). If the -z option is not given and a default has not been set, the path named by the FSCONFIG environment variable is used. The -o offset option can be used to specify an offset into config. If the -o option is not given and a default has not been set, the value of the environment variable FSOFFSET is used. If FSOFFSET is not set, the default is 0. If groupname is specified, then only log records for transactions where that group is the coordinator will be dumped. loadtlog -m machine filename : Read the ASCII version of a TLOG from the specified filename (produced by dumptlog ) into the existing TLOG for the named or default machine (it cannot be "DBBL" or "all"). logstart machine : Force a warm start for the TLOG information on the specified machine. This should normally be done following a loadtlog and after disk relocation during server group migration. Copyright -29

30 Review ƒ In this section we discussed ¾ the run-time administration tasks needed to support a transactional Tuxedo application -30 Copyright -30

31 Review ƒ In this module we discussed ¾ characteristics of transaction applications ¾ distributed transaction processing (DTP) ¾ configuring Tuxedo to support transaction applications ¾ the run-time administration tasks needed to support a transactional Tuxedo application -31 Copyright -31

32 Lab Workshop Please refer to the Lab Exercises guide and do lab. The suggested time for this lab is 45 minutes. The Instructor will determine when it is appropriate to stop. -32 Copyright -32