Subquery Factoring - cardinality estimate good but bad sql response times

This is Exadata 11.2.0.4.0 database, all tables have statistics of up to date. Cardinality estimation is good compared to the actual cardinality. It is a way to tune this sql to reduce its response time.

Sorry for the long sql and the execution plan.

WITH SUBWITH0 AS
  (SELECT D1.c1 AS c1
  FROM (
    (SELECT D1.c1 AS c1
    FROM
      (SELECT DISTINCT T7171.CH_ID_SYM AS c1
      FROM DW.TM_R_REP T7171
      WHERE ( T7171.CHILD_REP_ID = 939 )
      ) D1
    UNION
    SELECT D1.c1 AS c1
    FROM
      (SELECT DISTINCT T7167.MEMBER_KEY_SYM AS c1
      FROM DW.PC_T_REP T7167
      WHERE ( T7167.ANCESTOR_KEY = 939 )
      ) D1
    ) ) D1
  ),
  SUBWITH1 AS
  (SELECT D1.c1 AS c1
  FROM (
    (SELECT D1.c1 AS c1
    FROM
      (SELECT DISTINCT T7171.CH_ID_SYM AS c1
      FROM DW.TM_R_REP T7171
      WHERE ( T7171.CHILD_REP_ID = 939 )
      ) D1
    UNION
    SELECT D1.c1 AS c1
    FROM
      (SELECT DISTINCT T7167.MEMBER_KEY_SYM AS c1
      FROM DW.PC_T_REP T7167
      WHERE ( T7167.ANCESTOR_KEY = 939 )
      ) D1
    ) ) D1
  ),
  SUBWITH2 AS
  (SELECT DISTINCT T7171.CH_ID_SYM AS c1
  FROM ( DW.PC_T_REP T7167
  LEFT OUTER JOIN DW.TM_R_REP T7171
  ON T7167.ANCESTOR_KEY    = T7171.CHILD_REP_ID
  AND T7167.SALESYEARMONTH = T7171.SALES_YEAR_MONTH)
  LEFT OUTER JOIN DW.TM_REP T6715
  ON T7171.CHILD_REP_ID_N = T6715.REP_ID
  WHERE (
    CASE
      WHEN T7171.CHILD_REP_ID_N LIKE '9999%'
      THEN concat(concat('UNASSIGNED', lpad(' ', 2)), CAST(T7167.TERRITORY_ID AS VARCHAR ( 20 ) ))
      ELSE concat(concat(concat(concat(T6715.FIRST_NAME, lpad(' ', 2)), T6715.MIDDLE_NAME), lpad(' ', 2)), T6715.LAST_NAME)
    END = 'JOES     CRAMER'
  AND T7171.SALES_YEAR_MONTH BETWEEN '201505' AND '201505'
  AND T7171.CH_ID_SYM IN
    (SELECT DISTINCT D1.c1 AS c1 FROM SUBWITH0 D1
    ) )
  ),
  SUBWITH3 AS
  (SELECT MEMBER_KEY_SYM AS c1
  FROM DW.PC_T_REP T7167
  WHERE ( IS_LEAF = 1 )
  ),
  SAWITH0 AS
  (SELECT DISTINCT
    CASE
      WHEN T7171.CHILD_REP_ID_N LIKE '9999%'
      THEN concat(concat('UNASSIGNED', lpad(' ', 2)), CAST(T7167.TERRITORY_ID AS VARCHAR ( 20 ) ))
      ELSE concat(concat(concat(concat(T6715.FIRST_NAME, lpad(' ', 2)), T6715.MIDDLE_NAME), lpad(' ', 2)), T6715.LAST_NAME)
    END                      AS c1,
    T6715.REP_NUM          AS c2,
    T7171.SALES_YEAR_MONTH AS c3,
    T7315.MONTH_NUMERIC    AS c4,
    CASE
      WHEN T7171.CH_ID_SYM IN
        (SELECT D1.c1 AS c1
        FROM SUBWITH3 D1
        )
      THEN 1
      ELSE 0
    END                                              AS c5,
    CAST(T7171.PARENT_REP_ID AS CHARACTER ( 30 ) ) AS c6,
    T7171.CH_ID_SYM                         AS c7,
    T7171.PARENT_REP_ID_SYM                        AS c8
  FROM DW.TIM_MON T7315
    ,
    ( ( DW.PC_T_REP T7167
  LEFT OUTER JOIN (
    (SELECT TO_NUMBER(TO_CHAR(L_OPP.CloseDate,'YYYYMM')) AS Sales_Year_Month,
      Tm_Rep.Rep_Id                                              AS Rep_Id,
      L_OPP.Account_Name__C                              AS Account_Name__C,
      L_OPP.Closedate                                    AS Closedate,
      L_OPP.Forecastcategory                             AS Forecastcategory,
      L_OPP.Forecastcategoryname                         AS Forecastcategoryname,
      L_User.NAME                                                AS Opp_Owner_S_Sales_Org__C,
      L_OPP.Opportunity_Id__C                            AS Opportunity_Id__C,
      L_OPP.Renewal_Date__C                              AS Renewal_Date__C,
      L_OPP.Total_Incremental__C                         AS Total_Incremental__C,
      L_OPP.Offer_Code__C                                AS Offer_Code__C,
      L_OPP.ID                                           AS Opportunity_ID,
      L_OPP.TERRITORYID                                  AS TERRITORYID,
      L_OPP.ACCOUNTID                                    AS ACCOUNTID,
      L_OPP.OWNERID                                      AS OWNERID,
      L_OPP.TOTAL_RENEWAL__C                             AS TOTAL_RENEWAL__C,
      L_OPP.NAME                                         AS NAME,
      L_OPP.STAGENAME                                    AS STAGE_NAME,
      L_OPP.STAGE_DESCRIPTION__C                         AS STAGE_DESCRIPTION,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategory                = 'Closed'
        AND( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL )
        THEN L_OPP.Total_Incremental__C
      END , 0) AS Closed_Oppurtunity,
      CASE
        WHEN L_OPP.Forecastcategory                 = 'Closed'
        AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL )
        THEN 'Closed_Oppurtunity_Drill'
      END AS Closed_Oppurtunity_Drill,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategoryname            IN ('Pipeline', 'Potential', 'Commit')
        AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL )
        THEN L_OPP.Total_Incremental__C
      END , 0) AS OPEN_Oppurtunity,
      CASE
        WHEN L_OPP.Forecastcategoryname            IN ('Pipeline', 'Potential', 'Commit')
        AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL )
        THEN 'OPEN_Oppurtunity_Drill'
      END AS OPEN_Oppurtunity_Drill,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategory              = 'Closed'
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1'
        THEN L_OPP.TOTAL_RENEWAL__C
      END , 0) AS Renewal_Year1_Closed_Opp,
      CASE
        WHEN L_OPP.Forecastcategory              = 'Closed'
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1'
        THEN 'Renewal_Year1_Closed_Opp_Drill'
      END AS Renewal_Year1_Closed_Opp_Drill,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategory             IN ('Pipeline', 'Forecast', 'BestCase')
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1'
        THEN L_OPP.TOTAL_RENEWAL__C
      END , 0) AS Renewal_Year1_OPEN_Opp,
      CASE
        WHEN L_OPP.Forecastcategory             IN ('Pipeline', 'Forecast', 'BestCase')
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1'
        THEN 'Renewal_Year1_OPEN_Opp_Drill'
      END AS Renewal_Year1_OPEN_Opp_Drill,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategory              = 'Closed'
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2'
        THEN L_OPP.TOTAL_RENEWAL__C
      END , 0) AS Renewal_Year2_Closed_Opp,
      CASE
        WHEN L_OPP.Forecastcategory              = 'Closed'
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2'
        THEN 'Renewal_Year2_Closed_Opp_Drill'
      END AS Renewal_Year2_Closed_Opp_Drill,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategory             IN ('Pipeline', 'Forecast', 'BestCase')
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2'
        THEN L_OPP.TOTAL_RENEWAL__C
      END , 0) AS Renewal_Year2_OPEN_Opp,
      CASE
        WHEN L_OPP.Forecastcategory             IN ('Pipeline', 'Forecast', 'BestCase')
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2'
        THEN 'Renewal_Year2_OPEN_Opp_Drill'
      END AS Renewal_Year2_OPEN_Opp_Drill
    FROM DW.OPP_C_DIM
    RIGHT OUTER JOIN RT.L_OPP
    ON (TO_CHAR(OPP_C_DIM.OFFER_CODE) =TO_CHAR(L_OPP.Offer_Code__C)
    AND (TO_CHAR(L_OPP.CloseDate,'YYYYMM'))  = TO_CHAR(OPP_C_DIM.PERIOD))
    LEFT OUTER JOIN RT.L_User
    ON (L_OPP.Ownerid=L_User.Id)
    LEFT OUTER JOIN DW.Tm_Rep
    ON (Tm_Rep.Rep_Num='0'
      ||L_User.Rep_Employee_Number__C)
    )) T774110 ON T7167.MEMBER_KEY = T774110.Rep_Id
  AND T7167.SALESYEARMONTH         = T774110.Sales_Year_Month)
  LEFT OUTER JOIN DW.TM_R_REP T7171
  ON T7167.ANCESTOR_KEY    = T7171.CHILD_REP_ID
  AND T7167.SALESYEARMONTH = T7171.SALES_YEAR_MONTH)
  LEFT OUTER JOIN DW.TM_REP T6715
  ON T7171.CHILD_REP_ID_N        = T6715.REP_ID
  WHERE ( T774110.Sales_Year_Month = T7315.YEAR_MONTH
  AND T7171.CH_ID_SYM    IN
    (SELECT DISTINCT D1.c1 AS c1 FROM SUBWITH2 D1
    )
  AND T7171.SALES_YEAR_MONTH BETWEEN '201505' AND '201505'
  AND T7171.CH_ID_SYM IN
    (SELECT DISTINCT D1.c1 AS c1 FROM SUBWITH1 D1
    ) )
  ),
  SAWITH1 AS
  (SELECT SUM(T774110.Renewal_Year2_OPEN_Opp) AS c9,
    SUM(T774110.Renewal_Year2_Closed_Opp)     AS c10,
    SUM(T774110.Renewal_Year1_OPEN_Opp)       AS c11,
    SUM(T774110.Renewal_Year1_Closed_Opp)     AS c12,
    SUM(T774110.OPEN_Oppurtunity)             AS c13,
    SUM(T774110.Closed_Oppurtunity)           AS c14,
    T7315.MONTH_NUMERIC                     AS c15,
    T7171.CH_ID_SYM                  AS c16
  FROM DW.TIM_MON T7315
    ,
    ( RT.L_ACCOUNT T765190
  LEFT OUTER JOIN ( DW.PC_T_REP T7167
  LEFT OUTER JOIN (
    (SELECT TO_NUMBER(TO_CHAR(L_OPP.CloseDate,'YYYYMM')) AS Sales_Year_Month,
      Tm_Rep.Rep_Id                                              AS Rep_Id,
      L_OPP.Account_Name__C                              AS Account_Name__C,
      L_OPP.Closedate                                    AS Closedate,
      L_OPP.Forecastcategory                             AS Forecastcategory,
      L_OPP.Forecastcategoryname                         AS Forecastcategoryname,
      L_User.NAME                                                AS Opp_Owner_S_Sales_Org__C,
      L_OPP.Opportunity_Id__C                            AS Opportunity_Id__C,
      L_OPP.Renewal_Date__C                              AS Renewal_Date__C,
      L_OPP.Total_Incremental__C                         AS Total_Incremental__C,
      L_OPP.Offer_Code__C                                AS Offer_Code__C,
      L_OPP.ID                                           AS Opportunity_ID,
      L_OPP.TERRITORYID                                  AS TERRITORYID,
      L_OPP.ACCOUNTID                                    AS ACCOUNTID,
      L_OPP.OWNERID                                      AS OWNERID,
      L_OPP.TOTAL_RENEWAL__C                             AS TOTAL_RENEWAL__C,
      L_OPP.NAME                                         AS NAME,
      L_OPP.STAGENAME                                    AS STAGE_NAME,
      L_OPP.STAGE_DESCRIPTION__C                         AS STAGE_DESCRIPTION,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategory                = 'Closed'
        AND( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL )
        THEN L_OPP.Total_Incremental__C
      END , 0) AS Closed_Oppurtunity,
      CASE
        WHEN L_OPP.Forecastcategory                 = 'Closed'
        AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL )
        THEN 'Closed_Oppurtunity_Drill'
      END AS Closed_Oppurtunity_Drill,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategoryname            IN ('Pipeline', 'Potential', 'Commit')
        AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL )
        THEN L_OPP.Total_Incremental__C
      END , 0) AS OPEN_Oppurtunity,
      CASE
        WHEN L_OPP.Forecastcategoryname            IN ('Pipeline', 'Potential', 'Commit')
        AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL )
        THEN 'OPEN_Oppurtunity_Drill'
      END AS OPEN_Oppurtunity_Drill,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategory              = 'Closed'
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1'
        THEN L_OPP.TOTAL_RENEWAL__C
      END , 0) AS Renewal_Year1_Closed_Opp,
      CASE
        WHEN L_OPP.Forecastcategory              = 'Closed'
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1'
        THEN 'Renewal_Year1_Closed_Opp_Drill'
      END AS Renewal_Year1_Closed_Opp_Drill,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategory             IN ('Pipeline', 'Forecast', 'BestCase')
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1'
        THEN L_OPP.TOTAL_RENEWAL__C
      END , 0) AS Renewal_Year1_OPEN_Opp,
      CASE
        WHEN L_OPP.Forecastcategory             IN ('Pipeline', 'Forecast', 'BestCase')
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1'
        THEN 'Renewal_Year1_OPEN_Opp_Drill'
      END AS Renewal_Year1_OPEN_Opp_Drill,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategory              = 'Closed'
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2'
        THEN L_OPP.TOTAL_RENEWAL__C
      END , 0) AS Renewal_Year2_Closed_Opp,
      CASE
        WHEN L_OPP.Forecastcategory              = 'Closed'
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2'
        THEN 'Renewal_Year2_Closed_Opp_Drill'
      END AS Renewal_Year2_Closed_Opp_Drill,
      NVL(
      CASE
        WHEN L_OPP.Forecastcategory             IN ('Pipeline', 'Forecast', 'BestCase')
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2'
        THEN L_OPP.TOTAL_RENEWAL__C
      END , 0) AS Renewal_Year2_OPEN_Opp,
      CASE
        WHEN L_OPP.Forecastcategory             IN ('Pipeline', 'Forecast', 'BestCase')
        AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2'
        THEN 'Renewal_Year2_OPEN_Opp_Drill'
      END AS Renewal_Year2_OPEN_Opp_Drill
    FROM DW.OPP_C_DIM
    RIGHT OUTER JOIN RT.L_OPP
    ON (TO_CHAR(OPP_C_DIM.OFFER_CODE) =TO_CHAR(L_OPP.Offer_Code__C)
    AND (TO_CHAR(L_OPP.CloseDate,'YYYYMM'))  = TO_CHAR(OPP_C_DIM.PERIOD))
    LEFT OUTER JOIN RT.L_User
    ON (L_OPP.Ownerid=L_User.Id)
    LEFT OUTER JOIN DW.Tm_Rep
    ON (Tm_Rep.Rep_Num='0'
      ||L_User.Rep_Employee_Number__C)
    )) T774110 ON T7167.MEMBER_KEY = T774110.Rep_Id
  AND T7167.SALESYEARMONTH         = T774110.Sales_Year_Month) ON T765190.ID = T774110.ACCOUNTID)
  LEFT OUTER JOIN DW.TM_R_REP T7171
  ON T7167.ANCESTOR_KEY          = T7171.CHILD_REP_ID
  AND T7167.SALESYEARMONTH       = T7171.SALES_YEAR_MONTH
  WHERE ( T774110.Sales_Year_Month = T7315.YEAR_MONTH
  AND T7171.CH_ID_SYM    IN
    (SELECT DISTINCT D1.c1 AS c1 FROM SUBWITH2 D1
    )
  AND T7171.SALES_YEAR_MONTH BETWEEN '201505' AND '201505'
  AND T7171.CH_ID_SYM IN
    (SELECT DISTINCT D1.c1 AS c1 FROM SUBWITH1 D1
    ) )
  GROUP BY T7171.CH_ID_SYM,
    T7315.MONTH_NUMERIC
  )
SELECT DISTINCT D2.c9 AS c1,
  D2.c10              AS c2,
  D2.c11              AS c3,
  D2.c12              AS c4,
  D2.c13              AS c5,
  D2.c14              AS c6,
  D1.c1               AS c7,
  D1.c2               AS c8,
  D1.c3               AS c9,
  D1.c4               AS c10,
  D1.c5               AS c11,
  D1.c6               AS c12,
  D1.c7               AS c13,
  D1.c8               AS c14
FROM SAWITH0 D1
INNER JOIN SAWITH1 D2
ON SYS_OP_MAP_NONNULL(D2.c15)  = SYS_OP_MAP_NONNULL(D1.c4)
AND SYS_OP_MAP_NONNULL(D2.c16) = SYS_OP_MAP_NONNULL(D1.c7)
ORDER BY c10,
  c13

SQL in real time, followed by the details with the Predicate Section of dbms_xplan.display_cursor shot

Global stats

==============================================================================================================================

==============================================================================================================================

| 152. 146. 3.73 | 0.08 | 0.04 | 2.04 | 2. 16 M | 5223. 1 GB | 1. 200KB | 95,11% |

==============================================================================================================================

SQL details surveillance Plan (Plan hash value = 442312180)

===============================================================================================================================================================================================================================================

| 0 | SELECT STATEMENT | | | | 1. 152. 1. 0 | | | | | 0.65 | Cpu (1) |

| 1. RANGE OF PARTITION ALL THE | | 1. 3892 | | | 1. | | | | | | |

| 2. ACCESS STORAGE FULL FIRST RANKS TABLE. PC_T_REP | 1. 3892 | | | 37. | 74. 19 MB | 78.45% | 17 M | | |

| 3. TRANSFORMATION OF THE TEMPORARY TABLE. | | | 1. 152. 1. 1. | | | | | |

| 4. LOAD SELECT ACE | | | | 1. + 5 | 1. 1. | | | 278K | | |

| 5. VIEW | | 105. 3980 | 1. + 5 | 1. 13637 | | | | | | |

| 6. SORT UNIQUE | | 105. 3980 | 1. + 5 | 1. 13637 | | | | 757K | | |

| 7. UNION-ALL | | | | 1. + 5 | 1. 14033. | | | | | |

| 8. STORE TABLE FULL ACCESS | TM_R_REP | 22. 88. 1. + 5 | 1. 36. | | | | | |

| 9. RANGE OF PARTITION ALL THE | | 83. 3890. 1. + 5 | 1. 13997. | | | | | |

| 10. STORE TABLE FULL ACCESS | PC_T_REP | 83. 3890. 6. + 0 | 37. 13997. | | | 2 M | 0.65 | Smart cell table scan (1) |

| 11. LOAD SELECT ACE | | | | 1. + 5 | 1. 1. | | | 278K | | |

| 12. HASH UNIQUE | | 1. 4166. 1. + 5 | 1. 1. | | | 479K | | |

| 13. HASH JOIN | | 1. 4165 | 1. + 5 | 1. 444. | | | 1 M | | |

| 14. JOIN FILTER PART CREATE | : BF0000 | 3. 4075 | 1. + 5 | 1. 549. | | | | | |

| 15. OUTER HASH JOIN | | 3. 4075 | 1. + 5 | 1. 549. | | | 1 M | | |

| 16. HASH JOIN | | 3. 4068 | 1. + 5 | 1. 549. | | | 2 M | | |

| 17. VIEW | | 105. 3980 | 1. + 5 | 1. 13637 | | | | | | |

| 18. SORT UNIQUE | | 105. 3980 | 1. + 5 | 1. 13637 | | | | 757K | | |

| 19. UNION-ALL | | | | 1. + 5 | 1. 14033. | | | | | |

| 20. STORE TABLE FULL ACCESS | TM_R_REP | 22. 88. 1. + 5 | 1. 36. | | | | | |

| 21. RANGE OF PARTITION ALL THE | | 83. 3890. 1. + 5 | 1. 13997. | | | | | |

| 22. STORE TABLE FULL ACCESS | PC_T_REP | 83. 3890. 1. + 5 | 37. 13997. | | | 2 M | | |

| 23. STORE TABLE FULL ACCESS | TM_R_REP | 1884 | 88. 1. + 5 | 1. 1929 | | | | | | |

| 24. STORE TABLE FULL ACCESS | TM_REP | 7136 | 7. 1. + 5 | 1. 7137 | | | | | | |

| 25. RANGE OF SINGLE PARTITION | | 7449. 90. 1. + 5 | 1. 7449. | | | | | |

| 26. STORE TABLE FULL ACCESS | PC_T_REP | 7449. 90. 1. + 5 | 1. 7449. | | | | | |

| 27. SORT UNIQUE | | 1. 26032 | 1. 152. 1. 1. | | | 2048 | | |

| 28. OUTER HASH JOIN | | 1. 26031 | 72. + 81 | 1. 8238 | | | | 4 M | | |

| 29. FILTER | | | | 74. + 79 | 1. 8238 | | | | | 1.96 | Cpu (3) |

| 30. NESTED EXTERNAL LOOPS | | 1. 26027 | 72. + 81 | 1. 15 M | | | | | 3.27 | Cpu (5) |

| 31. HASH JOIN | | 1. 26026 | 72. + 81 | 1. 15 M | | | | 447K | 18.95 | Cpu (29) |

| 32. OUTER HASH JOIN | | 1. 13213 | 1. + 81 | 1. 332. | | | 452K | | |

| 33. HASH JOIN | | 1. 13206 | 1. + 81 | 1. 332. | | | 1 M | | |

| 34. HASH JOIN | | 1. 13199. 1. + 81 | 1. 444. | | | 434K | | |

| 35. HASH JOIN | | 1. 13197. 1. + 81 | 1. 444. | | | 290K | | |

| 36. JOIN CREATE FILTER | : BF0000 | 1. 13195. 1. + 81 | 1. 444. | | | | | |

| 37. HASH JOIN | | 1. 13195. 1. + 81 | 1. 444. | | | 2 M | | |

| 38. THE CARTESIAN MERGE JOIN. | 27. 13107 | 1. + 81 | 1. 7449. | | | | | |

| 39. HASH JOIN | | 1. 13017. 77. + 5 | 1. 1. | | | 750K | | |

| 40. STORE TABLE FULL ACCESS | TIM_MON | 1. 4. 1. + 5 | 1. 1. | | | | | |

| 41. VIEW | | 1. 13013. 1. + 81 | 1. 1. | | | | | |

| 42. HASH GROUP BY. | 1. 13013. 1. + 81 | 1. 1. | | | 482K | | |

| 43. OUTER HASH JOIN | | 1. 13012. 77. + 5 | 1. 8238 | | | | 4 M | | |

| 44. NESTED LOOPS | | 1. 13008. 77. + 5 | 1. 8238 | | | | | | |

| 45. FILTER | | | | 77. + 5 | 1. 8238 | | | | | 2.61 | Cpu (4) |

| 46. NESTED EXTERNAL LOOPS | | 1. 13007. 77. + 5 | 1. 15 M | | | | | 4.58. Cpu (7) |

| 47. HASH JOIN | | 1. 13006. 77. + 5 | 1. 15 M | | | | 424K | 11.76. Cpu (18) |

| 48. HASH JOIN | | 1. 193. 1. + 5 | 1. 332. | | | 1 M | | |

| 49. HASH JOIN | | 1. 186. 1. + 5 | 1. 444. | | | 420K | | |

