Issue with sql performance

Question

Hi, I am experiencing an issue with a couple of sql statements.   The rest of the db seems to be performing optimally.
A little history:  Stats typically were never touched on this db and they were old (I mean very very old).  However, the database performance was optimal.  Recently we ran into an issue (turned out to be hardware), but in the troubleshooting, we deleted the old statistics and refreshed the stats across the board. 
Prior to this incident, these queries would finish in mere minutes.
Performance for a few queries is sub optimal now.
When I execute this query it is performing ok returning a values in just over a minute.
select MAX(fr.fee_rqst_sid)
      from fee_rqst fr
      where fr.prcd_dt <=  to_date('15/10/2013', 'DD/MM/RRRR');
Elapsed: 00:01:10.17
Plan hash value: 3146244357
| Id  | Operation          | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |          |     1 |    23 |   404K  (2)| 01:20:49 |
|   1 |  SORT AGGREGATE    |          |     1 |    23 |            |          |
|*  2 |   TABLE ACCESS FULL| FEE_RQST |   148M|  3262M|   404K  (2)| 01:20:49 |
When it is executed as part of the slightly larger query it belongs to performance drops to over 40 minutes.
    select MAX(ch.clm_hdr_sid)
    from clm_hdr ch
    where ch.fee_rqst_sid <= (
      select MAX(fr.fee_rqst_sid)
      from fee_rqst fr
      where fr.prcd_dt <=  to_date('15/10/2013', 'DD/MM/RRRR'));
PLAN_TABLE_OUTPUT
Plan hash value: 2801176651
| Id  | Operation                    | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |            |     1 |    12 |   718K  (1)| 02:23:41 |
|   1 |  SORT AGGREGATE              |            |     1 |    12 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| CLM_HDR    |  9410K|   107M|   718K  (1)| 02:23:41 |
|*  3 |    INDEX RANGE SCAN          | IDX$_00002 |  1879K|       |  8533   (1)| 00:01:43 |
|   4 |     SORT AGGREGATE           |            |     1 |    23 |            |          |
|*  5 |      TABLE ACCESS FULL       | FEE_RQST   |   148M|  3262M|   404K  (2)| 01:20:49 |
I've create/dropped an index on the date column figuring it might help but it did not as a full table scan still occurred.
The primary key indexes have up to date stats and are not corrupted  indexes.
Again this is production and the rest of the db is running optimally and this db is used heavily.
I did run a sqltune but no new results yielded.
GENERAL INFORMATION SECTION
Tuning Task Name   : sql_tuning_task1
Tuning Task Owner  : SYS
Workload Type      : Single SQL Statement
Scope              : COMPREHENSIVE
Time Limit(seconds): 60
Completion Status  : COMPLETED
Started at         : 04/21/2015 16:23:18
Completed at       : 04/21/2015 16:24:15
Schema Name: SYS
SQL ID     : g52fuy8db7qgb
SQL Text   : select MAX(ch.clm_hdr_sid)
                 from npf.clm_hdr ch
                 where ch.fee_rqst_sid <= (
                   select MAX(fr.fee_rqst_sid)
                   from npf.fee_rqst fr
                   where fr.prcd_dt <=  to_date('15/10/2013', 'DD/MM/RRRR'))
There are no recommendations to improve the statement.
Any advice on what else I can check?

Answer 1

Before asking this question, next time you would need to ask this forum to clean their crystal balls.
Your many many lines boil down to:
My car doesn't run, please fix my car, as there is insufficient INFORMATION to work on, and plenty of RIDDLES
1 Your database doesn't seem to have a four digit version
2 Your database doesn't seem to run on an OS
3 The statistics where 'refreshed across the board'. How that happened, this forum needs to guess.
4 Which indices are present on this table, this forum needs to guess
5 Which part of the table satisifies the where clause, this forum needs to guess.
So the obvious would be to answer all of these questions AND run the statement with event 10053 set, so the optimizer decisions are dumped to a trace file,
See https://asktom.oracle.com/pls/asktom/f?p=100:11:0%3A%3A%3A%3AP11_QUESTION_ID:63445044804318
And lastly, I find it more and more annoying, many people don't seem to a have a name, and post 100 percent anonymously.
Sybrand Bakker
Senior Oracle DBA