Tibero 소개
Tibero의 주요 기능과 프로세스 구조, 디렉터리 구조를 간단히 소개합니다.
개요
현재 기업의 비즈니스는 폭발적인 데이터의 증가와 다양한 환경 및 플랫폼의 등장으로 빠르게 확장되고 있습니다. 새로운 비즈니스 환경이 도래함에 따라 보다 더 효율적이고 유연한 데이터 서비스와 정보의 처리, 데이터 관리 기능이 필요하게 되었습니다.
Tibero는 이러한 변화에 맞춰 기업 비즈니스 구현의 기반이 되는 데이터베이스 인프라 구성을 지원하며 고성능, 고가용성 및 확장성의 문제를 해결하는 엔터프라이즈 데이터베이스 관리 시스템입니다.
기존 DB의 단점을 보완하기 위해 Tibero는 독자적인 Tibero Thread Architecture를 채택하고 구현하였다. 한정된 서버 프로세스의 CPU 및 메모리 등의 시스템 리소스를 효율적으로 사용하면서 뛰어난 성능과 안 정성 및 확장성을 보장하고 편리한 개발 환경과 관리 기능을 제공합니다. Tibero는 초기 설계부터 대규모 사용자, 대용량 데이터, 강화된 안정성, 향상된 호환성 측면 등에서 다른 DBMS와 차별화를 고려하여 개발되었습니다.
Tibero는 이처럼 기업이 원하는 최적의 데이터베이스 환경을 제공하는 대표적인 DB입니다.
주요 기능
대용량의 데이터를 관리하고 안정적인 비즈니스의 연속성을 보장하는 데이터 관리 솔루션인 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에 포함하여 제 공하고 있습니다. 보다 자세한 내용은 "Tibero 관리자 안내서"의 "제15장 Tibero Active Cluster"를 참고합니다.
병렬 쿼리 처리(Parallel Query Processing) 기업의 데이터 크기는 계속적으로 증가하고 있습니다. 대용량 데이터를 처리하기 위해 서버의 리소스를 최 대한 활용할 수 있는 병렬 처리 기술이 필수적으로 요구되고 있습니다. Tibero는 이러한 요구사항에 맞추어 온라인 트랜잭션 처리(On-Line Transaction Processing, 이하 OLTP) 환경에 최적화된 기능을 제공할 뿐만 아니라 OLAP(On-Line Analytical Processing) 환경에 최적화된 SQL 병렬 처리 기능을 제공하고 있습니다. 이로 인해 쿼리는 빠른 응답 속도로 수행되며 기업의 빠른 의사 결정을 돕습니다.
쿼리 최적화기(Optimizer) 쿼리 최적화기는 스키마 객체의 통계 정도를 바탕으로 다양한 데이터 처리 경로들을 고려하여 어떤 실 행 계획이 가장 효율적인지를 결정합니다. 쿼리 최적화기는 논리적으로 다음과 같은 단계를 통해 수행됩니다.
주어진 SQL 문을 처리하는 다양한 실행 계획들을 만들어 냅니다.
데이터의 분산도에 대한 통계 정보와 테이블, 인덱스, 파티션 등의 특징을 고려하여 각각의 실행 계 획의 비용을 계산합니다. 여기서 비용이란 특정 실행 계획을 수행하는 데 필요한 상대 시간을 나타내고, 최적화기는 I/O, CPU, 메모리 등의 컴퓨터 자원을 고려하여 그 비용을 계산해 냅니다.
실행 계획들의 비용을 비교하여 가장 비용이 작은 계획을 선택합니다.
쿼리 최적화기의 주요 기능은 다음과 같습니다.
최적화 목표 사용자는 최적화기의 최종 목표를 바꿀 수도 있는데 다음의 두 가지 목표를 선택할 수 있습니다.
전체 처리 시간
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 로그가 먼저 내려가서 데이터베이스 전체가 일관성을 지니 게 합니다.
Row level locking
Tibero는 fine-grained lock control을 보장해 주기 위하여 row level locking을 사용합니다. 즉, 데이터 최소 단 위인 Row 단위의 locking을 통하여 최대한의 concurrency를 보장해 준다. 많은 Row들을 수정합니다고 해도 테이블에 lock이 걸려서 concurrent한 DML이 수행되지 못하는 상황은 발생하지 않습니다. 이러한 기법을 통 해 OLTP 환경에서 더욱 강력한 성능을 발휘하고 있습니다.
프로세스 구조
Tibero는 대규모 사용자 접속을 수용하는 다중 프로세스 및 다중 스레드 기반의 아키텍처를 갖추고 있습니다. 다음은 Tibero의 프로세스 구조를 나타내는 그림입니다.
[그림 1] 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 참조 안내서"를 참고합니다.
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가 기동될 때 초기화 파라미터에 설정된 수만큼 워커 스레드를 생성합니다.
클라이언트의 새로운 접속 요청이 오면 현재 유휴한 워커 스레드에 클라이언트의 접속을 할당합니다.
시그널 처리를 담당합니다.
Tibero 6부터 I/O multiplexing을 지원하며 필요한 경우 워커 스레드 대신 메시지를 보내거나 받는 역 할을 수행합니다.
워커 스레드
워커 스레드는 클라이언트와 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라는 명칭을 사용했으나 Tibero
6부터 AGNT로 명칭이 변경되었습니다. 시퀀스를 사용하는 방법은 "Tibero 관리자 안내서"의 "4.7.1. 시퀀스 생성, 변경, 제거"를 참고합니다.
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과 분리되어 모니터링 및 관리가 용이합니다.
디렉터리 구조
Tibero가 설치되면 다음과 같은 디렉터리가 생성됩니다.
위의 디렉터리 구조에서 $TB_SID라고 보이는 부분은 각각의 시스템 환경에 맞는 서버의 SID로 바꿔서 읽어야 합니다.
Tibero에서 사용하는 기본 디렉터리는 다음과 같습니다.
bin
Tibero의 실행 파일과 서버 관리를 위한 유틸리티가 위치한 디렉터리입니다. 이 디렉터리에 속한 파일 중에서 tbsvr과 tblistener는 Tibero를 구성하는 실행 파일이며, tbboot와 tbdown은 각각 Tibero를 기동하고 종료하는 역할을 담당합니다. tbsvr과 tblistener 실행 파일은 반드시 tbboot 명령어를 이용하여 실행되어야 하며, 절대로 직접 실행해서는 안 됩니다.
client
다음은 하위 디렉터리에 대한 설명입니다.
bin
Tibero의 클라이언트 실행 파일이 있는 디렉터리
이 디렉터리에는 다음과 같은 유틸리티가 있음
tbSQL : 기본적인 클라이언트 프로그램으로 사용자가 직접 SQL 질의를 하고 그 결과를 확인할 수 있음
T-Up : 다른 데이터베이스에서 Tibero로의 호환성 평가와 마이그레이션을 지원
tbExport : 논리적 백업이나 데이터베이스 간에 데이터를 이동을 위해 데이터베이스의 내용을 외부 파일로 저장
tblImport : 외부 파일에 저장된 내용을 데이터베이스로 가져옴
tbpc : C 언어로 작성된 프로그램 안에서 내장 SQL(Embedded SQL)을 사용하는 프로그램을 개발할 때 이를 C 프로그램으로 변환. 이렇게 변환된 프로그램은 C 컴파일러를 통해 컴파일할 수 있도록 도와주는 역할을 담당.
유틸리티에 대한 내용은 “Tibero 유틸리티 안내서”를 참고
단, tbpc 유틸리티는 “Tibero tbESQL/C 안내서”를 참고
config
Tibero의 클라이언트 프로그램을 실행하기 위한 설정 파일이 위치하는 디렉터리
include
Tibero의 클라이언트 프로그램을 작성할 때 필요한 헤더 파일이 위치하는 디렉터리
lib
Tibero의 클라이언트 프로그램을 작성할 때 필요한 라이브러리 파일이 위치하는 디렉터리
자세한 내용은 “Tibero 애플리케이션 개발자 안내서”와 “Tibero tbESQL/C 안내서”를 참고
epa
External Procedure와 관련된 설정 파일과 로그 파일이 있는 디렉터리
이에 대한 자세한 내용은 “Tibero External Procedure 안내서”를 참고
config
Tibero의 환경설정 파일이 위치하는 디렉터리입니다. 이 위치에 존재하는 $TB_SID.tip 파일이 Tibero의 환경설정을 결정합니다.
database
다음은 하위 디렉터리에 대한 설명입니다.
$TB_SID Tibero의 데이터베이스 정보를 별도로 설정하지 않는 한 모든 데이터베이스 정보가 이 디렉터리와 그 하위 디렉터리에 저장됩니다. 이 디렉터리에는 데이터 자체에 대한 메타데이터(metadata)뿐만 아니라 다음과 같은 종류의 파일이 있습니다.
컨트롤 파일
다른 모든 파일의 위치를 담고 있는 파일
데이터 파일
실제 데이터를 저장하고 있는 파일
로그 파일
데이터 복구를 위해 데이터에 대한 모든 변경 사항을 저장하는 파일
$TB_SID/java JAVA_CLASS_PATH가 정의되지 않은 경우 Java EPA Class File이 저장되는 디렉터리입니다.
instance
다음은 하위 디렉터리에 대한 설명입니다.
$TB_SID/out Tibero의 프로세스에서 로그를 남길 수 없는 특정 상황에 현재 상황에 대한 정보를 남기는 파일들이 남는 디렉터리입니다. 해당 파일에 남는 내용은 매우 중요한 정보이기에 Tibero가 운영 중일 때 이 위 \치에 존재하는 파일을 읽거나 수정하지 않는 것을 권장합니다. 리스너 프로세스의 것은 하위 디렉터 리 "/lsnr"에, 일반 프로세스의 것은 "/svr"에 남는다.
$TB_SID/log Tibero의 시스템 로그 파일(slog)과 DBMS 로그(dlog), Internal 로그(ilog), Listener 로그(lsnr), 메모 리 로그 등의 로그 파일이 저장되는 디렉터리입니다.
Activity 로그 파일(act)
서버 내 액티비티 모니터에서 타 쓰레드들의 동작을 점검하던 도중, 임의의 쓰레드가 장기간 멈춰 있음을 감지하였을 때 남기는 로그 파일
장기간 동작하지 않는 쓰레드의 원인 분석에 사용될 수 있음
AUDIT 로그 파일(audit)
데이터베이스 사용자가 시스템 특권 또는 스키마 객체 특권을 사용하는 것을 감시(AUDIT)한 내용을 기록한 파일
Diagnostic 로그 파일(diag)
TAC의 diag 기능을 사용하는 경우, 글로벌 노드 간 지연 현상이 감지되었을 때 문제 현상에 대한 대략적인 정보를 남기는 로그 파일
글로벌 노드 상에서 발생한 지연 현상의 원인을 분석하는 데에 사용될 수 있음
DBMS 로그 파일(dlog)
시스템 로그 파일에 기록되는 정보보다 좀 더 중요한 정보가 기록되는 파일이며, 서버 기동 및 종류, DDL 문장의 수행 등이 기록되는 파일
Internal 로그 파일(ilog)
스레드별로 설정된 이벤트에 대한 시스템 로그가 기록되는 파일이며, In ternal 로그를 보려면 tbiv를 이용해야 함
Listener 로그 파일(lsnr)
Listener의 디버깅을 위한 파일
리스너에서 일어난 중요한 일이 기록 되는 파일이며, 리스너의 버그를 해결하는 데 사용될 수 있음
시스템 로그 파일(slog)
디버깅을 위한 파일
서버가 하는 중요한 일이 기록되는 파일이며, 서버 성능이 저하되는 원인을 찾거나 Tibero 자체의 버그를 해결하는 데 사용될 수 있습니다.
SQLTRACE 로그 파일(sql trace)
세션에서 수행된 SQL들에 대한 정보를 남기는 로그 파일
SQL의 성능을 분석하거나 버그의 원인을 파악하는데에 사용될 수 있음
Memory 로그 파일(memlog)
임의의 세션이 부득이한 문제로 강제 종료되는 경우, 해당 세션에서 남길 예정이었던 시스템 로그들을 남기는 파일
문제가 발생한 세션을 분석하는 데에 사용될 수 있음
시스템 로그 파일, DBMS 로그 파일, Internal 로그 파일, Listener 로그 파일을 비롯한 로그 파일들 은 데이터베이스를 사용할수록 계속 누적되어 저장됩니다. 지속되는 누적으로 인한 디스크 포화 상태 를 방지하고, 성능 향상 및 최적화된 사용자 경험을 제공하기 위해 각 파일의 최대 크기와 전체 디렉터리의 최대 크기를 파라미터으로 조정할 수 있도록 되어있습니다.
예외적으로, SQLTRACE 로그 파일과 Memory 로그 파일들의 경우는 해당 로그들의 취지에 맞게 각 파일의 크기를 제한하는 것이 아니라 디렉터리 내 존재하는 파일들의 크기의 합을 파라미터를 통해 제한할 수 있습니다. 해당 값을 넘어가는 경우 파일들을 별도의 하위 디렉터리에 보관하고, 이 하위 디렉터리의 최대 개수를 파라미터로 제한하여 최댓값을 넘는 경우 오래된 디렉터리를 삭제하도록 설정할 수 있습니다.
로그 파일을 설정하는 초기화 파라미터는 다음과 같습니다.
AUDIT_LOG_FILE_SIZE
Audit 로그 파일 하나의 최대 크기를 설정
AUDIT_LOG_TOTAL_SIZE_LIMIT
Audit 로그 파일이 저장된 디렉터리의 최대 크기를 설정
ACT_LOG_FILE_SIZE
Activity 로그 파일 하나의 최대 크기를 설정
ACT_LOG_TOTAL_SIZE_LIMIT
Activity 로그 파일이 저장된 디렉터리의 최대 크기를 설정
DIAG_LOG_FILE_SIZE
Diagnostic 로그 파일 하나의 최대 크기를 설정
DIAG_LOG_TOTAL_SIZE_LIMIT
Diagnostic 로그 파일이 저장된 디렉터리의 최대 크기를 설정
DBMS_LOG_FILE_SIZE
DBMS 로그 파일 하나의 최대 크기를 설정
DBMS_LOG_TOTAL_SIZE_LIMIT
DBMS 로그 파일이 저장된 디렉터리의 최대 크기를 설정
ILOG_FILE_SIZE
Internal 로그 파일 하나의 최대 크기를 설정
ILOG_TOTAL_SIZE_LIMIT
Internal 로그 파일이 저장된 디렉터리의 최대 크기를 설정
LSNR_LOG_FILE_SIZE
Listener 로그 파일 하나의 최대 크기를 설정
LSNR_LOG_TOTAL_SIZE_LIMIT
Listener 로그 파일이 저장된 디렉터리의 최대 크기를 설정
SLOG_FILE_SIZE
시스템 로그 파일 하나의 최대 크기를 설정
SLOG_TOTAL_SIZE_LIMIT
시스템 로그 파일이 저장된 디렉터리의 최대 크기를 설정
SQL_TRACE_TOTAL_SIZE_LIMIT
SQL_TRACE_DEST 내에 존재하는 파일들 크기의 합의 상한을 설정 (하위 디렉터리의 크기는 제외)
SQL_TRACE_BACKUP_LIMIT_CNT
SQLTRACE 로그 파일들이 보관되어있는 하위 디렉터리의 최대 개수를 설정
값을 넘는 경우, 가장 오래된 하위 디렉터리부터 디렉터리 째로 삭제됨
MEM_LOG_TOTAL_SIZE_LIMIT
MEM_LOG_DEST 내에 존재하는 파일들 크기의 합의 상한을 설정(하위 디렉터리의 크기는 제외)
MEM_LOG_BACKUP_LIMIT_CNT
Memory 로그 파일들이 보관되어있는 하위 디렉터리의 최대 개수를 설정
값을 넘는 경우, 가장 오래된 하위 디렉터리부터 디렉터리 째로 삭제
$TB_SID/dump
Tibero의 DDL 또는 실행 중 에러에 의해 발생하는 덤프 파일이 저장되는 디렉터리입니다.
act
서버 내 액티비티 모니터에서 타 쓰레드들의 동작을 점검하던 도중, 임의의 쓰레드가 장기간 멈춰 있음을 감지하였을 때, 남기는 덤프 파일들의 디렉터리
덤프 파일 내에는 대상 쓰레드의 함수 호출 스택 정보가 남음
callstack
DDL dump 명령 혹은 서버 내 요청으로 인한 콜스택 덤프 시, tstack 스레드에서 대상 쓰레드들의 함수 호출 스택 정보를 파일 형태로 남기는 디렉터리
diag
TAC의 diag 기능을 사용하는 경우, 글로벌 노드 간 지연 현상이 감지되었을 때 문제 현상에 대한 자세한 정보를 남기는 덤프 파일들의 디렉터리
덤프 파일 들에는 관련 쓰레드들의 함수 호출 스택 정보, 관련 쓰레드들의 자원 획득 및 경 쟁에 대한 정보들이 남음
report
DB 성능 측정을 위해 DDL 혹은 TPR 패키지를 이용하여 TPR report를 생성하였 을 때 만들어 지는 파일들의 디렉터리
tracedump
DB 내 문제 상황에 대한 다양한 디버깅 정보들을 가진 덤프 파일들의 디렉터리
문제가 발생하는 동작에서 저절로 덤프가 남는 경우도 있고, DDL dump 명 령을 통해 남는 경우도 있
Activity 덤프, Diagnostic 덤프, Callstack 덤프, Tracedump 덤프 파일의 경우 데이터베이스를 사용 할수록 계속 누적되어 저장될 수 있습니다. Tibero는 성능 향상 및 최적화된 사용자 경험을 제공하고, 지속되는 덤프 파일 누적으로 인한 디스크 포화 상태를 예방하기 위해 디렉터리 내 존재하는 파일들 의 크기의 합을 파라미터를 통해 제한할 수 있습니다.
해당 값을 넘어가는 경우 파일들을 별도의 하위 디 렉터리에 보관하며, 이와 더불어 별도의 파라미터를 통해 하위 디렉터리들의 최대 개수를 제한하여 최댓값을 넘는 경우 오래된 디렉터리를 삭제하도록 설정할 수 있습니다. (TPR의 경우는 사용자 요청으 로만 파일이 생성되기 때문에 자동으로 관리하지 않습니다.)
ACT_DUMP_TOTAL_SIZE_LIMIT
ACT_DUMP_DEST 내에 존재하는 파일들 크기의 합의 상한을 설정 (하위 디렉터리의 크기는 제외)
ACT_DUMP_BACKUP_LIMIT_CNT
Activity 덤프 파일들이 보관되어있는 하위 디렉터리의 최대 개수를 설정
값을 넘는 경우, 가장 오래된 하위 디렉터리부터 디렉터리째로 삭제
CALLSTACK_DUMP_TOTAL_SIZE_LIMIT
CALLSTACK_DUMP_DEST 내에 존재하는 파일들 크기의 합의 상한을 설정 (하위 디렉터리의 크기는 제외)
CALLSTACK_DUMP_BACKUP_LIMIT_CNT
Callstack 덤프 파일들이 보관되어있는 하위 디렉터리의 최대 개수를 설정
값을 넘는 경우, 가장 오래된 하위 디렉터리부터 디렉터리째로 삭제됨
DIAG_DUMP_TOTAL_SIZE_LIMIT
DIAG_DUMP_DEST 내에 존재하는 파일들 크기의 합의 상한을 설정 (하위 디렉터리의 크기는 제외)
DIAG_DUMP_BACKUP_LIMIT_CNT
Diagnostic 덤프 파일들이 보관되어있는 하위 디렉터리의 최대 개수를 설정
값을 넘는 경우, 가장 오래된 하위 디렉터리부터 디렉터리째로 삭제됨
TRACE_DUMP_TOTAL_SIZE_LIMIT
TRACE_DUMP_DEST 내에 존재하는 파일들 크기의 합의 상한을 설정 (하위 디렉터리의 크기는 제외)
TRACE_DUMP_BACKUP_LIMIT_CNT
TRACEDUMP 덤프 파일들이 보관되어있는 하위 디렉터리의 최대 개수를 설정
값을 넘는 경우, 가장 오래된 하위 디렉터리부터 디렉터리째로 삭제됨
TB_SID/path
Tibero의 프로세스 간에 통신을 위한 소켓 파일이 있는 디렉터리입니다. Tibero가 운영 중일 때 이 위 치에 존재하는 파일을 읽거나 수정해서는 안 됩니다.
lib
Tibero 서버에서 Spatial과 관련된 함수를 사용하기 위한 라이브러리 파일이 있는 디렉터리입니다.
license
Tibero의 라이선스 파일(license.xml)이 있는 디렉터리입니다. XML 형식이므로 일반 텍스트 편집기로도 라이선스의 내용을 확인할 수 있습니다.
다음은 하위 디렉터리에 대한 설명입니다.
oss_licenses
반드시 준수해야 하는 오픈소스 라이선스의 대한 정보를 확인할 수 있는 디 렉터리
nls
다음은 하위 디렉터리에 대한 설명입니다.
zoneinfo
Tibero에서 사용하는 시간대 파일이 있는 디렉터리
scripts
Tibero의 데이터베이스를 생성할 때 사용하는 각종 SQL 문장이 있는 디렉터리입니다. 또한 Tibero의 현재 상태를 보여주는 각종 뷰의 정의도 이 디렉터리에 있습니다.
다음은 하위 디렉터리에 대한 설명입니다.
pkg
Tibero에서 사용하는 패키지의 생성문이 저장되는 디렉터리
dpv
Tibero에서 사용하는 동적 성능 뷰 생성문이 저장되는 디렉터리
sample_user
예제 실행을 위해 제공되는 샘플 유저 생성문이 저장되는 디렉터리
catalogview
Tibero에서 사용하는 카탈로그 뷰 생성문이 저장되는 디렉터리
catalogview_using_dpv
Tibero에서 사용하는 동적 성능 뷰를 참조하는 카탈로그 뷰 생성문이 저장되는 디렉터리
Last updated