| 50. HASH JOIN | | 4. 184. 1. + 5 | 1. 444. | | | 290K | | |

| 51. JOIN CREATE FILTER | : BF0002 | 1. 94. 1. + 5 | 1. 1. | | | | | |

| 52. JOIN FILTER PART CREATE | : BF0001 | 1. 94. 1. + 5 | 1. 1. | | | | | |

| 53. HASH JOIN | | 1. 94. 1. + 5 | 1. 1. | | | 290K | | |

| 54. JOIN CREATE FILTER | : BF0003 | 1. 6. 1. + 5 | 1. 1. | | | | | |

| 55. THE CARTESIAN MERGE JOIN. | 1. 6. 1. + 5 | 1. 1. | | | | | |

| 56. STORE TABLE FULL ACCESS | TIM_MON | 1. 4. 1. + 5 | 1. 1. | | | | | |

| 57. KIND OF BUFFER. | 1. 2. 1. + 5 | 1. 1. | | | 2048 | | |

| 58. VIEW | VW_NSO_1 | 1. 2. 1. + 5 | 1. 1. | | | | | |

| 59. UNIQUE HASH | | 1. | 1. + 5 | 1. 1. | | | 485K | | |

| 60. VIEW | | 1. 2. 1. + 5 | 1. 1. | | | | | |

| 61. STORE TABLE FULL ACCESS | SYS_TEMP_0FD9D71E1_B445AE36 | 1. 2. 1. + 5 | 1. 1. | | | | | |

| 62. USE OF JOIN FILTER | : BF0003 | 1884 | 88. 1. + 5 | 1. 1. | | | | | |

| 63. STORE TABLE FULL ACCESS | TM_R_REP | 1884 | 88. 1. + 5 | 1. 1. | | | | | |

| 64. USE OF JOIN FILTER | : BF0002 | 7449. 90. 1. + 5 | 1. 444. | | | | | |

| 65. RANGE OF SINGLE PARTITION | | 7449. 90. 5. + 1 | 1. 444. | | | | 0.65 | Cpu (1) |

| 66. STORE TABLE FULL ACCESS | PC_T_REP | 7449. 90. 1. + 5 | 1. 444. | | | | | |

| 67. VIEW | | 105. 2. 1. + 5 | 1. 13637 | | | | | | |

| 68. STORE TABLE FULL ACCESS | SYS_TEMP_0FD9D71E0_B445AE36 | 105. 2. 1. + 5 | 1. 13637 | | | | | | |

| 69. STORE TABLE FULL ACCESS | TM_REP | 7136 | 7. 1. + 5 | 1. 7137 | | | | | | |

| 70. STORE TABLE FULL ACCESS | L_OP | 19382 | 12813 | 77. + 5 | 1. 43879 | 565. 551 MB | 98.18% | 15 M | | |

| 71. TABLE ACCESS BY INDEX ROWID | L_US | 1. 1. 79. + 3 | 15 M | 15 M | 26. 208KO | | | 19.61 | Cpu (30) |

| 72. INDEX UNIQUE SCAN | L_US_PK | 1. | 77. + 5 | 15 M | 15 M | 2. 16384. | | 9 h 15 | Cpu (14) |

| 73. INDEX UNIQUE SCAN | L_A_PK | 1. 1. 151. + 2 | 8238 | 8238 | 3269 | 26 MB | | | 2.61 | Cpu (1) |

| 74. STORE TABLE FULL ACCESS | OPP_C_DIM | 2304 | 4. 1. + 81 | 1. 2304 | 3. 112 KB | | | | |

| 75. KIND OF BUFFER. | 7449. 13107 | 1. + 81 | 1. 7449. | | | 370K | | |

| 76. RANGE OF SINGLE PARTITION | | 7449. 90. 1. + 81 | 1. 7449. | | | | | |

| 77. STORE TABLE FULL ACCESS | PC_T_REP | 7449. 90. 1. + 81 | 1. 7449. | | | | | |

| 78. STORE TABLE FULL ACCESS | TM_R_REP | 1884 | 88. 1. + 81 | 1. 1929 | | | | | | |

| 79. VIEW | | 1. 2. 1. + 81 | 1. 1. | | | | | |

| 80. USE OF JOIN FILTER | : BF0000 | 1. 2. 1. + 81 | 1. 1. | | | | | |

| 81. STORE TABLE FULL ACCESS | SYS_TEMP_0FD9D71E1_B445AE36 | 1. 2. 1. + 81 | 1. 1. | | | | | |

| 82. VIEW | | 105. 2. 1. + 81 | 1. 13637 | | | | | | |

| 83. STORE TABLE FULL ACCESS | SYS_TEMP_0FD9D71E0_B445AE36 | 105. 2. 1. + 81 | 1. 13637 | | | | | | |

| 84. STORE TABLE FULL ACCESS | TM_REP | 7136 | 7. 1. + 81 | 1. 7137 | | | | | | |

| 85. STORE TABLE FULL ACCESS | TM_REP | 7136 | 7. 1. + 81 | 1. 7137 | | | | | | |

| 86. STORE TABLE FULL ACCESS | L_OP | 19382 | 12813 | 72. + 81 | 1. 43879 | 593. 577 MB | 98,44% | 15 M | | |

| 87. TABLE ACCESS BY INDEX ROWID | L_US | 1. 1. 72. + 81 | 15 M | 15 M | | | | | 13.73. Cpu (21) |

| 88. INDEX UNIQUE SCAN | L_US_PK | 1. | 73. + 80 | 15 M | 15 M | | | | | 9.80 | Cpu (15) |

| 89. STORE TABLE FULL ACCESS | OPP_C_DIM | 2304 | 4. 1. 152. 1. 2304 | | | | | | |

Information of predicates (identified by the operation identity card):

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

2. (("MEMBER_KEY_SYM" =: B1 ET "IS_LEAF" = 1) filter)

8 - storage("T7171".") CHILD_REP_ID "= 939)

