💡 핵심 인사이트
오라클 데이터베이스의 메모리 영역인 SGA(System Global Area)에서 가장 지능적인 역할을 하는 곳이 바로 **'공유 풀(Shared Pool)'**입니다.
똑같은 SQL을 두 번 분석(파싱)하는 삽질을 막아주는 라이브러리 캐시와, DB의 구조 정보를 기억하는 데이터 딕셔너리 캐시가 한 방에 동거하며 CPU의 과부하를 막아냅니다.

Ⅰ. 오라클 메모리 구조 (SGA의 3대장)

오라클 DB가 구동되면 OS로부터 거대한 공용 메모리 덩어리를 할당받는데 이를 **SGA(System Global Area)**라고 합니다. SGA는 수많은 접속자가 공통으로 사용하는 메모리이며, 크게 3개의 핵심 방으로 나뉩니다.

  1. 데이터 버퍼 캐시 (Data Buffer Cache): 하드 디스크에서 퍼올린 '실제 데이터(예: 회원 정보)'를 쟁여두는 가장 거대한 방.
  2. 리두 로그 버퍼 (Redo Log Buffer): 데이터가 깨질까 봐 수정 내역을 디스크에 쓰기 전에 잠시 적어두는 찰나의 임시 방.
  3. 공유 풀 (Shared Pool) ★: 실제 데이터가 아닌, 'SQL 명령어 자체'와 'DB의 스키마/권한 정보'를 저장해 두는 지능적인 뇌 영역.

Ⅱ. 공유 풀의 구성 요소 (두 개의 심장)

공유 풀 안에는 앞서 배운 두 가지 핵심 캐시가 함께 존재하며 서로 긴밀하게 협력합니다.

1. 라이브러리 캐시 (Library Cache)

  • 저장하는 것: 사용자가 던진 SQL 문장 텍스트 원본, 파스 트리(문법 구조), 그리고 옵티마이저가 며칠 밤새워 짜낸 '실행 계획(Execution Plan)'.
  • 역할 (소프트 파싱): 새로운 SQL이 들어왔을 때, 파서는 일단 이 방부터 뒤집니다. 똑같은 SQL이 예전에 실행되어 이 방에 저장되어 있다면, 옵티마이저를 깨우지 않고(하드 파싱 생략) 여기 저장된 실행 계획을 그대로 가져다 재사용합니다. 극단적인 CPU 절약 효과를 가져옵니다.

2. 데이터 딕셔너리 캐시 (Data Dictionary Cache / 로우 캐시)

  • 저장하는 것: 테이블 이름, 컬럼 속성, 사용자 권한 등 데이터베이스의 구조적 메타데이터.
  • 역할: 파서가 SQL을 검사할 때 "이 테이블 존재하는 거 맞아?"를 디스크가 아닌 이 메모리 방에서 즉시 확인하게 해 줍니다.

Ⅲ. 공유 풀의 장애와 파편화 현상 (Fragmentation)

공유 풀은 크기가 너무 작아도 문제고, 개발자가 코드를 잘못 짜도 엉망이 됩니다.

  • 바인드 변수 미사용의 참사: SELECT * FROM EMP WHERE ID = 1, WHERE ID = 2, WHERE ID = 3... 개발자가 이렇게 하드코딩으로 쿼리를 1만 개 날리면, 오라클은 이를 모두 다른 문장으로 인식합니다.
  • 그 결과, 라이브러리 캐시 공간은 쓸데없는 1회용 쓰레기 쿼리들로 꽉 차버리고 공간이 부족해집니다(파편화). 결국 진짜 중요한 쿼리의 실행 계획이 밀려나서 지워지게 되고, DB는 끊임없이 무거운 하드 파싱을 하느라 CPU 100%를 치고 장렬히 뻗어버리게 됩니다.

📢 섹션 요약 비유: SGA가 거대한 식당이라면, 버퍼 캐시는 식재료 냉장고입니다. 반면 공유 풀은 주방장의 '레시피 노트(라이브러리 캐시)'와 '단골손님 명부(딕셔너리 캐시)'가 놓인 책상입니다. 레시피 노트가 있어야 주문이 들어왔을 때 레시피를 처음부터 새로 고민하지 않고 0.1초 만에 웍질을 시작할 수 있습니다.