In this article, Brian Laube shows how we can solve a real-life performance problem by copying access path information from one environment to another one and then using it as an optimization hint.
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