태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

[티팩] PGA 크기가 급격히 증가할 때

오라클 2010.06.15 10:01
특정 프로세스의 PGA 크기가 급격히 증가하면 다양한 성능 문제를 유발할 수 있습니다. 예를 들어 보면 아래와 같습니다.
  • ORA-4030 에러가 발생할 수 있다. 단, OS차원의 Limit가 매우 크면(Unlimited?) ORA-4030 에러가 발생하기 전에 시스템이 죽어나간다.
  • PGA의 크기가 Physical RAM의 여유분보다 커지기 시작하면 과도한 Swapping이 발생하고 시스템의 성능이 전반적으로 저하된다.
  • 만일 SGA의 Lock되어 있지 않으면 SGA의 일부가 Swap Out되고 이런 경우에는 극단적인 library cache 래치 경합이 발생한다. 이쯤되면 수동으로 Oracle을 Restart해야하거나 PMON/SMON 등에 의해 자동으로 Restart됩니다.
PGA의 크기가 비정상적으로 증가하는 현상은 대부분 Oracle의 버그이거나 잘못된 프로그래밍에 의해 발생합니다. 이런 현상을 정밀하게 분석하기 위한 최고의 방법은 PGA Heap Dump를 수행하고, 해당 덤프 내용을 분석하는 것입니다.

여기서 한가지 문제가 발생합니다. PGA 크기가 급격히 증가해서 성능 문제가 발생하는 상황에서는 이를 간파하기도 쉽지 않고, 수동으로 Heap Dump를 수행하기도 쉽지 않습니다. 가령 1-2분만에 PGA 크기가 수GB로 증가하는 경우 시스템의 성능이 급격히 저하되기 때문에 작업이 원할하지 않을 수 있습니다.

다행히 오라클이 제공하는 진단 이벤트를 이용하면 이러한 일련의 작업을 자동화할 수 있습니다.

1. 다음과 같이 10261 진단 이벤트를 활성화합니다. Level은 KB를 의미합니다. 즉 아래와 같이 설정하면 "특정 프로세스의 PGA 크기가 100,000KB바이트를 넘으면 ORA-600 에러를 발생하라"라는 것을 의미합니다.

alter system set events '10261 trace name context forever, level 100000';
10261 진단 이벤트는 PGA의 크기가 지나치게 커지는 현상을 막는 일종의 응급처치로 종종 사용됩니다. 어디까지나 응급처치이지 해결책으로 남용되어서는 안됩니다.

2. 원하는 대로 동작하는지 확인해봅시다. 아래와 같이 PGA 크기가 커지는 경우 ORA-600 [723] 에러가 발생하는 것을 확인할 수 있습니다.

-- make big pga
declare
 type varchar2_array is table of varchar2(32767) index by pls_integer;
 vc  varchar2_array;
 v  varchar2(32767);
begin
 for idx in 1 .. 10000 loop
 v := rpad('x',32767,'x');
 vc(idx) := v;
 end loop;
 
 -- do something else
end;
/

ERROR at line 1:
ORA-00600: internal error code, arguments: [723], [41000], [pga heap], [], [],
[], [], []
3. 10261 이벤트와 함께 600 진단 이벤트를 설정합니다. 아래와 같이 설정하면 "ORA-600 에러가 발생하는 프로세스에 대해 0x20000001 레벨(Subheap의 Subheap까지 포함하라는 의미)로 PGA Heap Dump를 수행하라"는 의미가 됩니다.
alter system set events '600 trace name heapdump level 0x20000001';
4. 이제 다시 한번 PGA 사이즈가 급격히 커지면 다음과 같이 트레이스 파일에 PGA Heap Dump가 기록됩니다.
DDE: Problem Key 'ORA 600 [723]' was flood controlled (0x2) (incident: 44800)
ORA-00600: internal error code, arguments: [723], [41000], [pga heap], [], [], [], [], []
****** ERROR: PGA size limit exceeded: 102450812 > 102400000 *****
******************************************************
HEAP DUMP heap name="pga heap"  desc=11AFB098
 extent sz=0x206c alt=92 het=32767 rec=0 flg=2 opc=1
 parent=00000000 owner=00000000 nex=00000000 xsz=0xfff8 heap=00000000
 fl2=0x60, nex=00000000
