RMAN

간략한 개요

Oracle Database 11g의 RMAN은 데이터베이스 복구에 관련한 조언, 동일한 파일의 병렬 백업, 보안을 위한 가상 카탈로그와 같은 유용한 신기능을 제공합니다.

Data Recovery Advisor

아래와 같은 에러가 발생한 경우를 가정해 봅시다.

어딘지 눈에 익어 보이지 않습니까 여러분의 DBA 경험이 그리 길지 않더라도 이 메시지는 최소한 한 번 이상은 경험해 보았을 것입니다. 이 에러는 문제가 되는 데이터파일이 존재하지 않기 때문에 발생한 것입니다. 데이터파일은 손상되었을 수도 있고, 데이터베이스의 실행이 중단된 동안 누군가에 의해 삭제되었을 수도 있습니다. 어떤 경우든지, 더 심각한 상황으로 발전하기 전에 예방 조치를 취할 필요가 있을 것입니다.

Oracle Database 11g에 새로이 구현된 Data Recovery Advisor를 이용하면 이 작업을 훨씬 쉽게 수행할 수 있습니다. Data Recovery Advisor는 커맨드 라인 모드 또는 Oracle Enterprise Manager Database Control을 통해 사용이 가능합니다. 두 가지 인터페이스는 상황에 따라 나름의 장점을 제공합니다. 한 예로, 커맨드 라인 모드는 쉘 스크립트 또는 cron과 같은 스케줄 유틸리티를 이용하여 자동화된 파일 확인 작업을 수행하고자 할 때 유용합니다. OEM 스크린은 작업 절차에 익숙지 않은 DBA 입문자에게 유용할 것입니다. 여기에서는 두 가지 방법을 모두 설명하기로 하겠습니다.

커맨드 라인 옵션

커맨드 라인 옵션은 RMAN을 통해 실행됩니다. 먼저, RMAN 프로세스를 시작하고 타겟에 연결합니다.

이제 에러가 발생했다고 가정합시다. 문제가 무엇인지 파악해야 할 것입니다. list failure 커맨드를 이용하면 바로 문제를 확인할 수 있습니다.

에러가 발생하지 않았다면 아래와 같이 메시지가 표시됩니다.

에러가 발생했다면, 좀 더 상세한 메시지가 표시됩니다.

위 메시지를 통해 데이터파일 중 일부가 존재하지 않음을 알 수 있습니다. 이 데이터파일은 SYSTEM 이외의 다른 테이블스페이스에 포함되어 있습니다. 에러는 매우 심각한 수준이며 다라서 Priority가 HIGH로 설정되어 있습니다. 각각의 장애에는 Failure ID가 할당됩니다. 이 정보를 이용해서 개별 장애 사안들을 쉽게 확인할 수 있습니다. 예를 들어, Failure 142의 상세 정보를 얻기 위해 아래 커맨드를 실행하는 것이 가능합니다.

RMAN> list failure 142 detail;

이 커맨드를 통해 에러의 정확한 이유를 확인할 수 있습니다.

이제 좀 더 재미 있는 부분을 설명할 차례입니다. 이 문제를 어떻게 해결할까요 숙련된 DBA라면 바로 조치가 가능하겠지만, 초심자 DBA(아니면 피곤에 절은 숙련된 DBA)라면 작업 과정을 안내하는 가이드가 제공된다면 많은 도움이 될 것입니다. 이런 경우에 활용되는 것이 Data Recovery Advisor입니다:

Data Recovery Advisor는 에러의 상세한 설명과 그 해결 방법을 제시합니다:

위 출력 결과는 몇 가지 중요한 부분으로 나뉘어집니다. 먼저, 어드바이저가 에러를 분석합니다. 이번 경우는 그 원인이 명백합니다. 데이터파일이 존재하지 않습니다. 다음으로, 어드바이저가 전략을 제시합니다. 위에서는 전략 또한 매우 간단합니다. 파일을 복구하고 복원하면 됩니다. (여기에서는 기본적인 툴 사용 방법을 설명하기 위해 아주 간단한 예제를 들고 있음을 참고하시기 바랍니다. 데이터베이스의 장애 원인과 그 복구 방법에 대한 설명은 다른 자료들을 통해 확인하실 수 있을 것입니다. 다이내믹 성능 뷰 V$IR_MANUAL_CHECKLIST 에서도 이 정보를 확인할 수 있습니다.)

하지만 Data Recovery Advisor가 제공하는 가장 중요한 정보는 마지막 부분에서 확인할 수 있습니다. Data Recovery Advisor는 데이터 파 스크립트를 생성해 줍니다. 이 스크립트는 필요한 모든 작업을 수행하므로, DBA는 단 한 줄의 코드도 작성할 필요가 없습니다.

때로는 어드바이저가 필요한 모든 정보를 갖지 못하고 있을 수도 있습니다. 위의 경우에서, 어드바이저는 누군가가 파일을 다른 위치로 옮겼는지 또는 파일 이름을 변경했는지 알지 못합니다. 이런 경우에는 (Optional Manual Actions 부분에서) 파일을 원래 위치로 이동하거나 이름을 변경할 것을 조언합니다.

이제 스크립트는 모두 준비되었습니다. 그렇다면 바로 실행해도 될까요 여러분들은 어떻게 생각하고 계실지 모르겠지만, 저라면 먼저 스크립트가 어떻게 작성되어 있는지 확인해 볼 것입니다. 복구 작업을 위해 실행되는 내역의 "미리 보기(preview)"를 위해 아래와 같이 커맨드를 실행합니다:

별다른 문제가 없다면 YES를 입력하고 실행을 승인합니다:

복구 작업을 시도하기 전에 RMAN이 프롬프트를 제시하고 있음을 주목하시기 바랍니다. 스크립트를 이용하는 경우에는 프롬프트가 뜨는 것이 바람직하지 않을 수 있습니다. 프롬프트가 뜨는 것을 원하지 않는다면 RMAN 프롬프트에서 repair failure noprompt 옵션을 사용합니다.

사전예방적 상태 점검

데이터베이스에 아무런 문제가 없고 배드 블록이 존재하지 않는다는 것을 퇴근 전에 미리 확인할 수 있다면 여러분들도 발 뻗고 잠을 잘 수 있을 것입니다. 그 방법이 있을까요 배드 블록은 실제로 접근되는 경우에만 확인이 가능합니다. 따라서 사용자들이 에러를 경험하기 전에 이를 미리 확인하고 복구할 수 있다면 좋을 것입니다.

이를 위해 dbverify 툴을 이용할 수 있지만 전체 데이터파일들의 목록과 많은 매개변수를 포함하는 스크립트를 작성해야 하기 때문에 다소 불편할 수 있습니다. 또 출력 결과도 매우 복잡해서 한참을 들여다 보아야 합니다. Oracle Database 11g에서 RMAN에 새로 추가된 VALIDATE DATABASE 커맨드를 이용하면 물리적으로 손상된 데이터베이스 블록을 쉽게 확인할 수 있습니다. 손상된 블록이 감지되는 경우, 그 정보는 Automatic Diagnostic Repository에 저장됩니다. RMAN에서 출력되는 결과의 일부가 아래와 같습니다.

문제가 감지되는 경우 아래와 같은 결과를 확인할 수 있습니다:

특정 테이블스페이스를 지정해서 검증 작업을 수행할 수도 있습니다:

또는 데이터파일을 지정하는 것도 가능합니다:

심지어 데이터파일을 특정 블록을 지정할 수도 있습니다:

VALIDATE 커맨드의 적용 범위는 데이터파일로만 한정되지 않으며, spfile, controlfilecopy, 복구 파일, Flash Recovery Area 등에도 적용이 가능합니다.

Enterprise Manager 인터페이스

Enterprise Manager에서 장애를 감지하고 해결하는 방법에 대해 알아 보기로 합시다.

먼저 Database 홈페이지로 이동합니다. 아래는 표시되는 화면의 윗부분을 보여 주고 있습니다.

Alerts 섹션이 있는 곳으로 스크롤합니다

