Only this pageAll pages
1 of 10

Zetadata_7.2.5

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

ZetaData Manual

안내서 정보

안내서 제목 : Zetadata 관리자 안내서 발행일 : 2026-04-10 소프트웨어 버전 : Zetadata v.7.2.5 안내서 버전 : v1.0.0

본 안내서는 Tibero ZetaData(이하 ZetaData)를 설치하고 관리하는 데이터베이스 관리자(Database Administrator, 이하 DBA)를 대상으로 기술합니다.

사전 필요 지식

  • 데이터베이스의 이해

  • RDBMS의 이해

  • Tibero의 이해

  • 운영체제 및 시스템 환경의 이해

  • UNIX 계열 (LINUX 포함) 운영체제의 기본 지식


티맥스티베로 ZetaData 매뉴얼에 적용되는 저작권 안내사항 입니다.

경기도 성남시 분당구 정자일로 45 티맥스타워

Tel : +82-1544-8629

E-Mail : gitbook@tibero.com

이 소프트웨어(Tibero ZetaData) 사용설명서의 내용과 프로그램은 저작권법과 국제 조약에 의해서 보호받고 있습니다. 사용설명서의 내용과 여기에 설명된 프로그램은 TmaxTibero Co., Ltd.와의 사용권 계약 하에서만 사용이 가능하며, 사용설명서는 사용권 계약의 범위 내에서만 배포 또는 복제할 수 있습니다. 이 사용설명서의 전부 또는 일부분을 TmaxTibero의 사전 서면 동의 없이 전자, 기계, 녹음 등의 수단을 사용하여 전송, 복제, 배포, 2차적 저작물 작성 등의 행위를 하여서는 안 됩니다.

이 소프트웨어 사용설명서와 프로그램의 사용권 계약은 어떠한 경우에도 사용설명서 및 프로그램과 관련된 지적 재산권(등록 여부를 불문)을 양도하는 것으로 해석되지 아니하며, 브랜드나 로고, 상표 등을 사용할 권한을 부여하지 않습니다. 사용설명서는 오로지 정보의 제공만을 목적으로 하고, 이로 인한 계약상의 직접적 또는 간접적 책임을 지지 아니하며, 사용설명서 상의 내용은 법적 또는 상업적인 특정한 조건을 만족시키는 것을 보장하지는 않습니다. 사용설명서의 내용은 제품의 업그레이드나 수정에 따라 그 내용이 예고 없이 변경될 수 있으며, 내용상의 오류가 없음을 보장하지 아니합니다.

Tibero ZetaData는 TmaxTibero Co., Ltd.의 등록 상표입니다. 기타 모든 제품들과 회사 이름은 각각 해당 소유주의 상표로서 참조용으로만 사용됩니다.

본 제품의 일부 파일 또는 모듈은 다음의 라이선스를 준수합니다.

  • OpenSSL

  • RSA Data Security, Inc.,

  • Apache Foundation

  • Jean-loup Gailly and Mark Adler

관련 상세한 정보는 제품의 아래 디렉터리에 기재된 사항을 참고해 주십시오.

${INSTALL_PATH}/license/oss_licenses


본 문서는 총 9개의 장으로 구성됩니다.

Paul Hsieh's hash

본 안내서는 ZetaData 환경에 대한 모든 사항을 포함하지는 않습니다.

데이터베이스 운용에 관한 내용은 ''를 참고합니다.

저작권 안내

주소

Website

기술서비스센터

Restricted Rights Legend

Trademarks

Open Source Software Notice

안내서 구성

소개

ZetaData의 기본 개념과 구조, 특장점을 설명합니다.

🔎

네트워크 설정

각 구성 요소 간에 네트워크를 설정하는 방법을 설명합니다.

🔎

설치 및 설정

스토리지 서버 인스턴스를 설치하고 디스크와 플래시 디바이스 등을 등록하는 방법을 설명합니다. 또한 Tibero Active Storage 인스턴스와 Tibero Active Cluster 인스턴스에서 스토리지 서버 인스턴스를 사용하여 디스크 스페이스, 테이블 스페이스를 만들고 DB를 설치하는 방법을 안내합니다.

🔎

플래시 캐시 관리

스토리지 서버에 플래시 디바이스를 이용하여 플래시 캐시를 설정하는 방법을 기술하고, 이를 효율적으로 사용하기 위한 설정들을 안내합니다.

🔎

Tibero Columnar Compression

ZetaData의 기능인 Tibero Columnar Compression에 대해 설명합니다.

🔎

Function Offloading

ZetaData의 주요 기능인 Function Offloading에 대해 설명합니다.

🔎

Storage Data Map

ZetaData의 주요 기능인 스토리지 데이터 맵(Storage Data Map)에 대해 설명합니다.

🔎

데이터 백업 및 복구

ZetaData 상에서 데이터 백업과 복구 방법을 설명합니다.

🔎

장애 복구

ZetaData의 각 구성 요소에 대한 장애 복구 방법을 설명합니다.

🔎

Tibero 안내서
소개 바로가기
네트워크 설정 바로가기
설치 및 설정 바로가기
플래시 캐시 관리 바로가기
Tibero Columnar Compression 바로가기
Function Offloading 바로가기
Storage Data Map 바로가기
데이터 백업 및 복구 바로가기
장애 복구 바로가기

네트워크 설정

본 장에서는 ZetaData의 DB 노드와 Storage 노드의 네트워크를 구성하는 방법에 대해서 설명합니다.

개요

ZetaData는 DB 노드와 Storage 노드 간의 빠른 네트워크 통신을 위해서 InfiniBand를 사용합니다. 아래의 과정으로 InfiniBand를 사용해서 ZetaData 네트워크를 설정합니다.

  1. InfiniBand 드라이버 설치

  2. InfiniBand 드라이버 동작 확인

  3. 커널 파라미터 설정

  4. 네트워크 구성 (각 InfiniBand 제조사의 네트워크 구성 메뉴얼을 참고하여 구성합니다.)

아래 그림은 앞으로 예에서 사용할 ZetaData 노드의 InfiniBand용 IP 주소 구성입니다.

InfiniBand를 사용하기 위해서는 OS에 맞는 적합한 드라이버와 라이브러리를 설치해야 합니다.

먼저 각 OS 별로 적합한 명령어를 통해 해당하는 라이브러리를 설치합니다.

아래는 OS별 라이브러리 설치 예입니다.

Ubuntu

위 명령어로 출력된 'Development files for the libibverbs library' package를 설치합니다.

RedHat 계열 (RHEL, CentOS, Fedora)

아래는 RedHat 7, 8, 9 OS 위에 멜라녹스(Mellanox)사에서 제공한 InfiniBand 드라이버를 설치하는 예시입니다.

1. 멜라녹스 드라이버를 설치합니다.

  1. InfiniBand용 네트워크 설정 파일을 생성합니다. 아래는 DB 노드 0번에서의 설정 파일 예입니다.

  1. subnet manager 기능을 지원하지 않는 스위치의 경우에 opensmd 서비스를 실행합니다.

  1. 서버를 재부팅합니다.

아래는 멜라녹스사에서 제공하는 InfiniBand 드라이버의 동작을 확인하는 예입니다.

장애 복구

본 장에서는 ZetaData의 각 구성 요소에 대한 장애 복구 방법을 설명합니다.

SSVR 인스턴스에 장애가 발생하면 TAS 인스턴스는 해당 디스크의 상태를 자동으로 감지해 I/O Fail-over를 수행합니다. 각 SSVR 인스턴스를 1:1로 FAILGROUP을 구성했고, 디스크 스페이스의 중복 레벨이 NORMAL 이상이라면 DB에서 수행되는 모든 부하는 하나의 SSVR 인스턴스의 장애와 관계 없이 정상적으로 동작합니다.

SSVR 인스턴스가 장애 상황으로부터 복구되면 TAS 인스턴스는 SSVR 인스턴스의 상태를 자동으로 감지해 해당 SSVR 인스턴스에 속한 모든 디스크들에 대해 동기화를 수행합니다. SSVR 인스턴스의 장애가 복구 불가능한 경우라면 디스크 스페이스로부터 해당 SSVR 인스턴스를 제거할 수 있습니다. 이는 TAS 인스턴스에 접속해 제거 대상 SSVR 인스턴스에 해당하는 FAILGROUP을 삭제함으로써 가능합니다.

아래는 장애가 발생한 SSVR 인스턴스가 FG0이라는 FAILGROUP일 때 TAS 디스크 스페이스로부터 제거하는 예입니다.

제거하려는 모든 디스크의 데이터를 저장할 만큼 남은 디스크 스페이스에 충분한 여유 공간이 있어야 합니다.

새로 구성한 SSVR 인스턴스를 추가하려면 TAS의 ALTER DISKSPACE 구문을 이용해 FAILGROUP을 추가합니다.

참고

InfiniBand가 없거나 사용에 문제가 있는 경우 RDMA 프로토콜 대신 TCP 프로토콜을 사용하도록 설정할 수 있습니다. 방법은 “초기화 파라미터”의 SSVR_USE_TCP 파라미터를 참고합니다.

1. InfiniBand 드라이버 설치

2. InfiniBand 드라이버 동작 확인

DB 노드 0번

DB 노드 1번

참고

위 예에서는 ibv_rc_pingpong 명령어로 DB 노드 간의 테스트만 진행하였으나, SSVR 노드를 포함한 모든 노드에서 각 ZetaData 노드로의 InfiniBand 드라이버 동작 테스트를 진행하는 것을 권장합니다.

그림 1. ZetaData 노드 InfiniBand IP address 구성도
아래는 새로 구성한 SSVR 인스턴스의 그리드 디스크를 디스크 스페이스의 FG0이라는 FAILGROUP에 추가하는 예입니다.


TAC 인스턴스에 장애가 발생한 경우에는 Tibero Active Cluster의 Fail-over 기능을 통해 세션이 복구됩니다. 자세한 내용은 "Tibero 관리자 안내서"를 참고합니다.

SSVR 인스턴스 장애

참고

플래시 디바이스의 장애는 복구 불가능한 장애로 처리해야 합니다.

TAC 인스턴스 장애

$ sudo apt-cache search libibverb
$ sudo apt-get install libibverbs-dev
$ yum install libibverbs-devel libibverbs-devel-static
$ ./mlnxofedinstall
$ echo "CONNECTED_MODE=yes
> TYPE=InfiniBand
> BOOTPROTO=none
> DEFROUTE=yes
> #IPV4_FAILURE_FATAL=no
> #IPV6INIT=yes
> #IPV6_AUTOCONF=yes
> #IPV6_DEFROUTE=yes
> #IPV6_FAILURE_FATAL=no
> NAME=ib0
> #UUID=6842318b-35d2-475a-8ae2-b3f9ec6b787a
> DEVICE=ib0
> ONBOOT=yes
> IPADDR=10.10.10.11
> NETMASK=255.255.255.0
> #PREFIX=32
> #IPV6_PEERDNS=yes
> #IPV6_PEERROUTES=yes" > /etc/sysconfig/network-scripts/ifcfg-ib0
$ systemctl enable opensmd.service
$ service opensmd start
$ ip addr show ib0
8: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast \
state UP qlen 1024
link/infiniband 80:00:00:2c:fe:80:00:00:00:00:00:00:50:65:f3:ff:ff:88:81:d0 \
brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
inet 10.10.10.11/24 brd 10.10.10.255 scope global ib0
valid_lft forever preferred_lft forever
inet6 fe80::5265:f3ff:ff88:81d0/64 scope link
valid_lft forever preferred_lft forever
$ ibv_rc_pingpong
local address: LID 0x0006, QPN 0x008382, PSN 0xc85390, GID ::
remote address: LID 0x0002, QPN 0x02e388, PSN 0xb0671b, GID ::
8192000 bytes in 0.01 seconds = 10726.02 Mbit/sec
1000 iters in 0.01 seconds = 6.11 usec/iter
$ ip addr show ib0
8: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast \
state UP qlen 1024
link/infiniband 80:00:00:2c:fe:80:00:00:00:00:00:00:50:65:f3:ff:ff:88:71:40 \
brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
inet 10.10.10.12/24 brd 10.10.10.255 scope global ib0
valid_lft forever preferred_lft forever
inet6 fe80::5265:f3ff:ff88:7140/64 scope link
valid_lft forever preferred_lft forever
$ ibv_rc_pingpong 10.10.10.11
local address: LID 0x0002, QPN 0x02e388, PSN 0xb0671b, GID ::
remote address: LID 0x0006, QPN 0x008382, PSN 0xc85390, GID ::
8192000 bytes in 0.00 seconds = 13317.62 Mbit/sec
1000 iters in 0.00 seconds = 4.92 usec/iter
$ tbsql sys/tibero@tas0
SQL> alter diskspace DS0 drop disks in failgroup FG0 rebalance wait;
$ tbsql sys/tibero@tas0
SQL> alter diskspace DS0 add failgroup FG0
          disk '-10.10.10.11/GD0' name DISK0 size 64G, 
               '-10.10.10.11/GD1' name DISK1 size 64G
          rebalance wait;

Storage Data Map

본 장에서는 ZetaData의 주요 기능인 스토리지 데이터 맵(Storage Data Map)에 대해 설명합니다.

스토리지 데이터 맵(Storage Data Map) 기능은 수행하는 디스크 읽기 양을 줄여서 디스크 대역폭을 효율적으로 사용할 수 있는 기술입니다.

ZetaData는 한 번 읽은 디스크 영역에 대해 각 컬럼의 최댓값과 최솟값 등의 통계값을 자동으로 계산해 메모리에 유지함으로써, 필터링 조건을 만족하는 데이터가 없는 디스크 영역에 대해 읽기 작업을 수행하지 않도록 할 수 있습니다. 실제로 수행하는 디스크 읽기 작업의 양이 줄어들기 때문에 디스크 대역폭을 보다 효율적으로 사용할 수 있을 뿐만 아니라 디스크 I/O에 소모되는 시간을 크게 줄일 수 있습니다.


Table Full Scan의 형태로 데이터를 조회하는 경우에는 물리적으로 연속된 디스크 영역을 읽게 되는데, 이때 SSVR 인스턴스는 해당 디스크 영역에 대해 각 컬럼의 최댓값과 최솟값을 계산해 스토리지 데이터 맵을 구성합니다. 인덱스를 이용한 테이블 조회와 같이 특정 디스크 블록만 읽는 경우에는 연속된 디스크 영역 전체를 읽지 않기 때문에 스토리지 데이터 맵이 생성되지 않습니다. 따라서 Function Offloading과 마찬가지로 인덱스를 생성하지 않거나, 쿼리 힌트를 사용하는 방식으로 Table Full Scan을 수행하는 것이 효과를 높이는데 중요합니다.

스토리지 데이터 맵 생성 대상이 되는 컬럼은 테이블의 전체 컬럼들 중 조회 쿼리의 WHERE 절에 포함된 컬럼들로만 한정됩니다. 또한 함수나 계산식 등으로 전처리를 거치지 않은 컬럼들만 대상이 됩니다.

