RE: Capacity Planner from OEM VS Statspack
- From: <babette.turnerunderwood@xxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 6 Feb 2004 13:28:08 -0500
I wish ....
I am still trying to get the managers have the users CC me when there is =
a performance problem. Currently the e-mails are being sent to the =
development manager and the Mainframe SysAdmin person. I am not even in =
the loop. Later I hear from the developers that the system has been slow =
all day....
At least we are not in production yet...
I think the real issue is some form of swapping / paging going on.
However, because of the way the mainframe handles the swapping / paging,
It reports that it is not happening.=20
I believe we have 2GB of REAL memory in this machine. We also have 10 =
instances with 300-600M of irtual memory each. Each Oracle process,=20
runs in an Oracle service that can use up to 2GB of virtual memory=20
for everything (eg SGA, PGA, sort..). The number is supposed to be 2GB,=20
but in reality it is more like 1.8GB.
This is TOTALLY different than UNIX. In UNIX the SGA sits in memory.
In mainframe, only the active pages reside in memory. There is a=20
"working set" that must be able to be loaded into real, expanded or =
"disk swap area". The O/S decides which pages are active and they are in =
memory.
So when I startup an instance with 300M SGA, it might only load 80K of =
pages
in memory....
The machine is to be upgraded this summer and the O/S upgraded in the =
fall.
At that point I can have more than 2Gb of real memory...
It is very frustrating :-(
- Babette
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx =
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mladen Gogala
Sent: 2004-02-05 2:56 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Capacity Planner from OEM VS Statspack
Have you looked into the V$SESSION_WAIT? What did you see?
On 02/05/2004 02:47:03 PM, babette.turnerunderwood@xxxxxxxxxxxxxxx =20
wrote:
> It is worse than that .....
>=20
> EVERYONE has noticed that at times the performance is abysmally slow.
> BUT according to all of the mainframe reporting information=3D20
> Everything is fine... No swapping, no paging, no disk bottleneck, no =20
> =3D
> memory problems, no CPU problems.....
>=20
> For instance, full tablescan (no indexes) to update a NULL column to =20
> =3D
> 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 =20
> =3D
> level.
> The CPU is not maxed out, the disks have no bottlenecks or contention
> =3D
> and there are no memory problems at this time.
>=20
> There are only three things, CPU, DISK, Network.
> There has to be something wrong with at least one of them to be
> getting =3D
> the weird sporadic performance that we get.
>=20
> It is hard to get overall picture of health of machine in MF =3D
> 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 =3D
> there are no problems according to the system records.
>=20
> The statspack information is a bonus. We have SOMETHING that we can
> say =3D
> "explain this". Still waiting on explanation for a few weeks now...
>=20
> Babette
>=20
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx =3D
> [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
>=20
>=20
> > I agree with Ian.... Sometimes Statspack is VERY useful..
> >=3D3D20
> > In our case the Statspack reports shows ave read times of=3D3D20
> > 1-10ms. However we occasionally see read times of 300-700 ms.
> >=3D3D20
> > We are currently investigating what is on the slower disks,=3D3D20
> > What systems are sharing them, and whether oracle is=3D3D3D20=3D3D20
> > chaining I/O requests and giving false stats or if there=3D3D20
> > really is a =3D3D3D problem. (Hey, on OS/390 mainframe system =
we=3D3D20
> > don't get iostat / sar / vmstat / =3D3D3D
> > top)
> >=3D3D20
> > This top-down approach doesn't address any SPECIFIC=3D3D20
> > performance proble. BUT ... if we didn't have Statspack=3D3D20
> > running periodically, we might have =3D3D3D missed this.
> >=3D3D20
> > - Babette
>=20
> 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
> =3D3D
> care?'.
> Now I admit that I have a biased view in that all anyone ever seems =20
> to
> complain to me about is 'Screen X is running slow' or 'we can't
> complete =3D
> =3D3D
> our
> management reports overnight' or 'I'm not a dba so your presentation
> on
> managing databases that I chose to attend was irrelevant' - oops =20
> sorry
> =3D
> =3D3D
> not
> that last one. Almost never does anyone whinge that 'the system is =20
> =3D3D
> slow', or
> at least when they do they have a specific example in mind. As a
> result =3D
> =3D3D
> I am
> definitely biased towards a view that systems don't experience
> problems =3D
> =3D3D
> -
> processes do. I *suspect* that even where the *system* is slow then
> =3D3D
> actually
> it will be fewer than 5 processes that are killing it, but have no =20
> =3D3D
> proof.=3D3D20
>=20
> Niall
>=20
> ----------------------------------------------------------------
> 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
> -----------------------------------------------------------------
>=20
----------------------------------------------------------------
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:
