[Tibero교육] Tibero Architecture

0. 교육소개

1. 티베로 인스턴스

2. 데이터베이스 저장구조

3. 티베로 기능

 

교육소개

과정	내용
Tibero Architecture	티베로 SQL 아키텍쳐와 주요 기능을 학습합니다. • 교육기간 : 1일 • 교육대상 : Tibero 사용자

 교육목표

• 티베로 SQL 아키텍쳐와 주요 기능을 숙지한다.

 

 교육대상

• Tibero 관리자, SQL 개발자

 

 사전요구지식

• 데이터베이스 개념

• SQL 의 이해

• Application 과 DBMS 기반의 시스템 이해

• Linux/Unix 터미널에서의 기본 명령어 활용

• vi editor 사용

 

1. 티베로 인스턴스

 

Tibero 전체 구조

Tibero Process

 

 Tibero 프로세스 구조

   대규모 사용자 접속을 수용하는 다중 프로세스 및 다중 스레드 기반의 아키텍쳐 구조

    - Listener, 워커프로세스 (Working Process 또는 Foregroud Process) , Background Process

 Listener

 클라이언트의 새로운 접속 요청을 받아 이를 유휴한 워커 프로세스에 할당

 클라이언트와 워커 프로세스간에 중계 역할을 담당하며, 별도의 실행 파일인 tblistener를 사용하여 작업

 모니터링 프로세스에 의해서 생성되며 외부에서 강제 종료하더라도 자동으로 재 시작 됨

 Listener Port

Listener port

< $TB_SID.tip > LISTENER_PORT=8629

Extra listener port
정적	< $TB_SID.tip > LISTENER_PORT=8629 EXTRA_LISTENER_PORTS=8639;8640;
정적	alter system listener add port 8799; alter system listener delete port 8799;

 클라이언트의 새로운 접속 요청이 이루어지는 순서

1) Client가 접속 요청

2) Listener는 현재 빈 WTHR이 있는 프로세스를 찾아서 이 사용자의 접속 요청을 CTHR에게 넘겨줌.

3) 요청을 받은 CTHR은 자기 자신의 WTHR 상태를 체크해서 일하지 않는 WTHR에게 할당

4) WTHR은 Client와 인증 절차를 걸쳐 세션 시작

 

 워커프로세스 (Worker Processes 또는 Foregroud Process)

   클라이언트와 실제 통신을 하며, 사용자 요구 사항을 처리 하는 프로세스

   Foregroud Worker Process는 리스너를 통해 들어온 온라인 요청 처리

   Backgroud Worker Process는 Internal Task나 Job Scheduler에 등록된 배치 작업을 수행

 

 CTHR (Control Thread)

  - 각 Working Process마다 하나씩 생성. 서버 시작 시에 지정된 개수의 Worker Thread를 생성.

  - 시그널 처리 담당.

  - I/O Multiplexing을 지원하며, 필요한 경우 워커 스레드 대신 메시지 송/수신 역할 수행.

 

 WTHR (Worker Thread).

  - 각 Worker Process마다 여러 개 생성.

  - Client 가 보내는 메시지를 받아 처리하고 그 결과를 리턴.

  - SQL Parsing, 최적화, 수행 등 DBMS가 해야 하는 대부분의 일 처리.

 Background Processes

 

 사용자의 요청을 직접 받아들이지는 않고, 워커스레드나 다른 배경 프로세스가 요청할 때, 혹은 정해진 주기에 따라 동작하며 주로 시간이 오래 걸리는 디스크 작업 담당

 독립된 프로세스로서, 사용자의 요청과 비동기적으로 동작.

 

 감시 프로세스(MONP: monitor process)

 매니저 프로세스(MGWP: manager worker process)

 에이전트 프로세스(AGNT : agent process)

 데이터베이스 쓰기 프로세스(DBWR : database writer)

 복구 프로세스(RCWP : recover worker process)

감시 프로세스(MONP: monitor process)

 

Tibero 기동 시 최초로 생성되는 종료 시에도 마지막에 종료

Tibero 기동 시, 리스너를 포함한 다른 프로세스를 생성, 주기적으로 각 프로세스 상태 점검

교착 상태 (Deadlock)도 검사

 

매니저 프로세스(MGWP)

 

시스템 관리 용도 프로세스

관리자의 접속 요청을 받아 이를 시스템 관리 용도로 예약된 워커 스레드에 접속을 할당

기본적으로 워커 프로세스와 동일한 역할을 수행하지만 리스너를 거치지 않고, 스페셜 포트를 통해 직접 접속

SYS 계정만 접속이 허용, LOCAL 에서만 접속 가능

 

에이전트 프로세스(AGNT : agent process)

 

시스템 유지를 위해 주기적으로 처리해야 하는 Tibero 내부의 작업을 담당

- Internal Task나 Batch Job이 언제 수행되어야 하는지 판단은 AGENT 프로세스가 담당 하지만, 실제 수행은 포어그라운드 혹은 백그라운드 워커 프로세스에게 의뢰하는 구조임

다중 스레드(multi-threaded) 기반 구조로 동작하며, 서로 다른 용도의 업무를 스레드별로 나누어 수행

 

데이터베이스 쓰기 프로세스(DBWR)

 

데이터베이스에서 변경된 내용을 디스크에 기록하는 일과 연관된 스레드들이 모여 있는 프로세스

사용자가 변경한 블록을 디스크에 주기적으로 기록하는 스레드

리두 로그를 디스크에 기록하는 스레드

두 스레드를 통해 데이터베이스의 체크포인트 과정을 관할하는 체크포인트 스레드

 

복구 프로세스(REWP)

 

복구 전용 프로세스

Crash / Instance Recovery 수행

 

Tibero Memory

 

 Tibero Shared Memory (TSM)

 인스턴스에 대한 데이터와 제어 정보를 가지는 공유 메모리 영역

 사용자가 동시에 데이터를 공유

 Database Buffer, Redo Log Buffer, SQL Cache, Data Dictionary Cache 로 구성됨.

 Backgroud Process는 인스턴스가 시작될 때 TSM 영역을 할당하고, 인스턴스가 종료하면 할당 해제

 TSM의 전체 크기는 인스턴스가 시작될 때 생성되어 고정.

2. 데이터베이스 저장구조

 

Tibero Database 구조

 Tibero Database 저장소 구조

Tibero Database 구조 (물리 저장구조)

 

Tibero Database 파일

 하나 or 그 이상의 Control files, Datafiles 그리고 Redo log files.

 Datafiles

• Tables & Indexes 들과 같은 Logical structure들은 물리적으로 Datafiles에 저장 되는 파일.

 Redo Log Files

• 복구를 위하여 Database에서 변경된 모든 것을 기록 하는 파일.

 Control Files

• Database의 물리적 구조와 상태를 기록 하는 파일.

 

Tibero Database 파일 저장 방식

 

 운영체제의 파일 시스템

• 일반적으로 파일시스템은 논리볼륨관리자(LVM) 에 의해 생성된 논리볼륨을 기반으로 구축되어 있고, LVM 은 서로 다른 물리적 디스크 영역을 하나의 연속된 주소 공간으로 결합하여 제공함

 

 Tibero Active Storage (TAS)

• Tibero Database 에서 사용하는 전용 파일시스템

• Tibero TAC 환경에서 TAS 를 기반으로 데이터베이스를 생성하여 운영할 수 있음

 

 RAW 장치

• Raw Device 는 파일시스템으로 포맷되어 있지 않은 디스크 파티션 혹은 논리 볼륨으로, 파일시스템과 달리 캐시를 거치지 않고 직접 I/O 를 수행할 수 있음

• Tibero TAC 환경에서 TAS 를 기반으로 데이터베이스를 생성하여 운영할 수 있음

 

 클러스터 파일 시스템

• 클러스터 파일 시스템은 여러 컴퓨터에서 파일의 저장소를 공유 하는 기능을 제공함

• Tibero TAC 환경에서 클러스터 파일시스템을 기반으로 데이터베이스를 생성하여 운영할 수 있음

Datafiles

- Tibero Database 는 데이터 파일 이라는 구조에 데이터베이스 데이터를 저장합니다.

- Tablespace는 하나이상의 물리적인 datafile을 가지며, 하나의 datafile은 오직 하나의 Tablespace에 포함

- 세그먼트는 하나 이상의 데이터 파일에 걸쳐 있을 수 있지만, 여러 테이블스페이스에 걸쳐져 있는 것은 아님

 

일반 테이블스페이스의 영속적인 데이터 파일

- 테이블, 인덱스와 같은 영구적인 스키마 객체가 포함되며, 데이터 파일에 저장 관리됨

 

임시 테이블스페이스의 임시파일(Tempfile)

