how to use automatic shared memory management

How To Use Automatic Shared Memory Management (ASMM) In Oracle10g [ID 295626.1]

Modified 03-MAR-2010 Type BULLETIN Status PUBLISHED

Applies to:

Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.1Information in this document applies to any platform.

Purpose

Checked for relevance on 3-4-2010.

The main goal of this document is to show you how to put in place the ASMM facility introduced with Oracle10g, how to configure it, and also some examples on how to monitor its activity.

NOTE: ASMM can still be used on 11g instead of the new 11g Automatic Memory Management (AMM) setting MEMORY_TARGET=0 and SGA_TARGET > 0

Scope and Application

All the DBAs and users concerned with Database Administration activities.

How To Use Automatic Shared Memory Management (ASMM) In Oracle10g

The ASMM Facility, How to Configure it and Review its Effect

1. Concept

Starting with Oracle version 9.0.1, some SGA parameters have been defined as 'Dynamic' parameters. The "ALTER SYSTEM" command may be used to grow/shrink their current values.

The whole SGA size is limited by the SGA_MAX_SIZE parameter that is the defined upper bound. Each SGA parameter is allocated in terms of Granules that is the Allocation Unit. The Granule size will depend on the SGA_MAX_SIZE value and hardware platform.

Depending on the 9i version, the following parameters have been defined as dynamic parameters:

9.0.1: Shared Pool and Default Buffer Cache

9.2.0: Shared Pool, Default Buffer Cache, Large Pool

When you grow/shrink the dynamic size of one of the above parameters, the freed memory won't be reallocated to another dynamic component automatically. You must do it manually if needed.

In 10G version, the ASMM has been introduced to relieve DBAs from sizing some parts of the SGA by themselves.

When enabled, it lets Oracle decide of the right size for some components of the SGA:

SHARED POOL LARGE POOL JAVA POOL DB CACHE (using the DB_BLOCK_SIZE value)

They are called auto-tuned parameters.

The main objectives to justify this new functionality are: Distribute the available memory depending of the current Workload.

The MMAN process will take some regular memory snapshots to evaluate the needs and thereby the dispatching of the usable memory.

Enhance the memory usage depending of the activity. Avoid the memory errors like ORA-4031.

To get more details about the ASMM concepts, you can read the <note:257643.1 Oracle Database 10g Automated SGA Memory Tuning .

2. Configuration

The ASMM is driven by one init parameter: SGA_TARGET.

When set to 0, the ASMM is disabled and you run with the old method, so you need to define the above auto-tuned parameters by yourself.The default value for SGA_TARGET is 0 so ASMM disabled.

The conditions to enable the ASMM mechanism are: STATISTICS_LEVEL=TYPICAL or ALL SGA_TARGET > 0

When you use a value greater than 0, the ASMM is enabled and the memory will be spread between all components: auto-tuned and manual parameters.

The SGA_TARGET value will therefore define the memory size sharable between auto-tuned and manual parameters.

The manual parameters are: DB__CACHE_SIZE DB_nK_CACHE_SIZE (non default block size) LOG_BUFFER

https://support.oracle.com/CSP/main/article?cmd=show&id=257643.1&type=NOT

FIXED SGA STREAMS_POOL_SIZE

Amonst these manual parameters, some of them are modifiable or fixed (defined at startup only):

Modifiable: DB__CACHE_SIZE, STREAMS_POOL_SIZE Fixed: DB_nK_CACHE_SIZE, FIXED SGA, LOG_BUFFER

The SGA_TARGET will be limited by the SGA_MAX_SIZE value. The SGA_MAX_SIZE cannot be modified dynamically.

SQL> show parameter sga_max

NAME TYPE VALUE------------------------------------ ----------- -----sga_max_size big integer 300M

If you try to define a larger SGA_TARGET, you will get the following message:

SQL> alter system set sga_target=400M;alter system set sga_target=400M*ERROR at line 1:ORA-02097: parameter cannot be modified because specified value is invalidORA-00823: Specified value of sga_target greater than sga_max_size

