1. Backup & Recovery 개요 2. Backup 3. Recovery 4. Complete & … · 2015-01-21 ·...

II 백업 및 복구

II - 1 II 백업 및 복구

1. Backup & Recovery 개요

2. Backup

3. Recovery

4. Complete & Incomplete Recovery


Failure 범주


Statement failure

- SQL문 수행오류

User Process failure

- OS 프로세스의 비정상 종료

User failure

- 사용자 실수

Network failure

- Network 장애

Instance failure

- OS장애, Database Hang

Media failure

- Datafile 손상


Statement failure


Statement failure의 원인

– Application의 logic error

– Table에 bad data를 입력할 경우– 권한이 없이 operation을 수행할 경우– Quota를 초과해서 table을 생성할 경우– Insert나 Update시 Tablespace에 충분한 여유공간이 없을 경우

※ Statement failure가 발생하면 Oracle Server 또는 운영체제가 오류코드 및 메시지를 반환합니다.

예) ORA-1653: unable to extend table SMARTUSR.BUSTKSUMH_BACKUP by 256 in tablespace TS_FS_PL $ oerr ora 165301653, 00000, "unable to extend table %s.%s by %s in tablespace %s"// *Cause: Failed to allocate an extent for table segment in tablespace.// *Action: Use ALTER TABLESPACE ADD DATAFILE statement to add one or more files // to the tablespace indicated.

Statement failure 해결

– Program logic을 변경

– SQL statement 수정 및 재실행

– 필요한 Database 권한을 부여

– ALTER USER command 사용하여 user quota 변경

– Tablespace에 data file 추가


User Process failure


User Process failure의 원인

– User가 세션에서 비정상적인 연결해제를 수행한 경우

• Client-Server 구성에서 DB에 연결한동안 터미널창을 닫은 경우

– User 세션이 비정상적으로 종료된 경우

• User가 PC를 재부팅한 경우

• OS에서 Oracle user process를 Kill한 경우

– User 프로그램에서 세션을 종료하는 주소 Exception이 발생한 경우

• 프로그램 예외 발생으로 응용프로그램 처리에러 발생

User Process failure 해결

※ DBA는 User procee 오류를 해결하기 위해 조치를 취할 필요가 거의 없음.

– PMON Process는 비정상적으로 종료된 User Process를 감지하고

– PMON은 비정상 종료된 Process의 Transaction을 rollback하여 이 Transcation이 보유한 자원 및 잠

금을 해제함.


User failure


일반적인 User failure 유형

– User가 실수로 테이블을 삭제(drop)하거나 절단(truncate)한 경우

SQL> drop table employee;SQL> truncate table employee;

– User가 테이블에서 모든 행을 삭제한 경우

SQL> delete from employee;SQL> commit;

– User가 Data를 Commit했지만 Commit한 Data에서 오류가 발견된 경우

SQL> update employee set salary=salary*1.5;SQL> commit;

User failure 해결

– 유효한 백업에서 복구한다.

– Export 파일에서 테이블을 Import한다.

– LogMiner를 online/archived logfile을 읽고, 분석하고, 해결한다.

– Point-in-time Recovery를 통해 Recovery한다.

– Oracle 9i의 FlashBack을 사용하여 Historical Data를 보고 Recovery한다.

• undo segments를 이용(undo retention 기간안에서 돌아갈 수 있음)


Instance failure


Instance failure의 원인

– 정전으로 인해 서버를 사용할 수 없게 되는 경우

– CPU 고장, 메모리 훼손 또는 OS 고장 같은 하드웨어문제로 인해 서버사용 불가시– Oracle Server Backgroun Process(DBWn,LGWR,PMON,SMON,CKPT) 중 하나가

Failure 한 경우

Instance failure로부터 Recovery

※ DBA는 특별한 Recovery가 필요없음.

– startup 명령을 사용하여 Instance를 시작하면 Oracle Server는 roll forward 및 rollback 단계를

모두 수행하여 자동으로 Recovery한다.SQL> connect / as sysdbaConnected.SQL> startup...Database opened.• Database가 open되기까지 시간이 오래 걸릴 수 있음.

• SMON은 마지막 checkpoing로부터 online redo logfile에 기록된 변경사항을 적용하여

roll forward Procee를 수행함.

– Instance failure 중에 생성된 Alert Log file 및 Trace file을 읽어 원인을 조사한다.


Media failure


Media failure의 원인

– Database 파일 중 하나를 보유한 디스크드라이브에 헤드고장이 발생한 경우

– Database파일에 대한 읽기 및 쓰기와 관련된 물리적 문제가 발생한 경우– 파일을 실수로 지운 경우

Media failure 해결

– Recovery 전략은 선택한 Backup 방식 및 영향을 받는 파일에 따라 결정한다.

– 사용가능한 경우 Archive된 Redo Log file을 적용하여 마지막 Backup 이후 Commit된

Data를 Recovery한다.


Backup 및 Recovery 전략 정의


업무요구사항

– Mean time to recover (MTTR) : 장애복구시간

– Mean time between failures (MTBF) : 장애간 평균시간

운영요구사항

– 24시간 운영환경에 맞는 구성

– Backup의 유효성을 정기적으로 테스트 및 검증

– Database 휘발성(테이블의 빈번한 갱신, Database 구조의 빈번한 변경)

기술적 고려사항– 자원: 하드웨어, 소프트웨어, 인력 및 시간

– 물리적이미지(datafile) 혹은 논리적 객체(table) 복사본

– Database 구성 및 transaction 볼륨

Disaster Recovery 문제– 자연적 손상시 영향도(지진,홍수,화재)

– 핵심 담당자의 부재


Instance 및 Media Recovery 구조

Userprocess

Serverprocess

PGA

DatabasePassword

fileArchivedlog files

Parameterfile

Data file 3

Redo logfile 2

Data file 2

Control files

Redo logfile 1

Data file 1

InstanceSGA

Redo logbuffer

Data buffercache

Large poolLocks

Shared pool

Data dict.cache

Shared SQLand PL/SQL

PMONDBWnSMON LGWRCKPT ARCn



다중화된 Redo log file

Group 1Group 1

Log1a.rdo

Log1b.rdo

Group 2Group 2

