RE: Grid Control (Rel 2) Question
- From: "Taylor, Chris David" <Chris.Taylor@xxxxxxxxxxxxxxx>
- To: "Roman Podshivalov" <roman.podshivalov@xxxxxxxxx>
- Date: Wed, 7 Nov 2007 09:07:28 -0600
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@xxxxxxxxxxxxxxx
________________________________
From: Roman Podshivalov [mailto:roman.podshivalov@xxxxxxxxx]
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@xxxxxxxxxxxxxxx> 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?
Chris Taylor
Sr. Oracle DBA
Ingram Barge Company
Nashville, TN 37205
Office: 615-517-3355
Cell: 615-354-4799
Email: chris.taylor@xxxxxxxxxxxxxxx
Other related posts:
