DB Buffer Cache 내부 동작: Hash 탐색·Buffer 상태·Hot Block 진단

핵심 요약

Database Buffer Cache는 Datafile의 Oracle Block 복사본을 SGA에 보관합니다.

Block 요청
→ Data Block Address로 Buffer Cache 탐색
   ├─ Cache Hit: Memory의 Buffer 사용
   └─ Cache Miss: Datafile에서 Physical Read 후 적재

Oracle은 원하는 Block을 찾기 위해 Data Block Address를 Hash하여 Buffer Header Chain을 탐색합니다. 같은 Chain이나 같은 Block에 접근이 집중되면 latch: cache buffers chains, buffer busy waits, read by other session 같은 경합이 나타날 수 있습니다.

Data Block Address
→ Hash Bucket
→ Buffer Header Chain
→ 원하는 Buffer Header
→ Buffer의 Block Image 사용

Buffer Cache 튜닝의 핵심은 Cache 크기만 늘리는 것이 아니라 어떤 SQL이 어떤 Block을 얼마나 자주 방문하고, 같은 Block에 동시 접근이 집중되는 이유가 무엇인지 찾는 것입니다.

용량 문제
→ 재사용할 Buffer 부족·Physical Read 증가

작업량 문제
→ SQL의 과도한 Logical I/O

집중 문제
→ 같은 Block·Chain에 동시 접근

쓰기 문제
→ Dirty Buffer 생성 속도와 DBWn 처리 속도 불균형

이 이론의 범위

SQLP SQL 고급 활용 및 튜닝 → 데이터베이스 아키텍처 범위에서 Buffer Cache 구조, Current·Consistent Mode, Buffer 상태, DBWn, CBC·Buffer Busy·Free Buffer Wait와 Hot Block 진단을 다룹니다.

학습 목표

• Datafile Block과 Buffer Cache의 Buffer를 구분한다.
• Cache Hit와 Cache Miss의 처리 흐름을 설명한다.
• Data Block Address·Hash Bucket·Buffer Header Chain의 관계를 이해한다.
• Consistent Get과 Current Get을 Buffer 접근 목적과 연결한다.
• Clean·Dirty·Pinned·Current·CR 상태를 서로 다른 축으로 구분한다.
• DBWn과 Buffer Cache 교체의 관계를 설명한다.
• CBC Latch·Buffer Pin·Row Lock의 보호 대상을 구분한다.
• buffer busy waits, read by other session, free buffer waits를 구분한다.
• Hot Block을 Wait Event·File#·Block#·Object로 좁히는 방법을 적용한다.
• Cache Hit Ratio보다 Logical I/O 총량과 경합을 우선 확인한다.
• Buffer State·Access Mode·Read Mode가 서로 다른 분류 축임을 설명한다.
• Direct Path·Parallel Read가 Buffer Cache를 우회할 수 있음을 이해한다.
• Single Instance와 RAC의 Local·Global Buffer 대기를 구분한다.
• ASH·Segment Statistics는 표본·누적값이므로 구간 Delta로 해석한다.

1. Datafile Block과 Buffer의 차이

Datafile에는 영속적인 Oracle Block이 저장됩니다.

Buffer Cache에는 이 Block을 읽어 온 Memory 복사본인 Buffer가 존재합니다.

Datafile의 Block
→ Disk의 영속 데이터

Buffer Cache의 Buffer
→ SGA에 있는 Block Image

같은 Datafile Block이 여러 시점의 Image로 존재할 수 있습니다.

• Current Block
• Consistent Read Block
• RAC의 Past Image
• Recovery 중인 Block Image

따라서 “Block 하나당 Buffer 하나가 항상 존재한다”는 단순한 1:1 구조로 이해하지 않습니다.

Buffer Header는 Block Image 자체와 별도로 Buffer의 식별자·상태·Chain Link·사용 정보를 관리합니다. SQL Result Cache처럼 최종 Query Row 집합을 저장하는 구조가 아닙니다.

2. Cache Hit와 Cache Miss

Cache Hit

요청한 Block의 적절한 Image가 Buffer Cache에 있으면 Memory에서 사용합니다.

Block 요청
→ Buffer Header 탐색
→ 적절한 Buffer 발견
→ Logical I/O

Cache Miss

적절한 Block Image가 없으면 Storage에서 읽어 Buffer Cache에 적재합니다.

Block 요청
→ Buffer 없음
→ 재사용 가능한 Buffer 확보
→ Datafile Physical Read
→ Buffer Header 연결
→ Block 사용

