Mailing List
Home
Forum Home
Oracle List - by freelists.org
Oracle on SUSE Linux - Runing Oracle on SUSE Linux
Oracle database error code ...
www.freelists.org
Subjects
ORA 12540: TNS:internal limit restriction exceeded
ORA 12838 please : Is possible to append two times to the same table befo
ORA 12838 please : Is possible to append two times to the same table before
ora 04031
ora 12500 on windows
ORA 32004: obsolete and/or deprecated parameter(s) specified
ORA 01925: maximum of 30 enabled roles exceeded
ORA 01925: maximum of 30 enabled roles exceeded
ora 12500 on windows
ORA 01650, one idea
ORA 01650
ORA 4030
ORA 12838 please : Is possible to append two times to thesametable before do
ORA 12838 please : Is possible to append two times to thesame table before d
ORA 01536
ORA 03113 end of file on communication channel
ORA 32004: obsolete and/or deprecated parameter(s) specified
ORA 00600:
ORA 00020: maximum number of processes (%s) exceeded
ORA 01925: maximum of 30 enabled roles exceeded
ORA 3113 while creating a cluster database 9201 RAC on Linux with OCFS
ora 12500 on windows
ora 12500 on windows
ora 12500 on windows
ORA 01650, one idea
ora 12500 on windows
ora 12500 on windows
ora 12500 on windows
ORA 2000 Error Using DBMS STATS GATHER SCHEMA STATS
ORA 01650, one idea
ORA 01650, one idea
ORA 01650, one idea
ORA 01650
ORA 01650
Subject: ora 01031
ORA 4030
ORA 4030
ORA 06502: PL/SQL: numeric or value error: Bulk Bind: Truncated Bind
Subject: Re: ORA 01722 invalid number
 
OEM Agent Alert History Graph

OEM Agent Alert History Graph

2007-11-05       - By Charlotte Hammond

 Back
Reply:     1     2  

Hi All,

In the off-chance that anyone was interested in the outcome of this....

I traced the OMS sessions to try to find the query being used to populate the
bar graphs (not immediately obvious which query it was but tracing for a very
short instance around viewing the graph limited the choices).  Turned out it
was this query:



SELECT :B3 +
(CNT.C*:B8 )/:B1 START_POINT, MAX(SEV.SEVERITY_CODE) SEVERITY_CODE FROM (SELECT
/*+ INDEX(s) */ S.COLLECTION_TIMESTAMP, NVL(S.SEVERITY_DURATION/24, :B2
-S.COLLECTION_TIMESTAMP) SEVERITY_DURATION, S.SEVERITY_CODE FROM MGMT_SEVERITY
S WHERE S.TARGET_GUID = :B7 AND S.METRIC_GUID = :B6 AND S.SEVERITY_CODE IN (:B5
, :B4 ) AND S.COLLECTION_TIMESTAMP+NVL(S.SEVERITY_DURATION/24, :B2
-S.COLLECTION_TIMESTAMP) > :B3 AND S.COLLECTION_TIMESTAMP < :B2 ) SEV,
(SELECT /*+ INDEX(o) */ ROWNUM-1 (See http://NUM-1.ora-code.com) C FROM SYS.OBJ$ O WHERE OBJ# > 0 AND ROWNUM
<= :B1 ) CNT WHERE SEV.COLLECTION_TIMESTAMP >= :B3 + (CNT.C*:B8 )/:B1 -
SEV.SEVERITY_DURATION AND SEV.COLLECTION_TIMESTAMP <= :B3 + ((CNT.C+1)*:B8
)/:B1 GROUP BY :B3 + (CNT.C*:B8 )/:B1



For my single collection error it produced 70 rows of data - at chronological
intervals.  However the data was returned in an arbitrary (non-chronological)
order.  

Sorry, BAAG guys :-), but I then guessed that this lack of ordering was the
problem, and so set OPTIMIZER_FEATURE_ENABLE = 9.2.0 and flushed the shared
pool.  Doing this caused the GROUP BY to also do an implicit ordering and
return the data in chronological order.  

Re-freshing the graph in the OEM browser window then redrew the graph exactly
as I expected as a big chunk of red while the target was down, not dozens of
random vertical lines all over the place.

It looks like OEM expects this data to be date-ordered but is relying on GROUP
BY to do it - which won't work with the 10g optimizer.

I've asked a colleague to raise an SR on this - see if we can keep with
OPTIMIZER_FEATURE_ENABLE = 9.2.0 as a workaround, although obviously getting
Oracle to fix the SQL would be better.

Charlotte.



-- --Original
Message-- --

From: oracle-l-bounce@(protected) [mailto:oracle-l-bounce@(protected)] On
Behalf Of Charlotte Hammond

Sent: 01 November 2007 12:16

To: oracle-l@(protected)

Subject: OEM Agent Alert History Graph





Hi All,





I'm using OEM 10.2.0.2 and am having a
problem with a couple of agents.





If, on the Agent's main page, I click on
"Alert History" I see the Metric "Count of targets not uploading
data" I can see, in bar graph format, lots of red vertical lines indicating
critical state in the last 24 hour.  The
pattern is "random" but sometimes several an hour and sometimes 3 or
more hours go by without any.





However, if I click on the bar graph and
get the same information in tabular format there are much, much fewer incidents
(maybe 1 or 2 per day).   Given the
collection schedule is 240 minutes, I can't see how this metric is appearing in
the bar graph several times an hour.  The
tabular data looks much more as I'd expect it.





Furthermore, on one agent, I think I've
cured the problem with the uploads and I see no alerts either in the bar graph
(view data: last 24 hours) or tabular form, yet when I look at the bar graph
(view data: last 7 days) I do still see red error lines which appear *within*
the last 24 hours.





Therefore, my question is, where is the
data coming from in the repository to draw the bar graph?  If I could see the
raw data I'd have a better
idea whether I can trust the bar graph or not.










__ ____ ____ ____ ____ ____ ____ ____ ____ ____ __
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
http://www.freelists.org/webpage/oracle-l