Log2a.rdo

Log2b.rdo

Group 3Group 3

Log3a.rdo

Log3b.rdo

Group 1Group 1

Log1a.rdo

Log1b.rdoDisk 2Disk 2((Member b)Member b)

Disk 1Disk 1((Member a)Member a)

Redo log file 구성에는 Group당 최소 둘 이상의 Redo log Member가 필요하며 Failure할 때를 대비해서 각Member를 다른 디스크에 둡니다.

구성시 유의사항

– Group의 모든 Member는 동일한 정보를 포함하며 크기도 동일함

– Group Member는 동시에 갱신됨

– 각 Group은 동일한 수 및 크기의 Member를 포함해야함.



Database Checkpoint


개념

– Checkpoint는 Recovery가 시작될 위치를 결정하는 데 사용됨

– Dirty Block

– Checkpoint Queue

– Checkpoint Process(CKPT)

Checkpoint 유형

– 전체 Checkpoint

• 모든 Dirty Buffer가 기록됨

• Shutdown normal | immediate | transactional

• alter system checkpoint시

– Incremental Checkpoint(Fast-Start Checkpoint)

• 주기적으로 기록됨

• 가장 오래된 Block만 기록

– 부분 Checkpoint

• Tablespace에 속하는 Dirty Buffer

• alter tablespace begin backup시

• alter tablespace .. offline normal시


다중화된 Control file

Control file 기능

– Control file은 Database의 구조를 설명하는 Binary file

– Database 마운트에 꼭 필요

– Control file 손상에 대비 두개이상의 Control file을 다른 디스크에 두는 게 원칙임

Control file 내용

– Database이름

– Database가 생성된 시간 기록

– Recovery에 필요한 동기화정보(Checkpoint 및 Log Sequence 정보)

– Datafile과 Redo log file의 이름과 위치

– Database의 Archive 모드

Control file 다중화방법

– initSID.ora파일내 control_files 파라미터 편집 또는 추가

– Database Restart시 적용SQL> select name from v$controlfile;NAME-----------------------------------------------/oradata/control01.ctl/oraindx/control02.ctl



Database 동기화

Archive된 Log file

– Archive된 Redo log file과 결합된 Database Backup은 Commit된 모든 Data를 Failure지점까지

Recovery할 수 있도록 보장

– Database가 Online인 동안에도 유요한 Database Backup을 할 수 있음(Online Backup)

Database 동기화

– 모든 Datafile, Redo log 및 Control file이 동기화되지 않으면 Oracle Database를 열 수 없으며,

이러한 경우 Recovery가 필요함

– Database Open을 위해서는 모든 Datafile(Offline 또는 Readonly 제외)이 동일한 Checkpoint를

가져야함

– 동기화는 현재 Redo log Checkpoint 및 Sequence Number를 기반으로 함

– Redo log file에 기록된 변경사항을 적용하면 Datafile이 동기화됨

– Redo log file은 Recovery 단계중 Oracle Server에 의해 자동으로 요청됨

※ 요청된 위치에 Log가 존재해야함.



ARCHIVELOG 모드

LGWR


052053

051054

– 모든 Transaction은 Online Redo Log file에 기록되어 Database Failure시 Transaction을

자동으로 Recovery 할 수 있도록 함

– Database를 ARCHIVELOG모드로 구성하여 Redo 정보기록이 Archive된 파일로 유지관리되도록

할 수 있음. Archive된 Redo Log file은 Media Recovery에 사용할 수 있음

– Online 상태인 Database를 Backup할 수 있음

– Database를 파일손상시 Archive된 Log file을 이용하여 최신상태로 복구가능(Complete Recovery)

– Database를 특정시점까지 Recovery할 수 있음(Incomplete Recovery)

Online Redo Online Redo Log fileLog file

ArchiveArchive된된 Log fileLog file

051

052

053

Redo historyRedo history

052053

051054


ARCHIVELOG 모드 활성화


initSID.ora

– LOG_ARCHIVE_START = true

– LOG_ARCHIVE_MAX_PROCESSES = 4

– LOG_ARCHIVE_DEST = /ARCH

– LOG_ARCHIVE_FORMAT = log_%t_%s.arc

명령어

– 자동 활성화

– ALTER SYSTEM ARCHVIE LOG START;

– ALTER SYSTEM ARCHVIE LOG STOP;

– ALTER SYSTEM ARCHVIE LOG CURRENT;

– ARCHIVE LOG LIST;SQL> archive log listDatabase log mode Archive ModeAutomatic archival EnabledArchive destination /ARCHOldest online log sequence 832Next log sequence to archive 836Current log sequence 836 SQL>




2. Backup

3. Recovery


2. Backup

용 어


전체 DB 백업

– 모든 Datafile 및 Control file에 대한 백업

– 데이터베이스가 열려있거나 닫혀있을 수 있음

부분 DB 백업

– Tablespace

– Datafile

– Control file

일관성 있는 백업

일관성 없는 백업

Data Export 백업

2. Backup

Backup 종류


구 분 내 용 비 고

오프라인

(Cold) 백업

온라인

(Hot) 백업

데이터베이스 shutdown후 데이터

파일을 OS에서 백업

exp/imp

백업

- 가장 안정적이고 확실한 백업

- 백업중 데이터베이스 운영 중단

데이터베이스 운영중 백업상태 표

시후 파일을 OS에서 백업

- 아카이브로그모드에서만 운영 가능

- begin backup, end backup 사이의

OS상 백업

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

- 백업중 변경작업 응답속도 저하

- 스키마나 오브젝트 단위의 백업

- 변경중인 데이터는 백업받지 않음

Logical

백업

데이터베이스 운영중 논리적인 테

이블을 Flat 파일로 백업

Physical

백업

2. Backup

Backup 방식

Closed databaseClosed database Closed or Opened databaseClosed or Opened database

Physical backupPhysical backup

ARCHIVELOG ARCHIVELOG 모드모드NOARCHIVELOG NOARCHIVELOG 모드모드

물리적 백업방식

– Archive를 사용하지 않는 백업은 Media Failure후에 마지막 백업시점까지 Recovery

– Archive를 사용한 백업은 Media Failure후에 실패시점까지 Recovery


2. Backup