- 세션의 또는 트랜잭션 지속 시간 동안 임시 테이블과 같은 스키마 객체의 데이터가 존재하며, 메모리에서의 해시 및 정렬 등의 작업 메모리 공간이 부족했을때의 저장소로 사용됨

- 일반테이블의 영구적인 데이터는 임시파일에 저장되지 않음

- 임시파일을 사용하는 스키마 오브젝트는 NOLOGGING 모드로 설정되며, 미디어 복구가 않됨

- 임시 파일은 DBA_TEMP_FILES, V$TEMPFILE 에서 모니터링 할수 있고, 일반 데이터 파일을 조회하는 DBA_DATA_FILES, V$DATAFILE 뷰에서는 표시되지 않음

 

온라인 데이터 파일 및 오프라인 데이터 파일

- 모든 데이터 파일은 온라인 (사용 가능) 또는 오프라인 (사용 불가능) 상태에 해당됨

- MOUNT 모드에서 데이터파일을 오프라인 변경후, 테이블스페이스를 삭제할 수 있음

- 테이블스페이스를 오프라인 변경하면 연결된 데이터파일 또한 오프라인 상태가 됨

- 데이터파일의 이름/경로를 바꾸기 위해서는 해당 테이블 스페이스를 오프라인 상태로 설정후 변경가능

 

 

 복구를 위해 데이터베이스 변경사항을 기록하고, 리두 로그 그룹은 적어도 2개 이상으로 순환하며 사용

 만약 Database운영 Mode가 ARCHIVELOG Mode일 경우 Log Switch가 일어날 때 log_archive_dest로 Copy되어져 향후 복구 시 사용됨

 ( 인스턴스 복구시 ) 온라인 리두로그의 내용을 이용하여 아직 데이터 파일에 기록되지 않은 커밋된 데이터를 복구함

 리두로그 버퍼의 내용(커밋되지 않은 트랜잭션, 커밋된 트랜잭션, 언두 데이터, 스키마 객체 관리를 위해 사용한 쿼리 문 등) 이 기록됨

 Redo log File을 구성하는데 1 Group에 2개 이상의 Member를 동일 Machine상에서 다른 Disk에 분리하여 구성하기 권장.

 Multiplexed Redo Log Files는 특정 그룹에서 하나의 파일을 손실 시에 특이 사항 없음.

 그룹의 모든 Member들은 동일한 정보와 Size 를 갖음

 아카이브 리두 로그 파일은 온라인 리두로그 그룹 맴버의 복사본임

 데이터베이스 파일에 속하지는 않지만 복구를 위해 사용되는 중요한 파일임

 아카이브 리두 로그의 용도

- 데이터베이스 백업 복구

- TSC( Tibero Standby Cluster) 의 Standby DB 의 데이터 업데이트

- 데이터복제 솔루션인 ProSync 에서 사용

 Control File은 작은 Binary File로 Database의 구조.

 모든 Database Files & log files들은 Control file에서 식별 가능.

 Database name은 Control file에 저장.

 Control File은 Mount, Open시에 필요.

 Recovery시 필요한 동기화된 정보를 저장.

 최소 다른 Disk상에 2개 이상의 Control Files를 가지도록 권장.

 Control File은 Database가 Open되어 졌을 때 반드시 Tibero Server가 Writing 가능하도록 설정.

 

Tibero Database 구조 (논리 저장구조)

 

 

 

세그먼트 생성

- 테이블, 인덱스 객체 생성시 세그먼트가 할당됩니다.

- 파티션 되어 있는 객체는 파티션마다 세그먼트가 할당됩니다.

UNDO 세그먼트

 

 

세그먼트 공간관리와 HWM(High Water Mark)

 

- 자동 세그먼트 공간 관리 방식으로써 BITMAP 을 이용하여 공간을 관리함

- PCTFREE 파라미터를 이용하여 블록 속성 설정 ( 다른 파라미터는 허용은 되나 무시됨)

- 데이터 입력시 블록그룹을 할당하며 세그먼트 헤더블록의 비트맵에 블록 정보를 기록합니다

- 데이터 입력시 LOW HWM 하위의 여유공간이 있는 블록에 쓰거나, LOW HWM 과 HWM 사이의 블록을 사용함

- FULL SCAN 시에 LOW HWM 하위의 모든 블록과 LOW HWM 과 HWM 사이의 경우는 세그먼트 헤더블록의 BIT MAP 정보를 이용하여 액세스 함

 

데이터 블록

- 데이터베이스 I/O 의 단위이자 논리저장구조의 최소 단위가 데이터 블록임

