ORACLE - RMAN Backup

RMAN Backup 개념

---

▣RMAN Backup 개념

• Recovery Manager Backup은 Server-Managed Backup
  • 사용자 관리 백업은 모두 사용자가 수행해야 하지만, 이것은 RMAN상에서 관리됩니다.
  • 결과적으로 서버프로세스가 수행되고, 채널이라는 것을 반드시 사용함으로써, 이 채널이 서버프로세스상의 채널로 동작하고, RMAN 은 서버프로세스에 매우 의존적입니다.
• Recovery Manager는 Backup작업을 위해 Oracle Server Session사용
• 전체 Database, Tablespace, 모든 Datafile, 선택된 Datafile, Control file, Archived Redo log file backup
  • 선택적으로 SPFILE까지는 백업대상이 될 수 있으나, PFILE & Redolog 파일은 백업대상에서 완전하게 제외됩니다.(즉, 필요한 파일만 백업 받는다는 말입니다.)
• Closed Database Backup
  • Target Database Mount
  • Datafile, Control file, Archived Redo log file 포함
  • 운영모드가 더 중요하다는 것 잊지마세요. 항상 ARCHIVE MODE여야 합니다.
• 열린 Database Backup
  • Tablespace를 Backup Mode로 전환할 필요 없음
  • 누군가 ALTER DATABASE BEGIN BACKUP 명령어를 통하여 백업을 받고 있다면, 여기에 포함된 백업은 할 수 없습니다.
  • Datafile, Control file 및 Archived Redo log file 포
  • 운영모드가 더 중요하다는 것 잊지마세요. 항상 ARCHIVE MODE여야 합니다.

▣Recovery Manager Backup

COPY와 백업 셋

• COPY : 운영체제의 COPY와 동일하지만, RMAN이 카피에 대한 복사본에 대한 오류검증을 해줍니다.
  • 이것을 통한 백업은 모든 블록을 받기 때문에, 원본과 용량이 동일해지며, 숫자도 동일해집니다.
• 백업셋 : 백업본들의 집합이라고 합니다. 백업이라는 명령문을 통하여 실행시에 만들어 집니다.

▣Backup Sets

• 위의 그림을 보면 하나의 셋에 2개씩의 백업을 넣어서 총 3개가 생성되게 됩니다.

▣Backup Set 특성

• BACKUP 명령은 Backup Set 생성
• Backup Set은 대개 둘 이상의 파일 포함
  • 위의 그림을 보면 하나의 셋에 파일이 2개이상 포함된 것을 확인할 수 있었습니다.(그림2)
• 디스크 또는 테이프에 Backup Set 기록 가능
  • 백업셋으로 받는다면 위의 2가지 장치에 모두 기록이 가능하지만, RMAN의 COPY는 디스크에만 대상을 지정할 수 있습니다.
• Backup Set에서 파일을 추출하려면 Restore 작업 필요
• Datafile Backup Set은 Incremental 또는 전체(Full) Backup
  • Full Backup: 파일 하나를 처음부터 끝까지 스캔해서 백업
  • Incremental : 지난번 백업본과 비교하여 변경된 것만 백업
• Backup Set은 사용하지 않은 Block은 포함하지 않음
  • 따라서, 원본보다 사이즈가 많이 작아질 수 있습니다.

▣Backup Piece

• Backup Piece 는 Backup Set에 있는 파일
• Backup Piece는 둘 이상의 Datafile에 있는 Block 포함 가능

• 실제 운영체제에서 RMAN을 수행해서 백업받은 파일을 Backup Piece 라고 볼 수 있습니다.
• 결론적으로 셋은 하나인데, 저장장치의 용량제한이 있기 때문에, 파일을 여러개로 나눈 것이라고 할 수 있으며, 예를 들면 하나의 영화파일인데 마치 CD-ROM의 용량제한으로 2개로 나눈것과 같습니다.
• 운영체제에서는 Piece로 분류된 파일만 보여지게 되며, 백업셋은 논리적으로 이 파일들을 묶어서 관리됩니다.
• Piece라는 것은 백업셋의 하위에 속하게 되며, 이 Piece는 하나의 셋에 포함되어야 합니다.

