Re: 10g System statistics - single and multi

From: Christo Kutrovsky <kutrovsky.oracle_at_gmail.com>
Date: Tue, 17 May 2005 17:26:32 -0400
Message-ID: <52a152eb050517142673be4b33@mail.gmail.com>

Wolfgang,

"I don't know how you come to that conclusion."

If you refer to the statement under the document, it is not me that is concluding this. It is what is said in that metalink document !!

I find it very strange that they have such logic.

On 5/17/05, Wolfgang Breitling <breitliw_at_centrexcc.com> wrote:
> Christo,

>=20

> I don't know how you come to that conclusion. The value of MBRC does not
> factor into the decision whether to use the new cost formula or not. It
> is mreadtm which needs to be greater than sreadtm for the new cost
> formula (and cpu costing, at least in 9i) to be used. Only then does the
> MBRC value factor in.

>=20

> And I just realized that it misquoted the cost for a FTS under the new
> flrmula. It is of course

>=20

> cost(FTS) =3D #blocks/MBRC * MREADTM / SREADTM

>=20

> I suppose the optimizer developers chose to ignore the system statistics
> if they look suspicious and from their point of view mreadtm has to be
> greater than sreadtm and if it is not they ignore the entire thing. Of
> course, that could change at any time. Until then you need to check the
> values of your gathered system statistics for mreadtm > sreadtm.

>=20

> Christo Kutrovsky wrote:

>=20


> > Yes, this is exactly my observation. I dont understand why Oracle did

> > this ! They will never have this right, it seems.

> >

> > actually, i tried mread =3D 1.00000001 and sread =3D 1 -> cost =3D ~650

> >

> > So basically, this makes using a very high value for mbrc (so that

> > your mread > sread) almost mandatory in 10g, otherwise your FTS costs

> > would use the old formula.

> >
> >

>=20

> --
> Regards

>=20

> Wolfgang Breitling
> Centrex Consulting Corporation
> www.centrexcc.com

>=20

--=20
Christo Kutrovsky
Database/System Administrator
The Pythian Group

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

Received on Tue May 17 2005 - 17:31:09 CDT