주 콘텐츠로 건너뛰기
📓 Tibero Online Manual Click here 📓

검색

Welcome to Tibero GTS!

Tibero 운영 관리

문서유형ㅣ기술 정보

분야ㅣ보안

적용제품버전ㅣ7FS02PS 6FS07_CS_2005

문서번호ㅣTSETI018

 

개요

Tibero 운영에 필요한 내용을 기술합니다. 

 

 

방법

1. Tibero 기동과 종료

본 절에서는 Tibero를 기동하고 종료할 때 사용하는 명령어와 이를 사용하는 방법을 설명합니다. 

 

1.1. 환경 설정

  • tbboot는 Tibero가 설치된 장치에서 실행해야 됩니다. 또한, tbboot 를 실행하기 전에 반드시 환경 변수가 제대로 설정되어 있어야 합니다. 이 명령어와 관련된 환경 변수는 유닉스 계열의 경우 $TB_HOME과 $TB_SID입니다.
     
  • 또한, tbboot는 실행 파일을 실행할 수 있는 권한이 있는 사용자라면 어느 누구든 Tibero를 기동 할 수 있습니다. 따라서 이는 보안 문제가 발생할 수 있어, 정책 상 Tibero를 설치한 사용자만 Tibero의 실행 파일에 접근할 수 있도록 권한을 설정할 것을 권장합니다.

 

[예제]  파일의 권한(Permission) 설정 방법

$ cd TB_HOME/bin
$ chmod 700 tbsvr tblistener tbboot tbdown tbctl
$ ls -la
total 491232
... 중략
-rwx------ 1 tibero tibero      2557 Jan 24 17:29 tbboot 
-rwx------ 1 tibero tibero     13869 Jan 24 17:29 tbctl 
lrwxrwxrwx 1 tibero tibero        30 Jan 27 21:27 tbdown -> /home/tibero/tibero7/bin/tbsvr
-rwx------ 1 tibero tibero  19899671 Jan 24 17:54 tblistener 
-rwx------ 1 tibero tibero 200758410 Jan 24 17:55 tbsvr
... 중략

 

 

1.2. DBMS 단계

 

[그림9] DBMS 구동 단계

  • 1단계: Database Nomount
    • NOMOUNT : Instance 시작 단계
    • Database 생성 가능
    • Control File 생성 가능
  • 2단계: Database Mount
    • MOUNT: Control File Open단계
    • Datafile 이름 변경 가능
    • Online Redo Log File, Archive 옵션 활성화/비활성화 가능
    • 전체 database 복구 작업 가능
  • 3단계: Database Open
    • OPEN: Control File 에 정의한 모든 File Open

 

1.3. Tibero 시작

  • DB 시작 방법
    • Tibero Start 절차는 제공된 $TB_HOME/bin 하위의 tbboot 혹은 윈도우 버전의 경우 추가로 Service
      Control 방법을 이용할 수 있습니다.
  • DB 시작 절차
    • tbboot 에 의한 시작 방법을 설명합니다.

 

[예제] tbboot 사용

$ tbboot (Tibero 기동)

$ tbboot –v (Tibero 엔진 버전 확인)

$ tbboot –h 
Usage: tbboot [-h] [-v] [-l] [-C] [-t BOOTMODE]
  -h: show this help.
  -v: show RDBMS version.
  -p: show applied patches.
  -l: show license information.
  -C: show available character set list.
  -c: No replication mode.
  -w: wallet auto-login mode.
  -d: redirecting stdout to outfile mode. (not supported in Windows)
  BOOTMODE: one of NOMOUNT MOUNT RECOVERY NORMAL RESETLOGS ALTERDD READONLY FAILOVER
  If no bootmode is set, default bootmode is 'NORMAL'.

[표2] tbboot 사용

옵션설명
 옵션이 없는 경우Tibero를 boot mode 중 NORMAL로 기동하는 옵션입니다.
-htbboot를 사용하기 위한 간단한 도움말을 보여주는 옵션입니다.
-v버전 정보를 보여주는 옵션입니다. (-version과 동일)
-t서버 단계 별 기동 옵션이며,생략 가능합니다.

DB 시작 모드 설명

  1. NORMAL 모드로 실행
     

    • 정상적으로 데이터베이스의 모든 기능을 사용할 수 있는 모드입니다. 

      [예제] tbboot NORMAL 모드

      $ tbboot
Change core dump dir to /sdiske/ps1/pjha/tibero7/bin/prof.
Listener port = 8629

Tibero 7

TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Tibero instance started up (NORMAL mode).

참고 

데이터베이스를 비정상적으로 종료한 경우 Tibero가 기동할 때 자동으로 파손 복구(crash recovery)를 실행합니다.

  1. NOMOUNT 모드로 실행
  • Tibero의 프로세스만 기동 시키는 모드입니다. 일반적으로는 이 모드를 사용하는 경우는 거의 없습니다.
     

  • Tibero가 기동한 다음에 CREATE DATABASE 문을 이용하여 데이터베이스를 생성하는 것 밖에 없습니다.

    [예제] tbboot NOMOUNT 모드

     

    $ tbboot nomount
Change core dump dir to /sdiske/ps1/pjha/tibero7/bin/prof.
Listener port = 8629

Tibero 7

TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Tibero instance started up (NOMOUNT mode).
  1. MOUNT 모드로 실행

  • 미디어 복구를 위해 사용하는 모드입니다. 

    [예제] tbboot MOUNT 모드

    $ tbboot mount
Change core dump dir to /sdiske/ps1/pjha/tibero7/bin/prof.
Listener port = 8629

Tibero 7

TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Tibero instance started up (MOUNT mode).
  1. RESETLOGS 모드로 실행

  • Tibero 서버를 기동하는 과정에서 로그 파일을 초기화하며, 미디어 복구 이후에 사용하는 모드입니다. 불완전 복구 시 이용하는 모드입니다.

    [예제] tbboot RESETLOGS 모드

    $ tbboot mount
Change core dump dir to /sdiske/ps1/pjha/tibero7/bin/prof.
Listener port = 8629

Tibero 7

TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Tibero instance started up (NORMAL RESETLOGS mode).

 

1.4. Tibero 종료

 

DB 종료 방법

  • Tibero 종료 절차는 제공된 $TB_HOME/bin 하위의 tbdown 혹은 Windows OS 버전의 경우 추가로 ServiceControl 방법을 이용할 수 있습니다.

DB 종료 절차

  • tbdown 에 의한 시작 방법을 설명합니다.

    [예제] DB 종료 방법

    $ tbdown
$ tbdown -h
Usage: tbdown [-h] [-t DOWNMODE]
  DOWNMODE : NORMAL, POST_TX, IMMEDIATE, ABORT, SWITCHOVER, ABNORMAL

    [표3] tbdown 옵션 설명

    옵션

    		설명

     

    		옵션이 없는 경우 Tibero를 정상 모드로 종료하는 옵션입니다.

    -h

    		tbdown을 사용하기 위한 간단한 도움말을 보여주는 옵션입니다.

    -t

    		Tibero를 종료할 수 있는 옵션입니다. 이 옵션은 생략이 가능합니다.

 

참고 

만약 Tibero가 kill과 같은 시스템 내부 명령어에 의하여 비정상적으로 종료된 경우, 운영 중에 사용
하였던 공유 메모리나 Semaphore 자원들이 해제가 안 될 수 있습니다. 

이런 경우에 재기동을 시도하는 경우 실패를 하게 되고,이와 같은 서버의 비정상 종료 후, 재기동을 하기 위해서는 먼저 반드시 tbdown clean 명령어로 기존 자원을 해제 시켜야 합니다. 

비정상적으로 종료되더라도 초기화 파라미터 “BOOT_WITH_AUTO_TBDOWN_CLEAN”를 Y로 설정하면 자동으로 이전 운영 중에 사용하였던 자원을 해제하여 부팅 시킬 수는 있습니다. 

하지만 관리자가 서버의 비정상 종료 상황을 제대로 인지하지 못 하고 서버 운영을 할 수 있으며, 

기존 자원이나 프로세스가 제대로 정리가 안되는 예외적인 상황이 발생 하여 충돌이 날 수 있으므로“BOOT_WITH_AUTO_TBDOWN_CLEAN” 옵션을 켜는 것을 권장하지 않습니다.

 

DB 종료 모드 설명

[표4] DB 종료 모드

다운 모드설명
NORMAL일반적인 종료 모드입니다.
POST_TX모든 트랜잭션이 끝날 때까지 기다리고 나서 Tibero를 종료하는 모드입니다. 
IMMEDIATE현재 수행 중인 모든 작업을 강제로 중단 시키며, 진행 중인 모든 트랜잭션을 롤백하고Tibero를 종료하는 모드입니다.
ABORTTibero의 프로세스를 강제로 종료하는 모드입니다.
SWITCHOVERStandby DB와 Primary DB를 동기화 시킨 후, Primary DB를NORMAL모드처럼 종료하는 모드입니다.

 

NORMAL 모드로 실행

  • 일반적인 종료 모드입니다.

  • RDBMS에 SYS 사용자가 접속한 다음 다른 모든 session의 접속이 끊겨질 때까지 기다린 후, 그 다음 서버를 종료 시킨다. 일단 tbdown을 실행하고 나서 어떤 사용자도 더 이상 데이터베이스에 접속 할 수 없게 됩니다. 하지만, tbdown이 실행되기 전에 이미 데이터베이스에 접속한 사용자는 스스로 접속을 끊을 때까지 제한 없이 데이터베이스를 계속 사용할 수 있습니다.

    [예제] tbdown NORMAL 모드

    $ tbdown immediate

Tibero instance terminated (IMMEDIATE mode).

POST_TX 모드로 실행

  • 모든 TX(transaction)이 끝날 때까지 기다리고 나서 Tibero를 종료하는 모드입니다.
  • POST_TX는 Tibero에 SYS 사용자로 접속한 다음 모든 transaction이 끝날 때까지 기다린다. 그 다음 Tibero를 종료 시킨다. tbdown 실행이 시작되면 더는 데이터베이스에 접속할 수 없고, 이미 열려 있는 sesion에서도 새로운 transaction을 시작할 수 없게 됩니다. 다만, 현재 수행 중인 transaction은 commit 혹은 rollback 할 때까지 제한 없이 수행 할 수 있으며, commit이나 rollback을 하는 순간 자동으로 데이터베이스 접속을 종료하게 됩니다.

  • 또한, tbdown 실행이 시작되면 데이터베이스에 접속한 클라이언트에게 서버 종료를 알리는 메시지를 보내지 않습니다. tbSQL utility 등에서는 클라이언트가 서버 종료를 즉시 알지 못하고 그 다음 명령을 실행할 때 비로소 Tibero가 종료되었음을 알게 됩니다.

    [예제] tbdown POST_TX 모드 실행

    $ tbsql admin/password123
tbSQL 7
TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. Connected to Tibero.
SQL> CREATE TABLE T1 (COL1 NUMBER);
Table ‘T1’ created.
SQL> INSERT INTO T1 VALUES(10);
1 row inserted.
SQL> SELECT * FROM T1;
COL1
----
10
1 row selected.

  • 이 시점에서 tbdown POST_TX 명령을 실행합니다.

     

  • tbdown 명령은 트랜잭션이 끝나기를 기다린다. 

     

    SQL> COMMIT; Commit completed.

     

  • 이 시점에서 실제로 서버가 종료되고 tbdown 실행이 끝난다.

     

    SQL> SELECT * FROM T1;
TBR-2069: I/O read error

     

  • 서버가 종료되었으므로 tbSQL utility에서는 TBR-2069 에러가 발생됩니다.

IMMEDIATE 모드로 실행

  • 현재 수행 중인 모든 작업을 강제로 중단 시키며, 진행 중인 모든 tranaction을 rollback하고 Tibero를 종료하는 모드입니다.
  • IMMEDIATE는 Tibero에 SYS 사용자로 접속한 다음 현재 수행 중인 모든 작업을 강제로 종료하고 진행 중이던 모든 transaction을 Rollback한 후, Tibero를 종료 시킨다. 클라이언트에서 Tibero 종료를 알지 못하는 것은POST_TX 모드와 같습니다.

  • transaction이 오래 걸리는 작업 중에 있다면, 이를 모드 Rollback하기 위해서 다소 시간이 걸릴 수 있습니다.

    [예제] tbdown IMMEDIATE 모드

    $ tbdown immediate

Tibero instance terminated (IMMEDIATE mode).

ABORT 모드

  • Tibero의 프로세스를 강제로 종료하는 모드입니다.

  • ABORT는 Tibero에 접속하지 않은 채 Tibero의 모든 프로세스를 SIGTERM 시그널을 전달하여 강제로 종료 시키는 모드입니다. 

    따라서 이 모드는 비상 시에 사용하며, 원격이 아닌 서버에서만 실행 할 수 있습니다. 

    다음 번에 Tibero를 기동할 때 파손 복구 과정이 필요합니다.

    [예제] tbdown ABORT 모드 실행

    $ tbdown abort

Tibero instance terminated (abort mode).

     

    • ABORT는 Tibero가 강제로 종료시키므로 사용하던 시스템 리소스를 해체할 기회가 없습니다. 따라서 서버가 종료된 다음에도 공유 메모리(Shared Memory), 세마포어(Semaphore) 등의 시스템 리소스가 남아 있을 수 있으며, 로그 파일이나 데이터 파일도 마찬가지입니다. 또한, 다음 번에 Tibero를 기동할 때 파손 복구에 많은 시간이 걸릴 수도 있습니다.
       
    • ABORT는 다음과 같은 경우에만 제한적으로 사용할 것을 권장합니다.
      • Tibero의 내부 에러로 인한 정상적인 종료가 불가능한 경우
        예를 들어, 모든 session이 사용 중인 상태에서 클라이언트의 접속이 증가하는 경우가 해당됩니다.
      • H/W에 문제가 발생하여 Tibero를 즉시 종료해야 하는 경우
        해킹 등의 비상 상태가 발생하여 Tibero를 즉시 종료해야 하는 경우

SWITCHOVER 모드

  • SWITCHOVER는 Tibero Standby Cluster(TSC) 에서 사용하는 옵션이며, Standby DB와 Primary DB를 동기화 시킨 후, Primary DB를 NORMAL 모드처럼 종료하는 모드입니다.

 

2. 메모리 관리

  • Tibero에서는 빠른 I/O처리를 위해 메모리에 TSM영역을 설정합니다. TSM는 크면 클수록 좋으나 서버의 물리적 메모리 크기에 제약을 받는다. TSM 크기를 아무리 크게 하더라도 물리적 메모리가 크지 않다면 O/S레벨에서 Paging이 발생하기 때문에 시스템의 전체적인 성능을 저하 시키는 요인이 됩니다.
     
  • Memory: 
    System Memory(cf. Oracle의 PGA) 영역과 Shared Memory(cf. Oracle의 SGA) 영역으로 크게 구분됩니다.

 

[그림10] 전체 메모리 구조

 

 

2.1. 메모리 구성 환경

  • 아래의 그림은 메모리의 논리적 구조입니다. 

    [그림11] 논리적 메모리 구조

  • 아래 그림은 메모리 관련 Parameter와 영역에 대한 그림입니다. 

    [그림12] 메모리 Parameter (TSM) 구조

[표5] 현재 메모리 설정 정보

구분논리적 영역파라미터값(예제)
전체 메모리TSM(Tibero Shared Memory)TOTAL_SHM_SIZE10240M
Database buffer cache sizeDatabase BufferDB_CACHE_SIZE6800M
Redo Log buffer sizeRedo Log BufferLOG_BUFFER10M
Shared cache sizeShared Cache TOTAL_SHM SlZE - (DB_CACHE_SIZE+LOG_BUFFER+alpha)
PGA 영역PGAEX_MEMORY_HARD_LIMIT미설정 시 TOTAL_SHM_SIZE동일

 

 

2.2. 메모리 설정 방법

  • 메모리 설정은 $TB_HOME/config/$TB_SID.tip 파일을 수정합니다.
  • Parameter파일 (TIP)파일 수정하여 재기동 하거나, 동적으로 크기를 조정합니다.
    동적으로 적용가능한 것은 파라미터에 따라 다릅니다. 관련 내용은 파라미터 매뉴얼을 참조하면 됩니다.

 

2.3. 메모리 운영 절차

  • 동적 메모리 사이즈 조절

    • PGA영역의 사이즈 조절 “EX_MEMORY_HARD_LIMIT”
    • tbsql 에서 수정

    • Tibero 재기동 이후에는 설정이 초기화 되므로, 해당 값을 계속 사용할 예정이면, TIP 파일에도 내용을 적용해 두어서, 재기동 이후에도 반영되도록 합니다.

      • 문법: alter system set EX_MEMORY_HARD_LIMIT=<변경 값>

      [예제] PGA 메모리 동적 적용

      $ tbsql sys/tibero
tbSQL 7
TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
      SQL> show param EX_MEMORY_HARD_LIMIT

NAME                         TYPE     VALUE
---
EX_MEMORY_HARD_LIMIT         INT64    8589934592

1 row selected.
      SQL> alter system set EX_MEMORY_HARD_LIMIT=1073741824;

System altered.

SQL> show param EX_MEMORY_HARD_LIMIT

NAME                         TYPE     VALUE
---
EX_MEMORY_HARD_LIMIT         INT64    1073741824

1 row selected.

    정적 메모리 사이즈 조절

    • 메모리 설정은 $TB_HOME/config/$TB_SID.tip 파일을 수정합니다. 

    • 수정 후 tbdown > tbboot 명령 실행.

      [예제] TOTAL_SHM_SIZE 조정

      # RDBMS tip file generated from C:\Tibero\tibero7\config\tip.template(11 7 17:22:35 2023)
#---------------------------------------------------------------------
# RDBMS initialization parameter
#---------------------------------------------------------------------… …
...
TOTAL_SHM_SIZE=8192M
...

    메모리 DUMP 실행 방법

    • System Memory 영역(=PGA)
      • Dump File은 $TB_HOME/instance/$TB_SID/dump/tracedump 경로 하위에 “.trc” 파일로 생성된
        다

      • 주로 TBR-3003 에러(ERROR_OUT_OF_PHYSICAL_MEM) 발생 시 해당 내용을 dump 하여 ㈜
        TIBERO사에 분석 의뢰를 하면 됩니다.

        [예제] System Memory 메모리 Dump

        SQL> alter system dump systemalloc;

System altered.

    Shared Pool 영역(=SGA)

    • Dump File은 $TB_HOME/$TB_SID/dump/tracedump 경로 하위에 “.trc” 파일로 생성된다

    • 주로 TBR-3002 에러(ERROR_OUT_OF_SHP) 발생 시 해당 내용을 dump 하여 Tibero 벤더 회사에 분석 의뢰를 하면 됩니다.

      [예제] Shared Pool 메모리 Dump

      SQL> alter system dump shared pool;

System altered.

    Flush실행

    • Library Cache만을 Flush하여, 모든 쿼리 정보를 다시 만들어야 하기 때문에 일시적으로 Wait가 많이 걸
      릴 수 있습니다. 운영 중에는 되도록 실행하지 않습니다.

    • 필요 상황 : Cached의 SQL 실행 계획을 초기화 할 때

      [예제] Shared Pool 메모리 Flush

      $ tbsql sys/tibero

tbSQL 7
TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 

Connected to Tibero.

SQL> alter system flush shared_pool;

System altered.

참고

 Buffer Cache 를 초기화 할 경우 alter system flush buffer_cache; 명령어를 사용합니다.

 

2.4. 메모리 운영 참조

 

System Memory 참조

  • cf. PGA in Oracle
  • Fixed 영역
    • 부팅 시부터 malloc되는 기본 메모리 점유 됩니다.

    • 아래의 Parameter는 WTHR(work thread)마다 할당되어집니다. 

      [표6] System 메모리 관련 Parameter

      Parameter설명
      SQL_LOG_ON_MEMORY_SIZEsql_log_on_memory를 사용할 때 각 thread마다 사용하는 buffer 용량. (기본 값 100k)
      LOG_ON_MEMORY_SIZElog_on_memory를 사용할 때 각 thread 마다 사용하는 buffer 용량. (운영 시스템에 사용 미권장)
  • Allocator + Free : 초기 계산된 값으로 (_SYSTEM_MEMORY_RESERYED_SIZE) 점유 후 필요 시 확장 사이즈 만큼 확장되고, 불필요 시 반환하게 됩니다. 해당 영역은 EX_MEMORY_HARD_LIMIT 만큼 증가 가능합니다.
  • Allocator는 처음 만들 때부터 _SYSTEM_MEMORY_RESERVED_SIZE 만큼의 메모리를 잡고, 기존 영역이 모두 소진되연 _SYSTEM_MEMORY_EXPAND_SIZE (기본 4MB씩) 만큼 malloc 하여 공간을 확보하게 됩니다.

Shared Memory 참조

  • Fixed 영역: DB_CACHE_SIZE, LOG_BUFFER, alpha
  • Shared_pool 영역: TAC(cf. Oracle의 RAC)용 메모리 (shp_for_ccc, shp_for_cws)와 최소 
    shared_pool(_MIN_SHARED_POOL_SIZE)의 여유 shared_pool
     
    1. TAC용 메모리
      • CCC(Cluster Cache Control): 데이터베이스의 데이터 블록에 대한 클러스터 내 접근을 통제하는 모듈입니다. DLM이 내장되어 있습니다. CR Block Server, Current Block Server, Global Dirty Image, Global Write 서비스가 포함되어 있습니다. Cache Layer에서는 GCA(Global Cache Adapter)를 통해 CCC에 접근할 수 있으며, 이와 관련된 배경프로세스로 LASC, LKDC, RCOC이 존재합니다.
      • CWS(Cluster Wait-lock Service): 기존 Wait-lock(이하 Wlock)이 클러스터 내에서 동작할 수 있도록 
        구현된 모듈입니다. Distributed Lock Manager(이하 DLM)이 내장되어 있습니다. Wlock은 GWA를 통해 CWS에 접근할 수 있으며, 이와 관련된 배경 프로세스로는 LASW, LKDW, RCOW이 존재합니다. 이전의 Tibero 버전 에서는 Wlock이 싱글 인스턴스의 리소스만 보호했으나, 멀티 인스턴스를 지원하는 TAC 환경에서는 CWS를 통해 다른 노드와 동기화를 통제할 수 있습니다.

      • 계산 공식 예

        shp_for_ccc = 416 * CCC_RECL_MAX_RESOURCES (= 0.273 * DB_CACHE_SIZE )
= 416 * 5632K = 2288M

shp_for_cws = 368 * CWS_RECL_MAX_RESOURCES(= 89750 * WTHR_PROC_CNT *  WTHR_PER_PROC )
= 368 * 215K = 77M

        [표7] TAC용 메모리

        Parameter설명
        CCC_RECL_MAX_RESOURCES메모리에 유지할 CCC 리소스 블록의 최대 개수를 설정하는 파라미터입니다.
        CWS_RECL_MAX_RESOURCES메모리에 유지할 CWS 리소스 블록의 최대 개수를 설정하는 파라미터입니다.

최소 shared_pool

  • 최소 공유 Pool계산 공식

    _MIN_SHARED_POOL_SIZE = 1M * WTHR_PROC_CNT * WTHR_PER_PROC
= 1M * 300 = 300M(이론 계산 값)
= 사이트 _VT_PARAMETER 에 셋팅된 값은 = 300M

참고) 부팅 가능 최소 SHM
shared_pool > shp_for_ccc + shp_for_cws + _MIN_SHARED_POOL_SIZE
=shared_pool > 0 + 0 + 300M = 300M

  • DB_CACHE_SIZE 부팅 시 최소 용량 관련 Cache의 최소 크기는 모든 Thread에서 동시에 Multi Block Read를 했을 때 이를 수용할 수 있는 size로 정해집니다. 지금 DB Cache Size인 6800M는 870400개의 Block을 수용할 수 있습니다. 이 중에서 1/4영역만을 LRU Victim 영역으로 사용합니다. 즉 Cache의 1/4영역에서 victim을 못 찾으면 LRU 에서 Block들을 쫓아내서 Victim을 확보합니다. 그러므로 870400 / 4 = 217600만큼의 영역 안에서 위에서 말한 모든 Thread의 Multi Block Read가 가능해야 합니다.

    < 300개 Session일 때 계산식 >
