리스너 로그 확인

리스너 로그를 통해서 언제 어떤 클라이언트가 접속을 시도했는지 확인할 수 있다. 그러나 client의 접속 요청이 Listener에게 도달하기 전에 문제가 발생한 경우에는 리스너 로그에 아무것도 남지 않는다. 

만약 client 접속 요청이 실패하는 경우 리스너로그 확인 후 리스너 로그에 아무런 로그가 남아있지 않다면 네트워크 쪽을 확인해보거나 해야 하며, 로그가 남은 경우에 로그 기록에 따라 조치를 취하면 된다.

 

리스너 로그 조회

$ cat $TB_HOME/instance/$TB_SID/log/lsnr
$ vi trace_list.log 
# or $ tail -n10 trace_list.log

 

로그 예시

# 세션에 클라이언트 접속요청 후 접속 성공한 경우 발생하는 로그
2025/07/30 16:08:43.990291 [5] listener:1452 a new client connection detected.
2025/07/30 16:08:43.990326 [5] listener:1371 a client connection from [127.0.0.1:44318] # 접속 요청한 클라이언트 정보
2025/07/30 16:08:43.990332 [5] listener:1494 a client from IP socket
2025/07/30 16:08:43.990344 [5] listener:3104 sent a connection fd to the WTHR process 1 successfully. # 클라이언트 WTHR(WORKER THREAD) 커넥션 성공

 

리스너 로그가 현재 어떤 포트를 리스닝하는지 확인

$  netstat -tlpn | grep tblistener
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:8629            0.0.0.0:*               LISTEN      2026/tblistener

 


DB 접속 세션 끊기

DBA가 DB관련 작업을 할 때 모든 세션을 끊고 작업을 해야하는 경우가 있다. 실제 운영중인 서버인 경우 세션이 붙어있을 것이다. 이때는 세션이 연결되지 못하도록 막고, 기존 세션들을 끊는 작업이 필요하다. 

반드시 세션이 연결되지 못하도록 막는 것이 선행되어야 한다. (은행 창구에 대입하여 생각하면 이해하기 쉽다.)

은행 번호표 뽑는 것을 막지 않고 기존 고객을 쫒아내더라도 번호표는 계속 뽑히고 있을테니 계속해서 손님은 들어올 것이다. 번호표 기계를 먼저 종료한 후 기존 고객 거래를 끝내야 은행창구에 아무도 없을 것이다.

 

세션이 연결되지 못하도록 하려면 어떻게 해야할까?

세션을 연결하도록 하는 것은 Listener의 역할이다. Listener가 더이상 세션 연결 요청을 리스닝하지 못하도록 OFF 하는 방법이 있다.

 

1. 신규 세션 생성 막기

리스닝 OFF

리스닝 off 의 경우 아래 명령어를 실행하면 된다. 반대로 리스닝 ON은 OFF를 ON으로 변경하여 실행하면 된다.

ALTER SYSTEM LISTENER REMOTE OFF;

 

작업 후 netstat -tlpn | grep tblistener 조회해보면 아무것도 출력되지 않은 것을 확인할 수 있다.

 

2. 기존 세션 연결 끊기

기존 세션 연결 끊는 명령어는 아래와 같다. SID 와 SERIAL# 값은 V$SESSION 시스템뷰나 tm(tibero monotor)를 통해서 조회할 수 있다. 여기서는 V$SESSION을 통해 조회해보자

