RMAN은 독립형 애플리케이션으로 오라클 데이터베이스와 클라이언트 연결 방식을 통해 접속됩니다. 실제 RMAN은 Command Interpreter에 불과하여 유저의 명령을 해독한 후, RPC를 통하여 데이터베이스에게 넘겨줍니다. 실제적인 작업의 처리는 대상 데이터베이스에서 수행하게 됩니다. RMAN을 사용하여 대상 데이터베이스에 접속할 시에는 해당 데이터베이스의 SYS 권한으로 접속해야 합니다. 이때 RMAN 은 as sysdba 를 자동적으로 사용하게 됩니다.
Enterprise Edition이 아니면 RMAN은 백업 시에 오직 하나의 채널만을 구성할 수 있습니다. Client 설치 시에는 Runtime Client Option이 아닌 Administrator option을 선택해야 RMAN을 사용할 수 있습니다.
네크워크로의 연결 시, Oracle NET 연결방식을 통해 오라클 데이터베이스에 연결됩니다. Local 로 연결할 때에는 특정한 필요 작업이 없지만 Remote로 연결될 시에는 RMAN을 구동하는 머신의 tnsnames.ora 파일에 정확한 ORACLE_SID가 미리 설정되어야 하며, 패스워드 파일 또한 생성이 되어 있어야 합니다. 또한, 9iR2 버전에서의 디폴트 설치값인 Shared Server 형식으로 설치가 되어 있을 시에는 tnsnames.ora 파일에서의 연결방식은 항상 (SERVER=DEDICATED)로 설정이 되어야 합니다.
RMAN의 메모리 사용
RMAN을 사용할 시 주의해야 하는 것은 shared pool과 large pool 입니다. RMAN은 몇 개의 Oracle PL/SQL 패키지들을 기존의 PL/SQL 패키지들과 마찬가지로 Shared Pool 에 올려 사용합니다. 이 때 Shared Pool의 여유 공간이 부족하거나 단편화 현상이 심할 시에는 RMAN 패키지가 실행되지 않을 수가 있습니다. 항상 Shared Pool 내부에 RMAN의 실행에 충분한 메모리가 존재해야 합니다.
Large Pool은 RMAN이 디폴트로 사용하도록 설정된 공간이 아니며, 사용하도록 설정을 하였을 시에도 사용되지 않을 수가 있습니다.
RMAN과 Control file의 연관
Control File은 말 그대로 데이터베이스 내의 실제적 (Physical) 파일들을 관리하는데 사용됩니다. Control File의 내부적인 정보는 Circular reuse records와 noncircular reuse records로 구분됩니다. Physical Backup을 관장하는 RMAN으로서는 Control File의 사용이 절대적으로 필요합니다. RMAN은 Control File로부터 필요한 파일들의 리스트, checkpoint의 정보 및 복구 가능 여부를 수집합니다. 또한 Control File을 직접 액세스하므로 유저가 수동으로 파일 리스트를 작성할 필요성을 배재시킵니다. 이러한 추가적인 정보들을 저장하기 위해 Control File은 8에서부터 좀더 큰 사이즈로 작성이 됩니다.
RMAN은 스스로 행한 백업 작업의 정보들을 일반적으로는 Control File에 기록하여 필요 시 참조하게 됩니다. Control File의 내부적인 정보는 Circular reuse records와 noncircular reuse records로 구분됩니다. RMAN Catalog의 사용 시에는 Control File 대신 Catalog에 이러한 정보들을 기록하게 됩니다. 만약 이러한 백업과 관련된 정보가 Control File에 기록되지 않거나 삭제되었다면 RMAN을 통해 구축해둔 백업은 사용이 불가능해집니다. 이러한 이유로 인하여 Control File은 RMAN을 사용하기 위한 절대적 필요 요소라 말할 수 있습니다.
Control File은 극히 드물지만 디스크 용량의 부족으로 인하여 오래된 내부적인 정보들이 자체적으로 삭제될 수 있습니다. 또한 CONTROLFILE_RECORD_KEEP_TIME 파라미터의 적절치 못한 설정으로 인하여 자체 정보들이 삭제될 수도 있습니다. 이 파라미터의 기본값은 7 로서 DAY 단위를 나타냅니다. 물론 RMAN의 백업 정보가 삭제되는 것을 방지하기 위해서 입니다. 또한 뒤에서 다시 설명하겠지만 이 파라미터의 값을 RMAN의 BACKUP RETENTION PERIOD의 값보다 길게 잡는 것 또한 문제의 발생 요지가 있어 추천되지 않습니다.
또한 극히 주의해야 할 사항은 Control File을 백업할 시에 RMAN이 백업한 Control File 대신, ‘alter database backup controlfile to trace’를 사용하여 생성한 백업용 Control File의 사용입니다. 이와 같이 백업된 Control File은 RMAN이 기록한 백업 정보들을 포함시키지 않습니다. 만약 RMAN Catalog를 사용하지 않는 상태에서 이와 같은 Control File을 사용하여 기존의 Control File을 덮어 씌운다면 RMAN을 통한 백업은 전부 사용이 불가능해집니다. 이와 같이 Control File을 재구성해야 할 경우는 흔히 MAXLOGFILES 나 MAXLOGHISTORY 파라미터 값등의 변경과 같은 데이터베이스의 내부적인 구조를 변경시켰을 때 필요한데, 가능하다면 이와 같이 TRACE를 사용하여 Control File을 백업하는 것은 RMAN을 사용할 시에는 최대한 배재해야 합니다. 혹은 Trace 대신 Binary file 자체로서 Control File을 백업하여 RMAN 관련 정보를 보존하면서 Control File을 백업하는 것 또한 가능합니다.
Control File은 Binary File로 데이터베이스 내에서 매우 업데이트 성이 강한 파일입니다. 만약 RMAN을 통한 백업 중에 Control File의 내용이 변경이 된다면 에러가 발생하겠지요. 혹은 Control File의 변경을 잠금할 수도 있지만 이렇게 된다면 데이터베이스 전체를 잠금하는 것과 다를 바가 없습니다. 이러한 점을 극복하기 위해 RMAN은 Snapshot Controlfile이라는 기법을 사용하여 백업 도중의 Control File과의 동질성을 유지합니다. 이렇게 생성된 Snapshot Controlfile은 ORACLE_HOME/dbs (UNIX), ORACLE_HOME/database (MS) 에 SNCF<ORACLE_SID>라는 이름으로 저장되게 됩니다. 이러한 기본적인 위치는 ‘configure snapshot controlfile name to ‘<location/file_name>’ 의 사용을 통하여 변경이 가능합니다.
RMAN-08512 : waiting for snapshot controlfile enqueue
위와 같은 에러는 기존의 snapshot controlfile header가 다른 프로세스에 의해 잠겨있을 때 발생합니다. 두개 이상의 RMAN 프로세스를 실행하여 복수의 백업을 실행할 때에도 발생이 가능합니다. 이와 같은 에러가 발생하였을 시 다음과 같은 방법으로 트러블슈팅을 해보시기 바랍니다.
select s.sid, username as “User”, program, moduel, action, logon_time”Logon”, l.*
from v$seesion s, v$enqueue_lock l
where l.sid = s.sid and l.type = ‘CF’ and l.idl = 0 and l.id2 = 2;
RMAN Server Processes
RMAN 실행 시, 두개의 서버 프로세스와 채널 당 하나의 채널 프로세스가 생성됩니다. 한 개의 서버 프로세스는 대상 데이터베이스에서의 SYS권한으로 필요한 RMAN 패키지를 호출하며 백업과 복구에 을 실행하는 채널 프로세스의 작업양을 coordinate 합니다. 두번째 서버 프로세스는 shadow라고도 불리며, RMAN의 장시간 트랜잭션을 감시하며 필요한 정보들을 로그합니다. 채널 프로세스는 실제적으로 백업과 복구를 실행하는 프로세스로서 데이터파일로부터 실지 일기와 쓰기를 담당합니다. 채널 프로세스의 타입은 DISK CHANNEL과 TAPE CHANNEL 두가지가 존재합니다.
이와 같이 장기간 처리되는 프로세스들은 다음과 같이 확인할 수 있습니다.
Select sid, serial#, context, sofar, totalwork, round(sofar/totalwork * 100, 2) “%_COMPLETE”
From v$session_longops
And opname like ‘RMAN%’
And totalwork != 0
And sofar <> totalwork
RMAN I/O Processes
RMAN은 대상 데이터베이스가 적절하게 구성되었을 경우 I/O slave를 사용할 수 있습니다. 이러한 I/O slave 에는 disk I/O와 tape I/O 두가지가 있습니다.
Disk I/O Slave의 경우, DBWR_IO_SLAVE 파라미터로 조정됩니다. 어떠한 숫자로든 설정이 가능하며 0 이 아닌 값으로 설정이 되어 있을 경우 RMAN은 자동적으로 하나의 채널당 4개의 I/O 프로세스를 할당하여 데이터블럭을 RMAN 메모리 버퍼로 읽어 올리게 합니다. 이것은 좋은 기능이기는 하지만 RMAN이 메모리를 사용하는 방법에 있어 문제가 발생할 수도 있습니다. DBWR_IO_SLAVE의 활용은 오직 OS에서 비동기적 I/O 를 지원하지 않거나 사용하지 않도록 설정하였을 경우에만 유용하게 쓰입니다.
Tape I/O 의 경우 BACKUP_TAPE_IO_SLAVES 파라미터의 값이 TRUE로 설정이 되어 있는 경우에 RMAN은 각 채널 당 하나의 Tape I/O Slave를 설정합니다. 이 설정은 Disk I/O와는 달리 데이터베이스에 대해 어떠한 변경도 하지 않으며 단지 Tape Backup에만 영향을 미칩니다. 물론 Tape은 기본적으로 비동기적 I/O를 지원하지 않기 때문에 Tape Backup의 사용 시, 항상 이 파라미터의 값을 TRUE로 설정하는 것을 권장합니다.
RMAN의 SYS 패키지 사용
RMAN은 SYS권한으로 DBMS_RVCMAN과 DBMS_BACKUP_RESTORE 패키지를 사용합니다. 이 패키지들은 catproc.sql로 디폴트 생성되며, 8.0.3부터 기본적으로 생성됩니다. 이러한 패키지들은 Oracle 라이브러리파일로 자체 내장이 되어 있어, 다른 패키지들과는 달리 데이터베이스가 오픈되지 않았을 시에도 사용이 가능합니다. 즉 최소한 데이터베이스가 nomount 스테이지일 때부터 사용이 가능합니다.
SYS.DBMS_RCVMAN
이 패키지는 Control File을 읽어 RMAN이 해당 작업을 수행하기 위해 필요한 정보들을 입력하는 역할을 합니다. 백업 및 복구에 필요한 파일들의 위치와 파일 헤더 정보 및 크기 등의 정보 취급을 담당합니다.
SYS.DBMS_BACKUP_RESTORE
이 패키지는 백업 및 복구에 필요한 데이터파일, 컨트롤파일, ARCHIVED REDO LOG 파일들을 호출하기 위한 SYSTEM CALL을 생성합니다.
RMAN의 DATA BLOCK BACKUP
RMAN에서는 BLOCK-LEVEL BACKUP의 사용이 가능합니다. RMAN의 구조는 INPUT 메모리와 OUTPUT 메모리로 이루어져 각 DB 블록이 백업을 위해 처리될 때, 각 블록에 대해 CORRUPTION 점검을 하게 됩니다. (PROXY COPY로 실행할 경우에는 제외됩니다.) 또한 이 처리 절차 단계에서 Null Compression 점검을 하여 블록 헤더가 0 으로 잡혀있는, 즉 비어있는 블록에 대해서는 백업에 포함시키지 않아 훨씬 더 효과적인 백업을 수행하게 됩니다.
이 때 완벽하게 비어있는 모든 DB 블록들이 백업 대상에서 제외되는 것은 아닙니다. RMAN은 데이터베이스가 다운되어 있을 때에도 수행되어야 하기 때문에, 데이터베이스가 운용되어 있는 중의 Segment Management 정보를 포함하고 있는 뷰에 접근하는 대신 (보다 정확한 정보를 얻을 수 있는), OS 레벨에서의 데이터파일 헤더에서 필요한 정보를 얻어오기 때문에 예를 들어 Truncate 시킨 테이블에 소모되어 있는 DB 블록에 대한 정보들을 얻어올 수없습니다.
그리고 이러한 방식으로 미사용된 블록의 백업 불포함이 시간적인 성능 향상을 불러 일으키는 것은 아닙니다. 심각한 병합현상을 보이는 백업 대상 장치를 제외하고는 시간적으로는 거의 동일한 시간을 소모하게 됩니다. 왜냐하면 RMAN은 여전히 데이터파일 내의 모든 블록을 대상으로 검사를 하여야 하기 때문입니다.
이러한 BLOCK-Level Backup은 Redo 의 생성을 적게 합니다. 일반적인 모드의 백업 작업은 많은 양의 Redo Log 생성 및, Archived Redo Log 를 위한 Log Switch의 대량 발생등이 야기되나, RMAN 은 DBWR 와 연계하여 작업을 수행하기에 Block 레벨의 동기성을 보장할 필요가 없어 이러한 문제가 발생하지 않습니다.
오라클 9i 부터는 ‘ora-1578: block corruption detected’ 에러의 발생 시, 파일을 통째로 복구하는 대신, 단순히 Corrupt 된 블록만을 교체할수 있어 그 효용성이 더욱 증가되었습니다.
RMAN의 메모리 사용
RMAN의 두가지의 버퍼를 사용합니다. 하나는 INPUT BUFFER로 백업되는 파일들의 데이터블록이 로딩되는 곳이며 다른 하나는 OUTPUT BUFFER로써 해당 블록이 백업이 필요한지의 여부를 검사하는 곳입니다.
INPUT MEMORY BUFFER
– 백업 셋에 포함될 파일들의 개수가 4, 혹은 이하일 때 RMAN은 파일 당 4개의 버퍼를 1MB 크기로 생성합니다. 전체 크기는 16MB 혹은 그보다 작습니다.
– 백업 셋에 포함될 파일들의 개수가 4 보다 크고 9 보다 작을 때, RMAN은 파일 당 4개의 버퍼를 512 KB 크기로 생성합니다. 전체 크기는 16MB 혹은 그보다 작습니다.
– 백업 셋에 포함될 파일들의 개수가 8 보다 클 때 RMAN은 파일 당 4개의 버퍼를 128KB 크기로 생성합니다. 파일 당 할당되는 최대 INPUT 버퍼의 크기는 512KB 입니다.
– 이러한 모든 사항은 채널 당 할당되는 것임을 명심하시기 바랍니다.
OUTPUT MEMORY BUFFER
– 디스크로 쓸 때, 채널 별로 총 4개의 OUTPUT BUFFER가 생성되며 각각의 크기는 1MB가 됩니다. 이리하여 각 채널별 최대 크기는 4MB가 됩니다.
– 테이프에 쓸 때, 채널 별로 총 4개의 OUTPUT BUFFER가 생성되며 각각의 크기는 256KB가 됩니다. 이리하여 각 채널별 최대 크기는 총 1MB가 됩니다.
복구시 사용되는 메모리 버퍼
– 디스크에서의 복구 시, 채널 별로 총 4개의 INPUT BUFFER가 생성되며 각각의 크기는 총 1MB가 됩니다.
– 테이프에서의 복구 시, 채널 별로 총 4개의 INPUT BUFFER가 생성되며 각각의 크기는 BLKSIZE의 크기에 맞추어 생성됩니다. 기본값은 256KB입니다.
– 복구 시의 OUTPUT BUFFER의 크기는 채널 별로 총 4개의 OUTPUT BUFFER가 생성되며 항상 128KB 크기로 생성됩니다.
RMAN 의 메모리 사용: PGA vs SGA
– 기본적으로 메모리 할당은 PGA에서 생성되게 되어 있습니다. 만약 DBWR_IO_SLAVES 나 BACKUP_TAPE_IO_SLAVE 가 설정되어 있다면 SGA의 Shared Pool에서 할당받게 됩니다. 이 때 Shared Server나 JDBC connection pooling 혹은 PARALLEL_AUTOMATIC_TUNING=TRUE의 사용으로 Large Pool이 생성되어 있다면 Shared Pool 대신 Large Pool에서 할당받게 됩니다.
– 위와 같이 Slave I/O process를 사용하여 SGA에서 할당받게 되기를 원할 경우, 채널의 개수와 각 메모리 버퍼의 총 크기에 1MB의 오버헤드 영역을 포함한 메모리를 미리 할당하기를 권장합니다.
– 테이프로 백업할 시 사용되어지는 Media Management Server 가 데이터베이스와 동일 머신에 설치되어 있다면, 백업시 발생할 추가적인 시스템 자원 소모에 대해 대비하시기 바랍니다.
RECOVERY CATALOG
Recovery Catalog는 RMAN의 백업 작업에 대한 메타데이터의 저장소입니다. 쉽게 말해 컨트롤파일에서 RMAN의 백업과 복구에 관련된 정보들만을 따로 모아 생성시킨 파일과도 같습니다. 그리고 이 Recovery Catalog는 대상 데이터베이스와 ‘resync’ 명령어를 사용하여 해당 정보를 동기화할 수 있습니다. 이러한 이점 때문에 Recovery Catalog는 복수의 데이터베이스에 대한 백업 및 복구 작업을 중앙 관리하는데 편리한 이점을 가집니다. 이와 같은 Recovery Catalog의 정보 보호를 위해 직접적으로 액세스하는 것은 권장되지 않습니다. 대신 RC_* 의 뷰를 참조하여 해당 Recovery Catalog 내의 정보를 참조할 수 있습니다.
Recovery Catalog의 사용을 위해서는 먼저 대상 데이터베이스에 연결한 후, 두번째 NET 연결을 통하여 Recovery Catalog와의 세션을 생성합니다. 이 때 Recovery Catalog의 연결은 기존의 RMAN의 연결과는 달리 as sysdba의 권한을 사용하지 않습니다. 연결된 후에는 수동으로 대상 데이터베이스와 동기화를 시키거나, 백업 작업의 실행시 자동으로 동기화가 이루어 집니다.
Recovery Catalog의 사용은 필수가 아닙니다. 하지만 몇몇 RMAN만의 강력한 성능을 사용하기 위해서는 필수적으로 적용되어야 했습니다. 8i에서는 이와 같은 경우가 다수 존재하였습니다만, 9i에서는 오직 하나, 데이터베이스의 incarnation 레벨의 복구를 위해서만 필수입니다.
AUXILIARY DATABASE
Auxiliary Database란 Tablespace Point In Time Recovery 나, 복제, 혹은 Standby Database의 생성 등의 작업에 사용되어지는, 대상 데이터베이스를 액세스하여 파일을 복구하는 역할을 하는 인스턴스용 데이터베이스를 가리킵니다. 위와 같은 작업을 하는 경우 대상 데이터베이스와 Auxiliary 데이터베이스 두군데에 연결을 하게 됩니다. 이러한 경우 두 개 개별적인 데이터베이스를 대상으로 as sysdba 연결을 생성하는 것이기에 실제로는 둘다 같은 머신에서 운용되고 RMAN 또한 동일한 머신에서 운용된다손 치더라도 두 커넥션을 모두 Local로 처리할 수 없습니다. 최소 하나의 데이터베이스에 대해 패스워드 파일을 생성하고 tnsnames.ora 파일에 적절한 NET connection이 설정되어야만 합니다. 오라클 8i까지는 Auxiliary Database의 사용을 위해서는 Recovery Catalog의 사용이 필수였습니다.
호환성
이제 데이터베이스와 RMAN, 그리고 Auxiliary Database 등 대표적인 독립된 객체들간의 호환성에 대해 알아보겠습니다.
– 대상 데이터베이스와 RMAN 실행파일은 서로 동일한 버전이어야 합니다.
– Recovery Catalog의 사용 시, Recovery Catalog의 버전보다 낮은 버전의 데이터베이스가 포함될 수는 있지만, Recovery Catalog 보다 높은 버전의 데이터베이스를 대상으로 할 수는 없습니다. 9.2버전의 Recovery Catalog인 경우, 8.0.4 버전의 데이터베이스까지 대상으로 포함시킬 수 있습니다.
– Auxiliary Database의 사용 시, 데이터베이스의 복제를 위해서는 서로 동일한 버전이어야 합니다.