오라클 턱시도(Oracle Tuxedo) / 미들웨어 / OLTP / 턱시도 명령어 / 턱시도 사용방법
TUXEDO가 뭐야??
Transactions for UniX, Extended for Distributed Operations 의 약자이다. 분산 운영 환경에서 분산트랜잭션 처리용 미들웨어인데 대규모 트랜잭션 처리가 가능한 미들웨어이다. 클라이언트/서버 환경에서의 온라인시스템(OLTP: 온라인 트랜잭션 처리)을 원활하게 지원하여 주는 S/W, 다수의 사용자들이 자기가 요청한 작업들을 실시간내에 처리되어 응답받기를 원하는 시스템, 유닉스 중심의 분산환경에서 메인프레임상의 온라인 트랜잭션 관리 소프트 웨어인 CICS등과 같은 역할을 해주는 S/W, Tuxedo는 클라이언트와 서버 양쪽에 탑재되어 RDBMS의 Access 및 전송을 지원하여 주는 중간다리 역할을 하는 S/W이다.
턱시도 서버를 여러개 띄워놓는데 각 서버는 업무별로 서비스가 존재한다. 각 턱시도 서버들이 띄워져있다가 요청이 오면 각 서비스에 맞는 서버가 각 서비스를 수행하고 모니터한다고 보면 된다. 여기서 이 모니터라는 것은 서비스가 제대로 수행되는지 queue에 쌓이는지 얼마만큼 빠르게 처리되었는지 확인 가능하다.
턱시도는 TP-M(Transaction Processing Monitor) 미들웨어에 속하며, 트랜잭션 처리를 모니터링한다. TP모니터링의 목적은? 트랜잭션 처리가 완전하다는 것을 보장하고, 만약 에러가 발생하면 적절한 조치를 취하기 위한 것이다. 대형 전산시스템의 경우 하루 수천만건의 트랜잭션이 발생하게 되는데, TP monitor는 시스템의 부하를 조절하고 장애 발생을 방지해 안정적으로 시스템이 운영되도록 해준다.
턱시도 제품 사용환경 • 다수의 사용자 (100 이상 - 수십만, 수백만) • 전사적이며, Mission Critical 업무 • 대량의 분산 트랜잭션 처리 - 2단계 commit을 통한 데이타 무결성 보장 • LAN 및 WAN이 혼재된 분산 환경 • 이기종 하드웨어 및 이기종 DB 사용 환경 • 빠른 응답속도
오라클 턱시도는?
Oracle Tuxedo는 프라이빗 클라우드 또는 기존 데이터 센터 환경에서 C, C++, COBOL, Java 및 동적 언어 애플리케이션을 위한 최고의 애플리케이션 서버입니다. Oracle Tuxedo는 미션 크리티컬 애플리케이션을 개발, 배포 및 관리할 수 있는 매우 안정적이고 선형적으로 확장 가능한 플랫폼을 제공합니다. Oracle Tuxedo는 동일한 컨테이너에 공존하는 여러 프로그래밍 언어(C, C++, COBOL, Java, PHP, Python 및 Ruby)로 작성된 애플리케이션 간의 최적화된 통신을 제공합니다. Oracle Tuxedo에는 총 소유 비용을 낮추기 위한 애플리케이션 개발, 배포 및 관리를 위한 다양한 도구가 포함되어 있습니다.
턱시도 다운로드 사이트 : https://www.oracle.com/middleware/technologies/tuxedo.html
턱시도의 동작 원리
한 머신내에서 TUXEDO의 동작원리는 다음과 같으며, 하나의 WSH 프로세스는 여러 개의 Client들을 제어한다. (High Volumn : 10여개, Low Volumn : 30 ~ 50여개)
1) Client에서 TUXEDO와 접속을 요청하면 WSL와 접속 된다.
2) WSL는 WSH의 Address를 Return한다.
3) WSL는 WSH에 Connection 요청한다.
4) Client에서 서비스를 요청 하면 WSH와 접속. (이후 데이타는 WSH와 송수신)
5) WSH는 해당 서비스의 존재 위치 및 관련 정보를 Bulletin Board에서 찾는다.
6) 해당 서버의 어플리케이션에 서비스 요청한다.
7) 서버의 어플리케이션은 해당 서비스를 수행하고, 그 결과를 WSH로 Return.8) WSH는 Return된 결과를 Client로 보냄.
분산환경에서의 TUXEDO의 내부 동작원리를 프로세스 관점에서 살펴보면 다음과 같다.
- DBBLMaster 서버머신에만 존재하며, 주기적으로 모든 서버의 BBL 정보를 일치시키는 프로세스 로서 주기는 사용자가 정의 함
- BBL 로컬 머신의 어플리케이션들 (AP1 ~ APn)의 상태를 주기적 으로 점검하는 프로세스로서, 점검주기 는 사용자가 정의함.
- Bridge 머신간의 데이터 송수신 통로 역할을 수행하는 프로세스로서, 여러 개를 띄워 사용할 수 있음.
턱시도 환경 설정
대표적인 구성에 관련된 환경설정 파일
- ubbconfig : 턱시도 서버 및 서비스 구성을 위한 환경파일
- dmconfig : 웹로직과의 연결을 위한 GWTDOMAIN 구성 파일.
WTC(Weblogic Tuxedo Connection)와 연관이 있다.턱시도 명령어(Tuxedo Command)
| 명령어(약어) | 설명 |
| echo(e) | 입력된 명령을 화면에 보여준다 |
| help(h) | 도움말 (사용 가능한 명령과 그 설명)을 보여 준다. |
| verbose(v) | 시스템 정보를얻는 명령(pd,pt..)에 대한 상세한 정보를 보여준다. |
| paginate(page) | 출력의 페이징 기능을 토글 시킨다. |
| ! | 쉘 명령어를 수행한다. |
| !! | 직전에 수행한 쉘 명령을 반복하여 수행한다. |
| <CR> | 직전에 수행한 명령을 반복하여 수행한다. |
| default(d) | 기본 설정값을 재 설정하거나, 옵션이 없는 경우는 설정 값을 보여줌. default [-d local domain name] |
이 명령어 기준은 턱시도 설치하고 턱시도 PATH나 oracle path등이 다 잡혀있어야 한다.
- tmadmin
1. psr : 턱시도 서버를 보여주는 명령어
2. psc : 턱시도 서비스의 내역을 보여주는 명령어
3. bbc : 턱시도 Bulletin Board에 등록된 프로세스와 실제 프로세스간의 불일치 된 프로세스를 정리하는 명령어
4. bbs : Bulletin Board의 상태를 보여주는 명령어
5. pq : 턱시도 큐에 쌓여있는 서버를 보여주는 명령어
6. pclt : 턱시도에 접속되어 있는 클라이언트의 정보를 보여주는 명령어
7. susp : 턱시도의 그룹/서버/서비스의 사용을 못하도록 하는 명령어
8. res : 턱시도에서 suspend(susp) 된 그룹/서버/서비스를 사용하도록 하는 명령어
9. h(help) : tmadmin 도움말
10. q(quit) : tmadmin을 빠져나가는 명령어
- tmipcrm : 턱시도 자원을 회수한다.
tmipcrm -y
- tmloadcf / dmloadcf : 환경설정 파일을 컴파일
tmloadcf -y ubbconfig (ubbconfig파일을 컴파일함)
dmloadcf -y dmconfig (dmconfig파일을 컴파일함)
tmloadcf -n ubbconfig (ubbconfig파일의 문법이 정확한지 확인함. 실제로 컴파일은 안함)
dmloadcf -n dmconfig (dmconfig파일의 문법이 정확한지 확인함. 실제로 컴파일은 안함)
- tmunloadcf / dmunloadcf : 환경설정 컴파일 된 파일의 내용을 읽음
- txrpt : stderr파일을 참조하여 수행성능 실적을 생성한다.
# txrpt -d 11/20 -s 00:00 -e 24:00 < stderr > svclist.txt트랜잭션 처리 및 서비스 정보변경 관련 명령
| 명령어(약어) | 설명 |
| printtrans(pt) | 현재 수행 중인 트랜잭션의 상태를 글로벌 트랜잭션 테이블로부터 정보를 출력한다. >printtans(pt) -d local_domain_name 다음과 같은 형태로 트랜잭션 관련 정보가 출력된다. process ID:local domain name: remote domain name:service name:local GRTID:remote GTRID:record type:timestamp |
| gorgettrans(ft) | 로컬 도메인과 관련된 트랜잭션을 잊어 버림. > forgettrans(ft) -d local_domain_name [ -t tran_id] 트랜잭션 식별자인 tran_id는 printtrans 명령어 또는 ULOG 파일에서 얻을수 있다. |
턱시도 디바이스 관련 명령어
| 명령어(약어) | 설명 |
| dsdl | 전에 존재하지 않는 디바이스를 생성 >crdl -b blocks -z config -0 configoffset |
| initdl(indl) | 디바이스를 없앤다 > initdl (indl) [-yes] -z config [-o offset] dlindex |
| lidl | 디바이스 리스트의 항목을 보여준다 > lidl -z config [-o offset] [dlindex] |
| livtoc | 모든 VTOC(Volume Table of Contents) 테이블의 항목에 대한 정보를 보여준다 > livtoc -z config [ -o offset] |
턱시도 서버 시작 및 중지
- tmboot / tmshutdown (턱시도 기동 or 정지)
- 턱시도 서버 기동
# tmboot -s (턱시도서버명)
# tmboot -i (턱시도서버 i 값)
- 턱시도 서버 중지
# tmboot -s (턱시도서버명)
# tmboot -i (턱시도서버 i값)
- 턱시도 엔진까지 전부 정지
# tmshutdown -w1 -cy
w1 옵션은 1초 대기 후 종료를 의미한다. w1을 주지않으면 해당 커맨드 수행한 시간에 수행하던 서비스가 있다면 그 서비스 종료후 정지된다. FML함수
● Finit()
- 기능 : buffer을 초기화하기 위하여 사용한다.
- Syntax
Finit(FBFR *transf , int len);
① FBFR *transf : buffer의 포인터명
② int len : buffer의 길이
● Fchg()
- 기능 : 프로그램 변수의 값을 지정된 Buffer의 Field에 Move
- Tuxedo Buffer -> 프로그램 buffer
- Syntax
Fchg(FBFR *transf,FLEID fieldid,FLDOCC occ,char *buf,FLDLEN len);
① FBFR *transf : buffer의 포인터명
② FLDID fieldid : FML Buffer Header에 정의된 Field명
③ FLDOCC occ : field의 occurrence number 0부터시작
multi row data를 사용하는 경우 지정
④ char *buf : FML buffer에 move할 데이타 변수
buf의 pointer를 move해야 한다.
⑤ FLDLEN len : carray buffer를 사용하는 경우 buf 의 크기
carray buffer외에 사용하는 경우 0을 지정
- Return Type : int형
- 예)
strcpy(H_juminid,"780209-2574411");
Fchg(transf,JUMIN_ID,0,H_juminid,0);
● Fget()
- 기능 : 지정된 field의 내용을 프로그램 변수의 buffer에 move한다.
- 프로그램 buffer -> Tuxedo Buffer
- Syntax
Fget(FBFR *fbfr,FLEID,fieldid,FLDOCC oc,char *buf,FLDLEN *len);
① FBFR *transf : buffer의 포인터명
② Fldid fieldid : fml header table에 정의 field명
③ FLDOCC oc : field의 occurrence number 0부터시작
multi row data를 사용하는 경우 지정
④ char *buf : fieldid의 buffer를 프로그램 buffer에 move하기
위한 char pointer 변수
⑤ FLDLEN *len : 프로그램 buffer에 저장할 수 있는 최대크기
- Return Type : int형
- 예) Fget(transf,JUMIN_ID,0,H_juminid,&len);
● Foccur()
- 기능 : 지정된 field occurrence 조사
즉 지정한 field가 multi row이면 지정한 field의 갯수를 return
- Syntax
FLDOCC FLDcnt;
FLDcnt = Foccur(FBFR *fbfr, FLDID fieldid);
① FLDcnt : occurrence의 결과를 얻기위한 변수
② FBFR *fbfr : fml buffer의 data buffer의 포인터
③ FLDID fldided : fml buffer에 정의된 Field명
- Return Type : FLDOCC형
- 예) FLDcnt = Foccur(fbfr,JUMIN_ID);
● Fldid()
- 기능 : Field name에 대한 id값을 return.
- Syntax
FLDID fldvar
Fldvar = Fldid(char *name);
① FLDID fldvar : fml buffer에서 지정한 field의 id 얻기위한 변수.
② char *name : Field table에 정의된 field명
- Return Type : FIELDID 형
- 예) fldvar = FIELD("jumin_id");
● Fconcat()
- 기능 : Field buffer를 다른 field buffer에 추가.
- Syntax
Fconcat(FBFR *dest, FBFR *src);
① *dest, *src : src의 내용을 dest에 추가
dest의 크기가 src를 포함할 만큼 충분하지 않으면
error 발생
- Return type : int형
● Fvals()/Fvall()
- 기능 : Fget()과 동일한 기능(Error가 발생한 경우 return값이 없다)
- Syntax
Fvals(FBFR *fbfr,field,oc);
FvalL(FBFR *fbfr,field,oc);
① Fvals는 문자열에 대한 pointer field에 대한 buffer내용을 얻는다.
② Fvll는 숫자형에 대한 pointer field에 대한 buffer내용을 얻는다.
- Return type : Fvals : char형 pointer , Fvall : long 형
예) variable = Fvals(transf,JUMIN_ID,0);
pay = Fvall(transf,PAY_ID,0);
ATMI함수
● tpinit()
- 기능 : Client와 Tuxedo System/T Application과의 접속
- syntax
tpinit(TPINIT *tpinfo)
① TPINIT *tpinfo : TPINIT구조체형 포인터 변수 지정
Tuxedo에 접속한 Client의 정보를 등록한다.
TPINIT 구조체
struct tpinfo_t {
char usrname[MAXTIDENT+2]; /* client user name */
char cltname[MAXTIDENT+2]; /* application client name */
char passwd[MAXTIDENT+2]; /* application password */
char grpname[MAXTIDENT+2]; /* client group name */
long flags; /* initialization flags */
long datalen; /* length of app specific data */
long data; /* placeholder for app data */
};
typedef struct tpinfo_t TPINIT;
- Return Type : int 형
● tpterm()
- 기능 : Tuxedo System/T Application종료
Tuxedo에 접속한 Clinet의 정보 삭제
- Syntax : tpterm();
- Return Type : int 형
● tpalloc()
- 기능 : Data를 저장할 Buffer의 할당 및 초기화
- syntax
FBFR *transf;
pfbr = (FBFR *)tpalloc(char *type, char *subtype, long size)
① FBFR *transf : Client에서 전송된 부분중에서 data부분을 저장
하기 위한 pointer, 다수의 부분을 할당하는 경우
transf1, transf2,... 순차적으로 지정
② char *type : 할당받을 buffer의 type지정(FML buffer로 고정)
③ char *subtype : FML buffer사용시 NULL로 지정
④ longsize : 할당받을 Buffer의 크기지정
- Return Type : Character형 포인터
- 예) FBFR *transf;
transf = (FBFR *)tpalloc("FML",NULL,(long)(5*1024));
주의사항) 반드시 tpalloc은 tpfree를 꼭 해 주어서 할당된
Buffer를 풀어 주어야 한다.
● tprealloc()
- 기능 : tpalloc에의해서 할당된 메모리가 적을 경우 Buffer size를
크게 하기 위하여 사용.
- syntax
transf = (FBFR *)tprealloc((char *)transf,long size);
① FBFR * : realloc에 의해서 return받은 메모리를 FBFR *로 형변환
② (char *)transf : size를 크게 조정하는 buffer를 char포인터로 형변환
③ long size : buffer의 크기를 지정한다.
- tprealloc은 tpalloc과 달리 tpfree가 필요 없다.
- Return Type : Character형 포인터
- 예) transf = (FBFR *)tprealloc((char *)transf,(long)(7*1024));
● tpfree()
- 기능 : 사용이 완료된 Buffer해제
- syntax
tpfree((char *)transf);
① (char *)transf : 사용 완료된 버퍼의 Type을 Character형 포인터로
변환한후 메모리를 해제한다.
- 예) tpfree((char *)transf);
● tpcall()
- 기능 : 동기 방식으로 Service를 요구하고 응답이 올때까지 기다린다.
- syntax
tpcall(char *service, char *sendbuf, long sendlen,
char **rcvbuf, long *rcvlen,long flags);
① char *service : 요청할 서비스명을 지정한다.
② char *sendbuf : Service에 보내어질 data buffer의 pointer
③ long sendlen : 서비스에 보내어질 버퍼의 길이(보통 0으로 고정)
④ char **rcvbuf : 서비스에서 응답되어진 버퍼를 위한 pointer
⑤ long *rcvlen : return된 데이타 버퍼 길이의 포인터
⑥ long flags : 서비스 요청시의 option(보통 0으로 지정)
- Return Type : int형
- 예)
tpcall("SVC_1",(char *)transf,0,(char **)&transf,&rcvlen,0);
● tpacall()
- 기능 : 비동기 방식으로 service를 호출한다, 서비스만 요청한후
결과가 필요한 경우 tpgetrply()이용하여 응답을 받는다.
- syntax
handle = tpacall(char *service,char *sendbuf,long length,long flags);
① handle : tpacall()의 값을 return받기위한 Descriptor
handle수 많다면 handle1,handle2,..를 위한 순차적처리.
② char *service : 요청할 서비스명
③ char *sendbuf : 서비스에 전송하는 데이타 버퍼의 포인터
④ long length : 서비스에 보내어지는 데이타 버퍼의 길이(0)
⑤ long flag : 서비스 요청시 사용하는 option(0)
- Return Type : int형
- 예) handle1 = tpacall("SVC_1",(char *)transf,0,0);
● tpgetrply()
- 기능 : tpacall로 요청한 서비스의 응답을 받기 위하여 사용
- syntax
tpgetrply(int *handle1, char **buf, long *length, long flags);
① handle1 : tpacall()시 받은 service에 대한 handle
② buf : 응답시 받을 Buffer의 포인터
③ length : 응답시 받을 Buffer의 길이
④ flag : tpgetrply()시 주는 option
주의 사항) 동시에 여러 서비스에 대해 tpacall을 사용했을 경우에는
tpgetrply의 flag 부분에 TPGETANY로 설정하여 사용한다.
● tpcancel()
- 기능 : tpacall함수의 응답출력을 취소
- syntax
tpcancel(int handle);
- return type : int 형
- 예) tpcancel(handle1);
● tpbegin()
- 기능 : Transfaction을 시작한다.
- Syntax
tpbegin(unsigned long timeout, long flags);
① timeout : Transfaction timeout(초)지정, 0지정시 무제한
주의사항) 반드시 timeout을 지정해 주어야 합니다. (권장시간 30초)
② flag : 반드시 0으로 setting
- Return Type : int형
- 예) tpbegin(30,0);
● tpcommit()
- 기능 : Transaction을 완료한다.
- Syntax
tpcommit (long flags);
① flags : 반드시 0으로 setting
- Return Type : int형
- 예) tpcommit(0); 턱시도(TUXEDO) 용어
BB(Bulletin Board)
Tuxedo 의 제반정보가 등록되는 공유메모리 구조체.
BBL(Bulletin Board Liaison process)
Shared Memory를 관리 해 주는 프로세스(BB 를 관리해주는 Process)
DBBL(Distinguished Bulletin Board Liaison process)
네트워크 환경에서 Master Site에 떠서 BBL들의 상태를 감시 관리하는 프로세스
Bridge Process
다른 System 과 정보 및 메세지를 교환하는 Process.
AP Server
어플리케이션 서버
ATMI (Application Transaction Manager Process)
클라이언트와 서버를 지원하기 위한 /T에서 제공하는 함수들
RM (Resource Manager)
데이터베이스, 프린터 서버 등의 자원을 관리하는 부분
System /T 턱시도 시스템 OLTP Component
턱시도 시스템의 핵심 요소이며, 트랜잭션을 관리해 줌
TM (Transaction Manager)
트랜잭션 관리자 (시스템 /T)
XA (X/Open defined TM ↔ RM Interface)
X/Open에서 정의한 표준화 된 인터페이스로 이기종 데이터베이스를 투과적으로 다룰 수 있으며, 2단계 갱신 (2 Parse Commit)으로 무결성이 보장 됨
TMS (Transaction Manager Server)
이기종 데이터베이스를 지원하는 XA interface를 사용 할 경우 필요함
FML (Field Manipulation Language)
Field Buffer라는 데이터 구조를 정의하고 처리할 수 있는 C 언어 함수이며 named field를 사용하여 클라이언트와 서버 사이의 커뮤니케이션을 제공
MSSQ (Multiple Server, Single Queue)
같은 서비스를 제공하는 다수의 서버에 한 개의 큐를 공유하도록 하여 특정한 서버 만 작업량이 많아지는 것을 방지한다.named field를 사용하여 클라이언트와 서버 사이의 커뮤니케이션을 제공한다.
WSC (Workstation Client)
서비스를 요청한 클라이언트
WSL (Workstation Listener)
서비스 요청을 받아 WSH로 연결시켜 주는 데몬 프로세스
WSH (Workstation Header)
서비스 요청한 buffer data를 서버로 연결시키고 정보를 주고받음
턱시도(TUXEDO Security) 보안
TUXEDO SYSTEM은 전체 4단계의 Security를 제공한다.
1단계 : 시스템제공의 UID , GID 와 Password
2단계 : Application 접근에 대한 authentication
3단계 : user의 authorization level에 대한 security
4단계 : 1992년 이후 제공되는 Kerberos machanism security
턱시도 마이그레이션(TUXEDO Magration)
1. Migration DBBL
master machine에 장애가 발생하였을 경우 tmboot, tmshutdown등의 관리
명령어를 사용할 수 없으므로 DBBL을 backup master로 이동하여 이를 수행
할 수 있도록 한다.
1) 처리순서
$ tmadmin
> m
2) 세부사항
① RESOURCES의 MASTER에 backup machine이 선언되어 있어야 한다.
② OPTIONS에 MIGRATE를 선언
③ 위의 명령은 backup machine에서 실행시킨다.
2. Migration Servers
특정 Group내에 있는 Server들을 migrate
1) 처리 순서
$ tmadmin
> stop -R -g groupname
> migg groupname
2) 세부사항
① migrate될 server들을 shutdown시킬 때는 반드시 “-R” option을
사용한다.
② migrate될 server들은 LMID변수에 옮겨갈 machine을 미리 선언해
놓는다.
③ group내의 server들은 RESTART=Y로 설정되어 있어야 한다.
3. Migrating Machines
LMID를 이용하여 그 machine내의 server들을 migrate시킨다.
1) 처리 순서
$ tmadmin
> stop -R -l lmid
> migm machine
2) 세부사항
① 이 역시 마찬가지로 shutdown시에 “-R” option을 사용
② migm은 argument로 하나의 LMID를 갖는데 이 LMID는 migrate하려는
server들이 수행되던 machine의 이름이다.
③ 이 LMID를 갖는 machine내의 모든 server는 RESTART=Y로 선언되어
있어야 한다.
< 참고>
– “stop -R” 명령을 수행시킨 후에 migration을 취소할 수도 있는데,
이는 “-cancel” option을 사용하면 된다.
> migg -cancel groupname
> migm -cancel lmid
– “-cancel” option을 “-R” option없이 shutdown한 것과 똑같은 효과를 지닌다.
턱시도 동시사용자(TUXEDO Concurrent User)
1. Tuxedo의 Concurrent User 개념은 Tuxedo Client에서 Server 상의 Service를
호출하여 Service Program이 기동(Tpinit)에서부터 완료(Tpreturn)까지의
기간동안 Server상에서 수행되는 동시 Service Program의 수치를 말함.
2. 일반적으로 H/W의 초당처리속도(TPC)는 Tuxedo의 Concurrent User수에 비해
훨씬 높은 처리속도를 가지며, 순수하게 TP 환경에서 H/W의 최대
Performance를 내기 위해서는 Tuxedo의 Concurrent User수를 H/W의 TPC
수치와 동일하게 설정 해야만 한다.
3. Tuxedo 6.2 Version 이후 부터는 각각의 Server별로 Concurrent User수를
보유하고 있어야만 서버별로 동일한 성능을 기대할 수 있게 된다.
4. 개발용 모듈(SDK)와 RunTime 모듈(RDK)는 동일한 서버상에 동시에 Porting이
가능.
5. 어떤 금융업무의 Concurrent User 산정
① 시스템이 월간 1,800 만건의 Transaction이 발생한다고 가정.
② 월간 1,800만건을 25일 근무/8시간 운영으로 가정하고 초당 평균
Transaction 발생 수치를 계산했을 때 약 40 Transaction이 산정됨
③ 초당 40 Transaction은 Tuxedo 상에서 1초에 40 service Program이 기동 및
수행완료가 되어야 하는 경우임.
④ Tuxedo 상에서 Service Program이 2초내에 처리가 완료되도록 Target Time을
설정한다면 각각의 Transaction이 Waiting Time 없이 바로 처리 되기
위해서는 Tuxedo Concurrent User수는 80이 되어야 함.
(Transaction당 Target Time이 3초이면 Tuxedo Concurrent User수는 120이
되어야 함)
⑤ Network Server 2대로 운영하며 한 서버를 StandBy 상태로 가져갈 때는
Tuxedo User수를 다른 서버의 100% 수준으로 가지 않을수도 있음.
TP-Monitor정의
① 클라이언트/서버 환경에서의 온라인 시스템(OLTP)을 원활하게 지원하여 주는
Software.
※온라인 시스템(OLTP)
한 시스템에 접속된 다수의 사용자들은 일정한 작업에 대한 요청들을
동시에 요구하고 각 사용자들은 자기가 요청한 작업들을 실시간내에
처리되어 응답받기를 원하는 시스템.
② 유닉스 중심의 분산환경에서 Mainframe상의 온라인 트랜잭션 관리 S/W인
CICS등과 같은 역할을 하여 주는 Software.
③ TP-Monitor는 클라이언트와 서버 양쪽에 탑재되어 RDBMS의 Access 및 전송을
지원하여 주는 중간다리 역할을 하여 줌.
TP-Monitor장점
①처리 시간 보장 : Peak-Time시나 대용량 트랜잭션 발생시 안정적이고, 빠른
처리능력을 보장함.
②개발의 생산성 : Program 작성상의 용이성 및 확장성을 보장함.
③장애극복및 복구 : 장애 발생시 사용자가 계속해서 서비스를 받을 수 있게
하는 장애관리 및 복구 기능을 지원함.
④데이타 무결성 : 분산된 DBMS, Network, System등의 처리과정 중 전체에 대한
데이터 및 트랜잭션 무결성을 보장하여, 시스템 신뢰도
확보함. (2 Phase Commit)
⑤부하 분산 : 특정 시스템으로만 부하가 편중 되는 것을 막아 시스템 전체
성능을 최적화 함.
⑥자원의 중앙관리 : C/S 환경에서 가장 어려운 부분인 자원 관리를 중앙에서
일괄적으로 관리함.
⑦표준기술 지원 : 개방성 및 표준을 지원하여 향후 시스템 및 자원의 확장시
용이함.
TP-Monitor기능
①RPC(Remote Procedure Call) 기능
-다른 머신상에 있는 Procedure(프로그램)를 불러내는 기능으로
프로그래머는 통신을 의식하지 않고 보통의 Sub_Routine을 불러내는 식으로
코딩이 가능함
-RPC는 2단계 갱신(2 Phase-Commit)에도 대응하고 있어 분산환경에서의
데이터나 트랜잭션의 무결성을 보장한다. 즉 트랜잭션 처리중에 어떤 장애가
발생하면 DB에 대한 갱신을 모두 Rollback 할 수 있다
-현재 X/Open은 RPC에 대해 세가지 사양의 표준화를 추진하고 있으며 TUXEDO
기반의 XATMI와 TxRPC, 그리고 동배간 통신의 표준이다
②Multi-Thread 기능
-유닉스 프로세스로 여러 Application을 실행할 수 있으며, TP_Monitor
내부의 오버헤드를 줄일 수 있으므로 트랜잭션 처리를 고속화할 수 있다
③Directory 관리 기능
-Directory 서비스는 프로그램등 시스템 자원의 소재지 관리 기능
-클라이언트가 RPC로 서버 프로그램을 불러낼 때 네트웍 어드레스를 의식하지
않고 프로그램명(서비스명)만 지정하면 되는 방식이다.
④Data 의존형 Routing 기능
-Request의 데이터 내용을 보고 수신처의 서버를 판단하는 기능
-예를 들면 동일한 특성의 데이타를 여러 서버로 분산한 경우 고객의
우편번호를 보고 처리할 서버로 배분할 수 있는 기능이다
⑤여러 서버 사이의 Load Balancing
-분산처리 환경에서 여러 서버 사이의 Request를 배분하는 기능
-균등하게 배분하는 라운드로빙방식, 서버의 처리능력에 따라 일정비율로
배분하는 방식, 서버의 부하상황을 보고 동적으로 배분하는 방식등이 있다.
⑥클라이언트 프로그램 관리
-서버나 클라이언트를 추가할때에는 반드시 시스템 구성(Configuration)
File을 변경해야 한다
이때 시스템을 정지시키지 않고 온라인으로 변경할 수 있는 기능
-분산처리 환경에서는 클라이언트측 Application Program의 Version 관리
기능이 중요하다
즉, 새로운 버젼의 프로그램을 미리 클라이언트에 전송해 두고 어떤
시점에서 일제히 변경할 수 있는 기능
⑦시스템 리포트 기능
-장애 발생시 트랜잭션 로그나 에러 로그의 분석을 위해서 이들 로그를
편집해서 출력하는 기능
TP_Monitor의 구성
TP_Monitor 각 제품들은 UNIX용 Application 환경 표준화 단체인 X/Open이 정한 DTP
(분산 트랜잭션 처리) 모델에 준거하고 있으며, 여기에는 OLTP 시스템에 필요한
구성요소를 정의하고 각 구성요소간의 인터페이스를 규정하고 있다
▶Transaction Manager : 트랜잭션라우팅, 전역 트랜잭션 관리, 오류회복등의 관리기능
▶Resource Manager : DBMS 또는 프린터서버등과 같은 공유자원 관리기능
▶Communication Resource Manager : 클라이언트/서버사이 및 서버간의 통신전반을
제어하는 기능
▶XA : XA를 채택한 TP_Monitor는 XA에 대응한 모든 RDBMS와 자유롭게 연결 가능함
▶RPC(Remote Procedure Call) : 다른 머신상에 있는 Procedure를 불러내는 기능
(TxRPC, XATMI,동배간통신등의 3종류의 표준이 있음)
OLTP vs. OLAP
OLTP(온라인 트랜잭션 처리)는 온라인 뱅킹, 쇼핑, 주문 입력 또는 텍스트 메시지 전송 등 동시에 발생하는 다수의 트랜잭션을 실행하는 데이터 처리 유형입니다. 이러한 트랜잭션은 전통적으로 경제 또는 재무 트랜잭션이라고 칭하며, 기업이 회계 또는 보고 목적으로 언제든 정보에 액세스할 수 있도록 기록 및 보호된다.
| OLTP 시스템 | OLAP 시스템 |
| 다수의 사용자에 의한 대량의 데이터베이스 트랜잭션을 실시간으로 실행할 수 있도록 지원 | 일반적으로 분석을 목적으로 데이터베이스 내 다수의 레코드(또는 모든 레코드)에 대한 질의 작업 포함 |
| 빛의 속도에 가까운 빠른 응답시간 필요 | OLTP에 대비 엄청나게 느린 응답시간 필요 |
| 적은 양의 데이터를 자주 수정하고, 일반적으로 읽기 및 쓰기 작업 간 균형이 유지됨 | 데이터를 전혀 수정하지 않음. 일반적으로 읽기 집약적인 작업 |
| 인덱스화된 데이터를 사용해 응답 시간 개선 | 대량의 레코드에 손쉽게 액세스할 수 있도록 컬럼 형식으로 데이터 저장 |
| 데이터베이스에 대한 빈번한 또는 동시 백업 필요 | 훨씬 적은 빈도의 데이터베이스 백업 필요 |
| 상대적으로 적은 스토리지 공간 필요 | 대량의 기록 데이터를 저장하기 때문에 일반적으로 상당한 양의 스토리지 공간 필요 |
| 일반적으로 하나 또는 몇 개의 레코드를 포함하는 단순한 쿼리 실행 | 다수의 레코드를 포함하는 복잡한 쿼리 실행 |
종합하자면, OLTP가 온라인 데이터 수정 시스템이라면 OLAP는 분석을 목적으로 대량의 데이터를 검색하는 데 사용되는 다차원 온라인 기록 데이터 저장소 시스템입니다. OLAP는 일반적으로 하나 이상의 OLTP 시스템에서 수집한 데이터에 대한 분석을 제공합니다.
미들웨어 개념 및 종류
미들웨어란
미들웨어는 클라이언트 프로그램과 서버 프로그램 사이에 존재하면서 클라이언트와 서버간에 연결을 유지/관리하면서, 클라이언트의 작업 처리 요구를 서버에 전달하는 일을 하는 소프트웨어이다.
“Middle(중간)과 Ware(소프트웨어)”의 합성어이다.
미들웨어의 기능
1)기본기능
①클라이언트와 서버간에 통신이 가능하도록 데이타 통로를 제공하는 기능.
②클라이언트와 서버간에 연결 세션을 유지/관리하는 기능.
③클라이언트의 작업 처리에 필요한 서비스를 찾아주는 기능.
2)확장기능
①여러 서버에 흩어진 프로그램에 클라이언트 요청을 라우팅하는 기능.
②서버 프로그램이 작어중이면 클라이언트 요청을 기다리게 하는 기능.
③서버 프로그램을 감시하는 기능.
④데이타베이스 트랜잭션을 관리하고, 데이타베이스와 공조하는 기능.
미들웨어의 종류
(1) 데이터베이스 미들웨어
: 데이터 베이스 벤더에서 제공하는 소프트웨어로서 클라이언트에서 원격의 데이터 베이스와 연결하기 위한 미들웨어이다. 실제 광범위한 의미에서 미들웨어라고 하지만, 단순히 원격에 있는 데이터베이스를 접근할 수 있도록 중계해주는 제품이라고 할 수 있고, 이 제품을 사용하여 시스템을 구축하는 경우에 보통 2-티어 아키텍쳐라고 한다.
[예] 오라클의 Sql*Net, IBM 인포믹스의 I*Net, ODBC 드라이버 등
(2) RPC(Remote Procedure Call) 미들웨어
: 원격 프로시져를 마치 로컬 프로시져처럼 호출하는 방식의 미들웨어이다.
[예] DCE RPC, 엔테라(RPC 기반에서 발전된 형태임) 등
[참고] 가트너 자료에 의하면, 시장에서 점유율이 거의 없는 미들웨어 임. 엔테라 제품은 외국에서는 End-Of-Life 되었고, 국내 공급회사에서 소스 판권을 사서 새로운 운영체제에 포팅만 하는 상태이다.(기능 보강은 거의 되고 있지 않음)
(3) MOM(Message Oriented Middleware) 미들웨어
: 주로 비동기형 메시지 처리를 전달하는 방식의 미들웨어이다. 온라인 업무에 사용되기 보다는 이 기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용되고 있다.
[예] IBM MQ시리즈, BEA Message Q, J2EE의 JMS 기반 제품 등
[참고] 현재 IBM MQ 제품이 시장 점유율에서 가장 높고, 향후 시장에서는 J2EE의 JMS 기반의 제품 들과 경쟁관계가 될 것 같다.
(4) TP-모니터 미들웨어
: 온-라인 트랜잭션 업무(은행 계정, 항공기/버스 예약 업무 등)에서 트랜잭션을 처리, 감시하는 미들웨어이다. 사용자 수가 증가하여도 빠른 응답 속도를 유지해야 하는 OLTP 성의 업무에 적합하다.
[예] BEA TUXEDO, BEA TOPEND, IBM TxSeries, 대만 CS Talk 등
[참고] 현재 BEA Tuxedo가 전세계 시장 점유율이 가장 높고, 향후에는 TP 기능을 가지고 있는 J2EE 기반의 WAS 제품들과 경쟁관계가 예상 됨
(5) ORB(Object Request Broker) 미들웨어
: 객체 지향 미들웨어. 코바(CORBA) 표준 스펙을 구현한 미들웨어이다. 최근에는 TP-모니터가 가지고 있는 장점(트랜잭션 처리, 모니터링 등)을 추가로 구현하고 있다.
[예] IONA Orbix, Borland VisiBroker, BEA TUXEDO 8.0 이상 CORBA 엔진 등
[참고] 현재 IONA Orbix제품의 시장 점유율이 가장 높음. 객체 지향 미들웨어로서 J2EE기반의 WAS 제품에 경쟁에서 밀리고 있고, WAS 미들웨어에서 CORBA를 지원함으로써 점유율이 낮아지고 있는 상태이다
(6) WAS(Web Application Server) 미들웨어
: 클라이언트/서버 환경 보다는 웹 환경을 구현하기 위한 미들웨어이다. Web Application Server는 HTTP 세션 처리를 위한 웹서버 기능 뿐만 아니라, TP 기능을 보강하여, 미션-크리티컬한 기업 업무까지 자바, EJB 컴포넌트 기반으로 구현 가능하게 해주는 미들웨어이다.
[예] BEA WebLogic, IBM WebSphere, Oracle 9iAS, SUN iPlanet 등
[참고] 미들웨어에서 가장 각광받고 있는 제품들이고, 향후 지속적인 성장이 예상되고 있고, 기존에 기업의 소규모 업무에서 향후에는 대규모, 미션 크리티컬한 업무 까지도 적용되고 있는 추세이다.
턱시도(TUXEDO)의 기능
- 부하 분산
-특정 시스템으로만 부하가 편중 되는 것을 막아 시스템 전체 성능을
최적화 함. - 처리 시간 보장
-Peak-Time시나 대용량 트랜잭션 발생시 안정적이고, 빠른 처리능력을
보장함. - 데이타 의존형 라우팅
-서비스 이름과 입력된 데이터 값에 따라 해당 Machine의 DataBase를
액세스함. - 분산자원의 중앙관리
-C/S 환경에서 가장 어려운 부분인 자원 관리를 중앙에서 일괄적으로
관리함.
-GUI(Motif) Administration Tool 제공함. - 개발의 생산성
-Program 작성상의 용이성 및 확장성을 보장함. - 표준기술 지원
-지원 H/W Platform의 종류, 개방성 및 표준을 지원하여 향후 시스템 및
자원의 확장시 용이함. - 장애극복 및 복구
-장애 발생시 사용자가 계속해서 서비스를 받을 수 있게 하는 장애관리 및
복구 기능을 지원함. - 데이타 무결성
-분산된 DBMS, Network, System, OS등의 처리과정 중 전체에 대한 데이터
및 트랜잭션 무결성을 보장하여, 시스템 신뢰도 확보함.(2 Phase Commit)
RPC (Remote Procedure Call) 기능
다른 머신상에 있는 Procedure(프로그램)를 불러내는 기능으로, 프로그래머는 통신을 의식하지 않고 보통의 Sub_Routine을 불러내는 식으로 코딩이 가능함.
Multi-Thread 기능
유닉스 프로세스로 여러 Application을 실행할 수 있으며, TP_Monitor 내부의 오버헤드를 줄일 수 있으므로 트랜잭션 처리를 고속화할 수 있다.
Directory 관리 기능.
Directory 서비스는 프로그램등 시스템 자원의 소재지 관리 기능.
Data 의존형 Routing 기능
Request의 데이터 내용을 보고 수신처의 서버를 판단하는 기능.
여러서버 사이의 Load-Balancing
분산처리 환경에서 여러 서버 사이의 Request를 배분하는 기능.
클라이언트 프로그램 관리
서버나 클라이언트를 프로그램 추가할때에는 반드시 시스템 구성Configuration) File을 변경해야 한다. 이때, 시스템을 정지시키지 않고 온라인으로 변경할 수 있는 기능.
시스템 리포팅 기능
장애 발생시 트랜잭션 로그나 에러 로그의 분석을 위해서 이들 로그를 편집해서 출력하는 기능.