DBMS 1
DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!
오라클 데이터베이스를 사용하는 사용자들의 기업환경은 매우 다양합니다. 기업 입장에서는 오라클 서버를 종료할 수도 없고, 주문접수도 수행할 수 없는 지경에 이르게 되어 궁극적으로는 불안한 시스템 운영을 할 수밖에 없을 것 입니다. 이런 문제점을 해결하기 위해, 오라클 사는 24시간 365일 동안 데이터베이스를 사용하는 기업환경에서 오라클 서버를 종료하지 않고도 효과적인 백업작업을 수행할 수 있도록 온라인(On-Line) 백업방법을 제공하고 있습니다. 이 백업방법은 오픈(OPEN) 백업 또는 핫(HOT) 백업방법이라고 불리어지기도 합니다. 그리고, 온라인 백업은 반드시 아카이브 모드에서 만 수행할 수 있는 백업방법 입니다. 온라인 백업에는 2가지 백업 방법이 있습니다. 첫 번째는 테이블스페이스 단위의 백업이며 두 번째는 전체 데이터베이스 온라인 백업 방법입니다. 첫 번째 방법은 오라클 10g 이전 버전에서도 제공되었으며 두 번째 방법은 10g 버전부터 제공되었습니다. 다음은 온라인 백업의 방법과 절차에 대한 자세한 설명입니다. (1) 먼저, 오라클 데이터베이스는 사용 가능한 상태이어야 합니다. STARTUP 명령어에 의해 정상적으로 시작되어야 하며 사용자들의 SELECT, UPDATE, INSERT, DELETE 작업이 정상적으로 수행 가능해야 합니다. (2) 다음은, 오라클 데이터베이스가 아카이브 모드로 운영되고 있는지 확인하십시오. (3) 다음은, 해당 테이블스페이스에 대한 온라인 백업하는 방법입니다. 온라인 백업은 테이블스페이스 단위로 관련된 데이터 파일을 복사할 수 있습니다. (4) 온라인 백업된 모든 데이터 파일들을 확인하십시오. 오라클 사에서 제공하는 2가지 온라인 백업방법 중에 먼저 테이블스페이스 단위의 백업 방법을 알아 보았습니다. (2) 오프라인 상태의 테이블스페이스는 테이블스페이스 단위의 온라인 백업을 수행할 수 없지만, 전체 데이터베이스 온라인 백업방법으로는 가능합니다. (3) READ ONLY 상태의 테이블스페이스는 테이블스페이스 단위의 온라인 백업을 수행할 수 없지만, 전체 데이터베이스 온라인 백업방법으로는 가능합니다 온라인 백업파일을 이용한 오라클 데이터베이스의 복구방법에 대해서 알아 보도록 하겠습니다. 지금까지 대부분의 사례 내용들이 오프라인 백업파일을 이용한 복구 방법이었다면 이번 사례는 온라인 백업된 파일을 이용하는 방법입니다. 위 그림에서, 현재 시점 2001년 6월 10일 오전 12시에 데이터베이스의 상태에서 온라인 백업을 통해 SCN 번호가 95인 USERS01.DBF 데이터 파일을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 온라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다. 첫 번째 아카이브 파일 ARC1.LOG 에는 마지막 오프라인 백업 이후부터 2001년 6월 11일 오전 12시까지의 백업 데이터들이 저장 되었다고 합니다. 그리고, 두 번째 아카이브 파일 ARC2.LOG 에는 2001년 6월 11일 오전 12시부터 2001년 6월 12일 오전 12시까지의 백업 데이터들이 저장되었으며, 2001년 6월 12일 오전 12시부터 6월 12일 오후 13시까지의 데이터들은 ARC3.LOG 파일에 기록되어 있다고 합니다. 컨트롤 파일들이 저장되어 있는 모든 디스크에 장애가 발생하였습니다. 또한 모든 데이터 파일이 저장되어 있던 디스크에도 치명적인 문제가 발생하였습니다. 마지막, 온라인 백업 파일을 이용하여 완전 복구작업을 수행해 보도록 하겠습니다. (1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오 (2) 이번 시나리오는 모든 컨트롤 파일과 데이터 파일이 함께 장애가 발생했다고 합니다. (3) 자~ 지금부터 온라인 백업파일을 이용하여 완전복구 작업을 수행해 보도록 하겠습니다. (4) 불완전 복구를 수행하고 나면 반드시 이전의 마지막 백업파일은 재 사용될 수 없기 때문에 다시 오프라인 백업을 수행해야 합니다. 또한, 이전의 아카이브 파일, 트레이스 파일들도 제거 하십시오. 데이터베이스의 컨트롤 파일이 존재하는 디스크에 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없습니다. 모든 컨트롤이 유실된 상태이며 마지막으로 백업된 컨트롤 파일 만이 사용 가능한 상태입니다. 어떻게 복구해야 할까요 (1) 오DEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. (2) 이번 사례는 데이터베이스의 모든 상태정보와트롤 파일에 대한 내용입니다. (3) 결론적으로 모든 컨트롤 파일에 장애가 발생하면 더 이상 오라클 데이터베이스를 사용할 수 없게 됩니다. 이런 현상이 발생하는 경우에는 불완전 복구방법을 사용합니다. (4) 불완전 복구를 수행하고 나면 반드시 이전의 마지막 백업파일은 재 사용될 수 없기 때문에 다시 오프라인 백업을 수행해야 합니다. 또한, 이전의 아카이브 파일, 트레이스 파일들도 제거 하십시오. 현재, 데이터베이스는 아카이브 모드입니다. 최근에 온라인 백업과 오프라인 백업도 정상적으로 수행되었습니다. (1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. (2) 마지막 백업 이후에 NEW_DATA 테이블스페이스가 추가로 생성되었다고 합니다. 그리고, NEW_TEST 테이블을 NEW_DATA 테이블스페이스에 생성한다고 합니다. (3) 갑작스런 정전이 발생하고 새로 생성한 NEW_DATA 테이블스페이스에 장애가 발생한다고 합니다. (3) 그런데, 문제가 있군요 ~ (4) 백업 파일이 없는 데이터 파일은 새로운 데이터 파일을 생성한 후 아카이브 파일을 적용하면 복구작업을 수행할 수 있습니다. 데이터들이 정상적으로 복구되었는지 확인하십시오.ON-Line 백업을 이용한 장애복구
6장 ON-Line 백업을 이용한 장애복구
아침에 출근해서 저녁에 퇴근하는 기업이 있는가 하면, 퇴근 후에도 24시간 동안 인터넷을 통해 계속해서 고객으로부터 제품에 대한 주문 또는 서비스 요청을 받는 기업들도 있습니다. 지금까지 소개되었던 대표적인 백업방법은 오라클 서버를 종료한 후 관련된 모든 파일들을 복사하는 방법인 오프라인(Off-Line) 백업이 소개되었습니다. 그리고, 오프라인 백업된 파일들을 통해 오라클 데이터베이스에 장애가 발생한 경우 복구하는 방법과 절차에 대해서도 자세히 알아 보았습니다. 만약, 24시간 동안 계속적인 기업활동을 수행하는 회사에서 오라클 데이터베이스를 백업하기 위해 반드시 오프라인 백업을 수행해야 한다면 백업을 수행하는 시간 동안에는 고객으로부터 어떤 주문 접수도 처리할 수 없는 상태가 될 수 밖에 없을 것 입니다.
자~ 그럼, 테이블스페이스 단위의 온라인 백업 방법부터 자세히 알아 보도록 합시다.
온라인 백업방법은 반드시 아카이브 모드이어야 합니다. 왜냐하면, 오라클 서버가 사용자들에 의해 사용되고 있는 와중에 백업되는 방법이기 때문에 노-아카이브 모드에서는 수행될 수 없기 때문입니다. 만약, 어떤 데이터 파일을 온라인 백업하고 있는데 그 파일에 존재하는 테이블에 대해 누군가가 변경작업을 수행한다면 백업작업이 완료된 후 변경된 데이터를 해당 데이터 파일에 반드시 변경해야 하기 때문입니다.SQL> archive log list
데이터베이스 로그모드 아카이브 모드
가장 오래된 온라인 로그순서 1
아카이브할 다음 로그 1
현재 로그순서 1
SQL> MKDIR C:\ONLINE_BACKUP-- SYSTEM 테이블스페이스에 대한 온라인 백업
SQL> ALTER TABLESPACE SYSTEM BEGIN BACKUP;
SQL> HOST COPY c:\oracle\oradata\ora92\system01.dbf c:\online_backup
SQL> ALTER TABLESPACE SYSTEM END BACKUP;--TEMP 테이블스페이스에 대한 온라인 백업
SQL> ALTER TABLESPACE TEMP BEGIN BACKUP;
SQL> HOST COPY c:\oracle\oradata\ora92\temp01.dbf c:\online_backup
SQL> ALTER TABLESPACE TEMP END BACKUP;-- UNDOTBS 테이블스페이스에 대한 온라인 백업
SQL> ALTER TABLESPACE UNDOTBS BEGIN BACKUP;
SQL> HOST COPY c:\oracle\oradata\ora92\undotbs01.dbf c:\online_backup
SQL> ALTER TABLESPACE UNDOTBS END BACKUP;-- QUERY 테이블스페이스에 대한 온라인 백업
SQL> ALTER TABLESPACE QUERY BEGIN BACKUP;
SQL> HOST COPY c:\oracle\oradata\ora92\query01.dbf c:\online_backup
SQL> ALTER TABLESPACE QUERY END BACKUP;
온라인 백업을 수행하면서 가장 주의해야 할 점은 ALTER TABLESPACE ~ BEGIN BACKUP;
명령문과 ALTER TABLESPACE ~ END BACKUP; 명령문을 수행하는 시간의 차이입니다. BEGIN BACKUP문을 실행하는 순간부터 관련 테이블스페이스의 모든 파일들에는 CHECKPOINT가 더 이상 발생하지 않게 되며 END BACKUP문을 실행하는 순간 CHECKPOINT가 다시 발생하게 됩니다.(CHECKPOINT의 기본원리에 대해서는 "2편 데이터베이스의 논리적/물리적 구조설계"를 참조 하십시오.) 오라클 서버는 이러한 원리에 의해, 해당 테이블스페이스에 대한 백업시점을 관리하게 됩니다. 결론적으로 테이블스페이스를 생성할 때 너무 큰 크기의 데이터 파일을 생성하게 되면 온라인 백업을 수행할 때 CHECKPOINT의 시점관리에 문제가 발생하여 에러가 발생할 수도 있습니다. 너무 큰 크기의 데이터 파일들은 2~3개 정도로 나누어 스트라이핑(Striping) 하시는 것이 원활한 백업과 복구작업에 도움이 될 수 있습니다.
[C:\] CD C:\ONLINE_BACKUP
[C:\] DIR
SYSTEM01.DBF
UNDOTBS01.DBF
TEMP01.DBF
QUERY01.DBF
6-2 데이터베이스 전체 온라인 백업
온라인 백업방법은 24시간 365일 동안 오라클 데이터베이스를 종료할 수 없는 기업환경에서 매우 적절하게 수행할 수 있는 백업방법 중에 하나라는 것은 두말하면 잔소리일 것 입니다. 하지만, 이 백업방법의 가장 큰 단점은 오라클 데이터베이스를 구성하고 있는 모든 테이블스페이스에 대한 전체 백업이 요구되는 경우입니다.
ALTER TABLESPACE ~ BEGIN BACKUP과 ALTER TABLESPACE ~ END BACKUP 명령어를 반복적으로 수행해야 하기 때문에 번거로울 뿐만 아니라 READ ONLY 모드의 테이블스페이스와 OFFLINE 모드의 테이블스페이스에 대해서는 수행할 수 없는 것이 단점이기도 합니다.
이러한 문제점을 개선한 백업방법이 바로 전 백업방법은(1) ALTER DATABASE BEGIN BACKUP과 ALTER DATABASE END BACKUP 명령어SQL> ALTER DATABASE BEGIN BACKUP; ← 전체 DB 온라인 백업 시작
SQL> host copy c:\oracle\oradata\ora92\system01.dbf c:\full_online_backup
SQL> host copy c:\oracle\oradata\ora92\undotbs01.dbf c:\full_online_backup
SQL> host copy c:\oracle\oradata\ora92\temp01.dbf c:\full_online_backup
SQL> host copy c:\oracle\oradata\ora92\temp02.dbf c:\full_online_backup
SQL> host copy c:\oracle\oradata\ora92\users01.dbf c:\full_online_backup
SQL> host copy c:\oracle\oradata\ora92\query01.dbf c:\full_online_backup
SQL> ALTER DATABASE END BACKUP; ← 전체 DB 온라인 백업의 종료
SQL> ALTER TABLESPACE users OFFLINE IMMEDIATE;
SQL> SELECT tablespace_name, status FROM dba_tablespaces;
TABLESPACE_NAME STATUS
------------------------------ ---------
SYSTEM ONLINE
UNDOTBS ONLINE
TEMP ONLINE
USERS OFFLINESQL> ALTER TABLESPACE users BEGIN BACKUP;
*
ERROR at line 1:
ORA-01128 : cannot start online backup - file 4 is offline
ORA-01110 : data file 4 : 'c:\oracle\oradata\ora92\users01.dbf'SQL> ALTER DATABASE BEGIN BACKUP;
SQL> host copy c:\oracle\oradata\ora92\users01.dbf c:\full_online_backup
SQL> ALTER DATABASE END BACKUP;
SQL> select tablespace_name, status from dba_tablespaces;
TABLESPACE_NAME STATUS
------------------------------------
QUERY READ ONLY ← READ ONLY 상태를 확인하십시오.SQL> ALTER TABLESPACE query BEGIN BACKUP;
alter tablespace users begin backup
1행에 오류:
ORA-01642: 읽기 전용 'USERS' 테이블스페이스에는 초기 백업이 필요하지 않습니다.SQL> ALTER DATABASE BEGIN BACKUP;
SQL> host copy c:\oracle\oradata\ora92\query01.dbf c:\full_online_backup
SQL> ALTER DATABASE END BACKUP;
6-3 온라인 백업을 이용한 완전 복구
결 론적으로 말씀 드리면, 오라클 데이터베이스의 모든 복구방법은 백업된 파일이 오프라인 백업 파일이든, 온라인 백업 파일이든 상관없이 모두 동일한 방법과 절차에 의해 수행하게 됩니다. 지금부터 설명하는 방법과 절차는 이미 소개된 완전복구 방법과 동일합니다. 다만, 복구작업을 수행할 때 온라인 백업된 파일을 이용하는 것 입니다.
현재시점, 2001년 6월 12일 오후 13시에 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 데이터베이스를 사용할 수 없다고 합니다.사례-9
[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
← 갑작스런 정전상태를 만들기 위해 ABORT 옵션으로 오라클 서버를 강제 종료합니다.SQL> exit[C:\] del c:\oracle\oradata\ora92\system01.dbf
[C:\] del c:\oracle\oradata\ora92\undotbs01.dbf
[C:\] del c:\oracle\oradata\ora92\temp01.dbf
[C:\] del c:\oracle\oradata\ora92\temp02.dbf
[C:\] del c:\oracle\oradata\ora92\users01.dbf
[C:\] del c:\oracle\oradata\ora92\query01.dbf
→ 모든 데이터 파일들에 장애가 발생합니다.[C:\] del c:\oracle\oradata\ora92\*.ctl
→ 모든 컨트롤 파일들에 장애가 발생합니다.
먼저, 장애가 발생한 모든 컨트롤 파일과 데이터 파일에 대한 온라인 백업 파일들을 현재 경로로 재 설치하십시오.[C:\] cd c:\online_backup
[C:\] dir
[C:\] copy system01.dbf c:\oracle\oradata\ora92
[C:\] copy undotbs01.dbf c:\oracle\oradata\ora92
[C:\] copy temp01.dbf c:\oracle\oradata\ora92
[C:\] copy temp02.dbf c:\oracle\oradata\ora92
[C:\] copy users01.dbf c:\oracle\oradata\ora92
[C:\] copy query01.dbf c:\oracle\oradata\ora92
→ 장애가 발생한 모든 데이터 파일들을 재 설치합니다.[C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control01.ctl
[C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control02.ctl
[C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control03.ctl
[C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control04.ctl
→ 장애가 발생한 모든 컨트롤 파일들을 재 설치합니다. 만약, 컨트롤 파일의 개수가
4개이면 백업된 파일을 4번 해당 경로에 복사해야 합니다.[C:\] cd
[C:\] sqlplus "/as sysdba"
SQL> startup mountSQL> recover database using backup controlfile
→ 복구해야 할 대상 파일에 이전의 컨트롤 파일이 포함되어 있으므로 USING BACKUP
CONTROLFILE 옵션절을 사용하여 복구작업을 수행해야 합니다.ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed
ORA-00280: Change 8050 for thread 1 is in sequence #5
Specify log: {=suggested | filename | AUTO | CANCEL}AUTO ← 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.arcERROR 발생 ← AUTO 키워드를 적용하여 아카이브를 적용했지만 마지막 아카이브 파일
을 적용할 때 에러가 발생하는 경우가 있습니다. 왜냐하면, 적용해야
할 마지막 백업 데이터는 아카이브 파일에 저장되어 있지 않고 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 Complete Recovery. ← 복구작업이 완료되었습니다.SQL> alter database open resetlogs;
→ 백업된 컨트롤 파일을 이용한 복구작업은 수행과정과 절차는 완전복구 방법과
동일하지만, OPEN 단계에서 반드시 RESETLOGS 옵션을 사용해야 합니다. 왜냐하면,
컨트롤 파일은 현재 시점으로 복구되었지만 데이터베이스 내의 상태정보는 여전히
일치하지 않기 때문입니다. 반드시, 모든 상태정보를 초기화 해야만 OPEN 할 수
있습니다. SQL> select count(*) from scott.dept;
→ 정상적으로 복구된 것을 확인하십시오. SQL> shutdown
SQL> exit
[C:\] copy c:\oracle\oradata\ora92\*.* c:\backup
[C:\] copy c:\oracle\admin\ora92\init.ora c:\backup[C:\] del c:\oracle\oradata\ora92\arch\*.arc
사례-9
[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
사례-10
백업사용당 디스크에 장애가 발생하였습니다. 마지막 백업파일에는 존재하지 않는 새로 생성된 데이터 파일은 어떻게 복구할 수 있을까요 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> create tablespace new_data
datafile 'c:\oracle\oradata\ora92\new_data.dbf' size 500k;SQL> create table scott.new_test tablespace new_data
as select * from scott.dept;SQL> @moredept.sql
SQL> shutdown abort ← 갑작스런 정전이 발생합니다.
SQL> exit[C:\] dir c:\oracle\oradata\ora92
[C:\] del c:\oracle\oradata\ora92\new_data.dbf
a NEW_DATA 테이블스페이스에 장애가 발생합니다.[C:\] dir c:\oracle\oradata\ora92
NEW_DATA 테이블스페이스는 마지막 백업 시에는 존재하지 않던 데이터 파일이기 때문에 복구작업을 수행하기 위해 재 설치할 백업 파일이 존재하지 않기 때문입니다. 백업 파일이 존재하지 않는 복구는 어떻게 수행해야 할까요
결론적으로 말하면, 마지막 백업 이후에 발생한 모든 작업내용은 리두로그 파일과 아카이브 파일에 남아있기 때문에 오라클 서버가 아카이브 모드라면 쉽게 복구할 수 있습니다.[C:\] sqlplus "/as sysdba"
SQL> startup
ORA-01157: 데이터 4 파일을 식별 또는 잠금할 수 없습니다-DBWR 추적파일
ORA-01110: data file 7: ' dir c:\oracle\oradata\ora92\new_data.dbf'SQL> alter database
create datafile 'c:\oracle\oradata\ora92\new_data.dbf'
as 'c:\oracle\oradata\ora92\new_data.dbf';→ 아카이브 파일에는 모든 작업에서 발생한 변경 데이터 만 존재하기 때문에
데이터 파일(NEW_DATA.DBF)에 대한 구조는 별도로 생성해 주어야 합니다.SQL> host dir c:\oracle\oradata\ora92SQL> recover datafile 'c:\oracle\oradata\ora92\new_data.dbf'AUTO ← 새로 생성해준 NEW_DATA.DBF 파일에 아카이브 파일이 가지고 있는
백업 데이터를 적용하여 복구작업을 수행합니다.Log Applied.
Media Complete Recovery.SQL> alter database open;
SQL> select count(*) from scott.new_test;