ALTER SYSTEM KILL SESSION(SID, SERIAL#);

 

V$SESSION을 통해 SID, SERIAL# 값 조회하기

VT_MYTID를 통해 나는 어떤 SID를 사용중인지 확인이 꼭 필요하다. 실수로 나의 연결을 끊어버릴 수 있기 때문이다.

SELECT 
	SID, 
	SERIAL#,
	USERNAME,
	PROG_NAME
FROM V$SESSION;

# 조회 결과
#	SID	SERIAL#	USERNAME	PROG_NAME
1	77	6,058	SYS	tbsql
2	87	632	TIBERO	Studio
3	88	1,360	SYS	tbsql
4	89	1,051	SYS	Studio

# 나는 어떤 SID 사용중인지?
SQL > SELECT * FROM VT_MYTID; -- 77

# 기존 접속 끊기
ALTER SYSTEM KILL SESSION(87, 632);
ALTER SYSTEM KILL SESSION(88, 1360);
ALTER SYSTEM KILL SESSION(89, 1051);
728x90

Tibero Instance Paramter 파일 (TIP파일)

TIP 파일은 Tibero 데이터베이스의 초기화 파라미터(Parameter)를 정의한 설정 파일이다.

  • 확장자 : .tip
  • 기본 위치 : $TB_HOME/config/$TB_SID.tip
  • 역할 : DB 인스턴스 구동 시 필요한 환경설정 값 로딩
  • 주요 설정 : 메모리 크기, 로그 경로, 백업 설정, listener 포트
# 파라미터 파일 내용 예시
# DB 이름
DB_NAME=tibero
# 리스너 포트
LISTENER_PORT=8629
# 컨트롤 파일
CONTROL_FILES="/tibero/tbdata/control_1/c1.ctl","/tibero/tbdata/control_2/c2.ctl"
# db에서 생성된 파일 기본 저장 경로
DB_CREATE_FILE_DEST="/tibero/tbdata/data_1"
# 로그 아카이브 파일 경로
LOG_ARCHIVE_DEST="/tibero/tbdata/arch"

# 최대 연결 가능 세션 수
MAX_SESSION_COUNT=20
# 공유 메모리 사이즈
TOTAL_SHM_SIZE=1500M
# 전체 메모리 사이즈
MEMORY_TARGET=2048M

### LOG
# 로그 기본 경로
LOG_DEFAULT_DEST="/tibero/tibero7/instance/tibero/log"
# sys log 전체 최대 사이즈 => 오래된 순서로 삭제됨.
SLOG_TOTAL_SIZE_LIMIT=300M
# 리스너 로그 최대 사이즈
LSNR_LOG_TOTAL_SIZE_LIMIT=300M
# ilog 최대 사이즈
ILOG_TOTAL_SIZE_LIMIT=700M
# dbms 로그 최대 사이즈
DBMS_LOG_TOTAL_SIZE_LIMIT=300M
# sys 로그 파일 하나 당 사이즈
SLOG_FILE_SIZE=100M
# 리스너 로그 파일 하나 당 사이즈
LSNR_LOG_FILE_SIZE=10M
# ilog 파일 하나 당 사이즈
ILOG_FILE_SIZE=10M
# dbms 로그 파일 하나 당 사이즈
DBMS_LOG_FILE_SIZE=100M

### ETC
GATHER_SQL_PLAN_STAT=Y
# 날짜 포맷
NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS"

 

SQL 쿼리문으로 티베로 파라미터 정보 조회하기

- V$PARAMETERS 라는 시스템뷰를 통해 티베로 파라미터를 조회할 수 있다.

-- 예시코드
SELECT
	NAME
    , VALUE
FROM V$PARAMETERS
WHERE 1=1
AND NAME IN ('MEMORY_TARGET', 'TOTAL_SHM_SIZE')
;

 

공유 메모리(TSM) 크기 정보 조회

-- FIXED MEMORY (REDO LOG BUFFER, SYSTEM AREA, DATABASE BUFFER CACHE)
-- TSM에서 FIXED MEMORY에 해당하지 않는 것은 SHARED CACHE
SELECT
	NAME
    , ROUND(TOTAL / 1024 / 1024, 1) AS "TOTAL(MB)"
    , ROUND(USED / 1024 / 1024, 1) AS "USED(MB)"
FROM V$SGA;

 

*SQL WORK AREA → SORT_AREA_SIZE를 통해 사이즈 설정이 가능하다. (DEFAULT PGA의 30%)
*MEMORY TUNER → 티베로 내부적으로 SQL WORK AREA 메모리 사용할 때 3초 단위(감시 단위 변경 가능)로 확인하면서 메모리 사용량을 조절해준다.

-- SORT 작업용 메모리 크기
SORT_AREA_SIZE

-- HASH 조인용 해시테이블 할당 메모리 크기 설정
HASH_AREA_SIZE

-- PGA 메모리의 SQL WORK AREA 공간 크기 검사 주기
EX_MEMORY_COMPENSATE_INTERVAL

* 위 3개 파라미터 조회 쿼리
SELECT NAME, VALUE, DFLT_VALUE
FROM V$PARAMETERS
WHERE 1=1
AND NAME IN ('SORT_AREA_SIZE', 'HASH_AREA_SIZE', 'EX_MEMORY_COMPENSATE_INTERVAL');

 

 

 

728x90

Tibero Process 확인

# 현재 실행중인 티베로 프로세스 조회
$ ps -ef | grep tbsvr 

# 현재 실행중인 티베로 리스너 조회
$ ps -ef | grep tblistener

조회 예시

# 티베로 프로세스 조회
$ ps -ef | grep tbsvr

tibero      2025       1  0 14:09 pts/0    00:00:01 tbsvr          -t NORMAL -SVR_SID tibero # monitor process
tibero      2027    2025  0 14:09 pts/0    00:00:00 tbsvr_MGWP     -t NORMAL -SVR_SID tibero # 관리자 접속용 
tibero      2028    2025  0 14:09 pts/0    00:00:00 tbsvr_FGWP000  -t NORMAL -SVR_SID tibero # Worker Process
tibero      2029    2025  0 14:09 pts/0    00:00:01 tbsvr_FGWP001  -t NORMAL -SVR_SID tibero # Worker Process
tibero      2030    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP000  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2031    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP001  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2032    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP002  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2033    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP003  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2034    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP004  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2035    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP005  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2036    2025  0 14:09 pts/0    00:00:02 tbsvr_AGNT     -t NORMAL -SVR_SID tibero # 에이전트
tibero      2037    2025  0 14:09 pts/0    00:00:00 tbsvr_DBWR     -t NORMAL -SVR_SID tibero # DB Writer process
tibero      2038    2025  0 14:09 pts/0    00:00:00 tbsvr_RCWP     -t NORMAL -SVR_SID tibero # 복구 프로세스

 

# 리스너 프로세스 조회
$ ps -ef | grep listener 
[tibero@T6:/tibero/tibero7/config]$ ps -ef | grep listener
root         934       1  0 12:12 ?        00:00:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
tibero      2026    2025  0 14:09 pts/0    00:00:00 /tibero/tibero7/bin/tblistener -n 11 -t NORMAL -SVR_SID tibero

 


Tibero Memory Structure

Tibero Memory 구조는 TSM(Tibero Shared Memroy=SGA)와 PGA(Process Global Area)로 구성되어 있다.

  • PGA는 프로세스 끼리 서로 공유하지 않는 메모리 공간으로 MEMORY_TARGET - TOTAL_SHM_SIZE 즉, 전체 메모리 크기에서 TSM 크기를 뺀 나머지 사이즈가 PGA 크기이다. 
  • TSM은 인스턴스끼리 공유하는 메모리 영역으로, 사이즈는 TOTAL_SHM_SIZE 파라미터로 지정한다.

 

TSM (Tibero Shared Memory)

1. DB Buffer Cache

  - 최근 테이블, 인덱스의 데이터를 저장한다.

  - DB_CACHE_SIZE 파라미터로 크기를 지정한다.

  - DB Buffer Cache에 올라온 데이터 블록은 재사용된다.

  - DB Buffer Cache Hit 율이 높다. ▶️ 버퍼 캐시 내의 데이터 블록들의 재사용성이 높다. ▶️ Disk I/O가 적다

 

2. Redo Log Buffer

  - 데이터 처리 작업 내용을 저장 한다.

  - 기본 10MB 크기이며, LOG_BUFFER 파라미터로 크기를 설정하낟.

  - 데이터 수정 내역을 저장한다.

  - 여러 사용자들의 Redo Log 들이 Redo Log Buffer에 저장된다.

  - Redo Log Buffer 내용은 Redo Log File에 저장된다.

 

3. System Area

  - 전역변수 공간으로, Worker Thread를 관리하는 공간이다.

  - 세션정보 관리 공간으로 구성된다.

 

4. Shared Cache

  1) PP Cache(Physical Plan Cache)

    - 최근 실행환 쿼리문, 구문 분석(파싱)정보, 실행계획 정보를 저장한다.

  2) DD Cache(Dictionray Cache)

    - 최근 실행한 SQL에서 사용하는 오브젝트(테이블, 컬럼, 사용자, 권한)의 데이터 사전 정보 저장

 

