I have a query (below). The explain plan shows high CPU utilization which has also caused downtime in our lab. So it possible to tube this query further? What should i do to tune it?
FYI, mtr_main_a, mtr_main_b, mtr_hist contain huge no of records may be 10 millions or more.
SELECT to_char(MAX(mdt), 'MM-DD-RRRR HH24:MI:SS')
FROM (
SELECT MAX(mod_date - 2 / 86400) mdt
FROM mtr_main_a
UNION
SELECT MAX(mod_date - 2 / 86400) mdt
FROM mtr_main_b
UNION
SELECT MAX(mod_date - 2 / 86400) mdt
FROM mtr_hist@batch_hist
)
/
Explain plan is as below
Execution Plan
----------------------------------------------------------
Plan hash value: 1573811822
-------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Inst |IN-OUT|
-------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 9 | | 79803 (1)| 00:18:38 | | |
| 1 | SORT AGGREGATE | | 1 | 9 | | | | | |
| 2 | VIEW | | 2 | 18 | | 79803 (1)| 00:18:38 | | |
| 3 | SORT UNIQUE | | 2 | 17 | 77M| 79803 (2)| 00:18:38 | | |
| 4 | UNION-ALL | | | | | | | | |
| 5 | SORT AGGREGATE | | 1 | 8 | | 79459 (1)| 00:18:33 | | |
| 6 | TABLE ACCESS FULL| MTR_MAIN_A | 5058K| 38M| | 67735 (1)| 00:15:49 | | |
| 7 | SORT AGGREGATE | | 1 | 9 | | 344 (1)| 00:00:05 | | |
| 8 | TABLE ACCESS FULL| MTR_MAIN_B | 1 | 9 | | 343 (1)| 00:00:05 | | |
| 9 | REMOTE | | | | | | | HISTB | R->S |
-------------------------------------------------------------------------------------------------------------
Remote SQL Information (identified by operation id):
----------------------------------------------------
9 - EXPLAIN PLAN SET STATEMENT_ID='PLUS10294704' INTO PLAN_TABLE@! FOR SELECT
MAX("A1"."MOD_DATE"-.00002314814814814814814814814814814814814815) FROM "MTR_HIST" "A1" (accessing
'HISTB' )
Thanks and Regards,
Chandra
You should be able to greatly improve the performance by putting an index on the
mod_datecolumns and changing your query in a way that does the subtraction at the end, after you determined the maximum date:This should get rid of the full table scans.