High query execution time - sql

Question

SELECT T.xhrs, T.eq_id, mt.CATEGORY, mt.MODEL_NAME,
ROUND((SUM (T.TOT_AVAIL_TIME-T.maintenance_TIME) / SUM(T.TOT_AVAIL_TIME))*100) AVAILABILITY,
ROUND((SUM(UTIL_TIME) / nullif(SUM(T.TOT_AVAIL_TIME-T.maintenance_TIME ),0) )*100) UTILIZATION,
ROUND(SUM(T.failedcmds)/
SUM(T.total_failedcmds),2)*100 failedcmds,
AVG(MAX_QL) MAX_QL,
AVG(AVG_QL) avg_ql
FROM db1 T,
db2 mt
WHERE T.eq_model = mt.eq_model
and TOT_AVAIL_TIME != 0
AND TOT_AVAIL_TIME IS NOT NULL
GROUP BY T.xhrs, T.eq_id, mt.CATEGORY, mt.MODEL_NAME
This query returns 2550 records and takes 12-15 s to run in SQL Developer and in mybatis it takes 30-35 secs. Is there any thing wrong with existing query? Is there any way to optimize above query and bring down the execution time to <5 secs in sql developer and <15 secs in ORM?
Explain Plan

Answer 1

Let me bring up a few points for us to think about performance.
The matter of fact is that "MyBatis or any other ORM is going to be slower than native SQL execution". Some of the reasons for this fact are:
R1. It is clear that MyBatis adds overhead to database calls. You gain flexibility, maintenance and encapsulation but you lose in performance.
R2. In most cases, MyBatis is going to parse the ResultSet to Java objects, this adds additional overhead. SQL Clients can work straight with cursors which are faster but in a long run it may be harder to maintain.
R3. In most cases, MyBatis is going to create a transaction for you, this adds additional overhead.
R4. In most cases, MyBatis is going to create and manage a cache for you, this adds additional overhead for the fist select but speed up the process for the next selects.
R5. MyBatis can also help you with lazy loading and other data retrieval strategies.
-R6. We should compare MyBatis executions against JDBC executions. Instead of comparing MyBatis against a SQL Client Tool (such as SQL Developer) because there are variables which can obscure your results. Example, they may not fetch all rows at once.
That being said, MyBatis may give you flexibility, better maintenance, an easy way to handle transact, easy way to parse tables to Java objects but it you take some performance from you.
So, if you want to speed up your queries there are a few things you should consider. See MyBatis Documentation:
C1. Use fetchSize in your queries.
C2. Use cache wisely, see what kind of caching it is needed, in some cases it make sense to do not use cache at all. Example: <select ... useCache="false">
C3. Be aware of the "N+1 Selects Problem". The documentation has some insights about this characteristic of many ORMs.
C4. Try to use a lightweight transactionManager such as "JDBC", keep in mind that aspect oriented transactions (such as in Spring #Transactional) will add a little bit more of overhead.

Answer 2

If the tables aren't indexed properly yet, you could get the most out of indexing T by TOT_AVAIL_TIME and T.eq_model and indexing mt by mt.eq_model

Answer 3

Put T.eq_model and T.TOT_AVAIL_TIME in one index (in this order).
Note: as you also check for NULL-ness of TOT_AVAIL_TIME, I assume it can be NULL by column definition. If you index it in a simple index, NULL-s are not indexed, and a TOT_AVAIL_TIME IS NOT NULL won't use the index later. So either combine it with eq_model, or remove that filter and change the column to NOT NULL.
I used this workaround on nullable columns on JIRA: (PROJECT_CAN_HAS_NULL ASC, '1').

Answer 4

Add index on eq_model column and check
Please try with this query only i combined the where condition on TOT_AVAIL_TIM
SELECT T.xhrs, T.eq_id, mt.CATEGORY, mt.MODEL_NAME,
ROUND((SUM (T.TOT_AVAIL_TIME-T.maintenance_TIME) / SUM(T.TOT_AVAIL_TIME))*100) AVAILABILITY,
ROUND((SUM(UTIL_TIME) / nullif(SUM(T.TOT_AVAIL_TIME-T.maintenance_TIME ),0) )*100) UTILIZATION,
ROUND(SUM(T.failedcmds)/
SUM(T.total_failedcmds),2)*100 failedcmds,
AVG(MAX_QL) MAX_QL,
AVG(AVG_QL) avg_ql
FROM db1 T,
db2 mt
WHERE T.eq_model = mt.eq_model
AND (TOT_AVAIL_TIME != 0 AND TOT_AVAIL_TIME IS NOT NULL)
GROUP BY T.xhrs, T.eq_id, mt.CATEGORY, mt.MODEL_NAME