Query Advisor missing obvious SQL predicate datatype inconsistency
While researching a production issue in all our production systems with a remote DB2 program, we ran OQT in DSM and found that the QUERY ADVISOR was missing a very obvious and key SQL problem. A column that is defined with a CHAR datatype was being compared to a literal with NO Quotes that was all numerics. Although the Optimizer will convert it using a CAST function, it avoids the optimal use of an existing index that this column is a part of. We ended up finding it ourselves by looking at the formatted query that the tool created, but it should have showed up as a warning for us to review. I am attaching the full recommendation report that OQWT generated from our BOST production region. We are At DB2 V12 R100 . Running DSM Version 2.1 Release 220.127.116.11, Build 20190702_1507 . this is the solution that was sent to the developers (this recommendation resulted in a 99% reduction in CPU and I/O):
The SQL in APOIMP18 and APOIMP16 is listed below.
The SQLs in these programs have a WHERE clause coded: AND BATCH_PROC_D = 20191024 BATCH_PROC_D is a character column.
The SQL needs to be coded as AND BATCH_PROC_D = ‘20191024’ (put in quotes)
From IBM support: Looking for an enhancement to analyze the BEFORE stage query text to detect if there is a CAST function in one side and other side in predicate is a value, then show a warning in our Query Advisor recommendation.
reference CASE TS002923553
|Who would benefit from this IDEA?||Database Administrator and SQL developer and ultimately the end user|
How should it work?
Modify Query Analyzer so that the BEFORE stage query text can detect if there is a CAST function in one side and the other side has a predicate with a value that does not match the actual column data type, then show a warning in our Query Advisor recommendation.
By identifying this mismatch of datatypes in a predicate where a column is part of an index, we can advise the developer to fix their SQL to avoid this mismatch and result in a better use of the index. In our case making this one small change resulted in a 99% savings in CPU and I/O, as well as the ET. User CPU timeouts were ultimately avoided.
Although this seems like an obvious find and fix, it was not as easy to find. would be helpful if this Tool could identify this query tuning issue sooner and avoid manual effort to research.
|Priority Justification||if we could identify more of these types of datatype inconsistencies when comparing to literals in a larger scale (ie Workload)|
|Customer Name||Rachel Niedzwiecki|
NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "firstname.lastname@example.org" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions