[17] RAC GRD 개요

RAC 성능 튜닝과 관련된 문서들을 보면 대부분 가장 먼저 GRD (Global Resource Directory)를 설명합니다. 아마도 RAC 성능 튜닝에 있어서 RAC의 내부 아키텍처에 대한 이해가 필수적인 요소이고, 어찌 보면 GRD가 RAC 아키텍처의 가장 중요한 부분을 차지하고 있기 때문인 것 같습니다. 대략 1주일동안 GRD에 대한 학습과 연구를 마무리하고 글을 정리하려고 보니 하나의 포스팅으로는 글이 너무 길어질 것 같아서 다음과 같이 4개의 주제로 나누어서 포스팅을 하고자 합니다.

GRD 부분부터는 내부 동작원리를 설명해야 됨에 따라 인터널한 내용을 포함하게 됩니다. 인터널 부분은 학습하는 것도 쉽지 않지만, 학습을 토대로 연구한 내용을 설명하는 것도 쉽지 않습니다. 너무 깊이 설명하면 실용성이 현저히 떨어지고, 너무 가볍게 설명하면 트러블슈팅 시에 도움이 되지 않기 때문입니다. 이러한 점을 고려해서 제가 이해하는 수준에서 적절한 깊이로 설명하려고 합니다.

들어가기에 앞서


GRD 동작원리를 연구하면서 학습한 2개의 자료를 소개합니다. RAC 인터널에 대해서 논할 때 반드시 읽어봐야 할 문서들입니다.

  • Julian Dyke의 RAC Internal PPTPDF : PPT는 2006년 자료, PDF는 2008년 자료입니다. PDF에 조금 더 설명이 보강되어 있으므로 2개의 문서를 모두 보시는것이 좋습니다. 10년전 문서이지만 RAC 인터널 관련된 대부분의 문서들의 참고 자료가 될 정도로 정리가 잘된 문서입니다. 또한, PPT 애니메이션을 이용해서 동작 원리를 너무도 명쾌하게 설명한 문서이기도 합니다.
  • Riyaj Shamsudeen의 슬라이드 노트 : Export Oracle RAC 12c의 저자인 Riyaj Shamsudeen이 작성한 문서로써 RAC와 관련된 성능 이슈를 분석할 때 반드시 읽어봐야 할 문서입니다.

이번 시간에는 몇개의 질문들을 통해 GRD에 대해서 가볍게 정리해보도록 하겠습니다.

질문-1. GRD란 무엇인가요?


GRD는 “Global 리소스 관리를 위해 사용되는 메모리 구조체”입니다. GRD가 필요한 이유는 RAC에서의 모든 리소스들은 “Global”하게 관리되어야 하기 때문입니다. GRD 내부에는 다음과 같은 2개의 리소스를 위한 구조체를 가지고 있습니다.

  1. BL (Buffer Lock) 리소스를 위한 구조체 : 블록과 관련된 리소스를 저장하는 구조체이며 GCS (Global Cache Service)가 관리합니다.
  2. Non-BL 리소스를 위한 구조체 : 주로 락 (TX, TM등)과 관련된 리소스를 저장하는 구조체이며 GES (Global Enqueue Service)가 관리합니다.

 

질문-2. GRD 구조체란 정확히 무엇인가요?


메모리 구조체란 C 언어의 struct라고 이해하면 됩니다. 오라클은 x$ fixed 테이블을 통해 구조체의 내용을 제공하며 GRD의 내용을 확인할 수 있는 x$ fixed 테이블은 4개입니다. (그림-1. 참조)

그림-1. GRD와 관련된 x$ fixed 테이블 및 v$ 뷰

17-1

그림-1에서 보여지는 것처럼, BL 리소스를 위한 구조체 2개 (X$KJBL, X$KJBR)와 Non-BL 리소스를 위한 구조체 2개 (X$KJILKFT, X$KJIRFT)를 제공하며, 모니터링의 편의를 위해서 “락”과 관련된 2개의 구조체 (X$KJBL, X$KJILKFT)를 UNION ALL로 묶어서 V$GES_ENQUEUE로 제공하며, “리소스”와 관련된 2개의 구조체 (X$KJBR, X$KJIRFT)를 UNION ALL로 묶어서 V$GES_RESOURCE로 제공합니다.

질문-3. 리소스와 락 구조체의 차이점은 무엇인가요?


오라클에서 리소스와 락 구조체를 분리한 이유는 리소스와 락 구조체가 1:M의 관계이기 때문입니다. 다시 말해, 리소스 구조체 내의 항목들은 “항목 별로 1개“인 반면, 락 구조체 내에는 특정 리소스에 대해서 여러 개의 항목이 저장될 수 있습니다. 예를 들어, 하나의 블록에 대한 리소스 정보는 해당 블록의 마스터 노드의 X$KJBR에만 1건 등록됩니다. 하지만 해당 블록을 모든 인스턴스에서 액세스한다면, 모든 인스턴스의 X$KBJL에는 해당 블록에 대한 락 정보가 등록되게 됩니다. 일반적으로 리소스 구조체는 리소스를 “보호“할 목적으로, 락 구조체는 리소스를 “사용“할 목적으로 이용된다고 보면 됩니다.

Note
위에 기술된 “항목 별로 1개”를 좀 더 명확히 설명하면, BL 리소스는 전 노드에 걸쳐 1개의 항목을 X$KJBR에 등록하는 반면, Non-BL 리소스는 각 노드 별로 1개의 항목을 X$KJIRFT에 등록합니다.

질문-4. GRD는 어디에, 어떻게 저장되나요?


GRD는 shared pool에 저장되며, 아래 쿼리의 결과와 같이 인스턴스 별로 균등하게 나눠서 관리합니다. GRD 전체 Set을 인스턴스마다 중복해서 관리하지 않고, 균등하게 나눠서 관리하는 이유는 SGA 메모리의 낭비를 막기 위해서 입니다. 만일 모든 모드가 GRD의 전체 Set을 저장한다면 노드가 증가할수록 메모리 사용 측면에서 부담이 될 가능성이 높습니다. 제 경우에는 테스트 환경이기 때문에 버퍼 캐시도 아주 작고(60MB) 공유 풀도 그리 크지 않지만, 운영 장비인 경우에는 GRD를 위해서 꽤 많은 메모리 공간이 필요하게 됩니다.

select *
from (select inst_id, pool, name, round(bytes/1024/1024,0) size_MB
      from   gv$sgastat
      where  name in ('gcs resources',
                      'gcs shadows',
                      'ges enqueues',
                      'ges resource dynamic',
                      'ges resource permanent'))
pivot (max(size_MB) for inst_id in (1,2,3))
order by name
/
POOL         NAME                               1          2          3
------------ ------------------------- ---------- ---------- ----------
shared pool  gcs resources                      3          3          3
shared pool  gcs shadows                        2          2          2
shared pool  ges enqueues                       8          7          7
shared pool  ges resource dynamic               0          1          1
shared pool  ges resource permanent             4          4          4
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s