[Tibero] 티베로 아키텍쳐

목차

시작하며

티베로 프로세스는 크게 세가지로 구성된다

1. 리스너
2. 워커프로세스
3. 백그라운드 프로세스

 

워커 프로세스 (Worker Process)

---

tbsvr_WP000, tbsvr_WP001

 

클라이언트와 실제 통신을 하며 사용자의 SQL 요구사항을 처리하는 프로세스.

이 프로세스의 갯수는 초기화 파라메터로 조정할 수 있으며 일단 티베로가 기동된 뒤에는 재기동을 해야만 변경할 수 있다.

 

따라서 시스템 환경을 고려하여 적절한 환경을 구성해야한다.

 

티베로는 효율적 리소스 활용을 위해 스레드기반으로 작업을 수행한다

초기화 파라메터 MAX_SESSION_COUNT에서 설정된 개수만큼 워커스레드를 구성하게 되는데 MAX_SESSION_COUNT 파라메터 값을 아래 사진처럼 확인할 수 있다.

 

 

다음과 같이 MAX_SESSION_COUNT 값이 20인 경우, 20개의 워커스레드가 구동 가능함을 의미한다.

각각의 워커스레드는 세션을 위해 동작하며 티베로는 세션마다 1개씩의 워커 스레드를 할당한다.

 

MAX_SESSION_COUNT 값이 20이므로, 위 사진과 같이 WP000, WP001로 두개의 워크 프로세스를 확인할 수 있는데, 각각의 워크 프로세스 안에는 컨트롤 스레드 한개와 열개의 워크스레드가 존재한다.

 

ps -ATef | awk '{if($9-/tbsvr_WP/ && $9!="awk") print $0}'

워커스레드는 클라이언트와 1대1 통신하며, 클라이언트가 보내는 SQL 메시지를 받아 처리하고, 그 결과를 돌려주는 역할을 수행한다.

 

주로 SQL 파싱, 최적화 수행 등 DBMS가 하는 작업 대부분이 워커 프로세스에서 일어난다.

 

그리고 워커스레드는 하나의 클라이언트와 접속하므로 최대 세션이 생성될 수 있는 갯수는 워커스레드 갯수와 같다.

 

워커스레드는 클라이언트와 접속이 끊겨도 없어지지 않으며 티베로가 기동될 때 생성된 이후부터 종료될 때까지 계속 존재하게 된다.

 

이런 구조는 클라이언트와 접속을 빈번하게 발생시키더라도 매번 스레드를 생성하거나 제거하지 않으므로 전반적인 시스템의 성능을 높일 수 있다.

 

리스너 프로세스 (Listener Process)

---

ps -ef | awk '{if($8-/tblistener/ && $8!="awk") print $0}'

위 커맨드를 사용해 리스너 프로세스를 조회할 수 있다.

 

리스너는 클라이언트의 새로운 접속 요청을 받아 이를 유효한 워커 프로세스에 할당하는 역할을 수행한다.

즉, 클라이언트와 워커 프로세스간의 중개 역할을 담당하는것이다.

 

tblistener는 인스턴스 기동 시 생성되며, 인스턴스 다운 시 종료된다. 그리고 외부에서 프로세스클린 명령으로 강제종료 되더라도 다시 생성되는 특성을 갖는다.

 

리스닝 포트 설정 및 확인

리스너가 리스닝 하는 포트는 파라미터 파일에 리스너 포트 파라메터로 설정할 수 있다.

 

config 파일의 LISTENER_PORT 가 8629로 설정된것을 확인할 수 있고, 아래 명령어를 통해 리스너가 해당 포트를 리스닝하고있는지 확인할 수 있다.

netstat -na | grep $(grep LISTENER_PORT $TB_HOME/config/$TB_SID.tip | cut -d"_" -f2)

 

백그라운드 프로세스 (Background Process)

---

ps -ef | awk '{if(($8=="tbsvr"||$8-/RECO/||$8-/PEP/||$8-/TBMP/||$8-/AGNT/||$8-/DBWR/)&&$8!="awk") print $0}'

백그라운드 프로세스를 조회는 위 명령어를 통해 할 수 있다.

 

백그라운드 프로세스는 클라이언트의 작업 요청을 직접 받지 않고 워크스레드나 다른 백그라운드 프로세스의 요청이나 정해진 주기에 따라 동작하는 특징을 갖는다.

 

위와 같이 모니터(감시) 프로세스, 매니저 프로세스, 병렬처리 프로세스, 에이전트 프로세스, 데이터베이스 쓰기 복구 프로세스로 구성된다.

 

모니터 프로세스 (감시)

tbsvr은 감시 프로세스 mproc 이다.

티베로가 기동할 때, 최초로 생성되며 티베로가 종료하면 맨 마지막으로 프로세스를 종료한다.

 

티베로를 포함할 때, 리스너를 포함한 다른 프로세스를 생성하거나 주기적으로 각 프로세스의 상태를 점검하는 역할을 담당하며 또한 교착상태도 검사하는 역할을 수행한다

ps -ef | awk '{if($8!=="tbsvr") print $0}'

위 명령어를 통해 모니터 프로세스를 확인할 수 있다.

 

병렬처리 프로세스

일반적인 경우, 세션당 한개의 워커스레드가 할당되어 SQL을 수행하지만 패러럴 힌트 등을 사용한 병렬쿼리 수행 시 병렬처리 프로세스의 스레드가 추가되어 병렬 수행을 처리한다.

ps -ef | awk '{if($8-/tbsvr_PEP/ && $8!="awk") print $0}'

위 명령어를 통해 병렬처리 프로세스를 확인할 수 있다.

 

에이전트 프로세스

시스템 유지를 위해 주기적으로 처리해야하는 티베로 내부의 작업을 담당한다.

잡에 등록된 내용이 있다면 에이전트 프로세스가 이를 확인하여 수행이 필요한 시점에 워커 스레드를 할당하여 잡이 수행될 수 있도록 처리한다.

ps -ef | awk '{if($8-/tbsvr_AGNT/ && $8!="awk") print $0}'

위 명령어를 통해 에이전트 프로세스를 확인할 수 있다

 

데이터베이스 쓰기 프로세스

데이터베이스에서 변경된 내용을 디스크에 기록하는 일과 연관된 쓰레드들이 모여있는 프로세스이다.

사용자가 변경한 블록의 디스크에 주기적으로 기록하는 스레드, 리두로그를 디스크에 기록하는 스레드, 데이터베이스의 체크포인트 과정을 관할하는 체크포인트 스레드 등이 이 프로세스에 포함되어있다.

 

ps -ef | awk '{if($8-/tbsvr_DBWR/ && $8!="awk") print $0}'

위 명령어를 통해 데이터베이스 쓰기 프로세스를 확인할 수 있다

 

복구 프로세스

복구 프로세스는 비정상 종료 등 인스턴스 크래시가 발생하며 티베로가 다운된 이후 티베로를 재기동할 때 인스턴스 복구를 수행한다.

복구 과정은 리두로그를 이용하여 복구하는 캐시 리커버리, 언두 데이터를 통한 트랜잭션 리커버리 등 2단계에 거쳐 자동 수행되며 캐시 리커버리가 완료되어야 로그인 및 SQL 수행이 가능하며 백그라운드로 트랜잭션 리커버리가 수행된다.

 

 

티베로 인스턴스가 사용하는 메모리의 구조

---

위 사진과 같이 파라미터 파일에 세팅하며 이를 통해 설정된 값을 인스턴스에 할당받게 된다.

SELECT VALUE/1024/1024/1024 "VALUE(GB)" 
    FROM V$PARAMETERS
    WHERE NAME='MEMORY_TARGET';

티베로 인스턴스가 사용하는 전체 메모리 공간의 크기는 위 쿼리로 확인할 수 있다.

 

티베로 인스턴스가 사용하는 전체 메모리 공간의 크기는 MEMORY_TARGET 파라메터로 설정되며 이 공간은 다시 두가지 종류의 영역으로 나뉘어지는데, 프로세스들이 개별적으로 사용하는 메모리 공간과 공유하는 정보를 저장하는 메모리 공간이 있다.

 

프로세스들이 공유하는 메모리 공간은 TOTAL_SHM_SIZE 파라메터로 설정하며 프로세스들이 개별적으로 사용하는 메모리 공간은 (MEMORY_TARGET)- (TOTAL_SHM_SIZE) 크기를 할당하게 된다.

 

프로세스들이 공유하는 메모리 공간

