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 라이브러리 빌드를 진행하여야 한다.
CREATE USER [username] IDENTIFIED BY [password];
GRANT CONNECT, ALTER SYSTEM, SELECT_CATALOG_ROLE TO [username];
GRANT EXECUTE ON SYS.DBMS_TPR TO [username];
GRANT EXECUTE ON UTL_TPR TO [username];
기동 / 로그 확인 / 종료 / 초기화
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를 다시 기동하면 최초 설치 상태와 동일하게 동작한다. 단, 이전에 저장한 데이터는 사용할 수 없다.
Alert Alarm 항목에서는 아직 Confirm 처리되지 않은 Alert들의 리스트를 나타낸다. Alert는 유저가 직접 생성한 기준에 따라 발생한 User-created 카테고리와 자동으로 설정되어 전체 인스턴스에 대해서 발생하는 System 카테고리로 나뉘어져 있다.
각 Alert에 대해 Confirm 처리를 하거나, 우상단에 Confirm All 버튼을 눌러야 Alert Event를 제거할 수 있다.
현재 모니터링 중인 인스턴스들의 Aert 발생 현황을 나타내는 영역이다. 각 Alert Level (Error, Warning, Info) 별로 몇개의 Alert가 발생하고 있는지 표시한다. 버튼을 클릭하여 해당 인스턴스의 Alert Event History로 이동한다.
Alert Events History
User Created Alert 및 System Alert 모두 확인 할 수 있으며, Alert가 발생한 시각, Alert 이름, Alert 레벨, Alert가 발생한 인스턴스, Confirm 여부 및 Alert 확인시 작성한 유저 Comment 이력을 확인 할 수 있다.
인스턴스 및 필터 조건을 변경하여 다른 인스턴스 및 특정 시간대에서 발생한 Alert들을 조회 할 수 있다.
Heatmap Trend
글로벌 내비게이션 바에서 [Analysis] > [Perfomance Analysis] > [Heatmap Trend] 메뉴를 클릭하면 Heatmap Trend 화면이 열린다.
Heatmap Trend 화면에서는 선택한 인스턴스의 Resource 사용량에 대한 Overview를 확인할 수 있다. 이때 지정한 구간 동안 시간, 일자별로 Resource 사용량을 도식화하여 한눈에 확인할 수 있고, 선택한 시간의 분 단위 막대 그래프로 정밀하게 전체적인 사용량의 흐름을 알 수 있다.
참고
Heatmap의 검색 가능 구간은 10일 미만이다.
Copy Layout
Layout 목록에서 특정 Layout의 더보기 버튼 클릭 시 제공되는 Copy 기능을 통해 기존 Layout을 복사할 수 있다.
[Copy] 클릭 시 복사 대상 Layout의 복사본이 생성되며, 사용자는 복사본 Layout의 이름을 직접 설정하여 저장할 수 있다.
Session 상세보기
특정 session에 대한 현재 수행 중인 SQL 및 wait event 상황등 상세 정보를 모니터링 할 수 있다. session 목록에서 상세 보기를 원하는 session의 SID를 클릭하면 Session 상세보기 페이지가 열린다.
Session 기본 정보
Session Monitoring 페이지에서 한 row로 보여 주었던 항목들이다. Session Monitoring 화면과 마찬가지로 refresh, auto refresh, kill session 기능을 제공한다.
Delete Layout
Layout 목록에서 특정 Layout의 더보기 버튼 클릭 시 제공되는 Delete 기능을 통해 기존 Layout을 삭제할 수 있다.
Total Session Count 화면에서는 All Session Count에서 선택한 총 세션의 갯수를 확인할 수 있다.
Total Session Count 화면
다음은 Total Session Count 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
SQL Text
SQL Text 화면에서는 New Plan List에서 선택한 SQL문에 대한 전체 구문을 확인할 수 있다.
SQL Text 화면
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를 선택할 수 있다.
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 화면이 열린다.
All Session Flow
All Session Flow 화면에서는 동일한 DB 사용자는 제외하고, DB 사용자별 전체 세션 갯수를 그래프로 확인할 수 있다. 이이때 오른쪽 상단의 차트 간격(Interval)과 집계 방식(Aggregation)을 드롭다운 메뉴로 선택하여 확인할 수 있다.
All Session Flow 화면
All Session Flow
글로벌 내비게이션 바에서 [Analysis] > [History Analysis] > [All Session Flow] 메뉴를 클릭하면 All Session Flow 화면이 열린다.
All Session Flow 화면에서는 지정한 기간 동안 접속한 DB 사용자별로 구분하여 세션 개수를 그래프로 제공한다. 이때 특정 시점의 사용자가 몇개의 세션을 맺었는지 확인이 가능하며, 선택한 시점에 어떤 세션들이 활동을 하였는지 확인할 수 있다.
라이선스(기간 만료 등의 이유로) 파일 교체가 필요한 경우, 해당 경로 내 기존 라이선스 파일을 신규 라이선스 파일로 바꿔준 후 SysMasterDB 서비스를 재기동하면 된다.
1.4. 실행
1.4.1. Docker-compose 환경
1.4.2. Podman-compose 환경
2. 로그 확인
참고
Client 모듈의 경우 따로 로그를 파일로 남기고 있지 않고 있으므로, docker compose logs 와 같은 명령어로 출력되는 로그를 확인해야한다.
3. 종료
4. 초기화
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 를 다시 기동하면 이전에 저장한 데이터를 사용할 수 있다.
아래의 명령을 수행하면 모든 데이터가 삭제되고, 최초 설치 상태와 동일하게 동작한다. 단, 이전에 저장한 데이터는 사용할 수 없다.
1. 기동
1.1. Namespace, ConfigMap, PVC, Service 생성
1.2. RepoDB, MetaDB 디플로이먼트 생성 (데이터베이스 생성이 완료된 상태에서 진행)
라이선스(기간 만료 등의 이유로) 파일 교체가 필요한 경우, 해당 경로 내 기존라이선스 파일을 신규 라이선스파일로 바꿔준 후 SysMasterDB 서비스를 재기동하면 된다.
2. 로그 확인
3. 종료
1.1. SysMaster 디플로이먼트 삭제
1.2. Kafka 디플로이먼트 삭제
1.3. RepoDB, MetaDB 디플로이먼트 삭제
참고
1. SysMaster 디플로이먼트와 Kafka 디플로이먼트는 항상 같이 삭제한다.
2. RepoDB, MetaDB 디플로이먼트는 반드시 삭제할 필요는 없으며, SysMaster 종료 후에도 RepoDB와 MetaDB에 접속해 데이터를 확인할 수 있다.
4. 초기화
sysmaster-db up
podman compose -f podman-compose.yml up -d
Started SdmApplication in ... seconds (JVM running for ...)
sysmaster-db down
kubectl apply -f kubernetes/init
kubectl apply -f kubernetes/db
[ENTRYPOINT LOG]: INFO: Attempting to start PostgreSQL server...
LOG: database system is ready to accept connections
kubectl apply -f kubernetes/kafka
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
Role
그룹에서 해당 유저의 역할(Role)을 지정한다.
Description
그룹에 대한 설명을 작성한다.
Group Name
생성할 그룹의 이름을 지정한다.
Instance
그룹에 할당될 인스턴스를 지정한다.
Member&Name
그룹에 넣을 유저를 id기준으로 지정한다.
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
리눅스의 경우 도커 엔진 설치 이후 sudo 명령어 없이 운영하기 위해 아래 주소를 참고하여 시스템 구성하는 것을 권장한다.
1.3 파드맨(Podman) 엔진 설치
참고
파드맨(Podman)은 rootless container 기능을 지원하여 sudo 명령어 없이 컨테이너를 운용할 수 있다. Linux Kernel 4.18 이하에서는 디스크 볼륨을 rootless container에 마운트 할 수 없기 때문에 Podman은 Red Hat Enterprise Linux 8 이상부터 지원한다.
Tibero Wait Event 지표가 Count는 0 이상이지만 Time은 0 으로 표기되는 경우
티베로 라이브러리에서 수집되는 Wait Event Time 은 nanosecond 단위까지 발생하지만 지표 집계와 출력은 microsecond 단위로 이루어진다. 따라서 nanosecond 단위의 Wait 만 발생했을 경우 Wait Count가 0보다 크더라도 Wait Time이 0으로 출력 될 수 있다.
User created 탭과 System 탭 차트의 특정 시간을 클릭하여 해당 시간의 알림 목록을 조회할 수 있다.
항목
설명
Alert Time
알림이 발생한 시각
Alert Name
알림 이름
Alert Level
알림 레벨 (INFO, WARNING, ERROR)
User-created
System
Alert Event 목록
다음은 Invalid Objects 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Log Time
Invalid Object 데이터의 수집 시각
Owner
Invalid Object의 소유자
Object Name
Invalid Object의 Object 이름
Invalid Objects Count
Invalid Objects
Instance Alias
인스턴스 이름 (카드에 표시되는 정보)
IP Address
관제 대상 DB의 접속 IP
Port
관제 대상 DB의 접속 포트 번호
DB Name
관제 대상 DB의 SID
User ID
관제 대상 DB의 사용자 이름
Password
관제 대상 DB의 사용자 패스워드
TPM Agent ID
인스턴스 ID
Instance Color
인스턴스 고유 색상 (차트에 그려지는 색상)
새로 등록한 instance는 바로 화면에 반영되지 않고, 그룹에 instance를 할당한 후에 Dashboard에서 관제가 가능하다.
참고
인스턴스 등록 시 입력하는 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 모니터링 화면의 이 올바르게 보이지 않는다.
참고
SysMasterDB에 관제 대상 DB 인스턴스를 등록하면, TPM Agent 기동 여부와 관계없이 SysMasterDB는 관제 대상 DB에 직접 접속하여 수집을 시작한다.
일부 수집 항목은 TPM Agent가 아닌 DB 직접 쿼리 방식으로 주기적으로 수집되므로, TPM Agent가 종료되어도 SysMasterDB의 DB 접속 세션은 유지된다.
관제 및 수집을 중지하려면 SysMasterDB에서 해당 인스턴스를 삭제해야 한다.
Performance Trend
Analysis Performance Trend 메뉴의 메인 화면으로 이동한다. 해당 메뉴에 대한 자세한 내용은 를 참고한다.
Top N
Top N Performance 메뉴의 메인 화면으로 이동한다. 해당 메뉴에 대한 자 세한 내용은 를 참고한다.
Tablespace Usage - 테이블스페이스 사용량과 상태를 시간별 업데이트 및 실시간 데이터 수집으로 모니터링한다.
- 데이터베이스 파일 사용량을 자동으로 매시간 수집하며, 필요 시 실시간 업데이트도 가능하다.
- 비효율적인 쿼리나 과도한 자원 사용을 감지하기 위해 임시 테이블스페이스 사용량을 모니터링한다.
- 트랜잭션이 완료되지 않은 세션의 Undo 사용량을 모니터링한다.
트리 뷰로 세션 잠금(lock) 정보를 모니터링하고, 필요 시 차단된 세션을 종료할 수 있다.
- TSC 클러스터 토폴로지를 시각화하고, 데이터베이스 역할·상태·TSN 세부 정보를 모니터링한다.
- 그래프와 Time Slice 기능을 사용해 장기적인 성능 추세를 분석한다.
- 높은 자원 사용의 주요 원인이 되는 상위 SQL을 분석한다.
- Heatmap과 드릴다운 분석으로 시간대별 자원 사용 현황을 시각화한다.
- 지정한 기간 동안의 SQL 실행 계획(SQL Plan) 변화를 비교·분석한다.
- 세션 접속 추이와 실시간 세션 상태를 모니터링한다.
- Hard Parse 이벤트를 발생시킨 SQL 문을 추적한다.
- 시스템 및 사용자 정의 알림(Alerts) 이력을 추적한다.
- 유효하지 않은 데이터베이스 객체의 개수와 세부 정보를 추적한다.
- 테이블스페이스 크기 변화를 시간에 따라 추적한다.
- 서버의 파일시스템 크기 변화를 추적한다.
- 지정한 기간 동안 세그먼트 크기 변화를 추적한다.
- 임시 테이블스페이스 크기 변화를 시간별로 모니터링한다.
- Undo 테이블스페이스 크기 변화를 시간별로 추적한다.
- 인스턴스 또는 클러스터 단위의 성능 보고서를 생성·분석한다.
- 활성 세션 분석을 위한 ASH 보고서를 생성·조회한다.
File Usage
글로벌 내비게이션 바에서 [Realtime] > [Usage Monitoring] > [File Usage] 를 클릭하면 File Usage 페이지가 열린다.
File Usage 페이지에서는 데이터 파일 사용량 정보를 보여준다. File Usage 는 관제 DB 에 대한 부하를 최소화하기 위해 한시간마다 수집되는데, 우 상단 [Collect] 버튼 클릭시 최신 File Usage 정보를 수집하여 보여준다.
Configurable Privileges 중 선택한 인스턴스에 대해 [Data Collection] 권한이 부여된 사용자에 한해 [Collect] 버튼을 사용할 수 있다.
모니터링 대상 DB의 테이블스페이스의 데이터 파일 I/O 사용량 정보를 확인할 수 있다.
항목
설명
SQL Detail 탭
현재 session에서 수행중인 SQL과 동일한 SQL의 과거 수행 이력 및 통계를 보여준다.
SQL 수행 과거 이력 기한 선택
현재 session에서 수행 중인 SQL과 동일한 SQL이 과거에 수행되었던 이력을 조회하기 위하여, 원하는 기간을 선택하여 조회할 수 있다.
SQL Full Text
현재 session에서 수행 중인 SQL 전문을 보여준다.
Plan Tree
현재 session에서 수행 중인 SQL에 대한 Plan을 확인할 수 있는 화면이다. 이때 SQL Plan을 Tree 구조로 보여준다.
현재 수행 중인 SQL과 동일한 SQL들의 과거 이력들의 통계 정보를 보여준다. Summary, execute count, physical reads, logical reads, plan history, sql trace 항목들을 보여준다.
Summary 탭 화면에서는 분석 구간 동안 stat 지표 및 wait event 리스트와 각 wait event별 wait time의 값을 확인할 수 있다.
항목
설명
Execute Count 탭 화면에서는 시간 단위별 Execute Count를 차트 형태로 확인할 수 있다.
Physical Reads 탭 화면에서는 시간 단위별 Physical Reads를 차트 형태로 확인할 수 있다.
Logical Reads 탭 화면에서는 1분 단위의 Logical Reads를 차트 형태로 확인할 수 있다.
Plan History 탭 화면에서는 같은 쿼리에 대해 Plan별 비교가 가능하다.
SQL Trace 탭 화면에서는 조회 기간 동안의 SQL 수행 이력(Trace 정보)을 확인할 수 있다.
TPM Agent 기동 / 종료
TPM Agent 환경 설정
application.yml 파일 설정 완료 후 아래와 같은 순서로 TPM Agent를 환경을 설정한다.
1.1. 코어 덤프 파일 최대 사이즈 설정
ulimit -c unlimited
1.2. TPM Agent 환경 변수 설정
. set.sh
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
참고
위 스크립트는 위에 두 줄인 바이너리 실행 PATH 설정과 TPM Agent 라이브러리 경로 LD_LI BRARY_PATH 설정 그리고 환경 변수 설정들을 기본적으로 제공하는 템플릿이다. 환경에 맞게 직 접 스크립트를 수정하여 TPM Agent 실행을 하면 된다.
참고
하드링크를 사용하는 이유는 top, topas 등 명령어에서 프로세스명을 치환하여 TPM Agent 프로세스를 쉽게 확인하기 위한 용도이며, 실패해도 Tibero 모니터링에는 영향이 없다.
인자
설명
{TPM_Agent_Home_Path}
"java_tpmagent_dist_{version}.tar.gz" 압축 파일 해제 디렉터리 경로
인자
설명
tpmctl.sh 명령어는 아래와 같으며, help로 터미널에서 사용법 확인이 가능하다.
명령어
설명
Java TPM Agent에서 libtpmstat.so를 사용하기 위하여 필요한 라이브러리이다.
Tibero Down 이후 바로 Tibero Boot를 위해서 TPM Agent Down이 필요하다. TPM Agent가 참조하고 있는 Tibero Shared Memory를 해제해야 하기 때문이다.
Layout Tab 기본 기능
Instance Monitoring 페이지의 Layout Tab 영역에서 제공되는 기본 기능에 대해 설명한다.
Default Layout
사용자 편의를 위해, Instance Monitoring 페이지에서는 Default Layout을 제공한다.
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에서 비활성화된다. 해당 인스턴스 이름을 한 번 더 클릭하면, 다시 해당 인스턴스 그래프가 차트에 표출된다.
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 영역에서 제공하는 항목에 대한 설명이다.
항목
설명
Instance Info
Instance Info
모니터링 DB 인스턴스 및 장비에 관한 상세 정보를 제공한다.
이름
설명
TPM Agent ID
TPM Agent의 application.yml 파일에 설정한, 해당 DB의 내부 식별 ID
Analysis
본 장에서는 실시간 지표 수집을 통해 누적된 데이터의 기간 분석을할 수 있는 Analysis 메뉴에 대해 설명한다.
History Analysis - 그간 Plan 변화, 접속 세션 수 변화, Alert 발생량 변화, Invalid Object 갯수 변화 등의 추이를 분석할 수 있다.
Usage Analysis - Tablespace, Filesystem, Segment, Temp Tablespace, Undo Tablespace 사용량 추이를 확인할 수 있다.
Analysis 서비스 하위 메뉴에서 공통으로 사용되는 기능에 대해서 설명한다.
Analysis의 하위 메뉴에 진입 시 공통적으로 보여지는 드롭다운 메뉴이다. 해당 드롭다운을 통해 모니터링 대상 인스턴스를 선택할 수 있다.
Analysis 메뉴들 화면 좌측 상단의 드롭다운 메뉴를 클릭한다.
Instance 드롭다운 메뉴를 클릭한다.
드롭다운이 펼쳐지면 원하는 인스턴스를 선택하고, 해당 인스턴스에 대한 모니터링 정보가 화면에 나온다.
Analysis의 하위 메뉴에서는 공통적으로 Period Selector를 제공한다. 사용자는 Period Selector를 통해 데이터 분석 대상 기간을 설정할 수 있다. 이때 Period 영역에서 기간을 설정하고, 오른쪽의 [VIEW] 버튼을 클릭하면 대상 기간의 데이터가 조회된다. 기본적으로 1시간 단위로 되어 있고 만약 특정한 기간이 필요하다면, Custom으로 하여 원하는 기간 구간에서 조회가 가능하다.
기본적으로 차트 데이터의 단위는 분, 시, 일을 지원하며 데이터의 개수 120개를 기준으로 단위가 변한다.
예시 1: 검색 범위 120분(2시간) 이하는 분 단위 데이터로 조회
예시 2: 검색 범위 120분(2시간) 초과 120시간(5일) 이하는 시간 단위 데이터로 조회
예시 3: 검색 범위 120시간(5일) 초과는 일 단위 데이터로 조회
사례 1: 최소 검색 단위 [분], 차트 데이터는 기본 규칙을 따름
Performance Trend Alert Analysis
사례 2: 최소 검색 단위 [시], 차트 데이터는 모두 시간 단위 제공
Chart 공통 기능
Instance Monitoring 페이지의 Layout Tab 영역에서 제공되는 모니터링 지표 차트의 공통 기능에 대해 설명한다.
모니터링 지표 차트 예시
모니터링 지표 설명
차트 좌상단의 지표명 우측에 표출되는 info 아이콘 위에 마우스 포인터를 올려두면, 해당 지표에 대한 Description을 확인할 수 있다.
부가 기능
차트 우상단의 더보기 아이콘을 클릭하면, 각 차트별로 지원되는 부가 기능 목록을 확인할 수 있다.
차트 종류에 따라 지원되는 부가 기능이 다르며, 차트별 부가 기능에 대한 설명은 Chart Type을 참고한다.
차트 우상단의 확대 아이콘을 클릭하면, 별도의 모달을 통해 해당 차트를 확대하여 확인할 수 있다.
차트 우하단 모서리를 클릭한 상태로 드래그하여 해당 차트의 크기를 조절할 수 있다.
차트 우상단의 닫기 아이콘을 클릭하면, 현재 레이아웃에서 해당 차트를 제거할 수 있다.
일부 차트 종류에서는 실시간 모니터링 중 사용자의 편의를 위해 다른 페이지로 연계해주는 기능을 제공한다.
해당 기능은 Bar, Line, Area, Stack Bar 차트에서 특정 인스턴스 그래프 클릭 시 사용할 수 있으며, 이동 가능한 페이지는 아래와 같다.
Realtime > Session Monitoring
Analysis > Performance Trend
Analysis > Top N Performance
Analysis > Changed Plan Analysis
시스템 요구사항
1. 지원 플랫폼 및 운영체제
SysMaster DB 8.3의 공식지원 플랫폼 및 운영체제는 다음과 같다.
구분
제품 및 버전
운영체제
Linux:
CentOS 7 (64-bit)
Red Hat Enterprise Linux 7 ~ 9 (64-bit)
Docker
v28 이상
SysMaster DB 8.3를 설치하기 위해 필요한 하드웨어 및 소프트웨어의 요구 사항은 다음과 같다.
구분
사양
SysMaster DB 8.3의 관제 데이터베이스 대상 권장 패치는 다음과 같다.
패치 번호
패치 내용
Card View
현재 모니터링 중인 인스턴스의 상태와 주요 모니터링 데이터들을 카드 뷰 형태로 확인할 수 있다.
카드 뷰는 기본적으로 3초 주기로 Refresh되며, Card Order By 에 설정된 대로 정렬되어 표시된다. (카드 정렬 기준 참조)
TPM Agent 이 사용하는 TPM Stat 라이브러리 빌드 패치 목록과 Tibero의 패치 목록 출력
{Monitoring_DB_Path}
관제 데이터베이스의 경로를 입력
{Monitoring_DB_SID}
관제 데이터베이스의 SID를 입력
./tpmctl.sh [-p port] up
TPM Agent 실행, -p 옵션을 통하여 jvm 디버그 포트들을 지정할 수 있다. 기본적으로 사용 가능한 포트를 찾으나, 해당 환경에서 사용 가능한 포트를 찾지 못하여 프로세스 실행이 되지 않는다면 해당 옵션을 사용하여 수동으로 포트를 지정할 수 있다.
./tpmctl.sh down
TPM Agent 종료
./tpmctl.sh help
TPM Agent 도움말 출력
1.3. Tibero 환경 변수 설정
기동, 종료 및 기타 명령어
libJNITpmStat.so 라이브러리
참고
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를 하면 된다.
1분간 등록된 인스턴스와의 연결 시도가 실패할 경우 SysMasterDB는 해당 DB 인스턴스를 Down 상태로 간주한다. 이후 연결이 다시 가능해질 경우 자동으로 이를 인식하여 Normal 상태로 전환된다.
주의
방화벽 설정 변경 등의 이유로 TPM Agent 데이터 수집 전송이 멈췄을 경우 Normal 상태에서 아무런 지표가 보이지 않는 현상이 있을 수 있다. 따라서 Normal 상태인데 실시간 지표가 보이지 않는다면, 관제 DB 머신과 TPM Agent 로그를 확인해 볼 필요가 있다.
Performance trend overall 화면과 Heatmap trend 최초 화면은 default 시간으로 검색되어 제공한다.
Period selector는 검색 범위에 따라 데이터의 검색되는 단위가 변하며, Analysis 하위 메뉴는 각각 상이한 규칙과 최소 검색 단위가 존재한다.
검색 범위 및 차트 데이터 단위 기본 규칙
하위 메뉴의 최소 검색 단위 및 차트 데이터 단위
웹 브라우저
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 종료 여부가 정확히 판단되지 않을 수 있다.
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-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)
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 이상
CPU
8 Core
RAM
32 GB
저장 공간
30 GB 이상 (수집 정보의 보관 주기(RETENTION_DAY)에 따라 일 당 50 GB 추가 필요)
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 패치 버전이 맞아야 한다.
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. 관제 데이터베이스 권장 패치
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
이전 시점의 여유 공간 현황
Later Free/Total Size
이후 시점의 여유 공간 현황
Earlier Used/Total Size
이전 시점의 사용량 현황
Later Total/Total Size
이후 시점의 사용량 현황
Free
사용 가능한 양
Tablespace Name
테이블스페이스 이름
Contents
테이블스페이스에 저장하는 데이터 종류
TEMPORARY
PERMANENT
UNDO
Earlier Time
이전 시점
Later Time
이후 시점
Earlier Free/Total Size
Log Time
수집 시간
Tablespace Name
테이블스페이스 이름
Used
사용량
Tablespace Info
Tablespace Info
이전 시점의 여유 공간 현황
Alert Trigger
알람 트리거 이름
Instance
알림이 발생한 인스턴스 이름
Confirm
사용자 확인 여부
User Comment
알림 확인 시 사용자가 작성한 메시지 내용
Sub Object Name
Invalid Object의 Sub Object 이름
Object Type
Invalid Object의 타입
Status
Invalid Object의 상태 (INVALID)
Last DDL Time
Invalid Object의 최근 DDL이 실행된 시간
Tablespace Name
테이블스페이스 이름
Name
파일 경로를 포함한 파일명
Physical Reads
Physical Read 횟수
Physical Writes
Physical Write 횟수
Physical Block Reads
Physical Block Read 횟수
Physical Block Writes
Physical Block Write 횟수
Single Block Reads
Single Block Read 횟수
Free/Total Size
사용 가능 File 공간 크기 현황
Used/Total Size
사용중인 File 공간 크기 현황
Total/Auto Extend Limit Size
File 자동 확장 최대 증가 크기 현황
Auto Extend
File 자동 확장 여부
Statistics
Statistics 지표 확인
Wait Class
분석 구간 동안의 wait class 목록과 각 wait class별 wait time의 값을 확인
Wait Event
Wait class에서 선택한 항목에 대한 상세 내역을 확인
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 을 볼 수 없다.
사용자 이름
OS User
OS 이름
Machine
연결된 세션의 호스트 이름
Terminal
연결된 세션의 터미널(TTY) 정보
Program
세션의 프로그램 이름
Module
dbms_application_info.set_module로 지정된 모듈의 이름
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
Logon Time
세션의 로그온 시간
참고
Session 정보 수집에 사용하는 티베로 라이브러리 이슈로 일부 정보에 User Name, Schema Name, OS User, Machine, Terminal, Program, Module 등 항목이 수집되지 않을 수 있다.
글로벌 내비게이션 바에서 [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 리소스 사용량을 보여준다.
항목
설명
Lock Monitoring
글로벌 내비게이션 바에서 [Realtime] > [Lock Monitoring] 메뉴를 클릭하면 Lock Monitoring 화면이 열린다.
Lock Monitoring 화면에서는 세션간의 Lock 정보를 Tree 형식으로 보여준다. 따라서 Lock을 점유하고 있는 Holder Session과 Lock을 획득하기 위해 기다리고 있는 Waiter Session을 모니터링 할 수 있다. 그리고Lock을 점유하고 있는 세션을 모니터링할 수 있으며, 특정 세션을 종료 시킬 수 있다.
다음은 Lock Tree Table 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Lock을 점유하고 있는 세션을 종료시켜 Lock을 해제할 수 있는 기능이다.
우선 Lock Tree Table에서 해제할 세션을 선택한 후 Lock Tree Table 화면 오른쪽 상단의 [Kill Session] 버튼을 클릭하면 Kill Session 팝업창이 열린다. 이때 해당 세션을 Kill하여 Lock을 해제할 수 있다.
Custom Area
현재 모니터링 중인 그룹 내 인스턴스들의 각종 지표를 확인할 수 있다.
커스터마이징을 통해 시스마스터에서 지원하는 모든 실시간 차트와 세션, 락 모니터링 테이블을 원하는 위치와 크기로 배치할 수 있다.
차트를 클릭할 시 원하는 화면으로 이동이 가능하다.
Custom Area 기본 레이아웃
Response Time
그룹 내 모든 인스턴스에서 발생하는 SQL 수행의 응답 시간 (Response Time)을 히트맵 형태로 표시한다.
Y축은 응답 시간이며, 히트맵의 색깔은 해당 응답 시간에 해당하는 SQL의 숫자를 나타낸다.
더보기 메뉴를 클릭하여 Y축 Time Range를 설정하고 저장 할 수 있다.
Starting Point : 차트에 보여질 SQL들의 최소 Elasped time 값
Cell Height: 차트의 Y축인 각 Cell의 Elasped time을 설정하는 값
히트맵 영역을 드래그하거나 셀을 클릭하여 실제 SQL 수행 내역을 별도 모달로 확인할 수 있다.
Instance Name을 클릭할 시 해당 인스턴스에 대한 다른 화면으로 갈 수 있다.
SID를 클릭할 시 해당 SID에 대한 Session Detail 화면으로 이동한다.
Long SQL List의 칼럼 내용은 을 참조하면 된다.
각 인스턴스별로 TPS (Transaction Per Second)를 보여준다.
그룹 내 각 인스턴스 당 수행되고 있는 세션들의 Elapsed Time을 시간 구간별로 나눠서 제공한다.
Response Time 기준으로 4개의 구간에 대한 구간값을 정의할 수 있다.
더보기 버튼을 클릭하여 시간 구간을 커스터마이징하고 저장할 수 있다.
실시간 Running Session / Active Session / Lock Tree 현황을 테이블 형태로 표시한다.
각 행의 SID를 클릭하면 Session Detail 및 SQL Detail 페이지로 이동하여 확인할 수 있다.
최대화 버튼을 눌러 확장할 수 있으며, 확장하기 전에는 Elapsed Time 기준 10개 항목, 확장 후에는 50개 항목이 표시된다.
Custom 영역을 우클릭하여 Add Chart 메뉴를 호출할 수 있으며, Add Chart를 통해 Custom 영역에 차트를 추가할 수 있다.
이미 존재하는 차트는 하이라이트 되어 표시된다.
Recommend 섹션에서 선택하거나, All 섹션에서 시스마스터에서 제공하는 모든 실시간 차트 중에서 Dashboard에 표시할 차트를 선택할 수 있다.
각 차트 컴포넌트의 X 버튼을 눌러 차트 컴포넌트를 삭제할 수 있으며, 차트의 위치나 크기를 드래그하여 조정할 수 있다.
그룹 내 Admin이상의 권한 혹은 Custom Privilege 가 부여되어 있을 경우 Save 버튼을 통해 Custom Area의 변경 사항을 저장할 수 있다.
Reset 버튼을 누르면 변경 사항을 되돌린다.
Tablespace Usage
글로벌 내비게이션 바에서 [Realtime] > [Usage Monitoring] > [Tablespace Usage] 를 클릭하면 Tablespace Usage 페이지가 열린다.
Tablespace Usage 페이지에서는 테이블스페이스 사용량 정보를 보여준다.
Current Tablespace Usage
모니터링 대상 DB의 테이블스페이스 사용량과 상태 정보를 확인할 수 있다. 이때 기본 수집 단위는 1시간이지만, 우 상단의 [Collect] 버튼을 이용하면 해당 시간에 실시간 정보를 수집해서 보여준다.
항목
설명
Last 24 hours history 에서는 그리드(Grid) 형태로 현재까지의 사용량 정보를 확인하거나, 차트(Chart) 형태로 변화율 추이를 확인할 수 있다.
항목
설명
Segment Size 에서는 Last 24 hours history 에서 선택한 Log Time 내 세그먼트 타입별 크기를 확인할 수 있다. 이때 해당 정보의 수집 단위는 1시간이다.
항목
설명
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 에서 특정 데이터 클릭 시 해당 세그먼트의 일자별 크기 변화를 상세하게 확인할 수 있다. 이때 오른쪽의 그래프를 통해 크기 변화량을 한눈에 파악할 수 있다.
다음은 Segment Info 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
TSC Monitoring
글로벌 내비게이션 바에서 [Realtime] > [High Availability Monitoring] > [TSC Monitoring] 메뉴를 클릭하면 TSC Monitoring 화면이 열린다.
TSC Monitoring 화면에서는 TSC 목록, 각 TSC 네트워크 구성, TSN을 통한 복구 현황 차트, Primary DB와 Standby DB 실시간 현황을 모니터링할 수 있다.
자동 갱신 주기를 설정할 수 있다. [Refresh] 버튼을 통하여 즉시 갱신할 수 있다.
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 수집 주기의 영향을 받아 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 사용량은 전체 코어들에서 얼마나 사용되고 있는지에 대한 값이기 때문이다.
Partition Name
파티션 이름
Used/Total Size
해당 세그먼트가 차지하는 공간의 비율
Tablespace Name
테이블스페이스 이름
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 상태인지 여부
Log Time
수집 시간
Free/Total Size
테이블스페이스 여유공간 현황
Used/Total Size
테이블스페이스 사용공간 현황
Segment Type
세그먼트 종류 (Table, Index, Undo 등)
Owner
소유자 계정
Segment Name
세그먼트 이름
Last 24 hours history
Segment Size
참고
세그먼트 크기가 클수록 부하의 영향을 많이 받으며, Tablespace Usage 페이지 오른쪽 상단의 [Collect] 버튼을 클릭해도 해당 정보는 수집하지 않고 매시간 정각에 수집된다.
Tablespace Name
테이블스페이스 이름
Owner
Object의 소유자
Segment Name
세그먼트 이름
Segment Type
세그먼트 종류
Partition Name
파티션 이름
Earlier Extents
이전 시점의 Extent 수
Later Extents
이후 시점의 Extent 수
Earlier Blocks
이전 시점의 Blocks
Later Blocks
이후 시점의 Blocks
Blocks
Block 수
Earlier Time
이전 시점
Later Time
이후 시점
Earlier Size
이전 시점의 크기
Later Size
이후 시점의 크기
Increment
Log Time
수집 시간
Partition Count
파티션 수
Size
크기
Segment Usage Header
Segment Info
Segment Usage Date Column
Segment Usage Date Picker
Segment Info
이전 시점 대비 이후 시점 크기 증감량
TSC 네트워크 구성을 확인할 수 있다.
[Overview] 버튼을 누르면 TSN 차트를 확인하여 복구 현황을 모니터링할 수 있다.
Primary DB와 Standby DB의 현황을 테이블 형식으로 모니터링 할 수 있다.
Primary Database, Standby Database에서 각 인스턴스 명을 클릭하면 우측 사이드 패널에서 Instance info를 확인 할 수 있다.
다음은 Primary Database 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Instance
인스턴스 이름
Current Log
가장 최근의 Redo Log
CPU
인스턴스의 현재 총 CPU 사용량(%)
다음은 Standby Database 화면에서 제공하는 항목에 대한 설명이다.
항목
설명
Instance
인스턴스 이름
Status
Standby 의 상태. Status가 여러개 일 경우 1개만 표기하고 +n 으로 표기,
프라이머리 노드가 여러개일 경우 첫번째 노드와의 네트워크 상태가 표시된다.
값 종류
PRIMARY NOT CONNECTED
Open Mode
MOUNT
RECOVERY
READ WRITE
READ ONLY
TSC 목록
TSC Topology View
TSC 목록
Standby Database Recovery Overview
Primary/Standby Database 목록
Instance
SysMaster DB에 등록된 해당 인스턴스 이름
SID
세션의 SID
Serial#
세션의 시리얼 번호
Elapsed Time
세션의 Running 시간
Status
세션의 Holder 및 Waiter 정보
Session Status
세션의 상태
Username
세션 사용자 이름
Module
세션의 모듈 이름
Program
세션의 프로그램 이름
Machine
세션의 호스트 이름
IP
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)
Wait Time
대기한 시간
Kill Session
Configurable Privileges 중 선택한 인스턴스에 대해 [Kill Session] 권한이 부여된 사용자에 한해 사용할 수 있는 기능이다.
참고
팝업창 정보에 대해서 Session Monitoring의 'Kill Session'을 참고한다.
설치 및 파라미터 설정
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 문법에 맞게 각 파라미터들의 값을 조정하여 설정한다.
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로 연결하기 위한 포트 번호
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}
sysmaster-db-alpine-linux:{version}
로드한 도커 이미지들을 해당 환경에서 사용 중인 이미지 리포지터리로 푸시한다.
설치 디렉터리에서 kubernetes 디렉터리 안의 yaml 파일들을 통해서 8개의 디플로이먼트들에 대해 정의한다. 각 디플로이먼트에 대한 설명은 다음과 같다.
디플로이먼트
설명
client
사용자가 브라우저를 통해 접속하게 될 웹 서버
sdm
수집 정보를 조회하고 클라이언트와 통신하는 API 서버
tibero-master
관제 데이터베이스에 대한 상태 확인과 Admin 기능을 수행하는 서버
설치 디렉터리에서 kubernetes/init/configmap.yaml 파일을 열어 SysMaster DB의 설치에 필요한 계정 정보 및 보관 주기 관련 파라미터 값을 설정한다.
해당 과정에서 설정하는 파라미터에 대한 설명은 다음과 같다.
파라미터 이름
설명
초기값
ADMIN_USERNAME
Admin 계정의 사용자 이름
admin
ADMIN_PASSWORD
Admin 계정의 암호
admin
설치 디렉터리에서 kubernetes/init/service.yaml 파일을 열어 SysMaster DB의 설치에 필요한 포트 관련 파라미터 값을 설정한다. 해당 과정에서 설정하는 파라미터에 대한 설명은 다음과 같다.
파라미터 이름
설명
초기값
CLIENT_PORT
UI 접속 URL의 포트 번호
[수정 위치] metadata.name=client, name="client-port"인 ports의 nodePort 수정
80
COLLECTOR_PORT
수집 모듈(TPM Agent)이 접속할 포트 번호
[수정 위치] metadata.name=collector, name="collector-port"인 ports의 nodePort 수정
[참고] 관제 DB에서 접속할 수 있도록 SysMaster 서버에서 열려 있어야 함.
8292
설치 디렉터리에서 kubernetes/init/configmap.yaml 파일을 통해 Meta DB 및 Repository DB 파라미터 값을 확인할 수 있다. 다음은 Meta DB에 대한 파라미터 설정 예시이다.
해당 conf 파일은 기본적으로 제공되는 설정값을 사용하되, 다음에서 설명하는 파라미터는 필요 시 구동 환경에 맞게 사용자가 직접 설정해준다.
SKIP_DB_USER_COUNT_MIGRATION_PATCH, SKIP_DAILY_SEGMENT_MIGRATION_PATCH 파라미터는 신규 설치 시에는 필요하지 않고, SysMaster DB v8.1.2 이하 기설치 환경에서 버전 업데이트를 수행하는 경우에만 적용이 필요하다.
각 파라미터를 별도로 설정하지 않으면, 버전 업데이트 시 해당 패치가 자동으로 수행되면서 기수집 데이터를 기반으로 DB_USER_COUNT, DAILY_SEGMENT 데이터를 생성한다.
이때, 기수집 데이터양에 따라 패치 수행에 장시간 소요될 수 있으므로, 해당 파라미터를 통해 사용자가 선택적으로 해당 패치 수행 여부를 설정할 수 있다.
참고 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에서 신규 스키마가 적용된 테이블 목록은 다음과 같다.
5. 설치 파라미터 설정 - 포트
6. Meta DB 및 Repository DB 파라미터 설정
참고
Meta DB 및 Repository DB 파라미터 변경이 필요한 경우, 관련 파라미터 설정은 OpenSQL 사용 가이드를 참조할 수 있다. 그러나 관련 파라미터 설정을 임의 수정하는 경우, SysMasterDB 서버의 정상 동작이 보장되지 않는다. 따라서 위 표에 명시된 파라미터 외 다른 파라미터는, 기본 제공 설정값을 그대로 사용하는 것을 권장한다.
현재 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
Chart Type
Instance Monitoring 페이지의 Layout Tab 영역에서 제공되는 모니터링 지표 차트의 종류에 대해 설명한다.
Bar
인스턴스별 해당 지표의 실시간 값을 막대 그래프로 나타내는 차트이다.
Line 또는 Area 차트로 전환이 가능하다.
Line
인스턴스별 해당 지표의 실시간 값을 꺾은선 그래프로 나타내는 차트이다.
Bar 또는 Area 차트로 전환이 가능하며, 부가 기능을 통해 선 굵기를 사용자가 직접 설정할 수 있다.
인스턴스별 해당 지표의 실시간 값을 영역 그래프로 나타내는 차트이다.
Bar 또는 Line 차트로 전환이 가능하다.
인스턴스별 해당 지표의 실시간 값을 누적 막대 그래프로 나타내는 차트이다.
Grid 차트로 전환이 가능하며, 부가 기능을 통해 해당 지표의 범위값을 사용자가 직접 설정할 수 있다.
인스턴스별 해당 지표의 실시간 값을 테이블 형태로 나타내는 차트이다.
각 인스턴스별로 탭을 구분하여 해당 지표의 실시간 값을 제공하며, Stack Bar 차트로 전환이 가능하다.
인스턴스별 해당 지표의 실시간 값을 원형 그래프로 나타내는 차트이다.
각 인스턴스별로 탭을 구분하여 해당 지표의 실시간 값을 제공한다.
인스턴스별 해당 지표의 실시간 값을 분산형 그래프로 나타내는 차트이다.
부가 기능을 통해 해당 지표값의 조회 범위를 사용자가 직접 설정할 수 있다.
Scatter 차트로 제공되는 Response Time 지표의 경우, 차트 내 드래그를 통해 원하는 영역을 선택할 수 있다.
이 때, 드래그로 선택한 영역 내의 각 포인트에 해당하는 SQL Trace 정보가 Long SQL List 모달을 통해 제공된다.
Long SQL List 모달의 각 칼럼은 다음과 같다.
칼럼명
내용
Long SQL List 모달의 테이블 내 각 항목 클릭 시, 해당 SQL Trace가 수행된 Session Detail 페이지로 이동한다.
추가로, Super Admin 또는 Admin 권한을 가진 사용자에게는 Long SQL List 모달에 Download 버튼이 제공된다.
해당 클릭하면, 테이블 데이터를 csv 형식의 파일로 내려받을 수 있다.
일반 사용자에게는 기본적으로 Download 버튼이 표출되지 않으나, Admin 사용자에 의해 Data Export 권한을 부여받은 경우에는 해당 기능을 사용할 수 있다.
설치 및 파라미터 설정
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 파일은 기본적으로 제공되는 설정값을 사용하되, 다음에서 설명하는 파라미터는 필요 시 구동 환경에 맞게 사용자가 직접 설정해준다.
파라미터 이름
설명
INFO
DEBUG
TRACE
[참고]설정하지 않으면 INFO 로 설정됨.
DEBUG 이상 설정을 할 경우 로그양이 많아져 TPM Agent 에 설정한 주기 안에 수집을 하지 못하여 데이터 누락이 발생할 수 있음. 그로 인하여 실시간 데이터 모니터링 중 데이터가 조회되지 않는 현상이 있을 수 있음. 따라서 운영 환경에서는 해당 설정을 하지 않는 것을 권고하며, 이슈 분석을 위해서만 해당 로그 레벨을 설정.
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 사용이 불가능해지는 상황이 우려되고, 이를 방지해야만 하는 경우
사용자는 필요에 따라, 해당 두 파라미터 중 원하는 파라미터만 선택적으로 설정하는 것도 가능하다.
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 사용이 불가능해지는 상황이 우려되고, 이를 방지해야만 하는 경우
이때, 사용자는 아래 파라미터 설정을 통해 (마이그레이션 패치를 수행하되,) 패치 수행 대상 데이터 범위(일 단위 기간)를 별도로 설정할 수도 있다.
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가 정상 기동하지 않을 수 있다.
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한 횟수
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] 권한이 부여된 사용자는 해당 인스턴스의 세션을 종료할 수 있다.
Session 모니터링 주요기능
Session 목록
관제 대상 DB의 각 session 정보를 테이블 형식으로 보여주고, last update를 명시하여 현재 어떤 시간의 정보인지 확인할 수 있다.
항목
설명
사용자는 Elapsed Time의 기준을 설정할 수 있으며, 설정된 범위로 어떤 세션이 오래 수행되었는지를 색상을 통해 직관적으로 파악할 수 있다.
세션을 Kill 시킬 수 있다. Session Monitoring 기능에 대한 권한(Privileges)이 Full로 설정된 유저만 수행할 수 있으며, Session 목록에서 특정 세션을 클릭해야만 해당 버튼이 표시된다.
[Kill Session] 버튼을 클릭하면 Kill Session 팝업창이 열린다. 이때 해당 세션을 Kill 하거나 동작을 취소할 수 있다.
다음은 Kill Session 팝업창에서 제공하는 정보에 대한 설명이다.
항목
설명
이 수행됨.
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 파라미터를 true로 설정(주석 제거)한 경우, 본 파라미터 설정은 무시됨.
Module
dbms_application_info.set_module로 지정된 모듈의 이름
Logical Reads
세션의 Logical Reads 값
Physical Reads
세션의 Physical Reads 값
Execute Count
세션의 Execute Count 값
Hard Parse Count
세션의 Hard Parse 값
Wait Event
세션의 Wait Event 이름
Wait Time
세션이 Wait Event로 대기한 시간
Status
세션의 상태
READY : 세션 준비 상태
RUNNING : 세션 Running 상태
TX_RECOVERING : 트랜젝션 복구 중 상태
State
작업 스레드의 상태
INVALID : 초기화 되지 않음
NEW : 생성 중
IDLE : 실행될 준비가 됨
PGA Used Memory
세션의 PGA 메모리 사용량
SQL Trace
세션에서 SQL 추적을 사용할지 여부
WLock Wait
세션이 대기 중인 Wait 타입
Redo Entries
세션의 Redo Entries 값
Tx Undo Block Count
Transaction Undo Block 개수
Tx Undo Record Count
Transaction Undo Record 개수
User Commits
세션의 User Commits 값
Audsid
세션의 두 번째 시리얼 번호
User ID
User ID 정보
IP Address
User 접속 IP 주소
Command
현재 실행 중인 SQL 타입
0 : 실행 중인 SQL 없음
1 : SELECT
2 : INSERT
3 : UPDATE
4 : DELETE
5 : MERGE
6 : CALL
Schema
세션의 스키마
Session 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
Prev SQL ID
마지막으로 수행된 SQL의 SQL ID
Child Number
세션이 수행 중인 SQL ID의 Child Number 값
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의 이름
Program
세션의 프로그램 이름
Module
세션의 모듈 이름
Wlock Wait
세션이 대기 중인 Wait 타입
Machine
연결된 세션의 호스트 이름
SID
세션의 ID
Serial#
세션의 시리얼 번호
Elapsed Time
세션의 현재 수행 중인 SQL의 Elapsed Time
Username
현재 사용자 이름
Program
SID / Serial#
세션의 ID / 세션의 시리얼 번호
Status
세션의 상태
User Name
세션 사용자 이름
참고
Session 정보 수집에 사용하는 티베로 라이브러리 이슈로 일부 정보에 Username, Program, Module, Schema, Terminal, Machine, OS User 등 항목이 수집되지 않을 수 있다.
Long running session 모니터링
Kill Session
참고
해당 인스턴스의 세션을 종료할 수 있다(Session Kill). Configurable Privileges 중 선택한 인스턴스에 대해 [Kill Session] 권한이 부여된 사용자에 한해 사용할 수 있는 기능이다.
세션의 프로그램 이름
SESS_CLEANUP : 세션 리소스 정리 중 상태
ASSIGNED : 세션에 스레드가 할당되었지만 아직 준비가 되어 있지 않은 상태
CLOSING : 세션이 닫힌 상태
ROLLING_BACK : PE명세 레벨 트렌젝션의 Slave가 롤백된 상태
RUNNING : 실행 중
WAITING : 내부 메시지 대기 중
RECV_WAITING : 클라이언트 메시지 대기 중
STOP_BY_MTHR : 모니터링 프로세스에 의해 중지됨
DEAD: Dead 상태
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의 전체적인 지표를 파악할 수 있다.
