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

설치 전 준비사항

1. 디스크 용량 확인

Tibero를 설치하기 위해서는 각 플랫폼별로 약간의 차이가 있지만 최소 2GB 이상의 하드디스크 여유 공간이 필요합니다. 이는 Tibero 설치 후 데이터베이스를 생성할 때 최소로 필요한 하드디스크 공간을 의미하기도 합니다.

2. JDK 설치 확인

Tibero 클라이언트 인스톨러를 이용해 설치하기 위해서는 JDK 1.5.17 이상이 반드시 설치되어 있어야 합니다.

[그림 1] JDK 설치 확인

3. 설치 파일 준비

Tmax group의 TechNet에서 회원가입 후 설치파일을 다운로드합니다.

🔎

Tibero를 설치한 후 타 제품과 연동을 위해 JDBC를 제공합니다.

JDBC 연동을 할 경우 Tibero DB 서버의 해당 경로에서 드라이버 파일을 받아 연동합니다.

아래는 서버의 운영체제별 드라이버 파일 위치에 대한 설명입니다.

아래는 Tibero 버전 별 드라이버 파일명에 대한 설명입니다.

안내서 구성

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

OS 명령어 히스토리 검사

위험 분석

Tibero를 사용하여 DBMS에 접근할 경우 명령어 행의 계정 및 패스워드를 붙여서 사용하면 쉘 히스토리 (.history 또는 .sh_history) 파일에 사용한 계정과 패스워드의 기록이 남습니다.

위험 영향

계정 및 패스워드가 유출될 가능성이 있습니다.

해결 방안

Tibero 명령을 사용할 경우 명령어 행에 계정과 패스워드를 Line Mode가 아닌 Interactive Mode로 실행합니다. 쉘 히스토리(.history 또는 .sh_history) 파일에 대한 보호를 위하여 접근 권한 설정을 600으로 설정합니다.

UTL_FILE_DIR 사용 제한

위험 분석

UTL_FILE_DIR은 UTL_FILE을 통해 호스트의 파일 시스템 접근 허용 디렉터리를 제한합니다.

만약 UTL_FILE_DIR의 설정값이 '*'로 설정된 경우 전체 파일 시스템에 접근이 가능하므로 '*'로 설정할 경우에는 매 우 제한적으로 사용해야 합니다.

위험 영향

호스트의 전체 파일 시스템에 접근이 가능합니다.

해결 방안

'*' 설정값을 제거합니다.

UTL_SMTP 사용 제한

위험 분석

UTL_SMTP 패키지를 Public 그룹에서 사용할 수 있도록 권한을 부여하면 허가받지 않은 메일의 전송이 발생 할 수 있습니다.

위험 영향

시스템 내부의 파일을 외부로 전송할 수 있습니다.

해결 방안

Public 그룹과 같은 사용자에게 권한을 부여하지 않고 특정 사용자에게 부여하여 해당 사용자에게만 메일이 전송될 수 있게 합니다.

Sample DB 제거

위험 분석

Tibero DBMS를 초기에 설치할 경우 디폴트로 포함되는 Sample DB(TEST DB)를 제거하여 DBMS 운영정보 관련 공격이 침투할 때 환경 정보를 제거합니다.

데이터베이스의 운영 환경정보 노출 가능성이 있습니다.

Sample DB를 제거합니다.

Tibero의 중요 파일 중에 하나인 initialization 파일의 변경으로 시스템 장애가 발생합니다.

DB 기동 및 운영에 위협적인 영향을 줄 수 있습니다.

$ chmod 640 $TB_HOME/config/$TB_SID.tip 파일의 접근 권한을 설정합니다. (권장값 : 600 또는 640)

Tibero의 중요 파일인 Control 파일, Redo 로그 파일, 데이터 파일의 삭제 및 변경으로 시스템 장애가 발생합니다.

DB 운영 정지 및 데이터의 유실 위험이 있습니다.

Control 파일, Redo 로그 파일, 데이터 파일의 접근 권한을 설정합니다. (권장값 : 600 또는 640)

접근 권한을 640으로 설정한 경우

Join이나 대량 Sort 처리가 많은 경우 Temp 테이블 스페이스에서의 I/O가 다발적으로 발생합니다. (CREATE INDEX / ANALYZE / SELECT DISTINCT / ORDER BY / GROUP BY / UNION / SORT-MERGE)

Temp 테이블 스페이스 크기 산정을 위해서는 SQL Execution Work Area와 Temp 테이블 스페이스 간의 관계 이해가 필수입니다.

아래는 Temp 테이블 스페이스의 크기를 산정할 때 고려할 사항입니다.

• 시스템유형 : OLTP, DSS, DW, Batch Job

• User Load

개발 및 운영 시스템 분리 사용

위험 분석

개발 시스템과 운영 시스템을 하드웨어적으로 분리하여 Link가 설정되지 않아야 하며, 운영 시스템의 데이터를 개발 시스템으로 이전할 때 중요 데이터의 삭제 같은 통제와 검증 절차를 거쳐야 합니다.

위험 영향

운영 시스템의 중요 데이터가 개발 시스템으로 누출될 가능성이 있습니다.

해결 방안

개발 시스템과 운영 시스템의 분리를 회사의 정책으로 정의하고 개발자와 운영자를 원칙적으로 분리합니다. 만약 분리할 수 없다면 개발자가 운영 시스템에 접근할 경우 통제 절차를 거치도록 해야 합니다.

SYSDBA 권한 제한

위험 분석

DBA가 SYS 패스워드를 입력하지 않고 접근하면 그룹을 가진 멤버들이 SYS 권한으로 로그인이 가능하므로 SYS 암호를 반드시 입력해야 합니다.

위험 영향

인증 없이 SYS 권한 획득이 가능합니다.

해결 방안

Tibero에는 Oracle의 sqlplus /as sysdba와 같은 접속 방법이 없으므로 해당사항이 없다.

Listener 패스워드 설정 점검

위험 분석

