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(단독 수정)
동작 흐름 예시
- Instance A가 블록을 수정하려고 함 → GCS에 EXCLUSIVE 권한 요청
- GCS 마스터가 "Instance B가 이미 이 블록을 갖고 있다"는 걸 확인
- B의 버퍼에서 A로 **직접 전송**(Cache Fusion) — 이때 상황에 따라 CR(Consistent Read) 이미지 또는 Current 블록 전송
- 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` | 딕셔너리 캐시 자원 경합 |
- 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 기반 워크로드 분산(각 서비스를 특정 인스턴스 선호로 라우팅)으로 완화 가능.