서버 이관 프로젝트를 수행하는 과정에서 Oracle RAC(Real Application Clusters) 환경에서는 기존 단일 인스턴스 환경과 다른 성능 문제가 발생할 가능성이 크다. 다중 노드 환경에서는 부하 분산, 글로벌 캐시, 세션 이동성(Session Affinity), 노드 간 통신(Latency) 등 다양한 요소가 데이터베이스 성능에 영향을 미칠 수 있기 때문이다.
이러한 환경에서 데이터베이스 성능을 최적화하기 위해서는 ASH(Active Session History) 데이터를 효과적으로 활용하여 특정 노드에서 발생하는 세션 부하를 분석하고 성능 병목을 찾아내는 것이 중요하다. ASH는 Oracle이 매 초마다 활성 세션 정보를 기록하는 기능으로, RAC 환경에서는 여러 노드에서 실행되는 세션들의 동작을 실시간으로 모니터링할 수 있다.
본 글에서는 Oracle RAC 환경에서 ASH 데이터를 활용하여 세션 성능을 분석하는 방법을 설명하고, 이를 통해 성능 문제를 해결하는 실무적인 접근법을 제시한다. 이를 통해 다중 노드 환경에서 발생할 수 있는 성능 저하 문제를 효과적으로 감지하고 최적화할 수 있도록 한다.
Oracle RAC 환경에서의 성능 분석이 중요한 이유
RAC 환경에서 발생할 수 있는 주요 성능 이슈
- 노드 간 부하 분산 불균형
- 특정 노드에서만 세션이 집중될 경우, 일부 노드는 과부하가 걸리고 다른 노드는 여유가 발생하는 문제.
- 세션이 특정 노드에 편향되지 않도록 적절한 부하 분산이 필요함.
- 글로벌 캐시(Global Cache) 병목 현상
- RAC 환경에서는 각 노드가 공유 데이터블록을 캐싱하고, 다른 노드와 공유해야 함.
- 노드 간 데이터 요청이 많으면 GC (Global Cache) 관련 대기 이벤트가 증가하여 성능 저하 발생 가능.
- 락 컨플릭트(Lock Contention) 증가
- 여러 노드에서 동일한 데이터에 대한 변경 작업을 수행하면 트랜잭션 충돌이 발생할 가능성이 높음.
- 락 대기 시간이 증가하면 응답 속도가 저하될 수 있음.
- 인터커넥트(Interconnect) 트래픽 증가
- RAC 노드 간의 데이터 교환이 빈번하게 발생하면 인터커넥트 트래픽이 증가하여 성능 저하를 유발할 수 있음.
이러한 문제를 해결하기 위해 ASH 데이터를 활용하여 RAC 환경에서 실행되는 세션의 부하를 분석하고, 특정 노드에서 발생하는 병목을 감지하는 과정이 필요하다.
Oracle RAC 환경에서 ASH를 활용한 성능 분석 방법
특정 노드에서 실행 중인 세션 확인
RAC 환경에서 특정 노드에서 실행 중인 세션을 확인하려면 ASH 데이터를 조회하여 노드별 세션 정보를 분석할 수 있다.
SELECT instance_number, session_id, sql_id, event, wait_class FROM gv$active_session_history WHERE sample_time BETWEEN SYSDATE - (1 / 1440) AND SYSDATE ORDER BY instance_number, sample_time DESC; |
- instance_number: 세션이 실행 중인 RAC 노드의 번호.
- session_id: 실행 중인 세션의 ID.
- sql_id: 실행 중인 SQL의 ID.
- event & wait_class: 해당 세션에서 발생한 대기 이벤트.
이 데이터를 활용하면 어떤 노드에서 세션이 집중되고 있는지, 특정 노드에서 대기 시간이 길어지는지 확인할 수 있다.
노드별 부하 분석 – CPU 사용량 확인
RAC 환경에서는 특정 노드에서 CPU 부하가 집중될 수 있기 때문에, 노드별 CPU 사용량을 분석하는 것이 중요하다.
SELECT instance_number, COUNT(*) AS cpu_sessions FROM gv$active_session_history WHERE session_state = 'ON CPU' AND sample_time BETWEEN SYSDATE - (1 / 1440) AND SYSDATE GROUP BY instance_number ORDER BY cpu_sessions DESC; |
- session_state = 'ON CPU': 현재 CPU에서 실행 중인 세션만 조회.
- cpu_sessions: 특정 노드에서 CPU를 사용하는 세션의 개수.
이 데이터를 활용하면 특정 노드에서 CPU 부하가 집중되는지를 파악하고, 필요하면 부하를 균등하게 분산하도록 설정을 조정할 수 있다.
노드 간 글로벌 캐시(Global Cache) 대기 분석
RAC 환경에서는 노드 간 공유 데이터 블록을 주고받는 과정에서 글로벌 캐시 관련 대기 이벤트가 발생할 수 있다.
SELECT instance_number, event, COUNT(*) AS wait_count FROM gv$active_session_history WHERE wait_class = 'Cluster' AND sample_time BETWEEN SYSDATE - (1 / 1440) AND SYSDATE GROUP BY instance_number, event ORDER BY wait_count DESC; |
- wait_class = 'Cluster': 글로벌 캐시(Global Cache) 관련 대기 이벤트만 조회.
- event: RAC 환경에서 노드 간 블록 요청 및 데이터 교환과 관련된 대기 이벤트.
- wait_count: 해당 대기 이벤트가 발생한 횟수.
대표적인 글로벌 캐시 대기 이벤트는 다음과 같다.
- gc buffer busy acquire: RAC 노드 간 데이터 블록을 요청할 때 발생하는 대기.
- gc cr request: 읽기 전용 블록을 요청할 때 발생하는 대기.
- gc current block busy: 다른 노드에서 블록을 업데이트하는 동안 대기하는 경우.
이 데이터를 활용하면 어떤 노드에서 글로벌 캐시 대기가 많이 발생하는지 파악하고, 특정 테이블 또는 SQL에서 발생하는 문제인지 분석할 수 있다.
블로킹 세션(Blocking Session) 감지
RAC 환경에서 여러 노드에서 동일한 데이터에 대한 변경 작업을 수행하면, 세션 간 락 충돌이 발생할 가능성이 높다. 이를 감지하려면 블로킹 세션을 조회해야 한다.
SELECT blocking_session, instance_number, session_id, event, wait_time FROM gv$session WHERE blocking_session IS NOT NULL ORDER BY wait_time DESC; |
- blocking_session: 다른 세션을 차단하는 세션 ID.
- instance_number: 해당 세션이 실행 중인 노드.
- event: 대기 이벤트.
- wait_time: 대기 시간(밀리초).
이 데이터를 활용하면 트랜잭션 충돌을 방지하기 위해 테이블의 락 전략을 조정하거나, 트랜잭션 크기를 조정하는 등의 최적화 작업을 수행할 수 있다.
성능 최적화를 위한 해결 방법
부하 분산 조정
- 특정 노드에 세션이 집중되지 않도록 서버 연결 로드 밸런싱을 조정.
- 서비스 및 세션 연결 정책을 조정하여 부하를 균등하게 분산.
글로벌 캐시 대기 감소
- 자주 변경되는 데이터가 여러 노드에서 공유되지 않도록 애플리케이션 트랜잭션을 조정.
- 캐시된 데이터의 공유를 최소화하기 위해 파티셔닝을 활용.
락 충돌 해결
- 트랜잭션 크기를 줄이고 자주 갱신되는 데이터의 락 유지 시간을 단축.
- 락이 많이 발생하는 테이블에 대해 적절한 인덱스를 추가하여 충돌을 방지.
Oracle RAC 환경에서는 노드 간 부하 균형, 글로벌 캐시 대기, 락 충돌 등의 다양한 성능 문제가 발생할 수 있으므로, ASH 데이터를 활용하여 이를 신속하게 감지하고 해결하는 것이 중요하다.
특정 노드에서 CPU 부하가 집중되거나, 글로벌 캐시 대기가 길어지거나, 블로킹 세션이 증가하는 경우 ASH 데이터를 활용하여 문제를 분석하고, 로드 밸런싱 조정, 트랜잭션 최적화, 인덱스 활용 등의 방법을 적용하면 성능을 크게 개선할 수 있다.
'IT > AWR-ASH' 카테고리의 다른 글
ASH에서 Temp Tablespace 사용량 분석: 정렬 연산 등의 임시 테이블스페이스 사용량을 분석. (0) | 2025.02.16 |
---|---|
ASH와 Statspack 비교: Oracle 성능 모니터링 도구인 Statspack과 ASH의 차이점 분석. (0) | 2025.02.15 |
ASH 데이터를 활용한 트랜잭션 분석: 대량 트랜잭션이 시스템에 미치는 영향 분석. (0) | 2025.02.15 |
ASH 데이터 보관 기간 설정 및 관리: ASH 데이터의 보관 기간을 설정하고 관리하는 방법. (0) | 2025.02.14 |
조인 최적화와 ASH 분석: 조인이 많은 SQL의 실행 패턴을 분석하여 최적화하는 방법. (0) | 2025.02.11 |
인덱스 미사용 SQL 분석: ASH에서 특정 SQL이 인덱스를 사용하고 있는지 확인하는 방법. (0) | 2025.02.11 |
ASH 데이터를 활용한 병목 현상 해결하기: 시스템 성능을 저하시킬 수 있는 병목 요소 분석. (0) | 2025.02.11 |
ASH 데이터를 활용한 성능 추세 분석: 일정 기간 동안 성능 변화 감지 및 튜닝. (0) | 2025.02.10 |