RMAN은 오라클에서 물리적 백업 및 복구를 위해 기본적으로 제공되는 유틸리티다.

증분 백업

RMAN의 가장 대표적인 특징은 이전 백업 이후에 변경된 블록들만 백업하는 증분 백업이 가능하다는 것이다.

우선 RMAN에서 증분 백업 대상인 변경된 블록들을 어떠한 방법으로 확인해 백업하는지 [그림 1]을 통해 증분 백업 절차를 확인해보자.

• [그림 1] 증분 백업 절차
• 

[그림 1]과 같이 RMAN에서 레벨 1인 증분 백업 스크립트를 실행하게 되면 우선 백업 기준 SCN인 Incremental start SCN을 결정하게 된다. 이 값에는 Differential 방식일 경우 가장 최근의 Level 1 백업 Checkpoint SCN이, Cumulative 방식일 경우 가장 최근의 Level 0 백업 Checkpoint SCN이 대입된다.

백업 대상 데이터 파일 내 블록들 중에서 Incremental start SCN과 동일하거나 더 큰 SCN을 갖고 있는 블록들은 최근에 변경된 데이터 블록으로 백업 대상에 속하게 된다.

이렇듯 RMAN에서의 증분 백업 기능은 전체 데이터 블록이 아닌 변경된 데이터 블록만을 대상으로 백업을 진행하기 때문에 사용자 백업에 비해 적은 용량의 백업 파일을 생성하게 된다.

블록 압축

RMAN에서는 BZIP2와 ZLIB 등의 압축 알고리즘을 이용한 이진 압축 방법 외에도 백업이 불필요한 데이터 블록들을 백업 대상에서 제외시키는 블록 압축을 수행함으로써 백업 파일의 용량을 감소시키게 된다.

블록 압축은 데이터가 저장된 적이 없는 블록을 제외하고 백업하는 널 블록 압축 방법과 데이터가 저장된 적이 있지만 백업 시점에는 오브젝트가 할당돼 있지 않은 블록을 제외하고 백업하는 미사용 블록 압축 방법으로 구분된다.

이 중에서 미사용 블록 압축 방법은 지역 관리 테이블스페이스의 데이터 파일 헤더에 존재하는 비트맵 정보를 이용해 각 블록의 사용 여부를 확인하기 때문에, 미사용 블록 압축을 수행하기 위해서는 반드시 테이블스페이스를 지역 관리 테이블스페이스로 생성해야 한다.

채널

RMAN에서는 데이터베이스와 백업 장치 사이에 백업 및 복구 작업을 처리해주는 채널이 존재해 디스크뿐만 아니라 테이프 장치에도 직접 백업 데이터 파일을 저장하고 읽을 수 있다.

또한 단일 백업이나 복구 작업 시 다수의 채널을 할당해 병렬 작업을 수행할 수 있는데, [그림 2]를 통해 2개의 채널을 할당해 백업 작업을 수행하는 예를 확인해보자.

• [그림 2] 다중 채널을 사용하는 백업작업
• 

[그림 2]에서는 백업 작업을 위해 2개의 채널 disk1과 disk2를 할당하고 있다. 채널이 할당되면 각각의 채널들은 데이터베이스 서버 세션과 연결되는데, 이 서버 세션들은 백업 대상 데이터베이스 파일을 읽어 각 채널에서 지정한 파일 경로에 백업 파일을 생성하는 실제적인 백업 작업을 수행하게 된다.

만약 각 채널에서 파일 경로를 각기 다른 디스크 장치나 테이프 장치로 설정한 경우에는 쓰기 작업이 분산돼 백업 시간을 단축시킬 수 있게 된다.

백업 셋과 백업 조각

만약 잘못된 백업 용량 산정으로 인해 4개 백업 장치의 가용 공간이 각각 100GB 남은 상황에서 300GB가 넘는 데이터베이스 파일들을 사용자 백업으로 백업해야 한다고 가정하자. 이 경우, 다수 개로 분할된 백업 파일을 생성할 수 없으므로 이 백업은 실패할 가능성이 크다.

