개요

본 문서에서는 아카이브 로그 사용량을 분석하여 아카이브 로그가 많이 발생하는 원인 분석 방법에 대해 안내합니다.

• 테스트 환경:  Tibero 7.2.3

방법

1. TIBERO 구성 및 파라미터 확인

(1) TIBERO 구성 확인

$TB_SID.tip 파일을 통하여 SINGLE / TSC / TAC 등의 TIBERO 구성 확인

(2) REDO 로그 구성 확인

REDO LOG THREAD / GROUP / SIZE 확인

SQL > select thread#, group#, bytes / 1024 / 1024 as "redo_size(MB)" from v$log order by thread#

   THREAD#     GROUP# redo_size(MB)
---------- ---------- -------------
        0          0           100
        0          1           100

2 rows selected.

(3) 아카이브 로그 파라미터 확인

아카이브 로그 경로 / 다중화 / 넷백업 / 덮어쓰기 관련 파라미터 확인

SQL > select name, value from V$PARAMETER where name like '%LOG_ARCHIVE%';

NAME                           VALUE
------------------------------ --------------------------------------------------
LOG_ARCHIVE_DEST               /tibero/tibero7/database/t2/archive/
USE_NBU_FOR_ARCHIVELOG         NO
STANDBY_LOG_ARCHIVE_FORMAT     st-t%t-r%r-s%s.arc
NBU_ARCHIVE_RETRY_CNT          2
NBU_ARCHIVE_POLICY_NAME        TIBERO_ARCHIVE_POLICY
NBU_ARCHIVELOG_SEARCH          NO
LOG_ARCHIVE_RETRY_TIME         3
LOG_ARCHIVE_OVERWRITE          NO
LOG_ARCHIVE_FORMAT             log-t%t-r%r-s%s.arc
LOG_ARCHIVE_DEST_9
LOG_ARCHIVE_DEST_8
LOG_ARCHIVE_DEST_7
LOG_ARCHIVE_DEST_6
LOG_ARCHIVE_DEST_5
LOG_ARCHIVE_DEST_4
LOG_ARCHIVE_DEST_3
LOG_ARCHIVE_DEST_2
LOG_ARCHIVE_DEST_1
FLASHBACK_LOG_ARCHIVE_FORMAT   fb-t%t-r%r-s%s.arc
FLASHBACK_LOG_ARCHIVE_DEST     /tibero/tibero7/database/t2/fb_archive/

2. TIBERO 디스크 사용량

(1) TIBERO 프로세스 FD 확인

아카이브 로그를 바라보고 있는 프로세스 확인

참고
아카이브 로그는 리두 로그 스위치 상황과 리커버리 외에 TIBERO 프로세스가 오픈하고 있지 않아야 합니다.

## lsof를 통한 FD 확인
$ lsof -u tibero |grep tbsvr |grep arc

## lsof 사용 불가인 경우 fuser로 특정 파일을 오픈하고 있는 프로세스 확인
$ fuser  *.arc

(2) TIBERO 디스크 사용량 확인

아카이브 로그 디렉토리의 크기 확인

참고
TAC의 경우 THREAD(node) 별로 아카이브 로그를 따로 생성하기 때문에 각 node의 경로 확인 필요합니다.

## THREAD#0 아카이브 로그 경로 확인
SQL > show parameter LOG_ARCHIVE_DEST
----------------------------------------------------------------------------------- -------- ---------------------------------------------------------------------------------
FLASHBACK_LOG_ARCHIVE_DEST                                                          DIRNAME  /tibero/tibero7/database/t2/fb_archive/
LOG_ARCHIVE_DEST                                                                    DIRNAME  /tibero/tibero7/database/t2/archive/

[tibero@devdb archive]$ df -h /tibero/tibero7/database/t2/archive/
Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/ol-root   44G   37G  7.3G  84% /



[tibero@devdb archive]$ pwd
/tibero/tibero7/database/t2/archive
[tibero@devdb archive]$ du -skh
82M

3. TIBERO 아카이브 로그 생성 주기

(1) V$ARCHIVED_LOG뷰를 통한 확인

참고
TAC의 경우 모든 node의 아카이브 로그 정보가 포함되어 있습니다.

## 일별 확인
SQL > select to_char(first_time, 'YY/MM') as archived_date,
 count(*)
        from v$archived_log
    group by to_char(first_time,'YY/MM');
       

ARCHIVED_DATE   COUNT(*)
------------- ----------
25/11                 11

## 시간 별 확인
SQL > select to_char(first_time, 'YY/MM/DD hh24') as archived_date, count(*)
        from v$archived_log
    group by to_char(first_time,'YY/MM/DD hh24');

ARCHIVED_DATE   COUNT(*)
------------- ----------
25/11/21              11

(2) iLOG 를 통한 분석

