Query design for performance with DB2 Multisystem

 

You can design queries based on these guidelines. In this way, you can use query resources more efficiently when you run queries that use distributed files.

This topic also discusses how queries that use distributed files are implemented. This information can be used to tune queries so that they run more efficiently in a distributed environment.

Distributed files can be queried using SQL, the Open Query File (OPNQRYF) command, or any query interface on the system. The queries can be single file queries or join queries. You can use a combination of distributed and local files in a join.

This topic assumes that you are familiar with running and optimizing queries in a nondistributed environment. If you want more information about these topics:

• SQL users need to refer to the SQL reference and SQL programming concepts information.

• Non-SQL users need to refer to the database programming and control language information.

This topic also shows you how to improve the performance of distributed queries by exploiting parallelism and minimizing data movement.

• Optimization with DB2 Multisystem: Overview
  Distributed queries are optimized at the distributed level and the local level.

• Implementation and optimization of a single file query with DB2 Multisystem
  To do a single file query, the system where the query was specified, the coordinator node, determines the nodes of the file to which to send the query. Those nodes run the query and return the queried records to the coordinator node.

• Implementation and optimization of record ordering with DB2 Multisystem
  When ordering is specified on a query, the ordering criteria is sent along with the query, so that each node can perform the ordering in parallel. Whether a final merge or a sort is performed on the coordinator node is dependent on the type of query that you specify.

• Implementation and optimization of the UNION and DISTINCT clauses with DB2 Multisystem
  If a unioned SELECT statement refers to a distributed file, the statement is processed as a distributed query.

• Processing of the DSTDTA and ALWCPYDTA parameters with DB2 Multisystem
  The allow copy data (ALWCPYDTA) parameter can change the value specified for the distribute data (DSTDTA) parameter of the Override Database File (OVRDBF) command.

• Implementation and optimization of join operations with DB2 Multisystem
  In addition to the performance considerations for nondistributed join queries, more performance considerations exist for queries involving distributed files.

• Implementation and optimization of grouping with DB2 Multisystem
  The implementation method for grouping in queries that use distributed files is dependent on whether the partitioning key is included in the grouping criteria.

• Subquery support with DB2 Multisystem
  Distributed files can be specified in subqueries.

• Access plans with DB2 Multisystem
  The access plans stored for queries that refer to distributed files are different from the access plans stored for local files.

• Reusable open data paths with DB2 Multisystem
  Reusable open data paths (ODPs) have special considerations for distributed queries. Like most other aspects of distributed queries, ODPs have two levels: distributed and local.

• Temporary result writer with DB2 Multisystem
  Temporary result writers are system-initiated jobs that are always active.

• Optimizer messages with DB2 Multisystem
  The i5/OS^® distributed query optimizer provides you with information messages on the current query processing when the job is in debug mode.

• Changes to the Change Query Attributes command with DB2 Multisystem
  The Change Query Attributes command has two parameters that are applicable to distributed queries.

• Summary of performance considerations
  You should consider these performance factors when developing queries that use distributed files.

 

Parent topic:

DB2 Multisystem

 

Related concepts

Choosing partitioning keys with DB2 Multisystem
SQL programming
Database programming

 

Related reference

SQL reference
Control language