Backup & Recovery

Logging

(1) 기본용어

1. 가. Transaction 여러개의 SQL문으로 구성되는 기본적인 작업단위로 Unit of Work(UOW)이라고도
   

   한다. 한 UOW내의 SQL문들은 UOW종료시까지 그 실행이 보류되었다가 종료시에 일괄적으로
   Database에 반영되거나 혹은 취소된다. 즉, 한 UOW내의 SQL문들은 전부 성공적으로 수행되거
   나, 혹은 모두 그 실행이 취소되어야 한다. UOW의 종료를 표시하는 시점을 Consistency Point
   라고 한다.

2. 나. Commit
   

   UOW내의 모든 SQL문장이 처리했던 내용을 Database에 반영한 후 UOW를 종료한다.

3. 다. Rollback
   

   UOW내의 모든 SQL문장의 처리 내용을 취소한 후 UOW를 종료한다.

4. 라. Log
   

   UOW내의 모든 SQL문장이 처리했던 내용을 Database에 실제로 반영하기 전에 그 변경 전후의
   Image를 임시로 기록해 두는 File

5. 마. Recoverable
   

   Database Recovery에 Log file이 적용될 수 있는 경우를 Recoverable Database라고하고 그렇
   지 못한 경우를 Non-Recoverable Database라고 한다.

(2) Log의 종류

1. 가. Active Log : Log file내에 아직 database에 반영되지 않은 정보가 있는 log
2. 나. Inactive Log : Log file내의 모든 정보가 Database에 반영된 log
3. 다. On-line Archived Log : Inactiva시 Database log Directory에 저장되는 Log
4. 라. Off-line Archived Log : Inactive시 Database log Directory 이외의 Directory에 저장되는 log

Logging 방식

(4) Log File의 관리

1. 가. Log file은 S0000000.LOG에서 S9999999.LOG까지 순차적으로 사용된다.
2. 나. Logging 방법이 Archival에서 Circular로, 또는 Circular에서 Archival로 변경되면 Log file은
   S0000000.LOG에서부터 다시 사용된다.
3. 다. 10,000,000개의 log file을 다 사용한 경우에는 S0000000.LOG에서부터 다시 사용된다.
4. 라. Recovery에 log file이 적용되면 적용된 마지막 log file은 Truncate되고, 다음 번호의 log file부터
   다시 사용된다.
5. 마. Archive Log를 delete하면 Error

(4) Log File의 관리

1. 가. Log file은 S0000000.LOG에서 S9999999.LOG까지 순차적으로 사용된다.
2. 나. Logging 방법이 Archival에서 Circular로, 또는 Circular에서 Archival로 변경되면 Log file은
   S0000000.LOG에서부터 다시 사용된다.
3. 다. 10,000,000개의 log file을 다 사용한 경우에는 S0000000.LOG에서부터 다시 사용된다.
4. 라. Recovery에 log file이 적용되면 적용된 마지막 log file은 Truncate되고, 다음 번호의 log file부터
   다시 사용된다.
5. 마. Archive Log를 delete하면 Error

(5) Logging 방식 변경

1. 가. Circular Logging으로 설정
   
   $ db2 update db cfg db명 using logretain off
   $ db2 update db cfg db명 using userexit off
2. 나. Archival Logging으로 설정
   
   $ db2 update db cfg db명 using logretain on
   $ db2 update db cfg db명 using userexit on
   or db2 update db cfg db명 using userexit off
3. 다. DataBase Directory 확인
   
   $ db2 get db directory on $HOME
   Local Database Directory on /home/db2inst1
   Number of entries in the directory = 1
   Database 1 entry :
   Database alias = SAMPLE
   Database name = SAMPLE
   Database directory = SQL00001
   Database relese level = 6.00
   Commit =
   Directory entry type = Home
4. 라. DataBase Log file 확인
   
   $ Is - lia $HOME/db2inst1/SQL00001/SQLLOGDIR

User Exit

1. 가. Archival logging 방식을 취하려면 Logretain변수를 이용하는데, Userexit변수를 함께 쓰면
   Archival file을 다른 device로 이동시킬 수 있다.
2. 나. Database Configuration Parameter 조정
   
   $ db2 update db cfg db명 using logprimary 10
   $ db2 update db cfg db명 using logretain on
   $ db2 update db cfg db명 using userexit on
