Performance of using a "Like" Filter *is not due to straight index issue*

Question

Hello,
We have just released an Oracle APEX app to the users and ran into a performance issue in the production version that was not in development. The interactive report goes against a simple view that returns Data similar to:
NAME VALUE MIN MAX
BEL123 1 1 3
BEL245 3 3 4
AB222 2 1 3
The issue is that when a filter is used on the name column with a like operand (name LIKE 'BEL%' ). The query performance become very poor (average is 29 seconds to return according to the APEX stats). These are huge tables but the performance in the development area is quick (almost instantaneous). Here are the things I have looked into to try and narrow the problem down:
1) I have tried running the exact same query in SQL*Plus and the performance is quick in both production and development, so its not the indexes.
2) Creating brand new reports from scratch causes the same results in production and development. So its not anything specific that has been changed in the two versions (which are identical)
3) Putting the NAME Like 'BEL%' directly into the SQL clause of the report produces quick returns in production so the problem is not the APEX user not seeing the indexes for some reason. It also ensures that any data differences in the two databases are not the root cause of this.
So my only theory is that somehow the use of the Like filter does not allow the index on the NAME column to be used but only in production. Any ideas ... I am at a loss.
Edited by: user491396 on Jan 7, 2009 2:18 PM

Answer 1

g.myers wrote:
Apex does run the query the same way a direct connection does. It gets parsed, bind variables are peeked and an optimizer plan produced.
You have a query performance problem, not an Apex problem.
Oracle manages all SQL this way, irrespective of where it comes from.
Since we can only see the view, and not the full query (ie with all the tables, joins, predicates...) it is all pretty much guesswork for us.
It could be either the initial bind value (ie what was in the variable originally queried). If it was '%', then as a predicate it is pretty much useless. Your application should either prevent a '%' in the first character, or generate a separate SQL for that. If the '%' was the second character, then (depending on data volumes and data distribution) that may also result in a poorly performing plan.
Depending on db version you could look at v$sql_bind_capture for that SQL and see what values were used for peeking.
How many rows in DT_SCADA_TAGS ? The full table scan entry suggests you have 75 million in DT_SCADA_VALUES
The hash join between DT_SCADA_DATETIMES and DT_SCADA_VALUES suggests that there isn't a decent join path between the two (eg no date index on DT_SCADA_VALUES or one that indicates a low selectivity).Through testing the initial bind variable does not impact what the performance is ... even if its a full unique value without % it does not work any different. In this capture it was a full value 'BEL2395489'. There is 75 Million rows in DT_SCADA_VALUES. There is indexes on the dates and tag_names. I'll post the view for completeness at the end.
The outstanding issue/knowledge from here is that an APEX Filter using LIKE may be handled differently then a LIKE within the initial SQL by the parser and may lead to .
SELECT DT_SCADA_DATETIMES.DT_SCADA_DATETIME AS DT_SCADA_DATETIME,
       DT_SCADA_TAGS.TAG_NAME AS TAG_NAME,
       DT_SCADA_TAGS.TAG_DESCRIPTION AS TAG_DESCRIPTION,
       DT_SCADA_VALUES.ACTUAL_VALUE AS ACTUAL_VALUE,
       DT_SCADA_VALUES.MIN_VALUE AS MIN_VALUE,
       DT_SCADA_VALUES.MAX_VALUE AS MAX_VALUE,
       DT_SCADA_VALUES.AVG_VALUE AS AVG_VALUE,
       TRUNC(DT_SCADA_DATETIMES.DT_SCADA_DATETIME) AS DT_SCADA_DATE,
       TO_NUMBER(TO_CHAR(DT_SCADA_DATETIMES.DT_SCADA_DATETIME, 'HH24')) AS DT_SCADA_HR,
       TO_NUMBER(TO_CHAR(DT_SCADA_DATETIMES.DT_SCADA_DATETIME, 'MM')) AS DT_SCADA_MONTH,
       TO_NUMBER(TO_CHAR(DT_SCADA_DATETIMES.DT_SCADA_DATETIME, 'YYYY')) AS DT_SCADA_YEAR,
       TO_NUMBER(TO_CHAR(DT_SCADA_DATETIMES.DT_SCADA_DATETIME, 'DD')) AS DT_SCADA_DAY
  FROM
       DT_SCADA_TAGS   DT_SCADA_TAGS,
       DT_SCADA_VALUES DT_SCADA_VALUES,
       DT_SCADA_DATETIMES DT_SCADA_DATETIMES
WHERE DT_SCADA_DATETIMES.DT_SCADA_DATETIME_ID =
       DT_SCADA_VALUES.DT_SCADA_DATETIME_ID
   AND DT_SCADA_TAGS.DT_SCADA_TAG_ID = DT_SCADA_VALUES.DT_SCADA_TAG_ID
ORDER BY DT_SCADA_DATETIME DESC, DT_SCADA_TAGS.TAG_NAME