1장. Oracle 개요 — Instance와 Database

"Oracle을 켠다"는 말은 정확히 무엇을 켜는 걸까요? 메모리와 프로세스의 묶음(Instance)과 디스크 위의 파일들(Database)을 구분하는 순간, Oracle 아키텍처의 절반이 열립니다.

1.1 Oracle Database — 40년을 버틴 상용 RDBMS의 표준

Oracle Database는 1979년 첫 상용 SQL RDBMS로 출발해, 지금도 금융·통신·제조 등 대규모 기업 시스템의 표준으로 쓰이는 데이터베이스입니다. 이 파트에서 다루는 기준 버전은 Oracle Database 19c — 장기 지원(Long Term Release)으로 실무에서 가장 널리 쓰이는 버전입니다.

Oracle을 배우는 가장 좋은 방법은 "용어의 벽"을 먼저 넘는 것입니다. SGA, PGA, 리스너, undo, redo… 낯선 단어가 쏟아지지만, 사실 대부분은 다른 DB에도 있는 개념의 Oracle식 이름입니다. 예를 들어 redo는 PostgreSQL의 WAL과, buffer cache는 shared buffers와 같은 문제를 풉니다. 학습 홈의 PostgreSQL 개념 대응표를 옆에 두고 읽으면 훨씬 빠릅니다.

그 용어의 벽에서 첫 번째이자 가장 중요한 관문이 바로 이것입니다 — Instance와 Database는 다른 것이다.

1.2 Instance vs Database — 몸과 영혼의 구분

일상 대화에서는 "오라클 DB"라고 뭉뚱그려 부르지만, Oracle 공식 문서는 두 단어를 엄격히 구분합니다.

Instance가 Database를 "열어서(open)" 서비스하는 것이 Oracle의 동작 모델입니다. 인스턴스 하나는 한 번에 데이터베이스 하나만 마운트할 수 있고, 반대로 하나의 데이터베이스를 여러 인스턴스가 동시에 여는 구성이 바로 RAC(Real Application Clusters)입니다.

Database를 이루는 세 가지 파일의 역할은 꼭 기억해 두세요.

• 데이터파일(datafile) — 테이블·인덱스의 실제 데이터가 담긴 본체. 테이블스페이스(5장)를 구성합니다.
• 컨트롤파일(control file) — 데이터베이스의 "신분증 + 목차". DB 이름, 데이터파일·리두 로그 파일의 위치, 체크포인트 정보를 담습니다. 이 파일이 없으면 인스턴스는 데이터베이스를 마운트조차 못 합니다.
• 온라인 리두 로그 파일(online redo log file) — 모든 변경의 기록. 장애 시 복구의 원천입니다(7장).

기동 단계를 눈으로 확인해 봅시다. SQL*Plus에서 관리자로 접속해 조회하면 인스턴스와 데이터베이스의 상태가 각각 따로 보입니다.

-- 인스턴스 상태 확인 (메모리+프로세스 쪽)
SELECT instance_name, status, version FROM v$instance;

INSTANCE_NAME  STATUS   VERSION
-------------- -------- -----------
orcl           OPEN     19.0.0.0.0

-- 데이터베이스 상태 확인 (파일 쪽)
SELECT name, open_mode FROM v$database;

NAME   OPEN_MODE
------ ----------
ORCL   READ WRITE

1.3 접속의 여정 — 리스너에서 서버 프로세스까지

애플리케이션이 Oracle에 접속하면 무슨 일이 일어날까요? 주인공은 두 명입니다.

• 리스너(Listener) — 데이터베이스 밖에서 기다리는 별도 프로세스. 기본 포트 1521에서 접속 요청을 받아 중개만 합니다. 건물 1층의 안내 데스크라고 생각하세요.
• 서버 프로세스(server process) — 접속이 성사되면 그 세션의 SQL을 실제로 처리하는 일꾼. 파싱, 실행, 결과 반환을 모두 이 프로세스가 합니다.

1.4 Dedicated vs Shared Server — 일꾼을 배치하는 두 가지 방식

위 애니메이션은 기본값인 dedicated server 방식입니다. 세션 하나에 서버 프로세스 하나가 1:1로 붙습니다. PostgreSQL의 backend 프로세스와 같은 모델이죠. 반면 shared server 방식에서는 소수의 공유 서버 프로세스 풀이 여러 세션의 요청을 번갈아 처리합니다. 요청은 dispatcher라는 중간 프로세스가 큐에 넣어 분배합니다.

UGA(세션 메모리)의 위치가 왜 달라지는지는 3장 PGA에서 그림으로 다시 봅니다. 지금은 "shared server에서는 아무 공유 프로세스나 내 세션을 이어받아야 하니, 세션 상태를 모두가 보는 SGA에 둘 수밖에 없다"는 논리만 기억하세요.

1.5 CDB와 PDB — 멀티테넌트 아키텍처

Oracle 12c에서 도입되어 19c에서 표준이 된 멀티테넌트(multitenant) 구조에서는, 하나의 컨테이너 데이터베이스(CDB) 안에 여러 개의 플러거블 데이터베이스(PDB)가 들어갑니다.

• CDB$ROOT — 컨테이너 전체의 메타데이터와 공통 사용자를 관리하는 루트.
• PDB$SEED — 새 PDB를 찍어내는 템플릿(읽기 전용).
• PDB들 — 애플리케이션이 실제로 접속하는 "각각 독립된 데이터베이스처럼 보이는" 단위. 통째로 떼어(unplug) 다른 CDB에 꽂을(plug) 수 있어서 pluggable입니다.

핵심 이점은 인스턴스 하나(SGA와 백그라운드 프로세스 한 벌)를 여러 PDB가 공유한다는 점입니다. DB 10개를 서버 하나에 통합할 때, 인스턴스 10개를 띄우는 대신 CDB 하나에 PDB 10개를 꽂으면 메모리와 관리 비용이 크게 줄어듭니다.

-- 지금 내가 어떤 컨테이너에 있는지, 어떤 PDB들이 있는지
SHOW con_name;

CON_NAME
--------
CDB$ROOT

SHOW pdbs;

CON_ID  CON_NAME   OPEN MODE   RESTRICTED
------  ---------  ----------  ----------
     2  PDB$SEED   READ ONLY   NO
     3  ORCLPDB1   READ WRITE  NO

-- PDB로 이동해서 작업하기
ALTER SESSION SET container = ORCLPDB1;

1.6 PostgreSQL·MySQL과 나란히 놓고 보기

같은 관계형 DB지만 설계 철학과 생태계의 위치가 다릅니다. 앞으로 각 장에서 세부 비교가 계속 나오니, 여기서는 큰 그림만 잡습니다.

✍️ 이해도 체크