분산 트랜잭션
여러 개의 노드 또는 다른 종류의 데이터베이스가 참여하는 하나의 트랜잭션을 분산 트랜잭션(Distributed Transaction)이라고 합니다. Tibero에서는 분산 트랜잭션을 처리하기 위해 XA와 데이터베이스 링크(DBLink)를 통해 지원합니다.
XA
Tibero는 X/Open DTP(Distributed Transaction Processing) 규약의 XA를 지원합니다. XA는 2PC(Two-phase commit)를 이용하여 분산 트랜잭션을 처리합니다.
다음은 XA가 어떻게 동작하는지를 나타내는 그림입니다.
[그림 1] XA의 동작(AP, TM, DB의 상호 작용)
일반적으로 XA는 트랜잭션 매니저(TM: Transaction Manager, 이하 TM)에 의해 코디네이트됩니다. 가장 먼저 애플리케이션 프로그램(AP: Application Program, 이하 AP)은 TM에 분산 트랜잭션의 시작을 알립니다.
TM은 AP의 요청을 받고 어떤 데이터베이스의 노드가 해당 분산 트랜잭션에 참여하는지 확인합니다. 그 다음 각 데이터베이스 노드에 분산 트랜잭션의 시작을 알린다. 각 데이터베이스 노드에 분산 트랜잭션 의 시작을 알릴 때 TM은 내부에 고유한 트랜잭션 ID(이하 XID)를 만들어서 함께 전달합니다. 그러면 각 데이터베이스 노드는 이 XID와 관련된 분산 트랜잭션을 시작합니다. 앞으로 AP로부터 들어오는 요청은 해당 분산 트랜잭션에 대한 작업이라고 인식합니다.
AP는 각 데이터베이스에 SQL 문장을 전달함으로써 필요한 작업을 진행합니다. 이때 각 데이터베이스는 전달 받은 요청을 해당 XID와 관련된 작업이라고 인지하고 SQL 문장을 실행합니다.
모든 작업이 완료되면 AP는 TM에 분산 트랜잭션의 종료를 알린다. TM은 해당 XID로 분산 트랜잭션에 참여했던 각 데이터베이스 노드에 커밋과 롤백을 동시에 하도록 지 시합니다. 일부 데이터베이스는 커밋을 하고, 일부 데이터베이스는 롤백을 하는 상황이 벌어지지 않도록 TM은 Two-phase commit mechanism을 통해 수행합니다.
Two-phase commit mechanism
Two-phase commit mechanism은 분산 컴퓨팅 환경에서 트랜잭션에 참여하는 모든 데이터베이스가 정상 적으로 수정되었음을 보장하는 두 단계 커밋 프로토콜입니다. 분산 트랜잭션에 참여한 모든 데이터베이스 가 모두 함께 커밋되거나 롤백되는 것을 보장합니다.
Two-phase commit mechanism은 다음과 같이 두 단계로 작업이 이루어진다.
First Phase(또는 prepare phase)
First Phase는 각 데이터베이스 노드에 커밋을 하기 위한 준비 요청 단계입니다. 다음은 First Phase가 실행되는 과정입니다.
TM은 각 데이터베이스 노드에 커밋을 준비하라는 prepare 메시지를 보냅니다.
요청을 받은 각 데이터베이스는 커밋을 준비합니다. 커밋을 하기 위한 준비 작업에는 필요한 리소스에 잠금(Lock)을 설정하거나 로그 파일을 저장하는 작업 등이 있습니다.
각 데이터베이스는 커밋 준비 여부에 따라 TM에 성공 또는 실패 여부를 알린다. 커밋 준비가 모두 끝 나면 prepare가 성공한 것이고, 커밋 준비를 실패하면 prepare가 실패한 것입니다.
Second Phase(또는 commit phase)
TM은 참여한 모든 데이터베이스 노드로부터 prepare의 완료 메시지를 받을 때까지 대기합니다. 이 단계 에서는 전달 받은 prepare의 메시지에 따라 해당 결과가 다릅니다.
롤백
한 데이터베이스 노드라도 prepare ok 메시지를 받지 않으면 이 트랜잭션은 커밋할 수 없다고 판단하고, 모든 데이터베이스 노드에 롤백 메시지를 보내 해당 작업을 롤백
커밋
모든 데이터베이스 노드로부터 prepare ok 메시지를 받으면 다시 모든 데이터베이스 노드에 커밋 메시지를 보내고 모든 작업을 커밋
XA의 In-doubt 트랜잭션 처리
Two-phase commit mechanism에 의해 첫 번째 prepare 메시지를 받으면 데이터베이스는 분산 트랜잭션 에 해당하는 리소스를 잠금 처리하거나 로그를 남김으로써 커밋할 준비를 합니다. 그런데 prepare까지 마 친 상태에서 네트워크의 이상으로 다음 메시지(커밋 또는 롤백)를 받지 못하는 경우가 발생할 수 있습니다.
데이터베이스는 해당 트랜잭션을 커밋해야 할지 롤백해야 할지 판단할 수 없습니다. 따라서 다음 메시지가 올 때까지 prepare된 리소스에 잠금 처리를 한 채로 기다리게 되는데 이러한 경우를 In-doubt 트랜잭션이라 고 합니다.
일반적으로 네트워크 또는 TM 측의 문제가 해결됩니다면 복구되는 즉시 TM은 In-doubt 트랜잭션에 커밋 또 는 롤백 메시지를 다시 보냅니다. 하지만 In-doubt 트랜잭션이 잡고 있는 리소스가 급하게 반환 되어야 하는 상황이 발생한면 DBA는 임의로 In-doubt 트랜잭션을 커밋 또는 롤백시킴으로써 해당 리소스를 반환할 수 있습니다. 이러한 경우는 DBA의 판단에 의해 결정되므로 이후에 TM으로부터 전달되는 커밋 또는 롤백 메 시지가 DBA가 결정한 판단과 다릅니다면 전체 분산 트랜잭션이 일부 커밋되거나 롤백되는 현상이 발생할 수 있습니다. 따라서 전체 분산 트랜잭션의 일관성을 위해 TM의 다음 요청을 기다려야 합니다.
이러한 문제를 감수하더라도 In-doubt 트랜잭션을 처리해야 하는 경우가 발생한다면 DBA_2PC_PENDING뷰를 이용하여 이를 해결합니다.
DBA_2PC_PENDING 뷰
DBA_2PC_PENDING 뷰는 현재 정체되고 있는 XA 트랜잭션 브랜치(XA Transaction Branch)의 정보를 보여주는 뷰입니다.
다음은 XA 트랜잭션 브랜치의 정보를 조회하는 예입니다. 본 예제에서는 XID와 FAIL_TIME 정보를 이용하 여 커밋과 롤백을 수행할 브랜치를 선택합니다.
[예 1] DBA_2PC_PENDING 뷰 조회
DBA는 XA 트랜잭션 브랜치에 대해 Rollback 또는 Commit 명령을 실행할 수 있습니다. Rollback 또는 Commit 수행 시 해당 XA 트랜잭션 브랜치에서 잡고 있던 리소스는 반환됩니다.
강제 Commit을 통해 원하는 XA 트랜잭션 브랜치에 커밋 명령을 실행할 수 있습니다.
강제 Rollback을 통해 원하는 XA 트랜잭션 브랜치에 롤백 명령을 실행할 수 있습니다.
TM에 의한 정식 커밋이 아니고 DBA의 임의의 결정으로 커밋을 실행하면 해당 XA 트랜잭션 브랜치의 정 보는 그대로 남아 있는다.
다음과 같이 FORCE_TIME에 DBA가 강제로 커밋한 시간이 남아 있음을 알 수 있습니다.
해당 XA 트랜잭션 브랜치의 정보는 TM이 xa_forget을 이용하여 더 이상 XA 트랜잭션 브랜치 정보가 필 요 없습니다고 판단하면 해당 정보를 제거합니다. 자원 관리자(RM: Resource Manager, 이하 RM)에서는 TM의 요청이 있기 전까지는 XA 트랜잭션 브랜치의 정보를 제거하지 않습니다.
데이터베이스 링크
데이터베이스 링크는 원격 데이터베이스의 데이터를 마치 로컬 데이터베이스의 데이터처럼 접근할 수 있 는 방법을 제공합니다. 데이터베이스 링크를 사용하면 원격 데이터베이스의 데이터에 대한 접근, 수정이 용이하며 손쉽게 분산 트랜잭션을 처리할 수 있습니다. 분산 트랜잭션은 트랜잭션의 원자성을 보장하기 위해 XA 와 마찬가지로 Two-phase commit mechanism을 사용합니다.
데이터베이스 링크 생성, 제거
데이터베이스 링크는 다음과 같은 접근 권한에 따라 생성 및 제거 방법이 다릅니다.
Public DBLink
데이터베이스 링크를 생성한 사용자와 다른 사용자들도 데이터베이스 링크를 이용할 수 있습니다. Public DBLink를 생성하기 위해서는 create public database link 권한이 있어야 합니다.
다음은 Public DBLink를 생성하는 예입니다.
위의 예에서 using 절 이후의 'remote_2'는 연결할 데이터베이스를 가리키는 이름으로 tbdsn.tbr 파일에 해 당 데이터베이스의 연결 정보가 저장되어 있어야 합니다.
다음은 Public DBLink를 제거하는 예입니다. Public DBLink는 drop public database link 권한을 가진 사용 자만 제거할 수 있습니다.
Private DBLink
데이터베이스 링크를 생성한 사용자만 데이터베이스 링크를 사용할 수 있습니다. Private DBLink를 생성하기 위해서는 create database link 권한이 있어야 합니다.
다음은 Private DBLink를 생성하는 예입니다.
위의 예에서 using 절 이후의 'remote_1'는 연결할 데이터베이스를 가리키는 이름으로 tbdsn.tbr 파일에 해 당 데이터베이스의 연결 정보가 저장되어 있어야 합니다. 이 데이터베이스 링크는 Private DBLink이므로 생 성한 사용자 외에는 사용할 수 없습니다.
다음은 Private DBLink를 제거하는 예입니다. Private DBLink는 생성한 사용자만 제거할 수 있습니다.
원격 데이터베이스 연결
원격 데이터베이스와의 연결에 사용하는 계정을 설정하는 방법은 다음과 같이 두 가지가 있습니다.
지정한 계정
지정한 ID와 패스워드를 사용해 원격 데이터베이스에 접속
단, 지정한 ID와 패스워드를 가진 계정이 원격 데이터베이스에 존재해야 함
어떤 사용자가 사용하더라도 데이터베이스 링크를 생성할 때에는 지정한 ID와 패스워드를 사용해야 함
패스워드는 작은따옴표(' ') 사이에 패스워드가 입력된 경우에만 유효
예를 들어 아래 예제에서 "password"로 패스워드가 입력된 경우에는 데이터베이스 링크 생성에 실패하게 됨
현재 연결된 계정
현재 질의를 수행한 사용자의 ID와 패스워드를 사용해 원격 데이터베이스에 접속
데이터베이스 링크를 사용하는 사용자의 ID와 패스워드가 원격 데이터베이 스에 동일하게 존재해야 함
계정을 지정하지 않으면 기본으로 현재 연결된 계정으로 접속하도록 설정
따라서 데이터베이스 링크를 사용하는 사용자별로 다른 ID와 패스워드를 사용
원격 데이터베이스에 연결하기 위한 계정은 CREATE SESSION 등의 권한을 가져야 하며, 데이터베이스 링크를 통해 원격 데이터베이스의 연결에 사용된 계정의 권한을 로컬 사용자가 획득하게 되므로 권한 관 리에 유의해야 합니다. 특히 Public DBLink의 경우에는 모든 로컬 사용자가 원격 데이터베이스에 대한 권한 을 갖기 때문에 주의하여 사용해야 합니다.
다음은 지정한 계정을 이용하는 데이터베이스 링크의 생성 예입니다.
다음은 현재 연결된 계정을 이용하는 데이터베이스 링크의 생성 예입니다.
게이트웨이
데이터베이스 링크를 통해 질의를 수행할 때 데이터베이스 링크의 대상이 Tibero가 아닌 다른 DBMS라면 각각의 DBMS를 위한 게이트웨이를 통해 데이터베이스 링크를 수행할 수 있습니다.
Tibero 서버는 다른 DBMS에 필요한 질의를 해당 게이트웨이에 전달합니다. 게이트웨이는 원격 DBMS에 접 속하여 Tibero 서버로부터 전달 받은 질의를 수행하고 그 결과를 다시 Tibero 서버로 전송합니다. 다른 DBMS 로의 데이터베이스 링크 기능을 사용하는 경우에는 해당 DBMS에 대한 게이트웨이 바이너리와 설정 파일 이 필요합니다.
본 절에서는 DBMS 벤더별로 게이트웨이의 종류를 설명하고, 게이트웨이와 Tibero 서버가 같은 머신에 존재하는 경우와 다른 머신에 존재하는 경우를 알아본다. 또한 게이트웨이에서 제공하는 옵션 및 로깅도 설명합니다.
DBMS 벤더별 게이트웨이
다음은 Tibero에서 데이터베이스 링크 기능을 지원하고 있는 다른 DBMS의 종류와 게이트웨이 바이너리 명입니다.
Oracle
gw4orcl
C
Oracle 11g, 12c, 18c, 19c
[참고]
Oracle 의 경우는 64-bit OS에서만 지원
client/bin/에 있는 gw_install.sh 스크립트를 수행하여 쉽게 환경설정을 할 수 있음
DB2
gw4db2
C
DB2 V8, DB2 9, DB2 9.5
MS-SQL SERVER
tbgateway.jar
Java
MS-SQL SERVER 2000, 2005, 2008
Adaptive Server Enterprise(Sybase)
tbgateway.jar
Java
Sybase SQL Server 10.0.2 or later
GREENPLUM
tbgateway.jar
Java
GREENPLUM or PostgreSQL
MySQL
tbgateway.jar
Java
MySQL or MariaDB
각각의 게이트웨이 바이너리는 DBMS의 버전에 따라 다를 수 있기 때문에 버전에 맞는 게이트웨이 바이 너리를 사용할 것을 권장합니다.
참고
DB2 게이트웨이의 경우 HP PA-RISC 머신은 지원하지 않습니다.
MySQL 게이트웨이의 경우 mysql-connector-java 5.1.19 이상의 버전 사용해야 합니다.
게이트웨이를 통해 Oracle의 프러시저를 수행하는 경우 해당 프러시저 내에서 local commit을 수행할 수 없습니다.
게이트웨이 프로세스 생성 방식
게이트웨이는 연결할 DBMS가 제공하는 라이브러리가 필요합니다. 라이브러리를 Tibero 서버가 설치된 곳 에서 사용할 수 있습니다면 Tibero 서버와 같은 머신 내에서 게이트웨이 프로세스를 생성하여 데이터베이스 링크 기능을 수행할 수 있습니다. 생성된 게이트웨이 프로세스는 해당 데이터베이스 링크를 사용하는 세션이 닫힐 때 종료됩니다.
다음은 Oracle 서버와 연결하는 데이터베이스 링크를 사용하기 위해 tbdsn.tbr 파일을 설정하는 예입니다.
<<tbdsn.tbr>>
다음은 DB2 서버와 연결하는 데이터베이스 링크를 사용하기 위해 tbdsn.tbr 파일을 설정하는 예입니다.
<<tbdsn.tbr>>
PROGRAM
게이트웨이 바이너리 위치에 대한 절대 경로
게이트웨이 바이너리가
$TB_HOME/client/bin디렉터리에 있는 경우 바이너리명만 명시할 수 있음
CONFIG
게이트웨이 설정 파일 위치에 대한 절대 경로
TARGET
DBMS별로 다음과 같이 의미하는 것이 다름
Oracle 서버 : 네트워크 서비스명
DB2 서버 : 데이터베이스명
TX_MODE
글로벌 트랜잭션(Global Transaction) 또는 로컬 트랜잭션(Local Transaction)으로 처리할지의 여부를 설정
글로벌 트랜잭션은 커밋을 요청할 때 Two-phase 커밋으로 동작하고, 로컬 트랜잭션은 Two-phase 커밋으로 동작하지 않음
TX_MODE의 값은 처리 여부에 따라 다음과 같이 설정할 수 있음
GLOBAL : 글로벌 트랜잭션인 경우
LOCAL : 로컬 트랜잭션인 경우
CHARACTER_SET
게이트웨이의 문자 집합을 재설정할 때 설정
Tibero 서버에서 지원하는 문자 집합을 사용할 수 있음
SKIP_CHAR_CONV
게이트웨이의 초기화 파라미터 SKIP_CHAR_CONV 값을 재설정
Y 또는 y로 설정된 경우에 게이트웨이의 SKIP_CHAR_CONV의 값이 Y로 재설정되고, N 또는 n으로 설정된 경우에 게이트웨이의 SKIP_CHAR_CONV의 값이 N으로 재설정
TARGET 서버가 Oracle 서버인 경우에만 설정 가능
SKIP_CHAR_CONV 에 대한 자세한 사항은 게이트웨이 설정(ORACLE, DB2)을 참고
멀티 스레드 서버 방식
사용자는 Tibero 서버와 같은 머신 또는 원격에 있는 머신에서 게이트웨이를 멀티 스레드 서버 방식으로 시작할 수 있습니다. Tibero 서버의 세션은 tbdsn.tbr 파일에 명시된 접속 정보를 통해 게이트웨이와 TCP/IP 통 신을 합니다. 멀티 스레드 서버 방식의 게이트웨이는 Tibero 서버의 세션으로부터 요청이 오면 미리 생성된 워킹 스레드 중 하나가 해당 요청을 처리합니다. 특히 Java 프로그래밍 언어를 사용하는 게이트웨이는 멀티 스레드 서버 방식만을 지원합니다.
다음은 각 벤더별 서버와 연결하는 데이터베이스 링크를 사용하기 위해 tbdsn.tbr 파일을 설정하는 예와 항목에 대한 설명입니다.
Oracle 서버
DB2 서버
MS-SQL 서버
Sybase ASE 서버
GREENPLUM 서버
MySQL 서버
LISTENER
게이트웨이의 접속 정보
HOST : 원격에 있는 머신에서 게이트웨이가 존재하는 호스트의 IP 주소를 설정
PORT : 원격에 있는 머신에서 게이트웨이가 존재하는 호스트의 포트 번호를 설정
TARGET
DBMS별로 다음과 같이 의미하는 것이 다름
Oracle 서버 : 네트워크 서비스명
DB2 서버 : 데이터베이스명
MS-SQL 서버 : 서버의 연결 정보(IP:PORT:DATABASE NAME)
Sybase ASE 서버 : 서버의 연결 정보(IP:PORT:DATABASE NAME)
GREENPLUM 서버 : 서버의 연결 정보(IP:PORT:DATABASE NAME)
MySQL 서버 : 서버의 연결 정보(IP:PORT:DATABASE NAME)
TX_MODE
글로벌 트랜잭션(Global Transaction) 또는 로컬 트랜잭션(Local Transaction)으로 처리할지의 여부를 설정
글로벌 트랜잭션은 커밋을 요청할 때 Two-phase 커밋으로 동작하고, 로컬 트랜잭션은 Two-phase 커밋으로 동작하지 않음
TX_MODE의 값은 처리 여부에 따라 다음과 같이 설정할 수 있음
GLOBAL : 글로벌 트랜잭션인 경우
LOCAL : 로컬 트랜잭션인 경우
CHARACTER_SET
게이트웨이의 문자 집합을 재설정할 때 설정
Tibero 서버에서 지원하는 문자 집합을 사용할 수 있음
C 언어를 사용하는 게이트웨이인 경우에만 설정 가능
SKIP_CHAR_CONV
게이트웨이의 초기화 파라미터 SKIP_CHAR_CONV의 값을 재설정할 때 설정
Y 또는 y로 설정된 경우에 게이트웨이의 SKIP_CHAR_CONV의 값이 Y로 재설정되고, N 또는 n으로 설정된 경우에 게이트웨이의 SKIP_CHAR_CONV의 값이 N으로 재설정됨
TARGET 서버가 Oracle 서버인 경우에만 설정 가능
SKIP_CHAR_CONV에 대한 자세한 사항은 게이트웨이 설정(ORACLE, DB2)을 참고
BYTES_CHARSET
TARGET 서버와 게이트웨이 사이의 문자 집합 변환에 사용되는 게이트웨이의 문자 집합을 게이트웨이의 초기화 파라미터 ENCODING의 값과 다른 문자 집합으로 재설정할 때 설정
Tibero 서버에서 지원하는 문자 집합을 사용할 수 있다.Tibero 서버가 한글을 지원하지 않는 문자 집합과 한글 데이터를 동시에 사용하고 있는 특수한 경우에 사용
Java 프로그래밍 언어를 사용하는 게이트웨이인 경우에만 설정 가능
원격에 있는 게이트웨이를 사용하기 위해서는 먼저 원격에 있는 게이트웨이를 실행시켜야 합니다.
Oracle 서버
Oracle과 DB2 서버용 게이트웨이의 경우 -q 옵션을 통해 기존에 수행 중인 게이트웨이를 종료할 수 있습니다.
MS-SQL 서버
게이트웨이 관련 디렉터리 구조(ORACLE, DB2)
게이트웨이는 기본적으로 TBGW_HOME 환경변수를 통해 설정 파일을 읽고 로그 파일을 기록합니다.
TBGW_HOME 환경변수가 설정되어 있지 않은 경우에는 기본값은 '${TB_HOME}/client/gateway'입니다. Windows 환경에서는 기본값이 '%TB_HOME%\client\gateway'로 설정됩니다.
게이트웨이가 사용하는 설정 파일과 로그 파일이 존재하는 디렉터리 구조는 다음과 같습니다.
위의 디렉터리 구조에서 $TBGW_HOME이라고 보이는 부분은 시스템 환경에 맞게 바꿔서 읽어야 합니다.
DBMS 벤더명/config
tbgw.cfg라는 게이트웨이 설정 파일이 있습니다. 사용자가 게이트웨이와 관련된 설정 값을 변경하고 싶을 때 생성하며, 위의 디렉터리 구조에 맞게 위치시킵니다.
DBMS 벤더명/log
게이트웨이와 관련된 로그 파일이 있습니다. 로그 파일은 DBMS 벤더명에 맞춰 생성됩니다. 다음은 DBMS 벤더별 로그 파일입니다.
Oracle
gw4orcl.log
gw4orcl_lsnr.log
DB2
gw4db2.log
gw4db2_lsnr.log
게이트웨이 설정(ORACLE, DB2)
tbgw.cfg 파일에 초기화 파라미터의 설정 값을 명시함으로써 게이트웨이와 관련된 설정을 변경할 수 있습니다.
다음은 게이트웨이를 설정하는 예입니다.
<<tbgw.cfg>>
CHARACTER_SET
게이트웨이의 문자집합을 설정
이 값이 설정되지 않은 경우 TB_NLS_LANG 환경변수에 정의된 값을 사용 (기본값: MSWIN949)
FETCH_SIZE
데이터베이스에 질의 처리를 할 때 한 번에 가져오는 데이터의 크기를 설정 (기본값: 32KB, 최댓값: 64KB)
IGNORE_WARNING
원격 데이터베이스에서 발생한 경고 메시지를 무시할지 여부를 설정(기본값: N)
IP_VERSION
리스너가 사용하는 IP 프로토콜을 명시하기 위해 사용
4 : IPv4를 사용하는 경우 설정 값(기본값)
6 : IPv6를 사용하는 경우 설정 값
대상 DBMS가 Oracle인 경우에만 IPv6 사용이 가능
LOG_DIR
게이트웨이의 로그 파일을 저장할 경로를 설정
(기본값: ${TBGW_HOME}/{DBMS 벤더명}/log)
LOG_LVL
로그 파일에 남길 로그 레벨을 설정(기본값: 2)
[참고]
게이트웨이 프로세스가 이미 실행 중인 경우 게이트웨이 실행 명령어에 -l [0~6 사이의 값] 옵션을 주어 동적으로 로그 레벨 변경이 가능gw4orcl -l 4
MAX_LOG_BACKUP_SIZE
로그 백업 기능을 사용하는 경우 백업 로그 파일들의 최대 크기(기본값: 0, 단위: Byte)
값이 0인 경우 백업된 로그 파일들의 크기 제한이 없음
값을 명시한 경우 백업 로그 파일들의 크기 합이 설정된 최대 크기를 초과하면 오래된 순서로 로그 파일을 지움
MAX_LOG_SIZE
로그 파일의 최대 크기 (기본값: 0, 단위: Byte)
값이 0인 경우 로그 파일의 최대 크기를 설정하는 데 제한이 없음
값을 명시한 경우 로그 파일이 설정된 최대 크기를 초과하면 로그 파일을 백업
DUMP_FILE
게이트웨이의 allocator dump 파일명과 경로를 설정
(기본값: ${TBGW_HOME}/{DBMS 벤더명}/dump)
[참고]
게이트웨이 프로세스가 이미 실행 중인 경우 게이트웨이 실행 명령어에 -ad 옵션을 주어 allocator dump를 남길 수 있음
gw4orcl -ad
ORACLE_FETCH_SIZE
Oracle용 게이트웨이에만 사용 가능한 옵션
Oracle에 질의 처리를 할 때, 한 번에 가져오는 데이터의 크기
FETCH_SIZE보다 우선으로 적용됨 (기본값: 32KB, 최댓값: 1MB)
QUERY_WITH_UR
DB2용 게이트웨이에만 사용 가능한 옵션
쿼리에 WITH UR 구문을 추가할지 여부를 설정 (기본값: N)
SKIP_CHAR_CONV
Oracle용 게이트웨이에만 사용 가능한 옵션
Oracle에서 한글을 지원하지 않는 문자 집합과 한글 데이터를 동시에 사용하고 있는 특수한 경우에 사용
값이 Y일 경우 Oracle 데이터베이스에 있는 데이터를 문자 집합 변환 없이 가져옴(기본값: N)
VALIDATION_IDLE_TIME
Oracle용 게이트웨이에만 사용 가능한 옵션(기본값: 0, 단위: 초)
0이 아닌 값을 설정할 경우 설정한 만큼의 시간 간격마다 OCI Ping을 수행하여 Target 서버와의 Connection을 유지 (최댓값: 2,678,400)
값이 0인 경우 OCI Ping을 수행하지 않음
다음은 게이트웨이를 리스너 모드로 사용할 때 설정할 수 있는 옵션입니다.
LISTENER_PORT
IPv4를 사용하거나 IPv6를 사용하는 경우 그에 대한 리스너 포트 번호를 설정
설정한 포트 번호의 값으로 포트가 오픈되며, 설정값+1의 추가 포트 가 Statement Cancel을 처리하기 위해 오픈됨(기본값: 9999)
MIN_POOL_SIZE
동시에 접속 가능한 최소 세션 개수를 설정 (기본값: 10)
MAX_POOL_SIZE
동시에 접속 가능한 최대 세션 개수를 설정 (기본값: 100, 최댓값: 1024)
게이트웨이 관련 디렉터리 구조(MS-SQL, Sybase ASE, GREENPLUM, MySQL)
사용자는 ${TB_HOME}/client/bin에 있는 tbJavaGW.zip 파일을 설치할 디렉터리에 복사한 후 압축을 해 제합니다. 기본적으로 타깃 데이터베이스에 대한 JDBC 드라이버 파일(Sybase: jconn3.jar, MS-SQL: sqljd bc.jar, GREENPLUM: postgresql-8.4-701.jdbc3.jar)은 제공하지 않습니다. 따라서 사용자는 해당 서버의JDBC 드라이버 파일을 구한 후 LIB 디렉터리에 복사해야 합니다. 일반적으로 해당 서버의 홈페이지에서 다 운로드 받을 수 있습니다.
게이트웨이가 사용하는 설정 파일과 로그 파일이 존재하는 디렉터리 구조는 다음과 같습니다.
tbJavaGW/tbgw
Java 게이트웨이를 실행시키는 스크립트 파일입니다.
tbJavaGW/jgw.cfg
게이트웨이 설정 파일입니다. 사용자가 게이트웨이와 관련된 설정 값을 변경하고 싶을 때 생성하며 위 의 디렉터리 구조에 맞게 위치시킵니다.
tbJavaGW/jgwlog.properties
로그에 대한 설정 파일입니다. 로그 파일의 크기와 로그 레벨 등을 설정할 수 있습니다. 자세한 형식은 LOG4J를 참고합니다.
tbJavaGW/jgw_service.bat
Windows 환경에서 게이트웨이를 서비스로 사용할 수 있습니다. 서비스에 등록/삭제를 해주는 실행 파일 입니다. 이 파일을 실행하기 위해선 tbJavaGW/prunsrv.exe 파일이 반드시 있어야 합니다.
tbJavaGW/prunsrv.exe
Windows 환경에서 게이트웨이를 서비스에 등록/삭제를 해주는 실행 파일입니다. tbJavaGW/jgw_ser vice.bat 파일을 실행하기 위해서 반드시 필요한 파일입니다. 이 파일은 기본으로 제공되지 않으며 Apache Commons의 Daemon에서 다운받을 수 있습니다.
tbJavaGW/lib
Java 게이트웨이에서 사용하는 JAR 파일이 있는 디렉터리입니다. 타깃 데이터베이스의 JDBC 드라이 버도 해당 디렉터리에 있어야 합니다.
tbJavaGW/log
게이트웨이와 관련된 로그 파일이 생성됩니다.
게이트웨이 설정(MS-SQL SERVER, Sybase ASE, GREENPLUM, MySQL)
jgw.cfg 파일에 초기화 파라미터의 설정 값을 명시함으로써 게이트웨이와 관련된 설정을 변경할 수 있습니다.
다음은 게이트웨이를 설정하는 예입니다.
<<jgw.cfg>>
DATABASE
타깃 데이터베이스를 설정
SQL_SERVER : MS-SQL SERVER (기본값)
ASE : Sybase ASE
GREENPLUM : GREENPLUM– MYSQL : MySQL
LISTENER_PORT
리스너의 포트 번호를 설정
일반적인 요청의 처리를 위해 설정한 번호의 포트를 사용하며, Statement cancel 등의 제어 요청 처리를 위해 설정에 1을 더한 번호의 포트를 추가로 사용 (기본값: 9093)
INIT_POOL_SIZE
게이트웨이가 시작할 때 미리 생성할 워킹 스레드의 개수를 설정(기본값: 10)
MAX_POOL_SIZE
게이트웨이가 최대로 생성할 수 있는 워킹 스레드의 개수를 설정(기본값: 100)
MAX_CURSOR_CACHE_SIZE
워킹 스레드 당 최대로 캐시 가능한 커서의 개수를 설정 (기본값: 100)
ENCODING
Tibero 서버의 세션에 문자열을 전달할 때 사용할 인코딩을 설정
단, Tibero 서버의 문자 집합과 일치시켜야 함
설정할 수 있는 문자 집합은 다음과 같음
ASCII
EU-KR
MSWIN949 (기본값)
UTF-8
UTF-16
SHIFT-JIS
MAX_LONGVARCHAR
게이트웨이는 LONG, CLOB 타입의 데이터를 일정 간격을 정하여 가져오는 방식(Deferred 형태)을 지원하지 않음
CHAR나 VARCHAR 타입처럼 한번에 읽어 오게 되는데 그때 읽어올 수 있는 최대 크기를 설정(기본값: 4KB, 최대값: 32KB)
MAX_LONGRAW
게이트웨이는 LONG RAW, BLOB 타입의 데이터를 일정 간격을 정하여 가져오는 방식을 지원하지 않음
RAW처럼 한번에 읽어 오게 되는데 그때 읽어올 수 있는 최대 크기를 설정 (기본값: 4KB, 최대값: 32KB)
TARGET_DB_FETCH_SIZE
TARGET DB에서 한번에 FETCH해 올 row 수를 설정(기본값: 32)
MySQL의 경우 -2147483648(integer.MIN_VALUE)로 설정하면 1 row씩, 그 외의 값이면 모든 row를 한번에 FETCH 해옴
VALIDATION_QUERY
게이트웨이에서 타깃 데이터베이스로의 연결이 유효한지 확인하기 위한 SQL 문장을 지정
이 값이 설정되어 있다면 다음의 경우에 연결 확인 과정이 수행됨
Tibero 서버로부터 연결 확인 요청이 오는 경우
동일한 연결 내에서 마지막 수행 이후 VALIDATION_IDLE_TIME 설정에 지정된 시간동안 새로운 요청이 오지 않는 경우
VALIDATION_IDLE_TIME
마지막 요청 이후 연결 유효 확인을 수행할 때까지의 대기 시간을 설정
단위는 밀리초이며, 0은 무제한을 의미 (기본값: 0, 최소값: 60000)
VALIDATION_QUERY 항목이 설정되어 있는 경우에만 함께 적용됨
CONNECTION_PROPERTY
타깃 데이터베이스에 연결할 때 URL 쿼리 파라미터(Query Parameter) 형태로 연결 프로퍼티를 지정할 수 있음
형식은 일반적으로 대상 데이터베이스의 URL 규칙을 따름 예) ?key1=value1&key2=value2&...
JDBC - Tibero 타입 매칭표 (MS-SQL SERVER, Sybase ASE, GREENPLUM, MySQL)
Tibero는 JDBC 데이터 타입을 Tibero 데이터 타입으로 매핑합니다. Tibero 게이트웨이가 쿼리 실행 결과를 수신하면, 해당 결과의 JDBC 데이터 타입을 기준으로 Tibero 데이터 타입으로 변환합니다. 예를 들어 MySQL 의 TEXT 타입은 JDBC에서 LONGVARCHAR로 인식되므로 Tibero에서는 LONG 타입으로 매핑합니다.
만약 Tibero 게이트웨이에서 지원하지 않는 데이터 타입을 조회할 경우 오류(ERROR_GW_NOT_SUP PORTTED_DATA_TYPE)가 발생합니다.
BIT
NUMBER
-
TINYINT
NUMBER
-
SMALLINT
NUMBER
-
INTEGER
NUMBER
-
BIGINT
NUMBER
-
FLOAT
NUMBER
-
REAL
NUMBER
-
DOUBLE
NUMBER
-
NUMERIC
NUMBER
-
DECIMAL
NUMBER
-
DATE
DATE
-
TIME
TIME
-
TIMESTAMP
TIMESTAMP
-
CHAR
CHAR
N <= 65532
VARCHAR
VARCHAR2
N <= 65532
LONGVARCHAR
LONG
N <= MAX_LONGVARCHAR
BINARY
RAW
N <= MAX_LONGRAW
VARBINARY
RAW
N <= MAX_LONGRAW
LONGVARBINARY
LONGRAW
N <= MAX_LONGRAW
참고
허용 범위를 초과하는 데이터에 대해서는 잘림 (Truncation)이 발생할 수 있습니다.
게이트웨이 바이너리의 버전
게이트웨이 바이너리의 버전은 다음과 같은 명령을 실행하여 확인할 수 있습니다.
데이터베이스 링크 사용
데이터베이스 링크를 통해 접근할 수 있는 데이터베이스 객체의 종류는 다음과 같습니다.
테이블(LOB 타입의 컬럼에는 접근할 수 없습니다.)
뷰
시퀀스
프로시저
함수
패키지
데이터베이스 링크를 통해 Oracle의 LONG 타입 컬럼을 접근할 때 LONG 타입의 컬럼은 항상 마지막 컬 럼으로 설정하여 접근해야 합니다. 데이터베이스 링크를 사용할 수 있는 SQL 문장은 SELECT, INSERT, UPDATE, DELETE 입니다. 단, SELECT 문에서 FOR UPDATE 절은 사용할 수 없습니다.
참고
PSM 에서의 데이터베이스 링크 사용에 대한 자세한 내용은 "Tibero tbPSM 안내서"를 참고합니다.
Global Consistency
Homogeneous DB Link로 구성된 분산 트랜잭션은 Global Consistency를 제공합니다. 이를 위해 분산 트 랜잭션에 참여한 데이터베이스 간에 TSN을 동기화하는 작업을 합니다. TSN을 동기화하는 작업은 데이터 베이스 사이에 메시지를 교환할 때 이루어지며, 커밋할 때에는 모든 노드의 Commit TSN을 동일하게 동기화해야 합니다.
데이터베이스 링크 In-doubt 트랜잭션 처리
정체되고 있는 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가 수정한 내용에 접근하는 경우 다음과 같은 에러가 발생합니다.
데이터베이스 링크를 사용할 때 prepare 상태에서 정체가 발생하는 경우 해당 데이터에 접근할 수 없기 때문에 In-doubt 트랜잭션으로 인한 문제가 발생됩니다.
이와 같은 문제를 경감하기 위해 트랜잭션에 참여한 노드 중 한 노드는 prepare phase를 거치지 않고, 트 랜잭션이 in-doubt 상태가 되더라도 commit point site는 위와 같이 데이터를 접근하지 못하는 상황을 방지 할 수 있도록 하였다. 따라서 commit point strength는 데이터 접근성이 많이 필요한 데이터베이스일수록 큰 값을 설정해야 합니다.
데이터베이스 링크 정보 조회
Tibero에서는 생성한 데이터베이스 링크의 정보를 제공하기 위해 다음 표에 나열된 정적 뷰를 제공하고 있습니다.
DBA_DB_LINKS
Tibero 내의 모든 데이터베이스 링크의 정보를 보여주는 뷰
DBA만 사 용할 수 있는 뷰
ALL_DB_LINKS
현재 사용자가 이용할 수 있는 모든 데이터베이스 링크의 정보를 보여주는 뷰
USER_DB_LINKS
현재 사용자가 생성한 데이터베이스 링크의 정보를 보여주는 뷰
참고
정적 뷰에 대한 자세한 내용은 "Tibero 참조 안내서"를 참고합니다.
V$DBLINK
동적 뷰 V$DBLINK는 해당 세션에서 원격 데이터베이스에 연결된 데이터베이스 링크의 정보를 보여주는 뷰입니다.
사용자가 데이터베이스 링크를 통해 질의를 수행하면 원격 데이터베이스에 연결을 생성하고, 해당 질의 또는 트랜잭션이 종료되어도 연결을 해제하지 않고 계속 유지됩니다. 즉, 같은 데이터베이스 링크를 사용했 을 때 발생하는 연결의 비용을 줄이기 위함입니다. 이렇게 생성된 연결은 세션이 종료 또는 명시적으로 연결 을 종료할 때까지 계속 유지됩니다.
다음은 remote_tibero를 통해 SELECT 문을 수행한 후 V$DBLINK를 통해 연결 정보를 조회하는 예입니다.
현재 remote_tibero의 소유자의 ID는 15번이고, 현재 열려 있는 커서는 없으며 트랜잭션을 수행하고 있습니다. 동일한 Tibero 서버에 대한 데이터베이스 링크이며, 원격 데이터베이스의 commit point strength는 1입니다.
다음은 데이터베이스 링크 기능을 종료하는 예입니다.
① 데이터베이스 링크 기능을 종료하려는 시도가 실패한 이유는 해당 데이터베이스 링크를 사용한 트랜 잭션이 아직 수행 중이기 때문입니다.
② commit 문을 통해 해당 트랜잭션을 종료합니다.
③ 다시 데이터베이스 링크 기능의 종료를 시도합니다.
④ 정상적으로 데이터베이스 링크가 종료되며 이를 확인하는 방법은 V$DBLINK를 통해 확인할 수 있습니다.
Last updated