Tibero 소개
Tibero 기본 개념과 티베로 DBMS 기능 프로세스 구조에 대해 안내합니다.
대용량의 데이터를 관리하고 안정적인 비즈니스의 연속성을 보장하는 데이터 관리 솔루션인 Tibero는 DB 환경에서 요구되는 주요 기능을 다음과 같이 갖추고 있습니다.
주요 기능
분산 데이터베이스 링크 (Distributed Database Link)
데이터베이스 인스턴스별로 각각 서로 다른 데이터를 저장하는 기능입니다.
이 기능을 통해 원격 데이터 베이스에 저장된 데이터를 네트워크를 통해 읽기 및 쓰기를 수행할 수 있습니다. 또한 이 기능은 다양한 벤더의 DB 제품을 연결하여 읽기 및 쓰기를 수행할 수 있습니다.
데이터 이중화 (Data Replication)
현재 운영 중인 데이터베이스에서 변경된 모든 내용을 Standby DB로 복제하는 기능입니다. 네트워크를 통해서 변경 로그(Change log)만 전송하면 Standby DB에서 데이터에 적용하는 방식입니다.
데이터베이스 클러스터 (Database Cluster)
기업용 DB의 최대 이슈인 고가용성과 고성능을 모두 해결하는 기능 입니다.
Tibero는 고가용성과 고성능 을 보장하기 위해 Tibero Active Cluster 기술을 보유하고 있습니다.
이 기술로 여러 개의 데이터베이스 인스턴스가 공유 디스크를 이용하여 동일한 데이터베이스를 공유할 수 있습니다. 이때 각 데이터베이스 인스턴스는 내부의 데이터베이스 캐시(Database cache) 사이의 일관성을 유지하는 기술이 매우 중요하므로 이러한 기술도 Tibero Active Cluster에 포함하여 제공하고 있습니다.
병렬 쿼리 처리 (Parallel Query Processing)
기업의 데이터 크기는 계속적으로 증가하고 있고 대용량 데이터를 처리하기 위해 서버의 리소스를 최대한 활용할 수 있는 병렬 처리 기술이 필수적으로 요구되고 있습니다.
Tibero는 이러한 요구사항에 맞추어 온라인 트랜잭션 처리 (On-Line Transaction Processing, 이하 OLTP) 환경에 최적화된 기능을 제공할 뿐만 아니라 OLAP(On-Line Analytical Processing) 환경에 최적화된 SQL 병렬 처리 기능을 제공하고 있습니다. 이로써 쿼리는 빠른 응답 속도로 수행되며 기업의 빠른 의사 결정을 돕습니다.
쿼리 최적화기 (Optimizer)
쿼리 최적화기는 스키마 객체의 통계 정도를 바탕으로 다양한 데이터 처리 경로들을 고려하여 어떤 실행 계획이 가장 효율적인지를 결정합니다.
쿼리 최적화기는 논리적으로 아래와 같은 단계를 통해 수행됩니다.
주어진 SQL 문을 처리하는 다양한 실행 계획들을 만듭니다.
데이터의 분산도에 대한 통계 정보와 테이블, 인덱스, 파티션 등의 특징을 고려하여 각각의 실행계획의 비용을 계산합니다.
실행 계획들의 비용을 비교하여 가장 비용이 작은 계획을 선택합니다.
쿼리 최적화기의 주요 기능은 아래와 같습니다.
최적화 목표
사용자는 최적화기의 최종 목표를 바꿀 수도 있는데 다음의 두 가지 목표를 선택할 수 있습니다.
전체 처리 시간
ALL_ROWS 힌트 사용 시, 최적화기는 마지막 row까지 얻어내는 시간을 최대한 단축하도록 최적화
최초 반응 시간
FIRST_ROWS 힌트 사용 시, 최적화기는 첫 번째 row를 얻어내는 시간을 최대한 단축하도록 최적화
질의 변형
질의의 형태를 바꿔서 더 좋은 실행 계획을 만들 수 있도록 합니다. 질의 변형의 예에는 뷰 병합, 부질의 언네스트, 실체화 뷰의 사용 등이 있습니다.
데이터 접근 경로 결정
데이터를 데이터베이스로부터 꺼내오는 작업은 전체 테이블 스캔, 인덱스 스캔, rowid 스캔 등의 다양한 방법을 통해서 수행될 수 있습니다. 각 방법마다 필요한 데이터의 양이나 필터링의 형태 등에 따라 장단점이 있어 질의에 따라 최적의 접근 방식이 다릅니다.
조인 처리 방식 결정
여러 테이블에서 데이터를 꺼내오게 되는 조인의 경우 최적화기는 조인의 순서와 방법을 결정해야 합니다. 여러 테이블 간의 조인일 때 어떤 테이블을 먼저 조인할지에 대한 순서와 각각의 조인에 있어서 중첩 루프 조인, 합병 조인, 해시 조인 등의 다양한 방법 중 어떤 것을 사용할지가 실행 속도에 큰 영향을 미치게 됩니다.
비용 추정
각각의 실행 계획에 대해 비용을 추정합니다. 비용 추정을 위해 필요한 predicate의 선택도나 각 실행 단계에서 데이터의 row 수 등을 통계 정보를 사용해 추정하고, 이를 바탕으로 각 단계에서의 비용을 추정합니다.
기본 기능
Tibero는 데이터베이스의 영속성과 일관성을 유지하기 위해 SQL 문장의 묶음인 트랜잭션을 아래의 4가지 특성을 통해 보장합니다.
Atomicity
All-or-nothing. 즉, 트랜잭션이 행한 모든 일이 적용되던가 아니면 모두 적용되지 않아야 함을 의미합니다. Tibero에서는 이를 위해 undo 데이터를 사용합니다.
Consistency
트랜잭션이 데이터베이스의 Consistency를 깨뜨리는 일은 여러 방면에서 발생할 수 있습니다. 간단한 예로서, 테이블과 인덱스 간에 서로 다른 내용을 담고 있어서 Consistency가 깨지는 것입니다. 이를 방지하기 위해 Tibero에서는 트랜잭션이 적용한 일들 중 일부만 자신이나 남에게 적용되는 것을 금하고 있습니다. 즉, 테이블만 수정했고 아직 인덱스를 수정하지 않은 상태라고 해도 다른 트랜잭션에서는 이를 예전 모습으로 돌려 보아서 테이블과 인덱스가 항상 Consistency가 맞는 형태로 보이게 됩니다.
Isolation
트랜잭션은 혼자만 수행되고 있는 것처럼 보이게 됩니다. 물론 다른 트랜잭션이 수정한 데이터에 접근할 때는 이를 기다릴 수는 있지만 다른 트랜잭션이 수정 중이므로 접근할 수 없다고 에러가 발생하지는 않습니다. 이를 위해 Tibero에서는 Multi version concurrency control 기법과 row-level locking 기법을 사용합니다.
데이터를 참조하는 경우에는 MVCC 기법을 이용하여 다른 트랜잭션과 무관하게 참조 가능하며, 데이터를 수정할 때도 row level의 fine-grained lock control을 통해 최소한의 충돌만을 일으키고 같은 데이터에 접근한다고 해도 대기함으로써 이를 해결합니다.
Durability
Tibero에서는 이를 위해 Redo 로그와 write-ahead logging 기법을 사용합니다.
트랜잭션이 커밋할 때 해당 Redo 로그가 디스크에 기록되어 트랜잭션의 영속성을 보장해줍니다. 또한 블록이 디스크에 내려가기 전에 항상 Redo 로그가 먼저 내려가서 데이터베이스 전체가 일관성을 갖게 합니다.
프로세스 구조
Tibero는 대규모 사용자 접속을 수용하는 다중 프로세스 및 다중 스레드 기반의 아키텍처를 갖추고 있습니다.
아래는 Tibero의 프로세스 구조를 나타내는 그림 입니다.
Tibero의 프로세스는 크게 3가지로 구성 됩니다.
리스너 (Listener)
워커 프로세스 (Worker Process 또는 Foreground Process)
백그라운드 프로세스 (Background Process)
리스너
리스너(Listener)는 클라이언트의 새로운 접속 요청을 받아 이를 유휴한 워커 프로세스에 할당합니다. 즉, 클라이언트와 워커 프로세스간의 중계 역할을 담당하며 이는 별도의 실행 파일인 tblistener를 사용하여 작업을 수행합니다. Tibero 6부터 MONP에 의해서 생성되며 외부에서 강제 종료하더라도 다시 생성됩니다.
아래는 [그림 1]을 기준으로 클라이언트의 새로운 접속 요청이 이뤄지는 순서입니다.
현재 유휴한 워커 스레드가 있는 워커 프로세스를 찾아서 클라이언트의 접속 요청(①)을 합니다.
이때 File descriptor와 함께 할당되므로 클라이언트는 서버의 내부 동작과 상관없이 마치 처음부터 워커 스레드에 접속한 것처럼 동작하게 됩니다.
리스너의 요청을 받은 컨트롤 스레드(CTHR: control thread)는 자기 자신에 속한 워커 스레드의 상태를 검사(②)하여 현재 유휴한 워커 스레드에 클라이언트의 접속을 할당(③)합니다.
할당된 워커 스레드는 클라이언트와 인증 절차를 거친 후 세션을 시작(④)합니다.
워커 프로세스
워커 프로세스(Worker Process)는 클라이언트와 실제로 통신을 하며 사용자의 요구 사항을 처리하는 프로세스 입니다. 프로세스의 개수는 WTHR_PROC_CNT 초기화 파라미터로 조절할 수 있으며, 일단 Tibero가 기동된 뒤에는 변경할 수 없으므로 시스템 환경을 고려한 적절한 값을 설정해야 합니다.
Tibero 6부터 워커 프로세스는 용도에 따라 두 그룹으로 나눌 수 있습니다.
포어그라운드 워커 프로세스(Fore ground Worker Process)는 리스너를 통해 들어온 온라인 요청을 처리하는 반면, 백그라운드 워커 프로세 스(Background Worker Process)는 인터널 태스크(Internal Task)나 잡 스케줄러에 등록된 배치 작업을 수행합니다. 그룹은 MAX_BG_SESSION_COUNT 초기화 파라미터로 조절할 수 있습니다.
Tibero는 효율적인 리소스의 활용을 위해 스레드(Thread) 기반으로 작업을 수행합니다. Tibero를 설치하면 기본적으로 하나의 워커 프로세스 안에는 1개의 컨트롤 스레드와 10개의 워커 스레드가 존재합니다.
프로세스당 워커 스레드 개수는 WTHR_PER_PROC 초기화 파라미터로 조절할 수 있으며, WTHR_PROC_CNT 처럼 일단 Tibero가 기동된 뒤에는 변경할 수 없습니다. 따라서 시스템 환경을 고려한 적절한 값을 설정해야 합니다.
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_CNT * WTHR_PER_PROC 값이 MAX_SESSION_COUNT 값과 같게 두 값을 설정해야 합니다.
MAX_BG_SESSION_COUNT 값은 MAX_SESSION_COUNT 보다 작은 값을 설정해야하며 WTHR_PER_PROC 값의 배수가 되어야 합니다.
워커 프로세스는 컨트롤 스레드와 워커 스레드를 통해 작업을 수행합니다.
컨트롤 스레드
워커 프로세스마다 하나씩 존재하며 다음과 같은 역할을 담당합니다.
Tibero가 기동될 때 초기화 파라미터에 설정된 수만큼 워커 스레드를 생성
클라이언트의 새로운 접속 요청이 오면 현재 유휴한 워커 스레드에 클라이언트의 접속을 할당
시그널 처리를 담당
I/O multiplexing을 지원하며 필요한 경우 워커 스레드 대신 메시지를 보내거나 받는 역할 수행 (Tibero 6부터 적용)
워커 스레드
워커 스레드는 클라이언트와 1:1로 통신하며, 클라이언트가 보내는 메시지를 받아 처리하고, 그 결과를 돌려줍니다. 주로 SQL 파싱, 최적화 수행 등 DBMS가 하는 작업 대부분이 워커 프로세스에서 일어납니다.
워커 스레드는 하나의 클라이언트와 접속하므로 Tibero에 동시 접속이 가능한 클라이언트 수는 WTHR_PROC_CNT * WTHR_PER_PROC 입니다.
Tibero는 세션 멀티플렉싱(Session multiplexing)을 지원하지 않으므로 하나의 클라이언트 접속은 곧 하나의 세션과 같습니다. 그러므로 최대 세션이 생성될 수 있는 개수는 WTHR_PROC_CNT * WTHR_PER_PROC를 연산한 값과 같습니다.
워커 스레드는 클라이언트와 접속이 끊긴다고 해도 없어지지 않으며, Tibero가 기동될 때 생성된 이후 부터 종료할 때까지 계속 존재합니다. 이러한 구조에서는 클라이언트와 접속을 빈번하게 발생시키더라도 매번 스레드를 생성하거나 제거하지 않으므로 시스템의 성능을 높일 수 있습니다.
반면 실제 클라이언트의 수가 적더라도 초기화 파라미터에 설정된 개수만큼 스레드를 생성해야 하므로 운영체제의 리소스를 계속 소모하는 단점은 있으나, 운영체제 대부분이 유휴한 스레드 하나를 유지하는데 드는 리소스는 매우 적으므로 시스템을 운영하는 데는 별다른 무리가 없습니다.
주의
많은 수의 워커 스레드가 동시에 작업을 수행할 시, 심한 경우 운영체제에 과도한 부하를 일으켜 시스템 성능이 크게 저하될 수 있습니다.
그러므로 대규모 시스템을 구축할 경우에는 Tibero와 클라이언트의 애플리케이션 프로그램 사이에 미들웨어를 설치하여 3-Tier 구조로 시스템을 구축할 것을 권장합니다.
백그라운드 프로세스
백그라운드 프로세스(Background Process)는 클라이언트의 접속 요청을 직접 받지 않고 워커 스레드나 다른 백그라운드 프로세스가 요청할 때 또는 정해진 주기에 따라 동작하는, 주로 시간이 오래 걸리는 디스크 작업을 담당하는 독립된 프로세스 입니다.
백그라운드 프로세스에 속해 있는 프로세스는 아래와 같습니다.
Monitor Process (MONP: 감시 프로세스)
Tibero 6부터 영문 약자가 스레드에서 프로세스로 변경되었고 실제로 하나의 독립된 프로세스 입니다. Tibero가 기동할 때 최초로 생성되며 Tibero가 종료하면 제일 마지막에 프로세스를 끝마칩니다.
Tibero가 기동할 때 리스너를 포함한 다른 프로세스를 생성하거나 주기적으로 각 프로세스의 상태를 점검하는 역할을 담당하며 또한 교착 상태 (deadlock)도 검사합니다.
Tibero 매니저 프로세스 (MGWP)
시스템을 관리하기 위한 용도의 프로세스로, 관리자의 접속 요청을 받아 이를 시스템 관리 용도로 예약된 워커 스레드에 접속을 할당 합니다. 기본적으로 워커 프로세스와 동일한 역할을 수행하지만 리스너를 거치지 않고 스페셜 포트를 통해 직접 접속을 처리합니다. 단, SYS 계정만 접속이 허용됩니다.
Agent Process (AGNT: 에이전트 프로세스)
시스템 유지를 위해 주기적으로 처리해야 하는 Tibero 내부의 작업을 담당합니다.
Tibero 4 SP1까지는 시퀀스 캐시(sequence cache)의 값을 디스크에 저장하는 작업도 담당했으나, Tibero 5 이후로 각 워커 스레드가 담당하는 것으로 변경됐습니다. 또한이전에는 SEQW라는 명칭을 사용했으나 Tibero6부터 AGNT로 명칭이 변경됐습니다.
Tibero 6부터 다중 스레드(Multi-threaded) 기반 구조로 동작하며, 서로 다른 용도의 업무를 스레드별로 나누어 수행합니다.
DataBase Wirte Process (DBWR: 데이터베이스 쓰기 프로세스)
데이터베이스에서 변경된 내용을 디스크에 기록하는 일과 연관된 스레드들이 모여 있는 프로세스입니다. 사용자가 변경한 블록을 디스크에 주기적으로 기록하는 스레드, Redo 로그를 디스크에 기록하는 스레드, 이 두 스레드를 통해 데이터베이스의 체크포인트 과정을 관할하는 체크포인트 스레드 등이 이 프로세스에 포함됩니다.
Recovery Worker Process (RCWP: 리커버리 워커 프로세스)
리커버리와 백업을 담당하는 프로세스 입니다. 부팅과정에서 NOMOUNT 이후의 부팅 단계를 올리는 역할을 수행하고 리커버리가 필요한 상황인지 여부를 판단하여 필요할 경우 리두로그를 읽어서 리커버리를 진행합니다. tbrmgr을 이용하여 백업 작업을 하거나 백업본을 이용한 미디어 리커버리를 진행하는 경우에도 이 프로세스에서 진행합니다.
Parallel Execution Worker Process (PEWP: Parallel Execution 워커 프로세스)
Parallel Execution Process(이하 PEP)는 PE 수행을 위해 도입된 PE 전용 프로세스 입니다. PE SQL을 처리할 때 locality를 극대화하기 위해서 WTHR들을 하나의 PEP에서 할당합니다.
또한 일반적인 클라이언트 세션을 위한 WTHR과 분리되어, 모니터링 및 관리가 용이합니다.
Last updated