경고 중 하나의 심각도 수준이 "critical"로 분류되어 붉은색 X 마크가 표시되어 있습니다. 또 이 경고가 데이터 장애와 관련되어 있음이 표시되고 있습니다. 이 장애는 데이터 무결성 점검 작업을 통해 발견되었습니다. Message 컬럼의 하이퍼링크를 클릭하면 아래와 같은 상세 정보를 확인할 수 있습니다.

이제 Database 홈페이지로 돌아가 Software and Support 탭을 클릭합니다. 그러면 아래와 같은 화면이 표시됩니다.

Support Workbench를 클릭합니다은 작은 메뉴를 확인할 수 있습니다.

Checker Findings를 클릭하면 보다 자세한 정보를 확인할 수 있습니다.

Host Credentials 필드에 oracle 사용자의 유저네임과 패스워드를 입력합니다. 그런 다음 Advise 버튼을 누릅니다. Advise 화면이 아래와 같이 표시됩니다.

오라클 데이터베이스는 누군가가 이 파일을 실수로 이동했을 것이라고 추정하고 있습니다. 그게 정말 원인이라면 파일을 수작업으로 다시 이동한 다음 Re-assess Failure를 누릅니다. 이것으로 문제가 해결될 것입니다. 해결되지 않았다면 Continue 버튼을 누릅니다. 아래와 같은 화면을 통해 다시 조언이 제공될 것입니다.

Data Recovery Advisor는 데이터파일을 복구할 것을 권고 하고 있습니다. 이 경우에는 두 번째 조언이 더 적절해 보입니다. Continue를 누릅니다.

Submit Recovery Job 눌러 RMAN을 이용한 복구 프로세스를 시작할 수 있습니다. 이 모든 작업을 단 한 줄의 RMAN 커맨드도 작성하지 않고 완료하였습니다. 장애 복구를 위해 RMAN 사용 방법을 알고 있을 필요도 없습니다.

RMAN의 GUI 인터페이스

RMAN이 개발된 지도 매우 오랜 시간이 지났습니다. 하지만 많은 사용자들이 RMAN이 복잡하고 언어를 배우기 어렵다는 이유로 사용을 꺼리고 있습니다. 그럼에도 불구하고 어떤 경우에는 RMAN이 작업의 유일한 대안(또는 최선의 툴)이 되는 경우도 있습니다. 매우 큰 데이터파일의 블록 중 하나 또는 두 개만이 손상된 경우를 가정해 봅시다. 전체 데이터파일을 복구할 필요는 없습니다. 블록 미디어 복구 작업을 수행해서 손상된 블록만 복구하면 됩니다. 하지만 RMAN을 사용하고 있지 않다면 이렇게 요긴한 기능을 활용할 수 없을 것입니다.

그렇다면, RMAN 언어를 전혀 배울 필요가 없다면 어떻게 하시겠습니까 이제 사용자들은 GUI를 통해 RMAN의 모든 기능을 이용할 수 있게 되었습니다. 이번 섹션에서는 Enterprise Manager의 RMAN 인터페이스를 이용하여 손상된 블록을 복구하는 방법에 대해 알아보기로 하겠습니다.

Database 홈페이지에서 Availability 탭을 클릭합니다:

Perform Recovery를 클릭하면 메인 복구 페이지가 표시됩니다.

화면을 주의 깊게 살펴 보시기 바랍니다. 몇 가지 장애가 보고되고 있습니다. "Critical"로 분류되는 에러는 감지되지 않았지만 (붉은 색 화살표로 표시된) "High Severity" 에러가 하나 있습니다. 링크를 클릭하면 에러에 대한 자세한 정보를 확인할 수 있습니다.

이 경우에는 Data Recovery Advisor를 사용하지 않고 "User Directed Recovery"를 수행하고 원하는 복구 절차를 선택하기로 합니다. User Directed Recovery 섹션의 드롭다운 메뉴를 이용하면 복구 범위를 선택할 수 있습니다(디폴트는 'Whole Database'입니다). 이 섹션을 좀 더 자세히 살펴 보겠습니다.

