Partition Pruning Aint Happening

Question

I have a situation where Oracle pruning is not happening and this situation is getting worse when the search criteria is close to current date.
Table has a date based partition. SQL Statement has 2 partitioned tables. Date range is applied on a relatively smaller daily partitioned table and further joined to the next table (Its also date based partition). First table has partition column in the where clause and it joins to the next table using the partitioned column.
SQL does partition pruning even for a month range search if the date range is in August. It will do partition pruning only for 25 days for september where clause. Likewise the where clause date range ability for partition pruning goes down and It will only do partition pruning for where clause with 5 days. If the where clause has more than 6 days (Mar 01 Thru Mar 06) in March 2009, Oracle does All partitions.
Query is examined and it contains partition column in the where clause and we have also gathered 100% statistics of the table which is not partition pruning. Data growth is happening relatively each month.
Sample: -
Select 1
From TAB1, TAB2
Where TAB1.SELECT_DATE >= '01JAN2009
And TAB1.SELECT_DATE <= '31JAN2009
And TAB2.DATE_SELECT = TAB1.DATE_SELECT
TAB1 Is a daily partition with SELECT_DATE column. Oracle is able to successfully do partition pruning on this table. But TAB2 partition pruning is not happening.
How I can overcome this situation? Thanks for your help.
Here is the explain plan for the SQL statement

Answer 1

| Id  | Operation                            | Name         | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT                     |              |  1224 | 96696 |       |   978K  (4)| 01:21:35 |       |       |
|   1 |  HASH GROUP BY                       |              |  1224 | 96696 |       |   978K  (4)| 01:21:35 |       |       |
|*  2 |   HASH JOIN                          |              |  1122K|    84M|    49M|   978K  (4)| 01:21:34 |       |       |
|*  3 |    HASH JOIN                         |              |  1122K|    36M|       |  5218   (4)| 00:00:27 |       |       |
|   4 |     COLLECTION ITERATOR PICKLER FETCH| TABLE FUNC   |       |       |       |            |          |       |       |
|   5 |     PARTITION RANGE ITERATOR         |              |   729K|    22M|       |  5145   (3)| 00:00:26 |   413 |   422 |
|   6 |      PARTITION LIST ALL              |              |   729K|    22M|       |  5145   (3)| 00:00:26 |     1 |     2 |
|*  7 |       MAT_VIEW ACCESS FULL           | TAB_01       |   729K|    22M|       |  5145   (3)| 00:00:26 |   825 |   844 |
|   8 |    PARTITION RANGE ALL               |              |    84M|  3623M|       |   575K  (5)| 00:47:59 |     1 |   970 |
|   9 |     TABLE ACCESS FULL                | TAB_02       |    84M|  3623M|       |   575K  (5)| 00:47:59 |     1 |   970 |
Predicate Information (identified by operation id):
   2 - access("TAB_02"."SELECT_DATE"="TAB_01"."SELECT_DATE" AND "TAB_02"."SELECT_NUMBER"="TAB_01"."SELECT_NUMBER")
   3 - access("TAB_01"."TAG_ID"=SYS_OP_ATG(VALUE(KOKBF$),16,17,2))
   7 - filter("TAB_01"."SELECT_DATE"<=TO_DATE('2009-02-10 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))Following is the explain paln where partition elimination happening for a shorter date range search
| Id  | Operation                            | Name         | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT                     |              |   714 | 56406 |   851K  (1)| 01:10:56 |       |       |
|   1 |  HASH GROUP BY                       |              |   714 | 56406 |   851K  (1)| 01:10:56 |       |       |
|   2 |   NESTED LOOPS                       |              |   621K|    46M|   850K  (1)| 01:10:55 |       |       |
|*  3 |    HASH JOIN                         |              |   621K|    20M|  3210   (3)| 00:00:17 |       |       |
|   4 |     COLLECTION ITERATOR PICKLER FETCH| TABLE FUNC   |       |       |            |          |       |       |
|   5 |     PARTITION RANGE ITERATOR         |              |   403K|    12M|  3152   (3)| 00:00:16 |   413 |   418 |
|   6 |      PARTITION LIST ALL              |              |   403K|    12M|  3152   (3)| 00:00:16 |     1 |     2 |
|*  7 |       MAT_VIEW ACCESS FULL           | TAB_01       |   403K|    12M|  3152   (3)| 00:00:16 |   825 |   836 |
|   8 |    PARTITION RANGE ITERATOR          |              |     1 |    45 |     2   (0)| 00:00:01 |   KEY |   KEY |
|   9 |     TABLE ACCESS BY LOCAL INDEX ROWID| TAB_02       |     1 |    45 |     2   (0)| 00:00:01 |   KEY |   KEY |
|* 10 |      INDEX RANGE SCAN                | TAB_02_PK    |     1 |       |     1   (0)| 00:00:01 |   KEY |   KEY |
Predicate Information (identified by operation id):
   3 - access("TAB_01"."TAG_ID"=SYS_OP_ATG(VALUE(KOKBF$),16,17,2))
   7 - filter("TAB_01"."SELECT_DATE"<=TO_DATE('2009-02-06 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
  10 - access("TAB_02"."SELECT_DATE"="TAB_01"."SELECT_DATE" AND "TAB_02"."SELECT_NUMBER"="TAB_01"."SELECT_NUMBER")Query where partition elimination not happening on the second table is having date range of 7 days or more. SO the first explain plan is for Feb-01 Thru Feb 10 search
Query where partition elimination happening on the second table is having date range of 7 days or less. The second explain plan is for Feb-01 Thru Feb-06 search
This is great.
Edited by: user10929035 on Mar 24, 2009 8:18 AM