Skip to Main Content
Forums

SQL & PL/SQL

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Finding Min and Max date

RamiahRAGUJul 29 2010 — edited Aug 6 2010
SELECT * FROM (
SELECT 'STOR_A' STORE_NAME ,'BX1' BOX_NO, 'X11' LOC, '01-JAN-2010' MOVE_DT FROM DUAL UNION ALL 
SELECT 'STOR_A'  ,'BX1' , 'X21' , '03-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_A'  ,'BX1' , 'X13' , '05-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_A'  ,'BX1' , 'X41' , '07-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_A'  ,'BX1' , 'X15' , '09-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_A'  ,'BX2' , 'X31' , '02-JAN-2010'  FROM DUAL UNION ALL 
SELECT 'STOR_A'  ,'BX2' , 'X71' , '04-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_A'  ,'BX2' , 'X18' , '06-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_A'  ,'BX3' , 'X91' , '04-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_A'  ,'BX3' , 'X10' , '05-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_A'  ,'BX3' , 'X14' , '07-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_A'  ,'BX3' , 'X51' , '10-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_A'  ,'BX3' , 'X16' , '12-JAN-2010'  FROM DUAL UNION ALL  
SELECT 'STOR_B'  ,'BX2' , 'X41' , '09-JAN-2010'  FROM DUAL UNION ALL 
SELECT 'STOR_B'  ,'BX2' , 'X74' , '11-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_B'  ,'BX2' , 'X31' , '12-JAN-2010'  FROM DUAL UNION ALL
SELECT 'STOR_B'  ,'BX2' , 'X68' , '17-JAN-2010'  FROM DUAL 

);
[pre/]



I have the data of the Boxes which came to the store and changed the locations on a date.
how can i select in a single row the as below. Boxwise the date and location on which received in and sent out

[pre]

BOX_NO	STORE_NAME	IN_LOC	    	IN_DATE		OUT_LOC	OUT_DATE
--------------------------------------------------------------------------
BX1	STOR_A		X11		01-Jan-10	X15	09-Jan-10
BX2	STOR_A		X31		02-Jan-10	X18	06-Jan-10
BX3	STOR_A		X91		04-Jan-10	X16	12-Jan-10
BX2     STOR_B          X41		09-Jan-10	X68	17-Jan-10

[pre/]

Can someone helpout from the query

Comments

933257 wrote:
Hi we are using version 11.2.0.4 of Oracle Exadata. Below query is running for ~7-8 minutes. And the way this query is written here such that , table CNTRL_TAB is a just a control table so there is no join between the main table- TAB1 and this control table. And TAB1 is list partitioned on column DATE_KEY. And index TAB1_PK is composite index on (FCT_KEY,DATE_KEY).
And i saw the execution path , its going for a "INDEX STORAGE FAST FULL SCAN" path by default. but i see we are only picking up the MAX value of a column which is leading column of an unique index. Now when i tried putting hint INDEX(TAB1 TAB1_PK), it went for "INDEX FULL SCAN (MIN/MAX)" and finished in seconds. So wanted to understand why by default optimizer is not following the MIN/MAX optimization? From the plan it shows the expected costing of "INDEX FULL SCAN (MIN/MAX)" coming as ~27million as compared to the cost of "INDEX STORAGE FAST FULL SCAN" in the default path which is ~7million for same ~8billion rows estimated in both of the cases. But in case of INDEX FULL SCAN (MIN/MAX) the number of actual rows coming as ~496.
Another way i tried tweaking the query, using exists operator then i see its following MIN/MAX optimization an finishing i seconds. Why its not following that path by default?
Also the surprising part is even by default its using the same index but to be exact its doing "INDEX STORAGE FAST FULL SCAN". So how-come if i hint the query using same index(means i have not supplied any additional input/influencer to the query) its opting "INDEX FULL SCAN (MIN/MAX)"?
Default execution path:-
  1. SQLText
  2. ------------------------------
  3. SELECTMAX(TAB1.FCT_KEY)ASMX_VALFROMTAB1,
  4. CNTRL_TABWHERECNTRL_TAB.CNTRL_ID=111ANDCNTRL_TAB.STATUSISNOTNULL
  6. GlobalInformation
  7. ------------------------------
  8. Status:DONE(ALLROWS)
  9. InstanceID:3
  10. SQLID:2y1x33t9vf9xx
  11. SQLExecutionID:50331648
  12. ExecutionStarted:07/09/202009:08:48
  13. FirstRefreshTime:07/09/202009:08:52
  14. LastRefreshTime:07/09/202009:16:38
  15. Duration:470s
  16. Module/Action:SQL*Plus/-
  17. Program:sqlplus.exe
  18. FetchCalls:1
  20. GlobalStats
  21. ==============================================================================================================
  22. |Elapsed|Cpu|IO|Application|Cluster|Other|Fetch|Buffer|Read|Read|Cell|
  23. |Time(s)|Time(s)|Waits(s)|Waits(s)|Waits(s)|Waits(s)|Calls|Gets|Reqs|Bytes|Offload|
  24. ==============================================================================================================
  25. |470|446|15|0.34|0.10|10|1|32M|514K|245GB|27.54%|
  26. ==============================================================================================================
  28. SQLPlanMonitoringDetails(PlanHashValue=3656453152)
  29. =================================================================================================================================================================================================================
  30. |Id|Operation|Name|Rows|Cost|Time|Start|Execs|Rows|Read|Read|Cell|Mem|Activity|ActivityDetail|
  31. ||||(Estim)||Active(s)|Active||(Actual)|Reqs|Bytes|Offload|(Max)|(%)|(#samples)|
  32. =================================================================================================================================================================================================================
  33. |0|SELECTSTATEMENT||||467|+4|1|1|||||||
  34. |1|SORTAGGREGATE||1||468|+3|1|1|||||40.21|Cpu(189)|
  35. |2|NESTEDLOOPS||8G|7M|407|+4|1|4G|||||||
  36. |3|TABLEACCESSBYINDEXROWID|CNTRL_TAB|1|1|1|+4|1|1|||||||
  37. |4|INDEXUNIQUESCAN|CONTROLTAB_PK|1||467|+4|1|1|||||||
  38. |5|PARTITIONLISTALL||8G|7M|407|+4|1|4G|||||||
  39. |6|INDEXSTORAGEFASTFULLSCAN|TAB1_PK|8G|7M|471|+1|579|4G|510K|244GB|27.54%|15M|59.79|Cpu(262)|
  40. |||||||||||||||reliablemessage(9)|
  41. |||||||||||||||cellsingleblockphysicalread(1)|
  42. |||||||||||||||cellsmartindexscan(9)|
  43. =================================================================================================================================================================================================================
  45. PredicateInformation(identifiedbyoperationid):
  46. ---------------------------------------------------
  48. 3-filter("CNTRL_TAB"."STATUS"ISNOTNULL)
  49. 4-access("CNTRL_TAB"."CNTRL_ID"=111)
With hints:-
  1. SQLText
  2. ------------------------------
  3. SELECT/*+INDEX(TAB1TAB1_PK)*/MAX(TAB1.FCT_KEY)ASMX_VALFROMTAB1,CNTRL_TABWHERECNTRL_TAB.CNTRL_ID=111ANDCNTRL_TAB.STATUSISNOTNULL
  5. GlobalInformation
  6. ------------------------------
  7. Status:DONE(ALLROWS)
  8. InstanceID:3
  9. SQLID:5xrjk1zynqyt8
  10. SQLExecutionID:50331648
  11. ExecutionStarted:07/09/202009:19:39
  12. FirstRefreshTime:07/09/202009:19:39
  13. LastRefreshTime:07/09/202009:19:39
  14. Duration:.002947s
  15. Module/Action:SQL*Plus/-
  16. Program:sqlplus.exe
  17. FetchCalls:1
  19. GlobalStats
  20. ======================================
  21. |Elapsed|Cpu|Fetch|Buffer|
  22. |Time(s)|Time(s)|Calls|Gets|
  23. ======================================
  24. |0.00|0.00|1|1615|
  25. ======================================
  27. SQLPlanMonitoringDetails(PlanHashValue=2283604281)
  28. ==========================================================================================================================================================
  29. |Id|Operation|Name|Rows|Cost|Time|Start|Execs|Rows|Activity|ActivityDetail|
  30. ||||(Estim)||Active(s)|Active||(Actual)|(%)|(#samples)|
  31. ==========================================================================================================================================================
  32. |0|SELECTSTATEMENT||||1|+0|1|1|||
  33. |1|SORTAGGREGATE||1||1|+0|1|1|||
  34. |2|NESTEDLOOPS||8G|27M|1|+0|1|496|||
  35. |3|TABLEACCESSBYINDEXROWID|CNTRL_TAB|1|1|1|+0|1|1|||
  36. |4|INDEXUNIQUESCAN|CONTROLTAB_PK|1||1|+0|1|1|||
  37. |5|PARTITIONLISTALL||8G|27M|1|+0|1|496|||
  38. |6|FIRSTROW||8G|27M|1|+0|579|496|||
  39. |7|INDEXFULLSCAN(MIN/MAX)|TAB1_PK|8G|27M|1|+0|579|496|||
  40. ==========================================================================================================================================================
  42. PredicateInformation(identifiedbyoperationid):
  43. ---------------------------------------------------
  45. 3-filter("CNTRL_TAB"."STATUS"ISNOTNULL)
  46. 4-access("CNTRL_TAB"."CNTRL_ID"=111)
********************* Tweaking the query using Exists Operator*********
  1. SELECTMAX(TAB1.FCT_KEY)ASMX_VAL
  2. FROMTAB1
  3. whereexists(select1fromCNTRL_TAB
  4. WHERECNTRL_TAB.CNTRL_ID=111
  5. ANDCNTRL_TAB.STATUSISNOTNULL)
  7. ExecutionPlan
  8. ----------------------------------------------------------
  9. Planhashvalue:2799955177
  11. ---------------------------------------------------------------------------------------------------------------------------
  12. |Id|Operation|Name|Rows|Bytes|Cost(%CPU)|Time|Pstart|Pstop|
  13. ---------------------------------------------------------------------------------------------------------------------------
  14. |0|SELECTSTATEMENT||1|8|1160(0)|00:00:14|||
  15. |1|SORTAGGREGATE||1|8|||||
  16. |*2|FILTER||||||||
  17. |3|PARTITIONLISTALL||1|8|1159(0)|00:00:14|579|1|
  18. |4|FIRSTROW||1|8|1159(0)|00:00:14|||
  19. |5|INDEXFULLSCAN(MIN/MAX)|TAB1_PK|1|8|1159(0)|00:00:14|579|1|
  20. |*6|TABLEACCESSBYINDEXROWID|CNTRL_TAB|1|6|1(0)|00:00:01|||
  21. |*7|INDEXUNIQUESCAN|CONTROLTAB_PK|1||0(0)|00:00:01|||
  22. ---------------------------------------------------------------------------------------------------------------------------
  24. PredicateInformation(identifiedbyoperationid):
  25. ---------------------------------------------------
  27. 2-filter(EXISTS(SELECT0FROM"USER1"."CNTRL_TAB""CNTRL_TAB"WHERE
  28. "CNTRL_TAB"."CNTRL_ID"=111AND"CNTRL_TAB"."STATUS"ISNOTNULL))
  29. 6-filter("CNTRL_TAB"."STATUS"ISNOTNULL)
  30. 7-access("CNTRL_TAB"."CNTRL_ID"=111)

933257,  I think, the cost-based optimizer is incorrectly calculating the cost of the index with statistics.  You can gather a 10053 trace file before and after adding a hint that shows the cost of the index. Also, you can check the following:

1- Are the table and index stats up to date?

2- Has anyone changed system settings parameters?

3- Are there SQL profiles or plan baselines for this query?

Cheers,

Arsalan

User_OCZ1T

No Baseline/profile in place for this query. optimizer parameters are all default.  I am not able to convinced if its simply  because of because of stats. Also will try to regather stats but if i see the global stats i see the number of rows in table is ~8billion and same is being noted in global stats for the index i.e in dba_indexes in column num_distinct and num_rows as its a primary key.  And as i mentioned there are multiple oddities i see in the plan and just wanted to ensure if we are not hitting any special condition

1) by simple modifying the query using Exists operator making it go for the MIN/MAX optimization by default.

2)If i see the existing query path its estimating 8billion rows for the INDEX STORAGE FAST FULL SCAN but the cost is coming as 7Million whereas during forced index path the estimation is same 8billion but the cost becomes ~27million. Why?

