본문 바로가기

Oracle

User managed Restore 1

1 시간기반 불완전 복구


1-1 시나리오작성


SQL> host date → 현재 날짜를 메모해 두십시오.

SQL> host time → 현재 시간을 메모해 두십시오,

SQL> drop table scott.dept cascade constraints;

--> 개발자가 실수로 DEPT 테이블을 삭제하였다고 합니다.


SQL> select * from scott.dept; select * from scott.dept

*

ERROR at line 1: ORA-00942: table or view does not exist


SQL> shutdown immediate

SQL> exit


[C:\] cd c:\backup

[C:\] copy *.dbf c:\oracle\oradata\ora92

→ 반드시, 모든 데이터 파일들 만 재 설치하십시오.


1-2 복구


[C:\] sqlplus "/as sysdba"

SQL> startup mount


SQL> recover database until time '2001-01-23:16:44:47';

ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed

ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_219.arc

ORA-00280: Change 7220 for thread 1 is in sequence #219

Specify log: {=suggested | filename | AUTO | CANCEL}


Auto ← 관련된 모든 아카이브 파일들을 자동으로 적용해 줍니다.


Media Complete Recovery

→ 마지막, 오프라인 백업파일을 재 설치하고 그 이후에 생성된 아카이브 파일들을 순차적으로 적용하면서 실수로 테이블을 DROP한 이전 시점까지 만 복구한다면 삭제된 테이블을 복구할 수 있을 것 입니다.


(2) 단계에서 메모해 둔 날자와 시간정보를 'YYYY-MM-DD HH:MM:SI'포맷으로 정의하시면 됩니다. 반드시, 날자 포맷을 임의로 변경해서는 안됩니다.


SQL> alter database open resetlogs;

→ 불완전 복구가 수행되었으면 데이터베이스를 RESETLOG 옵션을 사용하여 OPEN 하십시오. 불완전 복구에 의한 복구작업 시에는 반드시 이 옵션을 사용하셔야 합니다. 현재, 데이터베이스는 과거 DEPT 테이블이 삭제되기 이전 상태로 복구된 상태 입니다. 그런데, 컨트롤 파일과 리두로그 파일은 복구작업을 수행하기 이전의 현 상태 에 대한 정보를 가지고 있기 때문에 시점이 일치하지 않는 문제점이 발생하게 됩니다. 결국, 이 상태에서는 데이터베이스를 정상적으로 OPEN 할 수 없기 때문에 RESETLOG 옵션을 사용하여 모든 상태정보를 초기화할 수 밖에 없게 됩니다.


SQL> archive log list

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

가장 오래된 온라인 로그순서 1 ← 상태정보가 초기화된 것을 확인하십시오.

아카이브할 다음 로그 1

현재 로그순서 1


SQL> select * from scott.dept;

→ 삭제되었던 DEPT 테이블이 다시 검색됩니다. 현재, 데이터베이스는 DEPT 테이블이 삭제되기 이전 상태로 복구되어 있기 때문에 DEPT 테이블을 검색할 수 있는 것 입니다.

SQL> shutdown immediate

SQL> exit


2 취소기반 불완전 복구


2-1 시나리오작성


SQL> select member from v$log where status = 'CURRENT';

MEMBER

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

c:\oracle\oradata\ora92\redo01.log


→ 만약, 현재 데이터베이스에서 REDO01.LOG 파일이 CURRENT 상태의 리두로그 파일이 라면 다음과 같이 화면에 출력됩니다.


SQL> host dir c:\oracle\oradata\ora92

SQL> host del c:\oracle\oradata\ora92\redo01.log

→ Windows 환경의 운영체계에서는 서버에 의해 삭제가 안됩니다.


SQL> host del c:\oracle\oradata\ora92\redo01b.log

→ Windows 환경의 운영체계에서는 서버에 의해 삭제가 안됩니다.


SQL> host dir c:\oracle\oradata\ora92

SQL> @moredept.sql

→ 온라인 리두로그 파일이 유실되었기 때문에 에러가 발생합니다. 또는, 무한정 대기상태에 빠지게 되기도 합니다.


SQL> shutdown abort

→ 에러가 발생하는 경우에는 오라클 서버가 자동 종료됩니다. 경우에 따라서는 무한정 대기상태에 빠지기도 하는데 이런 경우에는, 정상적인 복구작업을 수행하기 위해서 강제로 오라클 서버를 종료 시켜야 합니다. 바로 이때, SHUTDOWN 명령어의 ABORT 옵션을 이용하시면 오라클 서버를 강제 종료 시킬 수 있습니다.


2-2 복구


