ORACLE - Backup and Recovery 개요

Backup and Recovery 개요

---

▶백업과 복구의 문제

• 다양한 장애로부터 Database 보호
  • 장애유형이 한 두가지가 아닙니다.(정전도 장애가 됩니다)
• MTBF(Mean-Time-Between-Failures)증가
  • 장애간 평균 시간은 증가시켜줘야 합니다. 즉, 다음 장애까지의 기간이 커져야 합니다.
  • 매일 장애가 나면 안되기 때문입니다.
• MTTR(Mean-Time-To-Recover)감소
  • 복구에 관련된 시간은 감소해야 합니다. 장애가 발생하더라도 빨리 복구가 되어야 합니다.
• Data 손실 최소화
  • 복구를 하더라도 파일이나 데이터에 대한 손실은 최소화 해야 합니다.

---

DBA(데이터베이스 관리자)의 주요 역할 중 하나는 항상 데이터베이스를 사용할 수 있도록 유지하는 것입니다. DBA는 시스템 장애를 최소화하기 위해 예방 조치를 취할 수 있습니다.

예방 조치를 했다고 하여 모든 장애를 방지할 수 있다고 생각해서는 안됩니다. DBA는 장애 발생 시 가능한 한 빨리 데이터베이스가 작동되도록 만들어 데이터 손실을 최소화 해야 합니다.

발생할 수 있는 모든 유형의 장애로부터 데이터를 보호하기 위해서 DBA는 정기적으로 데이터베이스를 백업해야 합니다. 현재 백업이 없으면 파일 손실이 발생한 경우 데이터 손실 없이 데이터베이스를 시작하여 실행하는 것이 불가능합니다.

백업은 여러 유형의 장애로부터 데이터를 복구하는 데 반드시 필요하며 백업을 검증하는 작업은 아무리 강조해도 지나치지 않습니다. 실제로 백업이 있는지 확인하지 않고 백업이 있는 것으로 생각하고 있다가 막상 문제가 발생했을 때 백업이 적합하지 않을 경우에는 막대한 비용 손실이 초래될 수 있습니다.

---

▶Failure의 범주

• Statement failure
• User process failure
  • 사용자가 실제 DB 상태는 원격상태입니다. 즉, DB가 문제 생기는 것이 아니라. 접근하려는 클라이언트 측의서버프로세스에문제가 생기는 것입니다.
  • 이때는 PMON이 나서서. 문제를 처리하거나, 데이터를 ROLLBACK 합니다.
  • 툴이나 응용프로그램을 실행하던 쪽에서 장애가 발생해서 비정상 종료되는 상태입니다.
• User error
  • 이것은 위의 에러와 다릅니다. 즉. 사용자 자체가 실수를 한 것입니다.
  • 실수로 테이블을 드롭하거나, 변경하고 COMMIT 등의 작업을 한 것입니다.
• Network failure
  • 말 그대로 네트워크 상태의 문제입니다.
• Instance failure
  • DML처리 단계를 잘 생각해보세요.
  • 항상 데이터베이스는 인스턴스가 앞서 작업하고, 데이터베이스는 나중에 작업을 하게 됩니다.
  • 이럴 때, 인스턴스에 장애가 발생하는 것을 말합니다.
  • DBA가 해줄 일은 다시 데이터베이스를 재시작하면 됩니다.
  • 이것은 SMON이 장애를 파악하고, Redolog 의 내용을 읽어 이전의 작업을 지속할 수 있도록 합니다.
• Media failure
  • ★ 대부분의 심각한 장애가 바로 이 미디어 장애입니다. 즉, 데이터베이스 측, 제어파일, 데이터 파일에 문제가 생김을 뜻합니다.
  • Startup 시에 어떠한 파일이 손상됐냐에 따라서 mount 여부가 달라집니다.
  • 백업본이 없으면, 복구가능성은 0% 입니다.
  • 데이터베이스 관리자가 기술적으로 백업하고 복구하는 것이 필요합니다.

▶Statement Failures 원인(문장에러)

• 응용프로그램 논리 오류
• 부적합한 Data를 테이블에 입력하려고 시도하는 경우
• 충분하지 않은 권한으로 작업을 수행하려고 시도하는경우
• 테이블을 생성하려고 시도했지만 할당량 한계를 초과한경우
• Extent를 할당하게 만드는 INSERT 또는 UPDATE
• 작업을 테이블에 대해 시도했지만 Tablespace에 사용가능한 공간이 부족한 경우

▶Statement Failure 해결

• 프로그램의 논리적 흐름 수정
• SQL 문장 수정 및 재실행
• 필요한 Database 권한 부여
• ALTER USER 명령을 사용하여 User의 Quota 변경
• Tablespace에 file공간 추가
• Resumable space allocation 활성화

▶User Process Failure의 원인

• User가 세션에서 비정상적인 연결 해제를 수행한 경우
• User 세션이 비정상적으로 종료된 경우
• User 프로그램에서 세션을 종료하는 주소 Exception이발생한 경우

▶User Process Failure 해결

• PMON Process가 비정상적으로 종료된 Userprocess를 감지한다.
• PMON은 Transaction을 rollback 하고Transaction이 보유한 Resource와 Lock을 해제한다.

▶User Error Failures

> 롤백안됨 > 10g 에서는 해결됩니다. 휴지통 개념이 생겼어요.

> 롤백안됨

> 롤백안됨

▶User Failure 해결

• Database User에게 교육을 실시한다.
  • 사람이 한 실수니까 사람에게 ㅡㅡ..... 똑바로 햇.
• 유효한 Backup으로부터 Recovery한다.
• Export file에서 table을 Import한다.
• LogMiner를 사용하여 오류 시간을 확인한다.
  • 오라클 8i부터 지원하는 패키지 기반의 유틸리티입니다.
  • 손쉽게, 제어파일, 리두로그 파일을 TEXT 문서를 통해 확인할 수 있게 됩니다.
  • 운영 및 오래전 아카이브 로그 파일 (RedoLog)를 대상으로 합니다.
  • 잘못된 트랜잭션을 커밋하기 위한 방법
• Point-in-time Recovery를 통해 Recovery 한다.
• LogMiner를 사용하여 객체레벨 Recovery를 수행한다.
• FlashBack을 사용하여 Historical Data를 보고Recovery 한다.
  • 오라클 9i의 기능입니다.
  • 수정 작업에 대한 이력이 RedoLog에도 남지만, UndoSegment에도 남게 됩니다.
  • 이 기능은 바로 UndoSegment 의 내용을 확인할 수 있습니다.
  • 너무 오래 된 작업은 안되고, Undo가 덮어쓰이기 전까지 가능합니다.
  • 잘못된 트랜잭션을 커밋하기 위한 방법

▶Instance Failure 원인

◈정전이나 하드웨어 문제로 Server를 사용할 수 없는 경우

◈Oracle Server Background Process중 하나의 failure

▶Instance Recovery

• DBA는 특별한 Recovery 조치를 취할 필요가 없다.
• Startup 명령을 수행하여 instance를 시작한다.
• “database opened” 알림을 기다린다.
• User에게 알린다.
• Failure 원인을 찾기 위해 alert log를 검사한다.

▶Media Failures 원인

• 디스크드라이브의 헤드가 고장난 경우
• Database file에 대한 읽기 및 쓰기와 관련된 물리적 문제가 발생한 경우
• File을 실수로 지운 경우

▶Media Failures 해결

• Recovery 전략은 선택한 Backup 방식 및 영향을 받는 파일에 따라 결정한다.
• 백업을 했던 도구 등을 이용하여 동일한 도구를 가지고 복구를 합니다.
• Startup 시에 반드시 필요한 파일인가?
• 이 파일의 내용이 포기할 만한 데이터인가?
• 사용 가능한 경우 Archived Redo Log file을 적용하여 마지막 Backup 이후 Commit된 Data를 Recovery한다.
• 앞으로 나오게되는 Recover 라는 말은 항상 RegoLog를 적용하는 작업이라고 생각하면 됩니다.
• [그림 3-1, 3-2]

---

▶Backup and Recovery 전략 정의

• 업무상 요구 사항
• Mean time to recover : 점점점 줄어야 합니다.
• Mean time between failure : 장애간 시간 간격은 늘어야 한다(장애가 거의 일어나지 않아야 한다)
• 발전적인 Process : 진보되는 유틸리티 등의 기술적인 사용법을 익혀나가야 한다.
• 운영상 요구 사항
• 24시간 운영 : 데이터베이스의 목적에 따라.
• Backup 테스트 및 검증 : 잘못된 백업방식으로 해놓으면 안된다. 따라서 백업 후에도 테스트가 필요.
• Database 휘발성 : 변경이 많은지 적은지 여부에 따라 백업전략이 바뀌어야 합니다.
• 기술적 고려 사항
• 자원 : 하드웨어, 소프트웨어, 인력 및 시
• 운영 체제 파일의 물리적 이미지 복사본
• Database 객체의 논리적 복사본
• Database 구성
• 바람직한 Backup 주기에 영향을 주는 transaction 볼륨 : 휘발성이 높으면 트랜잭션볼륨이 큽니다.
• 경영진과의 합의 >> 뭘 하던 간에 돈이 필요하므로.

---

▶Disaster Recovery 문제

• 다음과 같은 중대한 손상 발생 시 업무에 어떠한 영향을 주는가?
  
• 지진, 홍수 또는 화재
• 완전한 시스템 손실
• 기억장치 하드웨어 또는 소프트웨어의 오작동
• Database 관리자와 같은 핵심 인력의 손실
  
• 주기적으로 전략을 테스트할 계획을 가지고 있는가?
• 테스트용 서버를 가지고, 백업 및 복구에 대한 테스트를 해야하며.
• 동일한 원본 서버와 같이 테스트 서버를 두어, 많은 테스트를 해야 한다.