Oracle® Database 18c Enterprise Edition은 엔지니어드 시스템(Exadata)과 결합되어 다양한 신규 기능과 개선 사항을 제공합니다. 18c 릴리스는 기존 12c Release 2의 리프레시 가능한 클론(Refreshable Clone) 기능을 한층 발전시켜, 빠른 전환(Switchover) 및 장애 조치(Failover) 기능을 추가했습니다. 또한 멀티테넌트 환경에서 플러거블 데이터베이스(PDB)를 손쉽게 클론하거나 복제할 수 있는 스냅샷 캐러셀(Snapshot Carousel)도 구축할 수 있습니다.
프로덕션 환경에서는 스냅샷 캐러셀과 리프레시 가능한 클론 PDB 기능을 함께 활용하면 예기치 않은 서비스 중단 대비, 논리적 손상 문제 진단 등 다양한 데이터베이스 관리(DBA) 업무를 훨씬 효율적으로 수행할 수 있습니다. 이 글에서는 수동 전환과 자동 전환 사례를 중심으로 리프레시 가능한 클론의 실전 활용법을 살펴봅니다. 스냅샷 캐러셀 기능과 연계하면 다음과 같은 데이터베이스 건강 상태 문제를 식별하고 대응할 수 있습니다.
- 프로덕션 데이터베이스 접근 불가
- 성능 저하 문제
- Oracle 데이터베이스의 논리적 손상
본 포스트는 두 부분으로 구성된 시리즈의 1부입니다. 리프레시 가능한 클론 PDB가 무엇인지, 어떻게 동작하는지, 언제 사용해야 하는지 알아보겠습니다. 2부에서는 리프레시 가능한 클론 PDB를 실제로 생성하고, 구성하고, 유지 관리하며 삭제하는 방법을 다룹니다.
클론과 스냅샷, 궁금한 점들
이 섹션에서는 클론과 스냅샷 캐러셀에 관한 기본적인 질문들에 답변합니다.
클로닝(Cloning)이란 무엇인가?
인스턴스를 클론한다는 것은 해당 인스턴스를 백업한 뒤, 그 백업을 다른 곳에 복원하는 작업입니다. 일반적으로는 동일한 디렉터리 구조를 갖춘 다른 머신에 복원하지만, Oracle SID(System ID)와 데이터베이스 이름만 변경하면 같은 머신에도 복원할 수 있습니다. 프로덕션 인스턴스의 클론을 테스트 머신에 구성하면 init.ora 파라미터 변경이나 코드 수정 등 다양한 'What-If' 시나리오를 안전하게 검증해 볼 수 있습니다.
PDB 클로닝은 어떻게 동작하는가?
PDB 클로닝은 멀티테넌트 환경에서 PDB를 복제하는 데 사용됩니다. 로컬 또는 원격 PDB 모두에 대해, 리프레시 가능한 클론이나 스냅샷 캐러셀을 활용해 로컬 컨테이너 데이터베이스 내에 PDB 클론을 만들 수 있습니다.
원격 PDB 클로닝 시에는 다음 사항을 고려해야 합니다.
- 리프레시 가능한 클론을 사용하려면 해당 PDB에 대한 데이터베이스 링크(Database Link)가 필요하며, 클론된 데이터베이스는 비활성화 상태여야 합니다.
- 스냅샷 캐러셀을 사용하려면 먼저 스냅샷을 이용해 일반적인 PDB 클론을 생성합니다. 이후 데이터베이스 링크를 사용하거나, 언플러그 후 다른 컨테이너 데이터베이스에 플러그하는 방식으로 활용할 수 있습니다. 클론된 PDB에서 리프레시 가능한 클론을 추가로 만드는 것도 가능합니다.
PDB 스냅샷이란 무엇인가?
PDB 스냅샷은 특정 시점의 PDB 복사본입니다. CREATE PLUGGABLE DATABASE(또는 ALTER PLUGGABLE DATABASE) 명령어에 SNAPSHOT 절을 지정해 수동으로 생성하거나, EVERY 간격 절을 사용해 자동으로 생성할 수 있습니다.
PDB 스냅샷 캐러셀이란 무엇인가?
PDB 스냅샷 캐러셀은 최근 PDB 스냅샷들의 라이브러리를 유지 관리합니다. 이를 통해 특정 시점 복구(Point-in-Time Recovery)를 수행하거나 PDB를 클론할 수 있습니다.
리프레시 가능한 클론 PDB(Refreshable Clone PDB)
리프레시 가능한 클론 기능을 사용하면 최소한의 데이터 손실로 데이터베이스를 데이터 손상 및 재해로부터 보호할 수 있으며, 보호 수준은 리프레시 주기와 Redo 발생률에 따라 달라집니다. 리프레시 가능한 클론 데이터베이스는 부하가 적고 중요도가 낮은 애플리케이션을 이어서 운영할 수 있는 복제본(Replica)으로 활용할 수 있습니다. 설정된 주기에 따라 자동으로 갱신하거나, Redo 로그 적용을 통해 수동으로 갱신하도록 구성할 수 있습니다.
그림 1은 리프레시 가능한 클론 처리의 아키텍처를 보여줍니다. 주요 구성 요소와 프로세스를 나타내고, 프로덕션 데이터베이스와 리프레시 가능한 클론 데이터베이스 간의 관계를 설명합니다. 이 다이어그램은 컨테이너 데이터베이스 CDB1의 플러거블 데이터베이스 PDB1을 다른 컨테이너 데이터베이스 CDB2로 클론하는 과정을 보여주며, 그 결과 PDB1_REF_CLONE이라는 이름의 핫 클론(Hot-Clone) 버전이 생성됩니다.
그림 1
리프레시 모드(Refresh Mode) 옵션
다음 세 가지 모드로 환경을 구성하여 리프레시 모드를 변경할 수 있습니다.
MANUALAUTOMATIC(EVERY n MINUTES사용)NONE
리프레시 가능한 클론 생성 및 활용
다음 문장을 사용하면 소스 PDB를 클론하고, 해당 클론을 리프레시 가능하도록 구성할 수 있습니다. 클론 PDB를 리프레시하면 마지막 Redo 로그 적용 이후 누적된 Redo 데이터로 갱신됩니다.
CREATE PLUGGABLE DATABASE ... REFRESH MODE [ MANUAL / AUTOMATIC (using EVERY n MINUTES) / NONE ] ;다음 문장은 현재 리프레시 중이거나 비활성화된 리프레시 가능한 클론의 모드를 변경하여, 완전한 기능을 갖춘 PDB로 전환할 때 사용합니다.
ALTER PLUGGABLE DATABASE ... REFRESH MODE [ MANUAL / AUTOMATIC (using EVERY n MINUTES) / NONE ] ;성능 저하를 피하기 위해 PDB를 자주 클론하지 않으면 클론 데이터가 낡아지게 됩니다(stale). 바로 이 문제를 리프레시 가능한 클론 PDB가 해결해 줍니다. 클론 데이터가 오래되었더라도 최신 Redo를 적용해 빠르게 갱신할 수 있기 때문입니다.
일반적으로는 프로덕션 PDB의 마스터(Master) 리프레시 가능한 클론 하나를 유지하고, 개발·테스트용으로는 이 마스터에서 스냅샷 클론을 추출하는 방식을 권장합니다.
다음 문장을 사용하면 소스 PDB와 클론 PDB의 역할을 서로 뒤바꿀 수 있습니다.
ALTER PLUGGABLE DATABASE ... SWITCHOVER;이 전환 프로세스는 다음 그림과 같이 간소화할 수 있습니다.
그림 2
그림 3
이러한 전환(Switchover) 기능은 다음과 같은 상황에서 특히 유용합니다.
계획된 전환(Planned Switchover)
그림 3에서 소스 PDB인 PDB1을 호스팅하는 CDB1이 클론 PDB인 PDB1_REF_CLONE을 호스팅하는 CDB2보다 상당히 많은 부하를 겪고 있다고 가정해 보겠습니다. 더 나은 부하 분산을 위해, 클론을 새로운 소스 PDB로, 기존 소스 PDB를 새로운 클론으로 변환하여 역할을 맞바꿀 수 있습니다.
현재 프라이머리 데이터베이스에서 다음 명령을 실행하면 역할 전환이 수행됩니다.
ALTER PLUGGABLE DATABASE PDB1 REFRESH MODE EVERY 2 MINUTES FROM PDB1_REF_CLONE@DBLINK2CDB2 SWITCHOVER;명령이 완료되면 CDB2의 PDB1_REF_CLONE이 프라이머리 역할을 맡고, CDB1은 복제본을 유지하게 됩니다. 프로덕션으로 향하는 모든 연결은 새로운 프라이머리인 CDB2로 향합니다. 리프레시가 소스의 Redo 발생률을 잘 따라왔다면, 트랜잭션 손실은 최대 2분 이내로 제한됩니다.
계획되지 않은 전환(Unplanned Switchover)
소스 PDB에 계획되지 않은 장애가 발생한 경우, 클론 PDB를 새로운 소스 PDB로 전환하여 정상 운영을 재개할 수 있습니다.
반드시 현실적인 트랜잭션 볼륨으로 환경을 사전 테스트하여, 복제본을 리프레시하는 프로세스가 Redo 발생률을 충분히 따라갈 수 있는지 확인해야 합니다.
리프레시 가능한 클론 vs. Data Guard: 무엇이 다른가?
Oracle은 Data Guard와 스탠바이 데이터베이스를 통해 고가용성 기능을 도입했습니다. 리프레시 가능한 클론과 Data Guard를 구분 짓는 요소들은 다음과 같습니다.
- Data Guard는 스탠바이 데이터베이스로의 전환(Switchover)과 장애 조치(Failover)를 제공함으로써, 재해와 데이터 손상으로부터 데이터베이스를 실시간으로 보호하는 고가용성을 확보합니다. 반면 리프레시 가능한 클론 PDB 기능을 활용하면 Data Guard 스탠바이 데이터베이스를 부하 분산 용도로도 사용할 수 있습니다. 단, Data Guard는 CDB 수준에서 작동하므로 PDB 수준의 전환이나 장애 조치는 불가능합니다.
- 전환이 시작된 후 완료되기까지의 지연 시간 때문에, 단순히 리프레시 가능한 클론만 유지하는 것보다 Data Guard가 더 효과적입니다. 이 지연 구간 동안에는 역할 전환 전에 프라이머리 데이터베이스로 들어온 트랜잭션이 읽기 전용 데이터베이스에 적용되거나 동기화되지 않을 수 있으며, 결과적으로 해당 트랜잭션을 잃을 위험이 있습니다.
- Data Guard는 최대 30개의 스탠바이 데이터베이스까지만 허용하지만, 리프레시 가능한 클론은 필요한 만큼 무제한으로 생성할 수 있습니다.
리프레시 가능한 클론 PDB 기능을 고가용성 측면에서 강화하고 데이터 손실을 거의 없애려면, REMOTE_RECOVERY_FILE_DEST 파라미터를 소스 PDB의 로그 아카이브 위치로 설정하십시오.
결론
리프레시 가능한 클론 PDB 기능은 고가용성 관점에서 Data Guard의 대체재로 여겨서는 안 됩니다. 하지만 다른 서버에 복제본 데이터베이스를 유지 관리하는 용도로는 충분히 활용할 수 있습니다.
이번 포스트에서는 계획된 전환이든 예기치 않은 전환이든, 리프레시 가능한 PDB를 복제본으로 활용해 부하가 적고 중요도가 낮은 애플리케이션 운영을 이어갈 수 있는 방법을 살펴보았습니다. 전환을 고려할 때는 반드시 RTO(Recovery Time Objective, 운영 재개까지의 시간)와 RPO(Recovery Point Objective, 최소 데이터 손실 달성 등)의 관점에서 판단해야 한다는 점을 기억하시기 바랍니다.
시리즈 2부에서는 리프레시 가능한 클론 기능의 실제 구현 과정을 시연합니다.
피드백 탭을 통해 의견을 남기거나 질문을 보내주세요. 지금 바로 채팅으로 대화를 시작할 수도 있습니다. 데이터베이스에 대해 더 자세히 알아보세요.