Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Extremely Slow Query
Jonathan Lewis wrote:
> The problem is generic, the specific query
> isn't the point. RAC is a massive improvement
> on OPS because block transfer is by wire not
> disc - but it still takes a serious amount of
> time to fling blocks from node to node, especially
> if the blocks have been subject to very recent update
> at the remote nodes.
Thanks, Jonathan! Sorry for misunderstanding. Got it. I thought you are talking about this particular query -- "looks like you've hit the big problem with RAC" -- sounded like it was not before however it's here now. One of the main concept of RAC/OPS is understanding application(s) workload and assign/partition it to/among different nodes. So, here we have a good example of the (unavoidable) functional clash.
Raj, can you try this one:
SELECT /*+ LEADING(dba_types.t)
INDEX(dba_types.o, i_obj3) INDEX(dba_types.so, i_obj3) */ *
In this case it's better to scan indexes.
> I like both your explanations for the size, and > the unusual number of obj$ blocks that needed > CR serving.
;)
-- Vladimir Begun The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Vladimir Begun INET: Vladimir.Begun_at_oracle.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Fri Jan 03 2003 - 13:59:57 CST
![]() |
![]() |