Fast Unload elapsed time increased after maintenance for SELECT processing via native SQL.

Products

• Fast Unload for DB2 for z/OS

Issue/Introduction

After applying maintenance, Fast Unload for Db2 for z/OS (PFU) executions that previously ran under a minute are now executing more than 15 minutes. 
The total rows from the table are almost the same and even the resulting rows of the unload are less now than before.

The only difference in the jobs that we see is that before the maintenance we had the message: PFU0307W - "ZIIP YES" NOT SUPPORTED FOR "SQL-ACCESS ONLY"  

The SELECT statement processed is passed to Db2 for processing due to SQL-ACCESS ONLY specified.

Resolution

It was discovered that the SQL being executed by PFU was operating as poorly when run using DSNTIAUL with multi-row fetch setting.

PFU was running with SQL-ACCESS ONLY setting and uses multi-row fetch which passes the SQL directly to DB2 for processing so there are no PFU parameter
settings that could be used to impact the processing of the SQL as it is done entirely in Db2 and then the results handed back to PFU.  

IBM indicated the multi-row fetch parameter also controls whether parallelism is used for the query:

When multi-row fetch is used, parallelism might be disabled in the last parallel group in the top-level query block for a query. For very simple queries, parallelism
might be disabled for the entire query when multi-row fetch is used. To obtain full parallelism when running DSNTIAUL, switch DSNTIAUL to single-row fetch mode
by specifying 1 for the number-of-rows-per-fetch parameter.

Site utilized PFU MULTI-ROW-FETCH 1 syntax as elapsed time of the jobs returned to expected times.