백업과 복구

1. 사용자 백업 및 복구

1.1. 사용자 백업 및 복구 개요

오라클에서는 OS명령과 SQL명령을 이용한 사용자백업과 RMAN을 이용한 백업 및 복구 방법이 지원된다.

오라클 관리자 입장에서 볼 때 사용자백업 및 복구는 RMAN으로 작업을 할 수 없을 때를 위한 백업 및 복구 방법이다.

예를 들어 다음의 경우에 RMAN 대신 사용자백업 및 복구를 사용하게 된다.

● 오라클 7.0 버전이나 그 이전 버전을 사용하는 경우(RMAN은 8.0부터 지원된다)

● RMAN으로 백업한 내용을 손실했을 때 사용자방식으로 백업한 내용을 대체할 수 있다.

● 구 버전에서 신 버전으로 데이터베이스를 이동하고 백업 스크립트를 즉시 업데이트하지 않는다고 가정할 때

상황에 따라 어떤 백업과 복구 방법을 사용할지를 잘 판단해야 한다.

이 문서에서는 사용자백업 및 복구에 관련된 다음 사항들을 실습한다.

백업

닫힌 백업

열린 백업

DBVERIFY를 이용한 백업 확인

복구

완전 복구

불완전 복구

백업 및 복구 내용

데이터 파일

컨트롤 파일

리두 로그 파일

초기화 파라미터 파일

패스워드 파일

사용자백업 및 복구로 물리적인 파일과 테이블, 테이블스페이스, 뷰 등 논리적인 오브젝트들을 백업 및 복구할 수 있는데 논리적인 오브젝트의 백업 및 복구 실습은 Import/Export 툴을 실습에서 보충할 것이다.

1.2. DB모드 변경

1.2.1. 아카이브모드로 변경하기위해 초기화파라미터 init<<SID>>.ora 파일을 다음과 같이 수정하거나 추가한다.

log_archive_start = true

log_archive_max_processes = 5

log_archive_dest_1 = "location=저장위치"

log_archive_format = arch_%%ORACLE_<SID>%%_%t_%s.arc

※병렬(Parallel)DDL이나 DML의 경우 많은 양의 리두로그를 발생시키는데 하나의 아카이브 프로세스로 이 모든 리두로그 파일들을 아카이브시키기에는 역부족일 것이다. 만약 인스턴스를 시작한 후 필요에 따라

alter system set 문을 이용해서 아카이브 프로세스를 추가한다면 런타임 오버헤드가 발생한다. 그래서 인스턴스 시작과 동시에 적당한 수의 아카이브 프로세스를 시작시켜야 한다. 최대 아카이브 프로세스의 수는 10개이다.

1.2.2. sysdba로 접속해서 현재 데이터베이스의 아카이브 모드를 확인하고 만약 아니라면 아카이브 모드로 변경한다.

