Oracle RAC 구조: 다중 Instance·Cache Fusion·GCS·GES

핵심 요약

Oracle Real Application Clusters(RAC)는 하나의 Database를 여러 Database Instance가 동시에 열어 처리하는 구조입니다. 모든 Instance는 같은 Datafile·Control File·Redo Log 파일 집합에 접근하지만, Instance마다 SGA·Buffer Cache·Background Process·Redo Thread를 독립적으로 가집니다.

공유 Database Files
├─ Instance 1: SGA·Buffer Cache·Process·Redo Thread 1
├─ Instance 2: SGA·Buffer Cache·Process·Redo Thread 2
└─ Instance 3: SGA·Buffer Cache·Process·Redo Thread 3

각 Buffer Cache가 독립적이므로 같은 Data Block의 최신 상태와 전역 접근 권한을 Cluster 전체에서 조정해야 합니다. Oracle RAC는 Global Resource Directory(GRD), Global Cache Service(GCS), Global Enqueue Service(GES) 및 RAC Background Process를 이용해 이를 관리하고, 필요한 CR·Current Block Image를 Cluster Interconnect로 전달하는 Cache Fusion을 수행합니다.

Local Cache에 적합한 Block이 없음
→ 전역 Resource 상태 확인
→ Remote Instance에서 Block 또는 Grant 준비
→ Cluster Interconnect로 전달
→ 요청 목적에 맞는 CR·Current 접근 수행

RAC 성능 진단의 핵심은 gc Wait를 곧바로 Interconnect 장애라고 단정하지 않는 것입니다. SQL의 Block 방문량, Hot Object·Hot Block, Serving Instance CPU, LMS 처리량, Redo Flush, Service 배치와 Interconnect 상태를 같은 시간 구간에서 연결해야 합니다.

학습 목표

• Single Instance와 RAC의 Database·Instance 관계를 비교한다.
• RAC Instance별 독립 구성과 Cluster에서 공유하는 구성을 구분한다.
• Redo Thread와 Instance Recovery의 관계를 설명한다.
• GRD·GCS·GES와 LMS·LMD·LMON의 역할을 구분한다.
• Cache Fusion의 CR Block·Current Block 전달 목적을 설명한다.
• gc cr/current block 2-way·3-way의 의미를 정확히 해석한다.
• busy·congested·lost·gc buffer busy Event를 구분한다.
• ASH·GV$ View를 이용해 SQL·Object·Block·Remote Instance를 연결한다.
• Service·Load Balancing·FAN·Application Continuity의 역할을 구분한다.
• Hot Block과 Instance Affinity의 Trade-off를 진단한다.

1. RAC의 Database·Instance 구조

1.1 Single Instance와 RAC

Single Instance
Database 1개 ← Instance 1개

Oracle RAC
Database 1개 ← Instance 여러 개

RAC의 각 Instance는 같은 Database 파일에 접근하고 사용자 요청을 처리합니다. 그러나 여러 Instance가 하나의 SGA를 공유하는 구조는 아닙니다.

1.2 Instance마다 독립적인 구성

• SGA와 Database Buffer Cache
• Shared Pool과 Library Cache
• Foreground·Background Process
• Instance 상태와 누적 통계
• Redo Thread
• 일반적으로 해당 Instance가 사용하는 Undo Tablespace

1.3 Cluster에서 공유하는 구성

• Datafile
• Control File
• 모든 Instance의 Online Redo Log File
• Database Dictionary와 Schema Object
• Cluster에서 관리하는 SPFILE·Password File 등의 구성
• Database의 논리적 데이터

공유 Storage
→ Database Files 공유

독립 Memory
→ Instance별 SGA·Buffer Cache

따라서 RAC는 Shared Disk Database이지만 Shared Buffer Cache 구조는 아닙니다.

2. Redo Thread와 Instance Recovery

각 RAC Instance는 자신의 Redo Thread에 변경을 기록합니다.

Instance 1 → Redo Thread 1
Instance 2 → Redo Thread 2

