| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: OEM Events
Mark,
We've never been able to keep the OEM events running around here, something to do with the SMTP daemons. Anyway, we do perform that check every hour from a custom in-house created tool.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
Sent: Monday, April 14, 2003 11:54 AM
To: Multiple recipients of list ORACLE-L
Sunny,
There is a whitepaper that I found available from:
www.csis.gvsu.edu/GeneralInfo/Oracle/em.920/a96675.pdf
This is the "Oracle Enterprise Manager Event Test Reference Manual Release 9.2.0" document..
I note two things in this document. For the "Tablespace Full" event, it's "Recommended Frequency" is 30 seconds (!), though it contradicts itself by saying:
"Note: Running the Tablespace Full event test may be a resource-intensive
operation.
Therefore, Oracle recommends running the Tablespace Full event test during
off-peak periods."
It says the same thing with the "Maximum Extents" event as well, stating the "Recommended Frequency" as 10 minutes (you can take that one back at least), whilst still stating:
"Note: Running the Maximum Extents event test may be a resource-intensive operation. Therefore, Oracle recommends running the Maximum Extents event test during off-peak periods."
One last thing to consider, with all of these events set at 5 minute intervals - do they all the checks execute at the same time? How about monitoring the monitor, to see what kind of resources it really is chewing up? I wonder if you will start to see large spikes on five minute intervals ;)
Here's one for the list:
How often do YOU check these limits (tablespace utilisation, and "max extents")?
Regards
Mark
-----Original Message-----
Sent: 14 April 2003 14:50
To: mark_at_cool-tools.co.uk
Thanks for your imput Mark.
I didn't want to get into this but here's the reason why we're in this situation.
The people that are setting the standards (!!) as to what event needs to be
defined on each prod. database are not exactly oracle experts (Enough said
!!), but they are the team leads because of their seniority with the
company. A lot of things they do are based on white papers they've seen
somewhere (In this particular case they claim that if oracle has a default
frequency of 5 minutes, that must be the correct interval) Sadly they're
also not very open to opinions from the more senior oracle dba's in the team
(until they get burnt !!!). If they don't see it on some document / white
paper somewhere , they won't believe it.
For my part I'm breaking down the statements being run by ORACLE and am planning on giving stats as to how much memory it is taking up, and how it is bad to be running these every 5 minutes, etc. I just want to see if there is some else out there (white paper, etc) that I can use to substantiate my findings.
I do have alternate user defined statements that I can run, but I need to get them to withdraw the "standards" before I can implement them :-) !!
Sunny
Mark Leith <mark_at_cool-tools.co.uk> wrote: Sunny,
Given the list below, I would say that the real "performance killer" would be the "max_extents" check. This would of course depend upon the number of tables and indexes with your instances schemas, but I would never tell anybody to set that one collection on an interval of 5 minutes. Every 5 hours maybe.. Even better, how about an "Event" that checks for tables or indexes that can't throw 5 extents, or a percentage of extents allocated and check that every 6 hours? "Your mileage may vary"..
What you mention about the tablespace check seems odd to me as well.. I'm no expert on OEM events (maybe someone else can help on that side), but can't you create your own custom event, based upon a script that checks all tablespaces utilisation, and evaluate it on a row by row basis (per tablespace)? Again, if you monitor this by tablespace percentage, how about setting it to 90% full, and doing it on a less frequent basis. The key is in setting the "threshold" (the event trigger) to something that gives you a reasonable amount of time to fix the "problem" before it arises..
And the final thing to take note of, is that each database that you have will have it's own characteristics, there is really no hard "set in stone" guideline for monitoring frequencies. You as the DBA are there to apply the human logic, once getting a feel for how your individual databases grow or behave.
There are a number of example "Collections" that have been written for our own monitoring tool available from:
http://www.cool-tools.co.uk/Support/UDC/Oracle/
They are all SQL based, and have been built by users, or on request by users.. Maybe you can make use of them. :)
HTH Mark
-----Original Message-----
Sent: 13 April 2003 17:43
To: Multiple recipients of list ORACLE-L
Hello,
Is anyonw aware of performace issues related to setting too many OEM
(9.2.0.1) events ???
At the site that I am currently at, they have the following events set on
all production databases. The frequenct for ALL these events is 5 minutes
probe
tablespace_full
max_extents
process_limit
session_limit
For one thing I am noticing that OEM does not use bind variables (go figure
!!!), so if there are a 100 sessions I see 100 statements with the only
diff. being sid = ???? . Also if there are say a 100 tablespaces
again, there are a 100 statements in the shared pool with the
tablespace name being the only difference.
In my mind , setting the above events at the frequency specified can cause
performance problems, especially if it is a very active database. IS that
accurate ?? If so, are there any notes / white papers about this.
Thanks,
Sunny
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mark Leith INET: mark_at_cool-tools.co.uk Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-LReceived on Mon Apr 14 2003 - 11:13:38 CDT
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing). Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mark Leith INET: mark_at_cool-tools.co.uk Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Goulet, Dick INET: DGoulet_at_vicr.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
 |
 |