DBA_2PC_PENDING는 현재 정체되고 있는 XA 트랜잭션 브랜치(XA Transaction Branch)의 정보를 보여주는 뷰이다.

다음은 XA 트랜잭션 브랜치의 정보를 조회하는 예이다. 본 예제에서는 XID와 FAIL_TIME 정보를 이용하여 커밋과 롤백을 수행할 브랜치를 선택한다.

SQL> SELECT LOCAL_TRAN_ID, XID, STATUS, FAIL_TIME, FORCE_TIME
    FROM DBA_2PC_PENDING;

LOCAL_TRAN_ID
-------------------------------------
XID
-------------------------------------
STATUS          FAIL_TIME  FORCE_TIME
--------------- ---------- ----------
2.16.18
1.1000.1000
PREPARED        2006/12/11

1 selected.          

DBA는 다음과 같이 원하는 XA 트랜잭션 브랜치에 커밋 명령을 실행할 수 있다. 그러면 해당 XA 트랜잭션 브랜치에서 잡고 있던 리소스는 반환되고 해당 트랜잭션은 커밋된다.

SQL> commit force '2.16.18';

Commit succeeded.            

DBA는 강제 커밋(commit force)을 통해 롤백할 수 있다.

SQL> rollback force '2.16.18';

Rollback succeeded.            

TM에 의한 정식 커밋이 아니고 DBA의 임의의 결정으로 커밋을 실행하면 해당 XA 트랜잭션 브랜치의 정보는 그대로 남아 있는다.

다음과 같이 FORCE_TIME에 DBA가 강제로 커밋한 시간이 남아 있음을 알 수 있다.

SQL> SELECT LOCAL_TRAN_ID, XID, STATUS, FAIL_TIME, FORCE_TIME
    FROM DBA_2PC_PENDING;

LOCAL_TRAN_ID
-------------------------------------
XID
-------------------------------------
STATUS          FAIL_TIME  FORCE_TIME
--------------- ---------- ----------

1.1000.1000
FORCED_COMMIT   2006/12/11 2006/12/12


1 selected            

해당 XA 트랜잭션 브랜치의 정보는 TM이 xa_forget을 이용하여 더 이상 XA 트랜잭션 브랜치 정보가 필요 없다고 판단하면 해당 정보를 제거한다. RM에서는 TM의 요청이 있기 전까지는 XA 트랜잭션 브랜치의 정보를 제거하지 않는다.

데이터베이스 링크는 다음과 같은 접근 권한에 따라 생성 및 제거 방법이 다르다.

Public DBLink

데이터베이스 링크를 생성한 사용자와 다른 사용자들도 데이터베이스 링크를 이용할 수 있다. Public DBLink를 생성하기 위해서는 create public database link 권한이 있어야 한다.

다음은 Public DBLink를 생성하는 예이다.

create public database link public_tibero using 'remote_2';

위의 예에서 using 절 이후의 'remote_2'는 연결할 데이터베이스를 가리키는 이름으로 tbdsn.tbr 파일에 해당 데이터베이스의 연결 정보가 저장되어 있어야 한다.

다음은 Public DBLink를 제거하는 예이다. Public DBLink는 drop public database link 권한을 가진 사용자만 제거할 수 있다.

drop public database link public_tibero;

Private DBLink

데이터베이스 링크를 생성한 사용자만 데이터베이스 링크를 사용할 수 있다. Private DBLink를 생성하기 위해서는 create database link 권한이 있어야 한다.

다음은 Private DBLink를 생성하는 예이다.

create database link remote_tibero using 'remote_1';

위의 예에서는 remote_1은 데이터베이스에 연결하는 remote_ tibero라는 이름의 데이터베이스 링크를 생성한다. 이 데이터베이스 링크는 Private DBLink이므로 생성한 사용자 외에는 사용할 수 없다.

다음은 Private DBLink를 제거하는 예이다. Private DBLink는 생성한 사용자만 제거할 수 있다.

drop database link remote_tibero;

원격 데이터베이스와의 연결에 사용하는 계정을 설정하는 방법은 다음과 같이 두 가지가 있다.

원격 데이터베이스에 연결하기 위한 계정은 CREATE SESSION 등의 권한을 가져야 하며, 데이터베이스 링크를 통해 원격 데이터베이스의 연결에 사용된 계정의 권한을 로컬 사용자가 획득하게 되므로 권한 관리에 유의해야 한다. 특히 Public DBLink의 경우에는 모든 로컬 사용자가 원격 데이터베이스에 대한 권한을 갖기 때문에 주의하여 사용해야 한다.

다음은 지정한 계정을 이용하는 데이터베이스 링크의 생성 예이다.

create database link remote_tibero connect to user1
identified by 'password' using 'remote_1';

다음은 현재 연결된 계정을 이용하는 데이터베이스 링크의 생성 예이다.

create database link remote_tibero using 'remote_1';

데이터베이스 링크를 통해 질의를 수행할 때 데이터베이스 링크의 대상이 Tibero가 아닌 다른 DBMS라면 각각의 DBMS를 위한 게이트웨이를 통해 데이터베이스 링크를 수행할 수 있다.

Tibero 서버는 다른 DBMS에 필요한 질의를 해당 게이트웨이에 전달한다. 게이트웨이는 원격 DBMS에 접속하여 Tibero 서버로부터 전달 받은 질의를 수행하고 그 결과를 다시 Tibero 서버로 전송한다.

다른 DBMS로의 데이터베이스 링크 기능을 사용하는 경우에는 해당 DBMS에 대한 게이트웨이 바이너리와 설정 파일이 필요하다.

본 절에서는 DBMS 벤더별로 게이트웨이의 종류를 설명하고, 게이트웨이와 Tibero 서버가 같은 머신에 존재하는 경우와 다른 머신에 존재하는 경우를 알아본다. 또한 게이트웨이에서 제공하는 옵션 및 로깅도 설명한다.

DBMS 벤더별 게이트웨이

다음은 Tibero에서 데이터베이스 링크 기능을 지원하고 있는 다른 DBMS의 종류와 게이트웨이 바이너리명이다.

각각의 게이트웨이 바이너리는 DBMS의 버전에 따라 다를 수 있기 때문에 버전에 맞는 게이트웨이 바이너리를 사용할 것을 권장한다.

ora_dblink=(
              (GATEWAY=(PROGRAM=gw4orcl)
                       (TARGET=orcl)
                       (TX_MODE=GLOBAL))
  )

db2_dblink=(
              (GATEWAY=(PROGRAM=gw4db2)
                       (TARGET=sample)
                       (TX_MODE=GLOBAL))
  )

ora_link_remote=(
                   (GATEWAY=(LISTENER=(HOST=12.34.56.78)
                                      (PORT=9999))
                            (TARGET=orcl)
                            (TX_MODE=GLOBAL))
  )

db2_link_remote=(
                   (GATEWAY=(LISTENER=(HOST=12.34.56.78)
                                      (PORT=9999))
                            (TARGET=sample)
                            (TX_MODE=GLOBAL))
  )     

$ gw4orcl

> sc create [리스너 이름] binPath= [게이트웨이 바이너리 위치]\gw4orcl.exe

$TBGW_HOME
      |--- DBMS 벤더명
              |--- config
              |      |--- tbgw.cfg
              |--- log
                     | --- 게이트웨이의 로그 파일

  LOG_DIR=${TBGW_HOME}/{DBMS 벤더명}/log
  LOG_LVL=2
  LISTENER_PORT=9999
  MAX_LOG_SIZE=20k
  FETCH_SIZE=32k

$ gw4orcl -v
  Tibero 5 SP1  Gateway for oracle (Build 70000)
  Linux Tibero_Linux 2.6.22-16-generic #1 SMP Mon Nov 24 17:50:35
  GMT 2008 x86_64 GNU/Linux version (little-endian)

mssql_link_remote=(
                     (GATEWAY=(LISTENER=(HOST=12.34.56.78)
                                        (PORT=9093))
                              (TARGET=192.168.16.25:1433:master)
                              (TX_MODE=LOCAL))
  )

ase_link_remote=(
                   (GATEWAY=(LISTENER=(HOST=12.34.56.78)
                                      (PORT=9093))
                            (TARGET=192.168.16.25:5000:master)
                            (TX_MODE=LOCAL))
  )

gp_link_remote=(
                   (GATEWAY=(LISTENER=(HOST=12.34.56.78)
                                      (PORT=9093))
                            (TARGET=192.168.16.25:5000:master)
                            (TX_MODE=LOCAL))
  )

설치 디렉터리
  |--- tbJavaGW
         |--- jgw.cfg
         |--- jgwlog.properties
         |--- tbgw
         |--- lib
         |     |--- tbgateway.jar
         |     |--- commons-collections.jar
         |     |--- commons-pool.jar
         |     |--- log4j-1.2.15.jar
         |--- log
               | --- 게이트웨이의 로그 파일

DATABASE=SQL_SERVER
  LISTENER_PORT=9093
  INIT_POOL_SIZE=10
  MAX_POOL_SIZE=100
  MAX_CURSOR_CACHE_SIZE=100
  ENCODING=MSWIN949
  MAX_LONGVARCHAR=4K
  MAX_LONGRAW=4K     

$ ./tbgw

-------------------------------
 Name : TIBERO JAVA GATEWAY
 Port : 9093
-------------------------------
$

c:\tbgateway> service_gw.bat install

c:\tbgateway> prunmgr.exe //ES//tbgateway

c:\tbgateway> service_gw.bat uninstall

$ ./tbgw -v
TIBERO tbgateway 5.0.68493

Usage: GatewayMain [PARAMETER1=VALUE] [PARAMETER2=VALUE] ...
Parameters:
    CONFIG    Config File path and name, default: jgw.cfg 

데이터베이스 링크를 통해 접근할 수 있는 데이터베이스 객체의 종류는 다음과 같다.

데이터베이스 링크를 사용할 수 있는 SQL 문장은 SELECT, INSERT, UPDATE, DELETE 이다. 단, SELECT 문에서 FOR UPDATE 절은 사용할 수 없다.

Homogeneous DBLink로 구성된 분산 트랜잭션은 Global Consistency를 제공한다. 이를 위해 분산 트랜잭션에 참여한 데이터베이스 간에 TSN을 동기화하는 작업을 한다.

TSN을 동기화하는 작업은 데이터베이스 사이에 메시지를 교환할 때 이루어지며, 커밋할 때에는 모든 노드의 Commit TSN을 동일하게 동기화해야 한다.

정체되고 있는 TX에 대한 처리는 XA의 경우와 동일하다. 본 절에서는 Two-phase commit mechanism에서 XA와의 차이점을 설명한다.

commit point site

데이터베이스 링크를 사용한 분산 트랜잭션에서는 트랜잭션에 참여한 노드 중에서 commit point site를 선정한다.

commit point site는 Two-phase commit을 시작할 때 설정하며 세션 트리를 따라가며 가장 큰 commit point strength를 가진 노드를 선택한다. 각 데이터베이스는 commit point strength를 가지는데 이 값은 초기화 파라미터 COMMIT_POINT_STRENGTH로 설정할 수 있다.

commit point site는 Two-phase commit의 prepare phase에서 prepare를 하지 않는다. 대신 모든 노드가 prepare를 한 이후에 commit point site를 바로 커밋한다. 그 이후에 다른 노드들은 commit phase를 실행한다.

데이터베이스 링크에서 이와 같이 수정된 Two-phase commit을 사용하는 이유는 Global consistency를 보장하기 위해 생기는 오버헤드를 줄이기 위해서이다. 데이터베이스 링크에서 Global consistency를 보장하기 위해서는 모든 노드의 Commit TSN을 동일하게 해야 한다. Commit TSN은 prepare phase까지 완료한 노드 중 가장 큰 TSN으로 결정하고 commit phase에서 결정된 TSN을 사용해 커밋을 한다.