3. 다. db2uexit Program 실행 module 생성
   
   - $HOME/sqllib/samples/c/db2uexit.cdisk를 작업 Directory에 db2uexit.c로 복사한다.
   - db2uexit.c file을 적당하게 수정한다.
   - xlc Compiler를 이용하여 db2uexit 실행 module을 생성한다.
   
   
   $ vi db2uexit.c
   #define ARCHIVE_PATH "/archive/"
   #define RETRIEVE_PATH "/retrieve/"
   #define AUDIT_ACTIVE 1
   #define ERROR_ACTIVE 1
   #define AUDIT_ERROR_PATH "/logback/"
   #define AUDIT_ERROR_ATTR "a"
   $ xlc -o db2uexit db2uexit.c
   $ mv db2uexit $HOME/sqllib/bin

Backup

(1) Backup 개요

1. 가. 기능 : Local 혹은 Remote node에 있는 Database의 Image를 Copy해주는 utility
2. 나. 권한 : SYSADM, SYSCTRL, SYSMAINT Authority가 필요
3. 다. Backup Level
   

   (가) Full DB backup : 특정 Database 전체의 Image를 backup
   (나) Tablespace backup : 특정 Database내의 1개 이상의 Tablespace Image를 backup

4. 라. Backup Mode
   

   (가) On-Line backup : Share Mode 상태에서 backup 실행
   (나) Off-Line backup : Exclusive Mode에서 backup 실행

5. 마. Configuration Parameter
   

   (가) backbufsz : backup을 실행하는 동안 사용되는 buffer의 크기로서 기본값은
   1024 page이다.
   (나) num_ioservers : backup을 실행하는 동안 Data prefetch 나 Asynchronous I/O를
   담당하는 I/O Server의 개수로서 기본값은 3이다.

6. 바. Specific Processor
   

   (가) Buffer Manipulator : database로부터 backup buffer로 backup image를 I/O하는
   processor로서 database당 1개씩 존재한다.
   (나) Media I/O Controller : backup buffer로부터 Tape등의 특정 device로 backup
   image를 I/O하는 processor로서 database다 1개씩 존재한다.

7. 사. Backup Image
   

   (가) Database alias : backup의 대상이 되는 database alias명을 나타낸다 .
   (나) Type : backup의 type으로 `0'은 full database, '3'은 tablespace,'4'는 load copy를 나타낸다.
   (다) Instance Name : database가 속한 Instance명을 나타낸다.
   (라) Reserved : Reserved field로서 값은 `0'이다.
   (마) Timestamp : backup이 실행된 timestamp를 나타낸다.
   (바) Sequential Number : File의 extension을 나타내는 일련번호

8. <<참고사항>>

참고사항

1. 1. Temporary Container를 포함한 Tablespace는 Backup할 수 없다.
2. 2. Tablespace Backup, On-Line, Backup은 Archival Logging상태에서만 가능하다.

(2) Backup 방법

가. Full DB Off-line Backup

Circular logging이거나 Archival logging이거나 무관

나. Full DB On-line Backup

Archival logging이어야 함

다. Tablespace Off-line Backup

Archival logging이어야 함

라. Tablespace On-line Backup

Archival logging이어야 함

Backup

(1) Recovery 종류

1. - Crash Recovery
2. - Restore Recovery
3. - Roll Forward Recovery

