오라클 GCS 와 GES

GCS(Global Cache Service)와 GES(Global Enqueue Service)

• Oracle RAC의 핵심 메커니즘인 GCS(Global Cache Service)와 GES(Global Enqueue Service)는 여러 인스턴스가 하나의 데이터베이스를 동시에 접근할 때 **데이터 일관성**과 **자원 동기화**를 보장하는 두 축입니다.

GCS (Global Cache Service)

— 캐시 퓨전(Cache Fusion)의 핵심

여러 인스턴스의 버퍼캐시에 흩어져 있는 **동일 데이터 블록의 일관성**을 인스턴스 간 네트워크(인터커넥트)를 통해 관리합니다.

디스크를 거치지 않고 메모리-투-메모리로 블록을 주고받는 것이 핵심입니다.

• 핵심 개념

- Cache Fusion: 한 인스턴스가 수정한 블록을 다른 인스턴스가 요청하면, 디스크에 쓰지 않고 인터커넥트를 통해 블록을 직접 전송합니다.

- 자원 마스터링(Resource Mastering): 각 블록(정확히는 자원 단위)마다 어느 인스턴스가 "마스터"인지가 정해져 있고, 마스터 인스턴스가 해당 블록의 상태(누가 갖고 있는지, 어떤 모드인지)를 관리합니다.

- 블록 상태(Role/Mode):

- **Role**: Local(단일 인스턴스만 사용 중) / Global(여러 인스턴스가 공유 중)

- **Mode**: NULL(공유 안 함), SHARED(읽기 공유), EXCLUSIVE(단독 수정)

동작 흐름 예시

1. Instance A가 블록을 수정하려고 함 → GCS에 EXCLUSIVE 권한 요청
2. GCS 마스터가 "Instance B가 이미 이 블록을 갖고 있다"는 걸 확인
3. B의 버퍼에서 A로 **직접 전송**(Cache Fusion) — 이때 상황에 따라 CR(Consistent Read) 이미지 또는 Current 블록 전송
4. A가 수정 완료 후, 필요시 다시 다른 인스턴스 요청에 따라 전송 지속

관련 대기 이벤트 (성능 진단 시 자주 봄)

| 이벤트 | 의미 | |---|---| | `gc cr request` | 다른 인스턴스에 Consistent Read 블록 요청 후 대기 | | `gc current request` | 다른 인스턴스에 Current 블록(수정용) 요청 후 대기 | | `gc buffer busy acquire/release` | 로컬에서 블록을 이미 누가 가져오는 중이라 대기 | | `gc cr/current block 2-way`, `3-way` | 2-way는 요청자↔소유자 직접, 3-way는 마스터를 거쳐 전달(인터커넥트 홉이 하나 더 생김 → 더 느림) |

인터커넥트가 느리거나(네트워크 지연, private interconnect 대역폭 부족), 특정 블록에 여러 인스턴스가 동시에 몰리는 **Hot Block** 상황(자주 갱신되는 소수 로우, 시퀀스 없는 카운터 컬럼 등)이면 `gc` 대기가 급증합니다.

GES (Global Enqueue Service)

— 자원 잠금 동기화

GCS가 **데이터 블록** 자체를 다룬다면, GES는 그보다 더 넓은 범위의 **논리적 자원(enqueue)**에 대한 인스턴스 간 잠금 동기화를 담당합니다. 즉 "블록의 내용"이 아니라 "누가 무엇을 잠갔는지"를 관리합니다.

GES가 관리하는 대표적 자원

- **TX (Transaction lock)**: 로우 레벨 락 — 여러 인스턴스에서 같은 로우를 수정하려 할 때 조율

- **TM (DML enqueue)**: 테이블 레벨 락 — DDL/DML 충돌 방지

- **각종 딕셔너리 캐시 락(dc_*)**: 데이터 딕셔너리 메타데이터 동기화