Listener를 구동 또는 중지하는 작업은 DBA와 같은 특권자에게만 부여하며 Listener에 대한 접근 통제를 위해Listener 접근 패스워드를 설정해야 합니다.

위험 영향

비인가자의 Listener 접근이 가능합니다.

해결 방안

Tibero는 Listener와 서버 프로세스가 동시에 기동되기 때문에 해당사항이 없습니다.

환경설정 파일 보호 점검

위험 분석

운영에 중요한 환경 파일을 아무나 접근해서 수정할 경우 침입자가 환경 파일을 열어 설정값을 변경함으로써DB 운영에 영향을 줄 수 있습니다.

위험 영향

악의적인 목적으로 파일을 변조할 수 있습니다.

• $TB_HOME/config/$TB_SID.tip 파일의 퍼미션값을 변경합니다. (권장값 : 600 또는 640)

• OS 계정에 의해 수정 및 관리되도록 하고 일반 계정의 접근을 금지합니다.

중요 파일에 불필요한 소유권 또는 그룹 권한이 주어질 경우 해당 파일로 인해 인증되지 않은 사용자가 정보를 획득할 수 있습니다.

시스템 또는 네트워크 환경설정 파일의 권한이 취약하게 설정되어 있거나 Tibero 사용자가 소유권을 가져야 하는 파일을 권한없는 사용자가 소유한다면비인가자가 시스템 권한을 획득하거나 중요 데이터를 파괴할 수 있습니다.

$TB_HOME/client/config/tbdsn.tbr 파일의 퍼미션값을 변경합니다. (권장값 : 600 또는 640)

Object의 사용 권한을 Public에 부여하면 Object 사용 권한이 없는 모든 계정이 해당 Object에 접근 가능하고Object의 정보를 획득할 수 있습니다.

새로 생성된 계정의 Object 사용 권한이 Public에 불필요하게 부여된 경우 권한 남용의 위험이 있습니다.

Object의 사용 권한이 불필요하게 Public에 부여된 경우 권한을 제한합니다.

다음은Public으로부터 권한을 제거하는 방법입니다.

GRANT 옵션과 함께 권한을 받은 사용자는 해당 권한을 다른 사용자에게 부여할 수 있습니다.

불필요하게 GRANT 옵션이 부여된 계정이 있는 경우 권한 남용의 위험이 있습니다. (단, 담당자가 확인하여 권한이 필요하다고 인정하는 경우는 제외합니다.)

GRANT 옵션 권한 부여는 DBA만 할 수 있도록 제한합니다. 불필요하게 GRANT 옵션이 부여된 계정은 권한을 제 거하고 GRANT 옵션 없이 권한을 다시 부여합니다.

ADMIN 옵션과 함께 시스템 권한을 받은 사용자는 해당 권한을 다른 사용자에게 부여할 수 있습니다.

불필요하게 ADMIN 옵션이 부여된 계정이 있는 경우 권한 남용의 위험이 있습니다. (단, 담당자가 확인하여 권한이 필요하다고 인정하는 경우는 제외합니다.)

ADMIN 옵션 권한 부여는 DBA만 할 수 있도록 제한합니다. 불필요하게 ADMIN 옵션이 부여된 계정은 권한을 제 거하고 ADMIN 옵션 없이 권한을 다시 부여합니다.

개발 및 운영 시스템 분리 사용

위험 분석

개발 시스템과 운영 시스템을 하드웨어적으로 분리하여 Link가 설정되지 않아야 하며, 운영 시스템의 데이터를 개발 시스템으로 이전할 때 중요 데이터의 삭제 같은 통제와 검증 절차를 거쳐야 합니다.

위험 영향

운영 시스템의 중요 데이터가 개발 시스템으로 누출될 가능성이 있습니다.

해결 방안

개발 시스템과 운영 시스템의 분리를 회사의 정책으로 정의하고 개발자와 운영자를 원칙적으로 분리합니다. 만약 분리할 수 없다면 개발자가 운영 시스템에 접근할 경우 통제 절차를 거치도록 해야 합니다.

DBA 권한 제한

위험 분석

인가되지 않은 사용자가 DBA 권한으로 DBMS를 오용 및 남용할 수 있습니다.

위험 영향

DBA 권한을 사용하여 시스템 장애 및 데이터베이스를 변조할 가능성이 있습니다.

해결 방안

DBA 권한이 있는 계정의 사용자와 필요성을 확인합니다. 만약 불필요하게 DBA 권한이 허용된 계정이 있다면 계정을 없애거나 DBA 권한을 제거하고 데이터 누출 및 유실을 막기 위해 보안 정책을 수립합니다.

다음은 DBA 권한 제거 방법입니다.

SQL> REVOKE DBA FROM <username>;

디폴트 계정 사용

위험 분석

잘 알려진 디폴트 계정과 디폴트 패스워드를 이용하여 데이터베이스에 접근할 수 있습니다.

위험 영향

데이터베이스 접근 또는 상위 권한을 획득하여 데이터를 열람, 수정, 삭제할 수 있습니다.

해결 방안

• OS, DB 레벨에서 원천적으로 접근을 제한하기 위해 사용하지 않는 애플리케이션 계정을 삭제합니다.

• 계정은 다른 용도로 사용하고 특정 데이터베이스의 접근만 제한해야 하는 경우 SUPER USER 또는 설치 계정 의 GROUP에서 삭제합니다.

디폴트 생성 DB 사용자(SYSCAT, SYSGIS, OUTLN, TIBERO, TIBERO1)의 디폴트 패스워드를 이용하여 인가되 지 않은 사용자가 DBMS에 접근할 수 있습니다.

데이터베이스 접근 및 상위 권한을 획득하여 데이터를 열람, 수정, 삭제할 수 있습니다.

사용하지 않는 디폴트 DB 계정은 삭제하거나 Lock 시키고, 사용하는 계정이라면 디폴트 패스워드를 수정합니다.

무제한으로 로그인 시도가 가능한 경우 Brute Force 공격으로 무제한 로그인 시도가 발생할 수 있습니다.

Brute Force 공격의 피해가 발생할 수 있습니다.

로그인 실패 횟수를 설정하는 FAILED_LOGIN_ATTEMPTS 항목을 설정하여 일정 횟수로 로그인을 실패할 경우 계정이 Lock 되게 합니다.

profile은 사용자 패스워드 관리 정책을 다양하게 생성하고 각각의 사용자에게 특정 정책을 사용하도록 지정 함으로써 사용자별로 그룹화된 패스워드 정책을 관리할 수 있는 기능을 제공합니다.

악의적인 사용자의 Brute Force 공격으로 무제한 로그인 시도가 발생할 수 있습니다.

Brute Force 공격의 피해가 발생할 수 있습니다.

패스워드 Lock 기간을 설정하는 PASSWORD_LOCK_TIME 항목을 설정하여 일정 시간동안 로그인을 할 수 없도록 계정이 Lock 되게 합니다. (기본값 : UNLIMITED, 권장값 : 1 또는 2 또는 24)

DBA_USERS 계정에 대해 주기적으로 패스워드를 변경하지 않고 취약한 패스워드로 설정할 경우 인증되지 않은 사용자에게 DBA 또는 USER 권한을 줄 수 있습니다.

권한이 노출되어 남용될 수 있습니다.

profile의 PASSWORD_LIFE_TIME 항목 설정값을 변경합니다. (기본값 : UNLIMITED, 권장값 : 30 ~ 90days)

profile 변경

DBA_USERS 계정의 패스워드를 변경할 때 패스워드 재사용 기간을 설정하지 않고 동일 패스워드를 사용할 경우 인증되지 않은 사용자에게 DBA 권한을 줄 수 있습니다.

권한이 노출되어 남용될 수 있습니다.

PASSWORD_REUSE_TIME에 지정한 날짜 동안에는 전에 사용했던 패스워드를 재사용하지 못하게 profile의 PASSWORD_REUSE_TIME 항목 설정값을 변경합니다. (기본값 : UNLIMITED, 권장값 : 30 ~ 90 days)

profile 변경

일반 계정의 System Catalog 접근 제한

위험 분석

일반 계정으로 데이터베이스의 관리 및 통계 등의 Meta 데이터를 가지고 있는 System Catalog에 접근하여 데이터베이스의 정보를 획득할 수 있습니다.

위험 영향

데이터베이스의 System Catalog 정보 유출 가능성이 있습니다.

해결 방안

데이터베이스의 Meta 데이터를 가지고 있는 System Catalog는 소수의 데이터베이스 관리자만 사용할 수 있도록 설정합니다.

Public으로부터 권한을 제거하는 방법

REVOKE <privilege> ON <system catalog object> FROM PUBLIC;

네트워크 액세스 제한

위험 분석

원격 서버로부터 DBMS 정보가 노출될 수있습니다.

위험 영향

인가되지 않은 IP 주소 사용자에게 정보 유출 가능성이 있습니다.

해결 방안

$TB_SID.tip 파일에 아래의 항목들을 정의하여 접근 허용 및 접근 제한 IP 주소를 지정합니다.

LSNR_INVITED_IP
LSNR_DENIED_IP
LSNR_INVITED_IP_FILE
LSNR_DENIED_IP_FILE

다음은 LSNR_INVITED_IP 항목의 등록 예제 입니다.

LSNR_INVITED_IP="192.168.20.0/24;192.168.10.101"

위와 같이 등록하면 $TB_HOME/instance/$TB_SID/log/lsnr/trace_list.log 파일에 다음과 같이 등록됩니다.

*** listener started and got into main loop ***
[INVITED-IP] 192.168.20.0 / 255.255.255.0
[INVITED-IP] 192.168.10.101 / 255.255.255.255

다음은 LSNR_INVITED_IP_FILE 항목의 등록 예제 입니다.

위와 같이 등록한 후 LSNR_INVITED_IP_FILE 항목에 등록한 파일(invited.list)에 허용할 IP 주소 List를 작성합니다.

DB Link는 클라이언트 또는 현재의 데이터베이스에서 네트워크 상의 다른 데이터베이스에 접속하기 위한 접속설정을 정의하는 Tibero 객체입니다.

클라이언트와 데이터베이스 간의 DB Link가 암호화되지 않으면 원격 서버에 접근할 경우 패스워드와 같은 중요 정보가 노출될 수 있습니다.

악의가 있는 사용자가 스니핑 등의 네트워크 공격을 통해 패스워드를 노출할 가능성이 있습니다.

Tibero는 DB Link를 설정할 때 원격 서버의 패스워드가 암호화되므로 해당사항이 없습니다.

감사를 수행할 수 있게 설정하여 사용자에 의한 문장, 권한, 객체에 대해 감사를 수행할 수 있습니다. 침해 사고 및 장애가 발생할 때 감사 자료를 이용하여 정확한 분석을 할 수 있습니다.

침해 사고 또는 장애 발생의 경우 원인 파악이 어렵습니다.

감사를 활성화하기 위하여 TIP 파일에 'AUDIT_TRAIL'의 값을 { NONE | DB | DB_EXTENDED | OS } 중에서 하나 선택합니다.

다음은 $TB_HOME/config/$TB_SID.tip 파일의 설정 예제 입니다.

감사 로그를 다른 사용자가 읽기, 쓰기 할 수 있는 경우 서버의 중요 정보가 노출될 위험성이 있습니다.

비인가 사용자에 의한 파일의 변조 및 노출이 가능합니다.

AUDIT_FILE_DEST에 설정된 경로의 디렉터리 권한을 750 또는 700 이하로 설정합니다.

데이터 Dictionary는 물리적 및 논리적 구조, 객체 정의 및 공간 할당, 사용자, 룰, 권한, 감사 등 데이터베이스의 핵심에 해당하는 정보를 담고 있으므로 사용자 및 외부로부터 보호해야 합니다.

보호되지 않을 경우 누구나 DROP ANY TABLE 명령어로 데이터 Dictionary의 내용을 삭제할 수 있습니다.

데이터 Dictionary 정보의 삭제가 가능합니다.

Tibero는 해당 기능이 없으므로 해당사항이 없습니다.

Listener logging 기능이 활성화 되어있지 않으면 공격자에 의한 악의적인 Listener command 사용 또는Listener 패스워드를 알아내기 위한 Brute Force 공격의 파악이 불가능합니다.

침해 사고 또는 장애 발생의 경우 원인 파악이 어렵습니다.

$TB_HOME/instance/$TB_SID/log/lsnr/trace_list.log 파일을 디폴트로 남깁니다.

Listener는 클라이언트로부터 접속 요구를 감시하는 프로세스로 클라이언트는 Listener를 통해 데이터베이스 에 접속합니다. Listener 설정 파일은 Listener가 기동할 때 읽혀져 클라이언트의 접근을 가능하게 하며 악의적인 사용자에 의해 사용될 경우 원격으로 Listener의 구성 설정을 변경할 수 있습니다.

버퍼 오버플로우, 정보 유출, 악의적인 목적으로 파일을 변조할 수 있습니다.

Tibero는 Oracle과 아키텍처 차이로 Listener가 별도로 존재하지 않습니다.

문서 다운로드

UNIX(SINGLE) 패치

본 장에서는 Tibero UNIX(SINGLE) 패치 방법을 설명합니다. UNIX(SINGLE) 패치 순서는 다음과 같습니다.

1. 패치 전 점검사항

2. UNIX(SINGLE) 패치 과정

3. 패치 후 점검사항

각 과정에 대한 상세한 설명은 해당 절의 내용을 참고합니다.

본 절에서는 UNIX(SINGLE) 패치 전 점검할 사항에 대해서 설명합니다.

• sys, syscat 패스워드 확인 패치할 때 두 개의 사용자 계정과 패스워드가 필요합니다. 패치 전 패스워드로 접속을 확인합니다.

• Object Validation 확인 패치 후 기존 Valid Object들이 Invalid할 경우 조치를 취하기 위해서 패치 전 아래의 쿼리를 수행하여 정보를 저장합니다.

- Check Count

– Check Invalid Object List

• Tablespace의 데이터 파일 위치 파악 데이터 파일 위치가 $TB_HOME 내부 디렉터리에 존재하는지 확인합니다.

• DB Link 사용 여부 확인 $TB_HOME/client/config/tbdsn.tbr을 확인합니다.

– Tibero To Oracle DB Link(ps -ef | grep gw4orcl)

– Tibero To DB2 DB Link(ps -ef | grep gw4db2)

– Tibero To MS-SQL DB Link(ps -ef | grep tbgw)

– Tibero To Sybase DB Link(ps -ef | grep tbgw)

– Tibero To GREENPLUM DB Link(ps -ef | grep tbgw)

– Tibero To MySQL DB Link(ps -ef | grep tbgw)

• External Procedure 사용 여부 확인 $TB_HOME 내부에 class 또는 so 파일이 존재하는지 확인 후 복사합니다.

– C External Procedure

– JAVA External Procedure

• ESQL/C, ESQL/COBOL 사용 여부 확인 담당자를 통해서 사용 여부를 확인합니다.

• Tibero 버전 확인 tbboot -v 명령어를 실행하여 현재 설치된 Tibero 버전을 확인합니다.

UNIX(SINGLE) 패치 과정의 순서는 다음과 같습니다.

1. Tibero 서비스 중지 애플리케이션이 DB에 연결되어 있다면 애플리케이션을 다운 후에 Tibero 서비스를 중지합니다.

1. Tibero 바이너리 교체

   1) 기존 Tibero가 설치된 폴더가 tibero7일 때 기존 Tibero 서버 바이너리를 “tibero7빌드버전 일자”로 바꿔 줍니다.

다음은 사용 예입니다.

2) 데이터 파일이 TB_HOME 디렉터리 내부에 존재할 경우 $TB_HOME 내부의 동일경로에 mv또는 copy 명령어를 수행합니다. 만약, 외부에 존재할 경우 백업 여부는 선택적으로 진행합니다.

3) DB Link를 사용 중일 경우 Gateway에 대하여 바이너리 패치가 필요할 수 있습니다. DB Link용 Gateway를 패치할 때는 기존 바이너Backup 이후에 수행합니다. 다음은 기존 Gateway를 패치한 곳으로 move하고 패치한 신규 바이너리와 적용에 문제가 없는지 체크하는 방법입니다.

• Tibero to Oracle "$TB_HOME/client/bin/gw4orcl"를 교체하고 ldd gw4orcl을 실행하여 "not found"가 발생하지 않는지 확인합니다.

• Tibero to MSSQL "$TB_HOME/client/bin/tbJavaGW.zip"을 교체합니다.

4) External Procedure를 사용 중일 경우

• C External Procedure so 파일이 $TB_HOME 내부에 존재할 경우 패치한 바이너리로 복사합니다.

• JAVA External Procedure class 또는 jar 파일이 $TB_HOME 내부에 존재할 경우 패치한 바이너리로 복사합니다. 아래와 같은 파일들의 설정 내용 파악 후 필요한 내용을 복사합니다.

Backup 받은 디렉터리 기준으로 변경사항을 다음과 같이 O/S 명령어로 비교하여 변경사항이 있을 경우에만 원본 설정 파일을 Overwrite 합니다.

다음은 변경사항이 있을 경우 원본 설정 파일을 Overwrite 하는 예입니다.

5) ESQL/C, ESQL/COBOL을 사용할 경우

• ESQL/C $TB_HOME/client/config/tbpc.cfg 파일의 설정 내용 파악 후 필요한 내용을 복사합니다.

• ESQL/COBOL $TB_HOME/client/config/tbpcb.cfg 파일의 설정 내용 파악 후 필요한 내용을 복사합니다.

