Query identified as OracleOEM reporting a lot of CPU wait time

Question

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

Answer 1

A typical question for this forum.
We use Oracle, we can't remember which version, and we can't be bothered to post it.
We don't know Oracle, so we use a third party product (Ignite from Confio) to perform redundant monitoring on our databases, which is already being performed by Oracle Enterprise Manager, for free.
Instead of trying to use the products which come with Oracle, we would like to wreck functionality, by tampering with things like frequency, and/or even adjusting Oracle provided queries, consequently invalidating our support contract for Oracle.
And, no, we are not aware, provided the database is doing nothing, queries like this one will automatically surface in the list of top <n> queries.
I would suggest you start to learn Oracle and dump Ignite. It is of no use to monitor your database with two tools, and OEM is fully integrated in Oracle.
Sybrand Bakker
Senior Oracle DBA