[Tibero] 티베로 Troubleshooting 가이드

tberr

- tberr 명령어는 Tibero 서버 또는 클라이언트가 설치된 환경의 OS 명령어 창에서 수행한다.

- 명령어를 통해 에러 코드의 원인 및 조치 방법 등을 확인할 수 있다.

 

에러 코드 디버깅

1) sys.log에 발생하는 Tibero 에러에 대해 확인이 필요한 경우.

2) 사이트 담당자가 에러 코드를 유발시키는 쿼리 확인 방법 문의하는 경우.

사용 구문

ALTER SYSTEM DUMP CALLSTACK ON ERROR “에러코드” ON/OFF;

주의 사항

- CALLSTACK ON ERROR에서 설정한 에러 발생 시에 callstack 파일 및 dump 파일 생성.

- 에러 발생 할 때 마다 파일들이 생성되며, Error가 수차례 발생시에 대량의 dump 파일 생성.

     (sys.log 모니터링 및 dump 확보 후 CALLSTACK ON ERROR 설정 OFF 필요.)

 

Example : sys.log에 ERROR_DT_OUT_OF_RANGE_DT_INPUT(-5114) 에러 발생.

- sys.log

- callstack on 설정

SQL> ALTER SYSTEM DUMP CALLSTACK ON ERROR -5114 ON;

-생성 되는 파일

1) tracedump

    - 에러 발생을 유발한 Query를 확인할 수 있으며, 에러 발생 시의 생성된 callstack 파일 확인 가능.

    - 파일 생성 경로 : TRACE_DUMP_DEST 파라미터로 확인 가능.

             (default 경로 : $TB_HOME/instance/$TB_SID/dump/tracedump)

 

  Ex)

2) callstack 파일

    - tbsvr.callstack.xxx 패턴의 파일 생성.

    - 파일 생성 경로 : CALLSTACK_DUMP_DEST 파라미터로 확인 가능.

                           (default 경로 : $TB_HOME/instance/$TB_SID)

추가 학습 권장 내용

1) ALTER SYSTEM DUMP 관련 CALLSTACK ON ERROR 뿐만 아니라, 상황에 맞는 여러 옵션 존재.

https://bingo6681.tistory.com/150

[Tibero] Tibero Dump 가이드

 

2)

ALTER SYSTEM DUMP 구문이 아닌 OS 창에서 원하는 proces의 callstack을 확보할 수 있는 방법 확인 필요.

  cf) pstack

https://bingo6681.tistory.com/134

[Tibero] 정기점검 정리

 

Blocking lock & Deadlock

 

Lock

데이터베이스는 여러 사용자들이 같은 데이터를 동시에 접근하는 상황에서,

데이터의 무결성과 일관성을 지키기 위해 락(lock)을 사용.

 

Blocking

Lock 간의 경합이 발생하여 특정 Transaction이 작업을 진행하지 못하고 멈춰선 상태를 말한다.

공유 락(Shared Lock)끼리는 블로킹이 발생하지 않지만, 베타 락(Exclusive Lock)은 블로킹을 발생.

 

상황

116번 session	117번 session
update test         set c1=10         where c2='a'; 1 row updated.
	update test         set c1=100         where c2='a'; (hang …)

lock 정보 조회 (tm 41)

 

조치 방안

    - blocking session 정리.

1) tx 완료 처리 (commit or rollback)

2) blocking 세션 킬

(alter system kill session (session_id, serial_no); )

 

Deadlock

교착상태는 두 트랜잭션이 각각 Lock을 설정하고 서로의 Lock에 접근하여 값을 얻어오려고 할 때,

이미 각각의 트랜잭션에 의해 Lock이 설정되어 있어 양 트랜잭션 모두 영원히 처리가 되지않게 되는 상태.

 

상황

116번 session	117번 session
update lock_test1         set c1=10 ; 2 row updated.
	update lock_test2         set c1=100 ; 2 row updated.
update lock_test2         set c1=100 ; (hang …)
	update lock_test1         set c1=10 ; TBR-12032: Deadlock detected.

sys.log

로그 확인

WLOCK  TYPE이 모두 WLOCK_TX 인 경우는 TX 끼리의 deadlock이 발생했다는 의미로, 우선 AP 쪽의 코드에서 서로 다른 세션이 로우를 update하는 순서가 반대인 경우가 없는지 확인이 필요.

 

추가 학습 권장 내용

1.spinlock 개념 확인 필요.

 

2.session kill 수행이 권장 / 비권장 인지 확인 및 해당 이유 확인.

 

 

 

Session Full 에러 발생

- $TB_SID.tip 파일 상의 MAX_SESSION_COUNT 값 초과한 SESSION 접속 시 에러 발생.

 

- session full 상황에서 문제 여부 판단을 위해서는 DB에 연결이 필요.  이런 경우 Special Port 사용.

 

스페셜 포트

- 스페셜 포트는 Session Full과 같은 상황에서 응급조치를 하기 위해 사용하는 포트.