3) And also when i am using same index hints, why the optimizer changes the path to min/max optimization which its not doing by default with same index scan?

2)If i see the existing query path its estimating 8billion rows for the INDEX STORAGE FAST FULL SCAN but the cost is coming as 7Million whereas during forced index path the estimation is same 8billion but the cost becomes ~27million. Why?

I think it's more like a bug. Bug because CBO has computed it wrongly that INDEX STORAGE FAST FULL SCAN is good so SQL query choosing the Index storage Fast Full Scan and causing the bad plan. You can check it when the stats are deleted on the table, whether Index Full (Min/Max) will be selected or not.

We also need more analysis from 10053 For both good and bad plans.

Regards

Arsalan

Jonathan Lewis
Answer

It's a bug in the optimizer - easy to demonstrate - revolving around table joins breaking the index(min/max) costing.  From an SQL*Plus session Oracle 12.2.0.1:

SQL> create table t1 as select * from all_objects where rownum <= 50000;

Table created.

SQL> create index t1_i1 on t1(object_name);

Index created.

SQL> set autotrace traceonly explain

SQL> select max(object_name) from t1;

Execution Plan

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

Plan hash value: 1743745495

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

| Id  | Operation                  | Name  | Rows  | Bytes | Cost  |

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

|  0  | SELECT STATEMENT           |      |    1 |    39 |    3 |

