ORACLE - User_Managed Complete Recovery

User_Managed Complete Recovery

---

▣Media Recovery

• 손실되거나 손상된 현재 Datafile 또는 Control file Recovery에 사용
• 명시적 호출 필요
• 작동 순서 :
  • Backup 에서 file Restore
  • Archived Redo Log file과 Online Redo Log 에서 Redo 데이터를 Restore된 파일에 적용

▣ 복구단계

▣ User_managed 프로시저를 사용한 Restore 및 Datafile Media Recovery

• 운영체제 명령을 사용하여 파일 Restore
• SQL*Plus RECOVER 명령을 사용하여 파일 Recovery
  • 3가지의 RECOVER 명령어를 단계별로 알아야 합니다.

▣ ARCHIVELOG 및 NOARCHIVELOG 모드

★ 아카이브로그로만 복구를 할 경우에는 많은 작업이 있거나 할 때에 데이터를 모두 복구하지 못할 수 있습니다.

★ 아카이브로그는 오픈되어 있는 데이터베이스 상태에서의 복구를 할 수 있다는 것이 가장 큰 장점 입니다.

▣ NOARCHIVELOG 모드에서의 Recovery

• NOARCHIVELOG 모드에서는 다음 Database 파일을 Restore
  • 모든 Datafile
  • Control file
  • 전체를 과거시점으로 복원합니다. 따라서 위의 파일을 모두 복원해야 합니다.
• 다음 파일은 선택적으로 Restore
  • Redo Log file
  • Password file
  • Parameter file
  • 아카이브 로그 모드에서는 위의 파일이 자동으로 백업되고 있기 때문에, 선택적으로 할 수 있습니다.
  • 위의 파일들을 정기적으로 백업을 해놓는다면, 좀 더 빠르게 복원이 가능합니다.
• 장점
  • 수행하기 쉽고 오류 발생 위험이 적음
  • Recovery 시간은 모든 파일을 Restore하는데 걸리는 시간
• 단점
  • 데이터가 손실되므로 수동 재적용 필요
  • 전체 Database가 마지막 완전(Whole) 닫힌 Backup 시점으로 Restore됨

▣ NOARCHIVELOG 모드에서 Redo Log file Backup을 사용한 Recovery

★ 위의 그림은 모든 데이터 파일이 144번으로 되돌아가는 모습입니다.

★ 따라서 변경되어 있던 변경사항은 적용이 되지 않습니다. 수동으로 재적용이 필요합니다.

▣ NOARCHIVELOG 모드에서 Redo Log file Backup을 사용하지 않고 Recovery

1. Instance 종료
2. 최신 완전 Database Backup에서 Datafile과 Control file을 Restore
3. Cancel-Based Recovery 수행
4. RESETLOGS 옵션을 사용하여 Database Open

▣ ARCHIVELOG 모드에서의 Recovery

• Complete Recovery
  • Redo 데이터 또는 Incremental Backup 사용
  • Database를 가장 최근 시점까지 갱신
  • 모든 Redo 변경 사항 적용
• Incomplete Recovery
  • Backup과 Redo Log를 사용하여 현재 버전이 아닌 Database 생성

▣ Complete Recovery

1. Restore할 Datafile이 Offline 상태인지 확인
2. 손실되거나 손상된 Datafile만 Restore
   • 주의
     • 제어파일이 복구되는 경우는 현재 실습까지 없었습니다.
3. Control file, Redo Log file, Password file 또는 Parameter file은 Restore 하지 않음
   • 위의 파일은 항상 복원하는 것이 아니라는 것을 알아두세요.
4. Datafile Recovery
   • 해당되는 데이터 파일을 대상으로 복원합니다.

▣ ARCHIVELOG 모드에서의 Complete Recovery

• 장점
  • 손실된 파일만 Restore
  • 모든 데이터를 오류시점까지 Recovery
  • Recovery 시간은 손실된 파일을 Restore 하고 모든 Archived Log file을 적용하는데 걸리는 시간
  • ★ 변경이 많은 데이터베이스는 백업 주기를 자주자주 하도록 해주는게 좋습니다.
