개요

본 문서에서는 동일 Major Version에서의 패치 시 사전 점검, 진행 순서, 사후 점검 사항에 대해 기술합니다. 

이후 기술 되는 내용은 아래와 같이 동일 Major Version에 대해서만 유효합니다.

[표] 버전 별 패치 가능 여부

방법

Patch전 권장 사항

Tibero Patch시에는 DB를 사용하는 모든 Application을 Down 이후 동작 세션 없이 
작업하기를 권장합니다.

세션 조회는 tbsql 관리자 계정 (sys) 으로 접속 이후 select * from v$session 조회하여 Application에 해당하는 Session이 없어야 정상적으로 Patch 수행이 가능합니다.

select * from v$session;

#	SID	SERIAL#	AUDSID	USER#	USERNAME	IPADDR	COMMAND	STATUS	SCHEMA#	SCHEMANAME	TYPE	SQL_ID	SQL_CHILD_NUMBER	SUB_SQL_ID	SUB_CHILD_NUMBER	PREV_SQL_ID	PREV_CHILD_NUMBER	SQL_ET	LOGON_TIME	STATE	WLOCK_WAIT	SEQ#	WAIT_EVENT	WAIT_TIME	LAST_WAIT_EVENT#	LAST_WAIT_EVENT	LAST_WAIT_TIME	LAST_WAIT_TIME_MICRO	TIME_SINCE_LAST_WAIT	TIME_SINCE_LAST_WAIT_MICRO	LATEST_STAT#	PGA_USED_MEM	SQL_TRACE	PROG_NAME	CLIENT_PID	PID	WTHR_ID	OS_THR_ID	OSUSER	MACHINE	TERMINAL	MODULE	ACTION	CLIENT_INFO	CLIENT_IDENTIFIER	PDML_ENABLED	PDML_STATUS	PDDL_STATUS	PQ_STATUS	ROW_WAIT_OBJ_ID	ROW_WAIT_FILE_NO	ROW_WAIT_BLOCK_NO	ROW_WAIT_ROW_NO	CONSUMER_GROUP	CONSUMED_CPU_TIME
1	114	37,864	4,294,967,295	0	SYS	192.168.141.9	1	RUNNING	0	SYS	WTHR	c7t6usrtg4qya	212	c7t6usrtg4qya	212	9g6pyx7qz035v	199	0	2026/04/15	RUNNING	<NULL>	368	-1	0	55	WE_WTHR_RECV	29,151	29,151,264	0	101	12,845	207,208	DISABLED	Studio	-1	507,197	1	507,299	krocd	mj	<NULL>	<NULL>	<NULL>	<NULL>	<NULL>	NO	DISABLED	ENABLED	ENABLED	-1	<NULL>	<NULL>	<NULL>	<NULL>	19
2	115	38,199	4,294,967,295	0	SYS	127.0.0.1	0	READY	0	SYS	WTHR	<NULL>	<NULL>	<NULL>	<NULL>	<NULL>	<NULL>	0	2026/04/15	RECV_WAITING	<NULL>	0	55	50	55	WE_WTHR_RECV	5,072	5,072,371	0	0	11,810	110,640	DISABLED	tbsql	758,487	507,197	2	507,307	jsb	localhost.localdomain	pts/31	<NULL>	<NULL>	<NULL>	<NULL>	NO	DISABLED	ENABLED	ENABLED	-1	<NULL>	<NULL>	<NULL>	<NULL>	0

Patch를 진행 전 Application 담당자들에게 미리 Patch된 JDBC Driver 또는 ODBC Driver 를 전달 후
Applicateion 테스트를 진행하는 것이 좋습니다.

Patch전 점검 사항

패치 전에 반드시 점검해야 될 Checklist 입니다.

Super User 계정 Password 확인

system.sh 수행이 필요하기 때문에 SYS, SYSCAT 사용자의 계정 정보가 반드시 필요합니다.
 

Object Validation 파악

모든 Object 상태 및 수량을 파악합니다.