▣Backup Piece Size

• Backup Piece Size는 다음과 같이 제한

• MAXPIECESIZE : 백업피스 하나 당 최대 사이즈를 지정
• FILESPERSET : 파일 당 셋의 개수는 3개이상이면 안된다는 말.

▣BACKUP 명령

• 설명안해도 될....듯.........

▣다중화된 Backup Set

• 테이프 스트리밍을 위해 둘 이상의 Datafile을 Backup Set으로 다중화

• 오라클의 블록 단위로 순차적으로 읽어서 백업셋을 만듭니다.
• 따라서 백업셋에는 섞여서 들어가게 되는데, 그 이유는 IO의 분산을 하기 위함입니다.
• 이건 사용자가 설정하거나 하는 것이 아니라,. 기본적인 방식입니다.

▣Backup Set의 병렬화

• 복수 Channel을 할당하고, 경우에 따라 filesperset을 지정, 많은 수의 파일을 포함시킨다.

• 그림 상으로 백업 DEVICE는 테이프 장치인데, 이 그림처럼 받을려면 채널을 병렬로 띄워야 합니다.
• 만약 PC에 테이프장치가 하나밖에 없다면? 안되겠지요.
• 물리적으로도 다 지원이 되어야 하는 것입니다.

▣이중화된 Backup Set

• 안전한건 좋은데, 경제적인 측면등에 대해서는 고려하지 않은 방법이라고 할 수 있겠습니다.

▣Backup Set의 Backup

▣Archived Redo log file Backup

• Online Redo log file의 자동 Log Switch
  • 자동으로 로그스위치를 일으켜 마지막 로그까지 자동으로 모두 백업하겠다는 뜻입니다.(명령문이 필요없죠잉)
• Archived Log의 Log Failover 수행
  • 두 개의 경로에 백업을 했을 경우라도 기본적으로는 하나의 백업본을 대상으로 복구를 하게 됩니다.
  • RMAN을 사용하지 않을 경우에는 백업을 했던 다른 경로를 사용자가 재지정해주어야 하지만, RMAN에서는 자동으로 찾아서 복구를 수행해 줍니다.
• Backup이 필요한 Archived Log Backup

▣Archived Log Backup Set

• Archived Redo log file만 포함
  • 리두로그나 아카이브는 OS단위의 저장이 되기 때문에, 하나의 셋으로 만들 수 없습니다.
  • 아카이브는 아카이브로그 끼리만 하나의 셋이 됩니다.
• 항상 전체(Full) Backup
  • 항상 전체백업을 수행합니다. 따라서 incremental 백업은 없습니다.

• ARCHIVELOG ALL : Archive 목적지의 모든 것을 백업하라는 뜻입니다. 특정 아카이브의 범위 지정도 가능합니다.
• DELETE ALL INPUT : 운영체제의 MOVE나 탐색기의 잘라내기와 비슷합니다. 즉, 백업이 종료되고 나면 원본은 삭제하라는 명령어 입니다.

▣Backup 제약 조건

• Database는 Mount 또는 Open
  • 완전히 닫혀있으면 안됩니다.
• Online Redo Log Backup은 지원되지 않음
  • 안됩니다. 안되요. 안받아도 되니까 안되는거에요.
• NOARCHIVELOG Mode에서는 “Clean” Backup만 사용 가능
  • RMAN이 아니라 더 훌륭한 툴이 오더라도 CLEAN만 됩니다. 백업방식은 툴이 결정하는게 아니라, 운영모드가 결정합니다.

▣Image Copy

▣Image Copy 특성

• Disk에만 쓰기 가능
• 즉시 Recovery에 사용할 수 있도록 Restore할 필요가 없음
  • 원본 그대로 복사한것이니까요.
• 단일 Datafile, Archived log 또는 Control File의 물리적 복사본
  • 사이즈가 줄어들지 않습니다.
• 모든 Block을 포함한다는 점에서 운영체제 Backup과 가장 유사함
  • 사이즈가 동일!