3. Some Examples

3.1 Manual to ASMM

This can be the case when you just upgraded your database from an older version.

The SGA_TARGET is non defined, so 0 by default.

SQL> show parameter sga

NAME TYPE VALUE---------------- ----------- -------lock_sga boolean FALSEpre_page_sga boolean FALSEsga_max_size big integer 164M <<<<<<<sga_target big integer 0

All the SGA parameters have been set manually:

SQL> show parameter size

NAME TYPE VALUE

------------------------------------ ----------- -------------------bitmap_merge_area_size integer 1048576create_bitmap_area_size integer 8388608db_block_size integer 8192db_cache_size big integer 24M <<<<<<<<<<<db_keep_cache_size big integer 0db_recovery_file_dest_size big integer 2Gdb_recycle_cache_size big integer 0db_16k_cache_size big integer 0db_2k_cache_size big integer 0db_32k_cache_size big integer 0db_4k_cache_size big integer 0db_8k_cache_size big integer 0global_context_pool_size stringhash_area_size integer 131072java_max_sessionspace_size integer 0java_pool_size big integer 48M <<<<<<<<large_pool_size big integer 8M <<<<<<<<<max_dump_file_size string UNLIMITEDobject_cache_max_size_percent integer 10object_cache_optimal_size integer 102400olap_page_pool_size big integer 0parallel_execution_message_size integer 2148sga_max_size big integer 164Mshared_pool_reserved_size big integer 4Mshared_pool_size big integer 80M <<<<<<<<<sort_area_retained_size integer 0sort_area_size integer 65536streams_pool_size big integer 0workarea_size_policy string AUTO

So the auto-tuned parameters are:

DB_CACHE_SIZE=24MSHARED_POOL_SIZE=80MLARGE_POOL_SIZE=8MJAVA_POOL_SIZE=48M

4M are reserved for the other manual parameters.

SQL> show sga

Total System Global Area 171966464 bytesFixed Size 787988 bytesVariable Size 145750508 bytesDatabase Buffers 25165824 bytesRedo Buffers 262144 bytes

You decide to switch in ASMM mode:

SQL> alter system set sga_target=100M;

System altered.


NAME TYPE VALUE----------------------------- ----------- -----lock_sga boolean FALSEpre_page_sga boolean FALSEsga_max_size big integer 164Msga_target big integer 164M

The SGA_TARGET has been adjusted silently to support the initial values for the auto-tuned parameters as listed in the V$SGA_DYNAMIC_COMPONENTS view.

SQL> select component, current_size, min_size, user_specified_size from v$sga_dynamic_components;

COMPONENT CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE------------------------------ ------------ ---------- -------------------shared pool 80 80 80large pool 8 8 8java pool 48 48 48streams pool 0 0 0DEFAULT buffer cache 24 24 24KEEP buffer cache 0 0 0RECYCLE buffer cache 0 0 0DEFAULT 2K buffer cache 0 0 0DEFAULT 4K buffer cache 0 0 0DEFAULT 8K buffer cache 0 0 0DEFAULT 16K buffer cache 0 0 0DEFAULT 32K buffer cache 0 0 0OSM Buffer Cache 0 0 24

13 rows selected.

This is a particular case when the SGA_MAX_SIZE parameter has been initialized by Oracle from the different init SGA parameters.

You don't have any free memory available to grow the dynamic sizes.

SQL> select * from v$sga_dynamic_free_memory;

CURRENT_SIZE------------ 0

If you have set the SGA_MAX_SIZE beyond the cumulative size of the different

SGA parameters, let say to 300M:


System altered.


NAME TYPE VALUE------------------------------------ ----------- -----------lock_sga boolean FALSEpre_page_sga boolean FALSEsga_max_size big integer 300Msga_target big integer 164M

SQL> select current_size/1024/1024 "CURRENT_SIZE" from v$sga_dynamic_free_memory;

CURRENT_SIZE------------------- 136

So you dispose now of 136M free for SGA expansion.

3.2 Increase/Reduce the SGA_TARGET

You have the means to change dynamically the size of the sga_target.


System altered.


NAME TYPE VALUE------------------------------------ ----------- -----lock_sga boolean FALSEpre_page_sga boolean FALSEsga_max_size big integer 300Msga_target big integer 200M

SQL> select component, current_size/1024/1024 "CURRENT_SIZE", min_size/1024/1024 "MIN_SIZE", user_specified_size/1024/1024 "USER_SPECIFIED_SIZE" from v$sga_dynamic_components;

COMPONENT CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE------------------------------ ------------ ---------- -------------------shared pool 80 80 80large pool 8 8 8java pool 48 48 48

streams pool 0 0 0DEFAULT buffer cache 60 24 24KEEP buffer cache 0 0 0RECYCLE buffer cache 0 0 0DEFAULT 2K buffer cache 0 0 0DEFAULT 4K buffer cache 0 0 0DEFAULT 8K buffer cache 0 0 0DEFAULT 16K buffer cache 0 0 0DEFAULT 32K buffer cache 0 0 0OSM Buffer Cache 0 0 24

We can see that the additional space has been used automatically. The DB_CACHE_SIZE has grown from 24M to 60M.

SGA SIZE = 80M+8M+48M+60M=196M so 4M are again reserved for the manual parameters.

We can also reduce the space reserved for auto-tuned parameters:

SQL> alter system set sga_target = 160M;alter system set sga_target = 160M*ERROR at line 1:ORA-02097: parameter cannot be modified because specified value is invalidORA-00827: could not shrink sga_target to specified value

The above example illustrates the fact that we cannot reduce the size below the sum of minimum values (MIN_SIZE): 80M+8M+48M+24M+4M (manual parameters)=164M.

Oracle will decide where to allocate the added space depending on the needs for each auto-tuned components based on the MMAN survey:


System altered.

select component, current_size/1024/1024 "CURRENT_SIZE", min_size/1024/1024 "MIN_SIZE", user_specified_size/1024/1024 "USER_SPECIFIED_SIZE" from v$sga_dynamic_components;

COMPONENT CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE---------------------------------------------------------------- ------------ ---------- -----------shared pool 80 80 80large pool 8 8 8java pool 48 48 48streams pool 0 0 0DEFAULT buffer cache 160 24 24 <<<<<<

KEEP buffer cache 0 0 0RECYCLE buffer cache 0 0 0DEFAULT 2K buffer cache 0 0 0DEFAULT 4K buffer cache 0 0 0DEFAULT 8K buffer cache 0 0 0DEFAULT 16K buffer cache 0 0 0DEFAULT 32K buffer cache 0 0 0OSM Buffer Cache 0 0 24

The DB_CACHE_SIZE has been raised from 24M to 160M so all the added memory has been allocated to the buffer cache. It won't be necessary the case at each time.

As we said above, the SGA_TARGET includes both the auto-tuned and the manual parameters. When you decide to raise a manual value, it will influence the auto-tuned part:

SQL> show sga

Total System Global Area 314572800 bytesFixed Size 788692 bytesVariable Size 145749804 bytesDatabase Buffers 167772160 bytesRedo Buffers 262144 bytes

SQL> alter system set streams_pool_size=10M;

System altered.

select component, current_size/1024/1024 "CURRENT_SIZE", min_size/1024/1024 "MIN_SIZE", user_specified_size/1024/1024 "USER_SPECIFIED_SIZE", last_oper_type "TYPE" from v$sga_dynamic_components;

SQL> /

COMPONENT CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE TYPE------------------------------ ------------ ---------- ------------------- --------shared pool 80 80 80 STATIClarge pool 8 8 8 STATICjava pool 48 48 48 STATICstreams pool 12 0 12 GROW

