dist_tran_fail.sql connect rem reenable distributed recovery to clean up rem any in-doubt distributed transactions pause

Transcription

1 connect reenable distributed recovery to clean up any in-doubt distributed transactions alter system enable distributed recovery; alter session advise nothing; clean up drop public database link angel; undefine tranid undefine scn create a link create public database link angel connect to system identified by oracle using 'ANGEL'; see the link col owner for a8 col db_link for a25 col username for a8 col host for a20 select * from dba_db_links order by db_link; see the commit point strengths on both sides this parameter determines which site is the commit point site col name for a30 col value for a30 col location for a8 Page 1

2 select 'LOCAL' as location,name,value from v$parameter where name = 'commit_point_strength' select 'REMOTE',name,value from v$parameter@angel where name like 'commit_point_strength'; see the transaction created by the ote query of the view col state for a30 select 'LOCAL' as location,branches,refcount,preparecount,state from v$global_transaction select 'REMOTE', branches,refcount,preparecount,state from v$global_transaction@angel; commit the transaction created by the ote query of the V$view commit; do a local update update scott.emp set sal=sal+0; now set advice to commit at this point if failure occurs alter session advise commit; now do a ote update thereby creating a distributed transaction Page 2

3 update set sal=sal+1; see the global transaction caused by the update select 'LOCAL' as location,branches,refcount,preparecount,state from v$global_transaction select 'REMOTE', branches,refcount,preparecount,state from set the default session advice to rollback note this will appear in the advice column for use in in-doubt resolution exec dbms_transaction.advise_rollback now disable automatic distributed recovery to help simulate what happens when errors occur during two-phase commit processing this does not ove the RECO process but prevents it from automatically resolving any in-doubt 2-phase commits alter system disable distributed recovery; see that the reco process is still alive col name for a4 col description for a40 select name,description from v$bgprocess where name = 'RECO'; now that RECO is disabled we can simulate failure Page 3

4 using the Distributed Transaction Crash Test feature There are 10 possible crash simulations listed below which may be used by adding a formatted comment to the commit statement as follows 'ORA-2PC-CRASH-TEST-<num>' failure 1 - Crash commit point site after collect failure 2 - Crash non-commit point site after collect failure 3 - Crash non-commit point site before prepare failure 4 - Crash non-commit point site after prepare failure 5 - Crash commit point site before commit failure 6 - Crash commit point site after commit failure 7 - Crash non-commit point site before commit failure 8 - Crash non-commit point site after commit failure 9 - Crash commit point site before forget failure 10 - Crash non-commit point site before forget now commit with a crash test commit comment 'ORA-2PC-CRASH-TEST-&testno'; commit comment 'ORA-2PC-CRASH-TEST-7'; see the error message produced by the crash test now try to access the the local emp table select * from scott.emp; it is not even readable! now lets see how to investigate this first we will look at pending two phase commit transactions desc dba_2pc_pending lets trap the local tranid for use later Page 4

5 col ltranid new_value ltranid select local_tran_id as ltranid from dba_2pc_pending; see it def LTRANID now lets see the pending transactions on both sides of the link col local_tran_id for a12 col global_tran_id for a26 col state for a9 col tran_comment for a20 col os_user for a8 col os_terminal for a8 col host for a8 col db_user for a8 col commit# for a10 if the global tranid and the local are the same then this site is the Global Coordinator of the transaction the mixed column shows if there are any mixed outcome situations where a commit was done in one place but a rollback in the other. the tran_comment has the comment from the commit or rollback statement which in this case is the special "Crash Test" comment. select 'LOCAL' as location,state,global_tran_id, local_tran_id,tran_comment,commit#,mixed,advice,fail_time from dba_2pc_pending where local_tran_id = (select local_tran_id from dba_2pc_pending) select 'REMOTE' as location,state,global_tran_id, local_tran_id,tran_comment,commit#,mixed,advice,fail_time Page 5

6 from see who the neighboring database is on both sides desc dba_2pc_neighbors the database column has the db link name for outbound and the client database name for inbound interface has "C" for request commit or "N" for prepare or read only transaction commit if IN_OUT=OUT and INTERFACE=C then the ote DB is the commit point site and knows whether to commit or not if IN_OUT=OUT and INTERFACE=N then the local node has informed the ote node that the local is prepared if IN_OUT=IN and INTERFACE=C then the local node or another node further down a daisy chain is the commit point site. if IN_OUT=IN and INTERFACE=N then the ote node has informed the local node that it is prepared Branch is the transaction branch identifier at this Database col local_tran_id for a13 col database for a10 col DBID for a10 col dbuser_owner for a8 col branch for a46 select 'LOCAL' as location,local_tran_id,in_out,interface, database,dbuser_owner,branch from dba_2pc_neighbors where local_tran_id = (select local_tran_id from dba_2pc_pending) select 'REMOTE',local_tran_id,in_out,interface, database,dbuser_owner,branch from dba_2pc_neighbors@angel; Page 6

7 dist_tran_fail.sql we can see that the ote database is the commit point site IN_OUT=OUT to DATABASE ANGEL and INTERFACE=C has been reported from the LOCAL location (TUTOR5C) and IN_OUT=IN to DATABASE TUTOR5C and INTERFACE=C has been reported from the REMOTE location (ANGEL) IN_OUT=IN to a NULL Database represents the local client connection now try to commit the txn for the dist query commit; trap the current scn for later col scn new_value scn select to_char(current_scn) as scn from v$database; see it def scn now force commit or force rollback using the local transid and scn exec dbms_transaction.commit_force('&ltranid','&scn') one may aslo use "commit force '&ltranid' '&scn';" Page 7

8 dist_tran_fail.sql now try again to access the table select * from scott.emp; now lets look at the pending txns on both sides select 'LOCAL' as location,state,global_tran_id, local_tran_id,tran_comment,commit#,mixed,advice,force_time from dba_2pc_pending where local_tran_id = (select local_tran_id from dba_2pc_pending) select 'REMOTE' as location,state,global_tran_id, local_tran_id,tran_comment,commit#,mixed,advice,force_time from dba_2pc_pending@angel; and look at the neighbors on both sides select 'LOCAL' as location, l.* from dba_2pc_neighbors l where local_tran_id = (select local_tran_id from dba_2pc_pending) select 'REMOTE', r.* from dba_2pc_neighbors@angel r; if there were mixed outcome results we would need to purge them as follows exec dbms_transaction.purge_mixed('&ltranid') if the ote database has gone for good and one or more rows ain in the local dictionary then they may be oved as follows Page 8

9 exec dbms_transaction.purge_lost_db_entry('&ltranid') reenable distributed recovery alter system enable distributed recovery; check to see if RECO has done the business select 'REMOTE',state,global_tran_id, local_tran_id,tran_comment,commit#,fail_time,force_time from select 'LOCAL' as location,state,global_tran_id, local_tran_id,tran_comment,commit#,fail_time,force_time from dba_2pc_pending where local_tran_id like '%&&ltranid%'; end the txn for the distributed query commit; Page 9