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_<KEEP/RECYCLE>_CACHE_SIZE
• DB_nK_CACHE_SIZE (non default block size)
• LOG_BUFFER
• FIXED SGA
• STREAMS_POOL_SIZE

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

• Modifiable: DB_<KEEP/RECYCLE>_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 invalid
ORA-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 FALSE
pre_page_sga boolean FALSE
sga_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 1048576
create_bitmap_area_size integer 8388608
db_block_size integer 8192
db_cache_size big integer 24M <<<<<<<<<<<
db_keep_cache_size big integer 0
db_recovery_file_dest_size big integer 2G
db_recycle_cache_size big integer 0
db_16k_cache_size big integer 0
db_2k_cache_size big integer 0
db_32k_cache_size big integer 0
db_4k_cache_size big integer 0
db_8k_cache_size big integer 0
global_context_pool_size string
hash_area_size integer 131072
java_max_sessionspace_size integer 0
java_pool_size big integer 48M <<<<<<<<
large_pool_size big integer 8M <<<<<<<<<
max_dump_file_size string UNLIMITED
object_cache_max_size_percent integer 10
object_cache_optimal_size integer 102400
olap_page_pool_size big integer 0
parallel_execution_message_size integer 2148
sga_max_size big integer 164M
shared_pool_reserved_size big integer 4M
shared_pool_size big integer 80M <<<<<<<<<
sort_area_retained_size integer 0
sort_area_size integer 65536
streams_pool_size big integer 0
workarea_size_policy string AUTO

So the auto-tuned parameters are:

DB_CACHE_SIZE=24M
SHARED_POOL_SIZE=80M
LARGE_POOL_SIZE=8M
JAVA_POOL_SIZE=48M
4M are reserved for the other manual parameters.

SQL> show sga

Total System Global Area 171966464 bytes

Fixed Size 787988 bytes
Variable Size 145750508 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes

You decide to switch in ASMM mode:

SQL> alter system set sga_target=100M;

System altered.

SQL> show parameter sga

NAME TYPE VALUE

----------------------------- ----------- -----
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 164M
sga_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 80
large pool 8 8 8
java pool 48 48 48
streams pool 0 0 0
DEFAULT buffer cache 24 24 24
KEEP buffer cache 0 0 0
RECYCLE buffer cache 0 0 0
DEFAULT 2K buffer cache 0 0 0
DEFAULT 4K buffer cache 0 0 0
DEFAULT 8K buffer cache 0 0 0
DEFAULT 16K buffer cache 0 0 0
DEFAULT 32K buffer cache 0 0 0
OSM 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:

SQL> alter system set sga_target=164M;

System altered.

SQL> show parameter sga

NAME TYPE VALUE

------------------------------------ ----------- -----------
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 300M
sga_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.

SQL> alter system set sga_target=200M;

System altered.

SQL> show parameter sga

NAME TYPE VALUE

------------------------------------ ----------- -----
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 300M
sga_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 80
large pool 8 8 8
java pool 48 48 48
streams pool 0 0 0
DEFAULT buffer cache 60 24 24
KEEP buffer cache 0 0 0
RECYCLE buffer cache 0 0 0
DEFAULT 2K buffer cache 0 0 0
DEFAULT 4K buffer cache 0 0 0
DEFAULT 8K buffer cache 0 0 0
DEFAULT 16K buffer cache 0 0 0
DEFAULT 32K buffer cache 0 0 0
OSM 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 invalid
ORA-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:

SQL> alter system set sga_target=300M;

System altered.

select component, current_size/1024/1024 "CURRENT_SIZE", min_size/1024/1024 "MIN_SIZE", user_sp

ecified_size/1024/1024 "USER_SPECIFIED_SIZE" from v$sga_dynamic_components;

COMPONENT CURRENT_SIZE MIN_SIZE USER_SPECIFIED_SIZE

---------------------------------------------------------------- ------------ ---------- -----------
shared pool 80 80 80
large pool 8 8 8
java pool 48 48 48
streams pool 0 0 0
DEFAULT buffer cache 160 24 24 <<<<<<
KEEP buffer cache 0 0 0
RECYCLE buffer cache 0 0 0
DEFAULT 2K buffer cache 0 0 0
DEFAULT 4K buffer cache 0 0 0
DEFAULT 8K buffer cache 0 0 0
DEFAULT 16K buffer cache 0 0 0
DEFAULT 32K buffer cache 0 0 0
OSM 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 bytes

