This document describes enhancements and fixes in IBM Db2 Analytics Accelerator for z/OS Version 7.1.7.
Find information about new functions here.
The behavior of stored procedure SYSPROC.ACCEL_LOAD_TABLES using automatic change detection was changed. Prior to maintenance level 7.1.7, a load job with a setting of detectChanges=“DATA” sometimes did not capture the changes in all partitions if the lock mode NONE had been used for the previous load. This was fixed with 7.1.7. The new behavior: If you use lock mode NONE and detectChanges=“DATA”, it can happen that more changes are detected than are actually transferred to the accelerator. This is caused by the SKIP LOCKED DATA option, which is used implicitly by the Db2 Unload Utility. If parts of the data were locked by other processes, then this data is ignored and not unloaded to the accelerator. To ensure that all changes are finally transferred, a partition in an accelerator-shadow table is always fully reloaded if it was previously loaded with lock mode NONE and detectChanges=“DATA”. A reload is started even if the partition had no further changes since then.
Recommendation Do not run more than 30 load threads in parallel.
Recommendation Do not use the multi-row insert method under these conditions.
Recommendation Wait 30 seconds before you submit queries to a newly paired accelerator.
This will be fixed in an upcoming release.
Recommendation To receive correct reload recommendations, do not use interactive load recommendations and batch job change detection at the same time.
The load operation fails with message AQT20113E: Operation RECEIVE, which was supposed to transfer 4 bytes on TCP/IP socket 2, failed because the connection to the remote machine at IP address is unknown and port 0 has been closed unexpectedly. Reason: errno = 1121 (EDC8121I Connection reset.). Recommendation Repeat the load operation. If the problem reoccurs, restart the accelerator server from the IBM Db2 Analytics Accelerator Console. If the problem persists, open a service request and provide a trace file.
It takes a long time to reload a set of incrementally updated tables, incremental update processing also takes longer and the replication latency increases.
Recommendation Pause after each reload, as this allows the system to come back to normal throughput rates and latency levels.
Network issues or component failures might lead to an interruption of incremental update processes. In such a situation, it can happen that the log reader position, as reported by the CDC capture agent, does not advance anymore. Moreover, the replication counters reported by the SYSPROC.ACCEL_GET_ACCELERATOR_INFO stored procedure do not increase any further. Recommendation Stop affected incremental update processes. Then restart these.
Recommendation The high value can be ignored. It will be corrected during the next statistics collection.
Recommendation Reduce the task diversity of parallel jobs if you process big table sets with more than 100 tables. For example, do not run 'Alter Keys', 'Add Tables', and 'Remove Tables' operations at the same time. Reduce this to 'Alter Keys' and 'Add Tables' jobs or any other combination of just two different tasks. If a query failed, rerun the query.
Recommendation Restart the aborted tasks and queries.
Recommendation Apply APAR PH10672.
Recommendation Contact IBM to get support with memory configuration and reload recommendation.
Recommendation You can ignore the wrong status message.
Recommendation Use only FICON DASD or only FCP storage devices for a specific storage pool definition.
Recommendation If this window does not come up shortly after clicking the button, click the button again.