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

Home -> Community -> Usenet -> c.d.o.server -> Re: statspack setup question

Re: statspack setup question

From: Ed Stevens <spamdump_at_nospam.noway.nohow>
Date: Thu, 21 Nov 2002 13:30:46 GMT
Message-ID: <3ddcded4.48173239@ausnews.austin.ibm.com>


Comments embedded

On Wed, 20 Nov 2002 21:29:04 +0100, "Anton Buijs" <aammbuijs_at_xs4all.nl> wrote:

>Comment embedded
>
>Ed Stevens <spamdump_at_nospam.noway.nohow> schreef in berichtnieuws
>3ddbd416.67114375_at_ausnews.austin.ibm.com...
>| Well, I finally made the 'leap' (uh, slight hop?) from utlestat to
>statspack.
>| Installed on one test database and liked what I saw. Now I need to
>install it
>| on at least one (and ultimately, all) of my prod databases. A couple of
>| questions about 'best practice'
>|
>| First, any recommendations on best extent size to define for the TS that
>will
>| hold the perfstat schema?
>
>Doesn't that depend on the interval of the snapshots and how long you want
>to keep history? Or turn it around: how much space do you want to give it,
>so that determines how much history you can keep.
>

I would think that optimal *extent* size would be tied to row length of the tables. Number of snapshots/amount of history would be limited by maxextents and total tablespace size.
>|
>| Second, it looks like we will need to set it to take snapshots at regular
>| intervals through eight hour periods. Any recommendations on the optimum
>| interval? Every five minutes? Thirty minutes? One hour?
>
>I would say it's the same as with utbstat/estat: the smaller the interval,
>the more you focus on a particular problem. The larger the interval the more
>the effects are leveled out.
>In one of my conversations (before the iTAR exists) with an Oracle RDMS
>expert of Technical Support I had the advice to run bstat/estat for 10
>minutes when you want to focus on a particular problem.
>Run it for 1 hour when a more general impression is wanted.
>

In general, it would be a daily or weekly 'health check' of the databases. However, the db currently in question is under rather intense scrutiny, though there is no 'specific' problem being watched for.

>| As an aside, we are also investigating more sophisticated packages to
>assist in
>| monitoring and tuning. Right now we are looking at BMC Patrol, Quest
>Spotlight,
>| and of course OEM. Any thoughts or recommendations on any of these
>products?
>| My partner went through a demo of Spotlight yesterday and is ready to buy
>it.
>
>Can Spotlight monitor events and send out emails? We have the product but
>then I must have a closer look at it, because I've not found that yet. I
>only know it as an interactive tool that has a magnificent start screen, but
>almost all other screens are available in Toad too and look exactly the
>same. The start screen shows all components of the database, how loaded they
>are (like number of block gets per second) and the color shows where there
>are problems (shared pool shows red when too many parse calls occur for
>instance).
>Worked in an environment where BMC Patrol was used but I was not heavily
>involved. My impression is it can do a wonderfull job but it took much
>resources on the host (on Unix it was in top most of the time....) and is
>expensive. The out-of-the-box settings are definitly not the ones you want
>to work with.
>We currently monitor all our databases with one Oracle Management server (10
>nodes, 40 databases, 4 different platforms, 3 different Oracle versions) and
>I am very happy with it. Beside the events we have scheduled jobs to cleanup
>trace files etc. Sometimes the Oracle Agent on a host gets crazy, killing
>and restarting not always helps and a "clean start" is needed, but we can
>live with it. We can be very pro-active now. And you already paid for it
>with the Oracle license. We moved the OMS from Windows 2000 to a HP-UX host
>(V8.1.7.3) but we are considering moving it back because it crashes every
>time we deregister 3 events or more at a time. Yes, I unfortunately must
>admit that in this case an Oracle product runs more stable on Microsoft. I
>think because almost nobody runs OMS on Unix so bugs are not reported and
>therefore not fixed.
>
>|
>| TIA
>| --
>| Ed Stevens
>| (Opinions expressed do not necessarily represent those of my employer.)
>
>

--
Ed Stevens
(Opinions expressed do not necessarily represent those of my employer.)
Received on Thu Nov 21 2002 - 07:30:46 CST

Original text of this message

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