300(Session) * 64(DB_FILE_MULTIBLOCK_READ_COUTN) * 8192(One Block Size) 
* 4(LRU 방식에서 확보해야 할 공간: 4배) 
= 600M만큼의 DB Cache size가 필요하게 된다.

     

참고
LRU(Least Recently Used) 방식 : Cache 라인의 사용에 대해 조사해본 다음, 가장 오랜 시간 동안 사용되지 않는 Cache 라인을 다음 Victim으로 선택
Victim : 교체를 위해 선택된 Cache 라인

 

3. 프로세스 관리

  • 운영 중인 DBMS의 Background 프로세스 관리 방법에 대해 기술합니다.
     
  • Listener : Oracle과 다르게 독립적인 프로세스가 아니며, Background 프로세스처럼 관리됩니다.
     
  • Foreground Process: WTHR(Working Thread), CTHR(Control Thread)등이 있으며, 사용자의 요청으로 처리하고, 가장 많은 Resource를 사용하고 있습니다. 다수의 Process내에 다수의 Thread로 구성되고, Session과 Thread가 1:1로 대응(Dedicated Sever) 됩니다. (Shared Server는 지원되지 않습니다.)
     
  • Background Process: 클라이언트의 접속 요청을 직접 받지 않고, 워킹 스레드나 다른 배경 프로세스가 요청 할 때 혹은 정해진 주기에 따라 동작하는 주로 시간이 오래 걸리는 디스크 작업을 담당하는 독립 된 프로세스입니다.
     
  • Background Process는 MONP(monitor process), MGWP(manager worker process), AGNT(agent process), DBWR(database writer), RCWP(recover worker process) 로 구성되어 있습니다.
     
  • DBWR의 경우, 설정 또는 CPU 코어 개수에 따라 기동 되는 프로세스 개수가 달라질 수 있습니다.(관련 파라미터 DBWR_CNT)

 

3.1. 프로세스 구성 환경

  • Tibero listener는 Oracle처럼 독립 프로세스로 동작하지 않습니다. 

  • Node1 (Active)서버 프로세스 확인하며, Node(Standby)는 Down 상태

    [예제] Process 확인

    $ tbdown pid

1634: MONP 
1636: MGWP 
1637: FGWP0000 
1638: FGWP0001 
1639: PEWP0000 
1640: PEWP0001 
1641: PEWP0002 
1642: PEWP0003 
1643: AGNT 
1644: DBWR 
1645: RCWP
    $ ps –ef | grep tbsvr

tibero   23948 23874  0 19:56 pts/18   00:00:00 tbsvr_MGWP     -t NORMAL -SVR_SID tibero
tibero   23949 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP000  -t NORMAL -SVR_SID tibero
tibero   23950 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP001  -t NORMAL -SVR_SID tibero
tibero   23951 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP002  -t NORMAL -SVR_SID tibero
tibero   23952 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP003  -t NORMAL -SVR_SID tibero
tibero   23953 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP004  -t NORMAL -SVR_SID tibero
tibero   23954 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP005  -t NORMAL -SVR_SID tibero
tibero   23955 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP006  -t NORMAL -SVR_SID tibero
tibero   23956 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP007  -t NORMAL -SVR_SID tibero
tibero   23957 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP008  -t NORMAL -SVR_SID tibero
tibero   23958 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP009  -t NORMAL -SVR_SID tibero
tibero   23959 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP010  -t NORMAL -SVR_SID tibero
tibero   23960 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP011  -t NORMAL -SVR_SID tibero
tibero   23961 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP012  -t NORMAL -SVR_SID tibero
tibero   23962 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP013  -t NORMAL -SVR_SID tibero
tibero   23963 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP014  -t NORMAL -SVR_SID tibero
tibero   23964 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP000  -t NORMAL -SVR_SID tibero
tibero   23965 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP001  -t NORMAL -SVR_SID tibero
tibero   23966 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP002  -t NORMAL -SVR_SID tibero
tibero   23967 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP003  -t NORMAL -SVR_SID tibero
tibero   23968 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP004  -t NORMAL -SVR_SID tibero
tibero   23969 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP005  -t NORMAL -SVR_SID tibero
tibero   23970 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP006  -t NORMAL -SVR_SID tibero
tibero   23971 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP007  -t NORMAL -SVR_SID tibero
tibero   23972 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP008  -t NORMAL -SVR_SID tibero
tibero   23973 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP009  -t NORMAL -SVR_SID tibero
tibero   23974 23874  3 19:56 pts/18   00:00:00 tbsvr_AGNT     -t NORMAL -SVR_SID tibero
tibero   23975 23874  6 19:56 pts/18   00:00:00 tbsvr_DBWR     -t NORMAL -SVR_SID tibero
tibero   23976 23874  1 19:56 pts/18   00:00:00 tbsvr_RCWP     -t NORMAL -SVR_SID tibero
tibero   24715 22408  0 19:56 pts/18   00:00:00 grep --color=auto tb

 

 

3.2. 프로세스 설정 방법

  • Foreground Process: TIP 파일에 설정된 session개수에 따라 달라집니다.(파라미터 MAX_SESSION_COUNT)
  • Background Process: DBWR의 경우, TIP 설정 또는 CPU 코어 개수에 따라 기동 되는 프로세스 개수가 달라질 수 있습니다. (파라미터 DBWR_CNT)

 

3.3. 프로세스 운영 절차

  1. Tibero 명령어를 통한 프로세스 확인
     
    • 확인 방법: cmd(Window) 혹은 터미널(Unix,Linux)에서 “tbdown pid” 명령으로 확인합니다. 
       
  2. 시스템에 등록된 프로세스 확인
     
    • Unix, Linux 시스템에서 확인
    • 명령 : ps -ef | grep tibero ( tibero 문구의 경우 티베로 제품을 설치한 유저임)  
    • Window system 에서 확인

      • 명령: tasklist /FI "IMAGENAME eq tb*"

        [예제] Task 이미지 확인(Window)

         C:\Tibero\tibero7\scripts>tasklist /FI "IMAGENAME eq tb*"
 
  이미지 이름                 PID 세션 이름              세션#  메모리 사용
  ====================== ======== ================ =========== ============   
  tbsvr.exe                 22580 Services                   0  1,417,104 K
  3. 프로세스 종료 시 시스템 재기동
    • TIBERO DBMS는 Working Process 를 제외한 Background Process가 하나라도 다운 되었을 경우 정합성을 위해서 스스로 shutdown 합니다.
    • 프로세스 확인
      • Unix, Linux인 경우: "ps -ef | grep tb*" or "tbdown pid" 명령으로 확인합니다.
      • Window인 경우: TASK 이미지는 "tasklist /FI "IMAGENAME eq tb* 명령을 이용하여 확인하고, 프로세스는 "tbdown pid"를 확인합니다.
      • Process별 조치 방법
      • Process Down에 의한 비정상 종료인 경우 반드시 "tbdown clean" 을 실행하고, "tbboot" 실행합니다.

 

3.4. 프로세스 관련 참조

  • One Execute Binary

    [그림12] tbsvr 관리형태

  • Monitor Thread가 Foreground Process 및 Background Process를 Fork하는 방식입니다.
  • Background 프로세스가 죽으면 MTHR가 감지하여 전체 서버를 죽인다. Foreground 프로세스가 죽으면 
    옵션에 따라 달라집니다.
  • Listener와 Server의 관계: Oracle과 달리 Tibero에서 listener는 서버의 Background 프로세스와 같이 존
    재하며 혼자 존재 할 수 있는 독립적인 프로세스가 아닙니다.

 

Foreground Process

[그림13] Foreground Process

  • Tibero는 Multi Process에 각 Thread로 동작합니다.
  • Process : Thread 비율 설정 (WTHR_PROC_CNT : WTHR_PER_PROC)
  • 운영 가이드: 프로세스 개수가 늘어나면 메모리 사용량이 많아지고, 부하가 많을 때 성능은 좋아집니다. thread 개수가 늘어나면 메모리 사용량은 줄어들지만, 부하 시에 성능은 떨어집니다. 메모리 자원이 넉넉하면 성능을 위하여 프로세스 비율을 높여보는 것이 좋습니다. (WTHR_PER_PROC 값이 10으로 고정)
    *참고(대상 AIX 전 버전)
  • 참고 사항: TIP 파일에, WTHR_PER_PROC를 15 이하로 설정할 것
  • 사유: AIX의 경우, sendmsg() system call에서 처리할 수 있는 message queue 용량이 15개, 만약 동시
    에 요청되는 message가 16개 이상일 경우 connection fail 발생, 대부분의 경우 위와 같은 일이 발생할 확률은 드물지만 장비 성능, 네트워크 사정이 좋은 상태에서 동시에 16개 이상의 대량 부하가 몰릴 경우 일부 Connection fail 발생할 가능성 있음.
  • 새로운 Client의 Connection방식
  • 접속 방법이 tbdsn.tbr 파일의 HOST 설정에 따라 다릅니다.
  • 일반 ip는 TCP 소켓으로 접속을 하며, localhost는 도메인 소켓으로 접속을 합니다.
  • 접속이 이루어지지 않을 때 점검 사항
  • listener 로그 확인하여 요청이 들어오는지 확인, 중간에 접근 제어 툴 및 방화벽에 차단이 된다면 로그가 남지 않음.
  • TB_SID, TB_HOME 환경 변수 설정이 올바른지 확인.
  • netstat 네트워크 상태 확인.
  • Listening 하거나 연결되어 있는 포트 확인.
  • Tibero 사용 포트
    • LISTENER_PORT(N) : 기본 서비스 포트(필수 사용)
    • _LSNR_SPECIAL_PORT(N+1) : 스페셜 포트, tbdown 및 응급 조치 시 사용.(필수 사용)
    • _LSNR_SSL_PORT(N+2) : SSL 접속으로 사용됨.(보안 통신 사용 시)
       

Background process

  1. [그림14] Background Process 상관도

MONP (Monitor process)

  • Tibero 6부터 영문 약자가 thead에서 프로세스로 변경되었으며 실제로 하나의 독립된 프로세스입니다. Tibero가 기동할 때 최초로 생성되며 Tibero가 종료하면 맨 마지막에 프로세스를 끝마칩니다.
    Tibero가 기동할 때 listener를 포함한 다른 프로세스를 생성하거나 주기적으로 각 프로세스의 상태를 점검하는 역할을 담당합니다. 또한 교착 상태(deadlock)도 검사합니다.

MGWP (Tibero Manager Worker Process)

  • 시스템을 관리하기 위한 용도의 프로세스입니다. 관리자의 접속 요청을 받아 이를 시스템 관리 용도로 예약된 worker thread에 접속을 할당합니다. 기본적으로 worker process와 동일한 역할을 수행하지만 listener를 거치지 않고 스페셜 포트를 통해 직접 접속을 처리합니다. SYS 계정만 접속이 허용됩니다.

AGNT (Agent Process)

  • 시스템 유지를 위해 주기적으로 처리해야 하는 Tibero 내부의 작업을 담당합니다.
    Tibero 4 SP1까지는 sequence cache의 값을 디스크에 저장하는 작업도 담당했으나,
    Tibero 5 이후로 각 worker thread가 담당하는 것으로 변경되었습니다. 이전에는 SEQW라는 명칭을 사용했으나 Tibero 6부터 AGNT로 명칭이 변경되었습니다. sequence를 사용하는 방법은 "Tibero 관리자 안내서"의 "4.7.1. 시퀀스 생성, 변경, 제거" 를 참고합니다.

DBWR (Database Writer Process)

  • 데이터베이스에서 변경된 내용을 디스크에 기록하는 일과 연관된 thread들이 모여 있는 프로세스입니다. 사용자가 변경한 블록을 디스크에 주기적으로 기록하는 thread, Redo log를 디스크에 기록하는 thread, 이 두 thread를 통해 데이터베이스의 체크포인트 과정을 관할하는 체크포인트 thread 등이 이 프로세스에 포함되어 있습니다.

RCWP (Recovery Worker Process)

  • 복구와 백업을 담당하는 프로세스입니다. 부팅 과정에서 NOMOUNT 이후의 부팅 단계를 올리는 역할을 수행하고 복구가 필요한 상황인지 여부를 판단하여 필요할 경우 redo log를 읽어서 복구를 진행합니다. tbrmgr을 이용하여 백업 작업을 하거나 백업 본을 이용하여 미디어 복구를 진행하는 경우에도 이 프로세스에서 진행합니다.

PEWP (Parallel Execution)

  • Parallel Execution Process(이하 PEP)는 PE 수행을 위해 도입된 PE 전용 프로세스입니다.
    PE SQL을 처리할 때에 locality를 극대화하기 위해서 WTHR들을 하나의 PEP에서 할당합니다. 또한 일반적인 클라이언트 session을 위한 WTHR과 분리되어 모니터링 및 관리가 용이하다.

 

4. Tip 파일 관리

  • 운영 중인 TIP파일에 대한 관리 방법을 설명합니다. 

 

4.1. Tip 파일 구성 환경

  • Tibero는 $TB_SID.tip 이라는 파라미터 파일을 읽어서 기동하게 됩니다. 
    Oracle의 경우 PFILE(initSID.ora)파일과 SPFILE(spfileSID.ora)가 존재하지만, Tibero는 PFILE 파일에 해당하는 TIP 파일만이 존재합니다.

    [예제] TIP 파일 설정 정보

    # tip file generated from /home/tibero/tibero7/config/tip.template (TUE NOV 21 20:25:37 PDT 2023)
#-------------------------------------------------------------------------------
# RDBMS initialization parameter
#-------------------------------------------------------------------------------
DB_NAME=t7
LISTENER_PORT=9629
CONTROL_FILES="/home/tibero/tbdata7/c1.ctl" 
DB_CREATE_FILE_DEST="/home/tibero/tbdata7" 
LOG_ARCHIVE_DEST="/home/tibero/archive/t7" 

#CERTIFICATE_FILE="/home/tibero/tibero7/config/svr_wallet/t7.crt" 
#PRIVKEY_FILE="/home/tibero/tibero7/config/svr_wallet/t7.key" 
#WALLET_FILE="/home/tibero/tibero7/config/svr_wallet/WALLET"

MAX_SESSION_COUNT=96
TOTAL_SHM_SIZE=1024M DB_BLOCK_SIZE=8K
SQL_LOG_ON_MEMORY=Y

 

4.2. TIP 파일 설정 방법

파일 내에 직접 기술하고, tbdown 후 tbboot으로 적용합니다.

 

4.3. TIP 파일 운영 절차

조회 명령: tbsql sys 계정으로 로그인 후 "show param"명령으로 확인합니다. 

 

4.4. TIP 파일 관련 참고

[예제] DB Parameter 조회

tbSQL 7
TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Connected to Tibero.
SQL> show param
NAME                         TYPE     VALUE
--------------------------  -------  --------
ACF_RCVR_CNT                 INT32    6
ACTIVE_SESSION_HISTORY       Y_N      NO
ACTIVE_SESSION_TIMEOUT       INT32    0
TPR_SNAPSHOT_RETENTION       INT32    7
TPR_SNAPSHOT_SAMPLING_INTERVAL INT32    60
TPR_SNAPSHOT_TOP_SQL_CNT   INT32    5
AUDIT_FILE_DEST              DIRNAME  /home/tibero/tibero7/instance/t7/audit/ AUDIT_FILE_SIZE              INT32    104857600
AUDIT_SYS_OPERATIONS         Y_N      NO
AUDIT_TRAIL                  STRING   NONE
.... 중략
USE_NET_KEEPALIVE            Y_N      NO
USE_PROFILE                  Y_N      YES
USE_RECYCLEBIN               Y_N      NO
USE_STORED_OUTLINES          Y_N      NO
USGMT_AUTO_SHRINK_INTERVAL   INT32    0
UTL_FILE_DIR                 DIRNAME  /home/tibero/tbdata7/psm/
WALLET_FILE                  STRING
WTHR_PROC_CNT                INT32    8 
WTHR_PROC_CNT_MAX            INT32    8
XA_MAX_BRANCH_CNT            INT32    1024
XA_TIMER_INTERVAL            UINT32   100
  • TIP파일에 기술되는 Init Parameter들 중 정적 Parameter와 동적 Parameter가 존재합니다. 정적 Parameter는 TIP 파일에 기술해야 적용되며, 동적 Parameter는 운영 중에도 변경 가능합니다.

 

