Tuning of SQL queries requires understanding why DB2 chose a particular access path and determining whether or not that access path should perform as expected. The key to this is understanding what filter factors are, how they are used by the Optimizer and how to get DB2 to better estimate them,
Let’s start this discussion candidly – I am a big fan of the FETCH FIRST n ROWS ONLY clause coded in a SQL statement. That assertion will require some clarification, since there are some valid use cases, and others that make little sense. Regardless, I will try not to over-complicate the discussion.
By now, most DB2 for LUW users have probably heard about the release of DB2 11.1 that became available in June of this year. In this article I’d like to provide more information on some performance optimizations in DB2 11.1 that will benefit queries accessing both row and column-organized tables.
Optimizing columnar access
Dynamic SQL statements can remain in the dynamic statement cache for a long period of time. When the statement gets refreshed, its access path could change dramatically. This article shows one way of limiting the impact of such an access path shift.