Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Grid Control (Rel 2) Question

RE: Grid Control (Rel 2) Question

From: Taylor, Chris David <Chris.Taylor_at_ingrambarge.com>
Date: Thu, 8 Nov 2007 07:15:10 -0600
Message-ID: <17E4CDE8F84DC44A992E8C00767402E0860C37@spobmexc02.adprod.directory>


Hey, thanks! I was trying to narrow down where that date was coming from. I'll poke around those views to see if I can find the bad date and I'll pull up that bug also.

Thanks again!

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
-----Original Message-----
From: Edgar Chupit [mailto:chupit_at_gmail.com] Sent: Thursday, November 08, 2007 4:06 AM To: Taylor, Chris David
Cc: oracle-l
Subject: Re: Grid Control (Rel 2) Question

Dear Chris,

I have had (still have) similar issues. Basically in our case it's due to the Bug: 6162079 V$SYSMETRIC_HISTORY HAS FUTURE TIMESTAMP (Or very similar to this bug)
Oracle Support is still working on fixing this issue.

In our case the situation is as follows on some of the instances timestamp in V$%METRIC views shows completely incorrect time (+1 year and some days).

Oracle EM Agent is using data from this view and tries to upload it to EM Repository, because timestamp is in future partition for that timestamp is not created and it reports error ORA-14400

If you want I can provide you with more details.

I have fixed issue with ORA-14400 by adding additional partition manually, but issue with V$%METRIC views is still unresolved.

On Nov 7, 2007 5:18 PM, Taylor, Chris David <Chris.Taylor_at_ingrambarge.com> wrote:
>
>
>
>
> Be aware, that the date that is off is not an hour....Its 2 years+
> (2009-01-27)
>
>
>
> But thanks anyway...
>
>
>
>
>
>
>
> 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: Elliott, Patrick [mailto:patrick.elliott_at_medtronic.com]
> Sent: Wednesday, November 07, 2007 10:18 AM
> To: kennaim_at_gmail.com; Taylor, Chris David; 'oracle-l'
>
>
> Subject: RE: Grid Control (Rel 2) Question
>
>
>
>
>
> Have you applied the latest DST patches? If not, then that could
easily
> cause a problem like this. If you applied the patch on one system,
but
> missed another one, then they would be an hour off.
>
>
>
>
> Pat
>
>
>
>
>
> ________________________________
>
>
> From: oracle-l-bounce_at_freelists.org

[mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of Ken Naim
> Sent: Wednesday, November 07, 2007 9:30 AM
> To: Chris.Taylor_at_ingrambarge.com; 'oracle-l'
> Subject: RE: Grid Control (Rel 2) Question
>
> While I don't know for sure, I think this happened to me on Monday
morning,
> one of my target database nodes (node 1 of 4) fell behind an hour even
> though all xml files were being uploaded. I stopped and started the
agents
> and it resolved it self although we lost data for that 1 node for an
hour.
>
>
>
> Ken
>
>
>
> ________________________________
>
>
> From: oracle-l-bounce_at_freelists.org

[mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of Taylor, Chris David
> Sent: Wednesday, November 07, 2007 9:21 AM
> To: oracle-l
> Subject: Grid Control (Rel 2) Question
>
>
>
> 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_at_ingrambarge.com
>
>
>
>
>




> CONFIDENTIALITY AND PRIVACY NOTICE
> Information transmitted by this email is proprietary to Medtronic and
is
> intended for use only by the individual or entity to which it is
addressed,
> and may contain information that is private, privileged, confidential
or
> exempt from disclosure under applicable law. If you are not the
intended
> recipient or it appears that this mail has been forwarded to you
without
> proper authority, you are notified that any use or dissemination of
this
> information in any manner is strictly prohibited. In such cases,
please
> delete this mail from your records.
>
> To view this notice in other languages you can either select the
following
> link or manually copy and paste the link into the address bar of a web
> browser: http://emaildisclaimer.medtronic.com
>
-- 
Best regards,
 Edgar Chupit
 callto://edgar.chupit


--
http://www.freelists.org/webpage/oracle-l
Received on Thu Nov 08 2007 - 07:15:10 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US