RE: Grid Control (Rel 2) Question

From: Taylor, Chris David <Chris.Taylor_at_ingrambarge.com>
Date: Wed, 7 Nov 2007 08:56:24 -0600
Message-ID: <17E4CDE8F84DC44A992E8C00767402E0860C2E@spobmexc02.adprod.directory>

Yes applied the DST patches back in the Spring. Applied necessary patches to agents, and to Grid Control components.

Only 1 agent (out of approximately 7) is experiencing this problem.

Chris Taylor

Sr. Oracle DBA

Ingram Barge Company

Nashville, TN 37205

Office: 615-517-3355

Cell: 615-354-4799

Email: chris.taylor_at_ingrambarge.com

From: Roman Podshivalov [mailto:roman.podshivalov_at_gmail.com] Sent: Wednesday, November 07, 2007 8:49 AM To: Taylor, Chris David
Cc: oracle-l
Subject: Re: Grid Control (Rel 2) Question

DST patches ? Were they applied across the environment ?

--romas

On 11/7/07, Taylor, Chris David <Chris.Taylor_at_ingrambarge.com> wrote:

Anyone ever have problems where an agent starts uploading data with a bad COLLECTION_TIMESTAMP? We're getting ORA-14400 errors - "Inserted Partition Key does not map to any partition".

The table involved is MGMT_METRICS_RAW which is partitioned by date. The XML files that are being uploaded by this agent contain a COLLECTION_TIMESTAMP of "2009-01-27". There is no partition in MGMT_METRICS_RAW that can handle this data. The agent on the affected box appears to be fine and shows the correct dates when doing a 'emctl status agent'. Does anyone know how the agent generates this 'COLLECTION_TIMESTAMP' when its monitoring a host and/or database.

Of course, it's one of our production servers so I can't just remove the monitored targets without a lot of pain of recreating the Grid Control jobs...ugh.

Thoughts?