1. 가. Crash Recovery
   
   1. (가) 기능 : System Power failure나 Application error 발생 등으로 인해 Database가
      

      Inconsistent한 상태가 된 경우 Active Log를 다시 적용함으로써 Database 상태를
      Consistent하게 유지시키는 Utility

   2. (나) 권한 : 특별한 Authority는 필요없음
   3. (다) Configuration Parameter : autorestart 기본값은 `on'으로 Crash recovery가 필요한
      

      경우 자동적으로 recovery작업을 실행한다.

2. 나. Restore Recovery
   
   1. (가) 기능 : 특정 시간에 생성된 backup image를 이용하여 database를 backup 당시의 image와
      

      동일하게 복구 혹은 새로 생성해주는 Utility

   2. (나) 권한
      

      ㄱ. 기존복구 : SYSADM, SYSCTRL, SYSMAINT 권한필요
      ㄴ. 신규생성 : SYSADM, SYSCTRL 권한필요

   3. (다) Restore Level
      

      ㄱ. Full DB backup : 특정 database 전체의 image를 restore
      ㄴ. Tablespace backup : 특정 database 내의 1개 이상의 Tablespace image를 restore
      ㄷ. Recovery History File : 특정 database의 recovery History file만 restore

   4. (라) Restore Mode
      

      ㄱ. On-Line restore : Share Mode 상태에서 restore
      ㄴ. Off-Line restore : Exclusive Mode 상태에서 restore

   5. (마) Configuration Parameter
      

      ㄱ. restbufsz : restore를 실행하는 동안 사용되는 buffer의 크기로서 기본값은 1024
      페이지이다.
      ㄴ. num_ioservers : restore를 실행하는 동안 data prefetch나 asyncronous I/O를 담당
      하는 I/O server의 개수로서 기본값은 3이다.

   6. (바) Specific Processor
      

      ㄱ. Buffer Mainpulator : restore buffer로부터 database로 backup image를 I/O하는
      processor로서 database당 1개씩 존재한다.
      ㄴ. Media I/O Controller : Tape등의 특정 device로부터 restore buffer로 backup
      image를 I/O하는 processor로서 database당 1개씩 존재 한다.

   7. (사) Redirected Restore Recovery
      

      ㄱ. Container 변경 : tablespace에 할당된 containers를 재배열할 때

3. 다. Rollforward Recovery
   
   1. (가) 기능 : 특정 시간에 생성된 backup image와 Active Log를 이용하여 database를 backup
      

      생성 이후의 특정 기간이나 가장 최근의 image로 복구 혹은 새로 생성해주는 recovery 방법

   2. (나) 권한
      

      ㄱ. 기존복구 : SYSADM, SYSCTRL, SYSMAINT권한 필요
      ㄴ. 신규생성 : SYSADM, SYSCTRL 권한 필요

   3. (다) Rollforward Level
      

      ㄱ. Log 적용 안함 : Log를 한 개도 적용하지 않는 방식으로 Off-line Full database backup image에만 적용가능
      ㄴ. 특정시간까지 적용 : Log 내용중 특정시간까지의 내용만 적용하는 방법
      ㄷ. Log 끝까지 적용 : 가장 최근까지의 Log내용을 적용하는 방법

(1) Recovery 방법

가. CRASH Recovery

Autorestart option 확인

실행명령어

나. RESTORE Recovery

현재의 Logging상태가 Circular Logging인지 확인

Full DB off-line backup image인 경우

다. ROLLFORWARD Recovery

현재의 Logging상태가 Archival Logging인지 확인

Full DB off-line backup image인 경우

Tablespace backup image인 경우에는 현재까지의 log를 모두 적용시켜야 한다.

<<참고사항>>

CPU Time : 현재시간에서 9시간을 빼야함.
(현재시간 - 9 = CPU Time)

(3) Recovery History File

1. 가. 기능 : 특정 database에 행한 Backup / Restore / Load 작업에 대한 정보를 기록하는 file
2. 나. Rcovery History File의 구조

1. 다. 권한 : SYSADM, SYSCTRL, SYSMAINT나 DBADM 권한이 필요하다.
2. 라. History file의 내용 확인
   
   1. ㄱ. List History command를 이용하여 Recovery History file의 내용을 확인한다.
   2. ㄴ. 특정시간까지 적용 : Log 내용중 특정시간까지의 내용만 적용하는 방법
   3. ㄷ. Log 끝까지 적용 : 가장 최근까지의 Log내용을 적용하는 방법
3. 마. History file의 관리
   
   1. ㄱ. Prune History command : History file중 특정 Timestamp 이전의 정보를삭제한다.
   2. ㄴ. Update History command : history file의 내용을 수정한다.
   3. ㄷ. REC_HIS_RETENTN parameter : history file의 size를 지정한다.
4. 바. History file의 복구
   
   1. ㄱ. Database Recovery 작업시 Recovery History file만을 복구하는 Option을 이용한다.
5. 사. Recovery History file의 내용 확인
   

   list backup command

   
   
   $ db2 list backup all for DB명
   $ db2 list backup since 199609 for DB명
   $ db2 list backup containing for DB명, Table명
   
   

   list backup command

   
   
   $ db2 list backup all for DB명
   $ db2 list backup since 199609 for DB명
   $ db2 list backup containing for DB명, Table명
6. 아. Recovery History file의 내용 관리
   

   prune history comand

   
   
   $ db2 prune history timestamp
   $ db2 prune history 199609
   $ db2 prune history 199609 with force option
   
   

   update history command

   
   
   $ db2 update history for object_part with
   new_location device type new_device_type
   cmment new_coment
   $ db2 update history for 1996090988881101 with
   location / dbbackup device type D comment testing
   
   

   update REC_HIS_RETENTN command

   
   
   $ db2 update db cfg db명 using
   REC_HIS_RETENTN 100

Data Moving

Export

table의 데이터 내용을 DEL, IXF, WSF 형태로 반출할 수 있다. 반출된 내용은 import 나
load 유틸리티를 사용하여 테이블로 다시 반입할 수 있다.

<예 : org 테이블의 데이터를 edu.exp 라고 하는 ixf 형태의 파일로 export>

lmport

일단 export 명령으로 반출된 파일이나 이미 DEL,ASC,IXF,WSF 형태로 존재하는 파일은
LOAD 명령(WSF유형만 지원 안됨)이나 IMPORT 명령으로DB의 TABLE로 데이타를 이동시킬 수
있다.

<예 : org 테이블의 데이터를 edu.exp 라고 하는 ixf 형태의 파일로 export>

method n ( column 명) 옵션을 부여할 수도 있다. 그 옵션은 export된 table과 다른 column을
주는 경우에 사용할 수 있는 option 임

Load

LOAD는 대량의 데이터를 빠른 속도로 테이블로 옮기는데 사용되는 utility 이다.

<예 : educ.exp 파일로부터 orgg테이블로 데이터를 LOAD>

LOAD는 IMPORT 보다 속도가 빠르다. 왜냐하면, 우선 Load utility는 log를 기록하지 않고
물리적인페이지 단위로 데이터를 올리는 반면 Import는 log를 기록하며 내부적으로는
SQL Insert 문장이 반복적으로 수행하여 데이터를 올린다. INDEX 가 생성되는 방법에 있어서도
IMPORT는 IMPORT 되는 레코드 단위로 한번에 하나의 INDEX를 만들지만, LOAD는 데이타의
LOAD 단계가 모두 끝난 이후에BUILD 단계에서 한꺼번에 INDEX를 만드는 특징을 갖고 있기
때문이다.

특기할 만한 옵션은 다음과 같은 것들이 있다.

REORG & RUNSTATS

REORGCHK

REORG utility는 레코드의 insert/delete등으로 인하여 데이터 및 index 페이지의 물리적인 정열
순서가 엉키는 것을 새롭게 정열시켜주는 utility이다. REORGCHK unility는 데이터베이스를 검사하
여 REORG를 할 필요가 있는지를 체크하는 utility이다. 데이터 페이지와 index 페이지의 순서가 서
로 맞지 않으면 성능의 저하를 유발하게 되므로 REORGCHK를 정기적으로 수행하여 데이터베이스
의 물리적인 상태를 확인하는 것이 필요하다.

Syntax

Sample Result

위의 결과에서 REORG컬럼의 내용이 별표(*) 이면 그 테이블은 reorg가 필요하고 하이폰(-)이면
정상이므로 reorg를 할 필요가 없다.

REORG

REORG명령은 해당 테이블의 데이터를 Physical 하게 재정렬하여 조회의 Performance를 향상시 킨다.

Syntax

RUNSTATS

RUNSTATS 는 데이터베이스의 통계정보를 최신 상태로 갱신하는데 사용된다. DB2 optimizer는
access path를 결정할 때 바로 이 통계정보를 참조하므로 대량의 데이터가 삽입되거나 또는 지워
졌을 경우 항상 RUNSTATS를 실행시켜서 통계정보를 갱신하는 것이 중요하다. 또한 REORGCHK
utility도 이 통계정보를 참조하기전에 항
상 RUNSTATS를 먼저 수행하는 것이 좋다.

즉 RUNSTATS a REORGCHK a REORG a RUNSTATS 순서로 항상 함께 사용하는 것이 바람직하 다.