mellowg

Tibero Backup & Recovery 

Backup & Recovery 개요

• 백업과 복구는 여러 가지 유형의 장애(시스템 장애, 미디어 장애, 사용자 실수 등)로부터 데이터베이스를 보호하는 핵심적인 기능이다.
  • 보호 대상 장애 유형
    1. 하드웨어 장애 : 디스크 손상, 서버 다운 등
    2. 소프트웨어 장애 : DBMS오류 등
    3. 사용자 오류 : 실수로 인한 데이터 삭제, 잘못된 UPDATE/DELETE 실행 등
    4. 재해 상황 : 화재, 정전, 천재지변 같은 예기치 못한 사건
• 백업의 역할
  • 데이터 복원 지점 확보 : 특정 시점의 데이터 상태를 보관
  • 서비스 연속성 보장 : 장애 발생 시 신속한 복구 가능
  • 데이터 손실 최소화 : 장애 발생 이후 손실되는 데이터를 최소화
• 복구의 역할
  • 장애 직전 시점으로 데이터 회복 : Redo/Undo 로그를 이용해 트랜잭션 적용/취소
  • 업무 중단 시간 단축 : 백업 및 복구 전략에 따라 다운타임 최소화
  • 데이터 무결설 보장 : 복구 과정에서 트랜잭션의 일관성과 무결성을 유지
• 관리자는 시스템 장애 시 발생할 손실을 최소화하고 복구 가능한 상태로 데이터베이스를 운용해야 한다.
  • 최소한 한 달에 한번 데이터베이스 전체 백업
  • 하루에 한번씩 Export 백업 권장
• 데이터베이스 관리자는 백업에 대한 정책을 수립하고, 꼭 필요한 데이터를 최소한의 양으로 백업
  • 백업은 DBA의 주요 역할 중 하나로, 가장 주의가 필요하다.
• "RECOVERY에 실패한 DBA는 용서할 수 있지만, BACKUP을 실패한 DBA는 용서할 수 없다."
• 백업이 정상적으로 수행되었는지 주기적인 검증 권장

▶️ 백업은 예방(사전 대비)이고, 복구는 대응(사후 처리)의 개념이라고 할 수 있다.

여러가지 유형의 장애

#1 명령문의 실패 

명령문의 실패 원인에는 다음과 같은 것들이 있다.

• 테이블의 제약 조건에 위배되는 데이터 INSERT
• 권한의 부족
• 테이블 생성 시 또는 데이터 변경 시 테이블스페이스의 공간이 부족한 경우

이러한 장애는 데이터 유실과는 관련이 없는 에러이다.

#2 사용자 프로세스의 실패

• 비정상적인 종료로 인한 사용자 프로세스의 실패가 대부분
• Tibero 의 monitor process가 비정상적인 종료를 감지하고 수행중인 트랜잭션 등은 롤백시킨다.

#3 사용자로 인한 장애

• 장애 발생 상황
  • DROP TABLE
  • TRUNCATE TABLE
  • DELETE FROM & COMMIT
  • 잘못된 UPDATE & COMMIT
• 해결 방안
  • 사용자에 대한 교육 실시
  • 백업에서 복구
  • Export 받은 파일에서 테이블을 Import
  • Time-based 불완전 복구

#4 Instance Fail

• 정전, CPU나 Memory Fault, Background Process의 비정상적인 종류가 대부분이다.
• 복구
  • 특별한 복구 작업이 필요하지 않음
  • tbboot을 통해 DBMS를 기동하면 자동으로 복구됨
  • 로그 등을 참고하여 원인 분석

#5 Media Fail

• 데이터파일이 저장된 하드 디스크의 장애
• 데이터 파일의 삭제
• 정해진 복구 전략에 따라 복구 절차가 필요
• Media Fail은 반드시 발생할 수 밖에 없다. 하드디스크에도 수명이 존재하기 때문에 24시간 계속 모터가 돌아가다 보면 언젠가 문제가 발생하여 데이터 유실이 발생할 수 있다.

Backup & Recovery 전략 수립

1. 업무적인 요구 사항
   • MTBF(Mean Time Between Failure)를 증가시키고, MTTR(Mean Time To Recover)를 감소
   • MTBF: 평균 고장 간격
     • 시스템이나 장비가 고장 없이 정상적으로 동작하는 평균 시간
     • 얼마나 신뢰성이 높은지를 나타낸다.
     • MTBF = 총 가동 시간 / 고장 횟수 
       • ex) 서버가 1년동안 (8760시간) 4번 다운되었다면 -> MTBF = 8760 / 4 = 2190 시간 → 약 3개월에 한 번꼴로 고장 발생
   • MTTR : 평균 복구 시간
     • 장애가 발생했을 때 복구하여 정상 기동까지 걸리는 평균 시간
     • 얼마나 빨리 가용성을 회복할 수 있는지를 나타냄
     • MTTR = 총 복구 시간 / 고장 횟수
       • ex) 장애 4번 동안 복구에 총 20시간이 걸렸다면 → MTTR = 20 / 4 = 5시간 → 한 번 장애 발생 시 평균 5시간 다운타임
   • MTBF vs MTTR
     • MTBF → 얼마나 자주 고장이 나는가 (신뢰성 지표)
     • MTTR → 고장이 났을 때 얼마나 빨리 고치는가 (유지보수성 지표)
     • 두 지표는 시스템 가용성(Availability) 계산에 활용된다.
     • Availability = MTBF / MTBF + MTTR
2. 운영 요구 사항
   • 24*365 운영, 백업 테스트 및 검증, 데이터베이스의 변경, 백업 데이터의 보관 장소 등
3. 기술적 고려 사항
   • 하드웨어, 소프트웨어의 구성, 백업 주기 결정을 위한 트랜잭션 주기, 데이터의 양 등
4. 경영진 합의
   • 경영진에서 기대하는 시스템의 가용성, 백업 및 복구 절차에 대한 이해, 백업을 위한 리소스 확보 등

💡 백업 - 파일 변경이 잘 되지 않는 시간대에 백업 전략을 수립해야 한다. 

Tibero 동작 방식의 이해

Transaction Durability

• Committed Transaction MUST Survive failures (Recoverable)
• 데이터 입력/수정 작업은 COMMIT을 수행하면 변경된 내용이 확정되어 Durability를 확보하게 된다.
• 데이터는 Durability가 확보가 안되어 있으면 유실될 수 있다.
• 데이터가 어떻게 하면 날아가지 안혹 안전하게 보관할 수 있을까?
  • 메모리에만 반영되면 장애 시 데이터가 유실 될 수 있기 때문에 영속 저장 장치에 반드시 기록해야 한다. 이때 사용되는 것이 Redo Log(로그 기록)이다.
• Commit이 되는 시점에 데이터 변경이력을 파일에 기록함으로써 Durability를 확보한다.

Logging

• Redo Log Buffer : TSM에 redo 데이터를 저장하기 위한 영역 → 데이터베이스의 모든 변경이력을 메모리에 저장
• Redo Log File : Recovery를 위해 가장 중요한 파일 → 메모리에 저장된 변경 이력을 사라지지 않도록 파일로 저장
• Archive : archive log mode 시 redo logfile을 별도의 위치에 backup

관련 background process

• DBWR, RCWP ( tibero 6 FS07 ~ )
• DBWR, RECO ( tibero6 ~ tibero6 FS06 )
• LGWR, DBWR, CKPT, LARC ( ~ tibero5 )

⭐️ Redo 저장 대상 범위

1) Physical Logging (물리적 로깅)

데이터 변경이 일어날 때마다 해당 Block 전체를 Redo Log에 남긴다.

변경 작업이 발생할 때마다 Block Size 만큼의 로그가 남아 많은 양 유지가 필요하다.

실제 데이터 블록의 변경된 내용(변경 전/후 이미지나 REDO 정보)을 로그에 기록

장점 : Recovery시 단순히 블록에 그대로 반영하면 되기 때문에 복구가 빠르고 간단하다는 장점이 있다.

단점 : 로그 사이즈가 크다.

2) Logical Logging (논리적 로깅)

UPDATE, DELETE 같은 OPERATION 을 LOG에 남기는 방법으로, 여러 Physical Block들에 대한 수정을 하더라도 OPERATION만 기록되어 Logging 양이 적다.

반드시 순서대로 Change Apply (Recovery때 Log Apply 어려움)

▶️ 논리적 로깅에는, '어느 블록(Block) 몇 번째 Row Slot이 바뀌었다.' 같은 물리적 위치 정보가 들어있지 않고, '이 연산 그대로 다시 실행하라' 는 의미마 남는다. Logical Log는 Opertaion만 기록되어 있기 때문에, 장애가 발생시 DBMS SQL을 모두 순차적으로 실행해야 한다. 

장점 : 로그 양이 적다( Operation 하나로 여러 블록 변경을 커버할 수 있다. )

단점 : 복구 시 반드시 순서대로 재적용해야 하며, 인덱스/트리 구조가 변하면 복잡해진다. 또한, 동시에 다른 트랜잭션이 섞여 있으면 복구가 어렵다.

3) Physiological Logging

Physical Logging과 Logical Logging의 장점을 합친 형태

Block의 Physical Change를 기록하는 Change Vector 들로 구성된 REDO RECORD

Change Vector는 Atomic Block Change로, Redo Record는 Atomic Database Change

블록에 대해서는 Physical 하게, 블록 내부 변경 내역은 Logical 하게 기록

Redo Log는 항상 특정 Block을 지정하며, 그 Block 안에서 어떤 Row/Slot/Column을 어떻게 바꿨는지는 논리적 연산으로 기록한다.

💡 Change Vector / Redo Record 

Change Vector

• Redo Log의 최소 단위
• 하나의 Atomic Block Change(블록 내에서 더 쪼갤 수 없는 단일 변경)
• 예 : Block #100의 Row Slot 3 → SAL 값을 800 →900으로 바꿈

Redo Record

• 하나 이상의 Change Vector를 모아 놓은 것
• Atomic Database Change (트랜잭션의 한 DB변경 단위)
• 예 : UPDATE문 하나가 여러 블록 (Row/Index 블록 등)에 영향을 줄 수 있는데,
  • Data Block 변경 Change Vector
  • Index Block 변경 Change Vector
  • Undo Block 변경 Change Vector
  •  → 이들을 합친 것이 하나의 Redo Record

※ 티베로는 Physiological Logging 방식으로 동작한다.
데이터는 커밋할 때 Durability를 확보한다. 이것과 관련있는 것이 Redo Log - Redo Log가 기록될 때는 변경 이력만 기록하는 Logical, Block 전체를 기록하는 Physical Logging 이 있다.
기본적으로 Physiological Logging을 하며, 특정 상황에서 Physical Logging을 한다. 
특정상황 예시 ) Begin Backup ~ End Backup 사이 시점에서 대상 테이블스페이스의 특정 데이터 블록을 변경하는 경우 Physical Logging 방식으로 로깅한다.

Redo 저장 시 발생

Page fix rule

데이터 블록을 수정하기 전에 반드시 블록에 대한 LOCK을 설정하고, 실제 데이터 버퍼 (Data Buffer)를 수정하기 전에 Redo Record를 먼저 생성한다는 규칙이다.

Redo Log는 복구를 위한 최소 단위이기 때문에, 블록이 변경되면 그 변경 이력이 Redo에 반드시 남아야 Durability를 보장할 수 있다.

✅ Redo Record를 먼저 생성하지 않고 데이터 블록을 수정하게 되면, 장애가 발생했을 때 Redo에 기록이 남아있지 않아 복구가 불가능 할 수 있기 때문에 데이터 블록 수정 전에 Redo Record를 생성하는 것이다.

WAL(Write Ahread Logging)

DB의 핵심 규칙 중 하나이다.

데이터 블록이 변경되기 전에 Redo Record가 먼저 Log Buffer에 기록되어야 한다.

예시 :

    사용자가 UPDATE 실행 → DB Buffer에 변경 예정

    하지만 DBWR이 Dirty Buffer를 디스크에 Write하기 전에, 해당 변경 Redo가 Log Buffer → Log File에 먼저 기록된다.

이유 : 장애가 발생해도 Log에 기록된 변경 사항으로 복구할 수 있도록 하기 위함이다. 데이터 블록을 디스크에 반영하기 전에, 반드시 그 변경 이력을 먼저 로그(Redo)에 기록해야 하낟.

데이터베이스에서 트랜잭션이 UPDATE/INSERT/DELTE 같은 작업을 하면, 먼저 메모리(Buffer Cache)의 블록이 수정된다. 나중에 DBWR이 Dirty Block을 디스크(Datafile)에 Write한다. 만약 메모리에만 반영된 상태에서 DB가 다운되게 되면, 데이터파일에는 반영이 되어 있지 않았기 때문에 데이터가 유실되게 된다. 따라서 장애 복구를 위해 Redo Log(변경이력)을 먼저 기록해 둬야 한다. DB가 재기동되면, Redo Log를 읽어서 Datafile에 적용(Redo Apply)하면 복구가 가능하다. 