5. Control 파일 관리

  • 운영 중인 DBMS의 Control file을 관리하는 방법을 기술합니다.
     
  • 컨트롤 파일은 데이터베이스 자체의 메타 데이터를 보관하고 있는 바이너리 파일입니다.
     
  •  최초의 컨트롤 파일은 Tibero를 설치할 때 함께 생성됩니다. 최초로 설정된 컨트롤 파일에 대한 정보는 $TB_SID.tip 파일에 저장됩니다. 컨트롤 파일은 Tibero에서 생성과 갱신을 할 수 있습니다.

 

5.1. Control file 구성 환경

  • Control file은 바이너리로 저장되며, 정기적 backup에 의해 보존해야 합니다. 

 

5.2. Control 파일 설정 방법

  • DBA는 컨트롤 파일의 복사본을 추가하거나 제거할 수 있습니다. 
     
  • 컨트롤 파일은 DBMS에 대한 메타 데이터여서, 데이터베이스를 운영 중일 때에는 컨트롤 파일의 물리적인 변경이 불가능합니다. 
     
  • 따라서, 컨트롤 파일의 복사본을 추가 또는 제거하기 위한 SQL 수행 문장은 존재하지 않습니다. 
    반드시 데이터베이스를 종료한 후, 컨트롤 파일을 변경 해야 합니다.
     
  • 이처럼 컨트롤 파일을 추가 또는 제거하기 위한 SQL 수행문장이 존재하지 않기 때문에 일반적인 운영체제 명령어를 사용하여 변경 작업을 수행해야 합니다. 
    그 다음 변경된 내용을 $TB_SID.tip 파일에 반영합니다.

 

5.3. Control 파일 운영 절차

  • 작업 순서: 이중화 하려는 Control 파일 copy하여 다른 공간에 저장 > tbdown > ${서비스ID}.tip 파일 수정 > tbboot
     
  • Control 파일 2중화 구성 방법
     
    1. Tibero 다운 (TIP파일 수정 전/후 가능)
      • tbdown 명령으로 Tibero DB 다운.tbdown
         
    2. Control 파일 복사
      • 다음은 UNIX Command에서 컨트롤 파일을 복사하는 예입니다.
        $ cp /usr1/tibero/control01.ctl /usr3/tibero/control03.ctl
      • 다음은 Window Command에서 컨트롤 파일을 복사하는 예입니다.
        copy D:/tbdata/control01ctl D:/tbdata/control02.ctl
         
    3. TIP파일에 Control 파일 Parameter 수정

      • TIP파일 위치: $TB_HOME 하위에 위치(현재 설정 기준) 

        CONTROL_FILES="/usr1/tibero/control01.ctl ","/usr3/tibero/control03.ctl"
         

    4. Tibero 기동 후 확인

 

  • Control 파일 백업 방법
    • 컨트롤 파일의 백업은 논리적 백업 만을 지원합니다. 따라서 컨트롤 파일을 생성하는 SQL 문장을 백업해야 합니다. 특히 tablespace, datafile, Redo log를 새로 생성하거나 변경 또는 제거를 수행한 경우에는 바로 controlfile을 백업하는 것이 관리 측면에서 안전하다. 물론 데이터베이스 전체를 백업할 때에도 controlfile자체를 백업해야 합니다.
       

    • 아래는 Control파일을 backup 받는 예입니다.

      [예제] Control File Backup

      SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS
   '/tibero/DB/tibero7/backup/ctrlfile1.sql' REUSE NORESETLOGS;

 

5.4. Control 파일 관련 참조

  • Tibero에서 컨트롤 파일은 같은 크기, 같은 내용의 파일을 두 개 이상 유지하기를 권장합니다. 이는 Redo log 멤버를 다중화하는 방법과 유사하다.
     
  • 같은 로그 그룹 내의 로그 멤버를 서로 다른 디스크에 설치하는 것처럼, 컨트롤 파일의 복사본을 서로 다른 디스크에 저장하는 것이 좋습니다. 이는 데이터베이스의 시스템 성능과 안정성을 유지하는 데 매우 필요합니다.
     
  • 예를 들어, 한 디스크에 컨트롤 파일의 복사본이 존재하는 경우 문제가 발생할 수 있습니다. 만약 이 디스크를 영구적으로 사용할 수 없게 된다면, controlfile은 복구할 수 없는 상태가 됩니다. 따라서 controlfile은 Redo 로그와 연관 하여 배치하는 것이 좋습니다.
     

  • Tibero에서는 데이터베이스를 다시 기동할 때마다 먼저 컨트롤 파일을 참조합니다. Control file을 참조하는 절차는 다음과 같습니다.
     

    가. tablespace와 데이터 파일의 정보를 얻습니다.
     

    나. 데이터베이스에 실제 저장된 데이터 사전과 schema 객체의 정보를 얻습니다.

    다. 필요한 데이터를 읽습니다.
     

  • 컨트롤 파일의 정보 조회

    V$DATABASE : ARCHIVELOG모드 여부와 체크포인트 등의 정보를 조회하는 view table입니다.

    V$CONTROLFILE : 컨트롤 파일의 이름과 상태 등의 정보를 조회하는 view table입니다.

 

6. Redo Log 파일 관리

Redo 로그

  • 운영 중인 DBMS의 Redo Log File 관리 방법에 대해 기술합니다.
     
  • 로그 파일은 Redo 로그를 저장하는 파일입니다. 
  • Redo 로그는 데이터베이스에서 발생하는 모든 변경 내용을 포함하며, 데이터베이스에 치명적인 에러가 발생한 경우, commit 된 transaction의 갱신 된 내용을 복구하는 핵심적인 데이터 구조입니다.
     

[그림15] Redo Log 파일 Group 구조

  • Redo 로그는 두 개 이상의 로그 그룹(Log Group)으로 구성됩니다.
     
  • Tibero에서는 이러한 로그 그룹을 순환적(Circular)으로 사용합니다. 
    예를 들어, 세 개의 로그 그룹으로 Redo 로그를 구성하는 경우, 
    1. 로그 그룹 1에 로그를 저장합니다. 
    2. 로그 그룹 1에 로그가 가득 차면, 그 다음 로그 그룹 2, 3에 로그를 저장합니다. 
    3. 로그 그룹 3까지 로그가 가득 차면 로그 그룹 1부터 다시 저장합니다. 

    이처럼 하나의 로그 그룹을 모두 사용하고 그 다음 로그 그룹을 사용하는 것을 로그 전환(log switch)이라고 합니다.
     
  • Redo 로그에는 하나 이상의 로그 레코드(log record)가 저장됩니다. 로그 레코드에는 데이터베이스에서 발생하는 모든 변경 내용이 포함되어 있으며, 이전에 변경된 값과 새로운 변경 값이 함께 저장됩니다.
     

로그 멤버의 다중화

  • Tibero는 동시에 하나의 로그 그룹 만을 사용하는 데, 현재 사용 중인 로그 그룹을 활성화(active)된 로그 그룹이라고 합니다.

  • 하나의 로그 그룹은 하나 이상의 로그 멤버로 구성할 수 있습니다. 이러한 구성을 다중화(multiplexing)라고 합니다.

    단, 다중화를 하려면 동일한 그룹에 속해 있는 모든 로그 멤버의 크기는 일정해야 하며, 동일한 데이터를 저장하고 동시에 갱신 되어야 합니다. 반면에 서로 다른 영역에 있는 로그 그룹은 각각 다른 개수의 로그 멤버를 포함할 수 있으며, 로그 멤버의 크기가 같지 않아도 됩니다.

    [그림16] 로그 멤버의 다중화

  • 로그 그룹 하나에 포함된 로그 멤버는 시스템의 성능을 위해 서로 다른 디스크에 저장하는 것이 좋습니다. 같은 로그 그룹내의 모든 멤버는 같은 로그 레코드를 저장해야 합니다. 모든 로그 멤버가 서로 다른 디스크에 존재하게 된다면, 로그 레코드를 저장하는 과정을 동시에 수행할 수 있습니다.