(3) 자~ 그럼, CURRENT 리두로그 파일이 유실된 경우 불완전 복구를 수행해 봅시다.
오라클 서버가 자동 종료되었거나, ABORT 옵션에 의해 강제 종료된 다음 다시 오라클 서버를 MOUNT 단계까지 만 시작한 다음 불완전 복구를 수행하기 위해 마지막 오프라인 백업 파일들 중에 모든 데이터 파일들 만 재 설치합니다.


SQL> startup

SQL> alter database drop logfile group 그룹번호;

→ 일반적으로 INACTIVE 리두로그 파일이 유실된 경우에는 관련 리두로그 파일을 제거한 후 다시 재 생성함으로써 복구작업을 완료할 수 있었습니다. 같은 방법으로 복구가 가능한지 수행해 보십시오. 하지만, CURRENT 리두로그 파일은 ALTER DATABASE DROP LOGFILE~ 명령어로는 더 이상 삭제할 수 없습니다. 왜냐하면, CURRENT 상태의 리두로그는 현재 쓰여지고 있는 파일을 의미하기 때문에 데이터베이스 관리자도 삭제할 수 없기 때문 입니다.


SQL> shutdown immediate

SQL> exit


(4) 다음은 정상적인 불완전 복구를 수행하는 방법과 절차입니다.
먼저, 현재 생성되어 있는 마지막 아카이브 파일이 몇 번인지 확인해 두십시오. 다음과 같이 여러 가지 방법을 통해 확인할 수 있습니다.


첫 번째 방법은 ALERT 파일의 로그 내용을 분석해 보면 마지막 아카이브 파일의 번호를 알아 낼 수 있습니다.

[C:\] cd c:\oracle\admin\ora92\bdump

[C:\] dir


[C:\] edit ALERT_.log

→ 파일의 끝부분으로 이동해서 Archiving을 실패한 기록과 Sequence 번호 확인 예를 들어, ORA-00255: error archiving log 1 of thread 1, sequence # 15 sequence # 15번이라면 마지막 아카이브 파일번호가 15번 입니다.


두 번째 방법은 아카이브 파일이 생성되어 있는 경로로 이동하여 마지막 파일 번호를 확인하는 방법입니다.


[C:\] DEL C:\ORACLE\ORA92\DATABASE\ARCH

[C:\] dir


(5) 이전에 마지막으로 오프라인 백업된 파일들 중에 모든 데이터 파일들만 재설치하십시오. 컨트롤 파일과 리두로그 파일들은 재 설치할 필요가 없습니다. 모든 파일들을 재 설치하게 되면 완전복구 방법이 되며, 데이터 파일들 만 설치하면 불완전 복구가 됩니다.


[C:\] cd c:\backup

[C:\] copy *.dbf c:\oracle\oradata\ora92


[C:\] sqlplus "/as sysdba"

SQL> startup mount

SQL> recover database until cancel

ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed

ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_1.arc

ORA-00280: Change 7220 for thread 1 is in sequence #1


Specify log: {=suggested | filename | AUTO | CANCEL}


Enter ← 1번 아카이브 파일을 적용해 줍니다.


ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed

ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_2.arc

ORA-00280: Change 7220 for thread 1 is in sequence #2

Specify log: {=suggested | filename | AUTO | CANCEL}


Enter ← 2번 아카이브 파일을 적용해 줍니다.


…………………………..

ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed

ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_15.arc

ORA-00280: Change 7220 for thread 1 is in sequence #15

Specify log: {=suggested | filename | AUTO | CANCEL}


Enter ← 15번 아카이브 파일을 적용해 줍니다.


ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed

ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_16.arc

ORA-00280: Change 7220 for thread 1 is in sequence #16

Specify log: {=suggested | filename | AUTO | CANCEL}


CANCEL ← 아카이브 파일을 적용하기 전에 현재 시점까지 생성되어 있는 마지막 아카이브 파일이 15번까지 생성되어 있는 것을 확인하였습니다. 그렇다면, 16번 아카이브 파일은 존재하지 않으므로 더 이상 복구작업을 수행할 수 없습니다. CANCEL을 입력하면 복구작업은 중단됩니다.


Media Complete Cancel. ← 불완전 복구작업이 완료되었습니다.


SQL> alter database open resetlogs;

→ 불완전 복구는 데이터베이스의 모든 상태가 불 일치하기 때문에 복구작업을 완료한 후 반드시 RESETLOGS 옵션을 사용하여 OPEN 해야 합니다. 이 명령어를 실행하면 유실된 모든 리두로그 파일들이 자동으로 생성됩니다.


SQL> archive log list

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

가장 오래된 온라인 로그순서 1 ← 모든 상태정보가 초기화 된 것을 확인하십시오.

아카이브할 다음 로그 1

현재 로그순서 1


SQL> shutdown immediate

SQL> exit