The problem solved..... The cursor_sharing is made to force... This reduced the IO very much. Now IO is normal in all instance. Then we created two indexes for the same query which recommended by sqltuning advisor and accepted the profile
2- SQL Profile Finding (see explain plans section below) -------------------------------------------------------- A potentially better execution plan was found for this statement.
Recommendation (estimated benefit: 80.44%)
Consider accepting the recommended SQL profile. execute dbms_sqltune.accept_sql_profile(task_name => 'my_sqltune_task1', task_owner => 'IMUSE01', replace => TRUE);
Validation results ------------------ The SQL profile was tested by executing both its plan and the original plan and measuring their respective execution statistics. A plan may have been only partially executed if the other could be run to completion in less time.
Original Plan With SQL Profile % Improved ------------- ---------------- ---------- Completion Status: PARTIAL COMPLETE Elapsed
Time(ms): 31479 8049 74.43% CPU Time(ms): 5172 1656 67.98%
User I/O Time(ms): 16367 3422 79.09%
Buffer Gets: 265365 51818 80.47%
Disk Reads: 3227 524 83.76%
Direct Writes: 0 0 Rows Processed: 0 20000 Fetches:
0 20000 Executions: 0
13- Index Finding (see explain plans section below) -------------------------------------------------- The execution plan of this statement can be improved by creating one or more
indices.Recommendation (estimated benefit: 81.1%)
Consider running the Access Advisor to improve the physical schema design or creating the recommended index. create index IMUSE01.IDX$$_67E5B0001 on IMUSE01.SUBSCRIBEINFO("STATE","SUBFLAG","MONTHBILLID","RETRYENDDATETIME");
Consider running the Access Advisor to improve the physical schema design or creating the recommended index. create index IMUSE01.IDX$$_67E5B0002 on IMUSE01.SUBSCRIBEINFO("STATE","MONTHBILLID","FAILTIMESTAMP");
Rationale --------- Creating the recommended indices significantly improves the execution plan of this statement. However, it might be preferable to run "Access Advisor" using a representative SQL workload as opposed to a single statement. This will allow to get comprehensive index recommendations which takes into account index maintenance overhead and additional space consumption.
4- Restructure SQL finding (see plan 1 in explain plans section) ---------------------------------------------------------------- Predicate "O"."NEXTCHARGETIME"<>:B1 used at line ID 5 of the execution plan is an inequality condition on indexed column "NEXTCHARGETIME". This inequality condition prevents the optimizer from efficiently using indices on table "IMUSE01"."SUBSCRIBEINFO".
Recommendation -------------- - Rewrite the predicate into an equivalent form to take advantage of indices.
Rationale --------- The optimizer is unable to use an index if the predicate is an inequality condition or if there is an expression or an implicit data type conversion on the indexed column.