You are on page 1of 5

How to determine if PGA is set properly

The PGA is a memory region containing data and control information for a single process (server or background). One PGA is allocated for each server process; the PGA is exclusive to that server process and is read and written only by Oracle code acting on behalf of that process. A PGA is allocated by Oracle when a user connects to an Oracle database and a session is created. In order to determine the proper size of PGA, we need to examine the measuring criteria from performance views. 1. Performance view V$PGASTAT Performance view V$PGASTAT displays PGA memory usage statistics as well as statistics about the automatic PGA memory manager when it is enabled (that is, when PGA_AGGREGATE_TARGET is set). Cumulative values in V$PGASTAT are accumulated since instance startup. Oracle official document about v$pgastat has good explanation for every field within that view.

To check the usage of PGA, we issued the following statement against v$pgastat. SQL> select name,value 2 from v$pgastat 3 where name in ('aggregate PGA target parameter', 4 'aggregate PGA auto target', 5 'total PGA inuse', 6 'total PGA allocated', 7 'over allocation count', 8 'extra bytes read/written', 9 'cache hit percentage'); NAME -------------------------------------------------aggregate PGA target parameter aggregate PGA auto target total PGA inuse total PGA allocated over allocation count extra bytes read/written cache hit percentage VALUE ---------550502400 34406400 1200735232 1520827392 573252 1.2234E+10 99.83

OraclePoint.com

7 rows selected. We noticed that “ total PGA inuse”is around 1.2G, which is far larger than “ aggregate PGA target”(550M). Similarly, “ total PGA allocated”is almost 3 times of “ aggregate PGA target” “over allocation count” . happen if the value of PGA_AGGREGATE_TARGET is too small and it in turn causes lots of system I/O, as indicated as “ extra bytes read/written” . In summary, the setting for PGA is not sufficient for current application. 2. Performance views V$SQL_WORKAREA and related Performance view V$SQL_WORKAREA displays information about work areas used by SQL cursors. Each SQL statement stored in the shared pool has one or more child cursors that are listed in the V$SQL view. V$SQL_WORKAREA lists all work areas needed by these child cursors. Within V$SQL_WORKAREA, what we need to examine for tuning PGA size are:  Optimal_executions -- number of times this work area ran in optimal mode without interacting with temporary tablespace  Onepass_executions -- number of times this work area ran in one-pass mode, which means sql execution need to interact with temporary tablespace once to get it finished  Multipasses_executions -- number of times this work area ran below the one-pass memory requirement, which means sql execution need to interact with temporary tablespace more than once to get it finished Here, we’ like to get summary information about executions criteria d from view v$sql_workarea. SQL> select sum(OPTIMAL_EXECUTIONS) OPTIMAL, 2 sum(ONEPASS_EXECUTIONS) ONEPASS , 3 sum(MULTIPASSES_EXECUTIONS) MULTIPASSES 4 from v$sql_workarea 5 where POLICY='AUTO'; OPTIMAL ONEPASS MULTIPASSES ---------- ---------- ----------40420912 41 0

OraclePoint.com

We have 41 ONEPASS upon output. That’ not bad because we have 0 s MULTIPASS. But, the ideal case is that all are OPTIMAL. Therefore, we need to do proper adjustment on PGA size. 3. Performance view V$SQL_WORKAREA_HISTOGRAM V$SQL_WORKAREA_HISTOGRAM displays the cumulative work area execution statistics (cumulated since instance startup) for different work area groups. The work areas are split into 33 groups based on their optimal memory requirements with the requirements increasing in powers of two. That is, work areas whose optimal requirement varies from 0 KB to 1 KB, 1 KB to 2 KB, 2 KB to 4 KB, ... and 2 TB to 4 TB. SQL> SELECT LOW_OPTIMAL_SIZE/1024 low_kb, 2 (HIGH_OPTIMAL_SIZE+1)/1024 high_kb, 3 optimal_executions optimal, 4 onepass_executions onepass, 5 multipasses_executions multipasses 6 FROM v$sql_workarea_histogram 7 WHERE total_executions != 0; LOW_KB HIGH_KB OPTIMAL ONEPASS MULTIPASSES ---------- ---------- ---------- ---------- ----------2 4 74592559 0 0 64 128 152005 0 0 128 256 1152234 0 0 256 512 31625 0 0 512 1024 1766394 0 0 1024 2048 2576760 0 0 2048 4096 549445 306 6 4096 8192 195631 246 0 8192 16384 1605 258 0 16384 32768 187 114 0 32768 65536 52 9 0 65536 131072 9 11 0 131072 262144 0 2 0 524288 1048576 0 1 0 1048576 2097152 0 1 0

OraclePoint.com

15 rows selected. From above output, work area in range of (2048,4096) incurs 306 ONEPASS and 6 MULTIPASS. Similarly, work area in other ranges also introduces ONEPASS and MULTIPASS. 4. Performance views V$SESSTAT, V$SYSSTAT AND V$STATNAME

SQL> 2 3 4 5

select n.name,sum(s.value) value from v$sesstat s,v$statname n where s.statistic#=n.statistic# and n.name like 'workarea executions%' group by n.name;

NAME VALUE -------------------------------------------------- ---------workarea executions - onepass 3 workarea executions - multipass 0 workarea executions - optimal 702865 SQL> 2 3 4 5 select n.name,sum(s.value) value from v$sysstat s,v$statname n where s.statistic#=n.statistic# and n.name like 'workarea executions%' group by n.name;

NAME VALUE -------------------------------------------------- ---------workarea executions - onepass 948 workarea executions - multipass 6 workarea executions - optimal 81119656

The joining query above also shows that the PGA size is not set properly because the number of ONEPASS and MULTIPASS are considerable. Adjusting PGA size

OraclePoint.com

Based on above findings, we should increase the PGA size through query view V$PGA_TARGET_ADVICE. SQL> SELECT round(PGA_TARGET_FOR_ESTIMATE/1024/1024) target_mb, 2 ESTD_PGA_CACHE_HIT_PERCENTAGE cache_hit_perc, 3 ESTD_OVERALLOC_COUNT 4 FROM v$pga_target_advice; TARGET_MB CACHE_HIT_PERC ESTD_OVERALLOC_COUNT ---------- -------------- -------------------66 95 37001 131 96 36811 263 96 33475 394 96 26833 525 100 22897 630 100 21332 735 100 19200 840 100 15690 945 100 11743 1050 100 6784 1575 100 0 2100 100 0 3150 100 0 4200 100 0 14 rows selected.

Clearly, setting PGA size to 1575MB can eliminate overallocation_count and gain maximum cache hit ratio. Command to change PGA size: Allter system set PGA_AGGREGATE_TARGET=1500m;

OraclePoint.com