PGA(Process Global Area)

Worker Process 간에 공유하지 않는 독립적인 메모리 영역이다.

PGA 크기 = MEMORY_TARGET - TOTAL_SHM_SIZE

 

1. SQL Work Area

  - Worker Thread가 SQL 수행 시 Sorting, Merge 조인, Hash 조인 작업 공간으로 사용 

  - 크기가 부족하면 임시 세그먼트 (Temporary Tablespace)를 사용하여 성능이 저하된다.

 

2. Process Memory

  - 프로세스가 동작하는 데 필요한 공간

 

3. SQL Info Area

  - 커서 정보 영역으로 SQL문을 처리하는데 필요한 공간

 

4. Session Info Area

  - 로그인 및 세션 관련 정보 저장

 

✅ 관리자 입장에서의 메모리 관리 

1. 각각의 메모리 크기 관리

2. 메모리들이 본래 목적에 맞게 잘 돌아가는지 확인

  - Hit율로 확인한다. ➡️ 100%에 가까울수록 좋다 ➡️ Hit율이 높다는 것은 그만큼 프로세스간 메모리 공유가 잘 된다는 것 

  - 크기, Hit율을 파악하여 조치해야 한다.

    ✔︎ 메모리 추가

    ✔︎ 기존 메모리 비율 재설정

    ✔︎ 기존 메모리를 효율적으로 사용하도록 수정 (ex, SQL Query 튜닝)

