Archive for the ‘Oracle Memory’ Category

PGA

Program Global Area (PGA)

The Program Global Area or Process Global Area (PGA) is a memory region that contains data and control information for a single server process or a single background process. The PGA is allocated when a process is created and deallocated when the process is terminated.  The total PGA memory allocated by each server process attached to an Oracle instance is also referred to as the aggregated PGA memory allocated by the instance.

Contents of PGA:

The contents of the PGA memory varies, depending whether the instance is running in a Dedicated Server or Shared Server configuration. Generally the PGA memory includes these components:

Private SQL area:

Contains data such as bind information and runtime memory structures. Each session that issues a SQL statement has a private SQL area. Each user that submits the same SQL statement has his or her own private SQL area that uses a single shared SQL area. Thus, many private SQL areas can be associated with the same shared SQL area. The private SQL area of a cursor is divided into two areas:

Persistent area: Contains bind information, and is freed only when the cursor is closed

Run-time area: Created as the first step of an execute request. For INSERT, UPDATE, and DELETE commands, this area is freed after the statement has been executed. For queries, this area is freed only after all rows are fetched or the query is canceled.

The location of private SQL area depends on the type of connection established for the session. In a Dedicated Server environment, the private SQL areas are located in the PGA of their server process. In a Shared Server environment, the private SQL areas are located in the SGA.

The management of private SQL areas is the responsibility of the User Process. The number of Private SQL areas that a User Process can allocate is always limited by the initialization parameter OPEN_CURSORS. The default value of this parameter is 50.

Session Memory:

Consists of memory allocated to hold a session’s variables and other information related to the session. For a Shared Server environment, the session memory is shared and not private.

SQL Work Areas:

Used for memory-intensive operations such as: Sort, Hash-join, Bitmap merge, Bitmap create. The size of a work area can be controlled and tuned.

Beginning with Oracle9i, the size of the work area can be automatically and globally managed. This is enabled by setting the WORKAREA_SIZE_POLICY parameter to AUTO, which is the default, and the PGA_AGGREGATE_TARGET initialization parameter. The PGA_AGGREGATE_TARGET parameter is set by the DBA to specify the target aggregate amount of PGA memory available to the instance. This parameter is only a target and can be dynamically modified at the instance level by the DBA. It will accept a number of bytes, kilobytes, megabytes or gigabytes. When these parameters are set, sizing of work areas becomes automatic and all *_AREA_SIZE parameters are ignored for these sessions.

Prior to Oracle9i, the DBA controlled the maximum size of SQL work areas by setting the following parameters: SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE, and CREATE_BITMAP_AREA_SIZE. Setting these parameters can be difficult because the maximum work area size is ideally selected on the basis of the data input size and the total number of work areas active in the system. These two factors vary a lot from one work area to another and from one time to another. Thus, these parameters are hard to tune under the best circumstances.

 

 

PGA Memory Management for Dedicated Mode

You can automatically and globally manage the size of SQL work areas. The database administrator simply needs to specify the total size dedicated to PGA memory for the Oracle instance by setting the initialization parameter PGA_AGGREGATE_TARGET. The specified number (for example, 2G) is a global target for the Oracle instance, and Oracle tries to ensure that the total amount of PGA memory allocated across all database server processes never exceeds this target.

 

There are fixed views and columns that provide PGA memory use statistics. Most of these statistics are enabled when PGA_AGGREGATE_TARGET is set.

  • Statistics on allocation and use of work area memory can be viewed in the following dynamic performance views:

V$SYSSTAT

V$SESSTAT

V$PGASTAT

V$SQL_WORKAREA

V$SQL_WORKAREA_ACTIVE

  • The following three columns in the V$PROCESS view report the PGA memory allocated and used by an Oracle process:

PGA_USED_MEM

PGA_ALLOCATED_MEM

PGA_MAX_MEM

Note:

The automatic PGA memory management mode applies to work areas allocated by both dedicated and shared Oracle database servers.

Advertisements

Oracle Memory Structure Diagram

Oracle SQL Execution Steps

All Oracle SQL statements must be processed the first time that they execute (unless they are cached in the library cache). and SQL execution steps include:

  1. A syntax check – Are all keywords present "select . . . from", etc . .

  2. A semantic check against the dictionary – Are all table names spelled correctly, etc.

  3. The creation of the cost-based decision tree of possible plans

  4. The generation of the lowest cost execution plan

  5. Binding the execution plan – This is where the table–> tablespace –> datafile translation occurs.

  6. Executing the query and fetching the rows. 

Once the execution plan is created, it is stored in the library cache (part of the shared_pool_size) to facilitate re-execution.  There are two types of parses:

  • Hard parse – A new SQL statement must be parsed from scratch.  (See hard parse ratio, comparing hard parses to executes).  If the database is parsing every statement that is executing, the parse to execute ratio will be close to 1% (high hard parses), often indicating non-reentrant SQL that does not use host variables (see cursor_sharing=force).
  • Soft parse – A reentrant SQL statement where the only unique feature are host variables. (See soft parse ratio, comparing soft parses to executes).  The best-case scenario is a parse to execute ratio of 100% which would indicate an application with fully reentrant SQL that “parses SQL once and executes many times” (also see your setting for session_cached_cursors, as this effects the reentrancy of an SQL statement).  

Excessive hard parsing can occur when your shared_pool_size is too small (and reentrant SQL is paged out), or when you have non-reusable SQL statements without host variables.  See the cursor_sharing parameter for an easy way to make SQL reentrant and remember that you should always use host variables in you SQL so that they can be reentrant.

For more details, read this SQL Execution Steps on BURLESON.