> We only have one pool -- DEFAULT.  So we would expect the values to be
> at least close, if not the same.  They are usually the same, but
> several times in the course of a day they are VERY different.

> In addition to be different enough to trigger the alert, the values in
> V$BUFFER_POOL_STATISTICS are sometimes a negative value.  What's up
> with that?

> Can anyone explain to me why V$BUFFER_POOL_STATISTICS sometimes has
> negative values or has very different values from V$SYSSTAT?  We'd
> like to know if we really have an issue with the size of our cache, or
> one of those views isn't the right one to use.

> Here are the queries being:

> SELECT ROUND(((SUM(cur.value) + SUM(con.value) - SUM(phy.value)) /
> (SUM(cur.value) + SUM(con.value))) * 100, 2) AS
> CLUSTER_CACHE_HIT_RATIO
> FROM v$sysstat cur, gv$sysstat con, gv$sysstat phy
> WHERE cur.name = 'db block gets'
> AND con.name = 'consistent gets'
> AND phy.name = 'physical reads'

> SELECT DECODE(NAME, 'DEFAULT', DECODE(block_size, 2048, 'CACHE_2K',
> 4096, 'CACHE_4K', 8192, 'CACHE_8K', 16384, 'CACHE_16K', 'CACHE_32K'),
> NAME) NAME ,  PHYSICAL_READS,  DB_BLOCK_GETS,  CONSISTENT_GETS,
>     ( 1 - ((DECODE (PHYSICAL_READS, 0, 1, PHYSICAL_READS)) /
> DECODE((DB_BLOCK_GETS + CONSISTENT_GETS),0, DECODE(PHYSICAL_READS, 0,
> 1, PHYSICAL_READS) ,(DB_BLOCK_GETS + CONSISTENT_GETS)))) * 100 AS
> BUFFER_RATIO
> FROM V$BUFFER_POOL_STATISTICS

> Any assistance in helping us make sense of this is greatly
> appreciated.

> Teresa Masino

> > We have acquired a software package that sends alerts based on defined
> > thresholds and/or events.  We are working on a simple alert like when
> > the cache hit ratio falls below a given threshold.  The package came
> > with a query that uses the V$BUFFER_POOL_STATISTICS view.  We have
> > typically used a query based on the V$SYSSTAT view.  We left the query
> > in place that came with the product, but it reports low cache hit
> > ratios pretty frequently whereas putting another alert in place that
> > uses V$SYSSTAT does not.

> > We only have one pool -- DEFAULT.  So we would expect the values to be
> > at least close, if not the same.  They are usually the same, but
> > several times in the course of a day they are VERY different.

> > In addition to be different enough to trigger the alert, the values in
> > V$BUFFER_POOL_STATISTICS are sometimes a negative value.  What's up
> > with that?

> > Can anyone explain to me why V$BUFFER_POOL_STATISTICS sometimes has
> > negative values or has very different values from V$SYSSTAT?  We'd
> > like to know if we really have an issue with the size of our cache, or
> > one of those views isn't the right one to use.

> > Here are the queries being:

> > SELECT ROUND(((SUM(cur.value) + SUM(con.value) - SUM(phy.value)) /
> > (SUM(cur.value) + SUM(con.value))) * 100, 2) AS
> > CLUSTER_CACHE_HIT_RATIO
> > FROM v$sysstat cur, gv$sysstat con, gv$sysstat phy
> > WHERE cur.name = 'db block gets'
> > AND con.name = 'consistent gets'
> > AND phy.name = 'physical reads'

> > SELECT DECODE(NAME, 'DEFAULT', DECODE(block_size, 2048, 'CACHE_2K',
> > 4096, 'CACHE_4K', 8192, 'CACHE_8K', 16384, 'CACHE_16K', 'CACHE_32K'),
> > NAME) NAME ,  PHYSICAL_READS,  DB_BLOCK_GETS,  CONSISTENT_GETS,
> >     ( 1 - ((DECODE (PHYSICAL_READS, 0, 1, PHYSICAL_READS)) /
> > DECODE((DB_BLOCK_GETS + CONSISTENT_GETS),0, DECODE(PHYSICAL_READS, 0,
> > 1, PHYSICAL_READS) ,(DB_BLOCK_GETS + CONSISTENT_GETS)))) * 100 AS
> > BUFFER_RATIO
> > FROM V$BUFFER_POOL_STATISTICS

> > Any assistance in helping us make sense of this is greatly
> > appreciated.

> > Teresa Masino

> Which release of Oracle is this?

> David Fitzjarrell- Hide quoted text -

> - Show quoted text -

> > On Aug 8, 10:57 am, Teresa Masino <teresa.mas...@peninsula.org> wrote:

> > > We have acquired a software package that sends alerts based on defined
> > > thresholds and/or events.  We are working on a simple alert like when
> > > the cache hit ratio falls below a given threshold.  The package came
> > > with a query that uses the V$BUFFER_POOL_STATISTICS view.  We have
> > > typically used a query based on the V$SYSSTAT view.  We left the query
> > > in place that came with the product, but it reports low cache hit
> > > ratios pretty frequently whereas putting another alert in place that
> > > uses V$SYSSTAT does not.

> > > We only have one pool -- DEFAULT.  So we would expect the values to be
> > > at least close, if not the same.  They are usually the same, but
> > > several times in the course of a day they are VERY different.

> > > In addition to be different enough to trigger the alert, the values in
> > > V$BUFFER_POOL_STATISTICS are sometimes a negative value.  What's up
> > > with that?

> > > Can anyone explain to me why V$BUFFER_POOL_STATISTICS sometimes has
> > > negative values or has very different values from V$SYSSTAT?  We'd
> > > like to know if we really have an issue with the size of our cache, or
> > > one of those views isn't the right one to use.

> > > Here are the queries being:

> > > SELECT ROUND(((SUM(cur.value) + SUM(con.value) - SUM(phy.value)) /
> > > (SUM(cur.value) + SUM(con.value))) * 100, 2) AS
> > > CLUSTER_CACHE_HIT_RATIO
> > > FROM v$sysstat cur, gv$sysstat con, gv$sysstat phy
> > > WHERE cur.name = 'db block gets'
> > > AND con.name = 'consistent gets'
> > > AND phy.name = 'physical reads'

> > > SELECT DECODE(NAME, 'DEFAULT', DECODE(block_size, 2048, 'CACHE_2K',
> > > 4096, 'CACHE_4K', 8192, 'CACHE_8K', 16384, 'CACHE_16K', 'CACHE_32K'),
> > > NAME) NAME ,  PHYSICAL_READS,  DB_BLOCK_GETS,  CONSISTENT_GETS,
> > >     ( 1 - ((DECODE (PHYSICAL_READS, 0, 1, PHYSICAL_READS)) /
> > > DECODE((DB_BLOCK_GETS + CONSISTENT_GETS),0, DECODE(PHYSICAL_READS, 0,
> > > 1, PHYSICAL_READS) ,(DB_BLOCK_GETS + CONSISTENT_GETS)))) * 100 AS
> > > BUFFER_RATIO
> > > FROM V$BUFFER_POOL_STATISTICS

> > > Any assistance in helping us make sense of this is greatly
> > > appreciated.

> > > Teresa Masino

> > Which release of Oracle is this?

> > David Fitzjarrell- Hide quoted text -

> > - Show quoted text -

> duh, sorry.  We're running 10g.  Specifically:

> Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 on one
> server and Oracle Database 10g Enterprise Edition Release 10.2.0.1.0
> on another.

> Teresa- Hide quoted text -

> - Show quoted text -

> > On Aug 8, 12:22 pm, "fitzjarr...@cox.net" <fitzjarr...@cox.net> wrote:

> > > On Aug 8, 10:57 am, Teresa Masino <teresa.mas...@peninsula.org> wrote:

> > > > We have acquired a software package that sends alerts based on defined
> > > > thresholds and/or events.  We are working on a simple alert like when
> > > > the cache hit ratio falls below a given threshold.  The package came
> > > > with a query that uses the V$BUFFER_POOL_STATISTICS view.  We have
> > > > typically used a query based on the V$SYSSTAT view.  We left the query
> > > > in place that came with the product, but it reports low cache hit
> > > > ratios pretty frequently whereas putting another alert in place that
> > > > uses V$SYSSTAT does not.

> > > > We only have one pool -- DEFAULT.  So we would expect the values to be
> > > > at least close, if not the same.  They are usually the same, but
> > > > several times in the course of a day they are VERY different.

> > > > In addition to be different enough to trigger the alert, the values in
> > > > V$BUFFER_POOL_STATISTICS are sometimes a negative value.  What's up
> > > > with that?

> > > > Can anyone explain to me why V$BUFFER_POOL_STATISTICS sometimes has
> > > > negative values or has very different values from V$SYSSTAT?  We'd
> > > > like to know if we really have an issue with the size of our cache, or
> > > > one of those views isn't the right one to use.

> > > > Here are the queries being:

> > > > SELECT ROUND(((SUM(cur.value) + SUM(con.value) - SUM(phy.value)) /
> > > > (SUM(cur.value) + SUM(con.value))) * 100, 2) AS
> > > > CLUSTER_CACHE_HIT_RATIO
> > > > FROM v$sysstat cur, gv$sysstat con, gv$sysstat phy
> > > > WHERE cur.name = 'db block gets'
> > > > AND con.name = 'consistent gets'
> > > > AND phy.name = 'physical reads'

> > > > SELECT DECODE(NAME, 'DEFAULT', DECODE(block_size, 2048, 'CACHE_2K',
> > > > 4096, 'CACHE_4K', 8192, 'CACHE_8K', 16384, 'CACHE_16K', 'CACHE_32K'),
> > > > NAME) NAME ,  PHYSICAL_READS,  DB_BLOCK_GETS,  CONSISTENT_GETS,
> > > >     ( 1 - ((DECODE (PHYSICAL_READS, 0, 1, PHYSICAL_READS)) /
> > > > DECODE((DB_BLOCK_GETS + CONSISTENT_GETS),0, DECODE(PHYSICAL_READS, 0,
> > > > 1, PHYSICAL_READS) ,(DB_BLOCK_GETS + CONSISTENT_GETS)))) * 100 AS
> > > > BUFFER_RATIO
> > > > FROM V$BUFFER_POOL_STATISTICS

> > > > Any assistance in helping us make sense of this is greatly
> > > > appreciated.

> > > > Teresa Masino

> > > Which release of Oracle is this?

> > > David Fitzjarrell- Hide quoted text -

> > > - Show quoted text -

> > duh, sorry.  We're running 10g.  Specifically:

> > Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 on one
> > server and Oracle Database 10g Enterprise Edition Release 10.2.0.1.0
> > on another.

> > Teresa- Hide quoted text -

> > - Show quoted text -

> Does this negative output occur on both releases?  It appears to work
> fine on my 10.2.0.2 database.

> David Fitzjarrell- Hide quoted text -

> - Show quoted text -

> > On Aug 8, 11:30 am, Teresa Masino <teresa.mas...@peninsula.org> wrote:

> > > On Aug 8, 12:22 pm, "fitzjarr...@cox.net" <fitzjarr...@cox.net> wrote:

> > > > On Aug 8, 10:57 am, Teresa Masino <teresa.mas...@peninsula.org> wrote:

> > > > > We have acquired a software package that sends alerts based on defined
> > > > > thresholds and/or events.  We are working on a simple alert like when
> > > > > the cache hit ratio falls below a given threshold.  The package came
> > > > > with a query that uses the V$BUFFER_POOL_STATISTICS view.  We have
> > > > > typically used a query based on the V$SYSSTAT view.  We left the query
> > > > > in place that came with the product, but it reports low cache hit
> > > > > ratios pretty frequently whereas putting another alert in place that
> > > > > uses V$SYSSTAT does not.

> > > > > We only have one pool -- DEFAULT.  So we would expect the values to be
> > > > > at least close, if not the same.  They are usually the same, but
> > > > > several times in the course of a day they are VERY different.

> > > > > In addition to be different enough to trigger the alert, the values in
> > > > > V$BUFFER_POOL_STATISTICS are sometimes a negative value.  What's up
> > > > > with that?

> > > > > Can anyone explain to me why V$BUFFER_POOL_STATISTICS sometimes has
> > > > > negative values or has very different values from V$SYSSTAT?  We'd
> > > > > like to know if we really have an issue with the size of our cache, or
> > > > > one of those views isn't the right one to use.

> > > > > Here are the queries being:

> > > > > SELECT ROUND(((SUM(cur.value) + SUM(con.value) - SUM(phy.value)) /
> > > > > (SUM(cur.value) + SUM(con.value))) * 100, 2) AS
> > > > > CLUSTER_CACHE_HIT_RATIO
> > > > > FROM v$sysstat cur, gv$sysstat con, gv$sysstat phy
> > > > > WHERE cur.name = 'db block gets'
> > > > > AND con.name = 'consistent gets'
> > > > > AND phy.name = 'physical reads'

> > > > > SELECT DECODE(NAME, 'DEFAULT', DECODE(block_size, 2048, 'CACHE_2K',
> > > > > 4096, 'CACHE_4K', 8192, 'CACHE_8K', 16384, 'CACHE_16K', 'CACHE_32K'),
> > > > > NAME) NAME ,  PHYSICAL_READS,  DB_BLOCK_GETS,  CONSISTENT_GETS,
> > > > >     ( 1 - ((DECODE (PHYSICAL_READS, 0, 1, PHYSICAL_READS)) /
> > > > > DECODE((DB_BLOCK_GETS + CONSISTENT_GETS),0, DECODE(PHYSICAL_READS, 0,
> > > > > 1, PHYSICAL_READS) ,(DB_BLOCK_GETS + CONSISTENT_GETS)))) * 100 AS
> > > > > BUFFER_RATIO
> > > > > FROM V$BUFFER_POOL_STATISTICS

> > > > > Any assistance in helping us make sense of this is greatly
> > > > > appreciated.

> > > > > Teresa Masino

> > > > Which release of Oracle is this?

> > > > David Fitzjarrell- Hide quoted text -

> > > > - Show quoted text -

> > > duh, sorry.  We're running 10g.  Specifically:

> > > Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 on one
> > > server and Oracle Database 10g Enterprise Edition Release 10.2.0.1.0
> > > on another.

> > > Teresa- Hide quoted text -

> > > - Show quoted text -

> > Does this negative output occur on both releases?  It appears to work
> > fine on my 10.2.0.2 database.

> > David Fitzjarrell- Hide quoted text -

> > - Show quoted text -

> Most of the time the queries return expected results for us too.  If I
> run the queries in a loop that sleeps for 30 seconds or so and let it
> go for a while, they eventually report different results.  It can take
> 10 minutes to see a discrepancy, it can take over an hour.  But at
> some point, they do report different values.  Which leads us to wonder
> which one we should pay attention to.  One of them tells us things are
> fine and the other says they aren't.  And then there's the wild part
> where the BUFFER_POOL_STATISTICS view has negative values.  That part
> alone makes me question the validity of those values, but I thought
> I'd check here to see if anyone knows for sure.

> Thanks
> Teresa- Hide quoted text -

> - Show quoted text -

> > On Aug 8, 12:53 pm, "fitzjarr...@cox.net" <fitzjarr...@cox.net> wrote:

> > > On Aug 8, 11:30 am, Teresa Masino <teresa.mas...@peninsula.org> wrote:

> > > > On Aug 8, 12:22 pm, "fitzjarr...@cox.net" <fitzjarr...@cox.net> wrote:

> > > > > On Aug 8, 10:57 am, Teresa Masino <teresa.mas...@peninsula.org> wrote:

> > > > > > We have acquired a software package that sends alerts based on defined
> > > > > > thresholds and/or events.  We are working on a simple alert like when
> > > > > > the cache hit ratio falls below a given threshold.  The package came
> > > > > > with a query that uses the V$BUFFER_POOL_STATISTICS view.  We have
> > > > > > typically used a query based on the V$SYSSTAT view.  We left the query
> > > > > > in place that came with the product, but it reports low cache hit
> > > > > > ratios pretty frequently whereas putting another alert in place that
> > > > > > uses V$SYSSTAT does not.

> > > > > > We only have one pool -- DEFAULT.  So we would expect the values to be
> > > > > > at least close, if not the same.  They are usually the same, but
> > > > > > several times in the course of a day they are VERY different.

> > > > > > In addition to be different enough to trigger the alert, the values in
> > > > > > V$BUFFER_POOL_STATISTICS are sometimes a negative value.  What's up
> > > > > > with that?

