[Tibero교육] Tibero Backup & Recovery

1. 백업 및 복구

 

Introduction

 

 Backup 및 recovery Introduction

−여러 가지 유형의 장애로부터 데이터베이스를 보호

MTBF (Mean Time Between Failure)를 증가시키고 MTTR (Mean Time Between Recover)를 감소

 

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

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

최소한 한 달에 한번 데이터베이스 전체 백업

하루에 한번씩 Export 백업 권장

 

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

백업은 DBA의 주요 역할 중 가장 주의를 기울여야 함

 

−“RECOVERY에 실패한 DBA는 용서할 수 있지만, BACKUP을 실패한 DBA는 용서할 수 없다.”

−백업이 정상적으로 수행되었는지 주기적으로 검증하는 것을 권장한다.

 

여러 가지 유형의 장애

 

명령문의 실패

−테이블의 제약 조건에 위배되는 데이터를 insert

−권한의 부족

−테이블 생성시나 데이터 변경시 테이블스페이스의 공간이 부족한 경우

 

사용자 프로세스의 실패

−비정상적인 종료로 인한 사용자 프로세스의 실패가 대부분

−Tibero의 monitor process가 비정상적인 종료를 감지하고 수행중인 트랜잭션 등은 롤백

 

사용자로 인한 장애

−장애 발생 상황

DROP TABLE

TRUNCATE TABLE

DELETE FROM & COMMIT

잘못된 update & COMMIT

−해결 방안

사용자에 대한 교육 실시

백업에서 복구 Export 받은 파일에서 테이블을 import

Time-based 불완전 복구

 

Instance fail

−정전, CPU나 memory fault, background process의 비정상적인 종류가 대부분

−복구

특별한 복구 작업이 필요하지 않음 tbboot을 통해 DBMS를 기동하면 자동으로 복구됨

로그 등을 참고하여 원인 분석

 

Media fail

−데이터파일이 저장된 하드 디스크의 장애

−데이터 파일의 삭제

−정해진 복구 전략에 따라 복구 절차가 필요

 

Backup 및 Recovery의 전략 수립

 

업무적인 요구 사항

−MTBF (Mean Time Between Failure)를 증가시키고 MTTR (Mean Time To Recover)를 감소

 

운영 요구 사항

−24*365 운영, 백업 테스트 및 검증, 데이터베이스의 변경, 백업 데이터의 보관 장소 등

 

기술적 고려 사항

−하드웨어, 소프트웨어의 구성, 백업 주기 결정을 위한 트랜잭션 주기, 데이터의 양 등

 

경영진 합의

−경영진에서 기대하는 시스템의 가용성, 백업 및 복구 절차에 대한 이해, 백업을 위한 리소스 확보 등

 

Backup과 Recovery 관련 Tibero 동작 방식의 이해

 

Transaction Durability

−Committed Transaction MUST Survive failures (Recoverable)

 

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 ( tibero 6 ~ tibero 6 FS06 )

−LGWR, DBWR, CKPT, LARC ( ~ tibero 5 )

 

Redo 저장 대상 범위

−Physical Logging

▪ 수정이 일어날 때마다 해당 block을 통째로 남긴다.

▪ 바뀔 때마다 block size 만큼의 로그가 남아 많은 양의 유지해야 한다.

 

−Logical Logging

▪ update, delete 같은 operation을 log에 남기는 방법이다.

▪ 여러 physical block들에 대한 수정을 하더라도 operation만 기록되어 logging 양이 적다.

▪ 하지만, change가 반드시 순서대로 apply되야 한다. recovery 때 log apply가 어렵다.

 

−Physiological Logging

▪ physical logging과 logical logging의 장점을 합친 형태

▪ block의 physical change를 기록하는 change vector 들로 구성된 redo record 들로 이루어진다.

▪ change vector는 atomic block change 이며, redo record는 atomic database change

 

Redo 저장 시 일어나는 일들

−Page fix rule

▪ block에 대한 수정작업이 일어나기 전에 buffer에 대한 Lock을 잡는다.

▪ 실제 data buffer를 수정하기 전에 Redo Record를 Generation한다.

 

−WAL ( Write Ahead Logging )

▪ database buffer가 변경되기 전에 redo record 가 먼저 log buffer에 기록된다.

▪ DBWR가 dirty buffer를 disk에 write하기 전에 Redo Record가 먼저 log buffer의 필요한 redo record를 log file에먼저 기록한다.

 

−Log force at commit

▪ Commit 발생시 log buffer의 redo entry를 모두 log file에 write한다.

▪ Commit된 데이터의 보장.

 

−Online log switch

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

Not active

Check point complete

Archiving not required

 

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

−TSN

▪ Database의 version 또는 commit version

▪ Data Concurrency Control, Redo Ordering, Recovery 등에 사용된다.

▪ Transaction이 commit될 때 TSN이 generate된다.

 

−Checkpoint

▪ 주기적으로 혹은 사용자의 을 줄임. 요청에 따라 메모리에 있는 모든 변경된 (dirty) 블럭을 디스크에 쓰는 작업

▪ 복구에 필요한 logfile의 양

▪ CheckPoint 발생 상황

– 모든 로그 스위치 발생시

– 인스턴스가 NORMAL, POST_TX, IMMEDIATE 옵션으로 종료

– 사용자 요청에 따라 수동으로 발생

 ALTER SYSTEM CHECKPOINT;

▪ 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에 저장되었음을 의미한다.

 

Backup 개요

 

 Backup 개요

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

− 관리자는 시스템 장애시 발생할 손실을 최소화하고 복구 가능한 상태로 데이터베이스를 운용해야 함. 최소한 한달에 한번 데이터베이스 전체 백업 하루에 한번씩 Export 백업 권장

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

Backup 종류와 전략

 

 Backup의 종류

− 논리적인 백업 데이터베이스의 논리적인 단위 백업.

Table, Index, Constraint, Sequence 등…

Export 툴로 백업

− 물리적인 백업

데이터베이스를 구성하는 파일을 운영체제 레벨에서 COPY 명령으로 백업 datafile, controlfile, archive logfile

 Backup의 종류

구분	설명
NOARCHIVELOG 모드에서의 백업 (Offline Backup / Cold Backup)	데이터베이스를 구성하는 전체 파일에 대해 운영을 멈춘 상태에서 백업 데이터베이스를 백업 받은 시점으로의 복구만 가능
ARCHIVELOG 모드에서의 백업 (Online Backup / Hot Backup)	운영중에도 백업가능. Controlfile 생성문, Datafile, Archive logfile백업 백업된 archive logfile 의 시점에 따라 datafile 백업 시점 이전으로의 복구도 가능

구분	설명
Consistent 백업	- 정상적인 Shutdown 후의 Backup
Inconsistent 백업	- DB 운영중에 Backup 또는 정상종료 되지 않은 상태에서의 Backup

Backup 대상 - Controlfile & Redo logfile

 

Controlfile 기능

−데이터베이스의 구조를 이진 파일 형태로 저장

−데이터베이스를 mount할 때 반드시 필요

−파일이 없으면 복구를 하거나 재생성해야 한다.

−두 개 이상의 controlfile로 구성하는 것을 권장하고 서로 다른 디스크에 위치시키도록 한다.

 

동적뷰

−v$controlfile

 

다중화 방법

−데이터베이스를 down (tbdown)

−Control file을 다른 위치로 copy

−$TB_SID.tip 파일에서 CONTROL_FILES 파라미터에 추가

−데이터베이스를 기동 (tbboot)

 

Controlfile 백업

−Offline backup : O/S의 copy 명령을 통해 별도의 위치에 copy한다.

−Online backup : 다음과 같이 controlfile 구문을 생성하여 copy 한다.

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

예) 다음과 같이 Controlfile 구문이 들어있는 파일이 생성됨

CREATE CONTROLFILE REUSE DATABASE "tibero"
LOGFILE
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 3MNORESETLOGS
DATAFILE
'/home/tibero6/tbdata/system001.dtf',
'/home/tibero6/tbdata/undo001.dtf'
NOARCHIVELOG
MAXLOGFILES 100
MAXLOGMEMBERS 8
MAXDATAFILES 256;

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

Backup 방식의 차이 - NOARCHIVELOG Mode VS ARCHIVELOG mode

 

 

Archive log mode에서 On-Line Redo Log 파일 사용

Archive log mode란?

−Log switch시 Redo logfile을 별도의 분리된 위치로 복사하여 저장하여 운영하는 방법

−Archive logfile은 recovery시 사용되는 매우 중요한 파일이다.

−Online backup을 하려면 반드시 archive log mode로 운영해야 한다.

관련 background process / initial parameter

−LOGA : tibero 기동시 자동으로 종료된다.

−LOG_ARCHIVE_DEST : archive logfile이 저장되는 위치

변경 방법

−데이터베이스 down

tbdown immediate

−데이터베이스를 mount 모드까지 기동

tbboot mount

−SYS 유저로 접속하여 archive log mode로 변경

tbsql sys/tibero

ALTER DATABASE ARCHIVELOG;

−데이터베이스 종료 후 재기동

tbdown immediate
tbboot

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

 

Backup 수행 방법 - Offline Backup

 

 티베로 종료 후 백업

− Tibero를 정상 종료한 후 OS의 Copy 명령을 이용해 datafile, logfile, contrilfile, tip file등을 백업한다.

   MOUNT 또는 OPEN 모드에서 v$datafile, v$logfile 뷰를 통해서 백업할 파일 정보 조회

   ARCHIVELOG 모드에서는 archive 파일도 백업

 

−V$DATAFILE에서 백업 대상 파일 조회

SQL> select name from v$datafile;

NAME
-----------------------------------------------------------
/home/tibero6/datafile/system001.dtf
/home/tibero6/datafile/undo001.dtf
/home/tibero6/datafile/ws_data1.dtf
/home/tibero6/datafile/ws_idx1.dtf
/home/tibero6/datafile/ts_test01.dtf

− V$LOGFILE에서 백업 대상 logfile 조회

SQL> select group#, member from v$logfile;

GROUP# MEMBER
---------- -------------------------------------------------- 
1 /home/tibero6/datafile/log011.log
2 /home/tibero6/datafile/log021.log
3 /home/tibero6/datafile/log031.log
3 rows selected.

−V$CONTROLFILE에서 백업 대상 controlfile 조회

SQL> select name from v$controlfile;

NAME
-----------------------------------------------------------------
/home/tibero6/datafile/control01.ct

−티베로를 정상 종료

$ tbdown

Tibero instance terminated (NORMAL mode)

반드시 정상 종료를 해야 한다.

 

−File copy

앞에서 조회한 모든 파일을 copy한다.