(Patch후 Object 의 상태가 Valid 에서 Invalid 가 될 경우 확인 목적의 파악입니다.)

[Object Validation Check Count]

COL OWNER FORMAT A20 
SET PAGES 500

SELECT OWNER, OBJECT_TYPE, STATUS, COUNT(*)  
FROM DBA_OBJECTS
GROUP BY OWNER, OBJECT_TYPE, STATUS
ORDER BY OWNER, OBJECT_TYPE, STATUS;

[Check Invalid Object List]  

SET LINESIZE 120
COL OBJECT_NMAE FORMAT A30
COL OWNER FORMAT A20

SELECT OWNER , OBJECT_NAME, OBJECT_TYPE, STATUS 
FROM DBA_OBJECTS  WHERE STATUS = 'INVALIED';  

[Trigger Enable 상태 확인]  

SELECT * FROM DBA_TRIGGERS;

TableSpace의 Datafile 경로 확인

DBA_DATA_FILES 테이블 을 조회하여 경로 확인이 가능합니다.

Datafile 위치가 $TB_HOME 내부 Directory 존재하는지 에 따라 절차가 변경되기에 수행전 조회해야합니다.

$TB_HOME 내부 Directory에 위치 한 경우 Binary 교체 시 해당 datafile도 같이 Copy 또는 Move 해야합니다.

SET LINESIZE 120
COL FILE_NAME FORMAT A100
 
SELECT FILE_NAME FROM DBA_DATA_FILES;

DB Link 사용 여부 확인

$TB_HOME/client/config/tbdsn.tbr 확인 합니다.

Gateway Process 실행 여부 확인 합니다.

위 경우가 포함될 시 반드시 설정 파일의 Backup 필요합니다.

External Procedure 사용 여부 확인

$TB_HOME 내부에 Class 또는 So 파일이 존재하는지 확인 후 Copy 또는 Move 해야 합니다.

JEPA 사용 여부 확인 필요하며 tip 파일 내의 _PSM_BOOT_JEPA=Y 여부를 확인 합니다.

JAVA의 Class 위치는 Tip파일 내의 JAVA_CLASS_PATH로 확인 합니다.

/* C External Procedure */

SET LINESIZE 120
COL OWNER FOR A10
COL LIBRARY_NAME FOR A30
COL FILE_SPEC FOR A50
COL STATUS FOR A10
 
SELECT OWNER, LIBRARY_NAME, FILE_SPEC, STATUS      
FROM DBA_LIBRARIES;

/* JAVA External Procedure*/  

SET LINESIZE 120
COL OWNER FOR A10
COL NAME FOR A30
COL SOURCE FOR A50

SELECT OWNER, NAME, SOURCE 
FROM DBA_JAVA_CLASSES;

ESQL, CESQL, COBOL 사용 여부 확인

외부 AP에 대한 확인 담당자를 통해서 사용 여부를 확인합니다.

Patch 진행

환경 설정 방법

Patch List를 관리하여야 하며, 사전 테스트 장비에 먼저 적용 후 일정 기간 모니터링 후 영향 분석 
완료되면 운영 시스템에 적용할 수 있도록 합니다.
 

운영 중인 DBMS의 경우 공지를 통하여 일정한 시간대에 접속을 제한합니다.
 

Tibero 데이터베이스는 Tibero6 이하 버전에 대하여 수작업으로 직접 패치 진행합니다.

Tibero7부터는 패치 Utility인 T-Patch를 제공합니다.

운영 절차

1. Tibero Patch전 상황 점검 (패치 전 점검 사항 참조)
2. Binary파일 준비
3. Tibero서비스 정지
4. Tibero바이너리 교체
5. license 및 tip, tbdsn.tbr 파일 교체

특이 사항 검토

• Tibero 서비스 시작
• system.sh shell 파일 실행
• ALTER SYSTEM RECOMPILE ALL; 실행
• Patch 후 작업(패치 후 점검 사항 항목 참조 바랍니다.)
• Patch 준비 (신규 Tibero binary를 서버에 업로드 합니다.)

