Query Tuning Help please

Question

I ran the below query two times . first this query run within 4 minutes now it is running withing 20 minutes only . and how can I reduce the running time of this query.
my first table TABLE1 has partitioned day wise.
Total 14 partition in TABLE1 so if it runs for total 14 partitions it will take 14*20= 280 minutes.
Index created for TABLE1 and TABLE2
CREATE INDEX TABLE1_COL_A_INX ON TABLE1(COL_A);
CREATE INDEX TABLE1_COL_B_INX ON TABLE1(COL_B);
CREATE INDEX TABLE2_BNO_TYP_INX ON TABLE2(COL_B,RECORD_TYP);TABLE1 contain 3 billion records
TABLE2 contain 87 thousand records
INSERT INTO TARGET_TABLE
SELECT   t1.col_A,
                         t1.col_b,
                         t1.record_typ,
                         TO_date('14/06/2012','DD/MM/YYYY') ,
                         MIN( start_dt) AS First_Seen,
                         MAX( start_dt) AS Last_Seen
                FROM     TABLE1  t1,
                         TABLE2  t2
                WHERE    t1.start_dt = TO_date('14/06/2012','DD/MM/YYYY') - 12   
                         AND t1.col_b = t2.col_b
                         AND t1.record_typ = t2.record_typ                                                                                    
                GROUP BY t1.col_a,t1.col_b,t1.record_typ,TO_date('14/06/2012','DD/MM/YYYY') ;Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
Explain plan with statistics
SQL>
117794 rows selected.
Execution Plan
Plan hash value: 1844245574
| Id  | Operation                           | Name                    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT                    |                         |   147K|  7362K|       |   615K  (1)| 02:03:05 |       |       |
|   1 |  HASH GROUP BY                      |                         |   147K|  7362K|  9320K|   615K  (1)| 02:03:05 |       |       |
|   2 |   NESTED LOOPS                      |                         |       |       |       |         |             |       |       |
|   3 |    NESTED LOOPS                     |                         |   147K|  7362K|       |   613K  (1)| 02:02:43 |       |       |
|   4 |     TABLE ACCESS FULL               | TABEL2                  | 87586 |  1282K|       |   137   (1)| 00:00:02 |       |       |
|   5 |     PARTITION RANGE SINGLE          |                         |     3 |       |       |     3   (0)| 00:00:01 |     4 |     4 |
|*  6 |      INDEX RANGE SCAN               | TABLE1_COL_B_INX        |     3 |       |       |     3   (0)| 00:00:01 |     4 |     4 |
|*  7 |    TABLE ACCESS BY LOCAL INDEX ROWID| TABLE1                  |     2 |    72 |       |     7   (0)| 00:00:01 |     4 |     4 |
Predicate Information (identified by operation id):
   6 - access("T1"."COL_B"="T2"."COL_B")
   7 - filter("T1"."START_DT"=TO_DATE(' 2012-06-02 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "T1"."RECORD_TYP"="T2"."RECORD_TYP")
Statistics
        105  recursive calls
          0  db block gets
     640720  consistent gets
     363307  physical reads
     635656  redo size
    3896682  bytes sent via SQL*Net to client
      86718  bytes received via SQL*Net from client
       7854  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
     117794  rows processed
SQL>TKPROF
SELECT   t1.COL_A,
                         t1.COL_B,
                         t1.record_typ,
                         TO_date('14/06/2012','DD/MM/YYYY') ,
                         MIN(start_dt) AS First_Seen,
                         MAX(start_dt) AS Last_Seen
                FROM     TABLE1  t1,
                         TABLE2 t2
                WHERE    t1.start_dt = TO_date('14/06/2012','DD/MM/YYYY') - 12
                         AND
                         t1.COL_B = t2.COL_B
                         AND t1.record_typ = t2.record_typ
                GROUP BY t1.col_a,t1.col_b,t1.record_typ,TO_date('14/06/2012','DD/MM/YYYY')
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch     7853      0.15       0.28          0          0          0      117793
total     7853      0.15       0.28          0          0          0      117793
Misses in library cache during parse: 0
Parsing user id: 85  Which parameters or settings I want to check , because this query run before 4 minutes. now it takes 20 minutes... or in anyway I can rewrite this query using multiple staging table or something like that...

Answer 1

Hi,
1) you didn't trace the session correctly -- you probably switched tracing off before the session finished fetching all rows. Do it again, and this time end tracing by exiting the session (this way you make sure that the cursor is closed and plan stats are dumped to the trace file)
2) the plan seems to be sensible -- it costs you only 600k reads to retrieve 150k rows, that's good read-to-row ratio. You can improve it if you get read of TABLE ACCESS BY ROWID operation, but that would require creating an index on all the columns that the query needs (both in WHERE clause and in column projection) which looks like a big overhead (especially given that this is a table with 3 billion records)
3) autotrace stats seem to agree with the plan -- you're making 600k gets and half of them result in single-block disk reads. Assuming 5ms per read that's close to 20 min that you are getting. Of course, 50% buffer cache ratio is far from being perfect, and better caching is most likely the reason why the query was performing better in the past. Look at the the buffer hit ratio trend for the database -- perhaps some other activity is trashing the buffer cache, resulting in performance degradation of this query as well
Best regards,
Nikolay