Oracle EBS Application and Database (11.1.0.7) Running Slow

Please Visit http://www.conacent.com/?page_id=218


 Problem :-
 Application and Database Slows down for 15-30 mins.
I have observed that one of the M00N background process taking huge resources. The Load increases to 6-7. I have found in the trace file of M00N some error. Error found in M00N trace file. Error is as follows
" kewrpanp - Clearing the error, continue to next tableDDE: Problem Key 'ORA 12751' was flood controlled (0x6) (no incident)
ORA-12751: cpu time or run time policy violation
*** KEWROCISTMTEXEC - encountered error: (ORA-12751: cpu time or run time policy violation
)
*** SQLSTR: total-len=350, dump-len=240,
STR={delete from WRH$_MEM_DYNAMIC_COMP tab where (:beg_snap <= tab.snap_id and tab.snap_id <= :end_snap and dbid = :dbid) and not exists (select 1 from WRM$_BASELINE b where (tab.dbid = b.dbid) and }
DDE: Problem Key 'ORA 12751' was flood controlled (0x6) (no incident)
ORA-12751: cpu time or run time policy violation
kewrpanp - Failed to purge non-partitioned table, tbid=103, errcode=13509"


Solution :-
These are the post installation steps. (after you have applied patch 10279045)

Post-install steps:
-------------------------
Apply the patch using OPatch (the normal way you would apply the patch)
( Note : Steps 1 and 5 to be followed for RAC environment only)
.
1. For RAC environment only,
set cluster_database=false in the init.ora
.
2. Startup the database in upgrade mode
SQL> startup upgrade
.
3. After the patch has been applied please reload the packages into
the database. To do this connect as SYSDBA and execute the following;
(Note: Order is important)
.
SQL> @?/rdbms/admin/dbmsstat.sql
SQL> @?/rdbms/admin/prvtstas.plb
SQL> @?/rdbms/admin/prvtstai.plb
SQL> @?/rdbms/admin/prvtstat.plb
.
4. Shutdown the database
.
5. For RAC environment only,
set cluster_database=true in the init.ora
.
6. Startup the database in normal mode
SQL> startup



Could you please confirm that you implemented the below things.
1. Check from SYSADMIN for IO throughput of the host.

2. Manual purging of old Optimizer STATS.
REFER : SYSAUX Grows Because Optimizer Stats History is Not Purged (Doc ID 1055547.1)
REFER : Statistics space used by SM/OPTSTAT in the SYSAUX tablespace is not reclaimed after purging (Doc ID 454678.1)
REFER : Suggestions if your SYSAUX Tablespace grows rapidly or too large (Doc ID 1292724.1)