Updating the SQL optimization settings
The SQL optimization settings influence the selection of packages and dynamic statements for optimization. The settings also affect how Db2ZAI compares the performance of different access paths. You can keep the default settings or tailor them to achieve the behavior you want.
Before you begin
For an example of updating SQL optimization settings, see Getting started with Db2ZAI SQL optimization.
About this task
The default behavior of Db2ZAI is to automatically selectively enable static packages and dynamic statements to be in processing scope, based on criteria that indicate that those static packages and dynamic statements are good candidates for Db2ZAI. You can, however, choose to manually selectively enable or disable particular packages for Db2ZAI processing. In addition, you can choose which dynamic queries that you want Db2ZAI to optimize by specifying the client user IDs or application names (or both) under which the queries are executed.
- It is initiated after the -START ML command is issued and then every 24 hours afterward.
- Each time it runs, the process finds packages of interest to Db2ZAI and puts the first 50 of them in a ranked list of packages that are pending processing.
- Package ranking is based upon several factors including the number of getpage requests from the table space or index space and the types of queries involved.
- Only static statements within the package are included in scope and the criteria above only apply to those static statements. Any dynamic statements that execute under the package are put into scope using the process described below.
- Monitoring of IFCID 318 data to determine the dynamic statements with the highest CPU consumption.
- Selection of the top 5 dynamic statements in terms of highest CPU consumption in a monitoring cycle.
- Once a dynamic statement is selected for processing, it remains in scope unless you explicitly exclude it.
- Queries that use the 'CONCENTRATE STATEMENTS WITH LITERALS' option
- REOPT(AUTO)
- Queries that involve temporal tables
- Constant literal in a predicate on a high cardinality column
- Simple query on a single table using fully-matched unique index
In determining the right mix of CPU vs. elapsed time weighting for your environment, an important factor to consider is the nature of your application. While a 50/50 balance of CPU vs. elapsed time weighting would work when the environment contains a broad mix of online and batch processes, if your environment contains a predominance of one or the other, you might want to change the setting. If the response time of your queries is important, as, for example, with an application that relies upon user responses (as opposed to a batch program), you may tend to give greater weight to elapsed time. In cases where you are running a batch process, where it might be more important to reduce CPU usage, you might want to weight CPU more heavily.
To reduce the possibility of unintended results, avoid setting either CPU or elapsed time weight to 100.
Procedure
To update the SQL optimization settings:
Static settings
Dynamic settings