Physical Read가 발생해도 Buffer를 찾고 사용하기 위한 Logical I/O가 함께 발생할 수 있습니다.

Physical Read
≠
Logical I/O가 발생하지 않음

반대로 모든 Physical Read가 반드시 일반 Buffer Cache에 적재되는 것도 아닙니다. 일부 Sort·Parallel Read·Direct Path Read는 Buffer Cache를 우회하거나 다른 Memory 경로를 사용할 수 있습니다.

Cache Miss Read
→ 일반적으로 Buffer Cache 적재

Direct Path Read
→ PGA 등 별도 경로 가능

따라서 physical reads 전체를 단순히 Buffer Cache Miss 수로 해석하지 않습니다.

3. Data Block Address와 Hash 탐색

Oracle은 Block을 File Number와 Block Number로 식별할 수 있습니다.

DBA
= Relative File Number + Block Number

Buffer Cache 탐색의 개념 흐름은 다음과 같습니다.

File#·Block#
→ Hash Function
→ Hash Bucket
→ Buffer Header Chain
→ Buffer Header 비교
→ 원하는 Buffer 발견

Buffer Header에는 다음과 같은 정보가 포함될 수 있습니다.

CDB·RAC 환경에서는 File#·Block#뿐 아니라 CON_ID, Instance와 Object 식별자를 함께 확인합니다. 같은 숫자만 보고 다른 Container·Instance의 Block을 혼동하지 않습니다.

• File#·Block#
• Buffer 상태
• Dirty 여부
• Pin·사용 상태
• Chain Link
• Object·Tablespace 관련 식별 정보
• RAC 전역 Cache 관련 상태

Hash Function의 목적은 전체 Buffer를 처음부터 모두 찾지 않고 후보 Chain으로 빠르게 이동하는 것입니다.

4. Cache Buffers Chains

같은 Hash Bucket에 매핑된 Buffer Header는 Chain으로 연결됩니다.

Hash Bucket
→ Header A
→ Header B
→ Header C

Process는 Chain을 탐색해 원하는 File#·Block#의 Header를 찾습니다.

CBC Latch

cache buffers chains Latch는 Buffer Cache의 Buffer List를 검색하거나 Buffer를 추가·제거하는 짧은 내부 작업을 보호합니다.

Chain 검색·Buffer Header 관리
→ CBC Latch로 공유 Memory 구조 보호

Latch는 Transaction Row Lock이 아니며 업무 Row를 COMMIT까지 보호하지 않습니다.

많은 Process가 같은 Chain이나 같은 Hot Block을 반복 탐색하면 다음 대기가 증가할 수 있습니다.

latch: cache buffers chains

CBC 경합은 Buffer Cache가 작다는 사실만으로 설명되지 않습니다. 대표 원인은 다음과 같습니다.

• 같은 Table Block에 반복 접근
• 같은 Index Leaf Block에 집중
• 비효율 SQL의 과도한 Logical I/O
• 증가 Key Index의 Rightmost Leaf
• 소수 Lookup Row 반복 접근
• Buffer Chain에 대한 높은 동시 탐색

5. Consistent Get과 Current Get

Consistent Get

Query SCN에 맞는 일관된 Block Image를 읽는 Logical I/O입니다.

일반 SELECT
→ Consistent Read
→ CR Block 사용

SQL Trace와 Statistics에서는 주로 query 또는 consistent gets와 연결됩니다.

Current Get

현재 상태의 Block을 읽어 변경하거나 현재 정보를 확인하는 Logical I/O입니다.

UPDATE·DELETE·INSERT
→ Current Block
→ 변경 수행

SQL Trace에서는 current, Statistics에서는 db block gets와 연결됩니다.

비교

DML도 대상 행을 찾는 단계에서는 Consistent Get을 수행하고 실제 변경 단계에서 Current Get을 수행할 수 있습니다.

consistent gets from cache, db block gets from cache, physical reads cache 등의 Statistics는 구간 Delta로 비교합니다. 전체 Instance 시작 후 누적값만 비교하면 문제 시간대의 변화율을 놓칠 수 있습니다.

6. Buffer 상태를 여러 축으로 구분하기

Buffer 상태는 하나의 단어로 모두 설명되지 않습니다.

내용의 기록 상태

Oracle 공식 분류의 Buffer State는 서로 배타적입니다.

Unused
→ 사용되지 않았거나 현재 비어 있어 가장 쉽게 재사용 가능

Clean
→ Checkpoint가 필요 없는 Block Image

Dirty
→ 변경됐지만 아직 Datafile에 기록되지 않아 재사용 전 Write 필요

