백업과 복구 14

(1)

데이터베이스 (2017-2)

백업과 복구 14

a. 로그 파일과 아카이브 로그

b. 백업의 종류와 특징(핫백업, 콜드백업) c. 증분 백업

d. 완전 복구와 불완전 복구

(2)

로그파일과 아카이브 로그

• 로그 파일

• 로그 파일은 순환하여서 재사용

• 재사용시 기존의 로그 파일이 덮어쓰여지게 됨

• 아카이브 로그

• 로그 파일을 다시 순차적으로 아카이빙 해 놓는 파일

• 데이터베이스에서 별도로 설정 함

1

(3)

데이터베이스 아카이브로그 모드 전환

• 데이터베이스를 종료한 후, MOUNT 단계에서 아카이브 로그 모 드로 전환 (SYS 유저에서 실행)

• SHUTDOWN IMMEDIATE;

• STARTUP MOUNT;

• ALTER DATABASE ARCHIVELOG;

• ALTER DATABASE OPEN;

• 아래와 같이 확인

• ARCHIVE LOG LIST

2

(4)

데이터베이스 (2017-2) 3

(5)

백업의 종류와 특징

• 백업 특징에 따라 구분하는 방법

• 논리적 백업

• 물리적 백업

• 전체 백업

• 전체 백업 + 증분 백업

• 백업 시점(데이터베이스 운영 여부)에 따라 구분하는 방법

• 콜드 백업

• 핫 백업

4

(6)

백업 특징에 따른 구분

5

논리적 백업

 테이블 데이터 및 데이터베이스의 내용을 논리적으로 추출해내어 백업하는 방법

 파일의 내용을 복사하여 저장하는 방법과 유사 (Word 파일의 내용을 메모장에 복사하는 방법과 같음)

 관련한 백업 유틸리티 – Data Pump

물리적 백업

 데이터베이스 파일의 물리적 레벨에 대한 백업을 취득

 데이터베이스 운영 중 백업이 가능

 디스크의 물리적 장애 (미디어 장애)가

발생하더라도 장애 발생 직전까지 복구 할 수 있음

 파일 자체를 복사하여 저장해두는 방법과 유사

 관련한 백업 유틸리티 – DBA 수작업, RMAN 툴

export import

백업 복구

(7)

백업 전략에 따른 구분

6

전체 백업

 모든 할당된 블록을 대상으로 한다

 증분 백업보다 복원시 속도가 빠르다

 매번 모든 할당 된 블록을 복사하기 때문에 많은 공간이 필요

증분 백업

 이전의 백업 이후에 변경된 블록만을 대상으로 한다

 「차분 증분」과「누적 증분」의 2 종류

 1회의 백업량이 적기 때문에 백업·사이즈를 작게 할 수 있다

 복원시 전체 + 차분의적용

Sun Mon Tue Wen Thu Sun Mon Tue Wen Thu

차분증분 누적증분

(8)

실제 백업 전략 예시

7

(9)

복구의 종류와 특징

• 완전 복구

• 마지막 장애 직전 시점까지 데이터베이스를 복구

• 데이터베이스의 풀백업 이후 변경 로그가 모 두 필요함

• 불완전 복구 (또는 Point-in-Time Recovery)

• 특정 시점(SCN 또는 날짜)까지만 데이터베이 스를 복구

• 마지막 풀백업으로부터 복구 시점까지의 로그 가 필요

• 복구 후에는 논리적으로 새로운 데이터베이스 가 됨

• RESETLOG를 수행해야만 함 (Log가 다시 처음 부터 시작됨)

8

(10)

완전 복구 프로세스

1. 손상되었거나 삭제된 파일에 대해 백업을 이용해 복원한다.

2. 증분 백업, 아카이브 로그 파일, 온라인 리두 로그 파일의 적용이 필한데, 이는 현재 최근 시점의 트랜잭션까지 포함되어야 한다. 이 모든 과정에 서 언두 블록이 생성된다. 이를 통상 롤링 포워드(Rolling Forward) 라고 한다.