EXTENT 0 addr=39150008
  Chunk 39150010 sz=    24528    free      "               "
  Chunk 39155fe0 sz=    40992    freeable  "koh-kghu call  "  ds=0D4D9A60
EXTENT 1 addr=39140008
  Chunk 39140010 sz=    24528    free      "               "
  Chunk 39145fe0 sz=    40992    freeable  "koh-kghu call  "  ds=0D4D9A60
...
5. 티팩에서는 좀 더 능동적인 방법으로 동일한 작업을 수행할 수 있습니다. 아래와 같은 코드로 session pga memory의 누적값이 100000000B를 넘으면 Heap Dump Report를 자동으로 수행하게 할 수 있습니다.
-- create report
col report_id new_value report_id

select tpack_server.create_report('Heap Dump') as report_id from dual;

exec tpack_server.add_parameter('&report_id', 'dump_level', '0x20000001');
exec tpack_server.add_parameter('&report_id', 'get_whole_contents', 0);

exec tpack_server.add_condition('&report_id', 'STAT', 'session pga memory', '>100000000', 'SUM');

exec tpack_server.register_report('&report_id');

-- start server
exec tpack_server.start_server;
이제 PGA 크기가 100000000B 이상 커지면 아래와 같이 tpack.heap_dump 프로시저가 자동으로 수집되는 것을 로그로부터 확인할 수 있습니다.
Fri Jun 11 06:19:10 GMT+00:00 2010 : Session 142 got! sum=659645392, name = session pga memory
...
Fri Jun 11 06:27:50 GMT+00:00 2010 : executing report 1:142:1973827792 for session 142
Fri Jun 11 06:27:55 GMT+00:00 2010 : executing report = begin tpack.heap_dump(  dump_level=>'0x20000001', get_whole_contents=>0,  session_id => 142); end;
...
6. 이제 티팩이 제공하는 Heap Dump Analysis 기능을 이용해서 덤프 파일의 내용을 분석하면 됩니다.
select * from table(tpack.heap_file_report('C:\oracle\diag\rdbms\ukja1106\ukja1106\trace\ukja1106_ora_3640.trc'));

TYPE     HEAP_NAME        ITEM             ITEM_COUNT  ITEM_SIZE  HEAP_SIZE      RATIO
-------- ---------------- ---------------- ---------- ---------- ---------- ----------
HEAP     pga heap                                   0      97.14      97.14        100
HEAP     top call heap                              0        .18        .18        100
HEAP     top uga heap                               0        .31        .31        100
CHUNK    pga heap         free                   1554       36.2       97.1       37.3
CHUNK    pga heap         recreate                  9          0       97.1          0
CHUNK    pga heap         perm                     14          0       97.1          0
CHUNK    pga heap         freeable               1597       60.7       97.1       62.5
CHUNK    top uga heap     recreate                  1          0         .3       19.9
CHUNK    top uga heap     free                      5          0         .3          0
CHUNK    top uga heap     freeable                  4         .2         .3       79.9
CHUNK    top call heap    free                      3         .1         .1       65.5
CHUNK    top call heap    recreate                  2          0         .1          1
CHUNK    top call heap    freeable                  1          0         .1       33.3
CHUNK    top call heap    perm                      1          0         .1          0
OBJECT   pga heap         kews sqlstat st           1          0       97.1          0
OBJECT   pga heap         pesom.c:Proces            3          0       97.1          0
...
오라클이 제공하는 진단 이벤트를 적절히 활용하면 의외의 효과를 얻을 수 있다는 것을 알 수 있습니다. 더불어 티팩의 사용 예에서 보듯이 좀 더 능동적인 모니터링 기법을 활용하는 것 또한 중요합니다. 무엇보다 중요한 것은 PGA Heap Dump 분석을 통해 PGA 크기가 급격히 증가하는 원인을 정밀하게 분석하는 것이겠지요.
저작자 표시
신고
Trackback 0 : Comment 0

Write a comment

티스토리 툴바