Note 789011 - FAQ Oracle memory areas

03.04.2011 Page 1 of 11

SAP Note 789011 - FAQ: Oracle memory areas

Note Language: English Version: 41 Validity: Valid Since 09.03.2011

Summary

Symptom

1. What Oracle memory areas are there?

2. What parameters define the memory area sizes?

3. What are useful sizes for the individual memory areas?

4. How do I determine Oracle's current memory requirements?

5. How do I determine the PGA consumption of individual Oracle processes?

6. Where can I find details on the memory consumption of the shared pool?

7. How I can determine which objects are represented with the most blocksin the buffer pool?

8. What characteristic errors can occur during memory allocation?

9. What are the main reasons for a high PGA-allocation by a process?

10. How can I determine the chronological sequence of the PGA size?

11. Can I also check the Oracle memory consumption using operating systemtools?

Other termsFAQ, frequently asked questions

Reason and Prerequisites

Solution

1. What Oracle memory areas are there?

There is a distinction between shared memory areas that can be calledby all Oracle processes, and process-local memory, which is assignedto exactly one process in each case.

o System Global Area (SGA, shared memory)

- Buffer Pool (or "Data buffer", "Cache"): Buffer for the datablocks.

- Shared Pool : Comprises various ares, for example, buffer forparsed SQL statements ("Shared SQL Area" or "Shared CursorCache" or "Library Cache") or Oracle DDIC information("Dictionary Cache" or "Row Cache")

- Java Pool: Java buffer

- Large Pool : Buffer for special data (for example, when using

03.04.2011 Page 2 of 11


Multi-threaded server, RMAN with several I/O slaves, oractivating PARALLEL_AUTOMATIC_TUNING).

- Streams Pool (Oracle 10g or later): Pool for Oracle streams

- Redo Buffer: Buffer for redo log data.

o Program global area (PGA, process-local memory)

This is a buffer for sortings, Hash Joins, bitmap operations andother temporary local memory requirements (for example, during theparsing of SQL statements); if the buffer is no longer sufficient,the PSAPTEMP temporary tablespace is also used.

o Operating system process memory

More memory is needed for the administration of processes atoperating system level. While the text section (which contains theexecutable program) only exists once and is used by all processes,there are other areas locally, such as data or stack, for everyprocess. You must generally expect up to 6 MB operatingsystem-sided memory consumption for each Oracle process (WINDOWS:Oracle thread).

2. What parameters define the memory area sizes?

Unless otherwise specified, parameters are specified in "bytes".

o SGA: The size is indirectly determined by the size of the memoryareas contained.

- Buffer Pool: DB_BLOCK_BUFFERS (unit: Blocks) or DB_CACHE_SIZEwhen you use the dynamic SGA as described in Note 617416.

- Shared Pool : SHARED_POOL_SIZE

- Java Pool: JAVA_POOL_SIZE

- Large Pool : LARGE_POOL_SIZE

- Streams Pool (Oracle 10g or later): STREAMS_POOL_SIZE

- Redo Buffer: LOG_BUFFER

In addition, in the context of the dynamic SGA (Note 617416), youcan define the parameter SGA_MAX_SIZE which sets an upper limit forthe total size of the SGA. In general, you can only increase thesize of parameters, such as DB_CACHE_SIZE or SHARED_POOL_SIZE, upto the size defined by SGA_MAX_SIZE .

As of Oracle 10g, parameter SGA_TARGET is also available. You canset this instead of parameters DB_CACHE_SIZE, SHARED_POOL_SIZE,JAVA_POOL_SIZE, LARGE_POOL_SIZE and STREAMS_POOL_SIZE. Ifnecessary, Oracle configures and then adjusts the individual SGAcomponents within SGA_TARGET. In this context, when you stop thedatabase, double-underscore parameters are also written to theOracle profile to make a note of the current size of the individualmemory areas ( for example, __SHARED_POOL_SIZE, __DB_CACHE_SIZE).

03.04.2011 Page 3 of 11