• Incremental Backup 전략의 일부로 사용가능
  • 방식 자체가 풀 백업입니다. 따라서, 다음번에 inceremental 백업셋의 생성이 가능합니다.

▣Image Copy : 예제

• TAG : OS에서는 식별되지 않습니다. 이것은 어떠한 백업본에 대한 별칭입니다.

▣COPY 명령

• 원본을 경로대신에 파일번호로 지정했습니다. (이 데이터파일의 번호는 딕셔너리가 알고있겠지요)

▣Image Copy 병렬화

• 위의 예제에서 채널은 4개를 사용하고 있습니다.
• 2번째 줄에 COPY, 6번째 줄에 COPY를 사용하고 있는데 이것은 직렬입니다.
• 위의 예제에서 4개의 병렬을 모두 병렬로 받을려고 한다면 COPY명령어 한번에 파일만 4개를 따로따로 지정해야 합니다. (거참 까탈 스럽네 -_-.........)

▣전체 Database Image Copy

• 일관성 있는 완전 Backup을 위해 Database를 MOUNT 한다. - shutdown immediate
• REPORT SCHEMA 명령을 사용하여 파일을 나열한다. - startup mount
• COPY 명령을 사용하거나 각 Datafile의 Image Copy를 만든다. - COPY............
  • 데이터베이스에 있는 테이블스페이스와 데이터파일의 목록을 얻어서, COPY를 1:1로 다 해줍니다.
  • 백업이 완료되고 DATABASE를 OPEN 합니다.
• LIST COPY 명령을 사용하여 복사본을 검증한다.
  • 검증! //

▣Incremental Backup

• 전체 Backup은 모든 Datafile Bloke을 포함
  • 처음에는 풀백업을 반드시 받아놔야 합니다.
• Differential IncrementalBackup은 레벨 n이하에서수정된 Block만 포함
  • 자신과 같은 레벨 혹은 자신보다 낮은 레벨에서 변경된 블록만 받습니다.
• Cumulative IncrementalBackup은 레벨 n-1이하에서 수정된 Block만 포함
  • 자기보다 한단계 낮은 레벨로 받았던 백업본을 포함시켜서 받습니다.

▣Differential Incremental Backup : 예제

• 레벨 n 이하의 최근 Backup 이후에 변경된 모든 Block의 레벨 n Backup

• 자신과 같거나, 자신보다 낮은 레벨의 변경된 데이터만 백업을 받습니다.
• 복구에 사용할 리두의 양을 줄이기 위한 것이 이 백업방식의 목적입니다. (즉, 복구성능을 높이기 위해)

▣Cumulative Incremental Backup : 예제

• 레벨 n-1 이하의 이전 Backup 이후에 변경된 모든 Block을 포함하는 레벨 n Backup

• 2C에서 받는것은 변경된 것을 받는것이 아니라, 월요일 백업본을 한번 더 포함시키고, 월요일에서 화요일사이의 변경된 내용을 함께 받는 것입니다.
• 수요일의 레벨1은 월요일에서 수요일까지 변경된 것만 받는거고,
• 목요일의 2C는 수요일의 백업내용과 수요일에서 목요일까지의 변경된 내용을 함께 받습니다.

▣NOARCHIVELOG 모드에서의 Backup

1. Backup을 위한 충분한 공간이 있는지 확인
2. NORMAL 또는 IMMEDIATE 절을 사용하여 종료
3. DATABASE MOUNT
4. 자동으로 사용되지 않는 경우 복수 Channel 할당
5. Backup 명령 실행
6. Backup이 완료 및 등록되었는지 확인
7. 정상적으로 사용할 수 있도록 Database Open

▣Control File 및 Server ParameterFile 자동 Backup