Redo Log도 Memory에만 기록되어 있으면 안되고, Redo Log File로 디스크에 기록되어 있어야 한다. Commit을 하게 되면 Redo Log Buffer의 내용이 Redo Log File로 저장된다.

Log force at commit

Commit 발생 시 Log Buffer의 Redo entry를 모두 Log file에 Write

Commit 된 데이터의 보장

Online log switch

Online Log 중 다음의 조건을 만족하는 Log file 로 Switching

Database (Controlfile, Redolog file, Datafile) 동기화 방식

1. TSN

• Database의 version 또는 commit version
• Data Concurrency Control, Redo Ordering, Recovery 등에 사용
• Transaction이 commit 될 때 TSN이 generate 된다.

2. Checkpoint

• 주기적으로 또는 사용자의 요청에 따라 메모리에 있는 모든 변경된(dirty) block을 디스크에 쓰는 작업
• 복구에 필요한 logfile의 양을 줄인다.
• Checkpoint 발생 상황
  • 모든 로그 스위치 발생시
  • 인스턴스가 NORMAL, POST_TX, IMMEDIATE 옵션으로 종료
  • 사용자 요청에 따라 수동으로 발생 (ALTER SYSTEM CEHCKPOINT;)
• ALTER TABLESPACE [BEGIN BACKUP | END BACKUP];
• Checkpoint 발생 시, DBWR가 작동하기 전 먼저 LGWR 이 현재 log buffer의 내용을 online log file에 write하여 해당 dirty buffer 에 mark 가 되면, 이 정보를 DBWR이 받아서 모든 marked dirty buffer를 disk에 기록
• Checkpoint는 Checkpoint TSN 이전에 발생한 Online log file내의 모든 변경 사항이 Disk 에 저장되었음을 의미

변경이 필요한 블록이 buffer cache에 그대로 있다가 dirty block들을 모아서 한번에 데이터파일에 작성한다. => checkpoint

이렇게 한번에 데이터파일에 작성하는 것이 효율이 더 좋기 때문이다. 데이터 블록을 데이터파일에 계속 즉시즉시 변경이 있을때마다 쓰게 된다면 변경때마다 Disk I/O가 발생하여 효율적이지 못하기 때문이다. 

Backup 개요

시스템 장애 발생시 복원을 하거나, 시스템 작동을 유지하기 위한 절차 또는 기법

관리자는 시스템 장애 시 발생할 손실을 최소화하고 복구 가능한 상태로 데이터베이스를 운용해야 한다. 

• 최소 한달에 한 번 데이터베이스 전체 백업(Full Backup)
• 하루에 한번씩 Export 백업 권장

데이터베이스 관리자는 백업에 대한 정책을 수립하고 꼭 필요한 데이터를 최소한의 양으로 백업

Backup 종류

1. 논리적 백업 ➡️ 나중에 복구할 때 쉽고 빠르게 진행할 수 있음 / 장애 범위가 어떠냐에 따라서 백업본도 문제가 발생할 수 있음
   • 데이터베이스의 논리적인 단위 백업 
   • Table, Index, Constraint, Sequence 등
   • Export 툴로 백업
2. 물리적 백업 ➡️ 복구할 때 다시 로컬 서버로 가져와야 해서 네트워크 속도에 따라 오래걸릴 수 있음
   • 데이터베이스르르 구성하는 파일을 운영체제 레벨에서 COPY 명령으로 백업
   • datafile, controlfile, archive logfile

✅ 각 하나의 백업만 하는 것이 아니라 둘 다 섞어서 백업해도 된다.

속도 : 파일을 그냥 OS 레벨에서 COPY하는 것이기 때문에 물리적 백업이 더 빠름, 논리적 백업은 파일내에서 논리적인 데이터를 뽑아내서 백업하는 것이기 때문에 물리적 백업보다 느리다.

COPY는 티베로 DBMS가 주체가 아니다. 파일을 가지고 있는 주체는 티베로지만, 복사하는 것은 백업을 작업하는 사람이 하는것이다. (보통 백업 소프트웨어를 사용) 논리적 백업 진행하는 작업자가 tbExport를 통해서 선택적으로 백업할 수 있다. (특정 테이블만 백업)

Backup 대상(Controlfile & Redo logfile)

Controlfile 기능

• 데이터베이스의 구조를 이진 파일 형태로 저장
• 데이터베이스를 mount할 때 반드시 필요
• 파일이 없으면 복구를 하거나 재생성
• 두 개 이상의 contolfile 로 구성 하는 것을 권장, 서로 다른 디스크에 위치

동적뷰

• v$controlfile

다중화 방법

• 데이터베이스를 down(tbdown)
• Controlfile 을 다른 위치로 copy
• $TB_SID.tip 파일에서 CONTROL_FILES 파라미터에 추가
• 데이터베이스를 기동(tbboot)

Redo logfile

• 데이터베이스의 모든 변경 사항을 저장
• 최소한 2개 이상의 redo log group으로 구성
• 각 log group 은 하나 이상의 redo logfile로 구성

동적뷰

• V$LOG, V$LOGFILE

다중화

• Logfile의 손실을 대비하여 각각의 redo log group은 2개 이상의 logfile로 구성할 것을 권장
• Log group의 logfile들은 별도의 disk로 분리
• Log group의 추가
  • ALTER DATABASE ADD LOGFILE GROUP 4 ('/home/tibero6/tbdata/redo41.log', '/home/tibero6/tbdata/redo42.log') SIZE 10m;
• Log group에 member 추가
  • ALTER DATABASE ADD LOGFILE MEMBER '/home/tibero6/tbdata/redo43.log' TO GROUP 4;

Contolfile 백업

• Offline backup : O/S 의 COPY 명령을 통해 별도의 위치에 copy (티베로 종료하고 백업) 
• Online backup : 다음과 같이 controlfile 구문을 생성해 copy (티베로 종료하지 않고 백업)
  • 💡 Online 중에는 티베로 인스턴스(프로세스)가 컨트롤 파일을 읽고, 쓰고 있기 때문에, 온라인 중 파일을 COPY하게 되면 컨트롤 파일이 변경되는 와중에 복사하게 된다. 파일의 내용이 깨진채로 COPY가 될 수 있다. 그래서 Online 백업을 하는 방법은 단순 파일 카피가 아닌 구문을 통해서 진행해야 한다.

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS [백업할 파일 경로 및 이름] REUSE NORESETLOGS;

예) 아래와 같은 Controlfile 구문이 담긴 파일 생성

CREATE CONTROLFILE REUSE DATABASE "tibero"
LOGFILE
NORESETLOGS
	GROUP 0 ('/home/tibero6/tbdata/log01.log', '/home/tibero6/tbdata/log02.log') SIZE 3M,
    GROUP 1 ('/home/tibero6/tbdata/log11.log', '/home/tibero6/tbdata/log12.log') SIZE 3M,
    GROUP 2 ('/home/tibero6/tbdata/log21.log', '/home/tibero6/tbdata/log22.log') SIZE 3M
DATAFILE
	'/home/tibero6/tbdata/system001.dtf',
    '/home/tibero6/tbdata/undo001.dtf'
NOARCHIVELOG
MAXLOGFILES 100
MAXLOGMEMBERS 8
MAXDATAFILES 256;

Backup 방식 차이 (NOARCHIVELOG VS ARCHIVELOG)

NOARCHIVELOG MODE

• 기본적으로 데이터베이스는 NOARCHIVELOG MODE이다.
• Redo logfile은 순환하여 사용되고 log switch가 발생하면 이전의 logfile을 overwrite한다. 이전의 log가 없으므로 트랜잭션 기록 중 최근의 부분만 사용가능하다.
• 백업은 반드시 데이터베이스가 정상 종료된 상태에서 해야 하며 이로 인해 서비스의 중지가 발생한다.

ARCHIVELOG MODE

• Redo logfile은 LOGA(LOG Archiver)에 의해 백업이 완료되기 전에는 사용 불가능하다.
• Archive logfile은 media recovery에 사용가능하다.
• 데이터베이스가 기동 중 백업 가능하다.

ARCHIVELOG Mode의 Backup 방식

Archive log mode

• Log switch시 Redo logfile을 별도의 분리된 위치로 복사하여 저장하여 운영하는 방법
• Archive logfile은 recovery 시 사용되는 매우 중요한 파일
• Online Backup 시 반드시 archive log mode로 운영

관련 Background process / initial parameter

• LOGA(Log Archiver Process) :
  • Redo Log 파일을 Archive log 파일로 복사하는 프로세스
  • ARCHIVELOG Mode에서만 의미가 있다.
  • 일반적으로 DB 기동 시 자동으로 실행되며, Archive log를 지정된 위치에 생성
  • 만약 ARCHIVELOG Mode가 아니면, LOGA는 필요하지 않으므로 자동으로 종료된다.
  • ARCHIVELOG Mode → LOGA 기동 유지
  • NOARCHIVELOG Mode → LOGA 기동했다가 곧바로 종료됨 (아무 할 일이 없기 때문)