오프라인(Cold) Database Backup

Data filesData files Control Control filesfiles

PasswordPasswordfilefile

Parameter filesParameter files Redo log files Redo log files

일관성 있는 전체 DB 백업

– Oracle Database가 닫혀있는 동안 DB를 구성하는 모든 Datafile과 Control file에 대해 수행

– 이 백업에는 Online Redo Log file, Parameter file 및 Password file도 포함될 수 있음

– Normal, Transactional 또느 Immediate 옵션을 사용하여 Database를 정상적으로 종료한 경우

Online Redo Log 파일을 백업할 필요는 없으나 백업되었으면 복구가 단순해짐.

장단점

– 개념적으로 단순함

– 최소한의 명령으로 백업을 수행하기 쉬움

– 운영자 상호작용이 거의 필요하지 않음(단순 스크립트 활용)

– 백업시 DB를 Shutdown해야 함


2. Backup

오프라인 Database Backup 수행

SHUTDOWN IMMEDIATE;

HOST cp <files> /backup/

STARTUP OPEN;

Data filesData files Control Control filesfiles

Parameter Parameter filesfiles

Log Log filesfiles

PasswordPasswordfilefile

백업수행방법

– 인스턴스 정상 종료후 OS utility(cp,tar 등)를 사용하여 백업

– Oracle Instance 재시작

백업수행지침

– 종료명령은 normal, immediate, transactional을 사용

– 전체 closed backup을 수행할 경우 초기화 parameter file과 password file 백업

– Read Only Tablespace에 연관된 파일은 전체 백업에 포함하지 않아도 됨

– Offline(Cold) Backup을 수행하는 동안 DB가 오픈될 경우 해당 백업은 유효하지 않으며

Recovery 상황에서 사용할 수 없을 수 있음


2. Backup

온라인(Hot) Database Backup

Data filesData files

Control filesControl files

Parameter filesParameter filesPassword filePassword file

Archived redoArchived redolog fileslog files

Online redoOnline redolog fileslog files

온라인 Database Backup의 특징

– Archive Log모드에서 수행되며 Archive Log file을 백업해야함

– Backup중에 Database를 정상적으로 사용가능(가용성)

– Tablespace 또는 Datafile 레벨에서 수행가능

– 매일 24시간 운영되는 업무 지원


2. Backup

온라인 Database Backup 요구사항

온라인 Database Backup 요구사항

– Database가 ARCHIVELOG모드로 설정되어 있고 Online Redo Log가 Archive 되었을 때

Database 사용중에도 Tablespace 또는 개별 Datafile을 백업할 수 있음

– Datafile이 백업모드에 있으면 Log Writer가 변경된 Block에 대한 이미지를 Redo Log에

기록하므로 Redo Log의 크기 및 Log Writer의 성능에 영향을 줄 수 있음


2. Backup

Online Tablespace Backup 수행방법

SQL> ALTER TABLESPACE users BEGIN BACKUP;

SQL> !cp /oradata/users01.dbf /BACKUP/users01.dbf

SQL> ALTER TABLESPACE users END BACKUP;

Tablespace Backup을 수행하는 방법

– ALTER TABLESPACE ... BEGIN BACKUP 명령을 실행하여 해당 Datafile이나 Tablespace를

Backup 모드로 설정한후 OS Backup 유틸리티를 사용하여 백업

– 백업이 끝나면 ALTER TABLESPACE ... END BACKUP 명령을 실행하여 일반모드로 설정

– Recovery에 필요한 Redo가 Archive 되도록 Archive시킴

– 백업수행시간에 쌓인 Archive Log file을 백업해야함

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;


2. Backup

Online Tablespace Backup 실패


Tablespace Backup 실패– 백업도중 시스템 고장, Database 종료 들의 상황으로 백업에 실패한 경우

– OS에서 백업이 완료되지 않은 파일은 다시 백업해야 함

– Oracle Server는 파일에 백업에서 Restore되었다고 가정하므로 Database Open 실패됨

– Database nomount 상태에서 ALTER DATABASE ... END BACKUP 명령을 사용하면

해당 Datafile은 동기화정보를 맞추어줌

Online Backup 종료– v$backup을 이용하여 Backup 상태를 확인

SQL> select * from v$backup;FILE# STATUS CHANG# TIME------- ------------------------ ------------ ----------

1 NOT ACTIVE 0 2 ACTIVE 228596 30-SEP-04

– Active 상태인 데이터파일을 종료SQL> ALTER DATABASE datafile 2 END BACKUP;

– Active 상태인 모든 데이터파일을 한번에 종료하는 방법(oracle 9i)SQL> ALTER DATABASE END BACKUP;

Binary 이미지 생성

– 이 명령을 사용하면 Control file의 Binary 복사본이 생성됨

– Recovery시 이 복사본을 이용하여 복구할 수 있음(using backup controlfile 옵션)

텍스트 스크립트로 생성

– 이 명령을 사용하면 USER_DUMP_DEST에 지정된 디렉토리에 Trace file로 만들어짐

– 데이터베이스 복구시 STARTUP NOMOUNT후 이 스크립트를 수행하면 Control file이 생성됨

Control file Backup

alter database backup controlfile to trace;

alter database backup controlfile to ‘control1.bck’;

2. Backup


2. Backup

Online Backup 매커니즘


Alter tablespace ts_name begin backup ;– Tablespace에 속하는 모든 data file들은 hot-backup-in-progress라고 mark된다

– Online-backup mode에 있는 모든 data file들에 대해 checkpoint가 발생한다.

– File header의 checkpoint SCN은 begin backup command를 사용한 SCN으로 진행한다.

– 이후의 checkpoint는 file header에 쓰여지지 않는다

– Online-backup mode에 있는 data file의 block에 대해 첫번째 변경이 일어날 경우 전체 block을logging하기 시작한다

Alter tablespace ts_name end backup ;

– begin backup checkpoint SCN을 가지는 redo record를 설정한다.

– block image의 logging이 종료되고 data file의 checkpoint가 database checkpoint까지 진행한다.

Online backup시의 주의 사항

– database는 archive log mode로 운영 중이어야 한다

– begin backup과 end backup사이에 발생한 모든 archived log file도 backup되어야 한다.

