IBM Db2 Analytics Accelerator for z/OS Version 7.5.1 Release Notes

Please find information about new functions here .

Accelerator on IIAS-specific considerations

If you plan to install or upgrade IBM Db2 Analytics Accelerator, please contact IBM support by opening a case.
For an upgrade we would like you to create an Appliance trace and to upload it to the support case for an offline health check of the system.
Further, before you begin, please consider the description in APAR PH24629.

The steps to be performed for an upgrade to 7.5.1 depend on your current maintenance level of the accelerator:

Accelerator on Z-specific considerations

If you plan to install or upgrade IBM Db2 Analytics Accelerator, please contact IBM support by opening a case.
For an upgrade we would like to know your current maintenance level of the accelerator software and the one you want to upgrade to.

The steps to be performed for an upgrade to 7.5.1 depend on your current maintenance level of the accelerator:

1) Current maintenance level: 7.5.0.2, 7.5.0.1, 7.5.0, or 7.1.9:
We recommend to migrate directly to maintenance level 7.5.1.

2) Current maintenance level: prior to 7.1.9
A two-step upgrade process is mandatory: in step 1 you upgrade to maintenance level 7.1.9, in step 2 you upgrade 7.1.9  to maintenance level 7.5.1. We recommend to perform the two required upgrade steps in the same maintenance window.

Further considerations:

• Maintenance level 7.1.9 significantly changed how the product is configured. Instead of using the Web UI to configure network and storage directly, the configuration is now imported into the Web UI from a separate file. Refer to the Installation Guide for more details.
• An alternative for the deployment on IBM Z (without massive tables and without accelerator-only tables) is to reinstall the current instance, or provision a completely new instance, and then reload the data from Db2 for z/OS.

Click here for the list of APARs having been fixed.

• Accelerator-only tables

  • Multi-row inserts fail if rows contain NULL values to be inserted in columns of data type BINARY or VARBINARY.

• Tracing

  • The information collected by the apdiag tool is not included in the trace archive of the appliance.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
   

The SYSPROC.ACCEL_LOAD_TABLES stored procedure behaves differently if automatic change detection is enabled.
Before version 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 version 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 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.

• therefore, a partition in an accelerator-shadow table is always fully reloaded to ensure that all changes are finally transferred. A reload is started even if the partition had no further changes since then.

General recommendations

• Under a high system load, the accelerator might appear slow or run into timeouts.

  Recommendation: Do not run more than 30 load threads in parallel.

Queries

• A query running during a partial reload of an incrementally updated table might be unable to access the new partitions.

  Recommendation: Rerun the query after the partial reload has finished.

• A query referencing a large set of federated objects could result in an SQLCODE -904: 954: Not enough storage is available error

  Recommendation: Contact IBM support for assistance.

• A query referencing several tables using union all views could run slower than V5.
  Example use cases are when union all views are used for collecting data from multiple branch offices and each branch-office has a schema-identical table that your are all referencing in a single query.

  Recommendation: Contact IBM support for assistance.

• When executing a query with a large result set, the query could be slow.

  Recommendation: Contact IBM support for assistance.

• An SQL query might hang in IBM Db2 Analytics Accelerator

  Recommendation: Cancel the query from IBM Db2 Analytics Accelerator Studio, or call the SYSPROC.ACCEL_CONTROL_ACCELERATOR stored procedure that uses the <cancelTasks> command.

• An SQL statement that contains a CAST on a column with the time data type as a character data type may return with colon delimiters instead of dot delimiters once after a table is loaded.
  Example: For the following query "SELECT cast(c_time as char(8)) from T1"
  On Db2 12 for z/OS the value returned is "13.10.00" as a character string. On the accelerator the value returned is "13:10:00" as a character string. This occurs only once after a table is loaded.

Loading tables

• After running the REORG utility in Db2 12 for z/OS,  reloads might be wrongly recommended for partitions that have already been loaded on the accelerator.

  Recommendation: To receive correct reload recommendations, do not use interactive load recommendations and batch job change detection at the same time.

• If you run SYSPROC.ACCEL_LOAD_TABLES with lock mode "TABLESET", the operation might fail and return an AQT10071E error.

  Recommendation: Cancel the previous load and rerun the load operation.

Incremental updates

• CDC based replication: The time needed to reload a set of incrementally updated tables increases as well as the replication latency.

  Recommendation: Pause after each reload, as this allows the system to come back to normal throughput rates and latency levels.
  As an alternative: use Integrated Synchronization based replication.

• Long load scenarios, during which a continuous replication setup collects about 24 million rows, might cause the integrated synchronization function to run out of memory.

  Recommendation: Try a reload. If the problem reoccurs, load the table with lock mode tableset.

Monitoring

• The values of the monitoring counter Q8STTMUD are too high, for example 0.18E+20.

  Recommendation: Ignore the high value. It will be corrected during the next collection of statistics.

• The monitoring values of the Q8STCQL, Q8STCQLS, and Q8STQUEW metrics might be displayed incorrectly.

Miscellaneous

• Under a very high system load caused by the parallel execution of various operations, such as 'Add Tables', 'Remove Tables', and 'Alter Keys', the accelerator might restart unexpectedly, leading to the abortion of running tasks or queries.
  Symptoms are aborted tasks, lock timeout exceptions, or messages with SQL code -911, SQLSTATE=40001, and rc=68.

  Recommendation: Reduce the task diversity of parallel jobs if you process large 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.

• Error when removing multiple tables in parallel. The following error message is "AQT20118E: A distributed commit between the stored procedure and the server failed for the following reason: Distributed commit failed while initiator was preparing for commit".

  Recommendation: Repeat the operation.

Issues specific to IBM Db2 Analytics Accelerator on Z

• During the replication of changes based on Integrated Synchronization the accelerator might run out of disk space in rare cases.

  Recommendation: As mitigation reload the table and open a support case for further assistance.

• Error AQT10050E occurs during the pairing of an accelerator or during a process that  adds or removes a multitude of tables: 
  "AQT10050E - An internal error occurred on the 'unknown' accelerator:  An assertion '( false )' failed.  Additional info: Failed to acquire SQL transaction serialization lock for request."

  Recommendation: Restart the accelerator from the IBM Db2 Analytics Accelerator Console. If the issue persists, restart the database engine of the accelerator from the same console.

• Installation fails with message AQTST130E shown in IDAA-on-Z Admin UI log. 
  This issue might show up in IDAA-on-Z zFCP environments, especially in case when there is no proper blocklisting or zoning in place.

  Recommendation: It helps to recover the system by restarting the node with the failing disk. Use zFCP zoning if possible.