개요

현재 기업의 비즈니스는 폭발적인 데이터의 증가와 다양한 환경 및 플랫폼의 등장으로 빠르게 확장되고 있습니다. 새로운 비즈니스 환경이 도래함에 따라 보다 더 효율적이고 유연한 데이터 서비스와 정보의 처리, 데이터 관리 기능이 필요하게 되었습니다.

Tibero는 이러한 변화에 맞춰 기업 비즈니스 구현의 기반이 되는 데이터베이스 인프라 구성을 지원하며 고성능, 고가용성 및 확장성의 문제를 해결하는 엔터프라이즈 데이터베이스 관리 시스템입니다.

기존 DB의 단점을 보완하기 위해 Tibero는 독자적인 Tibero Thread Architecture를 채택하고 구현하였습니다. 한정 된 서버 프로세스의 CPU 및 메모리 등의 시스템 리소스를 효율적으로 사용하면서 뛰어난 성능과 안정성 및 확장성을 보장하고 편리한 개발 환경과 관리 기능을 제공합니다.

Tibero는 초기 설계부터 대규모 사용자, 대용량 데이터, 강화된 안정성, 향상된 호환성 측면 등에서 다른 DBMS와 차별화를 고려하여 개발되었습니다.
Tibero는 이처럼 기업이 원하는 최적의 데이터베이스 환경을 제공하는 대표적인 DB입니다.

방법

데이터베이스로서 기본 기능

Tibero는 데이터베이스의 영속성과 일관성을 유지하기 위하여 SQL 문장의 묶음인 트랜잭션을 다음의 4가지 성질을 통해 보장합니다.

• Atomicity(원자성)

  All-or-nothing. 즉, 트랜잭션이 행한 모든 일이 적용되던가 아니면 모두 적용되지 않아야 함을 의미합니다. Tibero에서는 이를 위하여 undo 데이터를 사용합니다.

   

• Consistency(일관성)

  트랜잭션이 데이터베이스의 Consistency를 깨뜨리는 일은 여러 방면에서 생겨날 수 있습니다.

  간단한 예는 테이블과 인덱스 간에 서로 다른 내용을 담고 있어서 Consistency가 깨지는걸 예로 들수 있습니다.

  이를 막기 위해 Tibero에서는 트랜잭션이 적용한 일들 중 일부만 자신이나 남에게 적용되는 것을 막고 있습니다.

  즉, 테이블만 수정했고 아직 인덱스를 수정하지 않은 상태라고 해도 다른 트랜잭션에서는 이를 예전 모습으로 돌려 보아서 테이블과 인덱스가 항상 Consistency가 맞는 형태로 보이게 동작합니다.

   

• Isolation(고립성)

  다른 트랜잭션 관점에서 트랜잭션은 혼자만 돌고 있는 것처럼 보이게 됩니다.

  물론 다른 트랜잭션이 수정한 데이터에 접근할 때는 이를 기다릴 수는 있지만,
  다른 트랜잭션이 수정 중이므로 접근할 수 없다고 에러가 나지는 않습니다.

  이를 위해 Tibero에서는 Multi version concurrency control 기법과 row-level locking 기법을 사용합니다.
  데이터를 참조하는 경우에는 MVCC 기법을 이용하여 다른 트랜잭션과 무관하게 참조 가능하며,
  데이터를 수정할 때도 row level의 fine-grained lock control을 통하여 최소한의 충돌만을 일으키고 같은 데이터에 접근한다고 해도 단지 기다림으로써 이를 해결합니다.

   

• Durability(영속성)

  Tibero에서는 이를 위하여 Redo 로그와 write-ahead logging 기법을 사용합니다.
  트랜잭션이 커밋 할 때에 해당 Redo 로그가 디스크에 기록되어 트랜잭션의 영속성을 보장해 줍니다. 

  또한 블록이 디스크에 내려가기 전에 항상 Redo 로그가 먼저 내려가서 데이터베이스 전체가 일관성을 지니게 합니다.

Tibero 구조

[그림1] 티베로 아키텍처

• Tibero는 Instance 영역과 Database영역으로 구분되며, 
• Instance는 TSM(Tibero shared Memory)영역과 Worker Process영역, 
  Background Process영역, Process Monitor
• Database는 Log Data, Log File 영역 등으로 구분된다.

티베로 Process 구조

[그림2] 티베로 프로세스 구조

Tibero의 프로세스는 크게 3가지로 구분됩니다.

• Listener Process :
  •  LSNR
• Worker Process : 
  • CTHR(Control Thread)
  • WTHR(Worker Thread)
• Background Process : 
  • MONP(Monitor Process)
  • DBWR(Database Write Process)
  • MGWP(Tibero Manager), AGENT(Agent)
  •  RCWP(Recovery Worker Process)
  • PEWP(Parallel Execution Worker Process)

