.webp)
SQL performance investigations often begin with a practical problem: a job that has run reliably for a long time suddenly takes much longer than expected.
IBM i provides powerful tools for investigating SQL statements and access plans in depth. GiAPA SQL Observer serves a different purpose. It helps preserve the history needed to identify which statement or plan deserves that closer investigation.
IBM SQL Performance Center in Access Client Solutions is designed for detailed analysis of individual SQL statements and access plans. It is the natural place to go when a specific plan needs to be examined closely.
It can help technical specialists understand how the Optimizer chose to execute a statement and investigate the details of that choice.
GiAPA SQL Observer does not attempt to replace that analysis. Its role is to retrieve selected Plan Cache data over time, so that changes in access plans can be seen and compared.
The difference is important. SQL Performance Center helps answer: “Why did this particular plan behave as it did?” SQL Observer helps answer: “Which plan changed, and when did the change occur?”
A single access-plan snapshot can be valuable, but it cannot show whether the same SQL statement used another plan earlier in the day, last week, or before a performance problem began.
When a job suddenly becomes slower, the first challenge is often to identify what changed. The SQL statement may be exactly the same, while the access plan, data conditions, query options, or runtime environment have changed around it.
By retaining selected Plan Cache information over time, SQL Observer can make those changes easier to find. It can show which plans were used, when they changed, and which IBM-supplied reason codes were recorded.
That does not solve the investigation by itself. It gives the investigation a more useful starting point.
The two tools work well together.
SQL Observer can help narrow the search by showing that a plan changed at a particular time, perhaps after a table was recreated, an index became unavailable, row counts changed significantly, or the Optimizer selected a different Open Data Path.
Once the relevant statement and plan have been identified, SQL Performance Center can be used for the detailed technical analysis.
This avoids treating every SQL slowdown as a search through every statement in the system. Instead, the team can begin with historical evidence and focus its detailed work where it is most likely to matter.
The purpose of SQL Observer is not to decide whether an access plan is good or bad. It is to preserve the evidence that shows when a change occurred and what IBM recorded about it.
The purpose of SQL Performance Center is to help analyse the identified statement and plan in depth.
Together, they provide a more practical route from a general observation, such as “SQL suddenly got slower,” to a focused technical question that can be investigated with confidence.
This article is part of GiAPA’s guide: When SQL Performance Changes: What Access-Plan History Can Reveal on IBM i.