[오라클]백업 복구 가이드 - OFF-Line 백업을 이용한 불완전 백업

완전복구(Complete Recovery) 방법은 데이터베이스에 장애가 발생한 경우 그 시점까지의 모든 백업 데이터를 아카이브 파일과 리두로그 파일에 저장해 둔 후 복구 작업 시 사용하는 방법입니다. 실제 기업환경에서 데이터베이스를 운영하다 보면 예기치 못한 원인으로 인해 장애가 발생하는 경우 거의 대부분의 경우는 문제가 발생한 시점까지 모든 데이터를 복구하는 것이 원칙일 것 입니다. 하지만, 특별한 경우에는 문제가 생긴 시점이 아닌 그 이전 시점의 어느 순간까지 만 복구해야 하는 경우도 때로는 발생하게 됩니다. 이런 경우, 완전복구 방법으로는 과거 어느 시점까지의 복구는 할 수 없기 때문에, 반드시 불완전 복구방법을 사용해야 합니다.

 

5장 OFF-Line 백업을 이용한 불완전 복구
	5-1 불완전 복구
	완전복구(Complete Recovery) 방법은 데이터베이스에 장애가 발생한 경우 그 시점까지의 모든 백업 데이터를 아카이브 파일과 리두로그 파일에 저장해 둔 후 복구 작업 시 사용하는 방법입니다. 실제 기업환경에서 데이터베이스를 운영하다 보면 예기치 못한 원인으로 인해 장애가 발생하는 경우 거의 대부분의 경우는 문제가 발생한 시점까지 모든 데이터를 복구하는 것이 원칙일 것 입니다.  하지만, 특별한 경우에는 문제가 생긴 시점이 아닌 그 이전 시점의 어느 순간까지 만 복구해야 하는 경우도 때로는 발생하게 됩니다. 이런 경우, 완전복구 방법으로는 과거 어느 시점까지의 복구는 할 수 없기 때문에, 반드시 불완전 복구방법을 사용해야 합니다. 오라클 사에서는 시간기반 불완전 복구(Time Based Incomplete Recovery), 취소기반 불완전 복구(Cancel Based Incomplete Recovery), 변경기반 불완전 복구(Change Based Incomplete Recovery) 방법을 제공하고 있습니다.
	5-1-1 시간기반 불완전 복구 자~ 그럼, 불완전 복구의 대표적 방법인 시간기반 복구에 대해서 먼저 알아보겠습니다. 데이터베이스를 운영하다 보면 대부분의 경우는 물리적 구조(시스템, 디스크 장치 등)의 장애로 인해 더 이상 데이터베이스를 사용할 수 없는 경우를 보게 됩니다. 하지만, 사용자가 DML문을 수행한 후 실수로 COMMIT문을 실행하게 되는 경우나 DROP 또는 ALTER 문장으로 원치 않게 데이터가 변경되는 경우가 발생하게 됩니다. 시간기반 불완전 복구방법은 주로 사용자의 실수로 인해 해당 테이블의 데이터가 변경되어 데이터베이스의 신뢰성이 깨지는 경우 데이터베이스를 변경 이전상태로 복구하기 위해 사용되는 복구방법 중에 하나 입니다. 위 그림에서, 현재 시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다.  ARC1.LOG, ARC2.LOG, ARC3.LOG 파일에 모든 백업 데이터들이 저장되었다고 합니다.  현재시점, 2001년 6월 11일 오후 12시 10분 11초에 사용자가 실수로 EMP 테이블을 삭제했다고 합니다. 이 사실을 모른체 사용자들은 다른 테이블에 대해 입력, 수정, 삭제작업을 계속 수행했다고 합니다. 현재시점, 2001년 6월 12일 13시 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 데이터베이스를 사용할 수 없다고 합니다.  데이터베이스 관리자는 완전복구 방법을 통해 장애가 발생한 USERS01.DBF 데이터 파일을 복구하려고 합니다. 하지만, 완전복구 작업을 수행하게 되면 EMP 테이블은 여전히 DROP된 상태로 복구되기 때문에 테이블을 복구할 수 없다고 합니다. EMP 테이블이 복구되기 위해서는 장애가 발생한 시점까지 복구해서는 안되며, EMP 테이블이 DROP 되기 이전 상태까지만 복구해야 합니다.
	사례-7.
	사용자가 실수로 테이블을 DROP 했다고 합니다. 완전복구 작업을 수행하게 되면 해당 테이블이 삭제된 상태로 복구되기 때문에 반드시 불완전 복구작업을 수행해야 합니다.
	(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> @moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept;
	(2) 데이터베이스를 사용하던 중 개발자가 실수로 DEPT 테이블을 삭제하였다고 합니다. 이 테이블은 전체 업무에서 사용되는 아주 중요한 데이터를 저장하고 있기 때문에 반드시 필요한 테이블이라고 합니다. 하지만, DROP 명령어는 AUTO-COMMIT을 자동 수행하기 때문에 삭제된 테이블은 더 이상 사용할 수 없게 됩니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>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
	(3) 지금까지 대부분의 시나리오는 운영체계 상에서 관련된 파일들을 더 이상 사용할 수 없게 되는 경우에 대한 물리적 복구 방법이었다면, 이번 시나리오는 데이터베이스 내에서 중요한 테이블이 삭제된 경우의 논리적 복구방법을 소개하게 될 것 입니다. 이전에 오프라인 백업된 파일들 중에 모든 데이터 파일들 만 해당 경로에 재설치 하십시오.  반드시, 데이터 파일들 만 재 설치하셔야 하며 컨트롤 파일과 리두로그 파일들은 정상적으로 사용 가능한 상태이므로 재 설치하실 필요는 없습니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> shutdown immediate SQL> exit [C:\] cd c:\backup [C:\] copy *.dbf c:\oracle\oradata\ora92 → 반드시, 모든 데이터 파일들 만 재 설치하십시오.
	(4) 자, 그럼, 삭제된 하나의 테이블을 복구하기 위해 시간기반 불완전 복구작업을 수행해 보도록 하겠습니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[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: {<ret>=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</ret>
	5) 불완전 복구가 완료되었으면 현재 시점의 오프라인 백업을 수행하십시오. 대부분의 개발자들이 불완전 복구를 수행한 후 오프라인 백업을 수행하지 않다가 여가지 문제로 인해 데이터베이스를 복구하지 못하는 경우가 종종 발생합니다. 현재 시점에서는 마지막 오프라인 백업된 파일들은 더 이상 복구작업에 사용될 수 없는 무의미한 파일들에 불과합니다. 이유는 불완전 복구를 수행하게 되면, 데이터베이스 내의 모든 상태 정보들이 초기화되기 때문에 이전의 오프라인 백업 파일들이 가지고 있는 상태정보와 일치될 수 없기 때문 입니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] cd c:\oracle\oradata\ora92 [C:\] copy *.* c:\backup [C:\] copy c:\oracle\ora92\database\init.ora c:\backup → 관련된 모든 데이터 파일, 컨트롤 파일, 리두로그 파일, 파라메터 파일들을 오프라인 백업 하십시오. [C:\] del c:\oracle\oradata\ora92\arch\*.arc → 불완전 복구에 의해 데이터베이스의 모든 상태 정보들이 초기화되면 이전까지 생성 되었던 아카이브 파일들도 이젠 더 이상 필요 없는 파일들이 됩니다. 아카이브 파일들은 사용 가능한 마지막 오프라인 백업파일 이후에 생성된 것 들만 사용 가능하므로 초기화된 현재 시점에서는 이전의 아카이브 파일은 사용될 수 없습니다.
	5-1-2 취소기반 불완전 복구 이번에는 불완전 복구의 두 번째 방법인 취소기반 복구방법에 대해서 알아 보도록 하겠습니다. 대부분의 기업환경에서 데이터베이스에 장애가 발생하면 장애가 발생한 시점까지의 모든 데이터를 안전하게 복구하는 것이 원칙일 것 입니다. 하지만, 백업 데이터 파일과 아카이브 파일의 보관 및 관리 상의 문제로 인해 복구를 정상적으로 수행하지 못하는 경우도 때로는 발생하게 됩니다. 이런 경우에는 사용 가능한 백업 데이터를 이용하여 복구할 수 있는 시점까지 만이라고 최대한 복구작업을 수행해야 할 것 입니다.  바로 이런 경우의 복구방법을 취소기반 불완전 복구라고 합니다. 위 그림에서, 현재 시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다.  ARC1.LOG, ARC2.LOG, ARC3.LOG 파일에 모든 백업 데이터들이 저장되었다고 합니다.  현재시점, 2001년 6월 12일 오후 13시, 시스템 관리자가 실수로 USERS01.DBF 데이터 파일을 삭제했다고 합니다. 이 사실을 모른체 사용자들은 해당 데이터 파일에 저장되어 있는 테이블에 대해 입력, 수정, 삭제작업을 수행하려고 합니다. 하지만, 이 시점에 해당 디크크에는 USERS01.DBF 파일은 존재하지 않기 때문에 사용자들은 더 이상 데이터베이스를 사용할 수 없게 됩니다. 문제는, 이 데이터 파일에 대한 복구 작업을 수행하기 위해 복구작업 시 사용되어야 할 모든 아카이브 파일들 중에 몇 개가 유실되어 사용될 수 없다고 합니다.
	사례-8
	어느 날, 모든 리두로그 파일이 존재하는 디스크에 장애가 발생했다고 합니다. 현재 데이터베이스는 아카이브 모드이며 최근에 전체 데이터베이스 백업이 수행되었다고 합니다.  장애가 발생한 시점까지의 모든 데이터는 복구할 수 있을까요 ?  결론적으로 말씀드리면, 마지막 백업 데이터가 저장되어 있던 온라인 리두로그 파일이 아카이브 되지 않은 상태에서 유실되었기 때문에 완전복구 작업은 수행할 수 없는 상태입니다.  즉, 불완전 복구작업을 수행해야 합니다.
	(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept;
	(2) 이번 시나리오는 여러 개의 리두로그 파일들 중에 LGWR 프로세스에 의해 현재 쓰여지고 있는 CURRENT 리두로그 파일에 장애가 발생한 경우 복구하는 방법과 절차를 소개합니다. 먼저, 현재 사용하고 있는 오라클 서버에서 CURRENT 상태의 리두로그 파일을 확인하십시오. 그리고, CURRENT 리두로그 파일을 삭제하여 장애가 발생한 시나리오를 만들어 보시기 바랍니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>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 옵션을 이용하시면 오라클 서버를 강제 종료 시킬 수 있습니다.
	(3) 자~ 그럼, CURRENT 리두로그 파일이 유실된 경우 불완전 복구를 수행해 봅시다.  오라클 서버가 자동 종료되었거나, ABORT 옵션에 의해 강제 종료된 다음 다시 오라클 서버를 MOUNT 단계까지 만 시작한 다음 불완전 복구를 수행하기 위해 마지막 오프라인 백업 파일들 중에 모든 데이터 파일들 만 재 설치합니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> startup SQL> alter database drop logfile group 그룹번호; → 일반적으로 INACTIVE 리두로그 파일이 유실된 경우에는 관련 리두로그 파일을 제거한 후 다시 재 생성함으로써 복구작업을 완료할 수 있었습니다. 같은 방법으로 복구가 가능한지 수행해 보십시오. 하지만, CURRENT 리두로그 파일은 ALTER DATABASE DROP LOGFILE~ 명령어로는 더 이상 삭제할 수 없습니다. 왜냐하면, CURRENT 상태의 리두로그는 현재 쓰여지고 있는 파일을 의미하기 때문에 데이터베이스 관리자도 삭제할 수 없기 때문 입니다. SQL> shutdown immediate SQL> exit
	(4) 다음은 정상적인 불완전 복구를 수행하는 방법과 절차입니다.  먼저, 현재 생성되어 있는 마지막 아카이브 파일이 몇 번인지 확인해 두십시오. 다음과 같이 여러 가지 방법을 통해 확인할 수 있습니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>첫 번째 방법은 ALERT 파일의 로그 내용을 분석해 보면 마지막 아카이브 파일의 번호를 알아 낼 수 있습니다. [C:\] cd c:\oracle\admin\ora92\bdump [C:\] dir [C:\] edit ALERT_<db>명>.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</db명>
	(5) 이전에 마지막으로 오프라인 백업된 파일들 중에 모든 데이터 파일들만 재설치하십시오. 컨트롤 파일과 리두로그 파일들은 재 설치할 필요가 없습니다. 모든 파일들을 재 설치하게 되면 완전복구 방법이 되며, 데이터 파일들 만 설치하면 불완전 복구가 됩니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[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: {<ret>=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: {<ret>=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: {<ret>=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: {<ret>=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</ret></ret></ret></ret>
	(6) 데이터베이스의 모든 상태정보가 초기화되는 불완전 복구방법이 수행되고 나면 마지막으로 백업되었던 백업파일은 더 이상 사용할 수 없으므로 반드시 오프라인 백업을 수행해야 합니다. 또한, 오프라인 백업이 수행되고 나면 이전의 모든 트레이스 파일와 로그 파일, 아카이브 파일들을 삭제하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] cd c:\oracle\oradata\ora92 [C:\] copy *.* c:\backup [C:\] copy c:\oracle\ora92\database\init.ora c:\backup [C:\] del c:\oracle\admin\ora92\udump\*.trc [C:\] del c:\oracle\admin\ora92\bdump\alert_<db>명>.log [C:\] cd c:\oracle\ora92\database\arch [C:\] del *.arc [C:\] dir</db명>
	사례-9
	데이터베이스의 컨트롤 파일이 존재하는 디스크에 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없습니다. 모든 컨트롤이 유실된 상태이며 마지막으로 백업된 컨트롤 파일 만이 사용 가능한 상태입니다. 어떻게 복구해야 할까요 ?
	(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept; SQL> host dir c:\oracle\ora92\database\arch\*.arc
	(2) 이번 사례는 데이터베이스의 모든 상태정보와 오라클 서버의 시작과 종료 시 반드시 필요한 컨트롤 파일에 대한 내용입니다.  여러 개의 컨트롤 파일 중 하나라도 장애가 발생하면 더 이상 오라클 서버를 사용할 수 없기 때문에 오라클 데이터베이스 구조 중에 가장 중요한 파일 중에 하나입니다.  먼저, 현재 사용하고 있는 오라클 서버에서 컨트롤 파일의 위치와 개수를 확인하십시오. 그리고, 모든 컨트롤 파일을 삭제하여 장애가 발생한 시나리오를 만들어 보시기 바랍니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> shutdown abort --> 오라클 서버가 비정상적으로 종료됩니다. SQL> exit [C:\] del c:\oracle\oradata\ora92\*.ctl ← 사용자의 실수로 인해 모든 컨트롤 파일이 삭제됩니다. (실제 기업환경에서는 임의로 컨트롤 파일을 삭제해서는 안됩니다.)
	(3) 결론적으로 모든 컨트롤 파일에 장애가 발생하면 더 이상 오라클 데이터베이스를 사용할 수 없게 됩니다. 이런 현상이 발생하는 경우에는 불완전 복구방법을 사용합니다.  마지막 오프라인 백업된 백업 파일로부터 모든 컨트롤 파일을 현재 경로로 재 설치하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\]copy c:\backup\*.ctl c:\oracle\oradata\ora92\*.ctl [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> recover database using BACKUP controlfile ← 현재 환경은 컨트롤 파일 만 이전의 백업 파일이고 다른 파일들은 현재 시점의 파일들이기 때문에 컨트롤 파일 만의 복구작업을 수행하기 위해 USING BACKUP CONTROLFILE 절을 사용하여 복구작업을 수행해야 합니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed for thread 1 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} C:\oracle\oradata\ora92\arch\arch_1.arc ← 만약, 적용해야 할 아카이브 파일이 지정되지 않으면 직접 첫 번째 아카이브 파일의 경로와 이름을 입력해야 합니다. 적용해야 할 아카이브 파일명이 출력 되는 경우에는 AUTO 키워드를 입력하여 자동으로 아카이브를 적용하시면 됩니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_2.arc Specify log: {<ret>=suggested | filename | AUTO | CANCEL} AUTO ← 첫 번째 아카이브를 적용하면 두 번째 아카이브 파일의 이름과 경로가 출력되고 해당 파일을 적용할 것 인지가 나타납니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc ← 여러 개의 아카이브 파일을 적용하다 마지막 아카이브 파일을 적용하려고 했을 때 에러가 발생할 수 도 있습니다. 이런 경우는 적용해야 할 마지막 백업 데이터가 아카이브 파일로 저장되어 있는 것이 아니라, CURRENT 리두로그 파일에 저장되어 있기 때문입니다. 이러 경우에는 마지막 CURRENT 리두로그 파일의 경로와 이름을 지정해 주시면 됩니다. SQL> recover database using BACKUP controlfile 에러가 발생하면 다시 리두로그 파일을 적용해 줄 수 없으므로 RECOVER DATABASE 명령어를 재 수행하시면 됩니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc Specify log: {<ret>=suggested | filename | AUTO | CANCEL} c:\oracle\oradata\ora92\redo01.log --> 마지막 CURRENT 리두로그 파일명을 입력하십시오 Log applied. Media recovery complete. SQL> alter database open resetlogs; ← 절차와 방법은 완전복구 방법과 같지만 결론적으로 이 방법은 불완전 복구입니다. 왜냐하면, 데이터베이스의 모든 상태정보가 저장되어 있는 컨트롤 파일이 삭제되었 기 때문에 컨트롤 파일은 복구되었지만 상태정보는 복구되지 않았기 때문입니다. SQL> select count(*) from scott.dept; --> 정상적으로 검색이 가능합니다. SQL> shutdown SQL> exit</ret></ret></ret>
	(4) 불완전 복구를 수행하고 나면 반드시 이전의 마지막 백업파일은 재 사용될 수 없기 때문에 다시 오프라인 백업을 수행해야 합니다. 또한, 이전의 아카이브 파일, 트레이스 파일들도 제거 하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] cd c:\oracle\oradata\ora92 [C:\] copy *.* c:\backup [C:\] copy c:\oracle\ora92\database\init.ora c:\backup