[Tibero] Tibero 데이터베이스 유지관리 [1] 프로세스 구조

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#);