begin

위에서는 다양한 복구 옵션이 제시되고 있습니다. 예제에서는 블록 미디어 복구가 필요하므로 Block Recovery 라디오 버튼을 선택합니다. 그 결과로 표시되는 화면이 아래와 같습니다.

여기서 표시되는 옵션에 주목하시기 바랍니다. 블록이 손상되면, 데이터 무결성 점검을 통해 손상된 블록이 "corruption list"에 등록됩니다. 이 방법을 이용하여 복구가 필요한 블록이 무엇인지 확인할 수 있습니다. 물론 원한다면, 두 가지 방법 중 하나를 선택하여 복구할 블록 리스트를 직접 선택할 수도 있습니다. 어떤 블록이 손상되었는지 알고 있다면 블록 미디어 복구를 시도하고, 그렇지 않다면 오라클 데이터베이스가 권고하는 다른 복구 방법을 시도하는 것이 바람직합니다.

아래 화면은 데이터베이스에 의해 확인된 손상된 블록의 목록을 보여 주고 있습니다. Next를 클릭합니다.

Submit 버튼을 누르면 아래와 같이 복구 창이 표시됩니다.

위 화면은 실제 실행되는 RMAN 커맨드를 보 바로 실행할 수 있습니다. 창에 표시되는 내용에 주목하시기 바랍니다. 이것은 실제 RMAN 커맨드이므로 복사하여 RMAN 프롬프트에 붙여 넣은 후 실행하는 것도 가능합니다.

Enterprise Manager의 RMAN 인터페이스는 RMAN의 강력한 기능과 GUI의 단순화된 환경이라는 두 가지 이점을 동시에 제공합니다. 고급 RMAN 사용자들에게는 이 기능이 별로 유용하지 않을 수도 있습니다. 하지만 단순화된 인터페이스를 통해 복잡한 블록 미디어 복구 작업을 비교적 쉽게 수행할 수 있다는 점에서 초심자들에게는 구원의 빛이 될 수도 있습니다.

Flashback Log를 이용한 복구

Oracle Database 10g에서 처음 소개되었던 Flashback Logging 기능을 기억하십니까 Flashback Logging은 변경된 블록의 이전 이미지에 대한 최적화된 버전을 Flashback Recovery Area에 생성된 플래시백 로그에 기록합니다(그 이전에 데이터베이스에 Flashback이 활성화되어 있어야 합니다). 이 로그를 이용하면 백업본으로부터 포인트-인-타임 복구를 시도하지 않고도 과거의 특정 시점으로 데이터베이스를 신속하게 되돌릴 수 있습니다.

플래시백 로그가 블록의 과거 이미지를 저장하고 있다면 복구 작업에서도 활용될 수 있지 않을까요 Oracle Database 11g이 바로 이러한 기능을 지원합니다. 특정 블록을 복구하는 과정에서, 오라클은 (데이터파일 대신) 플래시를 아카이브 로그에 적용하여 롤 포워드 작업을 수행합니다. 이 방법을 이용하면 백업본을 참조하지 않고 많은 시간을 절약할 수 있습니다. 특히 백업이 테이프에 저장되어 있는 경우라면 더욱 유용할 것입니다.

ZLIB 압축

RMAN은 Oracle Database 10g의 백업본을 압축하여 네트워크 대역폭을 절감할 수 있는 기능을 제공합니다. 하지만 많은 사용자들은 이 기능이 느리다는 이유로 사용을 꺼리고 있습니다. 그 이유가 무엇일까요 써드 파티 압축 유틸리티를 이용하면 RMAN 압축보다 훨씬 빨리 작업을 완료할 수 있기 때문입니다. 하지만 RMAN 10g의 압축 기능은 써드 파티 툴이 제공하지 않는 몇 가지 유용한 장점을 포함하고 있습니다. 그 한 예로, RMAN 10g에서 데이터파일을 복구할 때 파일의 압축을 먼저 풀어 놓을 필요가 없다는 점을 들 수 있습니다. 따라서 복구 과정에서 많은 대acle Database 11g의 RMAN에는 기존에 제공되던 BZIP2 알고리즘에 더하여, 새로운 압축 알고리즘인 ZLIB이 추가되었습니다. ZLIB은 압축 속도가 훨씬 빠르지만 압축률은 낮은 편입니다. 또 한편으로 CPU를 많이 사용하지 않는다는 장점이 있습니다. 따라서 CPU 자원이 부족한 경우라면 ZLIB 압축이 매우 유용하게 활용될 것입니다. (BZIP2는 버전 11.1에서 기본적으로 제공됩니다. ZLIB을 사용하기 위해 Advanced Compression Option 라이센스를 별도로 구매할 필요가 없습니다.)