Tibero DBMS Shutdown

Tibero Down Script 를 통해 Tibero DBMS를 Shutdown 합니다.

$tbdown immediate

Patch 및 Bug Fix Binary 교체

기존의 Tibero binary 폴더를 다른 이름으로 변경합니다. (mv tibero7 tibero7_20231129)

새로운 Tibero binary 파일의 압축을 해제합니다.

license 및 tip, tbdsn.tbr 파일 교체

기존 Binary파일에서 License파일, TIP파일, tbdsn.tbr파일을 신규 Binary파일에 복사합니다.

특이 사항 검토

데이터 파일이 Tibero Binary 내부 존재

데이터 파일이 Tibero Binary 내부 존재 시 $TB_HOME 내부의 동일 경로에 mv 또는 copy 명령어 수
행, 외부에 존재할 땐 백업 여부는 선택적으로 수행합니다.

DB Link

DB Link를 사용 중이라면 Gateway에 대하여 Binary Patch가 필요할 수 있습니다.

Tibero To Oracle : $(TB_HOME)/client/bin/gw4orcl 교체 (ldd gw4orcl 실행하여 not found가 발생하지 않는지 확인)

Tibero to MSSQL : $(TB_HOME)/client/bin/tbgateway.zip 교체(DB Link용 Gateway Patch 시에는 기존 Binary Backup 이후 수행필요)

External Procedure

C External Procedure: So 파일이 $TB_HOME 내부 존재 시 복사가 필요합니다.

JAVA External Procedure : Class 파일이 $TB_HOME 내부 존재 시 복사가 필요합니다.

$TB_HOME/client/tbepa/java/config/tbepa.cfg설정내용 파악 후 필요 내용 복사가 필요합니다.

ESQL/C, ESQL/COBOL 사용 시

ESQL/C: $TB_HOME/clinet/config/tbpc.cfg 설정 내용 파악 후 필요 내용 복사가 필요합니다.

ESQL/COBOL: $TB_HOME/clinet/config/tbpc.cfg 설정 내용 파악 후 필요 내용 복사가 필요합니다.

Tibero 기동

$ tbboot

Port 변경 후 작업 (선택사항)

DB를 사용하는 모든 Application Down 했다면 무방하나 해당 Application 을 Down하지 못할 때에는 임시적으로 Service Port를 변경하여 작업하고 Patch 완료 후에 원래의 Service Port로 변경합니다. 
 

Patch 수행

TIP 파일의 LISTENER_PORT부분 수정: $TB_HOME/config/$TB_SID.tip
 

Client 의 DSN 수정:$TB_HOME/client/config/tbdsn.tbr 파일의 $TB_SID (서비스 ID)에 해당하는 alias 부분의 PORT 부분 수정
 

system.sh shell 파일 실행(Window OS 버전일 경우 system.vbs)

system.sh 실행하여 Tibero 내부 사용하는 Object들 재생성합니다.

[예제] system.sh 실행
 

$ cd $TB_HOME/scripts

$ system.sh

  * sys password 입력 (defalt :tibero)
  * syscat password 입력 (defalt :syscat) 

주의

진행 로그 파일 확인 : $TB_HOME/instance/$TB_SID/log/system_init.log

정상적으로 수행 되지 않았을 경우 로그 발생: “TBR-17001”, “TBS-70004”

모든 PSM recompile 

ALTER SYSTEM RECOMPILE ALL; 실행모든 PSM recompile 동작을 수행합니다.

적용되는 패치 에 따라 시간이 오래 걸릴수도 있습니다.
 

PSM Compile시 BCODE를 생성하여 Data Dictionary(DD)에 저장을 하는 구조임 Patch가 되면서 생성되는 CODE가 변경 됐을 가능성 때문에 수행합니다.

[예제] PSM Recompile

$ tbsql sys/tibero