Listener Process

• Listener는 클라이언트의 새로운 접속 요청을 받아 이를 대기 상태의 Worker Process에 할당 합니다.

  즉, 클라이언트와 WTHR간의 중계 역할을 담당하며 이는 별도의 실행 파일인 tblistener를 사용하여 작업을 수행합니다. Tibero 6부터 MONP에 의해서 생성되며 외부에서 강제 종료하더라도 다시 프로세스를 생성합니다.

   

• 클라이언트의 새로운 접속 요청이 이루어지는 순서는 다음과 같습니다.

  1. Client의 접속 요청수행

  2. Listener Process 는 대기 상태의 Worker Thread(WTHR)가 있는 Worker Process를 찾아서 클라이언트의 접속 요청

  3. 요청 하는 순간 File descriptor와 함께 할당되므로 클라이언트는 서버의 내부 동작과 상관없이 마치 처음부터 WTHR에 접속한 것처럼 동작

  4. listener Process 의 요청을 받은 control thread(CTHR)는 자기 자신에 속한 Worker Process 의 상태를 검사하여 현재 대기 상태의 WTHR에 클라이언트의 접속을 할당

  5. 할당된 WTHR는 클라이언트와 인증 절차를 거친 후 session 시작

Worker Process

[그림3] Worker Process 구조

• 클라이언트와 실제로 통신을 하며 사용자의 요구 사항을 처리하는 프로세스입니다.
• 이 프로세스의 개수는WTHR_PROC_CNT 초기화 파라미터로 조절할 수 있으며, 일단 Tibero가 기동 된 뒤에는 변경할 수 없습니다.
• Tibero 7부터 Worker Process는 용도에 따라 두 그룹으로 나눌 수 있습니다.
• Foreground Worker Process(FGWP)는 listener를 통해 들어온 온라인 요청을 처리합니다.
•  Background Worker Process(BGWP)는 Internal Task나 job scheduler에 등록된 배치 작업을 수행합니다.
  그룹은 MAX_BG_SESSION_COUNT 초기화 파라미터로 조절할 수 있습니다.
• Tibero는 효율적인 자원의 활용을 위해 thread 기반으로 작업을 수행하게 됩니다.
• Tibero를 설치하면 기본적으로 하나의 Worker Process 안에 1개의 CTHR와 10개의 WTHR가 존재합니다.
• Worker Process는 CTHR와 WTHR를 통해 작업을 수행합니다.
• CTHR(Control Thread)
  • 각 Worker Process마다 하나 씩 생성되며, Tibero가 기동 될 때 초기화 파라미터에 설정된 개수만큼
    WTHR을 생성합니다.
  • 시그널 처리를 담당합니다.
  • Client의 새로운 접속 요청이 들어오면 대기 상태의 WTHR에게 클라이언트의 접속을 할당합니다.
  • Tibero 7부터 I/O multiplexing을 지원하며 필요한 경우 WTHR 대신 메시지를 보내거나 받는 역할
    을 수행합니다.

• WTHR (Worker Thread)

  • 클라이언트와 1:1로 통신하며, 클라이언트가 보내는 메시지를 받아 처리하고, 그 결과를 돌려줍니다.
  • SQL parsing, 최적화 수행 등 DBMS가 해야 하는 대부분의 일을 처리합니다.
  • 클라이언트와 접속이 끊긴다고 해도 없어지지 않으며, Tibero가 기동 될 때 생성된 이후부터 종료할
    때까지 계속 존재하게 됩니다. 
  • 이러한 구조에서는 클라이언트와 접속을 빈번하게 발생 시키더라도 매번 thread를 생성하거나 제거하지 않으므로 시스템의 자원소모를 줄여 성능을 향상 시킬수 있습니다.

   

   

  Background Process

   [그림4] Background process

  

  • 사용자의 요청을 직접 받아들이지 않고, WTHR나 다른 background process가 요청할 때, 혹은 정해진 주기에 따라 동작하며 주로 시간이 오래 걸리는 디스크 작업을 담당합니다.
  • 독립된 프로세스로서, 사용자의 요청과 비동기로 동작합니다.
     
  • Monitor Process(MONP: 감시 프로세스)
    • Tibero 6부터 영문 약자가 thread에서 프로세스로 변경되었으며 실제로 하나의 독립된 프로세스
      입니다.
    •  Tibero가 기동할 때 최초로 생성되며 Tibero가 종료하면 맨 마지막에 프로세스를 끝 마칩니다.
    • 서버 시작 시에 listener를 포함한 다른 프로세스 생성합니다.
    • 주기적으로 각 프로세스 상태를 점검합니다.
    • deadlock을 검사합니다.
       
  • Database Write Process(DBWR: 데이터베이스 쓰기 프로세스)
    • Database Buffer의 Dirty Blocks의 내용을 주기적으로 Disk에 기록합니다.
    • 데이터베이스에서 변경된 내용을 디스크에 기록하는 일과 연관된 thread들이 모여 있는 프로세스
      입니다.

    • 사용자가 변경한 블록을 디스크에 주기적으로 기록하는 thread, Redo 로그를 디스크에 기록하는
      thread, 이 두 thread를 통해 데이터베이스의 체크포인트 과정을 관할하는 체크포인트 thread 등이 포함 되어 있습니다.

       

  • Tibero 매니저 프로세스(MGWP)
    • 시스템을 관리하기 위한 용도의 프로세스입니다.
    • 관리자의 접속 요청을 받아 이를 시스템 관리 용도로 예약된 WTHR에 접속을 할당합니다.
      기본적으로 Worker Process와 동일한 역할을 수행하지만 listener를 거치지 않고, 스페셜 포트를 통
      해 직접 접속합니다.

    • SYS 계정만 접속이 허용되며, LOCAL에서만 접속이 가능합니다.

       

    • Agent Process(AGNT)
      • 시스템 유지를 위해 주기적으로 처리해야 하는 Tibero 내부의 작업을 담당합니다.

      • 다중 thread(Multi-threaded) 기반 구조로 동작하며, 서로 다른 용도의 업무를 thread 별로 나누어 수행합니다.

         

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

