💡 핵심 인사이트
데이터 딕셔너리 캐시는 데이터베이스의 메타데이터(테이블 구조, 권한 등)를 디스크가 아닌 초고속 '메모리'에 올려놓은 공간입니다.
파서(Parser)가 SQL 문법을 검사하거나 옵티마이저가 실행 계획을 짤 때마다 디스크를 읽는 병목을 막아주는 핵심 성능 보조 장치입니다.

Ⅰ. 딕셔너리 캐시의 등장 배경

사용자가 쿼리를 던질 때마다, DBMS의 파서(Parser)는 이 테이블이 존재하는지, 사용자가 읽기 권한은 있는지 확인해야 합니다(의미 분석). 이를 확인하려면 앞서 배운 '데이터 딕셔너리(시스템 카탈로그)' 테이블을 읽어야 합니다.

그런데 데이터 딕셔너리 원본은 하드 디스크(데이터 파일)에 저장되어 있습니다. 초당 수만 건의 쿼리가 들어오는데 그때마다 디스크에 있는 딕셔너리 테이블을 뒤진다면 엄청난 디스크 I/O 병목이 발생할 것입니다. 이를 해결하기 위해 **가장 자주 쓰이는 딕셔너리 정보들만 메모리(공유 풀)에 복사해 둔 공간이 바로 '데이터 딕셔너리 캐시(Data Dictionary Cache)'**입니다.

Ⅱ. 딕셔너리 캐시의 구조와 로우 캐시 (Row Cache)

오라클(Oracle) 아키텍처를 기준으로 보면, 메모리의 SGA(System Global Area) 내의 공유 풀(Shared Pool) 영역에 딕셔너리 캐시가 존재합니다.

• 로우 캐시 (Row Cache): 일반적인 데이터 버퍼 풀은 디스크의 '블록(Page)' 단위로 덩어리째 캐싱을 합니다. 하지만 딕셔너리 캐시는 메타데이터의 크기가 작고 정밀한 검색이 필요하므로, 블록 단위가 아니라 하나의 레코드(행, Row) 단위로 쪼개어 메모리에 캐싱합니다. 그래서 DBA들은 이를 '로우 캐시'라고도 부릅니다.

딕셔너리 캐시에 저장되는 주요 정보

1. 테이블 구조 정보: 테이블명, 컬럼 이름, 데이터 타입의 길이.
2. 권한 및 유저 정보: 계정명, 비밀번호 해시, 접근 권한 부여 상태.
3. 제약 조건: Primary Key, Foreign Key 등의 무결성 규칙.

Ⅲ. 라이브러리 캐시와의 비교 (공유 풀의 두 형제)

메모리(Shared Pool) 안에는 성능을 돕는 두 가지 캐시가 나란히 붙어 있습니다. 이 둘의 역할을 명확히 구분해야 합니다.

1. 데이터 딕셔너리 캐시 (Data Dictionary Cache):
   • 무엇을 캐싱하는가?: "데이터베이스의 구조 정보(메타데이터, 테이블, 권한)"
   • 누가 쓰는가?: 파서가 의미를 검증할 때, 옵티마이저가 테이블 통계 정보를 볼 때 주로 씁니다.
2. 라이브러리 캐시 (Library Cache):
   • 무엇을 캐싱하는가?: "최근에 실행됐던 SQL 문장 자체와 파스 트리, 그리고 컴파일된 '실행 계획'"
   • 누가 쓰는가?: 똑같은 SQL이 들어왔을 때 하드 파싱을 피하고 '소프트 파싱'으로 바로 넘어가기 위해 사용합니다.

이 두 캐시 공간이 부족하면 DB는 계속 하드 디스크를 긁어오거나 파싱을 새로 해야 하므로 시스템 전체에 치명적인 응답 지연(Latch Contention)이 발생하게 됩니다.

📢 섹션 요약 비유: 데이터 딕셔너리 캐시는 도서관 사서의 **'머릿속 암기력'**입니다. 매번 손님이 "해리포터 책 어디 있어요?"라고 물어볼 때마다 무거운 관리 대장(디스크)을 펴보지 않고, 너무 자주 물어보는 책들의 위치(메타데이터)는 사서가 아예 뇌(캐시)에 외워두고 0.1초 만에 대답해 주는 것입니다.