:

ORA-14400: inserted partition key does not map to any partition

The Problem

Your Enterprise Manager becomes very slow and unresponsive when navigating around within the front end. It also becomes difficult to get to the performance screen for your instances.

Firstly, look in the file emoms.log found in $ORACLE_OMS_HOME\sysman\log

On Windows for me this was D:\oracle\oms10g\sysman\log\emoms.log

In this file you should see the error ORA-14400: inserted partition key does not map to any partition

The Cause

This is because the data that the agent is sending and trying to insert into the grid database is in the future.
It’s a known bug:

Bug 5880921: TIME INCONSISTENCY BETWEEN V$SYSMETRIC_HISTORY AND SYSDATE FROM DUAL

You can see if you are hitting this bug by looking inD:\oracle\oms10g\sysman\recv\errors. There should be lots
of files there, open one up and search for a date in the future. If it’s 2010, then search for 2011 for example.

Next, find the target_guid of the ones which have a data of 2011. Here is a snippet taken from one of the files:

<ROW>
<TARGET_GUID>31D12B3B41E38113F765BAA3578A769B</TARGET_GUID>
<METRIC_GUID>BE867518373EFAAF9500D6365493CF37</METRIC_GUID>
<KEY_VALUE/>
<COLLECTION_TIMESTAMP>2011-08-25 18:36:28</COLLECTION_TIMESTAMP>
<VALUE>93.743143</VALUE>
</ROW>

As you can see, the timestamp is wrong. Today’s date is Friday 4th June 2010.

To find out which target it is, log into your repository database as the sysman user and run this:

select target_guid, target_name, target_type, emd_url
from mgmt_targets
where target_guid = ’31D12B3B41E38113F765BAA3578A769B’;

Insert your own target_guid from the file you have just looked at.

It will usually be a database causing the issue. If this is the case, log into the problem DB as the SYS user and then run:

select to_char(max(end_time),’dd-mon-yyyy hh24:mi:ss’)
from v$sysmetric_history;

select to_char(sysdate, ‘DD-MON-YY HH24:MI:SS’) from dual;

You should see a large difference like this below:

SQL> select to_char(max(end_time),’dd-mon-yyyy hh24:mi:ss’)
2 from v$sysmetric_history;

TO_CHAR(MAX(END_TIME),’DD-MON-
—————————————————————–
25-aug-2011 19:49:53

SQL>
SQL> select to_char(sysdate, ‘DD-MON-YY HH24:MI:SS’) from dual;

TO_CHAR(SYSDATE,’DD-MON-YYHH2
—————————————————————–
04-JUN-10 10:24:38

Supposedly, there should not be a difference of more than a few seconds…

You can also run this:

select to_char(sysdate, ‘dd-mm-yyyy hh:mi:ss’) current_time,to_char(end_time,’dd-mm-yyyy hh:mi:ss’)
end_time,intsize_csec
from gv$waitclassmetric_history
where rownum < 5;

You can get more details by looking at Metalink note 303359.1.

The solution

Bounce your database and the OEM will start working again.

Like it, share it...

Category: Enterprise Manager


Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *