This blog post explores a strategy for improving processing efficiency within IBM’s DB2 on LUW. The Precise product line is designed for monitoring and improvement.
An idle database has static resource consumption and little contention. As resources are consumed, shortages develop resulting in waits, locks, contention, sub-optimal performance, and a ringing phone with users complaining. By tracking SQL statements and their execution states, Precise measures which resources are in short supply partition wide. By identifying where there is the largest buy-back, Precise helps the DBA prioritize and improve processing efficiency. When CPU and I/O are released back to the system, there can be nice ripple effect on all activity. This can have a wider impact in a shared virtualized environment.
The top SQL statement in the screen below spends the majority of its time accessing storage. This is the light blue execution state shown in the stacked bar graph is time spent waiting on the storage subsystem. The CAPEX budget could be spent on solid state storage. That’s one option and it might be worthwhile if accessing storage is a pervasive execution state. However in this case, storage is slowing down only one SQL statement. It might easier and less expensive to spend a little time examining this one SQL statement. The current execution plan reveals where the execution time is spent.
B-tree indices offer super efficient and fast access to data. Precise is predicated on management by measurement. It does not make sense to argue with the stop watch. A B-tree is often faster than parallel access. Test to know; implement the winner. The big question is what indices comprised of which columns.
The ideal index configuration is the minimum number of fresh, highly selective, low cluster-factor indices, that are placed to minimize hardware contention©. Each of these criteria is crucial and will have a major impact on response time. Every index imposes overhead during update, delete, and insert operations. Indices slow down ETL processing. This is why it pays to shoot for the minimum number of indices.
Precise for DB2’s index recommendation and evaluate functionality can assist with this task. Precise provides the execution plan. B-tree indices are used for more than pulling back rows of data. They can help with sorting and with joins.
Evaluate reveals that the new index will provide a 94% processing improvement. Please keep in mind that an index is built one time unlike a SQL statement which executes multiple times. This is one way that resources overall can be saved.
Contact IDERA to discuss further: Precise for DB2