Oracle CDB & PDB 완전 정복 — "컨테이너 속 데이터베이스"를 제대로 이해하는 법
Oracle CDB & PDB
완전 정복
컨테이너 속 데이터베이스 — 멀티테넌트 아키텍처를 처음부터 제대로 이해하는 법
// 01왜 이런 구조가 탄생했을까? — 탄생 배경
Oracle 12c(2013년)가 나오기 전까지, 기업이 데이터베이스를 운영하는 방식은 단순했습니다.
"애플리케이션 하나 = Oracle 인스턴스 하나"
인사 시스템, 회계 시스템, 영업 시스템 — 각각 별도의 Oracle DB를 띄웠죠. 서버가 10대면 Oracle도 10개. 문제는 당연히 쏟아졌습니다.
패치 지옥
패치 하나 적용하려면 DB를 10개 다 내려야 했습니다. 점검 공지만 몇 장.
메모리 낭비
인스턴스마다 SGA 메모리·CPU를 따로 할당. 자원 낭비가 극심했습니다.
관리 지옥
DBA 한 명이 10개 DB를 각각 모니터링. 콘솔 창이 10개씩 열려 있는 게 일상.
복제 느림
개발·운영 DB를 오가며 데이터 복사하는 작업이 고통스럽게 느렸습니다.
오라클은 이 문제를 한 번에 해결하기 위해 멀티테넌트 아키텍처(Multitenant Architecture)를 설계했습니다. 핵심 아이디어는 단순합니다.
"공유할 건 공유하고, 분리할 건 분리하자"
이렇게 탄생한 것이 CDB(Container Database)와 PDB(Pluggable Database)입니다.
// 02큰 그림 먼저 — 아파트 비유로 이해하기
가장 이해하기 쉬운 비유는 아파트입니다. 한 번만 이 비유를 머릿속에 새기면 나머지 개념이 술술 풀립니다.
CDB = 아파트 건물 전체입니다. 건물에는 엘리베이터, 전기 배선, 수도관, 관리 사무소가 있죠. 이것들은 모든 세대가 공유합니다. 새 세대가 입주한다고 엘리베이터를 하나 더 만들 필요가 없습니다.
PDB = 각 세대(101호, 102호...)입니다. 안에 사는 사람은 옆집이 무슨 짓을 하는지 모릅니다. 현관문을 잠그면 완전히 독립된 공간이고, 이사를 나가면(Unplug) 다른 건물로 이사도 갈 수 있습니다(다른 CDB에 Plug-in).
// 03CDB 내부 해부 — 세 가지 고정 구성요소
CDB는 단순히 "컨테이너"라는 이름만 붙은 게 아닙니다. 내부에 세 가지 고정 구성요소가 항상 존재합니다.
① CDB$ROOT
모든 CDB에는 반드시 하나의 CDB$ROOT가 존재합니다. SYS, SYSTEM 같은 공통 유저, 공통 Data Dictionary, CDB 전체에 적용되는 파라미터가 여기에 저장됩니다. DBA는 ROOT에 접속해서 모든 PDB를 한 번에 관리할 수 있습니다. Con# = 1 고정입니다.
② PDB$SEED
새 PDB를 만들 때 오라클은 처음부터 전부 구성하지 않습니다. PDB$SEED라는 읽기 전용 템플릿을 복사해서 만듭니다. 아파트 분양 시 "기본 평면도"를 찍어내는 것과 같습니다. 덕분에 PDB 생성이 수 초~수십 초 안에 완료됩니다. Con# = 2 고정이며, 절대 수정할 수 없습니다.
③ PDB (Pluggable Database)
실제 업무 데이터가 사는 곳입니다. 각 PDB는 고유한 Con# = 3, 4, 5...를 가지며, 자신만의 Data Dictionary, 유저, 스키마, 데이터파일을 보유합니다. 같은 CDB 안에 있어도 PDB끼리는 서로의 데이터를 직접 볼 수 없습니다.
핵심 포인트: PDB가 독립적으로 보유하는 건 오직 자신의 Datafile과 Data Dictionary뿐입니다. SGA 메모리, 백그라운드 프로세스, Redo Log, Control File은 CDB 전체가 공유합니다.
// 04PDB 생애주기 — Plug, Unplug, Clone
PDB의 가장 강력한 특징은 이동성과 복제성입니다. 데이터베이스를 마치 USB처럼 뽑아서 다른 서버에 꽂을 수 있습니다.
Unplug — PDB를 내보내기
운영 중인 PDB를 닫고 XML 매니페스트 파일로 내보냅니다. 이 XML에는 PDB 구조 정보와 데이터파일 경로가 담깁니다.
이동 — XML + Datafile 복사
XML 파일과 .dbf 데이터파일을 대상 서버로 복사합니다. 이 작업이 실질적인 데이터 이동 시간의 전부입니다.
Plug-in — 다른 CDB에 연결
대상 CDB에서 CREATE PLUGGABLE DATABASE ... USING 'file.xml' 한 줄로 완료. DB 버전이 같거나 상위이면 됩니다.
Clone — 복제해서 개발환경 만들기
운영 PDB를 통째로 복제해 개발용으로 씁니다. 테스트가 끝나면 DROP PLUGGABLE DATABASE 한 줄로 깔끔하게 삭제합니다.
SQL-- ① 기존 PDB 닫기 및 Unplug
ALTER PLUGGABLE DATABASE hr_pdb CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE hr_pdb UNPLUG INTO '/backup/hr_pdb.xml';
-- ② 다른 CDB에서 Plug-in
CREATE PLUGGABLE DATABASE hr_pdb
USING '/backup/hr_pdb.xml'
COPY FILE_NAME_CONVERT = ('/old/', '/new/');
-- ③ PDB Clone (개발환경 즉시 복제)
CREATE PLUGGABLE DATABASE hr_dev
FROM hr_pdb
FILE_NAME_CONVERT = ('/prod/', '/dev/');
// 05자원은 어떻게 공유될까? — Before & After
멀티테넌트의 핵심은 "공유"입니다. 전통 방식과 나란히 비교해 보면 차이가 극명합니다.
- 인스턴스 3개 × SGA 4GB = 12GB 메모리
- 백그라운드 프로세스 3세트 = ~60개 프로세스
- Redo Log 3세트 · Control File 3개
- 패치 적용 → DB 3번 개별 점검
- 모니터링 콘솔 3개 따로 운영
- 개발 환경 복제 → 수 시간 작업
- 인스턴스 1개 × SGA 5GB = 5GB 메모리
- 백그라운드 프로세스 1세트 = ~20개 프로세스
- Redo Log 1세트 · Control File 1개 공유
- 패치 적용 → CDB 1번 점검으로 전체 적용
- 모니터링 CDB 1개로 PDB 전체 조회
- 개발 환경 복제 → Clone 한 줄, 수 분 완료
주의: CDB 인스턴스 자체가 장애를 입으면 모든 PDB가 영향을 받습니다. 단일 실패 지점(SPOF)이 생기는 구조이므로, 고가용성 환경(RAC, Data Guard)과 함께 설계하는 것이 일반적입니다.
// 06PDB 상태 관리 — OPEN / MOUNT / CLOSE
PDB는 CDB와 독립적으로 상태를 전환할 수 있습니다. CDB가 열려 있어도 특정 PDB만 내릴 수 있습니다.
SQL-- 현재 모든 PDB 상태 조회
SELECT con_id, name, open_mode FROM v$pdbs;
-- 특정 PDB 열기 / 닫기
ALTER PLUGGABLE DATABASE hr_pdb OPEN;
ALTER PLUGGABLE DATABASE hr_pdb CLOSE IMMEDIATE;
-- 모든 PDB 한 번에 열기
ALTER PLUGGABLE DATABASE ALL OPEN;
-- CDB 레벨에서 특정 PDB로 세션 전환
ALTER SESSION SET CONTAINER = hr_pdb;
// 07핵심 개념 용어 정리
| 용어 | 설명 | 아파트 비유 |
|---|---|---|
| CDB | Container Database. PDB들을 담는 그릇이자 공유 인프라 | 아파트 건물 전체 |
| PDB | Pluggable Database. 실제 업무 데이터가 사는 DB | 각 세대 (101호, 102호) |
| CDB$ROOT | CDB 공통 관리 영역. 공통 유저·파라미터 저장 | 관리 사무소 |
| PDB$SEED | 새 PDB 생성을 위한 읽기 전용 템플릿 | 표준 평면도 |
| Con# | 각 컨테이너(ROOT, SEED, PDB)의 고유 번호 | 호수 번호 |
| Unplug | PDB를 XML 매니페스트 파일로 내보내는 작업 | 이사 나가기 |
| Plug-in | XML 파일로 PDB를 다른 CDB에 붙이는 작업 | 새 건물로 이사 들어오기 |
| Clone PDB | 기존 PDB를 복제해 새 PDB를 만드는 작업 | 같은 평면 그대로 복사 |
| Common User | CDB$ROOT에 생성되어 모든 PDB에 접근 가능한 유저 | 마스터키를 가진 관리자 |
| Local User | 특정 PDB 내에서만 존재하는 유저 | 해당 세대 거주자 |
// 08자주 묻는 질문
Q. PDB끼리 데이터를 공유할 수 있나요?
기본적으로 PDB는 완전히 격리되어 있어 직접 접근이 불가합니다. DB Link를 사용하거나, CDB$ROOT에 Common User를 만들어 제한적으로 접근하는 방법이 있습니다. 격리가 멀티테넌트의 핵심 가치이므로 PDB 간 직접 접근은 설계상 의도적으로 막혀 있습니다.
Q. PDB 하나가 다운되면 다른 PDB도 영향받나요?
아닙니다. PDB는 독립적으로 OPEN / CLOSE / MOUNT 상태를 가집니다. 특정 PDB를 내리거나 장애가 나도 다른 PDB는 계속 운영됩니다. 단, CDB 인스턴스 자체가 죽으면 해당 CDB의 모든 PDB가 영향을 받습니다.
Q. 기존 Non-CDB를 CDB로 마이그레이션하려면?
DBMS_PDB.DESCRIBE 프로시저를 이용해 Non-CDB를 PDB로 전환하는 방법이 공식적으로 제공됩니다. Oracle 20c부터는 Non-CDB 아키텍처 자체가 공식 지원 종료(Desupported)되었으므로, 신규 구축은 무조건 CDB로 해야 합니다.
Q. PDB 수에 제한이 있나요?
Oracle 라이선스 에디션에 따라 다릅니다. Standard Edition은 CDB당 PDB 3개로 제한되며, Enterprise Edition은 최대 4096개(버전에 따라 상이)까지 가능합니다. 실무에서는 서버 자원(CPU·메모리·디스크 I/O)이 실질적인 제한 요소가 됩니다.
// 09정리 — 언제 이 구조가 빛을 발할까?
DB 수가 많을 때
운영하는 DB가 5개 이상이라면 관리 비용 절감 효과가 눈에 띄게 납니다. 패치 한 번, 모니터링 한 곳.
환경 분리가 잦을 때
개발·QA·스테이징 환경을 자주 만들고 버려야 하는 팀에게 Clone은 혁명적입니다.
DB 이전이 필요할 때
서버 교체, 클라우드 마이그레이션 시 Unplug/Plug-in으로 데이터파일 복사만 하면 끝납니다.
라이선스·자원 최적화
서버 1대의 Oracle 라이선스로 여러 업무 DB를 운영. SGA 공유로 메모리 사용량도 대폭 절감.
Oracle CDB/PDB 구조는 처음 접할 때 생소하지만, "아파트 건물 + 각 세대"라는 비유 하나만 머릿속에 자리 잡으면 나머지 개념들이 자연스럽게 연결됩니다. 공유할 건 공유하고, 분리할 건 분리한다 — 이 단순한 원칙이 현대 Oracle 아키텍처의 핵심입니다.
댓글
댓글 쓰기