RMAN에서는 백업 셋이라는 논리적인 구조로 백업 데이터를 저장하게 되는데, 하나의 백업 셋에는 OS에서 확인 가능한 실제 백업 파일인 백업 조각을 다수 개 포함할 수 있다.

즉, 백업 파일을 다수 개로 분할해 백업할 수 있다는 뜻이다. [리스트 1]은 백업 조각의 최대 크기와 백업 셋에 포함될 최대 데이터 파일 수를 설정해 백업하는 RMAN 예제이다.

• [리스트 1] 다중 백업 셋과 백업 조각을 생성하는 RMAN 백업 스크립트

• RMAN> 
  run {
        allocate channel c1 type disk MAXPIECESIZE 100G;
        backup format '/backup/data/data_%U_%t.bak'
        FILESPERSET 3 
        database;
        release channel c1;
      }
  

[리스트 1]의 백업 스크립트가 수행되면 생성되는 백업 조각의 최대 크기는 100GB이고(MAXPIECESIZE 100G), 하나의 백업 셋에는 최대 3개의 데이터 파일이 포함된다(FILE SPERSET 3). 70GB, 50GB, 50GB, 40GB, 40GB, 80GB 크기의 데이터 파일이 존재하는 데이터베이스가 있다고 가정하자.

[리스트 1]의 스크립트를 이용해 이 데이터베이스를 백업하게 되면 하나의 백업 셋에는 3개의 데이터 파일이 포함될 수 있으므로 총 2개의 백업 셋이 생성되며, 백업 조각의 최대 크기 설정에 의해 하나의 백업 셋 안에는 각 2개씩 총 4개의 백업 조각이 생성된다.

위와 같은 백업 셋과 백업 조각에 대한 설정은 백업 장치의 용량에 맞는 크기의 백업 파일을 생성할 수 있어 백업 장치의 가용성을 높여줄 수 있게 된다.

백업/복구 정보 확인

오라클에서는 6초 이상 수행되는 명령어의 상태를 확인할 수 있는 V$SESSION_LONGOPS라는 데이터 딕셔너리 뷰가 존재한다. 이 데이터 딕셔너리 뷰를 이용하면 실시간으로 RMAN의 작업 진행률을 확인할 수 있다.

[리스트 2]는 V$SESSION _LONGOPS 뷰를 이용해 현재 진행 중인 RMAN 작업의 진행률을 확인하는 스크립트다.

• [리스트 2] RMAN 작업의 진행률을 확인하는 스크립트

• SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,
         ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE"
    FROM V$SESSION_LONGOPS
   WHERE OPNAME LIKE 'RMAN%'
     AND OPNAME NOT LIKE '%aggregate%'
     AND TOTALWORK != 0
     AND SOFAR <= TOTALWORK;
  

그럼 이미 완료된 과거의 백업 정보는 어떻게 확인할 수 있을까?

RMAN은 백업 일자, 용량, 파일의 위치 등을 포함해 RMAN 운영에 필요한 메타데이터(RMAN Repository)를 컨트롤 파일이나 복구 카탈로그 데이터베이스에 저장해 사용한다.

사용자들은 이러한 정보들을 RMAN에서 LIST 또는 REPORT 명령을 사용하거나 복구 카탈로그 뷰를 질의함으로써 조회 가능하다 자료로 활용될 수 있다.

지금까지 설명한 RMAN의 특징들을 분석해보면 RMAN 백업 방식은 백업 저장장치의 가용성과 백업 운영 관리의 효율성을 높이고 백업 운영 비용을 줄이는 효과가 있을 것으로 예상할 수 있다.

ASM의 등장으로 RMAN을 사용한 백업/복구가 선택이 아닌 필수가 되면서 그동안 사용자 백업의 그늘에 가려져 상대적으로 활용도가 낮았던 RMAN의 사용률이 증가할 것으로 보인다.