[ Pobierz całość w formacie PDF ]
.The chances of the above situations occurring are very rare, considering thelow probability of failures during the critical portions of the two-phasecommit.Even if such a failure occurs and assuming quick recovery from anetwork or system failure, problems are automatically resolved withoutmanual intervention.Thus problems usually resolve before they can bedetected by users or database administrators.Manually Overriding In-Doubt TransactionsA database administrator can manually force the COMMIT or ROLLBACK ofa local in-doubt distributed transaction.However, a specific in-doubttransaction should be manually overridden only when the following situationsexist:" The in-doubt transaction locks data that is required by othertransactions.This happens if users complain that the ORA-01591 errormessage interferes with their transactions." An in-doubt transaction prevents the extents of a rollback segment to beused by other transactions.The first portion of an in-doubt distributedtransaction s local transaction ID corresponds to the ID of the rollbacksegment, as listed by the data dictionary views DBA_2PC_PENDINGand DBA_ROLLBACK_SEGS." The failure that did not allow the two-phase commit phases to completewill not be corrected in an acceptable time period.Examples of suchcases might include a telecommunication network that has beendamaged or a damaged database that needs a substantial amount oftime to complete recovery.Normally, a decision to locally force an in-doubt distributed transactionshould be made in consultation with administrators at other locations.Awrong decision can lead to database inconsistencies which can be difficult totrace and that you must manually correct.If the conditions above do not apply, always allow the automatic recoveryfeatures of Oracle8 to complete the transaction.However, if any of the abovecriteria are met, the administrator should consider a local override of the in-doubt transaction.Distributed Transactions 3-21 If a decision is made to locally force the transaction to complete, the databaseadministrator should analyze available information with the following goalsin mind:" Try to find a node that has either committed or rolled back thetransaction.If you can find a node that has already resolved thetransaction, you can follow the action taken at that node." See if any information is given in the TRAN_COMMENT column ofDBA_2PC_PENDING for the distributed transaction.Comments areincluded in the COMMENT parameter of the COMMIT command.Forexample, an in-doubt distributed transaction s Comment might indicatethe origin of the transaction and what type of transaction it is:COMMIT COMMENT Finance/Accts_pay/Trans_type 10B ;" See if any information is given in the ADVICE column ofDBA_2PC_PENDING for the distributed transaction.An applicationcan prescribe advice about whether to force the commit or force therollback of separate parts of a distributed transaction with the ADVISEparameter of the SQL command ALTER SESSION.The advice sent during the prepare phase to each node is the advice ineffect at the time the most recent DML statement executed at thatdatabase in the current transaction.For example, consider a distributed transaction that moves an employeerecord from the EMP table at one node to the EMP table at another node.The transaction could protect the record (even when administratorsindependently force the in-doubt transaction at each node) by includingthe following sequence of SQL statements:ALTER SESSION ADVISE COMMIT;INSERT INTO emp@hq.; /*advice to commit at HQ */ALTER SESSION ADVISE ROLLBACK;DELETE FROM emp@sales.; /*advice to roll back at SALES*/ALTER SESSION ADVISE NOTHING;If you manually force the in-doubt transaction, the worst that canhappen is that each node has a copy of the employee record beingmoved; the record cannot disappear.3-22 Oracle8 Server Distributed Database Systems Manual Override ExampleThe following example shows a failure during the commit of a distributedtransaction and how to go about gaining information before manually forcingthe commit or rollback of the local portion of an in-doubt distributedtransaction.Figure 3-7 illustrates the example.Figure 3-7: An Example of an in-Doubt Distributed TransactionSALES.ACME.COMpreparedCommunication breakGlobal CoordinatorCommit Point Siteprepared commitDatabase ServerWAREHOUSE.ACME.COM HQ.ACME.COM ClientIn this failure case, the prepare phase completed.However, during the commitphase, the commit point site s commit message (the message telling the globalcoordinator that the transaction was committed at the commit point site) nevermade it back to the global coordinator, even though the commit point sitecommitted the transaction.You are the WAREHOUSE database administrator
[ Pobierz całość w formacie PDF ]