RE: Strange 'gc cr multi block request' during dictionary queries

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Tue, 16 Oct 2012 15:37:55 -0400
Message-ID: <007501cdabd5$bdd92200$398b6600$_at_rsiz.com>



Also, you might examine what cluster, table, or index that block is part of, as well as the other repeated blocks. Where it fits in the composition of dba_segments might be illuminating.

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of David Fitzjarrell
Sent: Tuesday, October 16, 2012 2:54 PM
To: grzegorzof_at_interia.pl; oracle-l_at_freelists.org Subject: Re: Strange 'gc cr multi block request' during dictionary queries

The output from tkprof can include the plan; have you checked what the optimizer is doing with that query?  If you will post the current execution plan we'll get a better feel for what Oracle 10.2.0.3 is doing with your query.  Also I've found that the stats on user tables can be off in 10.2.0.x depending on the sample size and whether or not you have tables with a single-valued, non-null column.  (that last condition can create meaningless histograms that cause optimizer calculations to go awry).

David Fitzjarrell



From: GG <grzegorzof_at_interia.pl>
To: oracle-l_at_freelists.org
Sent: Tuesday, October 16, 2012 12:42 PM Subject: Strange 'gc cr multi block request' during dictionary queries

Hi,
  here goes the case :
I've got 4 node 10.2.0.3 RAC , DDL intensive (CTAS, DROP/TRUNCATE) database .
It's like 20TB of data, milions of partitions and objects . When I'm doing queries agains dictionary tables like select * from dba_segments where owner = 'A' and segment_name = 'B' I'm observing  'gc cr multi block request' , as far as I know its kind of scattered reads but using interconnect to gather data . Whats bothering me is profile of that 'gc cr multi block requests' , here goes some lines from 10046 trace:

WAIT #6: nam='gc cr multi block request' ela= 861 file#=1 block#$34788
class#=1 obj#8 tim18733123446958
WAIT #6: nam='gc cr multi block request' ela= 69 file#=1 block#$34788
class#=1 obj#8 tim18733123447083
WAIT #6: nam='gc cr multi block request' ela= 60 file#=1 block#$34788
class#=1 obj#8 tim18733123447220
WAIT #6: nam='gc cr multi block request' ela= 99 file#=1 block#$34788
class#=1 obj#8 tim18733123447347
WAIT #6: nam='gc cr multi block request' ela= 111 file#=1 block#$34788
class#=1 obj#8 tim18733123447482
WAIT #6: nam='gc cr multi block request' ela= 193 file#=1 block#$34788
class#=1 obj#8 tim18733123447704
WAIT #6: nam='gc cr multi block request' ela= 84 file#=1 block#$34788
class#=1 obj#8 tim18733123447820
WAIT #6: nam='gc cr multi block request' ela= 81 file#=1 block#$34788
class#=1 obj#8 tim18733123447931
WAIT #6: nam='gc cr multi block request' ela= 108 file#=1 block#$34788
class#=1 obj#8 tim18733123448065
WAIT #6: nam='gc cr multi block request' ela= 111 file#=1 block#$34788
class#=1 obj#8 tim18733123448199
WAIT #6: nam='gc cr multi block request' ela= 105 file#=1 block#$34788
class#=1 obj#8 tim18733123448328
WAIT #6: nam='gc cr multi block request' ela= 100 file#=1 block#$34788
class#=1 obj#8 tim18733123448458
WAIT #6: nam='gc cr multi block request' ela= 151 file#=1 block#$34788
class#=1 obj#8 tim18733123448639
WAIT #6: nam='gc cr multi block request' ela= 84 file#=1 block#$34788
class#=1 obj#8 tim18733123448750
WAIT #6: nam='gc cr multi block request' ela= 90 file#=1 block#$34788
class#=1 obj#8 tim18733123448867
WAIT #6: nam='gc cr multi block request' ela= 98 file#=1 block#$34788
class#=1 obj#8 tim18733123448994


and that pattern repeats with different block#

Question is why Oracle is requesting the same block , over and over (16 times) , I thinks 16 comes from MBRC which is 16 and I've got 16kb blocksize .
Looks like a bug :) isnt it ?
Generally all queries agains dictionary tables are slow (minutes) , I'm not observing any lost block issues so its probably bad plans issue . Any comments ?
Regards
GregG

--

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

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

--

http://www.freelists.org/webpage/oracle-l Received on Tue Oct 16 2012 - 21:37:55 CEST

Original text of this message