Fixed Size 788692 bytes
Variable Size 145749804 bytes
Database Buffers 167772160 bytes
Redo 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 STATIC
large pool 8 8 8 STATIC
java pool 48 48 48 STATIC
streams pool 12 0 12 GROW <<<<<<<<<<<
DEFAULT buffer cache 148 24 24 SHRINK <<<<<
KEEP buffer cache 0 0 0 STATIC
RECYCLE buffer cache 0 0 0 STATIC
DEFAULT 2K buffer cache 0 0 0 STATIC
DEFAULT 4K buffer cache 0 0 0 STATIC
DEFAULT 8K buffer cache 0 0 0 STATIC
DEFAULT 16K buffer cache 0 0 0 STATIC
DEFAULT 32K buffer cache 0 0 0 STATIC
OSM 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 4
large pool 4
java pool 4
streams pool 4
DEFAULT buffer cache 4
KEEP buffer cache 4
RECYCLE buffer cache 4
DEFAULT 2K buffer cache 4
DEFAULT 4K buffer cache 4
DEFAULT 8K buffer cache 4
DEFAULT 16K buffer cache 4
DEFAULT 32K buffer cache 4
OSM 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 COMPLETE
streams 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> alter system set sga_target=200M;

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 STATIC
large pool 8 8 8 STATIC
java pool 48 48 48 STATIC
streams pool 12 0 12 GROW
DEFAULT buffer cache 48 24 24 SHRINK
KEEP buffer cache 0 0 0 STATIC
RECYCLE buffer cache 0 0 0 STATIC
DEFAULT 2K buffer cache 0 0 0 STATIC
DEFAULT 4K buffer cache 0 0 0 STATIC
DEFAULT 8K buffer cache 0 0 0 STATIC
DEFAULT 16K buffer cache 0 0 0 STATIC
DEFAULT 32K buffer cache 0 0 0 STATIC
OSM 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 = 176M
If 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 STATIC
java pool 48 48 48 STATIC
streams pool 12 0 12 GROW
DEFAULT buffer cache 28 24 24 SHRINK
KEEP buffer cache 0 0 0 STATIC
RECYCLE buffer cache 0 0 0 STATIC
DEFAULT 2K buffer cache 0 0 0 STATIC
DEFAULT 4K buffer cache 0 0 0 STATIC
DEFAULT 8K buffer cache 0 0 0 STATIC
DEFAULT 16K buffer cache 0 0 0 STATIC
DEFAULT 32K buffer cache 0 0 0 STATIC
OSM 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 invalid
ORA-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.

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 104 GROW <<<<<<<<<<<<
large pool 8 8 8 STATIC
java pool 48 48 48 STATIC
streams pool 12 0 12 GROW
DEFAULT buffer cache 24 24 24 SHRINK
KEEP buffer cache 0 0 0 STATIC
RECYCLE buffer cache 0 0 0 STATIC
DEFAULT 2K buffer cache 0 0 0 STATIC
DEFAULT 4K buffer cache 0 0 0 STATIC
DEFAULT 8K buffer cache 0 0 0 STATIC
DEFAULT 16K buffer cache 0 0 0 STATIC
DEFAULT 32K buffer cache 0 0 0 STATIC
OSM 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 GROW
large pool 8 8 8 STATIC
java pool 48 48 48 STATIC
streams pool 12 0 12 GROW
DEFAULT buffer cache 24 24 24 SHRINK
KEEP buffer cache 0 0 0 STATIC
RECYCLE buffer cache 0 0 0 STATIC
DEFAULT 2K buffer cache 0 0 0 STATIC
DEFAULT 4K buffer cache 0 0 0 STATIC
DEFAULT 8K buffer cache 0 0 0 STATIC
DEFAULT 16K buffer cache 0 0 0 STATIC
DEFAULT 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:27
streams pool GROW MANUAL 0 12 12 COMPLETE 18/01/2005 10:56:27
DEFAULT buffer cache SHRINK DEFERRED 148 48 48 COMPLETE 18/01/2005
11:29:47
DEFAULT buffer cache SHRINK MANUAL 48 28 28 COMPLETE 18/01/2005
11:48:20
shared pool GROW MANUAL 80 100 100 COMPLETE 18/01/2005
11:48:20
DEFAULT buffer cache SHRINK MANUAL 28 24 24 COMPLETE 18/01/2005
12:17:34
shared pool GROW MANUAL 100 104 104 COMPLETE 18/01/2005
12:17:34
3.4 ASMM to Manual

You can revert 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.

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 104 GROW <<<<< 104 has become the current value
large pool 8 8 8 STATIC
java pool 48 48 48 STATIC
streams pool 12 0 12 GROW
DEFAULT buffer cache 24 24 24 SHRINK
KEEP buffer cache 0 0 0 STATIC
RECYCLE buffer cache 0 0 0 STATIC
DEFAULT 2K buffer cache 0 0 0 STATIC
DEFAULT 4K buffer cache 0 0 0 STATIC
DEFAULT 8K buffer cache 0 0 0 STATIC
DEFAULT 16K buffer cache 0 0 0 STATIC
DEFAULT 32K buffer cache 0 0 0 STATIC
OSM 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.

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 104 104 STATIC
large pool 8 8 8 STATIC
java pool 48 48 48 STATIC
streams pool 12 12 12 STATIC
DEFAULT buffer cache 24 24 24 STATIC
KEEP buffer cache 0 0 0 STATIC
RECYCLE buffer cache 0 0 0 STATIC
DEFAULT 2K buffer cache 0 0 0 STATIC
DEFAULT 4K buffer cache 0 0 0 STATIC
DEFAULT 8K buffer cache 0 0 0 STATIC
DEFAULT 16K buffer cache 0 0 0 STATIC
DEFAULT 32K buffer cache 0 0 0 STATIC
OSM 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 don't have anymore to size by yourself some of the most important SGA parameters. The
right values are automatically chosen based on the Instance profile.

RELATED DOCUMENTS

Performance Tuning Guide 10G Release 1 Part No B10752-01

Administrator's Guide 10G Release 1 Part No B10739-01
Note 257643.1 Oracle Database 10g Automated SGA Memory Tuning
Note 270065.1 Use Automatic SGA Management
Sharing Memory—Automatically
By Kimberly Floss

Put away your scripts and let Oracle automatically resize your memory pools.

It used to be a challenge to size the various memory pools that comprise the Oracle system global area (SGA) for
optimal performance. But that was before Oracle Database 10g.

For example, the buffer cache had to be large enough to keep frequently used blocks readily available for fast
retrieval—but not so large that the database couldn't allocate memory in one of the other SGA pools when needed.
Since various types of applications and usage patterns tax the assorted pools differently, and since the workload can
vary minute by minute, manually resizing the SGA components could feel like a never-ending task.

If there wasn't enough free SGA to allocate memory to a specific pool when needed, the database would raise an out-
of-memory error, such as

ORA-04031: unable to allocate ...

Also, before Oracle9i Database Release 2, adjusting the pool sizes required bouncing the server—hardly practical in a
production environment.

That's why Oracle Database 10g's Automatic Shared Memory Management (ASMM) is such a welcome
improvement. First introduced in Oracle Database 10g and further enhanced in Oracle Database 10g Release 2,
ASMM automatically sizes many of the memory pools while the database is running, allocating and de-allocating
memory as needed. As the workload composition changes, Oracle Database 10g enlarges the appropriate pools and
reduces the sizes of other automatically sized pools accordingly. In short, ASMM can save you a lot of trouble—and
improve overall performance as well.

Let's take a closer look at how it works and how to use it.

SGA Memory Components

The linchpin of Oracle Database 10g's memory management scheme is the new SGA_TARGET initialization parameter.
The value of this setting determines the total amount of SGA memory that can be allocated across both manually and
automatically sized pools. (See Table 1, in the online version of this article at oracle.com/technology/oramag/oracle/
05-sep/o55tuning.html.) The SGA_TARGET value imposes a ceiling on the amount of RAM devoted to the Oracle SGA.

