6. DATA SOURCES › 6.4 Query CP Parallelism Considerations › 6.4.2 Parallel Tasks Data Analysis
6.4.2 Parallel Tasks Data Analysis
When analyzing data involving query parallelism, you have to
consider the end users perception and the internal DB2
parallel monitoring. What appears to be a single execution of
a thread for a user, actually translates into multiple DB2
subtasks which will only provide an overall elapsed time
improvement if their parallelism is well balanced. An
example of a comparison between sequential prefetch and
parallel processing follows:
SEQUENTIAL PROCESSING:
---------------------
With sequential processing, all requests for the various
partitions of a table space (four in our example, P1, P2, P3
and P4) are processed in order, one partition after each
other.
CP Processing: !---------!---------!---------!---------!
P1 reqs P2 reqs P3 reqs P4 reqs
Elapsed Time: !-----------------------------------------!
In the preceding diagram, a single thread performs multiple
requests against the four partitions of a table space. From
both the user and DB2 analyst perspective, the elapsed time
of this thread, commonly referred to as the response time, is
indeed the sum of the times used to perform sequential
requests (plus I/O and wait times not represented here).
PARALLEL PROCESSING:
-------------------
With parallel processing, DB2 can generate several subtasks
(running in parallel), one task per partition performing all
the requests for this specific partition.
CP Processing: !---------!
P1 reqs
!---------!
P2 reqs
!---------!
P3 reqs
!---------!
P4 reqs
Elapsed Time: !-----------!
In the preceding diagram, the elapsed time of the thread is
greatly reduced, again from both the user and the analyst
perspective. However, complications occur when you switch
from diagrams to actual measured data to establish service
level objectives or monitor CP parallelism activity.
The following topics present more detailed information:
1 - Understanding Elapsed Time CA MICS Metrics
2 - Data Analysis Guidelines