- **라이브러리 캐시 락(library cache lock, library cache pin)**: SQL/PL·SQL 커서, 오브젝트 정의 동기화

- **Sequence enqueue (SQ)**: 시퀀스 캐시 동기화 (NOORDER/캐시 크기에 따라 경합 발생 가능)

• • 관련 대기 이벤트**

| 이벤트 | 의미 | |---|---| | `enq: TX - row lock contention` | 여러 세션(다른 인스턴스 포함)이 같은 로우를 잠그려 대기 | | `enq: TM - contention` | 테이블 락 경합(FK 인덱스 없음 등이 원인인 경우 많음) | | `enq: HW - contention` | High Water Mark 확장 경합 — 여러 인스턴스에서 동시 INSERT로 세그먼트 확장할 때 | | `enq: SQ - contention` | 시퀀스 NEXTVAL 요청 경합 — 캐시 크기가 작거나 NOORDER 미설정 시 | | `row cache lock` | 딕셔너리 캐시 자원 경합 |

1. 1. GCS vs GES 핵심 차이

| 구분 | GCS | GES | |---|---|---| | 관리 대상 | 데이터 블록(버퍼캐시의 실제 내용) | 논리적 자원/락(TX, TM, dc_*, library cache 등) | | 목적 | 블록 데이터의 인스턴스 간 일관성 유지 | 자원 접근 순서/배타성 보장 | | 핵심 메커니즘 | Cache Fusion (메모리 간 직접 전송) | Enqueue 획득/대기/해제 프로토콜 | | 진단 뷰 | `V$GC_ELEMENT`, `GV$CACHE_TRANSFER`, `GV$BH` | `V$GES_ENQUEUE`, `GV$LOCK`, `GV$GES_RESOURCE` | | 프로세스 | LMS(Lock Manager Server) 프로세스가 실무 담당 | LMD(Lock Manager Daemon)가 enqueue 요청 처리, LMON이 전체 조율 |

두 서비스 모두 **LMON, LMD, LMS** 백그라운드 프로세스가 협력해서 동작합니다: - **LMON**: Global Enqueue Service Monitor — 클러스터 재구성(노드 추가/제거), 장애 감지 시 리마스터링 주도 - **LMD**: Global Enqueue Service Daemon — enqueue 요청/데드락 감지 처리 - **LMS**: Global Cache Service Process — 실제 블록 전송(Cache Fusion) 수행, 개수는 CPU 코어 수에 비례해 자동 설정

실무에서 자주 마주치는 경합 패턴

① Hot Block 경합**: 순번 발급용 단일 로우를 여러 인스턴스에서 동시에 UPDATE하는 설계(카운터 테이블 등) → `gc buffer busy`/`enq: TX`가 폭증. 해결은 시퀀스 사용, 또는 파티셔닝으로 인스턴스별 분산.

② 시퀀스 경합**: `NOCACHE` 또는 `ORDER` 옵션 시퀀스를 RAC에서 사용하면 매번 GES를 거쳐 전역 순서를 보장해야 해서 경합 심함 → 순서 보장이 꼭 필요한 게 아니면 `CACHE` 크게 잡고 `NOORDER` 사용 권장.

③ HW(하이워터마크) 경합**: 여러 인스턴스가 동시에 같은 테이블에 대량 INSERT → 세그먼트 확장 시 `enq: HW` 대기. ASSM이면 완화되지만, 극단적 동시 INSERT 워크로드면 파티셔닝으로 인스턴스별 물리적 분리 고려.

④ 애플리케이션 어피니티 부재**: 특정 데이터 범위를 특정 인스턴스로 유도하지 않고 무작위 라우팅하면, 같은 블록을 여러 인스턴스가 번갈아 요청해 GCS 트래픽(인터커넥트 부하)이 커집니다. Service 기반 워크로드 분산(각 서비스를 특정 인스턴스 선호로 라우팅)으로 완화 가능.