3. 복원된 데이터 파일은 이제 커밋된 데이터와 커밋되지 않은 변동사항을 포함할 것이다.

4. 언두 블록은 이에 대해 커밋되지 않은 변동 사항에 대해 롤백을 수행하 는데 이용된다. 이를 트랜잭션 복구(Transaction Recovery)라고 칭하기도 한다.

5. 데이터 파일은 이제 온전한 상태로 복구되었고 데이터베이스를 운용할 수 있다.

9

(11)

불완전 복구(또는 PITR) 프로세스

1. 불완전 복구나 데이터베이스 특정 시점 복구는 백업을 이용하여 현재 시점이 아닌 데이터베이스를 생성하고 하는 것이다. 이는 리 두 레코드 전부를 적용하는 것이 아님을 의미한다. 이 복구는 정말 필요한 경우에만 사용해야 함을 기억하고, 특별히 특정 시점 복구 에는 다음이 두 가지가 필요하다.

1. 복구하고자 하는 시점 이전의 유효한 오프라인 혹은 온라인 받은 백업데이 터 파일

2. 백업 시점으로부터 복구하고자 하는 시점까지의 모든 아카이브 로그 파일

2. 불완전 복구를 수행하는 지점까지는 완전 복구와 프로세스가 동일 하다. 다만, 그 시점까지 복구가 끝난 후에는 기존의 로그는 더 이 상 사용할 수 없게 RESETLOG를 수행해야 한다.

10

(12)

불완전 복구(또는 PITR) 프로세스 상세

1. 백업으로부터 데이터 파일 복원: 백업은 복구하고자 하는 시점 이전의 것이어야 한다.

2. RECOVER 명령어 사용: 아카이브 리두로그 파일을 통해 목표하는 시점까지의 리두를 적용한다.

3. 복구 이후의 상태: 이제 데이터 파일은 일정 부분의 커밋된 데이터와 커밋되지 않은 트랜잭션을 포함할 것이다.

4. ALTER DATABASE OPEN RESETLOGS명령어 사용: 데이터베이스는 이제 언두가 적용되기 시점 전으로 오픈된다.

5. 언두 데이터 적용: 리두가 적용되는 동안, 리두에 상응하는 언두 데이터 파일도 적용된다. 따라서 완료되지 않은 트랜잭션에 대해 데이터 파일에 적용하기 위한 언두를 확보하는 것이 가능하다.

6. 복구 완료: 데이터 파일은 선택한 시점으로 복구되었다. 다만, DBID가 변동되고, 로그 시퀀스가 1에서 재시작하기 때문에 새로운 백업을 받을 것을 권장한다.

11

(13)

LAB: RMAN을 이용한 백업

12

[root@db11gxe XE]# rman target sys/oracle_4U@xe

connected to target database: XE (DBID=2833848815) RMAN> RUN {

BACKUP FULL

TAG complete_backup

FORMAT '/backup/db_t%t_s%s_p%p' DATABASE;

}

Starting backup at 17-NOV-17

using channel ORA_DISK_1 [root@db11gxe XE]# ls /backup/

db_t960288750_s3_p1 db_t960288775_s4_p1

(14)

LAB: RMAN을 이용한 완전 복구

13

[root@db11gxe XE]# rman target sys/oracle_4U@xe

connected to target database: XE (DBID=2833848815, not open) RMAN> RUN {

RESTORE DATABASE;

RECOVER DATABASE;

sql 'ALTER DATABASE OPEN';

}

Starting restore at 17-NOV-17

using target database control file instead of recovery catalog allocated channel: ORA_DISK_1

(15)

LAB: RMAN을 이용한 불완전 복구

14

[root@db11gxe ~]# rman target sys/oracle_4U

connected to target database: XE (not mounted) RMAN> RUN {

ALTER DATABASE MOUNT;

RESTORE DATABASE;

RECOVER DATABASE UNTIL SCN 623953;

ALTER DATABASE OPEN RESETLOGS;

} database mounted

Starting restore at 17-NOV-17

(16)

백업과 복구 14