Re: Capacity Planner from OEM VS Statspack
- From: Mladen Gogala <mladen@xxxxxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Thu, 5 Feb 2004 14:56:07 -0500
Have you looked into the V$SESSION_WAIT? What did you see?
On 02/05/2004 02:47:03 PM, babette.turnerunderwood@xxxxxxxxxxxxxxx
wrote:
> It is worse than that .....
>
> EVERYONE has noticed that at times the performance is abysmally slow.
> BUT according to all of the mainframe reporting information=20
> Everything is fine... No swapping, no paging, no disk bottleneck, no
> =
> memory problems, no CPU problems.....
>
> For instance, full tablescan (no indexes) to update a NULL column to
> =
> NULL
> on 1 Million rows. Can take up to three times as long at times.
> BUT System people insist there is nothing being pushed at the system
> =
> level.
> The CPU is not maxed out, the disks have no bottlenecks or contention
> =
> and there are no memory problems at this time.
>
> There are only three things, CPU, DISK, Network.
> There has to be something wrong with at least one of them to be
> getting =
> the weird sporadic performance that we get.
>
> It is hard to get overall picture of health of machine in MF =
> environment.
> We have Logical machines (LPARs) on a single physical box.
> I know that I/O on other LPARs can affect our I/O, but we are told
> that =
> there are no problems according to the system records.
>
> The statspack information is a bonus. We have SOMETHING that we can
> say =
> "explain this". Still waiting on explanation for a few weeks now...
>
> Babette
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx =
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Niall Litchfield
> Sent: 2004-02-03 3:21 PM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: RE: Capacity Planner from OEM VS Statspack
>
>
> > I agree with Ian.... Sometimes Statspack is VERY useful..
> >=3D20
> > In our case the Statspack reports shows ave read times of=3D20
> > 1-10ms. However we occasionally see read times of 300-700 ms.
> >=3D20
> > We are currently investigating what is on the slower disks,=3D20
> > What systems are sharing them, and whether oracle is=3D3D20=3D20
> > chaining I/O requests and giving false stats or if there=3D20
> > really is a =3D3D problem. (Hey, on OS/390 mainframe system we=3D20
> > don't get iostat / sar / vmstat / =3D3D
> > top)
> >=3D20
> > This top-down approach doesn't address any SPECIFIC=3D20
> > performance proble. BUT ... if we didn't have Statspack=3D20
> > running periodically, we might have =3D3D missed this.
> >=3D20
> > - Babette
>
> I think the interesting question here is 'If you had missed this,
> would
> anyone care?' and its corollary 'now you have caught it, does anyone
> =3D
> care?'.
> Now I admit that I have a biased view in that all anyone ever seems
> to
> complain to me about is 'Screen X is running slow' or 'we can't
> complete =
> =3D
> our
> management reports overnight' or 'I'm not a dba so your presentation
> on
> managing databases that I chose to attend was irrelevant' - oops
> sorry
> =
> =3D
> not
> that last one. Almost never does anyone whinge that 'the system is
> =3D
> slow', or
> at least when they do they have a specific example in mind. As a
> result =
> =3D
> I am
> definitely biased towards a view that systems don't experience
> problems =
> =3D
> -
> processes do. I *suspect* that even where the *system* is slow then
> =3D
> actually
> it will be fewer than 5 processes that are killing it, but have no
> =3D
> proof.=3D20
>
> Niall
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
