Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Very high buffer gets
How did the original poster determine that the tables have only 2 blocks or less each? A less than 100 percent statistics computation, perchance?
Perhaps
select count(non-indexed-column) from aq$_<tab>
(without any joins or other complications) would show more blocks below the high water mark than you think you have.
Regards,
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Alex Gorbachev
Sent: Monday, February 13, 2006 4:07 PM
To: nnahata_at_deloitte.com
Cc: oracle-l_at_freelists.org
Subject: Re: Very high buffer gets
If I recall correctly this is a bug in AQ handling. I think you should be able to find it easilly on Metalink. I think Oracle attributes LIO that is caused by QMN during queue maintenance (delayed purging) instead of attributing those LIOs to the statements causing it. What is your version?
2006/2/13, Nahata, Naveen (US - Glen Mills) <nnahata_at_deloitte.com>: Hi All,
After tracing the QMON process which was doing lots of buffer gets, I found this culprit. None of the three tables involved in the query have more than 2 blocks. I know the nested loop is iterating over the blocks but that should still not account for more than 200 blocks / execution. Why do I see such high values for buffer gets?
select t.schema , t.name, t.flags, q.name
from
system.aq$_queue_tables t, sys.aq$_queue_table_affinities aft,
system.aq$_queues q where aft.table_objno = t.objno and
aft.owner_instance =
:1 and q.table_objno = t.objno and q.usage = 0 and bitand(t.flags, 4+16+32+64+128+256) = 0 and NOT ( t.namein
call count cpu elapsed disk query current rows
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Rows Row Source Operation
This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message.
Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1]
--
http://www.freelists.org/webpage/oracle-l
--
Best regards,
Alex Gorbachev
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Feb 14 2006 - 07:09:10 CST
![]() |
![]() |