ZLIB 압축을 이용하려면, RMAN 매개변수만 설정하면 됩니다.

BZIP2로 변경하려면 아래와 같이 설정합니다.

이제 모든 압축 백업에서 새로운 알고리즘을 사용할 것입니다.

동일한 데이터 파일의 병렬 백업

두 개 이상의 채널을 선언하고 각 채널을 별도의 RMAN 세션으로 활용하는 방법으로 병렬 백업을 수행할 수 있다는 사실은 이미 알고 계실 것입니다. 하지만, 각각의 채널을 통해 한 번에 하나의 데이터파일만을 백업할 수 있다는 점을 모르는 분들이 많습니다. 결국 채널을 여러 개 사용한다 하더라도 각각의 데이터파일은 하나의 채널로만 백업됩니다. 이를 진정한 의미의 병렬 백업이라 보기는 어려울 것입니다.

Oracle Database 11g RMAN은 채널에서 데이터파일들을 "섹션(section)"이라는 단위로 분류할 수 있는 기능을 새로 제공합니다. 각 섹션의 사이즈는 개별적으로 설정이 가능합니다. 그 예가 아래와 같습니다:

위의 RMAN 커맨드에서는 두 개의 채널을 할당하고 두 채널을 통해 사용자의 테이블스페이스를 병렬적으로 백업하고 있습니다. 각각의 채널은 데이터파일을 500MB 단위를 담당합니다. 이와 같은 방법으로 대용량 파일을 훨씬 빠르게 백업할 수 있습니다.이러한 방법으로 백업을 하면 백업본도 섹션 단위로 표시됩니다.

위에서 백업본이 여러 섹션의 파일들로 표시되고 있음을 확인할 수 있습니다. 각각의 섹션을 다른 채널에 할당할 수 있는 것처럼, 다른 마운트 포인트(예: /backup1과 /backup2)로 지정하는 것도 가능합니다. 또 여러 개의 테이프에 병렬로 백업할 수도 있습니다.

하지만 여러 개의 섹션으로 나뉘어진 파일이 하나의 디스크에만 저장된다면, 병렬 백업을 이용하는 의미가 없습니다. 디스크 헤드는 파일의 여러 섹션들을 동시에 저장하기 위해 계속적으로 움직여야 하며, 결국 섹셔닝 테크닉의 이점이 상쇄되어 버릴 것입니다.

커밋된 언두 데이터의 백업 과연 필요한가

언두(undo) 데이터입니다. 트랜잭션이 특정 블록을 변경하면, 블록의 이전 이미지가 언두 세그먼트에 저장됩니다. 데이터는 트랜잭션이 커밋된 이후에도 보존됩니다. 블록이 변경되지 전에 시작된 롱 러닝 쿼리(long running query)가 실행 취소되는 경우 블록의 현재 이미지가 아닌 (커밋 되기 이전의) 과거 이미지를 가져와야 하기 때문입니다. 따라서 언두 데이터는 커밋이 완료된 이후에도 언두 세그먼트에 보존됩니다. 언두 세그먼트의 데이터는 새로 입력되는 언두 데이터의 공간이 필요한 경우 삭제됩니다.

RMAN은 백업 작업을 실행하면서 언두 테이블스페이스의 데이터도 함께 백업합니다. 하지만 복구 과정에서 커밋된 트랜잭션과 관련된 언두 데이터는 전혀 필요하지 않습니다. 이 정보는 이미 리두 로그 스트림 또는 (더티 블록이 버퍼에서 삭제되고 디스크에 온전하게 기록된 경우) 데이터파일에 존재하므로 따로 언두 데이터를 활용하지 않아도 됩니다. 그렇다면 커밋된 언두 데이터를 굳이 백업할 필요가 없지 않을까요

Oracle Database 11g의 RMAN은 좀 더 스마트한 방법으로 백업을 수행합니다. 복구 과정에서 필요하지 않은 커밋된 언두 데이터는 백업되지 않습니다. 물론 복구에 필요한 커밋되지 않은 언두 데이터는 이전과 마찬가지로 백업됩니다. 이와 같은 방법으로 백업본의 크기와 백업/복구 작업 시간을 줄일 수 있습니다.

트랜잭션이 잦은 주기로 커밋 되고 언두 데이터가 언두 세그먼트에 비교적 오랫동안 보존되는 OLTP 환경에서, 대부분의 언두 데이터는 이미 커밋 처리된 것들입니다. 따라서 RMAN이 언두 테이블스페이스에서 백업해야 하는 블록의 수는 얼마 되지 않습니다.더 좋은 것은 이 작업을 위해 사용자가 설정해 줄 것이 아무것도 없다는 것입니다. 오라클이 모든 것을 알아서 처리합니다.

Virtual Private Catalog