– Online backup이 종료되면 반드시 end backup을 하여 backup이 끝난 tablespace의 모든 data file을nobackup mode로 바꾸어 주어야 한다.

– Online backup중에는 shutdown normal, shutdown immediate와 backup중인 tablespace의 offline은 불가능하다

2. Backup

HOT backup mechanism

NO-BACKUP mode시의 redo logBACKUP mode시의 redo log

OS block

OS block

OS block

OS block Oracle block (2K)

UpdateUpdate

수 bytes redo record2K





2. Backup

3. Recovery


3. Recovery

Recovery 종류


Object Recovery

- Data Export/Import

- Index 재생성

Block Level Recovery

- Instance Recovery

Media Recovery

- Database, Tablespace, Datafile

- Read-only tablespace

- Redolog

- Control file

3. Recovery

Block Level Recovery


- 오라클의 비정상 상태로 프로세스가 강제 종료될 때 발생된 비정상적인 상태의 오라클 메모리 블록의 복구

- Instance Recovery로 오라클 데이터베이스에서 기본적으로 자동 처리되는 기능 중 하나임.

- 만일 오라클이 트랜잭션의 비정상 종료나 오라클 인스턴스 장애 등으로 손상된 버퍼를 발견하게 되면,

장애 발생 이전의 버퍼 상태로 복구를 자동으로 시도

- 운영자의 특별한 조작이나 확인이 필요없이 오라클이 알아서 자동으로 처리

- 블럭의 복구는 kcrabr()이라는 오라클 내부 펑션이 호출되어 수행됨

- 프로세스가 비정상 종료 또는 취소 되었을 경우, 메모리 상에서 블럭의 내용이 바뀌는 중이었다면

이 펑션의 호출을 통해 복구가 수행됨. 보통 정상적인 경우에는 PMON이 이것을 수행하게

되지만, SMON이나 서버 프로세스에 의해서 수행될 수도 있음.

- 이 작업을 위해서 오라클은 해당 버퍼의 내용을 데이터 파일에서 읽은 후, 온라인 리두로그에서

마지막 체크포인트 이후의 변경사항 정보를 찾아서 적용하게 됨. 따라서 블럭의 복구를

위해서는 온라인 리두로그파일과 데이터파일이 필요함.


Instance Failure후 Oracle은 자동으로 Crash Recovery 및 Instance Recovery를 수행합니다.

Recovery 단계

– Datafile이 동기화되지 않은 상태

– Rollforward(Redo log 적용)

– Datafile내 Commit된 Data 및

Commit되지 않은 Data 상존

– Database Open

– Commit되지 않은 Data Rollback

Data file 3

Redo logfile 2

RBS Data File

Control file

Redo logFile 1

Database

146.5

145

146.5 146.5Data File 1

146.1

146.2

SQL*Plus Serverprocess

PGA

UndoUndo

CheckpointCheckpoint

InstanceSGA

Redo logbuffer

Large poolLocks

Shared pool

Data dict.cache

Shared SQLand PL/SQL

PMONDBWnSMON LGWRCKPT ARCn

Data buffercache

Undo Datafile

Data file 1

146.5Redo log

file 1146.5

146.5

3. Recovery

Instance Recovery 단계

3. Recovery

Media Recovery


손실되거나 손상된 Datafile 또는 Control File의 Recovery

- Datafile이 Offline Normal 옵션을 사용하지 않고 Offline 상태가 된 경우

- Disk의 H/W 장애로 인한 경우

명시적 호출 필요

- 사용자가 운영체제 명령으로 Backup 본을 명시적으로 적용시켜야 합니다.

작동 순서

1) Backup에서 파일 Restore

(손실되거나 손상된 파일을 복사본으로 대체)

2) Archive 된 Redo Log File과 Online Redo Log에서 Redo 데이터를 Recover

(대체한 복사본 이후에 기록된 변경사항을 순차적으로 적용하는 것)

Media Recovery 단계

RBSRBS

②

③

④

⑤

Commit / UnCommit Transaction 포함하는 Datafile

Archive Redo Log File

Online Redo Log File

DataFile

3. Recovery

Recover 완성된 DatafileRestore된 Datafile

①

1) 손상된 파일이 Backup에서 Restore가 완성된 단계

2) Datafile이 Backup된 시점 이후부터 현재까지의 Archive Redo Log File 과 Online Redo Log File의 변경 사항이 적용됩니다. 이 과정을 Roll forward 라고 합니다. (Redo 적용)

3) 현재 이 단계에서 Commit 된 변경 사항과 Commit 되지 않은 변경사항이 동시에 포함되어 있을 수 있습니다.

4) Undo Segment의 정보를 참조하여 실제 물리적 Data는 변경되었지만 Log에는 Commit 되었다는 기록이 없는 변경사항을 기존 값으로 되돌립니다. 이 과정을 Rollback 이라 합니다. (Undo 적용)

5) Recovery가 완료된 상태 입니다.


3. Recovery

Media Recovery 유형


컨트롤파일 복구

온라인 리두로그파일 복구

Datafile 복구

Tablespace 복구

Read-only Tablespace 복구

전체 Database 복구

- Noarchivelog 모드에서 Recovery

- Archivelog 모드에서 Recovery

. Complete Recovery

. Incomplete Recovery

3. Recovery

Recover 명령


RECOVER DATABASE

– Closed Database Recovery 만 사용할 수 있습니다.

– Oracle Instance는 Mount 단계이어야 합니다.

– System Tablespace 를 복구해야 하는 경우 이 명령어로만 가능합니다.

RECOVER DATAFILE ‘/ORADATA/u03/user01.dbf’– Oracle Instance가 Open 혹은 Mount 상태 일 때 모두 가능합니다.

– Datafile 단위로 Recovery 합니다.

RECOVER TABLESPACE USERS

– Oracle Instance가 Open 단계 일 때만 사용 가능합니다.

(Mount 단계에서는 Tablespace에 대한 정보에 접근할 수가 없으므로)

– Tablespace 단위로 Recovery 합니다.

3. Recovery

Resetlogs


명령어

– alter database open resetlogs

Resetlogs 옵션 사용시기

– 불완전 미디어 복구(Incomplete media recovery)