[예제] Linux 계열에서 Tibero Process 확인

[예제] Windows 에서 Tibero Process 확인

Tibero Memory 구조

[그림5] Tibero Memory 구조

• instance에 대한 데이터와 제어 정보를 가지는 공유 메모리 영역입니다.
• Database Buffer, Redo Log Buffer, SQL Cache, Data Dictionary Cache로 구성되었습니다.
• Background Process는 Instance 시작될 때 TSM 영역을 할당하고, Instance가 종료 하면 할당을 해제합니다. TSM의 전체 크기는 Instance가 시작될 때 생성되어 고정됩니다.

SQL Cache

• 사용자가 문장을 수행할 때 SQL과 Parse Tree, Plan등을 저장하여 공유합니다. 
• 데이터베이스에 Compile되어 저장된 Procedure 혹은 Package 등을 사용자가 호출 시 Load하여 처리합니다.

Data Dictionary Cache

• System Tablespaces에 저장되어 있는 Data Dictionary 정보가 Shared Pool에 상주 하는 부부분입니다.
•  database에 저장된 모든 객체 및 이와 관련된 정보들을 저장하는 시스템 테이블들이 로딩 되는 영역이 사용자가 실행한 SQL문장을 parsing 할 때 Syntax와 접근 권한 등을 체크하면서 참조가 되고 공유하는 내용이기 때문에 Shared Pool 영역에 저장됩니다.

•  만약 다음 항목인 Database Buffer Hit율이 95% 이하이면 Shared Pool 사이즈가 부족하다는 의미로 증설을 고려해야합니다. 

   

Database Buffer

• Database Buffer Cache는 User들의 SQL 실행 시 Datafile들로부터 Data Block을 메모리에 Load하여 공유합니다.
•  디스크에 완전히 쓰여지지 않는 수정된 데이터(Dirty Buffer)을 가질 수도 있습니다.
• Tibero Instance에 접속한 모든 User Process은 Database Buffer Cache에 대한 Access를 공유합니다.
   

LRU 리스트(Least Recently Used)

• 가장 오래전에 사용된 것은 디스크에 저장하고 메모리에는 가장 최근에 사용된 데이터를 저장 함으로써, 디스크 I/O를 줄이고, 데이터베이스 시스템의 성능은 증가 하게 관리하는 기법이며, Free Buffer, Pinned Buffer, Dirty Buffer가 존재합니다.
  • Free Buffer : 비어있는 상태의 버퍼를 말하며, 디스크에서 데이터를 읽어 올 때 필요한 영역입니다.
  • Pinned Buffer : 현재 사용자들이 사용 중인 버퍼를 말합니다.
  • Dirty Buffer : 데이터를 변경된 버퍼를 말하며 Free버퍼를 검색 하다가 Dirty Buffer를 발견하면 Dirty List로 옮깁니다.

Dirty buffer

• 데이터가 변경되어 DBWR 프로세스에서 의해 데이터 파일에 기록 되어야 할 buffer 입니다.

  서버 프로세스는 원하는 크기의 Free를 찾다가 실패하면 LRU 검색을 멈추고 background process인 DBWR에게 신호를 주어 Dirty 디스크에 기록하여 Free버퍼의 영역을 확보합니다.

   

  • data buffer cache에 읽어 오는 과정

    LRU 리스트는 자주 사용되는 데이터를 리스트의 앞 부분에 위치하게 함으로써 자주 사용되지 않는 데이터는 리스트의 뒷 부분으로 밀려나게 됩니다.

    LRU 리스트의 앞 부분부터 원하는 데이터가 있는지 찾아봐서 데이터가 없을 때 디스크에서 읽어 들일 공간을 확보하기 위하여 자주 사용되지 않는 버퍼를 제거합니다. 

    Free버퍼를 찾는 동안 변경 데이터가 들어있는 Dirty 버퍼를 발견하면 Dirty 리스트로 옮기게 됩니다. 원하는 크기의 Free 버퍼를 찾으면 디스크에서 읽어 와서 Free 버퍼에 기록합니다.

     

  • 논리적 읽기와 물리적 읽기

    논리적 읽기는 메모리인 TSM에서 데이터를 바로 읽어올 때를 말하며, 물리적 읽기는 TSM에 데이터가 없어서 디스크에서 읽어올 때를 말합니다.

    따라서 논리적 읽기를 수행 할수록 속도가 빠르며 논리적 읽기의 적중률이 OLTP의 경우 90% 이하일 경우에는 적절한 조치를 고려해야합니다.
     

    적중률 = ( 1 – (Physical Reads / (DB Block Gets + Consistent Gets) ) ) * 100

Tibero 논리/물리 구조

[그림6] 논리/물리 구조

Tibero의 데이터를 저장하는 구조는 다음과 같이 두 가지 영역으로 나뉩니다.

논리적 저장 영역

• 데이터베이스의 schema 객체를 저장하는 영역입니다.

• 논리적 저장 영역은 다음과 같은 포함 관계가 있습니다.

  데이터베이스 > 테이블 스페이스 > 세그먼트 > 익스텐트

• Tablespace는 Segment, Extent, Block으로 구성됩니다.

[그림7] 물리적 구조

물리적 저장 영역

• 운영체제와 관련된 파일을 저장하는 영역입니다.

• 물리적 저장 영역은 다음과 같은 포함 관계가 있습니다.

  데이터 파일 > 운영체제의 데이터 블록

• DataFile: 하나의 Tablespace는 하나 혹은 여러 개의 물리적 파일로(.dtf) 연결됩니다.
• Log File: 로그 파일은 Redo Log를 저장하는 파일이다. Redo 로그는 데이터베이스에서 발생하는 모든 변경 내용을 포함하며, 데이터베이스에 치명적인 에러가 발생 한 경우, 커밋된 트랜잭션의 갱신 된 내용을 복구하는 핵심적인 데이터 구조입니다.
  • Redo 로그는 최소 두 개 이상의 로그 그룹(Log Group)으로 구성됩니다. 

  • Tibero에서는 이러한 로그 그룹을 순환적(Circular)으로 사용합니다.
    예를 들어, 세 개의 로그 그룹으로 Redo 로그를 구성하는 경우, 

    1. 로그 그룹 1에 로그를 저장

    2. 로그 그룹 1에 로그가 가득 차면 그 다음 로그 그룹 2, 3에 로그를 저장

    3. 로그 그룹 3까지 로그가 가득 차면 로그 그룹 1부터 다시 저장

    이처럼 하나의 로그 그룹을 모두 사용하고 그 다음 로그 그룹을 사용하는 것을 로그 전환(Log Switch)이라고 합니다.

     

  • Redo 로그에는 하나 이상의 로그 레코드(Log Record)가 저장됩니다. 
    로그 레코드(Log Record)에는 데이터베이스 에서 발생하는 모든 변경 내용이 포함되어 있으며, 이전에 변경된 값과 새로운 변경 값이 함께 저장됩니다. 
  • Tibero는 동시에 하나의 로그 그룹만을 사용하는데, 현재 사용 중인 로그 그룹을 활성화(Active)된 로그 그룹이라고 합니다.
  • 하나의 로그 그룹은 하나의 이상의 로그 멤버로 구성할 수 있습니다.
    이러한 구성을 다중화 (Multiplexing)라고 합니다. 
    단, 다중화를 하려면 동일한 그룹에 속해 있는 모든 로그 멤버의 크기는 일정해야 하며, 
    동일한 데이터를 저장하고 동시에 갱신되어야 한다. 반면에 서로 다른 영역에 있는 로그 그룹은 각각 다른 개수의 로그 멤버를 포함할 수 있으며, 로그 멤버의 크기가 같지 않아도 됩니다.

참고-TAC 구조

[그림8] TAC 구조도

• 가용성 기능을 위한 TAC의 구조도 입니다.
• Heartbeat check를 네트워크 구성과 공유 디스크 기반의 Concurrent 환경에서 설치 가능합니다.