遭遇ORA-12801 insufficient memory for PX buffers

10g or 11g, Install or Upgrade Fails due to ORA-12853: insufficient memory for PX buffers policy_indexes.sql [ID 1174093.1]
		Modified 22-SEP-2010     Type PROBLEM     Status PUBLISHED

In this Document
  Symptoms
  Changes
  Cause
  Solution
  References

---

Applies to:

Enterprise Manager Grid Control - Version: 10.2.0.1 to 10.2.0.5 - Release: 10.2 to 10.2
Enterprise Manager Grid Control - Version: 11.1.0.1 and later    [Release: 11.1 and later]
Information in this document applies to any platform.
This problem can affect EM Grid Control installations on either 10GR2 or 11G platforms

Symptoms

The installation or upgrade of Enterprise Manager fails during Repository Creation.

Repository Creation is where the schema is defined on the back-end database.

The error is printed into two installation logs:
emschema.log.CREATE
and
em_repos_config.log

These are located in the directory:
$ORACLE_BASE/middleware/oms11g/sysman/log/schemamanager//.CREATE

The error text will appear to look something like this:

2010-07-27 14:13:41,908 [Thread-177] ERROR emschema.15y8b1pxt30zg - ERROR:ORA-12801: error signaled in parallel query server P138
ORA-12853: insufficient memory for PX buffers: current 682976K, max needed 2834304K
ORA-04031: unable to allocate 65560 bytes of shared memory ("large pool","unknown object","large pool","PX msg pool")
ORA-06512: at line 10
File:/obin/oracle/Middleware/oms11g/sysman/admin/emdrep/sql/core/10.2.0.5/policy/policy_indexes.sql

Note: This problem will usually cause the database instance to consume all memory and CPU resources on the host, which requires a reboot of the physical server itself.

Changes

The action which triggers this issue is an install or upgrade of Enterprise Manager.

Cause

The error is misleading.  It looks as though there is not enough memory available to the OMS repository database as per the messages:

ORA-12853: insufficient memory for PX buffers: current 682976K, max needed 2834304K
ORA-04031: unable to allocate 65560 bytes of shared memory ("large pool","unknown object","large pool","PX msg pool")

Oracle databases have a feature called parallelization which allows many threads to process work simultaneously.  However, each worker thread will consume additional resources; the more threads are working at once, the more CPU and RAM need to be available to the Oracle database process.  If too many threads are working at once, there will be resource starvation and the errors ORA-12853 and ORA-04031 can be triggered.  These are fatal for the install.

During the installation, the degree of parallelization is determined by the value of the database parameter cpu_count

In some instances CPU_COUNT is set to a value which is too high, which in turn triggers too much parallelization, and results in the fatal ORA-12853 and ORA-04031 errors.

Solution

If any cleanup steps show errors which indicate objects or packages do not exist, ignore them and continue to work through the procedure. As the installation of EM failed, we would not expect the current schema to be fully intact.
The solution for this problem is usually not to increase PGA, SGA, although it is worthwhile to first check the values and make sure they are set to a reasonably high value e.g.

SQL> show parameter sga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 900M
sga_target big integer 900M

Note:  Recommended SGA size is variable depending on your environment.  Consult Oracle performance and sizing documentation to decide how they should be set based on the load you anticipate  for your Enterprise. 
http://download.oracle.com/docs/cd/B19306_01/em.102/b40002/sizing.htm

Once the above has been validated, check the value of cpu_count on the database. 

Example:

SQL> select name,value from v$parameter where name='cpu_count';

NAME VALUE
cpu_count 80

If this number appears to be set to a value higher than the number of logical CPUs available to the Oracle Database, it will need to be altered.  Example:

alter system set cpu_count=2;

Once the CPU count has been altered, the following steps are necessary if a fresh (new) installation was attempted.  If an upgrade attempt was attempted, it will instead be necessary to restore the database from backup.  In this instance, skip the below step 1 and proceed to step 2.

1. Remove Enterprise Manager components from the database as per Note 278100.1

For the purposes of resolving the problem in this particular note, Option 4 (manual) is recommended.
Steps will be listed below so as to remove the need to cross reference the note itself.
Note that there are two specific steps for 11G EM cleanup only.  They are listed in bold. 

Note: Some steps will result in exceptions like "No such object" etc. Don't worry about these: just move through the process and run all statements and you are guaranteed to have a clean repository, ready for another install attempt

Start the database in restricted mode by logging in as sys as sysdba (or similarly privileged) user and executing:

> shutdown immediate
> startup restrict

Then execute

> EXEC sysman.emd_maintenance.remove_em_dbms_jobs;
> EXEC sysman.setEMUserContext('',5);
> EXEC sysman.DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'MGMT_NOTIFY_QTABLE',force =>TRUE);
> REVOKE dba FROM sysman;
> delete from SCHEMA_VERSION_REGISTRY where COMP_NAME='Metadata Services';
>
DECLARE
CURSOR c1 IS
SELECT owner, synonym_name name
FROM dba_synonyms
WHERE table_owner = 'SYSMAN';
BEGIN
FOR r1 IN c1 LOOP
IF r1.owner = 'PUBLIC' THEN
EXECUTE IMMEDIATE 'DROP PUBLIC SYNONYM '||r1.name;
ELSE
EXECUTE IMMEDIATE 'DROP SYNONYM '||r1.owner||'.'||r1.name;
END IF;
END LOOP;
END;
/
> DROP USER mgmt_view CASCADE;
> DROP ROLE mgmt_user;
> drop public synonym MGMT_TARGET_BLACKOUTS;
> drop public synonym SETEMVIEWUSERCONTEXT;
> DROP USER sysman CASCADE;
> DROP USER SYSMAN_MDS CASCADE;

Finally, restart the database so it is no longer in restrict mode

> shutdown immediate
> startup

2.  Uninstall the EM and WebLogic binaries from disk
- Launch EM installer again with -deinstall option e.g.

./runInstaller -deinstall

Then click on the Installed Products menu to see the list of oracle homes.
i) opening the installed products menu
ii) Removing ORACLE HOMEs oms11g, agent11g, common11g, webtier11g
When this procedure has completed, hit cancel to exit the OUI
iii) Traverse to the ORACLE_BASE directory and delete the artifact directories gc_inst and middleware

- Uninstall the Weblogic component
Most of this part has already been done when the "middleware" directory was removed.
However, it is necessary to perform. one additional step
CD to the installing user's home directory, e.g. /home/oracle
There is a directory here named bea which must be removed, e.g.

> rm -Rf bea
Note:  It will be necessary to re-install the WebLogic component and any required patches before attempting the next EM installation or upgrade attempt.

3.  Update oratab
Default Linux location:  /etc
Default Solaris location: /var/opt/oracle
- Look for entries such as:

*:/u01/app2/middleware/oms11g:N
*:/u01/app2/middleware/agent11g:N

Remove them and save the file
At this point, the following points have been accomplished:
1.  Validate memory parameters have been set correctly
2.  The value of cpu_count has been reduced
3.  The various bits of the failed EM install/upgrade have been cleaned.

Again work through install and upgrade guides and the next attempt should succeed.

References

NOTE:278100.1 - How To Drop, Create And Recreate DB Control In A 10g Database
NOTE:839789.1 - ORA-12853 / ORA-4031 or ORA-4030 on Instance Startup With Increased SGA_MAX_SIZE

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24867586/viewspace-717193/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24867586/viewspace-717193/