[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;

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 

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

[C:\] sqlplus   "/as  sysdba"

SQL>  startup mountSQL>  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

[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

→  불완전 복구에 의해 데이터베이스의 모든 상태 정보들이 초기화되면 이전까지 생성 되었던 아카이브

    파일들도 이젠 더 이상 필요 없는 파일들이 됩니다. 아카이브 파일들은 사용 가능한 마지막 오프라인

    백업파일 이후에 생성된 것 들만 사용 가능하므로 초기화된 현재 시점에서는 이전의 아카이브 파일은

    사용될 수 없습니다.

[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;

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\ora92SQL>  @moredept.sql

→ 온라인 리두로그 파일이 유실되었기 때문에 에러가 발생합니다.

   또는, 무한정 대기상태에 빠지게 되기도 합니다.SQL>  shutdown  abort

→ 에러가 발생하는 경우에는 오라클 서버가 자동 종료됩니다. 경우에 따라서는 무한정 대기상태에 빠지기도 하는데

   이런 경우에는, 정상적인 복구작업을 수행하기 위해서 강제로 오라클 서버를 종료 시켜야 합니다.

   바로 이때, SHUTDOWN 명령어의 ABORT 옵션을 이용하시면 오라클 서버를 강제 종료 시킬 수 있습니다.

SQL> startup

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

→ 일반적으로 INACTIVE 리두로그 파일이 유실된 경우에는 관련 리두로그 파일을 

   제거한 후 다시 재 생성함으로써 복구작업을 완료할 수 있었습니다.

   같은 방법으로 복구가 가능한지 수행해 보십시오.

   하지만, CURRENT 리두로그 파일은 ALTER DATABASE DROP LOGFILE~ 명령어로는 

   더 이상 삭제할 수 없습니다. 왜냐하면, CURRENT 상태의 리두로그는 현재 쓰여지고 

   있는 파일을 의미하기 때문에 데이터베이스 관리자도 삭제할 수 없기 때문 입니다.SQL>  shutdown immediate

SQL>  exit

첫 번째 방법은 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명>

[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

[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명>

[C:\]  sqlplus   "/as  sysdba"

SQL>  startupSQL>  @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

SQL>  shutdown abort    --> 오라클 서버가 비정상적으로 종료됩니다.

SQL>  exit[C:\] del c:\oracle\oradata\ora92\*.ctl

← 사용자의 실수로 인해 모든 컨트롤 파일이 삭제됩니다.

   (실제 기업환경에서는 임의로 컨트롤 파일을 삭제해서는 안됩니다.)

[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: {=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: {=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: {=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

[C:\] cd  c:\oracle\oradata\ora92 

[C:\] copy *.*  c:\backup

[C:\] copy c:\oracle\ora92\database\init.ora  c:\backup