모든 Redo Thread는 Shared Storage에 있으며 다른 Instance에서도 접근할 수 있어야 합니다. 한 Instance가 실패하면 생존 Instance가 실패 Instance의 Online Redo Log를 읽어 Instance Recovery를 수행할 수 있습니다.

Instance 장애
→ 생존 Instance가 실패 Thread의 Redo 읽음
→ 필요한 변경 Roll Forward
→ 장애 시점의 Active Transaction Rollback
→ 해당 Transaction Resource 해제

Instance Recovery가 Database 상태를 복구한다고 해서 실패 당시 Application 요청까지 자동으로 재실행되는 것은 아닙니다. Application 수준 복구에는 FAN, Transaction Guard, Application Continuity 등의 별도 구성이 필요합니다.

3. GRD·GCS·GES

3.1 Global Resource Directory

GRD는 RAC의 전역 Resource 상태를 나타내는 분산 Directory입니다. 각 Instance의 Cache Block 상태와 전역 Enqueue 정보가 모든 Active Instance에 분산되어 관리됩니다.

GRD
├─ Cache Block Resource 상태
├─ Holder·접근 Mode 정보
├─ 전역 Enqueue 정보
└─ Instance Membership 변화에 따른 재구성 정보

GRD는 하나의 중앙 Server에만 저장되는 단일 표가 아니라 Cluster Instance에 분산된 전역 상태 정보입니다.

3.2 Global Cache Service

GCS는 Buffer Cache Block에 대한 전역 접근을 조정합니다.

• Cache Block의 전역 상태 관리
• CR·Current 요청 조정
• Block·Grant 전달
• Block Mode 변환
• Cache Fusion Message 처리
• Instance 장애 후 Cache Resource 재구성

3.3 Global Enqueue Service

GES는 Cluster 전체에서 직렬화해야 하는 Enqueue와 Resource를 조정합니다.

• Global Enqueue 요청과 변환
• DDL·Library·Dictionary 관련 전역 Resource
• Distributed Deadlock Detection
• Instance Membership 변화 시 전역 Resource 재구성

시험에서는 다음과 같이 구분하되 실제 내부에서는 GCS와 GES, 여러 RAC Process가 협력한다는 점을 기억합니다.

GCS 중심
→ Buffer Cache Block 접근과 Cache Fusion

GES 중심
→ Cluster-wide Enqueue와 비 Cache Resource 직렬화

4. 주요 RAC Background Process

LMSn·LMnn

Global Cache Service Process입니다. GCS와 Buffer Cache Resource의 Lock Database를 유지하고 다음 작업을 수행합니다.

• GCS 요청 수신·처리·전송
• CR·Current Block Transfer
• Global Cache 관련 Message 처리
• Remote Instance에 Block Image 제공

LMDn

Global Enqueue Service Daemon입니다.

• Remote Global Enqueue 요청 처리
• Global Enqueue 접근 제어
• Distributed Deadlock Detection 지원

LMON

Global Enqueue Service Monitor입니다.

• RAC Instance Membership 관리
• Instance 상태 변화 탐지
• GES·GCS Resource 재구성 조정

LCK0·RMSn

• LCK0: Library·Row Cache 등 Non-Cache-Fusion Resource 요청 관리
• RMSn: Instance 추가 등 RAC Manageability 작업 수행

Process 이름만 외우기보다 어떤 Resource와 Message를 처리하는가를 기준으로 구분합니다.

5. Cache Fusion의 필요성과 기본 흐름

각 Instance의 Buffer Cache는 독립적입니다. Instance 1이 Block을 변경한 뒤 Instance 2가 같은 Block을 요청할 때 Instance 2가 Disk의 오래된 Image를 읽어서는 최신 상태와 일관성을 보장할 수 없습니다.

Instance 1
→ Block 500의 Current Image 보유

Instance 2
→ 같은 Block 조회 또는 변경 요청

Cache Fusion은 Block을 매번 Datafile에 기록한 뒤 다시 읽는 Disk Ping 방식 대신, 필요한 Block Image를 Instance Cache 사이에서 전달합니다.

1. Requester가 Local Cache에서 적합한 Image를 찾지 못함
2. 전역 Resource 정보로 Serving Instance와 상태 확인
3. Serving Instance가 Block 또는 Grant 준비
4. Cluster Interconnect로 요청 Instance에 전달
5. Requester가 CR 조회 또는 Current 접근 수행

Cache Fusion은 Disk I/O를 줄일 수 있지만 Interconnect 전송, LMS 처리, Mode 변환, Remote CPU Scheduling과 전역 직렬화 비용을 추가합니다.

6. CR Block과 Current Block

6.1 CR Block

CR Block은 Query SCN에 맞춘 Consistent Read Image입니다. 일반 SELECT가 현재보다 과거 시점의 Image를 필요로 하면 Undo를 적용해 CR Block을 만들 수 있습니다.

SELECT
→ Query SCN 결정
→ 필요한 경우 Undo 적용
→ CR Block 생성·사용

CR Block은 읽기 일관성용이며 변경 권한을 의미하지 않습니다.

6.2 Current Block

Current Block은 가장 최신 상태의 Block Image입니다. DML이나 Current Read에는 필요한 Current Mode와 전역 접근 권한이 필요합니다.

UPDATE
→ Current Block 요청
→ 전역 Mode 조정
→ 변경 가능한 권한 획득
→ Block 변경

같은 Data Block에 하나의 Current Copy와 여러 Snapshot 시점의 CR Copy가 존재할 수 있습니다.

7. 2-way·3-way Block Transfer

7.1 2-way

gc cr block 2-way와 gc current block 2-way는 요청한 Block이 다른 Instance에서 전달됐고 요청 완료까지 두 개의 Network Hop이 포함됐음을 뜻합니다.

7.2 3-way

gc cr block 3-way와 gc current block 3-way는 추가 전달 경로가 포함되어 세 개의 Network Hop으로 Block을 받았음을 뜻합니다.

2-way·3-way
→ Cache Fusion Transfer 경로의 Hop 수
→ 그 자체로 Interconnect 장애를 의미하지 않음

Oracle Cache Fusion Protocol은 Instance 수와 관계없이 요청을 세 Hop 이내에 완료하도록 설계됩니다. 3-way 비율이 높더라도 SQL 처리량과 평균 대기시간이 정상이라면 곧바로 장애라고 판단하지 않습니다.

8. Global Cache Wait Event 정밀 해석

8.1 진행 중 Request Event

• gc cr request
• gc current request

이 Event는 진행 중인 Cache Fusion 요청에 사용됩니다. 요청이 완료되면 gc cr block 2-way 같은 실제 결과 Event로 이름이 바뀝니다. 따라서 완료된 통계 중심의 AWR에는 일반적으로 나타나지 않지만, 진행 중 상태를 Sampling한 ASH에는 보일 수 있습니다.

8.2 Busy

• gc cr block busy
• gc current block busy

Serving Instance에서 요청을 잠시 보류한 경우입니다. 대표 원인은 다음과 같습니다.

• Dirty Buffer 전달 전에 필요한 Redo Flush 대기
• Remote Process가 해당 Buffer를 보유·Pin한 상태
• Serving Instance가 Block 처리를 끝내지 못한 상태

8.3 Congested

• gc cr block congested
• gc current block congested

Serving Instance에서 요청이 너무 오래 Queue에 머문 경우입니다. 많은 Cache Fusion 요청으로 LMS·LMnn Process가 바쁜 상황과 연결될 수 있습니다.

busy
→ 특정 Block을 즉시 제공할 수 없는 상태

congested
→ Serving Instance의 GCS 처리 Queue가 과도하게 밀린 상태

8.4 Lost·Direct Read

• gc cr/current block lost: Block이 손실됐을 가능성을 탐지해 자동 재시도하며 Packet Drop, Interconnect 오류, 시스템 과부하, 잘못된 Network 경로 등을 점검
• gc cr/current block direct read: RDMA를 이용해 Remote Cache에서 직접 읽은 경우

8.5 gc buffer busy acquire·release

• gc buffer busy acquire: 다른 Local Client가 Remote Cache에서 같은 Buffer를 이미 요청 중이어서 Pin하지 못함
• gc buffer busy release: Remote Instance가 이 Cache에서 Buffer를 가져가는 중이어서 Local Session이 Pin하지 못함

Event 이름은 원인 후보를 좁히는 단서이지 단독 결론이 아닙니다.

9. Hot Block과 Cross-Instance 이동

같은 Block을 여러 Instance가 번갈아 변경하면 Current Block과 접근 권한이 Cluster 사이를 반복 이동합니다.

Instance 1 UPDATE
→ Current Block이 Instance 1에 유리한 상태

Instance 2 UPDATE
→ Mode 변환·Block 전달

Instance 1 UPDATE
→ 다시 Mode 변환·Block 전달

대표 원인은 다음과 같습니다.

• 증가 Key Index의 Rightmost Leaf
• 소수 Hot Row에 대한 집중 UPDATE
• Segment Header·Bitmap Block 집중
• 작은 Lookup·Counter Table의 집중 변경
• 동일 업무를 모든 Instance에 무작위 분산
• SQL이 같은 Block을 과도하게 반복 방문

개선 후보는 다음과 같습니다.

• 업무 Key와 일치하는 Service 배치
• Hot Row·Counter 업무 분할
• Reverse Key 또는 Hash-Partitioned Global Index 검토
• Table·Index Partitioning
• SQL의 불필요한 Block 접근 감소
• Batch·Commit 단위 조정

Service Affinity는 가용성을 포기하고 하나의 Instance에 영구 고정하는 의미가 아닙니다. 정상 상태의 Block 이동을 줄이면서 장애 시 다른 Instance로 Service를 이동할 수 있도록 설계해야 합니다.

10. Service·Load Balancing·FAN

RAC Application은 물리 Instance 이름이 아니라 업무 Service를 접속·모니터링·Failover 단위로 사용합니다.

ORDER_OLTP
→ OLTP Workload를 제공하는 Instance 집합

REPORT_BATCH
→ Reporting·Batch용 Instance 집합

Service는 다음 기능과 연결됩니다.

• Client·Server-side Connection Load Balancing
• Runtime Load Balancing Advisory
• Workload별 Instance 배치
• Planned Maintenance Draining
• Service Failover
• 업무별 AWR·Service 통계
• Application Continuity 정책

FAN

Fast Application Notification은 Node·Instance·Service 상태 변화와 Load Balancing Advisory를 Client와 Connection Pool에 전달합니다.

Service DOWN
→ FAN Event
→ FAN-aware Pool이 실패 Connection을 빠르게 제거
→ 사용 가능한 Service Member로 새 요청 분배

Service UP
→ Pool이 새 Capacity를 빠르게 활용

FAN은 장애 탐지와 Pool 정리를 빠르게 하지만, 진행 중 Transaction을 자동 재실행하는 기능 자체는 아닙니다. 요청 Replay에는 Application Continuity 또는 Transparent Application Continuity와 올바른 Service·Client 구성이 필요합니다.

11. Instance Recovery와 Application 가용성

Instance 실패 시 생존 Instance는 실패 Instance의 Redo Thread를 읽어 Database 상태를 복구합니다.

• Commit된 변경을 Database에 반영
• 장애 당시 Active Transaction을 Rollback
• 해당 Transaction과 Instance가 사용하던 Resource 해제

하지만 실패 Instance에서 실행 중이던 Application Call은 별도 문제입니다.

Database 복구
→ Instance Recovery

Connection 정리·재분배
→ FAN·Pool

안전한 요청 Replay
→ Transaction Guard·Application Continuity

이 세 계층을 같은 기능으로 혼동하지 않습니다.

12. 진단 View와 SQL

12.1 Instance·Service 분포

SELECT inst_id,
       instance_name,
       host_name,
       status,
       startup_time
FROM   gv$instance
ORDER BY inst_id;