• CONFUGURE CONTROLFILE AUTOBACKUP 명령을 사용하여 활성화
• 백업이나 COPY 명령이 수행이 되면 매번 제어파일을 백업합니다. 물론, SPFILE도 함께 백업합니다.
• 활성화되면 RMAN는 BACKUP 또는 COPY 명령 이후 Control File 및 현재 Server Parameter file의 자동 Backup 수행
• Database의 구조 변경 이후 Backup 수행
• Backup에 기본 이름 제공(11-10)
• %T : 고정된 참조 시간 이후 경과한 시간(초)을 4바이트로 나타낸 값으로, 백업 셋 시간 기록을 지정합니다. %s 및 %t를 조합하여 백업 셋에 고유한 이름을 지정할 수 있습니다.
• %S : 백업 셋 번호를 지정합니다. 이 번호는 제어 파일 내의 카운터로, 백업 셋이 생성될 때마다 증가합니다.
• %U : 백업 셋 번호와 해당 백업 셋 생성 시간에 대한 단축 표기법으로 구성된 8자 이름을 지정합니다.
• %P : 백업 셋의 백업 피스 번호 지정. 이 값은 각 백업 셋에 대해 1부터 시작하고 각 백업 피스가 생성될 때마다 1씩 증가합니다.

[실습 예제]

▣Server Parameter file Backup

• CONFIGURE CONTROLFILE AUTOBBACK = ON이면 자동으로 backup 됨
• BACKUP SPFILE 을 사용하여 명시적으로 Backup

▣Backup 및 Image Copy 용 Tag

• Backup Set 또는 Image Copy에 지정된 논리적 이름
• 별칭입니다. 태그를 생성하면 RMAN에서만 볼 수 있습니다.

▣RMAN Dynamic View

• V$ARCHIVED_LOG
• 복구를 수행할 때 아카이브의 정보를 확인
• V$BACKUP_CORRUPTION
• 백업이라는 명령어
• V$COPY_CORRUPTION
• COPY라는 명령어를 통한.
• V$DATABASE_BLOCK_CORRUPTION
• 위 3개의 딕셔너리는 백업단계에서 블록의 훼손된 정보를 볼 수 있습니다.
• 훼손된 블록이 감지되더라도 백업은 되지만, 중지하지는 않습니다.
• 따라서 DBA는 백업이 완료된 후에 이러한 명령어를 통하여 훼손에 대한 복원을 해주어야 합니다.
• V$BACKUP_DATAFILE
• V$BACKUP_REDOLOG
• 아카이브 로그겠죠, 리두로그가 아니라. -_- RMAN에서는 리두로그 백업은 지원하지 않습니다.
• V$BACKUP_SET
• V$BACKUP_PIECE

[실습예제]

▣RMAN Backup 모니터

• SET COMMAND ID 명령을 사용하여 Server세션과 Channel 연결
• V$PROCESS 및 V$SESSION 을 질의하여 어떤 세션이 어떤 RMAN Channel에 대응되는지 확인
• V$SESSION_LONGOPS 를 질의하여 Backup 및 Image Copy의 진행상태를 모니터
• RMAN 작업에 대한 모니터를 지원하는 것이 아니라, 데이터베이스에 대한 모든 LONG OPERATION을 보기 위한 모니터를 하기 위한 것입니다.
• 운영 체제 유틸리티를 사용하여 Process 또는 스레드를 모니터

▣기타 RMAN 문제

• Recovery Manager 작업의 비정상적인 종료
• OS에는 파일이 만들어지다 말았겠죠. <-이거보고 백업이 완료된 줄 알수도 있습니다. 따라서, SHIFT+DEL
• 물리적 Block 손상 및 논리적 Block 손상 감지
• 오래전에 백업본을 통하여, 손상된 블록을 복구해줘야 합니다.
• 열린 Backup 중에 Fractured Block 감지
• 실제 운용중인 DB라면 백업 중이더라도 실제 사용자들이 사용할 수 있습니다.
• 그래서 USER Managed BACKUP 에서는 그 헤더를 잠궜는데, RMAN에서는 그게 아니죠.
• 따라서, 중간에 백업하다가 변경된 데이터가 발견되면, 추후에 또 다시 변경본에 대해 백업을 수행합니다.
• 이것의 문제는 실제 DB운용이 바쁜 시간에 할 때는 , 많은 프로세스가 동작하게 되므로, 시스템이 화내겠죠. 적당히 써야 됩니다.