대부분의 DBA들이 RMAN 리포지토리를 위해 카탈로그 데이터베이스를 사용하고 있습니다. (카탈로그 데이터베이스를 사용하지 않고 있다면, 다시 한 번 심각하게 고려해 보시기 바랍니다.) 카탈로그 데이터베이스는 리포팅, (컨트여러 가지 이점을 제공합니다.

이제 새로운 질문을 던져 보겠습니다. 카탈로그의 수는 몇 개가 적당할까요 일반적으로 전체 데이터베이스의 리포지토리로 단 하나의 카탈로그 데이터베이스를 관리하는 것이 좋습니다. 하지만 보안 측면에서 이는 그리 좋은 방법으로 볼 수 없습니다. 카탈로그의 소유자가 전체 데이터베이스의 모든 리포지토리를 조회할 수 있기 때문입니다. 백업되는 각각의 데이터베이스가 별도의 DBA에 의해 운영되고 있는 환경에서, 카탈로그를 이처럼 공개한다는 것은 용인할 수 없습니다.

그렇다면 대안은 무엇일까요 물론 각각의 타겟 데이터베이스를 위해 별도의 카탈로그 데이터베이스를 생지 못합니다. 또 다른 대안은 카탈로그를 위해 하나의 데이터베이스를 생성하고 각각의 타겟 데이터베이스별로 가상 카탈로그를 생성하는 것입니다. 가상 카탈로그(virtual catalog)는 Oracle Database 11g에서 새로이 제공되는 기능입니다. 가상 카탈로그의 생성 방법을 알아 보기로 합시다.

먼저, 전체 타겟 데이터베이스를 포함하는 베이스 카탈로그를 생성합니다. 카탈로그의 소유자는 "RMAN"입니다. 타겟 데이터베이스에서 베이스 유저로 카탈로그 데이터베이스에 연결하고 카탈로그를 생성합니다.

이렇게 생성된 데이터를 베이스 카탈로그(base catalog)라 부르며 "RMAN' 사용자가 카탈로그를 소유합니다. 이제 가상 카탈로그를 소유할 두 명의 사용자를 추가로 생성합니다. 예제의 단순화를 위해, 여기에서는 사용자가 타겟 데이터베이스와 동일한 이름을 갖는 것으로 가정하겠습니다. 베이스 카탈로그 소유자(RMAN)으로 연결된 상태에서 아래 명령을 실행합니다:

이제 가상 카탈로그 소유자(odel11)로 로그인한 후 create virtual catalog 구문을 실행합니다.

다음으로, 동일한 RMAN 리포지토리에 다른 데이터베이스(PRONE3)를 등록하고 "prone3" 사용자를 위한 가상 카탈로그를 생성합니다.

다시 베이스 카탈로그 소유자(RMAN)로 연결하여 등록된 데이터베이스를 조회합니다.

기대한 대로, 2개의 데이터베이스를 모두 확인할 수 있습니다. 다음으로, ODEL11으로 로그인하여 같은 커맨드를 실행합니다.

이번에는 하나의 데이터베이스만이 표시됩니다. 이 사용자(odel11)는었기 때문입니다. 다른 사용자(PRONE3)로 연결했을 때에도 마찬가지 결과를 확인할 수 있습니다.

가상 카탈로그는 RMAN 리포지토리에 하나의 데이터베이스를 관리하면서 개별 데이터베이스 사용자들이 자체적으로 가상 리포지토리를 관리할 수 있도록 허용합니다. 이처럼 공통 카탈로그 데이터베이스를 관리함으로써 운영을 단순화하고, 비용을 절감하고, 데이터베이스의 가용성을 높일 수 있습니다.

Merging Catalogs

여러 개의 카탈로그들을 관리하면서 발생할 수 있는 또 다른 문제가 있습니다. 하나의 베이스 카탈로그를 기반으로 가상 카탈로그를 생성하는 방법을 이용하면 여러 개의 독립적인 리포지토리들을 하나로 통합할 수 있습니다.

이 과정에서 타겟 데이터베이스를 기존의 카탈로그에서 등록 해제하고 새로운 베이스 카탈로그에 다시 등록하는 방법을 사용할 수도 있습니다. 하지만 이렇게 하면 기존 리포지토리에 저장되어 있던 유용한 정보들을 모두 잃어버리게 된다는 문제가 있습니다. 물론 컨트롤파일을 동기화하고 다시 카탈로그에 동기화할 수도 있습니다. 하지만 이렇게 하면 컨트롤파일의 크기가 너무 커져 버릴 것입니다.

Oracle Database 11g는 카탈로그의 병합을 위한 새로운 기능을 제공합니다. 실제로 이 기능은 특정 카탈로그를 다른 카탈로그로 임포트(import)하는, 다시 말해 카탈로그를 "이동"하는 방법을 사용합니다.

그 동작 방법이 아래와 같습니다. 카탈로그를 CATDB1 데이터베이스에서 CATDB2 데이터베이스로 이동하려는 경우를 가정해 봅시다. 먼저, CATDB2(타겟) 카탈로그 데이터베이스에 연결합니다.

이 데이터베이스가 이미 "RMAN" 사용자가 소유한 카탈로그를 포함하고 있다면, 다음 단계로 진행합니다. 그렇지 않다면 카탈로그를 아래와 같이 생성해 줍니다.

이제 원격 카탈로그(catdb1)으로부터 임포트 작업을 진행합니다.

위에서 여러 가지 중요한 정보들을 확인할 수 있습니다. 먼저, 타겟 데이터베이스가 기존의 카탈로그 데이터베이스에서 등록 해제 되었음을 확인할 수 있습니다. 새로운 카탈로그에서 데이터베이스 네임을 확인한 결과가 아래와 같습니다.

DB Key가 변경되었습니다. ODEL11의 DB Key는 1에서 2로 바뀌었습니다.

위 작업을 통해 카탈로그 데이터베이스에 등록된 전체 타겟 데이터베이스의 카탈로그를 임포트할 수 있습니다. 경우에 따라서는 한 두 개 정도의 데이터베이스만을 임포트하려 할 수도 있습니다. 이를 위한 명령이 아래와 같습니다.

임포트 과정에서 소스 데이터베이스의 등록을 해제하는 것을 원치 않는다면, 다시 말해 양쪽의 카탈로그 데이터베이스를 동시에 유지하고 싶다면 어떻게 해야 할까요 이럴 때에는 "no unregister" 구문을 사용할 수 있습니다:

이와 같이 하면 ODEL11 데이터베이스가 catdb1 카탈로그 데이터베이스에 등록되어 있는 상태에서 새로운 카탈로그에 다시 등록할 수 있습니다.