티베로

티베로(Tibero)는 한국의 ㈜티맥스소프트의 자회사인 ㈜티맥스데이터가 운영하는 관계형 데이터베이스 관리 시스템(RDBMS)이다. 미국 오라클사가 만든 오라클(Oracle)의 대체품으로 제작하였기 때문에 오라클과 유사하며, 대부분의 쿼리(query)가 호환된다. 기존 오라클 DB를 티베로 DB로 마이그레이션하기 편리하게 제작되어 있다. 티베로(Tibero)의 성능은 오라클(Oracle)과 거의 비슷하지만 가격은 절반 정도에 불과하다는 특징이 있다.

개요

현재 기업의 비즈니스는 폭발적인 데이터의 증가와 다양한 환경 및 플랫폼의 등장으로 빠르게 확장되고 있다. 새로운 비즈니스 환경이 도래함에 따라 보다 더 효율적이고 유연한 데이터 서비스와 정보의 처리, 데이터 관리 기능이 필요하게 되었다. 티베로(Tibero)는 이러한 변화에 맞춰 기업 비즈니스 구현의 기반이 되는 데이터베이스 인프라 구성을 지원하며 고성능, 고가용성 및 확장성의 문제를 해결하는 엔터프라이즈 데이터베이스 관리 시스템(DBMS) 이다. 기존 데이터베이스의 단점을 보완하기 위해 티베로는 독자적인 티베로 스레드 구조(Tibero Thread Architecture)를 채택하고 구현하였다. 한정된 서버 프로세스의 CPU 및 메모리 등의 시스템 리소스를 효율적으로 사용하면서 뛰어난 성능과 안정성 및 확장성을 보장하고 편리한 개발 환경과 관리 기능을 제공한다. 티베로는 초기 설계부터 대규모 사용자, 대용량 데이터, 강화된 안정성, 향상된 호환성 측면 등에서 다른 데이터베이스 관리 시스템과 차별화를 고려하여 개발되었다. 티베로는 이처럼 기업이 원하는 최적의 데이터베이스 환경을 제공하는 대표적인 데이터베이스다. 티베로5는 데이터베이스 간 동기화 성능을 개선하여 다중 노드에서도 안정적인 데이터베이스 서비스 운영을 가능하게 한다. 또, 오라클과 동일한 공유 데이터베이스 클러스터링 기술인 티베로 액티브 클러스터(TAC)를 강화하는 블럭 트랜스퍼(Block Transfer) 기술이 적용되었고 자가튜닝(Self Tuning)을 통한 성능 최적화, 지속적인 데이터베이스 모니터링, 성능 관리 지원 등을 제공한다. 많은 플랫폼에 지원됨에 따라 국내 업체들의 사용 빈도가 잦아지고 있다.

등장배경

