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.
SQL tuning is not just looking at statements and their EXPLAIN plans, but it’s also about verifying whether or not a tuning change actually improves performance. Remember that SQL tuning is about saving elapsed time and/or CPU resources, and there is only one way to really do that: benchmarking!
An under-appreciated set of ANSI SQL functions introduced over a decade ago could dramatically reduce application chattiness and improve response times.
We always assume that tuning, will result in actual monetary savings. Well, with IBMs Measured Workload Pricing this is not always the case. Join well known DB2 speaker Phil Grainger as he explains how IBMs MLC works in practice and what this means to our DB2 world.
Continuing this month's theme of Temporal Data (Time Travel Query), IDUG Content Committee chair Dan Luksetich goes behind the scenes to look at how DB2 processes temporal queries. Check out his article here -