However, this dynamic adjustment of the areas can be problematic insome cases, if one of the areas increases significantly in sizeand, as a result, other areas decrease significantly in size.Therefore,only use SGA_TARGET (if you use it at all) ifDB_CACHE_SIZE and SHARED_POOL_SIZE are set to sufficiently largevalues as well. In connection with SGA_TARGET, these parametersspecify lower limits for the area values, below which the valuescannot fall.

As of Oracle 11g, resize activitities may occur in the SGA, even ifthis was not configured explicitly. You can deactivate theseresizes if necessary using the parameter_MEMORY_IMM_MODE_WITHOUT_AUTOSGA = FALSE.

o PGA: The PGA allocation is dynamic and can be affected by theparameters SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZEand CREATE_BITMAP_AREA_SIZE or PGA_AGGREGATE_TARGET when you usethe automatic PGA administration (see Note 619876).

As of Oracle 11g, you can use the parameters MEMORY_TARGET andMEMORY_MAX_TARGET to define the total size of PGA and SGA(Automatic Memory Management, AMM). We do not recommend that youuse these parameters in the SAP environment.

o Operating system memory: The sizes of the areas are predefined bythe executable. However, adjustments are possible in individualcases:

- WINDOWS: You can use ORASTACK to reduce the stack size (Note130140).

- AIX: CONST pointers can be moved into the shared area to reducethe local process data (Note 750205).

3. What are useful sizes for the individual memory areas?

o Buffer Pool:

The buffer pool size generally has the greatest influence ondatabase performance. A larger buffer pool means that the systemneeds to carry out fewer time-consuming disk-accesses. Ensure thatthe data buffer quality is greater than 94%, as described in Note618868. The following applies to the buffer pool: the larger, thebetter (provided that sufficient physical memory is available).Note that the following side effects may occur with a large bufferpool:

- Oracle 9i or lower: The BEGIN BACKUP times are proportional tothe size of the buffer pool (see Note 875477).

- Oracle 10.2.0.3 or lower: The runtimes of operations thatinvolve a large data amount (for example, imports) may be muchlonger with large buffer pools due to block list scans inOracle (see Note 1028099).

o Shared Pool

The shared pool should be at least 400MB in size. In addition, you

03.04.2011 Page 4 of 11


should fulfill the approximations contained in Note 618868. Alsotake into account the recommendations given in Note 690241.

You should not configure the shared pool to a size much greaterthan that recommended in Note 690241, as this can cause seriousperformance problems. Also see Notes 767414 and 619188 ("row cachelock").

o Java Pool

If no Java components are used, the size of the Java pool can be 0.Java is not used in the R/3 standard.

o Large Pool

You do not have to configure the large pool explicitly. Memoryconsumption is small in comparison with the other memory areas.

o Streams Pool (Oracle 10g or later)

The streams pool can be defined with size 0 since streams are, bydefault, not used in the SAP environment

Streams are used as part of Data Pump (Note 1013049). Oracleautomatically allocates 10 % of the size of the shared pool in thebuffer pool for a streams pool configured with size 0. Thisimplicit reduction of the buffer pool must be taken into account ifyou want to use Data Pump.

o Redo Buffer

A good value for the Redo Buffer is 1MB, which should never beexceeded.

o PGA

The larger you set the *_AREA_SIZE parameter orPGA_AGGREGATE_TARGET, the more PGA operations can be performed inthe memory. As a starting point, refer to the recommendations inNotes 124361, 830576 and 619876.

4. How do I determine Oracle's current memory requirements?

In accordance with the information above, the areas for Java pool,large pool, streams pool and Redo Buffer may be neglected in terms ofsize. Therefore, the following formula approximately defines theamount of memory currently allocated by Oracle:

Oracle Memory = Buffer Pool + Shared Pool + PGA + Process Memory

Due to their static size, it is easy to determine the size of thebuffer and shared pools from the underlying parameters, butcalculating PGA memory consumption is more complicated, since this canvary over time. You can determine the actual consumption of PGA memoryusing the following query:

SELECT VALUE FROM V$PGASTAT WHERE NAME = 'total PGA allocated';

03.04.2011 Page 5 of 11


The following applies for the conventional PGA administration: Thelonger the database processes have already been running, the greaterthe PGA memory consumption, since no further PGA memory is released.

The size of the process-local memory is mainly determined by thenumber of Oracle processes. If you assume that a process allocates 5MB memory on average, you can determine the process-local memory asfollows:

SELECT MAX_UTILIZATION MAX_PROCESSES, 5 * MAX_UTILIZATION PROCESS_LOCAL_MEMORY_MBFROM V$RESOURCE_LIMITWHERE RESOURCE_NAME = 'processes';

5. How do I determine the PGA consumption of individual Oracle processes?

The following statement allows you to determine the Oracle sessionsand the client processes associated with them that currently have thehighest PGA consumption:

SELECT * FROM (SELECT SS.SID SID, TO_CHAR(SS.VALUE / 1024 / 1024, 9990.99) "PGA (MB)", SUBSTR(S.MACHINE, 1, 17) HOST, SUBSTR(S.PROGRAM, 1, 29) "PROGRAM", S.PROCESS "CLIENT PID" FROM V$SESSTAT SS, V$STATNAME SN, V$SESSION S WHERE SS.STATISTIC# = SN.STATISTIC# AND SN.NAME = 'session pga memory' AND S.SID = SS.SID ORDER BY VALUE DESC )WHERE ROWNUM <=20;

If the client processes are SAP work processes ("dw" in the PROGRAMname), the relevant work process can be identified by means of theclient-PID in transaction SM50 or SM66.

6. Where can I find details on the memory consumption of the shared pool?

There are several sources from which the size of the shared pools canbe determined. The calculated size can vary depending on the origin ofthe data:

o The memory consumption of the shared pool is determined byparameter SHARED_POOL_SIZE. Up to and including Oracle 9i, if youuse a non-dynamic SGA, there are also certain subcomponents of theshared pool (such as "db_block_buffers") that are created outsideof SHARED_POOL_SIZE. As a result, the memory consumption of theshared pool is sometimes several hundred MB larger than specifiedby SHARED_POOL_SIZE. You can use the following query to determinethe actual memory requirement of the shared pool:

03.04.2011 Page 6 of 11


SELECT SUM(BYTES) FROM V$SGASTAT WHERE POOL = 'shared pool';

You can use the following statement to determine the areas sortedaccording to size within the shared pool:

SELECT BYTES, NAME FROM V$SGASTAT WHERE POOL = 'shared pool'ORDER BY BYTES;

o The size that is displayed for SHARED_POOL_SIZE in transaction ST04was historically equated with the "Variable Size" of view V$SGA.However, this variable size also includes memory areas such as theLarge Pool or the Java Pool. The size displayed in ST04 wastherefore bigger than the SHARED_POOL_SIZE parameter in many cases.

o When you use the dynamic SGA on Oracle 9i, the freespace that isnot yet allocated under SGA_MAX_SIZE is also added to the "VariableSize", which is why the size displayed in ST04 for the Shared Poolcould be significantly higher than the value of theSHARED_POOL_SIZE parameter.

o As of Oracle 9i, the view V$SGA_DYNAMIC_COMPONENTS is available,which specifies the size of SHARED_POOL_SIZE correctly and which isaccessed by Transaction ST04 after you implement the correctionfrom Note 776021.

7. How I can determine which objects are represented with the most blocksin the buffer pool?

The following SQL statement returns the 20 segments that arerepresented with the most blocks in the buffer pool:

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE, ALLOC_MB, PERCENTFROM(SELECT OWNER, NVL(OBJECT_NAME, DECODE(DATA_OBJECT_ID, 0, '0 (UNUSED)', TO_CHAR(DATA_OBJECT_ID) || ' (UNDO?)')) OBJECT_NAME, OBJECT_TYPE, TO_CHAR(BLOCKS * 8192 / 1024 / 1024, 99990.99) ALLOC_MB, TO_CHAR(RATIO_TO_REPORT(BLOCKS) OVER () * 100, 990.99) PERCENT FROM (SELECT O.OWNER OWNER, O.OBJECT_NAME OBJECT_NAME, O.OBJECT_TYPE OBJECT_TYPE, B.OBJD DATA_OBJECT_ID, COUNT(*) BLOCKS, ROW_NUMBER() OVER (PARTITION BY O.DATA_OBJECT_ID ORDER BY O.OBJECT_TYPE) CLUSTRN FROM DBA_OBJECTS O, V$BH B WHERE

03.04.2011 Page 7 of 11


O.DATA_OBJECT_ID (+) = B.OBJD GROUP BY B.OBJD, O.OWNER, O.OBJECT_NAME, O.OBJECT_TYPE, O.DATA_OBJECT_ID ) WHERE CLUSTRN = 1 ORDER BY BLOCKS DESCWHERE ROWNUM <= 20;

8. What characteristic errors can occur during memory allocation?

o ORA-04031: unable to allocate <bytes> bytes of shared memory

ORA-04031 occurs if there is no longer sufficient space availablein the shared pool. This may be because:

- The shared pool is too small (less than 400MB)

- There are SQL statements that consume a lot of memory, due tolong IN lists, for example (see Note 133351).

- As of Oracle 9i: The sub-pools are too small (see Note 690241).

For further information, see Note 869006.

o ORA-04030: out of process memory when trying to allocate <bytes>bytes

The system issues the error ORA-04030 if it cannot allocate anymore PGA memory. This happens if the memory allocation reaches thelimits set by the operating system (for example, the virtualaddress space of a process, or available swap). In general, thiserror occurs on systems with 32-bit architecture that haverestricted virtual address space.

For example: In the case of an Oracle installation on a 32-bitWindows system, where the 3GB option is not activated, a total of2GB of virtual address space is available. Oracle can useapproximately 1.7GB of that. If you allocate 1GB for the bufferpool and 400MB for the shared pool, another 300MB of PGA memoryremains available to all Oracle processes. Error ORA-04030 occursif this limit is exceeded.

While all Oracle processes run as threads in a single operatingsystem process on Windows - and therefore, in the example above,ALL processes must share the remaining 300MB - on UNIX there is aseparate operating system process for every Oracle process. Thismeans that on a UNIX system, EACH INDIVIDUAL process can allocatethe rest of the available virtual memory as PGA memory.

If an ORA-04030 occurs, to solve the problem you can:

03.04.2011 Page 8 of 11


- Switch to a 64-bit operating system.

- Use the automatic PGA administration (Note 619876), so that PGAmemory is released again after being used.

- WINDOWS: Activate the 3GB option (see Note 142019).

- WINDOWS: Activate AWE (see Note 441663).

- LINUX: Configure an SGA greater than 3GB (see Note 804186)

- Restart all work processes regularly (see Note 101717). Thisalso restarts the Oracle shadow processes and releases the PGAmemory that was allocated so far. This is less useful if youare using automatic PGA administration.

- UNIX: Adjust the operating system parameters (such as ULIMITsettings or process-memory-limitation parameters; see also Note502782).

- Set event 10191 as described in Note 128221.

- Reducing the buffer pool (DB_CACHE_SIZE or DB_BLOCK_BUFFERS fornon-AWE, AWE_WINDOW_MEMORY for AWE) or shared pools so thatmore virtual memory is available for the PGA memory (Caution:this may negatively affect performance!).

- Reduction of the PGA parameters (Caution: this may negativelyaffect performance!).

- Use a Multi Threaded Server to reduce the number of Oracleprocesses (Caution: Note the restrictions from Note 70197)

- Avoid using USE_CONCAT hints in connection with long IN lists,since this combination can consume a great deal of PGA memorywhile parsing.

- Activate automatic PGA administration (WORKAREA_SIZE_POLICY =AUTO) in order to avoid a high PGA consumption in connectionwith INSERTs (refer to Note 71624 (18)).

See also Note 502782.

o ORA-12540: TNS:internal limit restriction exceeded

Error ORA-12540 during the connection setup often has the samecause as ORA-04030. Therefore, refer to the solutions describedabove under ORA-04030 (in addition to Note 513524).

o skgpspawn failed:category = 27143

This error (in the form of an alert log entry) is usually alsocaused by a memory limit. Therefore, refer to the solutionsdescribed above under ORA-04030.

o ORA-27102: out of memory

03.04.2011 Page 9 of 11


The system issues the error ORA-27102 if it cannot create the SGAin the defined size. See Note 743328.

o WARNING: EINVAL creating segment of size <size>

This warning appears in the alert log if the SGA is so large thatit must be split into several shared memory segments. See Note723744.

9. What are the main reasons for a high PGA-allocation by a process?

Obviously, the PGA allocation primarily depends on the size of the PGAparameters. The larger you set the *_AREA_SIZE parameter and thePGA_AGGREGATE_TARGET, the more PGA memory is available for eachoperation.

It is also important to note that a process can require several PGAmemory areas at the same time. For example, a complex BW statementwith 15 hash joins allocates the defined HASH_AREA_SIZE 15 times.

Bear in mind that the PGA is also used for other local operations.Several hundred MB of PGA memory may be required for parsing astatement with USE_CONCAT hints and a long IN list. This may mean thatthe PGA total exceeds the value

defined in PGA_AGGREGATE_TARGET (see Note 1266245).

10. How can I determine the chronological sequence of the PGA size?

Up to and including Oracle 9i, there was no standard way ofdetermining the chronological sequence of the PGA allocation.

As of Oracle 10g, you can determine the chronological sequence of theoverall PGA consumption using DBA_HIST_PGASTAT:

SELECT SUBSTR(S.END_INTERVAL_TIME, 1, 40) TIME,P.VALUE PGA_ALLOCATIONFROM DBA_HIST_SNAPSHOT S, DBA_HIST_PGASTAT PWHERE P.NAME = 'total PGA allocated' ANDS.SNAP_ID = P.SNAP_IDORDER BY P.SNAP_ID;

11. Can I also check the Oracle memory consumption using operating systemtools?

In principle, this is possible. However, in this case, the procedureis strongly dependent on the operating system, and you must takeaccount of several pitfalls (such as the problem described in Note825653 (49)). In general, an Oracle memory analysis in accordance withthis note is sufficient. If you also require operating systeminformation, contact your operating system partner for more specificdetails.

Header Data

Release Status: Released for Customer

03.04.2011 Page 10 of 11


Released on: 09.03.2011 16:19:23Master Language: GermanPriority: Recommendations/additional infoCategory: FAQPrimary Component: BC-DB-ORA Oracle

The Note is release-independent

Related Notes

Number Short Text

1266245 V$PGASTAT - more memory allocated than specified

1034126 ORA-00832 when using Oracle Data Pump

1028099 Long import runtimes for large db_cache_size

1013049 FAQ: Oracle Data Pump

896006 Fixes for reading order of Employer Tip Allocation (8027)

875477 Avoiding long runtimes with BEGIN BACKUP

832343 FAQ: Clustering factor

830576 Parameter recommendations for Oracle 10g

825653 Oracle: Common misconceptions

806554 FAQ: I/O-intensive database operations

804186 sga size > 2GB on Linux

776021 Incorrect shared pool size in ST04

771929 FAQ: Index fragmentation

767414 FAQ: Oracle latches

750631 Approximations for cost calculation of the CBO

750205 High memory usage with AIX5.2/5.3 and Oracle9.2

743328 Composite SAP note: ORA-27102

723744 WARNING: EINVAL creating segment of size <size>

712624 High CPU consumption by Oracle

690241 The Shared SQL Area in the Shared Pool and large SQL Stmnts

651060 FAQ: Oracle Parallel Execution

632556 Oracle 9.2.0.* database parameterization for BW

619876 Oracle9i: Automatic PGA Memory Management

619188 FAQ: Oracle wait events

618868 FAQ: Oracle performance

617416 Oracle9i: Dynamic SGA

541695 ORA-00470/ORA-00471/ORA-00472/ORA-00473/ORA-00474

502782 Composite SAP Note ora-4030

441663 USING > 3 GB of memory for Oracle on WINDOWS platforms

03.04.2011 Page 11 of 11


Number Short Text

142019 3GB Memory and Oracle 8 on Windows (NT or 2000)

133351 Short dumps due to Oracle error ORA 4031

130140 ORA-4030 on NT, out of process memory

128221 Increased memory consumption with Oracle >8.0.X

105047 Support for Oracle functions in the SAP environment

101717 Automatic restart of SAP R/3 work processes

70197 Is Multi-Threaded Server supported with SAP

Documents

Note 789011 - FAQ Oracle memory areas