• LOG_ARCHIVE_DEST : 
  • archive logfile이 저장되는 위치

변경 방법

• 데이터베이스 down (tbdown)
• 데이터베이스를 mount 모드까지 기동
  • $ tbboot mount
• SYS 유저로 접속하여 archive log mode 로 변경
  • $ tbsql sys/tibero
  • SQL > ALTER DATABASE ARCHIVELOG;
• 데이터베이스 종료 후 재기동

Archive log mode 확인

• V$DATABASE : LOG_MODE 컬럼 조회

Archive log 정보

• 아카이브 대상 상태 이해
• V$ARCHIVE_DEST_FILES : LOG_ARCHIVE_DEST 내의 archive log files의 정보 표시
• V$ARCHIVED_LOG : Archive log 정보 표시

Archive log 대상 지정($TB_SID.tip)

• LOG_ARCHIVE_DEST

✅ Archive Logfile도 백업 대상임으로, Archive Logfile 저장 사이즈는 하루 발생하는 Redo log 발생량을 고려하여 설정해야 한다.

tbExport

Tibero에서 제공하는 유틸리티로, tbExport를 통해 Tibero 데이터베이스에 저장된 스키마 객체의 전체 또는 일부를 추출해 고유 형식의 파일로 저장하므로 데이터베이스의 백업과 다른 머신 간의 데이터베이스를 전송할 때 유용

tbExport 유틸리티에서 하나의 스키마 객체를 추출하면 그와 연관된 스키마 객체가 자동으로 함께 추출된다. 예를 들어 하나의 테이블을 추출하면 그 테이블에 대해 생성된 인덱스와 제약조건 등이 함께 추출된다. 필요에 따라서 연관된 일부 스키마 객체가 함께 추출되지 않도록 지정할 수 있다.

tbExport 유틸리티를 실행한 결과로 생성된 파일은 운영체제 파일이다. 따라서 Tibero 데이터베이스 파일과는 달리 일반 파일과 같은 작업을 실행할 수 있다. 

ex) FTP 를 이용하여 전송하거나 CD-ROM 등에 저장하여 원격지의 Tibero 데이터베이스로 옮길 수도 있다.

Export 모드

Export 모드에는 전체 데이터베이스 모드, 사용자 모드, 테이블 모드가 있다. 각 모드는 파라미터를 사용하여 지정할 수 있다.

전체 데이터베이스 모드

전체 데이터베이스 모드는 Tibero 데이터베이스 전체를 Export하기 위한 모드이다. SYS 사용자를 제외한 모든 사용자의 객체를 Export하기 위해 사용한다. 

전체 데이터베이스 모드를 사용하려면 다음과 같이 FULL 파라미터를 Y로 설정한다.

FULL=Y

사용자 모드

사용자 모드는 SYS 사용자를 제외한 지정된 사용자가 소유한 모든 스키마 객체를 Export 하는 모드이다. 지정한 사용자가 소유한 객체를 Export 하기 위해 사용하며 DBA는 하나 이상의 사용자에게 이 모드를 사용할 수 있다.

사용자 모드를 사용하려면 다음과 같ㅇ USER 파라미터를 USER=userlist 형태로 설정한다.

USER=SCOTT, USER1, ...

테이블 모드

테이블 모드는 하나 이상의 테이블을 지정하여 그 테이블과 연관된 인덱스 등의 스키마 객체를 함께 Export하는 모드이다.

테이블 모드를 사용하려면 다음과 같이 TABLE 파라미터를 TABLE=tablelist 형태로 설정한다.

소유한 사용자를 반드시 명시해야 한다.

TABLE=SCOTT.EMP, USER1.TABLE1, ...

실행

$TB_HOME/client/bin 디렉터리에서 tbexport 명령어 입력

$ tbhome
$ cd client/bin

$ tbexport username=tibero password=tibero sid=tibero file=export.dat full=y
$ tbexport cfgfile=export.cfg

tbImport

tbImport 는 Tibero에서 제공하는 import 유틸리티로, 외부 파일에 저장된 스키마 객체를 Tibero 데이터베이스에 다시 저장하므로, tbExport 유틸리티와 함께 데이터베이스의 백업과 다른 머신 간의 데이터베이스 전송 등을 할 때 유용

실행

$ tbimport username=tibero password=tmax sid=tibero file=export.dat full=y
$ tbimport cfgfile=import.cfg

리스너 로그 확인

리스너 로그를 통해서 언제 어떤 클라이언트가 접속을 시도했는지 확인할 수 있다. 그러나 client의 접속 요청이 Listener에게 도달하기 전에 문제가 발생한 경우에는 리스너 로그에 아무것도 남지 않는다. 

만약 client 접속 요청이 실패하는 경우 리스너로그 확인 후 리스너 로그에 아무런 로그가 남아있지 않다면 네트워크 쪽을 확인해보거나 해야 하며, 로그가 남은 경우에 로그 기록에 따라 조치를 취하면 된다.

리스너 로그 조회

$ cat $TB_HOME/instance/$TB_SID/log/lsnr
$ vi trace_list.log 
# or $ tail -n10 trace_list.log

로그 예시

# 세션에 클라이언트 접속요청 후 접속 성공한 경우 발생하는 로그
2025/07/30 16:08:43.990291 [5] listener:1452 a new client connection detected.
2025/07/30 16:08:43.990326 [5] listener:1371 a client connection from [127.0.0.1:44318] # 접속 요청한 클라이언트 정보
2025/07/30 16:08:43.990332 [5] listener:1494 a client from IP socket
2025/07/30 16:08:43.990344 [5] listener:3104 sent a connection fd to the WTHR process 1 successfully. # 클라이언트 WTHR(WORKER THREAD) 커넥션 성공

리스너 로그가 현재 어떤 포트를 리스닝하는지 확인

$  netstat -tlpn | grep tblistener
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:8629            0.0.0.0:*               LISTEN      2026/tblistener

DB 접속 세션 끊기

DBA가 DB관련 작업을 할 때 모든 세션을 끊고 작업을 해야하는 경우가 있다. 실제 운영중인 서버인 경우 세션이 붙어있을 것이다. 이때는 세션이 연결되지 못하도록 막고, 기존 세션들을 끊는 작업이 필요하다. 

반드시 세션이 연결되지 못하도록 막는 것이 선행되어야 한다. (은행 창구에 대입하여 생각하면 이해하기 쉽다.)

은행 번호표 뽑는 것을 막지 않고 기존 고객을 쫒아내더라도 번호표는 계속 뽑히고 있을테니 계속해서 손님은 들어올 것이다. 번호표 기계를 먼저 종료한 후 기존 고객 거래를 끝내야 은행창구에 아무도 없을 것이다.

세션이 연결되지 못하도록 하려면 어떻게 해야할까?

세션을 연결하도록 하는 것은 Listener의 역할이다. Listener가 더이상 세션 연결 요청을 리스닝하지 못하도록 OFF 하는 방법이 있다.

1. 신규 세션 생성 막기

리스닝 OFF

리스닝 off 의 경우 아래 명령어를 실행하면 된다. 반대로 리스닝 ON은 OFF를 ON으로 변경하여 실행하면 된다.

ALTER SYSTEM LISTENER REMOTE OFF;

작업 후 netstat -tlpn | grep tblistener 조회해보면 아무것도 출력되지 않은 것을 확인할 수 있다.

2. 기존 세션 연결 끊기

기존 세션 연결 끊는 명령어는 아래와 같다. SID 와 SERIAL# 값은 V$SESSION 시스템뷰나 tm(tibero monotor)를 통해서 조회할 수 있다. 여기서는 V$SESSION을 통해 조회해보자