<<<<<<<<<<<DEFAULT buffer cache 148 24 24 SHRINK <<<<<KEEP buffer cache 0 0 0 STATICRECYCLE buffer cache 0 0 0 STATICDEFAULT 2K buffer cache 0 0 0 STATICDEFAULT 4K buffer cache 0 0 0 STATICDEFAULT 8K buffer cache 0 0 0 STATICDEFAULT 16K buffer cache 0 0 0 STATICDEFAULT 32K buffer cache 0 0 0 STATICOSM Buffer Cache 0 0 24 STATIC

The GROW and SHRINK operation types appear for streams pool and default buffer cache. The STREAMS_POOL_SIZE value has been rounded to 12M based on the GRANULE_SIZE of the component:

SQL> select component, granule_size/1024/1024 "GRANULE_SIZE(Mb)" from v$sga_dynamic_components;

COMPONENT GRANULE_SIZE(Mb)------------------------------ ----------------shared pool 4large pool 4java pool 4streams pool 4DEFAULT buffer cache 4KEEP buffer cache 4RECYCLE buffer cache 4DEFAULT 2K buffer cache 4DEFAULT 4K buffer cache 4DEFAULT 8K buffer cache 4DEFAULT 16K buffer cache 4DEFAULT 32K buffer cache 4OSM Buffer Cache 4

You can find the history of the resize operations in the V$SGA_RESIZE_OPS view:

SQL> select component, oper_type, oper_mode, initial_size/1024/1024 "INITIAL", TARGET_SIZE/1024/1024 "TARGET", FINAL_SIZE/1024/1024 "FINAL", status from v$sga_resize_ops;

COMPONENT OPER_TYPE OPER_MODE INITIAL TARGET FINAL STATUS------------------------------ ------------- --------- ---------- ---------- ---------- ---------DEFAULT buffer cache SHRINK MANUAL 160 148 148 COMPLETEstreams pool GROW MANUAL 0 12 12 COMPLETE

If you decide to decrease the sga_target, you will influence only the auto-tuned sizes, the manual parameters will stay untouched.


SQL> select component, current_size/1024/1024 "CURRENT_SIZE", min_size/1024/1024 "MIN_SIZE", user_specified_size/1024/1024 "USER_SPECIFIED_SIZE", last_oper_type "TYPE" from v$sga_dynamic_components;

COMPONENT CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE TYPE------------------------------ ------------ ---------- ------------------- -------------shared pool 80 80 80 STATIClarge pool 8 8 8 STATICjava pool 48 48 48 STATICstreams pool 12 0 12 GROWDEFAULT buffer cache 48 24 24 SHRINKKEEP buffer cache 0 0 0 STATICRECYCLE buffer cache 0 0 0 STATICDEFAULT 2K buffer cache 0 0 0 STATICDEFAULT 4K buffer cache 0 0 0 STATICDEFAULT 8K buffer cache 0 0 0 STATICDEFAULT 16K buffer cache 0 0 0 STATICDEFAULT 32K buffer cache 0 0 0 STATICOSM Buffer Cache 0 0 24 STATIC

The lowest limit for sga_target has become now: SUM(MIN_SIZE) for all auto-tuned parameters + CURRENT_SIZE(streams_pool) + 4M = 176MIf you try to override this limit, you will get the ORA-00827 error code.

3.3 Increase/Reduce the auto-tuned parameters

You can also decide to change the default distribution chosen by the MMAN process.

SQL> alter system set shared_pool_size=100M;

System altered.

SQL>select component, current_size/1024/1024 "CURRENT_SIZE", min_size/1024/1024 " user_specified_size/1024/1024 "USER_SPECIFIED_SIZE", last_oper_type "TYPE" from v$sga_dynamic_components;

COMPONENT CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE TYPE------------------------------ ------------ ---------- ------------------- -------shared pool 100 80 100 GROW <<<<<<

large pool 8 8 8 STATICjava pool 48 48 48 STATICstreams pool 12 0 12 GROWDEFAULT buffer cache 28 24 24 SHRINKKEEP buffer cache 0 0 0 STATICRECYCLE buffer cache 0 0 0 STATICDEFAULT 2K buffer cache 0 0 0 STATICDEFAULT 4K buffer cache 0 0 0 STATICDEFAULT 8K buffer cache 0 0 0 STATICDEFAULT 16K buffer cache 0 0 0 STATICDEFAULT 32K buffer cache 0 0 0 STATICOSM Buffer Cache 0 0 24 STATIC

