반응형
/********************************************************************************************
-- Title : [8i] Archiving을 이용한 불완전 복구(OLN)
-- Reference : OLN
-- Key word : cold backup 불완전 복구 recovery restore recover database resetlog
********************************************************************************************/
/****************************************************************************************
-- 불환전 복구의 경우
****************************************************************************************/
ㅇ사용자 에러 : 사용자가 잘못 삭제하거나 잘못된 where절을 사용하여 갱신된
데이터를 커밋하는 경우 등.
ㅇ아카이브 손실 : 완전 복구 작업이 손상되거나 없어진 아카이브 로그 때문에
실패하는 경우. 복구는 아카이브 로그를 적용 전 과거 시점으로 완성.
ㅇ컨트롤 파일 손실 : 컨트롤 파일을 이중화 하지 않았고 데이터베이스의 구조를 모르나
과거 바이너리 사본의 백업을 갖고 있는 경우.
ㅇ리두 로그 손실 : 리두 로그가 이중화 되지 않았으며 데이터 파일과 더불어 아카이브
되기 전의 리두 로그를 분실한 경우.
ㅇ분산 데이터베이스 : 한 지역에서의 불완전 복구는 분산 네트워크 상의 모든 다른 데이터
베이스의 불완전 복구를 요함.
-- Title : [8i] Archiving을 이용한 불완전 복구(OLN)
-- Reference : OLN
-- Key word : cold backup 불완전 복구 recovery restore recover database resetlog
********************************************************************************************/
/****************************************************************************************
-- 불환전 복구의 경우
****************************************************************************************/
ㅇ사용자 에러 : 사용자가 잘못 삭제하거나 잘못된 where절을 사용하여 갱신된
데이터를 커밋하는 경우 등.
ㅇ아카이브 손실 : 완전 복구 작업이 손상되거나 없어진 아카이브 로그 때문에
실패하는 경우. 복구는 아카이브 로그를 적용 전 과거 시점으로 완성.
ㅇ컨트롤 파일 손실 : 컨트롤 파일을 이중화 하지 않았고 데이터베이스의 구조를 모르나
과거 바이너리 사본의 백업을 갖고 있는 경우.
ㅇ리두 로그 손실 : 리두 로그가 이중화 되지 않았으며 데이터 파일과 더불어 아카이브
되기 전의 리두 로그를 분실한 경우.
ㅇ분산 데이터베이스 : 한 지역에서의 불완전 복구는 분산 네트워크 상의 모든 다른 데이터
베이스의 불완전 복구를 요함.
/****************************************************************************************
-- 불완전 복구 유형(RECOVER DATABASE 명령 사용)
****************************************************************************************/
ㅇTime-Based 복구
데이터베이스가 특정 시점으로 모든 변경을 커밋한 후에 종료됨.
- 데이터에 대한 원치 않는 변경이 만들어졌거나 중요한 테이블이 삭제되었고 에러가
발생한 대략적인 시간을 알 수 있는 경우. 잘 시험된 프로그램, 보안 및 절차가 이런
유형의 복구에 대한 필요을 없애 줄 것이다.
- 어느 시점에 이중화되지 않은 온라인 리두 로그는 손상된 경우. 로그 이중화로
이런 유형의 복구에 대한 필요성을 없애 준다.
ㅇCancel-Based 복구
이 복구 방법은 복구 프롬프트에서 "Cancel"을 입력함으로써 종료된다.
- 현재(Current)의 리두 로그 또는 그룹이 손상되어 복구를 위해 이용 불가능한 경우.
이중화 함으로 이 유형의 복구에 대한 필요성을 없애준다.
- 복구를 위해 필요한 아카이브 로그가 분실시. 자주 백업 받고 아카이브를 다중화
함으로 이런 유형의 복구에 댛나 필요성을 방지해 줄 것이다.
ㅇ백업 컨트롤 파일을 이용한 복구
명시한 복구 방법(cancel, time 또는 change)이 완료되었거나 컨트롤 파일이 복구 되었을때
종료 된다. 과거 컨트롤 파일의 복사본이 복구에 사용될 것이라는 것을 "recovery database"
명령에 명시해야 한다.
- 모든 컨트롤 파일들을 분실했고 컨트롤 파일이 재생성될 수 없으며 컨트롤 파일의 바이
너리 백업이 존재하는 경우. 컨트롤 파일을 이중화(다른 디스크로)하고,
"create controlfile"의 현재 텍스트 버전을 유지함으로 이 방법의 사용확률을 감소.
- 현재이 데이터베이스를 현재와 다른 구조를 가진 과거 어느 시점의 데이터베이스로
복원하는 경우.
ㅇChange-Based 복구
데이터베이스가 모든 변경사항을 특정 시스템 변경 번호(SCN)로 커밋한 후에 종료된 경우.
분산 환경에서 데이터베이스 복구 시 이 방법을 사용해야 한다.
/****************************************************************************************
-- "RECOVER" 명령 구문
****************************************************************************************/
-- Recover a database until cancel
SQL> RECOVER DATABSE UNTIL CANCEL;
-- Recover a databse until time
SQL> RECOVER DATABSE
2 UNTIL TIME '1997-12-04:14:22:03';
SQL> RECOVER DATABSE
2 UNTIL TIME '1997-12-04:14:22:03';
-- Recover using backup control file
SQL> RECOVER DATABSE
2 UNTIL TIME '1997-12-04:14:22:03'
3 USING BACKUP controlfile;
SQL> RECOVER DATABSE
2 UNTIL TIME '1997-12-04:14:22:03'
3 USING BACKUP controlfile;
/****************************************************************************************
-- 불완전 복구 단계(Archivelog Mode Database only)
****************************************************************************************/
1. 기존 데이터베이스의 전체 닫힌 백업 수행
2. 모든 데이터 파일들을 이전 백업(시스템 데이터파일 포함)으로부터 복원될 것이기 때문에
데이터베이스가 먼저 종료되었는지 확인
3. 데이터베이스를 과거 어느 시점으로 돌리기 위해 모든 데이터 파일 복원
4. 데이터베이스를 mount 모드로 하고 데이터베이스 복구
5. "resetlog"옵션을 사용하여 데이터베이스를 오픈하고 데이터베이스 문제가 해결 되었는지
확인(해결되지 않았을 때 다시 복구)
6. 데이터베이스 전체 닫힌 백업 수행
주) 1. 모든 데이터 파일을 포함하는 유효한 오프라인 또는 온라인 백업과 복원된 백업 시점에서
장애 시점 이전까지의 모든 아카이브 로그를 갖고 있어야 한다.
2. "alter database open resetlogs;"한 후에는 사용할 리두 로그 그룹(Current)에만
LSN 1로 재설정되고 나머지 리두 로그 그룹은 모두 임시로 0으로 설정된다. 그러므로
LSN 0은 새롭게 시작하는 LSN라기 보다는 임시로 존재하는 번호이다.
/****************************************************************************************
-- 복구 지침
****************************************************************************************/
ㅇ복구와 관련된 대부분의 문제들은 불완전 복구 동안 DBA에 의해 야기되기 때문에 모든 복구
단계들을 따르는 것은 중요하다.
ㅇ불완전 복구 개시 전에 전체 닫힌 데이터베이스 백업을 수행한다.
(컨트롤 파일 및 리두 로그 포함) 이는 다음과 같은 두 가지 측면에서 도움을 줍니다.
- 에러로부터 복구. 복구가 실패 시(예를 들어, 요구되는 복구시점 이전으로 복구),
리두 로그 및 컨트롤 파일은 이 파일들에 대한 백업이 없다면 다음 복구 시에 사용될 수
없다.
- 복구 실패 시 시간 절약. 이 경우에 아카이브 적용이 요구되는 이전 백업 대신에 새로운
백업으로부터 데이터 파일을 복원 가능하다.
- 주의: 전체 백업이 수행되지 않았다면, 적어도 현재의 리두 로그를 아카이브하고
(alter system archive log current) 컨트롤 파일을 백업한다.
(alter database backup controlfile to<location>)
ㅇ성공적 복구 후에 전체 닫힌 백업을 수행한다. 이는 다음에 예정된 백업 완료 전에 복구가
요구되는 경우에 필요하게 될 것이다.
ㅇ복구가 실패하여 다시 수행할 필요가 있는 경우에 사용자들이 시스템을 사용하기 전에 장애가
해결되었는지 확인하기 위해 항상 점검한다.
- 이것은 사용자가 여러분에게 해당 테이블이 11:45 a.m.에 삭제되었다고 알릴 때 발생할 수
있다.
- 여러분은 복구 후에도 해당 테이블이 여전히 거기에 없다는 것을 발견하기 위해서 11:44 a.m.
(테이블 삭제 전)으로 복구한다.
- 사용자 시계가 5분 빠르다는 것을 알았으며 11:39a.m.으로 복원했어야 했다.
ㅇ컨트롤 파일 백업을 데이터베이스 구조가 변경될 때 마다 해야 되는데 이는 현재 데이터베이스
구조가 복구하고자 원하는 시점의 구조와는 다른 경우에 백업 컨트롤 파일이 사용되어져야
하기 때문이다.
ㅇ불완전 복구 후에 모든 데이터베이스 파일들을 동기화 시키기 위해 "resetlogs" 옵션을 사용해
데이터베이스를 오픈해야 한다. 이 명령동안 빠뜨린 리두 로그 파일 (missing redo log file)이
있으면 자동적으로 재생성 된다.
ㅇ다른 데이터베이스 구조의 아카이브를 혼합 시키는 것을 방지하기 위해 시스템의 아카이브
로그를 백업 (추후 제거)한다.
- 예를 들어, 로그 시퀀스 144의 데이터베이스는 arch_120.rdo부터arch _143.rdo 까지의
아카이브 로그들을 가지고 있다.
- 불완전 복구 수행 후에 새로운 데이터베이스 구조가 생성되고 데이터베이스 로그 시퀀스가 0
으로 설정된다.
- arch_120.rdo에서 arch_143.rdo까지의 아카이브로그는 이제 과거 데이터베이스 구조의 부분.
- 120 로그 스위치 후에 arch_124.rdo은 덮어써질 것이며 모든 다른 아카이브로써 백업된다.
(과거 아카이브 로그인 arch_121.rdo에서 arch_143.rdo 까지 포함)
- 나중 단계에서, 복구할 때에 arch_124.rdo를 요구시 백업에서 복원된 아카이브 로그가
올바른 데이터베이스 구조를 위한 것인지 확인할 필요가 있습니다. 그렇지 않으면 에러가
발생할 것이다.
ㅇ트랜잭션 활동은 오직 요구되는 시점으로 roll forward 될 수 있으며 과거 어느 시점으로
되돌려질 수는 없다. 이것은 과거 어느 시점으로 데이터베이스를 돌리기 위해 모든 데이터
파일을 복원해야 하는 이유이다. 모든 데이터 파일의 복원이 실패하면 데이터베이스가
(비동기화된) 오픈되는 것을 막을 것이다.
장애 시점 이전까지의 모든 아카이브 로그를 갖고 있어야 한다.
2. "alter database open resetlogs;"한 후에는 사용할 리두 로그 그룹(Current)에만
LSN 1로 재설정되고 나머지 리두 로그 그룹은 모두 임시로 0으로 설정된다. 그러므로
LSN 0은 새롭게 시작하는 LSN라기 보다는 임시로 존재하는 번호이다.
/****************************************************************************************
-- 복구 지침
****************************************************************************************/
ㅇ복구와 관련된 대부분의 문제들은 불완전 복구 동안 DBA에 의해 야기되기 때문에 모든 복구
단계들을 따르는 것은 중요하다.
ㅇ불완전 복구 개시 전에 전체 닫힌 데이터베이스 백업을 수행한다.
(컨트롤 파일 및 리두 로그 포함) 이는 다음과 같은 두 가지 측면에서 도움을 줍니다.
- 에러로부터 복구. 복구가 실패 시(예를 들어, 요구되는 복구시점 이전으로 복구),
리두 로그 및 컨트롤 파일은 이 파일들에 대한 백업이 없다면 다음 복구 시에 사용될 수
없다.
- 복구 실패 시 시간 절약. 이 경우에 아카이브 적용이 요구되는 이전 백업 대신에 새로운
백업으로부터 데이터 파일을 복원 가능하다.
- 주의: 전체 백업이 수행되지 않았다면, 적어도 현재의 리두 로그를 아카이브하고
(alter system archive log current) 컨트롤 파일을 백업한다.
(alter database backup controlfile to<location>)
ㅇ성공적 복구 후에 전체 닫힌 백업을 수행한다. 이는 다음에 예정된 백업 완료 전에 복구가
요구되는 경우에 필요하게 될 것이다.
ㅇ복구가 실패하여 다시 수행할 필요가 있는 경우에 사용자들이 시스템을 사용하기 전에 장애가
해결되었는지 확인하기 위해 항상 점검한다.
- 이것은 사용자가 여러분에게 해당 테이블이 11:45 a.m.에 삭제되었다고 알릴 때 발생할 수
있다.
- 여러분은 복구 후에도 해당 테이블이 여전히 거기에 없다는 것을 발견하기 위해서 11:44 a.m.
(테이블 삭제 전)으로 복구한다.
- 사용자 시계가 5분 빠르다는 것을 알았으며 11:39a.m.으로 복원했어야 했다.
ㅇ컨트롤 파일 백업을 데이터베이스 구조가 변경될 때 마다 해야 되는데 이는 현재 데이터베이스
구조가 복구하고자 원하는 시점의 구조와는 다른 경우에 백업 컨트롤 파일이 사용되어져야
하기 때문이다.
ㅇ불완전 복구 후에 모든 데이터베이스 파일들을 동기화 시키기 위해 "resetlogs" 옵션을 사용해
데이터베이스를 오픈해야 한다. 이 명령동안 빠뜨린 리두 로그 파일 (missing redo log file)이
있으면 자동적으로 재생성 된다.
ㅇ다른 데이터베이스 구조의 아카이브를 혼합 시키는 것을 방지하기 위해 시스템의 아카이브
로그를 백업 (추후 제거)한다.
- 예를 들어, 로그 시퀀스 144의 데이터베이스는 arch_120.rdo부터arch _143.rdo 까지의
아카이브 로그들을 가지고 있다.
- 불완전 복구 수행 후에 새로운 데이터베이스 구조가 생성되고 데이터베이스 로그 시퀀스가 0
으로 설정된다.
- arch_120.rdo에서 arch_143.rdo까지의 아카이브로그는 이제 과거 데이터베이스 구조의 부분.
- 120 로그 스위치 후에 arch_124.rdo은 덮어써질 것이며 모든 다른 아카이브로써 백업된다.
(과거 아카이브 로그인 arch_121.rdo에서 arch_143.rdo 까지 포함)
- 나중 단계에서, 복구할 때에 arch_124.rdo를 요구시 백업에서 복원된 아카이브 로그가
올바른 데이터베이스 구조를 위한 것인지 확인할 필요가 있습니다. 그렇지 않으면 에러가
발생할 것이다.
ㅇ트랜잭션 활동은 오직 요구되는 시점으로 roll forward 될 수 있으며 과거 어느 시점으로
되돌려질 수는 없다. 이것은 과거 어느 시점으로 데이터베이스를 돌리기 위해 모든 데이터
파일을 복원해야 하는 이유이다. 모든 데이터 파일의 복원이 실패하면 데이터베이스가
(비동기화된) 오픈되는 것을 막을 것이다.
/****************************************************************************************
-- Alert Log 검사
****************************************************************************************/
ㅇ 복구 전후에 검사해야 한다.
ㅇ 자주 저장 및 삭제해야 한다.
ㅇ 복구 동안 정보가 기록된다.
ㅇ 정보는 backupgroud_demp_dest에 저장된다.
ㅇ 파일명은 alert_<SID>.log
ㅇ 복구에러 힌트 및 SCN을 알기 위해 검사는 유용하다.
-- Alert Log 검사
****************************************************************************************/
ㅇ 복구 전후에 검사해야 한다.
ㅇ 자주 저장 및 삭제해야 한다.
ㅇ 복구 동안 정보가 기록된다.
ㅇ 정보는 backupgroud_demp_dest에 저장된다.
ㅇ 파일명은 alert_<SID>.log
ㅇ 복구에러 힌트 및 SCN을 알기 위해 검사는 유용하다.
$ vi arc0_23629.trc
"arc0_23629.trc" 17 lines, 546 characters
Dump file /export/home/oracle8i/iORCL/init/bdump/arc0_23629.trc
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
ORACLE_HOME = /export/home/oracle8i
System name: SunOS
Node name: MAPBAKCOM2
Release: 5.8
Version: Generic_108529-13
Machine: i86pc
Instance name: ORCL
Redo thread mounted by this instance: 0 <none>
Oracle process number: 8
Unix process pid: 23629, image: oracle@MAPBAKCOM2 (ARC0)
Dump file /export/home/oracle8i/iORCL/init/bdump/arc0_23629.trc
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
ORACLE_HOME = /export/home/oracle8i
System name: SunOS
Node name: MAPBAKCOM2
Release: 5.8
Version: Generic_108529-13
Machine: i86pc
Instance name: ORCL
Redo thread mounted by this instance: 0 <none>
Oracle process number: 8
Unix process pid: 23629, image: oracle@MAPBAKCOM2 (ARC0)
*** SESSION ID:(7.1) 2004-09-14 10:23:47.498
*** 2004-09-14 10:23:47.498
*** 2004-09-14 10:23:47.498
$ vi /disk1/BDUMP/alert_DB00.log -- 에러 복구시 예
...
Media Recovery Log
ORA-279 … RECOVER database until time '1997…
Tue Dec 09 11:55;13 1997
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /disk1/archive/arch_34.rdo
Incomplete recovery done UNTIL CHANGE 309121
Media Recovery Complete
Completed: ALTER DATABASE RECOVER CONTINUE DEFAULT
Tue Dec 09 11:55:13 1997
alter database open resetlogs
...
...
Media Recovery Log
ORA-279 … RECOVER database until time '1997…
Tue Dec 09 11:55;13 1997
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /disk1/archive/arch_34.rdo
Incomplete recovery done UNTIL CHANGE 309121
Media Recovery Complete
Completed: ALTER DATABASE RECOVER CONTINUE DEFAULT
Tue Dec 09 11:55:13 1997
alter database open resetlogs
...
/****************************************************************************************
-- Time-Based 복구
****************************************************************************************/
-- 0. 수습 DBA가 실수로 EMP_0908 테이블을 삭제 했다. 테이블은 19:41:34 p.m에 삭제되었고
데이터베이스 활동은 대부분직원이 현재 회의중으로 최소상태임.
-- 1. 데이터베이스가 open상태라면 "nornal" 또는 "immediate"옵션을 사용하여 종료한다.
SQL> SHUTDOWN IMMEDIATE;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> SHUTDOWN IMMEDIATE;
Database closed.
Database dismounted.
ORACLE instance shut down.
-- 2. 데이터베이스 mount.
SQL> STARTUP MOUNT;
ORACLE instance started.
SQL> STARTUP MOUNT;
ORACLE instance started.
Total System Global Area 25419936 bytes
Fixed Size 73888 bytes
Variable Size 24449024 bytes
Database Buffers 819200 bytes
Redo Buffers 77824 bytes
Database mounted.
Fixed Size 73888 bytes
Variable Size 24449024 bytes
Database Buffers 819200 bytes
Redo Buffers 77824 bytes
Database mounted.
-- 3. 백업(가장 최근것)으로부터 모든 "데이터 파일"만 복원.
$ cp -i /backup/*.dbf /export/home/oracle8i/iORCL/data/
$ cp -i /backup/*.dbf /export/home/oracle8i/iORCL/data/
-- 4. 아카이브 로그 복원의 필요에 대비하여 log_archive_dest 위치에 저장하거나 위치를
변경하기 위해 다음 명령을 사용한다.
"alter system archive log start to <locatioin>" 또는
"set logsource <location>"
SQL> ALTER SYSTEM ARCHIVE LOG START TO '/export/home/oracle8i/iORCL/arch2/';
변경하기 위해 다음 명령을 사용한다.
"alter system archive log start to <locatioin>" 또는
"set logsource <location>"
SQL> ALTER SYSTEM ARCHIVE LOG START TO '/export/home/oracle8i/iORCL/arch2/';
System altered.
-- 5. "recover database until time" 명령으로 복구
SQL> RECOVER DATABASE UNTIL TIME '2004-09-14:19:38:46';
Media recovery complete.
SQL> RECOVER DATABASE UNTIL TIME '2004-09-14:19:38:46';
Media recovery complete.
-- 6. 컨트롤 파일 및 리두 로그와 동기화하기 위해 "resetlogs"옵션으로 데이터베이스 open.
SQL> ALTER AATABASE OPEN RESETLOGS;
SQL> ALTER AATABASE OPEN RESETLOGS;
Database altered.
-- 7. 삭제된 테이블 확인
SQL> SELECT table_name, owner
2 FROM dba_tables
3 WHERE table_name = 'EMP_0908';
SQL> SELECT table_name, owner
2 FROM dba_tables
3 WHERE table_name = 'EMP_0908';
TABLE_NAME OWNER
------------------------------ ------------------------------
EMP_0908 SCOTT
------------------------------ ------------------------------
EMP_0908 SCOTT
-- 8. 닫힌 데이터베이스 백업을 수행한다.
-- 9. 복구가 완료되고 백업이 오나료되면 데이터베이스가 사용 가능함을 사용자에게 알리고
복구 시점 이후에 입력된 모든 데이터는 재입력할 필요가 있다고 알린다.
복구 시점 이후에 입력된 모든 데이터는 재입력할 필요가 있다고 알린다.
/****************************************************************************************
-- Cancel-Based 복구(시나리오 위해 notest 자료 사용)
****************************************************************************************/
-- 0. 수습 DBA가 bad 블록 해결을 시도하가가 EMP_0908 테이블을 삭제 시킴.
로그 파일은 사원데이터 파일을 갖고 있는 디스크상에 존재함.
-- 1. 리두 로그가 동일 디스크 상에 존재하므로 리두 로그의 상태 및 아카이브 로그의 상태를
조사한다.
SVRMGR> select * from v$logfile;
GROUP# STAUS MEMBER
------- ----- -------------------
2 /disk1/data/log2a.rdo
1 /disk1/data/logla.rdo
조사한다.
SVRMGR> select * from v$logfile;
GROUP# STAUS MEMBER
------- ----- -------------------
2 /disk1/data/log2a.rdo
1 /disk1/data/logla.rdo
SVRMGR> select * from v$log;
G# ... SEQ# BYTES MEMBERS ARC STATUS ... FIRST_TIME
-- ... ---- ------ ------- --- -------- ... --------------
1 ... 49 153600 1 NO CURRENT ... 97-12-09:11:55
2 ... 48 153600 1 NO INACTIVE ... 97-12-09:11:34
G# ... SEQ# BYTES MEMBERS ARC STATUS ... FIRST_TIME
-- ... ---- ------ ------- --- -------- ... --------------
1 ... 49 153600 1 NO CURRENT ... 97-12-09:11:55
2 ... 48 153600 1 NO INACTIVE ... 97-12-09:11:34
-- 2. 발견 사항
ㅇ리두로그가 다중화 되어 있짐 않음.
ㅇ온라인 리두 로그 중 하나가 빠짐.
ㅇ빠진 리두 로그는 아키이브 되어 있지 않음.
ㅇ리두 로그는 emp테이블의 삭제 전 정보를 갖고 있음.
ㅇ26분간의 데이터가 손실될 것임.
ㅇ사용자가 그들의 데이터를 복구할 수 있음.
-- 3. /disk1/data 디렉토리를 찾은 후에 log2a.rdo 리두 로그를 찾을 수 없으며 아카이브가 되어
있지 않음을 알게 되었다. 따라서 이 시점까지 복구 할 수 없다.
v$log_history를 조회해서 아카이브 로그 시퀀스 48(log1a.rdo)이 존재 않음을 확인.
SVRMGR> select * from v$log_history;
RECID STAMP ... FIRST_CHANGE FIRST_TIME
----- --------- ... ------------ --------------
1 318531466 ... 88330 97-11-28:12:43
47 319512880 ... 309067 97-12-09:11:26
있지 않음을 알게 되었다. 따라서 이 시점까지 복구 할 수 없다.
v$log_history를 조회해서 아카이브 로그 시퀀스 48(log1a.rdo)이 존재 않음을 확인.
SVRMGR> select * from v$log_history;
RECID STAMP ... FIRST_CHANGE FIRST_TIME
----- --------- ... ------------ --------------
1 318531466 ... 88330 97-11-28:12:43
47 319512880 ... 309067 97-12-09:11:26
-- 4. 데이터베이스를 종료한다.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
-- 5. 이미 유효한 백업을 갖고 있으므로 인스턴트를 mount 한다.
SQL> startup mount
ORACLE instance started.
SQL> startup mount
ORACLE instance started.
Total System Global Area 25419936 bytes
Fixed Size 73888 bytes
Variable Size 24449024 bytes
Database Buffers 819200 bytes
Redo Buffers 77824 bytes
Database mounted.
Fixed Size 73888 bytes
Variable Size 24449024 bytes
Database Buffers 819200 bytes
Redo Buffers 77824 bytes
Database mounted.
-- 6. 가장 최근 백업으로부터 모든 데이터파일을 복원한다.
$ cp /backup/*.dbf /export/home/oracle8i/iORCL/data/
$ cp /backup/*.dbf /export/home/oracle8i/iORCL/data/
-- 7. 다음과 같이 로그 시퀀스 48까지 데이터베이스를 복구한다.
SVRMGR> recover database until cancel
ORA-00279 : change 148448 … 12/02/97 12 :45:20 needed for thread
ORA-00289 : suggestion : /disk1/archive/arch_34.rdo
ORA-00280 : change 148448 for thread 1 is in sequence #34
Log applied.
...
ORA-00279 : change 309012 … 12/09/97 11 :33:56 needed for thread 1
ORA-00289 : suggestion : /disk1/archive/arch_48.rdo
ORA-00280 : change 309012 for thread 1 is in sequence #48
Specify log : {<RET>=suggested l filename l AUTO l CANCEL}
cancel.
Media recovery cancelled.
SVRMGR> recover database until cancel
ORA-00279 : change 148448 … 12/02/97 12 :45:20 needed for thread
ORA-00289 : suggestion : /disk1/archive/arch_34.rdo
ORA-00280 : change 148448 for thread 1 is in sequence #34
Log applied.
...
ORA-00279 : change 309012 … 12/09/97 11 :33:56 needed for thread 1
ORA-00289 : suggestion : /disk1/archive/arch_48.rdo
ORA-00280 : change 309012 for thread 1 is in sequence #48
Specify log : {<RET>=suggested l filename l AUTO l CANCEL}
cancel.
Media recovery cancelled.
-- 7. 컨트롤 파일 및 리두 로그와 동기화하기 위해 "resetlogs"옵션으로 데이터베이스 open.
SQL> ALTER DATABASE OPEN RESETLOGS;
SQL> ALTER DATABASE OPEN RESETLOGS;
Database altered.
-- 8. 삭제된 테이블 확인
SQL> SELECT table_name, owner
2 FROM dba_tables
3 WHERE table_name = 'EMP_0908';
SQL> SELECT table_name, owner
2 FROM dba_tables
3 WHERE table_name = 'EMP_0908';
TABLE_NAME OWNER
------------------------------ ------------------------------
EMP_0908 SCOTT
-- 9. 복구가 성공적일 때 사용자에게 데이터베이스가 이용가능하게 되었으므로 복구시간(11:34)
이후에 입력된 모든 데이터는 재 입력할 필요가 있음을 알려준다.
------------------------------ ------------------------------
EMP_0908 SCOTT
-- 9. 복구가 성공적일 때 사용자에게 데이터베이스가 이용가능하게 되었으므로 복구시간(11:34)
이후에 입력된 모든 데이터는 재 입력할 필요가 있음을 알려준다.
/****************************************************************************************
-- Backup Control File 복구
****************************************************************************************/
-- 0. 가정)수습 DBA가 사용자 테이블스페이스를 삭제했다. 백업은 매일 저녁 받는다.
SQL> ALTER TABLESAPCE USERS including contetns;
Tablespace dropped.
-- 1. 즉각 사용자게엑 로그 아웃하고 과거 15분 동안 입력한 데이터를 보유하기를 요청.
더이상의 액세스를 막기 위해 데이터베이스를 "restricted mode"로 변경
SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;
더이상의 액세스를 막기 위해 데이터베이스를 "restricted mode"로 변경
SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;
System altered.
-- 2. 조사하는 동안 지난 밤 백업으로부터 컨트롤 파일 찾음. 현재의 컨트롤 파일이 대체될 것
이기 때문에 요구되는 경우에 데이터베이스 구조 정보를 주의 깊게 수집.
SQL> SELECT * FROM v$log;
이기 때문에 요구되는 경우에 데이터베이스 구조 정보를 주의 깊게 수집.
SQL> SELECT * FROM v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
------ ------- --------- ------- -------- --- -------- -------------- ---------
1 1 655 153600 1 YES ACTIVE 200945 17-SEP-04
2 1 656 512000 1 NO CURRENT 201185 21-SEP-04
3 1 654 512000 1 YES INACTIVE 180884 17-SEP-04
------ ------- --------- ------- -------- --- -------- -------------- ---------
1 1 655 153600 1 YES ACTIVE 200945 17-SEP-04
2 1 656 512000 1 NO CURRENT 201185 21-SEP-04
3 1 654 512000 1 YES INACTIVE 180884 17-SEP-04
SQL> SELECT tablespace_name, file_name
2 FROM dba_data_files
3 WHERE tablespace_name = 'USERS'; -- 정상적인 drop을 했는데.. 나오나??
TABLESPACE_NAME FILE_NAME
---------------- --------------------------------------------------
USERS /export/home/oracle8i/iORCL/systs/users01.dbf
-- 3. 경고 로그를 조사함으로 에러 시간 확인
$ vi alert_ORCL.log
...
Wed Sep 22 08:06:55 2004
drop tablespace users including contents
...
---------------- --------------------------------------------------
USERS /export/home/oracle8i/iORCL/systs/users01.dbf
-- 3. 경고 로그를 조사함으로 에러 시간 확인
$ vi alert_ORCL.log
...
Wed Sep 22 08:06:55 2004
drop tablespace users including contents
...
-- 4. 데이터베이스를 종료하고 컨트롤 파일들을 백업하고 난 뒤 테이블 스페이스가 존재했을
때의 모든 데이터파일과 컨트롤 파일을 복원. 데이터베이스 오픈을 시도한 후에 다음
에러는 리두 로그와 컨트롤 파일이 동기화 되지 않았다는 것을 알려주고 있음.
$ cp /backup/*.ctl /export/home/oracle8i/iORCL/systs/
$ cp /backup/*.dbf /export/home/oracle8i/iORCL/systs/
때의 모든 데이터파일과 컨트롤 파일을 복원. 데이터베이스 오픈을 시도한 후에 다음
에러는 리두 로그와 컨트롤 파일이 동기화 되지 않았다는 것을 알려주고 있음.
$ cp /backup/*.ctl /export/home/oracle8i/iORCL/systs/
$ cp /backup/*.dbf /export/home/oracle8i/iORCL/systs/
SQL> STARTUP
ORACLE instance started.
ORACLE instance started.
Total System Global Area 25419936 bytes
Fixed Size 73888 bytes
Variable Size 24449024 bytes
Database Buffers 819200 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-00338: log 1 of thread 1 is more recent than controlfile
ORA-00312: online log 1 thread 1: '/export/home/oracle8i/iORCL/log/log01.log'
Fixed Size 73888 bytes
Variable Size 24449024 bytes
Database Buffers 819200 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-00338: log 1 of thread 1 is more recent than controlfile
ORA-00312: online log 1 thread 1: '/export/home/oracle8i/iORCL/log/log01.log'
-- 5. 임의의 오프라인 데이터 파일이 존재하는지 알기 위해 조사해 보고 그들을 온라인으로
만든다. 임의의 오프라인 파일들은 복구 후에 복구 가능하지 않게 될수도 있기 때문.
SQL> select * from v$recover_file;
만든다. 임의의 오프라인 파일들은 복구 후에 복구 가능하지 않게 될수도 있기 때문.
SQL> select * from v$recover_file;
no rows selected
SQL> alter database datafile 4 online; -- offline 파일이 있을 시 online 시킴.
-- 6. 다음과 같이 복구 수행
SQL> RECOVER DATABASE UNTIL TIME '2004-09-22:08:06:00'
2 USING BACKUP CONTROLFILE;
ORA-00279: change 201117 generated at 09/21/2004 21:07:35 needed for thread 1
ORA-00289: suggestion : /export/home/oracle8i/iORCL/arch/arch_1_655.arc
ORA-00280: change 201117 for thread 1 is in sequence #655
SQL> RECOVER DATABASE UNTIL TIME '2004-09-22:08:06:00'
2 USING BACKUP CONTROLFILE;
ORA-00279: change 201117 generated at 09/21/2004 21:07:35 needed for thread 1
ORA-00289: suggestion : /export/home/oracle8i/iORCL/arch/arch_1_655.arc
ORA-00280: change 201117 for thread 1 is in sequence #655
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
Media recovery complete.
Media recovery complete.
-- 7. 컨트롤 파일 및 리두 로그와 동기화 시키기 위해 "resetlogs"옵션 사용하여 DB 오픈.
SQL> ALTER DATABASE OPEN RESETLOGS;
SQL> ALTER DATABASE OPEN RESETLOGS;
Database altered.
-- 8. 테이블 스페이스 생성 확인 및 08:06 이후 임의의 데이터는 재입력 시킬 필요가 있음을
알려준다.
알려준다.
/****************************************************************************************
-- 현재 리두 로그의 손실(notest) : 데이터베이스가 오픈되어 있으나 "hung" 상태에 있음.
****************************************************************************************/
-- 1. "hung" 데이터베이스 문제를 해결하기 위해 다음 단계 사용.
SQL> SELECT * FROM v$log;
-- 현재 리두 로그의 손실(notest) : 데이터베이스가 오픈되어 있으나 "hung" 상태에 있음.
****************************************************************************************/
-- 1. "hung" 데이터베이스 문제를 해결하기 위해 다음 단계 사용.
SQL> SELECT * FROM v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIM
------------- ---------
1 1 1 153600 1 NO CURRENT
201162 22-SEP-04
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIM
------------- ---------
1 1 1 153600 1 NO CURRENT
201162 22-SEP-04
2 1 0 512000 1 YES UNUSED
0
0
3 1 0 512000 1 YES UNUSED
0
0
-- 2. 다음 명령을 사용항 현재 로그 파일을 삭제한다.
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1;
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1;
-- 3. 데이터베이스는 이제 운영 가능하게 될 것이다. 로그 파일 손상 시 겹쳐 써지게 될 것이며
파일 손실 시에는 재생성 될 것이기 때문이다.
파일 손실 시에는 재생성 될 것이기 때문이다.
-- 4. 다음 백업 전에 데이터베이스가 미디어 장애 때문에 다운된다면 복구 정보가 막 삭제되었기
때문에 불완전 복구가 요구될 것이다. 따라서 즉각 닫힌 전체 백업을 수행해야 한다.
때문에 불완전 복구가 요구될 것이다. 따라서 즉각 닫힌 전체 백업을 수행해야 한다.
/****************************************************************************************
-- 현재 리두 로그의 손실(notest) : 장애로 인해 닫힌 데이터베이스
****************************************************************************************/
-- 0. 데이터베이스가 닫히게 되었다면 미디어 장애가 발생했거나 백그라운드 프로세스가 종료
되었을 수 있다.
-- 1. 데이터베이스를 오픈하려고 시도할 때 다음 메시지를 통해 현재 리두 로그 그룹의 오류를
바로 확인할 수 있다.
SQL> STARTUP
ORACLE instance started.
바로 확인할 수 있다.
SQL> STARTUP
ORACLE instance started.
Total System Global Area 25419936 bytes
Fixed Size 73888 bytes
Variable Size 24449024 bytes
Database Buffers 819200 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/export/home/oracle8i/iORCL/data/redo02.log'
Fixed Size 73888 bytes
Variable Size 24449024 bytes
Database Buffers 819200 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/export/home/oracle8i/iORCL/data/redo02.log'
-- 2. 로그 그룹2가 현재의 로그 그룹이기 때문에 아직 아카이브되지 않았을 것이다.
"clear logfile"명령도 소용없을 것이다.
SVRMGR> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;
ORA-01624 : log 2 needed for crash recovery of thread 1
ORA-00312 : online log 2 thread 1: 'disk1/archive/log2a.rdo'
"clear logfile"명령도 소용없을 것이다.
SVRMGR> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;
ORA-01624 : log 2 needed for crash recovery of thread 1
ORA-00312 : online log 2 thread 1: 'disk1/archive/log2a.rdo'
-- 3. 따라서 불완전 복구가 요구된다. 우선 다음과 같이 현재 로그 시퀀스 번호를 알아낸다.
SVRMGR > select * from v$log;
GROUP# ... SEQ# BYTES ... ARC STATUS ... FIRST_TIME
------ ... ---- ------ ... --- -------- ... --------------
1 ... 61 153600 ... NO CURRENT ... 97-12-09:11:55
2 ... 60 153600 ... NO INACTIVE ... 97-12-09:11:34
SVRMGR > select * from v$log;
GROUP# ... SEQ# BYTES ... ARC STATUS ... FIRST_TIME
------ ... ---- ------ ... --- -------- ... --------------
1 ... 61 153600 ... NO CURRENT ... 97-12-09:11:55
2 ... 60 153600 ... NO INACTIVE ... 97-12-09:11:34
-- 4. 이전 백업으로부터 모든 데이터 파일을 저장하고 리두 로그 61 적용 전에 중단하기 위해
"recover until cancel"을 사용한다.
SVRMGR> recover database until cancel
ORA-00279 : change 309043... 12/09/97 14:50:14 needed for thread 1
ORA-00289 : suggestion : /disk1/archive/arch_46.rdo
ORA-00280 : change 309043 for thread 1 is in sequence #46
Specify log: {<RET>=suggested | filename |AUTO | CANCEL}
...
ORA-00279 : change 309141... 12/09/97 19:50:14 needed for thread 1
ORA-00289 : suggestion : /disk1/archive/arch_61.rdo
ORA-00280 : change 309043 for thread 1 is in sequence #61
Specify log : {<RET>=suggested |filename | AUTO | CANCEL}
cancel.
Media recovery complete.
"recover until cancel"을 사용한다.
SVRMGR> recover database until cancel
ORA-00279 : change 309043... 12/09/97 14:50:14 needed for thread 1
ORA-00289 : suggestion : /disk1/archive/arch_46.rdo
ORA-00280 : change 309043 for thread 1 is in sequence #46
Specify log: {<RET>=suggested | filename |AUTO | CANCEL}
...
ORA-00279 : change 309141... 12/09/97 19:50:14 needed for thread 1
ORA-00289 : suggestion : /disk1/archive/arch_61.rdo
ORA-00280 : change 309043 for thread 1 is in sequence #61
Specify log : {<RET>=suggested |filename | AUTO | CANCEL}
cancel.
Media recovery complete.
-- 5. "resetlogs"옵션을 사용하여 데이터베이스를 오픈한다.
SQL> ALTER DATABASE OPEN RESETLOGS;
SQL> ALTER DATABASE OPEN RESETLOGS;
-- 6. 데이터베이스는 이제 운영 가능하게 될것인데 임의의 빠진 로그 파일들은 재생성될 것이다.
주. 미디어 장애 때문에 로그 파일이 다른 디스크상에서 생성될 필요가 있다면 "alter
database drop logfie group"이나 수동으로 로그 파일을 생성하기 위해 "alter database
add log group"명령을 사용한다.
주. 미디어 장애 때문에 로그 파일이 다른 디스크상에서 생성될 필요가 있다면 "alter
database drop logfie group"이나 수동으로 로그 파일을 생성하기 위해 "alter database
add log group"명령을 사용한다.
-- 7. 막 불완전 복구를 수행했기 때문에 데이터베이스는 이제 백업 되어야 한다.
/****************************************************************************************
-- Resetlogs를 통한 복구(notest)
****************************************************************************************/
-- 0. 전제조건)
ㅇ오라클 7.3.3 이상이어야 한다.
ㅇ"resetlogs" 후의 백업이 없다.
ㅇ"resetlogs" 전의 백업이 있다.
ㅇ컨트롤 파일이 "resetlogs" 전 후에 존재한다.
ㅇ아카이브 및 리두 로그가 이용 가능하다.
ㅇ경고 로그는 "resetlog" 정보를 가지고 있다.
-- 1. 아래 어느 단계도 생략하지 않고 모든 단계를 수행한다.
현재 데이터베이스 컨트롤 파일을 다른 위치에 복사한다.
-- 2. 최근 "resetlogs" 연산 전의 백업으로 데이터파일과 컨트롤 파일을 복원한다.
현재 데이터베이스 컨트롤 파일을 다른 위치에 복사한다.
-- 2. 최근 "resetlogs" 연산 전의 백업으로 데이터파일과 컨트롤 파일을 복원한다.
-- 3. 데이터베이스를 마운트한다.
-- 4. 경고 로그(alert log)에서 이전 "resetlogs" 연산 완료시에 계산된 변경 번호를 찾는다.
...
Incomplete recovery done UNTIL CHANGE 309121
Media Recovery complete
...
...
Incomplete recovery done UNTIL CHANGE 309121
Media Recovery complete
...
-- 5. 위에서 찾은 변경번호까지 데이터베이스를 복구한다.
SVRMGR> recover database until change 309121 \
2> using backup controlfile;
ORA-00279 : change 309043... 12/09/97 14:50:14 needed for thread 1
ORA-00289 : suggestion : /home/disk1/user4/ARCHIVE/arch_46.rdo
ORA-00280 : change 309043 for thread 1 is in sequence #46
Specify log: {<RET>=suggested | filename |AUTO | CANCEL}
auto
...
Media recovery complete.
SVRMGR> recover database until change 309121 \
2> using backup controlfile;
ORA-00279 : change 309043... 12/09/97 14:50:14 needed for thread 1
ORA-00289 : suggestion : /home/disk1/user4/ARCHIVE/arch_46.rdo
ORA-00280 : change 309043 for thread 1 is in sequence #46
Specify log: {<RET>=suggested | filename |AUTO | CANCEL}
auto
...
Media recovery complete.
-- 6. "normal"옵션을 사용하여 데이터베이스를 종료한다.
-- 7. 단계 1에서 명시한 위치로부터 현재 컨트롤 파일을 복원한다.
-- 8. 데이터베이스를 마운트한다.
-- 9. RECOVER DATABASE 명령에서 적절한 옵션을 사용하여 데이터베이스를 복구한다.
-- 10. 데이터베이스를 오픈한다.
-- 11. 복구하고자 했던 데이터를 검증한다.
-- 12. 올바른 로그 시퀀스 번호까지 복구가 되었는지 확인하기 위해 v$log를 조사한다.
-- 13. "resetlogs"를 통한 복구를 방지하기 위해 데이터베이스를 백업한다.
-- 주. LSN은 리두 로그 파일의 그룹을 사용할 때마다 증가한다. 무한정 증가할 수 있는 것은
아니지만 오라클이 내부적으로 특별한 제한없이 사용할 수 있도록 큰 값으로 max값을
했으므로 MAX에 도달될 염려없이 사용하면 된다.
LSN을 초기화하는 것은 데이터베이스를 오픈할 때 RESETLOGS로 오픈하면 초기화되어
LSN은 다시 1부터 시작하게 된다.
/****************************************************************************************
-- TableSpace Point-In-Time Recovery(TSPITR)
****************************************************************************************/
-- TSPITR 요구사항
ㅇ복구가 요구되는 테이블스페이스의 부분인 모든 데이터파일은 존해해야 한다.
ㅇ"alter database backup controlfile to <name>"명령으로 컨트롤 파일을 백업한다.
아니지만 오라클이 내부적으로 특별한 제한없이 사용할 수 있도록 큰 값으로 max값을
했으므로 MAX에 도달될 염려없이 사용하면 된다.
LSN을 초기화하는 것은 데이터베이스를 오픈할 때 RESETLOGS로 오픈하면 초기화되어
LSN은 다시 1부터 시작하게 된다.
/****************************************************************************************
-- TableSpace Point-In-Time Recovery(TSPITR)
****************************************************************************************/
-- TSPITR 요구사항
ㅇ복구가 요구되는 테이블스페이스의 부분인 모든 데이터파일은 존해해야 한다.
ㅇ"alter database backup controlfile to <name>"명령으로 컨트롤 파일을 백업한다.
-- TSPITR 수행
1. TSPITR 수행시 객체들이 손실될 지 결정한다.
2. 기본 데이터베이스의 종속성을 찾아 해결한다.
3. TSPITR을 위해 기본 데이터베이스를 준비한다.
4. clone 데이터베이스를 위해 파라미터 파일을 준비한다.
5. TSPITR을 위해 clone 데이터베이스를 준비한다.
6. clone 데이터베이스를 복구한다.
7. clone 데이터베이스를 오픈한다.
8. 익스포트를 위해 clone 데이터베이스를 준비한다.
9. clone 데이터베이스를 익스포트한다.
10. clone 파일들을 기본 데이터베이스에 복사한다.
11. 기본 데이터베이스로 임포트한다.
12. 사용을 위해 기본 데이터베이스를 준비한다.
13. 기본 데이터베이스의 복구된 테이블스페이스를 백업한다.
-- Clone DB 생성 과정
1. clone DB를 위한 파라미터 파일을 만들고 지정된 파라미터를 설정한다.
2. recovery set을 기본 데이터베이스와 다른 위치에 restore한다.
3. 새로 만든 init.ora 파일로 clone DB를 마운트 시킨다.
4. alter databsae renae file ... 명령으로 restore 된 위치를 인식시킨다.
5. alter database datafile ... online 명령을 수행하여 TSPITR을 수행할 recovery set
tablespace를 온라인시킨다.
1. TSPITR 수행시 객체들이 손실될 지 결정한다.
2. 기본 데이터베이스의 종속성을 찾아 해결한다.
3. TSPITR을 위해 기본 데이터베이스를 준비한다.
4. clone 데이터베이스를 위해 파라미터 파일을 준비한다.
5. TSPITR을 위해 clone 데이터베이스를 준비한다.
6. clone 데이터베이스를 복구한다.
7. clone 데이터베이스를 오픈한다.
8. 익스포트를 위해 clone 데이터베이스를 준비한다.
9. clone 데이터베이스를 익스포트한다.
10. clone 파일들을 기본 데이터베이스에 복사한다.
11. 기본 데이터베이스로 임포트한다.
12. 사용을 위해 기본 데이터베이스를 준비한다.
13. 기본 데이터베이스의 복구된 테이블스페이스를 백업한다.
-- Clone DB 생성 과정
1. clone DB를 위한 파라미터 파일을 만들고 지정된 파라미터를 설정한다.
2. recovery set을 기본 데이터베이스와 다른 위치에 restore한다.
3. 새로 만든 init.ora 파일로 clone DB를 마운트 시킨다.
4. alter databsae renae file ... 명령으로 restore 된 위치를 인식시킨다.
5. alter database datafile ... online 명령을 수행하여 TSPITR을 수행할 recovery set
tablespace를 온라인시킨다.
-- 위 과정을 통해 clone DB가 준비되면 이제 TSPITR을 수행한다. 이 과정이 상당히 복잡하여
생략한다.
생략한다.
반응형