SELECT inst_id,
       service_name,
       status,
       COUNT(*) AS session_count
FROM   gv$session
WHERE  type = 'USER'
GROUP BY inst_id, service_name, status
ORDER BY service_name, inst_id, status;

12.2 Global Cache Event Delta

GV$SYSTEM_EVENT는 Instance Startup 이후 누적값이므로 장애 시작·종료 Snapshot의 차이를 비교합니다.

SELECT inst_id,
       event,
       total_waits,
       time_waited_micro,
       ROUND(time_waited_micro / NULLIF(total_waits, 0) / 1000, 3) AS avg_wait_ms
FROM   gv$system_event
WHERE  event LIKE 'gc %'
ORDER BY time_waited_micro DESC;

12.3 ASH에서 SQL·Object·Block·Remote Instance 연결

SELECT inst_id,
       sample_time,
       event,
       sql_id,
       current_obj#,
       current_file#,
       current_block#,
       remote_instance#
FROM   gv$active_session_history
WHERE  wait_class = 'Cluster'
ORDER BY sample_time DESC;

CURRENT_OBJ#, CURRENT_FILE#, CURRENT_BLOCK#는 Cluster·Concurrency·User I/O 등의 특정 Wait에서만 의미 있는 값이므로 Event와 함께 해석합니다. REMOTE_INSTANCE#는 Cluster Event에서 Block을 제공할 Remote Instance를 나타냅니다.

12.4 추가 View

• V$INSTANCE_CACHE_TRANSFER: Instance 사이 CR·Current Block Transfer 통계
• V$CURRENT_BLOCK_SERVER: LMS의 Current Block Serving·Pin·Flush 통계
• GV$SEGMENT_STATISTICS: Object별 Segment 통계
• V$SEGSTAT_NAME: 현재 Version에서 지원하는 Segment Statistic 이름 확인

Dictionary·View 제공 항목은 Version·환경·License에 따라 다를 수 있으므로 실제 Column과 Statistic 이름을 먼저 확인합니다.

13. RAC Global Cache 진단 절차

1. 응답시간 증가가 실제로 발생한 시간 구간을 고정한다.
2. DB Time에서 Cluster Wait 비중과 처리량 변화를 확인한다.
3. CR·Current, 2-way·3-way, busy·congested·lost를 구분한다.
4. ASH에서 SQL_ID·Object·File·Block·Remote Instance를 연결한다.
5. 같은 Block이 여러 Instance에서 반복 요청되는지 확인한다.
6. Serving Instance CPU·Run Queue·LMS 상태를 확인한다.
7. Interconnect Latency·Packet Drop·오류·경로를 확인한다.
8. SQL의 Buffer Get·Access Path·Hot Row·Hot Index를 확인한다.
9. Service 배치·Partitioning·Index·SQL 개선 후보를 선택한다.
10. 변경 후 처리량·응답시간·Failover·가용성을 함께 회귀 검증한다.

gc Wait가 높다는 사실만으로 Interconnect 교체나 GCS Process 증가를 먼저 수행하지 않습니다. busy는 Block 제공 지연, congested는 Serving Queue 혼잡, Hot Block은 데이터 접근 집중이라는 서로 다른 문제일 수 있습니다.

14. 혼동하기 쉬운 판단

15. 핵심 정리

Oracle RAC
→ 하나의 Database + 여러 Instance
→ 공유 Database Files + 독립 SGA·Buffer Cache

GRD
→ 전역 Resource 상태의 분산 Directory

GCS·LMS
→ Cache Block 접근·Cache Fusion

GES·LMD·LMON
→ Global Enqueue·Membership·Resource 재구성

CR Block
→ Query SCN 기준 일관 읽기

Current Block
→ 최신 상태·DML 접근

2-way·3-way
→ Cache Fusion Network Hop 수

busy
→ Serving Instance에서 Block 제공 보류

congested
→ GCS 처리 Queue 지연

Service·FAN·AC
→ Workload 배치·빠른 장애 통지·요청 Replay를 각각 담당