적용되는 컬럼의 타입은 NUMBER, CHAR, VARCHAR뿐만 아니라 별도의 변환 없이 WHERE 절에 포함될 수 있는 대부분의 기본 타입이 포함됩니다. LOB 컬럼은 별도의 LOB 세그먼트에 저장되기 때문에 LOB 컬럼이 포함된 경우 해당 기능을 사용할 수 없습니다. Long과 Raw 타입은 Function Offloading 기능이 동작하지 않기 때문에 SDM이 생성되지 않습니다. Xml 타입도 같은 이유로 SDM의 기능을 사용할 수 없습니다.

해당 컬럼이 WHERE 절에 사용될 때에는 "크다, 작다"와 같은 크기 비교는 물론이고, "같다, 다르다", "NULL이다, NULL이 아니다" 등으로 표현될 수 있습니다. 대상 컬럼의 개수가 많은 경우에는 최대 8개까지의 컬럼에 대해서만 스토리지 데이터 맵이 생성되며, 이후 조회된 컬럼은 무시됩니다.

SSVR 인스턴스를 기동한 이후 처음으로 저장된 데이터를 조회할 때에는 아직 생성된 스토리지 데이터 맵이 없기 때문에 성능 향상 효과를 볼 수 없으며, 같은 컬럼을 WHERE 절을 이용해 반복해서 조회하는 경우에 조회 성능이 향상됩니다. 이때 사용하는 WHERE 절은 스토리지 데이터 맵 생성 시 사용한 WHERE 절과 완전히 같을 필요는 없습니다. 사용하는 컬럼만 동일하다면 조회 성능은 향상됩니다.

그림 1. Storage Data Map 동작 방식

스토리지 데이터 맵은 디스크의 각 영역에 대한 컬럼들의 최댓값과 최솟값을 포함하는데, WHERE 절의 조건이 최대, 최소의 범위를 벗어나는 경우 해당 디스크 영역에 대한 읽기 작업을 수행하지 않을 수 있습니다.

따라서 조회 쿼리의 선택도(selectivity)가 낮을수록 다시 말해 조건을 만족하는 데이터의 수가 적을수록 성능 향상의 폭이 큽니다. 마찬가지로 WHERE 절에 사용되는 컬럼에 대해 정렬된 형태로 데이터를 저장할 경우 컬럼의 최댓값과 최솟값의 차이가 작아지기 때문에 스토리지 데이터 맵의 효과를 극대화할 수 있습니다.

생성된 스토리지 데이터 맵은 해당 영역에 대한 쓰기 요청을 수행하는 즉시 메모리에서 제거됩니다. 데이터가 변경될 경우 기존에 계산한 통계값이 달라질 수 있기 때문입니다. 따라서 데이터의 변경이 많은 OLTP 시스템에서는 스토리지 데이터 맵의 사용은 권장하지 않습니다.

Function Offloading이 켜져있을 때 스토리지 데이터 맵이 동작하므로, 이 경우 Function Offloading 초기화 파라미터를 이용해 Function Offloading 기능을 비활성화합니다.

개요

동작 방식

주의

SDM에 대한 공유 메모리 확보가 필요합니다.

자세한 내용은 “”를 참고합니다.

데이터 백업 및 복구

본 장에서는 ZetaData의 데이터 백업 방법과 이를 이용한 복구 방법을 설명합니다.

개요

ZetaData는 크게 SSVR 인스턴스, TAS 인스턴스, TAC 인스턴스로 구성됩니다.

SSVR 인스턴스는 여러 대의 서버에 구성할 수 있으며, TAC 인스턴스에 볼륨을 제공하기 위하여 TAS 인스턴스가 이를 관리합니다. TAS 인스턴스 또한 TAC 인스턴스에 맞춰 클러스터로 구성합니다. SSVR과 TAS에 대한 백업 기능은 제공하지 않습니다. 일반적인 TAC 백업은 스토리지와 무관하게 데이터베이스 솔루션을 이용하여 이루어지는 것과 동일합니다.


ZetaData 백업 및 복구

ZetaData의 데이터를 백업하는 방법은 크게 세 가지가 있습니다.

tbexport를 이용한 논리적(logical) 백업 및 복구

범용적인 데이터베이스 백업과 동일하며 백업된 결과 파일을 tbimport를 이용하여 적재할 수 있습니다.

RMGR을 이용한 물리적(Physical) 백업 및 복구

데이터의 관점이 아닌 데이터베이스의 관리 대상 파일에 대한 물리적인 백업입니다.

TAS 인스턴스를 사용하여 데이터베이스를 구성한 경우 OS 유틸리티를 통해 데이터베이스 파일에 접근할 수 없습니다. RMGR이 이러한 역할을 대신 수행합니다.

RMGR은 데이터베이스의 스토리지가 로컬 디스크, SAN 디스크, TAS를 사용하는 SAN 디스크, 그리고 ZetaData인 모든 경우에 대해서 백업을 지원합니다. RMGR을 사용할 경우 DB 노드에서 백업/복구를 수행하게 되고, 이로 인해 사용자가 ZetaData만을 위한 별도의 작업을 하지 않아도 됩니다.

tbascmd를 이용하면 TAS 인스턴스에 command line tool로 명령어를 통하여 디스크 스페이스에 저장된 파일과 로컬 디렉터리간에 복사하는 방식으로 백업 및 복원을 수행할 수 있습니다. TAC 인스턴스를 기동 중지시킨 후 TAS 인스턴스만 기동 중인 상태에서 cptolocal 명령어를 이용하여 DB 운영에 필요한 모든 파일을 로컬 파일 시스템으로 백업합니다.

복구를 진행하기 전 checkpoint를 수행합니다. checkpoint를 하면 메모리에만 들어있던 데이터들이 플래시와 디스크에 저장됩니다.

아래 쿼리를 통하여 백업을 시도하기 전에 파일 타입(File Type)과 블록 크기(Block Size)를 확인합니다.

컨트롤 파일, 리두 파일, 데이터 파일 등 필요한 모든 파일을 로컬에 백업합니다.

TBASCMD는 tbascmd (포트 번호)로 접속할 수 있습니다. 포트 번호는 TAS의 tip 파일에 LISTENER_PORT로 기록되어 있습니다.

아래는 9120 포트를 사용하는 TAS 인스턴스에서 c1.ctl 컨트롤 파일을 로컬에 백업하는 예입니다.

위 명령어 수행 결과로 백업 파일과 cpfromlocal 명령어를 사용한 롤백 스크립트 파일이 생성된 것을 확인할 수 있습니다.

tbascmd의 cptolocal 명령어를 이용하여 DB가 관리하는 파일들을 모두 백업해 둔 상태에서 다른 노드의 TAS 디스크 스페이스로 이관 및 복원을 진행할 수 있습니다. 이관하고자 하는 노드의 로컬 디렉터리로 백업 파일을 전송하고 cpfromlocal 명령어를 이용하여 로컬 파일 시스템의 백업 파일들을 TAS의 디스크 스페이스로 복사합니다. 이때 백업하며 확인했던 파일 타입(file type '-t')과 블록 크기(block size '-b')를 인자로 지정합니다. 파일 타입에는 CTRL, REDO, DATA, TEMP, ARCH로 총 다섯 가지 종류가 있습니다.

아래는 노드 1번 TAS의 디스크 스페이스 DS0으로 백업 파일을 복사하는 예입니다.

초기화 파라미터
SQL> alter system checkpoint;
SQL> select a.type, a.block_size, b.name from v$as_file a, v$as_alias b 
        where a.file_number = b.file_number;
$ tbascmd 9120
ASCMD> cptolocal +DS0/c1.ctl /home/node0/c1.ctl
$ ls /home/node0
c1.ctl c1.ctl_rollback.sh
cpfromlocal /home/node1/c1.ctl +DS0/c1.ctl -b 16384 -t CTRL 
cpfromlocal /home/node1/log001.log +DS0/log001.log -b 512 -t REDO 
cpfromlocal /home/node1/usr001.tdf +DS0/usr001.dtf -b 32768 -t DATA 
cpfromlocal /home/node1/temp001.dtf +DS0/temp001.dtf -b 32768 -t TEMP
cpfromlocal /home/node1/log-t0-r0-s1.arc +DS0/ARCH/log-t0-r0-s1.arc -b 512 -t ARCH

참고

RMGR의 사용법은 ""의 "백업과 복구"를 참고합니다.

tbascmd를 이용한 cold 백업 및 복원

주의

잘못된 블록 크기로 파일을 복원하면 정합성 문제가 발생할 수 있습니다.

cpfromlocal 명령어는 cptolocal 명령어의 결과로 생성된 스크립트 파일을 여건에 맞게 수정한 뒤 참고 또는 사용하는 것을 권장합니다.

참고

TBASCMD의 자세한 내용은 ""의 "커맨드라인 툴"을 참고합니다.

Tibero 관리자 안내서
Tibero Active Storage 관리자 안내서

Function Offloading

본 장에서는 ZetaData의 주요 기능인 Function Offloading에 대해 설명합니다.

개요

Storage 노드를 사용하지 않는 TAC(Tibero Active Cluster) 구성에서 많은 양의 I/O를 수행하게 되면, SAN 스위치의 대역폭 한계에 의해 SAN 스위치에서 병목 현상이 발생합니다. ZetaData에서는 이와 같은 문제를 해결하기 위해 SAN 스위치 대신 고대역폭의 InfiniBand를 사용하고 있습니다. 하지만 여전히 네트워크를 통해 많은 양의 데이터를 전송해야 한다는 점은 바뀌지 않습니다.

ZetaData의 Function Offloading 기능은 기존에 TAC 인스턴스에서 수행하던 로우 필터링(filtering)이나 컬럼 필터링(projection) 등과 같은 작업들을 SSVR 인스턴스로 이전(offload)해서 수행함으로써, 네트워크를 통해 전송되는 데이터의 양을 현저히 감소시키는 역할을 합니다.

뿐만 아니라 DB 노드의 CPU 자원보다 상대적으로 사용률이 적은 Storage 노드의 CPU 자원을 이용할 수 있도록, 압축 해제와 같이 CPU 자원을 많이 사용하는 작업 또한 SSVR 인스턴스로 이전하여 수행할 수 있습니다.


동작 방식

Function Offloading은 기본적으로 Table Full Scan 형태로 데이터를 조회하는 경우에만 동작합니다.

Function Offloading 기능이 네트워크를 통한 데이터의 전송량을 줄이는 목적으로 만들어졌기 때문에 인덱스를 이용한 테이블 조회와 같이 I/O의 양이 많지 않은 경우에는 기능이 동작하지 않습니다.

ZetaData 구성에서 대용량의 데이터를 저장할 때 인덱스를 생성하지 않는 것이 해당 기능의 효과를 높이는데 중요합니다. 불가피하게 인덱스가 생성되어 있는 컬럼을 WHERE 절에 포함하여 데이터를 조회하는 경우에는 쿼리에 Full Scan 힌트(/*+full_storage(t1)*/)를 부여하여 인덱스를 통한 조회를 피할 수 있습니다. 반대로 Function Offloading을 사용하지 않고자 할 때에는 힌트(/*+no_full_storage(t1)*/)로 강제할 수 있습니다. 다른 제약 사항으로는 별도의 LOB 세그먼트에 저장되는 LOB 컬럼에 대해서는 해당 기능을 사용할 수 없다는 점이 있습니다.

Function Offloading 기능은 많은 데이터가 WHERE 절 처리 단계에서 걸러질 수 있는 경우에 큰 효과를 보입니다. TAC 인스턴스로 전송해야 하는 데이터의 양이 SSVR 인스턴스의 작업을 통해 많이 줄어들 수 있기 때문입니다.

또한 SSVR 인스턴스 내에서 Prefetch 관리를 하기 때문에 기능을 사용하지 않는 블록 요청 대비 I/O가 효율적으로 진행됩니다. 하지만 SSVR 인스턴스는 TAC 인스턴스의 버퍼 캐시 위에서 일어난 수정 작업에 대해서 알 수 없기 때문에 빈번한 수정작업이 일어나는 테이블에 대해서는 SSVR 인스턴스가 처리하지 못합니다. 즉, OLTP 작업에서는 이 기능의 효과가 미미합니다.

Function Offloading 기능을 통해 조회하는 테이블에 대한 데이터는 TAC 인스턴스의 버퍼 캐시에 보관되지 않을 수 있습니다. 이는 SSVR 인스턴스에서 1차 가공된 형태로 TAC 인스턴스에 전달된 경우에는 데이터 블록의 형태로 전달되지 않기 때문입니다. 같은 이유로 버퍼 캐시에 모든 데이터를 적재할 수 없을 정도로 양이 많은 테이블에 대한 작업 시에 기능의 효과가 크게 나타납니다.

반대로 조회하려는 데이터가 버퍼 캐시에 충분히 저장할 정도로 작거나 해당 데이터에 대한 조회와 수정이 빈번하게 일어나 이미 버퍼 캐시에 적재돼 있음을 기대하는 경우에는 기능을 사용하지 않도록 합니다.

IB를 사용하지 않고 ZetaData를 TCP로 구성하는 경우에는, Function Offloading의 결과가 TCP를 통해 전달되어 SGA에 임시 보관해야 하기 때문에 충분한 SGA가 확보되어야 합니다. TAC 인스턴스에서는 한 번에 SSVR 인스턴스의 그리드 디스크(Grid Disk) 개수 만큼 I/O를 요청하므로 기능을 사용하지 않을 때 보다 훨씬 많은 SGA 공간을 사용하기 때문입니다. SGA에 대한 TAC 인스턴스 설정은 Tibero의 설정을 참고합니다.


다음은 Function Offloading 기능과 관련한 초기화 파라미터에 대한 설명입니다.

파라미터
설명


다음은 Function Offloading 기능이 지원되는 함수들의 목록입니다.

제약 사항 : TO_CHAR 함수는 입력 데이터로 lob 타입을 지원하지 않습니다.

STORAGE_PROCESSING

Function Offloading 기능 사용해서 데이터를 읽을지 여부를 지정하는 DB 인스턴스의 세션 파라미터입니다.

쿼리 수행 전 "Y" 또는 "N"으로 설정해 수행하는 쿼리별로 해당 기능의 동작 여부를 지정합니다. (기본값: USE_ZETA=Y인 경우만 Y)

