Print
카테고리: [ Oracle Database ]
조회수: 11520

1. 개요

Two Phase Commit은 분산 트랜잭션에서 Commit이 발생하는 경우에 사용되며, 오라클은 이를 사용하여 Global Database의 일관성을 유지함. 다시 말해, 이 메커니즘은 분산 트랜잭션에  참여하는 모든 노드들에 대하여 'Everything Commit or Rollback'을 보장하게 된다.


2. Two Phase Commit의 2단계

2- 1. Prepare 단계

SQL문을 처음 수행한 Server인 Global Coordinator가 Commit Point Site를 제외한 나머지 노드에서 Prepare 하도록 요청함. 요청 받은 노드는 각각의 Local DB에서의 작업에 대해 Commit이나 Rollback 할 준비를 마치고 Global Coordinator에게 Prepare 되었음을 알려준다. Prepare 단계를 지나고 Commit을 완료하기 전까지는 트랜잭션이 In-doubt 상태가 되었다고 한다.

2-2. Commit 단계

분산 트랜잭션에 참여한 노드들이 Prepare 되었다는 메세지를 보내면 분산 트랜잭션을 일으킨 Global Coordinator는 트랜잭션에 대한 Commit을 요청. Commit Point Site가 가장 먼저 Commit을 완료하고 나머지 노드들도 Commit을 완료. Prepare 되지 않았다는 메시지가 오면 Rollback을 요구한다.

2-3. Failure

Two Phase Commit 단계중에 Failure이 발생하게 되면 관여된 일부 노드에서는 Commit 혹은 Rollback이 되고, 일부는 Distributed Lock이 걸린 상태로 계속 지속될 수 있다.

이렇게 Pending된 트랜잭션에 대해서는 기본적으로 Background Process인 RECO process가 Session Tree의 모든 노드에서 같은 결과가 발생되도록 (즉 모든 Commit or 모든 Rollback 되도록) In-doubt 트랜잭션을 자동적으로 Recovery한다

분산 트랜잭션에 연결된 노드간에 Communication Break이 발생하면 In-doubt 트랜잭션에 의하여 lock에 의하여 자원의 가용성에 제한을 받을 수 있다. 이런 경우 RECO에 의하여 pending된 프로세스의 정리에 앞서 Lock된 리소스를 Release 하기 위해 강제적으로 분산 트랜잭션의 Commit 혹은 Rollback을 통하여 현상을 해결할 수 있다.


3. ORA-01591: lock held by in-doubt distributed transaction '******‘

In-doubt 분산 트랜잭션에 의해 일부 자원이 lock 되어 있는 상황에서, 해당 자원에 lock을 발생시키는 다른 트랜잭션을 발생시켰을 때 발생하는 메시지임. (QDLG DB에서 발생)
 
분산 트랜잭션에 관여된 노드는 Commit 시점에 Commit이 가능한 경우 자원에 Distributed Lock을 걸게 되는데, 이렇게 lock이 걸린 상태를 트랜잭션이 In-doubt 상태에 있다고 표현하며, Commit Point Site의 Commit에 이어 나머지 노드들도 Commit을 하게 되는 시점에 비로소 Commit을 하고 Distributed Lock을 해제한다.
 
이 Distributed Lock이 걸려있는 동안은 다른 트랜잭션이 해당 분산 트랜잭션이 변경한 데이터와 같은 블록의 어떠한 데이터라도 읽거나 쓰려고 하면 위의 메시지를 발생시킨다. Distributed Lock은 실제 v$lock을 확인해서는 나타나지 않는다.

4. 관련 메세지

4-1. 오류로 비정상 종료

Mon Feb 26 19:13:38 2017
Error 2068 trapped in 2PC on transaction 3.54.126008. Cleaning up.
Error stack returned to user:
ORA-02054: transaction 3.54.126008 in-doubt
ORA-02068: following severe error from MY_DBLINK
ORA-03113: end-of-file on communication channel
Mon Feb 26 19:13:38 2017

4-2. 종료된 세션이 진행하던 insert 작업 pending

Mon Feb 26 19:13:38 2017
DISTRIB TRAN MYDB.6a55a5f2.3.54.126008
  is local tran 3.54.126008 (hex=03.36.1ec38)
  insert pending prepared tran, scn=9236973861156 (hex=866.a68bb924)

4-3. DB Restart 후에도 lock 지속되어 강제 rollback

Mon Feb 26 20:49:13 2017
DISTRIB TRAN MYDB.6a55a5f2.3.54.126008
  is local tran 3.54.126008 (hex=03.36.1ec38)
  change pending prepared tran, scn=9236973861156 (hex=866.a68bb924)
  to     pending forced rollback tran, scn= (hex=0.00000000)