PGA와 UGA 영역

PGA는 특정 프로세스에 의해 할당된 그 프로세스만을 위한 메모리 영역이다. 이 메모리 영역은 다른 프로세스가 접근하는 것이 불가능한, 할당 받은 프로세스만이 사용할 수 있는 영역이된다.
즉, Shared Memory 영역에 자리잡게되는 SGA공간과는 별개의 영역으로 자리잡게된다.

UGA는 세션 정보가 저장되는 영역이다. 따라서 특정 세션에서 특정 UGA 영역에 언제든 접근 가능해야 한다.
그러한 이유로 오라클 접속 방식이 어떻게 설정 되어있는지에 따라 UGA영역이 자리잡는 위치가 달라지게 된다.

만약 dedicated server 방식을 선택하였다면, 사용자가 접속할 때 마다 (dedicated) 서버 프로세스가 생성되게 된다. 이 서버 프로세스 역시 메모리를 할당 받게 될 것이며, 이는 이 서버 프로세스의 고유한 메모리 영역, 즉, PGA 영역이 된다.
이때 사용자 프로세스와 직접 통신하는 역할을 하는 것은 (dedicated) 서버 프로세스가 되며, 이 세션 정보를 다른 프로세스와 공유할 필요가 없다. 따라서 dedicated server 방식으로 설정되어 있다면, PGA 영역 안에 UGA 영역이 자리잡게 된다.

그리고 만약 접속 방식을 shared server 방식으로 설정하였다면, 사용자 프로세스는 (shared) 서버 프로세스와 직접 소통하게 되지 않는다.
사용자 프로세스는 dispatcher 프로세스와 통신을 하게 되며, 다시 dispatcher 프로세스가 실제로 작업해야되는 내용을 (shared) 서버 프로세스에 전달해주게 된다.
사용자에게 반납해야될 메세지 또한 서버 프로세스가 dispatcher에 전달을 해주게 되고, 사용자는 dispatcher로 부터 결과값을 받게 되는 것이다.
사용자의 요청사항이 서버 프로세스로 전달이 되고, 내부적인 동작을 마친 뒤의 결과값을 다시 서버 프로세스로부터 받아 온다라는 전체적인 동작 방식에는 차이가 없다.
단 shared server 방식을 사용하게되면 사용자 프로세스와, 서버 프로세스 사이에 dispatcher가 위치하게 되고, dispatcher와 서버 프로세스 사이의 IPC 통신이 필요하게 된다.
따라서 Shared Memory 영역에 자리잡고 있는 SGA 영역에 UGA 영역이 자리잡게 된다.

수동 PGA 메모리 관리

수동으로 PGA 메모리를 관리할 경우, 아래와 같은 파라미터들이 PGA 크기에 가장 큰 영향을 준다.

SORT_AREA_SIZE : 정렬 작업이 사용하는 메모리 공간의 크기. 정렬 작업이 해당 사이즈 이상의 공간을 필요로 하게되는 경우 디스크에서 정렬 작업이 이루어진다.
SORT_AREA_RETAINED_SIZE : 정렬된 작업이 완료된 이후에, 정렬된 데이터를 보관하기 위해 사용되는 메모리 영역. 정렬된 데이터의 사이즈가 해당 파라미터를 통해 지정된 사이즈 이상으로 크다면, 나머지 데이터는 템포러리 테이블스페이스에 저장된다.
HASH_AREA_SIZE : 해시 테이블을 저장하는데 사용되는 메모리 공간의 크기. 해시 조인등의 작업이 발생할 때에 사용된다.

 

SORT_AREA_SIZE 값에 따라, 정렬 작업시 PGA, UGA 및 디스크 사용량이 어떻게 변경되는지 확인해보기 위한 간단한 테스트를 진행한다. 

일단 아래와 같은 임시 테이블을 생성한다. 

sys@MHORA11G> create table imsi as select * from  all_objects;
Table created.
sys@MHORA11G> exec dbms_stats.gather_table_stats(user,'IMSI');
PL/SQL procedure successfully completed.
sys@MHORA11G> exit

그리고 테스트에 사용할 스크립트를 생성한다. 

[oracle@MHORA11G1 oratest]$ cat imsi.sql 
connect / as sysdba
set serveroutput off
set echo on
column sid new_val SID
select sid from v$mystat where rownum=1;
alter session set workarea_size_policy=manual;
alter session set sort_area_size = &1;
prompt 다른 세션을 하나 더 연결하고 @reset_stat &SID 를 실행 후, @watch_stat 를 실행하세요. 완료 후 현재 세션에서 Enter를 입력하세요.
pause
set termout off
select * from imsi order by 1, 2, 3, 4;
set termout on
prompt 다른 세션에서 @watch_stat 을 실행하세요.
pause

스크립트에 대해 간단히 설명하면, 
  새로 연결을 맺은 뒤, 
  해당 세션의 SID를 확인하고,
  해당 세션 내에서 workarea_size_policy=manual로 변경, 즉 pga_aggregate_target 파라메터를 무시하고, 수동으로 PGA 사이즈를 조정하도록 변경하고,
  해당 세션 내에서 sort_area_size를 스크립트 실행시 지정해준 값으로 변경한다.
  그리고 조금전에 생성해놓은 임시 테이블을 조회하되, 정렬 작업을 발생시키고, 
    테스트를 진행하는 사용자는 세션을 하나 더 열어 둔 뒤, 변화량을 측정할 수 있도록 한다.

테스트를 진행할 때에 오라클 세션을 2개 접속해 두어야 하고, 
 한 쪽 세션에서는 @imsi 65536 과 같은 식으로 스크립트를 실행해 주고,
 화면에 출력되는 메세지에 딸, 다른 쪽 세션에 접속하여 @reset_stat SID , @watch_stat 스크립트를 실행해 보도록 한다. 

reset_stat 스크립트와, watch_stat 스크립트의 내용은 각각 좌측의 링크를 통해 확인해보도록 한다.  

아래와 같이 실행하여, sort_area_size를 각각 64KB, 1MB, 1GB로 잡아두고 테스트를 진행한다. 

-- 이 란에서는 결과값만 요약해 두었다.
@imsi 65536 수행시, 
NAME                                                             KBYTES_WRITES DIFF_KBYTES_WRITES
---------------------------------------------------------------- ------------- ------------------
physical reads direct temporary tablespace                                6246               6246
physical writes direct temporary tablespace                               6246               6246
session pga memory                                                        2324               1600
session pga memory max                                                    2580               1856
session uga memory                                                         370                128
session uga memory max                                                     434                192


@imsi 1048576 수행시,
NAME                                                             KBYTES_WRITES DIFF_KBYTES_WRITES
---------------------------------------------------------------- ------------- ------------------
physical reads direct temporary tablespace                                1247               1247
physical writes direct temporary tablespace                               1247               1247
session pga memory                                                        2132               1408
session pga memory max                                                    4308               3584
session uga memory                                                         242                  0
session uga memory max                                                    2387               2145


@imsi 1073741820 수행시,
NAME                                                             KBYTES_WRITES DIFF_KBYTES_WRITES
---------------------------------------------------------------- ------------- ------------------
physical reads direct temporary tablespace                                   0                  0
physical writes direct temporary tablespace                                  0                  0
session pga memory                                                         724                  0
session pga memory max                                                   12564              11840
session uga memory                                                         242                  0
session uga memory max                                                   11946              11703

SORT_AREA_SIZE를 점점 더 크게 잡을 수록, PGA 사이즈가 훨씬 크게 증가되는 것을 확인할 수 있다. 반면 디스크 사용량은 크게 줄어들어, 1GB로 잡았을 경우에는 정렬에 사용 가능한 메모리 공간이 충분하기에 정렬 작업이 메모리 내에서만 발생하여 디스크는 사용되지 않았다는 것을 확인할 수 있다. 
또한 sort_area_size가 1GB로 잡혔을 때에도, PGA 사이즈가 1GB 이상으로 커지지 않는 것을 보면, SORT_AREA_SIZE는 최대 값에 해당할 뿐, 정렬시 무조건 SORT_AREA_SIZE만큼씩 할당해 주는 것은 아님을 확인할 수 있다.
다만 64KB로 놓았을 경우에, 교재의 경우 PGA사이즈가 정확히 64KB 증가하는 모습을 보이나 실제 테스트시엔 몇번을 반복하여도 64KB 이상으로 커지는 것으로 보인다. PGA영역이 반드시 정렬 작업에만 사용되는 것은 아니므로, 여타의 작업들이 PGA 사용량을 증가시킨 것으로 보인다.
그리고 교재에 따르면 쿼리가 완료된 이 후에 PGA 공간이 초기화 된다고 하나 이 또한 확인이 불가능하였다. 환경에 따라 다소 결과가 달라지는 듯 하니 정확한 이유를 파악하여 향후에 추가하도록 하겠다.

자동 PGA 메모리 관리

9i R1을 넘어가면서 부터, PGA 메모리를 자동화할 수 있는 방법들이 소개되기 시작했다. 

수동으로 PGA를 설정하던 시절에는 - 직접 파라미터를 설정해야 하기에 불편했고, 어디를 기준으로 맞추어야할 지도 애매했고, 동시에 발생하는 정렬 작업의 수치를 잘못 산정하여 어느 순간에는 메모리 사용량이 급격히늘어나거나 하는 문제가 생길 수도 있었다.
자동으로 넘어가며 - 이러한 불편함을 해소하며, 정렬이 없는 세션들에서 낭비하는 메모리를 최소화하고, 또 큰 정렬 작업을 발생시키는세션에서는 더 큰 메모리를 할당 받을 수 있는 등 메모리 활용도를 높힐 수 있게 되었다. 

자동 PGA 메모리 관리와 관련된 파라미터는 아래와 같다.

   WORKAREA_SIZE_POLICY : AUTO 혹은 MANUAL로 설정 가능하다. 이 파라미터를 AUTO로 설정할 경우 정렬공간 해시공간등과 관련된 파라미터를 자동으로 조정하며 동작한다. 
   PGA_AGGREGATE_TARGET : PGA 메모리 영역의 총합으로 사용할 메모리 사이즈를 지정해준다.
                                          sort_area_size, hash_area_size, bitmap_merge_size, create_bitmap_area_size와 같은 모든 작업 영역의 통합 사이즈를 몇으로 지정할지에 대한 값으로, 
                                          9i R1에서 처음 등장하였으며, 9i 시절엔 dedicated 서버 방식일 경우에만 동작했으나, 10g 시절로 넘어오며 shared 서버 방식에서도 동작하고 있다. 

"WORKAREA_SIZE_POLICY=AUTO / PGA_AGGREGATE_TARGET  = 0이 아닌 값"을 넣어주면 자동 PGA 메모리 관리 기능이 활성화된다. 

또한 11g R1 이후로는 MEMORY_TARGET이라는 파라미터가 추가 되었으며, 해당 파라미터를 수정하면(즉, 사용하게 되면) SGA와 PGA 메모리 모두를 자동으로 관리하게 된다.  

 

메모리 할당방식 결정하기 알아보기

(원서 상의 제목은 Determining How the Memory Is Allocated인데,
메모리 할당 방식 알아보기... 정도가 훨씬 어울리는 타이틀 같다. '결정하기'라는 제목을 보고서 내용을 읽었을 때는 왜 이런 이야기가 나오고 있는지 감이 안잡혀서 원서상의 제목을 찾아봤다...) 

자동으로 메모리를 할당하는 방식은, 그 동작 방식에 대하여 제공되는 문서화된 내용이 없을 뿐더러, 버전에따라 계속 변경되어 왔고, 앞으로도 변경되어갈 것이며, 사용자가 직접 제어하기 어려운 부분들 뿐이다.
그렇다보니 정확한 동작 방식을 알아보기에는 어려움이 있지만 메타링크 문서 147806.1223730.1399497.1번 등을을 확인해 보면 그 동작 방식에 대하여 어느정도의 힌트를 얻을 수 있다. 

  • PGA_AGGREGATE_TARGET 값은 전체 PGA 영역 사이즈에 관여한다. 이 값은 PGA 영역으로 사용할 최대의 크기를 뜻한다. 미리 메모리를 할당해 두지는 않으며, 최대 이 값까지 올라갈 수 있다는 것이다. 허나 이 값은 어디까지나 target이기에 어느 순간에 PGA 종량이 해당 값 이상으로 증가할 수도 있다.
  • PGA_AGGREGATE_TARGET 값은 개별 workarea의 사이즈에도 관여한다. 싱글 오퍼레이션은 PGA_AGGREGATE_TARGET의 5%정도까지, 패러럴 오퍼레이션은 30% 정도까지 메모리를 사용할 수 있다.
    이 리미트 값은 각각의 workarea 들에 대한 크기를 뜻하는 것으로, 하나의 세션에서 여러개의 쿼리를 수행할 수도 있고, 하나의 쿼리에서 여러번 해쉬가 일어나 hash area가 여러개 필요할 수도 있는 등, 하나의 세션을 기준으로 보면 5%와 30%를 넘어설 수 있다.
  • PGA_AGGREGATE_TARGET 값 내에서 자율조정되는 영역은 어디까지나 각 SQL Workarea들 뿐이다. (세션정보나, 커서정보가 저장되는 공간, PL/SQL에서 사용하는 공간 등) 그 외의 PGA 영역들에 대해서는 자동으로 조정되지 않는다. 
  • 즉 PGA_AGGREGATE_TARGET을 설정하면, "PGA_AGGREGATE_TARGET 값"에서 "조정 불가능한 공간의 크기를 제외한 만큼" 내에서 능동적으로 SQL Workarea들을 조정하며 동작하게 된다.
  • 해당 파라미터는 비용 기반의 옵티마이저 동작에도 영향을 미친다. 정렬,해쉬조인,비트맵 동작등에 사용할 수 있는 최소/최대 메모리 값을 계산하여 플랜을 선정하는데 이용한다. 

 

PGA_AGGREGATE_TARGET을 사용한 메모리 제어

오라클은 PGA_AGGREGATE_TARGET값을 넘지 않고 운영할 수 있도록 노력하지만, 상황에 따라서 더 큰 PGA 값이 요구될 때에는, 작업을 취소하는 것이 아니라 PGA의 사이즈를 더 키우는 쪽을 선택한다. 

 

수동/자동 메모리 관리기법의 선택

일반적으로 그냥 자동 관리 기법을 사용하는 편이 좋다. 
굉장히 특수한 상황, 책에서의 예제 대로면, 하루종일 한가지 작업만 수행된다던지, 특정 작업 한개만 매우크고 중요하다던지.. 그럴 때에만 특별히 alter session을 통해 수동으로 변경하고 작업하기를 추천한다. 


PGA와 UGA 요약

  • PGA는 특정 프로세스의 전용 공간. 서버 프로세스가 개별 세션마다 독립적으로 보관해야할 다양한 값들을 저장하는데 사용.
  • PGA 및 UGA는 heap 형태의 메모리 구조.
  • dedicated 서버 방식 사용시 UGA는 PGA안에 위치 / shared 서버 방식 사용시 SGA안에 위치.

 

레이블 (0)

  • 레이블 없음
댓글 쓰기...

첨부 파일  (0)

첨부 파일 추가하기
공유된 파일이 아직 없습니다.