- 운영체제 블록 크기와 다를 경우 배수 단위로 데이터 블록의 크기를 설정해야 함

행 연쇄(Row Chaining) & 행 이주(Row Migration)

- INSERT 수행시 공간 부족으로 해당 블록에 모두 저장되지 않는 경우, 일부는 해당 블록에 저장되고, 다른 새로운 블록에 나머지 데이터가 이어서 저장됨

- UPDATE 수행시 큰 값으로 수정되면서 저장할 공간이 없는 경우, 값이 다른 새로운 블록으로 이동하여 저장됨

- 한개의 행 조각(row piece ) 에 255 개 컬럼이 저장되므로, 컬럼 갯수가 그 이상일때 나머지 컬럼들은 다른 행 조각에 이어서 저장됨

ROWID

- 헁을 식별하기 위한 고유의 식별자

- 각 행의 물리적 주소를 BASE64 인코딩으로 표현한 값으로 ROWID 값 자체가 테이블에 저장되어 있는것은 아님

- 저장구조 정보(세그먼트에 대한 오브젝트 번호, 데이터파일 번호, 데이터 블록 번호, 행 번호) 를 조합하여 사용함

- 오브젝트 번호 : 세그먼트를 식별하는 데이터 오브젝트 번호

- 데이터 파일 번호 : 행을 포함하는 테이블스페이스의 데이터 파일의 파일 아이디

- 블록 번호 : 데이터파일 기준으로 블록의 위치를 식별하기 위한 값 ( * 따라서 Tablespace에 데이터파일이 여러 개일때 블록번호가 동일한 블록이 존재할 수 있음)

- 행 번호 : 블록내에서 행을 식별하기 위한 번호

 

테이블스페이스

 

- 세그먼트를 저장하는 논리 저장소, 한개 이상의 데이터 파일이나 임시파일을 사용하여 데이터를 저장함

 

Tibero Database 구조 ( 기타 )

 slog (TRACE Log)

• Tibero Instance가 실행 중에 Error발생시 messages은 Trace or Dbms Log file에 Write.

• 서버 성능이 저하되는 원인을 찾거나 티베로 자체 버그를 해결하는 데 사용될 수 있음

• Log File은 $TB_HOME/instance/$TB_SID/log/slog ( <--trace ) Directory에 Write.

• 다음과 같은 Error발생시 Write.

  – All internal errors

  – Block corruption errors

  – Deadlock errors

  – Etc

 

 dlog (DBMS Log) File

• Log File은 $TB_HOME/instance/$TB_SID/log/dlog (<--dbms) Directory에 Write.

• 서버 기동 및 종류, DDL 문장의 수행 등이 기록되는 파일.

• 다음과 같은 Error발생시 Write.

  – DDL, Server Manager statements (STARTUP, SHUTDOWN,ARCHIVE LOG, and RECOVER)

 

 Listener 로그 파일(lsnr)

• Listener의 디버깅을 위한 파일이다. 리스너에서 일어난 중요한 일이 기록되는 파일이며, 리스너의 버그를 해결하는 데 사용될 수 있다.

 

 Internal 로그 파일(ilog)

• 스레드별로 설정된 이벤트에 대한 시스템 로그가 기록되는 파일이며, Internal 로그를 보려면 tbiv를 이용해야 한다.

 

3. 티베로 기능

 

대용량 데이터의 고성능 처리

Tibero는 대용량 데이터 처리를 위한 아키텍처를 기반으로 고성능 처리를 지원합니다.

TAC(Tibero Active Cluster)

Tibero의 TAC 기술은 안정성과 고가용성을 위한 핵심으로서 공유디스크 기반의 Active Clustering을 통하여 다양한 유형의 장애에도 시스템 중단 없이 안정적인 서비스를 지원

TSC(Tibero Standby Cluster)

Tibero TAC 뿐만 아니라 독립 디스크 방식(Shared Nothing)의 TSC(Tibero Standby Cluster) 이중화 구성을 지원하여 운영상 고가용성과 재해복구(DR)에 적합한 아키텍처를 제공

백업 & 복구

장애로부터 데이터를 안전하게 보호하기 위하여, 다양한 백업/복구 방법을 지원

보안 및 암호화

Tibero는 DB 자체 보안 기능 뿐 아니라, 암호화 솔루션과의 연동 및 빠른 암호화를 지원

개발 관리 도구

Tibero RDBMS를 이용하는 개발자와 관리자에게 필요한 Utility 를 지원