• 단점
  • Restore에 사용 중인 Backup 이후의 Archived Log file이 모두 있어야 함
  • ★ 아카이브로그가 누락되면 그곳에서 중지 됩니다. 건너뛰기가 불가능 합니다. -_ㅠ

▣ Recovery 할 파일 결정

• V$RECOVER_FILE을 통해 Recovery 가 필요한 Datafile 결정
  • 장애가 발생하여 복구가 필요한 파일을 나열해 줍니다.
• V$ARCHIVED_LOG를 통해 Database의 모든 Archived Redo Log file 목록 확인
• V$RECOVERY_LOG를 통해 Recovery에 필요한 모든Archived Redo Log file 목록 확인
  • 첫번 째에서의 정보를 이용해서 현재 복구 작업에 사용할 범위가 어디서 어디까지인지 알 수 있습니다.
  • 일반적인 회사는, 아카이브를 하루에 한번씩 다른 테이프 장치 등으로 저장을 해놓습니다.
  • 테이프장치는 CD와 마찬가지로 한번 쓰고 나면 읽기가 가능하므로, 나중에 복구를 할 경우에는 디스크에 복사를 하고 복구를 할 때 사용해야 합니다.

▣ User-managed Recovery 프로시저 : Recover 명령

▣ Recovery 중 Archived Redo Log file 사용

• Archive 위치를 변경하려는 경우
  • ALTER SYSTEM ARCHIVE LOG … 명령 사용
  • 복구할 경우, 디스크에 용량이 부족할 경우에 이 명령을 사용하여 위치를 변경할 수 있습니다.
• Redo log file을 자동으로 적용하려는 경우
  • Media Recovery를 시작하기 전에 SET AUTORECOVERY ON 명령 실행
  • Archived Log file을 입력하라는 프롬프트가 나타나며 auto 입력
  • RECOVER AUTOMATIC … 명령 사용
  • 위의 세가지 명령어를 사용하면 리두로그를 자동으로 적용할 수 있습니다

▣ User-managed 프로시저를 사용하여 새 위치에 Datafile Restore

• 운영 체제 명령을 사용하여 Datafile을 새 위치에 Restore
  • 오라클에게 이 위치를 알려줘야 합니다. 그 명령어는 밑에 있네요 'ㅁ'//
• ALTER DATABASE RENAME FILE 명령을 사용하여 Contol file에 변경 사항 기록

---

▣ Complete Recovery 방식

• Closed Database Recovery : 반드시 필요한 것은 아니고, 필요할 때만 하면 됩니다.
  • 시스템 Datafile
  • Undo segment Datafile
  • 전체 Database
• 처음에 열려있던 Database를 사용한 Open Database Recovery (파일이 손실된 경우)
• 처음에 닫혀있던 Database를 사용한 Open Database Recovery (하드웨어 고장인 경우)
• Datafile Backup을 사용하지 않고 Datafile Recovery
  • CREATE DATAFILE AS .. 명령어로 빈 데이터 파일을 만들고, 새롭게 적용합니다.

▣ Closed Database의 Complete Recovery

• Closed Database Recovery는 다음 항목의 Recovery에 사용
• 시스템 Tablespace Datafile
• Undo Segment Datafile
• 전체 Database

▣ Closed Database Recovery : 예제

★ 어긋나 있는 로그를 맞춰주기 위해서 아카이브 로그와의 동기화를 시켜 줍니다.

★ 데이터베이스는 마운트 상태여야 합니다.

▣ Database가 처음 열려있던 경우의 열린 Database Recovery

• 다음 경우에 이 방법 사용
  • Database가 현재 열려 있는 경우
  • Recovery 하는 동안 Database가 열린 상태로 있을 경우
  • Media Failure가 SYSTEM Tablespace에 영향을 주지 않는 경우

▣ Open Database Recovery : 예제

★ 2번 과정에서 적용하는 동안 데이터베이스의 상태는 열린상태 입니다.

★ 하지만, 복원하고자 하는 파일만 OFFLINE 상태입니다.

▣ Database가 처음에 닫혀 있던 경우의 열린 Database Recovery

• 다음 경우에 이 방법 사용
  • Database가 현재 닫혀 있는 경우
  • Recovery 하는 동안 Database가 열릴 경우
  • Media Failure가 SYSTEM Tablespace에 영향을 주지 않는 경우

▣ Open Database Recovery : 예제

★ 어차피 시작하면 장애가 있기 때문에 모두 열리지 않습니다. 따라서 어쨋거나 마운트상태에서 정지합니다.

★ 그 다음부터 작업을 하면 됩니다. 'ㅁ'/// 차암 ~ 쉽죠잉 ~~~ *

▣ Backup을 사용하지 않는 Datafile Recovery

• Backup 한 적이 없는 Datafile이 손실된 경우 사용
• SYSTEM Tablespace에 속하는 파일에는 이 Recovery 방식을 사용할 수 없음
  • 따라서 추가를 했다면, 바로 BEGIN BACKUP -> END BACKUP으로 백업을 수행해 주세요.
• Control file이재생성된 경우에는, 이 Recovery 방식을 사용할 수 없음
  • TRACE로 복구후에는 이 방식을 사용할 수 없습니다.

▣ Backup을 사용하지 않고 손실된 Datafile 재생성

★ 'filename'에는 이전의 경로와 파일이름까지 지정해 줘야 합니다. 똑같은 경로, 똑같은 파일 이름이어야 합니다.

★ 하드웨어 적인 문제가 있을 경우에는 다른 곳에 생성해줘야 합니다. 그럴 경우에는 AS 구문을 사용해서 만들 수 있습니다.

★ ' ' 안에는 파일의 이름과 경로가 모두 지정되어야 합니다!!!!

▣ Backup을 사용하지 않고 Recovery : 예제

★ 백업하지 않은 파일은 헤더번호가 없습니다. (빈 파일을 만들어뒀다는 의미)

★ RECOVER 를 수행하면 현재의 헤더번호가 동기화 되어 집니다.

▣ Read-Only Tablespace Recovery

★읽기 전용은RECOVER가 필요 없습니다. 그냥 복사 -> 붙여넣기

★ 아카이브 로그 적용이 필요가 없습니다.

★ 위의 백업시점에 대한 설명

1. 그냥 복사 붙여넣기 하면 적용이 되겠습니다.
2. 두번째 백업시점까지 붙여넣고 나머지는 RECOVER가 필요합니다.
3. 피할 수 있는 문제였지만, 복구하고자 할경우에는 READ-ONLY가 될 시점까지 복원하면 됩니다.

▣ Read Only Tablespace Recovery 문제

• 다음을 수행할 때는 Read Only Tablespace에 대해 특별히 고려해야 함
  • Control file 재생성
  • Datafile 이름 변경
    • 현재는 RONLY 인데, 이전에는 READONLY라는 이름이었거나..... 등....
  • Backup Control file 사용

▣ Control file 손실

• 다음 경우에 Control file을 만들어야 한다.
  • 오류로 인해 모든 Control file이 손실된 경우
  • Database의 이름을 변경해야 하는 경우
  • Control file의 현재 설정을 변경해야 하는 경우

▣ Control file Recovery

• Control file이 손실된 경우 Recovery 방식
  • 현재 Control file 사용 : 다중화된 제어파일 중 하나를 이용하여 복구
  • 새 Control file 생성: TRACE 파일 이용
  • Backup Control file 사용 : 바이너리로 백업받은 파일을 이용하여 복구

▣ 정리

• 필요한 Recovery 유형 결정
• Restore 및 Recovery 해야 하는 파일 결정
• NOARCHIVELOG 모드로 Database Recovery
• ARCHIVELOG 모드로 Database Recovery
• 원래 위치를 사용할 수 없는 경우 다른 위치에 데이터 파일 Restore