Clean은 “현재 Datafile의 최신 Block과 항상 Byte 단위로 동일”하다는 뜻은 아닙니다. 과거 SCN의 Consistent Read Image도 변경되지 않아 Checkpoint가 불필요하면 Clean일 수 있습니다.

현재 접근 상태

Pinned
→ Session이 Buffer를 사용 중
→ Aging·다른 Block 용도 재사용 방지

Free·Unpinned
→ 현재 Pin되지 않은 상태

Buffer Read Mode

Consistent Mode
→ Query SCN에 맞는 CR Image

Current Mode
→ 현재 Block Image

따라서 다음처럼 서로 다른 축의 조합을 해석합니다.

Dirty + Pinned + Current
→ 변경 중인 Current Buffer

Clean + Pinned + Consistent
→ 읽기 중인 CR Buffer

Unused·Clean·Dirty는 내용 상태, Pinned·Free는 접근 상태, Current·Consistent는 Read Mode입니다.

7. Buffer Pin과 Row Lock의 차이

Buffer Pin

Buffer Pin은 Process가 Memory의 Buffer를 사용하는 동안 해당 Buffer가 Aging되거나 다른 Block 용도로 재사용되지 않게 합니다.

Buffer 사용 시작
→ Pin 획득
→ Row·Block 처리
→ Pin 해제

Pin은 짧은 내부 Memory 사용 보호입니다. 다른 Session이 호환되지 않는 방식으로 같은 Buffer를 Pin하고 있으면 buffer busy waits가 발생할 수 있습니다.

Row Lock

Row Lock은 Transaction이 같은 Row를 다른 Transaction이 동시에 변경하지 못하게 하는 업무 데이터 동시성 장치입니다.

UPDATE Row
→ Row Lock
→ COMMIT·ROLLBACK까지 유지 가능

CBC Latch

CBC Latch는 Hash Chain 같은 SGA 관리 구조를 짧게 보호합니다.

같은 “잠금”처럼 보여도 보호 대상과 지속 시간이 다릅니다.

8. Buffer 교체와 DBWn

Buffer Cache는 유한하므로 새 Block을 읽으려면 재사용 가능한 Buffer가 필요합니다.

새 Block Read 필요
→ Free·재사용 가능한 Buffer 탐색
→ Buffer 확보
→ Physical Read

Clean Buffer

Clean Buffer는 필요할 때 다른 Block 용도로 재사용하기 쉽습니다.

Dirty Buffer

Dirty Buffer는 Datafile에 먼저 기록해야 안전하게 재사용할 수 있습니다.

Dirty Buffer
→ Checkpoint Queue·Dirty Queue 관리
→ DBWn Write
→ Checkpoint 불필요한 상태
→ 재사용 가능

DBWn Write는 Checkpoint, Dirty Queue 압력, Free Buffer 부족 등 여러 조건으로 촉진될 수 있습니다. free buffer waits를 Cache 크기 부족 하나로만 결론내리지 않습니다.

Oracle은 단순한 하나의 LRU List만 사용하는 구조가 아니라 Touch Count와 Hot·Cold End, 여러 LRU·Checkpoint Queue를 이용해 Buffer의 재사용 가능성을 관리합니다. SQLP에서는 다음 원리를 기억합니다.

자주 재사용되는 Block
→ Cache에 남을 가능성 증가

큰 Full Scan·낮은 재사용 Block
→ Cold End 배치·Direct Path 등 Cache 오염을 줄이는 처리 가능

Free Buffer 부족
→ DBWn Write·Foreground Wait 가능

9. 대표 Buffer Cache 대기

9.1 read by other session

다른 Session이 같은 Block을 Disk에서 Buffer Cache로 읽는 중이라 현재 Session이 해당 Buffer를 Pin하지 못하고 Read 완료를 기다리는 Event입니다.

Session A
→ Block 100 Physical Read 중

Session B
→ 같은 Block 100 필요
→ 중복 Read 대신 A의 완료 대기

이 대기가 많으면 다음을 확인합니다.

• 특정 Block·Object 집중
• Storage Read Latency
• 비효율 SQL의 반복 Read
• Cache에서 계속 밀려나는 Block
• 동시 실행 시작 패턴

9.2 buffer busy waits

다른 Session이 해당 Buffer를 Pin하고 있어 현재 Session이 Buffer를 Pin할 수 없을 때 발생합니다.

대표 상황:

• 같은 Data Block 동시 Insert·Update
• Segment Header 경합
• Undo Header·Undo Block 경합
• Block Read·Write 상태 전환
• Hot Index Leaf Block

Wait Parameter의 File#·Block#·Class#를 이용해 Block 유형과 Object를 좁힙니다.

9.3 free buffer waits

Foreground가 Free Buffer를 찾지 못했거나 Dirty Queue가 가득 차 DBWn Write를 기다릴 때 발생할 수 있습니다. Read-only File 전환 후 Buffer 무효화 같은 특수 원인도 있으므로 Event 정의와 환경을 함께 확인합니다.

확인 항목:

• DBWn Datafile Write Latency
• Dirty Buffer 생성 속도
• Checkpoint 압력
• Buffer Cache 크기
• 대량 DML·Full Scan
• Datafile I/O 성능

Wait Parameter 해석

buffer busy waits와 read by other session의 대표 Parameter는 다음과 같습니다.

class#는 Object ID가 아닙니다. File#·Block# 또는 ASH의 CURRENT_OBJ#를 이용해 실제 Segment와 연결합니다.

9.4 latch: cache buffers chains

같은 Buffer Chain 탐색·변경에 Process가 집중될 때 나타날 수 있습니다.

확인 항목:

• Hot Block
• Logical I/O 상위 SQL
• 특정 Index Leaf
• V$LATCH_CHILDREN의 Child별 Gets·Misses·Sleeps 편중
• ASH의 CURRENT_FILE#, CURRENT_BLOCK#, CURRENT_OBJ#
• Object·Partition·SQL_ID

고급 진단에서 V$LATCH_CHILDREN.ADDR와 내부 Buffer Header 정보를 연결할 수 있지만, 내부 X$ 구조는 Version 의존적이므로 운영 표준과 지원 범위 안에서 사용합니다.

9.5 RAC의 Global Buffer 대기

RAC에서는 같은 Block의 최신 Image를 다른 Instance가 보유할 수 있습니다.

Single Instance
→ Local Buffer Pin·Latch·Disk Read 대기

RAC
→ Global Cache 전송·권한 변환 대기 추가

대표 Event입니다.

• gc buffer busy acquire
• gc buffer busy release
• gc current request
• gc cr request

동일 Block에 여러 Instance의 변경이 집중되면 Cache Fusion 전송과 Global Busy가 함께 증가할 수 있습니다. Instance Affinity·Service 배치·Insert Key 분산을 검토합니다.

10. Hot Block의 대표 원인

증가 Key Index

Sequence·Timestamp 증가 Key
→ 모든 Insert가 Rightmost Leaf로 집중
→ CBC·Buffer Busy·RAC gc 경합

개선 후보:

• Reverse Key Index
• Hash-Partitioned Global Index
• Partitioning
• Scalable Sequence
• Insert 분산 Key
• 서비스·Instance Affinity

Reverse Key Index는 증가 Key Insert 집중을 분산할 수 있지만 일반적인 Key Range Scan을 지원하지 않는 Trade-off가 있습니다. 범위 검색, Index 크기·유지비용과 실행계획을 함께 봅니다.

Hot Row

재고 총량 1행
→ 모든 Transaction이 같은 Row UPDATE
→ Row Lock + Buffer 접근 집중

Hot Row에서는 Buffer 경합과 함께 enq: TX - row lock contention이 나타날 수 있습니다. Buffer Wait만 보고 Row Lock을 놓치지 않습니다.

개선 후보:

• 원자적 조건부 UPDATE
• Counter Sharding
• 업무 Key별 Row 분산
• Batch Aggregation
• Lock 보유시간 단축

비효율 SQL

한 요청에서 같은 Block 수천 번 방문
→ Logical I/O 증가
→ CBC Chain 접근 증가

개선 후보:

• Join Order·Index 개선
• Scalar Subquery 반복 제거
• 불필요한 Nested Loops 반복 감소
• 집합 기반 처리
• Application Call 감소

11. File#·Block#을 Object로 매핑하기

Wait Event에서 File#와 Block#을 얻었다면 Extent 범위로 Object를 찾을 수 있습니다.

SELECT owner,
       segment_name,
       partition_name,
       segment_type,
       tablespace_name
FROM   dba_extents
WHERE  relative_fno = :file_no
AND    :block_no BETWEEN block_id
                     AND block_id + blocks - 1;

RAC·CDB·Bigfile Tablespace와 같은 환경에서는 File Identifier의 의미와 Container를 함께 확인합니다.

ASH에서 Hot Block 확인

SELECT sql_id,
       current_obj#,
       current_file#,
       current_block#,
       event,
       COUNT(*) AS samples
FROM   v$active_session_history
WHERE  sample_time >= SYSTIMESTAMP - INTERVAL '10' MINUTE
AND    event IN (
         'buffer busy waits',
         'read by other session',
         'latch: cache buffers chains'
       )