|  1  |  SORT AGGREGATE            |      |    1 |    39 |      |

|  2  |   INDEX FULL SCAN (MIN/MAX)| T1_I1 |    1 |    39 |    3 |

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

SQL> select max(object_name) from t1, dual where dummy is not null;

Execution Plan

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

Plan hash value: 805254539

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

| Id  | Operation              | Name  | Rows  | Bytes | Cost  |

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

|  0  | SELECT STATEMENT       |      |    1 |    41 |    56 |

|  1  |  SORT AGGREGATE        |      |    1 |    41 |      |

|  2  |   NESTED LOOPS         |      | 50000 |  2001K|    56 |

|* 3  |    TABLE ACCESS FULL   | DUAL  |    1 |    2 |    2 |

|  4  |    INDEX FAST FULL SCAN| T1_I1 | 50000 |  1904K|    54 |

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

Predicate Information (identified by operation id):

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

  3 - filter("DUMMY" IS NOT NULL)

SQL> select /*+ index(t1) */  max(object_name) from t1, dual where dummy is not null;

Execution Plan

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

Plan hash value: 3144875158

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

| Id  | Operation                    | Name  | Rows  | Bytes | Cost  |

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

|  0  | SELECT STATEMENT             |      |    1 |    41 |  351 |

|  1  |  SORT AGGREGATE              |      |    1 |    41 |      |

|  2  |   NESTED LOOPS               |      | 50000 |  2001K|  351 |

|*  3 |    TABLE ACCESS FULL         | DUAL  |    1 |    2 |    2 |

|  4  |    FIRST ROW                 |      | 50000 |  1904K|  349 |

|  5  |     INDEX FULL SCAN (MIN/MAX)| T1_I1 | 50000 |  1904K|  349 |

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

Predicate Information (identified by operation id):

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

  3 - filter("DUMMY" IS NOT NULL)

SQL> select max(object_name) from t1 where exists (select null from dual where dummy is not null);

Execution Plan

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

Plan hash value: 4251389670

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

| Id  | Operation                    | Name  | Rows  | Bytes | Cost  |

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

|  0  | SELECT STATEMENT             |      |    1 |    39 |    5 |

|  1  |  SORT AGGREGATE              |      |    1 |    39 |      |

|* 2  |   FILTER                     |      |      |      |      |

|  3  |    FIRST ROW                 |      |    1 |    39 |    3 |

|  4  |     INDEX FULL SCAN (MIN/MAX)| T1_I1 |    1 |    39 |    3 |

|* 5  |    TABLE ACCESS FULL         | DUAL  |    1 |    2 |    2 |

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

Predicate Information (identified by operation id):

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

  2 - filter( EXISTS (SELECT 0 FROM "SYS"."DUAL" "DUAL" WHERE "DUMMY"

              IS NOT NULL))

  5 - filter("DUMMY" IS NOT NULL)

A couple of points:  the index() hint is synonymous with the index_rs() hint (index range scan) which is probably why it blocked the index fast full scan (index_ffs() hint).

The "where exists" is a plan with two query blocks and the existence test is not correlated so

(a) the max(object_name) query block is optimised separately from the (select from dual) query block, and gets the right plan

(b) the select from dual actually executes BEFORE the select from t1.

Regards

Jonathan Lewis

Marked as Answer by User_OCZ1T · Sep 27 2020
User_OCZ1T

Thank you so much. You explained it so nicely with example, i got all my doubt cleared around the optimizer behavior along with buggy costing part.

1 - 5
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Sep 3 2010
Added on Jul 29 2010
8 comments
1,740 views