– 백업받은 컨트롤파일을 이용한 복구

– 컨트롤 파일을 새로 생성한 복구

Resetlogs를 사용시 정상 오픈조건

① 데이터 파일 호환모드는 데이터베이스 자체의 호환모드 설정보다 크면 안됨.

(호환모드 설정파라미터 예: compatible = 9.2.0.0.0 )

② 오프라인(Offline)된 파일들은 온라인(Online)되거나 DROP되어야 함.

③ 파일들은 동일한 체크포인트 SCN을 가지고 있어야 함.

3. Recovery

Control file Recovery

Control file 재생성 해야 하는 경우

– 오류로 인해 모든 Control file이 손실된 경우

– Database 이름을 변경해야 하는 경우

– Control file의 현재 설정을 변경해야 하는 경우

Control file Recovery 방법 - 1 (현재 Control file 사용)

– Control file 이 다중화 되어 있는 경우 현재 복사본을 사용하여 손실된 파일을 Restore

Control file Recovery 방법 - 2 (새 Control file 생성)

– Control file을 Trace File로 변환하여 백업 해놓은 경우 이것을 이용하여 생성

– DBA 가 직접 CREATE CONTROLFILE 명령을 사용하여 새 파일을 생성.(이 작업을 수행하려면Database의 모든 파일을 알고 있어야 함)

Control file Recovery 방법 - 3 (Backup Control file 사용)

– RECOVER DATABASE USING BACKUP CONTROLFILE 명령을 사용(이 방법은 모든 Control file이 손실된 경우 필요)


3. Recovery

Backup Control file 사용 Recovery : 예제

장애상황- 현재 시간은 2004년 10월 9일 12:00 이며 오전 11:45 경에 employees 테이블을 포함하는

Tablespace가 Drop됨

- 지난 밤 백업본에 Control file이 포함되어 있음

Recovery 방법

- 단계1 : Database가 Open 상태인 경우 정상 종료시킴

- 단계2 : 해당 Tablespace에 존재했던 시점의 모든 Datafile및 Control file을 Restore

- 단계3: Database를 Mount하고 v$recover_file 조회후 Offline Datafile이 존재하면 Online 전환

- 단계4: Recovery 수행SQL> RECOVER DATABASE UNTIL TIME ‘2004-10-09:11:44:00’ using backup controlfile;

- 단계5: RESETLOGS 옵션을 사용하여 Database를 Open(Control file과 Redo의 Sync)SQL> ALTER DATABASE open resetlogs;

- 단계6: EMPLOYEES 테이블을 존재 확인

- 단계7: 오전 11:44 이후에 입력한 모든 데이터를 다시 입력하도록 함


3. Recovery

Online Redolog file Recovery


Redolog 장애 감지

– v$log의 invalid 및 stale상태 check

– alert.log 및 redo log error에 관련된 background trace file error 감지

– v$archive,v$log,v$logfile을 통해서 current log와 archive된 log check

Redolog 장애 유형 및 조치

– 특정 log group내 member의 장애

=> 해당 log member drop후 add logfile member

– Inactive 상태의 리두로그 파일이 손상되었을 경우

=> 해당 log group을 삭제하고 재생성(shutdown후 mount 상태에서)

– Current online redo log가 손상되었을 경우

=> 백업본을 전체 Restore하고 Recovery 수행

3. Recovery

Current Redo Log file 손실 : 예제

장애상황- 현재 Active한 Online Redo Log file에 문제가 발생하여 Background Process가 종료됨

- Database를 Open하려고 하자 Current Redo Log Group 2 의 Log member 에러 메시지가 출력됨

- 현재 Active한 Group이므로 Archive 명령도 불가능하며 CLEAR LOGFILE 명령도 실행 되지 않음

Recovery 방법

- 단계1 : Database를 Mount하고 v$log를 조회하여 현재 Log Sequence Number를 기록(61번)SQL> select * from v$log;GROUP# … SEQ# BYTES … ARC STATUS… FIRST_TIME------------- --------- ---------- ------ ------------ -----------------

1 60 153600 NO INACTIVE2 61 153600 NO CURRENT

- 단계2 : 가장 최근 Backup에서 모든 Datafile을 Restore(Archive Log도 Restore 해야함)

- 단계3: Redo Log 61번까지 Recovery 수행SQL> RECOVER DATABASE UNTIL CANCEL;



3. Recovery

Recovery 할 파일 결정

단계1: V$RECOVER_FILE을 통해 Recovery가 필요한 Datafile을 결정

SQL> SELECT * FROM V$RECOVER_FILE;

FILE# ONLINE ONLINE_STATUS ERROR CHANGE# TIME---- ------ ------------- ------ -------- ---------

2 OFFLINE OFFLINE 299882 22-JUL-02

단계2: V$ARCHIVED_LOG를 통해 Database의 Archive된 모든 Redo Log file 목록을 확인

단계3: V$RECOVERY__LOG를 통해 Recovery에 필요한 Archive된 모든 Redo Log file 목록을 확인

SQL> SELECT * FROM V$RECOVERY_LOG;

THREAD# SEQUENCE# TIME ARCHIVE_NAME-------- ---------- -------- ----------------------------

1 34 02-MAR-01 /…/ORADATA/ARCHIVE1/arch_34.arc1 35 03-MAR-01 /…/ORADATA/ARCHIVE1/arch_35.arc1 36 04-MAR-01 /…/ORADATA/ARCHIVE1/arch_36.arc


3. Recovery

Read Only Tablespace Recovery

Read-only

Read-only

Read-only

Read-write

Read-write

Case 1

Case 2

Case 3


Backup 1 Backup 2 Recovery

Case 1– Recovery할 Tablespace가 현재 Read only이고 마지막 Backup을 수행할 당시에도 Read Only

=> 이 경우는 Redo 정보를 적용할 필요 없이 Backup에서 Tablespace를 Restore하기만 하면 됨.

Case 2– Recovery할 Tablespace가 현재 Read write 상태이고 마지막 Backup은 Read Only

=> 이 경우 Backup에서 Tablespace를 Restore하고 해당 Tablespace가 Read-Write 된 시점부터Redo 정보를 적용

