Unable To Start ASM (ORA-838、4031) On 11.2.0.3 If OS CPUs # > 64-1416083.1

最新推荐文章于 2019-12-22 18:25:27 发布

cuilian2013

最新推荐文章于 2019-12-22 18:25:27 发布

阅读量200

点赞数

In this Document

Symptoms

Cause

Solution

Community Discussions

References

Applies to:

Oracle Database - Enterprise Edition - Version 11.2.0.1 to 11.2.0.3 [Release 11.2]
Information in this document applies to any platform.

Symptoms

1) ASM 11.2.0.3 configuration on Solaris SPARC T4-4 Server with 128 CPUs & RAM = 128 GB.

2) If the 128 CPUs are enabled, then ASM instance is unable to start due to the next errors:

ORA-00838: Specified value of MEMORY_TARGET is too small, needs to be at least 1328M
ORA-01078: failure in processing system parameters

[main] [ 2012-01-21 18:26:28.986 COT ] [UsmcaLogger.logException:174] ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool","SELECT DECODE(null,'','Total...","SQLA","tmp")

3) But if only 64 CPUs are enabled, then ASM instance starts without problems.

4) On release 11.2, ASM uses Automatic Memory Management ( AMM) by default, therefore MEMORY_MAX_TARGET & MEMORY_TARGET have the default values = 272 MB (in the ASM instance):

MEMORY_MAX_TARGET = 272M
MEMORY_TARGET = 272M

5) And so, the SGA in the ASM instance has the same value (900 MB):

SQL> show sga

Total System Global Area 283930624 bytes
Fixed Size 2227664 bytes
Variable Size 256537136 bytes
ASM Cache 25165824 bytes

Cause

In 11.2.0.3, the " PROCESSES" parameter will be default to "available CPU cores * 80 + 40" (in the ASM spfile). As the default value for " MEMORY_TARGET" is based on " PROCESSES", it can be insufficient if there is a large number of CPU cores or large number of diskgroups which could cause issues (i.e. Grid Infrastructure stack fails to stop with ORA-04031 etc) per Bug:13605735 & Bug:12885278, it is recommended to increase the value of MEMORY_MAX_TARGET & MEMORY_TARGET before upgrading/installing to 11.2.0.3 (does not apply to 10g ASM).

Solution

1) Connect to the ASM instance(s) and increase the MEMORY_MAX_TARGET & MEMORY_TARGET as follow (3GB or 4GB will be enough):

SQL> alter system set MEMORY_MAX_TARGET=4096m scope=spfile;
SQL> alter system set MEMORY_TARGET=1536m scope=spfile;

Note: The number 1536m has proven to be sufficient for most environment, the change will not be effective until next restart.

2) Restart the ASM instances to apply the changes.

3) Then enable all the CPUs (e.g. total = 128) in your system:

bash-3.00# prtdiag -v|grep SPARC-T4 | grep on-line | wc -l
128

Important Note:

In 11.2.0.3, we increase the default PROCESSES based on the number of CPU cores, and the default MEMORY_TARGET is based on PROCESSES. If in 11.2.0.2, customers explicitly set MEMORY_TARGET to some value that may not be big enough for 11.2.0.3, when they upgrade to 11.2.0.3, ASM will fail to start with error "memory_target is too small". We should add additional check for MEMORY_TARGET during the upgrade prerequisite check.

You can unset MEMORY_TARGET so that ASM can use the default value, but if MEMORY_TARGET is explicitly set, please make sure it's large enough, following the next rules:

1) If PROCESSES parameter is explicitly set:

The MEMORY_TARGET should be set to no less than:

256M + PROCESSES * 132K (64bit)

or

256M + PROCESSES * 120K (32bit)

2) If PROCESSES parameter is not set:

The MEMORY_TARGET should be set to no less than:

256M + (available_cpu_cores * 80 + 40) * 132K (64bit)

256M + (available_cpu_cores * 80 + 40) * 120K (32bit)

======================================================

Community Discussions

Still have questions? Use the communities window below to search for similar discussions or start a new discussion on this subject. (Window is the live community not a screenshot)

Click here to open in main browser window