The query output above shows that the SHARED_POOL_SIZE has been well resized to 100M. Both the CURRENT_SIZE and USER_SPECIFIED_SIZE columns have been reset.The 20M have been taken from the default buffer cache which has dropped from 48M to 28M.

If you continue to do it:

SQL> alter system set shared_pool_size=180M;alter system set shared_pool_size=180M*ERROR at line 1:ORA-02097: parameter cannot be modified because specified value is invalidORA-04033: Insufficient memory to grow pool

The memory size increase for an auto-tuned parameter will be dependent on: SGA_TARGET (200M in this case). MIN_SIZE for the other auto-tuned parameters CURRENT_SIZE for the manual parameters resized manually SIZE already allocated for fixed parameters (4M)

The formula will be: SGA_TARGET - ((SUM(MIN_SIZE for other auto-tuned parameters) + (CURRENT_SIZE for manual parameters) + (size allocated for fixed parameters))

so Memory available for increase: 200M - ((8M + 48M + 24M)) + (12M) + (4M)) = 104M

SQL> alter system set shared_pool_size=104M

System altered.


COMPONENT CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE TYPE------------------------------ ------------ ---------- ------------------- -------------shared pool 104 80 104 GROW <<<<<<<<<<<<large pool 8 8 8 STATICjava pool 48 48 48 STATICstreams pool 12 0 12 GROWDEFAULT buffer cache 24 24 24 SHRINKKEEP buffer cache 0 0 0 STATICRECYCLE buffer cache 0 0 0 STATICDEFAULT 2K buffer cache 0 0 0 STATICDEFAULT 4K buffer cache 0 0 0 STATICDEFAULT 8K buffer cache 0 0 0 STATICDEFAULT 16K buffer cache 0 0 0 STATICDEFAULT 32K buffer cache 0 0 0 STATICOSM Buffer Cache 0 0 24 STATIC

If you want continue to increase the shared pool, it will be necessary to raise now the SGA_TARGET value.

When you raise the size of an auto-tuned parameter, the CURRENT_SIZE reflects synchronously this action as shown above.

This isn't the case when you decrease one of the auto-tuned parameters:

SQL> alter system set shared_pool_size=80M;

System altered.

SQL> select component, current_size/1024/1024 "CURRENT_SIZE", min_size/1024/1024 "MIN_SIZE",user_specified_size/1024/1024 "USER_SPECIFIED_SIZE", last_oper_type "TYPE" from v$sga_dynamic_components;

COMPONENT CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE TYPE------------------------------ ------------ ---------- ------------------- -------------shared pool 104 80 80 GROWlarge pool 8 8 8 STATICjava pool 48 48 48 STATICstreams pool 12 0 12 GROWDEFAULT buffer cache 24 24 24 SHRINKKEEP buffer cache 0 0 0 STATICRECYCLE buffer cache 0 0 0 STATICDEFAULT 2K buffer cache 0 0 0 STATICDEFAULT 4K buffer cache 0 0 0 STATICDEFAULT 8K buffer cache 0 0 0 STATICDEFAULT 16K buffer cache 0 0 0 STATICDEFAULT 32K buffer cache 0 0 0 STATIC

OSM Buffer Cache 0 0 24 STATIC

Only the USER_SPECIFIED_SIZE shows the shrink operation. However the 20M will be available by the ASMM process if needed to be redistributed..

Finally you can check the history of resize operations like below:

SQL> select component, oper_type, oper_mode, initial_size/1024/1024 "INITIAL", TARGET_SIZE/1024/1024 "TARGET", FINAL_SIZE/1024/1024 "FINAL", status, TO_CHAR(end_time, 'DD/MM/YYYY HH:MI:SS') "DATE" from V$SGA_RESIZE_OPS; order by end_time;

