| Where allowed to run: All environments (*ALL) Threadsafe: Yes |
Parameters Examples Error messages |
The Change Query Attributes (CHGQRYA) command specifies attributes for database queries and database file keyed access path builds, rebuilds, and maintenance that are run in a job. Database queries include the open of a SQL view and the running of SQL data manipulation statements.
Restrictions: You must have job control (*JOBCTL) special authority to use this command.
| Top |
| Keyword | Description | Choices | Notes |
|---|---|---|---|
| JOB | Job name | Single values: * Other values: Qualified job name |
Optional, Key |
| Qualifier 1: Job name | Name | ||
| Qualifier 2: User | Name | ||
| Qualifier 3: Number | 000000-999999 | ||
| QRYTIMLMT | Query processing time limit | 0-2147352578, *SAME, *NOMAX, *SYSVAL | Optional |
| DEGREE | Parallel processing degree | Single values: *SAME, *NONE, *IO, *OPTIMIZE, *MAX, *SYSVAL, *ANY Other values: Element list |
Optional |
| Element 1: Processing option | *NBRTASKS | ||
| Element 2: Number of tasks | 2-9999 | ||
| ASYNCJ | Asynchronous job usage | *SAME, *DIST, *LOCAL, *ANY, *NONE | Optional |
| APYRMT | Apply CHGQRYA to remote | *SAME, *YES, *NO | Optional |
| QRYOPTLIB | Query options file library | Name, *SAME | Optional |
| QRYSTGLMT | Query temporary storage limit | 0-2147352578, *SAME, *NOMAX | Optional |
| Top |
Specifies the job for which the query attributes are to be changed.
Single values
Qualifier 1: Job name
Qualifier 2: User
Qualifier 3: Number
| Top |
Specifies a limit for database queries allowed to be started based on the estimated number of elapsed seconds that the query requires to process.
The initial value of the QRYTIMLMT attribute for a job is *SYSVAL.
When 0 is specified all database queries issue a CPA4259 inquiry message. Setting a query time limit of 0 can be useful when attempting to tune database queries for better performance because the technical description of the CPA4259 inquiry message explains the type of access plan used by the query.
| Top |
Specifies the parallel processing option and, optionally, the number of tasks that can be used when running database queries and database file keyed access path builds, rebuilds, and maintenance in the job.
The specified parallel processing option determines the types of parallel processing allowed. There are two types of parallel processing:
With I/O parallel processing, the database manager uses multiple tasks for each query to do the I/O processing. The central processor unit (CPU) processing is still done serially.
SMP assigns both the CPU and I/O processing to tasks that will run the query in parallel. Actual CPU parallelism requires a system with multiple processors. SMP parallelism can only be used if the system feature, DB2 Symmetric Multiprocessing for OS/400, is installed.
Use of SMP parallelism can affect the order in which records are returned. Applications which depend on records being returned from database queries in arrival sequence or keyed access path sequence that have not explicitly defined the ordering sequence in the query, should not be run in jobs which have specified a parallel processing option that enables SMP processing.
The initial value of the DEGREE attribute for a job is *SYSVAL.
Single values
Element 1: Processing option
Element 2: Number of tasks
Using a number of tasks less than the number of processors available on the system restricts the number of processors used simultaneously for running a given query or database file keyed access path build, rebuild, or maintenance. A larger number of tasks ensures that the query or database file keyed access path build, rebuild, or maintenance is allowed to use all of the processors available on the system to run the query. Too many tasks can degrade performance because of the over-commitment of active memory and the overhead cost of managing all of the tasks.
| Top |
Specifies the circumstances in which asynchronous (temporary writer) jobs can be used to help process database queries in the job.
The specified usage option determines which types of database queries can use asynchronous jobs (running in parallel) to help in completing the query.
An asynchronous job is a separate job on the system that handles query requests from jobs that are running database queries. For each request, the asynchronous job processes the request and puts the results into a temporary file. This intermediate temporary file is then used by the main job to complete the database query.
The advantage of using an asynchronous job is that it can be processing its request at the same time (in parallel) that the main job is processing another step of the database query. The disadvantage of using an asynchronous job is that it may encounter a situation that it cannot handle in the same way as the main job. For example, the asynchronous job may receive an inquiry message from which it would have to cancel, whereas the main job could have chosen to ignore the message and continue.
There are two different types of database queries that can use asynchronous jobs:
These are database queries that involve distributed files. Distributed files are provided through the system feature DB2 Multi-System for OS/400.
These are database queries that involve only files local to the system where the database queries are being run.
The initial value of the ASYNCJ attribute for a job is *LOCAL.
In addition, for queries involving distributed files, this option allows the communications required to be asynchronous. This allows each system involved in the query of the distributed files to run its portion of the query at the same time (in parallel) as the other systems.
In addition, all processing for queries involving distributed files occurs synchronously. Therefore, no inter-system parallel processing will occur.
| Top |
Specifies, for database queries involving distributed files, whether or not the query attributes are applied to the jobs on the remote systems associated with this job. The query attributes applied are those from this command and those specified in the QAQQINI file in the library specified for the Query options file library (QRYOPTLIB) parameter.
The specified option determines whether the query attributes specified for the job are applied to the associated jobs on the systems applicable to the distributed file or files.
The initial value of the APYRMT attribute for a job is *YES.
| Top |
Specifies which library currently contains, or will contain, the query options file (QAQQINI).
The query options file is used to set or modify the attributes used by the Query Optimizer that will determine how a query will be implemented in the job specified.
The query options file uses a system-supplied trigger program associated with the file QAQQINI in order to process any changes made to the file. A template for the file is shipped in the library QSYS with the base trigger program already attached. In order to maintain and use the query options file correctly, it is recommended that Create Duplicate Object (CRTDUPOBJ) be used to create a copy of the file QAQQINI into the library specified for this parameter.
For more information, refer to the SQL Programming information in the iSeries Information Center at http://www.ibm.com/eserver/iseries/infocenter or Database information in the iSeries Information Center at http://www.ibm.com/eserver/iseries/infocenter.
The initial value of the QRYOPTLIB attribute for a job is QUSRSYS.
| Top |
Specifies a temporary storage limit for database queries. If the query is expected to use more than the specified amount of storage, the query will not be allowed to start. The value specified is in megabytes.
The initial value of the QRYSTGLMT attribute for a job is *NOMAX.
When 0 is specified most database queries will exceed the specified temporary storage limit and will issue a CPA4259 inquiry message. Setting a query temporary storage limit of 0 can be useful when attempting to tune database queries for better performance because the technical description of the CPA4259 inquiry message explains the type of access plan used by the query.
| Top |
Example 1: Changing the Query Time Limit
CHGQRYA QRYTIMLMT(60)
This command changes the query time limit to 60 seconds.
Example 2: Controlling Query and Database Parallel Processing
CHGQRYA DEGREE(*IO)
This command specifies that any number of tasks may be used when the database query optimizer chooses to use I/O parallel processing for queries. SMP parallel processing is not allowed.
Example 3: Controlling Query Parallel Processing
CHGQRYA DEGREE(*OPTIMIZE)
This command specifies that the query optimizer can choose to use any number of tasks for either I/O or SMP parallel processing to process a query, database file keyed access path build or rebuild, or database file I/O keyed access path maintenance. SMP parallel processing will only be used if the system feature DB2 Symmetric Multiprocessing is installed.
Example 4: Controlling Query Parallel Processing
CHGQRYA DEGREE(*MAX)
This command specifies that the query optimizer can assume that all active memory in the pool can be used to process a query, database file keyed access path build or rebuild, or database file I/O keyed access path maintenance and can choose to use any number of tasks for either I/O or SMP parallel processing to process a query, database file keyed access path build or rebuild, or database file I/O keyed access path maintenance. SMP parallel processing will only be used if the system feature DB2 Symmetric Multiprocessing is installed.
Example 5: Controlling Query Number of Tasks
CHGQRYA DEGREE(*NBRTASKS 12)
This command specifies that the 12 tasks are to be used when the query optimizer chooses to use SMP parallel processing to process a query, database file keyed access path build or rebuild, or database file I/O keyed access path maintenance. I/O parallelism will also be allowed. SMP parallel processing will only be used if the system feature DB2 Symmetric Multiprocessing is installed.
Example 6: Controlling Query Parallel Processing
CHGQRYA DEGREE(*SYSVAL)
This command specifies that the query, database file keyed access path build or rebuild, or database file I/O keyed access path maintenance, should be optimized with the current value of system value QQRYDEGREE when the query, database file keyed access path build or rebuild, or database file I/O keyed access path maintenance is run.
Example 7: Disabling Asynchronous Job Usage for Distributed File Processing
CHGQRYA ASYNCJ(*LOCAL)
This command prevents asynchronous jobs from being used for queries involving distributed files.
Example 8: Disabling Asynchronous Job Usage
CHGQRYA ASYNCJ(*NONE)
This command prevents asynchronous jobs from being used for any queries. In addition, for queries involving distributed files, communication to remote systems is done in a synchronous fashion.
Example 9: Specifies Query Options File Library
CHGQRYA QRYOPTLIB(QUSRSYS)
This command specifies that library QUSRSYS is to be searched for the existence of the query options file (QAQQINI).
Note: Use this command in addition to STRDBG UPDPROD(*YES) and all optimizer debug messages (local and remote) will show up in this job's job log.
Example 10: Specifies Query Options File Library for a Different Job
CHGQRYA QRYOPTLIB(LIB41) JOB(134543/QPGMR/DSP01)
This command specifies that library LIB41 is to be searched for the existence of the query options file (QAQQINI) for job number 134543. The job name is DSP01 and was started by the user named QPGMR. This library may exist in more than one independent ASP (auxiliary storage pool); the library in the namespace of the originator's job will always be used.
Example 11: Changing the Query Resource Limit
CHGQRYA QRYSTGLMT(200)
This command changes the query temporary storage limit to 200 megabytes.
| Top |
*ESCAPE Messages
| Top |