Case 3– Recovery할 Tablespace가 현재 Read Only이지만 마지막 Backup은 Read-Write 상태

=> Backup에서 Tablespace를 Restore하고 해당 Tablespace가 Read Only 상태가 된 시점까지

Recovery 해야 함.(이런 경우를 방지하기 위해 Read-only 적용후엔 반드시 백업을 수행해야함.)

3. Recovery

NOARCHIVELOG 모드에서의 Recovery

NOARCHIVELOG 모드에서 고려해야 할 점

– Closed Database Backup을 통해서 모든 Datafile들과 Control File 및 Redo Log File 을 Recovery 해

야 합니다.

– 만약 Online Redo File 이 재 사용(Overwrite)되지 않았다면 단순히 마지막 Backup 이후의 Online

Redo log file의 기록만 적용하여 Complete Recovery 할 수 있습니다.

NOARCHIVELOG 모드의 장점

– 보통 Recovery 단계가 없음. 운영 체제 명령의 Restore만 존재하므로 수행하기 쉽고 오류 발생 위험이

적습니다.

NOARCHIVELOG 모드의 단점

– 데이터가 필수 불가결하게 손실되므로 현실적으로 Complete Recovery가 불가능합니다.

– 수동으로 데이터를 재 입력하거나, Log Switch 를 통해 Online Redo Log File이 재사용 되지 않았을

경우에만 Complete Recovery 가능 합니다.

– 전체 Database 가 마지막 완전히 닫힌 시점 (Closed Backup) 로 Restore 됩니다.


3. Recovery NOARCHIVE LOG 모드에서

Redo Log File Backup이 존재 하는 경우에 따른 Recovery

146

146

146

146 146

145

Datafile

Control file

Redo Log file

Database

144

144

144

144 143

142

Datafile

Control file

Redo Log file

Backup

가장 최근의Closed Backup에서

Restore


시나리오

- 디스크가 손상되어 2번째 Datafile이 손상되었으며, Online Redo Log File은 2개 존재합니다.

- Log Sequence number 143에서 최근 Closed Backup이 수행되었고 현재 LSN은 146 입니다.

- Online Redo Log File 144가 재 사용 되었으므로 Datafile을 Recovery 할 수 없습니다.

Online Redo Log File 있는 경우

- 가장 최근의 Closed Backup인 143 상태로 Datafile/Control File/Online Redo log File을 Restore 한 후User가 수동으로 그 이후의 현재까지의 Data를 입력해야만 합니다.

NOARCHIVE LOG 모드에서Redo Log File Backup이 존재 하지 않는 경우에 따른 Recovery

3. Recovery

146

146

146

146 146

145

Datafile

Control file

Redo Log file

Database

111

1

1

144

144

144

144 143

142

Datafile

Control file

Redo Log file

Backup

가장 최근의Closed Backup에서

Restore 한 후RESETLOG를

통해 LSN 을 1로 설정


Online Redo Log File 없는 경우

- 가장 최근의 Closed Backup인 143 상태로 Datafile/Control File 을 Restore 한 후 Oracle에서 Online Redo Log를 재설정할 수 있도록 다음과 같이 Incomplete Recovery를 모방합니다.

SQL> RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFIILE ;

(원래 필요 없는 절차지만 RESETLOG 옵션이 Incomplete Recovery 후 만 사용 할 수 있으므로)

- RESETLOG 옵션으로 Current Redo Log Sequence Number 를 1로 재 설정합니다.

SQL> ALTER DATABASE OEPN RESETLOGS ;

3. Recovery

ARCHIVELOG 모드에서의 Recovery


Complete Recovery

– Redo log 데이터와 Backup 본을 사용하여 가장 최근 시점까지 갱신합니다.

– 모든 Redo의 변경 사항을 적용하며 데이터가 손실되지 않습니다.

– 손실된 특정 Datafile만 Restore, Recovery 하면 되며, Control file, Redo Log file 등은 Restore 가 필

요하지 않습니다.

– 과거 Backup 시점부터 현재까지의 모든 Archive Log file과 아직 Archive 되지 않은 Transaction을 포

함하는 Online Redo Log file이 필요합니다.

Incomplete Recovery

- Redo log 데이터와 Backup 본을 사용하여 User가 원하는 특정 시점 까지 Database를 갱신합니다.

- 전체가 아닌 일부의 Redo 변경 사항만을 적용합니다.

3. Recovery

Recover 중 Archive Redo Log File 적용

Archive 위치를 변경하려는 경우1) Archive Redo Log File이 LOG_ARCHIVE_DEST_n 디렉터리에 Restore 되지 않은 경우 그 위치를

Oracle 서버에게 가르쳐 줄 필요가 있습니다.

cf> Datafile의 경우에는 ALTER DATABASE RENAME FILE 명령 사용

2) ALTER SYSTEM ARCHIVE LOG…은 Control file에 새로운 Archive log 위치를 갱신합니다.

3) Archive 된 Log File을 입력하라는 프롬프트에 위치 및 이름을 지정합니다.

4) RECOVER FROM <LOCATION> DATABASE 명령 사용합니다.

SQL> RECOVER FROM ‘<NEW LOCATION>’ DATABASE

Archive Redo Log file을 자동으로 적용하려는 경우1) Media Recovery를 시작하기 전에 SET AUTORECOVERY ON 명령 실행합니다.

2) Archive 된 Log File을 입력하라는 프롬프트에 AUTO 입력합니다.

SQL> RECOVER DATAFILE 4ORA-00279: change 308810…07/22/02 17:00:14 needed for thread 1ORA-00289: suggestion : /ORADATA/ARCHIVE1/arch_35.arcORA-00280: change 308810 for thread 1 is in sequence #35Specify log: {<RET>=suggested | filename | AUTO | CANCEL}AUTOlog applied.

3) RECOVER AUTOMATIC.. 명령을 사용 합니다.





2. Backup

3. Recovery



Complete Recovery 방식


Close 상태에서 Database Recovery

– Database가 하루 24시간 일주일 내내 운영되는 것이 아닌 경우

– Recovery 되는 파일이 시스템 Tablespace 또는 Undo 세그먼트 Tablespace에 속한 경우

– 전체 Database 또는 대부분의 Datafile을 Recovery해야 하는 경우

