Query identified as OracleOEM reporting a lot of CPU wait time
625772Dec 22 2009 — edited Dec 22 2009We use "Ignite" by Confio to monitor the wait time on our database and I have been watching a query for a while now and it seems to be consuming a lot of resources for what it is doing.
This is the query:
/* OracleOEM */
SELECT m.tablespace_name,
m.used_percent,
(m.tablespace_size - m.used_space)*t.block_size/1024/1024 mb_free
FROM dba_tablespace_usage_metrics m,
dba_tablespaces t,
v$parameter p
WHERE p.name='statistics_level'
AND p.value!='BASIC'
AND t.tablespace_name = m.tablespace_name
And this is the execution plan:
SELECT STATEMENT Optimizer=ALL_ROWS (Cost=152 Cardinality=17 Bytes=2193)
NESTED LOOPS (Cost=152 Cardinality=17 Bytes=2193)
NESTED LOOPS (Cost=152 Cardinality=17 Bytes=2125)
MERGE JOIN (CARTESIAN) (Cost=149 Cardinality=17 Bytes=1785)
HASH JOIN (Cost=2 Cardinality=1 Bytes=49)
FIXED TABLE (FULL) OF X$KSPPI (TABLE (FIXED)) (Cost=1 Cardinality=1 Bytes=31)
FIXED TABLE (FULL) OF X$KSPPCV (TABLE (FIXED)) (Cost=1 Cardinality=1897 Bytes=34146)
BUFFER (SORT) (Cost=148 Cardinality=502 Bytes=28112)
VIEW OF DBA_TABLESPACE_USAGE_METRICS (VIEW) (Cost=147 Cardinality=502 Bytes=28112)
SORT (UNIQUE) (Cost=147 Cardinality=502 Bytes=19122)
UNION-ALL
SORT (AGGREGATE) (Cardinality=1 Bytes=8)
TABLE ACCESS (BY INDEX ROWID) OF RECYCLEBIN$ (TABLE) (Cost=4 Cardinality=389 Bytes=3112)
INDEX (RANGE SCAN) OF RECYCLEBIN$_TS (INDEX) (Cost=1 Cardinality=388)
SORT (AGGREGATE) (Cardinality=1 Bytes=14)
FIXED TABLE (FULL) OF X$KTFBHC (TABLE (FIXED)) (Cost=0 Cardinality=1 Bytes=14)
SORT (AGGREGATE) (Cardinality=1 Bytes=8)
TABLE ACCESS (BY INDEX ROWID) OF RECYCLEBIN$ (TABLE) (Cost=4 Cardinality=389 Bytes=3112)
INDEX (RANGE SCAN) OF RECYCLEBIN$_TS (INDEX) (Cost=1 Cardinality=388)
SORT (AGGREGATE) (Cardinality=1 Bytes=14)
FIXED TABLE (FULL) OF X$KTFBHC (TABLE (FIXED)) (Cost=0 Cardinality=1 Bytes=14)
HASH (GROUP BY) (Cost=89 Cardinality=500 Bytes=19000)
MERGE JOIN (Cost=87 Cardinality=500 Bytes=19000)
TABLE ACCESS (CLUSTER) OF TS$ (CLUSTER) (Cost=86 Cardinality=426 Bytes=9372)
INDEX (FULL SCAN) OF I_TS# (INDEX (CLUSTER)) (Cost=1 Cardinality=1)
SORT (JOIN) (Cost=1 Cardinality=501 Bytes=8016)
FIXED TABLE (FULL) OF X$KTTEFINFO (TABLE (FIXED)) (Cost=0 Cardinality=501 Bytes=8016)
HASH (GROUP BY) (Cost=52 Cardinality=1 Bytes=38)
NESTED LOOPS (Cost=50 Cardinality=1 Bytes=38)
FIXED TABLE (FULL) OF X$KTTEFINFO (TABLE (FIXED)) (Cost=0 Cardinality=251 Bytes=4769)
TABLE ACCESS (CLUSTER) OF TS$ (CLUSTER) (Cost=1 Cardinality=1 Bytes=19)
INDEX (UNIQUE SCAN) OF I_TS# (INDEX (CLUSTER)) (Cost=1 Cardinality=1)
HASH (GROUP BY) (Cost=5 Cardinality=1 Bytes=84)
HASH JOIN (Cost=3 Cardinality=1 Bytes=84)
NESTED LOOPS
NESTED LOOPS (Cost=3 Cardinality=1 Bytes=65)
HASH JOIN (Cost=2 Cardinality=1 Bytes=49)
FIXED TABLE (FULL) OF X$KSPPI (TABLE (FIXED)) (Cost=1 Cardinality=1 Bytes=31)
FIXED TABLE (FULL) OF X$KSPPCV (TABLE (FIXED)) (Cost=1 Cardinality=1899 Bytes=34182)
INDEX (UNIQUE SCAN) OF I_TS1 (INDEX (UNIQUE)) (Cost=1 Cardinality=1)
TABLE ACCESS (BY INDEX ROWID) OF TS$ (CLUSTER) (Cost=1 Cardinality=1 Bytes=16)
FIXED TABLE (FULL) OF X$KTTEFINFO (TABLE (FIXED)) (Cost=0 Cardinality=251 Bytes=4769)
TABLE ACCESS (BY INDEX ROWID) OF TS$ (CLUSTER) (Cost=1 Cardinality=1 Bytes=20)
INDEX (UNIQUE SCAN) OF I_TS1 (INDEX (UNIQUE)) (Cost=1 Cardinality=1)
FIXED TABLE (FIXED INDEX) OF X$KCFISTSA (ind:1) (TABLE (FIXED)) (Cost=0 Cardinality=1 Bytes=4)
My question is two fold... does anybody know where in OEM you can control the execution of this query? I would like to reduce the frequency it is run, or if that is not a good idea does anybody have any ideas from a tuning perspective?
Ignite is reporting 1,440 executions, 621,776,455 buffer gets, and 2 hours of CPU wait time per day.
Thanks in advance,
Zack