*튜닝이 필요한 쿼리 찾기 ➡️ 쿼리 모니터링(PP Cache) ➡️  쿼리 튜닝을 통해 Temp Tablespace를 적게 사용하도록 하거나, 실행계획을 조금 더 효율적으로 수정하거나 등등,,

 

OLTP 와 OLAP

  • OLTP(Online Transaction Processing)
    • 온라인 트랜잭션 처리 시스템
    • 사용자들이 실시간으로 데이터에 접근하고 처리하는 시스템을 의미
    • ex) 은행 ATM 이체, 온라인 쇼핑몰 상품 주문 등
  • OLAP(Online Analytical Processing)
    • 온라인 분석 처리 시스템
    • 대량의 데이터를 분석하고 인사이트를 얻기 위한 시스템
    • ex) 매출 분석 보고서, 고객 행동 패턴 분석

✔︎ OLTP vs OLAP 비교표

비고 OLTP OLAP
목적 실시간 업무 처리 데이터 분석
사용자 일반 사용자 관리자, 데이터 분석가
데이터 자주 변경 주로 읽기 전용
트랜잭션 짧고 빠름 길고 복잡함
예시 은행, 쇼핑몰 매출분석, 경영 리포트

 

업무 성격에 따른 메모리 크기 비율 설정 ( OLTP, OLAP )