commit phase 전에는 Commit TSN을 모르기 때문에 다른 트랜잭션에서 해당 트랜잭션의 수정 정보의 조회 여부를 결정할 수 없다. 다른 트랜잭션에서 prepare된 TX가 수정한 내용에 접근하는 경우 다음과 같은 에러가 발생한다.

TBR-21019: lock held by in-doubt distributed transaction.

데이터베이스 링크를 사용할 때 prepare 상태에서 정체가 발생하는 경우 해당 데이터에 접근할 수 없기 때문에 In-doubt 트랜잭션으로 인한 문제가 발생된다.

이와 같은 문제를 경감하기 위해 트랜잭션에 참여한 노드 중 한 노드는 Prepare Phase를 거치지 않고, 트랜잭션이 in-doubt 상태가 되더라도 commit point site는 위와 같이 데이터를 접근하지 못하는 상황을 방지할 수 있도록 하였다. 따라서 commit point strength는 데이터 접근성이 많이 필요한 데이터베이스일수록 큰 값을 설정해야 한다.

Tibero에서는 생성한 데이터베이스 링크의 정보를 제공하기 위해 다음 표에 나열된 정적 뷰를 제공하고 있다.

V$DBLINK

동적 뷰 V$DBLINK는 해당 세션에서 원격 데이터베이스에 연결된 데이터베이스 링크의 정보를 보여주는 뷰이다.

사용자가 데이터베이스 링크를 통해 질의를 수행하면 원격 데이터베이스에 연결을 생성하고, 해당 질의 또는 트랜잭션이 종료되어도 연결을 해제하지 않고 계속 유지된다. 즉, 같은 데이터베이스 링크를 사용했을 때 발생하는 연결의 비용을 줄이기 위함이다. 이렇게 생성된 연결은 세션이 종료 또는 명시적으로 연결을 종료할 때까지 계속 유지된다.

다음은 remote_tibero를 통해 SELECT 문을 수행한 후 V$DBLINK를 통해 연결 정보를 조회하는 예이다.

SQL> select * from employee@remote_tibero;

 ID     NAME
--- ---------
  1      KIM
  2      LEE
  3     HONG

3 rows selected.

SQL> select * from V$DBLINK;

DB_LINK         OWNER_ID   OPEN_CURSORS   IN_TRANSACTION  HETEROGENEOUS
-------------  ----------  ------------   --------------  -------------
REMOTE_TIBERO         15             0    YES             NO

COMMIT_POINT_STRENGTH
---------------------
                  1

1 row selected.

현재 remote_tibero의 소유자의 ID는 15번이고, 현재 열려있는 커서는 없으며 트랜잭션을 수행하고 있다. 동일한 Tibero 서버에 대한 데이터베이스 링크이며, 원격 데이터베이스의 commit point strength는 1이다.

다음은 데이터베이스 링크 기능을 종료하는 예이다.

SQL> alter session close database link remote_tibero;
TBR-12056: database link is in use.                       ... ① ...

SQL> commit;                                              ... ② ...
Commit succeeded.

SQL> alter session close database link remote_tibero;     ... ③ ...
Session altered.

SQL> select * from V$DBLINK;                              ... ④ ...

DB_LINK          OWNER_ID   OPEN_CURSORS   IN_TRANSACTION  HETEROGENEOUS
--------------  ----------  ------------   --------------  -------------

COMMIT_POINT_STRENGTH
---------------------

0 row selected.     

① 데이터베이스 링크 기능을 종료하려는 시도가 실패한 이유는 해당 데이터베이스 링크를 사용한 트랜잭션이 아직 수행 중이기 때문이다.

② commit 문을 통해 해당 트랜잭션을 종료한다.

③ 다시 데이터베이스 링크 기능의 종료를 시도한다.

④ 정상적으로 데이터베이스 링크가 종료되며 이를 확인하는 방법은 V$DBLINK를 통해 확인할 수 있다.