SQL Common Mistakes

Description or Symptoms
Mismatched host variables can result in slow application execution. Redundant SQL calls result in unnecessary resource usage and slower execution. SQL functions in the where clause can either cause the creation of an additional index containing the function results or prevent the use of an index.

Typing mismatched host variables in SQL Making SQL calls for information already known Using WHERE clauses containing SQL functions that could be done in the host language

Every SQL call accessing the database results in a resource usage. Excessive SQL calls can result in unnecessary and Using multiple SQL calls when one SQL call expensive resource usage, as well as can return the required data slower application execution. A feature included in a recent release of the DBMS, the OUTER JOIN feature is an improvement over the not exists subquery. Using the NOT EXISTS sub-query is less efficient, and can result in slower program execution. DISTINCT always causes a sort, while GROUP BY can be processed with an index. This usually occurs when a programmer isnt paying attention to how the DBMS accesses data. The result can be slow program execution.

Using NOT EXISTS sub-query instead of OUTER JOIN

Using DISTINCT instead of GROUP BY

Failing to check the PLAN_TABLE

Failing to take advantage of multi-row FETCH, INSERT, and MERGE

With every DBMS SQL call, there is a transmission cost. Using too many DBMS SQL results in excessive resource usage and slower applications.

Failing to use columns in the order of the index, in an order by clause, or needlessly ordering a result set Failing to use newer DB2 features such as WITH UR or WITH CS, OPTIMIZE FOR n This occurs when a programmer fails to ROWS, FOR FETCH ONLY, FETCH FIRST identify locations in an application where ROW ONLY newer features can save resources.

Sorting happens when the data is retrieved in a different order than an index, and can create needless resource usage. Getting the data in the order of the index can allow it to skip the sort.

Using SELECT COUNT(*) INTO to find all instead of SELECT COL INTO:hv FETCH FIRST ROW ONLY to find the existence

It takes DB2 longer to count all the rows rather than getting the first row that matches. DB2 can bring in the other rows around the row it is fetching using a clustering index. This is called sequential prefetch. If it doesnt have to bring in another page to get the data, it has less work to do.

Failing to process in the order of the clustering index when possible

Solution or Prevention
Perform a code review. Pay close attention to your SQL access paths. Perform a code review to investigate information already available from prior SQL calls.

Perform a code review and investigate access path selection. Reducing the number of SQL calls reduces resource usage. Perform a code review to reduce the number of SQL calls. Reevaluate the SQL logic to maximize the amount of returned data. Comparing new release improvements to your current code. Experiment for improvements using the more efficient OUTER JOIN sub query in lieu of the older NOT EXISTS sub-query coding method. Scan your code opportunities to use GROUP BY instead of DISTINCT. QA tools may be helpful in checking the access path.

SQL explain tools assist programmers by showing how DB2 will get the data. Multi-row operations return more data, thus saving time. This cost is multiplied in distributed processing. Performance monitoring software can report the amount of time DB2 spends transmitting data. Perform a code review to find opportunities for coding multi-row FETCH, INSERT, and MERGE.

SQL explain tools help indicate when the results are going to get sorted. Locate these areas and modify the application to get the data in the order of the index, if possible. Performance monitoring tools can point out the long running SQL and then compare it to the new features and decide if they will help. Perform a code review and scan for COUNT(*). QA tools can quickly locate this. Look for opportunities to replace SELECT COUNT(*) INTO with a more specific SELECT COL INTO:hv FETCH FIRST ROW ONLY.

Proactively paying attention to the indexes allows coders to take advantage of making the database get more done with each access.