2장. SGA — 공유 메모리 구조

모든 세션이 함께 쓰는 커다란 작업대, SGA. 디스크를 대신하는 Buffer Cache와 "같은 SQL은 두 번 준비하지 않는" Shared Pool — Oracle 성능의 8할이 이 방에서 결정됩니다.

2.1 SGA — 인스턴스의 심장인 공유 메모리

SGA(System Global Area)는 인스턴스가 기동될 때 할당되는 큰 공유 메모리 영역입니다. "System"이라는 이름처럼 모든 서버 프로세스와 백그라운드 프로세스가 함께 읽고 씁니다. 반대로 각 프로세스의 사적 메모리는 PGA(3장)입니다.

SGA는 용도별 구성 요소(component)로 나뉩니다. 이 장의 지도를 먼저 보세요.

2.2 Database Buffer Cache — 디스크를 안 읽는 기술

버퍼 캐시는 데이터파일의 DB block(기본 크기 8KB, DB_BLOCK_SIZE 파라미터)을 그대로 담는 메모리 버퍼들의 모음입니다. 서버 프로세스는 어떤 블록이 필요하면 무조건 버퍼 캐시부터 찾습니다. 있으면 cache hit(메모리 속도), 없으면 cache miss(디스크에서 읽어 캐시에 적재)입니다.

캐시는 유한하므로 자리가 없으면 누군가를 내보내야 합니다. Oracle은 LRU(Least Recently Used) 기반 알고리즘으로 "가장 오랫동안 사용되지 않은" 버퍼를 밀어냅니다. 자주 쓰는 블록일수록 캐시에 오래 살아남는 구조입니다.

Dirty Buffer — 고친 블록은 누가 디스크에 쓰나

UPDATE가 실행되면 서버 프로세스는 버퍼 캐시 안의 블록을 직접 수정합니다. 이렇게 메모리 내용과 디스크 내용이 달라진 버퍼를 dirty buffer라고 합니다. 중요한 것은 — 수정한 서버 프로세스가 디스크에 쓰지 않는다는 점입니다. 쓰기는 백그라운드 프로세스 DBWn(Database Writer)이 나중에 모아서 처리합니다.

2.3 Shared Pool — 같은 SQL은 두 번 준비하지 않는다

SQL 한 문장을 실행하려면 문법 검사, 의미 검사(테이블·컬럼 존재 확인), 그리고 옵티마이저의 실행계획 수립이라는 준비 작업(파싱)이 필요합니다. 특히 실행계획 수립은 CPU를 많이 쓰는 비싼 작업입니다. Shared Pool은 이 준비 결과물을 저장해 모든 세션이 재사용하게 하는 공간입니다.

• Library Cache — 파싱된 SQL 문장(shared SQL area, 흔히 "커서")과 실행계획, PL/SQL 코드를 보관합니다. SQL 텍스트의 해시값으로 찾습니다.
• Data Dictionary Cache — 테이블 정의, 컬럼, 권한 같은 딕셔너리 정보를 행 단위로 캐싱합니다(row cache라고도 부릅니다). 파싱할 때마다 딕셔너리를 디스크에서 읽지 않기 위해서입니다.

여기서 Oracle 튜닝의 최중요 개념이 나옵니다 — 하드 파싱 vs 소프트 파싱.

커서가 공유되려면 SQL 텍스트가 완전히 같아야 합니다. 그래서 값을 문장에 직접 박아 넣으면(리터럴) 매번 다른 SQL로 취급되어 전부 하드 파싱이 됩니다. 해결책이 바인드 변수입니다.

-- ❌ 리터럴 SQL: 세 문장 모두 다른 해시 → 하드 파싱 3번, 커서 3개
SELECT * FROM orders WHERE id = 101;
SELECT * FROM orders WHERE id = 102;
SELECT * FROM orders WHERE id = 103;

-- ✅ 바인드 변수: 텍스트가 동일 → 하드 파싱 1번 + 소프트 파싱 2번, 커서 1개
SELECT * FROM orders WHERE id = :order_id;

2.4 Redo Log Buffer — 변경 기록의 대기실

데이터를 변경하면 "무엇을 어떻게 바꿨는지"의 기록인 redo entry가 만들어집니다. 이 기록이 디스크의 리두 로그 파일로 가기 전에 잠시 머무는 곳이 Redo Log Buffer입니다. 서버 프로세스가 redo entry를 버퍼에 쌓으면, 백그라운드 프로세스 LGWR(Log Writer)이 커밋 시점 등에 디스크로 내려씁니다.

버퍼 캐시(수백 MB~수십 GB)에 비해 Redo Log Buffer는 보통 수 MB~수십 MB로 작습니다. LGWR이 부지런히 비워주기 때문에 클 필요가 없습니다. "커밋 = LGWR의 redo 기록"이라는 Oracle 내구성의 핵심 드라마는 4장에서 애니메이션으로 봅니다.

2.5 Large Pool과 Java Pool — 특수 목적 공간

2.6 SGA 자동 관리 — SGA_TARGET과 ASMM

옛날에는 버퍼 캐시 얼마, Shared Pool 얼마… 하고 DBA가 일일이 정했지만, 지금은 ASMM(Automatic Shared Memory Management)이 표준입니다. SGA_TARGET으로 SGA 전체 크기만 정해주면, Oracle이 워크로드를 관찰하며 구성 요소 간 크기를 자동으로 재분배합니다. 파싱이 많아지면 Shared Pool을 키우고, 스캔이 많아지면 버퍼 캐시를 키우는 식입니다.

-- SGA 관련 파라미터 확인
SHOW PARAMETER sga_target;

NAME        TYPE         VALUE
----------- ------------ ------
sga_target  big integer  8G

-- 구성 요소별 현재 크기 보기
SELECT name, bytes/1024/1024 AS mb FROM v$sgainfo ORDER BY bytes DESC;

NAME                        MB
--------------------------  ------
Buffer Cache Size            5632
Shared Pool Size             1792
Large Pool Size               128
Java Pool Size                 64
Redo Buffers                   16  ← 확인용 예시 값

✍️ 이해도 체크