dba_2pc_pending

출처 사이트의 내용을 번역 후 정리하는 글입니다.

 

분산 트랜잭션 환경에서 네트워크 이슈로 인해 트랜잭션이 끊기게 되면 dba_2pc_pending 뷰에 정보가 생기게 됩니다.

그런 다음 RECO(Recovery Background process)는 일관성을 보장하기 위해 연결이 끊긴 노드의 상태와 일치하도록 정상노드를 롤백하거나 커밋합니다.

dba_2pc_pending 뷰에는 보류중인 항목을 커밋하거나 롤백하도록 데이터베이스에 지시하는 ADVISE 컬럼이 포함되어 있습니다.

ALTER SESSION ADVISE 구문을 사용하여 2PC(2 phase commit)메커니즘을 지시할 수 있습니다. 예를 들어 INSERT를 강제로 완료하려면 다음을 입력할 수 있습니다.

 

ALTER SESSION ADVISE COMMIT;
INSERT INTO A@XE . . . ;

 

2PC 트랜잭션이 실패하면 dba_2pc_pending 테이블을 쿼리하여 STATE 컬럼을 확인할 수 있습니다.

RECO 복구를 하기전에, 트랜잭션은 dba_2pc_pending의 STATE에 COLLECTING,COMMITED,PREPARED로 표시됩니다.

COMMIT FORCE 또는 ROLLBACK FORCE를 사용하여 트랜잭션을 강제하면 FORCED COMMIT 또는 FORCED ROLLBACK 상태가 나타날 수 있습니다. 자동 복구는 일반적으로 이러한 상태의 항목을 삭제합니다.

유일한 예외는 복구가 트랜잭션의 다른 사이트와 일치하지 않는 상태에 있는 강제 트랜잭션을 발견하는 경우입니다.

이 경우 항목은 테이블에 남아있을 수 잇으며 dba_2pc_pending의 MIXED 컬럼은 YES값을 갖습니다.

이 항목은 DBMS_TRANSACTION.PURGE_MIXED 프로시저로 정리할 수 있습니다.

이렇게하면 트랜잭션이 해결된 후 dba_2pc_pending에서 행이 사라집니다. 

트랜잭션을 잘못된 방식으로 강제하는 경우(예 : 다른 노드가 커밋될 때 롤백) RECO는 문제를 감지하고 MIXED 열을 YES로 설정하며 행은 dba_2pc_pending테이블에 남아 있습니다.

 

출처 : www.dba-oracle.com/t_dba_2pc_pending.htm

dba_2pc_pending tips

 

관련 에러

ORA-01591 : 미확정분산 %s 트랜잭션에 의해 잠금되었습니다.

원인: 분산 트랜잭션 수행 도중 fail 발생하게 되었을 시 일부 database에는 트랜잭션이 종료되고 일부는 distributed lock이 걸린 상태로 지속될 수 있음. 평소에는 RECO 프로세스가 정리하여 주나 경우에 따라 자동으로 정리가 되지 못하여 해당 에러가 발생할 수 있음.

해결:

1)select * from dba_2pc_pending 으로 lock이 걸려있는 트랜잭션 확인

2)commit force 'trans_id' or rollback force 'trans_id' 으로 트랜잭션 종료 강제 수행

3)exec dbms_transaction.purge_lost_db_entry('trans_id'); 

4) select * from dba_2pc_pending 다시 조회

 

 

출처 : m.blog.naver.com/PostView.nhn?blogId=trust0416&logNo=60071738597&proxyReferer=https:%2F%2Fwww.google.com%2F

ORA-1591(Pending Transaction의 처리)

출처 : www.hyungjun.kr/336

Oracle ORA-01591 오류 문제 처리

출처 : m.blog.naver.com/PostView.nhn?blogId=kkj871001&logNo=220305746566&proxyReferer=https:%2F%2Fwww.google.com%2F

2pc pending 처리절차

 

분산 환경을 테스트환경으로 구축해보긴 힘들어서 우선 잘 정리되어 있는 블로그들의 글들을 읽어보고 다시 재정리하였습니다.