로그 멤버, 로그 그룹 다중화
 

  • 로그 그룹의 크기와 개수를 정할 때는 archive 작업을 충분히 고려해야 합니다. 로그 그룹의 크기는 제3의 저장 장치에 빠르게 전달되고 저장 공간을 효율적으로 사용할 수 있도록 설정해야 합니다. 또한, 로그 그룹의 개수는 archive 중인 로그 그룹을 대기하는 경우가 발생하지 않도록 해야 합니다.

 

6.2. Redo Log 파일 구성 환경

티베로 DBMS 명령어를 사용하여 관리합니다. 

 

6.3. Redo 로그 파일 운영 절차

Log Switch

  • tbsql 혹은 tbAdmin의 sys 계정으로 접속 후 실행합니다. 

    [예제] log switch

    SQL>
   GROUP# STATUS
   ---
   0 CURRENT    
   1 INACTIVE  
   2 INACTIVE
   
   3 rows selected.
   
   SQL> alter system switch logfile;

   System altered.
   
   SQL> select GROUP#, STATUS FROM v$log;
   
   GROUP# STATUS
   ---
   0 INACTIVE    
   1 CURRENT    
   2 INACTIVE
   
   3 rows selected.

 

Checkpoint

  • DBWR Process와 LGWR Process에게 신호를 보내 해당 프로세스가 수행되게 함으로써 변경된 DB 
    CACHE의 dirty buffer를 디스크의 datafile로 저장하는 것을 보장합니다.

    [예제] 수동 Checkpoint 명령어

    SQL> alter system checkpoint;

System altered.

 

Log Group 추가

  • ADD LOGFILE 절에 로그 그룹의 번호를 지정할 수 있는 GROUP 옵션을 추가할 수 있습니다. 로그 그룹의 번
    호를 설정하면, 이후에 특정한 로그 그룹을 지칭하여 로그 멤버를 추가하는 등의 작업을 수행할 수 있다(아래 예는 파일 시스템의 경우를 예시)

Log Memeber 추가

  • 기존의 로그 그룹에 새로운 로그 멤버를 추가하려면 ADD LOGFILE MEMBER 절을 삽입해야 합니다. 이때 
    로그 파일에 할당된 서버 프로세스를 반드시 명시해야 합니다. (아래 예는 파일 시스템의 경우를 예시)
  • Log Member 삭제
    • 로그 그룹 내의 하나의 로그 멤버를 제거하기 위해서는 DROP LOGFILE MEMBER 절을 삽입해야 합니다. 로그 그룹이 할당된 서버를 명시해야 하며, 로그 그룹은 명시하지 않아도 됩니다. 로그 멤버도 로그 그룹을 제거 할 때처럼 로그 그룹 내에 남겨진 로그 멤버가 하나도 없는 경우, 에러를 반환하게 됩니다. 뿐만 아니라 현재 활성화되어 사용 중이거나 ARCHIVELOG 모드에서 archive 되지 않은 로그 그룹 내의 로그 멤버도 제거되지 않습니다.

 

6.4. Redo 로그 파일 관련 참조

  • Tibero에서는 Redo 로그 관리에 도움을 주기 위해 다음 표에 나열된 동적 view를 제공하고 있습니다. Redo 로그의 그룹 별 로그 파일, 다중화 정보, 갱신 날짜 등의 정보를 제공하며, DBA나 일반 사용자 모두가 이 view를 사용할 수 있습니다.
  • Redo 로그 동적 뷰
    • V$LOG : 로그 그룹의 정보를 조회합니다.
    • V$LOGFILE : 로그 파일의 정보를 조회합니다.

 

7. Archive 파일 관리

  • 운영 중인 DBMS의 Archiving File 관리 방법에 대해 기술합니다.
  • Online 백업 및 완벽한 복구를 위해서는 반드시 Archive Mode가 설정되어 있어야 합니다. 

 

7.1. Archive 파일 구성 환경

  • 완벽한 Recovery 작업을 수행하기 위해서는 DB를 Archive log mode로 운영하여야 합니다. 데이터베이스를 archive log모드로 운영하면 redo log switch 발생 시 redo log 파일을 별도의 archive log 디렉토리로 복사합니다. 데이터베이스 archive log 모드로 동작하고 있을 때는 LGWR 프로세스가 redo log switch 작업에 archive log 복사가 동기화 작업으로 포함되어 있습니다.
  • 아카이브 로그파일을 백업받는 디스크에는 용량이 부족하지 않도록 관리를 해야 합니다. 공간이 충분하다면 상
    관이 없지만, 부족한 상태라면 온라인 full backup 을 받는 주기를 고려하여, 온라인 full backup 을 받아서 이미 archive log file이 적용된 것들은 삭제해도 무방합니다.

 

7.2. archive 파일 설정 방법

TIP파일을 수정하고, tbsql로 archive log mode를 설정합니다. 

 

7.3. Archive 파일 운영 절차

  1. TIP 파일 수정
    • LOG_ARCHIVE_DEST 파라미터 경로에 archive log file을 생성합니다. 
  2. Archive Mode로 변경
    • "tbsql"을 이용하여 Archive Mode로 변경
    • tbdown > tbboot mount > sys계정 로그인 > archive mode 변경 > open
    • Archive Mode 변경 이후에 꼭 강제로 log switch를 발생하여, archive 파일이  생성되는지 확인해야 합니다. 만약 생성이 되지 않는다면 tip 파일에 설정된 archive 경로에 대하여 파일을 생성할 수 있는 권한이 있는지 확인합니다.

 

7.4. Archive Mode 변경

관련 파라미터

  • Archive 관련 Parameters
    • LOG_ARCHIVE_DEST : Archive log file의 위치를 지정하는 파라미터
    • LOG_ARCHIVE_FORMAT : Archive log file명format (log-t%t-r%r-s%s.arc)
    • LOG_ARCHIVE_OVERWRITE : archive 로그 파일(Archive log file)이 존재하는 경우 새로운 archive 로그 파일로 덮어 쓸 지를 정하는 파라미터입니다.
  • 관련 동적 View Table
    • V$ARCHIVE_DEST_FILES : Archive log file의 정보를 보여준다.
    • V$DATABASE : LOG_MODE column의 Archive Mode 를 확인합니다.

 

8. Listener 관리

운영 중인 DBMS의 Listener 관리 방법에 대해 기술합니다. 

 

8.1. Listener 구성 환경

  • Tibero의 Listener는 Oracle의 Listener처럼 독립적인 프로세스가 아니고, Monitor Thread에 의해 관리됩니다. 데이터베이스 기동 시 같이 기동 되었다가 정지 시 같이 내려갑니다.
     
  •  Tibero의 Listener의 Port 및 연결 DBMS는 하나만 존재합니다. (multi instance는 가능)
     

  • 단독 프로세스로 존재할 수 없고, 연결 DBMS와 Port설정은 하나 이기 때문에 TIP파일상에 같이 기록되어 관리됩니다. (listener는 tbboot 명령에 의해 같이 기동 되고, tbdown 명령에 의해 같이 종료 됩니다.)

    [예제] 리스너 포트 관리

    # tip file generated from C:\TIBERO\tibero7\config\tibero.template(8 22 15:8:19 2023) #-------------------------------------------------------------------------------
#
# tibero initialization parameter
#
#-------------------------------------------------------------------------------
...
DB_NAME=TIBERO_SID 
LISTENER_PORT=8629
...

 

8.2 Listener 운영 절차

  • Listener Port 변경 절차
    • 변경 절차: tbdown > TIP 파일 수정 > Client DSN 수정 > tbboot
      1. tbdown
        • Command 창에서 "tbdown" 실행하여 down가능합니다. Window OS 환경에서는 서비스로 중지하는 경우는 작업 진행 내역이 표시되지 않기 때문에 되도록 Command 창에서 "tbdown" 명령으로 중지하기를 권고합니다.
      2. TIP 파일 수정

        • 파일 위치: $TB_HOME/config/$TB_SID.tip

          [예제] TIP 파일 Listen Port 변경

          # tip file generated from /home/tibero/tibero7/config/tip.template (Mon Sep 10 23:25:37 PDT 2012) #-------------------------------------------------------------------------------#