SQL>conn sys/*** as sysdba

SQL>shutdown immediate

SQL>startup mount pfile='PFILE의 위치를 기술'

SQL>archive log list

-- No Archive Mode 인지 확인

SQL>alter database archivelog;

SQL>archive log list

-- Archive Mode 인지 확인

SQL>alter database open;

SQL>show parameter log_archive

1.3. Closed Whole Backup

닫힌 전체 백업은 데이터베이스가 오픈되지 않은 상태에서 데이터베이스 전체를 백업하는 방법으로 데이터파일, 컨트롤파일, 리두로그파일을 백업하고 초기화 파라미터 파일이나 패스워드파일도 가급적이면 백업하는 것이 좋다.

또한 닫힌 전체 백업은 아카이브모드나 노아카이브모드에서 모두 가능하다.

SQL>shutdown immediate

SQL>host

C:\>mkdir c:\oracle\oradata\<SID>\backup

C:\>copy c:\oracle\oradata\<SID>\*.* c:\oracle\oradata\<SID>\backup

C:\>cd c:\oracle\oradata\<SID>\backup

C:\>dir

C:\>exit

SQL>

1.4. DBVERIFY를 이용한 백업 확인

DBVERIFY유틸리티는 데이터파일의 검증을 데이터베이스 관리자가 할 수 있도록 하는 명령어라인 유틸리티로서 다음의 두 가지 경우에 주로 사용한다.(8i에서는 DBVERIF80)

● 복원(Restore)하기 전에 백업 데이터베이스나 데이터 파일이 사용가능한지 확인

● 데이터 자체에 문제가 발생했을 때 유용한 문데 진단을 위해 사용

DBVERIFY는 데이터파일 진단만을 위해 사용되어지므로 컨트롤파일, 리두로그파일에는 사용할 수 없다.

C:\>dbv file='c:\c:\oracle\oradata\<SID>\backup\test.dbf' logfile=test.log feedback=50

※ file : 체크할 데이터파일logfile : 체크한 결과를 저장할 로그파일feedback : 명시된 값만큼 블록을 체크하고 마침표로 표시한다.start, end : 체크할 시작 블록과 끝 블록

로그파일을 이용하여 DBVERIFY 결과 확인

C:\>type c:\c:\oracle\oradata\<SID>\backup\test.log

※ Pages : 블록 수Total Pages Examined : 파일의 블록 수Total Pages Processed : 확인된 블록 수Total Pages Failing(Data) : 데이터 블록체크가 실패된 블록의 수Total Pages Failing(Index) : 인덱스 블록체크가 실패된 블록의 수Total Pages Marked Corrupt : 캐시 헤더가 유효하지 않은 블록의 수Total Pages Influx : 같은 시간에 읽혀지고 쓰여진 블록의 수

2. 사용자 Open백업 및 완전복구

2.1. Open백업 개요

24시간 데이터베이스를 오픈해야하는 비즈니스 정책에서 필요한 백업 방법이다

사용자백업 및 복구에서 오픈백업은

● 아카이브모드로 설정되어야 한다.

● 아카이브 프로세스에 의해서 자동이나 수동으로 온라인 리두로그가 아카이브 되어야 한다.

그리고 백업(ocopy)을 수행하는 SQL문은 백업모드로 설정하는 아래 SQL 문 사이에서 이루어진다.

ALTER TABLESPACE tablespace_name BEGIN BACKUP;

ALTER TABLESPACE tablespace_name END BACKUP;

사용자백업 및 복구에서 오픈백업은 다음 4가지 파일들이 백업(ocopy)되어야 한다.

● 데이터파일

● 컨트롤파일

● 패스워드파일

● 파라미터파일

2.2. 사용자 오픈백업

2.2.1. 각각의 백업할 온라인 테이블스페이스를 구성하는 데이터 파일을 확인한다.SQL>desc dba_data_filesSQL>select tablespace_name, file_name 2>from dba_data_file;

2.2.2. 위 결과를 통해 System, Undo 테이블스페이스를 구성하는 두 개의 파일을 확인하고 이 두 개의 파일을 사용자백업에서 오픈백업해 보자.SQL>alter tablespace system begin backup;SQL>hostC:\>ocopy c:\oracle\oradata\<SID>\system01.dbf c:\oracle\oradata\<SID>\backup\system01_backup.dbfC:\>exitSQL>alter tablespace system end backup;SQL>alter system archive log current;SQL>alter tablespace undo begin backup;SQL>hostC:\>ocopy c:\oracle\oradata\<SID>\undo01.dbf c:\oracle\oradata\<SID>\backup\undo01_backup.dbfC:\>exitSQL>alter tablespace system end backup;SQL>alter system archive log current;사용자백업에서 오픈백업을 할 때는 반드시 백업모드로 전환 후에 실시해야 한다.백업이 종료되면 아카이브되지 않은 리두로그를 아카이브하기 위해 alter system archive log current 문을 실행해야 한다.

2.2.3. 이어지는 실습을 위해 imsi 사용자를 만들고 imsi가 기본 테이블스페이스로 사용할 imsiTsp 테이블스페이스를 create한다.SQL>create tablespace imsiTsp 2>datafile 'c:\oracle\oradata\<SID>\imsiTsp.dbf' size 10M 3>extent management local uniform size 20k;SQL>alter database 2>datafile 'c:\oracle\oradata\<SID>\imsiTsp.dbf' 3>autoextent on next 1M maxsize unlimited;SQL>create user imsi 2>identified by password 3>default tablespace imsiTsp;SQL>grant connect, resource to imsi;

2.2.4. 생성된 imsiTsp 테이블스페이스를 dba_data_files 뷰에서 확인한다.SQL>select tablespace_name, file_name 2>from dba_data_files;

2.2.5. 새로 추가된 imsiTsp 테이블스페이스를 구성하는 데이터파일을 온라인 백업하고 아카이브되지 않은 리두로그를 아카이브한다.SQL>alter tablespace imsiTsp begin backup;SQL>hostC:\>copy c:\oracle\oradata\<SID>\imsiTsp.dbf d:\Backup\<SID>C:\>exitSQL>alter tablespace imsiTsp end backup;SQL>alter system archive log current;

2.2.6. 컨트롤파일 백업을 위해 텍스트 Trace 형태의 파일을 생성한다.alter database backup controlfile to trace;

2.2.7. 생성된 텍스트 Trace 형태의 컨트롤 파일의 위치를 확인한다. 기본 위치는 USER_DUMP_DEST에 파일이 생성된다SQL>hostC:\>dir c:\oracle\admin\<SID>\udump

2.2.8. 생성된 텍스트 Trace 형태의 컨트롤 파일의 내용을 확인한다.C:\>type c:\oracle\admin\<SID>\udump\<SID>_ora_XXXX.trc | moreC:\>exit

2.2.9. 생성된 텍스트 형태의 컨트롤파일을 다른 디렉토리로 백업한다.C:\>copy c:\oracle\admin\<SID>\udump\<SID>_ora_XXXX.trc d:\Backup\<SID>

2.2.10. 바이너리 이미지 형태의 컨트롤파일을 다른 위치로 백업한다.C:\>exitSQL>alter database backup controlfile to 'd:\Backup\<SID>\control.bkp';

2.2.11. 파라미터파일을 spfile 형태로 다른 위치로 백업한다.SQL>create spfile='d:\Backup\<SID>\spdile' from pfile;

2.2.12. 패스워드 파일을 다른 위치로 백업한다.SQL>hostC:\>copy C:\oracle\ora92\database\PW<SID>.ora d:\Backup\<SID>C:\>exit

지금까지 사용자백업 및 복구 환경에서 다음과 같은 파일들에 대해서 오픈백업을 실습하였다.

● 테이블스페이스를 구성하는 데이터 파일 백업

● 컨트롤파일(바이너리형태, 텍스트 Trace 형태) 백업

● 파라미터파일 백업

● 패스워드파일 백업

2.3. 사용자 완전복구

임의의 파일 삭제로 복구가 필요한 상황이 발생했다는 가정에서 백업 파일을 복원(Restore)하고 복구(Recover)할 것이다. 특히 온라인 리두로그와 아카이브 리두로그가 존재하기 때문에 복구의 형태는 완전복구(Complete Recovery)가 될 것이다.

2.3.1. 원활한 실습을 위하여 다음과 같이 하나의 테이블을 생성하고 데이터를 인서트하는 스크립트를 준비한다.CREATE TABLE sam(sam_id number(11) primary key,cate varchar(20) not null);INSERT INTO samVALUES (55, 'book');

2.3.2. imsi 사용자로 접속해서 위 스크립트를 실행한다.SQL>comm imsi/passwordSQL>CREATE TABLE sam( sam_id number(11) primary key, cate varchar(20) not null);SQL>INSERT INTO sam VALUES (55, 'book');위 생성되는 테이블과 데이터는 imsi 사용자의 기본 테이블스페이스 imsiTsp에 저장된다는 것을 기억하자.

2.3.3. 생성된 sam 테이블의 구조를 확인한다.SQL>desc sam

2.3.4. 생성된 sam 테이블에 저장된 데이터의 수를 확인한다.SQL>select count(*) from sam;

2.3.5. sys 사용자로 접속한 후 sam 테이블세그먼트가 있는 테이블스페이스와 파일이름을 확인한다.SQL>conn sys/sys as sysdbaSQL>select tablespace_name from dba_segments 2>where segment_name='sam';SQL>select file_name from dba_data_files 2>where tablespace_name='imsiTsp';

2.3.6. imsiTsp 테이블스페이스를 구성하는 데이터 파일을 오픈백업한 후 아카이브 되지 않은 리두로그를 아카이브한다.SQL>alter tablespace imsiTsp begin backup;SQL>hostC:\>ocopy c:\oracle\oradata\<SID>\imsiTsp.dbf b:\backup\<SID>C:\>exitSQL>alter tablespace imsiTsp end backup;SQL>alter system archive log current;

2.3.7. sam 테이블의 데이터가 들어있는 파일을 삭제 후 데이터베이스를 Shutdown 시키고 Restart 한다.!rm imsiTsp.dbfSQL>shutdown abortSQL>startup-- 마운트하고 오픈하는 단계에서 에러 발생 다시 shutdown해야 한다.SQL>shutdown abort

2.3.8. 데이터베이스를 마운트 단계로 오픈하고 에러가 발생한 파일을 확인한다.SQL>startup mountSQL>select d.file#, d.ts, h.tablespace_name, d.name, h.error 2>from v$datafile d, v$datafile_header h 3>where d.file# = h.file#;위 쿼리를 통해 imsiTsp 테이블스페이스에 imsiTsp.dbf 파일을 찾을 수 없다는 에러를 확인할 수 있다.

2.3.9. 삭제된 파일을 오프라인시킨 후 데이터베이스를 오픈한다.SQL>alter database datafile 'c:\......\imsiTsp.dbf' offline;SQL>alter database open;데이터베이스가 오픈 상태가 아니기 때문에 alter tablespace imsiTsp offline 문장은 사용할 수 없다.

2.3.10. imsiTsp.dbf 파일이 저장된 디스크가 손상되었다는 가정하에 다른 위치로 옮겨 복원(resrore)한다.SQL>!cp '......\imsiTsp.dbf' '......\imsiTsp.dbf'

2.3.11. 오라클 서버에 새로 옮긴 파일 위치를 등록한다.SQL>alter database rename file '......\imsiTsp.dbf' to '......\imsiTsp.dbf';

2.3.12. dba_data_files 쿼리를 통해서 imsiTsp 테이블스페이스 상태를 확인한다.SQL>select file_id f#, file_name, tablespace_name tablespace, status 2>from dba_data_files;새로 옮긴 imsiTsp 테이블스페이스가 사용가능(Available)한 파일인지 확인한다.

2.3.13. 복원한 데이터 파일에 아카이브 리두로그파일과 온라인 리두로그파일을 적용한다.SQL>recover tablespace imsiTsp;recover datafile '...\imsiTsp.dbf' 문장을 이용해도 된다.

2.3.14. 복구가 완료된 후 imsiTsp 테이블스페이스를 온라인 상태로 복귀시킨다.SQL>alter tablespace imsiTsp online;alter datafile '...\imsiTsp.dbf' 문장을 이용해도 된다.

2.3.15. 복구가 잘 되었는지 확인한다.SQL>select count(*) from imsi.sam;결과 건수가 복구 이전과 같은지 확인한다.

여기까지 사용자관리 오픈백업(open backup)과 완전복구(complete recovery)에 대한 실습을 마친다.

3. 사용자 Closed백업 및 불완전복구

3.1. 불완전복구 개요

Closed백업은 앞에서 살펴본바와 같이 데이터베이스를 shutdown한 상태에서 데이터를 백업하는 방법이다.

● 불완전복구는 다음과 같은 상황일 때 수행해야 하는 복구(recovery)방법이다.

╺ 아카이브로그 손실로 인해 완전 복구가 실패한 경우

╺ 아카이브되지 않은 리두로그파일과 데이터파일을 손실했을 때

╺ 사용자 에러로 인해 중요한 테이블 삭제나 잘못된 데이터를 업데이트라고 커밋이 발생한 경우(완전복구가 가능하더라도 완전복구 자체가 원하는 작업이 아니기 때문에 불완전 복구로 원하는 시점까지 복구를 한다.)

╺ 백업 컨트롤 파일을 이용한 복구

● 사용자가 불완전 복구를 할 때에 다음 3가지 방법으로 복구 할 수 있는데 상황에 따라 효과적인 방법을 선택하게 된다.

╺ Time-based recovery

╺ Cancel-based recovery

╺ Change-based recovery

백업 컨트롤을 아용해서 위 3가지 방법의 불완전복구를 수행할 수도 있다.

● 불완전복구의 가장 기본적인 절차는 다음과 같다.

╺ 초기 데이터베이스를 shutdown한 후 Closed Whole 백업을 수행한다.

╺ 문제 발생시 모든 데이터 파일등을 복원한다 : 컨트롤 파일 아카이브 리두로그파일, 패스워드파일, 초기화 파라미터 파일은 복원하지 않는다.

╺ 데이터베이스를 마운트 상태로 만든다.

╺ 실패 이전 시간 아카이브 리두로그와 온라인 리두로그 적용까지 데이터 파일을 복구한다.

╺ 데이터베이스를 resetlogs로 오픈한다.(연속되는 리두로그가 없기 때문에 처음부터 리두로그를 리셋시킨다.)

╺ 복구가 잘 되었는지 확인한다.

╺ 복구된 데이터베이스에 대해서 닫힌 전체 백업을 실시한다.

상황에 따라 기본적인 절차는 약간씩 달라진다.

3.2. 아카이브로그 손실로 인해 완전복구가 실패한 경우

다음과 같은 상황을 가정해서 실습한다.

● 현재 사용 중인 imsi 데이터베이스에 데이터 파일 하나가 손실되었다.

● 완전복구를 위해 해당 손실된 데이터의 백업을 복원한다.

● 완전복구를 시도하지만 아카이브 리두로그가 손실되어 복구가 실패한다.

● 불완전 복구를 시도한다.

3.2.1. 아카이브 로그를 발생시키기 위해 로그 스위치를 3회 실시한다.SQL>alter system switch logfile;SQL>alter system switch logfile;SQL>alter system switch logfile;로그 스위치는 로그 파일이 모두 채워졌을 때 발생한다 하지만 강제로 세 번 발생시키는 것이다. 즉 로그 스위치가 발생하면 체크포인트가 발생되고 리두로그파일의 내용은 아카이브되어 아카이브 리두로그파일이 생기게 된다. 로그 스위치를 세 번 발생시켰으므로 아카이브 리두로그파일이 세 개 생겼다.

3.2.2. 아카이브 로그 파일이 저장되어 있는 위치를 확인한다.SQL>show parameter log_archive_dest

3.2.3. 아카이브된 파일이 저장된 디렉토리 안에서 마지막에서 두 번째 아카이브 로그를 삭제해 본다.

3.2.4. sam 테이블의 데이터를 포함하고 있는 imsiTsp 테이블 스페이스의 데이터 파일을 삭제해 본다.SQL>select tablespace_name, file_name 2>from dba_data_files;SQL>!rm ....\imsiTsp.dbf

3.2.5. 데이터베이스를 shutdown 시킨 후 다시 데이터베이스를 시작한다.SQL>shutdown abortSQL>startup-- 에러 발생SQL>shutdown abort지금까지는 에러를 발생시키도록 상황을 만드는 과정이었고 이제부터 이 에러를 해결하는 실습이 이어진다.

3.2.6. 복구 후에 데이터 손실을 최소화하기 위해 완전 복구를 시도한다.1) 데이터베이스를 아뭉트 상태로 만든 후 삭제된 파일을 원래 위치로 복원한다.SQL>startup mountSQL>!cp SQL>recover database위에서 완전복구를 시도하는데 에러가 발생된다. 이는 앞에서

아카이브 리두로그 파일을 지웠기 때문이다. 순차적으로 적용해야할 아카이브 리두로그 파일 중 하나가 사라졌으므로 완적복구는 되지 않고 불완전복구라도 시도되어서 데이터 손실을 최소화해야 한다.

3.2.7. 불완전 복구를 시도한다.1) 데이터베이스를 shutdown하기 전에 복원해야할 데이터 파일을 확인한다.SQL>select tablespace_name, file_name 2>from dba_data_files; 이 쿼리 결과로 보여지는 데이터 파일들의 백업파일을 원 위치로 복원해야 한다.2) 데이터베이스를

shutdown한 후 확인된 모든 데이터 파일을 복원한다.SQL>shutdown immediateSQL>!cp ...... 데이터파일들만 복원한다는 점에 유의한다.3) Cancel-based 불완전 복구를 수행해서 삭제된 아카이브 로그 이전까지 적용된 데이터베이스를 복구한다.SQL>startup mount

SQL>recover database until cancel; 원하는 아카이브 로그파일이 적용될 때까지 엔터를 누르고 중디하고자하는 로그파일 부분에서 cancel을 입력한다.4) 복구된 데이터베이스를 resetlogs 옵션과 함께 오픈한다.SQL>alter database open resetlogs;

5) 데이터베이스 오픈 후 닫힌 전체 백업을 꼭 실시해야 나중을 기약할 수 있다.SQL>shutdown immediateSQL>!cp 모든 파일SQL>startup

3.3. 아카이브 되지 않은 온라인 리두로그 파일과 데이터파일 손실

아래의 경우와 같은 상황을 가정하고 실습한다.

● 현재 사용 중인 데이터베이스에 데이터 파일 하나가 손실되었다.

● 완전 복구를 위해 해당 손실된 데이터의 백업을 restore한다.

● 완전복구를 시도하지만 아카이브 되지 않은 현재 사용 중인 로그 그룹이 손실되어 복구가 실패된다.

● 불완전복구를 시도한다.

3.3.1. v$log 뷰에서 아카이브 되지 않은 현재 사용 중인 로그 그룹을 확인한다.SQL>select group#, thread#, sequence#, member, archived, status, first_time 2>from v$log;ARC 필드가 NO로 표시되는 로그 그룹 번호를 확인

3.3.2. v$logfiles를 이용해서 온라인 리두그룹, 멤버의 위치를 알아본다.select * from v$logfile;

3.3.3. 실습 상황을 만들기 위해 아카이브 되지 않은 리두로그파일을 삭제한다.SQL>!rm로그 그룹 번호를 참조

3.3.4. sam 테이블의 데이터를 포함하는 imsiTsp 테이블스페이스의 데이터파일을 삭제한다.SQL>!rm

3.3.5. 데이터베이스를 shutdown시키고 다시 restart 한다.SQL>shutdown abortSQL>start

3.3.6. 복구 후 손실을 최소화하기 위해서 완전복구를 시도한다.데이터베이스를 마운트 상태로 만든 후 삭제된 파일을 원래 위치로 복원한다.SQL>startup mountSQL>!cp .....SQL>recover database

3.3.7. 불완전복구를 시도한다.1)데이터베이스를 shutdown한 후 확인된 데이터파일을 복원한다.SQL>shutdown immediateSQL>!cp ......2)Cancel-based 불완전복구를 수행해서 삭제된 로그 이전까지 적용된 데이터베이스를 복구한다.SQL>startup mountSQL>recover database until cancel;3)복구된 데이터베이스를 resetlogs 옵션과 함께 오픈한다.SQL>alter database open resetlogs;4)OS명령으로 삭제했던 로그그룹을 SQL명령으로 삭제해 본다.SQL>alter database drop logfile group 3;현재 사용중인 로그 그룹이라면 지울 수 없다는 에러 메시지를 반환할 것이다. 따라서 로그 스위치를 사용해서 비활성화 상태로 바꾸고 삭제해야만 한다.5)로그스위치를 두 번 정도 실행하고 로그그룹을 비활성화한다.SQL>alter system switch logfile;SQL>alter system switch logfile;6)비활성화된 로그그룹을 v$log 뷰로 확인한다.SQL>select * from v$log;7)비활성화된 로그그룹을 삭제한다.SQL>alter database drop logfile group 3;8)로그그룹2를 대체할 수 있는 새로운 로그그룹을 추가한다.SQL>alter database add logfile group 4 2>('....\redo41.log', 3>'....\redo42.log') size 2M;9)새로 생성된 로그그룹이 잘 추가되었는지 확인한다.SQL>select * from v$logfile;10)데이터베이스 오픈 후 백업 디렉토리에 닫힌 전체 백업을 실시한다. 불완전복구 후에는 반드시 닫힌 전체 백업을 실시해야 한다.

3.4. 사용자 에러 복구

사용자 에러에 인해 발생한 문제를 위해 데이터베이스 복구가 필요할 때 사용하는 복구 방법이다. 완전복구하는 것은 의미가 없다. 완전복구 자체가 에러를 포함하고 있기 때문에 불완전복구를 선택할 수 밖에 없다. 특정 시간으로 되돌리는 Time-based 복구를 많이 사용할 것이다.

이번 실습 내용은 다음과 같은 상황을 가정하고 실습한다.

● 사용자 스키마에 있는 테이블을 실수로 삭제한 경우이다.

● 테이블이 삭제된 대략의 시간을 확인한다.

● 테이블을 삭제한 시간대는 데이터베이스 활동이 최소인 상태이다

● 테이블은 반드시 복구되어야하는 중요한 테이블이다.

● cancel-base 복구는 적용하기가 어려운 실정이다.

3.4.1. 사용자가 실수로 테이블을 제거하는 상황을 만들어 본다.SQL>conn imsi/passwordSQL>drop table sam;

3.4.2. 사용자로부터 테이블 복구 요청을 받은 DBA는 우선 sys 사용자로 접속해서 테이블을 쿼리해 본다SQL>conn sys/sys as sysdba;SQL>select * from imsi.sam;

3.4.3. 스키마에서 테이블이 지워진것을 확인하고 복구를 위해 모든 데이터파일을 복구한다. 데이터베이스를 shutdown하고 확인된 데이터파일 모두를 복원한다.SQL>shutdown immediateSQL>!cp

3.4.4. 데이터베이스를 마운트 상태로 바꾸고 time-based 복구를 수행한다.SQL>startup mountSQL>recover database until time '0000-00-00:00:00:00';

3.4.5. 복구된 데이터베이스를 resetlogs 옵션과 함께 오픈한다.SQL>alter database open resetlogs;

3.4.6. archive log list 문으로 현재 로그 시퀀스를 확인한다.SQL>archive log list

3.4.7. 테이블이 잘 복구되었는지 확인한다.SQL>select count(*) from imsi.sam;

3.4.8. 테이블이 완벽히 복구된 것을 확인하고 닫힌 전체 백업을 실시한다.

3.5. 백업 컨트롤파일을 이용한 복구

이번에는 백업 컨트롤 파일을 이용해서 time-based, cancel-based, change-based 복구 타입을 적용하는 실습을 해본다. 다음의 상황을 가정해서 실습한다.

● 사용자 실수로 테이블스페이스와 그 안의 데이터 모두를 지웠다.

● 닫힌 전체 백업에서 작업한 컨트롤 파일 백업이 존재한다.

● 백업 컨트롤 파일을 이용해서 삭제된 테이블스페이스와 그 내용을 복구해야 한다.

3.5.1. 실습 상황을 만들기 위해서 sam 테이블을 포함하는 imsiTsp 테이블스페이스를 삭제한다.SQL>drop tablespace imsiTsp including contents;

3.5.2. 삭제된 테이블스페이스 복구를 위해 제한된 세션만 로그온할 수 있도록 다음과 같음 명령을 실행한다.SQL>alter system enable restricted session;이 명령어를 실행하기 전에 이미 로그온된 세션에 대해서는 로그아웃하라고 알린다. 이 명령이 실행한 후에는 로그아웃된 세션들은 kill 해야 한다.SQL>select <SID>, serial#, username 2>from v$session;SQL>alter system kill session '20, 9';

3.5.3. alert.log 파일로부터 복구를 위한 시간 정보를 얻는다. 즉 테이블스페이스가 삭제된 시간을 확인해 본다.SQL>!vi alert.logBACKGROUND_DUMP_DEST에 위치한 alert.log 파일은 발생된 모든 에러의 정보가 담긴 파일이다. 에러의 원인과 해결책을 위해서 유용한 파일이다.

3.5.4. 데이터베이스를 shutdown하고 백업 컨트롤 파일을 복원한다.SQL>shutdown immediateSQL>!cp

3.5.5. 모든 데이터 파일을 복원한다.SQL>!cp

3.5.6. 데이터베이스 오픈을 시도해 본다.SQL>startup온라인 리두로그가 복원된 컨트롤 파일, 데이터 파일들과 동기화되지 않았기 때문에 에러가 발생한다.

3.5.7. v$recover_file 뷰를 이용해서 복원된 데이터 파일 중에서 오프라인 되어 있는 파일을 확인해 본다.SQL>select * from v$recover_file;복구 전에 복원한 파일들 중에 오프라인 파일이 있는지 찾아보는 이유는 복구가 완료되고나면 오프라인 파일을 복구할 수 없을 수도 있기 때문이다. 오프라인 파일이 없는 상태에서 복구가 이루어져야 한다. 오프라인 파일이 있다면 alter database datafile <n> online;

3.5.8. 백업 컨트롤 파일을 이용해서 테이블 삭제가 일어난 시간까지 복구를 해본다.SQL>recover database using backup controlfile until time '2006-00-00:00:00:00';

3.5.9. resetlogs 옵션과 함께 데이터베이스를 시작한다.SQL>alter database open resetlogs;

3.5.10. 테이블스페이스와 테이블이 복구되었는지 확인한다.