default 값 : LISTENER_PORT + 1 (_LSNR_SPECIAL_PORT 로 변경 가능.)

 

- 스페셜 포트를 이용해 DB 접속을 위해서는 $TB_HOME/client/config/tbdsb.tbr 설정 필요.

  (special port를 사용하는 alias 정보 설정)

 

Ex) special 이라는 alias를 사용  /   Tibero 접속 시 tbsql 유저명/패스워드@special 로 접속

 

Session Full 이지만 DB에 연결할 수 있는 이유

- 스페셜 포트는 Working Process가 아닌 TBMP 프로세스를 이용하여 DB에 접속.

 

 

 

테이블 - 인덱스 정합성

인덱스(INDEX)

- 인덱스는 데이터가 위치한 장소의 정보를 가진 일종의 주소록으로, 데이터의 주소(ROWID)를 가지고 있음.

 

 

인덱스 정합성 문제 발생 시 상황

1)Inter Error 발생.

2)테이블 조회 결과 건수의 차이 발생.

    (읽는 인덱스 사이의 조회 건수 차이 발생, Full scan / Index scan 사이의 조회 건수 차이 발생 등.)

3) 테이블 dml 수행 시 hang 발생.

4) etc

 

정합성 확인 하는 방법

      - DBMS_VERIFY 패키지 사용

 

1)SCHEMA_INDEX : 해당 스키마에 존재하는 모든 인덱스의 정합성을 검사하는 함수.

         : DBMS_VERIFY.SCHEMA_INDEX(‘유저명’) 프로시저 사용.

 

   Ex) TIBERO 유저의 모든 인덱스의 정합성을 검사하는 경우.

SET SERVEROUTPUT ON
EXEC DBMS_VERIFY.SCHEMA_INDEX('TIBERO');

 

 

2)TABLE_INDEX : 해당 테이블에 존재하는 모든 인덱스의 정합성을 검사하는 함수

     : DBMS_VERIFY.TABLE_INDEX(‘유저명’,’테이블명’) 프로시저 사용.

 

   Ex) TIBERO 유저의 TEST 테이블의 모든 인덱스의 정합성을 검사하는 경우.

        

SET SERVEROUTPUT ON
EXEC DBMS_VERIFY.TABLE_INDEX('TIBERO','TEST');

 

 

3) INDEX : 해당 인덱스의 정합성을 검사하는 함수

             : DBMS_VERIFY.INDEX(‘유저명’,’테이블명’,’인덱스명’) 프로시저 사용.

 

   Ex) TIBERO 유저의 TEST 테이블의 인덱스 중 TEST_IDX01의 정합성을 검사하는 경우

       

SET SERVEROUTPUT ON
EXEC DBMS_VERIFY.INDEX('TIBERO','TEST','TEST_IDX01');

주의 사항

- DBMS_VERIFY 수행 시 반드시 SERVEROUTPUT 변수를 활성화 시켜야 한다.

   (해당 변수를 활성화 시켜야만, 정합성 확인 프로시저의 결과가 출력된다.)

 

추가 학습 권장 내용

1. 인덱스 개념 및 실습

    - 종류, 생성 하는 방법, 개념 등 학습 필요.

 

2. 플랜, 힌트 개념에 대한 기본적인 개념 확인 필요.

    - FULL SCAN , INDEX SCAN 등과 같은 용어에 대한 기본적인 개념 학습.

    - 힌트 주는 법에 대한 기본적인 개념 확인.

 

 

 

 

공간 부족 – Disk 상황

- DB Hang 현상 발생.

원인

- 서버 disk full 발생 원인의 대다수는 Archivelog 누적 용량으로 인해 disk full 발생.

  (간혹 Tibero 로그 누적으로 발생할 수도 있으니 체크 필요.)

 

Archivelog 파일 삭제 기준

- 온라인 백업 시점 이전 최소 redo log 그룹 수 만큼의 Archivelog는 남겨야 한다.

 

 

 

 

공간 부족 – Tablespace 상황

- 데이터 입력 실패. (Insert 수행 중 에러 발생으로 작업 취소 등)

원인

- 데이터를 입력하고자 하는 Table이 사용하는 Tablespace의 여유공간이 부족한 경우 발생.

조치 방안

- Tablespace가 부족한 경우 1) Datafile 추가 2) Datafile Resize 등의 방법이 있으며,

     보통 Datafile 추가로 조치를 취한다.

- Datafile 추가 하는 법.

ALTER TABLESPACE <테이블스페이스이름> ADD DATAFILE </파일 경로/파일명> SIZE <원하는 크기>;

 

Autoextend On / Off

	Autoextend
	ON	OFF
장점	관리의 편리	next 값 증가에 따른 지연 미발생.
단점	반복적인 next 값 증가에 따른 지연 (부하 발생)	관리 포인트 발생.

 

추가 학습 권장 내용

1. 테이블스페이스의 논리적 / 물리적 구성 이해.

Cf)  Tibero 관리자 안내서

 

2. 백업 & 복구 개념 학습.

   - 논리적 백업 / 온라인 백업 / 오프라인 백업 등

 

3. Tablespace Resize 학습.

   - 시스템 테이블스페이스(UNDO, TEMP 등)일 경우와 비시스템 테이블스페이스 일 경우로 나눠서 확인해보기.

 

4. raw device 개념 학습.

 

 

문자 깨짐 상황

- 클라이언트 통해서 Tibero DBMS에서 데이터 입출력 시 문자열이 깨지는 현상 발생.

   (문자열 깨지는 문제 중 많은 케이스가 한글 데이터 문제.)

- 문자열이 깨지는 이유는 결국 Client – DB 사이의 캐릭터셋 문제.

 

한글 지원 CHARACTER SET

-MSWIN949, EUC-KR (한글 1글자 당 2bytes)

-UTF8 (한글 1글자 당 3bytes)

 

TB_NLS_LANG

- 클라이언트에서 사용하는 캐릭터 셋.

(Default TB_NLS_LANG 의 경우 Tibero6  : MSWIN949 / Tibero7 : UTF8)

TB_NLS_LANG 설정

1. tbdsn.tbr 파일에 설정.

2. OS에 설정.

 - export 명령어 수행 또는 .bash_profil에 설정.

 

Cf) 주의 사항

tbdsn.tbr 또는 OS 레벨로 TB_NLS_LANG 파라미터 설정 시  해당 내용을 읽는 모든 클라이언트에 적용됨.

 

 

 

 

DB 서비스 지연

서비스가 지연되는 경우는 여러 문제가 혼합되어 있는 경우가 많아, 항상 똑같은 문제라고 볼 수 없다.

따라서 해당 문제의 확인을 위해서는 아래의 방법을 모두 숙지해야 한다.

 

1. DB 서버 전체의 성능 분석.

2. 특정 업무(쿼리)의 수행 성능 확인. 

 

DB 서비스 지연 - DB 서버 성능 분석

TPR ( Tibero Performance Repository)

- Tibero DBMS가 자체적으로 수집하는 통계 정보를 기반으로 시스템 부하 분석에 도움을 줄 수 있는 기능.

DBMS_TPR

    - 관련 테이블 : _TPR_SNAPSHOT

 

1. CREATE_SNAPSHOT 

TPR을 위한 스냅샷을 남기는 프로시저

수행 예제

exec DBMS_TPR.CREATE_SNAPSHOT();

2. REPORT_TEXT 

- 특정 구간의 성능 분석 리포트를 생성하는 프로시저.

수행 예제

exec DBMS_TPR.REPORT_TEXT('2023/01/01 12:00:00', '2023/01/02 11:59:59');
exec DBMS_TPR.REPORT_TEXT('2023/01/01 12:00:00', '2023/01/02 11:59:59', file_name=>'tpr.txt');

주의사항) 리포트 생성 시 END_TIME에는  _TPR_SNAPSHOT 조회 시간에서 1초를 빼야 한다.

 

 

DB 서비스 지연 – 쿼리 성능 분석

쿼리 성능 분석

패치 및 업그레이드와 같이 DBMS의 옵티마이저 변화로 인한 쿼리 성능 변경이 발생할 경우,

쿼리의 성능 분석을 위해 실행 계획을 확인 해야한다.

 

실행 계획 확인하는 방법

1) SET AUTOTRACE

2) SQL TRACE

 

SET AUTOTRACE

-  AUTOTRACE : 수행 중인 질의의 플랜이나 통계 정보를 보여준다.

SET AUTOTRACE 예제

 

SQL TRACE 

- SQL 실행 과정을 TRACE 파일로 남기는 기능으로, 수행하고자 하는 쿼리의 실행 정보를 Profiling 하는데 사용.

- SQL TRACE 기능은 파라미터를 통해 활성화 가능. (파라미터 : SQL_TRACE [SESSION, SYSTEM 단위 가능] )

- 파일 생성 경로 : SQL_TRACE_DEST 파라미터로 확인 가능.                     

                        (default 경로 : $TB_HOME/instance/$TB_SID/log/sqltrace)

- TRACE 파일 확인 방법 : tbPROF 사용.

 

SQL TRACE 예제

- sql_trace=y 설정 후 쿼리 (select * from v$session) 수행.

 

- 생성된 sql trace 파일

- tbprof 변환

cat tb_sqltrc+10967_54_555.trc

cat test.log

추가 학습 권장 내용

1. DBMS_TPR 패키지 매뉴얼에서 찾아보고 학습.

    - REPORT_ID 프로시저를 이용한 리포트 생성 실습 등.

 

2. TPR 레포트 분석하는 연습.

 

3. SET AUTOTRACE 관련 다른 옵션들 학습.

 

4. PP Dump 확보하는 법 연계 학습.