# tibero initialization parameter
# #-------------------------------------------------------------------------------
... ...
LISTENER_PORT=8629 ← 변경
... ...

           

      3. Client DSN 수정
        • vi 또는 편집기를 이용하여 Port만 변경하면 됩니다. 
        • 파일 위치: $TB_HOME/client/tbdsn.tbr
           
      4. tbboot
        • Command 창에서 "tbboot"을 실행합니다.
           
      5. tbsql에서 확인

 

8.3 Listener 관련 참고

관련 Parameters

  • [표] Listener 관련 Parameter

    Parameter설명
    LOG_LVL_LISListener로그 레벨입니다. 이 값이 클수록 listener에서 더 많은 로그를 남긴다.
    LSNR_LOG_DESTListener에 남기는 로그 위치입니다.
    LSNR_DENIED_IPListener에 접근할 수 없는 IP리스트를 기술합니다. LSNR_INVITED_IP와 중복 설정 되었을 경우, 해당 설정은 무시됩니다.
    LSNR_DENIED_IP_FILEListener에 접근하는 특정IP들을 차단하기 위해 IP목록을 기술한 파일의 경로를 입력하는 파라미터입니다. LSNR_INVITED_IP_FILE와 중복 설정됐을 경우, 해당 설정은 무시됩니다.
    LSNR_INVITED_IPListener에 접근할 수 있는 IP 리스트입니다.
    LSNR_INVITED_IP_FILEListener에 접근 가능한 IP목록을 기술한 파일의 경로를 입력하는 파라미터입니다.
    LISTENER_PORTListener가 사용하는 포트 번호를 설정하는 파라미터입니다.

 

 

9. tbdsn.tbr 파일 관리

  • tbdsn.tbr 파일은 클라이언트가 Tibero의 데이터베이스에 접속하기 위해 필요한 정보를 가지고 있는 환경 설정 파일입니다. 기본적으로 tbdsn.tbr 파일에는 SID, host, 포트 번호 등의 정보가 포함되어 있습니다.
     
  • Oracle의 tnsnames.ora 파일과 동일한 역할을 합니다.

 

9.1. tbdsn.tbr 파일 구성 환경

Tibero 서버의 DSN파일 설정 수행

  • Window system 기본 편집기(예 notepad)를 사용하여 편집합니다. 
  • Unix 의 경우 vi 또는 vim 을 사용하여 편집합니다.

[예제] tbdsn.tbr 설정 파일

 

#-------------------------------------------------
# /tibero/tibero7/client/config/tbdsn.tbr
# Network Configuration File.
# Generated by gen_tip.sh at Fri Sep 14 22:04:36 KST 2023
TIBERO_SID=(
   (INSTANCE=(HOST=localhost)
             (PORT=8629)
             (DB_NAME=TIBERO_SID)    
   )
   (INSTANCE=(HOST=123.45.67.11)              
             (PORT=8629)
             (DB_NAME=TIBERO_SID)    
   )
   (LOAD_BALANCE=Y)
   (USE_FAILOVER=Y)
)
TIBERO_SID_SP=( 
   (INSTANCE=(HOST=123.45.67.10)
             (PORT=8630)
             (DB_NAME=TIBERO_SID)   
   )
)
TIBERO_SID_2=(
   (INSTANCE=(HOST=localhost)
             (PORT=8629)
             (DB_NAME=TIBERO_SID)    
   )
)
TIBERO_SID_1=(
   (INSTANCE=(HOST=123.45.67.11)              
             (PORT=8629)
             (DB_NAME=TIBERO_SID)    
   )
)

 

9.2. tbdsn.tbr 파일 운영 절차

  • tbdsn.tbr 파일은 다음과 같은 구조로 이루어져 있습니다. 

    [예제] tbdsn.tbr 구조

    SID_1=(
           (INSTANCE=(항목1=값1)            
           (항목2=값2)
               ...
       )
   )
SID_2=(
           (INSTANCE=(항목1=값1)            
           (항목2=값2)
               ...
       )
   )

TB_NLS_LANG=MSWIN949 
TBCLI_LOG_LVL=TRACE
  • tbdsn.tbr에서 SID로 사용할 수 있는 표준 문자는 문자(A-Z, a-z), 숫자(0-9), 및 하이픈(-)입니다. SID의 세부 항목은 다음과 같습니다.

  • 기본 항목 설명

    [표] DSN 기본 항목 설명- 

    항목설명
    HOST서버의IP주소(예, HOST=168.1.1.33)
    PORT대상 서버의Listen Port (예, PORT=8629)
    DB_NAME대상 데이터베이스 이름(예, DB_NAME=tibero)
  • SID 정보 외에 클라이언트 환경 설정도 할 수 있습니다. 이 설정들은 환경 변수로도 지정 가능하며 양쪽 다 설정 되어 있을 경우 tbdsn.tbr 파일 설정을 우선적으로 따릅니다.
  • DSN 관리 항목
    • TB_NLS_LANG : 클라이언트에서 사용하는 캐릭터 셋을 지정할 수 있습니다. (예: TB_NLS_LANG=UTF8)
    • TBCLI_LOG_LVL : CLI의 로그 레벨을 지정할 수 있습니다.문제해결을 위해 로그가 필요한 경우만 사용합니다. (예:TBCLI_LOG_LVL=TRACE)

 

9.3. tbdsn.tbr 파일 관련 참조

이중화 서버 설정

  • 이중화 서버(Replication server)는 물리적으로 독립된 여러 개의 서버를 동일하게 복제한 것을 의미한
    다. 동일하게 복제된 서버를 임의로 접속할 수 있고, 하나의 서버가 정지했을 때에도 다른 서버 대신 접속하여 같은 작업을 수행할 수 있습니다.
  • tbdsn.tbr 파일에서 이중화 서버를 구성하려면 다음과 같이 하나의 SID로 이중화 서버를 INSTANCE 항목
    으로 설정하면 됩니다.

  • 구분 예>

    [예제] DSN 이중화 서버 설정

    tb=( 
(INSTANCE=(HOST=168.1.1.33)
          (PORT=8629)
          (DB_NAME=tibero)
    ) 
(INSTANCE=(HOST=192.168.1.25)          
          (PORT=8629)
          (DB_NAME=tibero2)
    ) 
(INSTANCE=(HOST=localhost)
          (PORT=8629)
          (DB_NAME=tibero)
    )
)

 

Load Balance 설정

  • Tibero에서는 이중화 서버 중에서 특정 서버의 집중적인 접속을 막으려고 로드 밸런싱(Load balancing) 
    기능을 지원합니다. 즉 특정 서버의 집중적인 접속을 분산 시킴으로써 시스템의 과부하를 막고 더 나은 접속 환경을 제공합니다.

  • tbsdn.tbr 파일에서 로드 밸런싱 기능을 설정하는 방법은 다음과 같습니다.

    [예제] DSN Load Balancing 설정

    tb=( 
(INSTANCE=(HOST=168.1.1.33)
          (PORT=8629)
          (DB_NAME=tibero)
    ) 
(INSTANCE=(HOST=192.168.1.25)          
          (PORT=8629)
          (DB_NAME=tibero2)
    ) 
(INSTANCE=(HOST=localhost)
          (PORT=8629)
          (DB_NAME=tibero)
    )
    (LOAD_BALANCE=Y)
)

 

Failover 설정

  • Tibero가 TAC 또는 이중화 된 서버로 설정된 상태에서 장애로 인해 중단되면 CLI 모듈은 다른 Instance 
    또는 이중화 된 서버로 접속하여 해당 session을 자동으로 복구합니다.

    [예제] DSN FAILOVER 설정

    tb=( 
(INSTANCE=(HOST=168.1.1.33)
          (PORT=8629)
          (DB_NAME=tibero)
    ) 
(INSTANCE=(HOST=192.168.1.25)          
          (PORT=8629)
          (DB_NAME=tibero2)
    ) 
(INSTANCE=(HOST=localhost)
          (PORT=8629)
          (DB_NAME=tibero)
    )
    (USE_FAILOVER=Y)
)

 

 

관련 대상