Re: Routine Checks

Just about everything from 8.1.7.4 to 10.2.0.2. Although, we upgraded the 8i databases shortly after implementing EM10gR2, so I do not think we actually tried the EM features on the 8i databases. However, things work well for the 9i databases, and I have not experienced any problems related to version incompatibilities. We did use the 9i console, but mostly to monitor Production databases for various events (we turned a majority of them off). Our group is much happier with the 10g console (if you can call it that) over the 9i console, even given the various little nuances (ie, you do not always know where you are drilling down to, some of the links are completely counter-intuitive or just incorrect, navigating backwards can be tricky).

Actually, one of the most poignant lessons we learned was very serious at the time, but perhaps a little funny now. I share this with you all so you do not repeat it.

Be very careful when playing with the Maintenance Window. If you follow "Administration" tab -> "Windows" -> edit "WEEKEND" or "WEEKNIGHT". Note how the default RESOURCE PLAN is INTERNAL_QUIESCE. If you wish to strictly change the time of the window (say, one hour later) and forget to change the Resource Plan, you will be screwed (unless you really intend to put your database into a coma). I brought this up with our Oracle Sales Rep and percolated the issue as much as possible, but as far as I know, this issue has not been fixed yet. Beware the defaults!

The silver lining is that you can get some very obscure and exotic experience in trouble-shooting a database that accidentally quiesced. Would make for a good scenario in one of the DBA workshops.

On 8/16/06, Mercadante, Thomas F (LABOR) < Thomas.Mercadante_at_labor.state.ny.us> wrote:
>
> Charles,
>
>
>
> Thanks for the advice. Do you use EM10gR2 to monitor or manage any 9i
> databases? Did you stop using the 9i console?
>
>
>
> Thanks
>
>
> Tom
>
>
> ------------------------------
>
> This transmission may contain confidential, proprietary, or privileged
> information which is intended solely for use by the individual or entity to
> whom it is addressed. If you are not the intended recipient, you are
> hereby notified that any disclosure, dissemination, copying or distribution
> of this transmission or its attachments is strictly prohibited. In
> addition, unauthorized access to this transmission may violate federal or
> State law, including the Electronic Communications Privacy Act of 1985. If
> you have received this transmission in error, please notify the sender
> immediately by return e-mail and delete the transmission and its
> attachments.
>
> ------------------------------
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Charles Schultz
> *Sent:* Wednesday, August 16, 2006 9:07 AM
> *To:* niall.litchfield_at_gmail.com; oracle-l
> *Subject:* Re: Routine Checks
>
>
>
> On the subject of EM10gR2:
>
> We had an Oracle instructor who told us to forget about trying to use
> EM10gR1, as it was "not ready" for public consumption. So we waited for R2
> and were glad we did. Most things work quite well, and there are a few
> quirks here and there (especially where the documentation says one thing and
> EM says another). Due to EM's micromanagement style, we have not turned on
> any of the email alerts until we have a good grasp of what exactly we want
> to be notified of, but we do use it as a Monitor to gauge overall system
> health and to drill down quickly on problem areas. I do not believe we have
> come across any critical components that outright fail. We have a couple SRs
> with Oracle Support about issues with the OMS and the agent core dumping or
> hanging, but that does not directly affect the performance of the target
> database, only the monitoring thereof.
>
>
>
> On 8/16/06, *Niall Litchfield* <niall.litchfield_at_gmail.com> wrote:
>
> As some of you will have picked up I am in a relatively new position. One
> of the things sadly lacking is any sort of pro-active monitoring routine.
> This is something that I want to introduce, but my experience of, for
> example, daily checks is that they tend not to happen after a while. So I
> guess my question is what would you add to/remove from a list of daily
> checks for all production databases that read.
>
> 1) database up
> 2) application up
> 3) alert.log errors
> 4) audit trails
> 5) backup success/failure
> 6) dr logs applied (where applicable)
> 7) failed jobs
>
> and for a weekly list
>
> 1) db size
> 2) object size
> 3) availability
> 4) listener.log errors
> 5) redo/transaction volume
>
>
> You'll see that I'm mainly coming at this from a security and availability
> standpoint - I don't see that performance is amenable to routine system wide
> checks.
>
> A related question is how many of you are using, specifically, 10gR2 EM to
> automate these sorts of things. We have a pretty dire EM10gR1 implementation
> that I wish to redo and 10gR2 looks an order of magnitude better than R1,
> but any gotchas - like it doesn't work - would be nice to know ahead of
> time.
>
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
>
>
>
>
> --
> Charles Schultz
>
>

-- 
Charles Schultz

--
http://www.freelists.org/webpage/oracle-l