> > > > > > Can anyone explain to me why V$BUFFER_POOL_STATISTICS sometimes has
> > > > > > negative values or has very different values from V$SYSSTAT?  We'd
> > > > > > like to know if we really have an issue with the size of our cache, or
> > > > > > one of those views isn't the right one to use.

> > > > > > Here are the queries being:

> > > > > > SELECT ROUND(((SUM(cur.value) + SUM(con.value) - SUM(phy.value)) /
> > > > > > (SUM(cur.value) + SUM(con.value))) * 100, 2) AS
> > > > > > CLUSTER_CACHE_HIT_RATIO
> > > > > > FROM v$sysstat cur, gv$sysstat con, gv$sysstat phy
> > > > > > WHERE cur.name = 'db block gets'
> > > > > > AND con.name = 'consistent gets'
> > > > > > AND phy.name = 'physical reads'

> > > > > > SELECT DECODE(NAME, 'DEFAULT', DECODE(block_size, 2048, 'CACHE_2K',
> > > > > > 4096, 'CACHE_4K', 8192, 'CACHE_8K', 16384, 'CACHE_16K', 'CACHE_32K'),
> > > > > > NAME) NAME ,  PHYSICAL_READS,  DB_BLOCK_GETS,  CONSISTENT_GETS,
> > > > > >     ( 1 - ((DECODE (PHYSICAL_READS, 0, 1, PHYSICAL_READS)) /
> > > > > > DECODE((DB_BLOCK_GETS + CONSISTENT_GETS),0, DECODE(PHYSICAL_READS, 0,
> > > > > > 1, PHYSICAL_READS) ,(DB_BLOCK_GETS + CONSISTENT_GETS)))) * 100 AS
> > > > > > BUFFER_RATIO
> > > > > > FROM V$BUFFER_POOL_STATISTICS

> > > > > > Any assistance in helping us make sense of this is greatly
> > > > > > appreciated.

> > > > > > Teresa Masino

> > > > > Which release of Oracle is this?

> > > > > David Fitzjarrell- Hide quoted text -

> > > > > - Show quoted text -

> > > > duh, sorry.  We're running 10g.  Specifically:

> > > > Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 on one
> > > > server and Oracle Database 10g Enterprise Edition Release 10.2.0.1.0
> > > > on another.

> > > > Teresa- Hide quoted text -

> > > > - Show quoted text -

> > > Does this negative output occur on both releases?  It appears to work
> > > fine on my 10.2.0.2 database.

> > > David Fitzjarrell- Hide quoted text -

> > > - Show quoted text -

> > Most of the time the queries return expected results for us too.  If I
> > run the queries in a loop that sleeps for 30 seconds or so and let it
> > go for a while, they eventually report different results.  It can take
> > 10 minutes to see a discrepancy, it can take over an hour.  But at
> > some point, they do report different values.  Which leads us to wonder
> > which one we should pay attention to.  One of them tells us things are
> > fine and the other says they aren't.  And then there's the wild part
> > where the BUFFER_POOL_STATISTICS view has negative values.  That part
> > alone makes me question the validity of those values, but I thought
> > I'd check here to see if anyone knows for sure.

> > Thanks
> > Teresa- Hide quoted text -

> > - Show quoted text -

> Metalink reports the view was buggy up until 9.2.0.2, however it may
> be a platform-specific issue.  On which O/S are you running Oracle?

> David Fitzjarrell- Hide quoted text -

> - Show quoted text -

> Because you wanted to hurt yourself and there weren't any brick in the
> office you could drop on your toes? <g>

> Hit ratio's are meaningless.

>Alone, yea, but they can sometimes be an indicator that an instance
>needs attention.

> > On Aug 8, 12:36 pm, Teresa Masino <teresa.mas...@peninsula.org> wrote:

> > > On Aug 8, 12:53 pm, "fitzjarr...@cox.net" <fitzjarr...@cox.net> wrote:

> > > > On Aug 8, 11:30 am, Teresa Masino <teresa.mas...@peninsula.org> wrote:

> > > > > On Aug 8, 12:22 pm, "fitzjarr...@cox.net" <fitzjarr...@cox.net> wrote:

> > > > > > On Aug 8, 10:57 am, Teresa Masino <teresa.mas...@peninsula.org> wrote:

> > > > > > > We have acquired a software package that sends alerts based on defined
> > > > > > > thresholds and/or events.  We are working on a simple alert like when
> > > > > > > the cache hit ratio falls below a given threshold.  The package came
> > > > > > > with a query that uses the V$BUFFER_POOL_STATISTICS view.  We have
> > > > > > > typically used a query based on the V$SYSSTAT view.  We left the query
> > > > > > > in place that came with the product, but it reports low cache hit
> > > > > > > ratios pretty frequently whereas putting another alert in place that
> > > > > > > uses V$SYSSTAT does not.

> > > > > > > We only have one pool -- DEFAULT.  So we would expect the values to be
> > > > > > > at least close, if not the same.  They are usually the same, but
> > > > > > > several times in the course of a day they are VERY different.

> > > > > > > In addition to be different enough to trigger the alert, the values in
> > > > > > > V$BUFFER_POOL_STATISTICS are sometimes a negative value.  What's up
> > > > > > > with that?

> > > > > > > Can anyone explain to me why V$BUFFER_POOL_STATISTICS sometimes has
> > > > > > > negative values or has very different values from V$SYSSTAT?  We'd
> > > > > > > like to know if we really have an issue with the size of our cache, or
> > > > > > > one of those views isn't the right one to use.

> > > > > > > Here are the queries being:

> > > > > > > SELECT ROUND(((SUM(cur.value) + SUM(con.value) - SUM(phy.value)) /
> > > > > > > (SUM(cur.value) + SUM(con.value))) * 100, 2) AS
> > > > > > > CLUSTER_CACHE_HIT_RATIO
> > > > > > > FROM v$sysstat cur, gv$sysstat con, gv$sysstat phy
> > > > > > > WHERE cur.name = 'db block gets'
> > > > > > > AND con.name = 'consistent gets'
> > > > > > > AND phy.name = 'physical reads'

> > > > > > > SELECT DECODE(NAME, 'DEFAULT', DECODE(block_size, 2048, 'CACHE_2K',
> > > > > > > 4096, 'CACHE_4K', 8192, 'CACHE_8K', 16384, 'CACHE_16K', 'CACHE_32K'),
> > > > > > > NAME) NAME ,  PHYSICAL_READS,  DB_BLOCK_GETS,  CONSISTENT_GETS,
> > > > > > >     ( 1 - ((DECODE (PHYSICAL_READS, 0, 1, PHYSICAL_READS)) /
> > > > > > > DECODE((DB_BLOCK_GETS + CONSISTENT_GETS),0, DECODE(PHYSICAL_READS, 0,
> > > > > > > 1, PHYSICAL_READS) ,(DB_BLOCK_GETS + CONSISTENT_GETS)))) * 100 AS
> > > > > > > BUFFER_RATIO
> > > > > > > FROM V$BUFFER_POOL_STATISTICS

> > > > > > > Any assistance in helping us make sense of this is greatly
> > > > > > > appreciated.

> > > > > > > Teresa Masino

> > > > > > Which release of Oracle is this?

> > > > > > David Fitzjarrell- Hide quoted text -

> > > > > > - Show quoted text -

> > > > > duh, sorry.  We're running 10g.  Specifically:

> > > > > Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 on one
> > > > > server and Oracle Database 10g Enterprise Edition Release 10.2.0.1.0
> > > > > on another.

> > > > > Teresa- Hide quoted text -

> > > > > - Show quoted text -

> > > > Does this negative output occur on both releases?  It appears to work
> > > > fine on my 10.2.0.2 database.

> > > > David Fitzjarrell- Hide quoted text -

> > > > - Show quoted text -

> > > Most of the time the queries return expected results for us too.  If I
> > > run the queries in a loop that sleeps for 30 seconds or so and let it
> > > go for a while, they eventually report different results.  It can take
> > > 10 minutes to see a discrepancy, it can take over an hour.  But at
> > > some point, they do report different values.  Which leads us to wonder
> > > which one we should pay attention to.  One of them tells us things are
> > > fine and the other says they aren't.  And then there's the wild part
> > > where the BUFFER_POOL_STATISTICS view has negative values.  That part
> > > alone makes me question the validity of those values, but I thought
> > > I'd check here to see if anyone knows for sure.

> > > Thanks
> > > Teresa- Hide quoted text -

> > > - Show quoted text -

> > Metalink reports the view was buggy up until 9.2.0.2, however it may
> > be a platform-specific issue.  On which O/S are you running Oracle?

> > David Fitzjarrell- Hide quoted text -

> > - Show quoted text -

> It's the server running 10.1.0.5.0  where we see the differences and
> that's on Linux.  I saw some old postings saying things like that too
> and wondered.  Afterall, we are counting on somebody somewhere writing
> code to populate that data.    FYI, we also opened a ticket with
> Oracle, so if I get an answer from them, I'll let you know.  But that
> case has been open for a couple of weeks now, so I'm not very
> optimistic.

> Thanks
> Teresa- Hide quoted text -

> - Show quoted text -

>> Alone, yea, but they can sometimes be an indicator that an instance
>> needs attention.
> Do you really think so? Yesterday I had a customer spouting flames
> because of a RAC database coming down to a crawl due to buffer busy
> waits in  conjunction with both instances updating the same table over
> and over again.
> Nothing to be seen from the BCHR.

> But then of course BCHR is a MIPS (Meaningless Indicator of the
> Performance of the System).
> Only good old Don Burleson makes people erroneously believe they can
> tune their database by throwing memory at the problem to crank up the
> BCHR.
> Savy professionals (a favorite phrase of Don) know better.

>>> Alone, yea, but they can sometimes be an indicator that an instance
>>> needs attention.
>> Do you really think so? Yesterday I had a customer spouting flames
>> because of a RAC database coming down to a crawl due to buffer busy
>> waits in  conjunction with both instances updating the same table over
>> and over again.
>> Nothing to be seen from the BCHR.

>> But then of course BCHR is a MIPS (Meaningless Indicator of the
>> Performance of the System).
>> Only good old Don Burleson makes people erroneously believe they can
>> tune their database by throwing memory at the problem to crank up the
>> BCHR.
>> Savy professionals (a favorite phrase of Don) know better.

> enough of you will recognise where I stand on ratios. Indeed I believe
> that I presented on the effectiveness or in fact otherwise of the BCHR
> on its own nearly 5 years ago.

> I have some sympathy withe Teresa's sentiment above though. Imagine a
> system that has had a truly horrible burleson concerned hopelessness
> ratio of 75% since 2002. Today the BCHR is 25% (or indeed 98%). I
> venture to suggest that it's a change worth determining the reasons for,
> either way. Ratios don't mean anything much, abrupt changes in them
> often do.

> >>> Alone, yea, but they can sometimes be an indicator that an instance
> >>> needs attention.
> >> Do you really think so? Yesterday I had a customer spouting flames
> >> because of a RAC database coming down to a crawl due to buffer busy
> >> waits in  conjunction with both instances updating the same table over
> >> and over again.
> >> Nothing to be seen from the BCHR.

> >> But then of course BCHR is a MIPS (Meaningless Indicator of the
> >> Performance of the System).
> >> Only good old Don Burleson makes people erroneously believe they can
> >> tune their database by throwing memory at the problem to crank up the
> >> BCHR.
> >> Savy professionals (a favorite phrase of Don) know better.

> > enough of you will recognise where I stand on ratios. Indeed I believe
> > that I presented on the effectiveness or in fact otherwise of the BCHR
> > on its own nearly 5 years ago.

> > I have some sympathy withe Teresa's sentiment above though. Imagine a
> > system that has had a truly horrible burleson concerned hopelessness
> > ratio of 75% since 2002. Today the BCHR is 25% (or indeed 98%). I
> > venture to suggest that it's a change worth determining the reasons for,
> > either way. Ratios don't mean anything much, abrupt changes in them
> > often do.

> On the other hand monitoring things that matter would save you the
> trouble of chasing after smoke in a house of mirrors.

> There are real things that can be monitored. And if Theresa has the
> license to use AWR as it seems she'd be far better served looking at
> things that matter.
> --
> Daniel A. Morgan
> University of Washington
> damor...@x.washington.edu (replace x with u to respond)
> Puget Sound Oracle Users Groupwww.psoug.org- Hide quoted text -

> - Show quoted text -

>> There are real things that can be monitored. And if Theresa has the
>> license to use AWR as it seems she'd be far better served looking at
>> things that matter.
>> --
>> Daniel A. Morgan
>> University of Washington
>> damor...@x.washington.edu (replace x with u to respond)
>> Puget Sound Oracle Users Groupwww.psoug.org- Hide quoted text -

>> - Show quoted text -

> Indeed. And since EM will do alerts based on user defined metrics,
> it's possible the whole thing is moot.

> Niall

> Nothing prevents you from driving your car into a telephone pole.
> Smart people stay between the lines.

> But then of course BCHR is a MIPS (Meaningless Indicator of the
> Performance of the System).
> Savy professionals (a favorite phrase of Don) know better.

>> But then of course BCHR is a MIPS (Meaningless Indicator of the
>> Performance of the System).
>> Savy professionals (a favorite phrase of Don) know better.

>That is a common mistake of "savy professionals" - overlooking the basics
>and thinking they know better.

>>> But then of course BCHR is a MIPS (Meaningless Indicator of the
>>> Performance of the System).
>>> Savy professionals (a favorite phrase of Don) know better.

>>That is a common mistake of "savy professionals" - overlooking the basics
>>and thinking they know better.

> Assuming you are such a 'savy professional' 'Mr' Jones, why didn't you
> notice throwing memory at the problem doesn't help?

> What did we discuss? Was I wrong? I have no interest in becoming what you
> call a "savy professional", because that really amount to exactly, an
> arrogant idiot.

> Disagree all you wish Connor proved this clearly and decisively many
> years ago. And it should come as no surprise that Connor is one of the
> most capable, and respected, Oracle technologists on the planet for a
> reason.

>> What did we discuss? Was I wrong? I have no interest in becoming what you
>> call a "savy professional", because that really amount to exactly, an
>> arrogant idiot.

> Beats heck out of being one an not being a savvy professional. <g>

> If you can produce it then you don't have a case and should buy lots
> of books from Rampant.

>> Disagree all you wish Connor proved this clearly and decisively many
>> years ago. And it should come as no surprise that Connor is one of the
>> most capable, and respected, Oracle technologists on the planet for a
>> reason.

>I do not know who this Connor guy is. Did he really say BHCR is meaningless?
>I would love to see his proof.

>I think the burden is on you to prove BHCR is meaningless. Maybe the issue
>here is reading too many books and articles.

> I do not know who this Connor guy is. Did he really say BHCR is meaningless?
> I would love to see his proof.

>>>> I clearly disagree with the statement that BHCR is meaningless. This
>>>> has
>>>> been discussed several times before. I won't waste any more energy.

>>> Disagree all you wish Connor proved this clearly and decisively many
>>> years ago. And it should come as no surprise that Connor is one of the
>>> most capable, and respected, Oracle technologists on the planet for a
>>> reason.

>>I do not know who this Connor guy is. Did he really say BHCR is
>>meaningless?
>>I would love to see his proof.

> This 'Connor guy' (a label intended as disrespectful) is Connor Mc
> Donald, a member of the OakTable Network. His site is
> http://www.oracledba.co.uk. The proof is on this site including a
> demonstration.

>>I think the burden is on you to prove BHCR is meaningless. Maybe the issue
>>here is reading too many books and articles.

> I think the burden is on you to prove it is meaningfull and to
> contradict the figures provided by Connor McDonald.
> I think the issue here is you have read to many fairy tales composed
> by Donald K Burleson, Mike R Ault, and other Rampant authours.
> May be you get paid by Burleson to bash 'savy professionals'.
> But most likely you are someone who like Burleson's 'savy
> proefessionals' just doesn't know what he is talking about.
> I would love to see your apologize here once you have read the article
> on www.oracledba.co.uk, but I'm not holding my breath: you have
> established yourself here as an arrogant incompetent troll.

>> I do not know who this Connor guy is. Did he really say BHCR is
>> meaningless? I would love to see his proof.

> This Connor guy?

> You mean THIS Connor guy don'you?
> http://www.oracledba.co.uk/index.html
> http://www.oaktable.net/pageServer.jsp?body=members.jsp

> Next are we going to see "This Mogens guy" or "Who the heck is this
> Kyte guy? BHCR is meaningless. Totally meaningless. The only reason
> anyone pays any attention to it is that it has been promoted ad nauseum
> by the self-anointed to the clueless.