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 VALUE
-------------------------------------------------- ----------
aggregate PGA target parameter 550502400
aggregate PGA auto target 34406400
total PGA inuse 1200735232
total PGA allocated 1520827392
over allocation count 573252
extra bytes read/written 1.2234E+10
cache hit percentage 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’d like to get summary information about executions criteria

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’ s not bad because we have 0
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> select n.name,sum(s.value) value

2 from v$sesstat s,v$statname n
3 where s.statistic#=n.statistic#
4 and n.name like 'workarea executions%'
5 group by n.name;

NAME VALUE
-------------------------------------------------- ----------
workarea executions - onepass 3
workarea executions - multipass 0
workarea executions - optimal 702865

SQL> select n.name,sum(s.value) value

2 from v$sysstat s,v$statname n
3 where s.statistic#=n.statistic#
4 and n.name like 'workarea executions%'
5 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