100년이 채 되지 않는 컴퓨터 역사에서, '데이터'라는 단어는 대표되는 아이티기술과 이로 파생되는 다양한 디지털 사회 발전에는 바로 관계형 데이터베이스 관리 시스템(RDBMS)이 함께 해왔다고 해도 과언은 아닐 것이다. 관계형 데이터베이스 관리 시스템의 기초를 이루는 이론은 1970년 아이비엠(IBM)의 애드거 커드라는 사람에 의해 세상에 처음으로 소개되었다. 그리고 에스큐엘(SQL)은 1973년 처음 SQU(Structured Queries As Relational Expressions)라는 언어로 발표되었고, 1979년에 이르러 오라클이 아이비엠보다 먼저 에스큐엘을 활용한 최초의 상용 관계형 데이터베이스 관리 시스템을 출시한 이후, 데이터베이스 시장은 현재까지 세계 최대 규모의 소프트웨어 로 고성장을 이어가고 있다. 티베로는 지난 2003년 회사명과 같은 명칭의 데이터베이스 관리 시스템(DBMS) 솔루션인 티베로를 출시해 엔터프라이즈급 대용량 데이터베이스 관리 시스템 제품의 국산 상용화에 성공했다. 이후 2008년에는 국내 최초이자 세계에서 두 번째로 공유 데이터베이스 클러스터 기술인 티베로 액티브 클러스터(TAC'를 개발해 글로벌 기업들의 DBMS 제품을 대체할 수 있는 안정성과 성능을 갖췄다는 평가를 듣기도 했다. 이를 토대로 티베로는 2009~2013년에 보험개발원 계정계 시스템, 신한은행 내규관리 시스템, 교육과학기술연수원 통합교육 연수지원시스템, 국방군수 소요획득정보체계(DRIS) 구축사업, 케이티 올레TV 시스템 등 금융, 공공, 통신 등 주요 고객사의 핵심 시스템에 데이터베이스 관리 시스템 솔루션을 공급하는 성과를 거뒀다. 이외에도 다양한 산업 분야에 100여 개의 신규 고객사를 확보하는 성장세를 보여주고 있다. 또한 2011년 10월에는 대형 시스템에서 운영되는 기업의 핵심업무에 적합하게 설계된 데이터베이스 관리 시스템 신제품 티베로 5를 시장에 선보이며, 그동안 주로 단위업무 시스템에서 적용됐던 것을 점차 기업의 핵심업무 및 대형 시스템으로도 확산시키고 있다. 2015년 4월에는 티베로 6을 시장에 선보였다.

특징

티베로는 각각의 클라이언트 요청을 기존에 생성되어 있는 스레드(thread)로 연결하는 멀티 스레드, 멀티 프로세스 구조를 채택하여 사용자가 늘어나도 시스템 오버헤드가 적고, 비용기반 최적화에 기반한 질의 처리의 성능 최적화 구현 및 사용자 개입 없이 질의를 최적화하는 역동적인 샘플링 지원을 한다. 다중버전 동시성 제어기법을 통한 다중사용자접속의 동시 처리의 성능을 향상하여, 쓰기 작업이 읽기 작업을 차단하거나 읽기 작업이 쓰기 작업을 차단하는 상황이 발생하지 않는 멀티 스레드, 멀티 프로세스 기반의 고성능 구조를 가지고 있다. 그리고 시스템 장애나 오류 등에 의해 데이터베이스에 물리적인 데이터 손상이 발생할 경우를 대비하기 위해서 다양한 백업 방법이 제공되며, 장애 발생 시점이나 특정 시점 까지 데이터베이스를 복원함으로써 정상적인 데이터베이스 운영을 가능하게 하는 복구 기능을 지원하여 안정성을 향상시킨다. 마지막으로 데이터베이스 관리 시스템 관리와 개발이 가능한 티비어드민(tbadmin)을 제공하여 관리와 개발이 용이하고, 마이그레이션 유틸리티인 티비마이그레이터(tbmigrator)를 제공하여 GUI 상에서 소스 데이터베이스와 타깃 데이터베이스를 편리하게 지정하게 해주며, 지정된 소스 데이터베이스 전체 또는 일부를 티베로 관계형 데이터베이스 관리 시스템의 데이터베이스로 효율적으로 이동시켜서 마이그레이션이 용이하다. 일반 텍스트 파일로부터 데이터베이스 테이블로 적재하는 티비로더(tbloader), 데이터베이스에 저장된 스키마 객체 및 데이터의 전체 또는 일부를 추출(Export)하는 티비액스퍼(tbexpor), 추출된 파일로부터 스키마 객체 및 데이터를 데이터베이스에 적재(import)하는 티비임폴트(tbimport)를 제공도 하여 마이그레이션 및 운영 편의성 증진도 한다.

티베로 서버는 유연한 구성을 가지는 다중 프로세스, 다중 스레드 기반의 아키텍처를 가지고서 대규모 사용자 접속을 수용한다. 디스크에 저장된 데이터는 티베로 공유 메모리로 전송되어 티베로 서버 스레드에게 제공되며, 트랜잭션 처리를 위하여 다양한 백그라운드 스레드들이 협조하여 데이터베이스의 가장 중요한 특징인 ACID(Atomic Consistent Isolated Durable) 처리를 보장해 준다. 기업용 시스템은 막대한 용량의 데이터를 모두 데이터베이스에 저장하게 되는데, 이 경우 쿼리 성능이 수용할 수 없는 수준으로 느려지는 악영향이 발생하게 된다.이를 해결하기 위한 손쉬운 접근 방법은 파티션 테이블을 활용하는 것이다. 파티션 테이블을 활용할 경우 특정 파티션에 국한된 데이터를 처리할 때는 해당 파티션이 저장된 영역만을 스캔하게 되므로, 안정적인 성능을 제공할 수 있다. 이러한 특징들은 대부분의 대용량 데이터베이스 관리 시스템 제품들이 보여주는 특징이며, 보다 상세한 부분에서는 각 제품별 특징이 조금씩 달라진다.

세계 최다 데이터베이스 전환 경험

관계형 데이터베이스 관리 시스템 시장은 특정 제품이 시장의 반 이상을 차지할 정도로 쏠림 현상이 큰 편이다. 이러한 시장 상황에서 고객의 선택의 폭은 상당히 적을 수밖에 없다. 티베로는 타 벤더 제품과의 높은 호환성을 바탕으로 기존 데이터를 쉽게 이관하고 애플리케이션 수정을 최소화하고 있다. 티베로는 기존 데이터베이스 관리 시스템과의 호환성을 검증하고, 이관하고, 기존 업무 환경을 그대로 테스트 할 수 있도록 돕는 툴을 지원하고 있다. 또한 다양한 전환 경험을 통해 경쟁사 대비 이러한 리스크가 굉장히 적하고 할 수 있다.

데이터베이스 클러스터 기술

티베로를 선택하는 가장 큰 요인 중의 하나가 바로 공유 디스크 기반의 데이터베이스 클러스터 기술이다.TAC(Tibero Active Cluster) 기술은 세계에서 2번째로 상용화된 기술이며 다양한 레퍼런스를 통해 검증된 바 있다. 타제품에도 가용성을 높이기 위한 기술이 있지만, 현재 TAC가 제공하는 공유 디스크 방식처럼 신뢰도 높은 기술은 없다.

낮은 총소요 비용

비용만 생각한다면 얼마든지 다른 데이터베이스를 선택할 수 있을 것이다. 하지만 데이터베이스를 바꾸는 것은 비용 절감보다 훨씬 더 복잡한 문제이다. 그렇게 때문에 앞서 언급한 티베로의 기술적인 장점들과 비용적인 장점의 결합은 큰 매력으로 작용할 수밖에 없다.

기술서비스

티베로가 아무리 잘 만들어지고 500회 이상의 전환 경험을 가지고 있으며, 비용 절감효과가 크다고 해도 실제 고객분들은 망설일 수밖에 없는 것이 사실이다. 그렇게 복잡하고 중요한 데이터베이스의 변경에 아무런 문제도 발생하지 않는다고 해서 그 말을 믿는 사용자는 없을 것이다. 티베로가 가장 자신 있는 부분은 원천기술을 보유한 기술서비스이다. 사실상 티베로를 선택하고 가장 만족도가 높은 부분이 기술서비스이다. 외산 벤더나 오픈소스는 기술 지원을 받기 어렵거나, 시간이 오래 지체되거나, 기능 개선에 대한 요청이 잘 반영되지 않아 많은 고통을 겪는데 티베로는 이러한 부분들이 완전 해소되기 때문에 데이터베이스 관리자들에게 더 친화적이라고 말할 수 있다.

관련용어

• 로드 밸런싱(Load Balancing) : 이중화 서버 중에서 특정 서버에 집중적으로 접속하는 것을 막기 위한 기능이다. 일반 애플리케이션 프로그램 환경이나 TAC(Tactical Advanced Computer) 환경에서 여러개의 노드로 사용자를 분산 시켜 데이터베이스 서버의 효율성을 향상하기 위한 기능을 제공한다.

• 뮤텍스(Mutex) : 공통의 리소스에 동시에 여러 스레드가 접근하는 것이 아닌, 한 스레드만 접근할 필요가 있을 때 사용한다. 뮤텍스가 신호 상태이면 스레드를 대기 상태로 만들고, 비신호 상태이면 스레드가 리소스를 사용한 후 반환하도록 한다.

• 테이블(Table) : 데이터베이스에서 가장 기본적인 저장단위이다. 모든 스키마 객체들은 테이블을 중심으로 정의된다. 테이블은 2차원 행렬의 형태로서 하나 이상의 컬럼과 로우로 구성되는데, 로우는 없을 수도 있다. 티비피에스엠(tbPSM)에서 지원하는 컬렉션 타입의 한 종류로, 구성요소와 길이 제한이 없고, 각각의 구성요소에 접근할 때는 배열과 마찬가지로 인덱스로 접근한다.

• 파티션(Partition) : 대용량 서비스를 하는 데이터베이스를 효율적으로 관리하려는 방법으로 하나의 논리적 테이블을 여러 개의 물리적인 공간으로 나누는 것이다. 파티션의 종류에는 범위(RANGE), 해시(HASH), 리스트(LIST) 파티션이 있다.

• 외부 프리시저(External Procedure) : 사용자가 직접 작성한 공유 라이브러리 또는 데이터베이스 관리 시스템의 에스큐엘이나 피에스엠(PSM) 등으로는 구현하기 힘든 것이나 구현이 불가능한 것을 C나 자바 프로그래밍 언어로 개발하여 이것을 마치 피에스엠 함수(또는 프리시저)인 것처럼 데이터베이스 관리 시스템 내에서 사용하는 기능이다.

구조

프로세스

• 리스너(Listener) : 클라이언트의 새로운 접속 요청을 받아 이를 유휴한 워킹 프로세스에 할당한다. 즉, 클라이언트와 워킹 프로세스 간의 중계 역할을 담당하며 이는 별도의 실행 파일인 티비리스너(tblistener)를 사용하여 작업을 수행한다. 만약 리스너가 죽는다면 어떠한 외부 접속도 이루어지지 않는데, 대부분의 사용자는 리스너가 정상적으로 구동된 후에는 신경을 쓰지 않다. 그 이유는 리스너가 기동할 경우 계속 정상적으로 작동할 것으로 여기기 때문이다.

순서

1. 현재 유휴한 워킹 스레드가 있는 워킹 프로세스를 찾아서 클라이언트의 접속 요청을 한다.
2. 이때 파일 디스크립터(File descriptor)와 함께 할당되므로 클라이언트는 서버의 내부 동작과 상관없이 마치 처음부터 워킹 스레드에 접속한 것처럼 동작하게 된다.
3. 리스너의 요청을 받은 컨트롤 스레드(CTHR: control thread)는 자기 자신에 속한 워킹 스레드의 상태를 검사하여 현재 유휴한 워킹 스레드에 클라이언트의 접속을 할당한다.
4. 할당된 워킹 스레드는 클라이언트와 인증 절차를 거친 후 세션을 시작한다.

• 워킹 프로세스(Working Process 또는 Foreground Process) : 클라이언트와 실제로 통신을 하며 사용자의 요구 사항을 처리하는 프로세스이다. 이 프로세스의 개수는 WTHR_PROC_CNT 초기화 파라미터로 조절할 수 있으며, 일단 티베로(Tibero)가 기동된 뒤에는 변경할 수 없다. 따라서 시스템 환경을 고려하여 적절한 값을 설정해야 한다. 티베로(Tibero)는 효율적인 리소스의 활용을 위해 스레드(Thread) 기반으로 작업을 수행한다. 티베로를 설치하면 기본적으로 하나의 워킹 프로세스 안에는 1개의 컨트롤 스레드와 10개의 워킹 스레드가 존재한다. 프로세스당 워킹 스레드 개수는 _WTHR_PER_PROC 초기화 파리 미터로 조절할 수 있으며, WTHR_PROC_CNT처럼 일단 티베로가 기동된 뒤에는 변경할 수 없다. 따라서 시스템 환경을 고려하여 적절한 값을 설정해야 한다. WTHR_PROC_CNT와 _WTHR_PER_PROC 초기화 파라미터값을 직접 바꾸는 것보다는 MAX_SESSION_COUNT 초기화 파라미터를 통해 서버에서 제공하는 최대 세션 개수를 지정할 것을 권장한다. MAX_SESSION_COUNT 값에 따라 WTHR_PROC_CNT와 _WTHR_PER_PROC 값이 자동으로 설정된다. 만약 WTHR_PROC_CNT와 _WTHR_PER_PROC를 직접 설정할 경우 WTHR_PROC_CNTWTHR_PROC_CNT * _WTHR_PER_PROC 값이 MAX_SESSION_COUNT 값과 같게 두 값을 설정해야 한다.

• 컨트롤 스레드(Control Thread) : 워킹 프로세스마다 하나씩 존재하며, 티베로가 가동될 때 초기화 피라미터에 설정된 수만큼 워킹 스레드를 생성하고, 클라이언트의 새로운 접속 요청이 오면 현재 유휴한 워킹 스레드에클라이언트의 접속을 할당하고, 시그널 처리를 담당하는 역할을 한다.

• 워킹 스레드(Working Thread) : 워킹 스레드는 클라이언트와 1:1로 통신하며, 클라이언트가 보내는 메시지를 받아 처리하고, 그 결과를 돌려준다. 주로 에스큐엘(SQL) 파싱, 최적화 수행 등 데이터베이스 관리 시스템(DBMS)이 하는 작업 대부분이 워킹 프로세스에서 일어난다. 그리고 워킹 스레드는 하나의 클라이언트와 접속하므로 티베로에 동시 접속이 가능한 클라이언트 수는 WTHR_PROC_CNT * _WTHR_PER_PROC이다. 티베로는 세션 멀티플렉싱(Session multiplexing)을 지원하지 않으므로 하나의 클라이언트 접속은 곧 하나의 세션과 같다. 그러므로 최대 세션이 생성될 수 있는 개수는 WTHR_PROC_CNT * _WTHR_PER_PROC를 연산한 값과 같다. 워킹 스레드는 클라이언트와 접속이 끊긴다고 해도 없어지지 않으며, 티베로가 기동될 때 생성된 이후부터 종료할 때까지 계속 존재하게 된다. 이러한 구조에서는 클라이언트와 접속을 빈번하게 발생시키더라도 매번 스레드를 생성하거나 제거하지 않으므로 시스템의 성능을 높일 수 있다. 반면 실제 클라이언트의 수가 적더라도 초기화 파라미터에 설정된 개수만큼 스레드를 생성해야 하므로 운영체제의 리소스를 계속 소모하는 단점은 있으나, 운영체제 대부분이 유휴한 스레드 하나를 유지하는 데 드는 리소스는 매우 적으므로 시스템을 운영하는 데는 별 무리가 없다.

• 백그라운드 프로세스(Background Process) : 클라이언트의 접속 요청을 직접 받지 않고 워킹 스레드나 다른 백그라운드 프로세스가 요청할 때 또는 정해진 주기에 따라 동작하는 주로 시간이 오래 걸리는 디스크 작업을 담당하는 독립된 프로세스이다. 백그라운드 프로세스에 속해 있는 프로세스는 감시 프로세스(MTHR: monitor thread), 시퀀스 프로세스(AGENT 또는 SEQW: sequence writer), 데이터 블록 쓰기 프로세스(DBWR: data block writer 또는 BLKW), 체크포인트 프로세스(CKPT: checkpoint process), 로그 쓰기 프로세스(LGWR: log writer 또는 LOGW) 등이 있다. 먼저, 감시 프로세스는 실제로는 하나의 독립된 프로세스이다. 리스너를 제외하고 티베로가 기동할 때 최초로 생성되며 티베로가 종료하면 맨 마지막에 프로세스를 끝마친다. 시퀀스 프로세스는 시스템 유지를 위해 주기적으로 처리해야 하는 티베로 내부의 작업을 담당한다. 4 SP1까지는 시퀀스 캐시(sequence cache)의 값을 디스크에 저장하는 작업도 담당했으나, 5 이후로 각 워킹 스레드가 담당하는 것으로 변경되었다. 사용자의 혼란을 피하기 위해 시퀀스 프로세스라는 명칭은 유지된다. 데이터 블록 쓰기 프로세스는 사용자가 수정한 데이터 블록을 주기적으로 디스크에 기록한다. 기록된 데이터 블록은 주로 워킹 스레드가 직접 읽어온다. 체크포인트 프로세스는 주기적으로 또는 클라이언트의 요청에 따라 메모리에 있는 변경된 모든 데이터 블록을 디스크에 기록하는 작업이다. 티베로에 장애가 발생하면 이를 복구하기 위해 걸리는 시간이 한계 수치를 넘지 않도록 예방하는 효과가 있다. 이러한 체크포인트를 관리하는 프로세스가 체크포인트 프로세스이다. 마지막으로, 로그 쓰기 프로세스는 레도(Redo) 로그 파일을 디스크에 기록하는 프로세스이다. 로그 파일에는 데이터베이스의 데이터에 대한 모든 변경 사항을 저장하고 있으며 빠른 트랜잭션 처리와 복구를 위해 사용된다.

데이터베이스

티베로 데이터베이스 관리 시스템(Tibero RDBMS)은 에스큐엘 문장의 논리적인 묶음인 데이터베이스 트랜잭션이 안전하게 수행되는 것을 보장하기 위해서 다음의 4가지 성질을 만족한다. 4가지 성질은 원자성(Atomicity), 일관성(Consistency), 고립(Isolation), 내구성(Durability)이다. 티베로 데이터베이스 관리 시스템의 데이터를 저장하는 구조는 다음과 같이 논리적 구조와 물리적 구조로 나뉜다. 논리적 구조와 물리적 구조는 분리되어 있기 때문에 논리적 저장 구조 접근에 직접적인 영향을 주지 않고 데이터의 물리적 구조를 다룰 수 있다.

• 논리적 구조 : 데이터베이스의 스키마 객체를 저장하는 영역이다. 논리적 저장 영역은 다음과 같은 포함 관계가 있다.

 데이터베이스 > 테이블스페이스 > 세그먼트 > 익스텐트 > 블록

• 물리적 구조 : 운영체제와 관련된 파일을 저장하는 영역이다. 물리적 저장 영역은 다음과 같은 포함 관계가 있다.

 데이퍼 파일 > 운영체제의 데이터 블록

데이터베이스 클러스터링

분산 데이터베이스 기반의 클러스터링 방법

데이터베이스 클러스터링이란 단일 인스턴스 기반의 데이터베이스 관리 시스템 여러 대를 이용하여, 사용자에게는 하나의 대용량 데이터베이스 관리 시스템과 같은 동작을 보이도록 하는 것이다. 클러스터링의 결과로 얻을 수 있는 이익 은 두 가지인데, 하나의 노드가 멈춰도 나머지 노드들은 동작을 계속함으로써 매우 높은 수준의 서비스 안정성을 제공할 수 있으며, 노드의 수에 비례해 수용 가능한 사용자의 수가 늘어나게 돼 므로, 전체적인 성능을 향상시키게 되는 것이다. 단일 데이터베이스 인스턴스를 이용하여 데이터베이스 클러스터를 구축하는 기술은 여러 가지가 알려져 있다. 가장 쉬운 접근 방법은 분 산 데이터베이스 기술을 이용하는 구조다. 이 방법에서는 하나의 테이블을 여러 개의 파티션으로 나눈 다음 네트워크로 서로 연결된 각 데이터베이스 노드들마다 각각 하나의 파티션을 저장하는 것이다. 이러한 분산 데이터베이스 기반의 구조에서 사용자의 접속은 각 인스턴스들에게 고르게 나눠지게 되는데, 사용자가 요청한 데 이터가 해당 인스턴스의 파티션이 아닌 다른 인스턴스에 존재 하는 경우 분산 데이터베이스 요청을 통해서 다른 노드의 정보를 가져오게 된다. 이 경우의 단점은 사용자 질의에서 어떠한 파티션에 속하는 데 이터인지를 판단할 정보가 부족하다면, 어쩔 수 없이 전체 인스 턴스들에게 해당 질의를 브로드캐스트하여 처리할 수밖에 없으므로 성능에 악영향을 준다는 것이다. 게다가 사용자가 한 번에 두 개 이상의 파티션에 속하는 데이터 쓰기 작업을 하는 경우에는 분산 데이터베이스의 기법을 사용해서 트랜잭션을 처리해야 하므로 성능이 느려진다. 그리고 데이터베이스 관리자가 인스턴스를 추가, 삭제하는 작업을 할 때 마다 데이터 장애를 대비하여 모든 데이터는 디스크 미러링이 되어야 한다.

데이터 복제 기반의 클러스터링 방법

이 경우 모든 인스턴스가 완전한 데이터를 가지게 되므로 읽기 동작의 경우 매우 빠르게 처리할 수 있게 되지만, 모든 쓰기 동작의 경우에는 모든 인스턴스로 브로드캐스팅을 하는 부하가 있기 때문에 쓰기 성능은 느려지게 된다. 따라서 읽기 위주의 사용자에게 적합한 구조라고 할 수 있다. 데이터 복제 기법의 경우 자체적으로 디스크 미러링과 동일한 효과를 가지게 되므로, 추가적인 디스크 미러링을 구축할 필요가 없다는 장점이 있는 반면에, 인스턴스의 수만큼 데이터 복제본이 존재하는 구조이므로 인스턴스의 수가 많아질수록 필요한 디스 크의 용량이 계속 증가하는 문제점이 있다. 따라서 인스턴스의 수가 2개를 초과하는 환경에는 적합하지 않다.

공유 디스크 기반의 클러스터링 방법

이 방법에서 데이터는 단일 인스턴스 시스템에서와 마찬가지로 하나의 디스크에만 저장되어 있으며, 이것을 여러 인스턴스가 공유해서 사용하는 구조다. 데이터 관점에서 파티션이나 복제를 추가로 할 필요가 없으므로 가장 자연스러운 형태의 데이터 관리 가 가능하다. 현재 이러한 구조를 채택하는 데이터베이스 클러스터는 오라 클 RAC(Real Application Clusters)가 가장 잘 알려져 있으며 티베로 관계형 데이터베이스 관리 시스템 4.0에서도 동일한 공유 디스크 기반의 구조를 채택하고 있다. 공유 디스크 기반의 클러스터링에서는 단일 인스턴스와 마찬 가지로 읽기, 쓰기 동작을 모두 하나의 인스턴스에서 완전하게 처리할 수 있다. 이 과정에서 관계형 데이터베이스 관리 시스템 내부 메모리에 가지고 있는 데이터에 대해서 서로 다른 인스턴스 간에 불일치하게 되는 문제 가 발생하지 않도록 DB 캐시 일관성 프로토콜을 필요로 한다. 그러나 이러한 프로토콜은 앞서 소개한 두 가지 다른 방법에서 필요로 하고 또는 데이터 복제에 비하면 훨씬 적은 부하로 동작이 가능하므로, 전체적인 성능은 공유 디스크 방식이 가장 뛰어나다.

명령어

테이블스페이스

생성

 SQL>
 CREATE TABLESPACE cym_tb DATAFILE '/home/tibero/tibero6/tbdata/cym_tb.tdf' SIZE 10M AUTOEXTEND 
 ON NEXT 1M MAXSIZE 512M EXTENT MANAGEMENT LOCAL AUTOALLOCATE; 

조회

 SQL>
 SELECT A.FILE_NAME, A.TABLESPACE_NAME, BYTES/1024/1024||'M' "SIZE" FROM DBA_DATA_FILES A, 
 DBA_TABLESPACES B WHERE A.FILE_ID = B.TS_ID AND A.TABLESPACE_NAME = 'CYM_TB';
 !ls -al /home/tibero/tibero6/tbdata 

삭제

 SQL>
 DROP TABLESPACE cym_tb INCLUDING CONTENTS AND DATAFILES; 

유저 생성

생성

 SQL>
 CREATE USER test IDENTIFIED BY test;
 User 'TEST' created; 

데이터베이스 접속 및 리소스 사용권한 생성

 SQL>
 GRANT RESOURCE , CONNECT TO test;
 Granted. 

삭제

 SQL>
 DROP USER test CASCADE;
 User 'TEST' dropped. 

자주 사용되는 간단한 에스큐엘명령어

환경설정값 확인

 SQL>
 show all
 SYSTEM PARAMETERS ------------------- autocommit OFF autotrace OFF blockterminator ".PARAMETER  VALUE
 ---------------- ---------------------------------------------------------------
 AUTOCOMMIT       OFF
 AUTOTRACE        OFF
 BLOCKTERMINATOR  "." (0x2E)
 COLSEP           " " (0x20)
 CONCAT           "." (0x2E)
 DDLSTATS         OFF
 DEFINE           "&" (0x26) .
 
 SQL> SET PAGESIZE 100 (한 페이지당 표시되는 라인 수이다.)
 SQL> SET LINESIZE 150 (에스큐엘 쿼리 실행 시간을 확인한다.)
 SQL> SET TIME ON (현재 시간을 표시한다,)
 SQL> SET AUTOTRACE ON (수행중인 쿼리의 실행 계획이나 통계 정보 출력한다.)
 SQL> SET SERVEROUTPUT ON (티비피에스엠 수행결과를 화면에 출력하기 위한 명령어이다.) 

도입 성공사례

공공기관

• 경찰청 : 대한민국의 중앙경찰기관, 치안경찰에 관한 사무를 총괄하기 위해 행정안전부 장관 소속 아래에 둔 기관이다. 국가경찰 공무원 중 해양경찰청 소속이 아닌 모든 경찰관이 소속된 관청으로, 본청은 서울시 서대문구 통일로에 있다. 이전에는 내무부 치안본부로 불렸으나, 이후 행정안전부(당시 내무부)의 독립 외청으로 승격, 대통령령에 의거하여 현재의 이름으로 변경하였다. 경찰청은 티베로 5 TAC(Tactical Advanced Computer) 버전을 적용하였고, 온라인 조회, 통합 포털 등 35시스템을 전환하고 정보시스템 성능을 개선했다. 도입 후 선진 치안 업무를 24시간 365일 제공하여 원활하고 신속한 업무 행정 프로세스 구축 실현을 하는 효과를 보았다.

• 기상청 : 기상에 관한 사무를 관장하는 대한민국의 중앙행정기관이다. 1990년 12월 27일 중앙기상대를 개편하여 발족하였으며, 서울특별시 동작구 여의대방로16길 61에 위치하고 있다. 기상청은 기상청 차세대 통합 가상 아이티 인프라 시스템의 메인 데이터베이스 관리 시스템으로 외산 데이터베이스 관리 시스템과 벤치마크테스트를 거쳐 안정성과 성능이 검증된 제품 도입 목적을 가지기 위해 티베로 5 TAC(Tactical Advanced Computer) 버전을 적용하였고, 도입 후 기존 외산 데이터베이스 관리 시스템에서 탈피함으로써 총소유 비용을 절감을 기대하며, 기존 외산 데이터베이스 관리 시스템 환경에서 구축된 애플리케이션을 재사용함으로써 재구축 범위를 최소화하는 효과를 보았다.

금융기관

• 신한은행 : 신한금융그룹 계열 시중은행으로, 국내 최초로 민간 주도 금융지주회사를 설립했다. 신한은행은 국산 데이터베이스 관리 시스템 성능 향상에 따른 데이터베이스 다면화 정책 및 비용 절감 필요와 365일 24시간 안정성과 가용성이 필요한 업무에 TAC(Tactical Advanced Computer) 기능이 필요, 기존 오라클 위주에서 국산 데이터베이스 성능 향상에 따라 데이터베이스 다변화를 위해 티베로를 적용하였고, 도입 후 365일 24시간 무중단 운영을 위해 TAC(Tactical Advanced Computer) 기능으로 가용성 확보와 부하 분산 및 가용성 검증, 다양한 장애 시나리오에서 안정적인 트랜잭션 처리 검증 효과를 보았다.

유통 및 서비스기관

• 인터파크 : 1995년 11월 데이콤의 소사장제로 출범했고, 이듬해 6월 국내 최초 온라인 쇼핑몰 ‘인터파크’를 오픈해 본격적인 전자상거래 시장을 열었다. 인터넷을 통한 무형적 테마파크를 고객에게 제공하고자 하는 뜻이 담겨 있으며, 쇼핑/투어/도서/엔터테인먼트&티켓 등 다양한 사업을 통해 생활에 필요한 모든 유형의 상품에서 서비스까지 제공하고 있는 국내 대표 전자상거래 기업이다. 인터파크는 지나친 외산 데이터베이스 관리 시스템 사용에 따른 기술적 종속과 비용 증가로부터 탈피 필요를 해서 티베로 5를 적용하였고, 도입 후 단기간 내 성공적인 전환으로 시스템 전환 확산과 비용을 절감하는 효과를 보았다.

전망

국내 데이터베이스 관리 시스템(DBMS) 시장은 2014년도에 약 5천 8백억 원 규모를 형성하였으며 연평균 7% 이상의 성장률을 보이고 있다. 하지만 오라클, 아이비엠, 마이크로소프트 3사가 90% 정도의 점유율을 차지하고 있으며, 오라클의 경우 60% 정도의 시장을 점유하고 있다. 이러한 시장 지배력을 기반으로 오라클은 고가의 가격정책을 고수하고 있으며, 특히 유지보수 정책을 엄격하게 관리하고 있다. 이는 신규 라이선스 매출보다 유지보수 매출 비중이 높은데 기인하며 결국 사용자의 총 소유 비용에 부담을 주고 있다. 따라서 시장을 미리 선점한 외산 데이터베이스 관리 시스템 제조사 입장에서는 사용자가 타사의 제품으로 쉽게 변경할 수 없다는 사실을 알고 있기 때문에 상대적으로 우월적 지위에 있을 수밖에 없으며, 특정 정책이 불합리하고 유지보수 비용이 지나치게 비싸다는 사용자의 주장에 협의할 필요가 전혀 없다. 그들의 정책이 싫다면 수많은 위험성을 사용자가 감수하고 데이터베이스 관리 시스템 전환을 준비하는 것 외에는 방법이 없는 것이다. 이처럼 데이터베이스 관리 시스템의 작은 변경도 매우 신중하게 접근할 수밖에 없는 데이터베이스 관리 시스템 자체가 가지고 있는 어플리케이션과의 상호 의존성을 고려한다면 기업 내 데이터베이스 관리자 혹은 어플리케이션 관리자에게 데이터베이스 관리 시스템 제조사의 변경은 받아들이기 너무나 큰 위험이라는 것을 이해할 수 있을 것이며 이것이 바로 국산 데이터베이스 관리 시스템 점유율이 좀처럼 올라가지 못하는 원인이다.

참고자료

• 〈제1장 Tibero 소개〉, 《테크넷》
• 박민해, 〈Tibero RDBMS : 차세대 관계형 DBMS〉, 《티스토리》, 2012-09-12
• 티맥스소프트의데이터 테크놀로지 공식사이트 - https://www.kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=188&dbnum=127959&mode=detail&type=techreport
• Tmax, 〈(Product) DBMS 시장의 라이징 스타 티베로(Tibero)〉, 《네이버 블로그》, 2017-09-13
• 티베로 용어집 백서 - https://www.tmaxdata.com/img/service/pdf/Tibero%205%20Glossary%20Guide_v2.1.4.pdf
• 티베로 관계형 데이터베이스 관리 시스템 구조 백서 - https://www.tmaxdata.com/img/service/pdf/Tibero%20RDBMS%20Architecture.pdf
• 미니대왕, 〈Tibero RDBMS Utility Guide 간단한 명령!〉, 《티스토리》, 2019-09-13
• 사업부문 소개 및 성공사례 공식 홈페이지 - https://www.tmaxdata.com/company/successList.do
• 티베로, 〈우리 회사 데이터베이스를 티베로로 변경하기〉, 《구루비》, 2017-03-27

같이 보기

• 데이터베이스 관리 시스템(DBMS)
• 관계형 데이터베이스 관리 시스템(RDBMS)
• 오라클
• ㈜티맥스소프트
• ㈜티맥스데이터
• 티비마이그레이터