• iLOG의 경우 TAC 상에서는 node별로 발생하기 때문에, node 별로 수행이 필요합니다.
• 특정 시간을 주고 싶다면, tbiv -r 옵션을 사용합니다. 

$ tbiv -s -t                                   # 활성 iLOG 분석
$ tbiv -s -t backup_0908_093838/               # 특정 backup 디렉토리 분석
$ tbiv -s -t */*                               # 전체 backup 디렉토리 분석 
$ tbiv -s -t -r 20220908000000 20221109100000  # -r 옵션을 추가하여 위의 활성 또는 backup iLOG 분석

# 모든 backup 디렉토리의 월별 분석
$ tbiv -s -t */* 2>/dev/null \
|grep "LOG GROUP" \
|grep "ARCHIVED" \
|sed 's/\// /g' \
|awk '{print $1}' \
|sort |uniq -c 

# 특정 backup 디렉토리의 일별 분석
$ tbiv -s -t  backup_0908_093838/ 2>/dev/null \
|grep "LOG GROUP" \
|grep "ARCHIVED" \
|awk '{print $1}' \
|sort |uniq -c 

# 활성 된 iLOG 시간별 분석
$ tbiv -s -t  2>/dev/null \
|grep "LOG GROUP" \
|grep "ARCHIVED" \
|sed 's/:/ /g'  \
|awk '{print $1" "$2}' \
|sort |uniq -c

• iLOG 파일이 많은 상황에서는 tbiv 유틸리티가 segmentation fault 발생으로 실패할 수 있어, -r 옵션(range)과 iLOG 백업 디렉토리를 확인하여 분석에 필요한 범위를 출력하도록 진행하는 것을 권장 합니다.
• ulimit -a를 통한 open files가 낮으면 tbiv 유틸리티 수행 시 파일 오픈 개수 제한으로 에러가 발생할 수 있습니다.

4. TIBERO TPR을 통한 DML 확인

DML 사용량 확인

TPR의 INSERT / DELETE / UPDATE 사용량 확인

참고
TPR_SNAPSHOT_RETENTION 기한 내에서만 확인 가능합니다.

## TPR 추출 가능 범위 확인 
SQL > alter session set nls_date_format='YYYY/MM/DD HH24:MI:SS';
SQL > select 
thread#, min(begin_interval_time), min(end_interval_time)
        from 
_tpr_snapshot
    group by 
thread#;

## TPR 전체 instance 추출
SQL > alter session set nls_date_format='YYYY/MM/DD HH24:MI:SS';
SQL > exec dbms_tpr.report_text('날짜', '날짜');

## TPR 특정 instance 추출
alter session set nls_date_format='YYYY/MM/DD HH24:MI:SS';
exec dbms_tpr.report_text( '날짜', '날짜',instance_no=>'0');
exec dbms_tpr.report_text( '날짜', '날짜',instance_no=>'1');

## DML 횟수 확인, 출력 결과: DML TYPE  수행횟수 크기 시간
grep -E  "DML " TPR파일 |grep -v "time"

• TPR 정보는 TPR_SNAPSHOT 테이블에 남아있는 정보만 가져올 수 있어 한정적으로 활용 가능 합니다.

  TPR 내부에는 REDO SWITCH에 대한 성능 정보가 있기 때문에, TPR에서 아카이브 사용량 분석 관점으로 가용할수 있는 정보는 DML 수행 횟수 정도 입니다.

5. TIBERO 아카이브 로그 사용량이 높은 오브젝트 분석

(1) 아카이브 로그 덤프 추출

로그 스위치가 일어난 시점의 특정 아카이브 로그 분석

SQL > alter system dump logfile '아카이브로그 파일[절대경로]';
                              or
[아카이브로그 경로에서]
$ tblodump 아카이브로그 파일 >> [로그 덤프파일 받을 파일명]

(2) 아카이브 로그 덤프 파일 분석

# 출력 결과: cnt=횟수 smgt=세그먼트ID
$ grep -E "op=TD_DBLK" 덤프파일명 \
|grep -v "UNDO" \
|sed 's/=/ /g' \
|awk '{print $NF}' \
|sort -n \
|uniq -c \
|sort -r

결과예시)
1003 [0|00_00010492]
 951 [0|00_00010493]
 841 [0|00_00001315]
 
 ...

(3) 덤프 분석 결과를 통한 세그먼트 ID로 OBJECT 확인

SQL > select 
owner, object_name, object_type, object_id 
        from 
dba_objects
       where
 object_id in (세그먼트ID);

참고

아카이브 로그 사용량을 줄이기 위해서는 DML 스타일 변경 / 배치 작업 수정 / 데이터 삭제 방법 변경 등
업무 서비스와 관련 애플리케이션의 대한 이해도가 높아야하며, TIBERO 엔지니어의 관여부분은 많지 않습니다.  

가장 기본적으로 아카이브 로그 백업 주기를 짧게 설정할 수 있는 정책수정을 하도록 권장합니다.