Oracle Database 10g Release 2 can automatically tune the size of the shared pool, buffer cache, Java pool, large pool,
and streams pool. However, you must still manually tune several SGA components, including the log buffer (at
startup time only), the keep buffer cache, the recycle buffer cache, and all of the nonstandard block-size buffer caches
(for example, the 32K and 16K buffer caches set by the db_32K_cache_size and db_16K_cache_size parameters).
Manually sized components consume SGA from the target value first, and then the remainder of SGA memory is
spread across the various autosized pools. In other words, if you set parameter values for any of these manually tuned
pools, Oracle Database 10g Release 2 subtracts their sizes from SGA_TARGET first, before allocating memory to the
automatically allocated pools.

The SGA_TARGET setting value also includes a small amount of fixed-size SGA. Oracle Database 10g Release 2 sets
the fixed size based on the operating system and other criteria. You can see the amount (in bytes) of the fixed-size
SGA and totals of other major elements that occupy the SGA by querying the V$SGA view, as follows:
SQL> select * from v$sga;
NAME VALUE
------------------ ----------
Fixed Size 1247780
Variable Size 124319196
Database Buffers 41943040
Redo Buffers 262144

You can query this same view to determine an initial size for SGA_TARGET when you switch from manual to
autotuning, by summing all the components as follows:

SQL> select sum(value)/1024/1024 "Megabytes" from v$sga;

Megabytes
------------------
160

Listing 1 shows an example of total real memory allocation for the current SGA from the
V$SGA_DYNAMIC_COMPONENTS view (introduced in Oracle9i Database), which contains both manual and autotuned
SGA components.

Code Listing 1: Query of V$SGA_DYNAMIC_COMPONENTS

SQL> select component, current_size from v$sga_dynamic_components;

COMPONENT CURRENT_SIZE
------------------------------- -------------------------
shared pool 92274688
large pool 8388608
java pool 8388608
streams pool 12582912
DEFAULT buffer cache 33554432
KEEP buffer cache 4194304
RECYCLE buffer cache 4194304
DEFAULT 2K buffer cache 0
DEFAULT 4K buffer cache 0
DEFAULT 8K buffer cache 0
DEFAULT 16K buffer cache 0
DEFAULT 32K buffer cache 0
ASM Buffer Cache 0

13 rows selected.

Using ASMM

As with the other manageability features of Oracle Database 10g, ASMM requires you to set the STATISTICS_LEVEL
parameter to at least TYPICAL (the default), so make sure this setting is correct before you try to enable ASMM. You
can enable it in the following ways:

• Set SGA_TARGET to a nonzero value in the initialization parameter file (pfile).

• Use Oracle Enterprise Manager (or Oracle Grid Control) or ALTER SYSTEM to dynamically set a nonzero value
for SGA_TARGET in the server parameter file (spfile).

To use the command line (ALTER SYSTEM), set a value for SGA_TARGET and then set the parameters for all of the
autotuned pools to 0, as follows:
SQL> alter system set sga_target=160M scope=both;
System altered.

SQL> alter system set db_cache_size=0;

System altered.

SQL> alter system set shared_pool_size=0;

System altered.

<repeat for each autotuned pool>

If you don't set the values for each of the autotuned pools to zero after switching to ASMM, whatever value you had
set for a parameter will function as a lower threshold value for that pool—ASMM won't go below a nonzero value,
even if it needs the memory for another autotuned pool.

Rather than entering each of these ALTER SYSTEM commands for each of the autotuned pools as shown above, you
can use Oracle Enterprise Manager to accomplish the same thing in one step, as part of the switch from Manual to
Automatic tuning, by clicking the Enable button on the Memory Parameters page. This also shows you at a glance the
various memory allocations at any time. To open the Memory Parameters page, from Database Control's
Administration page, click the Advisor Central link (under the Related Links heading near the bottom of the page),
and then click the Memory Advisor link.

The Memory Parameters page shows the memory allocations across all major components over time, since the last
restart of the database, as shown in Figure 1. Lower down on the page you'll see a pie chart and a table displaying the
Current Allocations. The chart shows the allocations as percentages of the total SGA that can be allocated, while the
table shows the component and a value, in megabytes, of the allocation.
 Figure 1: Memory Parameters page

Also on the Memory Parameter page, adjacent to the Total SGA Size field, is an Advice button—new in Oracle
Database 10g Release 2. This lets you assess the impact of increasing (or decreasing) the system's target SGA. The
v$sga_target_advice view also provides this information, as shown in Listing 2.

The v$sga_target_advice view gives you the information you need to modify the SGA_TARGET parameter (up to the
size of the SGA_MAX_SIZE, if necessary). For the example in Listing 2, we can increase the SGA_TARGET to 200 and
thereby reduce physical reads by about 10%.

Code Listing 2: Query of V$SGA_TARGET_ADVICE

SQL> select sga_size, sga_size_factor, estd_db_time, estd_db_time_factor, estd_physical_reads

from v$sga_target_advice order by sga_size_factor;

SGA_SIZE SGA_SIZE_FACTOR ESTD_DB_TIME ESTD_DB_TIME_FACTOR ESTD_PHYSICAL_READS

--------- ----------------- -------------- ------------------- -------------------
120 .75 421 1 26042
160 1 421 1 8223
240 1.5 421 1 7340
280 1.75 421 1 7340
200 1.25 421 1 7340
320 2 421 1 7340

6 rows selected.
SHARED_POOL_SIZE Value in Oracle Database 10g

If you're going to manually tune Oracle Database 10g SGA pools, note one key difference in how it interprets the
shared pool value. In releases prior to Oracle Database 10g, the shared pool size was set equal to the
shared_pool_size initialization parameter value, plus the amount of internal SGA overhead—memory that the
database allocated during startup to maintain state for various server components of the SGA. So if you set the
shared_pool_size parameter to 48M in Oracle9i Database, for example, the actual shared pool size allocated by the
database might have been 60MB, assuming a startup overhead amount of 12MB.

In Oracle Database 10g, the shared pool size is the actual value of the parameter only—yet the overhead must still be
accounted for in the shared pool. This means that if you're migrating to Oracle Database 10g from a prior release and
you plan to manually size the various memory pools, you must make the shared_pool_size parameter value slightly
larger in Oracle Database 10g than in your prior release to account for the startup overhead. In Oracle Database 10g,
you can see precisely how much this startup overhead is by querying the v$sgainfo dynamic view—you'll find a
value for "Startup overhead in shared pool."

Conclusion

It doesn't matter how much memory the system has if it's not properly allocated across the appropriate SGA pools at
runtime. Yet since the system requirements can change from one minute to the next, these pools must be constantly
adjusted. Oracle Database 10g's ASMM is a huge time-saver, and it also reduces the chances of ORA-04031 errors.
The result? Your system will perform better—and you'll save time and trouble.
Oracle Database 10g Automated SGA Memory Tuning

Doc_id : 257643.1

Overview

In Oracle Database 10g, Automatic Shared Memory Management (ASMM) feature is introduced to automatically
determine the size of Database buffer cache (default pool), Shared pool, Large pool and Java pool (starting with
10gR2, the streams pool is included) by setting the parameter SGA_TARGET.

This feature reduces the tasks like dynamically analyzing the database workload and redistribute memory across the
SGA pools.

Benefits of Automatic Shared Memory Management

Automatic Shared Memory Management simplifies the configuration of the SGA. Before Oracle Database 10G,
buffer cache, shared pool, java pool, and large pool need to be manually specified for the database. Under sizing can
lead to poor performance and out-of-memory errors (ORA-4031), while over sizing can waste memory. This feature
enables you to specify a total memory amount to be used for all SGA Components (buffer cache, shared pool, java
pool, and large pool). The Oracle database periodically redistributes memory between these components according to
workload requirements. Before Oracle Database 10G, the user did not have exact control over the total size of the
SGA since memory was allocated by Oracle for the fixed SGA, and for other internal metadata allocations over and
above the total size of the user specified SGA parameters. The new SGA size parameter SGA_TARGET now includes
all the memory in the SGA, including all the automatically sized components, manually sized components, and any
internal allocations during startup.

Configuring Automatic Shared Memory Management

Automatic Shared Memory Management can be configured by using the SGA_TARGET initialization parameter. If
you specify a non-zero value for SGA_TARGET, the following four memory pools are automatically sized:

• Database buffer cache (Default pool)

• Shared pool
• Large pool
• Java pool
• 10gR2 the streams pool is included

If you set SGA_TARGET to 0, Automatic Shared Memory Management is disabled. The default value of
SGA_TARGET is 0.

