RE: Grid Control (Rel 2) Question

From: Taylor, Chris David <Chris.Taylor_at_ingrambarge.com>
Date: Wed, 7 Nov 2007 09:07:28 -0600
Message-ID: <17E4CDE8F84DC44A992E8C00767402E0860C2F@spobmexc02.adprod.directory>

Also, in the same affected XML files, the COLLECTION_TIMESTAMP is correct for some of the records (even for the same TARGET_GUID) but incorrect for others.

Certain metrics have the 2009 date so its not just one particular metric. For example, Instance Throughput (METRIC_GUID = AFAB5DA8631F9AA3309D30DA60969EC9) is showing 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?