1. OLTP → 8(TSM) : 2 (PGA) 비율

  - OLTP는 소량 데이터를 여러 세션에서 접근하는 경우가 많다. 소량의 데이터를 버퍼 캐시에서 빠르게 접근하기 때문에 PGA 크기가 많이 필요하지 않다. (소량 데이터라 처리 부담이 적음)

 

2. OLAP → 5(TSM) : 5 (PGA) 비율

  - OLAP는 대량의 데이터를 분석, 집계하는 경우로, 대량 데이터 처리(sorting 등 ) 하는데 작업 공간이 많이 필요하다. PGA가 커야 원할하게 작업을 처리할 수 있다. 대량 데이터 처리 환경에서는 1년치 데이터 or 테이블 모든 데이터 접근 하기 위해서 대량 데이터를 버퍼 캐시에 올려야 한다. 기존 버퍼 캐시 재사용이 잘 되지 않는다.

 

 

728x90

Tibero 구조

 

Client 가 Tibero DB에 접속하기 위해서는 Listener를 거쳐 유휴 Worker Thread를 할당 받아 Session을 맺은 후 여러 작업(SELECT, UPDATE, DELETE 등)을 수행한다.

 

그렇다면 Listener 는 어떻게 Worker Thread를 할당시켜줄까?

Client가 Tibero Instance에 접속을 요청하면 Listener가 해당 요청(request)를 받아 유휴한 Worker Process에게 해당 요청을 전달한다. 요청을 전달받은 Worker Process는 Control Thread 를 통해 유휴한 Worker Thread 를 배정해주며, 해당 Worker Thread가 Client 의 인증정보를 확인 후 세션을 맺게 된다. ( Connect )

 

Control Thread는 Worker Process 당 1개씩 존재하며, Worker Thread 는 default 값 10으로 Worker Process당 10개씩 존재한다.

 

즉, Client 는 Worker Process 와 연결이 되지 않으면 DB에 접근이 불가능하다.

Client 가 DB에 접속을 하지 못하고 있는 상태라면, 어디서 문제가 있는지 다음과 같이 생각해 볼 수 있다.

1. Listener가 Worker Process에게 요청을 던져주기 전

2. Listener가 Worker Process에게 요청을 던져준 후

 

1번인 상황이라면 네트워크의 문제로 client의 접속요청이 listener 까지 닿지 못했거나, listener 단에서 문제가 발생했다고 가정할 수 있다. 이러한 정보들은 listener log 를 통해서 확인할 수 있다.

2번 상황이라면 티베로 시스템 로그를 확인해 보아야 한다. 

 

리스너의 포트 넘버는 tip 파일에서 설정한다.

# $TB_SID.tip
LISTENER_PROT=8629

 

요약

< 티베로 접속 과정 >

1. client -> listener 접속 요청

2. listener -> control thread 요청

3. control thread -> 유휴 worker thread 할당

4. client <--> worker thread 인증 절차 후 세션 시작

 

< 접속정보 5가지 >

- IP

- PORT

- DB NAME

- USERNAME

- PASSWOD

*DB NAME : Instance 는 자기가 관리하는 데이터에비스를 DB NAME으로 인식한다. (DB 설치할 때 이름 부여)

 

< 리스너 로그를 통해 알 수 있는 정보 >

1. 접속요청한 클라이언트 IP

2. 워커프로세스 할당

* 리스너로그가 남아있지 않다는 것은 LISTENER에게 접속 요청이 오지 않았다는 것으로, 네트워크 문제가 있었을 수 있기 때문에 네트워크를 확인해 보아야 한다.

 

< 티베로 시스템 로그 >

- LISTENER 로그까지 남아있지만 접속이 안된 경우 확인해보기


프로세스

Listener 

- 사용자의 최초 접속 요청시 중계 역할

Worker Process (or Foreground Process)

- Tibero 동시 접속이 가능한 클라이언트의 수를 의미한다.

- (최대 DB 세션 수) = (워커프로세스 수 * 워커프로세스당 워커스레드 개수)

- MAX_SESSION_COUNT (권장하는 파라미터)

- 워커 프로세스를 강제 종료하게 되면 다른 워커프로세스들은 영향을 받지 않고, 죽은 워커프로세스는 다시 살아나지 않는다.

 

Worker Thread

- Tibero가 기동될 때 생성된 이후 종료할 때까지 계속 존재하는 Thread

- Client와 접속이 끊겨도 종료되지 않는다.

- 워커 스레드를 강제로 Kill 하게 되면 Tibero Instance는 비정상 종료하게 된다.

 

서비스를 운영하다가 사용자가 급격하게 많아져 워커 스레드가 부족할 수도 있다. 이때 워커스레드의 개수는 동적으로 증가시키는 것은 불가능하다. 워커 스레드의 수를 늘리려면 tip 파일에서 값을 수정 후 DB를 재기동해야 한다. 

부족 현상이 일어나지 않도록 사전에 넉넉하게 MAX_SESSION_COUNT 값을 설정해 두어야 한다.

 

MGWP

- SYS 계정은 두 가지 방식으로 DB Instance 연결이 가능하다.

1. LISTENER 와 WORKER PROCESS를 통해 접속하는 경우

2. MGWP를 통해 접속하는 경우

  - Worker Thread를 사용자들이 전부 점유하는 경우 SYS가 붙지 못한다.

  - Special Port 는 보통 Listener Process Port (=SERVICE PORT) + 1

  - Worker Thread를 통해 접속하는 것과 크게 다르지 않다.

 

MGWP 를 통해 접속하느 방법은 tbdsn.tbr 에 Special Port 를 추가해 준 후 명시적으로 접속해준다.

# tbdsn.tbr 
special=(
    (INSTANCE=(HOST=localhost)
              (PORT=8630)
              (DB_NAME=tibero)
    )
)

tibero=(
    (INSTANCE=(HOST=localhost)
              (PORT=8629)
              (DB_NAME=tibero)
    )
)

 

# MGWP로 접속하는 방법
$ tbsql sys/tibero@special

 

세션 모니터링 

- tm 툴 사용하기

- v$session 시스템 뷰 조회

 

<DB SESSION>

- 워커 스레드 <-----------> 사용자

- 식별자 (SESSION ID (SID), SERIAL#)

- 조회 가능 ( V$SESSION or GV$SESSION )

- 여러 정보들 ( 클라이언트 정보, 쿼리, 메모리 사용량 )

 

사용자 접속 차단

- 서비스 운영 중 거래가 없는 상태에서 작업을 해야 할 수도 있다. 그럴때는 어떻게 거래를 막아야 할까? 

사용자를 두 가지 분류로 나눌 수 있다. 이미 접속해 있는 사용자, 접속을 시도하는 사용자

그렇다면 우선 접속을 시도하는 사용자의 접속이 불가능하도록 막아야한다. 그 후 이미 접속해 있는 사용자의 거래가 끝나길 기다리던가, 강제로 접속을 끊으면 모든 사용자 접속을 차단할 수 있다. (마감시간 은행 창구를 생각하면 이해가 쉽다. )

 

사용자의 접속 시도는 어떻게 막을 수 있을까?

사용자가 접속 가장 처음 받는 것은 LISTENER 프로세스이다. 사용자가 알고 있는 LISTENER 프로세스의 포트 번호를 바꾸거나, 명령어를 통해 OFF 해준다.

 

SID, SERIAL#은 V$SESSION을 통해 조회할 수 있다. 잘못해서 내 세션을 끊을수도 있기 때문에 나의 SID를 미리 확인해주자. 

SQL > SELECT * FROM VT_MYTID;

-- 리스너 리스닝 OFF
ALTER SYSTEM LISTENER REMOTE OFF;

-- 접속되어 있는 사용자 세션 끊기
ALTER SYSTEM KILL SESSION(SID, SERIAL#);

 

 

 

728x90

+ Recent posts