오라클 GCS 와 GES - 편집 역사

2026년 9월 14일 (월) 12:21에 Oracle님의 편집

2026-09-14T12:21:17Z

← 이전 판		2026년 9월 14일 (월) 21:21 판
38번째 줄:		38번째 줄:

	==== GES가 관리하는 대표적 자원 ====		==== GES가 관리하는 대표적 자원 ====
	- TX (Transaction lock): 로우 레벨 락 — 여러 인스턴스에서 같은 로우를 수정하려 할 때 조율		::::- TX (Transaction lock): 로우 레벨 락 — 여러 인스턴스에서 같은 로우를 수정하려 할 때 조율
	- TM (DML enqueue): 테이블 레벨 락 — DDL/DML 충돌 방지		::::- TM (DML enqueue): 테이블 레벨 락 — DDL/DML 충돌 방지
	- *각종 딕셔너리 캐시 락(dc_)**: 데이터 딕셔너리 메타데이터 동기화		::::- *각종 딕셔너리 캐시 락(dc_)**: 데이터 딕셔너리 메타데이터 동기화
	- 라이브러리 캐시 락(library cache lock, library cache pin): SQL/PL·SQL 커서, 오브젝트 정의 동기화		::::- 라이브러리 캐시 락(library cache lock, library cache pin): SQL/PL·SQL 커서, 오브젝트 정의 동기화
	- Sequence enqueue (SQ): 시퀀스 캐시 동기화 (NOORDER/캐시 크기에 따라 경합 발생 가능)		::::- Sequence enqueue (SQ): 시퀀스 캐시 동기화 (NOORDER/캐시 크기에 따라 경합 발생 가능)

	관련 대기 이벤트		관련 대기 이벤트
68번째 줄:		68번째 줄:
	- LMS: Global Cache Service Process — 실제 블록 전송(Cache Fusion) 수행, 개수는 CPU 코어 수에 비례해 자동 설정		- LMS: Global Cache Service Process — 실제 블록 전송(Cache Fusion) 수행, 개수는 CPU 코어 수에 비례해 자동 설정

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

	① Hot Block 경합: ~~순번 발급용 단일 로우를 여러 인스턴스에서 동시에 UPDATE하는 설계(카운터 테이블 등)~~ → `~~gc buffer busy~~`/`~~enq: TX~~`~~가 폭증. 해결은 시퀀스~~ 사용~~, 또는 파티셔닝으로 인스턴스별 분산~~.		::: ② 시퀀스 경합**: `NOCACHE` 또는 `ORDER` 옵션 시퀀스를 RAC에서 사용하면 매번 GES를 거쳐 전역 순서를 보장해야 해서 경합 심함 → 순서 보장이 꼭 필요한 게 아니면 `CACHE` 크게 잡고 `NOORDER` 사용 권장.

	② 시퀀스 경합: ~~`NOCACHE` 또는 `ORDER` 옵션 시퀀스를 RAC에서 사용하면 매번 GES를 거쳐 전역 순서를 보장해야 해서 경합 심함~~ → ~~순서 보장이 꼭 필요한 게 아니면~~ `~~CACHE` 크게 잡고 `NOORDER~~` ~~사용 권장~~.		::: ③ HW(하이워터마크) 경합**: 여러 인스턴스가 동시에 같은 테이블에 대량 INSERT → 세그먼트 확장 시 `enq: HW` 대기. ASSM이면 완화되지만, 극단적 동시 INSERT 워크로드면 파티셔닝으로 인스턴스별 물리적 분리 고려.

	~~③ HW(하이워터마크) 경합~~: ~~여러 인스턴스가 동시에 같은 테이블에 대량 INSERT → 세그먼트 확장 시 `enq~~: ~~HW` 대기. ASSM이면 완화되지만, 극단적 동시 INSERT 워크로드면 파티셔닝으로 인스턴스별 물리적 분리 고려.~~		::: ④ 애플리케이션 어피니티 부재**: 특정 데이터 범위를 특정 인스턴스로 유도하지 않고 무작위 라우팅하면, 같은 블록을 여러 인스턴스가 번갈아 요청해 GCS 트래픽(인터커넥트 부하)이 커집니다. Service 기반 워크로드 분산(각 서비스를 특정 인스턴스 선호로 라우팅)으로 완화 가능.

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

	~~궁금하신 부분이 특정 대기 이벤트 분석(AWR RAC 리포트 해석)이나 실제 경합 진단 SQL 쪽이면 이어서 알려드릴 수 있습니다~~.

2026년 9월 14일 (월) 12:17에 Oracle님의 편집

2026-09-14T12:17:34Z

← 이전 판		2026년 9월 14일 (월) 21:17 판
3번째 줄:		3번째 줄:

	=== GCS (Global Cache Service) ===		=== GCS (Global Cache Service) ===
	: — 캐시 퓨전(Cache Fusion)의 핵심		::: — 캐시 퓨전(Cache Fusion)의 핵심
	:여러 인스턴스의 버퍼캐시에 흩어져 있는 동일 데이터 블록의 일관성을 인스턴스 간 네트워크(인터커넥트)를 통해 관리합니다.		:여러 인스턴스의 버퍼캐시에 흩어져 있는 동일 데이터 블록의 일관성을 인스턴스 간 네트워크(인터커넥트)를 통해 관리합니다.
	:디스크를 거치지 않고 메모리-투-메모리로 블록을 주고받는 것이 핵심입니다.		:::디스크를 거치지 않고 메모리-투-메모리로 블록을 주고받는 것이 핵심입니다.

	* 핵심 개념		* 핵심 개념

Oracle: 새 문서: == GCS(Global Cache Service)와 GES(Global Enqueue Service)== * Oracle RAC의 핵심 메커니즘인 GCS(Global Cache Service)와 GES(Global Enqueue Service)는 여러 인스턴스가 하나의 데이터베이스를 동시에 접근할 때 데이터 일관성과 자원 동기화를 보장하는 두 축입니다. === GCS (Global Cache Service) === : — 캐시 퓨전(Cache Fusion)의 핵심 :여러 인스턴스의 버퍼캐시에 흩어져 있는 **동일 데이터 블...

2026-09-14T12:09:51Z

새 문서: == GCS(Global Cache Service)와 GES(Global Enqueue Service)== * Oracle RAC의 핵심 메커니즘인 GCS(Global Cache Service)와 GES(Global Enqueue Service)는 여러 인스턴스가 하나의 데이터베이스를 동시에 접근할 때 **데이터 일관성**과 **자원 동기화**를 보장하는 두 축입니다. === GCS (Global Cache Service) === : — 캐시 퓨전(Cache Fusion)의 핵심 :여러 인스턴스의 버퍼캐시에 흩어져 있는 **동일 데이터 블...

새 문서

== 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 기반 워크로드 분산(각 서비스를 특정 인스턴스 선호로 라우팅)으로 완화 가능.

궁금하신 부분이 특정 대기 이벤트 분석(AWR RAC 리포트 해석)이나 실제 경합 진단 SQL 쪽이면 이어서 알려드릴 수 있습니다.