The individual parameters used before Oracle 10G releases to specify the sizes of the automatically sized components
have not been made obsolete. The initialization parameters that size these pools (DB_CACHE_SIZE,
SHARED_POOL_SIZE, LARGE_POOL_SIZE, and JAVA_POOL_SIZE) are now referred to as auto-tuned SGA
parameters.
The following buffers are now referred to as manually sized components:

• Log buffer
• Other buffer caches (KEEP/RECYCLE, other block sizes)
• Streams pool (new in Oracle Database 10g)
• Fixed SGA and other internal allocations

Note: STATISTICS_LEVEL must be set to TYPICAL (default) or ALL to use Automatic Shared Memory
Management.

Behavior of Auto-Tuned SGA Parameters

When SGA_TARGET is not set or set to zero, auto-tuned SGA components behave as they did in previous releases. The only
exception is the Shared Pool. As of 10g, internal overhead allocations for metadata are now included in the value of the
SHARED_POOL_SIZE parameter. See Note 270935.1 Shared pool sizing in 10g for more on this change.

Behavior of Manual SGA Parameters

Below are the manual SGA size parameters :

• DB_KEEP_CACHE_SIZE
• DB_RECYCLE_CACHE_SIZE
• DB_nK_CACHE_SIZE (n = 2, 4, 8, 16, 32)
• LOG_BUFFER
• STREAMS_POOL_SIZE

Manual SGA parameters are specified by the user, and the given sizes precisely control the sizes of their
corresponding components.

When SGA_TARGET is set, the total size of manual SGA size parameters is subtracted from the SGA_TARGET
value, and balance is given to the auto-tuned SGA components.

For example, if SGA_TARGET = 8G and DB_KEEP_CACHE_SIZE = 1G, this means that the total size of the four
auto-tuned components (shared pool, java pool, default buffer cache, and large pool) is limited to 7GB. The 7GB
includes the fixed SGA and log buffer, and only after those have been allocated the rest of the memory is divided
between the components. The size of the keep cache is 1GB, as specified by the parameter.

Resizing SGA_TARGET

SGA_TARGET is a dynamic parameter and can be changed through Enterprise Manager or with the ALTER
SYSTEM command.

SGA_TARGET can be increased up to the value of SGA_MAX_SIZE. It can be reduced until any one auto-tuned
components reaches its minimum size (either a user-specified minimum or an internally determined minimum). If you
increase the value of SGA_TARGET, the additional memory is distributed according to the auto-tuning policy across
the auto-tuned components. If you reduce the value of SGA_TARGET the memory is taken away by the auto-tuning
policy from one or more of the auto-tuned components. Therefore any change in the value of SGA_TARGET affects
only the sizes of the auto-tuned components.

For example, if SGA_TARGET = 8G and DB_KEEP_CACHE_SIZE = 1G and you increase SGA_TARGET to 9G,
the additional 1GB is distributed only among the components controlled by SGA_TARGET. The value of
DB_KEEP_CACHE_SIZE is not affected. Likewise, if SGA_TARGET is reduced to 7G, the 1GB is only taken from
the components controlled by SGA_TARGET. This decrease does not affect the settings of the manually controlled
parameters like DB_KEEP_CACHE_SIZE.

Disable Automatic Shared Memory Tuning

You can dynamically choose to disable automatic shared memory tuning by setting SGA_TARGET to zero. In this
case the values of all the auto-tuned parameters are set to the current sizes of the components, even if the user had
earlier specified a different non-zero value for an auto-tuned parameter. In the above example, the value of
SGA_TARGET is 8GB, and the value of SHARED_POOL_SIZE is 1G.

If the system has internally adjusted the size of the shared pool component to 2G, then setting SGA_TARGET to zero
results in SHARED_POOL_SIZE being set to 2G, overriding the original user-specified value.

Manually Resizing Auto-Tuned Parameters

As discussed above, when SGA_TARGET is set, the default value for the auto-tuned parameters is zero, and a
nonzero value serves as a lower bound for the size of the corresponding component. Therefore, when an auto-tuned
parameter is resized automatically, the resize results in a change to the size of the component only if the new value is
larger than the present size of the SGA component.

