> For the complete documentation index, see [llms.txt](https://docs.tibero.com/sysmasterdb/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tibero.com/sysmasterdb/8.4_manual/installation-guide/prerequisite/system-requirement.md). # 시스템 요구사항 ## 1. 지원 플랫폼 및 운영체제 SysMasterDB는 Linux 컨테이너 기반으로 배포되며, 선택한 구성 환경(Docker / Podman / Kubernetes)에 따라 필수 소프트웨어와 지원 운영체제가 달라진다. (64-bit 기준) | 구성 환경 (택 1) | 필수 소프트웨어 (최소) | 지원 운영체제 | | ----------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Docker | Docker Engine v28.0.0 이상 + Docker Compose v2.40.2 이상 |

Linux: RHEL 8 / 9, Rocky Linux 8 / 9, Oracle Linux 8 / 9, CentOS Stream 9 / 10
Windows: Windows 10 / 11, Windows Server 2022 (WSL2)

| | Podman | Podman v4.4.1 이상 + podman-compose v1.0.6 이상 |

Linux: RHEL / Rocky Linux / Oracle Linux 8.8 이상 또는 9.2 이상
Windows: Windows 10 / 11 (WSL2 / Podman Desktop)

| | Kubernetes | Kubernetes v1.21 이상 (유지 버전 권장) + CRI 런타임 (containerd 또는 CRI-O) | **Linux**: RHEL 8 / 9, Rocky Linux 8 / 9, Oracle Linux 8 / 9, CentOS Stream 9 / 10 | {% hint style="warning" %} **\[주의] CentOS 7 · RHEL 7 지원 종료** SysMasterDB 설치 호스트 기준으로 CentOS 7 · RHEL 7은 2024년 6월 30일에 지원이 종료(EOL)되어 세 구성 환경 모두에서 지원하지 않는다. 해당 OS가 유지보수 종료로 각 컨테이너 런타임(Docker/Podman)의 공식 지원 및 패키지 배포 대상에서 제외되었기 때문이다. (컨테이너는 이미지에 자체 런타임 라이브러리를 포함하므로 호스트 glibc 버전과 무관하게 동작한다.) 신규 설치는 RHEL / Rocky Linux / Oracle Linux 8 또는 9로 진행한다. {% endhint %} {% hint style="info" %} **\[참고] 소프트웨어 버전 하한의 근거** * **Docker Engine v28 이상**: Engine 24 계열의 컨테이너 다중 네트워크(endpoint) 연결 오류가 28 릴리스에서 수정되었다. * **Docker Compose v2.40.2 이상**: 원격 OCI Compose 아티팩트 경로 탐색 취약점(CVE-2025-62725, CVSS 8.9, 2025년 공개)이 2.40.2에서 패치되었다. 로컬 compose 파일만 사용하면 실제 노출은 제한적이나 방어적 하한으로 권장한다. * **Podman v4.4.1 / podman-compose v1.0.6**: Podman 4.4는 RHEL 8.8 · 9.2의 AppStream에 최초 탑재되었다. 따라서 Red Hat 배포 경로 기준 Podman 구성 환경의 OS 하한은 8.8 / 9.2이다. (podman-compose는 pip/EPEL로 별도 설치되며 RHEL minor 버전과 무관하다.) * **Kubernetes v1.21 이상**: 배포 매니페스트가 사용하는 `startupProbe`가 v1.18부터 기본 활성이다. 그 이전 버전에서는 이 필드가 무시되어, 기동에 시간이 걸리는 컨테이너가 `livenessProbe`에 의해 재시작을 반복한다. 또한 배포 매니페스트의 kustomize 문법이 kubectl v1.21에 내장된 버전을 기준으로 하므로, 배포를 수행하는 단말의 kubectl도 v1.21 이상이어야 한다. {% endhint %} {% hint style="info" %} **\[참고] Windows 환경** Windows 환경에서는 WSL2(Windows Subsystem for Linux 2)를 통해 Linux 컨테이너로 기동한다. Windows 10 / 11은 Docker Desktop 또는 Podman Desktop을, Windows Server 2022는 WSL2를 직접 설치해 사용한다. {% endhint %} {% hint style="info" %} **\[참고] Rocky Linux · Oracle Linux** RHEL 호환 배포판으로 RHEL 8 / 9 설치 절차를 준용해 동작한다. Docker는 파생 배포판을 공식 테스트하지 않으므로 사용자 환경에서 검증 후 적용한다. {% endhint %} {% hint style="info" %} **\[참고] Kubernetes** Kubernetes는 Linux 컨테이너를 Windows 노드에 배포할 수 없다(컨트롤 플레인·워커 노드 모두 Linux 필요). 또한 v1.21은 최소 동작 버전이며 이미 EOL 상태이므로, 신규 구축 시 벤더 지원을 받는 유지 버전(2026년 기준 v1.33 이상) 사용을 권장한다. SysMasterDB가 검증한 Kubernetes 버전은 v1.35이며, v1.21 \~ v1.32는 최소 동작 요건은 충족하나 제품 검증 범위에 포함되지 않는다. {% endhint %} ### 관제 데이터베이스 | 구분 | 제품 및 버전 | | --------------- | ------------------------------------------------------------------------------------------------------------ | | 관제 데이터베이스 | Tibero 6 PatchSet (6.7.x), Tibero 7 PatchSet (7.2.x) | | 관제 데이터베이스 운영 체제 | **Linux**: CentOS 7, RHEL 7 \~ 10, Oracle Linux 8 \~ 10, Rocky Linux 8 \~ 10, ProLinux 7.5, AIX 7.2 (64-bit) | {% hint style="info" %} **참고** * **관제 데이터베이스**는 위 '관제 데이터베이스 운영 체제' 목록에 있는 운영 체제에 설치된 데이터베이스에 대해서만 관제가 가능하다. (관제 대상 DB의 운영 체제는 SysMasterDB 설치 호스트의 운영 체제와 별개이다.) * **관제 데이터베이스는 Tibero PatchSet 바이너리만 지원한다.** Tibero 6 PatchSet(6.7.x)과 Tibero 7 PatchSet(7.2.x)이 지원 대상이며, FixSet·CoreSet 바이너리(예: Tibero 6 FS06 CS1902, Tibero 6 FS07 CS2005, Tibero 7 FS02)는 지원하지 않는다. PatchSet은 FixSet 번호가 같더라도 별개의 형상이므로(예: Tibero 7 FS02와 Tibero 7.2.x는 서로 다른 바이너리이다) FixSet 번호만으로 지원 여부를 판단하지 않는다. FixSet·CoreSet 바이너리를 사용 중인 경우 Tibero PatchSet으로 업그레이드한 후 관제 대상으로 등록한다. * 동일한 PatchSet 버전이라도 빌드 시점 및 적용된 패치 내역에 따라 연동 라이브러리와 호환되지 않을 수 있다. 특히 2022년 이전 빌드 바이너리는 정상 관제를 보장하지 않으며, 기본 지원 대상에서 제외된다. 적용된 패치는 **'3. 관제 데이터베이스 권장 패치'**와 함께 확인한다. * 관제 데이터베이스 운영 체제 요구: C++11 지원 컴파일러, gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44) 이상, GLIBCXX\_3.4.19 이상, GLIBC\_2.17 이상. {% endhint %} *** ## 2. 하드웨어 및 소프트웨어 SysMasterDB 8.4를 설치하기 위해 필요한 하드웨어 및 소프트웨어의 요구 사항은 다음과 같다. | 구분 | 사양 | | ------ | ----------------------------------------------------------- | | CPU | 8 Core | | RAM | 32 GB | | 저장 공간 | 30 GB 이상 (수집 정보의 보관 주기(RETENTION\_DAY)에 따라 일 당 50 GB 추가 필요) | | 웹 브라우저 | Chrome (최신 버전 사용 권장) | {% hint style="info" %} **참고** 총 Active Session 수 600개 (Active Session 수 60개 × 인스턴스 10대) 기준의 사양이다. {% endhint %} *** ## 3. 관제 데이터베이스 권장 패치 SysMasterDB 8.4의 관제 데이터베이스 대상 권장 패치는 다음과 같다. 권장 패치는 변경 대상에 따라 **라이브러리 패치**와 **서버 패치**로 구분한다. ### 라이브러리 패치 libtpmstat 라이브러리만 변경하는 패치로, Tibero 서버의 동작은 바뀌지 않으며 라이브러리 교체만으로 적용된다. 라이브러리 패치는 누적 적용을 전제로 생성되므로 일부만 선택하여 적용할 수 없고, 아래 패치를 모두 포함해야 한다.
패치 번호패치 내용
279651f

libtpmstat 라이브러리 생성

[참고] 해당 패치가 없는 경우 libtpmstat 라이브러리를 TPM Agent 설치 시 함께 배포해야 한다. TPM Agent 8.1.3 이상은 하위 버전 패치인 279651e 이하 패치와 호환이 되지 않기에, 279651f 이상 패치가 필요하다. Tibero에 적용된 279651 패치 버전과 상관 없이, TPM Agent 빌드 시 사용한 279651 패치 버전과 라이브러리의 279651 패치 버전이 맞아야 한다.

328607bWait count, wait time 정보 수집 시, wait event의 wait count, time 보정 문제 수정

[참고] 해당 패치가 없는 경우 wait time과 wait count의 값이 부정확하게 표출될 수 있다.
339899a

DB 비정상 종료 상태 판단 로직 개선

[참고] 해당 패치가 없는 경우 kill -9 등 외부 요인으로 DB가 비정상 종료되었을 때, TPM Agent에서 DB 종료 여부가 정확히 판단되지 않을 수 있다.

700601a

libtpmstat 라이브러리 v1.1.0 - TPM Agent CPU 사용률 개선을 위한 경량 세션 조회 API 및 SQL 식별 API 추가

[참고] 이 패치부터 libtpmstat 라이브러리 버전은 v1.1.0이다(기존 v1.0.0). TPM Agent 8.4 이상은 v1.1.0 API를 사용하므로 해당 패치가 없는 libtpmstat(v1.0.0)과 호환되지 않는다. 해당 패치가 없는 경우 TPM Agent가 라이브러리 심볼을 찾지 못해 기동 직후 종료되고, 인스턴스가 Agent Disconnected 상태를 반복한다.

701480a

libtpmstat 라이브러리 v1.1.0 - 700601a를 적용할 수 없는 바이너리용 패치 (패치 내용은 700601a와 동일)

[참고] Tibero 7 PatchSet 04(7.2.4) 이하이면서 700481a 패치가 없는 경우 700601a를 적용할 수 없으므로, 700601a 대신 이 패치를 적용한다. 해당 패치가 없는 경우의 현상은 700601a와 같다.

### 서버 패치 Tibero 서버를 변경하는 패치로, 관제 데이터베이스의 Tibero 서버 바이너리에 적용해야 한다. {% hint style="warning" %} **\[주의] 서버 패치는 라이브러리 교체만으로 적용되지 않는다** libtpmstat 라이브러리를 빌드할 때 서버 패치는 관제 데이터베이스 서버에 이미 적용되어 있는 것만 포함한다. 서버에 적용되지 않은 서버 패치를 라이브러리에 포함하면 라이브러리가 기대하는 공유 메모리 구조와 서버의 실제 구조가 달라져, 라이브러리가 잘못된 값을 읽거나 비정상 종료되어 정상적으로 연동되지 않는다. 서버 패치가 필요한 경우 서버 바이너리에 패치를 적용한 후 라이브러리를 함께 교체한다. 연동 라이브러리의 호환 조건(빌드 시점, 별도 반영 패치 내역, 컴파일 옵션 등)은 [TPM Agent 기동 / 종료 - libJNITpmStat.so 라이브러리](https://docs.tibero.com/sysmasterdb/8.4_manual/installation-guide/prerequisite/pages/UKytaA9xubKigXZZisB3#libjnitpmstat.so)를 참고한다. {% endhint %}
패치 번호패치 내용
240373

Program이 PE_SLAVE인 Session에서 OS User와 Machine 정보 누락 개선

[참고] 해당 패치가 없다면 Program이 PE_SLAVE인 Session에서 OS User와 Machine 정보가 누락된다.

276404

티베로의 global view 조회 시 수행되는 내부 쿼리에 대해 수행 시마다 physical plan을 새로 생성하는 문제 개선

[참고] SysMasterDB 8.4에서는 Lock 정보 수집을 위해 global view를 매초 조회한다. 해당 패치가 없는 경우 매초 특정 SQL에 대해 physical plan을 생성하여 [Analysis] > [Plan Analysis] 등에서 해당 SQL에 대해 조회 시 응답 없음 현상이 발생할 수 있다.

325193b

V$SESSION의 SQL 정보 컬럼(SQL_ID, SQL_CHILD_NUMBER, PREV_SQL_ID, PREV_CHILD_NUMBER, SQL_ET) 출력 항목 개선 - 사용자가 요청한 SQL 정보만 노출되고 SQL_ET가 fetch 구간을 포함해 집계되도록 수정

[참고] 해당 패치가 없는 경우 SQL의 실행(execute) 구간만 수행 중으로 판별되어 fetch 중인 세션의 SQL_ET(SQL 수행 시간)가 0으로 표시되고, 내부 쿼리가 사용자 SQL 대신 노출되거나 parallel 쿼리의 PE_SLAVE 세션에 SQL_ID가 보이지 않을 수 있다. 그 결과 [Realtime] > [Main Monitoring] > [Session Monitoring]의 Elapsed Time과 SQL Trace의 수행 시간이 실제보다 짧게 표출될 수 있다.

330570a

V$SESSION, V$BG_SESSION에 대기 이벤트 관련 컬럼(SEQ#, LAST_WAIT_EVENT#, LAST_WAIT_EVENT, LAST_WAIT_TIME, TIME_SINCE_LAST_WAIT) 추가 및 클라이언트 요청을 기다리는 세션의 WAIT_EVENT가 -1 대신 WE_WTHR_RECV로 조회되도록 개선

[참고] 해당 패치가 없는 경우 [Realtime] > [Main Monitoring] > [Session Monitoring]에서 클라이언트 요청을 기다리는 세션(Status가 READY인 세션)의 Wait Time은 표시되지만 Wait Event는 WE_WTHR_RECV로 표시되지 않는다.

281081

V$TEMPSEG_USAGE 뷰의 SESSION_NUMBER 컬럼 값 표기 잘못되는 문제 개선

[참고] 해당 패치가 없는 경우 [Realtime] > [Usage Monitoring] > [Temp Usage], [Analysis] > [Usage Analysis] > [Temp Usage] 메뉴에 부정확한 정보가 표출될 수 있다.

304770a

TSC 모니터링 전용 패치

[참고] 해당 패치가 없는 경우 아래 정보들이 V$DATABASE 뷰에 없어 primary와 standby가 구분되지 않는 등 TSC 모니터링 관련 정보들이 부정확하게 보여진다.

1) OPEN_MODE에 value 추가
    - READ ONLY WITH APPLY

PROTECTION\_MODE
: Protection mode currently in effect for the database

UNPROTECTED
PROTECTION
AVAILABILITY
PERFORMANCE

DATABASE\_ROLE
: Current role of the database

PRIMARY
PHYSICAL STANDBY
LOGICAL STANDBY (TODO)
SNAPSHOT STANDBY
CASCADING STANDBY

STANDBY\_BECAME\_PRIMARY\_TSN
: TSN at which the physical standby database became primary

STANDBY\_BECAME\_PRIMARY\_DATE
: Time at which the physical standby database became primary
338513a실제 TPR 연동에 필요한 패치로, 서버 패치 없이 패키지 생성 스크립트만 실행하면 된다.
338594a

TPR 연동 중 TPR 리포트 파일이 티베로 서버에 생성되는데, 이를 삭제해주는 티베로 패키지의 버그를 수정한 패치이다.

\[참고] 해당 패치 없어도 TPR 연동 기능은 동작하지만 리포트 파일이 서버에 쌓여서 주기적으로 삭제가 필요하다.

리포트 파일 수동으로 삭제 방법 : 주기적으로 TPR\_REPORT\_DIR 디렉터리에서 다음과 같이 .report로 시작하는 리포트 파일 삭제.

rm -f .report\*

149894l해당 패치가 없는 티베로 6에서 지원하지 않는 쿼리를 TPR 스냅샷 조회 시 사용하고 있어 해당 패치가 없으면 해당 패치가 없는 티베로 6에서는 조회가 되지 않는다.
250728fStandby에서 V$INSTANCE 뷰를 조회할 수 있도록 해주는 패치. 해당 패치가 없으면 해당 인스턴스가 클러스터링이 되지 않는다.