A possible side effect of this that I haven’t yet tested is that SQL Baselines involving remote joins may fail to stabilise the execution plan, because basically an SQL Baseline is a set of hints. I’ve tried copying the outline (dbms_xplan.display(null,null,’outline’)) hints back into a fully remote SQL statement – like your select from a view – and found that even the “guaranteed” full set won’t work.

For instance if we look at below example..

explain plan for
INSERT  INTO TESTING tt
                  (ACP_APPL_ID
                   ,ACP_APPL_RECEIVED_DATE
                   ,ACP_APRV_AMT
                                     )
         SELECT /*+ USE_HASH(st.acct st.ext) */
                    ACP_APPL_ID
                   ,ACP_APPL_RECEIVED_DATE
                   ,ACP_APRV_AMT
                    FROM origmgr.acaps_acct_auto_d@infoprod st
          WHERE acp_appl_received_date BETWEEN to_date('13jun2012','ddmonyyyy') and to_date('25sep2012','ddmonyyyy')
               and ACP_BRANCH_CODE  is not null;

--------------------------------------------------------------------------------------------------------------
| Id  | Operation                | Name              | Rows  | Bytes | Cost (%CPU)| Time     | Inst   |IN-OUT|
--------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT         |                   |  1015 | 28420 | 25190   (1)| 00:05:03 |        |      |
|   1 |  LOAD TABLE CONVENTIONAL | TESTING           |       |       |            |          |        |      |
|   2 |   REMOTE                 | ACAPS_ACCT_AUTO_D |  1015 | 28420 | 25190   (1)| 00:05:03 | INFOP~ | R->S |
--------------------------------------------------------------------------------------------------------------

Remote SQL Information (identified by operation id):
----------------------------------------------------

   2 - SELECT /*+ OPAQUE_TRANSFORM */ "ACP_APPL_ID","ACP_APPL_RECEIVED_DATE","ACP_APRV_AMT","ACP_BRANC
       H_CODE" FROM "ORIGMGR"."ACAPS_ACCT_AUTO_D" "ST" WHERE "ACP_BRANCH_CODE" IS NOT NULL AND
       "ACP_APPL_RECEIVED_DATE">=TO_DATE(' 2012-06-13 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
       "ACP_APPL_RECEIVED_DATE"<=TO_DATE(' 2012-09-25 00:00:00', 'syyyy-mm-dd hh24:mi:ss') (accessing remote)

we can see it completely ignored hash hint. I am accesing remote database view that's why i have specified globally.

I am wondering is there any way to change this pattern.

I do have a strategy for translating ANSI to Oracle (since I know that ANSI sometimes is the problem) – but it’s an option I would only adopt if I were fairly sure that ANSI was the problem.

I actually made two mistakes in my analysis in this case – the first one was that I didn’t consider the fact that it might be the SYS account that was causing the problem … and I should have thought of that before trying the rewrite. The second was rewriting the query correctly instead of writing a simplified variant of the ANSI query to see if it still failed, rather than spending time doing an exact rewrite into Oracle SQL.

Rewriting queries is something I’m not keen on (even Oracle to Oracle), because it can be very hard to prove that the rewrite is logically equivalent to the original.