ORACLE - 사용자 관리 백업 [10장]

사용자 관리 백업 (User - Managed Backup)

---

▶사용자가 자체적으로 백업 <--이걸 중점적으로 알아둬야 합니다.원리를 안다는게 중요한거지요. 네네~!

• User Managed Backup
  • 이곳에서 말하는 장애는 DB가 손상되어 STARTUP이 되지 않는 상태를 말합니다.
  • 그것을 대비하여, 백업이라는 것을 수행해야 합니다.
  • DB 를 시작하기 위해 필요한 3가지의 파일은 제어파일, 데이터파일, 리두로그 파일입니다.
  • 따라서, 위의 3가지 파일이 백업의 대상이 됩니다.
  • DB는 동일한 이름의 파일이더라도, 생성된 버전이 틀린 파일이 있다면 복구가 되지 않습니다.
  • [1] NO Archive Log Mode 에서의 백업
    • 백업하는 날짜에 모든 데이터베이스 파일(제어, 데이터, 리두로그파일)을 통째로 백업 받습니다.
    • 이 파일은 정상적으로 Shutdown 한 상태에서 복사한 파일을 의미합니다.
    • 따라서, 나중에 문제가 생긴 파일이 생기면, 전체적인 파일을 복구합니다.
    • 기존에 입력되었던 데이터베이스가 백업되지 않았다면, 복구가 불가능 합니다.
    • 갱신이 잘 일어나지 않는 데이터베이스 혹은 테스트 데이터베이스일 경우에 사용합니다.
    • 백업순서 >> 두 종류의 명령어가 사용됩니다. [O/S 명령어 (COPY), SQL 명령어]
      1. Shutdown(abort 를 하면 안됩니다)
      2. 모든 필수파일(Control File, Data File, +Redo log File은 옵션)을 복사합니다.
         • 리두로그 파일이 옵션인 이유는 마운트 상태에서 재생성을 할 수 있기 때문입니다.
      3. 복사가 끝나면, DB를 다시 시작하면 됩니다. START UP
    • DB를 종료했다고 해서, 이것을 CLOSED(Clean, Cold). 전체 적인 DB 구성요소를 받았다고 해서 Whole Database Backup 이라고 합니다.
    • 단점
      • 백업 시 DB를 내려야 합니다.
      • 운영체제 명령등에 대한 디스크 쓰기 속도 등에 따라 DB 복구 시간이 달라집니다.
      • 백업되지 않은 파일은 복구가 불가능합니다.
        • 한달 전에 백업하고, 작업을 하다가 손상될 경우, 백업 이후 데이터는 복구가 불가능합니다.
  • [2]Archive Log Mode 에서의 백업
    • Closed Whole Database Backup 이 가능합니다. (DB종료 후에)
    • Open Database Partial Backup 이 가능합니다.(DB운용 중에) > 부분적으로 백업 중
    • 아카이브 로그 모드에서는 리두로그 파일은 백업 대상이 되지 않습니다.
    • [1] 데이터 파일 백업 순서[테이블 스페이스 단위 백업]
      1. SQL > Alter tablespace [테이블스페이스 이름] begin backup; ◀백업모드라고 합니다.
      2. HOST > 테이블스페이스와 연관된 데이터파일을 운영체제에서 복사합니다.
      3. 만약 다중의 데이터파일이 있다면, SQL > Alter tablespace [테이블스페이스 이름] end backup;
         • 위의 수행은 테이블스페이스의 수 만큼 해줍니다.
         • 계속 DB가 운용 중인 환경입니다.
         • 백업하고 있는 테이블스페이스도 액세스가 가능합니다.
         • [그림1 > BEGIN BACKUP 과 END BACKUP]
    • [2]CONTROL 파일 백업 순서
      1. SQL > Alter Database Backup Controlfile to ' 경로 지정' ;
         • 이러한 것을 제어파일의 스냅샷이라고 합니다. 그 시점을 저장합니다.
      2. SQL > Alter Database Backup Controlfile to trace;
         • 컨트롤파일을 재생성 할 수 있는 스크립트를 생성합니다.
    • 위의 백업과정을 하나하나 떼어보면, Partial백업이지만, 모든 것들을 백업한다면, Whole Database Backup 이 됩니다. 통째로 백업 받은거지요.
  • 장점
    • DB 운용 중에 백업을 받을 수 있습니다.
    • 파일마다 갱신정보가 모두 다릅니다. 따라서 백업전략을 다양한 레벨로 할 수 있습니다.
      • 이 말은, 상대적으로 갱신정보가 다른 테이블끼리의 백업 간격 조정이 가능합니다.
    • CONTROL FILE은 데이터파일과는 별도로 백업을 받을 수 있습니다. 이 파일은 시스템파일이기 때문에 매우 중요합니다. 용량이 데이터파일처럼 크지 않기 때문에 , 자주자주 받는게 좋겠지요
• # 용어
  • FULLbackup : 원본 (모든 블록)을 그대로 읽어서, 백업을 받습니다.
  • Icremental 백업 (증분 저장 영역 관리 기능): 풀 백업과는 반대로 사용되는 용어이며, 이것은 이미 풀 백업을 받은 후에, 변경이 된 파일만 추가적으로 백업을 받는 것을 말합니다.
  • Whole Back up 의 반대말은 Partial 이지요. 위에서 충분히 했으니까 대충. 알아들으셔.....
    • Whole Database Backup
    • Target Database가 열려 있거나 닫혀있을 수 있습니다.
      모든 Datafile 및 Control file의 Backup
    • 부분 Database Backup
    • Tablespace
      Datafile
      Control file

# 참고할만한 사이트 : http://werty4082.springnote.com/pages/1566250

---

▶User-Managed Backup 및 Recovery

• 운영 체제 명령으로 파일 Backup
• 운영 체제 명령으로 파일 Restore
• SQL 및 SQL*Plus 명령으로 Recovery

▶Database File 정보

• 데이터베이스 파일에 대한 정보를 볼 수 있는 딕셔너리의 종류들 입니다.
• V$Datafile : 마운트 상태에서도 볼 수 있습니다.
• DBA_DATA_FILES : 데이터베이스가 완벽하게 오픈 된 상태에서만 볼 수 있습니다.
• V$LOGFILE : 리두로그 파일에 대한 정보,
• V$CONTROLFILE : 컨트롤 파일에 대한 이름이나 경로를 제공합니다.

▶백업 방식

• NOARCHIVELOG 에서는 운용중에 복구할 수 없다는 점 , 명심하세요.
• ARCHIVELOG mode 에서는 운용 중이거나, 데이터베이스가 닫혀있어도 백업이 가능합니다.

▶일관성있는Whole Database Backup(Closed Database Backup)

• 반드시 백업해야 하는 파일은 Data File과 Control Files 입니다.
• 파라미터 파일과 패스워드 파일도 필요하고, 리두로그 파일도 필요하지만 필수 요소는 아닙니다.
• 장점
  • 개념적으로 단순함
  • 수행하기 쉬움
  • 운영자 상호 작용이 거의 필요하지 않음 (명령문이 별로 없다는 말)

▶일관성있는 Whole Database Backup 생성

▶Opened Database Backup

• 데이터 운용모드가 아카이브 모드여야 합니다.
• 여전히 데이터파일과 컨트롤 파일은 반드시 백업해야 하며,
• 추가적으로 파라미터, 패그워드 파일을 받을 수 있습니다.
• 장점
  • 높은 Database 가용성 유지 관리
  • Tablespace 또는 Datafile 레벨에서 수행 가능
    • 백업 전략을 트랜잭션 볼륨에 따라서 별도로 수행할 수 있습니다.
    • 또한 백업되지 않은 일부 파일을 백업할 수 있습니다.
  • 중단 없는 업무 운영 지원
• 단점
  • 백업본 자체만으로는 STARTUP을 할 수 없습니다.
  • 리두로그를 모두 놓아놓지 않았을 경우에는 완전 복구가 불가능할 수 있습니다.
  • 백업본의 안정성 면에서는 Whole Database Backup에 비해서 떨어집니다.
  • 비용 측면에서도 추가적인 저장공간이 필요하기 때문에 부담이 있을 수 있습니다.
• 요구사항
  • 
• Open Database Backup 선택사항
  • 

▶Online Tablespace Backup 생성

• 145번이 현재의 커런트 시퀀스 번호이고, 144번의 Datafile 2를 복사 중입니다.
• 백업된 Datafile 1은 143 이 시퀀스 번호입니다. 모든 파일이 백업되었을 경우와, 현재가 시퀀스 번호가 다를 수 있습니다. 이것은 Open Database Backup의 특징이라고 할 수 있습니다.
• 위의 명령어 중 !CP는 안됩니다. 대신 탐색기를 이용해서 복사하면 되요 ㅡㅡㅋ
  

▶Online Tablespace Backup 종료

• 백업이 끝나면 위의 명령으로 종료를 해주어야 합니다.

▶백업 상태 정보

• V$BACKUP : 백업 중인 파일의 정보를 알 수 있습니다.

▶Online Tablespace Backup 실패

• 오픈을 하지 못하고, 마운트 단계까지만 수행 됩니다.
• 위의 에러는 백업모드에서 빠져나올 수 있도록END BACKUP을 실행하면, 마운트 상태에서 수동으로 DB 를 오픈할 수 있습니다.

▶Online Backup 종료

• V$BACKUP을 질의하여 Backup 상태 확인
• ALTER DATABASE 명령을 실행하여 상태를 변경하고 Header의 고정을 취소
• 
  
• Oracle 9i에서 다음 명령을 사용
• 

▶Read Only Tablespace Backup

• 특정 테이블스페이스를 읽기전용으로 만들었습니다.
• 읽기전용 테이블스페이스는 DML이 불가능해지며, DML을 못하게 하는 이유는 백업에서 제외시키기 위함입니다.
• 만드는 이유
  • 이미 갱신되었고, 앞으로도 갱신될 가능성이 거의 없는 테이블 스페이스를 읽기/쓰기 상태로 두면, 백업할 때마다 그 만큼의 용량대로 백업을 받아야 합니다. 용량이 낭비되는거지요.
  • 하지만, 읽기 전용으로만 만들면, 한 번 , 두 번 정도만 받으면 되니까 그만큼 백업 속도면에서나 용량 측에서도 좋겠습니다. :D
  • 단, 읽기 전용으로 만든 이후에는 최소한 1번이상은 백업을 해주어야 합니다.

▶Read Only Tablespace Backup 문제

• Tablespace를 Read Only로 변경한 후에는 한번의 Backup만 필요
  - 처음 백업 받기 위한 스크립트에서도 백업을 할 수 있도록 추가를 해주어야 합니다.
• Tablespace를 Read Write로 변경한 후에는 해당 Tablespace에 대한 정상적인 Backup 일정 재개
• Control file은 Read Only Tablespace를 올바르게 식별해야 하며 그렇지 않은 경우 Read Only Tablespace Recovery 필요
  • R/O의 테이블스페이스를 백업받을 때에는 Control Files 도 백업 받아서, 일관성을 유지해야 합니다.

▶Logging and Nologging 옵션

• 테이블 스페이스를 생성할 때 NOLOGGING 속성을 줄 수 있습니다.
  • create tablespace ... ... ... nologging
• INSERT, SELECT, CREATE 등에 옵션을 주게되면, 리두로그 기록을 하지 않게 할 수 있습니다.
• SQL* LOADER : 비 오라클 데이터베이스의 데이터베이스를 가져올때도 마찬가지로 NOLOGGING을 할 수 있습니다.
• 단점
  • 복구가 불가능 해집니다.
  • 하지만. 위의 동작들이 굳이 복구가 필요하진 않습니다.
  • 만들다가 실패하면 다시 하면 되니까요 ㅡ.,ㅡ

▶수동 Control file Backup

• Binary 이미지 생성
• 
• 텍스트 Trace file 생성
• 
• ▲이거 만들어지는 경로가 시험에 나옵니다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

▶초기화 Parameter file Backup

▶DBVERIFY Utility를 사용하여 Backup 확인

• 백업한 파일을 따로 검사할 수 있는 유틸리티입니다.
• 운용중이거나 백업파일 모두 검사할 수 있습니다.
• 이것은 DATA FILE 만 검사합니다.
• RMAN은 이러한 과정을 내부에서 자체적으로 수행하므로, 이러한 유틸리티가 필요하지 않습니다.
• 윈도우에서 사용하는 오라클이라도 COMMAND 에서 수행해야 합니다.

▶DBVERIFY 명령 행 인터페이스

• 외부명령행 유틸리티
• Restore 전에 Backup Database 또는 Datafile이 적합한지 확인하는 데 사용
• 데이터 손상 문제 발생 시 진단에 도움

• 

• 검사결과는 화면에 한 번 디스플레이 되고 끝이납니다. 하지만 로그파일을 지정해놓으면 나중에 로그 파일을 보고, 검사 결과를 볼 수 있습니다.