교체된 신규 바이너리에 tip, tbdsn.tbr, psm_commands 생성을 위해 환경설정을 수행합니다.

• 환경설정 방법

• 환경설정 예

다음은 각 파일의 교체 방법 및 사용 예입니다.

• 라이센스 파일 다음은 라이센스 파일 교체 방법입니다.

다음은 사용 예입니다.

• Tip(=Tibero Init Parameter) 파일 다음은 tip 파일 교체 방법입니다.

다음은 사용 예입니다.

• tbdsn.tbr 파일 다음은 tbdsn.tbr 파일 교체 방법입니다.

다음은 사용 예입니다.

• cfg 파일 다음은 cfg 파일 교체 방법입니다.

다음은 사용 예입니다.

1. Tibero 서비스 시작

다음과 같이 tbboot 명령어를 사용하여 Tibero 서비스를 시작합니다.

1. system 패키지 실행 및 확인

• 실행 sys, syscat 의 패스워드를 입력하여 Tibero 내부에서 사용하는 DD(Data Dictionary)와 system 패키지를 생성합니다.

sys, syscat의 패스워드 확인 방법은 “1.1 패치 전 점검사항”의 “sys, syscat 패스워드 확인”을 참고합니다.

• 확인 “$TB_HOME/instance/$TB_SID/log/system_init.log”를 확인했을 때 아래와 같이 에러 코드(”TBR- 17001”,”TBR-70004”)가 나타난다면 system 패키지 실행이 정상적으로 이뤄지지 않은 것입니다.

1. alter system recompile all; 실행 모든 PSM recompile 동작을 수행하며 PSM compile할 때 BCODE를 생성하여 Data Dictionary에 저장하는 구조입니다. 패치가 되면서 생성되는 BCODE가 변경됐을 가능성 때문에 수행합니다.

1. revalidate_viewsyn.sql 수행 sys 계정이 아닌 DBA 권한을 가진 계정에서 해당 스크립트를 수행합니다. Tibero에서는 현재 view/synonym의 compile ddl을 지원하지 않으며, 패치 후 해당 object의 validation을 실 시하기 위해 해당 스크립트를 수행합니다.

• Invalid Object 확인 패치 전 Object Validation 결과와 비교하여 처리합니다. 다음은 dba_objects 테이블에 등록된 Object들의 상태가 Invalid된 항목을 조회하는 방법입니다.

– PSM

Procedure, Function Invalid일 경우 다음과 같이 처리한다. (해당 사용자가 수행)

– INDEX

FBI(Function Based Index)의 경우 패치할 때 Invalid 가능성이 있으므로 다음과 같이 처리합니다. (해당 사용자 가 수행)

• 애플리케이션 Driver 패치 JDBC, ODBC, OLE DB 등 Driver가 변경 가능하다면 Tibero 서버 패치 버전에 맞춥니다. JDBC, ODBC, OLE DB는 서버 바이너리에 포함되어 있으며 다음과 같은 경로에 위치해 있습니다. – Tibero 7 버전

다음은 Tibero 패치 작업이 실패했을 경우 기존 바이너리로 복원하는 과정입니다.

1. Tibero 서비스 정지

2. Tibero 과거 버전으로 바이너리 교체

3. 기존 데이터 파일 경로 확인

4. Tibero 서비스 시작

본 장에서는 Tibero Windows(SINGLE) 패치 방법을 설명합니다. Windows(SINGLE) 패치 순서는 다음과 같습니다.

각 과정에 대한 상세한 설명은 해당 절의 내용을 참고합니다.

Windows(SINGLE) 패치 전 점검할 사항에 대한 자세한 설명은 UNIX(SINGLE) 패치의 “”을 참고합니다.

Windows(SINGLE) 패치 과정의 순서는 다음과 같습니다.

Windows(SINGLE) 패치 후 점검할 사항에 대한 자세한 설명은 UNIX(SINGLE) 패치의 “”을 참고합니다.

본 장에서는 Tibero UNIX(TAC) 패치 방법을 설명합니다. UNIX(TAC) 패치 순서는 다음과 같습니다.

각 과정에 대한 상세한 설명은 해당 절의 내용을 참고합니다.

UNIX(TAC) 패치 전 점검할 사항에 대한 자세한 설명은 UNIX(SINGLE) 패치의 “”을 참고한다.

본 절에서는 기본적으로 Node 2대에 대한 패치 방법을 설명하며 Node 3대 이상도 패치 방법은 동일합니다. UNIX(TAC) 패치 과정의 순서는 다음과 같습니다.

1. Tibero 서비스 중지 애플리케이션이 DB에 연결되어 있다면 애플리케이션을 다운 후에 Tibero 서비스를 중지합니다.

• Node1 다운

• Node2 다운

1. Tibero 바이너리 교체 Tibero 7 FS02 build 257078에서 tibero7 FS02 build 257446로 패치하는 과정입니다.

• Node1 바이너리 교체

• Node2 바이너리 교체

1. 환경설정 수행 교체된 신규 바이너리에 tip, tbdsn.tbr, psm_commands 생성을 위해 환경설정을 수행합니다.

• Node1 환경설정

• Node2 환경설정

1. 라이센스, tip, tbdsn.tbr, cfg 파일 교체 기존 파일들을 패치된 신규 바이너리에 복사합니다.

• 라이센스 파일

– Node1 라이선스 파일 복사

– Node2 라이선스 파일 복사

• Tip(=Tibero Init Parameter) 파일

– Node1 Tip 파일 복사

– Node2 Tip 파일 복사

• tbdsn.tbr 파일

– Node1 tbdsn.tbr 파일 복사

– Node2 tbdsn.tbr 파일 복사

• cfg 파일

– Node1 cfg 파일 복사

– Node2 cfg 파일 복사

1. Tibero 서비스 시작

– Node1 Tibero 기동

– Node2 Tibero 기동

