Recently appeared on Mos – “Bug 18219084 : DIFFERENT EXECUTION PLAN ACROSS RAC INSTANCES”
Now, I’m not going to claim that the following applies to this particular case – but it’s perfectly reasonable to expect to see different plans for the same query on RAC, and it’s perfectly possible for the two different plans to have amazingly different performance characteristics; and in this particular case I can see an obvious reason why the two nodes could have different plans.
Here’s the query reported in the bug:
SELECT /*+ INDEX(C IDX3_GOD_USE_LOT)*/ PATTERN_ID, STB_TIME FROM mfgdev.MTR_AUTO_GOD_AGENT_BT C WHERE 1 = 1 AND EXISTS (SELECT /*+ INDEX(B IDX_MTR_STB_LOT_EQP)*/ 1 FROM MFGDEV.MTR_STB_BTH B WHERE B.PATTERN_ID = C.PATTERN_ID AND B.STB_TIME = C.STB_TIME AND B.ACTUAL_START_TIME < SYSDATE AND EXISTS (SELECT /*+ INDEX(D CW_LOTID)*/ 1 FROM F14DM.DM_CW_WIP_BT D WHERE D.LOT_ID = B.LOT_ID AND D.SS = 'BNKI'));
See the reference to “sysdate”. I can show you a system where you had a 15 minute window each day (until the problem was addressed) to optimize a particular query if you wanted a good execution plan; if you optimized it any other time of day you got a bad plan – and the problem was sysdate: it acts like a peeked bind variable.
Maybe, on this system, if you optimize the query at 1:00 am you get one plan, and at 2:00 am you get another – and if those two optimizations occur on different nodes you’ve just met the conditions of this bug report.
Here’s another thought to go with this query: apparently it’s caused enough problems in the past that someone’s written a couple of hints into the code. With three tables and two correlated subqueries in the code a total of three index() hints is not enough. If you’re going to hard-code hints into a query then take a look at the outline it generates when it does the right thing, and that will tell you about the 15 or so hints you’ve missed out. (Better still, consider generating an SQL Baseline from the hinted code and attaching it to the unhinted code.)