Skip to Main Content

Oracle Database Discussions

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Query identified as OracleOEM reporting a lot of CPU wait time

625772Dec 22 2009 — edited Dec 22 2009
We 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
Comments
Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on Jan 19 2010
Added on Dec 22 2009
5 comments
869 views