The point of parallel_force_local is that the query coordinator and all its PX
slave processes operate on the same node so that any PQ messages
areinter-process on the node and no PQ messages (for the query) have to travel
across the interconnect.
If you think about a parallel hash join using hash/hash distribution, for
example; this will use two slave sets the first slave set scans the first
table and distributes the interesting rows to the second slave set, then the
first slave set scans the second table and distributes it's rows in the same
way to the second slave set. If you don't set parallel_force_local to true
then you could (in theory, though Oracle always makes some attempt to avoid it)
end up with the first slave set on one node and the second slave set on another
node, and all the data flying across the interconnect before any joining gets
done - them maybe the entire result set could go flying back across the
interconnect because the Query coordinator is on a third node. A single bad
parallel query could flood the interconnect and basically kill the system - to
the extent that nodes could get ejected because they couldn't get their
heartbeat messages through fast enough.
Regards
Jonathan Lewis
________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on behalf
of Cee Pee <carlospena999@xxxxxxxxx>
Sent: 24 February 2020 20:38
To: Oracle-L Freelists
Subject: parallel_force_local and parallel query
Hopefully not a dumb question, By setting parallel force local to TRUE all the
queries for a particular table and other objects happen in the local instance
only. What happens if a different query is issued from a different node for the
same table or object. Does the data get transferred over the interconnect, if
data is still cached in the first node. Assume SELECTs only in both nodes.
Thanks
CP
--
//www.freelists.org/webpage/oracle-l