filter ("T7171". ("CHILD_REP_ID" = 939)

10 - storage("T7167".") ANCESTOR_KEY "= 939)

filter ("T7167". ("ANCESTOR_KEY" = 939)

13 - access("T7167".") SALESYEARMONTH "= 'T7171'." SALES_YEAR_MONTH' AND 'T7167 '. "ANCESTOR_KEY"= "T7171". ("' CHILD_REP_ID")

filter (CASE WHEN TO_CHAR ("T7171". "CHILD_REP_ID_N") AS 9999% ' THEN 'ALL UNASSIGNED' | " CAST ("T7167". ("TERRITORY_ID" AS A VARCHAR (20)) ELSE 'T6715 '. "" NAME "| "

'||" T6715 ". "" MIDDLE_NAME "| " '||" T6715 ". ("" LAST_NAME "END ="JOES CRAMER")

15 - access("T7171".") CHILD_REP_ID_N "= 'T6715'." REP_ID")

16 - access("T7171".") CH_ID_SYM '= 'D1'.' C1")

20 - storage("T7171".") CHILD_REP_ID "= 939)

filter ("T7171". ("CHILD_REP_ID" = 939)

22 - storage("T7167".") ANCESTOR_KEY "= 939)

filter ("T7167". ("ANCESTOR_KEY" = 939)

23 - storage("T7171".") SALES_YEAR_MONTH "= 201505)

filter ("T7171". ("SALES_YEAR_MONTH" = 201505)

26 - storage("T7167".") SALESYEARMONTH "= 201505)

filter ("T7167". ("SALESYEARMONTH" = 201505)

28 - access (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM") = TO_CHAR ("OPP_C_DIM". " PERIOD") AND

TO_CHAR ("OPP_C_DIM". "OFFER_CODE") = "L_OP". ("' OFFER_CODE__C")

29 - filter("TM_REP".") REP_NUM "=" 0"|" » « « « L_US «. » REP_EMPLOYEE_NUMBER__C')

31 - access("T7315".") YEAR_MONTH «= TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP".» CLOSEDATE"),"YYYYMM")) AND

'T7167 '. «SALESYEARMONTH «= TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP".» (((("" CLOSEDATE "),"YYYYMM")))

32 - access("T7171".") CHILD_REP_ID_N "= 'T6715'." REP_ID")

33 - access("T7167".") MEMBER_KEY "=" TM_REP. " ("" REP_ID ")

34 - access("T7171".") CH_ID_SYM '= 'D1'.' C1")

35 - access("T7171".") CH_ID_SYM '= 'D1'.' C1")

37 - access (SYS_OP_MAP_NONNULL ("D2". "C16") = SYS_OP_MAP_NONNULL ("T7171". " CH_ID_SYM") AND"T7167 ". "SALESYEARMONTH"= "T7171". "" SALES_YEAR_MONTH "AND

'T7167 '. "ANCESTOR_KEY"= "T7171". ("' CHILD_REP_ID")

39 - access (SYS_OP_MAP_NONNULL ("D2". "C15") = SYS_OP_MAP_NONNULL ("T7315". " MONTH_NUMERIC'))

40 - storage("T7315".") YEAR_MONTH "= 201505)

filter ("T7315". ("YEAR_MONTH" = 201505)

43 - access (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM") = TO_CHAR ("OPP_C_DIM". " PERIOD") AND

TO_CHAR ("OPP_C_DIM". "OFFER_CODE") = "L_OP". ("' OFFER_CODE__C")

45 - filter("TM_REP".") REP_NUM "=" 0"|" » « « « L_US «. » REP_EMPLOYEE_NUMBER__C')

47 - access("T7315".") YEAR_MONTH «= TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP".» CLOSEDATE"),"YYYYMM")) AND

'T7167 '. «SALESYEARMONTH «= TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP".» (((("" CLOSEDATE "),"YYYYMM")))

48 - access("T7167".") MEMBER_KEY "=" TM_REP. " ("" REP_ID ")

49 - access("T7171".") CH_ID_SYM '= 'D1'.' C1")

50 - access("T7167".") SALESYEARMONTH "= 'T7171'." SALES_YEAR_MONTH' AND 'T7167 '. "ANCESTOR_KEY"= "T7171". ("' CHILD_REP_ID")

53 - access("T7171".") CH_ID_SYM "=" C1")

56 - storage("T7315".") YEAR_MONTH "= 201505)

filter ("T7315". ("YEAR_MONTH" = 201505)

63 - storage (("T7171". "SALES_YEAR_MONTH" = 201505 AND SYS_OP_BLOOM_FILTER (: BF0000, "T7171" ".") CH_ID_SYM')))

filter (("T7171". "SALES_YEAR_MONTH" = 201505 AND SYS_OP_BLOOM_FILTER (: BF0000, "T7171" ".") CH_ID_SYM')))

66 - storage (("T7167". "SALESYEARMONTH" = 201505 AND SYS_OP_BLOOM_FILTER (: BF0000, "T7167" ".") SALESYEARMONTH', 'T7167 '. ((("" ANCESTOR_KEY ")))

filter (("T7167". "SALESYEARMONTH" = 201505 AND SYS_OP_BLOOM_FILTER (: BF0000, "T7167" ".") SALESYEARMONTH', 'T7167 '. ((("" ANCESTOR_KEY ")))

70 - storage ((TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) > = 201505 AND "

TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) (< = 201505)) "

filter ((TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) > = 201505 AND "

TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) (< = 201505)) "

72 - access("L_OP".") OWNERID "=" L_US. " (' ' ID ')

73 - access("T765190".") WITH THE ID "=" L_OP. " ("' ACCOUNTID ')

77 - storage("T7167".") SALESYEARMONTH "= 201505)

filter ("T7167". ("SALESYEARMONTH" = 201505)

78 - storage("T7171".") SALES_YEAR_MONTH "= 201505)

filter ("T7171". ("SALES_YEAR_MONTH" = 201505)

81 - storage (SYS_OP_BLOOM_FILTER (: BF0000, "C0"))

filter (SYS_OP_BLOOM_FILTER (: BF0000, "C0"))

86 - storage ((TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) > = 201505 AND "

TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) (< = 201505)) "

filter ((TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) > = 201505 AND "

TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) (< = 201505)) "

88 - access("L_OP".") OWNERID "=" L_US. " (' ' ID ')

Note

-----

-dynamic sample used for this survey (level = 4)

-Automatic DOP: calculated degree of parallelism is 1 because of the parallel threshold

Although the table meet statistical why dynamic sampling is to be used? Why 15 million times ID 71, 72, 87 and 88 are executed, curious because that is where most of the time is spent. How can we reduce this 15 million probes?

Suggestions to reduce the response time sql would be useful.

Post edited by: Yasu masking of sensitive information (literal value)

YASU says:

For educational purposes could you please clarify why the optimizer has evaluated the join condition in the functioning of the FILTER to 15 million lines?

This is unusual, but TM_REP is attached to another PC_T_REP table using a join operation, so maybe it's the explanation of why it is moved to a FILTER operation had been delayed - could also be a side effect of the combination of ANSI join processing (Oracle internally transforms ANSI joins in Oracle join syntax) and the transformation of outer join internally.

Very curious to know how this is possible, could you please give us the hint/tour, you can use to push the inner join down execution plan is evaluated as soon as possible to reduce the data to be processed? I have a sql plus, where the situation is almost similar - ranks of filtering 2 million to the hash JOIN operation and return 0 rows. I can post the details of sql here but not to mix different sql question in the same post. Please let me know if you would like to give the details of this sql in this same thread, or a different thread? I searched for this type of information, but to no avail, so could you please suggest how this is possible, if not for this long sql then at least please provide a few examples/suggestions?

Normally you can influence this through the appropriate join order, for example with the help of the LEADING indicator, for filter indicator PUSH_SUBQ subqueries can also be useful for filtering at the beginning. But here the comment of Franck is particularly important - by leaning on the Cartesian join this problem here should be less relevant.

As I already said I would recommend here from scratch and think that all that this query is supposed to average and the question why most outer joins is actually converted into inner joins - the current query example returns the correct result?

Randolf

Tags: Database

Similar Questions

page every time I try to download a free trial version for the sequels, I get to the legacy that when I click on free trial he always says we know the atm problem but its nothing to with the wifi is good, but its unique every time Please HELP

page every time I try to download a free trial version for the sequels, I get to the legacy that when I click on free trial he always says we know the atm problem but its nothing to with the wifi is good, but its unique every time Please HELP

You MUST have a 64-bit computer and operating system... What is your computer?

-Programs are supposed TO not view or download if they are not installed on your computer

MINIMUM for After Effects and Premiere Pro http://helpx.adobe.com/premiere-pro/system-requirements.html

Subquery 'WITH SAWITH0 AS' OBIEE 11 g factoring clause contained in the generated sql code
I have observed that OBIEE 11 g generates in physics request log query using the (subquery factoring) WITH clause to the generated sql code elegantly readable. It's great! Thanks for the developers. However I have a few questions about it.

__Background__
Oracle database ' default behavior is that if you have only a subquery in the section, it runs as a perspective in line and he not materialized before the main sql is running. If you have more than one default database engine materializes all the in the order of definition. In some cases, it can completely blow up the SGA and make a query without end. To divert this behavior, you can apply two tips that work both in inline views in subqueries as well: / * + MATERIALIZE * / and / * + INLINE * /, however Analytics 11 g does not seem to have capabilities of Board at the table level logical, only at the level of the physical table.

If we go with the current default settings, the developers do not know this feature can fall on serious performance problems for the sake of a few sweets of syntax to the generated sql level, I'm afraid.

__Questions__

* It is possible to turn the Analytics Server to not use WITH but views inline instead?
* Is it possible to sneak in a few boards that would the / * + INLINE * / allusion to the proper place in the subqueries generated if necessary
* Is the Oracle database has any initialization parameter that can influence the behavior of this subquery factoring and divert by default?
The WITH statement is not added to make the query more elegant, it is added for performance reasons. If your queries slow to run, then you can have a design problem. In a typical DWH DB SGA should be increased seriously given that ran queries are much larger and complex than on an OLTP DB. In all cases, you can disable the WITH statement in the administration tool by double clicking on your database on the physical layer from object in the features tab. The function is called WITH_CLAUSE_SUPPORTED.

AVG TUNE MY C drive, 10% said stall can be time... Is it good or bad... It was work, but slow

a AVG TUNE MY desktop hp 500... Last tune up has been the C drive... He stuck on 10% and says can take an hour... Is it good or bad... He

You can ask either https://support.avg.com/?l=en_US

and/or

https://support.Avg.com/answers

Subquery factoring and DB Link

Hello

2 node RAC

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

I have a query of the form...

WITH temp as 
             (select col1, col2, col3 from LOCAL_TABLE)
           SELECT /*+ driving_site (remote1) */
             remote1.col1,
             remote1.col1,
             remote1.col1,
             remote1.col1,
             remote1.col1,
             remote1.col1,
             remote2.col1,
             remote2.col1,
             remote2.col1,
             remote2.col1,
             remote2.col1,
             null,
             null
          from remote_view1@dblink remote1, -- Remote View over 2 dbs
                 remote_view2@dblink remote2  -- Remote View over 2 dbs
           where remote1.col1 in (select col1 from temp);

This query used to work, but recently there has been a change of remote_view1, after which the query takes a long time to run.

The good performing query takes 2 seconds, while providing the wrong one takes about 8 minutes.

However, if I remove the subquery factoring and include the query as a subquery it works well.

           SELECT /*+ driving_site (remote1) */
             remote1.col1,
             remote1.col1,
             remote1.col1,
             remote1.col1,
             remote1.col1,
             remote1.col1,
             remote2.col1,
             remote2.col1,
             remote2.col1,
             remote2.col1,
             remote2.col1,
             null,
             null
          from remote_view1@dblink remote1, -- Remote View over 2 dbs
                 remote_view2@dblink remote2  -- Remote View over 2 dbs
           where remote1.col1 in  (select col1, col2, col3 from LOCAL_TABLE);

I tried to check the data from v$ sql. I saw this;

v$ SQL. Remote = 'Y' - good performance
v$ SQL. Remote = "n" - poor performance

All the world is facing this situation?

Rgds,
Guenoun

Do I have reason to assume that the queries executed entirely remote db have plans stored in v$ sql_plan

Right.

SQL> select /*+ domtest */ 1 from dual@domtest;

         1
----------
         1

SQL> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------
SQL_ID  9d51rf84zvt0s, child number 0

select /*+ domtest */ 1 from dual@domtest

NOTE: cannot fetch plan for SQL_ID: 9d51rf84zvt0s, CHILD_NUMBER: 0
      Please verify value of SQL_ID and CHILD_NUMBER;
      It could also be that the plan is no longer in cursor cache (check v$sql_plan)

8 rows selected.

SQL> select sql_id, remote, sql_text from v$sql where sql_id = '9d51rf84zvt0s';

SQL_ID        R SQL_TEXT
------------- - --------------------------------------------------
9d51rf84zvt0s Y select /*+ domtest */ 1 from dual@domtest

SQL> select * from v$sql_plan where sql_id = '9d51rf84zvt0s';

no rows selected

SQL> select /*+ domtest */ 1 from dual@domtest t, dual;

         1
----------
         1

Elapsed: 00:00:00.00
SQL> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------
SQL_ID  d0m08znks4yak, child number 0
-------------------------------------
select /*+ domtest */ 1 from dual@domtest t, dual

Plan hash value: 3754369022

-------------------------------------------------------------------------------------
| Id  | Operation            | Name | Rows  | Cost (%CPU)| Time     | Inst   |IN-OUT|
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |      |       |     4 (100)|          |        |      |
|   1 |  MERGE JOIN CARTESIAN|      |     1 |     4   (0)| 00:00:01 |        |      |
|   2 |   REMOTE             | DUAL |     1 |     2   (0)| 00:00:01 | DOMTE~ | R->S |
|   3 |   BUFFER SORT        |      |     1 |     2   (0)| 00:00:01 |        |      |
|   4 |    FAST DUAL         |      |     1 |     2   (0)| 00:00:01 |        |      |
-------------------------------------------------------------------------------------

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

   2 - SELECT 0 FROM "DUAL" "T" (accessing 'DOMTEST' )

22 rows selected.

Elapsed: 00:00:00.04
SQL> select sql_id, remote, sql_text from v$sql where sql_id = 'd0m08znks4yak';

SQL_ID        R SQL_TEXT
------------- - --------------------------------------------------
d0m08znks4yak N select /*+ domtest */ 1 from dual@domtest t, dua

SQL> select /*+ driving_site(t) */ 1 from dual@domtest t, dual;

         1
----------
         1

Elapsed: 00:00:00.00
SQL> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------
SQL_ID  741u736nrk6dx, child number 0

select /*+ driving_site(t) */ 1 from dual@domtest t, dual

NOTE: cannot fetch plan for SQL_ID: 741u736nrk6dx, CHILD_NUMBER: 0
      Please verify value of SQL_ID and CHILD_NUMBER;
      It could also be that the plan is no longer in cursor cache (check v$sql_plan)

8 rows selected.

Elapsed: 00:00:00.01
SQL> select sql_id, remote, sql_text from v$sql where sql_id = '741u736nrk6dx';

SQL_ID        R SQL_TEXT
------------- - --------------------------------------------------
741u736nrk6dx Y select /*+ driving_site(t) */ 1 from dual@domtest
                t, dual

Elapsed: 00:00:00.00
SQL>
SQL> select * from v$sql_plan where sql_id = '741u736nrk6dx';

no rows selected

Elapsed: 00:00:00.01
SQL>

Published by: Dom Brooks on August 21, 2012 13:05

Identify cycles recursive subquery factoring (RSF/CTE)

It is possible to detect cycles AFTER executing a recursive factoring subquery with the cycle_clause.
I need to detect already in the query, similar to the virtual CONNECT_BY_ISCYCLE in a hierarchical query.
Here is a test case of the use of factoring of the recursive subquery (RSF) to the algorithm of Dijkstra shortest Implement path?.
DROP TABLE edges;
CREATE TABLE edges (char (1) src, dst char (1), distance, NUMBER (3, 0));
DROP TABLE nodes.
CREATE TABLE nodes (nodes CHAR (1));
-INSERTION in the edges
-normal direction
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('A', '' B, 2');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('A', 'C', '4');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('A' 'd', '3' ");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (' B', 'E', 7' ");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ("C", "E", "3");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (', 'E', '4');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (' B', 'F', 4' ");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('C', 'F', "2");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (', 'F', '1');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (' B', 'G', 6' ");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('C', 'G', "4");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (', 'G', '5');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('E', 'H', '1');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('F', 'H', '6');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('G', 'H', '3');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('E', 'I', '4');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('F', 'I', '3');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('G', 'I', '3');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('H', 'J', '3');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('I', 'J', '4');
-inversion
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('A', '' B, 2');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('A', 'C', '4');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('A' 'd', '3' ");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (' B', 'E', 7' ");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ("C", "E", "3");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (', 'E', '4');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (' B', 'F', 4' ");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('C', 'F', "2");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (', 'F', '1');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (' B', 'G', 6' ");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('C', 'G', "4");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (', 'G', '5');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('E', 'H', '1');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('F', 'H', '6');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('G', 'H', '3');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('E', 'I', '4');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('F', 'I', '3');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('G', 'I', '3');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('H', 'J', '3');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('I', 'J', '4');
-SELECT the recursive subquery factoring (RSF) / Common Table Expressions (CTE)
-INCLUDE the starting point of Sub
WITH the railways (root, src, dst, path, distance, cost, lev, iscyc) AS
(SELECT 'A', NULL, 'A', 'A', 0, 0, 1, 0
OF the double
UNION ALL
SELECT p.root,
e.SRC,
e.DST,
p.Path | ',' || e.DST,
e.distance,
p.cost + e.distance,
p.Lev + 1,
-good idea?
p.iscyc
RAILWAYS p
JOIN the edges e WE (e.src = p.dst)
AND lev + 1 < = 3
)
Lev RESEARCH FIRST WIDTH, cost line_no SET
CYCLE of dst SET is_cycle to 1 by DEFAULT 0
SELECT *.
TRAIL pr
WHERE 1 = 1
- AND is_cycle = 0
- AND DST = 'J '.
ORDER BY lev;

DISTANCE FROM ROOT SRC DST LEV ISCY LINE_NO IS_CYCLE COST PATH
-------------------------------------------------------------------
A           A     A         0     0     1     0       1       0
A     A     D     A,D       3     3     2     0       3       0
A     A     B     A,B       2     2     2     0       2       0
A     A     C     A,C       4     4     2     0       4       0
A     C     F     A,C,F     2     6     3     0       9       0
A E C E A, C, 3 7 3 0 10 0
AN E D A, D, E 4 7 3 0 11 0
B G G, B, 6 8 3 0 12 0
A C AN A, C, 4 8 3 0 13 1
A D G, D, G 5 8 3 0 14 0
G C G, C, 4 8 3 0 15 0
B E A, B, E 7 9 3 0 16 0
A     B     F     A,B,F     4     6     3     0       7       0
A     B     A     A,B,A     2     4     3     0       6       1
A     D     F     A,D,F     1     4     3     0       5       0
A     D     A     A,D,A     3     6     3     0       8       1
There is a powerful way to fill the column ISCY, while the recursion like the IS_CYCLE column?

I tried the table nested in CTE before but had a few questions. The code below works in 11g but not 12 c:

create or replace type nt_char in the table to the varchar2 (20);

/

WITH the railways (root, src, dst, path, distance, cost, lev, iscyc) AS

(SELECT 'A', NULL, 'A', CAST (nt_char ('A') AS nt_char), 0, 0, 1, 0)

OF the double

UNION ALL

SELECT p.root,

e.SRC,

e.DST,

nt_char (e.dst) MULTISET UNION ALL p.Path,

e.distance,

p.cost + e.distance,

p.Lev + 1,

CASE WHEN e.dst MEMBER OF p.path, 1 ELSE 0 END AS iscyc

RAILWAYS p

JOIN the edges e WE (e.src = p.dst)

AND lev + 1<>

)

Lev RESEARCH FIRST WIDTH, cost line_no SET

CYCLE of dst SET is_cycle to 1 by DEFAULT 0

SELECT *.

TRAIL pr

WHERE 1 = 1

- AND is_cycle = 0

- AND DST = 'J '.

ORDER BY lev;

Subquery factoring and materialize Hint
```
WITH t AS
        (SELECT MAX (lDATE) tidate
           FROM rate_Master
          WHERE     Code = 'G'
                AND orno > 0
                AND TYPE = 'L'
                AND lDATE <= ':entereddate')
SELECT DECODE (:p1,  'B', RateB,  'S', RateS,  Rate)
  FROM rate_Master, t
 WHERE     Code = 'G'
       AND orno > 0
       AND TYPE = 'L'
       AND NVL (lDATE, SYSDATE) = tidate;
```
In the example given the sub query returns just one line because of the max aggregate function. This by making a With clause that will be of any benefit? Also I assume / understand that factoring of subquery would be really useful when we try to do a sub query that returns multiple rows in a clause. Is my right to intrepration?

Then add the / * + Materialize * / reference to a query with is required or the optimizer itself will do and perform a transformation of the temporary table. In my example, I have to give the hint in the query. Please discuss and help

Thanks in advance.
ramarun wrote:
```
WITH t AS
(SELECT MAX (lDATE) tidate
FROM rate_Master
WHERE     Code = 'G'
AND orno > 0
AND TYPE = 'L'
AND lDATE <= ':entereddate')
SELECT DECODE (:p1,  'B', RateB,  'S', RateS,  Rate)
FROM rate_Master, t
WHERE     Code = 'G'
AND orno > 0
AND TYPE = 'L'
AND NVL (lDATE, SYSDATE) = tidate;
```
In the example given the sub query returns just one line because of the max aggregate function. This by making a With clause that will be of any benefit? Also I assume / understand that factoring of subquery would be really useful when we try to do a sub query that returns multiple rows in a clause. Is my right to intrepration?
Not quite.
The subquery factoring should be used when you want to use the subquery results more than once in your query. So if you write a regular SQL statement, but find that it is necessary to write the same subquery more than once inside, then you can factor on this subquery using the WITH clause, so that it is executed once, and the results may then be referenced several times in the main query. This is what gives a performance advantage in many cases.

Then add the / * + Materialize * / reference to a query with is required or the optimizer itself will do and perform a transformation of the temporary table. In my example, I have to give the hint in the query. Please discuss and help

As mentioned the suspicion of materialization is not documented so should not be used in production code. Personally, I found that it can add significant performance gain of a weighted subquery where this subquery causes a large amount of data. Don't know why the optimizer is not always materialize subqueries by default but... not really looked inside a lot.

Re-organization of database every week, it is good or bad?
We use windows 2003 server and oracle 10.2.0.4, having two databases with 38 GB and another 72 GB. And the recommendation of the application team suggested to the reorganization of the database for each week. So, I want to know wheather do re-organization of complete database for each week is good or bad.
Uwe Hesse wrote:
It's bad. No sophisticated response required here. No DBA (Oracle) is supposed to do a "database reorganization' - whatever that means in detail - once a week.

And if it is indeed a requirement of the team of apps: they built a very bad application :-)

Uwe,

I know you have read this before, but for reasons of the constant stream of the beginners

I remember once more the seller make a ground for its product, kept talking about SQL Server. We informed that we were an Oracle shop. He said (and I quote): "we do not recommend running on Oracle, because we found that the Oracle can't handle more than 5 concurrent connections.

I started my career 30 years ago as a developer. I am constantly amazed at the current generation of developers who seem to not only know nothing about the technology with which they work, but do not yet seem a curiosity about this. They give without thinking at all made to design anything.

* I predict this thread will be sleeping in the next 48 hours, but 3 years from now, someone will record this with the forum, do some research on... on what? ... and revive this thread with a useless comment as their very first post.

Kind regards
Uwe Hesse

http://uhesse.WordPress.com

The recursive subquery factoring vs hierarchical query
Experts,

Here it is two queries, I'm executing using hierarchical of recursive subquery and new classical approach. Problem came out was different for the recursive subquery factoring, as this is not displayed parent-child approach, while forwards connect shows parent-child mode. Query 1, I use hierarchical as show good output parent-child, is approaching the 2 query displays all of the nodes of level 1 and then level 2 nodes. I want the query 2 output to be the same as query 1. change query 2 as required.

Note: the output of the two queries post as in sqlplus and toad. Please copy and use in your command prompt.

QUERY 1:

with the hand in the form (select 1 id, name 'John', null, mgrid Union double all the)
Select 2 id, the name of 'michael', null, mgrid Union double all the
Select 3 id, the name of "peter", null, mgrid Union double all the
Select 4 id, the name of "henry", 1 mgrid Union double all the
Select 5 id, "nickname", mgrid 2 Union double all the
Select 6 id, "pao" name, mgrid 3 of all the double union
Select 7 id, the name of 'kumar', mgrid 3 of all the double union
Select 8 id, the name 'parker', mgrid 3 of all the double union
Select 9 id, the name of "mike", 5 double mgrid),
Select lpad (' ', 2 *(level-1)). name, key start with mgrid level is null connect by prior id = mgrid.

OUTPUT:

LEVEL NAME
------------------------------ ----------
John 1
Henry 2
Michael 1
Nick 2
Mike 3
Stone 1
PAO 2
Kumar 2
Parker 2

9 selected lines.

QUERY 2:

with the hand in the form (select 1 id, name 'John', null, mgrid Union double all the)
Select 2 id, the name of 'michael', null, mgrid Union double all the
Select 3 id, the name of "peter", null, mgrid Union double all the
Select 4 id, the name of "henry", 1 mgrid Union double all the
Select 5 id, "nickname", mgrid 2 Union double all the
Select 6 id, "pao" name, mgrid 3 of all the double union
Select 7 id, the name of 'kumar', mgrid 3 of all the double union
Select 8 id, the name 'parker', mgrid 3 of all the double union
Select 9 id, the name of "mike", 5 double mgrid),
/ * Select lpad (' ', 2 *(level-1)). name, key start with mgrid level is null connect by prior id = mgrid. * /
secmain (id, name, mgrid, hierlevel) as (select id, name, mgrid, 1 hierlevel of the main where mgrid is null
Union of all the
Select m.id, $m.name, m.mgrid, sm.hierlevel + 1 in m main join secmain sm on(m.mgrid=sm.id))
cycle is_cycle set id 1 default 0
Select lpad (' ', 2 *(hierlevel-1)). name, secmain hierlevel.

OUTPUT:

NAME HIERLEVEL
------------------------------ ----------
John 1
Michael 1
Stone 1
Henry 2
Nick 2
Parker 2
Kumar 2
PAO 2
Mike 3

9 selected lines.
For example
```
SQL> with main as(select 1 id,'john' name,null mgrid from dual union all
  2  select 2 id,'michael' name,null mgrid from dual union all
  3  select 3 id,'peter' name,null mgrid from dual union all
  4  select 4 id,'henry' name,1 mgrid from dual union all
  5  select 5 id,'nick' name,2 mgrid from dual union all
  6  select 6 id,'pao' name,3 mgrid from dual union all
  7  select 7 id,'kumar' name,3 mgrid from dual union all
  8  select 8 id,'parker' name,3 mgrid from dual union all
  9  select 9 id,'mike' name,5 mgrid from dual),
 10  secmain (id,name,mgrid,hierlevel) as
 11  (select id,name,mgrid,1 hierlevel from main
 12   where mgrid is null
 13   union all
 14   select m.id,m.name,m.mgrid,sm.hierlevel+1 from main m join secmain sm on(m.mgrid=sm.id))
 15  search depth first by name set seq
 16  cycle id set is_cycle to 1 default 0
 17  select lpad(' ',2*(hierlevel-1))||name name,hierlevel from secmain order by seq;

NAME        HIERLEVEL
---------- ----------
john                1
  henry             2
michael             1
  nick              2
    mike            3
peter               1
  kumar             2
  pao               2
  parker            2

9 rows selected.

SQL> 
```
Published by: Dom Brooks on November 23, 2011 13:52
Edited for the scope of the search and detection of cycle

Is the indicator parallel use / * + PARALLEL * / good or bad?
Hello

I am facing problem in the use of / * + PARALLEL * / hint in SQL Query took his time to run.

Parallel Hint degrades performance?

The FCT_TABLE Table is to have clause PARALLEL (DEGREE by DEFAULT DEFAULT INSTANCES).

We use the suspicion parallel as SELECT / * + PARALLEL (FCT_TABLE 2)

Any help will be necessary for me.

Thanks and greetings
Re: Using parallel Hint / * + PARALLEL * / good or bad?

Bad news. (in production systems)

Why? You, when you code this SQL statement with this point in development, have absolutely no idea of what the production will be like in a month. No idea what data will be. What another charging process will run. Or what will be the version of Oracle and hardware will look like.

Yet, by coding this suspicion in the production of SQL, you claim you know. And not only that, you claim that you are in a position higher than the CBO to make an informed decision on whether to run SQL in parallel. You declare that production DBA knows his work and how to improve performance, and you have decided for them that the SQL should be run in parallel.

Be very careful with advice in the code that lands in the production. Generally these efforts will simply cause more problems to solve problems.

So why the parallel indicator then exist if it is so "+ bad +"?

Very rarely (if ever) there are absolutes in software engineering. And there are exceptions where this indication can be extremely useful. But it's like a hammer in a Toolbox. You use it on the odd nail. You don't use every day to drive screws because the screwdriver is "+ hard +" to use.

P40-10 X Equuim: Reception of WLan is very good, but extremely slow

Hello

I just bought an Equuim P40 - when I connect to wireless broadband, the reception is very good but is extremely slow when it comes to load the pages of the internet - any suggestions on how to remedy this?
Thank you!

Hello

It's not easy to say why the notebook loads page s Web slowly.
For the most part, Web sites load slowly due to the amount of data.
If pages use flash animations or there is a big traffic on Web sites, the service could be overworked and loads of slower sites.

If the antivirus software is activated and control each transfer of data the sites could also loads slowly.

As you can see, several factors can affect the loading of the page!

AWR report cannot locate the bad SQLs
DB version: 11.2.0.2
Platform: Solaris 10

In our data base RAC 2 nodes, we have patterns of 20 applications. When an application is faced with performance problems, we try to generate AWR for the period in question. But the stats (like bad SQLs) for this scheme to be buried because there is another application SQLs performing even worse.

I know that we cannot create AWR report for specific patterns. But I wonder how his stats are collected in a multi-schema RAC environments that will differentiate between applications.
But the stats (like bad SQLs) for this scheme to be buried because there is another application SQLs performing even worse.

Since all applications run in a database and query of the other application run bad then they will be the first candidate of tunning since these are taking more resources and impact on other application requests.
You can also generate report of ASH for module specific or customer with assistance from under the option set in report of ash.

set target_module_name = ";
set target_action_name = ";
set target_client_id = ";

Even to explain the plan but bad cost
Hi all

When I run a 9i application response time is good and the plan is:

---------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 1. 18. 28175 |
| 1. GLOBAL TRI | 1. 18.
| 2. COUNTY STOPKEY |
| 3. FILTER |
| 4. TABLE ACCESS BY INDEX ROWID | TJTMVNTO | 4779 | 86022 | 28160 |
| 5. INDEX RANGE SCAN | ITJTMVNTO_2 | 191K | 1837 |
| 6. FILTER |
| 7. GROUP SORT BY | 1. 18. 15.
| 8. TABLE ACCESS BY INDEX ROWID | TJTVTMOV | 1. 18. 5.
| 9. INDEX RANGE SCAN | ITJTVTMOV_3 | 2 | | 4.
---------------------------------------------------------------------------------

But when I run the same query in 10g o get the same plan, but the cost is bad and query take too long:

--------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 1. 22. 197 M |
| 1. GLOBAL TRI | 1. 22.
|* 2 | COUNTY STOPKEY |
|* 3 | FILTER |
|* 4 | TABLE ACCESS BY INDEX ROWID | TJTMVNTO | 2044K | 42 M | 404K |
|* 5 | INDEX RANGE SCAN | ITJTMVNTO_2 | 2456K | 22882 |
|* 6 | FILTER |
| 7. HASH GROUP BY. 1. 22. 97.
|* 8 | TABLE ACCESS BY INDEX ROWID | TJTVTMOV | 1. 22. 5.
|* 9 | INDEX RANGE SCAN | ITJTVTMOV_3 | 2 | | 4.

The query is:

Select count (*)
of tjtmvnto one
where a.fliqmov > = to_date('20090322','YYYYMMDD')
and nfpa <>0
and cacepmov = '01'
and exists (select b.nmov
of tjtvtmov b
where b.nmov = a.nmov
and b.cprocvto = '00'
and b.numvto <>- 9
Group of b.nmov, b.numvto, b.fvtoamor
view count (*) > 1)

Thank you.
Use
```
/*+ NO_USE_HASH_AGGREGATION */
```
to disable the GROUP BY of HASH - this is the biggest contributor at the time of query response (and BTW, the only difference between 9i & 10g plans)

Update ISTAT menus mac is good or bad

ISTAT Menus Mac update is good or bad for your Mac Book Pro and IMac

I saw no complaint from any user iStat menus. It is one of the best available for a Mac commercial follow-up, so I would use it.

Ciao.

My internet speed is good, but the download of firefox is very slow. Why?

I have a WiFi internet connection shared with 54.0 Mbps speed. Internet high speed is good, but the installer of Firefox download Firefox at very slow speed. It takes about 10 to 15 minutes in the Firefox download. Please correct the problem if it occurs through your side, else do tell me what can I do to feel better. Thank you.

Full Setup (for Windows) can be found at mozilla.org -> systems & languages under the Green download button link.

Subquery Factoring - cardinality estimate good but bad sql response times

Similar Questions

Maybe you are looking for