I think that's the challenge- scripting to monitor what's important and to avoid scripting that creates "white noise" that you learn to ignore which leads a DBA to missed issues... I can't stand receiving emails that say "I'm OK", where I prefer to have a second script on another server checking my script server to verify everything is running, etc, etc.. Now I did have to overhaul a huge "lot" of shell scripts at a now defunct company that was overscripted to the point of making me laugh... The author was a formidable shell scripter, but if anyone is familiar with the old joke, "the evolution of a programmer", (begins with "echo hello" which returns hello --> evolves to "advanced" programmer, writes 5000 lines and still only returns "hello") -- That was THIS GUY! 8000 line shell script for what I could do in 25.... I finally got to meet this DBA at RMOUG three years back and told him we had some words to share about shell scripting! He must have turned four shades of red, poor guy... :) Keep it simple, make it robust, create error handling and redundancy checks, only report on what matters... :) Kellyn Pedersen Sr. Database Administrator I-Behavior Inc. http://www.linkedin.com/in/kellynpedersen www.dbakevlar.blogspot.com "Go away before I replace you with a very small and efficient shell script..." --- On Wed, 5/5/10, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> wrote: From: Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> Subject: RE: OEMGC and Standard Edition? To: "jkstill@xxxxxxxxx" <jkstill@xxxxxxxxx>, "Gus Spier" <gus.spier@xxxxxxxxx>, "oracle-l" <oracle-l@xxxxxxxxxxxxx> Date: Wednesday, May 5, 2010, 11:35 AM Very true Jared, my scripts are configured very similarly to yours – I only get alerted when there is a problem. Informational and warning messages only go to email while critical alerts go to email + SMS to the cell phone of the DBA on-call – both email & SMS destinations are easily configurable via forwarding rules on a centralized public folder in MS Exchange where all the scripts send their output. I also get a handful of informational scripts daily for things like backups that require an active check to confirm they ran successfully rather than only an alert upon failure, which could fail to alert us if there is a failure with the monitoring script itself. Gus, it sounds like maybe you got stuck with some poorly designed scripts, but you shouldn’t knock them all because of that. I’ve heard many complaints from people using Grid Control that they get overwhelmed with the out of the box alerts as well, so whether you use Grid Control or custom scripts, or some other 3rd party monitoring tool, some work is going to be needed to configure the alerts, adjust thresholds, troubleshoot issues, etc. With custom scripts you have maximum flexibility – that’s the main reason I prefer them. I also find them to be more reliable, but that depends on who is doing your scripting. Regards, Brandon From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jared Still IMO there some elements of using monitoring scripts that must be done correctly to be useful. Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.