For example, if you set SGA_TARGET to 8G and set SHARED_POOL_SIZE to 2G, you ensure that the Shared Pool
has at least 2G at all times to accommodate the necessary memory allocations.
If you adjust the value of SHARED_POOL_SIZE to 1G, there is no immediate effect on the size of the shared pool. It
simply gives the automatic memory tuning algorithm the freedom to later reduce the Shared Pool to 1G if required.

On the other hand, if the size of the Shared Pool is 1G to begin with, then adjusting the value of
SHARED_POOL_SIZE to 2G results in the Shared Pool component growing to a size of 2G. The memory used in
this grow operation is taken from one or more auto-tuned components, and the sizes of the manual components are
not affected.

SGA Background Process

The Automatic Shared Memory Management feature uses a new background process named Memory Manager
(MMAN). MMAN serves as the SGA Memory Broker and coordinates the sizing of the memory components. The
SGA Memory Broker keeps track of the sizes of the components and pending resize operations.

Automatic Shared Memory Principles

The SGA Memory Broker observes the system and workload in order to determine the ideal distribution of memory.
It is never complacent and performs this check every few minutes so that memory can always be present where
needed. In the absence of automatic shared memory tuning, components had to be sized to anticipate their individual
worst-case memory requirements.
For example, consider a system that runs large OLTP jobs during the day that require large buffer caches, and runs
parallel batch jobs at night that require large values for the large pool. The DBA would have to simultaneously
configure both the buffer cache and the large pool to accommodate their peak requirements.

With SGA auto-tuning, when the OLTP job runs, the buffer cache has most of the memory to allow for good I/O
performance. When the DSS batch job starts later, the memory automatically migrates to the large pool so that it can
be used by Parallel Query operations.

Based on workload information, automatic shared memory tuning:

• Captures statistics periodically in the background

• Uses the different memory advisories
• Performs “what-if” analyses to determine best distribution of memory
• Moves memory to where it is most needed
• Has no need to configure parameters for the worst-case scenario
• Resurrects component sizes from last shutdown if SPFILE is used
Shared pool sizing in 10g
PURPOSE
-------

This bulletin explains the changes to shared_pool_size parameter value in 10g.

SCOPE & APPLICATION

-------------------

DBA and Developers

Setting the value of shared_pool_size correctly in 10g

-------------------------------------------------------
Before 10g, internal overhead allocations for metadata such as for data structures for processes and
sessions were not included in the value of shared_pool_size parameter. Because of this, actual memory
allocated to shared pool was higher than the value of shared_pool_size parameter.

For example:
SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
PL/SQL Release 9.2.0.1.0 - Production
CORE 9.2.0.1.0 Production
TNS for Solaris: Version 9.2.0.1.0 - Production
NLSRTL Version 9.2.0.1.0 - Production

SQL> show parameter shared_pool_size

NAME VALUE
----------------------- ------------- -
shared_pool_size 33554432
SQL> select sum(bytes) from V$SGASTAT where pool = 'shared pool';

SUM(BYTES)
----------
54525952

As you can see, shared_pool_size ~ 33 MB but actual shared pool allocated is ~ 54 MB.

Starting from 10G, internal overhead allocations for metadata is included in the value of shared_pool_size
parameter.

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Prod
PL/SQL Release 10.1.0.2.0 - Production
CORE 10.1.0.2.0 Production
TNS for 32-bit Windows: Version 10.1.0.2.0 - Production
NLSRTL Version 10.1.0.2.0 - Production

SQL> show parameter shared_pool_size

NAME VALUE
------------------- ---------------
shared_pool_size 80M
SQL> select round(sum(bytes)/(1024*1024),2) size_mb
2 from V$SGASTAT where pool = 'shared pool';

SIZE_MB
----------
80

The side effect of this change may result in not having the same amount of memory allocated to other
components of shared pool (like library cache and row cache, etc.) if you set the same value used in
prior versions for shared_pool_size in 10g. So, we need to follow the steps below to set the correct value
of shared_pool_size in 10g.

1) select sum(bytes) from V$SGASTAT where pool = 'shared pool';

Run this query in 8i/9i database before upgrading to 10g

2) Set value of shared_pool_size = value from above query.

( Do not use the value from init.ora for shared_pool_size parameter)

You can also use automatic shared memory tuning feature in 10g.
Refer Metalink Note 257643.1 for details.