If I had to identify a single most overlooked Db2 performance metric, it would be GETPAGEs.
Many organizations focus on CPU utilization, elapsed time, or buffer pool hit ratios because those metrics are easy to understand and frequently appear on dashboards. But getpages often reveal performance problems long before those other metrics become alarming.
In Db2 for z/OS, a GETPAGE represents a request by Db2 to access a page
of data or an index page. If the page is already in the buffer pool, no
physical I/O is required. If not, Db2 must read it from disk. Either way, every
GETPAGE consumes CPU resources.
Why GETPAGEs Matter
Because every SQL statement generates GETPAGE requests, the number of
GETPAGEs is a fundamental measure of how much work Db2 performs to execute a
workload. The more pages Db2 must examine to satisfy a query, the more work it
performs. Reducing unnecessary GETPAGEs often leads directly to lower CPU
consumption and better application performance.
High GETPAGE counts usually indicate one or more of the following:
- Inefficient index usage
- Poor clustering
- Table scans
- Low filter factors
- Redundant index probes
- Accessing more columns or rows
than necessary
Even when all pages are found in the buffer pool, millions of unnecessary
GETPAGEs still consume CPU.
The Hidden CPU Consumer
I've worked with organizations that upgraded processors because CPU costs
continued to rise. After analyzing the workload, we discovered that many
critical SQL statements were generating ten or even one hundred times more GETPAGEs
than necessary.
A simple index redesign or SQL rewrite reduced GETPAGE counts
dramatically. And CPU usage dropped without any hardware changes.
That's why I often tell clients: "Every unnecessary GETPAGE results
in costly unneeded work."
Don't Just Count GETPAGEs
The raw number of GETPAGEs by itself does not tell the whole story.
Instead, monitor:
- GETPAGEs per transaction
- GETPAGEs per SQL statement
- GETPAGEs per row returned
- Trends over time
- The highest GETPAGE-consuming
applications
A workload processing twice as many transactions should naturally
generate more GETPAGEs. The real warning sign is when GETPAGEs per
transaction steadily increase. That usually means SQL or access paths have
degraded.
GETPAGEs Point to Root Causes
Unlike CPU utilization, which tells you that work is occurring, GETPAGEs often explain why.
For example:
|
Symptom |
What High GETPAGEs May Indicate |
|
High CPU |
Excessive index or table page
accesses |
|
Long elapsed time |
Inefficient access path |
|
Buffer pool pressure |
Poor locality of reference |
|
Lock contention |
Long-running scans |
|
Increased zIIP usage |
More work being offloaded, but still
excessive overall processing |
My Rule of Thumb 👍
After more than four decades tuning Db2 systems, one principle has
remained remarkably consistent:
Watch the work, not just the time.
Elapsed time can fluctuate because of concurrency. CPU depends on
hardware generation. I/O depends on storage technology.
But GETPAGEs measure the amount of work Db2 is performing. If you reduce
the work, you almost always improve performance.
Other Frequently Overlooked Metrics
Although GETPAGEs are my top choice, several other metrics deserve more
attention:
- Synchronous read percentage — Indicates how often Db2 must
wait for I/O instead of benefiting from prefetch.
- Pages read per GETPAGE — Helps evaluate buffer pool
effectiveness.
- Lock suspension time — Often more meaningful than
simply counting lock waits.
- Class 3 suspension time — Shows where Db2 is waiting
(I/O, locks, logging, etc.).
- RID pool failures — Can reveal access path
problems that are otherwise difficult to diagnose.
- Sort overflows — Indicate insufficient sort
memory or inefficient SQL.
- Index leaf page split rates — A useful indicator of index
maintenance issues and clustering degradation.
If I were teaching a new Db2 performance analyst, I'd spend less time
looking at CPU graphs and more time asking, "Why is Db2 doing so much
work?" In many cases, the answer begins with GETPAGEs.