COL "Size(MB)" FOR A10
SELECT NAME, ROUND(TOTAL/1024/1024)||'MB' "Size(MB)"
    FROM V$SGA
    WHERE NAME IN('FIXED MEMORY', 'SHARED POOL MEMORY');

TOTAL_SHM_SIZE 파라미터로 설정되는 프로세스들이 공유하는 메모리 공간은 FIXED MEMORY 영역과 SHARED POOL MEMORY 영역으로 나누어지며 위 쿼리로 그 크기를 조회할 수 있다.

 

FIXED MEMORY 영역은 데이터 블록을 저장하는 DB 캐시와 리두로그 버퍼 등을 포함하고 있다.

 

SHARED POOL MEMORY 영역은 실행된 SQL을 저장하는 라이브러리 캐시, 데이터베이스 딕셔너리 정보를 저장하는 딕셔너리 캐시 등으로 구성되고, 라이브러리 캐시에는 SQL 수행시 소프트파싱시 필요한 SQL 문장, PSM 문장 및 해당 B코드, 실행계획등이 저장되며 LRU알고리즘으로 관리된다.

 

데이터베이스를 구성하는 파일

---

데이터베이스는 크게 3가지 종류의 파일들로 구성된다.

• 데이터 파일
• 로그 파일
• 컨트롤 파일

데이터 파일

테이블 및 인덱스는 특정한 테이블 스페이스에서 데이터를 저장하며 테이블 스페이스는 1개 이상의 데이터 파일과 연결되어 있는데 데이터파일은 테이블스페이스에게 데이터 저장공간을 제공하는 역할을 수행하며 그 크기는 설정된 일정한 크기 또는 AUTOEXTENSIBLE 설정에 따라 MAXBYTES까지 자동으로 크기가 증가한다.

로그 파일

데이터의 변경 시 티베로는 변경 이력을 별도로 저장하여 나중에 복구가 필요한 경우 이를 활용하고 있다.

 

이를 리두로그라 부르며 리두로그는 여러개의 그룹으로 구성되고 그룹마다 한개 이상의 로그파일을 설정하여 리두로그를 저장하게 된다.

 

리두로그는 모든 리두로그 그룹을 순차적으로 사용하며 저장되며 모든 리두로그 그룹을 사용한 이후 처음 사용한 그룹을 재사용하여 리두로그를 계속 기록하게 된다.

이때, 기존의 리두로그는 제거되며 새로운 리두로그가 기록된다.

 

이렇게 순환하며 리두로그 그룹을 사용하는 동작으로 과거의 리두로그가 제거되는데 티베로는 이를 보존하기 위한 아카이브 로그 모드 기능을 제공한다.

 

아카이브 로그 모드 기능 설정시, 리두로그는 리두로그 그룹에 대한 로그 스위치 동작을 할 때마다 아카이브 로그 DSP 파라메터에서 설정한 경로에 기존 리두로그를 복사하는 동작을 수행한다.

컨트롤 파일

컨트롤 파일은 바이너리 형태의 파일로써 데이터베이스에 대한 여러가지 메타 정보를 저장하고 있으며 인스턴스가 데이터 파일이나 로그 파일을 인식하기 위해 우선 컨트롤 파일을 오픈하여 컨트롤 파일에 담긴 데이터파일, 로그 파일 정보를 읽는 동작을 수행하는 등 유저 데이터를 직접적으로 저장하지는 않지만 중요한 역할을 수행하는 파일이다.

 

컨트롤 파일에는 각 데이터 파일들로 최종 저장된 tsn(?) 번호를 갖고있는데, 데이터파일을 오픈할 때 유효성 여부를 검증하는 용도로 사용하기도 하며, 나중에 데이터 파일 손상시 복구 작업을 위해서도 사용된다.

 

그리고 컨트롤 파일에는 테이블 스페이스 관련 정보, 아카이브 로그 정보, 백업 복구 유틸리티인 RMGR의 백업 셋 관련 정보도 기록된다.

 

컨트롤 파일은 1개 또는 장애를 대비하여 다중화하여 사용할 수 있다.

티베로 데이터베이스를 이용하기 위한 인터페이스

어플리케이션에서 티베로 데이터베이스를 이용하기 위해선 위 경로에서 드라이버를 사용한다.