COMPONENT OPER_TYPE OPER_MODE INITIAL TARGET FINAL STATUS DATE------------------------- ------------- --------- ---------- ---------- ---------- --------- -------DEFAULT buffer cache SHRINK MANUAL 160 148 148 COMPLETE 18/01/2005 10:56:27streams pool GROW MANUAL 0 12 12 COMPLETE 18/01/2005 10:56:27DEFAULT buffer cache SHRINK DEFERRED 148 48 48 COMPLETE 18/01/2005 11:29:47DEFAULT buffer cache SHRINK MANUAL 48 28 28 COMPLETE 18/01/2005 11:48:20shared pool GROW MANUAL 80 100 100 COMPLETE 18/01/2005 11:48:20DEFAULT buffer cache SHRINK MANUAL 28 24 24 COMPLETE 18/01/2005 12:17:34shared pool GROW MANUAL 100 104 104 COMPLETE 18/01/2005 12:17:34

3.4 ASMM to Manual

You can disable the ASMM mechanism at any time by setting the SGA_TARGET value to 0.

In this case the current_size will be used by default as shown below:

SQL> alter system set sga_target=0;

System altered.


COMPONENT CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE TYPE------------------------- ------------ ---------- ------------------- -------------

shared pool 104 80 104 GROW <<<<< 104 has become the current valuelarge pool 8 8 8 STATICjava pool 48 48 48 STATICstreams pool 12 0 12 GROWDEFAULT buffer cache 24 24 24 SHRINKKEEP buffer cache 0 0 0 STATICRECYCLE buffer cache 0 0 0 STATICDEFAULT 2K buffer cache 0 0 0 STATICDEFAULT 4K buffer cache 0 0 0 STATICDEFAULT 8K buffer cache 0 0 0 STATICDEFAULT 16K buffer cache 0 0 0 STATICDEFAULT 32K buffer cache 0 0 0 STATICOSM Buffer Cache 0 0 24 STATIC

If you shutdown the instance now, you will record the CURRENT_SIZE value for all the parameters.

After the restart, the MIN_SIZE values are equal to CURRENT_SIZE.


COMPONENT CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE TYPE------------------------- ------------ ---------- ------------------- -------------shared pool 104 104 104 STATIClarge pool 8 8 8 STATICjava pool 48 48 48 STATIC

streams pool 12 12 12 STATICDEFAULT buffer cache 24 24 24 STATICKEEP buffer cache 0 0 0 STATICRECYCLE buffer cache 0 0 0 STATICDEFAULT 2K buffer cache 0 0 0 STATICDEFAULT 4K buffer cache 0 0 0 STATICDEFAULT 8K buffer cache 0 0 0 STATICDEFAULT 16K buffer cache 0 0 0 STATICDEFAULT 32K buffer cache 0 0 0 STATICOSM Buffer Cache 0 0 24 STATIC

It is strongly advised to use an spfile with your your instance as you will record any changes applied.

4. Conclusion

In previous Oracle versions, finding the right values for SGA parameters was an important part of Instance Tuning.

With ASMM, you do not have to size some of the most important SGA parameters. The right values are automatically chosen based on the Instance profile. Providing minimum (explicit) settings for those auto-tuned parameters is recommended to help the database make the "best choices" with memory moves in the SGA.

RELATED DOCUMENTS

Performance Tuning Guide 10G Release 1 Part No B10752-01Administrator's Guide 10G Release 1 Part No B10739-01note:257643.1Oracle Database 10g Automated SGA Memory Tuningnote:270065.1Use Automatic SGA Management

Related

Products

Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition

Keywords

V$SGA_RESIZE_OPS; MEMORY_TARGET; SGA_MAX_SIZE; MEMORY USAGE; ASMM; CONFIGURATION

Errors

ORA-4033; ORA-823; ORA-4031; ORA-827; ORA-2097; 00827 ERROR



how to use automatic shared memory management

Documents