RE: Very high buffer gets

  • From: "Nahata, Naveen (US - Glen Mills)" <nnahata@xxxxxxxxxxxx>
  • To: "fairlie rego" <fairlie_r@xxxxxxxxx>
  • Date: Tue, 14 Feb 2006 08:34:49 -0500

Yes, I have already seen this note. Ultimately, I will go ahead with
what is recommended in the metalink note, but I fail to understand why
too many blocks are being read and hence posted the query in this forum.
Probably its because of my lack of experience with AQ/IOTs I cannot come
up with a reasonable explanation.
 
Naveen

________________________________

From: fairlie rego [mailto:fairlie_r@xxxxxxxxx] 
Sent: Monday, February 13, 2006 7:22 PM
To: Nahata, Naveen (US - Glen Mills)
Cc: oracle-l@xxxxxxxxxxxxx; Alex Gorbachev
Subject: RE: Very high buffer gets


Hi Naveen
 
Isn't this the same issue as described in Metalink note 310923.1
<https://www.metalink.oracle.com/metalink/plsql/f?p=130:14:4200270662525
378742::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_bl
ack_frame,p14_font:NOT,310923.1,1,1,1,helvetica> 
 
Regards,
Fairlie

"Nahata, Naveen (US - Glen Mills)" <nnahata@xxxxxxxxxxxx> wrote:

        9.2.0.6 (on HP-UX)

________________________________

        From: Alex Gorbachev [mailto:gorbyx@xxxxxxxxx] 
        Sent: Monday, February 13, 2006 4:07 PM
        To: Nahata, Naveen (US - Glen Mills)
        Cc: oracle-l@xxxxxxxxxxxxx
        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@xxxxxxxxxxxx>: 

                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 <http://t.name/> , t.flags,
q.name <http://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.name <http://t.name/> 
                in
                ('DEF$_AQCALL' , 'DEF$_AQERROR') and t.schema =
'SYSTEM')for update of 
                t.name <http://t.name/> , aft.table_objno skip locked
                
                
                call     count       cpu    elapsed       disk
query    current
                rows
                ------- ------  -------- ---------- ----------
---------- ---------- 
                ----------
                Parse       84      0.00       0.03          0
0          0
                0
                Execute     84      0.03       0.03          0
0          0
                0
                Fetch       84     11.87      47.87        266
536288      45281 
                4627
                ------- ------  -------- ---------- ----------
---------- ----------
                ----------
                total      252     11.90      47.94        266
536288      45281
                4627
                
                Misses in library cache during parse: 1 
                Optimizer goal: CHOOSE
                Parsing user id: SYS   (recursive depth: 1)
                
                Rows     Row Source Operation
                -------
---------------------------------------------------
                    60  FOR UPDATE
                    62   HASH JOIN
                    59    NESTED LOOPS
                    59     TABLE ACCESS FULL AQ$_QUEUE_TABLES
                    59     TABLE ACCESS BY INDEX ROWID
AQ$_QUEUE_TABLE_AFFINITIES
                    59      INDEX UNIQUE SCAN AQ$_QTABLE_AFFINITIES_PK
(object id 2400)
                    64    TABLE ACCESS FULL AQ$_QUEUES 
                
                Naveen
                
                
                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]
                --
                //www.freelists.org/webpage/oracle-l 
                
                
                




        -- 
        Best regards,
        Alex Gorbachev 




Fairlie Rego
Senior Oracle Consultant
Optus Telecommunications
www.optus.com.au <http://www.optus.com.au/> 
Mobile: +61 4 02 792 405
Home: +61 2 8920 0273

 
When I read about the evils of drinking, I gave up reading.

________________________________


What are the most popular cars? Find out at Yahoo! Autos
<http://us.rd.yahoo.com/evt=38382/_ylc=X3oDMTEzNWFva2Y2BF9TAzk3MTA3MDc2B
HNlYwNtYWlsdGFncwRzbGsDMmF1dG9z/*http://autos.yahoo.com/newcars/popular/
thisweek.html>  

Other related posts: