Hint for self-join connect by

From: Herring Dave - dherri <Dave.Herring_at_acxiom.com>
Date: Mon, 30 Apr 2007 15:04:29 -0500
Message-ID: <7ED53A68952D3B4C9540B4EFA5C76E360326B783@CWYMSX04.Corp.Acxiom.net>

Folks,

I've got a rather aggravating query which performs "well" (45 min.) under 9.2.0.6 CPUApr2006 but under 9.2.0.6 CPUOct2006 it choses a "poor" path (around 4 1/2 hrs consistently). I'm working on the patch issue with Oracle, but since I now know what the optimal path should be, I thought I'd hint the CBO into the right direction. But so far nothing is working. I know a hint is just that, but still it seems with proper statistics and hints you can pretty much manipulate most plans.

Here's the query:
SELECT surrogate_id

, root_surrogate_id
FROM (SELECT surrogate_id

             , root_surrogate_id
             , ROW_NUMBER () OVER (PARTITION BY surrogate_id ORDER BY lev DESC) AS rn
          FROM (SELECT SUBSTR(tree, 1, INSTR(tree, '|') - 1) AS surrogate_id
                     , SUBSTR(SUBSTR(tree, INSTR(tree, '|', -1)), 2) AS root_surrogate_id
                     , lev
                  FROM (SELECT SUBSTR(sys_connect_by_path(surrogate_id, '|'), 2) tree
                             , LEVEL AS lev
                          FROM dch_work_surr_mgmt_ordered
                         START WITH acct_id = '&ACCT_MERGE'
                       CONNECT BY PRIOR forward_surrogate_id = surrogate_id
                       )
                 WHERE INSTR(tree, '|') > 0
               )
       )

WHERE rn = 1;

The "poor" plan is as follows:

|Id|Operation                    | Name                 | Rows  | Bytes |TempSpc| Cost  |  TQ    |IN-OUT| PQ Distrib |


-----------------------------------------------------------------------------------------------------------------------

| 0|SELECT STATEMENT             |                      |    70M|   264G|       |   948K|        |      |            |
|*1| VIEW                        |                      |    70M|   264G|       |       |        |      |            |
|*2|  WINDOW SORT PUSHED RANK    |                      |    70M|   132G|   270G|   948K|        |      |            |
|*3|   VIEW                      |                      |    70M|   132G|       |       |        |      |            |
|*4|    CONNECT BY WITH FILTERING|                      |       |       |       |       |        |      |            |
|*5|     FILTER                  |                      |       |       |       |       |        |      |            |
| 6|      TABLE ACCESS FULL      |DCH_WORK_SURR_MGMT_ONE|    70M|  1553M|       |  1787 | 12,00  | P->S | QC (RAND)  |
| 7|     HASH JOIN               |                      |       |       |       |       |        |      |            |
| 8|      CONNECT BY PUMP        |                      |       |       |       |       |        |      |            |
| 9|      TABLE ACCESS FULL      |DCH_WORK_SURR_MGMT_ONE|    70M|  1553M|       |  1787 |        |      |            |
|10|     TABLE ACCESS FULL       |DCH_WORK_SURR_MGMT_ONE|    70M|  1553M|       |  1787 |        |      |            |


-----------------------------------------------------------------------------------------------------------------------

The "good" plan is as follows:

|Id|Operation                       | Name                 |Rows  |Bytes |TempSpc| Cost  |  TQ    |IN-OUT| PQ Distrib |


-----------------------------------------------------------------------------------------------------------------------

| 0|SELECT STATEMENT                |                      |   70M|  264G|       |  1045K|        |      |            |
|*1| VIEW                           |                      |   70M|  264G|       |  1045K|        |      |            |
|*2|  WINDOW SORT PUSHED RANK       |                      |   70M|  132G|   270G|  1045K|        |      |            |
|*3|   VIEW                         |                      |   70M|  132G|       |   812 |        |      |            |
|*4|    CONNECT BY WITH FILTERING   |                      |      |      |       |       |        |      |            |
| 5|     NESTED LOOPS               |                      |      |      |       |       |        |      |            |
|*6|      TABLE ACCESS FULL         |DCH_WORK_SURR_MGMT_ONE|    1 |   11 |       |   812 | 13,00  | P->S | QC (RAND)  |
| 7|      TABLE ACCESS BY USER ROWID|DCH_WORK_SURR_MGMT_ONE|      |      |       |       |        |      |            |
| 8|     HASH JOIN                  |                      |      |      |       |       |        |      |            |
| 9|      CONNECT BY PUMP           |                      |      |      |       |       |        |      |            |
|10|      TABLE ACCESS FULL         |DCH_WORK_SURR_MGMT_ONE|   70M| 1418M|       |   812 |        |      |            |


-----------------------------------------------------------------------------------------------------------------------

The table has 70,000,000 rows and has stats gathered at the same % (5) for both. I ran the query with 10053 event and found no difference, except at the end when one path was chosen over another.

I've tried various hints, but either I'm messing up the syntax due to the self join or I just am not using the right combination.

Anyone have any good ideas? BTW, as listed above, this is 9.2.0.6 on Tru64 5.1b.

Thanks.

Dave

David C. Herring, DBA | A c x i o m Delivery Center Organization 630-944-4762 office | 630-430-5988 wireless | 630-944-4989 fax

The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged.

If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system.

Thank You.

--
http://www.freelists.org/webpage/oracle-l

Received on Mon Apr 30 2007 - 15:04:29 CDT