Tuning the Program Global Area and the User Global Area:

========================================================

In this recipe, we will see the Program Global Area (PGA) and the User Global Area
(UGA) and how to tune them for maximum performance.

The PGA is used to store real values of bind variables, sort areas, and cursor
state information. In a dedicated server environment this area is in private user
memory. Only in a shared-server environment the session stack space remains in the
PGA, while session data and cursor state are moved into the shared pool.

The following steps will demonstrate tuning the PGA and UGA:
1. Connect to Oracle Enterprise Manager as SYSDBA.

2. Go to Advisor Central.

3. Choose Memory Advisors.

4. Choose the PGA palette to show or change the size of PGA.

5. Connect to SQL*Plus as SYSDBA:

CONNECT / AS SYSDBA

6. Show the parameters related to cursors:

SHOW PARAMETER CURSOR

In step 6 and step 7, we query the statistics to see the space used by the current
session and the maximum UGA space used by all users, respectively.

7. Query for the total session memory:

SELECT SUM(VALUE) AS "session uga memory"
FROM V$MYSTAT, V$STATNAME
WHERE V$STATNAME.NAME = 'session uga memory'
AND V$MYSTAT.STATISTIC# = V$STATNAME.STATISTIC#;

8. Query for the session UGA memory:

SELECT SUM(VALUE) AS "session uga memory max"
FROM V$SESSTAT, V$STATNAME
WHERE V$STATNAME.NAME = 'session uga memory max'
AND V$SESSTAT.STATISTIC# = V$STATNAME.STATISTIC#;

Private information about the user session, such as private data and cursor state
are stored in the UGA. The UGA is located in the PGA when using dedicated server
environments, and inside the Shared Pool when using shared servers.

In step 5, we have seen the parameters related to cursor management. Let's explain
their use. OPEN_CURSORS defines the number of concurrent cursors that a user
process can use to reference private SQL areas. Increasing the value associated to
this parameter allows the user to use more cursors simultaneously, but the memory
consumption will be greater.

SESSION_CACHED_CURSORS allows defining the number of session cursors cached.

Setting this parameter to a value greater than zero results in a performance gain,
where there are repeated parse calls to the same SQL statements. Closed cursors
will be cached within the session, ready to be reused.
The last parameter, CURSOR_SHARING, allows us to define whether the cursors are
shared only when they match exactly (using EXACT) or also in other situations
(using FORCE and SIMILAR).