전문순서 역전현상 - Oracle RAC, XA 트랜잭션
Updated:
Oracle RAC, XA 트랜잭션에서 전문순서 역전현상 원인분석
현상
문자메시지로 발송하는 전문들의 순서가 뒤바뀌는 현상이 간헐적으로 발생하고 있었다. 예를 들어 전문a 가 먼저 발송된 후 전문b 가 발송되어야 하는데 전문b, 전문a 순으로 발송되는 상황이었다.
서버 연결 아키텍처는 다음 그림과 같다. 전문생성AP 는 DB 에 connection pool 을 만들 때 mash 방식으로 만들어져 있다. 즉, AP1,AP2 는 각각 RAC 로 구성된 DB 인스턴스 1번과 2번 모두에 connection pool 을 가지고 있다. 전문생성 Tx. 는 요건상 XA 로 묶여 있다.
위 그림에서 XA1 Tx. 를 보면 전문a 는 DB1 인스턴스에 만들어져 있는 세션1 로, 전문b 는 DB2 인스턴스에 있는 세션3 으로 보낸다. 이 경우 DB 입장에서는 세션1 과 세션3 은 별개의 Tx. 이며 당연히 commit 도 각각 이루어진다. 따라서 세션1 이 세션3 보다 먼저 commit 이 완료된다는 보장은 없다. 만일 전문발송 AP 가 세션3 이 commit 되었지만 아직 세션1 이 commit 되기 전에 DB 를 select 한다면 세션3(전문b) 만 발송될 것이다. 그리고 다음 select 에서야 이제 commit 되어있는 세션1(전문a)가 발송되어질 것이며 이런 원리로 전문발송순서가 역전되어지는 것이었다.
이제 XA2 Tx. 를 보면, 한 세션(세션4)만을 이용하여 전문a 와 전문b 를 insert 한후 한번에 commit 하는 경우이다. 이유는 알 수 없지만 복수의 DB인스턴스를 사용하지 않고 이처럼 하나의 DB 인스턴스만을 가지고 XA 로 묶인 경우에는 한 세션 및 한 Tx. 로 처리되고 있었다. 이것은 로그마이너를 통해 확인할 수 있었다.(V$LOGMNR_CONTENTS 의 XID 열값이 동일함) 당연히 이 경우엔 전문이 한 Tx. 로 처리되니 전문이 나뉘어질 수도 순서가 역전될 수도 없다.
대책
오라클 RAC 환경에서 XA 를 구성할 때는 한 DB 인스턴스 세션으로만 묶어야 DB內 트랜잭션 정합성을 보장할 수 있다. 여러 인스턴스 세션들로 XA 를 묶으면 각 세션들은 독립적으로 commit 되어지므로 트랜잭션 정합성이 깨지게 된다..(AP 입장에서는 1 TX. 이지만 DB 입장에서는 2 TX. 이기 때문) 따라서 오라클 RAC 환경에서 XA를 구성할 때는 AP - DB 간 connection pool 을 만들 때 mesh 방식이 아닌 dedicate 방식으로 만드는 것이 바람직하다. (아래 그림 참조) 위 전문발송 순서역전 현상도 AP - DB 간 connection pool 을 dedicate 방식으로 전환한 후 말끔히 사라졌다.