GROUP BY sql_id,
         current_obj#,
         current_file#,
         current_block#,
         event
ORDER BY samples DESC;

ASH의 CURRENT_OBJ#, CURRENT_FILE#, CURRENT_BLOCK#는 Concurrency·Cluster·User I/O 등 관련 Wait에서 제공됩니다. ASH는 초 단위 표본이므로 Sample 수를 정확한 대기 발생 횟수로 해석하지 않고 집중 Block·SQL의 경향을 찾는 데 사용합니다.

AWR·ASH 사용에는 Diagnostic Pack License 조건을 확인해야 합니다.

12. Segment별 Buffer 경합 확인

SELECT owner,
       object_name,
       subobject_name,
       object_type,
       statistic_name,
       value
FROM   v$segment_statistics
WHERE  statistic_name IN (
         'logical reads',
         'buffer busy waits',
         'gc buffer busy'
       )
AND    value > 0
ORDER BY value DESC;

지원되는 Statistic 이름은 다음 View에서 확인합니다.

SELECT name,
       sample
FROM   v$segstat_name
ORDER BY name;

V$SEGMENT_STATISTICS와 V$SEGSTAT은 Segment 수준 누적 Statistics를 제공합니다. Instance 재시작·Object 재생성 영향을 고려하고 문제 시간 구간의 Delta를 비교합니다.

logical reads가 높은 Segment가 반드시 병목 Object인 것은 아닙니다. SQL별 실행 횟수·처리 Row·대기시간과 연결합니다.

13. Cache Hit Ratio의 한계

Buffer Cache Hit Ratio는 Cache Statistics Delta로 계산하는 개념적 비율입니다.

1 - physical reads cache
    ÷ (consistent gets from cache + db block gets from cache)

분자·분모는 같은 Workload 구간의 Delta를 사용합니다.

높은 Ratio가 항상 좋은 성능을 뜻하지 않습니다.

예를 들어:

SQL A
→ 같은 Block을 1,000만 번 Memory에서 반복
→ Hit Ratio 매우 높음
→ CPU·CBC 경합·Logical I/O는 큼

SQL B
→ 대량 Report Full Scan
→ Physical Read 많음
→ 순차·Multiblock Read로 업무 완료

따라서 다음을 함께 봅니다.

• SQL별 Buffer Gets
• 실행당 Buffer Gets
• 반환·처리 Row당 Buffer Gets
• Physical Reads와 Read Latency
• DB CPU
• CBC·Buffer Busy·Free Buffer Wait
• DBWn Write Latency
• 처리 Row 수
• 업무 응답시간
• 반복 Block 방문 이유

High Hit Ratio와 Hot Block 경합은 동시에 발생할 수 있습니다. Cache 증설은 동일 Block 집중을 분산하지 못합니다.

목표
→ Hit Ratio 최대화

보다 정확한 목표
→ 필요한 결과를 최소 Block 작업과 안정적인 동시성으로 생성

14. Buffer Cache 진단 순서

1. Top Wait가 CBC·Buffer Busy·Read by Other Session인가?
2. 문제 시간대의 총 대기시간과 평균을 확인한다.
3. SQL_ID와 Object를 찾는다.
4. File#·Block#이 특정 Block에 집중되는지 본다.
5. Hot Row·Index Leaf·Segment Header·Undo 중 무엇인지 구분한다.
6. SQL의 Logical I/O와 반복 접근 원인을 분석한다.
7. Data 배치·Index·Partition·업무 동시성을 검토한다.
8. Single Instance Local Wait인지 RAC Global Cache Wait인지 구분한다.
9. Storage·DBWn·Buffer Cache 크기는 그 다음에 판단한다.
10. 변경 후 처리량·대기시간·Logical I/O·정합성을 비교한다.

15. 혼동하기 쉬운 개념 비교

16. 핵심 정리

Block 요청
→ DBA Hash
→ Buffer Header Chain
→ Buffer 탐색

Cache Hit
→ Memory Logical I/O

Cache Miss
→ Physical Read 후 Buffer 적재

Dirty Buffer
→ DBWn이 Datafile에 기록

CBC Latch
→ Hash Chain 보호

Buffer Pin
→ Buffer 사용 보호

Row Lock
→ Transaction Row 변경 보호

대기 구분
→ 다른 Session Disk Read: read by other session
→ 다른 Session Buffer Pin: buffer busy waits
→ Free Buffer 확보 실패: free buffer waits
→ Header Chain 경합: latch: cache buffers chains