SysMaster DB 에서 관제 데이터베이스 등록 시 유저 정보를 입력하게 된다. 기존에 생성된 유저를 사용할 수 있고, 새로운 유저를 생성해 사용할 수도 있다. 이때 유저에게 필요한 권한은 CONNECT, ALTER SYSTEM, SELECT_CATALOG_ROLE이다. 유저 생성 및 권한 부여는 SYS 계정에서 아래 DDL 및 DCL 문을 사용한다.
추가로 TPR Report, ASH Report 기능을 사용하려면 아래 DCL 문을 사용하여 관련 권한을 부여해야 한다.
참고
SysMasterDB 8.3은 관제 데이터베이스에 테이블 생성이나 데이터 적재를 하지 않는다.
2. libtpmstat.so 라이브러리
TPM Agent에서 Tibero로부터 정보를 수집하기 위해서는 libtpmstat 라이브러리가 필요하다.
관제 데이터베이스에 279651 패치가 적용되어 libtpmstat 라이브러리가 있는 경우에는 Tibero 환경 변수 설정 과정을 통해 해당 라이브러리를 사용할 수 있다.
만약 관제 데이터베이스에 libtpmstat 라이브러리가 없는 경우에는 해당 데이터베이스에 맞는 라이브러리를 추가로 배포해야 한다. 이때 배포된 libtpmstat.so 파일을 TPM Agent 디렉터리로 이동시킨 후 TPM Agent 라이브러리 경로 설정을 통해 해당 라이브러리를 사용할 수 있다.
참고
libtpmstat.so 라이브러리 파일의 배포를 위하여 관제 데이터베이스 패치 목록과 정확하게 동일한 패치가 되어있는 관제 데이터베이스 빌드를 통하여 libtpmstat.so 빌드를 해야 한다. 예를 들어, Tibero 6에 [1번 패치], [2번 패치], [3번 패치] 세 개의 패치가 되어 있는 곳과 [1번 패치], [3번 패치] 두 개의 패치가 되어 있는 곳이 있다면, [1번 패치], [2번 패치], [3번 패치]가 적용된 Tibero에서 빌드한 libtpmstat.so 파일과 [1번 패치], [3번 패치]가 적용된 Tibero에서 빌드한 libtpmstat.so 파일 두 개 모두 각각 빌드해서 배포해야 한다.
추가로 libtpmstat.so 라이브러리 빌드 시, Tibero 바이너리 빌드 시 적용하였던 모든 빌드 플래그들을 동일하게 적용하여 라이브러리 빌드를 진행하여야 한다. 예를 들어 NET_BACKUP 빌드 플래그를 적용하여 Tibero 바이너리를 빌드하여 배포했다면, 라이브러리 배포 시에도 해당 플래그를 넣고 libtpmstat.so 라이브러리 빌드를 진행하여야 한다.
sysmasterdb8-sdm-container가 생성되면, 해당 컨테이너 내 sysmaster/license 경로 하위에 발급받은 라이선스 파일을 배치한다. 라이선스 파일명은sysmaster-db-license.xml 이며, 변경 불가능하다.
부팅이 완료된 이후에 로그인과 프로그램 사용이 가능하다. 부팅 완료는 SDM 로그에서 아래와 같은 로그를 통해 확인할 수 있다.
기본적으로 각 모듈들의 pod 내 컨테이너에 접속하여 해당 모듈의 log 파일을 볼 수 있다. SysMaster DB 모듈들은 동일하게 각 컨테이너 내 아래 경로에 로그가 적재된다.
추가로, 사용자의 편의를 위하여 로그 확인 전용 컨테이너를 생성하여 활용할 수 있다.
배포 파일 구성에 포함된 client-deployment.yaml 파일에 정의된 sysmasterdb8-client-pod 내에, 로그 확인 전용 컨테이너인 sysmasterdb8-log-container가 정의되어 있다. 사용자는 해당 컨테이너 내 로그 디렉터리 경로(/sysmaster/logs)를 통해 모든 SysMaster DB 모듈의 로그를 확인할 수 있다.
설치 파일이 위치한 디렉터리에서 아래와 같은 순서로 명령을 수행하면 SysMaster DB 가 종료된다. 이때 SysMaster DB 를 종료해도 Repository DB와 Meta DB의 데이터 파일은 유지되므로, SysMaster DB 를 다시 기동하면 이전에 저장한 데이터를 사용할 수 있다.
아래의 명령을 수행하면 모든 데이터가 삭제되고, 최초 설치 상태와 동일하게 동작한다. 단, 이전에 저장한 데이터는 사용할 수 없다.
기동 / 로그 확인 / 종료 / 초기화
Docker-compose 및 Podman-compose 환경에서 SysMaster DB 8.3를 기동, 로그 확인, 종료, 초기화하는 방법이다.
1. 기동
1.1. SysMaster DB 환경 변수 설정
export SYSMASTERDB_HOME={SysMasterDB_Home_Path}
인자
설명
{SysMasterDB_Home_Path}
docker-compose.yml 파일이 위치한 디렉터리 경로
1.2. SYSMASTERDB_HOME을 PATH에 추가
export PATH=$PATH:$SYSMASTERDB_HOME
1.3. 라이선스 파일 세팅
지정된 경로 하위에 발급받은 라이선스 파일을 배치한다. 라이선스 파일명과 경로는 아래와 같으며, 변경 불가능하다.
라이선스 파일명
sysmaster-db-license.xml
라이선스 경로
$SYSMASTERDB_HOME 경로 하위에 license 디렉토리가 존재하지 않는 경우, 해당 디렉토리를 직접 생성해준 후 라이선스 파일(sysmaster-db-license.xml)을 넣어주면 된다.
부팅이 완료된 이후에 로그인과 프로그램 사용이 가능하다.
부팅 완료는 SDM 로그에서 아래와 같은 로그를 통해 확인할 수 있다.
.env 파일의 로그 관련 파라미터 설정을 통해 로그가 저장될 경로를 지정할 수 있다. default 로그 경로는 ./logs이므로 docker-compose.yml 파일이 있는 디렉터리에 logs 폴더가 자동으로 생성되며, 여기서 로그 파일을 확인할 수 있다.
SysMaster DB 8.3 기동을 위한 환경 변수 및 PATH가 설정된 상태에서 아래의 명령을 수행하면 모든 서비스가 제거되고, SysMaster DB 8.3가 종료된다. 이때 SysMaster DB 8.3를 종료해도 METADB_PATH와 REPODB_PATH에 생성된 파일은 유지되므로, SysMaster DB 8.3를 다시 기동하면 종료 전과 동일하게 사용할 수 있다.
METADB_PATH와 REPODB_PATH 디렉터리를 삭제한 후 SysMaster DB 8를 다시 기동하면 최초 설치 상태와 동일하게 동작한다. 단, 이전에 저장한 데이터는 사용할 수 없다.
설치 및 파라미터 설정 - SysMaster DB 8.3 의 설치 및 파라미터 설정방법에 대해서 설명한다.
기동 / 로그 확인 / 종료 / 초기화- 기동, 로그 확인, 종료, 초기화 방법에 대해서 설명한다.
마지막으로 에서는 SysMaster DB 8.3에서 사용하는 포트들에 대해서 설명한다.
Detail Layout
Card View Detail Layout
CPU / Memory 파이 차트에 마우스를 호버하여 상세 정보를 확인할 수 있다.
Lock Waiter: 인스턴스가 락을 기다리고 있는 세션 갯수를 표시한다.
Tablespace: 사용량이 90% 이상인 테이블스페이스 갯수를 표시한다. 마우스 호버시 사용룰 내림차순으로 10개 테이블스페이스에 대해 사용 현황을 표시한다.
Running Session: 지난 5분간의 Running Session 추이를 Area 차트로 표시하며 현재 Running Session의 갯수를 우상단에 표시한다.
관제 인스턴스 DB가 다운 상태일 경우 마지막에 Normal 상태였던 시간을 표시한다.
Agent Disconnected 상태일 경우 위와 같이 표시되며 카드뷰 마지막에 정렬된다.
Alert Alarm
Alert Alarm 항목에서는 아직 Confirm 처리되지 않은 Alert들의 리스트를 나타낸다. Alert는 유저가 직접 생성한 기준에 따라 발생한 User-created 카테고리와 자동으로 설정되어 전체 인스턴스에 대해서 발생하는 System 카테고리로 나뉘어져 있다.
각 Alert에 대해 Confirm 처리를 하거나, 우상단에 Confirm All 버튼을 눌러야 Alert Event를 제거할 수 있다.
Layout 목록에서 특정 Layout의 더보기 버튼 클릭 시 제공되는 Delete 기능을 통해 기존 Layout을 삭제할 수 있다.
Temp Usage
글로벌 내비게이션 바에서 [Realtime] > [Usage Monitoring] > [Temp Usage] 를 클릭하면 Temp Usage 페이지가 열린다.
Temp Usage 페이지에서는 Session Temp 사용량 정보를 보여준다. 효율적인 실행 계획 또는 잘못 쓰여진 SQL Statement로 인하여 과도하게 Temporary Tablespace 영역을 사용하고 있는 세션을 모니터링할 수 있다.
다음은 Session Temp Usage 페이지에서 제공하는 항목에 대한 설명이다.
항목
설명
Heatmap Trend
글로벌 내비게이션 바에서 [Analysis] > [Perfomance Analysis] > [Heatmap Trend] 메뉴를 클릭하면 Heatmap Trend 화면이 열린다.
Heatmap Trend 화면에서는 선택한 인스턴스의 Resource 사용량에 대한 Overview를 확인할 수 있다. 이때 지정한 구간 동안 시간, 일자별로 Resource 사용량을 도식화하여 한눈에 확인할 수 있고, 선택한 시간의 분 단위 막대 그래프로 정밀하게 전체적인 사용량의 흐름을 알 수 있다.
참고
Heatmap의 검색 가능 구간은 10일 미만이다.
SysMasterDB Manual
안내서 정보
안내서 제목 : SysMasterDB 매뉴얼
발행일 : 2026-04-15
소프트웨어 버전 : SysMasterDB 8.3.5
안내서 버전 : v1.5.0
본 안내서는 SysMasterDB 8.3를 시스템에 설치하는 과정을 설명한다.
SysMasterDB 8.3를 설치하고자 하는 시스템 관리자 그리고 DBA를 대상으로 기술한다.
데이터베이스의 이해
Lock Monitoring
글로벌 내비게이션 바에서 [Realtime] > [Lock Monitoring] 메뉴를 클릭하면 Lock Monitoring 화면이 열린다.
Lock Monitoring 화면에서는 세션간의 Lock 정보를 Tree 형식으로 보여준다. 따라서 Lock을 점유하고 있는 Holder Session과 Lock을 획득하기 위해 기다리고 있는 Waiter Session을 모니터링 할 수 있다. 그리고Lock을 점유하고 있는 세션을 모니터링할 수 있으며, 특정 세션을 종료 시킬 수 있다.
다음은 Lock Tree Table 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Instance Info
모니터링 DB 인스턴스 및 장비에 관한 상세 정보를 제공한다.
이름
설명
History Analysis
지정한 기간 동안에 변경된 SQL Plan에 대해 비교 분석 기능을 제공한다.
각 관제 DB에서의 세션 접속 추이와 각 시점의 세션 접속 현황을 제공한다.
Instance Overview
모니터링 중인 그룹에 포함된 DB 인스턴스들의 상태 및 인스턴스의 Alert 발생 현황을 확인하는 영역이다.
각 인스턴스당 색상이 할당되며, TAC / TSC 클러스터일 경우 묶여서 배치된다.
Instance Overview에서는 각 인스턴스의 상태를 한눈에 확인할 수 있다.
우측 Alert 항목에 Alert 항목이 보일 경우 Normal, 이며, Agent Disconnected 혹은 DB Down일 경우 해당 상태가 우측에 표시된다.
우측 화살표 버튼을 클릭하여 Instance Overview 메뉴를 숨기거나 펼칠 수 있다.
모니터링 대상 DB의 상태에는 Normal, Agent Disconnected, Down이 있다.
Global Navigation Bar (GNB)
Global Navigation Bar를 통해 시스마스터 각 메뉴로 이동해 기능을 사용할 수 있다.
GNB로 이동할 수 있는 메뉴는 Realtime, Analysis, ,,, 이다.
- 논리적 읽기, 물리적 읽기, 실행 횟수 등 세션 실시간 지표를 모니터링한다.
- CPU·메모리 사용량 등 OS 수준의 자원 사용 현황과 프로세스별 자원 소비를 필터 옵션과 함께 모니터링한다.
- 사용자 지정 차트 레이아웃으로 선택한 인스턴스를 실시간 모니터링한다.
- 테이블스페이스 사용량과 상태를 시간별 업데이트 및 실시간 데이터 수집으로 모니터링한다.
권한 설정하기
Expanded Layout
CPU / Memory 파이 차트에 마우스를 호버하여 상세 정보를 확인할 수 있다.
Lock Waiter: 인스턴스가 락을 기다리고 있는 세션 갯수를 표시한다.
Tablespace: 사용량이 90% 이상인 테이블스페이스 갯수를 표시한다. 하단에 스크롤 가능한 테이블을 통해 테이블스페이스 사용 현황을 표시한다.
Realtime
본 장에서는 데이터베이스의 실시간 상태 모니터링 기능을 제공하는 Realtime Monitoring에 대해 설명한다.
- DB 세션 현황, DB 머신의 CPU 및 메모리 사용량 등 DB 실시간 지표들을 확인할 수 있다.
- 테이블스페이스, 파일, UNDO 및 TEMP 공간의 실시간 상태를 확인할 수 있다.
All Session Flow
글로벌 내비게이션 바에서 [Analysis] > [History Analysis] > [All Session Flow] 메뉴를 클릭하면 All Session Flow 화면이 열린다.
All Session Flow 화면에서는 지정한 기간 동안 접속한 DB 사용자별로 구분하여 세션 개수를 그래프로 제공한다. 이때 특정 시점의 사용자가 몇개의 세션을 맺었는지 확인이 가능하며, 선택한 시점에 어떤 세션들이 활동을 하였는지 확인할 수 있다.
Alert Events
현재 모니터링 중인 인스턴스들의 Aert 발생 현황을 나타내는 영역이다. 각 Alert Level (Error, Warning, Info) 별로 몇개의 Alert가 발생하고 있는지 표시한다. 버튼을 클릭하여 해당 인스턴스의 Alert Event History로 이동한다.
User Created Alert 및 System Alert 모두 확인 할 수 있으며, Alert가 발생한 시각, Alert 이름, Alert 레벨, Alert가 발생한 인스턴스, Confirm 여부 및 Alert 확인시 작성한 유저 Comment 이력을 확인 할 수 있다.
인스턴스 및 필터 조건을 변경하여 다른 인스턴스 및 특정 시간대에서 발생한 Alert들을 조회 할 수 있다.
Chart 공통 기능
Instance Monitoring 페이지의 Layout Tab 영역에서 제공되는 모니터링 지표 차트의 공통 기능에 대해 설명한다.
차트 좌상단의 지표명 우측에 표출되는 info 아이콘 위에 마우스 포인터를 올려두면, 해당 지표에 대한 Description을 확인할 수 있다.
차트 우상단의 더보기 아이콘을 클릭하면, 각 차트별로 지원되는 부가 기능 목록을 확인할 수 있다.
차트 종류에 따라 지원되는 부가 기능이 다르며, 차트별 부가 기능에 대한 설명은 을 참고한다.
Changed Plan Analysis
글로벌 내비게이션 바에서 [Analysis] > [History Analysis] > [Changed Plan Analysis] 메뉴를 클릭하면 Changed Plan Analysis 화면이 열린다.
Changed Plan Analysis 화면에서는 지정한 기간 동안에 변경된 SQL Plan에 대해 비교 분석할 수 있는 차트를 제공한다.
Card View
현재 모니터링 중인 인스턴스의 상태와 주요 모니터링 데이터들을 카드 뷰 형태로 확인할 수 있다.
카드 뷰는 기본적으로 3초 주기로 Refresh되며, Card Order By 에 설정된 대로 정렬되어 표시된다. (카드 정렬 기준 참조)
라이선스(기간 만료 등의 이유로) 파일 교체가 필요한 경우, 해당 경로 내 기존라이선스 파일을 신규 라이선스파일로 바꿔준 후 SysMasterDB 서비스를 재기동하면 된다.
2. 로그 확인
3. 종료
1.1. SysMaster 디플로이먼트 삭제
1.2. Kafka 디플로이먼트 삭제
1.3. RepoDB, MetaDB 디플로이먼트 삭제
참고
1. SysMaster 디플로이먼트와 Kafka 디플로이먼트는 항상 같이 삭제한다.
2. RepoDB, MetaDB 디플로이먼트는 반드시 삭제할 필요는 없으며, SysMaster 종료 후에도 RepoDB와 MetaDB에 접속해 데이터를 확인할 수 있다.
4. 초기화
$SYSMASTERDB_HOME/license
참고
라이선스(기간 만료 등의 이유로) 파일 교체가 필요한 경우, 해당 경로 내 기존 라이선스 파일을 신규 라이선스 파일로 바꿔준 후 SysMasterDB 서비스를 재기동하면 된다.
1.4. 실행
1.4.1. Docker-compose 환경
1.4.2. Podman-compose 환경
2. 로그 확인
참고
Client 모듈의 경우 따로 로그를 파일로 남기고 있지 않고 있으므로, docker compose logs 와 같은 명령어로 출력되는 로그를 확인해야한다.
3. 종료
4. 초기화
kubectl apply -f kubernetes/sysmaster
Started SdmApplication in ... seconds (JVM running for ...)
/sysmaster/logs
kubectl delete -f kubernetes/sysmaster
kubectl delete -f kubernetes/kafka
kubectl delete -f kubernetes/db
kubectl delete -f kubernetes/init
sysmaster-db up
podman compose -f podman-compose.yml up -d
Started SdmApplication in ... seconds (JVM running for ...)
sysmaster-db down
RDBMS의 이해
운영체제 및 시스템 환경의 이해
UNIX 계열(LINUX 포함)의 기본 지식
티맥스티베로 SysMasterDB 매뉴얼에 적용되는 저작권 안내사항 이다.
경기도 성남시 분당구 정자일로 45 티맥스타워
Tel : +82-1544-8629
E-Mail : gitbook@tibero.com
이 소프트웨어(SysMasterDB 8®) 사용설명서의 내용과 프로그램은 저작권법과 국제 조약에 의해서 보호받고 있다.
사용설명서의 내용과 여기에 설명된 프로그램은 TmaxTibero Co., Ltd.와의 사용권 계약 하에서만 사용이 가능하며, 사용설명서는 사용권 계약의 범위 내에서만 배포 또는 복제할 수 있다. 이 사용설명서의 전부 또는 일부분을 TmaxTibero의 사전 서면 동의 없이 전자, 기계, 녹음 등의 수단을 사용하여 전송, 복제, 배포, 2차적 저작물 작성 등 의 행위를 하여서는 안된다.
이 소프트웨어 사용설명서와 프로그램의 사용권 계약은 어떠한 경우에도 사용설명서 및 프로그램과 관련된 지적 재산권(등록 여부를 불문)을 양도하는 것으로 해석되지 아니하며, 브랜드나 로고, 상표 등을 사용할 권한을 부여하지 않는다. 사용설명서는 오로지 정보의 제공만을 목적으로 하고, 이로 인한 계약상의 직접적 또는 간접적 책임을 지지 않으며 사용설명서 상의 내용은 법적 또는 상업적인 특정한 조건을 만족시키는 것을 보장하지는 않는다. 사용설명서의 내용은 제품의 업그레이드나 수정에 따라 그 내용이 예고 없이 변경될 수 있으며, 내용상의 오류가 없음을 보장하지 않는다.
SysMaster DB 8®는 TmaxTibero Co., Ltd.의 등록 상표이다. 기타 모든 제품들과 회사 이름은 각각 해당 소유주의 상표로서 참조용으로만 사용된다.
Spoqa Han Sans Neo 및 Inconsolata가 적용되며 SIL Open Font License 이다.
상세정보는 제품 내 위치한 아래의 디렉터리에서 확인할 수 있다.
${INSTALL_PATH}/license/font_li censes
본 제품의 일부 파일 또는 모듈은 아래의 라이선스를 준수한다.
Apache License 2.0, BSD 2-Clause License, CDDL 1.0 / 1.1, Confluent Community License, Eclipse Public License (EPL) 1.0 / 2.0, Eclipse Distribution License 1.0, GNU General Public License (GPL) 2.0, GNU Lesser General Public License (LGPL) 2.1, MIT License, MIT-0, Mozilla Public License (MPL) 1.1 / 2.0, Public Domain (CC0 포함), Revised BSD License, The JSON License, WTFPL
상세정보는 제품 내 위치한 아래의 디렉터리에서 확인할 수 있다.
$BINARY_HOME/oss_license
: 해당 인스턴스가 TSC일 경우 해당 인스턴스에 대한 TSC Monitoring 메뉴로 이동한다.
전체
Instance 상태 설명
참고
1분간 등록된 인스턴스와의 연결 시도가 실패할 경우 SysMasterDB는 해당 DB 인스턴스를 Down 상태로 간주한다. 이후 연결이 다시 가능해질 경우 자동으로 이를 인식하여 Normal 상태로 전환된다.
주의
방화벽 설정 변경 등의 이유로 TPM Agent 데이터 수집 전송이 멈췄을 경우 Normal 상태에서 아무런 지표가 보이지 않는 현상이 있을 수 있다. 따라서 Normal 상태인데 실시간 지표가 보이지 않는다면, 관제 DB 머신과 TPM Agent 로그를 확인해 볼 필요가 있다.
Import Instance
Alert Events
참고
바로가기
인스턴스 선택 기능
드롭 다운 메뉴 설명
File Usage - 데이터베이스 파일 사용량을 자동으로 매시간 수집하며, 필요 시 실시간 업데이트도 가능하다.
Temp Usage - 비효율적인 쿼리나 과도한 자원 사용을 감지하기 위해 임시 테이블스페이스 사용량을 모니터링한다.
Configurable Privileges 중 선택한 인스턴스에 대해 [Data Collection] 권한이 부여된 사용자에 한해 [Collect] 버튼을 사용할 수 있다.
SQL Text
SQL 구문
Child Number
SQL의 Child Number
SQL ID
New Plan List 화면
SQL ID
그룹 생성 시 필요한 항목은 다음과 같다.
항목
설명
Group Name
생성할 그룹의 이름을 지정한다.
Instance
그룹에 할당될 인스턴스를 지정한다.
Member&Name
그룹에 넣을 유저를 id기준으로 지정한다.
현재 수행 중인 SQL과 동일한 SQL들의 과거 이력들의 통계 정보를 보여준다. Summary, execute count, physical reads, logical reads, plan history, sql trace 항목들을 보여준다.
Summary 탭 화면에서는 분석 구간 동안 stat 지표 및 wait event 리스트와 각 wait event별 wait time의 값을 확인할 수 있다.
항목
설명
Statistics
Statistics 지표 확인
Wait Class
분석 구간 동안의 wait class 목록과 각 wait class별 wait time의 값을 확인
Wait Event
Wait class에서 선택한 항목에 대한 상세 내역을 확인
Execute Count 탭 화면에서는 시간 단위별 Execute Count를 차트 형태로 확인할 수 있다.
Physical Reads 탭 화면에서는 시간 단위별 Physical Reads를 차트 형태로 확인할 수 있다.
Logical Reads 탭 화면에서는 1분 단위의 Logical Reads를 차트 형태로 확인할 수 있다.
Plan History 탭 화면에서는 같은 쿼리에 대해 Plan별 비교가 가능하다.
SQL Trace 탭 화면에서는 조회 기간 동안의 SQL 수행 이력(Trace 정보)을 확인할 수 있다.
SQL 수행 과거 이력 기한 선택
SQL Full Text
Plan Tree
SQL 수행 이력 통계
Summary
Execute count
Physical Reads
Logical Reads
Plan History
SQL Trace
참고
SQL 수행 이력 수집에 사용하는 티베로 라이브러리 이슈로 일부 정보에 Machine, Module, Program, Username, OS User 항목이 수집되지 않을 수 있다.
SQL trace 의 child number 가 0 인 경우는 다양한 이유로 SQL plan 할당에 실패 했을 경우이다. 그리고 SQL plan 생성을 실패하는 지점까지 수행 시간 자체가 사용자가 설정한 SQL_STAT_HISTORY_THRESHOLD 가 넘으면 SQL plan 생성을 실패한 SQL trace 를 수집하게 된다. 결론적으로 수집된 SQL trace 의 child number 가 0 인 경우 매핑되는 SQL plan 이 없으므로 SQL plan 을 볼 수 없다.
Analysis 서비스 하위 메뉴에서 공통으로 사용되는 기능에 대해서 설명한다.
Analysis의 하위 메뉴에 진입 시 공통적으로 보여지는 드롭다운 메뉴이다. 해당 드롭다운을 통해 모니터링 대상 인스턴스를 선택할 수 있다.
Analysis 메뉴들 화면 좌측 상단의 드롭다운 메뉴를 클릭한다.
Instance 드롭다운 메뉴를 클릭한다.
드롭다운이 펼쳐지면 원하는 인스턴스를 선택하고, 해당 인스턴스에 대한 모니터링 정보가 화면에 나온다.
Analysis의 하위 메뉴에서는 공통적으로 Period Selector를 제공한다. 사용자는 Period Selector를 통해 데이터 분석 대상 기간을 설정할 수 있다. 이때 Period 영역에서 기간을 설정하고, 오른쪽의 [VIEW] 버튼을 클릭하면 대상 기간의 데이터가 조회된다. 기본적으로 1시간 단위로 되어 있고 만약 특정한 기간이 필요하다면, Custom으로 하여 원하는 기간 구간에서 조회가 가능하다.
기본적으로 차트 데이터의 단위는 분, 시, 일을 지원하며 데이터의 개수 120개를 기준으로 단위가 변한다.
예시 1: 검색 범위 120분(2시간) 이하는 분 단위 데이터로 조회
예시 2: 검색 범위 120분(2시간) 초과 120시간(5일) 이하는 시간 단위 데이터로 조회
아래의 주소에서 도커 엔진 설치 방법 문서를 확인한 후 운영체제에 맞는 도커 엔진을 설치한다.
설치 환경의 인터넷 연결 여부에 따른 설치 방법은 다음과 같다.
인터넷 연결이 가능한 경우
"Install using the repository" 과정에 따라 설치한다.
이때 별도의 버전을 명시하지 않고 가장 최신 버전을 설치할 것을 권장한다.
이때 도커 엔진 설치 과정에서 최종적으로 설치되어야 하는 패키지는 docker-ce, docker-ce-cli, containerd.io, docker-compose-plugin이다.
docker version 명령을 사용하여 정상적으로 도커/ 파드맨이 설치되었는지 확인한다.
아래의 주소에서 설치 방법을 확인한 후 설치한다.
파드맨 엔진 설치 과정에서 최종적으로 설치되어야 하는 패키지는 podman, Slirp4netns, podman-plugins이다.
podman version명령을 사용하여 정상적으로 도커/ 파드맨이 설치되었는지 확인한다.
'Docker-compose', 'Kubernetes', 'Podman-compose' 중에서 하나만 선택하여 설치한다.
Docker 설치 시 docker-compose-plugin 패키지가 함께 설치된다. Docker가 정상적으로 설치되었을 경우 docker-compose 환경을 위한 별도의 추가 설치 과정은 필요 없다.
docker compose version 명령을 사용해 정상적으로 docker compose가 설치되었는지 확인한다.
Period Selector
Period Selector
All Session Flow 페이지에서 Period Selector는 Chart Interval 기능이 추가되어있다. 공통 기능의 Period Selector는 조회 기간에 따라 Chart Interval이 동적으로 결정되지만 All Session Flow 페이지에서는 사용자가 Chart Interval을 지정할 수 있다.
Chart Interval
Chart Interval은 각각 sec, min, hour, day가 존재하고 선택한 Period가 Chart Interval로 표현할 수 있는 시간을 포함하는 경우 선택할 수 있다.
참고
아래는 Chart Interval로 표현할 수 있는 시간의 예시다.
Period가 04-22 00:00 ~ 04-22 10:00 일때 sec, min, hour, day를 선택할 수 있다.
Period가 04-22 01:00 ~ 04-22 10:00 일때 00:00 시가 포함되지 않아 DAY로 표현할 수 없어 sec, min, hour를 선택할 수 있다.
Server Monitoring
글로벌 내비게이션 바에서 [Realtime] > [Main Monitoring] > [Server Monitoring] 을 클릭하면 Server Monitoring 페이지가 열린다.
Server Monitoring 페이지에서는 OS Level의 CPU, Memory의 System Resource 사용량과 Process의 CPU 및 Memory 사용량에 대한 정보를 보여준다. 이때 PID, User, CPU(%), Memory(%) 등 각 조건별로 필터링 기능을 제공하며 전체 프로세스가 리소스를 어느 정도 차지하고 있는지 전반적인 상태를 모니터링할 수 있다.
Server Monitoring 페이지 오른쪽 상단의 [Refresh] 버튼을 클릭하면 실시간으로 CPU 사용량을 모니터링 할 수 있다.
CPU Monitoring
Server Monitoring 페이지 왼쪽 상단의 CPU 화면은 User, System 영역별 CPU 사용량과 현재 총 CPU 사용량을 차트로 보여준다.
항목
설명
Server Monitoring 페이지 왼쪽 하단의 Memory 화면은 전체 Memory 크기와 현재 Memory 사용량을 차트로 보여준다.
항목
설명
Current Process Usage 페이지은 각 프로세스의 CPU 및 Memory 리소스 사용량을 보여준다.
항목
설명
Minute Chart
Daily Hourly Chart에서 선택한 한 시간 동안의 분 단위 차트를 확인할 수 있다. 이때 해당 차트는 Daily Hourly Chart의 아래에 위치한다.
Minute Chart
Minute Chart bar를 클릭하면 원하는 메뉴로 이동이 가능하다.
Go to Analysis
각 버튼에 대한 설명은 다음과 같다.
버튼
설명
Performance Analysis
Performance Analysis에서는 성능과 관련된 각종 지표들을 확인할 수 있다.
Overall 메뉴에서 장기간 그래프를 통해 추이를 확인 한 후, Time Slice 기능을 통해 특정 시점에서 발생한 모든 지표 정보를 복합적으로 확인 할 수 있다.
Time Slice
Analysis의 하위 메뉴별로 조회 기간을 설정할 수 있다. 화면 상단의 Time Slice 버튼을 누르면 Time Slice 생성창으로 이동한다.
Time Slice를 할 구간을 선택한다.
Time Slice로 구분할 Time Unit을 선택하고 View를 누른다.
구간 안에서 Time Unit으로 나누어진 Time Slice를 선택하면 해당 Time Slice에 대한 화면이 열린다.
Physical Reads, Hard Parse Count 등 내가 관심 있는 지표를 어떤 SQL이 가장 많이 발생시켰는지 확인 할 수 있다.
설정한 지표의 변화 추이를 Heatmap을 통해 확인하고, 더 상세히 분석하고자 하는 기간의 Performance Trend나 Top N Performance 페이지로 연계할 수 있다.
TSC Monitoring
글로벌 내비게이션 바에서 [Realtime] > [High Availability Monitoring] > [TSC Monitoring] 메뉴를 클릭하면 TSC Monitoring 화면이 열린다.
TSC Monitoring 화면에서는 TSC 목록, 각 TSC 네트워크 구성, TSN을 통한 복구 현황 차트, Primary DB와 Standby DB 실시간 현황을 모니터링할 수 있다.
자동 갱신 주기를 설정할 수 있다. [Refresh] 버튼을 통하여 즉시 갱신할 수 있다.
TSC 목록
TSC 목록
TSC 목록을 확인할 수 있다.
TSC Topology View
TSC 네트워크 구성을 확인할 수 있다.
[Overview] 버튼을 누르면 TSN 차트를 확인하여 복구 현황을 모니터링할 수 있다.
Primary DB와 Standby DB의 현황을 테이블 형식으로 모니터링 할 수 있다.
Primary Database, Standby Database에서 각 인스턴스 명을 클릭하면 우측 사이드 패널에서 Instance info를 확인 할 수 있다.
다음은 Primary Database 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
다음은 Standby Database 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Total Session Info
Total Session Info 화면에서는 All Session Count에서 선택한 세션의 정보를 확인할 수 있다.
Total Session Info 화면
다음은 Total Session Info 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
User Name
Instance 등록하기
로그인 후 첫 화면인 Dashboard에서 import 버튼을 클릭하면 instance를 등록할 수 있다.
아래 예시 화면은 인스턴스 등록 페이지이다.
해당 페이지에서는 모니터링을 위한 인스턴스 연결 테스트 및 등록을 수행할 수 있으며, 현재 서비스에 적용된 라이선스 정보를 상단 License Info 영역을 통해 참고할 수 있다.
항목
설명
새로 등록한 instance는 바로 화면에 반영되지 않고, 그룹에 instance를 할당한 후에 Dashboard에서 관제가 가능하다.
Alert Event Analysis
글로벌 내비게이션 바에서 [Analysis] > [History Analysis] > [Alert Event Analysis] 페이지를 클릭하면 Alert Analysis 페이지가 열린다.
Alert Event Analysis 페이지에서는 SysMaster DB 8 제품의 사용자가 설정한 알림 및 시스템 알림 규칙 대한 알림 발생 이력을 확인할 수 있다. 또한 발생한 알림에 대한 확인 여부도 확인할 수 있다.
User-created
시간 범위를 설정하여 사용자 설정 알림 발생 정보를 차트로 조회하여 볼 수 있다.
System
시간 범위를 설정하여 사용자 설정 알림 발생 정보를 차트로 조회하여 볼 수 있다.
User created 탭과 System 탭 차트의 특정 시간을 클릭하여 해당 시간의 알림 목록을 조회할 수 있다.
항목
설명
All Session Flow
All Session Flow 화면에서는 동일한 DB 사용자는 제외하고, DB 사용자별 전체 세션 갯수를 그래프로 확인할 수 있다. 이이때 오른쪽 상단의 차트 간격(Interval)과 집계 방식(Aggregation)을 드롭다운 메뉴로 선택하여 확인할 수 있다.
All Session Flow 화면
SQL Text
SQL Text 화면에서는 New Plan List에서 선택한 SQL문에 대한 전체 구문을 확인할 수 있다.
SQL Text 화면
Add Layout
[New Tab]에서 [Add Layout] 버튼을 클릭하여 Layout을 신규 생성할 수 있다.
레이아웃 생성은 다음과 같은 프로세스로 진행된다.
Layout Name
레이아웃 이름을 입력한다. 해당 이름이 Instance Monitoring 페이지에 노출된다.
Chart Index
사용자가 실시간으로 모니터링할 지표를 선택한다.
Instance Monitoring에서 제공되는 모니터링 지표 목록은 를 참고한다.
Selected Item
사용자가 선택한 지표 목록을 확인하고, 각 지표 차트 옵션을 설정한다.
Summary
사용자가 선택한 지표 목록이 반영된 레이아웃 예시를 확인할 수 있다.
Add
Add 버튼을 클릭하여 사용자가 직접 정의한 Layout을 생성, 해당 Layout Tab에 적용한다.
Plan History Comparison
Plan History Comparison 화면에서는 TimeStamp와 Child Number가 다른 동일한 SQL에 대해 Plan을 비 교할 수 있다. 이때 Plan에 대한 비교는 Plan Tree 형태와 Plan Text 형태로 확인할 수 있다.
Plan History Comparison 화면 - Plan Tree 형태
Plan History Comparison 화면 - Plan Text 형태
Search SQL Text
글로벌 내비게이션 바에서 [Analysis] > [History Analysis] > [Search SQL Text] 메뉴를 클릭하면 Search SQL Text 화면이 열린다. Search SQL Text 화면에서는 지정한 기간 동안의 SQL 목록을 확인할 수 있다.
Search SQL Text 전체 화면
SQL Detail
Search SQL Text 화면의 SQL 목록에서 특정 열을 더블 클릭하면 해당 SQL의 상세 정보를 확인할 수 있 는 SQL Detail 화면이 열린다.
Copy Layout
Layout 목록에서 특정 Layout의 더보기 버튼 클릭 시 제공되는 Copy 기능을 통해 기존 Layout을 복사할 수 있다.
[Copy] 클릭 시 복사 대상 Layout의 복사본이 생성되며, 사용자는 복사본 Layout의 이름을 직접 설정하여 저장할 수 있다.
시스템 요구사항
SysMaster DB 8.3의 공식지원 플랫폼 및 운영체제는 다음과 같다.
구분
제품 및 버전
Tablespace Usage
글로벌 내비게이션 바에서 [Realtime] > [Usage Monitoring] > [Tablespace Usage] 를 클릭하면 Tablespace Usage 페이지가 열린다.
Tablespace Usage 페이지에서는 테이블스페이스 사용량 정보를 보여준다.
모니터링 대상 DB의 테이블스페이스 사용량과 상태 정보를 확인할 수 있다. 이때 기본 수집 단위는 1시간이지만, 우 상단의 [Collect] 버튼을 이용하면 해당 시간에 실시간 정보를 수집해서 보여준다.
항목
설명
Chart Type
Instance Monitoring 페이지의 Layout Tab 영역에서 제공되는 모니터링 지표 차트의 종류에 대해 설명한다.
인스턴스별 해당 지표의 실시간 값을 막대 그래프로 나타내는 차트이다.
Line 또는 Area 차트로 전환이 가능하다.
인스턴스별 해당 지표의 실시간 값을 꺾은선 그래프로 나타내는 차트이다.
Bar 또는 Area 차트로 전환이 가능하며, 부가 기능을 통해 선 굵기를 사용자가 직접 설정할 수 있다.
Session Info 탭
현재 session의 상태 정보, session에서 수행중인 SQL 정보들을 보여준다.
현재 session의 wait event 발생 정보이다.
항목
설명
Tablespace Usage
글로벌 내비게이션 바에서 [Analysis] > [Usage Analysis] > [Tablespace Usage] 메뉴를 클릭하면 Tablespace Usage 화면이 열린다.
이 화면에서는 지정한 기간 동안의 테이블스페이스 이름별 크기의 변화량을 확인할 수 있다.
다음은 Tablespace Usage 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Layout Tab 기본 기능
Instance Monitoring 페이지의 Layout Tab 영역에서 제공되는 기본 기능에 대해 설명한다.
사용자 편의를 위해, Instance Monitoring 페이지에서는 Default Layout을 제공한다.
파드맨(Podman)은 rootless container 기능을 지원하여 sudo 명령어 없이 컨테이너를 운용할 수 있다. Linux Kernel 4.18 이하에서는 디스크 볼륨을 rootless container에 마운트 할 수 없기 때문에 Podman은 Red Hat Enterprise Linux 8 이상부터 지원한다.
인스턴스 등록 시 입력하는 TPM Agent ID와 TPM Agent의 설정 파일에 있는 ID는 동일해야 한다.
주의
LOG_REPLICATION_DEST_N = "hostname_N:port_N {LGWR SYNC|LGWR ASYNC|ARCH ASYNC}" 의 IP:PORT와 SysMaster DB 에 Standby 인스턴스 등록할 때 사용한 IP:PORT 가 다르다면 TSC 모니터링 화면의 topology 네트워크 구성이 올바르게 보이지 않는다.
참고
SysMasterDB에 관제 대상 DB 인스턴스를 등록하면, TPM Agent 기동 여부와 관계없이 SysMasterDB는 관제 대상 DB에 직접 접속하여 수집을 시작한다.
일부 수집 항목은 TPM Agent가 아닌 DB 직접 쿼리 방식으로 주기적으로 수집되므로, TPM Agent가 종료되어도 SysMasterDB의 DB 접속 세션은 유지된다.
관제 및 수집을 중지하려면 SysMasterDB에서 해당 인스턴스를 삭제해야 한다.
TPM Agent 수집 주기의 영향을 받아 TPM Agent 수집 주기보다 빠르게 갱신하더라도 TPM Agent 수집 주기로 갱신이 이루어진다. 예를 들어 TPM Agent 에서 CPU, Memory, Process 수집 주기를 1분으로 했다면, Server Monitoring 화면 갱신을 1초마다 진행하더라도 데이터의 갱신은 1분마다 이루어지게 된다.
Process 목록에서의 CPU 사용량은 하나의 코어에 대한 사용량으로 100%일 경우 하나의 코어를 전부 사용하는 것이며, 100%가 넘어가면 하나의 코어를 전부 사용하고 추가로 다른 코어도 사용한다는 의미이다. 따라서 Process 목록에 있는 CPU 사용량을 전부 더한 값과 CPU Monitoring 의 CPU 사용량과 다르다. CPU Monitoring 의 CPU 사용량은 전체 코어들에서 얼마나 사용되고 있는지에 대한 값이기 때문이다.
Alert Trigger
알람 트리거 이름
Instance
알림이 발생한 인스턴스 이름
Confirm
사용자 확인 여부
User Comment
알림 확인 시 사용자가 작성한 메시지 내용
Alert Time
알림이 발생한 시각
Alert Name
알림 이름
Alert Level
알림 레벨 (INFO, WARNING, ERROR)
Alert Event 목록
Docker-compose
v2.40.2 이상
Podman
v4.4.1 이상, Linux Kernel 4.18을 사용하는 Linux Red Hat Enterprise Linux 8 이상부터 지원.
Podman-compose
v1.0.6 이상
Kubernetes
v1.17 이상
관제 데이터베이스
Tibero 6 FixSet06 이상
Tibero 7
[참고]
SysMasterDB의 Tibero 관제 연동은 Tibero 버전명뿐 아니라 서버 바이너리의 빌드 형상과 연동 라이브러리 간 호환성을 기준으로 한다.
동일한 Tibero 버전이라도 빌드 시점 및 적용 패치 내역에 따라 연동 라이브러리와 호환되지 않을 수 있다.
특히 2022년 이전 빌드 바이너리는 정상 관제를 보장하지 않으며, 기본 지원 대상에서 제외된다.
관제 데이터베이스 운영 체제
Linux:
CentOS 7 (64-bit)
Red Hat Enterprise Linux 7 ~ 10 (64-bit)
SysMaster DB 8.3를 설치하기 위해 필요한 하드웨어 및 소프트웨어의 요구 사항은 다음과 같다.
구분
사양
CPU
8 Core
RAM
32 GB
저장 공간
30 GB 이상 (수집 정보의 보관 주기(RETENTION_DAY)에 따라 일 당 50 GB 추가 필요)
SysMaster DB 8.3의 관제 데이터베이스 대상 권장 패치는 다음과 같다.
패치 번호
패치 내용
240373
Program 이 PE_SLAVE 인 Session 에서 OS User 와 Machine 정보 누락 개선
[참고] 해당 패치가 없다면 Program 이 PE_SLAVE 인 Session 에서 OS User 와 Machine 정보가 누락된다.
276404
티베로의 global view 조회 시 수행되는 내부 쿼리에 대해 수행 시마다 physical plan을 새로 생성하는 문제 개선
[참고] SysMaster DB 8에서는 Lock 정보 수집을 위해 global view를 매초 조회한다. 해당 패치가 없는 경우 매초 특정 SQL에 대해 physical plan을 생성하여 [Analysis] > [Plan Analysis] 등에서 해당 SQL에 대해 조회 시 응답 없음 현상이 발생할 수 있다.
279651f
libtpmstat 라이브러리 생성
[참고] 해당 패치가 없는 경우 libtpmstat 라이브러리를 TPM Agent 설치 시 함께 배포해야 한다. TPM Agent 8.1.3 이상은 하위 버전 패치인 279651e 이하 패치와 호환이 되지 않기에, 279651f 이상 패치가 필요하다. Tibero에 적용된 279651 패치 버전과 상관 없이, TPM Agent 빌드 시 사용한 279651 패치 버전과라이브러리의 279651 패치 버전이 맞아야 한다.
운영체제
Linux:
CentOS 7 (64-bit)
Red Hat Enterprise Linux 7 ~ 9 (64-bit)
Oracle Linux Server release 9.4
Rocky Linux release 8 ~ 9 (64-bit)
Windows:
Windows 10 (64-bit)
Windows Server 2022 (64-bit)
아래(Docker 및 Podman) 지원 플랫폼 및 소프트웨어 요구 사항 설치를 지원하는 운영체제면 기동 가능
Docker
v28 이상
1. 지원 플랫폼 및 운영체제
Docker Engine 24버전 환경에서 컨테이너 다중 네트워크(endpoint) 연결 실패 문제가 확인되었으며, 해당 네트워크 처리 관련 이슈는 Docker Engine 28버전에서 수정되었다. 따라서 안정적인 기동을 위해 Docker Engine 28버전 이상 사용을 권장한다.
참고
'관제 데이터베이스'는 '관제 데이터베이스 운영 체제' 목록에 있는 운영 체제에 설치된 데이터베이스에 대해서만 관제가 가능하다.
주의
Docker Compose 2.40.2 버전 미만인 경우 Docker Compose에서 원격 OCI Compose 아티팩트 설정 값 검증 미흡으로 발생하는 경로 탐색 취약점이 있다. 따라서 2.40.2 버전 이상으로 업데이트를 권고한다.
2. 하드웨어 및 소프트웨어
참고
총 Active Session 수 600개 (Active Session 수 60개 × 인스턴스 10대) 기준의 사양이다.
3. 관제 데이터베이스 권장 패치
테이블스페이스 이름
Status
테이블스페이스의 현재 상태
Contents
테이블스페이스 종류
Permanent
Undo
Free/Total Size
테이블스페이스 여유공간 현황
Used/Total Size
테이블스페이스 사용공간 현황
Extent Management
Extent Management 방식
Allocation Type
Extent Allocation 방식
Segment Space Management
Segment Space Management 방식
Auto Extend On
해당 테이블스페이스의 Data File 중 하나라도 Auto Extend 상태인지 여부
Last 24 hours history 에서는 그리드(Grid) 형태로 현재까지의 사용량 정보를 확인하거나, 차트(Chart) 형태로 변화율 추이를 확인할 수 있다.
항목
설명
Log Time
수집 시간
Free/Total Size
테이블스페이스 여유공간 현황
Used/Total Size
테이블스페이스 사용공간 현황
Segment Size 에서는 Last 24 hours history 에서 선택한 Log Time 내 세그먼트 타입별 크기를 확인할 수 있다. 이때 해당 정보의 수집 단위는 1시간이다.
항목
설명
Segment Type
세그먼트 종류 (Table, Index, Undo 등)
Owner
소유자 계정
Segment Name
세그먼트 이름
Current Tablespace Usage
Tablespace Name
Last 24 hours history
Segment Size
참고
세그먼트 크기가 클수록 부하의 영향을 많이 받으며, Tablespace Usage 페이지 오른쪽 상단의 [Collect] 버튼을 클릭해도 해당 정보는 수집하지 않고 매시간 정각에 수집된다.
인스턴스별 해당 지표의 실시간 값을 영역 그래프로 나타내는 차트이다.
Bar 또는 Line 차트로 전환이 가능하다.
인스턴스별 해당 지표의 실시간 값을 누적 막대 그래프로 나타내는 차트이다.
Grid 차트로 전환이 가능하며, 부가 기능을 통해 해당 지표의 범위값을 사용자가 직접 설정할 수 있다.
인스턴스별 해당 지표의 실시간 값을 테이블 형태로 나타내는 차트이다.
각 인스턴스별로 탭을 구분하여 해당 지표의 실시간 값을 제공하며, Stack Bar 차트로 전환이 가능하다.
인스턴스별 해당 지표의 실시간 값을 원형 그래프로 나타내는 차트이다.
각 인스턴스별로 탭을 구분하여 해당 지표의 실시간 값을 제공한다.
인스턴스별 해당 지표의 실시간 값을 분산형 그래프로 나타내는 차트이다.
부가 기능을 통해 해당 지표값의 조회 범위를 사용자가 직접 설정할 수 있다.
Scatter 차트로 제공되는 Response Time 지표의 경우, 차트 내 드래그를 통해 원하는 영역을 선택할 수 있다.
이 때, 드래그로 선택한 영역 내의 각 포인트에 해당하는 SQL Trace 정보가 Long SQL List 모달을 통해 제공된다.
Long SQL List 모달의 각 칼럼은 다음과 같다.
칼럼명
내용
Instance
인스턴스 명
SID
세션의 ID
Serial#
세션의 시리얼 번호
Long SQL List 모달의 테이블 내 각 항목 클릭 시, 해당 SQL Trace가 수행된 Session Detail 페이지로 이동한다.
추가로, Super Admin 또는 Admin 권한을 가진 사용자에게는 Long SQL List 모달에 Download 버튼이 제공된다.
해당 클릭하면, 테이블 데이터를 csv 형식의 파일로 내려받을 수 있다.
일반 사용자에게는 기본적으로 Download 버튼이 표출되지 않으나, Admin 사용자에 의해 Data Export 권한을 부여받은 경우에는 해당 기능을 사용할 수 있다.
Bar
Line
Area
Stack Bar
Grid
Pie
Scatter
현재 session에서 발생한 wait event로 대기한 시간
항목
설명
SQL ID
세션이 수행 중인 SQL의 SQL ID
Prev Child Number
세션이 이전에 수행했던 SQL의 Child Number 값
Child Number
세션이 수행 중인 SQL의 Child Number 값
현재 session에서 수행 중인 SQL 전문을 보여준다.
현재 session에서 수행 중인 SQL에 대한 Plan을 확인할 수 있는 화면이다. 이때 SQL Plan을 Tree 구조로 보여준다.
현재 session 상태 지표이다.
상태 지표 별 항목은 다음과 같다.
항목
설명
∑
세션의 Statistics 지표별 누적 값
Delta
세션의 Statistics 지표별 새로고침 전, 후의 변경 값
Value/Sec
Delta 값을 새로고침한 시간(초 단위)으로 나누어 계산한 값
상태 지표 목록은 다음과 같다.
Statistics 지표 이름
설명
CONSISTENT_BLOCK_GETS_READONLY_PIN
Readonly block에 대해 consistent block get을 수행한 횟수
TOTAL_PARSE_COUNT
Parse 총 횟수
REDO_ENTRIES
Redo Entries의 개수
(Redo Entries : 세션이 Log Buffer에 기록한 Redo 레코드)
Wait event
현재 session에서 발생한 wait event 번호
Wait event 정보
Wait time
Session이 수행한 SQL 기본 정보
SQL Full Text
Plan Tree
Session statistics
Tablespace Name
테이블스페이스 이름
Contents
테이블스페이스에 저장하는 데이터 종류
TEMPORARY
PERMANENT
UNDO
Earlier Time
이전 시점
Later Time
이후 시점
Earlier Free/Total Size
Tablespace Usage 에서 특정 데이터 클릭 시 해당 테이블스페이스의 시간별 크기 변화를 상세하게 확인할 수 있다. 이때 오른쪽의 그래프를 통해 크기 변화량을 한눈에 파악할 수 있다.
Tablespace Info
다음은 Tablespace Info 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Log Time
수집 시간
Tablespace Name
테이블스페이스 이름
Used
사용량
Tablespace Usage
Tablespace Usage 전체 화면
Tablespace Usage
Tablespace Info
[Session] Long Running Session Count
[Session] Lock Waiter Session Count
[System] TPS
[Stat] Buffer Cache Hit
[System] TSM Usage (Total)
[System] PGA Usage (Total)
[Stat] Redo Log Size
[Stat] Physical Reads
[Stat] Logical Reads
[Stat] Hard Parse Count
Layout Tab 영역 우상단의 설정 아이콘 클릭 시, Auto Refresh 여부와 초(sec) 단위 간격을 사용자가 직접 설정할 수 있다.
Layout Tab 영역 상단 탭 추가 아이콘 클릭 시, 새로운 Layout Tab이 추가된다.
사용자는 새 탭에 기존 Layout 또는 직접 생성한 새 Layout을 적용할 수 있다.
Layout Tab 영역 상단 Save 버튼 클릭 시, 현재 탭에 적용된 Layout 변경 상태가 저장된다.
사용자가 생성한 Layout에 한해 해당 기능을 사용할 수 있으며, Custom 권한이 없는 일반 사용자는 해당 기능을 사용할 수 없다.
Default Layout의 경우, Save 기능이 제공되지 않으므로 해당 버튼이 다음과 같이 비활성화된다.
Layout Tab 영역 상단 Cancel 버튼 클릭 시, 현재 탭에 적용된 Layout을 기존 상태(최근 저장된 상태)로 되돌린다. 이 때, 변경된 사항은 저장되지 않는다.
Layout Tab 영역 상단의 인스턴스 목록에서 특정 인스턴스 이름 클릭 시, 해당 인스턴스가 현재 Layout Tab에서 비활성화된다. 해당 인스턴스 이름을 한 번 더 클릭하면, 다시 해당 인스턴스 그래프가 차트에 표출된다.
Default Layout
Default Layout 적용 예시
Auto Refresh
Layout Tab 추가
Layout 저장
Layout 되돌리기
인스턴스 비활성화
다음은 Invalid Objects 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Log Time
Invalid Object 데이터의 수집 시각
Owner
Invalid Object의 소유자
Object Name
Invalid Object의 Object 이름
Invalid Objects Count
Invalid Objects
Y축은 응답 시간이며, 히트맵의 색깔은 해당 응답 시간에 해당하는 SQL의 숫자를 나타낸다.
더보기 메뉴를 클릭하여 Y축 Time Range를 설정하고 저장 할 수 있다.
Starting Point : 차트에 보여질 SQL들의 최소 Elasped time 값
Cell Height: 차트의 Y축인 각 Cell의 Elasped time을 설정하는 값
히트맵 영역을 드래그하거나 셀을 클릭하여 실제 SQL 수행 내역을 별도 모달로 확인할 수 있다.
수정한 모든 내용(Card View, Custom Area)은 그룹 내 모든 사용자에게 공유된다.
인자
설명
{Monitoring_DB_Path}
관제 데이터베이스의 경로를 입력
{Monitoring_DB_SID}
관제 데이터베이스의 SID를 입력
tpmctl.sh 명령어는 아래와 같으며, help로 터미널에서 사용법 확인이 가능하다.
명령어
설명
./tpmctl.sh [-p port] up
TPM Agent 실행, -p 옵션을 통하여 jvm 디버그 포트들을 지정할 수 있다. 기본적으로 사용 가능한 포트를 찾으나, 해당 환경에서 사용 가능한 포트를 찾지 못하여 프로세스 실행이 되지 않는다면 해당 옵션을 사용하여 수동으로 포트를 지정할 수 있다.
./tpmctl.sh down
TPM Agent 종료
./tpmctl.sh help
TPM Agent 도움말 출력
Java TPM Agent에서 libtpmstat.so를 사용하기 위하여 필요한 라이브러리이다.
Tibero Down 이후 바로 Tibero Boot를 위해서 TPM Agent Down이 필요하다. TPM Agent가 참조하고 있는 Tibero Shared Memory를 해제해야 하기 때문이다.
ulimit -c unlimited
. set.sh
if [ -n "$JAVA_HOME" ] && [ -x "$JAVA_HOME/bin/java" ]; then
TARGET="$JAVA_HOME/bin/tpmagent"
# 하드링크 시도, 실패하면 복사
if ln -f "$JAVA_HOME/bin/java" "$TARGET" 2>/dev/null; then
echo "Hardlink created: $TARGET"
elif cp -p "$JAVA_HOME/bin/java" "$TARGET"; then
echo "Copied binary to: $TARGET"
else
echo "WARNING: Failed to create $TARGET"
echo " This may be a permission issue. Please check write access to $JAVA_HOME/bin."
echo " You can start TPM Agent, but in 'top'/'topas', process name will appear as java."
fi
# 실행 가능 확인
if [ -x "$TARGET" ]; then
echo "Installed $TARGET"
fi
else
echo "ERROR: JAVA_HOME not set or java not found in \$JAVA_HOME/bin"
fi
# 사용자 환경변수 설정
export TPMAGENT_HOME={TPM_Agent_Home_Path}
export PATH=$TPMAGENT_HOME:$PATH
export LD_LIBRARY_PATH=$TPMAGENT_HOME:$LD_LIBRARY_PATH
# 기존 실행 중이던 Agent가 있다면, 종료 후 실행
export BOOT_WITH_AUTO_DOWN_CLEAN=true
export ENABLE_DEBUG=false
export ENABLE_GC_LOG=false
# Agent 의 java heap 메모리 설정. 2000 session 기준 1000m. 이후 1000 session 마다 200m 추가 권장
export JAVA_MIN_HEAP_SIZE=1000m
export JAVA_MAX_HEAP_SIZE=1000m
{TPM_Agent_Home_Path}
"java_tpmagent_dist_{version}.tar.gz" 압축 파일 해제 디렉터리 경로
TPM Agent 환경 설정
1.1. 코어 덤프 파일 최대 사이즈 설정
1.2. TPM Agent 환경 변수 설정
참고
위 스크립트는 위에 두 줄인 바이너리 실행 PATH 설정과 TPM Agent 라이브러리 경로 LD_LI BRARY_PATH 설정 그리고 환경 변수 설정들을 기본적으로 제공하는 템플릿이다. 환경에 맞게 직 접 스크립트를 수정하여 TPM Agent 실행을 하면 된다.
참고
하드링크를 사용하는 이유는 top, topas 등 명령어에서 프로세스명을 치환하여 TPM Agent 프로세스를 쉽게 확인하기 위한 용도이며, 실패해도 Tibero 모니터링에는 영향이 없다.
tpmagent.jar 와 함께 있어야하므로, 배포된 압축파일을 압축해제하여 하위의 lib 경로 아래에서 실행 하고자 하는 os 버전에 해당하는 libJNITpmStat.so 파일을 tpmagent.jar 와 같은 경로에 복사해야한다.
주의
Tibero 버전명 또는 코어셋명만으로 연동 라이브러리의 호환 여부를 판단할 수 없다.
연동 라이브러리(libtpmstat.so)는 Tibero 서버와 공유 메모리 구조체가 일치해야 정상 동작하므로, 동일한 Tibero 버전이라도 빌드 시점, 직반 패치 내역, 컴파일 옵션 등에 따라 호환되지 않을 수 있다.
따라서 과거 빌드 바이너리 또는 별도 패치가 적용된 바이너리를 사용하는 경우, 관제 연동 전 동일한 Tibero 형상 기준으로 라이브러리를 빌드하고 호환 여부를 확인해야 한다.
libJNITpmStat.so 파일이 사용하는 libtpmstat.so 라이브러리 버전이 현재 Tibero 바이너리 버전과 맞지 않다면, 기존 TPM Agent 와 동일하게 SIGSEGV 문제 등 오류가 발생하여 프로세스가 실행되지 않는다. 각 JVM 벤더별로 생성되는 오류 관련 파일 종류는 다르나 core, jitdump, javacore 등의 파일 들이 생성될 수 있으므로 해당 파일 생성시 libtpmstat.so 라이브러리 버전을 확인해야한다.
Tibero Reboot시 주의 사항
주의
TPM Agent가 참조하고 있는 Tibero Shared Memory를 해제하기 위해서는 Tibero Down을 감지해야 하는데 감지 주기는 매 수집 주기와 동일하다. 따라서 사용자의 수집 주기 설정이 길게 되어있거나 TPM Agent 자체가 느려지는 경우 등 Tibero Down 감지 자체가 늦어질 경우 Tibero Down을 하고 다시 Tibero Boot가 가능한 시점이 지연되게 된다.
이와 같이 Tibero Down 감지가 늦어져 Tibero Boot 가능 시점이 지연되는 것을 방지하기 위해서는 TPM Agent Down을 진행하고 Tibero Boot를 하면 된다.
이때 지표 선택 버튼 영역 오른쪽의 콤보박스를 사용하여 조회할 리소스를 변경할 수 있다.
Daily Hourly Chart - STAT - 리소스 선택
Wait Time 관련 항목('WE_JC_BUF_DISK_READ_TIME', 'WE_BUF_FREE_TIME' 등)의 사용량에 대 한 시간 단위 차트를 조회한다.
Daily Hourly Chart - WAIT(TIME)
이때 지표 선택 버튼 영역 오른쪽의 콤보박스를 사용하여 조회할 리소스를 변경할 수 있다.
Daily Hourly Chart - WAIT(TIME) - 리소스 선택
Wait Count 관련 항목('WE_JC_BUF_DISK_READ_COUNT', 'WE_BUF_FREE_COUNT' 등)의 사용량 에 대한 시간 단위 차트를 조회한다.
Daily Hourly Chart - WAIT(COUNT)
이때 지표 선택 버튼 영역 오른쪽의 콤보박스를 사용하여 조회할 리소스를 변경할 수 있다.
Daily Hourly Chart - WAIT(COUNT) - 리소스 선택
Sessions 관련 항목('Active Session', 'Lock Waiter Session')의 사용량에 대한 시간 단위 차트를 조회한다.
Tibero Wait Event 지표가 Count는 0 이상이지만 Time은 0 으로 표기되는 경우
티베로 라이브러리에서 수집되는 Wait Event Time 은 nanosecond 단위까지 발생하지만 지표 집계와 출력은 microsecond 단위로 이루어진다. 따라서 nanosecond 단위의 Wait 만 발생했을 경우 Wait Count가 0보다 크더라도 Wait Time이 0으로 출력 될 수 있다.
TPM Agent를 설치하는 과정은 다음과 같다. 단, 반드시 관제 데이터베이스를 설치한 계정과 동일한 OS 계정으로 진행해야 한다.
1. 설치 파일 배포
관제 데이터베이스가 위치한 서버에 "tpmagent_dist_{version}.tar.gz" 압축 파일을 배포한 후 압축을 해제한다.
tar -zxvf java_tpmagent_dist_{version}.tar.gz
참고
설치 파일 압축 해제 시 150MB 정도이다. 해당 공간만큼 확보한 이후에 압축 해제를 해야 한다. 이후 에 운영 시에는 로그 로테이션 설정에 따라 용량을 확보하면 된다.
로그 파일 로테이션이란 기존에 로그를 적재하던 로그 파일을 아카이빙하고 새로운 로그 파일을 생 성하여 적재하는 것이다. 기본적으로 매 24시간 또는 한 파일의 사이즈가 50MB를 넘었을 때 새 로그 파일을 생성한다. 또한 로그 파일을 최대 7개까지 저장하는 것이 기본 설정이며, 7개가 넘어가게 되 면 오래된 로그 파일부터 삭제된다. 따라서 기본 설정인 상태에서 시간 트리거만 발생했을 때는 약 1주일 분량의 로그를 보관하며, 파일 사이즈 트리거만 발생했을 때 약 350MB 분량의 로그를 보관한 다. 그러므로 기본 설정인 상태에서 모든 로그를 보관하기 위해서는 실행 파일과 로그 파일을 합쳐 약 500MB 이상의 공간을 확보해야 한다.
2. application.yml 파일 설정
"java_tpmagent_dist_{version}.tar.gz" 압축 파일을 해제한 디렉터리에 application.yml 파일을 아래와 같이 작성하여 설정을 적용한다.
yml 문법에 맞게 각 파라미터들의 값을 조정하여 설정한다.
"java_tpmagent_dist_{version}.tar.gz" 압축 파일을 해제한 디렉터리에 set.sh 파일에 적용시킬 환경 변수들이 있으며, 아래와 같이 작성하여 설정을 적용한다.
해당 과정에서 설정하는 환경변수에 대한 설명은 다음과 같다.
환경 변수
설명
필수 여부
Top N Performance
글로벌 내비게이션 바에서 [Analysis] > [Performance Analysis] > [Top N Performance] 메뉴를 클릭하면 Top N Performance 화면이 열린다.
Top N Performance 화면에서는 검색 기간 동안에 상위에 존재하는 SQL에 대해 확인할 수 있다.
이때 Category와 Item을 설정하면 선택한 Item에 대해 Value를 확인할 수 있다. 또한 Category에서 값을 선택하여 더블 클릭을 하면 SQL에 대한 정보를 확인할 수 있고, SQL을 선택하여 더블 클릭하면 SQL Detail 화면으로 연계된다.
다음은 탭 화면의 각 영역에 대한 설명이다.
Category
데이터 집계 기준으로 'Machine', 'Module', 'Program', 'Username', 'OS user'가 있으며 'SQL' 선택 시 집계 기준을 설정하지 않는다.
Category 선택
집계 항목으로 'Logical Reads', 'Physical Reads', 'Redo Entries', 'Execute Count' 등이 있다.
Category와 Item 선택을 통해 모니터링 하고자 하는 기간에서의 성능 지표를 확인할 수 있다. 이때 영역 오른쪽 상단의 콤보박스를 통해 SQL Category를 제외한 Category에 대해 정렬 리스트의 개수(ALL / Top 20 / Top 30 / Top 50)를 지정할 수 있다.
다음은 Category / Module 영역에서 제공하는 항목에 대한 설명이다.
항목
설명
Category / Module에서 발생한 SQL 중 Item(Logical Reads) 값(Value)이 높은 순서대로 출력한다. 이 때 해당 SQL을 더블 클릭하면 SQL Detail 화면으로 넘어간다.
다음은 MODULE / SQL 영역에서 제공하는 항목에 대한 설명이다.
항목
설명
Filesystem Usage
글로벌 내비게이션 바에서 [Analysis] > [Usage Analysis] > [Filesystem Usage] 메뉴를 클릭하면 Filesystem Usage 화면이 열린다.
Filesystem Usage 전체 화면
Filesystem Usage
이 화면에서는 지정한 기간 동안의 파일 시스템 이름별 서버에 마운트된 크기의 변화량을 확인할 수 있다.
Filesystem Usage
다음은 Filesystem Usage 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Filesystem Usage 에서 특정 데이터 클릭 시 해당 파일 시스템의 시간별 크기 변화를 상세하게 확인할 수 있다. 이때 오른쪽의 그래프를 통해 크기 변화량을 한눈에 파악할 수 있다.
다음은 Filesystem Info 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Session Monitoring
글로벌 내비게이션 바에서 [Realtime] > [Main Monitoring] > [Session Monitoring] 를 클릭하면 Session Monitoring 페이지가 열린다.
Session Monitoring 페이지에서는 관제 대상 DB에서 수집 agent를 통하여 직접 세션 정보를 조회한 화면으로, 현재 연결되어 있는 세션별 logical reads, physical reads, execute counts, hard parse 등 session의 현 상황을 모니터링한 정보를 보여준다.
SID, user name, program 등 각 컬럼별로 filtering 기능을 제공하며, session 상세보기로 연계하여 각 session의 세부 정보를 모니터링할 수 있다. Configurable Privileges 중 선택한 인스턴스에 대해 [Kill Session] 권한이 부여된 사용자는 해당 인스턴스의 세션을 종료할 수 있다.
관제 대상 DB의 각 session 정보를 테이블 형식으로 보여주고, last update를 명시하여 현재 어떤 시간의 정보인지 확인할 수 있다.
./tpmctl.sh version
TPM Agent 버전 출력
./tpmctl.sh libversion
TPM Agent 이 사용하는 TPM Stat 라이브러리 빌드 패치 목록과 Tibero의 패치 목록 출력
SQL ID
SQL의 SQL ID
Child Number
SQL ID의 Child Number 값
SQL Text
수행된 SQL 전문
Elapsed Time
수행된 SQL의 Elapsed Time
Machine
연결된 세션의 호스트 이름
Module
dbms_application_info.set_module로 지정된 모듈의 이름
Program
세션의 프로그램 이름
User Name
현재 사용자 이름
OS User
연결된 세션의 OS 계정 이름
CPU Time
CPU 사용 시간
Logical Reads
Logical Reads 값
Physical Reads
Physical Reads 값
Execute Counts
Execute Count 값
Redo Entries
Redo Entries 값
Hard Parse
Hard Parse 값
Cluster Wait
Cluster Wait로 대기한 시간
IO Wait
IO Wait로 대기한 시간
Redo Wait
Redo Wait로 대기한 시간
Standby Wait
Standby Wait로 대기한 시간
Redo TAC Wait
Redo TAC Wait로 대기한 시간
Resource Wait
Resource Wait로 대기한 시간
SQL Wait
SQL Wait로 대기한 시간
SQL TAC Wait
SQL TAC Wait로 대기한 시간
Recovery Wait
Recovery Wait로 대기한 시간
Recovery TAC Wait
Recovery TAC Wait로 대기한 시간
DDL Wait
DDL Wait로 대기한 시간
PSM Wait
PSM Wait로 대기한 시간
Internal Wait
Internal Wait로 대기한 시간
DD Wait
DD Wait로 대기한 시간
XA Wait
XA Wait로 대기한 시간
Backup Wait
Backup Wait로 대기한 시간
Session Wait
Session Wait로 대기한 시간
Space Wait
Space Wait로 대기한 시간
Oracle Linux 8 ~ 10 (64-bit)
Rocky Linux 8 ~ 10 (64-bit)
ProLinux 7.5 (64-bit)
AIX 7.2 (64-bit)
[참고]
C++11 지원 컴파일러
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44) 이상
GLIBCXX_3.4.19 이상
GLIBC_2.17 이상
웹 브라우저
Chrome (최신 버전 사용 권장)
281081
V$TEMPSEG_USAGE 뷰의 SESSION_NUMBER 컬럼 값 표기 잘못되는 문제 개선
[참고] 해당 패치가 없는 경우 [Realtime] > [Usage Monitoring] > [Temp Usage], [Analysis] > [Usage Analysis] > [Temp Usage] 메뉴에 부정확한 정보가 표출될 수 있다.
304981b
SQL Trace 정보 수집 시 machine, OS user 추가 수집
[참고] 해당 패치가 없는 경우 SQL Trace 정보에서 OS User 와 Machine 정보가 부정확하게 표출될 수 있다. 279651f 패치 선적용이 필요하며, 279651e 패치 이하 패치와는 호환되지 않는다.
307175a
SQL Trace 정보 수집 시, 이미 닫힌 세션의 경우 수집되지 않는 문제 수정
[참고] 해당 패치가 없는 경우 세션이 자주 열리고 닫히는 환경의 경우에는 SQL Trace 정보를 상당히 누락하여 수집하게 된다.
328607b
Wait count, wait time 정보 수집 시, wait event 의 wait count, time 보정 문제 수정
[참고] 해당 패치가 없는 경우 wait time과 wait count의 값이 부정확하게 표출될 수 있다.
304770a
TSC 모니터링 전용 패치
[참고] 해당 패치가 없는 경우 아래 정보들이 V$DATABASE 뷰에 없어 primary와 standby가 구분되지 않는 등 TSC 모니터링 관련 정보들이 부정확하게 보여진다.
338513a
실제 TPR 연동에 필요한 패치로, 서버 패치 없이 패키지 생성 스크립트만 실행하면 된다.
338594a
TPR 연동 중 TPR 리포트 파일이 티베로 서버에 생성되는데, 이를 삭제해주는 티베로 패키지의 버그를수정한 패치이다.
[참고] 해당 패치 없어도 TPR 연동 기능은 동작하지만 리포트 파일이 서버에 쌓여서 주기적으로 삭제가 필요하다.
리포트 파일 수동으로 삭제 방법 : 주기적으로 다음과 같이 .tpr 로 시작하는 리포트 파일 삭제.
rm -f .tpr*
149894l
해당 패치가 없는 티베로 6에서 지원하지 않는 쿼리를 TPR 스냅샷 조회시 사용하고 있어 해당 패치가 없으면 해당 패치가 없는 티베로 6에서는 조회가 되지 않는다.
250728f
Standby에서 V$INSTANCE 뷰를 조회할 수 있도록 해주는 패치. 해당 패치가 없으면 해당 인스턴스가 클러스터링이 되지 않는다.
339899a
DB 비정상 종료 상태 판단 로직 개선
[참고] 해당 패치가 없는 경우 kill -9 등 외부 요인으로 DB가 비정상 종료되었을 때, TPM Agent에서 DB 종료 여부가 정확히 판단되지 않을 수 있다.
1) OPEN_MODE에 value 추가
- READ ONLY WITH APPLY
2) PROTECTION_MODE
: Protection mode currently in effect for the database
- UNPROTECTED
- PROTECTION
- AVAILABILITY
- PERFORMANCE
3) DATABASE_ROLE
: Current role of the database
- PRIMARY
- PHYSICAL STANDBY
- LOGICAL STANDBY (TODO)
- SNAPSHOT STANDBY
- CASCADING STANDBY
4) STANDBY_BECAME_PRIMARY_TSN
: TSN at which the physical standby database became primary
5) STANDBY_BECAME_PRIMARY_DATE
: Time at which the physical standby database became primary
TPM Agent 실행시 기존에 실행중인 process가 있으면 해당 프로세스 종료 후 실행할 것인가에 대한 환경 변수, default는 true
X
ENABLE_DEBUG
TPM Agent 실행시 debug port를 열 것인 지에 대한 환경 변수, default는 false
X
참고
현재 Java TPM Agent는 Tibero jdbc Charset 을 동일하게 지원한다.
참고
sqltrace-elapsed-time-threshold 이상 수행된 SQL 실행 정보를 sqltrace-queue-size 크기의 큐에 저장한다.
큐가 모두 차있을 경우 가장 오래된 SQL 실행 정보부터 큐에서 지운다.
TPM Agent에서 sqltrace-freq(ms)마다 SQL 실행 정보를 수집하므로, [세션 개수 * (sqltrace-freq / sqltrace-elapsed-time-threshold) ≤ sqltrace-queue-size] 로 sqltrace-queue-size를 설정해야 정상적인 상황에 유실되는 정보가 없다. sqltrace-queue-size의 경우 위에 언급되어 있듯 개수이므로 정수 값이며, 만약 나누기의 결과가 0.01과 같은 소수일 경우 부등호로 인하여 0.01 이상의 정수인 1이상으로 sqltrace-queue-size를 설정하면 유실이 없다. sqltrace-freq의 범위와 sqltrace-queue-size의 범위는 매뉴얼에 기입된 것을 참고한다. 추가로 부하 상황에서는 권장 값으로 sqltrace-queue-size를 설정하였더라도 수집 누락이 발생할 수 있는데, 예를 들어 Tibero에 부하가 발생하여 CPU 자원을 TPM Agent가 사용하지 못하게 되는 상황이 발생하면 수집 주기가 예기치 못하게 늘어나게 된다. 만약 기존에 1000ms 마다 수집을 하고 있었는데, CPU 자원을 사용하지 못하여 몇 초간 수집을 2000ms 마다 진행하게 될 수 있다. 이럴 경우 권장 값으로 설정하였더라도 SQL Trace 수집에 누락이 발생할 수 있다. 이럴 경우를 대비하여 권장 값보 다 더 많은 sqltrace-queue-size를 할당하여 대비할 수 있으나, 그만큼 메모리를 사용하게 되므로 상황에 맞게 권장 값 기반으로 sqltrace-queue-size를 설정하면 된다.
Java TPM Agent 지원 Charset
환경 변수를 통한 설정
참고
Tibero max session이 2000세션인 기준으로 1000MB 이며, 그 이상이면 max heap size를 증가시켜줘야 한다. 1000세션 당 200MB를 증가시키는 것을 권장한다. (한 세션 당 할당하는 SQL Trace의 개수가 10개라 가정했을 때, 한 세션당 추가로 사용하는 메모리는 약 200KB이다.)
TPM Agent가 SysMaster DB 서버의 COLLECTOR_PORT로 연결하기 위한 포트 번호
Ratio(%)
SQL별 비율
Module
Category에서 선택한 값에 대한 정보
– Module : 모듈 이름
– Program : 프로그램 이름
– Username : 데이터베이스 사용자 이름
– OS user : OS 사용자 이름
– Machine : 관제 DB hostname
Value
선택한 기준(Category, Item)에 대한 총합
Ratio (%)
각 항목별 사용 비율
SQL ID | Child Number
SQL ID와 SQL의 Child Number
SQL Text
SQL 구문
Value
SQL별 선택한 기준(Category, Item)에 대한 값
Item
Category / {CATEGORY}
참고
SQL 수행 이력 수집에 사용하는 티베로 라이브러리 이슈로 일부 정보에 Machine, Module, Program, Username, OS User 항목이 수집되지 않을 수 있다.
{ITEM} / SQL
Item 선택
Category 정보
SQL 정보
Later Free/Total Size
이후 시점의 여유 공간 현황
Earlier Used/Total Size
이전 시점의 사용량 현황
Later Total/Total Size
이후 시점의 사용량 현황
Mounted On
마운트 영역 이름
FileSystem Name
파일 시스템 이름
Earlier Time
이전 시점
Later Time
이후 시점
Earlier Free/Total Size
Log Time
수집 시간
Used
사용량
Free
사용 가능한 양
Filesystem Info
Filesystem Info
이전 시점의 여유 공간 현황
항목
설명
SID
세션의 ID
Serial#
세션의 시리얼 번호
Elapsed Time
세션의 현재 수행 중인 SQL의 Elapsed Time
Username
현재 사용자 이름
Program
사용자는 Elapsed Time의 기준을 설정할 수 있으며, 설정된 범위로 어떤 세션이 오래 수행되었는지를 색상을 통해 직관적으로 파악할 수 있다.
세션을 Kill 시킬 수 있다. Session Monitoring 기능에 대한 권한(Privileges)이 Full로 설정된 유저만 수행할 수 있으며, Session 목록에서 특정 세션을 클릭해야만 해당 버튼이 표시된다.
[Kill Session] 버튼을 클릭하면 Kill Session 팝업창이 열린다. 이때 해당 세션을 Kill 하거나 동작을 취소할 수 있다.
다음은 Kill Session 팝업창에서 제공하는 정보에 대한 설명이다.
항목
설명
SID / Serial#
세션의 ID / 세션의 시리얼 번호
Status
세션의 상태
User Name
세션 사용자 이름
Session 모니터링 주요기능
Session 목록
참고
Session 정보 수집에 사용하는 티베로 라이브러리 이슈로 일부 정보에 Username, Program, Module, Schema, Terminal, Machine, OS User 등 항목이 수집되지 않을 수 있다.
Long running session 모니터링
Kill Session
참고
해당 인스턴스의 세션을 종료할 수 있다(Session Kill). Configurable Privileges 중 선택한 인스턴스에 대해 [Kill Session] 권한이 부여된 사용자에 한해 사용할 수 있는 기능이다.
Partition Name
파티션 이름
Used/Total Size
해당 세그먼트가 차지하는 공간의 비율
Prev SQL ID
세션이 이전에 수행했던 SQL의 SQL ID
REDO_LOG_SIZE
Redo 로그 사이즈
REDO_WRITE_MULTI
Redo 로그 버퍼의 내용 기록을 요청한 세션이 다수인 경우의 횟수
USER_ROLLBACKS
사용자가 롤백을 요청한 횟수
SERIAL_NUMBER
세션의 시리얼 번호
CONSISTENT_BLOCK_GETS_EXAMINE_NOWAIT
Consistent Read Mode examine에 대한 nowait의 횟수
CURRENT_BLOCK_GETS
Current 상태에 있는 Block의 데이터를 읽은 횟수
(current block gets : 최신 버전의 Block을 버퍼 Cache에서 찾아 pin하는 것과 관련된 수치)
REQ_SERVICE_TIME
DB Time (실제 Working 스레드가 일한 시간의 총합)
CURRENT_BLOCK_GETS_EXAMINE
Index branch peep이나 데이터 Block의 Rowlock 정보를 Block pin없이 빠르게 얻어오는 Current examine 기능의 사용 횟수
BLOCK_DISK_READ
디스크에서 Block을 읽어 버퍼 Cache에 올리기를 기다리는 시간
EXECUTE_COUNT
SQL 실행 횟수
CONSISTENT_BLOCK_GETS_EXAMINE
Index block unique key search 등에서 Pin을 잡지 않고 필요한 값을 빠르게 얻어오는 Consistent Read(CR) examine 기능을 사용한 횟수
REDO_WRITE
Redo 버퍼의 로그 Block들을 디스크에 기록하는데 걸린 시간
LOGICAL_READS
Memory I/O로 읽은 Block 개수
HARD_PARSE_COUNT
Hard Parse 횟수
PHYSICAL_READS
Disk I/O로 읽은 Block 개수
DB_CPU_TIME
CPU 사용 시간
CONSISTENT_BLOCK_GETS
Consistent Read (CR) mode로 읽은 Block 개수
PHYSICAL_WRITE
디스크에 write한 Block 개수
BUFFER_CACHE_HIT
Buffer Cache 적중률
CONSISTENT_MULTI_BLOCK_GETS
Multi Block에 대해 CONSISTENT_BLOCK_GETS을 수행한 횟수
CURRENT_BLOCK_GETS_EXAMINE_NOWAIT
current block gets examine에 대한 nowait 횟수
USER_COMMIT
세션의 User Commit 횟수
CURRENT_BLOCK_GETS_NOWAIT
current block gets에 대한 nowait 수행 횟수 (대기 없이 current block get을 수행한 횟수)
MULTI_BLOCK_DISK_READ
Multi Block을 디스크에서 Read한 횟수
이전 시점의 여유 공간 현황
Later Free/Total Size
이후 시점의 여유 공간 현황
Earlier Used/Total Size
이전 시점의 사용량 현황
Later Total/Total Size
이후 시점의 사용량 현황
Free
사용 가능한 양
Sub Object Name
Invalid Object의 Sub Object 이름
Object Type
Invalid Object의 타입
Status
Invalid Object의 상태 (INVALID)
Last DDL Time
Invalid Object의 최근 DDL이 실행된 시간
Segment Usage
글로벌 내비게이션 바에서 [Analysis] > [Usage Analysis] > [Segment Usage] 메뉴를 클릭하면 Segment Usage 화면이 열린다.
Segment Usage 전체 화면
Overview
조회하기 원하는 날짜를 선택할 수 있는 기능이 있다. 조회한 기간의 Segment usage 목록에 간단하게 사용량 증감을 보여준다.
Segment Usage Overview
Segment Usage
이 화면에서는 지정한 기간 동안의 세그먼트 이름별 크기의 변화량을 확인할 수 있다.
Segment Usage
다음은 Segment Usage 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Segment Usage Header에는 데이터 조회를 위한 필터링을 선택할 수 있는 기능이 있다.
Order by 우측의 드롭박스를 이용해 원하는 column으로 정렬할 수 있다.
그 오른쪽의 드롭박스를 이용해 사용자가 보기를 원하는 top 개수를 설정할 수 있다.
Segment Usage 에서 특정 데이터 클릭 시 해당 세그먼트의 일자별 크기 변화를 상세하게 확인할 수 있다. 이때 오른쪽의 그래프를 통해 크기 변화량을 한눈에 파악할 수 있다.
DEBUG 이상 설정을 할 경우 로그양이 많아져 TPM Agent 에 설정한 주기 안에 수집을 하지 못하여 데이터 누락이 발생할 수 있음. 그로 인하여 실시간 데이터 모니터링 중 데이터가 조회되지 않는 현상이 있을 수 있음. 따라서 운영 환경에서는 해당 설정을 하지 않는 것을 권고하며, 이슈 분석을 위해서만 해당 로그 레벨을 설정.
SKIP_DB_USER_COUNT_MIGRATION_PATCH, SKIP_DAILY_SEGMENT_MIGRATION_PATCH 파라미터는 신규 설치 시에는 필요하지 않고, SysMaster DB v8.1.2 이하 기설치 환경에서 버전 업데이트를 수행하는 경우에만 적용이 필요하다.
각 파라미터를 별도로 설정하지 않으면, 버전 업데이트 시 해당 패치가 자동으로 수행되면서 기수집 데이터를 기반으로 DB_USER_COUNT, DAILY_SEGMENT 데이터를 생성한다.
이때, 기수집 데이터양에 따라 패치 수행에 장시간 소요될 수 있으므로, 해당 파라미터를 통해 사용자가 선택적으로 해당 패치 수행 여부를 설정할 수 있다.
v8.1.3 이상의 SysMaster DB 서비스 이용 시, DB_USER_COUNT, DAILY_SEGMENT 데이터는 각각 다음 메뉴에서 사용된다.
1. DB_USER_COUNT 데이터 - Analysis > All Session Flow 메뉴
2. DAILY_SEGMENT 데이터 - Analysis > Segment Usage 메뉴
따라서 해당 패치를 생략하도록 설정(각 파라미터를 true로 설정하고 주석 제거)하는 경우, 위 1, 2의 메뉴에서 과거(해당 업데이트 이전에 수집된) 데이터가 조회되지 않는다. 그러므로 기본적으로는 해당 파라미터를 별도로 설정하지 않는 것을 권장한다.
반면 다음과 같은 경우, 사용자는 해당 파라미터를 true로 설정(주석 제거)하여 앞서 설명한 패치를 생략할 수 있다.
위 1, 2의 메뉴에서 과거(SysMaster DB v8.1.2 이하에서 수집된) 데이터 조회가 불필요한 경우
(SysMaster DB 서버 자원 제한 등의 이유로) 해당 데이터 생성 패치 진행 시 장시간 SysMaster DB 사용이 불가능해지는 상황이 우려되고, 이를 방지해야만 하는 경우
사용자는 필요에 따라, 해당 두 파라미터 중 원하는 파라미터만 선택적으로 설정하는 것도 가능하다.
참고 2
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH, RETENTION_DAY_FOR_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 파라미터는 신규 설치 시에는 필요하지 않고, SysMaster DB v8.2.1 이하 기설치 환경에서 버전 업데이트를 수행하는 경우에만 적용이 필요하다.
각 파라미터를 별도로 설정하지 않으면, v8.3.0에서 신규 스키마가 적용된 테이블을 대상으로 v8.2.1 이하 버전에서의 기수집 데이터를 마이그레이션하는 패치가 자동으로 수행된다.
v8.3.0에서 신규 스키마가 적용된 테이블 목록은 다음과 같다.
SQL
SQL_TEXT
SQL_PLAN
DB_SESSION
SESSION_TEMP
SESSION_UNDO
LOCK
SQL_TRACE
위 테이블에 대한 마이그레이션 과정은 기수집 데이터양에 따라 장시간 소요될 수 있다.
사용자는 필요에 따라, 다음과 같이 별도 파라미터 설정을 통해 사용자가 선택적으로 해당 패치 수행 여부를 설정할 수 있다.
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH
v8.3.0에서 신규 스키마가 적용된 테이블에 대해 v8.2.1 이하 기수집 데이터를 마이그레이션하는 패치 수행 여부를 설정
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 파라미터를 true로 설정(주석 제거) 시, 패치 대상 테이블 전체에 대한 마이그레이션이 수행되지 않음.
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 설정을 통해 마이그레이션을 수행하지 않은 경우, v8.2.1 이하에서 수집된 데이터가 삭제되므로 더 이상 조회되지 않는다.
그러므로 기본적으로는 해당 파라미터를 별도로 설정하지 않는 것을 권장한다.
반면 다음과 같은 경우, 사용자는 해당 마이그레이션 생략을 고려할 수 있다.
v8.3.0에서 신규 스키마 적용 대상 테이블의 과거(SysMaster DB v8.2.1 이하에서 수집된) 데이터 조회가 불필요한 경우
(SysMaster DB 서버 자원 제한 등의 이유로) 해당 데이터 생성 패치 진행 시 장시간 SysMaster DB 사용이 불가능해지는 상황이 우려되고, 이를 방지해야만 하는 경우
이때, 사용자는 아래 파라미터 설정을 통해 (마이그레이션 패치를 수행하되,) 패치 수행 대상 데이터 범위(일 단위 기간)를 별도로 설정할 수도 있다.
v8.3.0에서 신규 스키마가 적용된 테이블에 대한 v8.2.1 이하 기수집 데이터 중 마이그레이션 대상 데이터 범위(일 단위 기간) 설정
예를 들어, RETENTION_DAY_FOR_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 파라미터를 7로 설정(주석 제거)하는 경우, v8.2.1 이하에서 수집된 데이터 중 최근 7일 이내의 데이터에 대해서만 마이그레이션
상기 설명을 참고하여, 사용자는 운영 환경에 맞는 적절한 파라미터 설정을 선택, 적용할 수 있다.
5. 설치 파라미터 설정 - 포트
6. Meta DB 및 Repository DB 파라미터 설정
참고
Meta DB 및 Repository DB 파라미터 변경이 필요한 경우, 관련 파라미터 설정은 OpenSQL 사용 가이드를 참조할 수 있다. 그러나 관련 파라미터 설정을 임의 수정하는 경우, SysMasterDB 서버의 정상 동작이 보장되지 않는다. 따라서 위 표에 명시된 파라미터 외 다른 파라미터는, 기본 제공 설정값을 그대로 사용하는 것을 권장한다.
설치 및 파라미터 설정
Docker-compose 및 Podman-compose 환경에서 SysMaster DB 8.3를 설치하는 과정이다.
참고
Podman-compose는 Docker-compose 스타일의 yml 파일을 지원하기 때문에 동일한 yml 파일로 docker / podman 환경에서 모두 구동할 수 있다.
1. Docker / Podman 이미지 로드
설치 파일이 준비된 디렉터리에서 아래의 명령을 수행하여 Docker / Podman 이미지를 로드한다.
Docker:
docker load -i sysmaster-db-{version}.tar
Podman:
podman load -i sysmaster-db-{version}.tar
이때 로드된 컨테이너 이미지 목록은 다음과 같다.
sysmaster-db-client:{version}
sysmaster-db-sdm:{version}
sysmaster-db-tibero-master:{version}
sysmaster-db-collector:{version}
sysmaster-db-analyzer:{version}
sysmaster-db-tiberoopensql-postgres:{version}
sysmaster-db-schema-registry:{version}
sysmaster-db-kafka-loggable:{version}
sysmaster-db-zookeeper-loggable:{version}
설치 디렉터리에서 docker-compose.yml 파일을 열어 Docker-compose / Podman-compose 환경에 생성하는 10개의 서비스들에 대해 정의한다. 각 서비스에 대한 설명은 다음과 같다.
서비스
설명
설치 디렉터리에서 .env 파일을 열어 SysMaster DB 8.3의 설치에 필요한 파라미터 값을 설정한다.
이때 각 파라미터들은 개행으로 구분하며, 파라미터 이름과 값 사이에는 공백 없이 등호를 하나 입력한다.
해당 과정에서 설정하는 파라미터에 대한 설명은 다음과 같다.
파라미터 이름
설명
초기값
Rootless podman 환경에서는 NGINX_RESOLVER 패러미터 설정이 별도로 필요하다. 이는 시스마스터 기동 후 개별 컨테이너가 재기동 되는 상황에서의 재연결을 위해 필요하며 sysmaster 네트워크의 gateway ip 주소를 사용한다. 해당 값은 환경 / podman 기동마다 달라질 수 있다.
아래 예시에서 NGINX_RESOLVER=10.89.0.1로 설정 후 시스마스터를 부팅하는 과정을 보여준다.
Podman bridge 네트워크 환경에서 SysmasterDB 컨테이너가 동일 호스트에 설치된 관제 DB에 호스트 IP(예: 192.168.141.12) 로 접속을 시도할 경우, 컨테이너 → 호스트 방향의 Hairpin NAT(DNAT loopback) 가 기본적으로 보장되지 않아 Connection Refused가 발생할 수 있다.
이는 동일 서버 내 구성이라도 컨테이너와 호스트가 서로 다른 네트워크 네임스페이스에 존재하기 때문에 발생하는 Podman bridge 구조적 제약이다.
예시로, 컨테이너에 접속하여 telnet 192.168.141.12 40010을 수행하면 Connection refused로 실패하고, Host Gateway 경로 적용 후 telnet host.docker.internal 40010은 정상 접속되는 것으로 확인할 수 있다.
해결을 위해 podman-compose.yml에 Host Gateway 매핑을 추가하고, 관제 DB 접속 주소를 호스트 IP → host.docker.internal 로 변경한다.
아래 예시처럼 서비스에 extra_hosts를 추가한다.
그리고 아래처럼 관제 DB IP를 host.docker.internal 로 설정하면 동일 호스트에 설치된 관제 DB를 등록 할 수 있다.
설치 디렉터리에서 meta.conf, repo.conf 파일을 통해 Meta DB 및 Repository DB 파라미터 값을 확인할 수 있다. 해당 conf 파일은 기본적으로 제공되는 설정값을 사용하되, 다음에서 설명하는 파라미터는 필요 시 구동 환경에 맞게 사용자가 직접 설정해준다.
파라미터 이름
설명
이 수행됨.
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 파라미터를 true로 설정(주석 제거)한 경우, 본 파라미터 설정은 무시됨.
collector
관제 데이터베이스로부터 데이터를 수집하는 서버
analyzer
수집한 정보를 가공해 분석 및 저장하는 서버
metadb
UI 관련 설정 정보를 저장하는 DB 서버
repodb
관제 데이터베이스 수집 데이터를 저장하는 DB 서버
zookeeper
Kafka Broker 서버의 상태 관리
broker
Kafka Broker 서버
schema-registry
Kafka 메시지 프로토콜 관리
ADMIN_PASSWORD
Admin 계정의 암호
admin
COLLECTOR_PORT
수집 모듈(TPM Agent)이 접속할 포트 번호
[참고] 관제 DB에서 접속할 수 있도록 SysMaster 서버에서 열려 있어야 함
8292
METADB_PORT
Meta DB의 접속 포트 번호
25432
METADB_USER
Meta DB의 슈퍼 사용자 이름
sysmaster
METADB_PASSWORD
Meta DB의 슈퍼 사용자 암호
sysmaster
METADB_PATH
Meta DB의 데이터 파일 경로
./meta
METADB_CONF_PATH
Meta DB의 설정 파일 경로
./meta.conf
REPODB_PORT
Repository DB의 접속 포트 번호
15432
REPODB_USER
Repository DB의 슈퍼 사용자 이름
sysmaster
REPODB_PASSWORD
Repository DB의 슈퍼 사용자 암호
sysmaster
REPODB_PATH
Repository DB의 데이터 파일 경로
./repo
REPODB_CONF_PATH
Repository DB의 설정 파일 경로
./repo.conf
RETENTION_DAY
수집 정보의 보관 주기
7
LOG_PATH
로그 생성 위치
./logs
LOG_RETENTION_DAY
로그 파일 보관 주기
1
LOG_FILE_SIZE
로그 파일 하나의 최대 크기
100MB
LOG_TOTAL_SIZE
모듈 별 최대 로그 저장 용량
1000MB
LOG_LEVEL
모듈 별 로그 레벨
info
CONTAINER_LOG_PATH
컨테이너 내부 로그 경로 설정
/sysmaster/logs
KAFKA_MESSAGE_MAX_BYTES
카프카 메시지 사이즈 설정,
1MB ~ 2GB 범위로 설정 가능
20971520 Byte
TIME_ZONE
SysMaster DB 서버 Time-Zone 설정
Asia/Seoul
SQL_FLUSH_THRESHOLD
SQL 관련 하나의 메시지가 담을 수 있는 정보 개수 제한. SQL Plan의 경우 해당 값의 10배로 제한한다.
관제 DB 당 100개
SQL_RS_FETCH_SIZE
한 번에 관제 DB 로부터 조회하는 SQL 관련 정보 row 개수
관제 DB 당 1000개
SKIP_DB_USER_COUNT_MIGRATION_PATCH
(기설치 환경 패치 시,) 기수집 데이터 기반 Repository DB의 DB_USER_COUNT 테이블 데이터 생성 패치 생략 여부. 필요 시 아래 [참고 1]을 확인하고 설정.
true (주석 처리를 통한 미적용)
SKIP_DAILY_SEGMENT_MIGRATION_PATCH
(기설치 환경 패치 시,) 기수집 데이터 기반 Repository DB의 DAILY_SEGMENT 테이블 데이터 생성 패치 생략 여부. 필요 시 아래 [참고 1]을 확인하고 설정.
true (주석 처리를 통한 미적용)
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH
(기설치 환경 패치 시,) v8.3.0 신규 스키마 적용 테이블 대상 v8.2.1 이하 기수집 데이터 마이그레이션 생략 여부. 필요 시 아래 [참고 2]를 확인하고 설정.
tibero-master:
image: sysmaster-db-tibero-master:8.3.4
container_name: tibero-master
hostname: tibero-master
environment:
<<: *common-env
# (기타 환경변수 생략)
networks:
sysmaster:
aliases:
- tibero-master
restart: on-failure
# 이 부분 추가
extra_hosts:
- "host.docker.internal:host-gateway"
pg_max_connections
Meta DB(또는 Repository DB)의 최대 커넥션 수
pg_owner_id
해당 DB 데이터 디렉토리 접근 권한 설정을 위한 Host OS의 사용자 ID(uid). 호스트 머신의 특정 유저에서 컨테이너 DB 디렉토리로 직접 접근하고 싶을 경우 해당 유저의 사용자 ID로 설정한다.
pg_group_id
해당 DB 데이터 디렉토리 접근 권한 설정을 위한 Host OS의 사용자 그룹 ID(gid). 호스트 머신의 특정 유저에서 컨테이너 DB 디렉토리로 직접 접근하고 싶을 경우 해당 유저의 그룹 ID로 설정한다.
참고
docker images | grep sysmaster 명령어를 통해 컨테이너 이미지 목록을 확인할 수 있다.
2. Docker / Podman 서비스 정의
3. 설치 파라미터 설정
참고
.env 파일이 없다면 vim .env 명령어를 이용해 생성한다.
참고 1
SKIP_DB_USER_COUNT_MIGRATION_PATCH, SKIP_DAILY_SEGMENT_MIGRATION_PATCH 파라미터는 신규 설치 시에는 필요하지 않고, SysMaster DB v8.1.2 이하 기설치 환경에서 버전 업데이트를 수행하는 경우에만 적용이 필요하다.
각 파라미터를 별도로 설정하지 않으면, 버전 업데이트 시 해당 패치가 자동으로 수행되면서 기수집 데이터를 기반으로 DB_USER_COUNT, DAILY_SEGMENT 데이터를 생성한다.
이때, 기수집 데이터양에 따라 패치 수행에 장시간 소요될 수 있으므로, 해당 파라미터를 통해 사용자가 선택적으로 해당 패치 수행 여부를 설정할 수 있다.
v8.1.3 이상의 SysMaster DB 서비스 이용 시, DB_USER_COUNT, DAILY_SEGMENT 데이터는 각각 다음 메뉴에서 사용된다.
1. DB_USER_COUNT 데이터 - Analysis > All Session Flow 메뉴
2. DAILY_SEGMENT 데이터 - Analysis > Segment Usage 메뉴
따라서 해당 패치를 생략하도록 설정(각 파라미터를 true로 설정하고 주석 제거)하는 경우, 위 1, 2의 메뉴에서 과거(해당 업데이트 이전에 수집된) 데이터가 조회되지 않는다. 그러므로 기본적으로는 해당 파라미터를 별도로 설정하지 않는 것을 권장한다.
반면 다음과 같은 경우, 사용자는 해당 파라미터를 true로 설정(주석 제거)하여 앞서 설명한 패치를 생략할 수 있다.
위 1, 2의 메뉴에서 과거(SysMaster DB v8.1.2 이하에서 수집된) 데이터 조회가 불필요한 경우
(SysMaster DB 서버 자원 제한 등의 이유로) 해당 데이터 생성 패치 진행 시 장시간 SysMaster DB 사용이 불가능해지는 상황이 우려되고, 이를 방지해야만 하는 경우
사용자는 필요에 따라, 해당 두 파라미터 중 원하는 파라미터만 선택적으로 설정하는 것도 가능하다.
참고 2
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH, RETENTION_DAY_FOR_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 파라미터는 신규 설치 시에는 필요하지 않고, SysMaster DB v8.2.1 이하 기설치 환경에서 버전 업데이트를 수행하는 경우에만 적용이 필요하다.
각 파라미터를 별도로 설정하지 않으면, v8.3.0에서 신규 스키마가 적용된 테이블을 대상으로 v8.2.1 이하 버전에서의 기수집 데이터를 마이그레이션하는 패치가 자동으로 수행된다.
v8.3.0에서 신규 스키마가 적용된 테이블 목록은 다음과 같다.
SQL
SQL_TEXT
SQL_PLAN
DB_SESSION
SESSION_TEMP
SESSION_UNDO
LOCK
SQL_TRACE
위 테이블에 대한 마이그레이션 과정은 기수집 데이터양에 따라 장시간 소요될 수 있다.
사용자는 필요에 따라, 다음과 같이 별도 파라미터 설정을 통해 사용자가 선택적으로 해당 패치 수행 여부를 설정할 수 있다.
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH
v8.3.0에서 신규 스키마가 적용된 테이블에 대해 v8.2.1 이하 기수집 데이터를 마이그레이션하는 패치 수행 여부를 설정
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 파라미터를 true로 설정(주석 제거) 시, 패치 대상 테이블 전체에 대한 마이그레이션이 수행되지 않음.
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 설정을 통해 마이그레이션을 수행하지 않은 경우, v8.2.1 이하에서 수집된 데이터가 삭제되므로 더 이상 조회되지 않는다.
그러므로 기본적으로는 해당 파라미터를 별도로 설정하지 않는 것을 권장한다.
반면 다음과 같은 경우, 사용자는 해당 마이그레이션 생략을 고려할 수 있다.
v8.3.0에서 신규 스키마 적용 대상 테이블의 과거(SysMaster DB v8.2.1 이하에서 수집된) 데이터 조회가 불필요한 경우
(SysMaster DB 서버 자원 제한 등의 이유로) 해당 데이터 생성 패치 진행 시 장시간 SysMaster DB 사용이 불가능해지는 상황이 우려되고, 이를 방지해야만 하는 경우
이때, 사용자는 아래 파라미터 설정을 통해 (마이그레이션 패치를 수행하되,) 패치 수행 대상 데이터 범위(일 단위 기간)를 별도로 설정할 수도 있다.
v8.3.0에서 신규 스키마가 적용된 테이블에 대한 v8.2.1 이하 기수집 데이터 중 마이그레이션 대상 데이터 범위(일 단위 기간) 설정
예를 들어, RETENTION_DAY_FOR_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 파라미터를 7로 설정(주석 제거)하는 경우, v8.2.1 이하에서 수집된 데이터 중 최근 7일 이내의 데이터에 대해서만 마이그레이션
상기 설명을 참고하여, 사용자는 운영 환경에 맞는 적절한 파라미터 설정을 선택, 적용할 수 있다.
3.1 Podman 환경에서 DNS Resolver 설정
3.2 Podman 환경에서 SysMasterDB 서버와 동일 호스트에 설치된 관제 DB 등록
설정 방법 (YML 예시 + 관제 DB 접속 주소 변경)
4. Meta DB 및 Repository DB 파라미터 설정
참고
Meta DB 및 Repository DB 파라미터 변경이 필요한 경우, 관련 파라미터 설정은 OpenSQL 사용 가이드를 참조할 수 있다. 그러나 관련 파라미터 설정을 임의 수정하는 경우, SysMaster DB 서버의 정상 동작이 보장되지 않는다. 따라서 위 표에 명시된 파라미터 외 다른 파라미터는, 기본 제공 설정값을 그대로 사용하는 것을 권장한다.
특히 Podman-compose 환경에서의 설치 시, pg_owner_id와 pg_group_id 값을 직접 설정(변경)하는 경우 정상 동작하지 않을 수 있다. Podman의 컨테이너는 Rootless모드로 동작하고, 컨테이너 내부의 root (owner_id = 0, group_id = 0)가 호스트 머신의 유저에 대응된다. 하지만 OpenSQL이 root 권한 상태에서의 설치 및 기동을 허용하고 있지 않기 때문에 기본 설정값을 사용하는 것을 권장한다.
또한 Podman-compose 환경에서는 Host OS에서 조회되는 meta, repo 디렉터리의 소유자가 pg_owner_id, pg_group_id에 설정한 UID/GID에 대응하는 사용자명으로 표시되지 않을 수 있다.
이는 Podman rootless 환경의 user namespace 매핑 방식에 따른 정상 동작이다. Podman rootless 환경에서는 컨테이너 내부의 UID/GID가 Host OS의 UID/GID와 1:1로 동일한 사용자를 의미하지 않을 수 있다.
예를 들어 Host OS의 sysmaster 사용자가 uid=1008이고 pg_owner_id를 1008로 설정하더라도, 컨테이너 내부의 uid=1008은 Host OS에서 sysmaster가 아닌 subordinate UID로 매핑될 수 있다. 따라서 Host OS에서 meta, repo 디렉터리를 ls -al 명령으로 조회할 경우 소유자가 sysmaster가 아닌 숫자 UID/GID로 표시될 수 있다.
이는 권한 변경 실패나 제품 오류가 아니며, 컨테이너 내부에서는 매핑된 UID/GID 기준으로 정상 접근된다.
Host OS에서 숫자 UID/GID로 표시되는 데이터 디렉터리를 chown 등으로 임의 변경하지 않는 것을 권장한다. 임의로 소유자를 변경할 경우, 컨테이너 내부의 UID/GID 매핑과 파일 권한이 불일치하여 Meta DB 또는 Repository DB가 정상 기동하지 않을 수 있다.
이 수행됨.
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 파라미터를 true로 설정(주석 제거)한 경우, 본 파라미터 설정은 무시됨.
Performance Trend
Performance Trend에서는 Overall 차트를 통해 각 지표의 변화 추이를 거시적 시점에서 확인하는 기능과 타임 슬라이스를 사용해 문제가 되는 시점의 초단위까지 세션 및 SQL 지표까지 확인할 수 있는 기능을 제공한다. 이를 통해 문제가 발생한 시점 및 문제 원인 파악까지 한번에 진행할 수 있다.
Performance Trend 메뉴에 처음 진입하면 Overall 차트를 확인할 수 있다. 각 인스턴스 별 시간 구간 에서 CPU / Memory / 세션 / Wait Class 별 추이를 확인 할 수 있다.
Overall 차트 소개
Performance Trend의 Overall 차트에서는 조회 기간 동안의 CPU, Memory, Running Session, Wait Class의 값 변화 추이 및 요약 정보를 보여준다. 이때 시간, 날짜 단위별로 상세 분석할 수 있는 기능을 제공하며, 그래프별로 차트 간격(Interval)과 집계 방식(Aggregation)을 드롭다운 메뉴로 선택하여 확인할 수 있다. 또한 마우스를 보고자 하는 지표에 올리면 해당 지표 값을 확인할 수 있다.
차트를 클릭시 해당 시점의 1시간 범위 Time Slice 페이지로 전환되어 더 자세한 분석을 진행할 수 있다.
CPU (Sys + User + IO)
설정한 시간 구간 동안 CPU 사용량 변화 추이를 나타낸다.
선택한 분석 기간 동안의 Memory 사용량 추이를 확인할 수 있다.
선택한 분석 기간 동안의 Running Session Count 추이를 확인할 수 있다.
선택한 분석 기간 동안 발생한 Wait Class Time의 추이를 확인할 수 있다.
Performance Chart는 Performance Trend에서 Time Slice 된 기간으로 조회되는 화면으로 CPU, Memory, Session, Wait Class 지표별 상세 분석이 가능하다.
상단과 중단 차트에서는 카테고리별로 세션 지표, DB 성능 통계 지표, 메모리 사용량, Wait Class 별 퍼센트 분포, 주요 Wait Event 별 Time / Count 지표, Wait Class 별 소모된 시간 정보의 시간 당 변화 추이를 확인할 수 있다.
상단의 분단위 차트 클릭시 중간에 초 단위의 차트 그래프가 나타난다. 해당 초 단위 차트를 클릭하고 카테고리를 선택하면 해당 시점의 세션 관련 지표, 수행 SQL 관련 지표, Lock 관련 지표, Wait Event 관련 지표를 확인 할 수 있다.
다음은 Performance Chart 화면 상단에서 제공하는 차트에 대한 설명이다.
시간 구간별 Running Session들의 정보를 Bar Chart로 제공한다. 이때 오른쪽 상단의 범례를 선택하여 원하는 지표를 선별할 수 있다. 또한 콤보박스를 통해 MIN, MAX, AVG 집계 방식을 선택 할 수 있다.
지표(Logical Reads, Physical Reads, Redo Entries 등)별로 시간 구간 별 정보를 Bar Chart로 제공한다. 이때 오른쪽 상단의 범례를 선택하여 원하는 지표를 선별할 수 있다. 또한 콤보박스를 통해 MIN, MAX, AVG 집계 방식을 선택 할 수 있다.
시간 구간별 CPU 사용률 정보를 제공한다. 이때 오른쪽 상단의 범례를 선택하여 System, IO, User Usage의 CPU 사용률에 대한 지표를 선별할 수 있다. 또한 콤보박스를 통해 MIN, MAX, AVG 집계 방식을 선택 할 수 있다.
시간 구간별 Memory 사용률 정보를 제공한다. 이때 오른쪽 상단의 범례를 선택하여 원하는 지표를 선별할 수 있다. 또한 콤보박스를 통해 MIN, MAX, AVG 집계 방식을 선택 할 수 있다.
Wait Class를 기반으로 같은 데이터지만 직관적인 분석이 가능하도록 백분율(%) 형태로 보여준다. 이 때 오른쪽 상단의 범례를 선택하여 원하는 지표를 선별할 수 있다. 또한 콤보박스를 통해 MIN, MAX, AVG 집계 방식을 선택 할 수 있다.
주요 Wait Event에 대한 시간 구간별 정보를 Bar Chart로 제공한다. 해당 시간에 몇 초 동안 Event가 발생했는지 확인할 수 있다. 이때 오른쪽 상단의 범례를 선택하여 원하는 지표를 선별할 수 있다. 또한 콤보박스를 통해 MIN, MAX, AVG 집계 방식을 선택 할 수 있다.
주요 Wait Event에 대한 시간 구간별 정보를 Bar Chart로 제공한다. 해당 시점에 Wait Event가 몇 번 발생했는지 확인할 수 있다. 이때 오른쪽 상단의 범례를 선택하여 원하는 지표를 선별할 수 있다. 또한 콤보박스를 통해 MIN, MAX, AVG 집계 방식을 선택 할 수 있다.
Wait Event의 Class화된 정보를 Stacked Bar Chart 형태로 제공한다. 이때 오른쪽 상단의 범례를 선택하여 원하는 지표를 선별할 수 있다. 또한 콤보박스를 통해 MIN, MAX, AVG 집계 방식을 선택 할 수 있다.
다음은 Performance Chart 클릭 시 하단에 제공되는 테이블 카테고리에 관한 설명이다.
Performance Chart의 Snapshot 영역에서는 해당 시점의 Running Session의 Wait Class별 요약 정보와 각 세션의 SQL 수행 이력 등 해당 구간의 세션 정보들을 제공한다.
항목
설명
Top Process 카테고리에서는 시간 구간별로 OS Level의 CPU 와 Memory 자원 사용량이 많은 프로세스 정보를 집계해서 프로세스별 사용 Resource를 보여준다.
항목
설명
Performance Chart의 Session 영역에서는 상단의 그래프를 클릭했을 때 해당 시간 구간의 Running Session목록을 보여준다.
항목
설명
Performance Chart의 SQL 영역에서는 상단의 그래프를 클릭했을 때 해당 구간의 각 세션에서 수행한 SQL 목록을 보여준다. SQL ID 클릭시 해당 SQL 에 대한 SQL Detail 페이지로 전환된다.
항목명
설명
Performance Chart의 All SQL 영역에서는 상단의 그래프를 클릭했을 때 해당 시간 구간 동안 수행된 모든 SQL 목록을 보여준다.
항목
설명
Performance Chart의 Lock Tree 영역에서는 상단의 그래프를 클릭했을 때 해당 구간 동안 세션 간의 Transaction Lock으로 인해 발생한 Wait 상황을 Tree 형태로 제공한다.
항목
설명
Performance Chart의 Wait Detail 영역에서는 상단의 그래프를 클릭했을 때 1분 동안 발생한 Wait Event를 집계해서 보여주고, 특정 Wait Event를 클릭하면 Wait Event가 발생했던 세션 목록을 오른쪽에 보여준다.
항목
설명
항목
설명
User Name
현재 사용자 이름
Program
세션의 프로그램 이름
Module
dbms_application_info.set_module로 지정된 모듈의 이름
Logical Reads
세션의 Logical Reads 값
Physical Reads
세션의 Physical Reads 값
Execute Counts
세션의 Execute Count 값
Redo Entries
세션의 Redo Entries 값
Hard Parse
세션의 Hard Parse 값
Wait Event
세션이 대기하는 Wait Event 타입
Wait Time
세션이 Wait Event로 대기한 시간
Status
세션의 상태
-READY : 세션 준비 상태
-RUNNING : 세션 Running 상태
-TX_RECOVERING : 트랜젝션 복구 중 상태
-SESS_CLEANUP : 세션 리소스 정리 중 상태
-ASSIGNED : 세션에 스레드가 할당되었지만 아직 준비되지 않은 상태 - CLOSING : 세션이 닫힌 상태
-ROLLING_BACK : PE명세 레벨 트렌젝션의 Slave가 롤백된 상태
State
작업 스레드의 상태
-INVALID : 초기화 되지 않음
-NEW : 생성 중
-IDLE : 실행될 준비가 됨
-RUNNING : 실행 중
-WAITING : 내부 메시지 대기 중
-RECV_WAITING : 클라이언트 메시지 대기 중
-STOP_BY_MTHR : 모니터링 프로세스에 의해 중지됨
-DEAD : Dead 상태
PGA Memory (Session)
세션의 PGA 메모리 사용량
SQL Trace
세션에서 SQL 추적을 사용할지 여부
Wlock Wait
세션이 대기 중인 Wait 타입
Audsid
세션의 두 번째 시리얼 번호
User ID
User ID 정보
IP Address
User 접속 IP 주소
TX_UNDO_BLK_CNT
Transaction Undo Block 개수
TX_UNDO_REC_CNT
Transaction Undo Record 개수
Command
현재 실행 중인 SQL 타입
-0 : 실행 중인 SQL 없음
-1 : SELECT
-2 : INSERT
-3 : UPDATE
-4 : DELETE
-5 : MERGE
-6 : CALL
Schema
세션의 스키마
Thr Type
세션의 타입
-WTHR : Working thread
-CTHR : Control thread
-LGWR : Log writing process
-CKPT : Checkpoint process
-LARC : Log archive
-AGENT : Sequence process
-MTHR : Monitoring process
-DBWR : Datablock writing process
-LNW : Log network writing process
SQL ID
세션이 수행 중인 SQL의 SQL ID
Child Number
세션이 수행 중인 SQL ID의 Child Number 값
Prev SQL ID
마지막으로 수행된 SQL의 SQL ID
Prev Child Number
마지막으로 수행된 SQL ID의 Child Number 값
Logon Time
세션의 로그온 시간
Client PID
세션의 Client PID
PID
세션이 속한 프로세스의 식별자
OS User
연결된 세션의 OS 계정 이름
Machine
연결된 세션의 호스트 이름
Terminal
연결된 세션의 터미널(TTY) 정보
Action
dbms_application_info.set_module/action으로 지정된 액션의 이름
Client Info
dbms_application_info.set_client_info로 지정된 client_info의 이름
Client Identifier
dbms_session.set_identifier로 지정된 client ID의 이름
Backup Wait
Backup Wait로 대기한 시간
DD Wait
DD Wait로 대기한 시간
DDL Wait
DDL Wait로 대기한 시간
Internal Wait
Internal Wait로 대기한 시간
IO Wait
IO Wait로 대기한 시간
PSM Wait
PSM Wait로 대기한 시간
Recovery Tac Wait
Recovery Tac Wait로 대기한 시간
Recovery Wait
Recovery Wait로 대기한 시간
Redo Tac Wait
Redo Tac Wait로 대기한 시간
Redo Wait
Redo Wait로 대기한 시간
Resource Wait
Resource Wait로 대기한 시간
Session Wait
Session Wait로 대기한 시간
Space Wait
Space Wait로 대기한 시간
Sql Tac Wait
Sql Tac Wait로 대기한 시간
Standby Wait
Standby Wait로 대기한 시간
Wlock Wait
Wlock Wait로 대기한 시간
Xa Wait
Xa Wait로 대기한 시간
CPU (%)
프로세스 레벨의 CPU 사용률
Memory
메모리 사용량
Running Time
프로세스의 Running Time
Last Time
프로세스의 Last Time
Logon Time
세션의 로그온 시간
Elapsed Time
세션의 현재 수행 중인 SQL의 Elapsed Time
Machine
연결된 세션의 호스트 이름
Program
세션의 프로그램 이름
Module
dbms_application_info.set_module로 지정된 모듈의 이름
Action
dbms_application_info.set_module/action으로 지정된 액션의 이름
OS User
연결된 세션의 OS 계정 이름
IP Address
User 접속 IP 주소
CPU Time
세션의 CPU 사용 시간
Logical Reads
세션의 Logical Reads 값
Physical Reads
세션의 Physical Reads 값
Execute Counts
세션의 Execute Count 값
Redo Entries
세션의 Redo Entries 값
Hard Parse
세션의 Hard Parse 값
Backup Wait
Backup Wait로 대기한 시간
DD Wait
DD Wait로 대기한 시간
DDL Wait
DDL Wait로 대기한 시간
Internal Wait
Internal Wait로 대기한 시간
IO Wait
IO Wait로 대기한 시간
PSM Wait
PSM Wait로 대기한 시간
Recovery Tac Wait
Recovery Tac Wait로 대기한 시간
Recovery Wait
Recovery Wait로 대기한 시간
Redo Tac Wait
Redo Tac Wait로 대기한 시간
Redo Wait
Redo Wait로 대기한 시간
Resource Wait
Resource Wait로 대기한 시간
Session Wait
Session Wait로 대기한 시간
Space Wait
Space Wait로 대기한 시간
Sql Tac Wait
Sql Tac Wait로 대기한 시간
Standby Wait
Standby Wait로 대기한 시간
Wlock Wait
Wlock Wait로 대기한 시간
Xa Wait
Xa Wait로 대기한 시간
Elapsed Time
현재 수행 중인 SQL의 Elapsed Time
Execute Counts
SQL 실행 횟수
CPU Time
CPU 사용 시간
Logical Reads
Memory I/O로 읽은 Block 수
Physical Reads
Block I/O로 읽은 Block 수
Redo Entries
Redo Entries의 개수
Hard Parse
SQL의 Hard Parse 값
Application Wait
Application Wait로 대기한 시간
Cache Wait
Cache Wait로 대기한 시간
Cluster Wait
Cluster Wait로 대기한 시간
Concurrency Wait
Concurrency로 대기한 시간
Other Wait
Other Wait로 대기한 시간
SQL Wait
SQL Wait로 대기한 시간
System IO Wait
System I/O Wait로 대기한 시간
User IO Wait
User I/O Wait로 대기한 시간
SQL ID
세션이 수행 중인 SQL의 SQL ID
Child Number
세션이 수행 중인 SQL의 Child Number
SQL Text
SQL 내용
Elapsed Time
현재 수행 중인 SQL의 Elapsed Time
Start Time
SQL의 시작 시간
End Time
SQL의 끝난 시간
Log Time
해당 SQL 수행이 시스마스터에 기록된 시간
Machine
연결된 세션의 호스트 이름
Module
dbms_application_info.set_module로 지정된 모듈의 이름
Program
세션의 프로그램 이름
User Name
현재 사용자 이름
OS User
연결된 세션의 OS 계정 이름
CPU Time
세션의 CPU 사용 시간
Logical Reads
세션의 Logical Reads 값
Physical Reads
세션의 Physical Reads 값
Execute Counts
세션의 Execute Count 값
Redo Entries
세션의 Redo Entries 값
Hard Parse
세션의 Hard Parse 값
Backup Wait
Backup Wait로 대기한 시간
DD Wait
DD Wait로 대기한 시간
DDL Wait
DDL Wait로 대기한 시간
Internal Wait
Internal Wait로 대기한 시간
IO Wait
IO Wait로 대기한 시간
PSM Wait
PSM Wait로 대기한 시간
Recovery Tac Wait
Recovery Tac Wait로 대기한 시간
Recovery Wait
Recovery Wait로 대기한 시간
Redo Tac Wait
Redo Tac Wait로 대기한 시간
Redo Wait
Redo Wait로 대기한 시간
Resource Wait
Resource Wait로 대기한 시간
Session Wait
Session Wait로 대기한 시간
Space Wait
Space Wait로 대기한 시간
Sql Tac Wait
Sql Tac Wait로 대기한 시간
Standby Wait
Standby Wait로 대기한 시간
Wlock Wait
Wlock Wait로 대기한 시간
Xa Wait
Xa Wait로 대기한 시간
Elapsed Time
세션의 Running 시간
Status
세션의 Holder 및 Waiter 정보
Session Status
세션의 상태
Wait Time
대기한 시간
User Name
세션 사용자 이름
Module
세션의 모듈 이름
Program
세션의 프로그램 이름
Machine
세션의 호스트 이름
IP Addr
User 접속 IP 주소
SQL ID
세션이 수행 중인 SQL의 SQL ID
Child Number
세션이 수행 중인 SQL Plan의 Child Number 값
Wait Event
세션의 Wait Event 이름
Type
Lock 타입
ID1
Lock ID1
ID2
Lock ID2
Mode
Holder 가 점유한 Lock 모드 (Waiter는 항상 0)
Request
Waiter 가 요청한 Lock 모드 (Holder는 항상 0)
Count
Wait Event 발생 횟수
Time
Wait Event 대기 시간
Count
Wait Event 발생 횟수
User Name
현재 사용자 이름
Module
dbms_application_info.set_module로 지정된 모듈의 이름
OS User
연결된 세션의 OS 계정 이름
Machine
연결된 세션의 호스트 이름
Program
세션의 프로그램 이름
SID
세션의 ID
Serial #
세션의 시리얼 번호
Elapsed Time
세션의 현재 수행 중인 SQL의 Elapsed Time
PID
프로세스의 OS PID 값
Command
프로세스의 OS Command
User
OS 사용자 이름
SID
세션의 ID
Serial #
세션의 시리얼 번호
User Name
현재 사용자 이름
SQL ID
수행 중인 SQL의 SQL ID
Child Number
수행 중인 SQL의 Child Number 값
SQL Text
SQL 내용
SQL ID | Child Number
세션이 수행 중인 SQL의 SQL ID 와 Child Number 값 쌍
SID
세션의 ID
Serial #
세션의 시리얼 번호
Instance
데이터베이스 인스턴스 번호
SID
세션의 SID
Serial #
세션의 시리얼 번호
Name
Wait Event 이름
Desc
Wait Event 상세 설명
Wait Class
Wait Class 이름
SID
세션의 ID
Serial #
세션의 시리얼 번호
Time
Wait Event 대기 시간
Memory
Running Session
Wait Class
참고
Wait Class란 Tibero에서 작업 중 발생한 각 Wait Event들을 유형별로 정리한 것이다. 예를 들어 IO Class의 경우 IO 관련 작업을 할 때 발생한 Wait Event에서 소모된 시간 및 Wait Event 발생 횟수를 집계 것이다.
Performance Chart 소개
Session
Stat
CPU
Memory
Wait (%)
Wait
Wait (Count)
Wait Class
Performance Table 소개
Snapshot
주의
Session 정보 수집에 사용하는 티베로 라이브러리 버전에 따라 일부 지표 (Username, Program, Module, Schema, OS User, Machine, Terminal 등) 가 수집되지 않을 수 있다.
Top Process
Session
참고
Snapshot과 Session의 차이:
Snapshot: 각 세션의 매 초당 상태 변화를 확인하기 위한 카테고리
Session: 1분 이상의 구간동안에서 세션의 전체적인 지표를 확인하기 위한 카테고리.
참고
Session은 해당 시간 구간에서 Session의 전체적인 지표를 나타내는 지표이다.
Session의 경우에는 해당 시간 구간에서 Session의 전체적인 지표를 파악할 수 있다.
