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)
*/
*
FROM dba_types
/
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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