1. system 패키지 실행 및 확인 UNIX(TAC) 패치의 경우 한쪽의 Node에서만 실행 및 확인을 합니다.

• 실행 sys, syscat의 패스워드를 입력하여 Tibero 내부에서 사용하는 DD(Data Dictionary)와 system 패키지를 생성합니다.

sys, syscat의 패스워드 확인 방법은 “1.1. 패치 전 점검사항”의 “sys, syscat 패스워드 확인”을 참고합니다.

• 확인 “$TB_HOME/instance/$TB_SID/log/system_init_log”을 확인했을 때 아래와 같이 에러 코드(”TBR- 17001”, “TBR-70004”)가 나타난다면 system. 패키지 실행이 정상적으로 이뤄지지 않은 것입니다.

1. alter system recompile all; 실행 모든 PSM recompile 동작을 수행하며 PSM compile할 때 BCODE를 생성하며 Data Dictionary에 저장하는 구조입니다. 패치가 되면서 생성되는 BCODE가 변경됐을 가능성 때문에 수행을 합니다. UNIX(TAC) 패치의 경우 한쪽의 Node 에서만 실행을 합니다.

1. revalidate_viewnsyn.sql 수행 sys 계정이 아닌 계정에서 해당 스크립트를 수행합니다.

UNIX(TAC) 패치 후 점검할 사항에 대한 자세한 설명은 UNIX(SINGLE) 패치의 “”을 참고합니다.

본 장에서는 Tibero Active-Standby 패치 방법을 설명한다. Active-Standby 패치 순서는 다음과 같습니다.

각 과정에 대한 상세한 설명은 해당 절의 내용을 참고합니다.

Active-Standby 패치 전에 HA Cluster를 중지하고 패치할 때 Cluster 엔지니어를 필요로 합니다. 패치 전 점검할 사항 에 대한 자세한 설명은 UNIX(SINGLE) 패치의 “”을 참고합니다.

Active 서버는 “”과 동일하므로 본 절에서는 Standby 서버의 패치 과정만 설명합니다. Standby 서버의 패치 과정의 순서는 다음과 같습니니다.

1. Tibero Standby 서버 바이너리 교체 1) 기존 Tibero가 설치된 폴더가 tibero7일 때, 기존 Tibero 서버 바이너리를 “tibero7빌드버전일자”로 바꿔줍니다.

다음은 사용 예입니다.

2) 데이터 파일이 TB_HOME 디렉터리 내부에 존재할 경우

$TB_HOME 내부의 동일경로에 mv 또는 copy 명령어를 수행합니다. 만약, 외부에 존재할 경우 백업 여부 는 선택적으로 합니다.

3) DB Link를 사용 중일 경우

Gateway에 대하여 바이너리 패치가 필요할 수 있습니다. DB Link용 Gateway를 패치할 때는 기존 바이너리Backup 이후에 수행합니다.

다음은 기존 Gateway를 패치한 곳으로 move하고 패치한 신규 바이너리와 적용에 문제가 없는지 체크하는 방법입니다.

• Tibero to Oracle “$TB_HOME/client/bin/gw4orcl”를 교체하고 ldd gw4orcl을 실행하여 “not found”가 발생하지 않는지 확인합니다.

• Tibero to MSSQL “$TB_HOME/client/bin/tbgateway.zip”을 교체합니다.

4) External Procedure를 사용 중일 경우

• C External Procedure so 파일이 $TB_HOME 내부에 존재할 경우 패치한 바이너리로 복사합니다.

• JAVA External Procedure class 또는 jar 파일이 $TB_HOME 내부에 존재할 경우 패치한 바이너리로 복사합니다. 아래와 같은 파일들의 설정 내용 파악 후 필요한 내용을 복사합니다.

Backup 받은 디렉터리 기준으로 변경사항을 다음과 같이 OS 명령어로 비교하며 변경사항이 있을 경우에만 원본 설정 파일을 Overwrite 합니다.

다음은 변경사항이 있을 경우 원본 설정 파일을 Overwrite 하는 예입니다.

5) ESQL/C, ESQL/COBOL을 사용할 경우

• ESQL/C $TB_HOME/client/config/tbpc.cfg 파일의 설정 내용 파악 후 필요한 내용을 복사합니다.

• ESQL/COBOL $TB_HOME/client/config/tbpcb.cfg 파일의 설정 내용 파악 후 필요한 내용을 복사합니다.

1. 환경설정 수행

교체된 신규 바이너리에 tip, tbdsn,tbr, psm_commands 생성을 위해 환경설정을 수행합니다.

다음은 환경설정 수행 예입니다.

1. 라이센스, tip, tbdsn.tbr, cfg 파일 교체

다음은 각 파일의 교체 방법 및 사용 예입니다.

• 라이센스 파일 다음은 라이센스 파일 교체 방법입니다.

다음은 사용 예입니다.

• Tip(=Tibero Init Parameter) 파일

다음은 tip 파일 교체 방법입니다.

다음은 사용 예입니다.

• tbdsn.tbr 파일

다음은 tbdsn.tbr 파일 교체 방법입니다.

다음은 사용 예입니다.

• cfg 파일

다음은 cfg 파일 교체 방법입니다.

다음은 사용 예입니다.

Active-Standby 패치 후 점검할 사항에 대한 자세한 설명은 UNIX(SINGLE) 패치의 “”을 참고합니다.

본 장에서는 Tibero 패치 과정을 요약하여 설명합니다.

다음은 Single과 TAC의 패치 과정 순서입니다.

1. 바이너리 준비

패치 바이너리를 패치 대상 서버에 FTP를 이용하여 옮깁니다.

1. INVALID Object 확인

1. Tibero 종료

TAC의 경우 모든 노드를 tbdown 한 후에 tbcm을 종료합니다.

1. Tibero 바이너리 백업

기존 Tibero 7 Backup 이름을 tibero7*<패치일자>*로 바꿔줍니다.

1. 패치 바이너리 설치

1. 환경설정 및 복원

• 설정

• 복원

1. Tibero 시작

TAC의 경우 모든 노드의 tbcm을 기동 후 tbboot합니다.

1. Dictionary 갱신

1. Object 재컴파일

1. INVALID SYNONYM 스크립트 수행

sys 계정이 아닌 계정에서 해당 스크립트를 수행합니다.

1. 패치 후 INVALID Object확인

1. Object 컴파일

1. Driver 갱신

필요한 경우 애플리케이션에서 사용하는 JDBC Driver나 ODBC DLL 파일을 신규 Driver로 갱신합니다.

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

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

개요

Redo 로그 파일은 최소 2개 그룹을 권장하며, Archivelog 모드인 경우 최소 3개 그룹을 권장합니다. 이는 Redo 로그가 순환할 때 rewrite 방지를 위한 hangup 현상을 막기 위함이며 최소 2개의 멤버를 권장합니다. 성능을 위해 각각 다른 물리 디스크에 배치하도록 합니다.

Redo 로그 파일의 크기를 사전에 정확하게 추측하기가 어렵기 때문에 수행하는 업무의 일부를 수행한 후 Redo 로그 양을 측정하고 전체 업무를 수행했을 때의 Redo 로그 파일의 크기를 예측하는 것을 권장합니다.

고려사항

아래는 Redo 로그 파일 크기를 산정할 때 고려할 사항입니다.

• 트랜잭션 처리 중 Log Switch가 발생하는 경우 트랜잭션 성능 저하가 발생합니다.

• OLTP 중심의 시스템에서 트랜잭션 처리의 피크 타임에 Log Switch가 빈번하게 일어나지 않도록 Redo로그 크기의 조정이 필요합니다.

• Redo 로그 파일의 크기가 크면 Log Switch 발생 가능성이 낮은 반면 Recovery 시간은 길어집니다.

위 고려 사항을 참고해서 다음의 모드 중에 하나를 선택합니다.

• LOGGING / NOLOGGING 모드

  • 테이블/인덱스에 대한 모든 변경사항은 기본적으로 Redo 로그로 기록되지만 NOLOGGING 테이블/ 인덱스에 대해 Direct-Path(DP) 방식으로 데이터를 추가하는 경우 Redo 로그를 기록하지 않습니다. DP에 대한 Redo 로그가 남지 않는 경우에 Media Recovery가 수행될 때 DP로 추가한 테이블 데이터 가 복구되지 않기 때문에 DP로 데이터를 추가한 후에는 백업을 받도록 권장합니다.

아래는 LOGGING 모드에서 하나의 DML당 로그 발생량 및 확인 방법입니다.

• 로그의 발생량을 DML 한 건으로 측정하기가 쉽지 않기 때문에 여러 건의 DML을 수행한 후 전체 로그 발생량을 측정해서 건수로 나누는 방법을 권장합니다.

• 로그 발생량은 v$sysstat 테이블의 'name' 컬럼이 'Redo log size'인 항목으로 확인 가능하며 alter system clear stat 명령으로 v$sysstat 테이블의 내용을 clear할 수 있습니다.

  • ARCHIVELOG / NOARCHIVELOG 모드 Redo 로그 파일은 Cache Recovery될 때 더 이상 필요없는 경우에 재사용됩니다. (일반적으로 3개의 Redo 로그 파일들을 생성해서 순차적으로 돌면서 재사용하는 구조입니다.)

Redo 로그에는 사용자 데이터에 가해지는 변경사항이 저장되며 DML의 종류에 따라 아래와 같은 내용이 저장됩니다.

추가로 아래와 같은 내용을 포함합니다.

• 트랜잭션 처리(begin/commit)를 위한 Redo 로그

• Segment의 공간 관리(extent add, block format, index split)에 대한 Redo 로그

• Undo 블록에 대한 변경사항

• 블록 내 각 ROW에서 수행했던 트랜잭션의 commit 여부를 확인하고 변경하는 Redo 로그

Redo 로그 파일에 쓰여지는 데이터량은 SQL 및 갱신 데이터량에 의해 크게 바뀌기 때문에 운영 전 사전에 정확한 추측이 불가능합니다.

시스템의 크기에 따라서 다음과 같이 사전 설정 후 실제 운영 중 REDO 발생량을 보고 조정해야 합니다.

table_migrator.zip 바이너리 압축 파일을 해제하면 다음과 같은 파일이 생성됩니다.

Redo Log Files, Undo 및 Temp 테이블 스페이스 그리고 메모리 영역의 크기 산정을 위해서는 먼저 Tibero의 특성에 대한 이해가 필요하며 관련 정보는 Tibero 관리자 안내서를 참고합니다.

또한, Table 및 Index 크기를 산정하기 위해 필요한 정보와 산정 방식은 Tibero의 Data Block Architecture 특성을 고려합니다.

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

Tibero 클라이언트는 데이터가 지정한 크기만큼 바인딩되기 전까지 서버로 업로드되지 않으므로 대용량 의 데이터를 업로드할 때 효율적으로 사용할 수 있습니다.

tbLoader에서 제공하는 아래의 옵션을 사용하여 이관합니다.

Tibero를 설치하기 위해서는 각 플랫폼별로 약간의 차이가 있지만 최소 2GB 이상의 하드디스크 여유 공간이 필요합니다. 이는 Tibero 설치 후 데이터베이스를 생성할 때 최소로 필요한 하드디스크 공간을 의미하기도 합니다.

Tibero 클라이언트 인스톨러를 이용해 설치하기 위해서는 JDK 1.5.17 이상이 반드시 설치되어 있어야 합니다.

[그림 1] JDK 설치 확인

Tmax group의 TechNet에서 회원가입 후 설치파일을 다운로드합니다.

Tibero 클라이언트 수동 모드 설치

1. 설치 파일을 준비합니다. Tibero 클라이언트를 설치할 폴더를 생성하고 압축을 해제하면 폴더들이 생성됩니다.

2. 환경변수를 설정합니다.

(1) Windows에서 [시스템 환경 변수 편집] -> [고급] -> [환경변수]를 선택한 후 [시스템 변수]를 설정합니다.

[그림 2] 시스템 변수 설정

(2) [환경변수]에서 [시스템 변수] -> [새로 만들기]를 선택 한 후 TB_HOME, TB_SID를 설정합니다.

[그림 3] TB_HOME, TB_SID 설정

(3) C:\Tibero 디렉터리에서 압축된 바이너리 실행 파일(tar.gz)을 해제합니다. 그 후에 %TB_HOME%의 license라는 하위 디렉터리에 발급받은 라이선스 파일(license.xml)을 복사합니다.

(4) tbinstall.vbs 실행 후 레지스트리 등록을 확인합니다.

[그림 4] 설치완료 확인창

레지스트리 확인(regedit)에서 HKEY_LOCAL_MACHINE\SOFTWARE\TmaxTibero\Tibero\tibero 경로에 TB_HOME과 TB_SID가 등록되었는지 확인합니다.

[그림 5] TB_HOME, TB_SID 등록 확인

(5) gen_tip.bat를 실행합니다.

(6) 필요없는 폴더를 제거합니다. bin과 client 폴더를 남기고 나머지는 제거합니다.

(7) 네트워크 파일(tbdsn)을 설정합니다. tbdsn.tbr 파일은 서버의 접속 경로를 설정하는 파일로 "%TB_HOME%\client\config"에 위치합니다.

(8) Tibero Client를 이용해서 Tibero Server로 접속합니다.

1. tbuninstall.vbs를 실행하여 레지스트리에서 제거합니다.

[그림 6] 제거완료 확인창

1. 물리 파일을 삭제합니다. %TB_HOME%으로 설정된 경로의 디렉터리를 삭제하여 Tibero 클라이언트를 삭제합니다.

Tibero Shared Memory는 부팅할 때 고정된 용도로 사용되는 Fixed 영역과 운영 중에 자동으로 할당되어 사용되는 Shard Pool 영역으로 구분할 수 있습니다.

• Fixed Memory DB가 부팅할 때 파라미터 값을 바탕으로 크기가 고정되는 영역입니다.

  • Buffer Cache(Database Buffer)

  • Log Buffer

다른 워킹 프로세스 및 워킹 스레드와 공유되지 않은 독립적인 메모리 공간으로 세부 영역은 다음과 같습니다.

• 세션 정보 영역 로그온 및 세션 관련 정보

• 커서 정보 영역 (SQL영역) SQL 문 처리할 때 필요한 메모리 공간

• SQL Work Area (SQL 작업 영역) Sort, hash-Join, Bitmap 생성 및 Merge(병합) 작업할 때 사용되는 메모리 영역

개요

기존 데이터베이스를 Tibero로 전환하는 Table Migrator 유틸리티에 대해 안내합니다.

특징

Table Migrator 유틸리티의 특징 입니다.

• Command 기반이며, 내부적으로 JAVA의 JDBC 드라이버를 이용하여 DBMS에 접속합니다.

• 별도 컴퓨터(클라이언트)가 필요하지 않으며 Source 또는 Target 서버에서 수행 가능합니다.

• 전체, 사용자별 이관은 불가능하며 Table 단위로 데이터 이관만 가능합니다. (스키마 객체 및 Table에 정의된 각종 제약조건은 전환되지 않음)

• 옵션을 사용하여 다양한 방법으로 전환이 가능합니다. (SELECT 옵션, DPL, P-DPL 지원)

아래는 Table Migrator 유틸리티 실행 전 준비사항 입니다.

• JRE 1.6 이상 설치

• Table Migrator 설치 전 아래의 파일이 준비여부 확인

  - table_migrator.zip : Table Migrator 바이너리

  - Source DB의 JDBC 드라이버

• Table Migrator 바이너리를 Source DB 또는 Target DB(Tibero)에 위치합니다.

• 이관 대상 Table을 생성 DDL을 이용하여 Target DB(Tibero)에 미리 생성합니다.

Table Migrator 유틸리티를 실행할 때 아래와 같은 사항에 유의합니다.

• Source DB의 Table을 이관할 경우 Target DB(Tibero)에 Tablespace, User, Table을 미리 생성 후 TableMigrator를 수행합니다.

• DBMS 접속 계정에 DBA 권한이 필요합니다.

만약, 고객사의 정책상 DBA 권한을 부여받지 못할 경우 이관 작업을 위한 사용자별 최소한의 권한 예시는 아래와 같습니다.

• long, longraw 컬럼을 지원하지 않습니다.

• index가 존재하는 Table일 경우 DPL 옵션을 사용하지 못합니다.

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

Tibero 클라이언트 수동 모드 설치

1. 설치 파일(tar.gz)과 라이선스 파일(license.xml)을 준비합니다.

1. 클라이언트 계정을 생성합니다.

$ useradd -d /home/tibero7_client -g dba tibero7_client
$ passwd tibero7_client

1. 바이너리 압축을 해제합니다.

1. profile을 설정합니다. 클라이언트 서버의 profile에 해당 내용을 환경에 맞게 수정한 후 추가합니다.

1. gen_tip.sh를 실행합니다.

1. 네트워크 파일 (tbdsn)을 설정합니다. tbdsn.tbr 파일은 서버의 접속 경로를 설정하는 파일로 $TB_HOME/client/config에 위치합니다. 아래와 같이 tbdsn.tbr 파일을 수동으로 설정합니다.

1. Tibero Client를 이용해서 Tibero Server로 접속합니다.

이기종 데이터베이스를 이관할 때 대용량 테이블이 있다면 이관 방법을 통해 수행 시간을 단축할 수 있습니다. 고객사의 환경(네트워크, Disk I/O, 데이터 속성)을 고려하여 적절한 방법을 선택합니다.

아래는 이관 방법들의 특징에 대한 설명입니다.