Documente Academic
Documente Profesional
Documente Cultură
How To Use Automatic Shared Memory Management (ASMM) In Oracle10g [ID 295626.1]
Applies to:
Purpose
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
All the DBAs and users concerned with Database Administration activities.
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:
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
2
• 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
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.
• 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.
• DB__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):
The SGA_TARGET will be limited by the SGA_MAX_SIZE value. The SGA_MAX_SIZE cannot
be modified dynamically.
If you try to define a larger SGA_TARGET, you will get the following message:
3. Some Examples
This can be the case when you just upgraded your database from an older version.
DB_CACHE_SIZE=24M
SHARED_POOL_SIZE=80M
LARGE_POOL_SIZE=8M
JAVA_POOL_SIZE=48M
System altered.
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.
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.
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.
CURRENT_SIZE
-------------------
136
You have the means to change dynamically the size of the sga_target.
System altered.
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.
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.
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:
System altered.
SQL> /
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:
8
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:
If you decide to decrease the sga_target, you will influence only the auto-tuned sizes, the manual
parameters will stay untouched.
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.
You can also decide to change the default distribution chosen by the MMAN process.
System altered.
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.
The memory size increase for an auto-tuned parameter will be dependent on:
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
System altered.
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:
System altered.
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:
You can disable the ASMM mechanism at any time by setting the SGA_TARGET value to 0.
System altered.
If you shutdown the instance now, you will record the CURRENT_SIZE value for all the
parameters.
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.
13
RELATED DOCUMENTS
PURPOSE
These include:
• Overview
• Benefits of Automatic Shared Memory Management
• Configuring Automatic Shared Memory Management
• Behavior of Auto-Tuned SGA Parameters
• Behavior of Manual SGA Parameters
• Resizing SGA_TARGET
• Disable Automatic Shared Memory Tuning
• Manually Resizing Auto-Tuned Parameters
• SGA Background Process
• Automatic Shared Memory Principles
Overview
This feature reduces the tasks like dynamically analyzing the database workload and
redistribute memory across the SGA pools.
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.
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.
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.
divided between the components. The size of the keep cache is 1GB, as specified by
the parameter.
Resizing SGA_TARGET
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.
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
17
or more auto-tuned components, and the sizes of the manual components are not
affected.
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.
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.