SQL> ALTER SYSTEM RECOMPILE ALL;

Patch 후 점검 사항

Invalid Object 확인

패치 전 점검 내역의 Object Validation 결과를 확인합니다.

Synonym Invalid 처리

PUBLIC의 Synonym 부분은 정상 Synonym 일 경우 추후 사용 시 자동으로 Valid하게 되므로 
Invalid 된 부분Skip 해도 무방합니다. 그래도 진행하고 싶다면 아래의 내용을 수행합니다.

$ cd $TB_HOME
$ tbsql sys/tibero 

SQL> @scripts/pkg/pkg_synoym.sql 
SQL> @scripts/pkg/pkg_synoym2.sql 
SQL> @scripts/pkg/pkg_dbms_redefinition.sql 
SQL> @scripts/create_gis.sql

View Invalid 처리

View일 경우도 정상적인 View 일 경우 추후 사용 시 자동으로 Valid하게 되므로 Invaild된 부분 
을 생략해도 됩니다. 그래도 진행하고 싶다면 아래의 내용을 수행합니다.

SQL> SELECT * FROM <VIEW_NAME> WHERE ROWNUM < 1;

PSM Invalid 처리

Procedure, Function Invalid 시 아래의 내용을 수행합니다. (해당 user에서 수행) 

SQL> ALTER FUNCTION <FUNCTION_NAME> COMPLIE;
SQL> ALTER PROCEDURE <PROCEDURE_NAME> COMPLIE;

FBI(Function Based Index)의 경우 Patch시 Invalid 가능성 있는 경우 아래의 내용을 수행합니다.
(해당 user에서 수행)

SQL> ALTER INDEX <FBI_INDEX_NAME> REBUILD;

Package Invalid 처리

Package Invalid 처리의 경우 complie body 를 활용해 valid 상태로 변경합니다.

SQL> ALTER PACKAGE <PACKAGE_NAME> COMPLIE BODY;

Trigger Disabled 처리

이전 Trigger 상태 확인 후 enable인 경우 아래의 구문을 실행합니다.

SQL> ALTER TRIGGER <TRIGGER_NAME> ENABLE;

Port 변경을 하였다면, 원래의 Service Port로 변경

Patch를 진행하면서 Port변경 했을 때 에는 기존 사용하던 Port로 전환합니다.

Application Driver Patch

JDBC, ODBC, OLEDB 고려 사항

Tibero Driver에서는 하위 호환성은 지원을 하나, 상위 버전의 호환성은 지원이 안되는 경우가 발생 
가능성이 있습니다.

Driver가 변경 가능하다면 Patch Version에 맞추어 주는 것이 좋습니다.

ODBC 및 OLEDB는 Uninstall 이후 Install을 권고합니다. (Window인 경우)

외부 클라이언트 제공된 경우 클라이언트 패치

외부 연동 AP서버에 Tibero 클라이언트 설치된 경우 해당 client도 패치 하는 것을 권고합니다.

데이터베이스 서버에 패치 된 Revision으로 해당 OS 및 Bit에 맞는 Client Binary파일을 받아서 패치를 진행합니다.

Tibero Patch 복원

복원 이 필요할경우 복원을 수행하는 방법에 대해 기술합니다.

복원 순서도 패치 순서와 동일하다. 단, License, TIP, tbdsn등의 파일을 따로 copy할 필요가 없습니다.

1. Tibero서비스 정지
2. Tibero과거버전으로 Binary 파일로 교체
3. Datafile 경로 고려
4. Tibero서비스 시작
5. system.sh shell 파일 실행
6. ALTER SYSTEM RECOMPILE ALL; 실행
7. Patch 후 작업(점검 사항)

모든 Datafile(System, Undo, Temp, User Datafile등), Control file 등을 Backup 이후 Patch를 진행했다면 
해당 파일로 복구 후에 4번 까지만 수행해주면 됩니다. 위 경우가 아니라면, 
7번 (Patch 후 작업(점검 사항) 까지 수행합니다.