Open 상태에서 Database Recovery (장애시 Close안된 경우)

– 파일 손상, 과실로 인해 파일 손실이 발생하였으나 Database가 종료되지 않은 경우

– Database를 하루 24시간 일주일 내내 운영하므로 Database의 Shutdown을 최소화 해야 하는 경우

– Recovery 되는 파일이 시스템 Tablespace 혹은 Undo 세그먼트 Tablespace에 속하지 않은 경우

Open 상태에서 Database Recovery (장애시 Close 된 경우)

– 매체 또는 하드웨어 고장으로 인해 Oracle이 강제종료된 경우

– Database를 하루 24시간 일주일 내내 운영하므로 Database의 Shutdown을 최소화 해야 하는 경우


Backup을 사용하지 않는 Datafile Recovery (No Restore exits)

– Media Failure 또는 User 실수로 인해 Backup 되지 않은 Datafile이 손실된 경우

– 파일이 생성된 이후의 모든 Archive 된 Log가 있는 경우



Close Database Recovery: 예제

장애 상황– U01 디렉토리에 손상된 Block이 포함되어 있고 이곳에는 Datafile 1이 저장되어 있음.

– V$DATAFILE 및 V$TABLESPACE를 통해 Datafile 1이 SYSTEM Tablespace에 속하는 파일이라는 것을 알았음.

Recovery 방법

- Instance가 아직 종료되지 않았다면 다음과 같이 SHUTDOWN 명령을 실행SQL> SHUTDOWN ABORT

- 가능하면 가장 최근 Backup에서 파일을 RestoreUNIX> cp /BACKUP/system01.dbf /ORADATA/u01

- Mount 모드로 Instance를 시작하고 Datafile을 Recovery SQL> STARTUP MOUNTSQL> RECOVER DATABASEORA-00279: change 148448 …07/23/02 17:04:20 needed for thread ORA-00289: suggestion : /ORADATA/ARCHIVE1/arch_144.arcORA-00280: change 148448 for thread 1 is in sequence #144 Log applied.

- Recovery가 완료 되면 모든 Datafile이 동기화 됨SQL> ALTER DATABASE OPEN;



Open Database Recovery (장애시 Open 상태): 예제

장애 상황– Database가 현재 Open 상태이고 실수로 운영 체제 명령을 사용하여 Datafile 2를 제거함.

– 다음 명령을 사용하여 해당 Datafile이 속한 Tablespace를 확인 하였음.

SQL> SELECT file_Id F#, file_name, tablespace_name, status from dba_data_files ;F# FILE_NAME TABLESPACE_NAME STATUS--- --------- ---------------- ---------1 /disk1/data/system01.dbf SYSTEM AVAILABLE2 /disk2/data/df2.dbf USER_DATA AVAILABLE3 /disk1/data/rbs01.dbf RBS AVAILABLE

Recovery 방법

- 해당 파일을 Restore(Offline 상태가 아닐 때는 임의로 Offline 시켜준 후 실행)UNIX> cp /disk1/backup/df2.dbf /disk2/data/

- Recover 명령을 사용하여 Archive 및 Redo Log를 Restore된 Datafile에 적용SQL> RECOVER DATAFILE ‘/disk2/backup/df2.dbf’또는, SQL> RECOVER TABLESPACE user_data

- Recovery가 완료 되면 모든 Datafile이 동기화됨. Datafile을 Online 상태로 만듦.SQL> ALTER DATABSE DATAFILE ‘disk2/data/df2.dbf’ online;또는, SQL> ALTER TABLESPACE user_data ONLINE;



Open Database Recovery (장애시 Close 상태): 예제장애상황

– Datafile 2 만 포함하는 디스크 제어 장치의 오류로 Media Failure가 발생하여 DB가 다운됨

– Datafile 2 는 시스템 또는 Undo 세그먼트 Datafile이 아님.

– 서비스를 위해 일단 Database를 Open한 후 Recovery를 하기로 결정

Recovery 방법

- Database Mount. Datafile 2를 열 수 없으므로 Database가 열리지 않음.

- 해당 파일을 Offline 상태로 만듦.(V$DATAFILE을 질의하여 파일이 Online 상태임을 확인)SQL> ALTER DATABASE datafile ‘/disk2/data/df2.dbf’ offline;SQL> ALTER DATABASE OPEN;

- 이제 파일을 Restore 합니다. 손상된 Disk 2 에 Restore 할 수 없으므로 Disk 3을 이용

또한 Oracle Server 에게 새로운 파일 위치를 알려야 함UNIX> cp /disk1/backup/df2.dbf /disk3/data/SQL> ALTER DATABASE rename file ‘/disk2/data/df2.dbf’ to ‘/disk3/data/df2.dbf’

- Recover 명령을 사용하여 Archive 및 Redo Log를 Restore된 Datafile에 적용.SQL> RECOVER DATAFILE ‘/disk3/data/df2.dbf’

- Recovery가 완료 되면 모든 Datafile이 동기화 됨. Datafile을 Online 상태로 만듦.SQL> ALTER DATABASE datafile ‘/disk3/data/df2.dbf’ online;



Incomplete Recovery 개요


Incomplete Recovery는 장애 시점 이전으로 Database를 재생성함.

- Disk의 H/W 장애로 인한 경우 이 상황에서는 Recovery 시점 이후의 Commit 된 Transaction의 데이

터가 손실되므로 필요에 따라 이 데이터를 수동으로 다시 입력해야 함

- Incomplete Recovery는 복잡하고 시간이 많이 소요되는 작업일 수 있음

Incomplete Recovery를 수행하려면 다음이 필요함

- Recovery 시점 전에 만들어진 모든 Datafile의 적합한 Offline 또는 Online Backup

- Backup으로부터 지정된 Recovery 시점까지의 모든 Archive Redo Log

Incomplete Recovery는 일반적으로 Complete Recovery 작업이 실패한 경우 사용

- 최대한 Complete Recovery 를 하려고 노력한 후 불가피한 상황에서만 실행


Incomplete Recovery가 필요한 상황


Archive Log가 손실되어 Complete Recovery가 실패한 경우

- 잘못되었거나 손실된 Archive Log 로 인해 Complete Recovery 작업이 실패한 경우, 해당 Archive Log

를 적용하기 전의 시점까지만 Recovery를 완료할 수 있음

Archive 되지 않은 모든 Online Redo Log File Datafile이 손실된 경우

- Online Redo Log를 이중화 하지 않은 상태에서 Archive 하기 전에 Datafile과 함께 Online Redo Log가

손실된 경우, 손실된 Redo Log 이후의 시점에 대해서는 Recovery를 계속 할 수 없음

User 오류

- User가 테이블을 잘못 삭제했거나 잘못된 WHERE 절을 사용하여 갱신한 데이터를 Commit 한 경우 등.

Backup Control file을 사용하여 Database를 열어야 하는 경우

- Control file을 이중화 하지 않았고 Trace File로 Backup 해 놓은 것도 없으며 Database의 구조도 모르지

만 이전의 Control file Binary 복사본 Backup이 있는 경우


Incomplete Recovery의 유형

Time-based Recovery- 모든 변경 내용이 지정된 시간 기준의 시점 까지 Recovery

- 데이터에 대해 원하지 않는 변경 작업을 수행했거나 중요한 테이블을 삭제했으며 이러한 오류가 발생한대략적인 시간을 알고 있는 경우

- 이중화 되지 않은 Online Redo Log 가 훼손된 대략적인 시간을 알고 있는 경우

Cancel-based Recovery

- Recovery 하는 도중 뜨는 프롬프트에 Log file 이름 대신 CANCEL을 입력하면 Recovery 완료

- Recovery 과정 중에 훼손되지 않은 모든 Log File 들을 최대한 적용할 경우 사용

- Online Redo Log File을 이중화하거나 Archive Log File을 자주 Backup하고 다중화하면 이러한 유형의Recovery가 불필요

Change-based Recovery

- 모든 변경 내용이 지정된 SCN(System Change Number)까지 적용된 후에 완료

Backup Control file을 이용한 Recovery

- 모든 Control file이 손실되었으며 Control file을 재생성 할 수 없으나 Control file의 Binary Backup이 있는 경우 사용

- Database 구조가 현재와 달라지는 시점까지 불가피하게 Recovery를 해야 하는 경우



Incomplete Recovery 지침


모든 과정을 주의하여 수행

- Incomplete Recovery에서 발생하는 대부분의 문제는 Recovery 중 DBA의 실수로 인한 것이므로 모든

Recovery 단계를 꼼꼼하게 수행하는 것이 중요

Recovery 전후에 완전 Database Backup 수행

- Recovery 실패시 재시도 또는 롤백을 위한 시간 절약

- 예정된 다음 Backup이 수행되기 전에 Recovery가 필요할 경우를 대비할 수 있음

항상 Recovery의 성공 여부 확인

- Recovery에 실패해서 다시 수행하는 일이 없도록 하려면 User가 시스템을 다시 사용 할 수 있도록 하기

전에 문제가 모두 해결되었지만 항상 확인해야함

Archive 된 Log 를 Backup 한 후 제거

- 시스템에서 Archive 된 Log를 제거 하여 새로운 Archive 가 Recover 전 시점의 Archive와 섞이는 것을

방지해야함


Incomplete Recovery Procedure


1) Database 종료 및 Backup

- Shutdown abort로 Database를 종료한 후 Recovery 시작하기 전 Backup을 수행

2) Datafile Restore

3) Database Mount

- Database 동기화 정보가 맞지 않기 때문에 Open이 불가능

4) Datafile을 장애 시점 이전으로 Recovery

- Until cancel을 사용한 Cancel-based Database RecoverySQL> RECOVER DATABASE until cancel

- Until time을 사용한 Time-based Database RecoverySQL> RECOVER DATABASE until time ‘2004-10-01:14:20:00’

- Backup Control file을 사용한 RecoverySQL> RECOVER DATABASE until time ‘2004-10-01:14:20:00’ using backup controlfile

5) RESETLOGS를 사용하여 Database OpenSQL> ALTER DATABASE OPEN RESETLOGS

6) Closed Database Backup 수행

7) 혼돈방지를 위해 기존 Archive log 제거


Resetlogs


Resetlogs 옵션 사용시기

- 불완전 미디어 복구 (Incomplete Media Recovery)

- 백업받은 컨트롤파일을 이용한 복구

- 컨트롤파일을 새로 생성한 복구

Resetlogs를 사용시 정상 오픈조건

① 데이터 파일 호환모드는 데이터베이스 자체의 호환모드 설정보다 크면 안됨.

(호환모드 설정파라미터 예: compatible = 9.2.0.0.0 )

② 오프라인(Offline)된 파일들은 온라인(Online)되거나 DROP되어야 함.

③ 파일들은 동일한 체크포인트 SCN을 가지고 있어야 함.


Time-based Recovery : 예제

장애상황- 현재 시간은 2004년 10월 9일 12:00 이며 11:45 경에 emplyees 테이블이 삭제됨

- 현재 Database 작업량은 최소 상태이고 테이블을 반드시 Recovery 해야 함.

Recovery 방법


- 단계1 : Database 구조가 오전 11:44 이후로 변경되지 않았으므로 UNTIL TIME 방식을 사용가능



- 단계4: Database를 Mount

- 단계5: Database를 Recovery SQL> RECOVER DATABASE UNTIL TIME ‘2004-10-09:11:44:00’





Cancel-based Recovery : 예제

장애상황- 현재 시간은 2004년 10월 9일 12:00 이며 오전 11:45 경에 디스크 오류로 employees 테이블과

Online Redo Log file 하나도 손상됨

- v$log와 v$logfile을 조회한 결과 손상된 Redo Log는 시퀀스 48번이며 오전 11:34 이후의 정보를 포함

하고 있었음(26분동안의 데이터 손실)

Recovery 방법



- 단계3: Database를 Mount

- 단계4: Log Sequence Number 48까지 Database를 RecoverySQL> RECOVER DATABASE UNTIL CANCEL





1. Backup & Recovery 개요 2. Backup 3. Recovery 4. Complete & … · 2015-01-21 ·...

Documents

Transcript of 1. Backup & Recovery 개요 2. Backup 3. Recovery 4. Complete & … · 2015-01-21 ·...