[ORACLE] DBA_2PC_PENDING 뷰 완벽 가이드 : 분산 트랜잭션 복구 핵심

[ORACLE] DBA_2PC_PENDING

 

Oracle의 분산 트랜잭션 환경에서 발생할 수 있는 ‘불완전 커밋’(in-doubt transaction) 문제를 해결하기 위해 사용되는 주요 뷰가 바로 DBA_2PC_PENDING입니다. 이 뷰는 2단계 커밋(2PC: Two-Phase Commit) 프로토콜의 중간 또는 실패 상태를 추적하고, 복구 절차를 수행하기 위한 필수 정보를 제공합니다. 본 글에서는 DBA_2PC_PENDING의 구조, 주요 컬럼, 내부 동작 원리, 복구 시나리오를 단계별로 정리해 Oracle DBA가 실무에서 즉시 활용할 수 있도록 구성했습니다.

---

1. DBA_2PC_PENDING의 개요

DBA_2PC_PENDING 뷰는 Oracle 분산 트랜잭션의 커밋 과정에서 문제가 발생했을 때, ‘완전 커밋되지 않은 상태의 트랜잭션’을 보여주는 관리용 데이터 딕셔너리 뷰입니다. 이 뷰의 주요 목적은 트랜잭션 상태를 식별하고, DBA가 수동으로 COMMIT 또는 ROLLBACK을 결정할 수 있도록 지원하는 것입니다.

Oracle은 2단계 커밋(2PC) 프로토콜을 통해 여러 데이터베이스 간의 트랜잭션 일관성을 유지합니다. 그러나 네트워크 단절, 인스턴스 장애, 또는 커밋 과정 중 중단이 발생하면 일부 노드는 커밋 상태를 알 수 없게 됩니다. 이때 DBA_2PC_PENDING은 그러한 미확정 트랜잭션 정보를 기록해 관리자가 조치할 수 있도록 합니다.

---

2. 주요 컬럼 설명

컬럼명	데이터 타입	설명
LOCAL_TRAN_ID	VARCHAR2(22)	로컬 데이터베이스 내 트랜잭션 식별자 (예: 1.25.123)
GLOBAL_TRAN_ID	VARCHAR2(64)	전역 트랜잭션 식별자. 분산 시스템 간 고유하게 구분
STATE	VARCHAR2(10)	트랜잭션 상태 (‘collecting’, ‘prepared’, ‘committed’, ‘forced rollback’ 등)
MIXED	VARCHAR2(3)	일부 노드만 커밋된 불일치 상태 여부
ADVICE	VARCHAR2(255)	Oracle 복구 관리자가 제안하는 처리 방향 (‘commit recommended’ 등)
TRAN_COMMENT	VARCHAR2(255)	트랜잭션 관련 코멘트 (예: 사용자 정보, 애플리케이션명 등)
FAIL_TIME	DATE	트랜잭션 실패가 감지된 시각
FORCE_TIME	DATE	DBA가 수동으로 FORCE COMMIT 또는 ROLLBACK한 시각
RETRY_COUNT	NUMBER	Oracle이 자동 재시도한 횟수

---

3. DBA_2PC_PENDING과 다른 2PC 관련 뷰 비교

뷰 이름	주요 역할	주요 컬럼	활용 목적
DBA_2PC_PENDING	현재 미확정 상태의 트랜잭션 관리	LOCAL_TRAN_ID, STATE, ADVICE	복구 시 COMMIT/ROLLBACK 결정
DBA_2PC_NEIGHBORS	트랜잭션 참여 노드 정보	DBID, BRANCH, DATABASE	분산 트랜잭션 노드 관계 파악
DBA_2PC_TRANSACTIONS	2PC 관련 모든 트랜잭션 이력	GLOBAL_TRAN_ID, FAIL_TIME	감사 및 추적 용도

---

4. 트랜잭션 복구 절차

DBA는 DBA_2PC_PENDING 뷰를 통해 문제 트랜잭션을 식별한 뒤, 상태에 따라 수동 조치를 취할 수 있습니다. 일반적인 복구 절차는 다음과 같습니다.

1. 조회:

   SELECT * FROM DBA_2PC_PENDING;

2. 문제 트랜잭션 식별:

   SELECT LOCAL_TRAN_ID, STATE FROM DBA_2PC_PENDING WHERE STATE='collecting';

3. 수동 복구 (예: 커밋 강제 수행):

   COMMIT FORCE '1.25.123';

4. 또는 강제 롤백:

   ROLLBACK FORCE '1.25.123';

5. 복구 완료 후 클린업:

   EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.25.123');

---

5. DBA_2PC_PENDING의 내부 동작

Oracle의 2단계 커밋 프로토콜은 크게 Prepare → Commit 두 단계로 구성됩니다. 각 단계에서 노드 간 통신이 원활하지 않거나 장애가 발생하면, 해당 트랜잭션은 ‘pending’ 상태로 남게 됩니다.

• Prepare 단계: 모든 참여 노드가 커밋 준비 상태(‘prepared’)로 전환.
• Commit 단계: Coordinator가 ‘commit’ 신호를 보내지만, 일부 노드에서 응답 실패 시 ‘in-doubt’ 상태 발생.
• 복구 단계: DBA 또는 Oracle 자동 복구 프로세스(SMON)가 DBA_2PC_PENDING 정보를 참조하여 처리.

---

6. 관리 및 모니터링 팁

1) 주기적으로 DBA_2PC_PENDING을 모니터링하면, 미확정 트랜잭션으로 인한 undo segment 잠김이나 리소스 경합 문제를 예방할 수 있습니다.
2) 대규모 분산 환경에서는 DBA_2PC_NEIGHBORS와 함께 조회하여, 커밋이 중단된 노드 간 관계를 파악하는 것이 중요합니다.
3) 트랜잭션이 오래 남아 있는 경우, DBA가 수동으로 COMMIT FORCE 또는 ROLLBACK FORCE 명령을 수행해 정리해야 합니다.

---

7. 실무 적용 예시

예를 들어, ERP 시스템과 Data Warehouse 간의 대용량 트랜잭션이 수행 중 네트워크 장애가 발생했다고 가정해보겠습니다. 이때 ERP 측에서는 커밋이 되었지만, DW 측에서는 응답을 받지 못한 상태가 발생할 수 있습니다. 이 경우 DBA_2PC_PENDING은 해당 트랜잭션을 기록하고, DBA는 ‘advice’ 컬럼의 제안에 따라 COMMIT 또는 ROLLBACK을 결정할 수 있습니다. 이 절차를 통해 데이터 불일치를 최소화할 수 있습니다.

---

8. 결론

DBA_2PC_PENDING은 Oracle의 분산 트랜잭션 관리에서 핵심적인 역할을 담당하는 뷰입니다. 이는 단순한 오류 로그가 아니라, 복구 전략 수립의 출발점이자 데이터 일관성 유지의 마지막 보루입니다. DBA는 해당 뷰를 정기적으로 점검하고, 복구 자동화 스크립트나 모니터링 도구와 연계해 관리 효율성을 높이는 것이 바람직합니다.

---

출처

• Oracle® Database Reference 19c - DBA_2PC_PENDING View
• Oracle Distributed Database Concepts Guide