ABS, ADD_MONTHS, ASCII, ASCIISTR, BETWEEN, BITAND, CASE, CEIL, CHR, COALESCE, DECODE, DUMP, EXP, EXTRACT, FLOOR, FROM_TZ
HEXTORAW, INITCAP, INSTR, INSTRB, ISSEQUENCEWORDS,
LAST_DAY, LENGTH, LENGTHB, LENGTHC, LIKE, LNNVL, LOG, LOWER, LPAD, LTRIM, MOD, MONTHS_BETWEEN, NEW_TIME, NEXT_DAY, NULLIF, NUMTODSINTERVAL, NUMTOYMINTERVAL, NVL, NVL2, OVERLAPS, RAWTOHEX, REVERSE, ROUND, ROWIDTOCHAR,
RPAD, RTRIM, SIGN, SQRT, SUBSTR, SUBSTRB, SYS_EXTRACT_UTC,
TO_CHAR(Lob 타입은 지원하지 않음), TO_DATE, TO_DSINTERVAL, TO_MULTI_BYTE, TO_NCHAR, TO_NUMBER, TO_SINGLE_BYTE, TO_TIME, TO_TIMESTAMP, TO_TIMESTAMP_TZ, TO_YMINTERVAL, TRANSLATE, TRIM, TRUNC, UPPER, VSIZE

참고

쿼리 힌트와 관련한 자세한 내용은 ""를 참고합니다.

초기화 파라미터

함수

Tibero SQL 참조 안내서

소개

본 장에서는 ZetaData의 기본 개념과 구조, 특장점을 설명합니다.

개요

현재 데이터 웨어하우스(Data Warehouse) 시장은 데이터의 폭증으로 인해 큰 한계에 도달했습니다. 데이터의 크기는 테라바이트(terabytes)를 넘어 페타바이트(petabytes)로 확장되며, 단일 데이터 웨어하우스의 규모로 인해 기업 전체의 데이터 양은 더욱 증가하게 됩니다. 이러한 데이터 증가는 결국 성능과 비용 문제를 야기하게 됩니다.

기존 SAN(Storage Area Network) 환경으로 구성된 데이터 웨어하우스에서는 I/O 성능에서 병목 현상이 발생합니다. 일반적인 스토리지 I/O 성능 증가율은 데이터 증가 비율을 충분히 반영하지 못하고 있습니다.

또한 SAN 환경에서는 확장성에 한계가 있습니다. 이를 해결하기 위해서는 더욱 고가의 장비를 마련하여 DB를 재설치하고 데이터를 이관해야 합니다. 이 또한 어느 시점에는 더 이상 확장(Scale-up)할 수 없게 되어 기존 데이터를 외부로 백업하거나 삭제해야 합니다. 즉, 향후 데이터 증가 추세를 해결하려면 수평적 확장성과 대용량 데이터에 대한 고속 접근 성능이 필요합니다.

이에 대한 해결책 중 하나로 '빅 데이터' 시장에서 오픈 소스인 Hadoop을 찾을 수 있습니다. Hadoop은 무한 확장이 가능한 파일 시스템인 HDFS와 이를 분석하기 위한 MapReduce 프레임워크를 제공합니다. 그러나 Hadoop을 이용하여 범용 RDBMS만큼 고차원의 분석을 수행하는 것은 쉽지 않습니다.

Hadoop은 다음과 같은 문제점을 가지고 있습니다.

  • MapReduce를 사용하면 SQL과 같이 간단한 쿼리를 작성하고 활용하기 어렵습니다.

  • 엄격한 일관성(Strict Consistency)을 가지지 않습니다.

또 다른 해결책으로는 Appliance 시장에서 찾을 수 있습니다. 대기업들이 일반적으로 사용하는 방식으로, Oracle 사의 Exadata, EMC사의 Greenplum, MS사의 PDW 등이 있습니다. 이들은 수백 terabytes에서 petabytes까지 지원하는 스토리지 데이터베이스 통합 솔루션을 제공합니다. 또한 하드웨어(H/W)와 소프트웨어(S/W)를 동시에 제공합니다. 대부분 분석에 최적화되어 있으며 SQL 표준을 준수하여 다양한 환경에서 일관된 쿼리 작성이 용이합니다.

이러한 Appliance DW 방식의 문제점은 종속성에 있습니다. H/W와 S/W 일체형을 도입해야 하기 때문에 모든 면에서 특정 벤더에게 종속될 수 있습니다. 예를 들어 Exadata의 경우, Exadata S/W와 Sun H/W를 도입해야 합니다. 고객마다 원하는 H/W가 다를 수 있지만, 항상 정해진 H/W를 사용해야 합니다.

또 다른 문제점은 가격입니다. 위의 Appliance들은 매우 고가의 장비로, H/W와 S/W 가격이 수억에서 수십억 원에 이르게 됩니다. 따라서 특정 규모 이상의 기업이 아니라면 도입하기 어렵습니다. 이러한 문제점들을 해결하기 위해 ZetaData가 출시됐습니다.

ZetaData는 다음과 같은 주요 기능을 가집니다.

ZetaData는 DB와 이를 지원하기 위한 스토리지 소프트웨어로 이루어져 있습니다. 스토리지 소프트웨어는 로컬 디스크(Local Disk)가 여러 개 장착된 서버에 설치되며, 이를 스토리지 서버라고 합니다. 이러한 스토리지 서버 각각은 서로 독립된 구성요소이므로, 스토리지 서버가 하나 늘어난다고 해도 다른 스토리지 서버에 영향을 주지 않습니다. 단지 TAS Layer에서 이를 하나의 볼륨으로 보이게 합니다. 이러한 구조로 인해 대용량 확장이 가능한 스토리지 구조를 제공할 수 있습니다.

H/W에 플래시 디바이스가 있다면 이를 이용하여 I/O Cache Tiering을 할 수 있습니다. 즉, 플래시 디바이스를 I/O 캐시로 사용하게 되어 OLTP 환경에서도 매우 빠른 응답속도를 제공합니다. 필요하다면 플래시 디바이스를 I/O 캐시가 아닌 디스크로 사용할 수 있습니다.

ZetaData는 InfiniBand를 기본 네트워크 인터커넥트로 채택하고 있습니다. InfiniBand는 기존 네트워크 기술들보다 훨씬 높은 대역폭을 자랑하며, Fiber Channel로 구축된 SAN 환경 보다 수 배 높은 대역폭을 제공합니다.

ZetaData는 기본적으로 RDMA(Remote Direct Memory Access) 프로토콜을 이용해 노드 간에 데이터를 주고받습니다. RDMA 프로토콜을 사용함으로써 통신 지연시간과 CPU 사용률을 크게 줄이고 있습니다.

기존의 로우 방향 데이터 저장 구조를 컬럼 방향으로 바꾼 후 압축함으로써 극대화된 압축 효율을 얻을 수 있습니다. 또한 데이터의 접근 빈도에 따라 서로 다른 압축 방법을 적용하여, 자주 사용하는 데이터는 조회 속도를 높이고 자주 사용하지 않는 데이터는 압축률을 높일 수 있습니다.

Tibero 7은 10년 이상 실환경에서 검증을 받아온 RDBMS로, 다른 DBMS들과의 BMT(Bench Marking Test)에서도 우수한 성능을 입증하고 있으며, 공공, 금융, 기업 등 다양한 분야에서 적용되고 있습니다. 핵심 및 분석 업무를 고려한 자원 효율적 아키텍처를 채택하여 대규모 데이터 처리와 클라우드 환경 요구에 효과적으로 대응하며, 안정성, 고성능, 호환성, 편의성을 보장합니다.

Tibero는 다음과 같은 고급 기능을 제공합니다.

  • 분산 데이터베이스 링크

  • 데이터 이중화

  • 데이터베이스 클러스터

  • 병렬 쿼리 처리

ZetaData의 여러 분산 스토리지 서버를 하나로 묶고 Volume Managing을 하기 위하여 TAS를 제공합니다. TAS를 이용하여 일반 스토리지 솔루션처럼 Striping, Mirroring, Logical Volume Managing 등의 기능을 사용할 수 있습니다. CM(Cluster Manager)은 클러스터링 운영을 안정적으로 가능하게 합니다.

SSVR 인스턴스는 로컬 디스크를 관리하고 DBMS의 작업 중 I/O 작업을 위해 독립적으로 구성됩니다. TAC 인스턴스에 접근하는 방식과 동일하게 tbSQL을 이용하여 SSVR 인스턴스에 접속하여 관리할 수 있습니다.

로컬 디스크 관리, 통계 정보 확인을 위한 정보를 제공합니다. SSVR 인스턴스를 설치하기 위한 바이너리는 기존 Tibero 바이너리와 동일한 형태로 제공됩니다.

SSVR 인스턴스에는 아래의 프로세스들이 생성됩니다.

프로세스
설명

TAS 인스턴스와 TAC 인스턴스가 SSVR 인스턴스에 I/O 요청을 보내고 결과를 받기 위해 TAS 인스턴스와 TAC 인스턴스에 다음의 프로세스가 추가로 생성됩니다.

프로세스
설명

쿼리 최적화기

MGWP

시스템을 관리하기 위한 용도의 프로세스입니다. 기본적으로 워커 프로세스와 동일한 역할을 수행하지만 리스너를 거치지 않고 스페셜 포트를 통해 직접 접속을 처리합니다. SYS 계정만 접속이 허용됩니다.

FGWP0000

클라이언트와 실제로 통신을 하며 사용자의 요구 사항을 처리하는 프로세스입니다. 구체적으로 로컬 디스크 관리, 통계 정보 확인을 위한 정보 제공 등을 합니다.

SSVR

실제 입출력 요청을 받고, 이를 처리합니다.

플래시 캐시의 관리나 스토리지 데이터 맵의 관리도 수행합니다. 대부분의 작업이 SSVR 프로세스에서 수행됩니다.

SSIO

SSIO는 ZetaData 환경에서 TAS 인스턴스와 TAC 인스턴스가 SSVR 인스턴스와 I/O 요청 메시지를 교환하기 위해 생성되는 프로세스입니다.

주요 기능

대용량의 데이터를 처리하기 위한 수평적 스토리지 구조

Flash Device를 활용한 I/O Cache Tiering

InfiniBand를 네트워크 인터커넥트로 사용하여 SAN보다 고대역폭 I/O 제공

RDMA 프로토콜을 적용하여 통신 지연시간 단축

컬럼 방향 압축을 통한 압축률 극대화

검증된 Tibero 7 데이터베이스 제공

참고

Tibero의 상세 기능에 대한 설명은 ""를 참고 합니다.

TAS, CM 활용한 안정적인 클러스터링 운영

참고

Tibero의 상세 기타 기능에 대한 자세한 설명은 ""를 참고합니다.

참고

본 안내서에서는 물리적인 서버를 노드(Node), 노드 내에서 실행되는 소프트웨어를 인스턴스(Instance) 라고 정의합니다. ZetaData에서 TAS, TAC, CM 인스턴스가 실행되는 서버는 DB 노드이며, SSVR 인스턴스가 실행되는 서버는 Storage 노드입니다.

이후 Tibero는 ZetaData와 같은 스토리지 솔루션뿐만 아니라 TAC, HA, Single 등 다양한 제품을 포괄하는 의미로 사용합니다.

SSVR 인스턴스

참고

모든 DB 노드와 Storage 노드에 ZetaData 전용으로 빌드된 바이너리를 동일하게 사용할 것을 권장합니다.

SSVR 인스턴스 내 프로세스들

TAS/TAC 인스턴스 전용 SSVR 통신 프로세스

참고

SSVR을 설치하면 생성되는 디렉터리는 기존 Tibero와 동일합니다.

자세한 내용은 ""를 참고 합니다.

그림 1. ZetaData 구성도
Tibero 안내서
Tibero Active Storage 안내서
Tibero 안내서

Tibero Columnar Compression

본 장에서는 ZetaData의 주요 기능인 Tibero Columnar Compression(이하 TCC)에 대해 설명합니다.

개요

TCC는 압축률 향상과 디스크 I/O 감소에 도움을 주는 데이터 저장 방식입니다.

TCC를 이용하면 기존의 방식(row의 column들을 연속으로 배치하는 것)을 대신하여 테이블의 각 컬럼들을 개별적으로 수집하여 연속으로 저장합니다.

아래와 같이 컬럼을 연속으로 배치할 경우, 동일한 데이터 패턴이 반복되어 RLE(Run-Length Encoding), LZ4(Lempel-Ziv 4), gzip(GNU zip), bzip2(block zip version 2)와 같은 압축 기법에 매우 효과적입니다.

그림 1. TCC 구성(Compression Unit)

TCC 장점

  • 압축률이 크게 향상됩니다. 데이터 패턴에 따라 차이가 나지만, 일반적인 OLAP 비즈니스 환경에서 4:1~10:1의 압축률 향상을 기대할 수 있습니다.

  • 압축률이 향상되므로 전체 I/O가 줄어듭니다. I/O가 성능의 병목인 경우 성능향상을 도모할 수 있습니다. 또한 ZetaData는 SSVR 인스턴스에서 압축을 해제하기 때문에 DB 노드의 자원을 소모하지 않습니다. Storage 노드의 CPU 자원은 일반적으로 여유가 있는 경우가 많습니다.

  • 컬럼별로 배치되므로 불필요한 컬럼을 읽지 않습니다. 전체 컬럼수와 비교하여 필요한 컬럼이 적을 경우 I/O수행 횟수를 줄일 수 있습니다.

아래의 경우에 TCC를 사용하면 효과적입니다.

위에서 설명한 바와 같이 TCC로 구성된 테이블에 대해 update가 일어나면 성능이 저하됩니다. 따라서 주로 DPL/DPI를 통해 대량으로 로딩하고, 데이터 라이프 사이클(Life Cycle)에 따라 테이블 전체를 따로 저장하거나 폐기하는 용도로 매우 적합합니다.

주로 사용되는 쿼리가 Full table scan인 경우에 TCC를 추천합니다. Full table scan은 선택도(Selectivity) 에 따라 결정될 수도 있고, aggregation 사용 여부에 따라 결정될 수도 있습니다.

데이터 길이나 패턴이 일정하거나 비슷한 테이블의 경우 RLE, LZ4, gzip, bzip2와 같은 압축을 적용했을 때 좋은 압축률을 기대할 수 있습니다. 또한 로딩할 때 압축률이 거의 일정하면, 재압축 횟수가 줄어들어 로딩 속도도 향상됩니다.

TCC 사용은 테이블의 일부 컬럼만 필요로 하는 경우에 특히 효과적입니다. 필요하지 않은 컬럼에 해당하는 CU(Compression Unit)는 읽지 않습니다. 만약, row-oriented로 저장되어 있다면 필요로 하는 컬럼 개수와 관계없이 row의 전체 컬럼을 읽어야 합니다. 따라서 상대적으로 읽어야하는 블록 숫자가 늘어납니다.


아래는 TCC와 관련한 초기화 파라미터에 대한 설명입니다. CC_CU_BLKCNT는 시스템 파라미터이고 나머지 파라미터들은 세션 파라미터입니다.

파라미터
설명


CREATE TABLE 명령을 수행할 때 아래의 옵션을 주어서 TCC 테이블을 만들 수 있습니다.

컬럼 압축 중에서는 OLTP성 업무로 인한 성능 손실을 최대한 막을 수 있는 레벨입니다.

중간 정도의 압축 레벨입니다. 압축/해제의 성능도 중간 정도입니다.

보다 높은 압축 레벨입니다. 압축/해제의 성능은 다소 떨어집니다.

최대 압축률입니다. 압축/해제의 성능도 제일 낮습니다.

아래는 옵션을 사용한 예입니다.


TCC는 row-oriented 저장구조에 비해 장점만 있는 것은 아니기 때문에 잘못 사용하면 성능에 큰 손실을 입을 수 있습니다. 아래와 같은 경우는 주의해야 합니다.

TCC로 저장된 테이블에 update가 수행되면, 압축이 해제되고 해당 row는 row-oriented 로 변경됩니다. 또한 많은 경우에 row 단위로 읽는 방식보다 더 많은 블록을 읽어야 하는 특성이 있습니다. 예를 들어 UPDATE SET A=1, B=2 WHERE C=3을 처리할 때에 row-oriented로 저장되어 있으면 한 블록만 읽으면 되지만, TCC로 저장되어 있으면 세 개의CU를 읽어야 합니다.

CC_CU_BLKCNT가 클 경우는 다음과 같은 상황에서 더욱 문제가 될 수 있습니다. 하나의 row를 처리하기 위해서 각 CU마다 CC_CU_BLKCNT만큼의 블록 I/O가 필요합니다. 따라서 압축효율의 큰 차이가 없다면, 적정 수준의 CC_CU_BLKCNT를 사용하는 것이 좋습니다.

인덱스를 통한 접근 시 항상 CU 단위로 압축을 해제합니다. (단, 연속된 rowid에 대해서는 압축 해제된 내용을 재사용합니다. 각각의 Row마다 항상 압축을 해제하는 것은 아닙니다.)

따라서 인덱스를 통한 접근 시 압축 해제가 빈번하게 발생할 수 있으므로, 성능 저하 가능성을 고려해야 합니다. 인덱스를 통한 접근과 같이, TCC 저장방식은 row 단위로 접근하는 모든 경우에 비효율적입니다.

  • TCC가 걸린 테이블에 drop column, set unused column, rowid를 사용하는 table redefinition이 불가능합니다.

  • TCC가 걸린 테이블에 bitmap index 생성이 불가능합니다.

  • LOB, LONG, XML, 사용자 정의형(nested table, varray, object 등) column type이 존재하는 테이블에 TCC 사용 불가능합니다.

CC_EXPECTED_RATE

압축될 데이터의 일반적인 압축 비율입니다(힌트).

CC_TYPICAL_ROW_SIZE와 함께 처음 CU를 구성할 때 쓰입니다. 이후 CU에 대한 예측은 직전 CU의 결과를 이용합니다.

(기본값: 25, 범위: 1 - 100)

CC_CU_WRITEOUT_THRESHOLD

CC_CU_WRITEOUT_THRESHOLD는 단일 블록이 쓰기 작업을 진행하기 위해 충족해야 하는 최소 채움 비율을 지정하는 설정입니다. 즉, 블록의 데이터가 설정된 비율 이상 채워졌을 때에만 해당 블록이 디스크에 기록됩니다.

(기본값: 85, 범위: 0 - 99)

암호화된 테이블에 DPI 수행 시 압축이 되지 않습니다.
  • TCC가 걸린 테이블에 Merge, Split partition 수행 시 Update Global Indexes(UGI), Update Indexes(UI) 사용이 불가능합니다.

  • CC_CU_BLKCNT

    CU(Compression Unit)가 가질 수 있는 최대 블록 개수입니다.

    보통은 큰 CU가 압축에 유리하지만, 어느 정도 이상이 되면 많이 차이가 나지 않습니다. 불필요하게 CU가 크면 반복적인 압축 해제가 있는 경우 불리하게 작용할 수도 있습니다.

    DB_FILE_MULTIBLOCK_READ_COUNT보다 작게 설정하는 것을 권장합니다. (기본값: 4, 범위: 1 - 32)

    CC_CU_PCTUSE

    CU에 들어갈 최소 용량 비율입니다. CU를 구성할 때 최소 이 비율 이상을 채웁니다. 이 값이 크면 공간 낭비를 막을 수 있는 반면, 로딩할 때 재압축이 많아져서 성능이 저하될 수 있습니다. (기본값: 95, 범위: 0 - 99)

    CC_TYPICAL_ROW_SIZE

    압축될 데이터의 일반적인 row 크기입니다.

    처음 압축을 시작할 때에 힌트로 사용됩니다. 이 값과 CC_EXPECTED_RATE를 이용해서 한 CU에 몇 개의 row가 들어갈지 예측해서 압축을 더 빠르게 진행시킬 수 있습니다. (기본값: 100, 범위: 3 - 1000)

    Update(또는 delete)가 드물게 발생하는 테이블

    Full table scan이 빈번하게 발생하는 테이블

    데이터 길이나 패턴이 일정하거나 비슷한 테이블

    Projectivity가 큰 테이블

    초기화 파라미터

    TCC 테이블 생성 명령어

    참고

    컬럼 압축이 아닌 기존의 기본 압축 방식을 적용하기 위해서는 COMPRESS까지만 설정합니다.

    TCC 사용 주의사항

    Update(또는 Delete)가 빈번하게 발생하는 테이블

    인덱스를 통한 접근이 많은 테이블

    제약조건

    CREATE TABLE {table-name} COMPRESS FOR QUERY LOW
    CREATE TABLE {table-name} COMPRESS FOR QUERY HIGH
    CREATE TABLE {table-name} COMPRESS FOR ARCHIVE LOW
    CREATE TABLE {table-name} COMPRESS FOR ARCHIVE HIGH
    CREATE TABLE T(A NUMBER) COMPRESS FOR QUERY HIGH

    플래시 캐시 관리

    본 장에서는 Storage 노드의 플래시 디바이스를 이용하여 SSVR 인스턴스에 플래시 캐시를 설정하는 방법을 기술하고, 이를 효율적으로 사용하기 위한 설정들을 설명합니다.

    개요

    SSVR 인스턴스는 플래시 디바이스를 캐시로 지원합니다.

    플래시 디바이스는 빠른 I/O 성능과 비휘발성 저장 공간을 제공합니다. 캐시는 데이터를 쓰는 방법에 있어서 아래 그림과 같이 write-through 방식과 write- back 방식이 존재합니다.

    그림 1. write-through와 write-back

    write-through 방식

    디스크와 캐시 양쪽에 데이터를 저장해야 쓰기 동작이 완료되는 방식입니다.

    write-back 방식

    캐시에만 데이터를 저장하면 쓰기 동작이 완료되는 방식입니다.

    write-back 방식은 디스크 쓰기를 하지 않기 때문에 I/O 속도가 빨라진다는 장점을 가집니다. 반면에 캐시의 내용을 추후에 디스크에 복사(flush)를 해야 한다는 단점을 가집니다. 이것을 체크포인트 과정이라고 합니다. ZetaData의 플래시 캐시는 쓰기 I/O속도 향상을 위해서 write-back 방식을 사용하고 있습니다.

    write-back 캐싱 알고리즘을 사용하면 캐시의 내용과 디스크의 내용이 일치하지 않는 경우가 발생합니다.

    데이터가 들어 있는 블록을 dirty 블록이라고 합니다. dirty 블록은 캐시 교환 알고리즘에 의해서 캐시가 부족한 시점에 오래된 dirty 블록순으로 디스크와 동기화합니다. 이때 dirty 블록을 디스크에 동기화하는 작업을 체크포인트라고 합니다. 동기화된 dirty 블록은 clean 블록이 됩니다.

    free 블록의 비율이 부족할 경우, clean 블록 중 오래된 블록을 선별하여 free 블록이 되어 새로운 I/O 요청을 캐싱할 수 있습니다. 평소에는 캐시 교체 정책에 의하여 자동으로 체크포인트가 수행됩니다. 또한, 관리자는 체크포인트를 수동으로 지시할 수 있습니다.

    아래는 수동으로 플래시 캐시를 체크포인트하는 DDL입니다.

    자동 혹은 수동으로 체크포인트를 수행할 때, 플래시 캐시로부터 읽어서 디스크로 쓰는 작업이 수행되기 때문에 해당 기간동안 성능 저하가 발생할 수 있습니다. 이를 방지하고자 SSVR 인스턴스의 IDLE 상태를 파악하여 체크포인트를 수행하는 IDLE 체크포인트 기능을 사용할 수 있습니다.

    IDLE이라고 판단한 상태에서 천천히 내리도록 노력하지만 플래시 캐시 읽기 및 디스크 쓰기 작업이 수행되기 때문에 상황에 따라 다른 작업들에 지연을 유발할 수 있습니다. 따라서 본 기능의 경우 보수적으로 설정하여 성능에 영향이 없는 지 주기적으로 확인하거나 IDLE 체크포인트 관련된 로그를 수집하여 파라미터를 면밀히 설정할 필요가 있습니다.

    플래시 캐시 IDLE 체크포인트 수행 방식은 파라미터 값을 설정하여 조절할 수 있습니다. 아래는 플래시 캐시 IDLE 체크포인트에 관련된 파라미터에 대한 설명입니다.

    초기화 파라미터
    설명

    플래시 캐시를 사용하고 싶지 않을 경우에는 플래시 캐시를 제거합니다.

    플래시 캐시의 정합성을 유지하기 위해서는 dirty 블록이 없어야 합니다. 현재 플래시 캐시 제거를 명령하면 내부적으로 체크포인트를 수행합니다. 체크포인트 동작이 완료되면 플래시 캐시는 정상적으로 제거됩니다.

    아래는 플래시 캐시를 제거하는 DDL입니다.

    아래는 플래시 캐시 성능에 관련된 파라미터에 대한 설명입니다.

    초기화 파라미터
    설명

    아래는 플래시 캐시의 생성 정보를 확인하는 방법입니다.

    SSVR_FC_IDLE_THRESHOLD

    SSVR_FC_IDLE_PW_RATIO를 통해 IDLE이라고 판단한 상태가 이 값 만큼 지속되어야 최종적으로 IDLE 체크포인트를 시작합니다. 이 값의 단위는 초단위입니다. (기본값: 600)

    SSVR_FC_CKPT_ON_IDLE

    플래시 캐시을 IDLE 체크포인트기능을 활성화할지 여부를 나타내는 파라미터입니다. (기본값: N)

    SSVR_FC_IDLE_CKPT_CNT

    IDLE한 경우, 1초에 checkpoint를 수행할 dirty 블록 개수입니다. (기본값: 1)

    SSVR_FC_IDLE_PW_RATIO

    IDLE이라고 판단할 SSVR의 worker thread의 수 대비 job의비율입니다. 이 비율 이하의 job이 존재할 시, IDLE이라 판단합니다. (기본값: 5)

    SSVR_FC_WS_CNT

    Working set의 개수를 정의합니다. 별도로 설정하지 않은 경우 CPU 개수와 동일하게 지정되므로 설정하지 않아도 됩니다. Working set의개수는 CPU 개수와 동일하게 설정하는 것을 권장합니다.

    SSVR_FC_FREE_BIN_RATIO

    플래시 캐시는 오랫동안 접근되지 않은 캐시 블록을 free 블록으로 변경시켜 줍니다.

    파라미터는 확보해야 할 free 블록의 비율을 정의합니다. 이 값이 크면 free 블록을 미리 확보하여 free 블록 얻는 대기시간을 줄일 수 있다는 장점이 있지만, 반대로 캐싱되는 블록의 개수가 줄어들게 된다는 단점이 있습니다. (기본값: 10%)

    SSVR_FC_DIRTY_BIN_RATIO_MAX

    플래시 캐시에서 유지할 최대 dirty 블록의 비율(%)을 정의합니다.

    만약 이 비율 이상 dirty 블록이 존재하게 되면, Background Thread에서 체크포인트를 수행하여 정의한 최대 dirty 블록의 비율을 유지합니다. (기본값: 80%)

    플래시 캐시 체크포인트

    플래시 캐시 IDLE 체크포인트

    플래시 캐시 제거

    플래시 캐시 초기화 파라미터

    플래시 캐시 생성 정보 확인

    $ tbsql sys/tibero
    
    tbSQL 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    
    Connected to Tibero.
    
    SQL> alter flashcache checkpoint;
    
    altered.
    
    SQL>
    $ tbsql sys/tibero
    tbSQL 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    
    Connected to Tibero.
    
    SQL> drop flashcache flash0;
    
    dropped.
    
    SQL>
    $ tbsql sys/tibero
    
    tbSQL 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
    
    Connected to Tibero.
    
    SQL> select * from V$SSVR_FLASHCACHE;
    FLASHCACHE_NUMBER NAME                    PATH                         OS_BYTES
    ----------------- ----------------------- -------------------------- -----------
                    0 FLASH1                  /dev/zeta-flash1            5.3687E+10
                    1 FLASH2                  /dev/zeta-flash2            5.3687E+10
                    2 FLASH3                  /dev/zeta-flash3            5.3687E+10
                    
    3 rows selected.
    
    SQL>
    

    설치 및 설정

    본 장에서는 SSVR 인스턴스를 설치하고 디스크와 플래시 디바이스 등을 등록하는 방법을 설명합니다. 그리고 TAS 인스턴스와 TAC 인스턴스에서 SSVR 인스턴스를 사용하여 디스크 스페이스, 테이블 스페이스를 만들고 DB를 설치하는 방법을 설명합니다.

    노드 사양

    본 장에서 다루는 모든 설치 및 설정 예는 아래 표에 제시된 DB 노드와 Storage 노드의 사양을 기준으로 진행합니다. 각 노드의 사양은 ZetaData 구성 및 시스템 성능에 영향을 미치는 주요 요소이므로, 설정 작업을 시작하기 전에 이를 확인하는 것이 중요합니다.

    항목
    DB 노드 사양
    Storage 노드 사양

    메모리

    256GB

    메모리와 디스크 용량을 확인하는 방법은 여러 가지가 있습니다.

    아래는 노드의 물리 메모리 용량을 확인하는 예입니다.

    아래는 노드의 디스크 용량을 확인하는 예입니다.

    Storage 노드의 디스크가 용량 4TB인 12개로 가정하면, 일반적으로 임의의 디스크 1개에 400GB로 OS, SSVR 바이너리 및 컨트롤 파일을 저장합니다.

    RAID를 사용하지 않은 경우에는 OS가 설치된 400GB를 제외한 3.6TB 공간이 하나의 파티션으로 구성됩니다. 따라서 OS가 설치된 디스크의 3.6TB짜리 파티션, 나머지 4TB 디스크 11개를 이용하여 Storage 노드를 구성할 수 있습니다.

    Storage 노드의 디스크가 용량 4TB인 12개로 가정하고, 2개의 4TB 디스크를 RAID1 미러링으로 구성합니다. RAID1로 구성된 디스크에서 400GB를 할당하여 OS, SSVR 바이너리 및 컨트롤 파일을 저장합니다.

    OS 설치 후 남은 7.2TB를 각각 3.6TB로 나누고 각각 RAID 0으로 구성합니다. 따라서 RAID 1 미러링을 이용하여 OS를 설치한 공간을 제외하고, 3.6TB 디스크 2개, 나머지 4TB 디스크 10개를 이용하여 Storage 노드를 구성할 수 있습니다.

    다음은 설치 대상 공유 디스크를 준비하는 과정으로, 모든 Storage 노드에서 동일하게 수행합니다.

    Storage 노드의 각 디스크의 권한 또는 소유권을 변경해 직접 사용해도 되지만 재기동할 때 디스크 이름이 변경되는 문제가 발생할 수 있으므로 이러한 문제를 예방하기 위해 udev를 사용하여 Storage 노드의 디스크를 구성하는 방법을 권고합니다.

    아래는 udev에 대한 간단한 설명입니다.

    • udev는 시스템 소프트웨어와 연동하여 디바이스 이벤트 처리 및 디바이스 노드의 권한 관리, 네트워크 인터페이스의 이름 설정 또는 /dev 디렉터리에 심볼릭 링크를 추가할 수 있습니다.

    • 디바이스가 커널에 의해 감지되면, udev는 sysfs 디렉터리에서 시리얼 번호나 버스 디바이스 번호 등의 속성을 수집해 디바이스의 고유한 이름을 결정합니다. udev는 메이저와 마이너 번호를 기반으로 디바이스를 /sys 파일 시스템에서 추적하고, 시스템 메모리와 sysfs를 활용해 디바이스 정보를 관리합니다.

    • 모듈이 적재되거나 디바이스가 추가·제거될 때 커널이 이벤트를 발생시키면, udev는 규칙에 따라 디바이스 파일명 설정, 심볼릭 링크 생성, 파일 권한 설정 등을 수행합니다.

    아래는 udev를 사용하여 구성된 Storage 노드 디스크의 예입니다.

    위의 예에서 /dev/*로 나타나는 링크들은 udev rules에 따라 생성된 심볼릭 링크입니다.

    아래는 디스크를 구성하기 위한 udev rules 파일의 예입니다.

    udev rules 파일은 /etc/udev/rules.d 폴더 안에 .rules라는 확장자로 저장되어야 합니다.

    위 예시의 rule은, sda로 표현되는 커널 이름(KERNEL=="sda")을 가진 블록 디바이스(SUBSYSTEM=="block") 노드 중에서 명시된 SCSI_ID(ENV{ID_SERIAL}=="SCSI_ID")와 일치하는 디바이스를 찾아 소유자, 사용자 권한을 설정하고 주어진 심볼릭 링크를 생성하는 명령입니다.

    디바이스의 SCSI_ID는 /usr/lib/udev/scsi_id(RHEL9 기준)를 실행하면 확인할 수 있습니다. 시스템에 따라 /lib/udev/scsi_id를 대신하여 실행합니다. 이 프로그램은 관리자 권한으로 실행되어야 하며 아래는 scsi_id를 확인하는 예입니다.

    ZetaData의 정상적 구동을 위해 커널 파라미터를 설정합니다.

    커널 파라미터 설정 파일의 위치는 다음과 같습니다.

    아래는 커널 파라미터를 설정하는 예입니다.

    • 정의: 단일 공유 메모리 세그먼트에 할당할 수 있는 바이트 단위의 최댓값

    • 값 설정: SSVR 인스턴스에 할당할 전체 공유 메모리의 크기보다 여유롭게 설정

    • 정의: 시스템 전체에서 사용할 수 있는 공유 메모리의 총 페이지 수

    • 값 설정: SSVR 인스턴스를 기준으로 설정한 kernel.shmmax 값을 페이지 크기로 나눈 값 (사유: 일반적으로 시스템의 공유 메모리 자원을 SSVR 인스턴스가 대부분 사용)

    시스템의 페이지 크기는 아래 명령어를 사용해 확인합니다.

    • 정의: 시스템에서 동시에 처리할 수 있는 최대 비동기 I/O 요청 수

    • 값 설정: 실제 사용량을 모니터링한 적절한 값

    • 정의: 시스템에서 동시에 열 수 있는 최대 파일 디스크립터 수

    • 값 설정: 시스템의 규모에 따라 값을 조정

    • 정의: 프로세스당 가질 수 있는 메모리 매핑 개수의 최댓값

    • 값 설정: InfiniBand를 통한 RDMA를 사용할 때, 라이브러리 내부 자원 및 RDMA용 region 등록 과정에서 mmap이 빈번하게 일어나기 때문에 여유롭게 설정

    DB 노드와 Storage 노드 간 통신에 TCP 소켓을 사용할 경우에는 소켓 버퍼의 기본값과 최대 크기를 아래와 같이 설정합니다.

    아래는 SSVR 인스턴스를 사용하기 위한 환경변수입니다.

    환경변수
    설명

    ZetaData를 설치하기 위해 설정해야 하는 초기화 파라미터는 기본적으로 Tibero와 동일하며, 아래와 같은 파라미터의 추가 설정이 필요합니다.

    초기화 파라미터
    설명

    아래는 Storage 노드 0번의 SSVR 인스턴스 초기화 파라미터 설정 예입니다.

    MEMORY_TARGET 파라미터는 SSVR 인스턴스에서 사용할 메모리의 총량을 의미합니다.

    InfiniBand 라이브러리에서 connection에 사용되는 외부 메모리 사용량이 많으므로(connection 당 4MB) 사이트 담당 사업부나 기술지원에 문의 후 세팅을 권장합니다. 계산식은 아래와 같습니다.

    TOTAL_SHM_SIZE 파라미터는 SSVR 인스턴스에서 사용할 공유 메모리의 총량을 의미합니다.

    SSVR 인스턴스를 기동하는데 기본적으로 필요한 3GB와 디스크 1TB 당 150MB를 우선 합하고, 그 결과에 10GB 당 1GB에서 2GB의 기타 여유분을 더해 최솟값을 계산할 수 있습니다.

    tbSQL을 이용해 Tibero 인스턴스에 접속하기 위해서는 $TB_HOME/client/config/tbdsn.tbr 파일에 접속 정보를 설정해야 합니다. SSVR 인스턴스 설정 방법은 기본적으로 다른 Tibero 인스턴스와 같지만 DB_NAME은 필요하지 않습니다.

    아래는 $TB_HOME/client/config/tbdsn.tbr 파일 설정의 예입니다.

    아래 과정으로 SSVR 인스턴스를 구성합니다. (본 예에서는 Storage 노드 3대, DB 노드 2대로 구성합니다.)

    1. SSVR 인스턴스 생성과 기동

    2. 스토리지 디스크 생성

    3. 그리드 디스크 생성

    4. 플래시 캐시 생성

    아래는 $TB_HOME/config/$TB_SID.tip에 설정된 내용에 따라서 SSVR 인스턴스를 생성하는 과정입니다.

    초기화 파라미터의 내용을 확인하고, 그에 따른 control file을 생성합니다. SSVR 인스턴스를 nomount 모드로 기동하고 SSVR 인스턴스를 생성합니다. 생성 후에는 SSVR 인스턴스는 자동으로 종료(Shutdown)됩니다.

    SSVR 인스턴스를 다시 기동할 때에는 mount 모드로 기동합니다.

    스토리지 디스크(Storage Disk)는 SSVR 인스턴스에서 사용할 물리적 디스크입니다. Storage 노드의 디스크를 사용하기 위해 각각의 디스크를 SSVR 인스턴스의 스토리지 디스크로 등록합니다.

    아래의 명령어로 스토리지 디스크를 등록할 수 있습니다.

    파라미터
    설명

    OS와 SSVR 바이너리 파일 및 컨트롤 파일이 설치된 디스크는 4TB에서 400GB를 뺀 만큼을 스토리지 디스크 용량으로 설정합니다. 아래 예는 첫 번째 디스크에 설치된 것으로 가정하고 설명합니다.

    스토리지 디스크 정보는 V$SSVR_STORAGE_DISK 뷰를 통해서 조회할 수 있습니다.

    그리드 디스크(Grid Disk)는 SSVR 인스턴스의 외부에서 보이는 디스크이며, 반드시 하나의 스토리지 디스크에 포함되도록 구성합니다.

    아래의 명령어로 그리드 디스크를 등록할 수 있습니다.

    파라미터
    설명

    아래는 size 옵션을 생략하여 등록된 스토리지 디스크의 최대 가용량을 사용하여 그리드 디스크를 생성하는 예입니다.

    그리드 디스크 정보는 V$SSVR_GRID_DISK 뷰를 통해서 조회할 수 있습니다.

    아래의 명령어로 플래시 디바이스를 캐시로 등록해 I/O 속도를 향상시킬 수 있습니다.

    파라미터
    설명

    아래는 경로가 '/dev/flash'이고 플래시 장치의 시작번호는 0, 장치개수는 4, 플래시 장치의 크기는 1490GiB인 플래시 캐시를 생성하는 예입니다. 플래시 캐시 생성 후 SSVR 인스턴스를 재기동하기 전까지는 플래시 캐시가 사용되지 않습니다. 플래시 캐시 사용을 위해서 SSVR 인스턴스를 재기동합니다.

    플래시 캐시 정보는 V$SSVR_FLASHCACHE 뷰를 통해서 조회할 수 있습니다.

    본 절에서는 TAS와 TAC에서 SSVR 인스턴스를 사용하여 디스크 스페이스, 테이블 스페이스를 생성하고 DB를 설치하는 방법을 기술합니다.

    TAS 인스턴스와 TAC 인스턴스에서 SSVR 인스턴스를 사용하기 위해 SSVR 인스턴스 접속 정보를 설정합니다. $TB_HOME/client/config/ssdsn.tbr 파일에 통신에 사용할 Storage 노드의 네트워크 IP 주소와 SSVR 인스턴스의 포트 정보를 기록합니다. 이 SSVR 인스턴스 접속 정보는 TAS와 TAC 인스턴스가 설치된 모든 노드에 설정이 필요합니다.

    아래는 $TB_HOME/client/config/ssdsn.tbr 파일의 예입니다.

    항목
    설명

    아래의 과정을 통해 먼저 TAS 인스턴스를 설정하고, SSVR의 그리드 디스크를 활용하여 디스크 스페이스(DiskSpace)를 생성합니다.

    이후 CM 인스턴스를 구축한 뒤, 이를 TAS 인스턴스와 연동해 TAC 인스턴스를 클러스터로 운영할 수 있습니다.

    1. tbSQL 사용을 위한 접속 정보 설정

    2. DB 노드 0번 TAS 인스턴스 구성 및 디스크 스페이스 생성

    3. DB 노드 0번 CM 인스턴스 구성

    4. DB 노드 0번 CM, TAS 인스턴스 기동

    아래는 tbSQL을 이용해 SSVR 인스턴스와 TAS, TAC 인스턴스에 접속하기 위한 $TB_HOME/client/config/tbdsn.tbr 파일의 예입니다.

    TAS 인스턴스는 $TB_HOME/client/config/ssdsn.tbr 파일에 기록된 SSVR 인스턴스의 접속 정보를 통해 SSVR 인스턴스에 접속하며, SSVR에 생성되어 있는 그리드 디스크 이름을 통해 각각의 디스크를 구분합니다.

    TAS 인스턴스는 "-"로 시작하는 파일 경로를 SSVR의 그리드 디스크로 인식하며 디스크 스페이스 생성, 디스크 추가/삭제 등 모든 경우에 해당 경로를 사용할 수 있습니다.

    아래는 TAS 인스턴스의 초기화 파라미터와 설정 예입니다.

    초기화 파라미터
    설명

    아래는 SSVR 인스턴스의 그리드 디스크를 이용해 디스크 스페이스를 생성하는 과정의 예입니다.

    AU(Allocation Unit)는 할당 단위를 나타내는 값으로 설정 가능한 할당 단위의 크기는 4MB입니다. 디스크의 striping 단위와 TAS의 striping 단위가 배수 관계여야 배열이 맞아 성능 향상이 있습니다.

    디스크 스페이스 정보는 V$AS_DISKSPACE 뷰를 통해서 조회할 수 있습니다.

    CM 인스턴스는 네트워크와 클러스터를 등록하고 TAS와 TAC를 서비스로 등록하여 안정적인 클러스터 운영을 돕습니다.

    아래는 CM의 초기화 파라미터 설정 예시로, 자세한 내용은 ""를 참고합니다.

    아래는 CM 인스턴스를 기동하고 나서 CM에 네트워크 등록, 클러스터 등록, 클러스터 기동, TAS 서비스 등록, TAS 인스턴스 등록, TAS 인스턴스 기동 과정의 예입니다.

    아래는 DB 노드 0번 TAS 인스턴스에서 DB 노드 1번 TAS를 추가하는 과정의 예입니다.

    아래는 DB 노드 1번 TAS 인스턴스 초기화 파라미터 설정 예입니다.

    아래는 DB 노드 1번 CM 인스턴스의 초기화 파라미터 설정의 예입니다.

    아래는 DB 노드 1번 CM 인스턴스를 기동하고 네트워크 등록, 클러스터 등록, 클러스터 기동, TAS 서비스 등록, TAS 인스턴스 등록, TAS 인스턴스 기동 과정의 예입니다.

    TAC 인스턴스는 $TB_HOME/client/config/ssdsn.tbr 파일에 기록된 SSVR 인스턴스 접속 정보를 통해 SSVR 인스턴스에 접속합니다. TAC 인스턴스는 "+"로 시작하는 파일 경로를 TAS 인스턴스에 의해 관리되는 가상 파일로 인식합니다. 해당 경로는 컨트롤 파일, CM 파일을 포함한 모든 파일의 경로에 사용할 수 있습니다.

    아래는 TAS를 이용해 DB 노드 0번 TAC 인스턴스를 클러스터로 구성하는 경우에 대한 초기화 파라미터의 예입니다. 'DB_BLOCK_SIZE=32K' 파라미터는 수정하지 않습니다.

    MEMORY_TARGET 파라미터는 TAC 인스턴스에서 사용할 메모리의 총량을 의미합니다.

    InfiniBand 라이브러리에서 connection에 사용되는 외부 메모리 사용량이 많으므로(connection 당 4MB) 사이트 담당 사업부나 기술지원에 문의 후 세팅을 권장합니다.

    계산식은 아래와 같습니다.

    아래는 이전 단계에서 기동했던 DB 노드 0번 CM 인스턴스에 TAC 서비스를 등록하고 TAC 인스턴스를 등록하는 과정의 예입니다.

    아래는 DB 노드 0번 TAC 인스턴스를 nomount 모드로 기동하여 TAS 인스턴스의 디스크 스페이스를 이용해 데이터베이스를 생성하는 과정의 예입니다. 생성 후에는 자동으로 종료되므로 재기동합니다.

    아래는 DB Node 1번 TAC 인스턴스를 기동하기 위해 DB 노드 0번 TAC 인스턴스에서 추가 구성하는 예입니다.

    다음은 DB 노드 1번 TAC 인스턴스 초기화 파라미터 설정 예입니다. 'DB_BLOCK_SIZE=32K'는 수정하지 않습니다.

    MEMORY_TARGET 파라미터는 TAC 인스턴스에서 사용할 메모리의 총량을 의미합니다.

    InfiniBand 라이브러리에서 connection에 사용되는 외부 메모리 사용량이 많으므로(connection 당 4MB) 사이트 담당사업부나 기술지원에 문의 후 세팅을 권장합니다.

    계산식은 아래와 같습니다.

    아래는 이전 단계에서 기동했던 DB 노드 1번 CM 인스턴스에 TAC 인스턴스를 등록하고 기동하는 과정의 예입니다.

    위의 과정들을 통해 3대의 SSVR 노드, 2대의 DB 노드에 각각 SSVR 인스턴스, TAS 인스턴스, TAC 인스턴스를 구성합니다.

    SSVR 인스턴스 정보를 조회하기 위해 다음의 뷰들을 사용할 수 있습니다. 해당 뷰들은 SSVR 인스턴스에서만 조회할 수 있습니다.

    뷰
    설명

    V$SSVR_CLIENT 뷰는 SSVR 인스턴스가 커넥션을 맺고 있는 모든 클라이언트 정보를 보여줍니다.

    컬럼
    데이터 타입
    설명

    아래는 V$SSVR_CLIENT 조회 예입니다.

    V$SSVR_FLASHCACHE 뷰는 SSVR 인스턴스에 연결된 모든 플래시 캐시 정보를 보여줍니다.

    컬럼
    데이터 타입
    설명

    V$SSVR_GRID_DISK 뷰는 SSVR 인스턴스에 연결된 모든 그리드 디스크 정보를 보여줍니다.

    컬럼
    데이터 타입
    설명

    V$SSVR_STORAGE_DISK 뷰는 SSVR 인스턴스에 연결된 모든 스토리지 디스크 정보를 보여줍니다.

    컬럼
    데이터 타입
    설명

    V$SSVR_SLAB_STAT 뷰는 SSVR 인스턴스가 현재 사용하고 있는 SLAB 정보를 보여줍니다.

    컬럼
    데이터 타입
    설명

    아래는 V$SSVR_SLAB_STAT 조회 예입니다.

    V$SSVR_MEMSTAT 뷰는 SSVR 인스턴스의 메모리 사용 정보를 보여줍니다. (단위는 MB)

    컬럼
    데이터 타입
    설명

    아래는 V$SSVR_MEMSTAT 조회 예입니다.

    SSVR_USE_FC

    플래시 캐시를 사용할지 여부를 나타내는 파라미터입니다. (기본값: Y)

    SSVR_USE_SDM

    스토리지 데이터 맵을 사용할지 여부를 나타내는 파라미터입니다. (기본값: Y)

    SSVR_USE_AGNT

    에이전트 프로세스를 활성화할지 여부를 나타내는 파라미터입니다. 에이전트 프로세스는 내부 작업 등을 관리하거나 보조하는 역할을 합니다. TPM(Tibero Performance Monitor) 관련 성능 지표를 수집하고 전송하는 역할도 합니다. (기본값: N)

    SSVR_USE_TPM

    TPM을 활성화할지 여부를 나타내는 파라미터입니다. (기본값: N)

    SSVR_TPM_SENDER_INTERVAL

    TPM을 활성화한 경우 송신자 연결 상태 확인 간격을 설정합니다. (기본값: 50)

    SSVR_WTHR_CNT

    SSVR 인스턴스에서 I/O를 수행하는데 사용할 Working Thread의 개수를 나타냅니다. 별도로 설정하지 않은 경우 CPU 개수에 비례해 자동으로 지정되므로 설정하지 않아도 됩니다.

    (범위: SSVR_WTHR_CNT > 0)

    INSTANCE_TYPE

    인스턴스의 종류를 나타내며 각각 인스턴스에 맞게 설정합니다.

    • TAS 인스턴스 : AS

    • SSVR 인스턴스 : SSVR

    USE_ZETA

    ZetaData를 위한 구성을 합니다. 별도로 설정하지 않은 경우 INSTANCE_TYPE 파라미터 값이 "SSVR"일 때만 "Y"로 설정됩니다.

    size {grid-disk-size}

    SSVR 인스턴스에 등록할 그리드 디스크의 크기입니다. 기본 단위는 바이트이며 K(KiB), M(MiB), G(GiB), T(TiB), P(PiB), E(EiB)로 단위를 붙여 사용할 수 있습니다. 스토리지 디스크의 가용량보다 크지 않아야 합니다. 옵션 파라미터이며 명시하지 않는 경우 명시한 스토리지 디스크의 총 용량 이하 32KB의 최대 배수값이 들어갑니다.

    DB 노드 0번 TAS 인스턴스에서 DB 노드 1번 TAS 추가

  • DB 노드 1번 TAS, CM 인스턴스 구성 및 기동

  • DB 노드 0번 TAC 인스턴스 구성 및 기동

  • DB 노드 0번 TAC 인스턴스에서 DB 노드 1번 TAC 추가

  • DB 노드 1번 TAC 인스턴스 기동

  • V$SSVR_STORAGE_DISK

    SSVR 인스턴스에 연결된 스토리지 디스크(Storage Disk) 정보를 조회합니다.

    V$SSVR_SLAB_STAT

    SSVR 인스턴스에서 사용 중인 SLAB 정보를 조회합니다.

    V$SSVR_MEMSTAT

    SSVR 인스턴스에서 사용 중인 메모리 정보를 조회합니다.

    NAME

    VARCHAR(128)

    클라이언트의 이름입니다.

    THREAD_NUMBER

    NUMBER

    클라이언트와의 커넥션을 담당하는 Thread number입니다.

    PATH

    VARCHAR(256)

    플래시 캐시의 경로입니다.

    OS_BYTES

    NUMBER

    OS가 인식하는 플래시 캐시의 크기입니다.

    STORAGE_DISK_NUMBER

    NUMBER

    그리드 디스크와 매핑되어 있는 스토리지 디스크 의 번호입니다.

    STORAGE_DISK_OFFSET

    NUMBER

    그리드 디스크와 매핑되어 있는 스토리지 디스크의 offset입니다.

    TOTAL_BYTES

    NUMBER

    그리드 디스크의 크기입니다.

    PATH

    VARCHAR(256)

    스토리지 디스크의 경로입니다.

    OS_BYTES

    NUMBER

    OS가 인식하는 스토리지 디스크의 크기입니다.

    TOTAL_CHUNK_CNT_NUMBER

    NUMBER

    청크(Chunk)의 총량입니다.

    MAX_CHUNK_CNT

    NUMBER

    청크의 가능한 최대 개수입니다.

    USED_PGA_MEMORY_MB

    VARCHAR(128)

    사용한 프로세스 메모리 크기입니다.

    TOTAL_SHARED_MEMORY_MB

    NUMBER

    공유 메모리 총 크기입니다.

    FIXED_SHARED_MEMORY_MB

    NUMBER

    고정 공유 메모리 크기입니다.

    USED_SHARED_MEMORY_MB

    NUMBER

    사용한 공유 메모리 크기입니다.

    96GB

    디스크 구성

    2TB NVMe x 4

    4TB HDD x 12, 2TB NVMe x 4

    $TB_HOME

    SSVR 인스턴스가 설치된 홈 디렉터리입니다.

    $TB_SID

    SSVR 인스턴스를 구분하는 서비스 ID입니다.

    SSVR_RECV_PORT_START

    SSVR 인스턴스가 사용할 포트들의 시작 번호를 설정합니다.

    (범위: 1024 - 65535)

    SSVR_USE_TCP

    RDMA 프로토콜 대신 TCP 프로토콜을 사용하고자 하는 경우에 "Y"로 설정합니다. TAS 인스턴스와 TAC 인스턴스의 초기화 파라미터에도 동일하게 설정합니다. (기본값: N)

    SSVR_USE_IB

    RDMA 프로토콜을 사용하고자 하는 경우에 "Y"로 설정합니다. "Y"로 설정한 경우 USE_ZETA 파라미터 값이 "Y"이어야 합니다. 별도로 설정하지 않은 경우 SSVR_USE_TCP 파라미터의 반대값으로 설정 됩니다.

    storage disk

    {storage-disk-name}

    SSVR 인스턴스에 등록할 스토리지 디스크 이름입니다. 각 SSVR 인스턴스 내에서만 고유한 이름을 가지면 됩니다.

    path {path}

    Storage 노드의 디스크 경로입니다.

    size {storage-disk-size}

    SSVR에 등록할 스토리지 디스크의 크기입니다. 기본 단위는 바이트이며 K(KiB), M(MiB), G(GiB), T(TiB), P(PiB), E(EiB)로 단위를 붙여 사용할 수 있습니다.

    스토리지 디스크의 용량 단위는1T(TiB)=1024G(GiB)입니다. fdisk 명령어로 확인하는 디스크의 용량은 1TB=1000GB로 계산되므로 용량을 1T=1024G단위로 계산하여 스토리지 디스크들의 크기를 설정해야 합니다.

    옵션 파라미터이며 명시하지 않은 경우 디바이스의 총 용량이 들어갑니다.

    grid disk {grid-disk-name}

    SSVR 인스턴스에 등록할 그리드 디스크 이름입니다. 각 SSVR 인스턴스 내에서만 고유한 이름을 가지면 됩니다.

    storage disk

    {storage-disk-name}

    SSVR 인스턴스에 등록된 스토리지 디스크 이름입니다. V$SSVR_STORAGE_DISK 뷰를 통해서 이름을 조회할 수 있습니다.

    offset {offset}

    스토리지 디스크의 오프셋을 입력할 수 있습니다. 옵션 파라미터이며 사용하지 않는 것을 권장합니다. 사용하려면 32KB의 배수로 설정해야 합니다.

    path {path}

    플래시 장치명의 prefix입니다.

    예를 들어 /dev/flash0, /dev/flash1, /dev/flash2, /dev/flash4 4개의 플래시 장치가 있으면 '/dev/flash'에 해당됩니다.

    size {flashcache-size}

    플래시 장치들의 크기입니다. 기본 단위는 바이트이며 K(KiB), M(MiB), G(GiB), T(TiB), P(PiB), E(EiB)로 단위를 붙여 사용할 수 있습니다.

    플래시 장치의 용량 단위는 1T(TiB)=1024G(GiB)입니다. fdisk 명령어로 확인하 는 플래시 장치의 용량은 1TB=1000GB로 계산되므로 용량을 1TiB=1024GiB 단위로 계산하여 플래시 장치들의 크기를 설정해야 합니다.

    옵션 파라미터이며 명시하지 않는 경우 디바이스의 총 용량이 들어갑니다.

    현재 동일한 크기의 플래시 장치들을 지원하게 되어 있습니다. 모든 플래시 장치들의 크기의 합이 아니라 각각의 플래시 장치들의 크기를 설정해야 한다는 점을 주의합니다.

    {storage node IP}

    사용할 Storage 노드의 IP 주소입니다.

    {port}

    사용할 SSVR 인스턴스의 포트 번호를 나타내며, SSVR 인스턴스 초기화 파라미터 중 SSVR_RECV_PORT_START에 해당합니다. Storage 노드 IP 뒤에 "/"로 구분한 뒤 설정합니다.

    AS_SCAN_SSVR_DISK

    TAS tip에 기재하는 초기화 파라미터로 SSVR 인스턴스의 디스크 사용 여부를 나타냅니다. 별도 변경 없을 시 "N"으로 설정되므로 ZetaData를 사용하는 경우에는 TAS tip에 반드시 "Y"로 명시합니다.

    V$SSVR_CLIENT

    SSVR 인스턴스가 커넥션을 맺고 있는 클라이언트를 조회합니다.

    V$SSVR_FLASHCACHE

    SSVR 인스턴스에 연결된 플래시 캐시(Flash Cache) 정보를 조회합니다.

    V$SSVR_GRID_DISK

    SSVR 인스턴스에 연결된 그리드 디스크(Grid Disk) 정보를 조회합니다.

    ADDRESS

    VARCHAR(20)

    클라이언트의 주소입니다.

    PORT

    NUMBER

    클라이언트와 커넥션이 되어있는 포트 번호입니다.

    FLASHCACHE_NUMBER

    NUMBER

    플래시 캐시의 번호입니다.

    NAME

    VARCHAR(32)

    플래시 캐시의 이름입니다.

    GRID_DISK_NUMBER

    NUMBER

    그리드 디스크의 번호입니다.

    NAME

    VARCHAR(128)

    그리드 디스크의 이름입니다.

    STORAGE_DISK_NUMBER

    NUMBER

    스토리지 디스크의 번호입니다.

    NAME

    VARCHAR(128)

    스토리지 디스크의 이름입니다.

    SLAB_SIZE

    NUMBER

    SLAB의 크기입니다.

    SLAB_GET_CNT

    NUMBER

    SLAB의 개수입니다.

    TOTAL_PGA_MEMORY_MB

    NUMBER

    프로세스 메모리 총 크기입니다.

    FIXED_PGA_MEMORY_MB

    NUMBER

    고정 프로세스 메모리 크기입니다.

    참고

    DB 노드는 고성능 CPU와 충분한 메모리가 필수적이며, 디스크는 OS 저장 용도로만 주로 사용됩니다. 반면, Storage 노드는 데이터 저장과 제공에 중점을 두기 때문에 디스크 용량과 속도가 더욱 중요한 요소로 작용합니다. 동일 비용이라면, DB 노드에는 CPU와 메모리에 Storage 노드는 디스크와 플래시 디바이스에 초점을 두어 구성하는 것이 좋습니다.

    RAID 설치

    RAID 기능을 사용하지 않고 OS를 설치하는 경우

    RAID 기능을 사용하여 OS를 설치하는 경우

    Storage 노드 디스크 설정

    커널 파라미터 설정

    kernel.shmmax 파라미터

    kernel.shmall 파라미터

    fs.aio-max-nr 파라미터

    fs.file-max 파라미터

    vm.max_map_count 파라미터

    주의

    Storage 노드의 경우, HugePages 사용은 메모리를 사용하지 못하는 역효과를 초래하므로 설정하지 않도록 주의합니다.

    환경변수

    참고

    SSVR 인스턴스에서 사용하는 환경변수는 Tibero와 동일합니다.

    자세한 내용은 "Tibero 설치 안내서"의 "멀티 인스턴스 설치와 제거"에 "Unix 환경"을 참고합니다.

    초기화 파라미터

    주의

    “커널 파라미터 설정”에서 설정한 kernel.shmmax 값(단위: bytes)이 TOTAL_SHM_SIZE 값보다 커야 합니다.

    tbSQL 사용을 위한 접속 정보

    SSVR 인스턴스 구성

    1. SSVR 인스턴스 생성과 기동

    주의

    SSVR 인스턴스는 nomount 모드 기동과 mount 모드 기동만 허용합니다.

    2. 스토리지 디스크 생성

    3. 그리드 디스크 생성

    4. 플래시 캐시 생성

    참고

    위와 동일한 설정으로, 다른 두개의 SSVR 인스턴스를 추가로 구성합니다.

    본 예에서 세 개의 SSVR 인스턴스를 이용하여 디스크 스페이스를 생성할 것입니다.

    다른 두 개의 SSVR 인스턴스에도 스토리지 디스크, 그리드 디스크, 플래시 캐시를 구성합니다.

    TAS/TAC 인스턴스 구성

    SSVR 인스턴스 접속 정보

    설정 항목

    TAS/TAC 설정

    참고

    DB 노드 1번 TAS 인스턴스 기동과 TAC 인스턴스 기동은 DB 노드 0번 TAS 인스턴스 추가와 TAC 인스턴스 추가 이후에 수행한다면 순서와 무관합니다.

    1. tbSQL 사용을 위한 접속 정보 설정

    2. DB 노드 0번 TAS 인스턴스 구성 및 디스크 스페이스 생성

    참고

    디스크 스페이스 생성의 자세한 설명은 "Tibero Active Storage 관리자 안내서"의 "TAS 기동"을 참고합니다.

    참고

    REDUNDANCY 관리는 FAILGROUP 단위로 이뤄집니다. 따라서, 동시에 장애가 발생할 가능성이 높은 SSVR 인스턴스 단위로 FAILGROUP을 구성하는 것을 권장합니다.

    주의

    AU_SIZE가 '4M'가 아닐 경우 플래시 캐시의 효과를 제대로 볼 수 없으므로 반드시 '4M'로 설정합니다.

    3. DB 노드 0번 CM 인스턴스 구성

    4. DB 노드 0번 CM, TAS 인스턴스 기동

    주의

    반드시 이전 단계 'DB 노드 0번 TAS 인스턴스 구성 및 디스크 스페이스 생성'을 진행하고 아래 과정을 실행합니다.

    5. DB 노드 0번 TAS 인스턴스에서 DB 노드 1번 TAS 추가

    6. DB 노드 1번 TAS, CM 인스턴스 구성 및 기동

    7. DB 노드 0번 TAC 인스턴스 구성 및 기동

    주의

    플래시 캐시에는 32K 블록만 적재되므로 이를 수정하면 플래시 캐시 사용이 불가능합니다.

    따라서, TAC 인스턴스들의 DB_BLOCK_SIZE는 반드시 32K로 설정해야 합니다.

    8. DB 노드 0번 TAC 인스턴스에서 DB 노드 1번 TAC 추가

    9. DB 노드 1번 TAC 인스턴스 기동

    참고

    TAS 인스턴스와 TAC 인스턴스에서 SSVR 인스턴스를 사용하기 위해서는 앞서 설명한 접속 정보 이외에 별도의 설정이 필요하지 않습니다.

    TAS와 TAC의 설치 및 환경 설정에 관한 자세한 사항은 "Tibero Active Storage 관리자 안내서"와 "Tibero 관리자 안내서"를 참고합니다.

    SSVR 인스턴스 정보 조회

    V$SSVR_CLIENT

    V$SSVR_FLASHCACHE

    참고

    V$SSVR_FLASHCACHE 조회 예는 “플래시 캐시 생성”을 참고합니다.

    V$SSVR_GRID_DISK

    참고

    V$SSVR_GRID_DISK 조회 예는 “그리드 디스크 생성”을 참고합니다.

    V$SSVR_STORAGE_DISK

    참고

    V$SSVR_STORAGE_DISK 조회 예는 “스토리지 디스크 생성”을 참고합니다.

    V$SSVR_SLAB_STAT

    V$SSVR_MEMSTAT

    Tibero 관리자 안내서
    $ grep MemTotal /proc/meminfo 
    MemTotal: 98707668 kB
    $ fdisk -l
    Disk /dev/sdd: 4000.8 GB, 4000753475584 bytes, 7813971632 sectors 
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes 
    I/O size (minimum/optimal): 262144 bytes / 262144 bytes 
    Disk label type: dos
    Disk identifier: 0x00000000
    ...
    $ ls -al /dev
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk0 -> sda
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk1 -> sdb
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk2 -> sdc
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk3 -> sdd
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk4 -> sde
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk5 -> sdf
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk6 -> sdg
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk7 -> sdh
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk8 -> sdi
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk9 -> sdj
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk10 -> sdk
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/disk11 -> sdl
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/flash0 -> nvme0n1
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/flash1 -> nvme1n1
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/flash2 -> nvme2n1
    lrwxrwxrwx. 1 root root 3 Aug 13 19:50 /dev/flash3 -> nvme3n1
    
    $ cat /etc/udev/rules.d/zetadisk.rules
    KERNEL=="sdb", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="3600508b1001cdc32750", \
    SYMLINK+="disk0", OWNER="zeta", MODE="0600"
    
    KERNEL=="sdc", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="3600508b1001cdc32751", \
    SYMLINK+="disk1", OWNER="zeta", MODE="0600"
    
    KERNEL=="sdd", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="3600508b1001cdc32752", \
    SYMLINK+="disk2", OWNER="zeta", MODE="0600"
    
    KERNEL=="sde", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="3600508b1001cdc32753", \
    SYMLINK+="disk3", OWNER="zeta", MODE="0600"
    
    KERNEL=="sdf", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="3600508b1001cdc32754", \
    SYMLINK+="disk4", OWNER="zeta", MODE="0600"
    
    KERNEL=="sdg", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="3600508b1001cdc32755", \
    SYMLINK+="disk5", OWNER="zeta", MODE="0600"
    
    KERNEL=="sdh", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="3600508b1001cdc32756", \
    SYMLINK+="disk6", OWNER="zeta", MODE="0600"
    
    KERNEL=="sdi", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="3600508b1001cdc32757", \
    SYMLINK+="disk7", OWNER="zeta", MODE="0600"
    
    KERNEL=="sdj", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="3600508b1001cdc32758", \
    SYMLINK+="disk8", OWNER="zeta", MODE="0600"
    
    KERNEL=="sdk", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="3600508b1001cdc32759", \
    SYMLINK+="disk9", OWNER="zeta", MODE="0600"
    
    KERNEL=="sdl", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="3600508b1001cdc32710", \
    SYMLINK+="disk10", OWNER="zeta", MODE="0600"
    
    KERNEL=="nvme0n1", SYMLINK+="flash0", OWNER="zeta", MODE="0600"
    KERNEL=="nvme1n1", SYMLINK+="flash1", OWNER="zeta", MODE="0600"
    KERNEL=="nvme2n1", SYMLINK+="flash2", OWNER="zeta", MODE="0600"
    KERNEL=="nvme3n1", SYMLINK+="flash3", OWNER="zeta", MODE="0600"
    
    $ /usr/lib/udev/scsi_id --whitelisted --device=/dev/sda 
    3600508b1001cdc32750
    /etc/sysctl.conf
    kernel.sem = 100000 100000 100000 100000
    kernel.shmmax = 17179869184
    kernel.shmall = 24718805
    fs.aio-max-nr = 4194304
    fs.file-max = 8388608
    vm.max_map_count = 262144
    $ getconf PAGE_SIZE 
    4096
    net.core.rmem_default = 4194304
    net.core.wmem_default = 4194304
    net.core.rmem_max = 67108864
    net.core.wmem_max = 67108864
    # ssvr0.tip 
    INSTANCE_TYPE=SSVR 
    LISTENER_PORT=9100
    CONTROL_FILES="/home/tibero/zetadata/database/ssvr0/c1.ctl"
    
    TOTAL_SHM_SIZE=15G 
    MEMORY_TARGET=70G
    
    SSVR_RECV_PORT_START=9110
    SSVR 인스턴스 기준
    MEMORY_TARGET = (전체 메모리양)
                    - [(DB 노드 개수) 
                        * {(TAC 인스턴스의 Max Session Count)
                            + (TAC 인스턴스의 PEP thread 전체 개수)}] * 4MB
                    - 10GB(=OS 및 타 thread의 connection 여유분)
    ** (TAC 인스턴스의 PEP thread 전체 개수) = (TAC 인스턴스의 PEP Process 개수)
                                            * (PEP process 당 thread 개수)
    ** TAC 인스턴스의 PEP thread 전체 개수 계산은 하나의 TAC 인스턴스를 기준으로 함.
    ssvr0=((INSTANCE=(HOST=10.10.10.13)(PORT=9100))) 
    ssvr1=((INSTANCE=(HOST=10.10.10.14)(PORT=9100))) 
    ssvr2=((INSTANCE=(HOST=10.10.10.15)(PORT=9100))) 
    tas0=((INSTANCE=(HOST=10.10.10.11)(PORT=9120))) 
    tas1=((INSTANCE=(HOST=10.10.10.12)(PORT=9120)))
    tac0=((INSTANCE=(HOST=10.10.10.11)(PORT=9150)(DB_NAME=TAC))) 
    tac1=((INSTANCE=(HOST=10.10.10.12)(PORT=9150)(DB_NAME=TAC)))
    $ export TB_SID=ssvr0
    $ tbboot -t nomount
    Listener port = 9100
    
    Tibero 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    Tibero instance started up (NOMOUNT mode).
    $ tbsql sys/tibero
    
    tbSQL 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
    
    Connected to Tibero.
    
    SQL> create storage server;
     created.
    $ tbboot -t mount
    Listener port = 9100 
    
    Tibero 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    Tibero instance started up (MOUNT mode).
    create storage disk {storage-disk-name} path {path} size {storage-disk-size}
    $ tbsql sys/tibero
    
    tbSQL 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
    
    Connected to Tibero.
    
    SQL> create storage disk SD00 path '/dev/disk0' size 3350G;
     created.
    SQL> create storage disk SD01 path '/dev/disk1' size 3725G;
     created.
    SQL> create storage disk SD02 path '/dev/disk2' size 3725G;
     created.
    SQL> create storage disk SD03 path '/dev/disk3' size 3725G;
     created.
    SQL> create storage disk SD04 path '/dev/disk4' size 3725G;
     created.
    SQL> create storage disk SD05 path '/dev/disk5' size 3725G;
     created.
    SQL> create storage disk SD06 path '/dev/disk6' size 3725G;
     created.
    SQL> create storage disk SD07 path '/dev/disk7' size 3725G;
     created.
    SQL> create storage disk SD08 path '/dev/disk8' size 3725G;
     created.
    SQL> create storage disk SD09 path '/dev/disk9' size 3725G;
     created.
    SQL> create storage disk SD10 path '/dev/disk10' size 3725G;
     created.
    SQL> create storage disk SD11 path '/dev/disk11' size 3725G;
     created.
    SQL> select * from v$ssvr_storage_disk;
    
    STORAGE_DISK_NUMBER NAME PATH OS_BYTES
    ------------------- ------ ----------- ---------
                      0 SD00 /dev/disk0 4.000E+12
                      1 SD01 /dev/disk1 4.000E+12
                      2 SD02 /dev/disk2 4.000E+12
                      3 SD03 /dev/disk3 4.000E+12
                      4 SD04 /dev/disk4 4.000E+12
                      5 SD05 /dev/disk5 4.000E+12
                      6 SD06 /dev/disk6 4.000E+12
                      7 SD07 /dev/disk7 4.000E+12
                      8 SD08 /dev/disk8 4.000E+12
                      9 SD09 /dev/disk9 4.000E+12
                     10 SD10 /dev/disk10 4.000E+12
                     11 SD11 /dev/disk11 4.000E+12
    create grid disk {grid-disk-name} storage disk {storage-disk-name} \ 
       offset {offset} size {grid-disk-size}
    SQL> create grid disk GD00 storage disk SD00;
     created.
    SQL> create grid disk GD01 storage disk SD01;
     created.
    SQL> create grid disk GD02 storage disk SD02;
     created.
    SQL> create grid disk GD03 storage disk SD03;
     created.
    SQL> create grid disk GD04 storage disk SD04;
     created.
    SQL> create grid disk GD05 storage disk SD05;
     created.
    SQL> create grid disk GD06 storage disk SD06;
     created.
    SQL> create grid disk GD07 storage disk SD07;
     created.
    SQL> create grid disk GD08 storage disk SD08;
     created.
    SQL> create grid disk GD09 storage disk SD09;
     created.
    SQL> create grid disk GD10 storage disk SD10;
     created.
    SQL> create grid disk GD11 storage disk SD11;
     created.
    SQL> select * from v$ssvr_grid_disk;
    
    GRID_DISK_NUMBER NAME STORAGE_DISK_NUMBER STORAGE_DISK_OFFSET TOTAL_BYTES
    ---------------- ------ ------------------- ------------------- -----------
                   0 GD00                     0                   0 4.000E+12
                   1 GD01                     1                   0 4.000E+12
                   2 GD02                     2                   0 4.000E+12
                   3 GD03                     3                   0 4.000E+12
                   4 GD04                     4                   0 4.000E+12
                   5 GD05                     5                   0 4.000E+12
                   6 GD06                     6                   0 4.000E+12
                   7 GD07                     7                   0 4.000E+12
                   8 GD08                     8                   0 4.000E+12
                   9 GD09                     9                   0 4.000E+12
                  10 GD10                    10                   0 4.000E+12
                  11 GD11                    11                   0 4.000E+12
    create flashcache {name} path {path} size {flashcache-size}
    SQL> create flashcache flash0 path '/dev/flash0' size 1490G;
     created.
    SQL> create flashcache flash1 path '/dev/flash1' size 1490G;
     created.
    SQL> create flashcache flash2 path '/dev/flash2' size 1490G;
     created.
    SQL> create flashcache flash3 path '/dev/flash3' size 1490G;
     created. 
    SQL> quit 
    Disconnected.
    
    $ tbdown
    
    Tibero instance terminated (NORMAL mode).
    
    $ tbboot -t mount
    Listener port = 9100 
    
    Tibero 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    Tibero instance started up (MOUNT mode).
    SQL> select * from v$ssvr_flashcache;
    FLASHCACHE_NUMBER NAME   PATH        OS_BYTES
    ----------------- ------ ----------- ---------
                    0 FC0    /dev/flash0 1.600E+12
                    1 FC1    /dev/flash1 1.600E+12
                    2 FC2    /dev/flash2 1.600E+12
                    3 FC3    /dev/flash3 1.600E+12
    
    # Example
    # {storage node #0 IP}/{port} 
    # {storage node #1 IP}/{port} 
    # {storage node #2 IP}/{port} 
    10.10.10.13/9110
    10.10.10.14/9110
    10.10.10.15/9110
    ssvr0=((INSTANCE=(HOST=10.10.10.13)(PORT=9100)))
    ssvr1=((INSTANCE=(HOST=10.10.10.14)(PORT=9100)))
    ssvr2=((INSTANCE=(HOST=10.10.10.15)(PORT=9100)))
    tas0=((INSTANCE=(HOST=10.10.10.11)(PORT=9120)))
    tas1=((INSTANCE=(HOST=10.10.10.12)(PORT=9120)))
    tac0=((INSTANCE=(HOST=10.10.10.11)(PORT=9150)(DB_NAME=TAC)))
    tac1=((INSTANCE=(HOST=10.10.10.12)(PORT=9150)(DB_NAME=TAC)))
    # tas0.tip
    INSTANCE_TYPE=AS
    LISTENER_PORT=9120
    
    TOTAL_SHM_SIZE=4G
    MEMORY_TARGET=5G
    
    CLUSTER_DATABASE=Y
    LOCAL_CLUSTER_ADDR=10.10.10.11
    LOCAL_CLUSTER_PORT=9130
    CM_PORT=9140
    
    THREAD=0
    DB_BLOCK_SIZE=4K
    
    AS_SCAN_SSVR_DISK=Y
    USE_ZETA=Y
    $ export TB_SID=tas0
    $ tbboot -t nomount
    Listener port = 9120
    
    Tibero 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    Tibero instance started up (NOMOUNT mode).
    $ tbsql sys/tibero
    
    tbSQL 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
    
    Connected to Tibero.
    
    SQL> create diskspace DS0 normal redundancy
        failgroup FG1 disk
            '-10.10.10.13/GD00' name DISK00 size 3350G,
            '-10.10.10.13/GD01' name DISK01 size 3725G,
            '-10.10.10.13/GD02' name DISK02 size 3725G,
            '-10.10.10.13/GD03' name DISK03 size 3725G,
            '-10.10.10.13/GD04' name DISK04 size 3725G,
            '-10.10.10.13/GD05' name DISK05 size 3725G,
            '-10.10.10.13/GD06' name DISK06 size 3725G,
            '-10.10.10.13/GD07' name DISK07 size 3725G,
            '-10.10.10.13/GD08' name DISK08 size 3725G,
            '-10.10.10.13/GD09' name DISK09 size 3725G,
            '-10.10.10.13/GD10' name DISK10 size 3725G,
            '-10.10.10.13/GD11' name DISK11 size 3725G
        failgroup FG2 disk
            '-10.10.10.14/GD00' name DISK20 size 3350G,
            '-10.10.10.14/GD01' name DISK21 size 3725G,
            '-10.10.10.14/GD02' name DISK22 size 3725G,
            '-10.10.10.14/GD03' name DISK23 size 3725G,
            '-10.10.10.14/GD04' name DISK24 size 3725G,
            '-10.10.10.14/GD05' name DISK25 size 3725G,
            '-10.10.10.14/GD06' name DISK26 size 3725G,
            '-10.10.10.14/GD07' name DISK27 size 3725G,
            '-10.10.10.14/GD08' name DISK28 size 3725G,
            '-10.10.10.14/GD09' name DISK29 size 3725G,
            '-10.10.10.14/GD10' name DISK30 size 3725G,
            '-10.10.10.14/GD11' name DISK31 size 3725G
        failgroup FG3 disk
            '-10.10.10.15/GD00' name DISK40 size 3350G,
            '-10.10.10.15/GD01' name DISK41 size 3725G,
            '-10.10.10.15/GD02' name DISK42 size 3725G,
            '-10.10.10.15/GD03' name DISK43 size 3725G,
            '-10.10.10.15/GD04' name DISK44 size 3725G,
            '-10.10.10.15/GD05' name DISK45 size 3725G,
            '-10.10.10.15/GD06' name DISK46 size 3725G,
            '-10.10.10.15/GD07' name DISK47 size 3725G,
            '-10.10.10.15/GD08' name DISK48 size 3725G,
            '-10.10.10.15/GD09' name DISK49 size 3725G,
            '-10.10.10.15/GD10' name DISK50 size 3725G,
            '-10.10.10.15/GD11' name DISK51 size 3725G
        attribute 'AU_SIZE' = '4M';
    
    created.
    SQL> select * from v$as_diskspace;
    
    DISKSPACE_NUMBER  NAME   SECTOR_SIZE  BLOCK_SIZE  ALLOCATION_UNIT_SIZE
    ----------------- ------ ------------ ----------- ---------------------
                    0 DS0             512       4096               4194304
                    
    STATE   TYPE    TOTAL_MB  FREE_MB   REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB
    ------- ------- --------- --------- ----------------------- --------------
    MOUNT   NORMAL  33666928  30482600                   106152       14710574
    # cm0.tip 
    CM_NAME=cm0 
    CM_UI_PORT=9140
    CM_RESOURCE_FILE="/home/tibero/zetadata/cm0_res.crf"
    $ export CM_HOME=$TB_HOME
    $ export CM_SID=cm0
    
    $ tbcm -b
    CM Guard demon started up. 
    
    TBCM 7.1.1 (Build -)
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
    
    Tibero cluster manager started up. 
    Local node name is (cm0:9140).
    
    $ cmrctl add network --name net0 --ipaddr 10.10.10.11 --portno 1000
    Resource add success! (network, net0)
    $ cmrctl add cluster --name cls --incnet net0 --cfile "-"
    Resource add success! (cluster, cls)
    $ cmrctl start cluster --name cls
    MSG SENDING SUCCESS!
    $ cmrctl add service --name TAS --type as --cname cls
    Resource add success! (service, TAS)
    $ cmrctl add as --name tas0 --svcname TAS --dbhome "$TB_HOME"
    Resource add success! (as, tas0)
    $ cmrctl start as --name tas0
    Listener port = 9120 
    
    Tibero 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    Tibero instance started up (NORMAL mode).
    BOOT SUCCESS! (MODE : NORMAL)
    $ export TB_SID=tas0
    $ tbsql sys/tibero
    
    tbSQL 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    
    Connected to Tibero.
    
    SQL> alter diskspace DS0 add thread 1;
    Diskspace altered.
    # tas1.tip 
    INSTANCE_TYPE=AS 
    LISTENER_PORT=9120
    
    TOTAL_SHM_SIZE=4G 
    MEMORY_TARGET=5G
    
    CLUSTER_DATABASE=Y 
    LOCAL_CLUSTER_ADDR=10.10.10.12 
    LOCAL_CLUSTER_PORT=9130 
    CM_PORT=9140
    
    THREAD=1 
    DB_BLOCK_SIZE=4K
    AS_SCAN_SSVR_DISK=Y 
    USE_ZETA=Y
    # cm1.tip
    CM_NAME=1 
    CM_UI_PORT=9140
    CM_RESOURCE_FILE="/home/tibero/zetadata/cm1_res.crf"
    $ export TB_SID=tas1
    $ export CM_HOME=$TB_HOME
    $ export CM_SID=cm1
    $ tbcm -b
    CM Guard demon started up. 
    
    TBCM 7.1.1 (Build -)
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
    
    Tibero cluster manager CM started up. 
    Local node name is (cm1:9140).
    
    $ cmrctl add network --name net1 --ipaddr 10.10.10.12 --portno 1000
    Resource add success! (network, net1)
    $ cmrctl add cluster --name cls --incnet net1 --cfile "-"
    Resource add success! (cluster, cls)
    $ cmrctl start cluster --name cls
    MSG SENDING SUCCESS!
    $ cmrctl add as --name tas1 --svcname TAS --dbhome "$TB_HOME"
    Resource add success! (as, tas1)
    $ cmrctl start as --name tas1
    Listener port = 9120 
    
    Tibero 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    Tibero instance started up (NORMAL mode).
    BOOT SUCCESS! (MODE : NORMAL)
    # tac0.tip 
    DB_NAME=TAC
    LISTENER_PORT=9150
    CONTROL_FILES="+DS0/c1.ctl"
    LOG_ARCHIVE_DEST="+DS0/ARCH"
    
    MAX_SESSION_COUNT=300
    
    TOTAL_SHM_SIZE=60G 
    MEMORY_TARGET=270G
    
    CLUSTER_DATABASE=Y 
    LOCAL_CLUSTER_ADDR=10.10.10.11 
    LOCAL_CLUSTER_PORT=9160 
    CM_PORT=9140
    THREAD=0 
    UNDO_TABLESPACE=UNDO0 
    DB_BLOCK_SIZE=32K 
    AS_PORT=9120 
    USE_ACTIVE_STORAGE=Y
    _USE_O_DIRECT=Y 
    USE_ZETA=Y
    TAC 인스턴스 기준
    MEMORY_TARGET = (전체 메모리양)
                    - (Storage 노드 개수)
                        * {(TAC 인스턴스의 Max Session Count)
                            + (TAC 인스턴스의 PEP thread 전체 개수)} * 4MB
                    - (노드 내 TAS 인스턴스의 Memory Target)
                    - 10GB(=OS 및 타 thread의 connection 여유분)
    ** (TAC 인스턴스의 PEP thread 전체 개수) = (TAC 인스턴스의 PEP Process 개수)
                                            * (PEP process 당 thread 개수)
    ** TAC 인스턴스의 PEP thread 전체 개수 계산은 현재 TAC 인스턴스를 기준으로 함.
    $ export CM_HOME=$TB_HOME
    $ export CM_SID=cm0
    $ cmrctl add service --name TAC --type db --cname cls
    Resource add success! (service, TAC)
    $ cmrctl add db --name tac0 --svcname TAC --dbhome "$TB_HOME"
    Resource add success! (db, tac0)
    $ export TB_SID=tac0
    
    $ tbboot -t nomount
    Listener port = 9150 
    
    Tibero 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    Tibero instance started up (NOMOUNT mode).
    $ tbsql sys/tibero
    
    tbSQL 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    
    Connected to Tibero.
    
    SQL> create database "TAC"
            user sys identified by tibero 
            maxinstances 32
            maxdatafiles 2048 
            character set MSWIN949
            logfile group 1 '+DS0/log0001.log' size 2G, 
                    group 2 '+DS0/log0002.log' size 2G, 
                    group 3 '+DS0/log0003.log' size 2G
            maxloggroups 255
            maxlogmembers 8
            datafile '+DS0/system.dtf' size 4G 
                    autoextend on next 64M maxsize 128G
            syssub datafile '+DS0/syssub.dtf' size 4G
                    autoextend on next 64M maxsize 128G 
            default temporary tablespace TEMP tempfile
                    '+DS0/temp000.dtf' size 128G autoextend off, 
                    '+DS0/temp001.dtf' size 128G autoextend off, 
                    '+DS0/temp002.dtf' size 128G autoextend off, 
                    '+DS0/temp003.dtf' size 128G autoextend off,
                                            .
                                            .
                                            .
                    '+DS0/temp098.dtf' size 128G autoextend off, 
                    '+DS0/temp099.dtf' size 128G autoextend off
            undo tablespace UNDO0 datafile
                    '+DS0/undo00.dtf' size 128G autoextend off, 
                    '+DS0/undo01.dtf' size 128G autoextend off, 
                    '+DS0/undo02.dtf' size 128G autoextend off
            default tablespace USR
                    datafile '+DS0/usr.dtf' size 32G 
                    autoextend on next 64M maxsize unlimited;
    
    Database created.
    
    SQL> Disconnected.
    $ tbboot
    Listener port = 9150
    
    Tibero 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    Tibero instance started up (NORMAL mode).
    $ export TB_SID=tac0
    $ tbsql sys/tibero
    
    tbSQL 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    Connected to Tibero.
    
    SQL> create undo tablespace UNDO1 datafile
            '+DS0/undo03.dtf' size 128G autoextend off,
            '+DS0/undo04.dtf' size 128G autoextend off, 
            '+DS0/undo05.dtf' size 128G autoextend off;
    
    SQL> alter database add logfile thread 1 group 4 '+DS0/log004.log' size 2G; 
    SQL> alter database add logfile thread 1 group 5 '+DS0/log005.log' size 2G; 
    SQL> alter database add logfile thread 1 group 6 '+DS0/log006.log' size 2G; 
    SQL> alter database enable public thread 1;
    SQL> Disconnected.
    # tac1.tip 
    DB_NAME=TAC 
    LISTENER_PORT=9150
    CONTROL_FILES="+DS0/c1.ctl"
    LOG_ARCHIVE_DEST="+DS0/ARCH" 
    
    MAX_SESSION_COUNT=300
    
    TOTAL_SHM_SIZE=60G 
    MEMORY_TARGET=270G
    
    CLUSTER_DATABASE=Y 
    LOCAL_CLUSTER_ADDR=10.10.10.12 
    LOCAL_CLUSTER_PORT=9160 
    CM_PORT=9140
    THREAD=1 
    UNDO_TABLESPACE=UNDO1 
    DB_BLOCK_SIZE=32K 
    AS_PORT=9120 
    USE_ACTIVE_STORAGE=Y
    _USE_O_DIRECT=Y 
    USE_ZETA=Y
    TAC 인스턴스 기준
    MEMORY_TARGET = (전체 메모리양)
                    - (Storage 노드 개수)
                        * {(TAC 인스턴스의 Max Session Count)
                            + (TAC 인스턴스의 PEP thread 전체 개수)} * 4MB
                        - (노드 내 TAS 인스턴스의 Memory Target)
                        - 10GB(=OS 및 타 thread의 connection 여유분)
    ** (TAC 인스턴스의 PEP thread 전체 개수) = (TAC 인스턴스의 PEP Process 개수)
                                          * (PEP process 당 thread 개수)
    ** TAC 인스턴스의 PEP thread 전체 개수 계산은 현재 TAC 인스턴스를 기준으로 함.
    $ export TB_SID=tac1
    $ export CM_HOME=$TB_HOME
    $ export CM_SID=cm1
    $ cmrctl add db --name tac1 --svcname TAC --dbhome "$TB_HOME"
    Resource add success! (db, tac1)
    $ cmrctl start db --name tac1
    Listener port = 9150 
    
    Tibero 7
    
    TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 
    Tibero instance started up (NORMAL mode).
    BOOT SUCCESS! (MODE : NORMAL)
    SQL> select * from v$ssvr_client;
    
    ADDRESS   PORT   NAME         TRHEAD_NUMBER
    --------- ------ ---------- ----------------
    127.0.0.1 36088   TAS                     0
    127.0.0.1 36070   CLIENT_LIB              0
    SQL> select * from v$ssvr_slab_stat;
    
    SLAB_SIZE SLAB_GET_CNT TOTAL_CHUNK_CNT MAX_CHUNK_CNT
    ---------- ------------ --------------- -------------
         32768        99838              48            48
       1048576          354              48            48
       4194304           72              48            48
         32768       112967              64            64
       4194304           25              16            16
       
    5 rows selected.
    
    SQL> select * from v$ssvr_memstat;
    
    TOTAL_PGA_MEMORY_MB FIXED_PGA_MEMORY_MB USED_PGA_MEMORY_MB
    ------------------- ------------------- ------------------
    TOTAL_SHARED_MEMORY_MB FIXED_SHARED_MEMORY_MB USED_SHARED_MEMORY_MB
    ---------------------- ---------------------- ---------------------
                    4092                  31              3466
                      2048                    714            1.7592E+13
                      
    1 row selected.
    
    티베로 | 대한민국 대표 데이터베이스 전문 기업티베로
    Logo