$ cp /home/tibero6/datafile/*dtf /backup/
$ cp /home/tibero6/datafile/*log /backup/
$ cp /home/tibero6/datafile/*ctl /backup/

Backup 수행 방법 - Online Backup

 

 티베로 운영 중 백업 (온라인 백업)

− ALTER TABLESPACE 명령으로 테이블스페이스의 datafile 백업한다.

   ARCHIVELOG 모드에서만 사용 가능하다.

   Tibero 데이터베이스에 온라인 백업 시작을 알림

SQL> ALTER TABLESPACE SYSTEM BEGIN BACKUP;

OS 명령으로 해당 테이블스페이스의 데이터파일 복사

SQL> !cp /data01/tibero/system001.tbf /backup/tibero/system001.tbf_backup

Tibero 데이터베이스에 온라인 백업 종료를 알림

SQL> ALTER TABLESPACE SYSTEM END BACKUP;

− 주의 사항

온라인 백업 중에는 데이터베이스의 변경 사항에 대한 log의 양이 늘어나기 때문에 가능하면신속하게 작업을 종료해야 함

 

 티베로 Begin backup 이후 발생 내용.

1) begin backup 실행시 redo log 에 쌓이는 로그 차이점:

 begin backup 이 일어난 후 block 변경시 해당 block 전체를 redo log 로 남기는 image logging 이 발생함에따라 log 양이 평소에 비해 증가하게 됨.

2) end backup 을 실행하지 않는 경우 문제점:

 1) 에서 언급한 바와 같이 log 양이 증가함.

 티베로 정상 종료가 불가하며, 만일 강제 종료할 경우 다음 부팅시 media recovery 를 해줘야 함.

3) end backup 실행시 tibero 내부적으로 처리되는 내용:

 controlfile 과 datafile 에서 해당 tablespace 가 backup mode 라는 플래그를 off 하며, check point 정보를 최신으로 업데이트 합니다.

4) begin backup 실행시 datafile 의 변경사항:

(1) datafile 의 header 에 backup mode 라는 플래그가 on 됨.

(2) begin backup 과 end backup 사이에 발생하는 변경사항이 data file 과 redo log file 에 기록되지만, header 에 setting 되는 checkpoint 값, TSN 값은 고정된다.

 

동적 뷰

−V$BACKUP : 현재 begin backup으로 인해 backup mode인 상태를 확인한다.

SQL> alter tablespace ws_data begin backup;
Tablespace altered.

SQL> select * from v$backup;

 

Backup 수행 방법 - Logical Backup

 

tbExport 유틸리티

−tbExport 유틸리티를 이용해서 스키마 전체 혹은 일부를 추출해서 백업한다.

−문제점

서로 다른 시점의 데이터

Export 받은 시점으로의 복구만 가능하다.

 

Export 모드

−전체 데이터베이스 모드

DBA 유저(SYS)로만 가능

SYS를 제외한 모든 유저의 데이터를 export

FULL=Y

−사용자 모드

사용자가 소유하고 있는 테이블만 추출

USER=SCOTT

−테이블 모드

특정 테이블만 지정해서 추출

TABLE=SCOTT.EMP, SCOTT.DEPT

 

Recovery - 인스턴스 기동 단계 별 복구 대상

Recovery - Crash Recovery 개요

개요

− 시스템이상, shutdown abort 등 비정상적인 데이터베이스 종료 후 Tibero가 기동하는 과정에서 자동으로 수행

− Online redo log file, online data file, current control file만을 사용

− Undo 테이블스페이스를 이용하여 commit 되지 않은 데이터에 대해 복구 작업

 

특징

−Database에 접근 가능한 Instance에 Failure가 발생한 경우.

−Database가 기동될 때 자동 수행됨.

−redo의 roll forward and roll back

Recovery - Crash Recovery 원리

Roll Forward

−Redo log에 존재하는 redo record를 data file에 reapply하는 작업

−Redo log 적용 순서는 Checkpoint 시점의 Lowest TSN부터 recover를 시작하여 큰 값의 TSN 순으로 진행함

−Redo Record에는 rollback(undo) segment를 변경하는 내용도 포함되어 있으므로 실제 rollback(undo) data도 발생한다.−Roll forward 종료 시 committed change와 uncommitted change가 모두 data block에 반영되어 있게 된다. -> RollBack Phase

 

Roll Back

−rollback segments에 있는 undo information을 이용하여 uncommitted changes에 대한 undo 작업 수행(Consistency)

 

Recovery - Media Recovery 개요

 

Media Recovery란?

−티베로를 구성하는 파일에 물리적인 손상이 발생하였거나 정상 동작을 할 수 없는 경우 복구하는 과정

 

특징

−DBA에 의한 명령에 의해 수동으로 수행 (ALTER DATABASE RECOVER ...)

−Backup받은 datafile을 이용해서 복구

−redo logfile 이나 archive logfile로부터 redo record를 적용

−MOUNT 모드에서만 가능하다.

 

참고하는 동적 뷰

−V$RECOVER_FILE

−V$RECOVERY_FILE_STATUS

−V$LOGFILE, V$CONTROLFILE, V$LOG

 

종류

−Complete Recovery : Archive logfile 과 Online logfile 을 모두 사용해서 가장 최근 로그까지 모두 반영

−Incomplete Recovery : logfile 일부만 적용 하거나 특정시점으로 복구 가능. RESETLOGS 적용 필요

 

Recovery - Media Recovery 수행시 불완전 복구

 

Incomplete Recovery

−point-in-time recovery

−redo record 의 일부 만 적용

 

필요한 상황

−online redo logs are damaged

−data loss by user error

−some archived log is missing

 

Resetlogs

−Incomplete recovery를 하게 되면 반드시 resetlogs로 데이터베이스를 기동해야 한다.

−resetlogs 이전 datafile, logfile 과 resetlogs 이 후의 파일은 서로 호환되지 않는다

resetlogs 이전에 백업 파일이나 logfile들을 이용하여 resetlogs 이후로 복구할 수 없다.

또한 resetlogs 이후의 file들을 가지고 resetlogs 이전 상태로 incomplete 복구도 불가능하다

−resetlogs 시작한 경우, 반드시 새로운 백업을 받기를 권장한다

−Resetlogs로 데이터베이스 기동하기

$ tbboot –t RESETLOGS

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

2. 백업 및 복구 예제 1

 

Controlfile 백업 및 복구

 

Controlfile 백업

−데이터베이스의 구조에 변화가 일어난 경우 controlfile을 백업해야 한다.

−Offline Full Backup을 하거나 trace를 통한 controlfile 생성 구문을 백업한다.

−MOUNT,OPEN 모드에서 controlfile 생성 구문 백업 가능

−지정한 디렉토리에 controlfile 백업 생성

  ▪ 디렉토리 경로를 지정하지 않을 경우 DB_CREATE_FILE_DEST 파라미터로 설정한 디렉토리에 백업 파일 생성

 

Controlfile 백업 및 복구 - Controlfile 백업 ( offline backup )

 

Controlfile 확인 ( V$CONTROLFILE )

SQL> select name from v$controlfile;

NAME
--------------------------------------------------------------------------
/home/tibero6/tibero6/database/c1.ctl

1 row selected.

Tibero 종료 후 backup 대상 위치로 copy

$ tbdown

Tibero instance terminated (NORMAL mode).

$ cp /home/tibero6/tibero6/database/c1.ctl /home/tibero6/tbdata/bak/c1.ctl

Controlfile 백업 및 복구 - CONTROLFILE의 이중화

 

Controlfile의 이중화

−Tibero를 종료한 후 controlfile을 copy

$ tbdown

Tibero instance terminated (NORMAL mode).

$cp /tibero/tibero6/database/c1.ctl /tibero/tibero6/database/c2.ctl

−$TB_SID.tip 파일의 CONTROL_FILES 항목에 추가

CONTROL_FILES="/tibero/tibero6/database/c1.ctl","/tibero/tibero6/database/c2.ctl"

Controlfile 백업 및 복구 - Controlfile 백업 (Using trace)

 

 Controlfile 백업(Online)

− Online 백업 시, Alter ~ trace 구문을 사용하여 Controlfile 생성용 SQL문장을 백업하고, 복구시 이를 사용한다.

− ALTER DATABASE BACKUP CONTROLFILE

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

− 실행 예

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS
'/home/tibero6/tbdata/backup/create_controlfile.sql' REUSE NORESETLOGS;