*2pc pending 처리 사용예
sqlplus as sysdba (sys권한으로 접속)
spool 20060715_2pc_pending
set time on
set timing on
set echo on
set pages 100
select * from dba_2pc_pending;
alter session set "_smu_debug_mode" = 4;
exec dbms_transaction.purge_lost_db_entry('8.16.204198');
commit;
select * from dba_2pc_pending;
spool off
#########################
# 2pc pending 처리 절차 #
#########################
DISTRIBUTED TRANSACTION TROUBLESHOOTING (ORA-1591해결 방법)
STEP 1: alert.log file을 check한다.
STEP 2: network 환경을 확인한다.
STEP 3: RECO process가 떠 있는지 확인한다.
os> ps -ef | grep reco
STEP 4: DBA_2PC_PENDING을 조회해 본다.
SQL>select local_tran_id, global_tran_id, state, mixed, host, commit#
from dba_2pc_pending;
SQL> alter session set "_smu_debug_mode" = 4;
STEP 7: DBA_2PC_PENDING의 MIXED column을 확인한다.
- MIXED값이 NO인 경우 : STEP 8 수행
- MIXED값이 YES인 경우: STEP 9 수행
STEP 8: DBA_2PC_PENDING의 STATE column의 값을 확인한다.
CASE 8-1: STATE field ---> COMMITTED인 경우
SQL>exec dbms_transaction.purge_lost_db_entry('1.25.818505');
SQL>commit;
CASE 8-2: STATE field ---> PREPARED인 경우 <-- Lock 인상태
SQL>rollback force '<TRANS_ID>'; 혹은
SQL>commit force '<TRANS_ID>';
CASE 8-3: STATE field ---> COLLECTING인 경우
SQL>exec dbms_transaction.purge_lost_db_entry('<TRANS_ID>');
SQL>commit;
CASE 8-4: STATE field ---> FORCED ROLLBACK/FORCED COMMIT 인 경우
SQL>exec dbms_transaction.purge_lost_db_entry('<TRANS_ID>');
SQL>commit;
STEP 9: 불일치 사항을 파악하고 DBA_2PC_PENDING을 정리한다.
MIXED가 YES인 상태에서, inconsistency를 받아들이고 DBA_2PC_PENDING view를
정리하려면 다음과 같이 수행한다.
SQL>exec dbms_transaction.purge_mixed('1.8.238');
SQL>commit;
================================================================
exec dbms_transaction.purge_mixed('1.8.238') 에러발생시 조치요령
에러내용
ERROR at line 1:
ORA-30019: Illegal rollback Segment operation in Automatic Undo mode
ORA-06512: at "SYS.DBMS_TRANSACTION", line 65
ORA-06512: at "SYS.DBMS_TRANSACTION", line 85
ORA-06512: at line 1
조치
alter session set "_smu_debug_mode" = 4;
# END #########################################################################
다른 데이타베이스를 이용하지 않는 로컬 트랜잭션이 비정상 종료시 자동으로
Rollback되는 것과는 달리, 분산 트랜잭션이 실패한 경우에는 관여된 일부 데이타
베이스에서는 Rollback 혹은 Commit이 되고, 일부는 Distributed Lock이 걸린
상태로 계속 지속될 수 있다. 이렇게 Pending된 트랜잭션에 대해서는 기본적으로
Oracle의 백그라운드 프로세스인 RECO 프로세스가 자동으로 정리하여 주지만, 경
우에 따라 자동으로 정리가 되지 못하는 상황이 발생할 수 있다.
이렇게 분산 트랜잭션이 비정상 종료시, Distributed Lock에 의해 이후 관계된 테
이블을 조회나 변경시 ORA-1591 오류가 발생할 수 있음은 이미 앞의‘2 Phase
Commit‘ 부분에서 설명하였다. 이때의 조치 방법을 정리하면, 다음 9단계와 같다.
여기서는 이해를 돕기 위해 분산 환경에 포함된 노드를 V817LOC와 V817REM으
로 예를 들고, V817LOC 노드에서 트랜잭션을 수행하였다고 가정한다.
여기서 사용되는 dbms_transaction 패키지는 기본적으로 catproc.sql 스크립트에
의해 생성되나 만약 존재하지 않는다면, cd $ORACLE_HOME / rdbms/admin
디렉토리의 dbmsutil.sql, prvtutil.plb 스크립트를 sys user에서 수행하도록 한
다(svrmgrl에서 connect internal에서 수행하는 것이 일반적이다).
아래의 STEP 중 STEP 1~3까지는 문제 해결을 위해 필수적인 단계는 아니므로
바로 문제를 시급히 해결해야 하는 경우 STEP 4부터 확인하도록 한다.