: performance issue on select count(*)
Date: Mon, 27 Oct 2003 10:34:59 -0800
Linda,
I am guessing that since your table is partitioned on an unspecified date
column, that the index on TID is either LOCAL or non-partitioned (i.e.
GLOBAL).
If it is LOCAL (you would have had to specify the keyword
The symptom suggests caching is a big factor here - most likely
block-buffers.
Contrary to ?current? popular beliefs, BCHR is still a very relevant
performance indicator - either being very high, or being too low - both of
which gives a good indication of something that needs to be looked at.
So, what exactly is indicated by a high or low hit rate? What, exactly, is high
and what do you consider low?
What HR are you talking about?
This would be the infamous BCHR:
select 'bc_hit_ratio' ratio,( sum(decode(name, 'consistent gets',value,0))
+ sum(decode(name,'db block gets', value,0))
: Re: performance issue on select count(*)
So, what exactly is indicated by a high or low hit rate? What, exactly, is high
and what do you consider low?
What HR are you talking about?
This would be the infamous BCHR:
select 'bc_hit_ratio' ratio,( sum(decode(name, 'consistent gets',value,0
To:Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:Re: performance issue on select count(*)
So, what exactly is indicated by a high or low hit rate? What, exactly, is high
and what do you consider low?
What HR are you talking about?
This would
have to
interpret it.
that is about it. Anyone who uses it for anymore than that is wrong.
From: Mladen Gogala [EMAIL PROTECTED]
Date: 2003/10/28 Tue PM 12:09:34 EST
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: Re: performance issue on select count(*)
So, what
Linda,
I guess that the key word is 'partition'. This type of query should not require to
access the table if (hopefully) tid is indexed. If the index on tid is also
partitioned, all index partitions have to be searched. My feeling is that in such a
case what should run faster is some
PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: performance issue on select count(*)
Date: Mon, 27 Oct 2003 05:49:24 -0800
Linda,
I guess that the key word is 'partition'. This type of query should not
require to access the table
Linda,
I am guessing that since your table is partitioned on an unspecified date
column, that the index on TID is either LOCAL or non-partitioned (i.e.
GLOBAL).
If it is LOCAL (you would have had to specify the keyword, as it is not the
default), then you will be performing indexed RANGE scans