ALTER SYSTEM KILL SESSION(SID, SERIAL#);

V$SESSION을 통해 SID, SERIAL# 값 조회하기

VT_MYTID를 통해 나는 어떤 SID를 사용중인지 확인이 꼭 필요하다. 실수로 나의 연결을 끊어버릴 수 있기 때문이다.

SELECT 
	SID, 
	SERIAL#,
	USERNAME,
	PROG_NAME
FROM V$SESSION;

# 조회 결과
#	SID	SERIAL#	USERNAME	PROG_NAME
1	77	6,058	SYS	tbsql
2	87	632	TIBERO	Studio
3	88	1,360	SYS	tbsql
4	89	1,051	SYS	Studio

# 나는 어떤 SID 사용중인지?
SQL > SELECT * FROM VT_MYTID; -- 77

# 기존 접속 끊기
ALTER SYSTEM KILL SESSION(87, 632);
ALTER SYSTEM KILL SESSION(88, 1360);
ALTER SYSTEM KILL SESSION(89, 1051);

Tibero Instance Paramter 파일 (TIP파일)

TIP 파일은 Tibero 데이터베이스의 초기화 파라미터(Parameter)를 정의한 설정 파일이다.

• 확장자 : .tip
• 기본 위치 : $TB_HOME/config/$TB_SID.tip
• 역할 : DB 인스턴스 구동 시 필요한 환경설정 값 로딩
• 주요 설정 : 메모리 크기, 로그 경로, 백업 설정, listener 포트

# 파라미터 파일 내용 예시
# DB 이름
DB_NAME=tibero
# 리스너 포트
LISTENER_PORT=8629
# 컨트롤 파일
CONTROL_FILES="/tibero/tbdata/control_1/c1.ctl","/tibero/tbdata/control_2/c2.ctl"
# db에서 생성된 파일 기본 저장 경로
DB_CREATE_FILE_DEST="/tibero/tbdata/data_1"
# 로그 아카이브 파일 경로
LOG_ARCHIVE_DEST="/tibero/tbdata/arch"

# 최대 연결 가능 세션 수
MAX_SESSION_COUNT=20
# 공유 메모리 사이즈
TOTAL_SHM_SIZE=1500M
# 전체 메모리 사이즈
MEMORY_TARGET=2048M

### LOG
# 로그 기본 경로
LOG_DEFAULT_DEST="/tibero/tibero7/instance/tibero/log"
# sys log 전체 최대 사이즈 => 오래된 순서로 삭제됨.
SLOG_TOTAL_SIZE_LIMIT=300M
# 리스너 로그 최대 사이즈
LSNR_LOG_TOTAL_SIZE_LIMIT=300M
# ilog 최대 사이즈
ILOG_TOTAL_SIZE_LIMIT=700M
# dbms 로그 최대 사이즈
DBMS_LOG_TOTAL_SIZE_LIMIT=300M
# sys 로그 파일 하나 당 사이즈
SLOG_FILE_SIZE=100M
# 리스너 로그 파일 하나 당 사이즈
LSNR_LOG_FILE_SIZE=10M
# ilog 파일 하나 당 사이즈
ILOG_FILE_SIZE=10M
# dbms 로그 파일 하나 당 사이즈
DBMS_LOG_FILE_SIZE=100M

### ETC
GATHER_SQL_PLAN_STAT=Y
# 날짜 포맷
NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS"

SQL 쿼리문으로 티베로 파라미터 정보 조회하기

- V$PARAMETERS 라는 시스템뷰를 통해 티베로 파라미터를 조회할 수 있다.

-- 예시코드
SELECT
	NAME
    , VALUE
FROM V$PARAMETERS
WHERE 1=1
AND NAME IN ('MEMORY_TARGET', 'TOTAL_SHM_SIZE')
;

공유 메모리(TSM) 크기 정보 조회

-- FIXED MEMORY (REDO LOG BUFFER, SYSTEM AREA, DATABASE BUFFER CACHE)
-- TSM에서 FIXED MEMORY에 해당하지 않는 것은 SHARED CACHE
SELECT
	NAME
    , ROUND(TOTAL / 1024 / 1024, 1) AS "TOTAL(MB)"
    , ROUND(USED / 1024 / 1024, 1) AS "USED(MB)"
FROM V$SGA;

*SQL WORK AREA → SORT_AREA_SIZE를 통해 사이즈 설정이 가능하다. (DEFAULT PGA의 30%)
*MEMORY TUNER → 티베로 내부적으로 SQL WORK AREA 메모리 사용할 때 3초 단위(감시 단위 변경 가능)로 확인하면서 메모리 사용량을 조절해준다.

-- SORT 작업용 메모리 크기
SORT_AREA_SIZE

-- HASH 조인용 해시테이블 할당 메모리 크기 설정
HASH_AREA_SIZE

-- PGA 메모리의 SQL WORK AREA 공간 크기 검사 주기
EX_MEMORY_COMPENSATE_INTERVAL

* 위 3개 파라미터 조회 쿼리
SELECT NAME, VALUE, DFLT_VALUE
FROM V$PARAMETERS
WHERE 1=1
AND NAME IN ('SORT_AREA_SIZE', 'HASH_AREA_SIZE', 'EX_MEMORY_COMPENSATE_INTERVAL');